ORTHOGONAL SUB CHANNEL (OSC) BSS21309, BSS30385, BSS30390 BSC S15 Requirements Specification Nokia Siemens Networks Radio Access Base Station Controller For Internal Use ____________________________________________________________________ ______________ Version Author/Checked by Approved by Feature Number Pages 1.1-0 02/09 P.Virsu 09580 231 J.Rämä, T.Räisänen, J.Saikko, J.Kaasalainen ____________________________________________________________________ ______________
Transcript
ORTHOGONAL SUB CHANNEL (OSC)BSS21309, BSS30385, BSS30390
6.1 Control of the optionality and licensing 256.1.1 BSS21309-001 Double Half Rate with SAIC MS is optional software 25
6.2 General requirements 256.2.1 BSS21309-002 BSC shall accept information of TRX OSC support 256.2.2 BSS21309-003 TRX parameter for OSC support 266.2.3 BSS21309-004 BTS parameter for controlling the use of the feature 266.2.4 BSS21309-056 AMR HR is a prerequisite for Double Half Rate 276.2.5 BSS21309-005 DHR channels in MML printouts 286.2.6 BSS21309-050 OSC limitation in hopping configuration with different TRX HW variants 286.2.7 BSS21309-008 Uplink RX level of neighbouring OSC subchannel 286.2.8 BSS21309-009 Optimized TSC pairs 296.2.9 BSS21309-010 OSC shall be deployed for SAIC capable MS 316.2.10 BSS21309-012 TRX OSC support 316.2.11 BSS21309-013 Rx diversity 326.2.12 BSS21309-014 Double Power TRX and Intelligent Downlink Diversity with OSC 326.2.13 BSS21309-015 Triggering of DHR multiplexing 336.2.14 BSS21309-016 Target TRXs in multiplexing 346.2.15 BSS21309-017 Rx level and power control information update 346.2.16 BSS21309-018 Co-operation with traditional AMR HR packing 356.2.17 BSS21309-019 UL Rx level change rate 356.2.18 BSS21309-020 Target TCH/H for OSC multiplexing 366.2.19 BSS21309-021 Second candidate for multiplexing 376.2.20 BSS21309-022 Selecting the best pair of calls for multiplexing 396.2.21 BSS21309-023 MS power optimization in multiplexing handover 396.2.22 BSS21309-024 BS power control in multiplexing handover 406.2.23 BSS21309-051 Abis resource for OSC-1 416.2.24 BSS21309-025 Dynamic Abis resource 416.2.25 BSS21309-026 OSC channel activation 426.2.26 BSS21309-027 ASSIGNMENT COMMAND for OSC-1 436.2.27 BSS21309-028 DHR multiplexing with a handover to an OSC-1 subchannel UC 436.2.28 BSS21309-029 DHR multiplexing with a handover to an OSC-0 subchannel UC 476.2.29 BSS21309-030 Handover and power control thresholds for OSC DHR connections 506.2.30 BSS21309-031 Quality threshold to trigger demultiplexing 506.2.31 BSS21309-032 Processing and threshold comparison of OSC DHR connections UL Rx Level measurements 516.2.32 BSS21309-033 Demultiplexing based on UL Rx Level difference 526.2.33 BSS21309-034 Demultiplexing based on UL Rx Level difference UC 536.2.34 BSS21309-035 Limiting of OSC DHR connection uplink power control 546.2.35 BSS21309-036 UL Rx Level balancing of paired OSC DHR connections UC 556.2.36 BSS21309-037 Downlink power control 576.2.37 BSS21309-057 Configuration limitation with Double Half Rate 586.2.38 BSS21309-053 Channel handling capacity with Double Half Rate 596.2.39 BSS21309-039 No OSC multiplexing for Emergency Calls 596.2.40 BSS21309-040 Pre-emption of DHR calls 606.2.41 BSS21309-041 No OSC multiplexing for DTM calls 606.2.42 BSS21309-042 Blocking of DHR multiplexing due to DHR channel activation failures 616.2.43 BSS21309-043 No EGPRS2 TSL followed by OSC TSL 616.2.44 BSS21309-052 DHR in Resource Availability Measurement 626.2.45 BSS21309-054 Double Half Rate performance 63
6.3.1 BSS21309-044 Preventing demultiplexing with poor Rx quality 636.3.2 BSS21309-045 Rx level criteria for demultiplexing 646.3.3 BSS21309-055 Connection specific Rx level trigger for demultiplexing 64
6.4 DFCA requirements 656.4.1 BSS21309-046 TSC selection for a DHR connection in DFCA 656.4.2 BSS21309-047 C/I calculation for a DHR connection in DFCA 666.4.3 BSS21309-048 No SAIC offset for OSC connection 666.4.4 BSS21309-049 Pairing with DFCA 67
6.5 Postponed or rejected requirements 676.5.1 BSS21309-006 OSC support for Epsilon TRX, POSTPONED 676.5.2 BSS21309-007 Independent DTX control for each OSC subchannel, REJECTED 686.5.3 BSS21309-011 BSC shall allocate AMR HR calls as OSC calls, REJECTED 696.5.4 BSS21309-038 OSC-1 channel release, REJECTED 69
7 REQUIREMENTS FOR THE FEATURE BSS30385 CIRCUIT SWITCHED DYNAMIC ABIS POOL 70
7.1 General CSDAP requirements 707.1.1 BSS30385-001 General CSDAP Requirements 707.1.2 BSS30385-002 CSDAP radio network object 717.1.3 BSS30385-003 Modifications to BCF radio network object 737.1.4 BSS30385-004 Circuit group amount increase 74
7.6 Abis loop test for CSDAP circuits 1147.6.1 BSS30385-027 Abis loop test for CSDAP circuits 1147.6.2 BSS30385-030 Abis loop test shall be done for each CSDAP attached to BCF during automatic comissioning test 1147.6.3 BSS30385-028 Abis loop test for CSDAP circuits UC 115
7.7 Control of the optionality and licensing 1197.7.1 BSS30385-029 Circuit Switched Dynamic Abis Pool is optional software 119
9.2.2.3.1 CSDAP id 1569.2.2.4 BTS_TEST_REPORT (ABIS_LOOP_TEST) message 1579.2.2.5 Ack-Nack 157
9.3 Compatibility 1599.3.1 Double Half Rate with SAIC MS 1599.3.2 Circuit Switched Dynamic Abis Pool 1599.3.3 Dynamic Soft Channel Capacity 159
9.4 Effects to SoC 159
9.5 Requirements for the DX200 Platform 160
9.6 Capacity and performance 160
9.7 Interaction with other features or functionalities 1619.7.1 AMR Half Rate 1619.7.2 Circuit Switched Dynamic Abis Pool, Packet Abis 1619.7.3 Rx diversity 1619.7.4 Emergency calls 1619.7.5 Dual Transfer Mode 1619.7.6 AMR Unpacking Optimization 1619.7.7 Improved AMR packing and unpacking 1619.7.8 Frequency hopping 1629.7.9 Dynamic Frequency and Channel Allocation 1629.7.10 Enhanced Coverage by Frequency Hopping, Intelligent Underlay-Overlay, Handover Support for Coverage Enhancements 1629.7.11 Extended Cell Range 1629.7.12 Wideband AMR 1629.7.13 Tandem-free Operation 1629.7.14 UL interference level update procedure 1629.7.15 Double Power TRX 1629.7.16 Intelligent Downlink Diversity 1629.7.17 4-way uplink diversity 1639.7.18 Soft Channel Capacity 1639.7.19 Dynamic Soft Channel Capacity 163
The traditional voice services consumption is expected to grow close to three fold by 2012. This growth is fuelled by new subscriptions, completing of coverage and by lowering tariffs. Declining revenue per delivered minute sets continuously increasing challenges on operators. Because of this, GSM networks need to further evolve to new levels of efficiency.
Orthogonal Subchannel (OSC) is a feature that enables operators to increase the radio channel capacity for voice in their GSM networks. Increasing the voice channel capacity is provided by adoption of quaternary modulation scheme in downlink and spatially orthogonal subchannels in uplink. These two key techniques linked with AMR give the possibility to serve two handsets, that support single antenna interference cancellation method (SAIC), simultaneously in a single radio traffic channel.
Double Half Rate with SAIC MS implements the Orthogonal Subchannel feature for half rate traffic channels. This is according to the approach represented in the Orthogonal Subchannel System Feature Specification. The SFS proposes a phased implementation where the first release of the feature shall include support for OSC in HR traffic channels only. OSC functionality in a TCH/F is left for further development in later BSS releases.
Orthogonal subchannel feature is included in 3GPP release 9 as a study item called VAMOS (Voice services over Adaptive Multi-user Orthogonal Sub channels). However, this BSC requirements specification aims at specifying the half rate part of the feature for the legacy MSs without the improvements that release 9 would bring. This arrangement allows the early introduction of the feature independent of the specification work in 3GPP. Having a sufficient penetration of mobile phones to support Rel-9 standardized OSC will in any case take some time. With an OSC feature for the legacy MSs operators can make good use of the feature already before that.
Voice channel capacity of the BSC will remain the same at the introduction of the Double Half Rate feature. Operator should take this into account and consider actions to compensate the increased TRX channel capacity. One option is to apply the Dynamic Soft Channel Capacity feature.
Use of Double Half Rate (DHR) always requires additional Abis transport capacity for the second OSC connection in a half rate TCH channel. Additional Abis transport capacity shall be provided by Dynamic Abis or by Packet Abis.
A broad enough LAPD signalling link is required to handle the increased amount of radio measurements and signalling caused by increased amount of calls per TRX. Operator shall have to define at minimum a 32 kbit/s LAPD signalling link, when OSC is enabled in a TRX.
BSC supports Double Half Rate with SAIC MS for Flexi EDGE BTS.
Double Half Rate with SAIC MS is an application SW feature controlled with license.
1.1.1 Benefits
Double Half Rate with SAIC MS improves cost efficiency of GSM voice and supports the vision of 5 billion mobile users by 2015.
Double Half Rate with SAIC MS provides operators the capability to exploit installed hardware efficiently or even reduce it. Operators can fully exploit the available spectrum with less TRX hardware compared to AMR.
System simulations have shown significant gains in capacity with the Double Half Rate feature when the available spectrum is exploited with a low number of TRXs. The increased capacity per TRX reduces the energy consumption per user. Energy consumption required per Erlang can be expected to reduce by tens of percents.
Double Half Rate with SAIC MS provides for an operator a profitable path to grow with minimized CAPEX and OPEX. Coverage area can be maintained in capacity extensions with the Double Half Rate feature and the need to add new sites is avoided, thus, lowering considerably the operator’s expenditures.
Double Half Rate with SAIC MS is applicable with the existing GSM SAIC handsets, providing network operators an immediate gain with just a software upgrade in their GSM radio network.
As Double Half Rate with SAIC MS increases voice capacity, it also releases capacity for data traffic. When another radio technology or another operator needs to share the same site, antennas or input ports of combiners may be released by the introduction of Double Half Rate with SAIC MS.
Nokia Siemens Networks estimates that Double Half Rate with SAIC MS is reducing a GSM operator’s CAPEX and OPEX for voice service by up to 50%.
1.2 Circuit Switched Dynamic Abis Pool
In legacy Abis interface there is fixed transmission capacity configured for each radio timeslot. When Double Half Rate with SAIC MS is taken into use more Abis transmission capacity is needed because two DHR calls are multiplexed into one TCH/H. Circuit Switched Dynamic Abis Pool (CSDAP) feature offers common Abis transmission pools that can be shared by all calls in a BCF cabinet. With CSDAP operator avoids the need to configure additional fixed Abis transmission capacity when taking the Double Half Rate feature into use.
The absolute maximum for the TCH handling capacity of a BCSU unit is 8 times the maximum amount of TRXs in the BCSU. This is the maximum amount of active TCHs in a BCSU. The BSC can never exceed this maximum capacity.
The BSC makes sure that in each created TRX of a BCSU it is possible to activate as many calls as there are TCH TSLs in the TRX. This is 100% assured channel capacity.
When the Soft Channel Capacity feature is used the BSC allows to configure more TCHs than there can be active TCH connections in a BCSU. This is achieved with the use of half rate TCHs and the Double Half Rate feature which further doubles the amount of configured TCHs in HR capable TSLs.
When the configured TCH amount in the TRXs of a BCSU exceed the active channel capacity of the unit then all the configured TCHs in a TRX cannot be activated even though there is idle signalling capacity available in the BCSU. This is because the BSC reserves part of the BCSU capacity to guarantee the assured channel capacity in each TRX.
Dynamic Soft Channel Capacity feature introduces the possibility to give up the 100% TCH capacity assurance. Operator can define certain amount of BCSU capacity to be freely available in the TRXs where the need exceeds the 100% assured channel capacity. Certain minimum capacity is still ensured for the TRXs with little or no traffic.
While Dynamic Soft Channel Capacity allows utilizing BCSU capacity more dynamically it increases the amount of actual transmitted traffic in the BSC.
Orthogonal Subchannel (OSC) is a voice capacity feature that enables to assign two AMR calls on the same radio traffic channel. OSC can double TRX channel capacity in optimal radio propagation conditions for handsets that support single antenna interference cancellation method (SAIC).
The two OSC subchannels OSC-0 and OSC-1 in a TCH/H are called as double half rate (DHR) channels. DHR subchannels OSC-0 and OSC-1 are independent of each other, i.e. they have independent RR layer signalling. The separation between the simultaneous connections in a TCH is enabled by the use of separate training sequences. Subchannel specific Training Sequence Codes (TSC) are optimised in TSC pairs for lowest cross-correlation.
Use of DHR always requires additional Abis transport capacity for the second OSC subchannel (OSC-1). Additional Abis transport capacity can be provided with Dynamic Abis as introduced in chapter 7. An alternative method for providing the needed extra Abis transport capacity is Packet Abis /B/.
OSC-0 is the subchannel using legacy Abis transport resources and the legacy TSC of the TRX. OSC-1 is the subchannel using additional Abis transport resources and additional TSC.
In downlink OSC uses quaternary phase shift keying (QPSK). QPSK modulation carries two orthogonal subchannels which can be received by legacy SAIC handsets like normal GMSK. The separate reception of the subchannels is enabled by the orthogonality of the subchannels and the different training sequences of the subchannels. Figure 1 shows the mapping of users to OSC subchannels carried by QPSK in downlink. Receiver of MS makes decisions related to I or Q axis, i.e. receiver is studying the sign of I or Q signal components depending on allocated OSC channel.
Figure 1 Mapping of OSC users to QPSK constellation
In downlink DHR has about 3 dB weaker performance than legacy AMR HR. Thus, DHR shall not be applicable in the most demanding radio conditions. By using existing AMR FR and AMR HR together with the new OSC DHR network capacity can be increased without compromising voice quality. Figure 2 illustrates the adaption between the three channel rates.The network capacity increase is dependent on radio conditions. Typically, Double Half Rate may be used in over 50% of the connections.
Figure 2 Channel rate adaption with AMR FR, AMR HR and DHR
In OSC uplink handsets use traditional GMSK transmission. Simultaneous users in a TCH/H differentiate only in training sequence and propagation path. BTS will need antenna diversity with two antennas to facilitate the reception of two simultaneous users. UL Rx level balance between the OSC subchannels on a TCH/H is needed for the simultaneous reception of the two users to be possible with reasonable quality in the BTS. The received power in BTS should be aligned by means of power control and proper user pairing.
BTS separates users with a multi-user detection (MUD) receiver. BTS applies 4 th generation mobile communications technology, a method called Multi User Multiple Inputs Multiple Outputs (MU-MIMO), to enable the simultaneous reception of the two OSC subchannels.
In Double Half Rate with SAIC MS feature the target channel for OSC packing, also called as multiplexing, is always a TCH/H where an AMR call is already going on with sufficient signal level and quality. For the ongoing AMR HR connection another
adequate AMR call is searched for so that the UL Rx levels of the two connections can be adjusted close enough to each other.
In the OSC multiplexing procedure an AMR call is handed over to the target TCH. The original channel rate of the AMR connection to be handed over can be either half rate or full rate. Thus, Double Half Rate with SAIC MS includes also the option of multiplexing into DHR straight from AMR FR. The target for the multiplexing handover is however a TCH/H.
Unpacking from DHR, also called as demultiplexing, can be caused by the deteriorating quality of a DHR connection or by the weakening UL Rx level balance between the OSC subchannels. In the former case, by default, the demultiplexing handover is made into a FR TCH. Additionally, when the AMR Unpacking Optimization feature is used the demultiplexing handover can be into a HR TCH or into a FR TCH depending on the radio conditions. If the reason for demultiplexing is the excessive UL Rx level difference between the multiplexed calls the handover to be made is primarily into a HR TCH.
During the multiplexing procedure BTS switches from GMSK modulation to QPSK modulation in downlink transmission for the original connection on the target TCH/H. Likewise, during the demultiplexing procedure where one of the OSC connections is handed over to another TCH as a traditional AMR connection the BTS switches to GMSK modulation in downlink transmission for the OSC connection that remains in the original TCH/H.
DHR multiplexing shall trigger based on traffic load in a BTS. The triggering load limit shall be an operator parameter based on a similar definition for load as in the traditional parameters of AMR HR packing. The load limit parameter serves also as a BTS specific control function for the feature with which you turn the feature on and off in a BTS.
2.1.2 BSS30385 Circuit Switched Dynamic Abis Pool
In legacy Abis interface there are allocated 16 kbit/s fixed transmission capacity for each RTSL from Abis ETPCM. When OSC is taken to use then more Abis transmission is needed for RTSL because two calls are multiplexed to one HR (or FR) TCH. There is no sense to allocate double fixed transmission capacity for each RTSL because extra transmission is needed only when there is high load situation in the cell. Circuit Switched Dynamic Abis Pool feature offers possibility to create common transmission pool(s) for OSC DHR calls to BCF cabinet. This Circuit Switched Dynamic Abis Pool (CSDAP) can situate in the same or different Abis ETPCM as TRXs using it. Abis transmission resources can be allocated for all TRXs of BCF cabinet from the same CSDAP.
The maximum active channel capacity of a BCSU is 8 times the maximum amount of TRXs in the BCSU. The BSC can never exceed the maximum channel capacity of a BCSU. When the maximum amount of TRXs has been created to a BCSU the BSC makes sure that in each created TRX of the BCSU it is possible to activate as many calls as there are TCH TSLs in the TRX. This is the assured channel capacity.
When BSC configuration does not contain maximum amount of TRXs then it is possible to use the unused TCH handling capacity (free assured channel capacity) in the existing TRXs for HR and DHR TCHs.
Without the Soft Channel Capacity feature it is not possible to create more TCHs (FR, HR, DHR TCHs) to BCSU than its maximum TCH handling capacity is.
When the Soft Channel Capacity feature is active then it is possible in TRX configuration to exceed the maximum TCH handling capacity of BCSU. But BSC can activate neither HR nor DHR TCHs to a TRX if it would lead to the situation where the activation of the assured channel capacity in some other TRX of the same BCSU is threatened.
Dynamic Soft Channel Capacity feature presents possibility to change assured channel capacity so that system does not need to guarantee 100 % FR TCH capacity for each TRX but operator can define an applicable value for the TRX specific assured channel capacity (8…1) with a BSC specific parameter. Operator purchases the Dynamic Soft Channel Capacity as TRX licences, each TRX licence corresponding to 8 TCHs. Operator is able to utilize the capacity defined by the licence amount dynamically in the TRXs where the need exceeds the 100% FR TCH capacity. At the same time operator can ensure with the assured channel capacity parameter that certain capacity remains available also for the TRXs where there is not much traffic at that time.
Dynamic Soft Channel Capacity enables the BSC to utilize BCSU capacity more efficiently. This increases the actual amount of traffic transmitted in the BSC. This further leads to the increase in the loading of the computer units of the BSC.
1 Epsilon TRX support is included in the RS but the related BSS15 CR /H/ has not been approved yet.
The Epsilon support related requirement BSS21309-006 has been listed in the postponed requirements, RS shall be updated according to the CR decision once that takes place.
BC Business critical. The feature has no value, or BSC competitiveness is seriously threatened, if this requirement is not implemented.
E Essential. This requirement is an essential part of the feature. If this requirement were not implemented, an important part of the feature would be missing.
I Important. The requirement adds something (e.g. usability, a minor function) to the feature, but is still a “nice-to-have” (at least if something must be dropped).
Requirement type:
UC Use caseF Functional requirementP Performance requirementT Technical requirement
5.2 Postponed or Rejected Requirements
Le-vel
I&V Req id Req name Prio-rity
Ty-pe
Domain Comments
1 X BSS21309-006 OSC support for Epsilon TRX
E F O&M, telecom
POSTPONED due to the pending approval of the related BSS15 CR /H/
1 BSS21309-007 Independent DTX control for each OSC subchannel
I T telecom This is no actual requirement for the BSC and is removed to avoid confusion
1 x BSS21309-011 BSC shall allocate AMR HR calls as OSC calls
I F telecom OSC indication for an AMR HR call is not required to enable DHR multiplexing later
1 x BSS21309-038 OSC-1 channel release E F telecom Issue is better covered by requirement BSS30385-018.
1 x BSS30385-017 CSDAP Resource Allocation Failure alarm
I F telecom SFS: BSS21309-018
Circuit Switched Dynamic Abis Pool Failure alarm can offer needed information.
1 X BSS30390-003 TRX parameter for dynamic channel capacity
E F O&M, telecom
Removed with the changed licencing principles according to finding in first review
6 REQUIREMENTS FOR THE FEATURE BSS21309 DOUBLE HALF RATE WITH SAIC MS
6.1 Control of the optionality and licensing
6.1.1 BSS21309-001 Double Half Rate with SAIC MS is optional software
Double Half Rate with SAIC MS shall be optional software. Optionality shall be controlled with a capacity licence that is based on TRX amount. The BSC shall allow operator to modify the feature’s control parameters when there is a valid licence for the Double Half Rate with SAIC MS feature and the feature’s state is ON or CONF. The BSC shall allow enabling the feature in a BTS when there is enough of unused licence capacity available to cover all the TRXs in the BTS.
The BSC shall check the availability of licence capacity for Double Half Rate (DHR) in all unlock scenarios (BCF/BTS/TRX) where a TRX is taken in use in a BTS where the Double Half Rate with SAIC MS feature has been enabled. The BSC shall prevent the action if it would lead to the exceeding of the licenced capacity. In general, unlocking of a BCF, unlocking of a BTS and unlocking of a TRX in a configuration where a related BTS has DHR enabled shall require that the Double Half Rate with SAIC MS feature’s state is ON.
Similar checking as for the unlock cases above shall be included also for the enabling of the Double Half Rate feature in a BTS as this shall be made with an online parameter.
The BSC shall perform OSC DHR multiplexing only when the feature’s state is ON.
Rationale: BSS SW business reasons
Source: SFS
Linked requirements:
6.2 General requirements
6.2.1 BSS21309-002 BSC shall accept information of TRX OSC support
The BSC shall accept the information about OSC support for each FlexiEDGE TRX in the BTS_STATE_CHANGED message from the BTS. The information is in the message as a new optional OSC Support Information Element. When the OSC Support IE is included in the BTS_STATE_CHANGED message the BSC shall save the information in it to the BSS Radio Network Configuration Database.
BSC must know the OSC capability of a TRX when selecting TCH resources for OSC usage.
Source: SFS:BSS21309-006
Linked requirements: BSS21309-003
6.2.2 BSS21309-003 TRX parameter for OSC support
OSC support information shall be a read-only TRX parameter in the BSS RNW Configuration Database. Operator shall not be able to modify the value of the parameter but shall be able to print out the parameter with ZERO command. Parameter shall also be delivered to NetAct.
Rationale:
TRX OSC support is system’s internal information but must be visible also for the operator.
Source: SFS:BSS21309-006
Linked requirements: BSS21309-002
6.2.3 BSS21309-004 BTS parameter for controlling the use of the feature
The use of OSC DHR shall be controlled with a BTS object parameter in the BSS RNW Configuration Database.
The new parameter DHR Limit For FR TCH Resources shall indicate the triggering load level for multiplexing using a similar load definition as the traditional AMR HR packing procedure: the multiplexing need is decided based on the amount of idle FR TCH resources.
The default value of the parameter shall be 0 meaning that OSC multiplexing is initially off.
The parameter shall be modifiable online.
When DHR Limit For FR TCH Resources is being modified into a value >0 the BSC shall require that there is additional Abis transport capacity available in the BTS.
The necessary extra capacity shall be provided by the Packet Abis feature or, if not in use, by the Circuit Switched Dynamic Abis Pool (CSDAP) feature introduced in chapter
7. The BSC shall check the availability of Packet Abis from a new BCF object parameter Abis Interface Connection Type /B/.
If the BTS site is connected to the BSC via Packet Abis a separate dynamic Abis pool is not needed to provide the additional Abis transport capacity for OSC-1 subchannels. Packet Abis will provide Abis transport for OSC-1 subchannels exactly in the same manner as for other speech calls.
Rationale:
Having the parameter on BTS level allows the BTS specific control of the feature in segment configuration where the operator may want to apply different policy for different layers of a segment.
Using a similar load definition as in the traditional AMR HR packing makes it easier for the operator to understand and define the relation between OSC multiplexing and AMR HR packing.
The existence of additional Abis capacity needs to be checked in order to avoid unnecessary multiplexing attempts that would lead to failure.
Source: RS team, SFS: BSS21309-038
Linked requirements: BSS21309-001, BSS21309-056
6.2.4 BSS21309-056 AMR HR is a prerequisite for Double Half Rate
The BSC shall make sure that AMR HR packing is in use in a BTS based on the respective load limit parameters before it allows operator to enable Double Half Rate in the BTS. AMR HR can be active based on the load limit parameters on SEG level or based on the load limit parameters on BSC level.
If the licence for the AMR specific load limit parameters is available (Load based AMR packing) the BSC shall decide the activity of AMR HR packing based on the following parameters: AMR lower limit for SEG FR resources (AFRL), AMR upper limit for SEG FR resources (AFRU), AMR lower limit for FR resources (AHRL) and AMR upper limit for FR resources (AHRU).
If the Load based AMR packing licence is not available the BSC shall decide the availability of AMR HR packing based on the general HR load limit parameters lower limit for FR TCH resources (FRL), upper limit for FR TCH resources (FRU), lower limit for FR TCH resources (HRL) and upper limit for FR TCH resources (HRU).
The BSC shall also make sure that while Double Half Rate in in use in a BTS the new parameter DHR Limit For FR TCH Resources is less than or equal to the used lower limit criterion of AMR HR packing.
The BSC shall prevent actions that lead to contradictions against the criteria above.
Rationale:
OSC DHR cannot operate without AMR HR in use. It is reasonable for the BSC to check the necessary availability of AMR HR with OSC DHR to avoid unnecessary problems in situations where operator has missed the requirement based on documentation. Having this checking made by the BSC has no negative effects for general operability because the related parameters can be modified without any object locking.
Source: RS Review
Linked requirements: BSS21309-004, BSS21309-018
6.2.5 BSS21309-005 DHR channels in MML printouts
The BSC shall add information of DHR connections / busy DHR channels in the MML printouts that currently indicate similar information for FR and HR channels separately. These shall include printouts of ZEEI, ZEEL and ZERO commands.
Rationale:
Operator must have means to verify with basic MML printouts how the BSC applies OSC in the network.
Source: RS team
Linked requirements: -
6.2.6 BSS21309-050 OSC limitation in hopping configuration with different TRX HW variants
The BSC shall not perform DHR multiplexing in a BTS where there are both Epsilon TRXs and Odessa TRXs and Antenna hopping is in use in the BTS.
If BB hopping is in use in a BTS and there are both Epsilon TRXs and Odessa TRXs in a BB hopping group the BSC shall not apply OSC multiplexing in the TRXs of the hopping group.
Rationale:
Epsilon TRX and Odessa TRX use different modulator types and cannot support BB hopping nor Antenna hopping with Double Half Rate when in the same hopping group.
6.2.7 BSS21309-008 Uplink RX level of neighbouring OSC subchannel
The BSC shall accept in the Measurement Result message for a DHR channel the uplink RX level information, the related DTX flag and the measurement validity bit of the neighbouring DHR connection in the same TCH/H. These pieces of information shall be a new OSC Neighbouring Sub Channel Measurements IE in the Supplementary Measurement Information of the Uplink Measurements Information Element, see Abis Telecom interface
The BSC shall use the new OSC Neighbouring Sub Channel Measurements IE to decide if the connection itself is a DHR OSC connection or a normal AMR HR connection. If the IE is present then there is also another DHR connection going on in the TCH/H and the BSC shall apply the DHR specific examinations for the connection. The BSC shall verify the RX level balance between the OSC subchannels that share the same radio channel and to decide on the needed demultiplexing, handover and power control actions. Also, the BSC shall collect the DHR specific statistics.
If the OSC Neighbouring Sub Channel Measurements IE is not included then the BSC shall apply the traditional examinations that are made for an AMR HR connection. The BSC shall collect the performance measurement statistics accordingly.
If there are two connections in a TCH/H but the uplink RX level of the neighbouring OSC connection is not available the BTS reports the Rx level value as 0.
For an ongoing connection the BSC shall change between AMR HR mode and DHR mode according to if the new OSC Neighbouring Sub Channel Measurements IE is included in the Measurement Result message or not.
Rationale:
The BSC must be able to decide between actions for an AMR HR connection and for a DHR connection and especially notice the switch between the two modes for an ongoing connection.
During DHR call the BSC can take the RX level balance between the neighbouring OSC subchannels into account when deciding on the individual actions for them.
The BSC shall use fixed TSC pairs for the OSC subchannels sharing the same radio channel. The BSC shall define the TSC value for the OSC-1 subchannel based on the TSC value used for subchannel OSC-0 according to the following table:
TSC for OSC-0 TSC for OSC-1
0 2
1 7
2 0
3 4
4 3
5 6
6 5
7 1
Table 1 Optimized training sequence pairs for OSC
The BSC shall deliver the TSC of an OSC-1 subchannel to the BTS on a call-by-call basis during channel activation.
Rationale:
OSC subchannel recognition by MS is enabled by using different training sequence codes for the two OSC subchannels that share the same radio channel. Also OSC subchannel recognition in BTS is enabled by the different TSCs.
New TSC values are currently being defined for OSC in 3GPP. However, in Double Half Rate feature for the legacy handsets the TSC pairs have to be found among the existing 8 TSC values. The TSC pairs to be used for OSC have been defined based on simulations. Table 2 shows all the suitable pairs there are among the available TSCs /4/. The pairs selected to be used are not necessarily the best ones from a single TSC’s point of view but a compromise in order to have a uniform quality in all TSC pairs.
Table 2 Suitable training sequence pairs for use with existing handsets
TSC delivery to BTS on a call-by-call basis is used already in existing DFCA implementation. In DFCA, TSC pairing for DHR is not based on fixed pairs but all alternatives of table 2 are available. For TSC pair selection in DFCA see section BSS21309-046 TSC selection for a DHR connection in DFCA.
Source: SFS: BSS21309-023
Linked requirements:
6.2.9 BSS21309-010 OSC shall be deployed for SAIC capable MS
The BSC shall apply OSC for an MS which indicates its SAIC support. The BSC receives the SAIC capability information in the Mobile Station Classmark 3 information element within the CLASSMARK CHANGE message.
Rationale:
OSC downlink uses QPSK modulation where each subchannel is detected by an MS as a GMSK modulated channel. The detection requires a SAIC receiver in the MS.
The BSC shall apply OSC multiplexing in a TRX only if the TRX supports OSC. The BSC shall check the TRX OSC support while searching for candidates for OSC multiplexing. The basis for the check shall be the information received from the BTS and saved in BSS RNW Configuration database as a read-only TRX parameter.
If BB hopping is in use in a BTS and there are both TRXs that support OSC and TRXs that do not support OSC in a BB hopping group the BSC shall not apply OSC multiplexing in the TRXs of the hopping group.
If Antenna hopping is in use in a BTS and there are both TRXs that support OSC and TRXs that do not support OSC in the BTS the BSC shall not apply OSC multiplexing in the BTS.
Rationale:
TRX level OSC support varies between different TRX versions and BSC has to take this into account in multiplexing.
Source: SFS:BSS21309-025
Linked requirements: BSS21309-003
6.2.11 BSS21309-013 Rx diversity
The BSC shall allow activating of Double Half Rate (turning parameter DHR Limit For FR TCH Resources to a value >0) in a BTS only if Rx diversity is in use in the BTS. The BSC shall check the use of Rx diversity from the value of the existing BTS object specific RX diversity (RDIV) parameter. If Rx diversity is not in use while operator is trying to turn DHR on in a BTS the BSC rejects the action with an error indication.
The BSC shall allow disabling of Rx diversity in a BTS object only if DHR in not in use in the BTS (parameter DHR Limit For FR TCH Resources = 0). If Double Half Rate feature is in use while operator is trying to turn Rx diversity off in a BTS the BSC shall reject the action with an error indication.
Rationale:
Without RX diversity OSC performance will be very poor with only one antenna. OSC multiplexing is not reasonable in a BTS with RX diversity out of use.
6.2.12 BSS21309-014 Double Power TRX and Intelligent Downlink Diversity with OSC
The BSC shall not apply OSC multiplexing in a TRX that has either Double Power TRX (DPTRX) or Intelligent Downlink Diversity (IDD) feature in use. The use of these features is controlled by an existing TRX object parameter Dual TRX Usage (DTRX). The BSC shall apply OSC multiplexing in a TRX only if Dual TRX Usage parameter is in value “disabled”.
Rationale:
Double Power TRX with OSC would need separate calibration that is different from GMSK and 8PSK.
For Intelligent Downlink Diversity further research is needed to provide phase and delay control algorithms with OSC.
Source: BTS team
Linked requirements: -
6.2.13 BSS21309-015 Triggering of DHR multiplexing
The BSC shall decide the need for OSC multiplexing based on load using a similar load definition as the traditional AMR HR packing procedure: the multiplexing need is decided based on the amount of idle FR TCH resources.
Unlike in the traditional AMR HR packing, the BSC shall make the actual decision on triggering the multiplexing procedure in the channel allocation algorithm at the reception of Rx level and power control information from the HO&PC algorithm.
When the BSC has found out the need for OSC multiplexing it shall result in one multiplexing handover in the BTS. The BSC shall hand an AMR call over to a TCH/H where an AMR HR call is already ongoing.
Rationale:
Using a similar load definition as in the traditional AMR HR packing makes it easier for the operator to understand and define the relation between OSC multiplexing and AMR HR packing.
Multiplexing decisions in the channel allocation algorithm are made based on the data received in the Rx level and power control information update from the HO&PC algorithm. The rate for this update is every 5 seconds. In order to have the best
accuracy in the decisions the multiplexing examinations are made at the reception of the update.
Source: RS team
Linked requirements:
6.2.14 BSS21309-016 Target TRXs in multiplexing
The channel allocation algorithm shall search for the target TCH/H for multiplexing in a BTS among the TRXs that it just received the Rx level and power control information update for.
The BSC shall search for the connection to be handed over to the target TCH/H in DHR multiplexing among all the TRXs of the BTS that it just received the Rx level and power control information update for.
Rationale:
Rx level and power control information update from HO&PC algorithm to channel allocation algorithm is both BTS object and BCSU unit specific procedure. When the channel allocation algorithm in the MCMU unit receives a message for a BTS the message contains data related to some TRXs of the BTS, not necessarily to all of them. Information of the TRXs that are controlled by other BCSU units come(s) independently at some other moment(s) during the 5-second update period that is used in the update procedure.
Source: RS team
Linked requirements: BSS21309-012, BSS21309-014
6.2.15 BSS21309-017 Rx level and power control information update
Rx level and power control information update from HO&PC algorithm to channel allocation algorithm is a procedure of the DFCA feature. For OSC this procedure shall be enhanced to cover all TRXs in OSC use, so far it has included DFCA TRXs only. Also the information in the procedure shall be enhanced to include the quality information that is needed in OSC multiplexing decisions (UL and DL Rx quality). The same averaging method as used in handover decisions shall be used for this quality information.
The decision on OSC multiplexing is practical only in a centralized part of the BSC where there is knowledge of all connections of a BTS. However, all necessary information is not available there based on existing implementation and some enhancements are needed in data exchange between program blocks.
Source: RS team
Linked requirements: BSS21309-015
6.2.16 BSS21309-018 Co-operation with traditional AMR HR packing
Existence of AMR HR calls is a prerequisite for OSC multiplexing. OSC multiplexing shall be a supplementary activity in addition to the traditional AMR HR packing in situations of high load. The BSC shall continue with the traditional AMR HR packing procedure also when it has started the OSC multiplexing procedure.
AMR HR packing and OSC multiplexing shall be mainly separate procedures. However, if DHR multiplexing triggers but there are no ongoing AMR HR calls in the BTS the BSC shall start the traditional AMR HR packing procedure as a secondary option.
Each examination on the need to perform packing of traffic shall result in initiating of only one of the two packing procedures.
The traditional AMR HR packing and DHR multiplexing being independent procedures can lead to a situation where the two procedures are being started simultaneously at different parts of the BSC. When the BSC notices that there are handover attempts for each of the two procedures for a single call it shall interrupt the later one.
Rationale:
Existing AMR HR calls is a prerequisite for OSC multiplexing but otherwise AMR HR packing and OSC multiplexing are separate procedures that can operate quite freely of each other. Having OSC multiplexing as a supplementary activity in addition to AMR HR packing maintains and enhances the efficiency of traffic packing in situations of high load.
Customer documentation should include text about traditional AMR HR packing and AMR HR calls in general being a prerequisite for OSC multiplexing.
The BSC shall take into account the change in the UL Rx level of the two connections it is going to multiplex together. The BSC shall calculate the UL Rx level change between the last two RX level and power control information updates for each connection that is a potential multiplexing candidate. The calculation is made using equation [1]. RX level and power control information update period is 5 seconds. The BSC shall save the connection specific UL Rx level change information to be used when the best candidates for pairing are searched for.
[1]
Calculated UL Rx level change rate, in other words at least two power level updates, shall be a prerequisite for an AMR call to be selected as a candidate for multiplexing.
There shall be an absolute maximum for the allowed difference in the UL Rx level change rates of the two connections that are planned to be multiplexed together. BSC shall reject multiplexing between candidates for which the UL Rx level change rate difference exceeds 10 dB. This threshold shall be adjustable by a new UTPFIL parameter.
Rationale:
By comparing the UL Rx level change rate and change direction between the two connections to be multiplexed together a prediction can be made of the durability of the planned pairing.
Source: RS team
Linked requirements: BSS21309-022
6.2.18 BSS21309-020 Target TCH/H for OSC multiplexing
The BSC shall select as the target channel for DHR multiplexing a TCH/H with an ongoing AMR HR call. The BSC shall check that the call has good enough uplink signal level and sufficient signal quality both in uplink and downlink to be used as a DHR TCH.
The minimum UL Rx level for the target TCH of DHR multiplexing shall be a new parameter OSC Multiplexing UL Rx Level Threshold. This is the absolute minimum UL Rx level with which the BSC shall accept a TCH/H as a target channel for DHR multiplexing.
The minimum quality requirement for the target TCH for DHR multiplexing shall be a new parameter OSC Multiplexing Rx Quality Threshold. The Rx quality of the target TCH has to be at least as good as indicated with this parameter both in uplink and downlink direction.
The BSC shall search for a TCH/H that fulfills the minimum criteria above and has the lowest path loss in uplink, that is, has the highest UL Rx level after the used power reduction effect for the connections has been removed.
Rationale:
OSC multiplexing algorithm shall be based on the existence of AMR HR calls. In multiplexing the original AMR HR connection on the target TCH/H can remain there but the conditions on the channel have to fulfill DHR specific signal level and quality criteria to make sure that the original connection can survive also when multiplexed with another OSC DHR connection.
It is reasonable to apply DHR multiplexing for the best available connections to maximize the probability for the pairing to succeed and last.
Source: SFS, RS team
Linked requirements: BSS21309-021
6.2.19 BSS21309-021 Second candidate for multiplexing
After the BSC has selected a candidate for the target TCH/H of OSC multiplexing it shall search for a multiplexing candidate to be moved to the selected target TCH/H with an intra-cell handover. Let us call this connection to be handed over as the second multiplexing candidate.
The second multiplexing candidate shall always have its UL Rx level so that the difference between the original connection in the target TCH/H and the second multiplexing candidate can be adjusted with power control into a signal level window defined by the new OSC Multiplexing UL Rx Level Window parameter. Equations [2] and [3] give the allowed minimum and maximum UL Rx level values for the second multiplexing candidate. The second candidate’s UL signal level with the effect of the applied power reduction removed is compared with these limit values.
POWER_reductionmaxsecond is the maximum possible uplink power reduction of the second multiplexing candidate and is defined with the following two equations:
[4]
RXLEVmax_UL is the signal level with the effect of the applied power reduction removed. SafetyMargin is a safety margin that is used in existing DFCA algorithm in the definition of initial transmit power. There are existing UTPFIL parameters for BCCH BTS and non-BCCH BTSs of a segment separately for this purpose and these shall be used also for the decision in equation 4..
Also the MS power capability must be taken into account in the maximum value for uplink power reduction.
[5]
MsTxPwrMax is either MsTxPwrMaxGSM or MsTxPwrMaxGSM1x00 depending on the frequency band. MsPowerClass is the maximum power defined by the MS power class.
The default target in the selection algorithm shall be to have the UL Rx level difference between the connections in the OSC pair as small as possible. Equation [6] below defines the target UL Rx level for the second multiplexing candidate:
[6]
Target UL Rx level difference shall be able to be increased with a parameter in UTPFIL. This tuning may become useful for reducing the processing load of the algorithm if this turns out to be critical and the tuning does not reduce the algorithm’s efficiency too much.
The BSC shall search for the second multiplexing candidate within the BTS object where the selected target TCH/H is. The BSC shall search for the second multiplexing candidate equally well among AMR HR and AMR FR calls of the BTS. DHR multiplexing starting from a wideband AMR connection shall not be supported.
The second multiplexing candidate shall fulfill the minimum quality requirement
averaged Rx quality <= Intra HO Threshold Rx Qual AMR FR
both in uplink and downlink direction. Intra HO Threshold Rx Qual AMR FR (IHRF) is an exisiting criterion for the AMR FR -> AMR HR packing. The same parameter applies for both AMR FR and AMR HR connections that are to be handed over into DHR mode as part of OSC multiplexing.
The possibility to prevent AMR FR -> DHR multiplexing shall be included as a UTPFIL parameter. This shall be a measure of precaution for the case that the direct switching from AMR FR to OSC DHR causes too big a change in the end-user experience.
Rationale:
In addition to the quality requirements for the multiplexing candidates the two calls to be multiplexed on a TCH/H need to have their link budgets close enough to each other in order for OSC multiplexing to be feasible.
Allowing multiplexing to OSC DHR directly from AMR FR maintains the efficiency of radio resource packing in cases of high load. Allowing multiplexing similarly for both AMR FR and AMR HR connections increases the probability for finding matching pairs for multiplexing.
Multiplexing taking place within a BTS object follows the established practice that has been adopted with AMR HR packing.
Source: RS team
Linked requirements: BSS21309-020
-
6.2.20 BSS21309-022 Selecting the best pair of calls for multiplexing
The BSC shall define the best pair of connections for DHR multiplexing by combining the following two factors:
1) difference between the UL Rx level of the second multiplexing candidate with the power reduction compensated and the target value of [6]
2) UL Rx level change rate difference between the original call on the target TCH/H and the second multiplexing candidate (change rate defined by equation [1])
The pair of connections that produces the lowest result when the two differences above are summed up shall be selected.
6.2.21 BSS21309-023 MS power optimization in multiplexing handover
The BSC shall optimize the uplink power of the second multiplexing candidate so that the UL Rx level of this shall equal the UL Rx level of the original connection in the target channel when the multiplexing is made. The UL power level of the original call in the channel shall not be changed during the multiplexing handover.
- If the measured UL Rx level of the second multiplexing candidate is lower than the measured UL RX level of the original call in the TCH/H then the MS power needs to be increased from the current level. The power increase shall equal the difference between the measured UL RX levels of the original call and the second multiplexing candidate.
- If the measured UL RX level of the second multiplexing candidate is higher than the measured UL RX level of the original call then the MS power needs to be reduced from the current level. The power decrease shall equal the difference between the measured UL RX levels of the the second multiplexing candidate and the original call.
The possibility to allow for the UL Rx level of the second multiplexing candidate a deviation from that of the original connection shall be enabled by a UTPFIL parameter.
The maximum possible power reduction for UL RX level is defined by equations [4] and [5] in BSS21309-021 Second candidate for multiplexing.
Rationale:
There is no extra power control made for the original connection in the target TCH/H at the time of multiplexing when the second connection is added into the channel. The power level of the second connection has to be adjusted so that the UL Rx levels of the two connections match.
UTPFIL parameter gives possibility to adjust the procedure based on experience gained during actual use.
6.2.22 BSS21309-024 BS power control in multiplexing handover
In downlink the BSC shall optimize the transmit power for the connection that is handed over to the same TCH/H with another connection in order to avoid an unnecessary power increase for the original connection in the channel.
The BSC shall take into account the approximately 3 dB weaker performance of OSC downlink and QPSK modulation in the optimized transmit power that it defines based on the DL path loss differences between the two connections.
The BSC shall define the optimized downlink transmit power for the connection to be handed over with the following equation:
[7]
The 3 dB value of this requirement is based on theoretical assumptions. In order to allow optimization of this activity based on the experience of the actual use the value shall be modifiable through a UTPFIL parameter.
Rationale:
Since OSC downlink with the QPSK modulation has about 3 dB weaker performance than the legacy AMR with GMSK modulation the BSC has to make an extra power increase to keep the experience of the original connection in the channel stable.
Source: RS team
Linked requirements: -
6.2.23 BSS21309-051 Abis resource for OSC-1
When the BSC ends up in a conclusion that a DHR multiplexing handover is to be made into an OSC-1 subchannel it shall check if there is a need to reserve dynamic Abis resource for the OSC-1 channel. CSDAP resource allocation is needed, if the BSC is connected to the BTS with legacy Abis.
The BSC shall decide the need for CSDAP resource allocation based on a new BCF object parameter Abis Interface Connection Type introduced in the Packet Abis feature /B/.
If the BSC is connected to the BTS site via Packet Abis a separate dynamic Abis pool is not needed to provide the additional Abis transport capacity for OSC-1 subchannels. Packet Abis will provide Abis transport for both OSC subchannels exactly in the same manner as for other speech calls.
Source: RS team
Linked requirements: BSS21309-025
6.2.24 BSS21309-025 Dynamic Abis resource
When the BSC ends up in a conclusion that a DHR multiplexing handover is to be made into an OSC-1 subchannel and the BSC is connected to the BTS with the legacy Abis connection the BSC shall allocate Abis resource from CSDAP for the new radio connection. If CSDAP resource allocation fails due to the lack of free CSDAP resources the BSC shall change priorities in multiplexing algorithm to prefer in next attempt a pair of AMR connections with which a new CSDAP resource allocation is not needed. That is, a pair where the target TCH/H is with an ongoing OSC-1 connection and where the new connection would be an OSC-0 connection with traditional fixed Abis resources. Whether the next multiplexing attempt shall be made immediately after the detection of the lack in CSDAP resources or when multiplexing triggers for the next time, is left to be decided in later phases of specification.
Rationale:
During DHR use the use of CSDAP resources is not necessarily optimal. There will be OSC-1 connections without a neighbouring OSC-0 connection in the TCH/H. These kinds of connections perform like normal AMR HR calls but consume CSDAP capacity. The negative effect caused by these connections for the CSDAP resource availability and multiplexing activity should be minimized.
Source: RS team
Linked requirements: BSS21309-051
6.2.25 BSS21309-026 OSC channel activation
The BSC shall indicate OSC usage and the related OSC specific parameters to the BTS in Channel Activation message. The BSC shall indicate a channel as an OSC channel when the channel activation takes place as part of the DHR multiplexing procedure, that is, the activation is made in the same TCH/H with an ongoing AMR HR
connection. OSC channel activation can take place for an OSC-0 subchannel or for an OSC-1 subchannel.
The BSC shall
- indicate that the channel is to be used for OSC and the number of bits used on Abis interface as new fields OSC in Use and Bits on Abis in the Channel Mode IE. The Bits on Abis field is meaningful only when the new CSDAP Circuit IE (introduced below) is included in the Channel Activation message, that is, for OSC-1 channel.
- identify the OSC-1 channel with a new OSC-1 specific channel number in the Channel Number IE.
- communicate the Training Sequence Code (TSC) to be used for OSC-1 subchannel in the Channel Identification IE.
- include the CSDAP resource to be used for OSC-1 subchannel in the new CSDAP Circuit IE.
For the detailed description of the fields and information elements, see chapter Abis Telecom interface.
The BSC shall include all of the above listed OSC specific pieces of information in the Channel Activation message for an OSC-1 subchannel.
Of the OSC specific fields above the BSC shall include for an OSC-0 subchannel the new fields OSC in Use and Bits on Abis in the Channel Mode IE. The Bits on Abis field has no actual meaning for an OSC-0 subchannel but the BSC shall fill the field with the value for DHR.
Rationale:
BTS needs to informed of all the necessary details when a TCH is intended for OSC use.
Source: SFS
Linked requirements: -
6.2.26 BSS21309-027 ASSIGNMENT COMMAND for OSC-1
When ASSIGNMENT COMMAND is sent to MS related to an OSC-1 subchannel in a non-DFCA TRX the BSC shall define the Training Sequence Code included in the message based on the TSC value used for OSC-0 connections according to table 1 in BSS21309-009 Optimized TSC pairs.
Even though an OSC-1 specific channel number is used towards BTS the BSC uses the normal channel number of the target TCH/H in ASSIGNMENT COMMAND to MS.
Rationale:
Training Sequence Code is the only piece of information that is handled differently for an OSC-1 DHR connection compared to the normal practice in a non-DFCA TRX during channel assignment to MS. In a DFCA TRX the actions related to TSC follow the existing practice for both OSC-0 and OSC-1 similarly and no separation of actions for OSC-1 is needed.
Source: RS team
Linked requirements: BSS21309-009
6.2.27 BSS21309-028 DHR multiplexing with a handover to an OSC-1 subchannel UC
Source: Internal
Context of Use: DHR multiplexing triggers based on load and results in activating of an OSC-1 subchannel, e.g. when multiplexing takes place for the first time. DFCA not involved.
Scope: BSC.
Level: Sub-function
Primary Actor: BSC
Stakeholders and Interests:
BSC telecom, BTS, MS
Precondition: OSC DHR multiplexing enabled with OSC capable TRX HW but no earlier multiplexing procedures made, that is, in each occupied TCH/H there is only one connection active.
Minimum Guarantees:
No multiplexing but relevant performance measurement counters updated.
Success Guarantees:
AMR call is handed over to a TCH/H with another AMR call.
Trigger: Sufficient traffic load during a periodic check.
1. HO&PC algorithm in a BCSU sends the periodic Rx level and power control data update for ongoing calls of a BTS object to Radio Channel Allocation algorithm in the MCMU.
2. At the reception of the Rx level and power control data Radio Channel Allocation algorithm detects the need for DHR multiplexing in the BTS based on traffic load and parameter DHR Limit For FR TCH Resources. Radio Channel Allocation algorithm updates DHR MULTIPLEXING ATTEMPTS counter.
3. Radio Channel Allocation algorithm searches for a target TCH/H for DHR multiplexing among the TRXs that it received the Rx level and power control data update for in the BTS. The TCH/H shall be a channel with an ongoing AMR HR call. For the AMR HR call another AMR call (“second call”) is searched for in the BTS to be multiplexed with the first one. The detailed rules of the candidate selection have been presented in requirements BSS21309-020, BSS21309-021 and BSS21309-022.
4. In this use case it is assumed that the second call on the TCH/H will be an OSC-1 connection. Radio Channel Allocation algorithm requests for the OSC-1 connection dynamic Abis transmission resource from Resource Control algorithm. Radio Channel Allocation algorithm updates CSDAP RESOURCE ALLOCATION ATTEMPTS FOR DHR counter. For details of CSDAP allocation, see use case BSS30385-016 Resource allocation from CSDAP UC in chapter 7.
5. Resource Control algorithm acknowledges with allocated CSDAP to Radio Channel Allocation algorithm.
6. Radio Channel Allocation algorithm requests source side Call Control algorithm to start a DHR multiplexing handover attempt for the second call to the selected target channel.
7. Source side Call Control algorithm forwards the handover request via Handover Attempt Supervisor to the target side and acknowledges the handover start to Radio Channel Allocation algorithm. Counter HO ATTEMPT FROM AMR HR TO DHR or HO ATTEMPT FROM AMR FR TO DHR updated depending on the original channel rate of the second call.
8. Radio Channel Allocation algorithm requests target side Call Control algorithm to activate the OSC-1 channel.
11. Call Control algorithm sends ASSIGNMENT COMMAND message to MS otherwise normally but indicating an OSC-1 subchannel specific TSC. Call Control algorithm shall use normal channel number of the TCH/H towards MS.
12. MS returns ASSIGNMENT COMPLETE message as an acknowledgement.
13. BSC updates counter HO FROM AMR HR TO DHR SUCCESSFUL or HO FROM AMR FR TO DHR SUCCESSFUL depending on the original channel rate of the second call.
Exceptions:
Each exception below interrupts the multiplexing procedure
Step 3:
a) There is no ongoing AMR HR call in the BTS: Radio Channel Allocation algorithm updates counter DHR MULTIPLEXING FAILURE DUE TO TCH RESOURCE and checks the possibility to initiate traditional AMR HR packing procedure.
b) There are ongoing AMR HR calls but none of them fulfills the necessary quality criteria: Radio Channel Allocation algorithm updates counter DHR MULTIPLEXING FAILURE DUE TO TCH RESOURCE.
Resource Control algorithm returns negative acknowledgement to CSDAP allocation request: Radio Channel Allocation algorithm updates DHR MULTIPLEXING FAILURE DUE TO CSDAP RESOURCE measurement counter.
Radio Channel Allocation algorithm changes its preferences to favour in the next multiplexing attempt a pair of AMR calls for which a new CSDAP resource allocation is not needed (multiplexing handover targeting OSC-0 subchannel).
Step 7:
State of the second call is not suitable for starting a handover: Call Control algorithm sends a negative acknowledgement to Radio Channel Allocation algorithm. Radio Channel Allocation algorithm updates DHR MULTIPLEXING FAILURE DUE TO OTHER REASON measurement counter and requests Resource Control algorithm to release the allocated CSDAP.
Step 10:
Negative acknowledgement from BTS to channel activation: Call Control algorithm terminates multiplexing handover attempt and requests Resource Control algorithm to release the allocated CSDAP resource. Call Control algorithm releases the OSC-1 subchannel of the target TCH/H from Radio Channel Allocation algorithm.
If the channel activation failure is related to CSDAP problem then Resource Control algorithm starts a penalty period for the CSDAP and raises CIRCUIT SWITCHED DYNAMIC ABIS POOL FAILURE alarm for the CSDAP in question. Handover Attempt Supervisor updates INT CELL UNSUCCESS HO TO DHR DUE TO CSDAP MISMATCH measurement counter.
If there have been several consecutive channel activation failures related to DHR multiplexing handovers in a TRX for other reasons than CSDAP problems then Radio Channel Allocation algorithm takes the TRX out of OSC use and raises DOUBLE HALF RATE CHANNEL ACTIVATION FAILURE alarm.
Frequency of Occurrence:
All the time when load exceeds load limit for DHR multiplexing.
6.2.28 BSS21309-029 DHR multiplexing with a handover to an OSC-0 subchannel UC
Source: Internal
Context of Use: DHR multiplexing triggers based on load and results in activating of an OSC-0 subchannel. DFCA not involved.
Scope: BSC.
Level: Sub-function
Primary Actor: BSC
Stakeholders and Interests:
BSC telecom, BTS, MS
Precondition: OSC DHR multiplexing enabled with OSC capable TRX HW. DHR multiplexing and demultiplexing procedures have taken place so that there are also OSC-1 connections in TCH/H channels without a neighbouring OSC-0 connection.
Minimum Guarantees:
No multiplexing but relevant performance measurement counters updated.
Success Guarantees:
AMR call is handed over to a TCH/H with another AMR call.
Trigger: Sufficient traffic load during a periodic check.
Main Success Scenario:
0. Similar actions as in steps 1 - 3 of use case BSS21309-028 DHR multiplexing with a handover to an OSC-1 subchannel UC . This case assumes that in the selected target TCH/H there is an ongoing AMR HR call in the OSC-1 subchannel. For the OSC-0 connection to be created during multiplexing there is no
need for Channel Allocation algorithm to request any CSDAP resource.
1. Radio Channel Allocation algorithm requests source side Call Control algorithm to start a DHR multiplexing handover attempt for the second call to the selected target channel.
2. Source side Call Control algorithm forwards the handover request via Handover Attempt Supervisor to the target side and acknowledges the handover start to Radio Channel Allocation algorithm. Counter HO ATTEMPT FROM AMR HR TO DHR or HO ATTEMPT FROM AMR FR TO DHR updated depending on the original channel rate of the second call.
3. Radio Channel Allocation algorithm requests target side Call Control algorithm to activate the OSC-0 subchannel.
4. Call Control algorithm sends Channel Activation message to BTS with OSC specific information including new fields OSC in Use and Bits on Abis in the Channel Mode IE. The Bits on Abis field is filled with value for DHR even though it does not have actual meaning for OSC-0 subchannel.
For OSC-0 the normal channel number is used in the Channel Number IE. Call Control algorithm includes neither TSC nor CSDAP in the channel activation of an OSC-0 subchannel towards the BTS.
6. Call Control algorithm sends ASSIGNMENT COMMAND message to MS normally. That is, Call Control algorithm uses the traditional TSC that is used in a non-DFCA TRX and the normal channel number of the TCH/H.
7. MS returns ASSIGNMENT COMPLETE message as an acknowledgement.
8. BSC updates counter HO FROM AMR HR TO DHR SUCCESSFUL or HO FROM AMR FR TO DHR SUCCESSFUL depending on the original channel rate of the second call.
Exceptions:
Each exception below interrupts the multiplexing procedure
There are ongoing AMR HR calls but none of them fulfills the necessary quality criteria: Radio Channel Allocation algorithm updates counter DHR MULTIPLEXING FAILURE DUE TO TCH RESOURCE.
Step 2:
State of the second call is not suitable for starting a handover: Call Control algorithm sends a negative acknowledgement to Radio Channel Allocation algorithm. Radio Channel Allocation algorithm updates DHR MULTIPLEXING FAILURE DUE TO OTHER REASON counter.
Steps 5:
Negative acknowledgement from BTS to channel activation: Call Control algorithm terminates multiplexing handover attempt. and releases the OSC-0 subchannel of the target TCH/H from Radio Channel Allocation algorithm.
If there have been several consecutive channel activation failures related to DHR multiplexing handovers in a TRX for other reasons than CSDAP problems then Radio Channel Allocation algorithm takes the TRX out of OSC use and raises DOUBLE HALF RATE CHANNEL ACTIVATION FAILURE alarm.
Frequency of Occurrence:
All the time when load exceeds load limit for DHR multiplexing.
6.2.29 BSS21309-030 Handover and power control thresholds for OSC DHR connections
BSC shall use OSC specific handover and power control Rx Quality thresholds for DHR connections. For handover the thresholds are defined with the following two parameters
For power control the Rx Quality thresholds are defined with the following four parameters
- PC Lower Threshold Dl Rx Qual DHR,
- PC Lower Threshold Ul Rx Qual DHR,
- PC Upper Threshold Dl Rx Qual DHR,
- PC Upper Threshold Ul Rx Qual DHR.
See section Parameters for parameter details.
Source: SFS:BSS21309-038
Rationale:
OSC specific Rx Quality thresholds are needed to provide independent handover and power control for OSC DHR connections.
Linked requirements: -
6.2.30 BSS21309-031 Quality threshold to trigger demultiplexing
Demultiplexing of an OSC DHR connection into a non-OSC connection is triggered by the deteriorating quality of the OSC DHR connection when the averaged uplink or downlink quality value reaches or exceeds the value defined by a new parameter OSC Demultiplexing Rx Qual Threshold. The existing quality trigger for AMR HR unpacking (Intra HO threshold Rx qual AMR HR) shall not be applied for OSC DHR connections.
When the demultiplexing procedure triggers based on Rx quality and the AMR unpacking optimization feature is not in use (feature state = CONF or OFF) then the BSC shall demultiplex the OSC DHR connection into an AMR FR non-OSC connection. For the cases where AMR unpacking optimization feature’s state is ON, see chapter AMR unpacking optimization.
Apart from a new OSC Demultiplexing Rx Qual Threshold BSC shall use same parameters for averaging of OSC DHR connection quality and for Px/Nx comparison as are used for AMR HR unpacking handover.
Quality based OSC DHR connection demultiplexing shall have same priority as AMR HR unpacking handover has among other existing handover criteria.
Rationale:
OSC demultiplexing is based on the same principle as AMR unpacking. OSC DHR call is handed over back to a non-OSC call when the signal quality of the call degrades to the defined OSC DHR specific triggering level.
Source: SFS:BSS21309-038, RS team
Linked requirements: -
6.2.31 BSS21309-032 Processing and threshold comparison of OSC DHR connections UL Rx Level measurements
Measurement Result message that BSC receives from BTS for an individual OSC DHR connection includes also the paired OSC DHR connection UL Rx Level measurement, UL DTX usage indication for the same and validity bit for indicating measurements validity. They are included in the OSC Neighbouring Sub Channel Measurements IE in the Supplementary Measurement Information of the Uplink Measurements Information Element. BTS includes OSC Neighbouring Sub Channel Measurements IE only when both OSC sub channels of a TCH have an ongoing DHR call.When OSC Neighbouring Sub Channel Measurements IE is included but measurements are invalid BTS sets validity, UL Rx Level and UL DTX fields to zero. This may take place when two calls are paired as adjacent OSC DHR connections and they start to receive measurements from each other in OSC Neighbouring Sub Channel Measurements IE. Or it may take place during an ongoing adjacent OSC DHR connections.
When it takes place in OSC DHR connection setup BSC shall obey the validity bit zero value and perform handover and power control for the individual connection as if adjacent OSC DHR connection would not exist for it. After validity bit has once been set to 1 BSC shall ignore it and regard measurements always valid as long as Neighbouring Sub Channel Measurements IE exist.
BSC shall perform UL Rx Level measurement processing of both OSC DHR connections same way as for non-OSC calls with the exception that BSC shall use fast averaging in uplink Rx Level based power control. BSC shall do this although fast averaging would not be active in cell. It means that BSC shall not wait for uplink power control averaging window size to become full. BSC shall calculate averaged UL Rx Level based on measurements that are available inside the averaging window. BSC shall also use measurement scaling for UL
Rx level when UL power control takes place. It means that UL Rx Level measurements in averaging window are scaled up or down by the value of power control step size.
When BSC does comparison among averaged UL Rx Levels of paired OSC DHR connections, and calculates if Px measurements out of Nx measurements is triggering handover or power control due to UL Rx Level difference, BSC shall use existing Px and Nx parameters that are meant for UL Rx Level.
Source: RS team
Rationale:
Continuous variation of UL Rx Level implies that averaged UL Rx Level is more reliable than only the latest one. And comparison among UL Rx Levels of paired OSC DHR connections requires that both are equally averaged. However fast averaging shall be used for uplink Rx Level based power control to minimize power control delay in call setup and in handovers.
Linked requirements: BSS21309-008
6.2.32 BSS21309-033 Demultiplexing based on UL Rx Level difference
When the difference between the averaged uplink Rx levels of the paired OSC DHR connections on a TCH/H equals to or exceeds OSC Demultiplexing UL Rx Level Margin the BSC shall demultiplex the OSC DHR connection with the stronger uplink signal into an AMR non-OSC connection. The BSC shall select primarily a HR TCH as the target channel for the demultiplexing handover but accept also a FR TCH if there is no HR TCH available.
Rationale:
DHR calls in an OSC pair are required to have link budgets that are close enough to each other. When this requirement is no more fulfilled the calls need to be separated. It is reasonable to always demultiplex the stronger connection because it increases the probability of success for the demultiplexing handover. Because the problems are not on the connection itself, it is safe to direct the demultiplexing handover into a TCH/H as a normal AMR HR connection.
6.2.33 BSS21309-034 Demultiplexing based on UL Rx Level difference UC
Source: SFS:BSS21309-027
Context of Use: Averaged UL Rx Levels of paired OSC DHR connections deviate too much from each other.
Scope: BSC
Level: Sub-function
Actors: BSC, BTS, MS
Precondition: Both OSC sub channels of a TCH/H have an ongoing DHR call.
Minimum Guarantees:
.
Success Guarantees:
OSC DHR connection with stronger UL Rx Level is demultiplexed into an AMR HR non-OSC connection.
Trigger:
Difference between the averaged UL Rx Levels of the paired OSC DHR connections equals to or exceeds the value of the OSC Demultiplexing UL Rx Level Margin parameter.
Main Success Scenario:
1. BSC receives Measurement Result message for OSC DHR connection. Message includes also the paired OSC DHR connection UL Rx Level measurement.
2. BSC compares the averaged UL Rx Levels of paired OSC DHR connections. When the difference between averaged UL Rx Levels equals to or exceeds the value of the OSC Demultiplexing Ul Rx Level Margin parameter, BSC evaluates need to start demultiplexing handover for OSC DHR connection:
AV_RXLEV_UL_HO(dhr_call) – AV_RXLEV_UL_HO(paired_dhr_call) >= OSC Demultiplexing Ul Rx Level Margin
THEN:Demultiplexing handover due to UL Rx Level difference
3. After BSC decides to start demultiplexing handover into an AMR HR non-OSC connection, handover procedure goes similarly with AMR HR unpacking intra-cell handover.
Exceptions:
Step 1. When OSC Neighbouring Sub Channel Measurements IE is not included in the Measurement Result message, BSC shall consider that OSC DHR connection does not have pair. In this case BSC shall evaluate handover needs for a connection as without OSC.
Frequency of Occurrence:
Everytime when UL Rx Level difference between paired OSC DHR connections equals to or exceeds the OSC Demultiplexing Ul Rx Level Margin parameter.
Timing and Performance:
Linked requirements: BSS21309-008, BSS21309-032
6.2.34 BSS21309-035 Limiting of OSC DHR connection uplink power control
BSC shall do uplink Rx Level and Rx Quality based power control for OSC DHR connection as for non-OSC connection. The exception is that the difference between the averaged UL Rx Levels of the paired OSC DHR connections shall not reach the value of the OSC Multiplexing Ul Rx Level Window parameter.
Source: RS team
Rationale:
With UL Rx Level balancing BSC tries to keep UL Rx Levels of paired OSC DHR connections close enough to each other. It is not reasonable to allow BSC to do normal power control simultaneously without taking UL Rx Level difference into account.
6.2.35 BSS21309-036 UL Rx Level balancing of paired OSC DHR connections UC
Source: SFS:BSS21309-026
Context of Use: UL Rx Levels of paired OSC DHR connections deviate too much from each other.
Scope: BSC
Level: Sub-function
Actors: BSC, BTS, MS
Precondition: Both OSC sub channels of a timeslot have an ongoing DHR call.
Minimum Guarantees:
If difference between averaged Rx Levels of paired OSC DHR connections increases more than allowed, connections are changed to non-OSC connections and calls continue as non-OSC calls.
Success Guarantees:
OSC DHR connection UL Rx Level is adjusted closer to the paired OSC DHR connection UL Rx Level.
Trigger:
Difference between the averaged UL Rx Levels of the paired OSC DHR connections equals to or exceeds the value of the OSC Multiplexing Ul Rx Level Window parameter.
Main Success Scenario:
1. BSC receives Measurement Result message for OSC DHR connection. Message includes also the paired OSC DHR connection UL Rx Level measurement.
2. BSC compares the averaged UL Rx Levels of paired OSC DHR connections. When the difference between averaged UL Rx Levels equals to or exceeds the value of the OSC Multiplexing Ul Rx Level Window parameter, BSC calculates new uplink power level for OSC DHR connection:
IF:AV_RXLEV_UL_PC(dhr_call) – AV_RXLEV_UL_PC(paired_dhr_call) >= OSC Multiplexing Ul Rx Level Window
3. After calculating the new uplink power level for OSC DHR connection, BSC sends MS Power Control Command via BTS to the MS. BSC also sets an existing supervision timer for the uplink power control.
4. When BSC receives Measurement Result message wherein the MS reports that it has adapted to the new uplink power level, BSC resets the supervision timer and sets an existing power control interval timer for the uplink power control.
Exceptions:
Step 1. When paired OSC Neighbouring Sub Channel Measurements IE is not included in the Measurement Result message, BSC shall consider that OSC DHR connection does not have pair. In this case BSC shall evaluate uplink power control needs and perform uplink power control as without OSC.
Step 4.When uplink power control supervision timer expires BSC proceeds as in the existing implementation. When power control interval timer expires, new uplink power control is possible as in existing implementation.
Frequency of Occurrence:
Everytime when UL Rx Level difference between paired OSC DHR connections equals to or exceeds the OSC Multiplexing Ul Rx Level Window parameter.
BSC shall perform independent Rx Level and Rx Quality based downlink power control for the OSC DHR connections that share a TCH/H.
When BTS reports measurement results to BSC, measurements include the DL power level value that BTS has used for the connection. BTS used DL power level may differ from the same of what BSC has commanded. For an OSC DHR connection BSC shall compare the BSC commanded DL power level to the BTS reported DL power level. When the BTS reported DL power level is higher than what BSC has commanded, BSC shall not allow DL power decrease.
When BSC commands DL power increase or decrease but BTS continues to report different DL power level while power control is in progress, BSC shall not totally disable DL power control as it does in current implementation but it shall try again later.
Rationale:
DL power control of individual connections is an independent procedure also in the case of OSC. BSC power control algorithm process working on one OSC subchannel does not have any idea of the DL situation of the neighbouring OSC subchannel. BTS selects the power to be used in BTS transmitter based on the individual power levels that the BSC has commanded for the paired OSC DHR connections. BTS selects the highest power level of individual OSC DHR connections and uses it for both connections.
When real DL power level is higher than what BSC has commanded for a connection, there is no point of commanding DL power decrease cause BTS will in any case use the highest DL power level of paired OSC DHR connections.
Currently if BTS does not obey BSC commanded DL power level while BSC is waiting for DL power control to succeed, i.e. BTS reports that new DL power level is not taken into use, BSC tries once more. If second try is unsuccessful, BSC disables DL power control for the call in question. This is not reasonable for OSC DHR connections since BTS uses the highest DL power level of paired OSC DHR connections.
6.2.37 BSS21309-057 Configuration limitation with Double Half Rate
The BSC shall limit the amount of half rate capable TCH resources with OSC DHR and prevent operator from configuring an excessive amount of TCH resources without the Soft Channel Capacity feature. When the Soft Channel Capacity is not in use the BSC traditionally makes sure that the traffic handling capacity of a BCSU unit is not exceeded with the configured amount of TCHs. In this examination the BSC shall calculate a TSL, that is capable of AMR half rate traffic in a BTS with the Double Half Rate feature active, as 3 TCHs. The BSC shall prevent actions that would lead to the excess of TCH resources in a BCSU with the interpretation of an OSC DHR capable TSL corresponding to 3 TCHs.
With the Soft Channel Capacity feature in use the BSC shall also regard a DHR capable TSL as 3 TCHs when comparing the configured resources against the Soft Channel Capacity feature’s capacity licence.
Table 3 gives an example of maximum TCH amounts for full rate, half rate and double half rate TRX configurations in BSC3i 3000 with 500 TRXs per BCSU.
Max configured TCH count per BCSU without SCC (max active)
Max configured TCH count per BCSU with SCC (max active)
Table 3 Maximum numbers of TCHs per BCSU in BSC3i 3000
The value 5312 for Double Half Rate TRX configuration without Soft Channel Capacity is based simply on the max TRX amount with full DHR TSL configuration (all TSLs as DHR capable). By calculating DHR capable TSLs as 3 TCHs gives 24 TCHs per TRX. With this policy the BSC shall allow 166 full DHR TRXs (BSC calculates these as 3984 TCHs). The theoretical maximum amount of TCHs in this case is 8 * 4 * 166 = 5312. To be exact, this leaves still 16 TCHs as unconfigured. In any case, these are only theoretical values as the numbers in table 3 do not take into account the effect of the necessary signalling TSLs. The main point here is that with DHR the number of configured TCHs can exceed the actual traffic handling capacity even without the Soft Channel Capacity.
Traditionally the BSC prevents TCH configurations where the traffic handling capacity of a BCSU unit would be exceeded. With OSC DHR this same kind restriction is also used but calculating a TSL capable of DHR traffic as 3 TCHs. Value 3 is used instead of 4 because value 4 is seen as too limiting because in practice the situation of fully multiplexed DHR channels cannot be reached. A similar interpretation of DHR resources is applicable also with the Soft Channel Capacity feature.
Source: RS review
Linked requirements: BSS21309-053
6.2.38 BSS21309-053 Channel handling capacity with Double Half Rate
The BSC shall make sure that the traffic handling capacity of the BCSU units is not exceeded while employing the Double Half Rate feature. Radio Channel Allocation algorithm shall use with the Double Half Rate feature the same principles that it uses with the Soft Channel Capacity feature. In other words the BSC makes sure that the traffic handling capacity of the BCSU units is not exceeded but also that in each TRX there can be at least as many active calls as there are configured TCH TSLs in the TRX.
Rationale:
With the Double Half Rate feature the configured TCH amount may exceed the traffic handling capacity of the BSC because the BSC takes into account only 3 out of the 4 possible TCHs of a DHR capable TSL during configuration phase. The amount of DHR channels in the configuration is twice the amount of TCH/Hs. The exceeding of the maximum TCH capacity by active TCHs can occur even without the Soft Channel Capacity feature in use and this needs to be prevented.
Source: RS team
Linked requirements: BSS21309-057
6.2.39 BSS21309-039 No OSC multiplexing for Emergency Calls
The BSC shall not apply OSC multiplexing for emergency calls.
Rationale:
OSC multiplexing can be regarded as an unnecessary risk for an emergency call.
The BSC shall support forced handover and forced release of the two multiplexed DHR calls in a TCH/H when these actions have triggered in a congestion situation in order to find a TCH/H for a new call with a higher priority.
The BSC shall prefer a non-OSC connection rather than two OSC connections in a TCH/H as the target for the forced actions if these alternatives are regarded as equal candidates by other criteria of the pre-emption algorithm.
For the pre-emption of both of the two DHR calls in a TCH/H to be possible requires that the procedure is allowed for each of the DHR calls based on the connection specific priority information.
Rationale:
Double Half Rate and Pre-emption are features that are targeted for congested environments. It is likely that these two features are used together and, thus, the features must co-operate.
Source: RS team
Linked requirements: -
6.2.41 BSS21309-041 No OSC multiplexing for DTM calls
The BSC shall not apply OSC multiplexing for calls in dual transfer mode (DTM).
Rationale:
Applying OSC for a DTM call is not reasonable because of the momentary nature of the DTM connection. Multiplexing with a DTM call would not result in a long-lasting OSC connection. On the other hand OSC multiplexing and demultiplexing would further increase the discontinuous nature of a DTM call with the additional handovers. All in all, the two features are a poor match.
Existing BSC implementation does not support the use of AMR HR in DTM calls, only AMR FR is used for speech when it is combined with a packet switched connection. This alone does not totally exclude DTM calls from taking part in OSC multiplexing because also an AMR FR connection can be selected as a candidate for the multiplexing handover. Due to this an explicit prohibition is needed.
6.2.42 BSS21309-042 Blocking of DHR multiplexing due to DHR channel activation failures
The BSC has a method where it blocks a radio time slot and raises an alarm (7725 TRAFFIC CHANNEL ACTIVATION FAILURE) when the activation of a radio channel in the TSL has failed a number of times. This procedure shall not be applied when the successive channel activation failures take place in DHR channels during multiplexing handovers.
Instead of blocking the radio TSL in question from use the BSC takes the TRX in question out of DHR multiplexing activity and raises a new alarm DOUBLE HALF RATE CHANNEL ACTIVATION FAILURE for the BTS. The BSC takes these actions when there are several consecutive channel activation failures that take place during DHR multiplexing in a TRX and there are no successful multiplexing cases between them. Returning of the DHR multiplexing activity in the TRX shall require that operator turns OSC off and then back on in the BTS. Also lock/unlock actions involving the TRX shall cause the cancelling of the alarm.
Channel activation failures due to CSDAP problems are not included in this activity. All CSDAP problems are handled with the activities related to another new alarm CIRCUIT SWITCHED DYNAMIC ABIS POOL FAILURE of requirement BSS30385-026 Circuit Switched Dynamic Abis Pool Failure alarm.
Rationale:
Problems in DHR must not prevent the use of other connection types or traffic handling capability in general. Because of this the DHR specific channel activation failure cases must be separated from the traditional ones that may cause blocking a radio TSL out of use. DHR problems may have effects on DHR service only.
Operator is informed when the recovery of the normal activity needs user actions.
Source: RS team
Linked requirements: -
6.2.43 BSS21309-043 No EGPRS2 TSL followed by OSC TSL
The BSC must not select the target TCH for DHR multiplexing in a TSL that follows a TSL in EGPRS2 use. BSC DX telecom regards a TSL being in EGPRS2 use if the TSL
belongs to a packet territory the type of which is EGPRS2. It should be noted that TSL0 follows TSL7 in the radio transmission frame structure.
Table 4 below illustrates two examples of illegal DHR channel allocations with EGPRS2. BSC shall prevent DHR allocation in TSL7 of TRX x and TSL0 of TRX y. Example configuration of TRX y is the one that will occur in practice. Example configuration of TRX x is a rare one and requires that TSL7 is configured permanently for HR.
When the BSC extends EGPRS2 territory to a new TRX it shall not select a TRX where there are two DHR calls going on in a TCH/H of TSL0.
TSL0 TSL1 TSL2 TSL3 TSL4 TSL5 TSL6 TSL7
TRX x DHR DHR FR/HR DHR FR/HR FR/HR EGPRS2 DHR
TRX y DHR FR/HR DHR DHR FR/HR DHR EGPRS2 EGPRS2
Table 4 Examples of illegal DHR channel allocations with EGPRS2
Rationale:
The restriction is a result of internal memory limitations in Flexi EDGE BTS Odessa DTRX. This limitation is specific to Odessa DTRX only because it is currently the only DTRX type to support EGPRS2.
Source: SFS:BSS21309-039
Linked requirements: -
6.2.44 BSS21309-052 DHR in Resource Availability Measurement
The BSC shall not change the way it collects the statistics of congestion when Double Half Rate feature is introduced. The BSC shall regard half rate TCH congestion for counter 002045 HALF RATE RADIO TCH CONGESTION TIME as started when there is at least one call in each TCH/H. Similarly for counter 002026 TOTAL CHANNEL BUSY TIME congestion occurs when there is at least one call in each TCH of the BTS.
The BSC shall include DHR calls in the counters that collect the average and peak numbers of occupied TCHs, that is, counters 002027 AVE BUSY TCH and 002029 PEAK BUSY TCH.
The BSC shall include DHR calls in the counter that collects the average holding time of all TCHs, counter 002036 AVE TCH HOLD TIM.
Rationale:
It is not reasonable to collect congestion statistics of DHR resources because the situation where there would be two calls in every TCH/H cannot be reached. The meaning of existing congestion counters is maintained unchanged at the introduction of the Double Half Rate feature.
By including DHR calls in the general average and peak number counters operator is able to verify the actual number of simultaneous calls in a BTS.
Including DHR calls in the general holding time counter follows the established practice. All calls are included in the same average counter.
Source: RS team
Linked requirements: -
6.2.45 BSS21309-054 Double Half Rate performance
The BSC’s traffic handling capacity with the Double Half Rate feature and less TRXs shall be at least at the same level as without the feature and normal TRX amount.
Rationale:
Increased efficiency in the use of radio capacity must not lead to a decrease in traffic handling capacity of the BSC.
Source: RS team
Linked requirements: -
6.3 AMR unpacking optimization
6.3.1 BSS21309-044 Preventing demultiplexing with poor Rx quality
When
- the state of the licenced feature AMR unpacking optimization is ON and
- the averaged uplink or downlink quality for an OSC DHR connection is equal to or worse than defined by the existing Intra HO Lower Rx Quality Limit AMR parameter
then the BSC shall prevent demultiplexing of the OSC DHR connection into a non-OSC connection as well the intra cell handover due to interference for the OSC DHR connection.
Rationale:
BSS21120 AMR Unpacking Optimization includes a method for preventing the unpacking of AMR HR calls into AMR FR calls as well as intra cell handovers due to interference in cases of very poor quality. This same method shall be applied also for OSC DHR connections. This is particularly important for OSC DHR connections as their performance is compromised by the efficient use of radio capacity.
Source: SFS:BSS21309-027, RS team
Linked requirements: -
6.3.2 BSS21309-045 Rx level criteria for demultiplexing
Once the demultiplexing of an OSC DHR connection into a non-OSC connection has triggered based on RX quality and the state of the AMR unpacking optimization feature is ON the BSC shall select the target mode for the connection based on the averaged signal level and existing parameters Intra HO Upper Rx Level Limit AMR HR and Intra HO Lower Rx Level Limit AMR HR as follows:
- if averaged uplink or downlink signal level is above Intra HO Upper Rx Level Limit AMR HR the demultiplexing handover shall be made to AMR HR,
- if averaged uplink or downlink signal level is equal to or below Intra HO Upper Rx Level Limit AMR HR but still at least Intra HO Lower Rx Level Limit AMR HR the demultiplexing handover shall be made to AMR FR,
- if averaged uplink or downlink signal level is below Intra HO Lower Rx Level Limit AMR HR the demultiplexing handover shall be prevented.
Rationale:
BSS21120 AMR Unpacking Optimization includes a method for preventing the unpacking of AMR HR calls into AMR FR calls in case of very poor signal level but also in the case of good enough signal level. With OSC DHR connection a similar functionality with the same threshold parameters is applied to direct OSC DHR connection either to AMR HR or to AMR FR or to totally prevent the demultiplexing handover from OSC.
6.3.3 BSS21309-055 Connection specific Rx level trigger for demultiplexing
BSS21483 Improved AMR packing and unpacking feature introduces a connection specific RX level based trigger for AMR unpacking handovers. When Improved AMR packing and unpacking feature is in use the BSC shall apply it also to trigger OSC DHR demultiplexing into AMR FR.
Rationale:
Improvements that have been found out as important for AMR calls should be applied also for OSC DHR calls.
Source: RS Review
Linked requirements: -
6.4 DFCA requirements
6.4.1 BSS21309-046 TSC selection for a DHR connection in DFCA
For a DFCA OSC connection TSC must be selected among the possible TSC pairs shown in table 2 of requirement BSS21309-009 Optimized TSC pairs, that is,
if the first connection uses TSC 0 or 1 then BSC shall select TSC 2, 3, or 7 for the second OSC connection
if the first connection uses TSC 2 then BSC shall select TSC 0, 1 or 5 for the second OSC connection
if the first connection uses TSC 3 then BSC shall select TSC 0, 1 or 4 for the second OSC connection
if the first connection uses TSC 4 then BSC shall select TSC 3 or 6 for the second OSC connection
if the first connection uses TSC 5 then BSC shall select TSC 2 or 6 for the second OSC connection
if the first connection uses TSC 6 then BSC shall select TSC 4 or 5 for the second OSC connection
if the first connection uses TSC 7 then BSC shall select TSC 0 or 1 for the second OSC connection.
When DFCA is used the TSC allocation is done by the DFCA algorithm, so there is no TSC plan made by the operator. For the Double Half Rate feature there are defined fixed TSC pairs that shall be used. For DFCA this kind of functionality does not work as after the first OSC channel release the other channel uses a predefined TSC. If this connection is paired again the TSC for the new connection would be selected without any C/I check and then both connections would use non-calculated TSCs. In high load situation this would lead to situation that almost all TSCs in the network would be selected randomly.
Source: RS team, SFS:BSS21309-035
Linked requirements: BSS21309-009
6.4.2 BSS21309-047 C/I calculation for a DHR connection in DFCA
The BSC shall use DHR specific C/I target values when it performs DFCA C/I calculation for a DHR connection. When incoming and outgoing interference is defined, C/I calculations are done individually for both OSC connections in the HR channel. With OSC the DHR calls use simultaneously the channel and hence both calls cause interference no matter if the call is using OSC-1 or OSC-0 channel. For outgoing interference a -1dB offset, in addition to HR offset, is used because a DHR call causes less interference than a HR call.
The target channel of DHR multiplexing already includes a call that is using proper power levels for UL and DL. In UL C/I calculation it must be taken into account that UL RX level is set to be in a defined range from the existing connection. The range is defined by the new OSC Multiplexing UL Rx Level Window parameter. This limits the power reduction. For DL direction power reduction max is the reduction that is currently in use in the target channel.
Rationale:
DHR specific parameters and restrictions have to be taken into account in the C/I calculations of DFCA.
Source: RS team, SFS:BSS21309-035
Linked requirements: -
6.4.3 BSS21309-048 No SAIC offset for OSC connection
SAIC DL C/I offset shall not be used for OSC connections.
As OSC connection uses QPSK coding for DL direction, it basically loses the benefit of SAIC receiver against external interference. In OSC the SAIC gain is needed to remove the channel internal interference (caused by the other OSC connection). Also all DHR users are SAIC capable and hence the target C/I can be defined just with the C/I target DHR parameter, so there is no need to separate SAIC and non SAIC MSs.
Source: RS team
Linked requirements: -
6.4.4 BSS21309-049 Pairing with DFCA
In OSC multiplexing on a DFCA channel the BSC shall prefer a DFCA channel where C/I for both connections (the call that already exists in the channel and the call that is handed over to the channel) is above C/I target DHR. Channels between C/I target DHR and C/I soft blocking DHR can be only used if there are no other possibilities available.
When C/I check is done the possible DL power increase of the existing connection must be taken into account. It is possible that the DL RX level of the new connection is too low and it would cause too high power increase for the existing connection that would lead to an outgoing soft blocking situation.
Rationale:
In pairing with DFCA both of the connections have to fulfill the criteria defined for single DHR connections but also the combined effect of the two connections must remain within acceptable limits.
Source: RS team
Linked requirements: -
6.5 Postponed or rejected requirements
6.5.1 BSS21309-006 OSC support for Epsilon TRX, POSTPONED
To support OSC also for Epsilon TRX of the Flexi EDGE BTS requires certain extra actions from the BSC because Epsilon TRX does not support the concurrent use of EGPRS and OSC in a TRX. The BSC shall have to decide and indicate to the BTS at startup phase if an Epsilon TRX is to be used for OSC.
The BSC shall configure an Epsilon TRX to be used for OSC only if the TRX is not an EGPRS TRX. The BSC shall conclude a TRX being an EGPRS TRX based on the two existing parameters, EGPRS enabled (EGENA) and GPRS enabled TRX (GTRX). A TRX is an EGPRS TRX if
- EGENA is in another value than “disabled” and
- GTRX = Y.
Note that this is not a general definition for an EGPRS TRX but to be used for this OSC specific procedure only.
If a TRX in a Flexi EDGE BTS is not an EGPRS TRX the BSC shall start the TRX as an OSC TRX by including a new OSC indication field for the TRX in the BTS_CONF_DATA message. If BB Hopping or Antenna Hopping is used in a BTS and there is an EGPRS TRX in the BTS then BSC shall not indicate OSC use for any of the TRXs in the BTS.
The BSC does not know the TRX HW variant of the Flexi EDGE BTS (Epsilon or Odessa) until it receives the BTS_STATE_CHANGED message. For the procedure to be general, the BSC does these actions always in the case of a Flexi EDGE BTS.
In Odessa TRX OSC and EGPRS can co-operate without limitations. BSC shall conclude the TRX HW variant between Epsilon and Odessa based on the Air interface modulation capability that it receives in the BTS_STATE_CHANGED message from the BTS /G/.
The BSC shall be able to apply OSC in the TRXs that it has started with the OSC indication included in BTS_CONF_DATA.
In a configuration where neither BB hopping nor Antenna hopping is used the BSC shall be able to apply OSC in an Odessa TRX even though it did not indicate OSC use to the BTS in BTS_CONF_DATA.
In a BB hopping or Antenna hopping configuration where the BSC has not indicated OSC use for any of the TRXs in the BTS_CONF_DATA the BSC shall be able to apply OSC in the BTS only if all the TRXs in the BTS are of Odessa HW variant.
Rationale:
Limited capacity of Epsilon TRX has to be taken into account.
The Epsilon specific restrictions in the common use of OSC and EGPRS need to be addressed in the relevant customer documents.
6.5.2 BSS21309-007 Independent DTX control for each OSC subchannel, REJECTED
BSC shall enable DL DTX separately for the OSC subchannels that are sharing the same radio channel.
Rationale:
This requirement causes no additional change in the BSC but has been inherited from the SFS to ensure the following activity that is required in the BTS:
With DTX in use BTS shall send GMSK for the active channel instead of QPSK. This enables power savings because with GMSK it is possible to use lower output power than with QPSK.
Source: SFS:BSS21309-042
Linked requirements: -
6.5.3 BSS21309-011 BSC shall allocate AMR HR calls as OSC calls, REJECTED
When OSC has been enabled in a BTS the BSC shall allocate HR TCHs for normal non-OSC AMR calls as OSC-0 connections in the BTS for the SAIC supporting MSs.
Rationale:
Starting a normal AMR HR call as an OSC connection right from the beginning gives the possibility to implement the OSC multiplexing simply by adding another OSC connection into the channel later when the traffic load calls for further packing of traffic in the BTS. Thus, the original connection does not need to be moved with a handover and also there is data available of the conditions on the channel to be utilized when the actual OSC multiplexing is made.
In the air interface the BTS uses dynamically GMSK or QPSK modulation according to if there is only one or if there are two OSC connections in a channel. When there is only one OSC connection in a TCH/H the channel performs as a traditional AMR HR TCH.
During channel release of OSC-1 subchannel the BSC shall not release the related CSDAP resource until the channel is successfully released from BTS with RF Channel Release. Meanwhile the BSC shall temporarily connect the CSDAP circuit to NULL circuit.
The release of an OSC-1 subchannel can be caused by a handover of the related call or because of the termination of the call.
Rationale:
In order to avoid collisions in CSDAP usage the BSC has to make sure that CSDAP resource is released from the old radio channel in BTS before allocating it for a new radio channel.
7 REQUIREMENTS FOR THE FEATURE BSS30385 CIRCUIT SWITCHED DYNAMIC ABIS POOL
7.1 General CSDAP requirements
7.1.1 BSS30385-001 General CSDAP Requirements
Description:
1. CSDAP shall be a BCF object level item. All the TRXs situating under BCF cabinet can use the CSDAPs attached to the BCF.
2. CSDAP shall be a continuous block of 64 kbit/s physical timeslots inside one Abis ETPCM. Minimum size of CSDAP shall be 1 TSL. Maximum size of CSDAP shall be 31 TSLs (24 TSLs in ANSI). Size of CSDAP can be selected in 1 TSL steps.
3. CSDAP area shall not have dependencies with other TRX object(s) transmission capacity configurations, e.g. CSDAP can reside in its own Abis ETPCM.
Source: SFS: BSS21309-008
Rationale:
1. This is simplier solution than attaching CSDAP to each BTS separately.
2. Managing of CSDAP is easier when all timeslots situate in the same Abis ETPCM. .
3. When place of CSDAP can be allocated freely it does not require Abis ETPCM timeslot reallocation when feature is taken to use.
CSDAP information shall be stored to new radio network object called "Circuit Switched Dynamic Abis Pool (CSDAP)". Maximum amount of CSDAPs in BSC shall be 1000.
The CSDAP radio network object shall contain the next information:
CSDAP ID
o Each CSDAP has own CSDAP ID that is used to identify the CSDAP.
o CSDAP ID has values from 1 to 1000.
o Operator enters the CSDAP ID parameter when he/she creates a CSDAP.
o CSDAP ID can not be modified later.
Circuit Group Number
o BSC allocates own circuit group number for each CSDAP during CSDAP creation procedure.
o Circuit group number can not be modified later.
Abis ETPCM
o This parameter defines the Abis ETPCM where the CSDAP situates in BSC side.
o Operator enters the Abis ETPCM parameter when he/she creates a CSDAP.
o Operator can not modify the Abis ETPCM parameter later.
First Timeslot
o This parameter defines the first timeslot used for the CSDAP in Abis ETPCM.
o Operator enters the First Timeslot parameter when he/she creates a CSDAP.
o Operator can modify the First Timeslot parameter later, but not simultaneously with the Last Timeslot parameter.
o BSC does not allow modification if the First Timeslot is greater than the Last Timeslot (First Timeslot <= Last Timeslot)
Last Timeslot
o This parameter defines the last timeslot used for the CSDAP in Abis ETPCM.
o Operator enters the Last Timeslot parameter when he/she creates a CSDAP.
o Operator can modify the Last Timeslot parameter later, but not simultaneously with the First Timelsot parameter.
o BSC does not allow modification if the First Timeslot is greater than the Last Timeslot (First Timeslot <= Last Timeslot)
BCF Abis IF
o This parameter defines Abis IF number in BCF site.
o Operator enters the BCF Abis IF parameter when he/she creates a CSDAP.
o Operator can modify the BCF Abis IF parameter later while the CSDAP does not have attachment to BCF.
BCF Timeslot Shift
o This parameter defines offset between CSDAP timeslots in Abis ETPCM and BCF Abis IF.
o Operator enters the BCF Timeslot Shift parameter when he/she creates a CSDAP.
o Operator can modify the BCF Timeslot Shift parameter later while the CSDAP does not have attachment to BCF.
Source: SFS: BSS21309-008
Rationale:
CSDAP parameters differs so much from legacy DAP parameters that it is better to define own radio network object for CSDAP.
Each CSDAP requires own circuit group (CMECGR) and it increases memory consumption in some program blocks. It is reasonable to allocate less CSDAPs than 3000 which is the maximum amount BCFs in BSC. When assuming that there are at least 3 TRXs per site then the maximum amount of CSDAP is 3000 / 3 = 1000.
The BCF Abis IF parameter is needed because CSDAP is created to Abis ETPCM in BSC side and it has cross-connection to certain Abis IF in BCF.
The BCF Timeslot Shift parameter is needed because CSDAP is created to certain timeslots in Abis ETPCM in BSC and these timeslots can have cross connection to different Abis IF timeslots in BCF. For example if CSDAP is in E1 timeslots 1 - 10 at BSC and in timeslots 11 - 20 at BTS, then BCF Timeslot Shift is +10.
The same logic as used for handling the legacy DAP parameters is used for handling the CSDAP parameters in MML and NetAct interface. It has to be considered if it is possible even use the same MML commands (ESE, ESM, ESG, ESI). Note: Changes may come to the legacy DAP handling MMLs because of Shared EDAP feature.
7.1.3 BSS30385-003 Modifications to BCF radio network object
Description:
CSDAP information shall be added to BCF radionetwork object because CSDAP is BCF object level item.
There shall be maximum 4 separate CSDAPs attached to one BCF, but a single CSDAP can be connected to only one BCF.
The BCF radio network object shall contain the new radio network parameters:
Attached CSDAP 1
Attached CSDAP 2
Attached CSDAP 3
Attached CSDAP 4
Source: Internal
Rationale:
Attached CSDAP describes the relation between CSDAP and BCF. Maximum at 4 CSDAP per BCF and 1 BCF per CSDAP.
When there are several CSDAPs attached to one BCF then a possible fault situation in one CSDAP (or Abis ETPCM) does not totally prevent OSC capability in the BCF. CSDAP capacity can be increased later for BCF by attaching new Abis ET-PCMs to BCF.
Order number in the parameter name indicates hunting order between attached CSDAPs. Abis transmission is first hunted from the CSDAP that is found from the Attached CSDAP 1 parameter and then from the Attached CSDAP 2 parameter and so on.
7.2.1 BSS30385-005 CSDAP configuration sending to BTS
Description:
BSC shall send information of all CSDAPs that are attached to BCF to BTS in BTS_CONF_DATA message when:
CSDAP is attached to BCF
CSDAP is detached from BCF
new timeslots are added to CSDAP
timeslots are removed from CSDAP
BCF is unlocked
in BCF reset
BSC shall send always whole CSDAP configuration to BTS when CSDAP IE is present in the BTS_CONF_DATA message.
BSC shall send empty CSDAP IE in BTS_CONF_DATA message to BTS when there are not any CSDAP attached to BCF. For example when the last CSDAP is detached from the BCF.
When BSC does not include CSDAP IE to BTS_CONF_DATA message then CSDAP configuration is not changed in BCF.
BSC can send BTS_CONF_DATA message to BTS while TRXs using the CSDAP are in unlocked state and there are active calls in these TRXs.
BSC shall send CSDAP's PCM-TSL information to BTS in format that is used in BSC side.
b. whether CSDAP timeslots are within in allowed E1/T1 bounds
c. whether there is a timeslot conflict between CSDAPs attached to the message
d. whether the timeslots have been already allocated for some other use
3. BTS shall send BTS_ACK message as an acknowledgement to BSC.
4. BTS shall send BCF_CONF_COMPL message to BSC.
5. BSC shall send BTS_ACK message as an acknowledgement to BTS.
Exceptions:
Step 1. BCF locked:
If BCF is in locked state, BTS_CONF_DATA is not sent.
Step 1. No CSDAPs attached to BCF:
BSC sends empty CSDAP IE to BTS in BTS_CONF_DATA message.
Step 2. Error in CSDAP information:
BTS shall reject the CSDAP information if Abis IF does not exist. BTS shall send negative acknowledgement (N_CSDAP_ABIS_IF_NOT_IN_USE_1 ... 4) within BTS ACK message to BSC. The error code name contains reference to order number of CSDAP IE in the BTS_CONF_DATA message.
BTS shall reject the CSDAP information if CSDAP timeslots exceed the E1/T1 bounds. BTS shall send negative acknowledgement (N_CSDAP_OUT_OF_BOUND_1 ... 4) within BTS ACK message to BSC. The error code name contains reference to order number of CSDAP IE in the BTS_CONF_DATA message.
BTS shall reject the CSDAP information if there is timeslot conflict between CSDAPs included to the message. BTS shall send negative acknowledgement (N_CSDAP_OVERLAP_1 ... 4) within BTS ACK message to BSC. The error code name contains reference to order number of CSDAP IE in the BTS_CONF_DATA message.
BTS shall reject the CSDAP information if the timeslots mentioned are allocated for some other use. BTS shall send a negative acknowledgement (N_CSDAP_OVERLAP_1 ... 4) within BTS ACK message to BSC. The error code name contains reference to order number of CSDAP IE in the BTS_CONF_DATA message.
Step 3. Negative acknowledgement from BTS:
BSC operation is dependent on the use case where the negative acknowledgement is received. Check the linked requirements.
BSC informs operator about the failed CSDAP by returning a reference to the failed CSDAP in execution printout when it is available in the BTS error code.
4. BSC shall create own SPE-BB circuit group for the CSDAP called CDAPxxxx, where xxxx indicates CSDAP ID. BSC shall add virtual circuits that corresponds the subtimeslots 0,1,2,3,4,5,6,7 to the CDAPxxxx circuit group.
5. BSC shall change the working state of the virtual circuits from BA to WO.
6. BSC shall write CSDAP information to the radio network configuration database.
7. BSC shall inform operator about the procedure completion in execution printout.
Exceptions:
Step 2. Already existing CSDAP:
BSC shall reject the CSDAP creation if there already exist CSDAP ID with the same number. The BSC shall inform operator about the failure in execution printout.
Step 3. Already reserved physical timeslots in ETPCM:
BSC shall reject the CSDAP creation if the physical timeslot already situates in circuit group called ETPCM. This means that it has been already allocated for some other user in Abis ETPCM. The BSC shall inform operator about the failure in execution printout.
Step 4. Circuit group creation failure:
BSC shall reject the CSDAP creation if creation of SPE-BB circuit group fails. BSC shall remove all routings created for the CSDAP and then the BSC shall inform operator about the failure in execution printout.
Step 6. Database update failure:
BSC shall reject the CSDAP creation if the radio network configuration database update fails. BSC shall remove all routings created for the CSDAP and then the BSC shall inform operator about the failure in execution printout.
Frequency of Occurrence:
When OSC DHR feature is taken into use in BCF or, when more CSDAP capacity is needed for OSC calls to BCF.
Precondition: CSDAP id exists in Abis ETPCM. CSDAP has been attached to BCF.
Minimum Guarantees:
CSDAP size increment fails.
Success Guarantees:
CSDAP size is increased.
Trigger: Operator adds timeslots to the CSDAP.
Main Success Scenario:
1. Operator shall configure Abis transmisson to BCF for the new CSDAP timeslots before increasing CSDAP size in BSC.
2. Operator then requests BSC to add new timeslots to CSDAP via MML or NetAct. Operator shall enter the following parameters in the command:
CSDAP ID
First Timeslot or Last Timeslot
3. In case of MML operation BSC shall require operator to confirm the operation because forced release will be performed for the ongoing calls using the CSDAP during the procedure.
4. BSC shall check that the CSDAP exists and the command parameters are acceptable. BSC shall reserve the related BCF object for modification.
5. BSC shall set penalty (90 s) for the CSDAP that prevents new resource allocations from the CSDAP during the modification procedure. The BSC shall perform forced release for the ongoing calls using the modified CSDAP (The same method is used as during BCSU restart).
6. BSC shall add new physical Abis ETPCM timeslots to circuit group called "ETPCM".
7. BSC shall add new virtual circuits that corresponds the subtimeslots 0,1,2,3,4,5,6,7 to the CDAPxxxx circuit group.
8. BSC shall change the working state of the new CSDAP virtual circuits from BA to WO.
9. BSC shall write the updated CSDAP information to the radio network configuration database.
10. BSC shall send CSDAP configuration to BTS.
11. BSC shall cancel the penalty from the CSDAP after the procedure is successfully completed.
12. BSC shall inform operator about the procedure completion in execution printout.
Exceptions:
Step 3. Operator does not accept the operation.
Command excution is cancelled.
Step 4. Error in CSDAP information:
BSC shall reject the CSDAP modification and then the BSC shall inform operator about the failure in execution printout if
a. CSDAP does not exist
b. CSDAP parameters have invalid values
Step 6. Already existing physical timeslots in ETPCM:
BSC shall reject the CSDAP modification if the new physical timeslot already situates in the circuit group called ETPCM. This means that it has been already allocated for some other use in Abis ETPCM. The BSC shall inform operator about the failure in execution printout
Step 7. Virtual circuit addition fails:
BSC shall reject the CSDAP modification if adding of the new virtual circuits to the CDAPxxxx circuit group fails. BSC shall remove the new routings created for the CSDAP and then the BSC shall inform operator about the failure in execution printout.
BSC shall reject the CSDAP modification if the radio network database update fails. BSC shall remove all new routings created for the CSDAP and then the BSC shall inform operator about the failure in execution printout.
Step 10. Negative acknowledgement from BTS:
BSC shall reject the CSDAP modification if it receives a negative acknowledgement from BTS. BSC shall remove all new routings created for the CSDAP and restore the previous CSDAP information to radio network configuration database and then the BSC shall restore the previous CSDAP information to the BTS. The BSC shall inform operator about the failure in execution printout.
Frequency of Occurrence:
When more CSDAP capacity is needed for OSC calls to BCF.
Precondition: CSDAP id exists in Abis ETPCM. CSDAP has been attached to BCF.
Minimum Guarantees:
CSDAP size decrement fails.
Removing of routings should not fail. Possible error situations encountered during the procedure are indicated to operator in MCMU computer logs.
Success Guarantees:
CSDAP size is decreased.
Trigger: Operator removes timeslots from the CSDAP.
Main Success Scenario:
1. Operator then requests BSC to remove timeslots from CSDAP via MML or NetAct. Operator shall enter the following parameters in the command:
CSDAP ID
First Timeslot or Last Timeslot
2. In case of MML operation BSC shall require operator to confirm the operation because forced release will be performed for the ongoing calls using the CSDAP during the procedure.
3. BSC shall check that the CSDAP exists and all the command parameters are acceptable. BSC shall reserve the related BCF object for modification.
4. BSC shall set penalty (90 s) for the CSDAP that prevents new resource allocations from the CSDAP during the modification procedure. The BSC
shall perform forced release for the ongoing calls using the modified CSDAP (The same method is used as during BCSU restart).
5. BSC shall change the working state of the removed CSDAP virtual circuits from WO to BA.
6. BSC shall remove the virtual circuits that corresponds the subtimeslots 0,1,2,3,4,5,6,7 of the removed circuits from the CDAPxxxx circuit group.
7. BSC shall remove the removed physical Abis ETPCM timeslots from the circuit group called ETPCM.
8. BSC shall write the updated CSDAP information to the radio network configuration database.
9. BSC shall send CSDAP configuration to BTS.
10. BSC shall cancel the penalty from the CSDAP after the procedure is successfully completed.
11. BSC shall inform operator about the procedure completion in execution printout.
Exceptions:
Step 2. Operator does not accept the operation.
Command excution is cancelled.
Step 3. Error in CSDAP information:
BSC shall reject the CSDAP modification and then the BSC shall inform operator about the failure in execution printout if
a. CSDAP does not exist
b. CSDAP parameters have invalid values
Step 6. Virtual circuit removal failure:
If the removal of circuits fails because they are not free, BSC shall release connections from all virtual circuits corresponding subtimeslots 0,1,2,3,4,5,6,7 and continue the procedure.
Step 6,7 Routing removal failure:
If the removal of some routings fails, BSC shall write explanation of the failure to MCMU computer log and continue the procedure.
BSC shall reject the CSDAP modification if the radio network configuration database update fails. BSC shall restore all the removed routings for the CSDAP and then BSC shall inform operator about the failure in execution printout.
Step 9. Negative acknowledgement from BTS:
If BSC receives negative acknowledgement from BTS then the BSC shall inform operator about the failure in execution printout.
Frequency of Occurrence:
When Abis timeslots are taken to some other use in Abis ETPCM.
7. CSDAP(s) are ready for use and BSC can start hunting resources.
Exceptions:
Step 3. CSDAP does not exist or it has been already attached to some BCF.
BSC shall reject the request. BSC shall inform operator about the failure in execution printout.
Step 4. Database update failure:
BSC shall reject the CSDAP attachment if the radio network configuration database update fails. BSC shall inform operator about the failure in execution printout.
Step 5. Negative acknowledgement from BTS:
If BSC receives negative acknowledgement from BTS, BSC shall remove CSDAP attachment from BCF and shall inform operator about the failure in execution printout.
Frequency of Occurrence:
When OSC DHR feature is taken into use in BCF or, when more CSDAP capacity is needed for OSC calls to BCF.
2. In case of MML operation BSC shall require operator to confirm the operation because forced release will be performed for the ongoing calls using the detached CSDAP during the procedure.
3. BSC shall set penalty (90 s) for the CSDAP that prevents new resource allocations from the CSDAP during the detach procedure. The BSC shall perform forced release for the ongoing calls using the detached CSDAP (The same method is used as during BCSU restart)..
4. BSC shall detach the CSDAP from the BCF in radio network configuration database.
7. BSC shall inform operator about the procedure completion in execution printout.
Exceptions:
Step 2. Operator does not accept the operation.
Command excution is cancelled.
Step 4. Database update failure:
BSC shall reject the CSDAP detach if the radio network configuration database update fails. BSC shall inform operator about the failure in execution printout.
Step 5. Negative acknowledgement from BTS:
If BSC receives negative acknowledgement from BTS then the BSC shall inform operator about the failure in execution printout.
Frequency of Occurrence:
When using of OSC DHR feature stopped on BCF or when CSDAP capacity is reduced on BCF.
Precondition: CSDAP exist and it is not attached to any BCF.
Minimum Guarantees:
Removing of routings should not fail. Possible error situations encountered during the procedure are indicated to operator in MCMU computer logs. BSC returns an acknowledgement to operator.
Success Guarantees:
CSDAP is deleted. All routings are removed.
Trigger: Operator deletes CSDAP.
Main Success Scenario:
1. Operator then requests BSC to delete CSDAP via MML or NetAct. Operator shall enter the following parameters in the command:
CSDAP ID
2. BSC shall check that CSDAP does not have attachment to BCF object.
3. BSC shall remove the CSDAP information from the radio network configuration database.
4. BSC shall change the working state of the virtual circuits that corresponds the subtimeslots 0,1,2,3,4,5,6,7 from WO to BA.
5. BSC shall remove virtual circuits that corresponds the subtimeslots 0,1,2,3,4,5,6,7 from the CDAPxxxx circuit group.
6. BSC shall remove physical Abis ETPCM timeslots from the ETPCM circuit group.
7. BSC shall inform operator about the procedure completion in execution printout.
Exceptions:
Step 2. CSDAP still attached:
BSC shall reject the CSDAP deletion if CSDAP has attachment to BCF. The BSC shall inform operator about the failure in execution printout.
Step 3. Database update failure:
BSC shall reject the CSDAP deletion if the radio network configuration database update fails. The BSC shall inform operator about the failure in execution printout.
Step 5. Virtual circuit removal failure:
If removal of the circuits fails because they are not free, BSC shall release connections from all virtual circuits corresponding subtimeslots 0,1,2,3,4,5,6,7 and continue the procedure.
If removal of some routings fails, BSC shall write explanation of the failure to MCMU computer log and continue the procedure.
Frequency of Occurrence:
When using of OSC DHR feature stopped on BCF or when CSDAP capacity is reduced on BCF.
Bit-based hunting shall be used to allocate resources from CSDAP.
Hunting granularity is 1 bit. All bandwidths from 1 to 8 bits are possible:
1 bit is used for DHR,
2 bits is used for DFR,
3 or 4 bits can be used for example for AMR-WB.
Only the 1 bit hunting is required for DHR. Other granularities are left for further releases.
Source: SFS: BSS21309-008
SFS: BSS21309-016
Rationale:
Bit based hunting is a flexible method to allocate resources from the CSDAP. There is no need for application software to manage CSDAP resources, because DX platform software can offer the management. Without bit-based hunting 8 kbit/s allocations are not possible.
Notes:
Hunting service for bit based hunting allows hunting with bandwidth information and makes one-way connection to the hunted circuits. Hunting service allows hunting of 1-8 consecutive bits from the same time slot and up to eight this kind of same size band slices can be requested with the same hunting request. Hunting is started from the start of the circuit group and when the first slice of the consecutive free bits from the same TSL is found it is reserved and the connection is made to the hunted circuits. Hunting is then repeated for the requested amount of the bandwidth slices.
There are no plans at present for AMR-WB using 32 kbit/s Abis.
7.3.2 BSS30385-015 BSC hunting capability from CSDAP
Description:
BSC shall be able to handle 10 simultaneous hunting operations from a single CSDAP.
BSC shall be able to store 25 temporary resource allocations per CSDAP.
Source: SFS: BSS21309-017
Rationale:
MCMU memory consumption increases in BSC when amount of simultaneuos operations is increased or, when amount of temporarily allocated CSDAP circuits is increased. Values 10 and 25 are selected in order to minimize memory consumption.
7.3.3 BSS30385-016 Resource allocation from CSDAP UC
Source: SFS: BSS21309-018
Context of Use: Abis transmission resources are allocated for an OSC-1 call.
Scope: BSC
Level: User-goal
Actors: BSC, BTS
Precondition: One or several CSDAP have been attached to BCF. OSC DHR is active in cell.
Minimum Guarantees:
Resource allocation fails from CSDAP or OSC-1 channel activation fails. OSC DHR multiplexing procedure is terminated. BSC informs operator about the error situation with disturbance and measurement counters.
Success Guarantees:
Resource allocation is successful from CSDAP. OSC-1 call is activated to the allocated CSDAP resource.
Trigger: OSC DHR multiplexing is started.
Main Success Scenario:
1. BSC shall start OSC multiplexing when BTS cell load exceeds the load threshold as described in requirement BSS21309-015 Triggering of DHR multiplexing.
2. BSC shall select the target TCH/H for DHR multiplexing.
3. BSC shall select the call to be handed over to the selected target TCH/H as an OSC-1 call.
4. BSC shall hunt Abis transmission resource for OSC-1 call from the CSDAPs that are attached to BCF. Bit-based hunting shall be used to allocate resources from CSDAP. Hunting shall be started from the first CSDAP and it shall be continued from the next CSDAP until hunting succeeds. BSC shall increase counter CSDAP RESOURCE ALLOCATION ATTEMPTS FOR DHR when CSDAP resource allocation is started.
5. BSC shall send Abis transmission information among other information for OSC-1 channel to BTS in Channel Activation message.
6. BTS sends Channel Activation Acknowledge to BSC.
7. When BSC receives Channel Activation Acknowledge message from BTS it shall connect one-way downlink connection from the A-interface circuit to the hunted CSDAP circuit.
8. BSC shall send ASSIGNMENT COMMAND to mobile station.
9. BSC shall connect two-way connection between the A-interface circuit and the hunted CSDAP circuit when it receives ESTABLISH INDICATION from BTS.
10. When BSC receives ASSIGNMENT COMPLETE message from the mobile station it shall send HANDOVER PERFORMED message to MSC and release possible one-way connection to the old circuit.
Exceptions:
Step 2/3. No suitable channels for multiplexing:
When a matching pair of TCHs cannot be found, the multiplexing attempt is abandoned.
Step 4. CSDAP hunting error:
BSC shall stop OSC multiplexing attempts in BTS for a penalty period and, shall increment the error counter DHR MULTIPLEXING FAILURE DUE TO CSDAP RESOURCE if
all CSDAPs attached to the BCF are barred because of CSDAP supervision
all CSDAPs attached to the BCF are congested
some other failure is encountered during the hunting procedure
Step 6. Error in CSDAP information:
BTS sends Channel Activation Negative Acknowledge message with new cause "CSDAP error" if it can not accept the channel activation because of CSDAP reasons.
BSC shall terminate the OSC-1 multiplexing attempt and shall increment existing error counters 1083 TCH ACT FAIL TARGET and 4021 INT CELL UNSUCCESS HO DUE BSS PROBLEM.
If the channel activation failure is related to CSDAP problem then BSC shall start a penalty period for the CSDAP and shall raise CIRCUIT SWITCHED DYNAMIC ABIS POOL FAILURE alarm for the CSDAP in question. BSC shall update INT CELL UNSUCCESS HO TO DHR DUE TO CSDAP MISMATCH measurement counter.
BSC shall not include channel activation failures for DHR channels in the activity that currently may result in raising of alarm 7725 TRAFFIC CHANNEL ACTIVATION FAILURE and locking of a radio time slot.
BSC shall release the allocated CSDAP resources after failed channel activation.
Frequency of Occurrence:
Everytime when OSC DHR multiplexing triggers.
Timing and Performance:
Check BSS30385-015 BSC hunting capability from CSDAP.
When OSC-1 sub channel call is terminated, BSC shall not release CSDAP resource even if A-interface circuit is released. BSC shall temporarily connect the CSDAP circuit to NULL circuit until the radio channel (TCH) is successfully released from BTS with RF CHANNEL RELEASE.
When OSC demultiplexing (intra-cell handover) is performed for OSC-1 sub channel call, BSC shall not release CSDAP resource even handover is successfully performed to new channel. BSC shall temporarily connect the CSDAP circuit to NULL circuit until the source radio channel (TCH) is successfully released from BTS with RF CHANNEL RELEASE.
When inter-cell handover is performed for OSC-1 sub channel call, BSC shall not release CSDAP resource even handover is successfully performed to new channel. BSC shall temporarily connect the CSDAP circuit to NULL circuit until the source radio channel (TCH) is successfully released from BTS with RF CHANNEL RELEASE.
When OSC DHR multiplexing fails and MS stays on old channel, BSC shall not release CSDAP resource until the target radio channel is successfully released from BTS with RF CHANNEL RELEASE.
BSC shall release CSDAP resources immediately when channel activation fails for OSC-1 sub channel.
Release order of CSDAP resources and radio resources is important in order to prevent collisions in CSDAP slot usage between BSC and BTS. Collision here means that same CSDAP resource is allocated for a new radio channel in BSC even it is not released from the old radio channel in BTS.
Context of Use: Releasing of CSDAP resources after call release OSC-1 DHR call.
Scope: BSC
Level: User-goal
Actors: MSC, BSC, BTS, MS
Precondition: OSC-1 DHR call is active.
Minimum Guarantees:
The CSDAP circuit is released because of time supervision.
Success Guarantees:
Controlled release is performed for the CSDAP circuit.
Trigger: OSC-1 DHR call is released.
Main Success Scenario:
1. When BSC receives CLEAR COMMAND from MSC concerning OSC-1 DHR call, the BSC shall release connection from Abis-interface circuit to A-interface circuit and then, the BSC shall make time supervised connection (PAFILE T3109 + 2,5 s) from the null circuit (0-1) to the Abis-interface (CSDAP) circuit.
2. BSC releases all A-interface resources releated to the call and sends CLEAR COMPLETE message to MSC
3. BSC sends CHANNEL RELEASE message to MS and sets timer T3109.
4. When BSC receives RELEASE INDICATION message from BTS it stops timer T3109 and starts timer T3111.
5. When timer T3111 expires BSC sends RF CHANNEL RELEASE message to BTS and sets 2 s timer to supervise the RF CHANNEL RELEASE ACKNOWLEDGE message.
6. When BSC receives RF CHANNEL RELEASE ACKNOWLEDGE message from BTS it shall release the connection from the Abis (CSDAP) circuit.
7.4.3 BSS30385-020 Intra-cell handover for CSDAP call UC
Source: SFS: BSS21309-027
Context of Use: Releasing of CSDAP resources after demulplexing of OSC-1 DHR call.
Scope: BSC
Level: User-goal
Actors: MSC, BSC, BTS, MS
Precondition: OSC-1 DHR call is active.
Minimum Guarantees:
The CSDAP circuit is released because of time supervision.
Success Guarantees:
Controlled release is performed for the CSDAP circuit.
Trigger: OSC-1 DHR call is demultiplexed.
Main Success Scenario:
1. BSC starts demultiplexing procedure for OSC-1 DHR call
2. BSC allocates target channel and sends CHANNEL ACTIVATION message to BTS.
3. When BSC receives CHANNEL ACTIVATION ACKNOWLEDGE message from the BTS, it checks if branching can be used and then connects (one-way) branch connection from the A-interface circuit to the new target Abis-interface circuit if it is possible.
4. BSC send ASSIGNMENT COMMAND message to MS.
5. When BSC receives ESTABLISH INDICATION from BTS it makes two-way connection between the A-interface circuit and the target Abis-interface circuit.
If branching is used a (one-way) branch connection is left automatically active from the A-interface circuit to the source Abis-interface (CSDAP) circuit when BSC makes the two-way connection.
If branching is not used the BSC shall connect one-way connection from null circuit (0-1) to the source Abis-interface (CSDAP) circuit just
before making the two-way connection. (Normally connection is released between the A-interface circuit and the source Abis circuit just before making the two-way connection)
6. When BSC receives ASSIGNMENT COMPLETE message from MS it sends HANDOVER PERFORMED message to MSC. Then the BSC shall make time supervised (2,5 s) connection from the null circuit (0-1) to the source Abis-interface (CSDAP) circuit. (Normally the branch connection from A-interface circuit to the source Abis-interface circuit is released in this phase.)
7. BSC sends RF CHANNEL RELEASE message to BTS and sets 2 s timer to supervise the RF CHANNEL RELEASE ACKNOWLEDGE message.
8. When BSC receives RF CHANNEL RELEASE ACKNOWLEDGE message from BTS it shall release the connection from the source Abis (CSDAP) circuit.
7.4.4 BSS30385-021 Inter-Cell HO for CSDAP call UC
Source: SFS: BSS21309-032
Context of Use: Releasing of CSDAP resources after inter-cell handover of OSC-1 DHR call.
Scope: BSC
Level: User-goal
Actors: MSC, BSC, BTS, MS
Precondition: OSC-1 DHR call is active.
Minimum Guarantees:
The CSDAP circuit is released because of time supervision.
Success Guarantees:
Controlled release is performed for the CSDAP circuit.
Trigger: OSC-1 DHR call is handed over to another cell.
Main Success Scenario:
1. BSC starts inter-cell handover procedure for OSC-1 DHR call
2. BSC allocates target channel and sends CHANNEL ACTIVATION message to BTS.
3. When BSC receives CHANNEL ACTIVATION ACKNOWLEDGE message from the BTS, it checks if branching can be used and then connects (one-way) branch connection from the A-interface circuit to the new target Abis-interface circuit if it is possible.
4. BSC send HANDOVER COMMAND message to MS.
5. When BSC receives ESTABLISH INDICATION from BTS it makes two-way connection between the A-interface circuit and the target Abis-interface circuit.
If branching is used a (one-way) branch connection is left automatically active from the A-interface circuit to the source Abis-interface (CSDAP) circuit when BSC makes the two-way connection.
If branching is not used the BSC shall connect one-way connection from null circuit (0-1) to the source Abis-interface (CSDAP) circuit just
before making the two-way connection. (Normally connection is released between the A-interface circuit and the source Abis circuit just before making the two-way connection)
6. When BSC receives HANDOVER COMPLETE message from MS it sends HANDOVER PERFORMED message to MSC. Then the BSC shall make time supervised (2,5 s) connection from the null circuit (0-1) to the source Abis-interface (CSDAP) circuit. (Normally the branch connection from A-interface circuit to the source Abis-interface circuit is released in this phase.)
7. BSC sends RF CHANNEL RELEASE message to BTS and sets 2 s timer to supervise the RF CHANNEL RELEASE ACKNOWLEDGE message.
8. When BSC receives RF CHANNEL RELEASE ACKNOWLEDGE message from BTS it shall release the connection from the source Abis (CSDAP) circuit.
7.4.5 BSS30385-022 OSC multiplexing fails, MS stays on old channel UC
Source: Internal
Context of Use: Releasing of CSDAP resources after failed OSC DHR multiplexing procedure.
Scope: BSC
Level: User-goal
Actors: MSC, BSC, BTS, MS
Precondition: One or several CSDAP have been attached to BCF. OSC DHR is active in cell.
Minimum Guarantees:
The CSDAP circuit is released because of time supervision.
Success Guarantees:
Controlled release is performed for the CSDAP circuit.
Trigger: OSC-1 DHR multilplexing fails.
Main Success Scenario:
1. BSC shall send Abis transmission information among other information for OSC-1 channel to BTS in Channel Activation message.
2. When BSC receives Channel Activation Acknowledge message from BTS it shall connect one-way downlink connection from the A-interface circuit to the hunted CSDAP circuit.
3. BSC shall send ASSIGNMENT COMMAND to mobile station.
4. When BSC receives ESTABLISH INDICATION on target channel from BTS it makes two-way connection between the A-interface circuit and the target Abis-interface (CSDAP) circuit
5. When BSC receives ASSIGNMENT FAILURE from MS on source channel it connects two-way connection back to the source channel if it was already connected to the target channel.
The BSC shall make time supervised (2,5 s) connection from the null circuit (0-1) to the target Abis-interface (CSDAP) circuit. (Normally the branch connection from A-interface circuit to the target Abis-interface circuit is released in this phase.)
BSC shall be able to detect connection problems between BSC and BTS concerning CSDAP. When BSC detects a point to point malfunction in CSDAP it shall stop hunting resources from the CSDAP and set a penalty timer (PAFILE: CSDAP Penalty Duration) for the CSDAP. BSC shall also set an alarm CIRCUIT SWITCHED DYNAMIC ABIS POOL FAILURE that indicates the situation for operator. A point to point malfunction is defined to happen when several consecutive (PAFILE: CSDAP Penalty Threshold) calls using certain CSDAP are released because of remote transcoder failure (BSC DX cause code bc_t_conn_fail_rem_trans_fail_c = 318).
BSC shall be able to detect consecutive hunting errors concerning certain CSDAP. When BSC detects consecutive (PAFILE: CSDAP Penalty Threshold) hunting errors in CSDAP it shall stop hunting resources from the CSDAP and set a penalty timer (PAFILE: CSDAP Penalty Duration) for the CSDAP. BSC shall also set an alarm CIRCUIT SWITCHED DYNAMIC ABIS POOL FAILURE that indicates the situation for operator.
BSC shall be able to handle channel activation failures that are related to CSDAP configuration problems between BSC and BTS. When BSC receives CHANNEL ACTIVATION NEGATIVE ACKNOWLEDGE message with cause code "CSDAP error" it shall stop hunting resources from the CSDAP and set a penalty timer (PAFILE: CSDAP Penalty Duration) for the CSDAP. BSC shall also set an alarm CIRCUIT SWITCHED DYNAMIC ABIS POOL FAILURE that indicates the situation for operator.
When the CSDAP penalty timer expires BSC shall check that there are working circuits in the CSDAP circuit group before it can allow resource allocation from the CSDAP again. If there are working circuits available, BSC shall allow traffic on CSDAP and cancel the alarm indicating CSDAP problem.
Source: SFS: BSS21309-020
Rationale:
Notes:
It has to be taken into account that Abis ETPCM is supervised by DX platform software in BSC. When fault is detected on Abis ETPCM or when the state of the Abis ET is changed to SE-OU, the DX platform software changes all circuits in CSDAP to BA-SY state. In Abis ETPCM fault situation there is 10 second delay before circuit states are changed BA-SY state.
Context of Use: BSC detects consecutive remote transcoder failures on calls allocated from CSDAP
Scope: BSC
Level: User-goal
Actors: BSC, BTS
Precondition:
OSC-1 DHR call is active.
Minimum Guarantees:
Remote transcoder failures are detected on CSDAP, but the penalty threshold is not exceeded.
Success Guarantees:
Remote transcoder failures are detected on CSDAP. BSC prevents resource allocation from the faulty CSDAP. Alarm CIRCUIT SWITCHED DYNAMIC ABIS POOL FAILURE indicates situation for the operator.
BSC allows resource allocations from the CSDAP and cancels the alarm after penalty period is exceeded and fault situation has disappeared.
Trigger: BTS does not detect valid TRAU frames on Abis circuit.
Main Success Scenario:
1. BSC shall keep up internal counter that counts amount of consecutive call releases with the BSC DX cause code bc_t_conn_fail_rem_trans_fail_c = 318 from each CSDAP pool. The counter is increased as long as calls using the certain CSDAP are released with this cause code. If there comes some other release reason then the counter is cleared.
2. When amount of consecutive Remote Transcoder Failures on certain CSDAP exceeds the value defined with PAFILE parameter CSDAP Penalty Threshold, the BSC sets penalty timer for the CSDAP. Penalty duration is defined with PAFILE parameter CSDAP Penalty Duration. BSC does not allocate Abis resources from the CSDAP during the penalty period. BSC
sets alarm CIRCUIT SWITCHED DYNAMIC ABIS POOL FAILURE for the CSDAP.
3. When penalty timer expires the BSC checks that there are working circuits in the CSDAP and then BSC starts trial period for the CSDAP that is as long as the penalty duration (PAFILE: CSDAP Penalty Duration). BSC allows hunting from the CSDAP but it does not cancel the alarm CIRCUIT SWITCHED DYNAMIC ABIS POOL FAILURE.
4. BSC cancels the alarm CIRCUIT SWITCHED DYNAMIC ABIS POOL FAILURE when one successful resource allocation and normal release has been performed from the CSDAP during the trial period. The alarm is also cancelled if there have not been any allocation attempts from the CSDAP during the trial period and the trial period timer expires.
Exceptions:
Step 3. If there are not any working circuits in the CSDAP then the BSC restarts the penalty timer.
Step 4. If there appears a hunting error or a release with the BSC DX cause code bc_t_conn_fail_rem_trans_fail_c = 318 during the trial period then the penalty period is restarted for the CSDAP.
Frequency of Occurrence:
Everytime when point to point error is encountered on call allocated from CSDAP.
Context of Use: BSC encounters consecutive hunting error during resource allocation from CSDAP
Scope: BSC
Level: User-goal
Actors: BSC
Precondition:
OSC is active in the cell. OSC DHR multiplexing triggers.
Minimum Guarantees:
Hunting errors are detected on CSDAP, but penalty threshold is not exceeded.
Hunting errors are detected but they are caused by congestion.
Success Guarantees:
Hunting errors are detected on CSDAP. BSC prevents resource allocation from the faulty CSDAP. Alarm CIRCUIT SWITCHED DYNAMIC ABIS POOL FAILURE indicates situation for the operator.
BSC allows resource allocations from the CSDAP and cancels the alarm after penalty period is exceeded and the fault situation has disappeared.
Trigger: BTS detects missing TRAU frames on Abis circuit.
Main Success Scenario:
1. BSC shall keep up internal counter that counts amount of conscutive hunting errors from each CSDAP pool. The counter is increased as long as hunting fails from the CSDAP. If there comes successful resource allocation from the CSDAP then the counter is cleared.
2. When amount of consecutive hunting errors on certain CSDAP exceeds the value defined with PAFILE parameter CSDAP Penalty Threshold, the BSC sets penalty timer for the CSDAP. Penalty duration is defined with the PAFILE parameter CSDAP Penalty Duration. BSC does not allocate Abis resources from
the CSDAP during the penalty period. BSC sets alarm CIRCUIT SWITCHED DYNAMIC ABIS POOL FAILURE for the CSDAP.
3. When penalty timer expires the BSC checks that there are working circuits in the CSDAP and then BSC starts trial period for the CSDAP that is as long as the penalty duration (PAFILE: CSDAP Penalty Duration). BSC allows hunting from the CSDAP but it does not cancel the alarm CIRCUIT SWITCHED DYNAMIC ABIS POOL FAILURE.
4. BSC cancels the alarm CIRCUIT SWITCHED DYNAMIC ABIS POOL FAILURE when one successful resource allocation and normal release has been performed from the CSDAP during the trial period. The alarm is also cancelled if there have not been any allocation attempts from the CSDAP during the trial period and the trial period timer expires.
Exceptions:
Step 2. If the last hunting error was 'congestion on route' then the BSC sets penalty for the CSDAP only if there are not any working circuits in the CSDAP (all circuits are in BA-SY-state). The BSC checks amount of working circuits before setting the penalty. Hunting is prevented from the CSDAP during the checking procedure.
Step 2. BSC does not set penalty for the CSDAP if the last hunting error was 'congestion on route' and there are working circuits available in the CSDAP. In this case the BSC clears the CSDAP specific hunting error counter.
Step 3. If there are not any working circuits in the CSDAP then the BSC restarts the penalty timer.
Step 3. If there appears a hunting error or a release with the BSC DX cause code bc_t_conn_fail_rem_trans_fail_c = 318 during the trial period then the penalty period is restarted for the CSDAP.
Frequency of Occurrence:
Everytime when consecutive hunting errors are encountered on CSDAP.
7.5.4 BSS30385-026 Circuit Switched Dynamic Abis Pool Failure alarm
New alarm CIRCUIT SWITCHED DYNAMIC ABIS POOL FAILURE shall be defined to indicate failure situations concerning a single CSDAP.
The alarm is set when :
Several consecutive remote transcoder failures are detected on CSDAP
Several concecutive hunting errors are detected on CSDAP
Channel activation failure because of CSDAP error
Missing CSDAP configuration. CSDAP resource allocation attempt for BCF not having any CSDAP attached
o Dummy value shall be set for CSDAP ID
BSS30385 Circuit Switched Dynamic Abis Pool feature is not active. CSDAP resource allocation attempt while the feature is inactive.
o Dummy values shall be set for CSDAP ID and BCF id
In case of remote transcoder failures, hunting errors or, channel activation failures the alarm is cancelled after the penalty timer has expired and, one successful resource allocation and normal release from the CSDAP has been performed. This way alarm pumping is avoided in long lasting failure situations.
In case of missing CSDAP configuration the alarm is cancelled when a CSDAP is attached to the BCF.
In case of the CSDAP feature is not active the alarm is cancelled when the feature is activated.
The alarm is CSDAP specific and it contains the next field elements:
CSDAP ID
BCF id
cause code
This is two star (**) alarm, which means that it requires action in normal working hours.
Source: SFS: BSS21309-020
Rationale:
Operator is able to detect malfunction on a single CSDAP.
7.6.1 BSS30385-027 Abis loop test for CSDAP circuits
Description:
Abis loop test shall be possible for CSDAP circuits.
The CSDAP circuits shall be free while they are tested. There shall not be implemented any special functionality for releasing circuits for Abis loop test.
Testing shall be performed with 2 bits granularity (16 kbit/s circuits).
Source: SFS:BSS21309-021
Rationale:
Linked requirements:
7.6.2 BSS30385-030 Abis loop test shall be done for each CSDAP attached to BCF during automatic comissioning test
Description:
Abis loop test shall be done for each CSDAP attached to BCF during automatic comissioning test when BTS request BSC to start testing with BTS_COMMISS_TEST_REQ message.
The first 16 kbit/s timeslot and the last 16 kbit/s timeslot shall be tested from each CSDAP with Abis loop test during automatic comissioning test.
Source: Internal
Rationale:
Testing of the first 16 kbit/s timeslot and the last 16 kbit/s timeslot is enough to ensure CSDAP operation.
7.6.3 BSS30385-028 Abis loop test for CSDAP circuits UC
Source: SFS: BSS21309-022
Context of Use: Abis loop test is performed for CSDAP circuit(s).
Scope: BSC
Level: User-goal
Actors: BSC, BTS
Precondition:
Minimum Guarantees:
Abis loop test fails for CSDAP circuit(s). The resources allocated for the loop test are released.
Success Guarantees:
Abis loop test success for CSDAP circuit(s). The resources allocated for the loop test are released.
Trigger: Operator starts Abis loop test for CSDAP in BSC.
Main Success Scenario:
1. Operator shall prevent traffic on CSDAP to ensure that CSDAP timeslots are available for Abis loop test. Operator shall change the state of the CSDAP circuit group from WO to BA and wait the release of allocated CSDAP resources.
2. Operator shall define Abis loop test for the CSDAP timeslot with MML. Operator shall enter the following parameters in the command:
7.7.1 BSS30385-029 Circuit Switched Dynamic Abis Pool is optional software
BSS30385 Circuit Switched Dynamic Abis Pool shall be optional software. Optionality shall be controlled with a capacity licence that is based on amount of CSDAP timeslot in CSDAPs attached to BCFs.
BSC shall allow CSDAP attach to BCF object only when there is enough of unused licence capacity available for the operation and the feature's state is ON or CONF.
BSC shall allow increasing of CSDAP size, while the CSDAP has attachment to BCF, only when there is enough of unused licence capacity available for the operation and the feature's state is ON or CONF.
BSC shall allow resource allocations from the CSDAP only when the feature’s state is ON.
BSC shall allow the next operations only when the feature's state is ON or CONF:
o CSDAP creation
o CSDAP size increment
o CSDAP size decrement
o CSDAP attach to BCF object
Rationale: BSS SW business reasons
Circuit Switched Dynamic Abis Pool has to be separately licensed feature because Abis resource could be allocated later also for some other call types than OSC DHR.
New alarm CSDAP RESOURCE ALLOCATION FAILURE shall be defined to indicate situations where OSC multiplexing procedure is terminated in BTS because of failed CSDAP resource allocation.
The alarm is set when the CSDAP resource reservation fails first time for the BTS. BSC sets penalty timer to prevent further DHR multiplexing attempts in BTS.
The alarm is cancelled when the multiplexing penalty timer has expired and CSDAP resource allocation is successful for the BTS. Alarm is also cancelled if load of the cell has decreased so much during the penalty period that DHR multiplexing is not needed anymore.
This is a BTS specific alarm which contains the next field elements
BCF id
BTS id
cause code
This is a one star (*) alarm
Source: SFS: BSS21309-018
Rationale:
Operator is able to detect lack of CSDAP resources attached to the BCF / (BTS).
8 REQUIREMENTS FOR THE FEATURE BSS30390 DYNAMIC SOFT CHANNEL CAPACITY
8.1 BSS30390-001 Dynamic Soft Channel Capacity is optional software
Dynamic Soft Channel Capacity shall be optional software.
Optionality shall be controlled with a capacity licence that is based on TRX amount. Each TRX licence corresponds to 8 TCHs. The BSC shall divide the licence capacity to be used in BCSU units according to their share of the TRXs in BSC configuration. The BSC shall be able to utilize the licenced dynamic capacity in the TRXs where the need exceeds the full FR TCH capacity that is assured to be available according to the basic Soft Channel Capacity feature.
The BSC shall apply Dynamic Soft Channel Capacity only when the feature’s state is ON and there is licenced capacity available for the feature.
Rationale: BSS SW business reasons.
The Dynamic Soft Channel Capacity feature offers an improved method to share the traffic handling capacity of a BCSU unit between the TRXs controlled by the unit. It allows to concentrate the BCSU’s traffic handling capacity in certain hot spots while certain other locations survive with less TCH capacity than has been configured.
The Dynamic Soft Channel Capacity feature is an enhancement to the basic Soft Channel Capacity feature. Dynamic Soft Channel Capacity is reasonable only if operator has also the basic Soft Channel Capacity in use so that (s)he can build a configuration where configured TCH amount exceeds the actual traffic handling capacity.
Source: SFS, RS team
Linked requirements: BSS30390-002
8.2 BSS30390-002 BSC parameter for dynamic channel capacity
A new BSC radio network object parameter Assured Channel Capacity shall be added to define the minimum amount of guaranteed capacity in each TRX while part of the BCSU unit capacity is consumed in the high loaded TRXs of the BCSU as the licenced dynamic capacity. The parameter shall be optional and depend on the availability of the Dynamic Soft Channel Capacity feature.
Assured Channel Capacity parameter is partly based on existing implementation. There is a hidden UTPFIL parameter for this purpose but the existing UTPFIL parameter is in %. After introducing the new BSC radio network object parameter the UTPFIL parameter shall not be used anymore.
There is no need for conversion from the value of the UTPFIL parameter to the new BSC parameter during SW upgrade because the UTPFIL parameter has not been officially used in any operator’s network.
Assured Channel Capacity defines the amount of TCH capacity the BSC shall try to make sure is available in each TRX of a BCSU unit. The parameter shall have a value in range 1…8. The guaranteed capacity in a TRX shall not exceed the TCH TSL amount of the TRX. If a TRX has less TCH TSLs than the value of the Assured Channel Capacity the BSC shall use the actual TCH TSL amount as the target for the guaranteed capacity in the TRX. The parameters default value 8 practically means that Dynamic Soft Channel Capacity is not in use.
Source: SFS, RS team
Rationale:
Operator needs means for ensuring certain minimum available capacity in each TRX while part of the BCSU capacity is consumed dynamically in the high loaded TRXs.
Linked requirements: BSS30390-001
8.3 BSS30390-003 TRX parameter for dynamic channel capacity (REJECTED)
Note: This requirement has been rejected based on the licencing principle correction that was made according to the findings in the original review.
A new TRX radio network object parameter Dynamic Soft Channel Capacity Enabled shall be added to define if the dynamic channel capacity offered by the Dynamic Soft Channel Capacity feature is to be employed in a TRX.
The parameter shall be optional and depend on the availability of the Dynamic Soft Channel Capacity feature.
Modifying of the parameter shall require locking of the TRX.
Source: RS team
Rationale:
This parameter is needed for managing the capacity licence based on TRX amount.
Explanation of the rightmost columns of the table:
MML = Parameter can be handled via MML commands (M=read/modify, R=read-only)
FBPP = Parameter is included in the File Based Plan Provisioning featureFBUL = Parameter is included in the File Based Upload featureStNW = Parameter is included in the Send to Network featureQ3 = Parameter can be handled via Q3 commands (M or R)Event = Changing of the parameter value is reported to NetAct via an event
9.1.1.1.1 Double Half Rate with SAIC MS
NameNew / Modified Level Description Range
Default value
MML
FBPP
FBUL
StNW
Event
DHR Limit For FR TCH Resources
New BTS Determines the limit value for the amount of idle FR TCH resources of a BTS below which existing AMR HR and AMR FR calls are multiplexed as double half rate calls. Value 0 means that double half rate multiplexing is disabled.
0..100%
0% M x X x x
TRX OSC capability
New TRX Indicates if the TRX supports Orthogonal Subchannel feature
N/Y N R - X - x
OSC Multiplexing Ul Rx Level Threshold
New HOC Determines minimum uplink RX level for double half rate multiplexing.
AMR HR calls which have uplink Rx level at or above the Rx level threshold, can be selected as a target channel for double half rate multiplexing.
-110...-47 dBm, step 1 dB
-85 dBm M x X x x
OSC Multiplexing Ul Rx Level Window
New HOC Determines maximum allowed Ul Rx Level difference between candidates for pairing in
This parameter shall always have lower value than OSC Demultiplexing Ul Rx Level Margin.
dB
OSC Multiplexing Rx Quality Threshold
New HOC Determines uplink and downlink RX quality threshold for target channel for double half rate multiplexing.
AMR HR calls which have averaged Rx quality at or above the OSC Multiplexing Ul Rx Level Threshold both in uplink and downlink direction can be selected as a target channel for double half rate multiplexing.
New HOC Determines uplink RX level difference threshold for triggering double half rate demultiplexing for the stronger connection into an AMR HR call.
This parameter shall always have higher value than OSC Multiplexing Ul Rx Level Window
0...63 dB, step 1 dB
14 dB M x x x x
OSC Demultiplexing Rx Qual Threshold
New HOC This parameter defines the threshold level of the averaged signal quality downlink and uplink measurements for triggering the intra-cell handover for an double half rate call in order to switch it to an AMR FR call.
New HOC This parameter defines the threshold level of the averaged signal quality downlink measurements for triggering the handover. Defined for the double half rate call.
New HOC This parameter defines the threshold level of the averaged signal quality uplink measurements for triggering the handover. Defined for the double half rate call.
New POC With this parameter you define the threshold level of the averaged uplink signal quality measurements for the MS power increase. Defined for the double half rate call.
New POC With this parameter you define the threshold level of the averaged downlink signal quality measurements for the BTS power decrease. Defined for the double half rate call.
New POC With this parameter you define the threshold level of the averaged uplink signal quality measurements for the MS power decrease. Defined for the double half rate call.
MML:This parameter is modified by entering new value for parameter New First Timeslot (NFT). By entering a number smaller than the first time slot you add the time slot(s) to the beginning of the pool. By entering a number bigger than the first time slot you remove time slot(s) from the beginning of the pool.
TSLs: in ETSI 1..31, in ANSI 1..24
Last Timeslot New CSDAP This parameter defines the last time slot of the CSDAP. The time slots are entered as time slot numbers.
NOTE:
MML:This parameter is given during CSDAP creation by entering last timeslot to parameter Circuit (CRCT) or, by entering pool size with parameter Size (SIZE).
MML:This parameter is modified by entering new value for parameter New Last Timeslot (NLT). By entering a number bigger than the last time slot you add time slot(s) to end of the pool. By entering a number smaller than the last time slot you remove time slot(s) from the end of the pool.
CRCT TSLs: in ETSI 1..31, in ANSI 1..24
1...31 - M x x x x
BCF Abis IF New CSDAP This parameter identifies Abis IF number in BCF side.
NOTE: Modification is possible only when the CSDAP has not been attached to BCF.
1...16 - M x x x x
BCF Timeslot Shift
New CSDAP This parameter identifies offset between ETPCM
New BCF This parameter identifies the circuit switched dynamic Abis pool that is attached to the BCF.
NOTE:
MML Modification: Read-only, the value is given during CSDAP attach/detach.
1...1000, special value: 'not_in_use'
'not_in_use'
M x x x x
CSDAP Penalty Duration
New PAFILE This parameter defines duration of CSDAP penalty timer.
BSC sets penalty for a certain CSDAP in case of
- consecutive remote transcocder failures
- hunting error(s)
1...255 seconds
90 s M
CSDAP Penalty Threshold
New PAFILE This parameter defines the amount of consecutive remote transcoder failures after which CSDAP supervision considers the CSDAP as malfunctioned.
0...255
0= penalty not in use
5 M
9.1.1.1.3 Dynamic Soft Channel Capacity
NameNew / Modified Level Description Range
Default value
MML
FBPP
FBUL
StNW
Event
Assured Channel Capacity
New BSC This parameter determines assured capacity in each TRX as absolute TCH amount when part of the capacity in the BCSU is utilised dynamically by the loaded TRXs according to the Dynamic Soft Channel Capacity licences.
New New Circuit Switched Dynamic Abis Pool Measurement is added under Call Control Measurements. It contains counters to verify CSDAP usage rate and makes possible for the operator to optimize the size of CSDAP.
OSC RX Quality Measurement
New The OSC RX Quality Measurement collects statistics of received signal quality both in uplink and downlink directions for each AMR HR bitrate for double half rate calls. The information is collected from each transceiver separately.
The Bit Error Ratio (BER) based signal quality counters correspond to the eight RX Quality bands, as defined in 3GPP TS 45.008, both in uplink and downlink directions. The counters are updated by the RX Quality values as measured by the MS (downlink) and BTS (uplink) and reported in the radio link measurement messages. The RX Quality reports are collected on the traffic channels .
The counters that are related to Double Half Rate give information about the distribution of the received signal quality using the different AMR bitrates. There are separate uplink and downlink counters for each RX quality band 0..7 and for each AMR bitrate used with a double half rate call. There are five different bitrates (4.75, 5.15, 5.90, 6.70 and 7.40) for Double Half Rate.
Updated: When the Radio Resource Management concludes the need for double half rate multiplexing at the reception of Rx level and power control information from the HO&PC algorithm.
DHR MULTIPLEXING FAILURE DUE TO TCH RESOURCE
Traffic Measurement
Description: Number of times a suitable pair of AMR calls for double half rate multiplexing cannot be found.
Updated: When the Radio Resource Management fails to allocate calls for double half rate multiplexing at the reception of Rx level and power control information from the HO&PC algorithm.
CSDAP RESOURCE ALLOCATION ATTEMPTS FOR DHR
Traffic Measurement
Description: Number of CSDAP resource allocation attempts for Double Half Rate.
Updated: When Radio Resource Management requests CSDAP resources for double half rate multiplexing.
DHR MULTIPLEXING FAILURE DUE TO CSDAP RESOURCE
Traffic Measurement
Description: Double half rate multiplexing has triggerred but CSDAP resource allocation fails because of
CSDAP congestion
CSDAP being out of order due to failure
CSDAP hunting timer expiry or
CSDAP hunting error.
Updated: After double half rate multiplexing attempt has been cancelled.
Description: Sum of the busy double half rate TCHs sampled. The average value is calculated by dividing the value of this counter by the value of the denominator counter AVE BUSY DHR TCH DENOMINATOR.
Updated: The number of the busy double half rate TCHs is sampled every 20 seconds. The number of the busy double half rate TCHs is updated when a double half rate TCH is seized or released.
Dependencies with other counters: AVE BUSY DHR TCH DENOMINATOR is updated along with this counter.
AVE BUSY DHR TCH DENOMINATOR
Resource Availability Measurement
Description: Number of the busy double half rate TCH samples. Denominator of the average number of busy double half rate TCHs.
Updated: The counter is updated every 20 seconds when a sample of the busy double half rate TCH number is taken.
Dependencies with other counters: AVE BUSY DHR TCH counter is updated along with this counter.
Measurement demultiplexing handover attempts starting from a double half rate TCH based on Rx quality.
Updated: When demultiplexing handover attempt for a double half rate call is started based on Rx quality.
HO ATTEMPT FROM DHR DUE TO UL RX LEVEL DIFFERENCE
Handover Measurement
Description: Number of demultiplexing handover attempts starting from a double half rate TCH based on UL Rx level difference between the multiplexed double half rate TCHs.
Updated: When a demultiplexing handover attempt for a double half rate call is started based on UL Rx level difference between the multiplexed double half rate TCHs.
HO FROM DHR DUE TO RX QUALITY SUCCESSFUL
Handover Measurement
Description: Number of successful handovers starting from double half rate TCH based on Rx quality.
Updated: When a demultiplexing handover starting from a double half rate TCH based on Rx quality has been completed.
HO FROM DHR DUE TO UL RX LEVEL DIFFERENCE SUCCESSFUL
Handover Measurement
Description: Number of successful demultiplexing handovers starting from a double half rate TCH based on UL Rx level difference between the multiplexed double half rate TCHs.
Updated: When a demultiplexing handover from a double half rate TCH based on UL Rx level difference between the multiplexed double half rate TCHs has been completed.
INTRA HO FROM AMR HR TO DHR
BSC Level Clear Code (PM) Measurement
Description: Number of successful intra-cell handovers from an AMR HR TCH to a double half rate TCH.
Updated: After the HANDOVER PERFORMED message is sent to the MSC.
Dependencies with other counters:: Counter 051014 Internal Intra HO Succ and counter 057013 Int Intra HO Success (BSC Level Clear Code (SERLEV) Measurement) are updated along with this counter.
INTRA HO FROM AMR FR TO DHR
BSC Level Clear Code (PM) Measurement
Description: Number of successful intra-cell handovers from an AMR FR TCH to a double half rate TCH.
Updated: After the HANDOVER PERFORMED message is sent to the MSC.
Dependencies with other counters:: Counter 051014 Internal Intra HO Succ and counter 057013 Int Intra HO Success (BSC Level Clear Code (SERLEV) Measurement) are updated along with this counter.
INTRA HO FROM DHR DUE TO RX QUALITY
BSC Level Clear Code (PM) Measurement
Description: Number of successful intra-cell handovers starting from a double half rate TCH based on Rx quality.
Updated: After the HANDOVER PERFORMED message is sent to the MSC.
Dependencies with other counters: Counter 051014 Internal Intra HO Succ and counter 057013 Int Intra HO Success (BSC Level Clear Code (SERLEV) Measurement) are updated along with this counter.
INTRA HO FROM DHR DUE TO UL RX LEVEL DIFFERENCE
BSC Level Clear Code (PM) Measurement
Description: Number of successful intra-cell handovers starting from a double half rate TCH based on UL Rx level difference between the
Updated: After the HANDOVER PERFORMED message is sent to the MSC.
Dependencies with other counters: Counter 051014 Internal Intra HO Succ and counter 057013 Int Intra HO Success (BSC Level Clear Code (SERLEV) Measurement) are updated along with this counter.
TOTAL PCM 8 KBIT/S SUBTSLS IN CSDAP
CSDAP Measurement
Description: Total number of 8 kbit/s PCM subTSLs in a CSDAP.
Updated: The counter is updated by the size of the CSDAP once in a measurement period.
AVERAGE CSDAP 8 KBIT/S SUBTSL USAGE
CSDAP Measurement
Description: Sum of the busy 8 kbit/s subTSLs sampled in CSDAP. The average value is calculated by dividing the value of this counter by the value of the denominator counter AVERAGE CSDAP 8 KBIT/S SUBTSL USAGE DENOMINATOR.
Updated: The number of the busy 8 kbit/s subTSLs is sampled every 20 seconds. The number of the busy 8 kbit/s subTSLs is updated when an 8 kbit/s subTSL resource is allocated or released.
Dependencies with other counters: This counter is updated along with the AVERAGE CSDAP 8 KBIT/S SUBTSL USAGE DENOMINATOR counter.
AVERAGE CSDAP 8 KBIT/S SUBTSL USAGE DENOMINATOR
CSDAP Measurement
Description: Number of the busy 8 kbit/s subTSL samples. Denominator for counter AVERAGE CSDAP 8 KBIT/S SUBTSL USAGE.
every 20 seconds when a sample of the busy 8 kbit/s subTSL number is taken.
Dependencies with other counters: This counter is updated along with the AVERAGE CSDAP 8 KBIT/S SUBTSL USAGE counter.
PEAK CSDAP 8 KBIT/S SUBTSL USAGE
CSDAP Measurement
Description: Peak usage of 8 kbit/s subTSLs in CSDAP.
Updated: When the number of reserved 8 kbit/s subTSLs exceeds the previous peak value.
OSC AMR HR 4.75 ON UPLINK DIRECTION WITH RXQUAL 0
OSC RX Quality Measurement
Description: Number of times AMR HR 4.75 kbit/s codec mode (bitrate) is used when the RX quality is within class 0 on the uplink direction for a double half rate call. On the fast link adaptation (LA) mode the bitrate is the last used one during the measurement report interval. On the slow LA mode this counter indicates the only used bitrate during the measurement report interval.
Updated: The counter is updated every time when a measurement report is received concerning double half rate radio channel and the codec mode of 4.75 kbit/s is used for AMR MS on the uplink direction and the reported RX quality is within class 0.
OSC AMR HR 4.75 ON DOWNLINK DIRECTION WITH RXQUAL 0
OSC RX Quality Measurement
Description: Number of times AMR HR 4.75 kbit/s codec mode (bitrate) is used when the RX quality is within class 0 on the downlink direction for a double half rate call. On the fast link adaptation (LA) mode the bitrate is the last used one during the measurement report interval. On the slow LA mode this counter indicates the only used bitrate during the
Updated: The counter is updated every time when a measurement report is received concerning a double half rate radio channel and the codec mode of 4.75 kbit/s is used for AMR MS on the downlink direction and the reported RX quality is within class 0.
.. RXQUAL 1...7 OSC RX Quality Measurement
Check above.
OSC AMR HR 5.15 ON UPLINK DIRECTION WITH RXQUAL 0
OSC RX Quality Measurement
Check above.
OSC AMR HR 5.15 ON DOWNLINK DIRECTION WITH RXQUAL 0
OSC RX Quality Measurement
Check above.
.. RXQUAL 1...7 OSC RX Quality Measurement
Check above.
OSC AMR HR 5.90 ON UPLINK DIRECTION WITH RXQUAL 0
OSC RX Quality Measurement
Check above.
OSC AMR HR 5.90 ON DOWNLINK DIRECTION WITH RXQUAL 0
OSC RX Quality Measurement
Check above.
.. RXQUAL 1...7 OSC RX Quality Measurement
Check above.
OSC AMR HR 6.70 ON UPLINK DIRECTION WITH RXQUAL 0
OSC RX Quality Measurement
Check above.
OSC AMR HR 6.70 ON DOWNLINK DIRECTION WITH RXQUAL 0
New values to support OSC DHR specific codecs 7.4, 6.7, 5.9, 5.15 and 4.75kbit/s.
Object modification DFCA Measurement
The object level of the measurement is BTS id + connection type (FR/EFR, HR, 14.4, AMR FR, AMR HR, SDCCH, PS DATA). DHR shall be added as a new connection type to be collected data about
Object modification DFCA SAIC Measurement
The object level of the measurement is BTS id + connection type (FR/EFR, HR, 14.4, AMR FR, AMR HR). DHR shall be added as a new connection type to be collected data about
9.1.2.3 Key performance indicators
To verify feature functionality some new key performance indicators (KPIs) can be created in measurement data post processing tool. Below are some examples of the KPIs.
DHR seizures:
DHR MULTIPLEXING ATTEMPTS - DHR MULTIPLEXING FAILURE DUE TO TCH RESOURCE
Average DHR traffic in a measurement period:
AVE BUSY DHR TCH / AVE BUSY DHR TCH DENOMINATOR
Peak DHR traffic in a measurement period:
PEAK BUSY DHR TCH
AMR HR to DHR Handover success ratio:
100% * HO FROM AMR HR TO DHR SUCCESSFUL / HO ATTEMPT FROM AMR HR TO DHR
AMR FR to DHR Handover success ratio:
100% * HO FROM AMR FR TO DHR SUCCESSFUL / HO ATTEMPT FROM AMR FR TO DHR
Handover success ratio from DHR due to Rx quality:
100% *HO FROM DHR DUE TO RX QUALITY SUCCESSFUL / HO ATTEMPT FROM DHR DUE TO RX QUALITY
Handover success ratio from DHR due to UL Rx level difference:
100% *HO FROM DHR DUE TO UL RX LEVEL DIFFERENCE SUCCESSFUL / HO ATTEMPT FROM DHR DUE TO UL RX LEVEL DIFFERENCE
Average CSDAP usage:
AVERAGE CSDAP 8 KBIT/S SUBTSL USAGE / AVERAGE CSDAP 8 KBIT/S SUBTSL USAGE DENOMINATOR
Peak CSDAP usage:
PEAK CSDAP 8 KBIT/S SUBTSL USAGE
9.1.2.4 Internal statistics
No changes.
9.1.2.5 System Level Trace
No changes.
9.1.3 Effects on MMI
For the new parameters see Parameters.
For Double Half Rate related MMI printouts see requirements BSS21309-003 TRX parameter for OSC support and BSS21309-005 DHR channels in MML printouts.
Double half rate resources shall be included in E00HAN servive terminal extension printouts with the same accuracy as traditional radio channel resources currently.
Service terminal extensions E01HAN, ABMONI and TGMONI to be updated due to the Double Half Rate feature.
The BSC shall deploy OSC on a call-by-call basis. The BSC gives OSC subchannel identification, training sequence code, amount of bits used on Abis interface and CSDAP resource to BTS in Channel Activation message, see /1/.
9.2.1.1 Channel Mode IE
Channel Mode information element gives information on the mode of coding/decoding and transcoding/rate adaption of a channel. OSC usage and number of used bits on Abis interface shall be defined in bits 6 - 8 of octet 3 of the Channel Mode IE, as depicted in table below.
8 7 6 5 4 3 2 1Element identifier 1
Length 2OSC
in UseBits on Abis Reserved for future use DTXd DTXu 3
Speech or data indicator 4Channel rate and type 5
Speech coding algor./data rate + transp ind 6
The OSC in Use bit of octet 3 indicates whether OSC is deployed:
1 OSC is deployed
0 OSC is not deployed
The Bits on Abis bits of octet 3 indicate the number of used Abis bits, when OSC is deployed and CSDAP Circuit IE is present in Channel Activation message:
In the BSC-to-BTS direction the Channel Number information element is used to indicate on which physical channel the message is to be sent. In the BTS-to-BSC direction the Channel Number IE indicates on which physical channel the message was received.
OSC-1 subchannel shall be defined in the free C-bit combinations of Channel Number IE in Abis telecom interface messages, as depicted below. OSC-0 subchannel shall use the legacy channel number codings.
8 7 6 5 4 3 2 1
Element identifier 1
C5 C4 C3 C2 C1 TN 2
The C-bits describe the channel as follows:
C5 C4 C3 C2 C10 0 0 0 1 Bm + ACCH's (DFR OSC-0 sub channel)0 0 0 1 T Lm + ACCH's (DHR OSC-0 sub
channels)0 0 1 T T SDCCH/4 + ACCH0 1 T T T SDCCH/8 + ACCH1 0 0 0 0 BCCH1 0 0 0 1 Uplink CCCH (RACH)1 0 0 1 0 Downlink CCCH (PCH + AGCH)1 1 0 0 1 Bm + ACCH's (DFR OSC-1 sub channel)1 1 0 1 T Lm + ACCH's (DHR OSC-1 sub
channels)
The T-bits in table above indicate, coded in binary, the subchannel number as specified in 3GPP TS 45.002.
Legacy codings 00010 and 00011 are for double half rate OSC-0 subchannels. The corresponding OSC-1 subchannels are coded as 11010 and 11011.
Legacy coding 00001 is used for double full rate OSC-0 subchannel. The corresponding OSC-1 subchannel is coded as 11001.
TN is time slot number, represented in binary as in 3GPP TS 45.002.
Training sequence code shall be included on a call-by-call basis by including the optional Channel Identification IE in the Channel Activation message. This method is according to existing practice of DFCA implementation.
9.2.1.4 CSDAP Circuit IE
CSDAP resource shall be defined in the Channel Activation message as a new conditional CSDAP Circuit IE after the Nokia specific ACCH Control IE, see /D/. CSDAP Circuit IE shall only be present when OSC is deployed and OSC-1 subchannel is indicated.
Octet 5 bits 1 to 3 contain Sub timeslot information. Range 0..7. Octet 5 bits 4 to 8 contain Timeslot information. Range 0..31.Timeslot information is indicated as Abis ETPCM timeslot.
9.2.1.5 Cause IE
New cause values are needed for Channel Activation Negative Acknowledge message in case BTS can not accept the channel activation because of CSDAP or TSC reasons:
CSDAP error: cause value 101 1101
OSC TSC conflict: cause value 101 1110
9.2.1.6 Supplementary Measurement Information
BTS shall indicate to BSC the measurement result validity information, the uplink DTX information and the uplink RX level information of the neighbouring OSC subchannel. BTS indicates these pieces of information in Measurement Result message inside Supplementary Measurement Information of the Uplink Measurements IE.
AMR signalling data IEI Length of AMR signalling data N+M+1
DL_SRR UL_SRO
DL_SRS
FF_rep N+M+2
Spare ULSC FF_non_rep N+M+3
. . .DL_SRR UL_S
RODL_S
RSFF_rep N+M+K-1
Spare ULSC FF_non_rep N+M+K
OSC Neighbouring Sub Channel Measurements IEValidity DTXu RXLEV-FULL-up
Spare RXLEV-SUB-up
Octet N+M+K+1 contains the OSC Neighbouring Sub Channel Measurements IE (0x05). The neigbouring OSC sub channel here means the sub channel sharing the same radio channel with the sub channel the Measurement Result message is meant for. The next two octets contain RX level measurements as defined in 3GPP TS 48.058.
Octet N+M+K+2 contains measurement result validity information. The Validity bit indicates if BTS has valid measurement result available from the mobile on the neighbouring OSC sub channel during the measurement period
0 invalid measurement result
1 valid measurement result
Octet N+M+K+2 contains DTXu information. The DTXu bit indicates whether uplink DTX was employed by the mobile on the neighbouring OSC sub channel during the measurement period
When BTS Measure Average (BMA) is set to value 2...4 BTS shall report fields in Neighbouring Sub Channel Measurement IE according to the next table:
Name of the field Handling of the field in averagingValidity Set 0 if 0 in any of reports to be averagedDTXu Set 1 if 1 in any of reports to be averagedRXLEV-FULL-up Averaged
RXLEV-SUB-up Averaged
BTS receives 'Averaging period' in the FU parameters IE in BTS_CONF_DATA message.
9.2.2 Abis O&M interface
9.2.2.1 BTS STATE CHANGED message
BTS shall provide info about FlexiEDGE BTS OSC support for BSC.
FIELD TYPE NOTE
Command header M
Object identity and object state M 1,4
Air i/f modulation O 2
TRX Special Tx Power O 3 OSC support O
NOTE 1: Object = TRX, state = enabled. NOTE 2: See table below:
Note 1: range 0 = TRX shall start in EGPRS mode, 1 = TRX shall start in OSC mode
Note 2: Valid only for Epsilon TRX
9.2.2.3 BTS_TEST_REQ (ABIS_LOOP_TEST) message
FIELD TYPE NOTE
Command header M
Test type M 1
Object identity (=TRX + RTSL) M 2
Loop duration ms M 3
Abis TSL O 4,6
CSDAP id O 5
NOTE 1: 'Abis_loop_test_req' or 'Abis_loop_test_stop_req'. From BTS’s point of view the loop is an equipment or interface loop somewhere in Abis transmission. As default the loop will be in BSC’s group switch. Test_stop_request means that BTS stops the ongoing test and builds an valid report of the results reached so far.
NOTE 2: During autoconfiguration it is possible to test also the signalling RTSLs (BCCH, SDCCH). The state of the RTSL can be either Locked or Unlocked.
NOTE 3: minimum 100 ms, value 0 means a permanent loop NOTE 4: This element is included if Dynamic Abis allocation is used. NOTE 5: This element is included when CSDAP circuit is tested. NOTE 6: When CSDAP is tested the Abis TSL indicates testable timeslot as Abis ETPCM
timeslot. Position in timeslot is indicated with 2 bits granularity. Position range from 0 to 3.
NOTE 1: The same as in the test request. NOTE 2: If the test fails, the values returned in the remaining elements of the report are
insignificant. NOTE 3: This element is included if Dynamic Abis allocation is used. NOTE 4: This element is included when CSDAP circuit is tested. NOTE 5: When CSDAP is tested the Abis TSL indicates testable timeslot as Abis ETPCM
timeslot. Position in timeslot is indicated with 2 bits granularity. Position range from 0 to 3.
9.2.2.5 Ack-Nack
New CSDAP specific cause values in Ack-Nack IE to be used in the BTS_ACK message.
? N_CSDAP_ABIS_IF_NOT_IN_USE_1 Abis IF is not in use in BCF. This cause code refers to the first CSDAP IE in the BTS_CONF_DATA message.
? N_CSDAP_ABIS_IF_NOT_IN_USE_2 Abis IF is not in use in BCF. This cause code refers to the second CSDAP IE in the BTS_CONF_DATA message.
? N_CSDAP_ABIS_IF_NOT_IN_USE_3 Abis IF is not in use in BCF. This cause code refers to the third CSDAP IE in the BTS_CONF_DATA message.
? N_CSDAP_ABIS_IF_NOT_IN_USE_4 Abis IF is not in use in BCF. This cause code refers to the fourth CSDAP IE in the BTS_CONF_DATA message.
? N_CSDAP_OUT_OF_BOUND_1 CSDAP timeslots exceed the E1/T1 bounds. This cause code refers to the first CSDAP IE in the BTS_CONF_DATA message.
? N_CSDAP_OUT_OF_BOUND_2 CSDAP timeslots exceed the E1/T1 bounds. This cause code refers to the second CSDAP IE in the BTS_CONF_DATA message.
? N_CSDAP_OUT_OF_BOUND_3 CSDAP timeslots exceed the E1/T1 bounds. This cause code refers to the third CSDAP IE in the BTS_CONF_DATA message.
? N_CSDAP_OUT_OF_BOUND_4 CSDAP timeslots exceed the E1/T1 bounds. This cause code refers to the fourth CSDAP IE in the BTS_CONF_DATA message.
? N_CSDAP_OVERLAP_1 CSDAP timeslot are overlapping with other Abis resources. This cause code refers to the first CSDAP IE in the BTS_CONF_DATA message.
? N_CSDAP_OVERLAP_2 CSDAP timeslot are overlapping with other Abis resources. This cause code refers to the second CSDAP IE in the BTS_CONF_DATA message.
? N_CSDAP_OVERLAP_3 CSDAP timeslot are overlapping with other Abis resources. This cause code refers to the third CSDAP IE in the BTS_CONF_DATA message.
? N_CSDAP_OVERLAP_4 CSDAP timeslot are overlapping with other Abis resources. This cause code refers to the fourth CSDAP IE in the BTS_CONF_DATA message.
? N_CSDAP_RESOURCE_UNAVAILABLE
CSDAP does not exist or the the timeslot does not belong to CSDAP.
Double Half Rate with SAIC MS and Circuit Switched Dynamic Abis Pool have effects on 3GPP TS 48.058 Base Station Controller - Base Transceiver Station (BSC - BTS) Interface; Layer 3 Specification.
Amount of circuit groups shall be increased. Check requirement BSS30385-004 Circuit group amount increase.
9.6 Capacity and performance
BSC performance should remain on the same level when switching from a traditional configuration to a new one using Double Half Rate feature and less TRXs. The BSC should be able to transmit the same amount of traffic in each configuration.
9.7 Interaction with other features or functionalities
9.7.1 AMR Half Rate
Existence of AMR HR calls is a prerequisite for Double Half Rate multiplexing. DHR multiplexing shall be supplementary activity in addition to the traditional AMR HR packing in situations of high load.
9.7.2 Circuit Switched Dynamic Abis Pool, Packet Abis
Use of Double Half Rate always requires additional Abis transport capacity for the second OSC connection in a half rate TCH channel. Additional Abis transport capacity shall be provided by the Circuit Switched Dynamic Abis Pool feature or by the Packet Abis feature.
9.7.3 Rx diversity
Use of Double Half Rate requires that the Rx diversity feature is also in use. Without RX diversity DHR performance will be very poor with only one antenna. DHR multiplexing is not reasonable in a BTS with RX diversity out of use.
9.7.4 Emergency calls
The BSC shall not apply DHR multiplexing for emergency calls.
9.7.5 Dual Transfer Mode
The BSC shall not apply DHR multiplexing for calls in dual transfer mode (DTM).
9.7.6 AMR Unpacking Optimization
When the AMR Unpacking Optimization feature is used together with Double Half Rate the BSC shall follow the parameters of AMR Unpacking Optimization to prevent demultiplexing of DHR connections into non-OSC connections as well the intra cell handovers due to interference for the OSC DHR connections in case of very poor quality.
With AMR Unpacking Optimization in use the BSC uses the signal level thresholds of the feature to direct a DHR connection either to AMR HR or to AMR FR in a triggered demultiplexing handover, or to totally prevent the demultiplexing handover if the signal level is very poor.
9.7.7 Improved AMR packing and unpacking
When the Improved AMR packing and unpacking feature is in use the BSC uses the RX level based trigger of the feature to initiate OSC DHR demultiplexing into AMR FR.
Operator is recommended to apply RF hopping or BB hopping together with OSC in order to smooth out the impact of fast fading.
The BSC shall not apply OSC in BB hopping and Antenna hopping BTS objects where TRXs have varying OSC capability.
9.7.9 Dynamic Frequency and Channel Allocation
The BSC supports the Double Half Rate with SAIC MS feature also in the TRXs that apply the Dynamic Frequency and Channel Allocation (DFCA) feature.
9.7.10 Enhanced Coverage by Frequency Hopping, Intelligent Underlay-Overlay, Handover Support for Coverage Enhancements
OSC shall not be supported in the super reuse layer of a BTS.
9.7.11 Extended Cell Range
OSC shall not be supported in the TRXs of the extended coverage area.
9.7.12 Wideband AMR
Multiplexing into DHR is not supported for wideband AMR FR connections.
9.7.13 Tandem-free Operation
Normal rules of Tandem-free Operation (TFO) are applied when DHR multiplexing handover is performed starting from an AMR FR or AMR HR call and when demultiplexing from DHR is made into an AMR FR or AMR HR call.
9.7.14 UL interference level update procedure
The uplink interence level update procedure is not changed at the introduction of OSC DHR channels. The information delivered by the UL interference level update procedure is not applied in OSC multiplexing algorithm.
9.7.15 Double Power TRX
The BSC does not apply DHR multiplexing in a TRX that has Double Power TRX (DPTRX) feature in use.
9.7.16 Intelligent Downlink Diversity
The BSC does not apply DHR multiplexing in a TRX that has Intelligent Downlink Diversity (IDD) feature in use.
The BSC does not apply DHR multiplexing in a TRX that has 4-way uplink diversity (4UD) feature in use.
9.7.18 Soft Channel Capacity
Soft Channel Capacity feature may be used to enable the full TRX configuration with Double Half Rate in use but Soft Channel Capacity is not absolutely necessary with Double Half Rate.
9.7.19 Dynamic Soft Channel Capacity
Dynamic Soft Channel Capacity feature may be used to further enhance the ability to utilize BSC’s traffic handling capacity in certain hot spot locations and high loaded cells where the Double Half Rate feature is in use. Dynamic Soft Channel Capacity is a very useful feature when the amount of configured TCH capacity exceeds the actual traffic handling capability of the BSC as a result of the concurrent use of Double Half Rate and the basic Soft Channel Capacity feature.
New information elements used in Abis O&M and Abis Telecom interface have to supported by
Network Protocol Analyzer
TTCN tester
9.9 Restrictions
See requirements
BSS21309-050 OSC limitation in hopping configuration with different TRX HW variants,
BSS21309-043 No EGPRS2 TSL followed by OSC TSL.
See also chapter Interaction with other features or functionalities for the restrictions there are in the interactions with other features.
9.10 IPR Issues
9.10.1 Need for IPR Risk Analysis
To be examined.
9.10.2 Possible new inventions
Not available.
10 IDEAS FOR FUTURE DEVELOPMENT
10.1 Forced Demultiplexing
BSC should be able to release CSDAP resources controlled way by demultiplexing the calls from the CSDAP when needed. This would be useful during CSDAP modification operations when CSDAP size is increased or decreased and when CSDAP is detached from BCF object. Current solution is to perform forced release for on ongoing calls that uses the CSDAP.
