OSC Feature Description
OSC Feature Description
__________________________________________________________________________________
CONTENTS
1 INTRODUCTION
1.1 Double Half Rate with SAIC MS
1.1.1 Benefits
2.2 Abbreviations
3 REFERENCES
4.2 Problems
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
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
8.3 BSS30390-003 TRX parameter for dynamic channel capacity (REJECTED) 122
1 INTRODUCTION
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.
Voice channel capacity of the BSC will remain the same at the introduction of the
Double Half Rate feature. Operator should take this into account and consider actions
to compensate the increased TRX channel capacity. One option is to apply the Dynamic
Soft Channel Capacity feature.
Use of Double Half Rate (DHR) always requires additional Abis transport capacity for
the second OSC connection in a half rate TCH channel. Additional Abis transport
capacity shall be provided by Dynamic Abis or by Packet Abis.
A broad enough LAPD signalling link is required to handle the increased amount of
radio measurements and signalling caused by increased amount of calls per TRX.
Operator shall have to define at minimum a 32 kbit/s LAPD signalling link, when OSC is
enabled in a TRX.
BSC supports Double Half Rate with SAIC MS for Flexi EDGE BTS.
Double Half Rate with SAIC MS is an application SW feature controlled with license.
1.1.1 Benefits
Double Half Rate with SAIC MS improves cost efficiency of GSM voice and supports
the vision of 5 billion mobile users by 2015.
Double Half Rate with SAIC MS provides operators the capability to exploit installed
hardware efficiently or even reduce it. Operators can fully exploit the available
spectrum with less TRX hardware compared to AMR.
System simulations have shown significant gains in capacity with the Double Half Rate
feature when the available spectrum is exploited with a low number of TRXs. The
increased capacity per TRX reduces the energy consumption per user. Energy
consumption required per Erlang can be expected to reduce by tens of percents.
Double Half Rate with SAIC MS provides for an operator a profitable path to grow with
minimized CAPEX and OPEX. Coverage area can be maintained in capacity
extensions with the Double Half Rate feature and the need to add new sites is avoided,
thus, lowering considerably the operator’s expenditures.
Double Half Rate with SAIC MS is applicable with the existing GSM SAIC handsets,
providing network operators an immediate gain with just a software upgrade in their
GSM radio network.
As Double Half Rate with SAIC MS increases voice capacity, it also releases capacity
for data traffic. When another radio technology or another operator needs to share the
same site, antennas or input ports of combiners may be released by the introduction of
Double Half Rate with SAIC MS.
Nokia Siemens Networks estimates that Double Half Rate with SAIC MS is reducing a
GSM operator’s CAPEX and OPEX for voice service by up to 50%.
In legacy Abis interface there is fixed transmission capacity configured for each radio
timeslot. When Double Half Rate with SAIC MS is taken into use more Abis
transmission capacity is needed because two DHR calls are multiplexed into one
TCH/H. Circuit Switched Dynamic Abis Pool (CSDAP) feature offers common Abis
transmission pools that can be shared by all calls in a BCF cabinet. With CSDAP
operator avoids the need to configure additional fixed Abis transmission capacity when
taking the Double Half Rate feature into use.
The absolute maximum for the TCH handling capacity of a BCSU unit is 8 times the
maximum amount of TRXs in the BCSU. This is the maximum amount of active TCHs in
a BCSU. The BSC can never exceed this maximum capacity.
The BSC makes sure that in each created TRX of a BCSU it is possible to activate as
many calls as there are TCH TSLs in the TRX. This is 100% assured channel capacity.
When the Soft Channel Capacity feature is used the BSC allows to configure more
TCHs than there can be active TCH connections in a BCSU. This is achieved with the
use of half rate TCHs and the Double Half Rate feature which further doubles the
amount of configured TCHs in HR capable TSLs.
When the configured TCH amount in the TRXs of a BCSU exceed the active channel
capacity of the unit then all the configured TCHs in a TRX cannot be activated even
though there is idle signalling capacity available in the BCSU. This is because the BSC
reserves part of the BCSU capacity to guarantee the assured channel capacity in each
TRX.
Dynamic Soft Channel Capacity feature introduces the possibility to give up the 100%
TCH capacity assurance. Operator can define certain amount of BCSU capacity to be
freely available in the TRXs where the need exceeds the 100% assured channel
capacity. Certain minimum capacity is still ensured for the TRXs with little or no traffic.
While Dynamic Soft Channel Capacity allows utilizing BCSU capacity more dynamically
it increases the amount of actual transmitted traffic in the BSC.
Orthogonal Subchannel (OSC) is a voice capacity feature that enables to assign two
AMR calls on the same radio traffic channel. OSC can double TRX channel capacity in
optimal radio propagation conditions for handsets that support single antenna
interference cancellation method (SAIC).
The two OSC subchannels OSC-0 and OSC-1 in a TCH/H are called as double half rate
(DHR) channels. DHR subchannels OSC-0 and OSC-1 are independent of each other,
i.e. they have independent RR layer signalling. The separation between the
simultaneous connections in a TCH is enabled by the use of separate training
sequences. Subchannel specific Training Sequence Codes (TSC) are optimised in TSC
pairs for lowest cross-correlation.
Use of DHR always requires additional Abis transport capacity for the second OSC
subchannel (OSC-1). Additional Abis transport capacity can be provided with Dynamic
Abis as introduced in chapter 7. An alternative method for providing the needed extra
Abis transport capacity is Packet Abis /B/.
OSC-0 is the subchannel using legacy Abis transport resources and the legacy TSC of
the TRX. OSC-1 is the subchannel using additional Abis transport resources and
additional TSC.
In downlink OSC uses quaternary phase shift keying (QPSK). QPSK modulation carries
two orthogonal subchannels which can be received by legacy SAIC handsets like
normal GMSK. The separate reception of the subchannels is enabled by the
orthogonality of the subchannels and the different training sequences of the
subchannels. Figure 1 shows the mapping of users to OSC subchannels carried by
QPSK in downlink. Receiver of MS makes decisions related to I or Q axis, i.e. receiver
is studying the sign of I or Q signal components depending on allocated OSC channel.
(0,1) (1,1)
I
(0,0) (1,0)
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
BTS separates users with a multi-user detection (MUD) receiver. BTS applies 4 th
generation mobile communications technology, a method called Multi User Multiple
Inputs Multiple Outputs (MU-MIMO), to enable the simultaneous reception of the two
OSC subchannels.
In Double Half Rate with SAIC MS feature the target channel for OSC packing, also
called as multiplexing, is always a TCH/H where an AMR call is already going on with
sufficient signal level and quality. For the ongoing AMR HR connection another
adequate AMR call is searched for so that the UL Rx levels of the two connections can
be adjusted close enough to each other.
In the OSC multiplexing procedure an AMR call is handed over to the target TCH. The
original channel rate of the AMR connection to be handed over can be either half rate
or full rate. Thus, Double Half Rate with SAIC MS includes also the option of
multiplexing into DHR straight from AMR FR. The target for the multiplexing handover is
however a TCH/H.
Unpacking from DHR, also called as demultiplexing, can be caused by the deteriorating
quality of a DHR connection or by the weakening UL Rx level balance between the
OSC subchannels. In the former case, by default, the demultiplexing handover is made
into a FR TCH. Additionally, when the AMR Unpacking Optimization feature is used the
demultiplexing handover can be into a HR TCH or into a FR TCH depending on the
radio conditions. If the reason for demultiplexing is the excessive UL Rx level difference
between the multiplexed calls the handover to be made is primarily into a HR TCH.
During the multiplexing procedure BTS switches from GMSK modulation to QPSK
modulation in downlink transmission for the original connection on the target TCH/H.
Likewise, during the demultiplexing procedure where one of the OSC connections is
handed over to another TCH as a traditional AMR connection the BTS switches to
GMSK modulation in downlink transmission for the OSC connection that remains in the
original TCH/H.
DHR multiplexing shall trigger based on traffic load in a BTS. The triggering load limit
shall be an operator parameter based on a similar definition for load as in the traditional
parameters of AMR HR packing. The load limit parameter serves also as a BTS specific
control function for the feature with which you turn the feature on and off in a BTS.
In legacy Abis interface there are allocated 16 kbit/s fixed transmission capacity for
each RTSL from Abis ETPCM. When OSC is taken to use then more Abis transmission
is needed for RTSL because two calls are multiplexed to one HR (or FR) TCH. There is
no sense to allocate double fixed transmission capacity for each RTSL because extra
transmission is needed only when there is high load situation in the cell. Circuit
Switched Dynamic Abis Pool feature offers possibility to create common transmission
pool(s) for OSC DHR calls to BCF cabinet. This Circuit Switched Dynamic Abis Pool
(CSDAP) can situate in the same or different Abis ETPCM as TRXs using it. Abis
transmission resources can be allocated for all TRXs of BCF cabinet from the same
CSDAP.
The maximum active channel capacity of a BCSU is 8 times the maximum amount of
TRXs in the BCSU. The BSC can never exceed the maximum channel capacity of a
BCSU. When the maximum amount of TRXs has been created to a BCSU the BSC
makes sure that in each created TRX of the BCSU it is possible to activate as many
calls as there are TCH TSLs in the TRX. This is the assured channel capacity.
When BSC configuration does not contain maximum amount of TRXs then it is possible
to use the unused TCH handling capacity (free assured channel capacity) in the
existing TRXs for HR and DHR TCHs.
Without the Soft Channel Capacity feature it is not possible to create more TCHs (FR,
HR, DHR TCHs) to BCSU than its maximum TCH handling capacity is.
When the Soft Channel Capacity feature is active then it is possible in TRX
configuration to exceed the maximum TCH handling capacity of BCSU. But BSC can
activate neither HR nor DHR TCHs to a TRX if it would lead to the situation where the
activation of the assured channel capacity in some other TRX of the same BCSU is
threatened.
Dynamic Soft Channel Capacity feature presents possibility to change assured channel
capacity so that system does not need to guarantee 100 % FR TCH capacity for each
TRX but operator can define an applicable value for the TRX specific assured channel
capacity (8…1) with a BSC specific parameter. Operator purchases the Dynamic Soft
Channel Capacity as TRX licences, each TRX licence corresponding to 8 TCHs.
Operator is able to utilize the capacity defined by the licence amount dynamically in the
TRXs where the need exceeds the 100% FR TCH capacity. At the same time operator
can ensure with the assured channel capacity parameter that certain capacity remains
available also for the TRXs where there is not much traffic at that time.
Dynamic Soft Channel Capacity enables the BSC to utilize BCSU capacity more
efficiently. This increases the actual amount of traffic transmitted in the BSC. This
further leads to the increase in the loading of the computer units of the BSC.
2.2 Abbreviations
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
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
3 REFERENCES
Public references:
/1/ 3GPP TS 48.058 Base Station Controller - Base Transceiver Station (BSC
- BTS) interface; Layer 3 specification (Release 8)
/4/ Doubling GSM Voice Capacity with the Orthogonal Sub Channel,
Technology Brief, Nokia Siemens Networks
Internal references:
/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
4.1 Risks
No identified risks.
- - - - - -
4.2 Problems
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.
5 REQUIREMENT LIST
variants
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
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
Function Point Analysis to be made and updated here after the approval of the RS.
6 REQUIREMENTS FOR THE FEATURE BSS21309 DOUBLE HALF RATE WITH SAIC MS
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.
Source: SFS
Linked requirements:
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
OSC support information shall be a read-only TRX parameter in the BSS RNW
Configuration Database. Operator shall not be able to modify the value of the
parameter but shall be able to print out the parameter with ZERO command. Parameter
shall also be delivered to NetAct.
Rationale:
TRX OSC support is system’s internal information but must be visible also for the
operator.
Source: SFS:BSS21309-006
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.
When DHR Limit For FR TCH Resources is being modified into a value >0 the BSC
shall require that there is additional Abis transport capacity available in the BTS.
The necessary extra capacity shall be provided by the Packet Abis feature or, if not in
use, by the Circuit Switched Dynamic Abis Pool (CSDAP) feature introduced in chapter
7. The BSC shall check the availability of Packet Abis from a new BCF object
parameter Abis Interface Connection Type /B/.
If the BTS site is connected to the BSC via Packet Abis a separate dynamic Abis pool is
not needed to provide the additional Abis transport capacity for OSC-1 subchannels.
Packet Abis will provide Abis transport for OSC-1 subchannels exactly in the same
manner as for other speech calls.
Rationale:
Having the parameter on BTS level allows the BTS specific control of the feature in
segment configuration where the operator may want to apply different policy for
different layers of a segment.
Using a similar load definition as in the traditional AMR HR packing makes it easier for
the operator to understand and define the relation between OSC multiplexing and AMR
HR packing.
The 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
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.
Linked requirements:
The BSC shall accept in the Measurement Result message for a DHR channel the
uplink RX level information, the related DTX flag and the measurement validity bit of
the neighbouring DHR connection in the same TCH/H. These pieces of information
shall be a new OSC Neighbouring Sub Channel Measurements IE in the
Supplementary Measurement Information of the Uplink Measurements Information
Element, see Abis Telecom interface
The BSC shall use the new OSC Neighbouring Sub Channel Measurements IE to
decide if the connection itself is a DHR OSC connection or a normal AMR HR
connection. If the IE is present then there is also another DHR connection going on in
the TCH/H and the BSC shall apply the DHR specific examinations for the connection.
The BSC shall verify the RX level balance between the OSC subchannels that share
the same radio channel and to decide on the needed demultiplexing, handover and
power control actions. Also, the BSC shall collect the DHR specific statistics.
If the OSC Neighbouring Sub Channel Measurements IE is not included then the BSC
shall apply the traditional examinations that are made for an AMR HR connection. The
BSC shall collect the performance measurement statistics accordingly.
If there are two connections in a TCH/H but the uplink RX level of the neighbouring
OSC connection is not available the BTS reports the Rx level value as 0.
For an ongoing connection the BSC shall change between AMR HR mode and DHR
mode according to if the new OSC Neighbouring Sub Channel Measurements IE is
included in the Measurement Result message or not.
Rationale:
The BSC must be able to decide between actions for an AMR HR connection and for a
DHR connection and especially notice the switch between the two modes for an
ongoing connection.
During DHR call the BSC can take the RX level balance between the neighbouring
OSC subchannels into account when deciding on the individual actions for them.
Source: SFS:BSS21309-043
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:
6 5
7 1
The BSC shall deliver the TSC of an OSC-1 subchannel to the BTS on a call-by-call
basis during channel activation.
Rationale:
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.
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
Linked requirements:
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:
Source: SFS:BSS21309-024
The BSC shall apply OSC multiplexing in a TRX only if the TRX supports OSC. The
BSC shall check the TRX OSC support while searching for candidates for OSC
multiplexing. The basis for the check shall be the information received from the BTS
and saved in BSS RNW Configuration database as a read-only TRX parameter.
If BB hopping is in use in a BTS and there are both TRXs that support OSC and TRXs
that do not support OSC in a BB hopping group the BSC shall not apply OSC
multiplexing in the TRXs of the hopping group.
If Antenna hopping is in use in a BTS and there are both TRXs that support OSC and
TRXs that do not support OSC in the BTS the BSC shall not apply OSC multiplexing in
the BTS.
Rationale:
TRX level OSC support varies between different TRX versions and BSC has to take
this into account in multiplexing.
Source: SFS:BSS21309-025
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.
Source: SFS:BSS21309-025
6.2.12 BSS21309-014 Double Power TRX and Intelligent Downlink Diversity with OSC
The BSC shall not apply OSC multiplexing in a TRX that has either Double Power TRX
(DPTRX) or Intelligent Downlink Diversity (IDD) feature in use. The use of these
features is controlled by an existing TRX object parameter Dual TRX Usage (DTRX).
The BSC shall apply OSC multiplexing in a TRX only if Dual TRX Usage parameter is in
value “disabled”.
Rationale:
Double Power TRX with OSC would need separate calibration that is different from
GMSK and 8PSK.
For Intelligent Downlink Diversity further research is needed to provide phase and
delay control algorithms with OSC.
Linked requirements: -
The BSC shall decide the need for OSC multiplexing based on load using a similar load
definition as the traditional AMR HR packing procedure: the multiplexing need is
decided based on the amount of idle FR TCH resources.
Unlike in the traditional AMR HR packing, the BSC shall make the actual decision on
triggering the multiplexing procedure in the channel allocation algorithm at the
reception of Rx level and power control information from the HO&PC algorithm.
When the BSC has found out the need for OSC multiplexing it shall result in one
multiplexing handover in the BTS. The BSC shall hand an AMR call over to a TCH/H
where an AMR HR call is already ongoing.
Rationale:
Using a similar load definition as in the traditional AMR HR packing makes it easier for
the operator to understand and define the relation between OSC multiplexing and AMR
HR packing.
Multiplexing decisions in the channel allocation algorithm are made based on the data
received in the Rx level and power control information update from the HO&PC
algorithm. The rate for this update is every 5 seconds. In order to have the best
accuracy in the decisions the multiplexing examinations are made at the reception of
the update.
Source: RS team
Linked requirements:
The channel allocation algorithm shall search for the target TCH/H for multiplexing in a
BTS among the TRXs that it just received the Rx level and power control information
update for.
The BSC shall search for the connection to be handed over to the target TCH/H in DHR
multiplexing among all the TRXs of the BTS that it just received the Rx level and power
control information update for.
Rationale:
Rx level and power control information update from HO&PC algorithm to channel
allocation algorithm is both BTS object and BCSU unit specific procedure. When the
channel allocation algorithm in the MCMU unit receives a message for a BTS the
message contains data related to some TRXs of the BTS, not necessarily to all of
them. Information of the TRXs that are controlled by other BCSU units come(s)
independently at some other moment(s) during the 5-second update period that is used
in the update procedure.
Source: RS team
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
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
Linked requirements: -
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
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
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:
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.
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.
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:
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
both in uplink and downlink direction. Intra HO Threshold Rx Qual AMR FR (IHRF) is an
exisiting criterion for the AMR FR -> AMR HR packing. The same parameter applies for
both AMR FR and AMR HR connections that are to be handed over into DHR mode as
part of OSC multiplexing.
The possibility to prevent AMR FR -> DHR multiplexing shall be included as a UTPFIL
parameter. This shall be a measure of precaution for the case that the direct switching
from AMR FR to OSC DHR causes too big a change in the end-user experience.
Rationale:
In addition to the quality requirements for the multiplexing candidates the two calls to
be multiplexed on a TCH/H need to have their link budgets close enough to each other
in order for OSC multiplexing to be feasible.
Allowing multiplexing to OSC DHR directly from AMR FR maintains the efficiency of
radio resource packing in cases of high load. Allowing multiplexing similarly for both
AMR FR and AMR HR connections increases the probability for finding matching pairs
for multiplexing.
Multiplexing taking place within a BTS object follows the established practice that has
been adopted with AMR HR packing.
Source: RS team
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
The BSC shall optimize the uplink power of the second multiplexing candidate so that
the UL Rx level of this shall equal the UL Rx level of the original connection in the
target channel when the multiplexing is made. The UL power level of the original call in
the channel shall not be changed during the multiplexing handover.
- If the measured UL Rx level of the second multiplexing candidate is lower than the
measured UL RX level of the original call in the TCH/H then the MS power needs to
be increased from the current level. The power increase shall equal the difference
between the measured UL RX levels of the original call and the second multiplexing
candidate.
- If the measured UL RX level of the second multiplexing candidate is higher than the
measured UL RX level of the original call then the MS power needs to be reduced
from the current level. The power decrease shall equal the difference between the
measured UL RX levels of the the second multiplexing candidate and the original
call.
The possibility to allow for the UL Rx level of the second multiplexing candidate a
deviation from that of the original connection shall be enabled by a UTPFIL parameter.
The maximum possible power reduction for UL RX level is defined by equations [4] and
[5] in BSS21309-021 Second candidate for multiplexing.
Rationale:
There is no extra power control made for the original connection in the target TCH/H at
the time of multiplexing when the second connection is added into the channel. The
power level of the second connection has to be adjusted so that the UL Rx levels of the
two connections match.
Source: SFS:BSS21309-026
Linked requirements: -
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:
Rationale:
Since OSC downlink with the QPSK modulation has about 3 dB weaker performance
than the legacy AMR with GMSK modulation the BSC has to make an extra power
increase to keep the experience of the original connection in the channel stable.
Source: RS team
Linked requirements: -
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
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
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.
- indicate that the channel is to be used for OSC and the number of bits used on Abis
interface as new fields OSC in Use and Bits on Abis in the Channel Mode IE. The
Bits on Abis field is meaningful only when the new CSDAP Circuit IE (introduced
below) is included in the Channel Activation message, that is, for OSC-1 channel.
- identify the OSC-1 channel with a new OSC-1 specific channel number in the
Channel Number IE.
- communicate the Training Sequence Code (TSC) to be used for OSC-1 subchannel
in the Channel Identification IE.
- include the CSDAP resource to be used for OSC-1 subchannel in the new CSDAP
Circuit IE.
For the detailed description of the fields and information elements, see chapter Abis
Telecom interface.
The BSC shall include all of the above listed OSC specific pieces of information in the
Channel Activation message for an OSC-1 subchannel.
Of the OSC specific fields above the BSC shall include for an OSC-0 subchannel the
new fields OSC in Use and Bits on Abis in the Channel Mode IE. The Bits on Abis field
has no actual meaning for an OSC-0 subchannel but the BSC shall fill the field with the
value for DHR.
Rationale:
BTS needs to informed of all the necessary details when a TCH is intended for OSC
use.
Source: SFS
Linked requirements: -
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
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
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:
Success Guarantees:
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.
Exceptions:
Step 3:
Step 5:
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:
Frequency of Occurrence:
All the time when load exceeds load limit for DHR multiplexing.
Linked requirements:
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
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:
Success Guarantees:
Exceptions:
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:
Frequency of Occurrence:
All the time when load exceeds load limit for DHR multiplexing.
Linked requirements:
6.2.29 BSS21309-030 Handover and power control thresholds for OSC DHR connections
BSC shall use OSC specific handover and power control Rx Quality thresholds
for DHR connections. For handover the thresholds are defined with the
following two parameters
For power control the Rx Quality thresholds are defined with the following four
parameters
Source: SFS:BSS21309-038
Rationale:
Linked requirements: -
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:
Linked requirements: -
6.2.31 BSS21309-032 Processing and threshold comparison of OSC DHR connections UL Rx Level
measurements
Measurement Result message that BSC receives from BTS for an individual
OSC DHR connection includes also the paired OSC DHR connection UL Rx
Level measurement, UL DTX usage indication for the same and validity bit for
indicating measurements validity. They are included in the OSC Neighbouring
Sub Channel Measurements IE in the Supplementary Measurement
Information of the Uplink Measurements Information Element. BTS includes
OSC Neighbouring Sub Channel Measurements IE only when both OSC sub
channels of a TCH have an ongoing DHR call.When OSC Neighbouring Sub
Channel Measurements IE is included but measurements are invalid BTS sets
validity, UL Rx Level and UL DTX fields to zero. This may take place when two
calls are paired as adjacent OSC DHR connections and they start to receive
measurements from each other in OSC Neighbouring Sub Channel
Measurements IE. Or it may take place during an ongoing adjacent OSC DHR
connections.
When it takes place in OSC DHR connection setup BSC shall obey the validity
bit zero value and perform handover and power control for the individual
connection as if adjacent OSC DHR connection would not exist for it. After
validity bit has once been set to 1 BSC shall ignore it and regard
Source: RS team
Rationale:
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
Source: SFS:BSS21309-027
Source: SFS:BSS21309-027
Scope: BSC
Level: Sub-function
Precondition: Both OSC sub channels of a TCH/H have an ongoing DHR call.
Minimum Guarantees:
Success Guarantees:
Trigger:
IF:
AND
THEN:
Demultiplexing handover due to UL Rx Level difference
Exceptions:
Step 1.
When OSC Neighbouring Sub Channel Measurements IE is not included in
the Measurement Result message, BSC shall consider that OSC DHR
connection does not have pair. In this case BSC shall evaluate handover
needs for a connection as without OSC.
Frequency of Occurrence:
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:
Source: SFS:BSS21309-026
Context of Use: UL Rx Levels of paired OSC DHR connections deviate too much
from each other.
Scope: BSC
Level: Sub-function
Precondition: Both OSC sub channels of a timeslot have an ongoing DHR call.
Minimum Guarantees:
Success Guarantees:
OSC DHR connection UL Rx Level is adjusted closer to the paired OSC DHR
connection UL Rx Level.
Trigger:
IF:
AV_RXLEV_UL_PC(dhr_call) – AV_RXLEV_UL_PC(paired_dhr_call) >=
OSC Multiplexing Ul Rx Level Window
AND
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
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.
Exceptions:
Step 1.
When paired OSC Neighbouring Sub Channel Measurements IE is not
included in the Measurement Result message, BSC shall consider that OSC
DHR connection does not have pair. In this case BSC shall evaluate uplink
power control needs and perform uplink power control as without OSC.
Step 4.
When uplink power control supervision timer expires BSC proceeds as in the
existing implementation. When power control interval timer expires, new uplink
power control is possible as in existing implementation.
Frequency of Occurrence:
Rationale:
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.
Linked requirements: -
The BSC shall limit the amount of half rate capable TCH resources with OSC DHR and
prevent operator from configuring an excessive amount of TCH resources without the
Soft Channel Capacity feature. When the Soft Channel Capacity is not in use the BSC
traditionally makes sure that the traffic handling capacity of a BCSU unit is not
exceeded with the configured amount of TCHs. In this examination the BSC shall
calculate a TSL, that is capable of AMR half rate traffic in a BTS with the Double Half
Rate feature active, as 3 TCHs. The BSC shall prevent actions that would lead to the
excess of TCH resources in a BCSU with the interpretation of an OSC DHR capable
TSL corresponding to 3 TCHs.
With the Soft Channel Capacity feature in use the BSC shall also regard a DHR
capable TSL as 3 TCHs when comparing the configured resources against the Soft
Channel Capacity feature’s capacity licence.
Table 3 gives an example of maximum TCH amounts for full rate, half rate and double
half rate TRX configurations in BSC3i 3000 with 500 TRXs per BCSU.
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
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
The BSC shall not apply OSC multiplexing for emergency calls.
Rationale:
Source: SFS:BSS21309-036
Linked requirements: -
The BSC shall support forced handover and forced release of the two multiplexed DHR
calls in a TCH/H when these actions have triggered in a congestion situation in order to
find a TCH/H for a new call with a higher priority.
The BSC shall prefer a non-OSC connection rather than two OSC connections in a
TCH/H as the target for the forced actions if these alternatives are regarded as equal
candidates by other criteria of the pre-emption algorithm.
For the pre-emption of both of the two DHR calls in a TCH/H to be possible requires
that the procedure is allowed for each of the DHR calls based on the connection
specific priority information.
Rationale:
Double Half Rate and Pre-emption are features that are targeted for congested
environments. It is likely that these two features are used together and, thus, the
features must co-operate.
Source: RS team
Linked requirements: -
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.
Source: SFS:BSS21309-037
Linked requirements: -
6.2.42 BSS21309-042 Blocking of DHR multiplexing due to DHR channel activation failures
The BSC has a method where it blocks a radio time slot and raises an alarm (7725
TRAFFIC CHANNEL ACTIVATION FAILURE) when the activation of a radio channel in
the TSL has failed a number of times. This procedure shall not be applied when the
successive channel activation failures take place in DHR channels during multiplexing
handovers.
Instead of blocking the radio TSL in question from use the BSC takes the TRX in
question out of DHR multiplexing activity and raises a new alarm DOUBLE HALF RATE
CHANNEL ACTIVATION FAILURE for the BTS. The BSC takes these actions when
there are several consecutive channel activation failures that take place during DHR
multiplexing in a TRX and there are no successful multiplexing cases between them.
Returning of the DHR multiplexing activity in the TRX shall require that operator turns
OSC off and then back on in the BTS. Also lock/unlock actions involving the TRX shall
cause the cancelling of the alarm.
Channel activation failures due to CSDAP problems are not included in this activity. All
CSDAP problems are handled with the activities related to another new alarm CIRCUIT
SWITCHED DYNAMIC ABIS POOL FAILURE of requirement BSS30385-026 Circuit
Switched Dynamic Abis Pool Failure alarm.
Rationale:
Problems in DHR must not prevent the use of other connection types or traffic handling
capability in general. Because of this the DHR specific channel activation failure cases
must be separated from the traditional ones that may cause blocking a radio TSL out of
use. DHR problems may have effects on DHR service only.
Operator is informed when the recovery of the normal activity needs user actions.
Source: RS team
Linked requirements: -
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.
Rationale:
The restriction is a result of internal memory limitations in Flexi EDGE BTS Odessa
DTRX. This limitation is specific to Odessa DTRX only because it is currently the only
DTRX type to support EGPRS2.
Source: SFS:BSS21309-039
Linked requirements: -
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:
By including DHR calls in the general average and peak number counters operator is
able to verify the actual number of simultaneous calls in a BTS.
Including DHR calls in the general holding time counter follows the established
practice. All calls are included in the same average counter.
Source: RS team
Linked requirements: -
The BSC’s traffic handling capacity with the Double Half Rate feature and less TRXs
shall be at least at the same level as without the feature and normal TRX amount.
Rationale:
Increased efficiency in the use of radio capacity must not lead to a decrease in traffic
handling capacity of the BSC.
Source: RS team
Linked requirements: -
When
- 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:
Linked requirements: -
Once the demultiplexing of an OSC DHR connection into a non-OSC connection has
triggered based on RX quality and the state of the AMR unpacking optimization feature
is ON the BSC shall select the target mode for the connection based on the averaged
signal level and existing parameters Intra HO Upper Rx Level Limit AMR HR and Intra
HO Lower Rx Level Limit AMR HR as follows:
Rationale:
Linked requirements: -
Rationale:
Improvements that have been found out as important for AMR calls should be applied
also for OSC DHR calls.
Source: RS Review
Linked requirements: -
For a DFCA OSC connection TSC must be selected among the possible TSC pairs
shown in table 2 of requirement BSS21309-009 Optimized TSC pairs, that is,
if the first connection uses TSC 0 or 1 then BSC shall select TSC 2, 3, or 7 for
the second OSC connection
if the first connection uses TSC 2 then BSC shall select TSC 0, 1 or 5 for the
second OSC connection
if the first connection uses TSC 3 then BSC shall select TSC 0, 1 or 4 for the
second OSC connection
if the first connection uses TSC 4 then BSC shall select TSC 3 or 6 for the
second OSC connection
if the first connection uses TSC 5 then BSC shall select TSC 2 or 6 for the
second OSC connection
if the first connection uses TSC 6 then BSC shall select TSC 4 or 5 for the
second OSC connection
if the first connection uses TSC 7 then BSC shall select TSC 0 or 1 for the
second OSC connection.
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.
The BSC shall use DHR specific C/I target values when it performs DFCA C/I
calculation for a DHR connection. When incoming and outgoing interference is defined,
C/I calculations are done individually for both OSC connections in the HR channel.
With OSC the DHR calls use simultaneously the channel and hence both calls cause
interference no matter if the call is using OSC-1 or OSC-0 channel. For outgoing
interference a -1dB offset, in addition to HR offset, is used because a DHR call causes
less interference than a HR call.
The target channel of DHR multiplexing already includes a call that is using proper
power levels for UL and DL. In UL C/I calculation it must be taken into account that UL
RX level is set to be in a defined range from the existing connection. The range is
defined by the new OSC Multiplexing UL Rx Level Window parameter. This limits the
power reduction. For DL direction power reduction max is the reduction that is currently
in use in the target channel.
Rationale:
DHR specific parameters and restrictions have to be taken into account in the C/I
calculations of DFCA.
Linked requirements: -
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
Linked requirements: -
In OSC multiplexing on a DFCA channel the BSC shall prefer a DFCA channel where
C/I for both connections (the call that already exists in the channel and the call that is
handed over to the channel) is above C/I target DHR. Channels between C/I target
DHR and C/I soft blocking DHR can be only used if there are no other possibilities
available.
When C/I check is done the possible DL power increase of the existing connection
must be taken into account. It is possible that the DL RX level of the new connection is
too low and it would cause too high power increase for the existing connection that
would lead to an outgoing soft blocking situation.
Rationale:
In pairing with DFCA both of the connections have to fulfill the criteria defined for single
DHR connections but also the combined effect of the two connections must remain
within acceptable limits.
Source: RS team
Linked requirements: -
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
- GTRX = Y.
Note that this is not a general definition for an EGPRS TRX but to be used for this OSC
specific procedure only.
If a TRX in a Flexi EDGE BTS is not an EGPRS TRX the BSC shall start the TRX as an
OSC TRX by including a new OSC indication field for the TRX in the BTS_CONF_DATA
message. If BB Hopping or Antenna Hopping is used in a BTS and there is an EGPRS
TRX in the BTS then BSC shall not indicate OSC use for any of the TRXs in the BTS.
The BSC does not know the TRX HW variant of the Flexi EDGE BTS (Epsilon or
Odessa) until it receives the BTS_STATE_CHANGED message. For the procedure to
be general, the BSC does these actions always in the case of a Flexi EDGE BTS.
In Odessa TRX OSC and EGPRS can co-operate without limitations. BSC shall
conclude the TRX HW variant between Epsilon and Odessa based on the Air interface
modulation capability that it receives in the BTS_STATE_CHANGED message from the
BTS /G/.
The BSC shall be able to apply OSC in the TRXs that it has started with the OSC
indication included in BTS_CONF_DATA.
In a configuration where neither BB hopping nor Antenna hopping is used the BSC
shall be able to apply OSC in an Odessa TRX even though it did not indicate OSC use
to the BTS in BTS_CONF_DATA.
In a BB hopping or Antenna hopping configuration where the BSC has not indicated
OSC use for any of the TRXs in the BTS_CONF_DATA the BSC shall be able to apply
OSC in the BTS only if all the TRXs in the BTS are of Odessa HW variant.
Rationale:
The Epsilon specific restrictions in the common use of OSC and EGPRS need to be
addressed in the relevant customer documents.
Linked requirements: -
6.5.2 BSS21309-007 Independent DTX control for each OSC subchannel, REJECTED
BSC shall enable DL DTX separately for the OSC subchannels that are sharing the
same radio channel.
Rationale:
This requirement causes no additional change in the BSC but has been inherited from
the SFS to ensure the following activity that is required in the BTS:
With DTX in use BTS shall send GMSK for the active channel instead of QPSK. This
enables power savings because with GMSK it is possible to use lower output power
than with QPSK.
Source: SFS:BSS21309-042
Linked requirements: -
6.5.3 BSS21309-011 BSC shall allocate AMR HR calls as OSC calls, REJECTED
When OSC has been enabled in a BTS the BSC shall allocate HR TCHs for normal
non-OSC AMR calls as OSC-0 connections in the BTS for the SAIC supporting MSs.
Rationale:
Starting a normal AMR HR call as an OSC connection right from the beginning gives
the possibility to implement the OSC multiplexing simply by adding another OSC
connection into the channel later when the traffic load calls for further packing of traffic
in the BTS. Thus, the original connection does not need to be moved with a handover
and also there is data available of the conditions on the channel to be utilized when the
actual OSC multiplexing is made.
In the air interface the BTS uses dynamically GMSK or QPSK modulation according to
if there is only one or if there are two OSC connections in a channel. When there is
only one OSC connection in a TCH/H the channel performs as a traditional AMR HR
TCH.
Source: RS team
Linked requirements: -
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.
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.
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.
3. When place of CSDAP can be allocated freely it does not require Abis
ETPCM timeslot reallocation when feature is taken to use.
Linked requirements:
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.
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.
Description:
CSDAP information shall be added to BCF radionetwork object because CSDAP is
BCF object level item.
There shall be maximum 4 separate CSDAPs attached to one BCF, but a single
CSDAP can be connected to only one BCF.
The BCF radio network object shall contain the new radio network parameters:
Attached CSDAP 1
Attached CSDAP 2
Attached CSDAP 3
Attached CSDAP 4
Source: Internal
Rationale:
Attached CSDAP describes the relation between CSDAP and BCF. Maximum at 4
CSDAP per BCF and 1 BCF per CSDAP.
When there are several CSDAPs attached to one BCF then a possible fault situation in
one CSDAP (or Abis ETPCM) does not totally prevent OSC capability in the BCF.
CSDAP capacity can be increased later for BCF by attaching new Abis ET-PCMs to
BCF.
Order number in the parameter name indicates hunting order between attached
CSDAPs. Abis transmission is first hunted from the CSDAP that is found from the
Attached CSDAP 1 parameter and then from the Attached CSDAP 2 parameter and so
on.
Linked requirements:
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)
Source: Internal
Rationale:
There are not enough circuit groups in BSC when maximum amount of legacy DAPs
and CSDAPs is created.
Linked requirements:
Description:
BSC shall send information of all CSDAPs that are attached to BCF to BTS in
BTS_CONF_DATA message when:
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:
Linked requirements:
Source: BSS21309-009
Scope: BSC
Level: User-goal
Minimum Guarantees:
Success Guarantees:
Trigger:
BCF is unlocked
BCF reset
d. whether the timeslots have been already allocated for some other
use
Exceptions:
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
Frequency of Occurrence:
Everytime when:
BCF is unlocked
BCF reset
Linked requirements:
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
Minimum Guarantees:
Success Guarantees:
Trigger:
Exceptions:
BCF is left to LOCKED state. BSC shall inform operator about the failure in
execution printout.
Frequency of Occurrence:
Linked requirements:
Scope: BSC
Level: User-goal
Precondition: Abis ETPCM has been created between BSC and BCF. CSDAP ID
does not exist in BSC.
Minimum Guarantees:
Success Guarantees:
CSDAP ID
Abis ETPCM
First Timeslot
BCF Abis IF
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
5. BSC shall change the working state of the virtual circuits from BA to WO.
Exceptions:
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.
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.
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.
BSC shall reject the CSDAP creation if the radio network configuration
database update fails. BSC shall remove all routings created for the CSDAP
and then the BSC shall inform operator about the failure in execution
printout.
Frequency of Occurrence:
When OSC DHR feature is taken into use in BCF or, when more CSDAP
capacity is needed for OSC calls to BCF.
Linked requirements:
Scope: BSC
Level: User-goal
Minimum Guarantees:
Success Guarantees:
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
4. BSC shall check that the CSDAP exists and the command parameters
are acceptable. BSC shall reserve the related BCF object for
modification.
5. BSC shall set penalty (90 s) for the CSDAP that prevents new resource
allocations from the CSDAP during the modification procedure. The BSC
shall perform forced release for the ongoing calls using the modified
CSDAP (The same method is used as during BCSU restart).
6. BSC shall add new physical Abis ETPCM timeslots to circuit group called
"ETPCM".
7. BSC shall add new virtual circuits that corresponds the subtimeslots
0,1,2,3,4,5,6,7 to the CDAPxxxx circuit group.
8. BSC shall change the working state of the new CSDAP virtual circuits
from BA to WO.
9. BSC shall write the updated CSDAP information to the radio network
configuration database.
11. BSC shall cancel the penalty from the CSDAP after the procedure is
successfully completed.
12. BSC shall inform operator about the procedure completion in execution
printout.
Exceptions:
BSC shall reject the CSDAP modification and then the BSC shall inform
operator about the failure in execution printout if
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
BSC shall reject the CSDAP modification if adding of the new virtual circuits
to the CDAPxxxx circuit group fails. BSC shall remove the new routings
created for the CSDAP and then the BSC shall inform operator about the
failure in execution printout.
BSC shall reject the CSDAP modification if the radio network database
update fails. BSC shall remove all new routings created for the CSDAP and
then the BSC shall inform operator about the failure in execution printout.
Frequency of Occurrence:
Linked requirements:
Scope: BSC
Level: User-goal
Minimum Guarantees:
Success Guarantees:
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
3. BSC shall check that the CSDAP exists and all the command
parameters are acceptable. BSC shall reserve the related BCF object for
modification.
4. BSC shall set penalty (90 s) for the CSDAP that prevents new resource
allocations from the CSDAP during the modification procedure. The BSC
shall perform forced release for the ongoing calls using the modified
CSDAP (The same method is used as during BCSU restart).
5. BSC shall change the working state of the removed CSDAP virtual
circuits from WO to BA.
6. BSC shall remove the virtual circuits that corresponds the subtimeslots
0,1,2,3,4,5,6,7 of the removed circuits from the CDAPxxxx circuit group.
7. BSC shall remove the removed physical Abis ETPCM timeslots from the
circuit group called ETPCM.
8. BSC shall write the updated CSDAP information to the radio network
configuration database.
10. BSC shall cancel the penalty from the CSDAP after the procedure is
successfully completed.
11. BSC shall inform operator about the procedure completion in execution
printout.
Exceptions:
BSC shall reject the CSDAP modification and then the BSC shall inform
operator about the failure in execution printout if
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.
If the removal of some routings fails, BSC shall write explanation of the
failure to MCMU computer log and continue the procedure.
BSC shall reject the CSDAP modification if the radio network configuration
database update fails. BSC shall restore all the removed routings for the
CSDAP and then BSC shall inform operator about the failure in execution
printout.
If BSC receives negative acknowledgement from BTS then the BSC shall
inform operator about the failure in execution printout.
Frequency of Occurrence:
When Abis timeslots are taken to some other use in Abis ETPCM.
Linked requirements:
Scope: BSC
Level: User-goal
Precondition: CSDAP has been created to Abis ETPCM. CSDAP has not been
attached to any BCF.
Minimum Guarantees:
Success Guarantees:
1. Operator shall configure Abis transmisson to BCF for the new CSDAP
before attaching CSDAP to BCF in BSC.
BCF id
3. BSC shall check that the CSDAP(s) exist and it has not been attached to
any BCF.
7. CSDAP(s) are ready for use and BSC can start hunting resources.
Exceptions:
Step 3. CSDAP does not exist or it has been already attached to some BCF.
BSC shall reject the request. BSC shall inform operator about the failure in
execution printout.
BSC shall reject the CSDAP attachment if the radio network configuration
database update fails. BSC shall inform operator about the failure in
execution printout.
Frequency of Occurrence:
When OSC DHR feature is taken into use in BCF or, when more
CSDAP capacity is needed for OSC calls to BCF.
Linked requirements:
Scope: BSC
Level: User-goal
Minimum Guarantees:
Success Guarantees:
BCF id
3. BSC shall set penalty (90 s) for the CSDAP that prevents new resource
allocations from the CSDAP during the detach procedure. The BSC shall
perform forced release for the ongoing calls using the detached CSDAP
(The same method is used as during BCSU restart)..
4. BSC shall detach the CSDAP from the BCF in radio network
configuration database.
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.
Frequency of Occurrence:
Linked requirements:
Scope: BSC
Level: User-goal
Minimum Guarantees:
Success Guarantees:
CSDAP ID
2. BSC shall check that CSDAP does not have attachment to BCF object.
3. BSC shall remove the CSDAP information from the radio network
configuration database.
4. BSC shall change the working state of the virtual circuits that
corresponds the subtimeslots 0,1,2,3,4,5,6,7 from WO to BA.
6. BSC shall remove physical Abis ETPCM timeslots from the ETPCM
circuit group.
Exceptions:
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.
If removal of the circuits fails because they are not free, BSC shall release
connections from all virtual circuits corresponding subtimeslots
0,1,2,3,4,5,6,7 and continue the procedure.
If removal of some routings fails, BSC shall write explanation of the failure to
MCMU computer log and continue the procedure.
Frequency of Occurrence:
Linked requirements:
Description:
Bit-based hunting shall be used to allocate resources from CSDAP.
Only the 1 bit hunting is required for DHR. Other granularities are left for further
releases.
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.
Linked requirements:
Description:
BSC shall be able to handle 10 simultaneous hunting operations from a single CSDAP.
Rationale:
Linked requirements:
Context of Use: Abis transmission resources are allocated for an OSC-1 call.
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:
1. BSC shall start OSC multiplexing when BTS cell load exceeds the
load threshold as described in requirement BSS21309-015
Triggering of 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.
Exceptions:
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
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.
BSC shall not include channel activation failures for DHR channels in the
activity that currently may result in raising of alarm 7725 TRAFFIC
CHANNEL ACTIVATION FAILURE and locking of a radio time slot.
BSC shall release the allocated CSDAP resources after failed channel
activation.
Frequency of Occurrence:
Linked requirements:
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.
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.
Linked requirements:
Context of Use: Releasing of CSDAP resources after call release OSC-1 DHR call.
Scope: BSC
Level: User-goal
Minimum Guarantees:
Success Guarantees:
Exceptions:
BSC shall release the connection from the Abis-interface (CSDAP) circuit.
Frequency of Occurrence:
Linked requirements:
Scope: BSC
Level: User-goal
Minimum Guarantees:
Success Guarantees:
released between the A-interface circuit and the source Abis circuit just
before making the two-way connection)
Exceptions:
BSC shall release the connection from the source Abis-interface (CSDAP)
circuit.
Frequency of Occurrence:
Linked requirements:
Scope: BSC
Level: User-goal
Minimum Guarantees:
Success Guarantees:
released between the A-interface circuit and the source Abis circuit just
before making the two-way connection)
Exceptions:
BSC shall release the connection from the source Abis-interface (CSDAP)
circuit.
Frequency of Occurrence:
Linked requirements:
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:
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.)
Exceptions:
BSC shall release the connection from the target Abis-interface (CSDAP)
circuit.
Frequency of Occurrence:
Linked requirements:
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.
Linked requirements:
Scope: BSC
Level: User-goal
Precondition:
Minimum Guarantees:
Success Guarantees:
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.
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.
Exceptions:
Step 3. If there are not any working circuits in the CSDAP then the
BSC restarts the penalty timer.
Frequency of Occurrence:
Linked requirements:
Source: Internal
Scope: BSC
Level: User-goal
Actors: BSC
Precondition:
Minimum Guarantees:
Success Guarantees:
BSC allows resource allocations from the CSDAP and cancels the alarm
after penalty period is exceeded and the fault situation has disappeared.
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.
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.
Frequency of Occurrence:
Linked requirements:
New alarm CIRCUIT SWITCHED DYNAMIC ABIS POOL FAILURE shall be defined to
indicate failure situations concerning a single CSDAP.
In case of remote transcoder failures, hunting errors or, channel activation failures the
alarm is cancelled after the penalty timer has expired and, one successful resource
allocation and normal release from the CSDAP has been performed. This way alarm
pumping is avoided in long lasting failure situations.
In case of missing CSDAP configuration the alarm is cancelled when a CSDAP is
attached to the BCF.
In case of the CSDAP feature is not active the alarm is cancelled when the feature is
activated.
The alarm is CSDAP specific and it contains the next field elements:
CSDAP ID
BCF id
cause code
This is two star (**) alarm, which means that it requires action in normal working hours.
Source: SFS: BSS21309-020
Rationale:
Operator is able to detect malfunction on a single CSDAP.
Linked requirements:
Description:
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.
Source: SFS:BSS21309-021
Rationale:
Linked requirements:
7.6.2 BSS30385-030 Abis loop test shall be done for each CSDAP attached to BCF during
automatic comissioning test
Description:
Abis loop test shall be done for each CSDAP attached to BCF during automatic
comissioning test when BTS request BSC to start testing with
BTS_COMMISS_TEST_REQ message.
The first 16 kbit/s timeslot and the last 16 kbit/s timeslot shall be tested from each
CSDAP with Abis loop test during automatic comissioning test.
Source: Internal
Rationale:
Testing of the first 16 kbit/s timeslot and the last 16 kbit/s timeslot is enough to ensure
CSDAP operation.
Linked requirements:
Scope: BSC
Level: User-goal
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.
2. Operator shall define Abis loop test for the CSDAP timeslot with
MML. Operator shall enter the following parameters in the command:
TRX number
CSDAP ID (1..1000)
looping time
CSDAP exists
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.
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 shall reject the test request if the changing state of the circuits fails.
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.
BSC shall reject the test request if loop connection fails. State of the
circuits is changed from BA to WO.
Frequency of Occurrence:
Linked requirements:
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
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
Linked requirements:
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
Source: SFS: BSS21309-018
Rationale:
Operator is able to detect lack of CSDAP resources attached to the BCF / (BTS).
Linked requirements:
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.
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.
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.
There is no need for conversion from the value of the UTPFIL parameter to the new
BSC parameter during SW upgrade because the UTPFIL parameter has not been
officially used in any operator’s network.
Assured Channel Capacity defines the amount of TCH capacity the BSC shall try to
make sure is available in each TRX of a BCSU unit. The parameter shall have a value
in range 1…8. The guaranteed capacity in a TRX shall not exceed the TCH TSL
amount of the TRX. If a TRX has less TCH TSLs than the value of the Assured
Channel Capacity the BSC shall use the actual TCH TSL amount as the target for the
guaranteed capacity in the TRX. The parameters default value 8 practically means that
Dynamic Soft Channel Capacity is not in use.
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.
Source: RS team
Rationale:
This parameter is needed for managing the capacity licence based on TRX amount.
Linked requirements:
9 SYSTEM EFFECTS
9.1.1.1 Parameters
Explanation of the rightmost columns of the table:
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.
12.8%
(7)
1.6% -
3.2%
(4),
3.2% -
6.4%
(5),
6.4% -
12.8%
(6), >
12.8%
(7)
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
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
NOTE:
NOTE: DXPFIL
)
MML Modification: Read-only,
the value is automatically
selected during CSDAP
creation.
Range:
NOTE: 2048..3391 is
reserved for OC-3/T1
administration area.
NOTE:
NOTE:
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.
NOTE:
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.
NOTE: Modification is
possible only when the
CSDAP has not been
attached to BCF.
- consecutive remote
transcocder failures
- hunting error(s)
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
9.1.2 Monitoring
9.1.2.1 Alarms
related to these
BSC Level Clear Code Modified New Double Half Rate specific
(PM) Measurement counters for multiplexing and
demultiplexing handovers
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
New counters
algorithm.
CSDAP congestion
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.
PEAK BUSY DHR TCH Resource Description: Peak number of the busy
Availability double half rate TCHs within a
Measurement measurement period.
Modified counters:
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.
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:
No changes.
No changes.
For Double Half Rate related MMI printouts see requirements BSS21309-003 TRX
parameter for OSC support and BSS21309-005 DHR channels in MML printouts.
Double half rate resources shall be included in E00HAN servive terminal extension
printouts with the same accuracy as traditional radio channel resources currently.
Service terminal extensions E01HAN, ABMONI and TGMONI to be updated due to the
Double Half Rate feature.
The BSC shall deploy OSC on a call-by-call basis. The BSC gives OSC subchannel
identification, training sequence code, amount of bits used on Abis interface and
CSDAP resource to BTS in Channel Activation message, see /1/.
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
1 OSC is 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:
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
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.
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
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:
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.
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
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
Octet N+M+K+2 contains DTXu information. The DTXu bit indicates whether uplink DTX
was employed by the mobile on the neighbouring OSC sub channel during the
measurement period
When BTS Measure Average (BMA) is set to value 2...4 BTS shall report fields in
Neighbouring Sub Channel Measurement IE according to the next table:
BTS shall provide info about FlexiEDGE BTS OSC support for BSC.
BSC shall provide CSDAP configurations for BTS in BTS_CONF_DATA with a new
CSDAP IE.
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.
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.
9.2.2.2.1 CSDAP IE
NOTE 2: Time slot shift offset between Abis ETPCM and Abis IF timeslots.
NOTE 3: Pool timeslots are reported as they are from BSC's viewpoint.
Range: 1...31
Note 1: range 0 = TRX shall start in EGPRS mode, 1 = TRX shall start in OSC mode
9.2.2.3.1 CSDAP id
9.2.2.5 Ack-Nack
? N_CSDAP_ABIS_IF_NOT_IN_USE_1 Abis IF is not in use in BCF. This cause code refers to the
first CSDAP IE in the BTS_CONF_DATA message.
? N_CSDAP_ABIS_IF_NOT_IN_USE_2 Abis IF is not in use in BCF. This cause code refers to the
second CSDAP IE in the BTS_CONF_DATA message.
? N_CSDAP_ABIS_IF_NOT_IN_USE_3 Abis IF is not in use in BCF. This cause code refers to the
third CSDAP IE in the BTS_CONF_DATA message.
? N_CSDAP_ABIS_IF_NOT_IN_USE_4 Abis IF is not in use in BCF. This cause code refers to the
fourth CSDAP IE in the BTS_CONF_DATA message.
? N_CSDAP_OUT_OF_BOUND_1 CSDAP timeslots exceed the E1/T1 bounds. This cause
code refers to the first CSDAP IE in the BTS_CONF_DATA
message.
? N_CSDAP_OUT_OF_BOUND_2 CSDAP timeslots exceed the E1/T1 bounds. This cause
code refers to the second CSDAP IE in the
BTS_CONF_DATA message.
? N_CSDAP_OUT_OF_BOUND_3 CSDAP timeslots exceed the E1/T1 bounds. This cause
code refers to the third CSDAP IE in the
BTS_CONF_DATA message.
? N_CSDAP_OUT_OF_BOUND_4 CSDAP timeslots exceed the E1/T1 bounds. This cause
code refers to the fourth CSDAP IE in the
BTS_CONF_DATA message.
? N_CSDAP_OVERLAP_1 CSDAP timeslot are overlapping with other Abis
resources. This cause code refers to the first CSDAP IE in
the BTS_CONF_DATA message.
? N_CSDAP_OVERLAP_2 CSDAP timeslot are overlapping with other Abis
resources. This cause code refers to the second CSDAP
IE in the BTS_CONF_DATA message.
? N_CSDAP_OVERLAP_3 CSDAP timeslot are overlapping with other Abis
resources. This cause code refers to the third CSDAP IE
in the BTS_CONF_DATA message.
? N_CSDAP_OVERLAP_4 CSDAP timeslot are overlapping with other Abis
resources. This cause code refers to the fourth CSDAP IE
in the BTS_CONF_DATA message.
? N_CSDAP_RESOURCE_UNAVAILAB CSDAP does not exist or the the timeslot does not belong
LE to CSDAP.
9.3 Compatibility
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.
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.
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.
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.
The BSC shall not apply DHR multiplexing for emergency calls.
The BSC shall not apply DHR multiplexing for calls in dual transfer mode (DTM).
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.
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.
The BSC shall not apply OSC in BB hopping and Antenna hopping BTS objects where
TRXs have varying OSC capability.
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.
OSC shall not be supported in the TRXs of the extended coverage area.
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.
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.
The BSC does not apply DHR multiplexing in a TRX that has Double Power TRX
(DPTRX) feature in use.
The BSC does not apply DHR multiplexing in a TRX that has Intelligent Downlink
Diversity (IDD) feature in use.
The BSC does not apply DHR multiplexing in a TRX that has 4-way uplink diversity
(4UD) feature in use.
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.
9.8 Testing
BSC (S15)
o AMR HR
o SAIC
o CSDAP
o Packet Abis
o DFCA
o BB Hopping
o Antenna Hopping
Flexi BTS
o Odessa TRXs
o Epsilon TRXs
Abis transmission
o Packet Abis
Several MSs
o AMR HR capable
o SAIC capable
o AMR HR support
New information elements used in Abis O&M and Abis Telecom interface have to
supported by
TTCN tester
9.9 Restrictions
See requirements
See also chapter Interaction with other features or functionalities for the restrictions
there are in the interactions with other features.
To be examined.
Not available.
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.
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
https://sharenet-ims.inside.nokiasiemensnetworks.com/Open/391651404
Clear Case:
Not relevant.