OSC - Feature Description PDF

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 166
J.Rämä, T.Räisänen,
J.Saikko, J.Kaasalainen
__________________________________________________________________________________
REQUIREMENTS 2 (166)
SPECIFICATION BSS21309,
BSS30385, BSS30390
Radio Access For Internal Use
CONTENTS
1 INTRODUCTION
1.1 Double Half Rate with SAIC MS
1.1.1 Benefits
1.2 Circuit Switched Dynamic Abis Pool
1.3 Dynamic Soft Channel Capacity
2 DESCRIPTION AND CONCEPTS

2.1 Description of the feature
2.1.1 BSS21309 Double Half Rate with SAIC MS
2.1.2 BSS30385 Circuit Switched Dynamic Abis Pool
2.1.3 BSS30390 Dynamic Soft Channel Capacity
2.2 Abbreviations
2.3 Terms and Concepts
3 REFERENCES
4 PROJECT RELATED INFORMATION

4.1 Risks
4.2 Problems
4.3 Support persons
5 REQUIREMENT LIST
5.1 Accepted Requirements
5.1.1 Double Half Rate with SAIC MS
5.1.2 Circuit Switched Dynamic Abis Pool
5.1.3 Dynamic Soft Channel Capacity
5.2 Postponed or Rejected Requirements
5.3 Function Point Analysis
6 REQUIREMENTS FOR THE FEATURE BSS21309 DOUBLE HALF RATE WITH SAIC
MS 25
6.1 Control of the optionality and licensing
6.1.1 BSS21309-001 Double Half Rate with SAIC MS is optional software
File name: Doc. status: Author: Approved by:

288386244.doc v. 1.1-0 J.Rämä, T.Räisänen, P.Virsu
BSS30385, BSS30390
6.2 General requirements

6.2.1 BSS21309-002 BSC shall accept information of TRX OSC support
6.2.2 BSS21309-003 TRX parameter for OSC support
6.2.3 BSS21309-004 BTS parameter for controlling the use of the feature
6.2.4 BSS21309-056 AMR HR is a prerequisite for Double Half Rate
6.2.5 BSS21309-005 DHR channels in MML printouts
6.2.6 BSS21309-050 OSC limitation in hopping configuration with different TRX HW variants
6.2.7 BSS21309-008 Uplink RX level of neighbouring OSC subchannel
6.2.8 BSS21309-009 Optimized TSC pairs
6.2.9 BSS21309-010 OSC shall be deployed for SAIC capable MS
6.2.10 BSS21309-012 TRX OSC support
6.2.11 BSS21309-013 Rx diversity
6.2.12 BSS21309-014 Double Power TRX and Intelligent Downlink Diversity with OSC
6.2.13 BSS21309-015 Triggering of DHR multiplexing
6.2.14 BSS21309-016 Target TRXs in multiplexing
6.2.15 BSS21309-017 Rx level and power control information update
6.2.16 BSS21309-018 Co-operation with traditional AMR HR packing
6.2.17 BSS21309-019 UL Rx level change rate
6.2.18 BSS21309-020 Target TCH/H for OSC multiplexing
6.2.19 BSS21309-021 Second candidate for multiplexing
6.2.20 BSS21309-022 Selecting the best pair of calls for multiplexing
6.2.21 BSS21309-023 MS power optimization in multiplexing handover
6.2.22 BSS21309-024 BS power control in multiplexing handover
6.2.23 BSS21309-051 Abis resource for OSC-1
6.2.24 BSS21309-025 Dynamic Abis resource
6.2.25 BSS21309-026 OSC channel activation
6.2.26 BSS21309-027 ASSIGNMENT COMMAND for OSC-1
6.2.27 BSS21309-028 DHR multiplexing with a handover to an OSC-1 subchannel UC
6.2.29 BSS21309-030 Handover and power control thresholds for OSC DHR connections
6.2.30 BSS21309-031 Quality threshold to trigger demultiplexing
6.2.31 BSS21309-032 Processing and threshold comparison of OSC DHR connections UL Rx Level
measurements
6.2.32 BSS21309-033 Demultiplexing based on UL Rx Level difference
6.2.33 BSS21309-034 Demultiplexing based on UL Rx Level difference UC
6.2.34 BSS21309-035 Limiting of OSC DHR connection uplink power control
6.2.35 BSS21309-036 UL Rx Level balancing of paired OSC DHR connections UC
6.2.36 BSS21309-037 Downlink power control
6.2.37 BSS21309-057 Configuration limitation with Double Half Rate
6.2.38 BSS21309-053 Channel handling capacity with Double Half Rate
6.2.39 BSS21309-039 No OSC multiplexing for Emergency Calls
6.2.40 BSS21309-040 Pre-emption of DHR calls
6.2.41 BSS21309-041 No OSC multiplexing for DTM calls
6.2.42 BSS21309-042 Blocking of DHR multiplexing due to DHR channel activation failures
6.2.43 BSS21309-043 No EGPRS2 TSL followed by OSC TSL
6.2.44 BSS21309-052 DHR in Resource Availability Measurement
6.2.45 BSS21309-054 Double Half Rate performance
6.3 AMR unpacking optimization

6.3.1 BSS21309-044 Preventing demultiplexing with poor Rx quality
6.3.2 BSS21309-045 Rx level criteria for demultiplexing
6.3.3 BSS21309-055 Connection specific Rx level trigger for demultiplexing
6.4 DFCA requirements

6.4.1 BSS21309-046 TSC selection for a DHR connection in DFCA

BSS30385, BSS30390
6.4.2 BSS21309-047 C/I calculation for a DHR connection in DFCA

6.4.3 BSS21309-048 No SAIC offset for OSC connection
6.4.4 BSS21309-049 Pairing with DFCA
6.5 Postponed or rejected requirements

6.5.1 BSS21309-006 OSC support for Epsilon TRX, POSTPONED
6.5.2 BSS21309-007 Independent DTX control for each OSC subchannel, REJECTED
6.5.3 BSS21309-011 BSC shall allocate AMR HR calls as OSC calls, REJECTED
6.5.4 BSS21309-038 OSC-1 channel release, REJECTED
7 REQUIREMENTS FOR THE FEATURE BSS30385 CIRCUIT SWITCHED DYNAMIC

ABIS POOL
7.1 General CSDAP requirements
7.1.1 BSS30385-001 General CSDAP Requirements
7.1.2 BSS30385-002 CSDAP radio network object
7.1.3 BSS30385-003 Modifications to BCF radio network object
7.1.4 BSS30385-004 Circuit group amount increase
7.2 CSDAP handling

7.2.1 BSS30385-005 CSDAP configuration sending to BTS
7.2.2 BSS30385-006 CSDAP configuration sending to BTS UC
7.2.3 BSS30385-007 CSDAP configuration sending after BCF unlock / BCF reset UC
7.2.4 BSS30385-008 CSDAP creation UC
7.2.5 BSS30385-009 CSDAP size increment UC
7.2.6 BSS30385-010 CSDAP size decrement UC
7.2.7 BSS30385-011 CSDAP attach to BCF object UC
7.2.8 BSS30385-012 CSDAP detach from BCF object UC
7.2.9 BSS30385-013 CSDAP deletion UC
7.3 Resource allocation from CSDAP

7.3.1 BSS30385-014 CSDAP Bit-based hunting
7.3.2 BSS30385-015 BSC hunting capability from CSDAP
7.3.3 BSS30385-016 Resource allocation from CSDAP UC
7.4 Releasing of CSDAP resources

7.4.1 BSS30385-018 Releasing of CSDAP resources
7.4.2 BSS30385-019 Call release for CSDAP call UC 100
7.4.3 BSS30385-020 Intra-cell handover for CSDAP call UC 102
7.4.4 BSS30385-021 Inter-Cell HO for CSDAP call UC 104
7.4.5 BSS30385-022 OSC multiplexing fails, MS stays on old channel UC 106
7.5 CSDAP supervision 108

7.5.1 BSS30385-023 CSDAP failure handling 108
7.5.2 BSS30385-024 CSDAP supervision UC 109
7.5.3 BSS30385-025 Hunting errors in CSDAP UC
7.5.4 BSS30385-026 Circuit Switched Dynamic Abis Pool Failure alarm 113
7.6 Abis loop test for CSDAP circuits 114

7.6.1 BSS30385-027 Abis loop test for CSDAP circuits 114
7.6.2 BSS30385-030 Abis loop test shall be done for each CSDAP attached to BCF during automatic comissioning
test 114
7.6.3 BSS30385-028 Abis loop test for CSDAP circuits UC 115

BSS30385, BSS30390
7.7 Control of the optionality and licensing 119

7.7.1 BSS30385-029 Circuit Switched Dynamic Abis Pool is optional software 119
7.8 Rejected requirements 120

7.8.1 BSS30385-017 CSDAP Resource Allocation Failure alarm (REJECTED) 120
8 REQUIREMENTS FOR THE FEATURE BSS30390 DYNAMIC SOFT CHANNEL

CAPACITY 121
8.1 BSS30390-001 Dynamic Soft Channel Capacity is optional software 121
8.2 BSS30390-002 BSC parameter for dynamic channel capacity 121
8.3 BSS30390-003 TRX parameter for dynamic channel capacity (REJECTED) 122
9 SYSTEM EFFECTS 123

9.1 Feature Management 123
9.1.1 Configuration management 123
9.1.1.1 Parameters 123
9.1.1.1.1 Double Half Rate with SAIC MS 123
9.1.1.1.2 Circuit Swithed Dynamic Abis Pool 127
9.1.1.1.3 Dynamic Soft Channel Capacity 131
9.1.2 Monitoring 132
9.1.2.1 Alarms 132
9.1.2.2 Customer Statistics 133
9.1.2.3 Key performance indicators 143
9.1.2.4 Internal statistics 144
9.1.2.5 System Level Trace 144
9.1.3 Effects on MMI 144
9.1.4 Control of the optionality 146
9.1.4.1 Double Half Rate with SAIC MS 146
9.1.4.2 Circuit Switched Dynamic Abis Pool 147
9.1.4.3 Dynamic Soft Channel Capacity 148
9.2 Effects on interfaces and network elements 149

9.2.1 Abis Telecom interface 149
9.2.1.1 Channel Mode IE 149
9.2.1.2 Channel Number IE 150
9.2.1.3 Channel Identification IE 151
9.2.1.4 CSDAP Circuit IE 151
9.2.1.5 Cause IE 151
9.2.1.6 Supplementary Measurement Information 151
9.2.2 Abis O&M interface 153
9.2.2.1 BTS STATE CHANGED message 153
9.2.2.1.1 OSC Support IE 153
9.2.2.2 BTS CONF DATA message 154
9.2.2.2.1 CSDAP IE 155
9.2.2.2.1.1 CSDAP Parameters IE 155
9.2.2.2.2 OSC Enabled IE 156
9.2.2.3 BTS_TEST_REQ (ABIS_LOOP_TEST) message 156
9.2.2.3.1 CSDAP id 156
9.2.2.4 BTS_TEST_REPORT (ABIS_LOOP_TEST) message 157

BSS30385, BSS30390
9.2.2.5 Ack-Nack 157
9.3 Compatibility 159

9.3.1 Double Half Rate with SAIC MS 159
9.3.2 Circuit Switched Dynamic Abis Pool 159
9.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 161

9.7.1 AMR Half Rate 161
9.7.2 Circuit Switched Dynamic Abis Pool, Packet Abis 161
9.7.3 Rx diversity 161
9.7.4 Emergency calls 161
9.7.5 Dual Transfer Mode 161
9.7.6 AMR Unpacking Optimization 161
9.7.7 Improved AMR packing and unpacking 161
9.7.8 Frequency hopping 162
9.7.9 Dynamic Frequency and Channel Allocation 162
9.7.10 Enhanced Coverage by Frequency Hopping, Intelligent Underlay-Overlay, Handover Support for
Coverage Enhancements 162
9.7.11 Extended Cell Range 162
9.7.12 Wideband AMR 162
9.7.13 Tandem-free Operation 162
9.7.14 UL interference level update procedure 162
9.7.15 Double Power TRX 162
9.7.16 Intelligent Downlink Diversity 162
9.7.17 4-way uplink diversity 163
9.7.18 Soft Channel Capacity 163
9.7.19 Dynamic Soft Channel Capacity 163
9.8 Testing 164

9.8.1 Testing environment 164
9.8.2 Requirements for testing tools 165
9.9 Restrictions 165
9.10 IPR Issues 165

9.10.1 Need for IPR Risk Analysis 165
9.10.2 Possible new inventions 165
10 IDEAS FOR FUTURE DEVELOPMENT 165

10.1 Forced Demultiplexing 165
11 DOCUMENT REVISION HISTORY 166
DOCUMENT STORAGE: 167

BSS30385, BSS30390

BSS30385, BSS30390
1 INTRODUCTION
1.1 Double Half Rate with SAIC MS
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.

BSS30385, BSS30390
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.
1.3 Dynamic Soft Channel Capacity
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.

BSS30385, BSS30390
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.

BSS30385, BSS30390
2 DESCRIPTION AND CONCEPTS
2.1 Description of the feature
2.1.1 BSS21309 Double Half Rate with SAIC MS
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.
(0,1) (1,1)
I
(0,0) (1,0)
Figure 1 Mapping of OSC users to QPSK constellation

BSS30385, BSS30390
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.

BSS30385, BSS30390
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.
2.1.3 BSS30390 Dynamic Soft Channel Capacity
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.

BSS30385, BSS30390
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.

BSS30385, BSS30390
2.2 Abbreviations
CSDAP Circuit Switched Dynamic Abis Pool
DFR Double Full Rate
DHR Double Half Rate
MU-MIMO Multi User Multiple Inputs Multiple Outputs
MUD Multi User Detection
OSC Orthogonal Sub Channel
QPSK Quaternary Phase Shift Keying
SAIC Single Antenna Interference Cancellation
TSC Training Sequence Code
VAMOS Voice services over Adaptive Multi-user Orthogonal Sub channels
2.3 Terms and Concepts
Double Full Rate Full rate traffic channel shared by two AMR FR calls applying
OSC
Double Half Rate Half rate traffic channel shared by two AMR HR calls
applying OSC
Epsilon First generation TRX HW of Flexi EDGE BTS
Odessa Second generation TRX HW of Flexi EDGE BTS
OSC-0 OSC-0 is DHR (or DFR) channel using legacy TSC and
legacy fixed Abis transmission
OSC-1 OSC-1 is DHR (or DFR) channel using additional TSC and
additional Abis transmission

BSS30385, BSS30390
3 REFERENCES
Public references:
/1/ 3GPP TS 48.058 Base Station Controller - Base Transceiver Station (BSC
- BTS) interface; Layer 3 specification (Release 8)
/2/ 3GPP TS 44.018 Mobile radio interface layer 3 specification; Radio

Resource Control (RRC) protocol (Release 8)
/3/ 3GPP TS 24.008 Mobile radio interface Layer 3 specification; Core

network protocols; Stage 3 (Release 8)
/4/ Doubling GSM Voice Capacity with the Orthogonal Sub Channel,
Technology Brief, Nokia Siemens Networks
Internal references:
/A/ Orthogonal Subchannel (OSC) BSS21309, System Feature Specification,

T.Virtanen & T.Räisänen, 1.0.0, 15.9.2008
/B/ Packet Abis Operability BSS21231_C, System Feature Specification,

T.Muikku, 1.1.0, 15.1.2009
/C/ AMR Unpacking Optimization BSS21120, Requirements Specification,

V.Tiihonen, 1.0.0, 28.11.2007
/D/ Abis Telecom Interface Specification, layer 3, S14
/E/ ABIS O&M INTERFACE SPECIFICATION, BSS14 interface specification
/F/ 31038 Hunting of Bit Based Circuits, Feature implementation specification,

Jyri Peltonen, Edition 1, 27.04.2000, (DXSYDE 31038)
/G/ EGPRS2 BSS21298, SS21299, BSS21358, BSS21359, Requirements

Specification, Huovila, Räty, Saarinen, Taponen, Valo, 0.0.13, 12.2.2009
/H/ OSC Support for Epsilon TRX of FlexiBTS, BSS Change Request CR010
BSS15, H.Hirvonen, 1.0, 20.1.2009
/I/ Improved AMR packing and unpacking BSS21483, BSC Change Request
EDS13_011, V.Ahonen, 7.1.2009

BSS30385, BSS30390
4 PROJECT RELATED INFORMATION
4.1 Risks
No identified risks.
# Risk Preventive action Probabilit Impact LE/Closed/Tran

y sfered
- - - - - -
4.2 Problems
# Problem Action Impact LE/Closed/Transfe

red
1 Epsilon TRX support is The Epsilon support related minor Actions according
included in the RS but the requirement BSS21309-006 has to BSS CR
related BSS15 CR /H/ has not been listed in the postponed approval.
been approved yet. requirements, RS shall be updated
according to the CR decision once
that takes place.
4.3 Support persons
Support person Role / Supported topic

Rade Luburic Flexi EDGE BTS
Kari Niemelä Product Management
Tapani Virtanen SFS author
Harri Tervonen RS support person, O&M
Hannu Makkonen RS support person, statistics
Outi Rissanen RS support person, L3 signalling
Erkki Castren IS co-author, Wipro
Timo Latva-Aro IS co-author, Wipro
Mikko Hietaoja IS co-author, Wipro

BSS30385, BSS30390
5 REQUIREMENT LIST
5.1 Accepted Requirements
Le- I&V Req id Req name Prio Ty- Domain Comments

vel -rity pe
1 BSS21309-001 Double Half Rate with BC F O&M,

SAIC MS is optional telecom
software
1 X BSS21309-002 BSC shall accept E F O&M

information of TRX
OSC support
1 X BSS21309-003 TRX parameter for E F O&M

OSC support
1 X BSS21309-004 BTS parameter for E F O&M,

controlling the use of telecom
the feature
1 X BSS21309-005 DHR channels in MML I F O&M

printouts
1 X BSS21309-008 Uplink RX level of E F telecom

neighbouring OSC
subchannel
1 X BSS21309-009 Optimized TSC pairs E F telecom
1 X BSS21309-010 OSC shall be deployed E F telecom

for SAIC capable MS
1 X BSS21309-012 TRX OSC support E F telecom
1 X BSS21309-013 Rx diversity E F O&M
1 X BSS21309-014 Double Power TRX and E F telecom

Intelligent Downlink
Diversity with OSC
1 X BSS21309-015 Triggering of DHR E F telecom

multiplexing
1 X BSS21309-016 Target TRXs in E F telecom

multiplexing
1 X BSS21309-017 Rx level and power E F telecom

control information
update

BSS30385, BSS30390
1 X BSS21309-018 Co-operation with E F telecom

traditional AMR HR
packing
1 X BSS21309-019 UL Rx level change rate E F telecom
1 X BSS21309-020 Target TCH/H for OSC E F telecom

multiplexing
1 X BSS21309-021 Second candidate for E F telecom

multiplexing
1 X BSS21309-022 Selecting the best pair E F telecom

of calls for multiplexing
1 X BSS21309-023 MS power optimization E F telecom

in multiplexing
handover
1 X BSS21309-024 BS power control in E F telecom

multiplexing handover
1 X BSS21309-025 Dynamic Abis resource E F telecom
1 X BSS21309-026 OSC channel activation E F telecom
1 X BSS21309-027 ASSIGNMENT E F telecom

COMMAND for OSC-1
1 X BSS21309-028 DHR multiplexing with a E UC telecom

handover to an OSC-1
subchannel UC
1 X BSS21309-029 DHR multiplexing with a E UC telecom

handover to an OSC-0
subchannel UC
1 X BSS21309-030 Handover and power E F telecom

control thresholds for
OSC DHR connections
1 X BSS21309-031 Quality threshold to E F telecom

trigger demultiplexing
1 X BSS21309-032 Processing and E F telecom

threshold comparison of
OSC DHR connections
UL Rx Level
measurements
1 X BSS21309-033 Demultiplexing based E F telecom

on UL Rx Level
difference

BSS30385, BSS30390
1 X BSS21309-034 Demultiplexing based E UC telecom

on UL Rx Level
difference UC
1 X BSS21309-035 Limiting of OSC DHR E F telecom

connection uplink power
control
1 X BSS21309-036 UL Rx Level balancing E UC telecom

of paired OSC DHR
connections UC
1 X BSS21309-037 Downlink power control E F telecom
1 BSS21309-039 No OSC multiplexing I F telecom

for Emergency Calls
1 X BSS21309-040 Pre-emption of DHR I F telecom

calls
1 BSS21309-041 No OSC multiplexing I F telecom

for DTM calls
1 X BSS21309-042 Blocking of DHR I F telecom

multiplexing due to
DHR channel activation
failures
1 X BSS21309-043 No EGPRS2 TSL E F telecom

followed by OSC TSL
1 X BSS21309-044 Preventing I F telecom

demultiplexing with
poor Rx quality
1 X BSS21309-045 Rx level criteria for I F telecom

demultiplexing
1 X BSS21309-046 TSC selection for a I F telecom

DHR connection in
DFCA
1 X BSS21309-047 C/I calculation for a I F telecom

DHR connection in
DFCA
1 X BSS21309-048 No SAIC offset for OSC I F telecom

connection
1 X BSS21309-049 Pairing with DFCA I F telecom
1 X BSS21309-050 OSC limitation in E F telecom

hopping configuration
with different TRX HW

BSS30385, BSS30390
variants
1 X BSS21309-051 Abis resource for OSC- I F telecom

1
1 BSS21309-052 DHR in Resource I F telecom

Availability
Measurement
1 X BSS21309-053 Channel handling I F telecom

capacity with Double
Half Rate
1 X BSS21309-054 Double Half Rate E P telecom

performance
1 X BSS21309-055 Connection specific Rx I F telecom

level trigger for
demultiplexing
1 X BSS21309-056 AMR HR is a I F O&M

prerequisite for Double
Half Rate
1 X BSS21309-057 Configuration limitation E F O&M

with Double Half Rate

vel -rity pe
1 x BSS30385-001 General CSDAP BC F O&M, SFS: BSS21309-008

Requirements telecom
1 BSS30385-002 CSDAP radio network E T O&M

object
1 BSS30385-003 Modifications to BCF E T O&M

radio network object
1 BSS30385-004 Circuit group amount E T DX

increase platform
1 BSS30385-005 CSDAP Configuration E F O&M, SFS: BSS21309-009

sending to BTS telecom
1 x BSS30385-006 CSDAP configuration E F O&M

sending to BTS UC

BSS30385, BSS30390
1 x BSS30385-007 CSDAP configuration E UC O&M,

sending after BCF telecom
unlock / BCF reset UC
1 x BSS30385-008 CSDAP creation UC E UC O&M, SFS: BSS21309-010

telecom
1 x BSS30385-009 CSDAP size increment E UC O&M, SFS: BSS21309-011

UC telecom
1 x BSS30385-010 CSDAP size decrement E UC O&M, SFS: BSS21309-012

UC telecom
1 x BSS30385-011 CSDAP attach to BCF E UC O&M, SFS: BSS21309-013

object UC telecom
1 x BSS30385-012 CSDAP detach from E UC O&M, SFS: BSS21309-014

BCF object UC telecom
1 x BSS30385-013 CSDAP deletion UC E UC O&M, SFS: BSS21309-015

telecom
1 BSS30385-014 CSDAP Bit-based E T telecom SFS: BSS21309-016

hunting
1 x BSS30385-015 BSC hunting capability E T telecom SFS: BSS21309-017

from CSDAP
1 x BSS30385-016 Resource allocation E UC telecom SFS: BSS21309-018

from CSDAP UC
1 BSS30385-018 Releasing of CSDAP E F telecom SFS: BSS21309-027,

resources SFS: BSS21309-031,
SFS: BSS21309-032
1 x BSS30385-019 Call release for CSDAP E UC telecom SFS: BSS21309-031

call UC
1 x BSS30385-020 Intra-cell handover for E UC telecom SFS: BSS21309-027

CSDAP call UC
1 x BSS30385-021 Inter-cell handover for E UC telecom SFS: BSS21309-032

CSDAP call UC
1 x BSS30385-022 OSC multiplexing fails, E UC telecom

MS stays on old
channel UC
1 BSS30385-023 CSDAP supervision E F telecom SFS: BSS21309-020
1 x BSS30385-024 CSDAP supervision UC E UC telecom SFS: BSS21309-020
1 x BSS30385-025 Hunting errors in E UC telecom

CSDAP UC

BSS30385, BSS30390
1 x BSS30385-026 Circuit Switched E F telecom SFS: BSS21309-020

Dynamic Abis Pool
Failure alarm
1 x BSS30385-027 Abis loop test for E F O&M, SFS:BSS21309-021

CSDAP circuits telecom
1 x BSS30385-028 Abis loop test for E UC O&M, SFS: BSS21309-022

CSDAP circuits UC telecom
1 x BSS30385-029 Circuit Switched E BC O&M,

Dynamic Abis Pool is telecom
optional software
1 x BSS30385-030 Abis loop test shall be E F O&M

done for each CSDAP
attached to BCF during
automatic comissioning
test

vel -rity pe
1 X BSS30390-001 Dynamic Soft Channel BC F O&M,

Capacity is optional telecom
software
1 X BSS30390-002 BSC parameter for E F O&M,

dynamic channel telecom
capacity
Priority:
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 case
F Functional requirement
P Performance requirement
T Technical requirement

BSS30385, BSS30390
5.2 Postponed or Rejected Requirements

vel -rity pe
1 X BSS21309-006 OSC support for E F O&M, POSTPONED due to the

Epsilon TRX telecom pending approval of the
related BSS15 CR /H/
1 BSS21309-007 Independent DTX I T telecom This is no actual requirement

control for each OSC for the BSC and is removed
subchannel to avoid confusion
1 x BSS21309-011 BSC shall allocate AMR I F telecom OSC indication for an AMR
HR calls as OSC calls 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 I F telecom SFS: BSS21309-018

Allocation Failure alarm
Circuit Switched Dynamic
Abis Pool Failure alarm
can offer needed
information.
1 X BSS30390-003 TRX parameter for E F O&M, Removed with the changed

dynamic channel telecom licencing principles according
to finding in first review
capacity
5.3 Function Point Analysis
Function Point Analysis to be made and updated here after the approval of the RS.
Link to CosmicET file to be added.

BSS30385, BSS30390
6 REQUIREMENTS FOR THE FEATURE BSS21309 DOUBLE HALF RATE WITH SAIC MS
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.
Rationale:
BSC must know the OSC capability of a TRX when selecting TCH resources for OSC
usage.
Source: SFS:BSS21309-006

BSS30385, BSS30390
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.
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:

BSS30385, BSS30390
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

BSS30385, BSS30390
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.
Source: BTS team
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

BSS30385, BSS30390
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.
6.2.8 BSS21309-009 Optimized TSC pairs
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

BSS30385, BSS30390
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.

BSS30385, BSS30390
TS 0 1 2 3 4 5 6 7
C
0 - Yes Yes Yes
1 - Yes Yes Yes
2 Yes Yes - Yes
3 Yes Yes - Yes
4 Yes - Yes
5 Yes - Yes
6 Yes Yes -
7 Yes Yes -
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
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.
6.2.10 BSS21309-012 TRX OSC support
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.

BSS30385, BSS30390
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.
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”.

BSS30385, BSS30390
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
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
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.

BSS30385, BSS30390
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
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.
Rationale:
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
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.

BSS30385, BSS30390
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.
Source: RS team
6.2.17 BSS21309-019 UL Rx level change rate
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.
RX _ LEVEL _ change 
 RX _ LEVELnew  POWER _ REDUCTION new   [1]
 RX _ LEVELold  POWER _ REDUCTION old 
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

BSS30385, BSS30390
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
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

BSS30385, BSS30390
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.
RX _ LEVEL _ MIN sec ond 

[2]
CURRENT _ RX _ LEVEL first  MultiplexingULRxLevelWindow
RX _ LEVEL _ MAX sec ond 

CURRENT _ RX _ LEVEL first  [3]
POWER _ reduction max sec ond  MultiplexingULRxLevelWindow
POWER_reductionmaxsecond is the maximum possible uplink power reduction of the

second multiplexing candidate and is defined with the following two equations:
  RXLEV max_UL 
RXLEV _ reduction maxUL  max 0, 
 PCLowerTresholdLevUL  SafetyMargin
[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.

BSS30385, BSS30390
POWER _ reduction maxUL 

 0,  min MsTxPwrMax, MsPowerClass  MsTxPwrMin, [5]
min 
 RXLEV _ reduction maxUL 
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:
RX _ LEVEL _ TARGETsec ond 

[6]
CURRENT _ RX _ LEVEL first  POWER _ REDUCTION first
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:

BSS30385, BSS30390
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
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.
Rationale:
Pairing decision takes into account the current circumstances but also a prediction of
the near future.
Source: RS team
Linked requirements: BSS21309-019, BSS21309-020, BSS21309-021
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.

BSS30385, BSS30390
- 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:

BSS30385, BSS30390
NEW _ POWER _ REDUCTION sec ond 

MIN ( MAX (0, ( BS _ TXPWR first  BsTxPwrMax first )  3dB), [7]
MAX (0, RXLEV _ DLsec ond  ( BS _ TXPWRsec ond  BsTxPwrMaxsec ond )  RXLEV _ DL first  3dB))
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
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/.
Rationale:
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

BSS30385, BSS30390
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
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.

BSS30385, BSS30390
- 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
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

BSS30385, BSS30390
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.
Main Success Scenario:
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

BSS30385, BSS30390
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.
9. 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
- OSC-1 specific channel number in the Channel Number IE
- OSC-1 specific Training Sequence Code in the Channel

Identification IE
- CSDAP resource in the new CSDAP Circuit IE.
10. BTS sends Channel Activation acknowledgement message.
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.

BSS30385, BSS30390
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.
Step 5:
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

BSS30385, BSS30390
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.
Timing and Performance:
BSS21309-004, BSS21309-009, BSS21309-010, BSS21309-012,

BSS21309-015, BSS21309-016, BSS21309-017, BSS21309-018,
BSS21309-019, BSS21309-020, BSS21309-021, BSS21309-022,
BSS21309-025, BSS21309-051, BSS21309-026, BSS21309-027
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

BSS30385, BSS30390
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.
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.

BSS30385, BSS30390
5. BTS sends Channel Activation acknowledgement message.
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
Step 0:
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.
All the time when load exceeds load limit for DHR multiplexing.

BSS30385, BSS30390
BSS21309-004, BSS21309-009, BSS21309-010, BSS21309-012,

BSS21309-015, BSS21309-016, BSS21309-017, BSS21309-018,
BSS21309-019, BSS21309-020, BSS21309-021, BSS21309-022,
BSS21309-025, BSS21309-051, BSS21309-026, BSS21309-027
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
- Threshold Dl Rx Qual DHR,
- Threshold Ul Rx Qual DHR.
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.
Rationale:
OSC specific Rx Quality thresholds are needed to provide independent

handover and power control for OSC DHR connections.
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

BSS30385, BSS30390
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
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

BSS30385, BSS30390
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.
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

BSS30385, BSS30390
itself, it is safe to direct the demultiplexing handover into a TCH/H as a normal

AMR HR connection.
Linked Requirements: BSS21309-008
6.2.33 BSS21309-034 Demultiplexing based on UL Rx Level difference UC
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.
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:

BSS30385, BSS30390
IF:
AV_RXLEV_UL_HO(dhr_call) > AV_RXLEV_UL_HO(paired_dhr_call)
AND
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.
Everytime when UL Rx Level difference between paired OSC DHR

connections equals to or exceeds the OSC Demultiplexing Ul Rx Level Margin
parameter.
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.

BSS30385, BSS30390
6.2.35 BSS21309-036 UL Rx Level balancing of paired OSC DHR connections UC
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.
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

BSS30385, BSS30390
AND
RXLEV_UL(dhr_call) – PowRedStepSize > PcLowerThresholdsLevUL + 6dB
THEN:
PWR_RED_STEP = PowRedStepSize
ELSE IF:
AV_RXLEV_UL_PC(paired_dhr_call) – AV_RXLEV_UL_PC(dhr_call) >=
OSC Multiplexing Ul Rx Level Window
AND
RXLEV_UL(dhr_call) + PowIncrStepSize < PcUpperThresholdsLevUL
THEN:
PWR_INCR_STEP = PowIncrStepSize
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.
Everytime when UL Rx Level difference between paired OSC DHR

connections equals to or exceeds the OSC Multiplexing Ul Rx Level Window
parameter.
Linked requirements: BSS21309-008, BSS21309-032, BSS21309-035

BSS30385, BSS30390
6.2.36 BSS21309-037 Downlink power control
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

BSS30385, BSS30390
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 Max configured TCH

count per BCSU count per BCSU with
without SCC (max SCC (max active)
active)
Full Rate 4000 (4000) 4000 (4000)
Half Rate 4000 (4000) 8000 (4000)
Double Half Rate 5312 (4000) 16000 (4000)
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.
Rationale:
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

BSS30385, BSS30390
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
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.
6.2.40 BSS21309-040 Pre-emption of DHR calls
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.

BSS30385, BSS30390
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
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

BSS30385, BSS30390
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
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

BSS30385, BSS30390
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.
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

BSS30385, BSS30390
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
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.
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

BSS30385, BSS30390
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

BSS30385, BSS30390
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
 if the first connection uses TSC 4 then BSC shall select TSC 3 or 6 for the
second OSC connection.
Rationale:
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
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.

BSS30385, BSS30390
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
6.4.3 BSS21309-048 No SAIC offset for OSC connection
SAIC DL C/I offset shall not be used for OSC connections.
Rationale:
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
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

BSS30385, BSS30390
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
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/.

BSS30385, BSS30390
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.
Source: RS team, CR010 BSS15 /H/
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.
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:

BSS30385, BSS30390
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.
Source: RS team
6.5.4 BSS21309-038 OSC-1 channel release, REJECTED
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.
Source: SFS:BSS21309-031, SFS:BSS21309-032

BSS30385, BSS30390
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.

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.

BSS30385, BSS30390
7.1.2 BSS30385-002 CSDAP radio network object
Description:
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.

BSS30385, BSS30390
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.

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.

BSS30385, BSS30390
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
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.

BSS30385, BSS30390
7.1.4 BSS30385-004 Circuit group amount increase
Description:
Amount of circuit groups shall be increased
 BSC (M92): 1024 (400H) -> 1536 (600H)
 BSC3i (M98): 3072 (C00H) -> 3584 (E00H)
 Flexi BSC: 3072 (C00H) -> 3584 (E00H)
Next files are effected:

 SWOCGRGM 0320005H
 CMECGRGX 0600000H
 CGNAMEGM 0770005H
Source: Internal
Rationale:
There are not enough circuit groups in BSC when maximum amount of legacy DAPs
and CSDAPs is created.
First circuit group number for DAP and CSDAP is 500.

Maximum amount of DAPs is 1800. (dap_id_t_max_c = 1800)
Maximum amount of CSDAPs is 1000.
500 + 1800 + 1000 = 3300

BSS30385, BSS30390
7.2 CSDAP handling
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.
Rationale:

BSS30385, BSS30390
7.2.2 BSS30385-006 CSDAP configuration sending to BTS UC
Source: BSS21309-009
Context of Use: CSDAP configuration is sent to BTS.
Scope: BSC
Level: User-goal
Actors: Operator, BSC, BTS
Precondition: CSDAP exist.
Minimum Guarantees:
CSDAP information sending fails. All CSDAPs are out of use.
Success Guarantees:
CSDAP information is sent to BTS. All CSDAPs attached to BCF are

working.
Trigger:
Any of the next operations:
 BCF is unlocked
 BCF reset
1. BSC shall send BTS_CONF_DATA message to BTS containing

information of all CSDAPs attached to BCF.
2. When BTS receives BTS_CONF_DATA message containing information

about CSDAP(s) it shall check
a. whether Abis IF(s) are available
b. whether CSDAP timeslots are within in allowed E1/T1 bounds

BSS30385, BSS30390
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

BSS30385, BSS30390
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.
Everytime when:
 BCF is unlocked
 BCF reset
BSS30385-007, BSS30385-009, BSS30385-010, BSS30385-011, BSS30385-012

BSS30385, BSS30390
7.2.3 BSS30385-007 CSDAP configuration sending after BCF unlock / BCF reset UC
Source: Internal
Context of Use: CSDAP configuration is sent to BTS after BCF unlock / BCF reset.
Scope: BSC
Level: User-goal
Precondition: BCF locked. CSDAPs have been attached to BCF.
Minimum Guarantees:
BCF unlock fails. / BCF reset fails.
Success Guarantees:
BCF unlock success. / BCF reset success.
Trigger:
Operator unlocks BCF. / BCF is reset.
1. Operator unlocks BCF. / BCF is reset.
2. BSC shall send CSDAP configuration to BTS.
3. BSC informs operator about the procedure completion in execution

printout.
Exceptions:
BCF is left to LOCKED state. BSC shall inform operator about the failure in
execution printout.
Everytime when BCF is unlocked / BCF is reset.

BSS30385, BSS30390
7.2.4 BSS30385-008 CSDAP creation UC
Context of Use: CSDAP pool is created to BSC.
Scope: BSC
Level: User-goal
Actors: Operator, BSC
Precondition: Abis ETPCM has been created between BSC and BCF. CSDAP ID
does not exist in BSC.
Minimum Guarantees:
CSDAP creation fails.
Success Guarantees:
CSDAP pool is created successfully to BSC.
Trigger: Operator request BSC to create a new CSDAP pool
1. Operator requests BSC to create CSDAP via MML or NetAct. Operator

shall enter following parameters in the command:
 CSDAP ID
 Abis ETPCM
 First Timeslot
 Last Timeslot (or pool size)
 BCF Abis IF
 BCF Timeslot Shift
2. BSC shall check that CSDAP does not already exist and the command
parameters are acceptable.
3. BSC shall add physical Abis ETPCM timeslots to circuit group called
ETPCM.
4. BSC shall create own SPE-BB circuit group for the CSDAP called
CDAPxxxx, where xxxx indicates CSDAP ID. BSC shall add virtual

BSS30385, BSS30390
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.
When OSC DHR feature is taken into use in BCF or, when more CSDAP
capacity is needed for OSC calls to BCF.

BSS30385, BSS30390
7.2.5 BSS30385-009 CSDAP size increment UC
Context of Use: Size of CSDAP is increased
Scope: BSC
Level: User-goal
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.
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).

BSS30385, BSS30390
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.
11. BSC shall cancel the penalty from the CSDAP after the procedure is
successfully completed.
printout.
Exceptions:
Step 3. Operator does not accept the operation.
Command excution is cancelled.
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.

BSS30385, BSS30390
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.
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.
When more CSDAP capacity is needed for OSC calls to BCF.

BSS30385, BSS30390
7.2.6 BSS30385-010 CSDAP size decrement UC
Context of Use: Size of CSDAP is decreased.
Scope: BSC
Level: User-goal
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.
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

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.
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).

BSS30385, BSS30390
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
10. BSC shall cancel the penalty from the CSDAP after the procedure is
successfully completed.
printout.
Exceptions:
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

BSS30385, BSS30390
CSDAP and then BSC shall inform operator about the failure in execution
printout.
If BSC receives negative acknowledgement from BTS then the BSC shall
inform operator about the failure in execution printout.
When Abis timeslots are taken to some other use in Abis ETPCM.

BSS30385, BSS30390
7.2.7 BSS30385-011 CSDAP attach to BCF object UC
Context of Use: CSDAP is attached to BCF.
Scope: BSC
Level: User-goal
Precondition: CSDAP has been created to Abis ETPCM. CSDAP has not been
attached to any BCF.
Minimum Guarantees:
CSDAP attachment to BCF fails.
Success Guarantees:
CSDAP is attached to BCF successfully.
Trigger: Operator attaches the CSDAP(s) to the BCF.
1. Operator shall configure Abis transmisson to BCF for the new CSDAP
before attaching CSDAP to BCF in BSC.
2. Operator requests BSC to attach CSDAP(s) to BCF via MML or NetAct.

Operator shall enter the following parameters in the command:
 BCF id
 [Attached CSDAP 1], [Attached CSDAP 2], [Attached CSDAP 3],

[Attached CSDAP 4]
3. BSC shall check that the CSDAP(s) exist and it has not been attached to
any BCF.
4. BSC shall attach the CSDAP(s) to BCF in radio network configuration

database.

printout.
7. CSDAP(s) are ready for use and BSC can start hunting resources.

BSS30385, BSS30390
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.
BSC shall reject the CSDAP attachment if the radio network configuration
database update fails. BSC shall inform operator about the failure in
execution printout.
If BSC receives negative acknowledgement from BTS, BSC shall remove

CSDAP attachment from BCF and shall inform operator about the failure in
execution printout.
When OSC DHR feature is taken into use in BCF or, when more
CSDAP capacity is needed for OSC calls to BCF.

BSS30385, BSS30390
7.2.8 BSS30385-012 CSDAP detach from BCF object UC
Context of Use: CSDAP is detached from BCF
Scope: BSC
Level: User-goal
Precondition: CSDAP has been attached to BCF.
Minimum Guarantees:
CSDAP is not detached from BCF.
Success Guarantees:
CSDAP is detached from BCF.
Trigger: Operator detaches CSDAP(s) from BCF.
1. Operator requests BSC to detach CSDAP(s) from BCF via MML or

NetAct. Operator shall enter the following parameters in the command:
 BCF id
 [Attached CSDAP 1], [Attached CSDAP 2], [Attached CSDAP 3],

[Attached CSDAP 4]

using the detached CSDAP during the procedure.
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
6. BSC cancels the CSDAP penalty.

BSS30385, BSS30390

printout.
Exceptions:
BSC shall reject the CSDAP detach if the radio network configuration
database update fails. BSC shall inform operator about the failure in
execution printout.
If BSC receives negative acknowledgement from BTS then the BSC shall
inform operator about the failure in execution printout.
When using of OSC DHR feature stopped on BCF or when CSDAP

capacity is reduced on BCF.

BSS30385, BSS30390
7.2.9 BSS30385-013 CSDAP deletion UC
Context of Use: CSDAP is deleted
Scope: BSC
Level: User-goal
Actors: Operator, BSC
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.
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
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.

printout.

BSS30385, BSS30390
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.
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.
When using of OSC DHR feature stopped on BCF or when CSDAP

capacity is reduced on BCF.

BSS30385, BSS30390
7.3 Resource allocation from CSDAP
7.3.1 BSS30385-014 CSDAP Bit-based hunting
Description:
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.

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.

BSS30385, BSS30390
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.
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.

BSS30385, BSS30390
7.3.3 BSS30385-016 Resource allocation from CSDAP UC
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.
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.

BSS30385, BSS30390
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
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

BSS30385, BSS30390
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.
Everytime when OSC DHR multiplexing triggers.
Check BSS30385-015 BSC hunting capability from CSDAP.

BSS30385, BSS30390
7.4 Releasing of CSDAP resources
7.4.1 BSS30385-018 Releasing of CSDAP resources
Description:
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.
Source: SFS: BSS21309-027, SFS: BSS21309-031, SFS: BSS21309-032
Rationale:
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.

REQUIREMENTS 100
SPECIFICATION BSS21309, (166)
BSS30385, BSS30390
7.4.2 BSS30385-019 Call release for CSDAP call UC
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.
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.

REQUIREMENTS 101
BSS30385, BSS30390
Exceptions:
Step 6. The timer supervising the RF CHANNEL RELEASE

ACKNOWLEDGE message expires.
BSC shall release the connection from the Abis-interface (CSDAP) circuit.
Step 6. Abis-interface (CSDAP) connection has not been released within

time set for the time supervised connection
BSC releases the connection from the Abis-interface (CSDAP) circuit.
Everytime when OSC-1 DHR call is released.

REQUIREMENTS 102
BSS30385, BSS30390
7.4.3 BSS30385-020 Intra-cell handover for CSDAP call UC
Context of Use: Releasing of CSDAP resources after demulplexing of OSC-1 DHR

call.
Scope: BSC
Level: User-goal
Minimum Guarantees:
Success Guarantees:
Trigger: OSC-1 DHR call is demultiplexed.
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

REQUIREMENTS 103
BSS30385, BSS30390
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.

message from BTS it shall release the connection from the source
Abis (CSDAP) circuit.
Exceptions:
Step 8. The timer supervising RF CHANNEL RELEASE ACKNOWLEDGE

message expires.
BSC shall release the connection from the source Abis-interface (CSDAP)
circuit.
Step 8. Source Abis-interface (CSDAP) connection has not been released

within time set for the time supervised connection
BSC releases the connection from the source Abis-interface (CSDAP)

circuit.
Everytime when OSC-1 DHR call is demultiplexed.

REQUIREMENTS 104
BSS30385, BSS30390
7.4.4 BSS30385-021 Inter-Cell HO for CSDAP call UC
Context of Use: Releasing of CSDAP resources after inter-cell handover of OSC-1

DHR call.
Scope: BSC
Level: User-goal
Minimum Guarantees:
Success Guarantees:
Trigger: OSC-1 DHR call is handed over to another cell.
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

REQUIREMENTS 105
BSS30385, BSS30390
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.)

message.

message from BTS it shall release the connection from the source
Abis (CSDAP) circuit.
Exceptions:

message expires.
BSC shall release the connection from the source Abis-interface (CSDAP)
circuit.

BSC releases the connection from the source Abis-interface (CSDAP)

circuit.
Everytime when inter-cell handover is made for OSC-1 DHR call.

REQUIREMENTS 106
BSS30385, BSS30390
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
Precondition: One or several CSDAP have been attached to BCF. OSC DHR is
active in cell.
Minimum Guarantees:
Success Guarantees:
Trigger: OSC-1 DHR multilplexing fails.
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.)

REQUIREMENTS 107
BSS30385, BSS30390

message.

message from BTS it shall release the connection from the target Abis
(CSDAP) circuit.
Exceptions:
Step 4. Mobile can not reach target channel at all.
BSC does not make two-way connection to the target Abis-interface

(CSDAP) circuit.

message expires.
BSC shall release the connection from the target Abis-interface (CSDAP)
circuit.

BSC releases the connection from the target Abis-interface (CSDAP)

circuit.
Everytime OSC DHR multiplexing fails and MS returns back to old

channel.

REQUIREMENTS 108
BSS30385, BSS30390
7.5 CSDAP supervision
7.5.1 BSS30385-023 CSDAP failure handling
Description:
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.
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.

REQUIREMENTS 109
BSS30385, BSS30390
7.5.2 BSS30385-024 CSDAP supervision UC
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.
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.

REQUIREMENTS 110
BSS30385, BSS30390
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.
Everytime when point to point error is encountered on call allocated from

CSDAP.

REQUIREMENTS 111
BSS30385, BSS30390
7.5.3 BSS30385-025 Hunting errors in CSDAP UC
Source: Internal
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.
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.

REQUIREMENTS 112
BSS30385, BSS30390
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.
Everytime when consecutive hunting errors are encountered on CSDAP.

REQUIREMENTS 113
BSS30385, BSS30390
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.
Rationale:
Operator is able to detect malfunction on a single CSDAP.

REQUIREMENTS 114
BSS30385, BSS30390
7.6 Abis loop test for CSDAP circuits
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).
Rationale:
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.

REQUIREMENTS 115
BSS30385, BSS30390
7.6.3 BSS30385-028 Abis loop test for CSDAP circuits UC
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.
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:
 BTS number | BTS name
 TRX number
 radio time slot
 select Abis connection = dynamic
 CSDAP ID (1..1000)
 Abis time slot (E1 0...31, T1 1…24)
 sub time slot (0...3)
 looping time

REQUIREMENTS 116
BSS30385, BSS30390
3. BSC shall check that
 CSDAP exists
 CSDAP has been attached to BCF where the TRX situates.
 the circuits to be tested are part of the CSDAP.
4. BSC shall change the state of the CSDAP timeslots to be tested from
WO to BA.
5. BSC shall ensure that the circuits to be tested are free by searching
timeslots from the call connection table.
6. BSC shall make loop connection for the CSDAP circuit
7. BSC shall send BTS_TEST_REQ (ABIS_LOOP_TEST) message to

BTS where CSDAP identity and CSDAP timeslots are indicated.
8. When BTS receives BTS_TEST_REQ(ABIS_LOOP_TEST) it checks
 that it has information about the CSDAP
 the circuits under the test belongs to CSDAP
9. BTS sends BTS ACK message as an acknowledgement to BSC.

BSC sends acknowledgement to the operator about the started test.
10. BTS starts Abis loop test.
11. BTS sends BTS_TEST_REPORT (ABIS_LOOP_TEST) when Abis

loop test is completed.
12. BSC shall send BTS ACK message as an acknowledgement to BTS.
13. BSC shall clear loop connection from the CSDAP circuit.
14. BSC shall change the state of the tested CSDAP timeslots from BA
to WO.
Exceptions:
BSC rejects the test request if
 the CSDAP does not exist
 the CSDAP has not been attached to BCF

REQUIREMENTS 117
BSS30385, BSS30390
 the circuits to be tested does not belong to CSDAP
BSC shall indicate failure situation to operator in execution printout.
Step 4. Error in timeslot state change:
BSC shall reject the test request if the changing state of the circuits fails.
Step 5. Timeslots are busy:
BSC shall reject the test request if the circuits to be tested are reserved
for call. BSC changes state of the circuits from BA to WO.
Step 6. Loop connection failure:
BSC shall reject the test request if loop connection fails. State of the
circuits is changed from BA to WO.
BTS rejects the test request if
 it does not recognize the CSDAP

(N_CSDAP_RESOURCE_UNAVAILABLE)
 the circuits does not belong to the CSDAP

(N_CSDAP_RESOURCE_UNAVAILABLE)
Loop connection is released and state of the circuits is changed from BA

to WO.
Everytime when a new CSDAP is taken into use in BCF.

REQUIREMENTS 118
BSS30385, BSS30390

REQUIREMENTS 119
BSS30385, BSS30390
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.
Source: SFS

REQUIREMENTS 120
BSS30385, BSS30390
7.8 Rejected requirements
7.8.1 BSS30385-017 CSDAP Resource Allocation Failure alarm (REJECTED)
Description:
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
Rationale:
Operator is able to detect lack of CSDAP resources attached to the BCF / (BTS).

REQUIREMENTS 121
BSS30385, BSS30390
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.
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.

REQUIREMENTS 122
BSS30385, BSS30390
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.

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.
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.

REQUIREMENTS 123
BSS30385, BSS30390
9 SYSTEM EFFECTS
9.1 Feature Management
9.1.1 Configuration management
9.1.1.1 Parameters
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 feature
FBUL = Parameter is included in the File Based Upload feature
StNW = Parameter is included in the Send to Network feature
Q3 = 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
M F F S E
M B B t v
L P U N e
New / Default P L W n
Name Modified Level Description Range value t
DHR Limit For New BTS Determines the limit value for 0..100 0% M x X x x
FR TCH the amount of idle FR TCH %
Resources 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.
TRX OSC New TRX Indicates if the TRX supports N/Y N R - X - x

capability Orthogonal Subchannel
feature
OSC New HOC Determines minimum uplink -110...- -85 dBm M x X x x

Multiplexing Ul RX level for double half rate 47
Rx Level multiplexing. dBm,
Threshold step 1
AMR HR calls which have dB
uplink Rx level at or above
the Rx level threshold, can
be selected as a target
channel for double half rate
multiplexing.
OSC New HOC Determines maximum 0...63 10 dB M x x x x

Multiplexing Ul allowed Ul Rx Level dB,
Rx Level difference between step 1
Window candidates for pairing in dB
double half rate multiplexing.

REQUIREMENTS 124
BSS30385, BSS30390
This parameter shall always

have lower value than OSC
Demultiplexing Ul Rx Level
Margin.
OSC New HOC Determines uplink and < 0.2% 0 M x x x x

Multiplexing downlink RX quality (0),
Rx Quality threshold for target channel 0.2% -
Threshold for double half rate 0.4%
multiplexing. (1),
0.4% -
AMR HR calls which have 0.8%
averaged Rx quality at or (2),
above the OSC Multiplexing 0.8% -
Ul Rx Level Threshold both in 1.6%
uplink and downlink direction (3),
can be selected as a target 1.6% -
channel for double half rate 3.2%
multiplexing. (4),
3.2% -
6.4%
(5),
6.4% -
12.8%
(6), >
12.8%
(7)
OSC New HOC Determines uplink RX level 0...63 14 dB M x x x x

Demultiplexing difference threshold for dB,
Ul Rx Level triggering double half rate step 1
Margin demultiplexing for the dB
stronger connection into an
AMR HR call.
This parameter shall always

have higher value than OSC
Multiplexing Ul Rx Level
Window
OSC New HOC This parameter defines the < 0.2% 3 M x x x x

Demultiplexing threshold level of the (0),
Rx Qual averaged signal quality 0.2% -
Threshold downlink and uplink 0.4%
measurements for triggering (1),
the intra-cell handover for an 0.4% -
double half rate call in order 0.8%
to switch it to an AMR FR (2),
call. 0.8% -
1.6%
(3),
1.6% -
3.2%
(4),
3.2% -
6.4%
(5),
6.4% -
12.8%
(6), >

REQUIREMENTS 125
BSS30385, BSS30390
12.8%
(7)
Threshold Dl New HOC This parameter defines the < 0.2% 4 M x x x x

Rx Qual DHR threshold level of the (0),
averaged signal quality 0.2% -
downlink measurements for 0.4%
triggering the handover. (1),
Defined for the double half 0.4% -
rate call. 0.8%
(2),
0.8% -
1.6%
(3),
1.6% -
3.2%
(4),
3.2% -
6.4%
(5),
6.4% -
12.8%
(6), >
12.8%
(7)
Threshold Ul New HOC This parameter defines the < 0.2% 4 M x x x x

Rx Qual DHR threshold level of the (0),
averaged signal quality 0.2% -
uplink measurements for 0.4%
triggering the handover. (1),
rate call. 0.8%
(2),
0.8% -
1.6%
(3),
1.6% -
3.2%
(4),
3.2% -
6.4%
(5),
6.4% -
12.8%
(6), >
12.8%
(7)
PC Lower New POC With this parameter you < 0.2% 3 M x x x x

Threshold Dl define the threshold level of (0),
Rx Qual DHR the averaged downlink signal 0.2% -
quality measurements for the 0.4%
BTS power increase. Defined (1),
for the double half rate call. 0.4% -
0.8%
(2),
0.8% -
1.6%
(3),

REQUIREMENTS 126
BSS30385, BSS30390
1.6% -
3.2%
(4),
3.2% -
6.4%
(5),
6.4% -
12.8%
(6), >
12.8%
(7)
PC Lower New POC With this parameter you < 0.2% 3 M x x x x

Threshold Ul define the threshold level of (0),
Rx Qual DHR the averaged uplink signal 0.2% -
MS power increase. Defined (1),
0.8%
(2),
0.8% -
1.6%
(3),
1.6% -
3.2%
(4),
3.2% -
6.4%
(5),
6.4% -
12.8%
(6), >
12.8%
(7)
PC Upper New POC With this parameter you < 0.2% 0 M x x x x

Threshold Dl define the threshold level of (0),
Rx Qual DHR the averaged downlink signal 0.2% -
BTS power decrease. (1),
rate call. 0.8%
(2),
0.8% -
1.6%
(3),
1.6% -
3.2%
(4),
3.2% -
6.4%
(5),
6.4% -
12.8%
(6), >
12.8%
(7)
PC Upper New POC With this parameter you < 0.2% 0 M x x x x

Threshold Ul define the threshold level of (0),

REQUIREMENTS 127
BSS30385, BSS30390
Rx Qual DHR the averaged uplink signal 0.2% -

MS power decrease. Defined (1),
0.8%
(2),
0.8% -
1.6%
(3),
1.6% -
3.2%
(4),
3.2% -
6.4%
(5),
6.4% -
12.8%
(6), >
12.8%
(7)
C/I Target New BSC With this parameter you 0...63 16 dB M x x x x

DHR define the target C/I value for dB,
double half rate connections. step 1
dB
Soft Blocking New BSC With this parameter you -20...43 -20 dB M x x x x
C/I DHR define the minimum dB,
acceptable C/I value for step 1
double half rate connections. dB
9.1.1.1.2 Circuit Swithed Dynamic Abis Pool
M F F S E
M B B t v
L P U N e
CSDAP ID New CSDAP This parameter identifies the 1...100 - M x x x x

dynamic Abis pool in a BSC. 0
The identification number
must be unique within the
BSC.
NOTE:
MML Modification: Read-only,

the value is given during
CSDAP creation.
Circuit Group New CSDAP This parameter identifies the 1... R - - - -

Number circuit group number of a CM_C
CSDAP that has been GR_C
created (in

REQUIREMENTS 128
BSS30385, BSS30390
NOTE: DXPFIL
)
the value is automatically
selected during CSDAP
creation.
ETPCM New CSDAP The parameter defines the 0...339 - M x x x x

Abis interface ET-PCM 1
number for the CSDAP.
This parameter is given

during CSDAP creation by
entering ET-PCM value to
parameter Circuit (CRCT).
Range:
CRCT PCM: 0..3391
NOTE: 2048..3391 is
reserved for OC-3/T1
administration area.
NOTE:

CSDAP creation.
First Timeslot New CSDAP This parameter defines the 1...31 - M x x x x

first 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 first timeslot to
parameter Circuit (CRCT)
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 1...31 - M x x x x

REQUIREMENTS 129
BSS30385, BSS30390
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
BCF Abis IF New CSDAP This parameter identifies 1...16 - M x x x x

Abis IF number in BCF side.
NOTE: Modification is
possible only when the
CSDAP has not been
attached to BCF.
BCF Timeslot New CSDAP This parameter identifies 0...30 0 M x x x x

Shift offset between ETPCM (0x00...
timeslots in BSC side and 0x1E)
Abis IF timeslots in BCF
side. -1...-30
(0xFF...
NOTE: Modification is 0xE2)
possible only when the
CSDAP has not been Negativ
attached to BCF. e offset
=
0x100 -
BCF
Timeslo
t Shift
Attached New BCF This parameter identifies the 1...100 'not_in_ M x x x x

CSDAP 1 circuit switched dynamic Abis 0, use'
pool that is attached to the special
BCF. value:
'not_in_
NOTE: use'

REQUIREMENTS 130
BSS30385, BSS30390

CSDAP attach/detach.

BCF. value:
'not_in_
NOTE: use'


BCF. value:
'not_in_
NOTE: use'


BCF. value:
'not_in_
NOTE: use'

CSDAP New PAFILE This parameter defines 1...255 90 s M

Penalty duration of CSDAP penalty second
Duration timer. s
BSC sets penalty for a

certain CSDAP in case of
- consecutive remote
transcocder failures
- hunting error(s)
CSDAP New PAFILE This parameter defines the 0...255 5 M

Penalty amount of consecutive
Threshold remote transcoder failures 0=
after which CSDAP penalty
supervision considers the not in
CSDAP as malfunctioned. use

REQUIREMENTS 131
BSS30385, BSS30390
9.1.1.1.3 Dynamic Soft Channel Capacity
M F F S E
M B B t v
L P U N e
Assured New BSC This parameter determines 1…8 8 M x x x X

Channel assured capacity in each
Capacity 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.

REQUIREMENTS 132
BSS30385, BSS30390
9.1.2 Monitoring
9.1.2.1 Alarms
Name New / Modified Description
CIRCUIT SWITCHED New CSDAP has encountered a

DYNAMIC ABIS POOL malfunction and it has been taken out
FAILURE of use for a penalty period.
BSC sets penalty for a certain

CSDAP in case of consecutive
remote transcoder failures and
hunting error(s).
DOUBLE HALF RATE New Several consecutive DHR

CHANNEL ACTIVATION multiplexing attempts have failed due
FAILURE to channel activation failure in a TRX.
The BSC has interrupted DHR

multiplexing activity in the TRX.
Failures due to CSDAP problems

excluded.

REQUIREMENTS 133
BSS30385, BSS30390
9.1.2.2 Customer Statistics
New / modified measurements and observations
Name New / Modified Description
Circuit Switched Dynamic New New Circuit Switched Dynamic Abis

Abis Pool Measurement 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 New The OSC RX Quality Measurement

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.
Traffic Measurement Modified New counters for double half rate

multiplexing attempts, CSDAP
allocation attempts and failures

REQUIREMENTS 134
BSS30385, BSS30390
related to these
Resource Availability Modified New Double Half Rate specific

Measurement counters for average and peak
amounts
Handover Measurement Modified New Double Half Rate specific

counters for multiplexing and
demultiplexing handover attempts
and successful cases
BSC Level Clear Code Modified New Double Half Rate specific
(PM) Measurement counters for multiplexing and
demultiplexing handovers
FER Measurement Modified New values for Double Half Rate in

counter 077002 / USED CODEC
TYPE.
DFCA Measurement Modified New connection type for Double Half

Rate
DFCA SAIC Measurement Modified New connection type for Double Half
Rate
Drop Call Breakdown Modified New values for Double Half Rate in
Observation counters 029014 / DL LAST USED
BITRATE and 029015 / UL LAST
USED BITRATE
Radio Measurement Modified New values for Double Half Rate in

Report counters 0210800 / AMR UL 1,
0210801 / AMR DL 1 …0210955 /
AMR UL 32, 0210956 / AMR DL 32
New counters
Name Measurement Description
DHR MULTIPLEXING Traffic Description: Number of times the load

ATTEMPTS Measurement criteria for double half rate
multiplexing has triggered.
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

REQUIREMENTS 135
BSS30385, BSS30390
algorithm.
DHR MULTIPLEXING Traffic Description: Number of times a

FAILURE DUE TO TCH Measurement suitable pair of AMR calls for double
RESOURCE 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 Traffic Description: Number of CSDAP

ALLOCATION ATTEMPTS Measurement resource allocation attempts for
FOR DHR Double Half Rate.
Updated: When Radio Resource

Management requests CSDAP
resources for double half rate
multiplexing.
DHR MULTIPLEXING Traffic Description: Double half rate

FAILURE DUE TO Measurement multiplexing has triggerred but
CSDAP RESOURCE 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.
DHR MULTIPLEXING Traffic Description: Number of times double

FAILURE DUE TO Measurement half rate multiplexing is rejected due
OTHER REASON to unsuitable state of the call
Updated: When Call Control rejects

the initiated double half rate
multiplexing handover request due to
unsuitable state of the call.

REQUIREMENTS 136
BSS30385, BSS30390
AVE BUSY DHR TCH Resource Description: Sum of the busy double
Availability half rate TCHs sampled. The average
Measurement 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 Resource Description: Number of the busy

DENOMINATOR Availability double half rate TCH samples.
Measurement 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.

AVE BUSY DHR TCH counter is
updated along with this counter.
PEAK BUSY DHR TCH Resource Description: Peak number of the busy
Availability double half rate TCHs within a
Measurement measurement period.
Updated: When the number of the

busy double half rate TCHs exceeds
the previous peak value.
HO ATTEMPT FROM Handover Description: Number of handover

AMR HR TO DHR Measurement attempts from an AMR HR TCH to a
double half rate TCH.
Updated: When a double half rate

multiplexing handover attempt for an
AMR HR call is started.
HO ATTEMPT FROM Handover Description: Number of handover

REQUIREMENTS 137
BSS30385, BSS30390
AMR FR TO DHR Measurement attempts from an AMR FR TCH to a

Updated: When a double half rate

multiplexing handover attempt for an
AMR FR call is started.
HO FROM AMR HR TO Handover Description: Number of successful

DHR SUCCESSFUL Measurement handovers from an AMR HR TCH to a
Updated: When a handover from an

AMR HR TCH to a double half rate
TCH has been completed.
HO FROM AMR FR TO Handover Description: Number of successful

DHR SUCCESSFUL Measurement handovers from an AMR HR TCH to a
Updated: When a handover from an

AMR FR to a double half rate TCH
has been completed.
INT CELL UNSUCCESS Handover Description: Number of failed

HO TO DHR DUE TO Measurement handovers to a double half rate TCH
CSDAP MISMATCH due to CSDAP conflict between BSC
and BTS.
Updated: When target channel

activation fails during a double half
rate multiplexing handover with cause
code CSDAP error.
HO ATTEMPT FROM Handover Description: Number of demultiplexing

DHR DUE TO RX Measurement handover attempts starting from a
QUALITY 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 Handover Description: Number of demultiplexing

DHR DUE TO UL RX Measurement handover attempts starting from a
LEVEL DIFFERENCE double half rate TCH based on UL Rx
level difference between the
multiplexed double half rate TCHs.
Updated: When a demultiplexing

REQUIREMENTS 138
BSS30385, BSS30390
handover attempt for a double half

rate call is started based on UL Rx
HO FROM DHR DUE TO Handover Description: Number of successful

RX QUALITY Measurement handovers starting from double half
SUCCESSFUL rate TCH based on Rx quality.

handover starting from a double half
rate TCH based on Rx quality has
been completed.
HO FROM DHR DUE TO Handover Description: Number of successful

UL RX LEVEL Measurement demultiplexing handovers starting
DIFFERENCE from a double half rate TCH based on
SUCCESSFUL UL Rx level difference between the

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 BSC Level Clear Description: Number of successful

HR TO DHR Code (PM) intra-cell handovers from an AMR HR
Measurement 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
INTRA HO FROM AMR BSC Level Clear Description: Number of successful

FR TO DHR Code (PM) intra-cell handovers from an AMR FR
Measurement TCH to a double half rate TCH.

MSC.
Dependencies with other counters::

REQUIREMENTS 139
BSS30385, BSS30390

INTRA HO FROM DHR BSC Level Clear Description: Number of successful

DUE TO RX QUALITY Code (PM) intra-cell handovers starting from a
Measurement double half rate TCH based on Rx
quality.

MSC.

INTRA HO FROM DHR BSC Level Clear Description: Number of successful

DUE TO UL RX LEVEL Code (PM) intra-cell handovers starting from a
DIFFERENCE Measurement double half rate TCH based on UL Rx

MSC.

TOTAL PCM 8 KBIT/S CSDAP Description: Total number of 8 kbit/s

SUBTSLS IN CSDAP Measurement PCM subTSLs in a CSDAP.
Updated: The counter is updated by

the size of the CSDAP once in a
measurement period.
AVERAGE CSDAP 8 CSDAP Description: Sum of the busy 8 kbit/s

KBIT/S SUBTSL USAGE Measurement subTSLs sampled in CSDAP. The
average value is calculated by
dividing the value of this counter by

REQUIREMENTS 140
BSS30385, BSS30390
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.

This counter is updated along with the
USAGE DENOMINATOR counter.
AVERAGE CSDAP 8 CSDAP Description: Number of the busy 8

KBIT/S SUBTSL USAGE Measurement kbit/s subTSL samples. Denominator
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.

This counter is updated along with the
USAGE counter.
PEAK CSDAP 8 KBIT/S CSDAP Description: Peak usage of 8 kbit/s

SUBTSL USAGE Measurement subTSLs in CSDAP.
Updated: When the number of

reserved 8 kbit/s subTSLs exceeds
the previous peak value.
OSC AMR HR 4.75 ON OSC RX Quality Description: Number of times AMR

UPLINK DIRECTION Measurement HR 4.75 kbit/s codec mode (bitrate) is
WITH RXQUAL 0 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.

REQUIREMENTS 141
BSS30385, BSS30390

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 OSC RX Quality Description: Number of times AMR

DOWNLINK DIRECTION Measurement HR 4.75 kbit/s codec mode (bitrate) is
WITH RXQUAL 0 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
measurement report interval.

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 Check above.

Measurement
OSC AMR HR 5.15 ON OSC RX Quality Check above.

UPLINK DIRECTION Measurement
WITH RXQUAL 0

DOWNLINK DIRECTION Measurement
WITH RXQUAL 0

Measurement

WITH RXQUAL 0

REQUIREMENTS 142
BSS30385, BSS30390

WITH RXQUAL 0

Measurement

WITH RXQUAL 0

WITH RXQUAL 0

Measurement

WITH RXQUAL 0

WITH RXQUAL 0
..RXQUAL 1...7 OSC RX Quality Check above.

Measurement
Modified counters:
Name Measurement Description
077002 / USED CODEC FER New codecs to be added:

TYPE Measurement
21 = OSC half rate speech, 7.4kbit/s
24 = OSC half rate speech,

5.15kbit/s
25 = OSC half rate speech,

4.75kbit/s

REQUIREMENTS 143
BSS30385, BSS30390
DL LAST USED BITRATE Drop Call New values to support OSC DHR
Breakdown specific codecs 7.4, 6.7, 5.9, 5.15 and
Observation 4.75kbit/s.
UL LAST USED BITRATE Drop Call New values to support OSC DHR
Breakdown specific codecs 7.4, 6.7, 5.9, 5.15 and
Observation 4.75kbit/s.
AMR UL 1…32 Radio New values to support OSC DHR

Measurement specific codecs 7.4, 6.7, 5.9, 5.15 and
Report 4.75kbit/s.
AMR DL 1…32 Radio New values to support OSC DHR

Measurement specific codecs 7.4, 6.7, 5.9, 5.15 and
Report 4.75kbit/s.
Object modification DFCA The object level of the measurement

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 The object level of the measurement

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:

REQUIREMENTS 144
BSS30385, BSS30390
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.

REQUIREMENTS 145
BSS30385, BSS30390
9.1.4 Control of the optionality
9.1.4.1 Double Half Rate with SAIC MS
SW Licence Methods (mark with x, clarify with product manager):
X Optionality control Activation methods

Trust based Freely available.
(No technical control) Feature is activated without feature configuration.
(No technical control) Feature activation needs RNW configuration with MML command(s).
BSC Parameter file based control PRFILE/FIFILE control
Feature is activated without feature configuration.
Feature needs configuration with MML command/s
Licence Key (LK) based control Licence key installation
X Licence Key (LK) based control Licence key installation.
Licence Type: Capacity
Capacity Item: TRX
X Actions when Licence is disabled

Feature has no deactivation functionality (Feature continues to work despite disabling of licence)
Feature works until reconfiguration
X Feature is deactivated automatically

REQUIREMENTS 146
BSS30385, BSS30390
9.1.4.2 Circuit Switched Dynamic Abis Pool

Capacity Item: Other: CSDAP timeslots attached to BCF


REQUIREMENTS 147
BSS30385, BSS30390
9.1.4.3 Dynamic Soft Channel Capacity

Capacity Item: TRX


REQUIREMENTS 148
BSS30385, BSS30390
9.2 Effects on interfaces and network elements
9.2.1 Abis Telecom interface
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 1
Element identifier 1
Length 2
OSC Bits on Abis Reserved for future use DTXd DTXu 3
in Use
Speech or data indicator 4
Channel 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:
00 1 bit for OSC DHR
01 2 bits for OSC DFR
10 3 bits for possible OSC WB-AMR use
11 4 bits for possible OSC WB-AMR use

REQUIREMENTS 149
BSS30385, BSS30390
9.2.1.2 Channel Number IE
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 C1
0 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 + ACCH
0 1 T T T SDCCH/8 + ACCH
1 0 0 0 0 BCCH
1 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.

REQUIREMENTS 150
BSS30385, BSS30390
9.2.1.3 Channel Identification IE
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.
8 7 6 5 4 3 2 1
Element identifier (IEI=1111 0100) 1
Length 2
CSDAP Id (H) 3
CSDAP Id (L) 4
Timeslot Sub timeslot 5
Octet 3 and 4 contain CSDAP identity.
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.

REQUIREMENTS 151
BSS30385, BSS30390
8 7 6 5 4 3 2 1
MS Speed 1
Enhanced Timing Advance IE 2
Enhanced Timing 3
Advance Value 4
Uplink FER data + Length of uplink FER data + AMR 5
AMR codecs IEI codecs
Number of uplink bad frames 6
UL codec 1 UL codec 2 DL codec 1 DL codec 2 7
...
Number of uplink bad frames N-1
UL codec 1 UL codec 2 DL codec 1 DL codec 2 N
EMR data IEI Length of EMR data N+1
MEAN_BEP CV_BEP N+2
Number of downlink bad frames N+3
...
Number of downlink bad frames N+M
AMR signalling data IEI Length of AMR signalling data N+M+1

DL_SRR UL_S DL_S FF_rep N+M+2
RO RS
Spare ULSC FF_non_rep N+M+3
...
DL_SRR UL_S DL_S FF_rep N+M+K-1
RO RS
Spare ULSC FF_non_rep N+M+K
OSC Neighbouring Sub Channel Measurements IE
Validity 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
0 DTX was not employed

REQUIREMENTS 152
BSS30385, BSS30390
1 DTX was employed
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 averaging

Validity Set 0 if 0 in any of reports to be averaged
DTXu Set 1 if 1 in any of reports to be averaged
RXLEV-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:
9.2.2.1.1 OSC Support IE
FIELD TYPE LENGTH NOTE

Element identifier #XXX M 3
Length M 1
OSC support M 1 1
NOTE 1: 0= OSC not supported, 1= OSC supported
9.2.2.2 BTS CONF DATA message
BSC shall provide CSDAP configurations for BTS in BTS_CONF_DATA with a new
CSDAP IE.

REQUIREMENTS 153
BSS30385, BSS30390
BSC shall Indicate for Flexi EDGE TRX in BTS_CONF_DATA with a new OSC enabled
IE if the TRX it is to be started in OSC mode.
FIELD TYPE NOTE

Command header M
FU parameters O,S 3,21
FU channel configuration O,S 2,3,6
Object Identity and Object state O,S 3,5
FU BSIC O,S 2,3
ARFN of a CU O,S 3,6,9,12
FU radio definition O,S 3,6
Frame number M 3,4
RX antenna supervision period M 19
Sector configuration O,S 18
Hopping mode O,S 7, 35
Floating TRX O 8
Extended cell radius O,S 1,6, 35
ARFN O 10
BS_TXPWR_OM O 11
Real time O 13
RX diversity selection O,S 14, 34
EAC input config O,S 14
Feature support O 15
RX difference limit O 16
Dynamic pool info O,S 17
DFCA FU radio definition O,S 20, 35
Antenna hopping O,S 22
Connectsite optional elements O,S 23
STIRC Option Setting O, S 24
BSC BCF id O 26
LAPDm T200 Values O 27,28
BTS Object Mapping O,S 18, 29
Abis Mapping O,S 30,31
DTRX info O,S 32, 34, 35
TRS Licensing O, S 33
CSDAP O, S 36
OSC Enabled O, S 37
 NOTE 36: This element is included for Flexi EDGE BTS after site reset or if the pool info is
changed.
 NOTE 37: This element is included for Flexi EDGE BTS.

REQUIREMENTS 154
BSS30385, BSS30390
9.2.2.2.1 CSDAP IE
New information element CSDAP IE is defined to BTS_CONF_DATA message.

Element identifier #183 M 3
Length M 1
CSDAP id O 2 1
CSDAP parameters O 8
NOTE 1: CSDAP identity. Range 1 ... 1000
9.2.2.2.1.1 CSDAP Parameters IE

Length M 1
Abis IF O 1 1
Timeslot shift offset O 1 2
Pool start TSL O 1 3
Pool end TSL O 1 3
NOTE 1: Abis IF in BCF. Range 1 ... 16
NOTE 2: Time slot shift offset between Abis ETPCM and Abis IF timeslots.
Positive offset range: 0 ... 30 (0x00 ... 0x1E)
Negative offset range: -1 ... -30 (0xFF ... 0xE2)
Negative offset = 0x100 - TSO
NOTE 3: Pool timeslots are reported as they are from BSC's viewpoint.
Range: 1...31

REQUIREMENTS 155
BSS30385, BSS30390
9.2.2.2.2 OSC Enabled IE

Length M 1
TRX id M 1
OSC enabled M 1 1, 2
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.
9.2.2.3.1 CSDAP id
FIELD TYPE LENGTH

Element Identifier #XXX M 3
Length M 1
CSDAP id O 2

REQUIREMENTS 156
BSS30385, BSS30390
9.2.2.4 BTS_TEST_REPORT (ABIS_LOOP_TEST) message
FIELD TYPE NOTE

Command header M
Object identity M 1
Test type ( = Abis_loop_test_req) M
Success-Failure M 2
FER M
Bit error ratio M
Transmission delay M
Abis TSL O 1,3,5
CSDAP id O 4
 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.

Element identifier#35 M 2
Length M 1
Ack (1) / Nack (2) M 1
Nack reason O 2

REQUIREMENTS 157
BSS30385, BSS30390
Specific nack reasons:
? 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.
second CSDAP IE in the BTS_CONF_DATA message.
third CSDAP IE in the BTS_CONF_DATA message.
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.
code refers to the second CSDAP IE in the
code refers to the third CSDAP IE in the
code refers to the fourth CSDAP IE in the
? 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.
resources. This cause code refers to the second CSDAP
IE in the BTS_CONF_DATA message.
resources. This cause code refers to the third CSDAP IE
resources. This cause code refers to the fourth CSDAP IE
? N_CSDAP_RESOURCE_UNAVAILAB CSDAP does not exist or the the timeslot does not belong
LE to CSDAP.

REQUIREMENTS 158
BSS30385, BSS30390
9.3 Compatibility

SUPPORTED IN:
GSM GSM GSM GSM MSS MGW NetAct BSC SGSN Talk- MetroSite UltraSite Flexi Multiradi BSxx
800 900 1800 1900 family EDGE o Flexi
Y Y Y Y - - OSS5.2 S15 - - - - Y - -
CD set
3
HW/FW DEPENDENCY: BSS SOFTWARE:

BSC BTS MS BSC BTS TC SGSN ASW/BSW
MMI MMI HW/FW HW/FW HW/FW HW/FW
Y - Y, see - - - - ASW
note
Note: SAIC support required.

SUPPORTED IN:
Y Y Y Y - - OSS5.2 S15 - - - - Y - -
CD set
3

Y - - - - - - ASW

SUPPORTED IN:
Y Y Y Y - - OSS5.2 S15 - Y Y Y Y - -
CD set
3

Y - - - - - - ASW
9.4 Effects to SoC
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.
9.5 Requirements for the DX200 Platform
Amount of circuit groups shall be increased. Check requirement BSS30385-004 Circuit

group amount increase.

REQUIREMENTS 159
BSS30385, BSS30390
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.

REQUIREMENTS 160
BSS30385, BSS30390
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.
9.7.8 Frequency hopping
Operator is recommended to apply RF hopping or BB hopping together with OSC in

order to smooth out the impact of fast fading.

REQUIREMENTS 161
BSS30385, BSS30390
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.
9.7.17 4-way uplink diversity
The BSC does not apply DHR multiplexing in a TRX that has 4-way uplink diversity
(4UD) feature in use.

REQUIREMENTS 162
BSS30385, BSS30390
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.
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.

REQUIREMENTS 163
BSS30385, BSS30390
9.8 Testing
9.8.1 Testing environment
Enviroment for testing OSC calls
 BSC (S15)
o AMR HR
o SAIC
o CSDAP
o Packet Abis
o DFCA
o AMR Unpacking Optimization
o BB Hopping
o Antenna Hopping
 Flexi BTS
o Odessa TRXs
o Epsilon TRXs
o Two antenna diversity
 Abis transmission
o Circuit Switched Dynamic Abis Pool (CSDAP)
o Packet Abis
 Several MSs
o AMR HR capable
o SAIC capable
 MSC & TCSM
o AMR HR support

REQUIREMENTS 164
BSS30385, BSS30390
9.8.2 Requirements for testing tools
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.

REQUIREMENTS 165
BSS30385, BSS30390
11 DOCUMENT REVISION HISTORY
DATE ISSUE AUTHOR APPROVER SUMMARY OF CHANGES

27.11.08 0.0.1 Tommi Requirements for BSS30385
Raisanen Circuit Switched Dynamic Abis
Pool.
Licensing proposals for:

- BSS21309 OSC DHR
- BSS30390 Dynamic Soft
Channel Capacity
Parameter table updated

according to OSC workshops.
23.12.08 0.0.2 Jyrki Rämä DRAFT Telecom requirements added

11.01.09 0.0.3 J.Rämä DFAFT Introduction for OSC, DFCA
requirements
26.1.09 0.0.4 J.Rämä DRAFT Requirements updated and
improved, parameters and
counters updated, interactions
with other features updated.
1.2.09 0.0.5 J.Rämä DRAFT Updated version for pre-review
of chapters 6, 7, 9.1.1.1, 9.1.2,
9.7
2.2.09 0.0.6 J.Rämä DRAFT Version for pre-review with
“track changes” removed
14.2.2009 0.0.7 J.Rämä DRAFT Updated version after pre-
review
17.2.2009 0.0.8 T.Räisänen DRAFT Updated version after pre-
review (CSDAP corrrections)
17.2.2009 0.1.0 T.Räisänen DRAFT Version for RS review
05.03.2009 0.1.1 T.Räisänen DRAFT Corrections after review
10.3.2009 0.1.1 J.Rämä DRAFT Review corrections
13.3.2009 0.1.2 J.Rämä DRAFT Re-review corrections with “track
changes” tool on.
13.3.2009 1.1-0 J.Rämä P.Virsu First approved version

REQUIREMENTS 166
BSS30385, BSS30390
DOCUMENT STORAGE:
DXSYDE:
Subsystem 09580.
Sharenet:
Enterprise -> COO -> Radio Access -> GSM_EDGE RD -> Line organizations -> eBSC
and BSC RD -> BSC Programs -> S15 -> S15 Features -> BSS21309 Orthogonal
Subchannel with SAIC MS
Link to the folder:
https://sharenet-ims.inside.nokiasiemensnetworks.com/Open/391651404
Clear Case:
Not relevant.


OSC - Feature Description PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

OSC - Feature Description PDF

Uploaded by

Copyright:

Available Formats

ORTHOGONAL SUB CHANNEL (OSC)

BSS21309, BSS30385, BSS30390

For Internal Use

Version Author/Checked by Approved by Feature Number Pages

Radio Access For Internal Use

1.2 Circuit Switched Dynamic Abis Pool

1.3 Dynamic Soft Channel Capacity

2 DESCRIPTION AND CONCEPTS

2.3 Terms and Concepts

4 PROJECT RELATED INFORMATION

4.3 Support persons

5.2 Postponed or Rejected Requirements

5.3 Function Point Analysis

File name: Doc. status: Author: Approved by:

Radio Access For Internal Use

6.2 General requirements

6.3 AMR unpacking optimization

6.4 DFCA requirements

File name: Doc. status: Author: Approved by:

Radio Access For Internal Use

6.4.2 BSS21309-047 C/I calculation for a DHR connection in DFCA

6.5 Postponed or rejected requirements

7 REQUIREMENTS FOR THE FEATURE BSS30385 CIRCUIT SWITCHED DYNAMIC

7.2 CSDAP handling

7.3 Resource allocation from CSDAP

7.4 Releasing of CSDAP resources

7.5 CSDAP supervision 108

7.6 Abis loop test for CSDAP circuits 114

File name: Doc. status: Author: Approved by:

Radio Access For Internal Use

7.7 Control of the optionality and licensing 119

7.8 Rejected requirements 120

8 REQUIREMENTS FOR THE FEATURE BSS30390 DYNAMIC SOFT CHANNEL

8.2 BSS30390-002 BSC parameter for dynamic channel capacity 121

9 SYSTEM EFFECTS 123

9.2 Effects on interfaces and network elements 149

File name: Doc. status: Author: Approved by:

Radio Access For Internal Use

9.2.2.5 Ack-Nack 157

9.3 Compatibility 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 161

9.8 Testing 164

9.9 Restrictions 165

9.10 IPR Issues 165

10 IDEAS FOR FUTURE DEVELOPMENT 165

11 DOCUMENT REVISION HISTORY 166

DOCUMENT STORAGE: 167

File name: Doc. status: Author: Approved by:

Radio Access For Internal Use

File name: Doc. status: Author: Approved by:

Radio Access For Internal Use

1.1 Double Half Rate with SAIC MS

Orthogonal subchannel feature is included in 3GPP release 9 as a study item called

File name: Doc. status: Author: Approved by:

Radio Access For Internal Use

1.2 Circuit Switched Dynamic Abis Pool

1.3 Dynamic Soft Channel Capacity

File name: Doc. status: Author: Approved by:

Radio Access For Internal Use

File name: Doc. status: Author: Approved by: