GEMINI features

LAPD multiplexing

• LAPD multiplexing in GEMINI (1/9): overall aspects

• LAPD multiplexing aims at optimizing usage of the LAPD channels by reduction of required
signaling bandwidth

• Up to now on Abis interface controlled by the BSC3i/FlexiBSC a dedicated LAPD signaling

channel is foreseen for each TRX
Each logical LAPD link called TRXSIG has
its own physical channel created on PCM line

• In GEMINI, when BSC3i/FlexiBSC controls BTSplus, several TRXs can be multiplexed in the
same LAPD (just like for Flexible Abis), allowing all the TRXs belonging to the same site to be
configured on one common physical LAPD link Several logical LAPD links are multiplexed within
a single physical channel created on PCM line

For internal use

1 © Nokia Siemens Networks Gemini / April 2009 / SA NE
GEMINI features
LAPD multiplexing

• LAPD multiplexing in GEMINI (2/9): implementation overview

• up to 11 LAPD links per BTSplus are configurable for TRX signaling and O&M part
– several TRXs (i.e. TRXSIG channels) are multiplexed in a single physical LAPD link
– OMUSIG channel is also multiplexed in one of physical LAPD links
– up to 16 logical LAPD connections can be multiplexed into one physical LAPD link (upper limit)
– the actual number of logical connections per physical link is subject to dimensioning (as it depends on
many factors: site configuration, traffic profile, LAPD link capacity, …) => refer to here for details
• physical LAPD links can have capacity of 16 kbps or 32 kbps or 64 kbps
– physical LAPD links with different bitrates can be created within the same site
(impossible in BR implementation as well as the usage of 32 kbps physical LAPD links)
– each Abis line needs to have (at least) 1 physical LAPD link created, several physical LAPD links can
be created onto a single PCM line (but a single physical link must not be spread over several PCM
lines)
• existing (BSS) LAPD related objects are used in GEMINI to manage LAPD multiplexing
– distribution of TRXSIG/OMUSIG among available physical LAPD links is done manually
– refer to here for TRXSIG/OMUSIG “mapping rules”
up to 11 physical LAPD links per site

up to 16 logical LAPD channels per physical link

(each TRXSIG/OMUSIG corresponds to a single
logical LAPD connection)
For internal use
2 © Nokia Siemens Networks Gemini / April 2009 / SA NE
GEMINI features
LAPD multiplexing

• LAPD multiplexing in GEMINI (3/9): implementation overview

• LAPD multiplexing is feature of LAPD protocol which, for each logical connection that is
multiplexed into common physical LAPD link, assures:
– independent message flows with their own sequence control,
– flow control, re-transmission, re-synchronization, …

• Each logical LAPD connection inside a physical LAPD link is unambiguously identified within
site by TEI+SAPI pair
TEI: Terminal Endpoint Identifier
SAPI: Service Access Point Identifier

• The following coding is in use for LAPD multiplexing in GEMINI:

fixed ID, not configurable
– OMUSIG: SAPI = 62, TEI = 1
implicitly known ID, retrieved automatically based on TRX-id,
– TRXSIG: SAPI = 0, TEI = TRX-id
TRX-id within site must be unique in GEMINI

• When LAPD multiplexing is in use then all TRXSIG and OMUSIG channels sharing the same
physical link, must be configured to the same BCSU unit (and the same signaling terminal AS7):
– it means that in GEMINI all TRXs belonging to given BSxx must be assigned to the same BCSU and
AS7 (when they are mapped to a single LAPD link)
all TRXSIG/OMUSIG that are multiplexed in the same physical LAPD link must have:
-> the same BITRATE (cf. command ZDSE)
-> the same BCSU-id (cf. command ZDSE) and LOG TERM-id (by means of AS7 resource manager)
For internal use
3 © Nokia Siemens Networks Gemini / April 2009 / SA NE
GEMINI features
LAPD multiplexing

• LAPD multiplexing in GEMINI (4/9): LAPD related attributes

• Pre-defined set of LAPD attributes is defined to simplify configuration of LAPD links for
FlexiBTS and BTSplus
The number of I-frames that may be sent
without any acknowledgement from
the opposite side

“No response” timer: defines timeout for

initiating retry or declaring failure.

“No traffic” timer: defines timeout for

initiating link integrity check (if no traffic
received in the meantime).

Max frame size in

Max number of frame retransmissions: an information field
when no acknowledgement received after
T200 * (N200 + 1) ms then an ERROR INDICATION
with cause 'T200 expired N200+1 times' is sent

Parameter Description
Parameter Set Number object: LAPD Parameter Set Number (parameterSetNumber), with this parameter you define
range: the used predefined parameter set of LAPD in LAPD creation.
0 (Standard Abis setup)
1 (Satellite Abis setup)
2 (BTSplus Abis setup) Note:
3 (BTSplus Satellite Abis setup) For FlexiBTS in addition to the values reported in the table above it is possible to have the following set
4 (IP Abis setup 1) of LAPD attributes:
5 (IP Abis setup 2 - for long delays), Parameter Set 0, SAPI = 61: window size = 1, T200 = 40 ms, T203 = 10 s, N200 = 18, N201 = 260
6 (IP Abis setup 3 - for low quality lines) Parameter Set 1, SAPI = 61: window size = 1, T200 = 40 ms, T203 = 10 s, N200 = 18, N201 = 260
default: 0
MML command: DSE
For internal use
4 © Nokia Siemens Networks Gemini / April 2009 / SA NE
GEMINI features
LAPD multiplexing

• LAPD multiplexing in GEMINI (5/9): LAPD redundancy

• TRXSIG concept
– after failure of physical LAPD where BCCHTRX has its TRXSIG, BSC3i will move BCCH to other TRX
(which has its TRXSIG running) leading to loss of another (non-BCCH) TRX
▪ a TRXSIG failure is not indicated via alarm, only a warning (12316) is logged in the BTS internal alarm buffer
– in case of PCM failure the concept is only efficient when we have 2 PCM lines per site and TRXSIG
are distributed over both PCM lines
– failure of the physical link where TRXSIG related to non-BCCH TRX is mapped triggers no recovery
action... SAPI0, TEI0
SAPI0, TEI1
SAPI0, TEI3
SAPI0, TEI4
SAPI0, TEI8
LAPD1
BCCH TRX0 TRX1 TRX2 cell1

BCCH TRX3 TRX4 TRX5 cell2 BTSplus GEMINI

BSC3i
BCCH TRX6 TRX7 TRX8 cell3 LAPD2
SAPI0, TEI2
SAPI0, TEI5
After failure of LAPD2 the 3rd cell’s SAPI0, TEI6
BCCH is moved to TRX8 SAPI0, TEI7
SAPI62, TEI1

• OMUSIG: no redundancy
– after failure of physical LAPD link where OMUSIG was mapped, the BSC3i will not do any recovery
actions
▪ an OMUSIG failure will trigger the alarms: 12318 (LAPD link protocol failure), 7706 (BTS and O&M link failure)
For internal use
5
and 7704
(PCM failure).
© Nokia Siemens Networks Gemini / April 2009 / SA NE
GEMINI features
LAPD multiplexing

• LAPD multiplexing in GEMINI (6/9): LAPD overload handling

• uplink (stepwise mechanism):
– Step 1: smooth reduction of measurement results (MR) messages
– load of LAPD links estimated on the basis of LAPD usage (the number of bytes which are
transmitted over Abis during predefined period of time) computed every LAPDOVLT0 sec
– lower and upper load thresholds defined and depending on LAPD usage the actual MR load is
subject to REDUCTION (MR messages are discarded randomly irrespective of their purpose
and origin)
USG > firstLevelUpperThreshold then REDUCTION = 100 (i.e. all MR are discarded)
firstLevelLowerThreshold < USG ≤ firstLevelUpperThreshold then REDUCTION = min(100, REDUCTION + firstLevelReductionStep)
firstLevelLowerThreshold ≥ USG then REDUCTION = max(0, REDUCTION - firstLevelReductionStep)

USG [%]

firstLevelUpperThreshold

firstLevelLowerThreshold

max(0,0-10) min(100,0+10) min(100,20+10) 100 min(100,100+10)

min(100,100+10)min(100,100+10) LAPDOVLT0 [sec]
Initial state: max(0,0-10) min(100,10+10) 100 100 min(100,100+10)max(0,100-10)
min(100,100+10)
REDUCTION = 0 REDUCTION [%] = 0 0 10 20 30 100 100 100 100 100 100 100 100 90 80

Parameter settings:
LAPDOVLT0 = 1 sec
firstLevelReductionStep = 10 When upper threshold is exceeded (even for a while) then all MR are discarded
until usage drops below lower threshold.
Next, MR load is ramped up stepwise until usage exceeds lower threshold.
For internal use
6 © Nokia Siemens Networks
After that, MR load is ramped down stepwise...
Gemini / April 2009 / SA NE
GEMINI features
LAPD multiplexing

• LAPD multiplexing in GEMINI (7/9): LAPD overload handling

• uplink (stepwise mechanism):

0% 100
1L 1H 2L 2H %
ramp up MR load
LAPD overload
- with step of 10%/sec
- discard low/medium prio messages
- except init phase
suspend MR load
ramp down MR load
- with step of 10%/sec
- expect the case just after 1H exceeding
(when MR load is totally discarded)

– All parameters that control LAPD overload handling are hardcoded in GEMINI. These are:
FLAPDOVLTH:
firstLevelLowerThreshold = 60% (referred to as “1L” in the figure above)
firstLevelUpperThreshold = 80% (referred to as “1H” in the figure above)
firstLevelReductionStep = 10%
LAPDOVLT0 = 1 sec
SLAPDOVLTH:
secondLevelLowerThreshold = 80% (referred to as “2L” in the figure above)
secondLevelUpperThreshold = 90% (referred to as “2H” in the figure above)

– There are 2 parameters introduced in GEMINI to control rate of MR messages. These are: SDCCH
MR Sending, Interval MR Sending.
For internal use
7 For details refer to https://sharenet-ims.inside.nokiasiemensnetworks.com/Open/407567011
© Nokia Siemens Networks Gemini / April 2009 / SA NE
GEMINI features
LAPD multiplexing

• LAPD multiplexing in GEMINI (8/9): LAPD overload handling

• uplink (stepwise mechanism):

0% 100
1L 1H 2L 2H %
ramp up MR load
LAPD overload
- with step of 10%/sec
- discard low/medium prio messages
- except init phase
suspend MR load
ramp down MR load
- with step of 10%/sec
- expect the case just after 1H exceeded
(when MR load is totally discarded)

– Step 2: priority based discarding messages (2L ↔ 2H)

– three priority levels defined for LAPD messages
HIGH MEDIUM LOW
all TELECOM CHAN_REQ TMEASRES,
messages MEAS_RESULT

– high prio messages are not discarded

– medium and low prio messages are discarded when queue length exceeds hardcoded limits
(of 45 and 30 messages, respectively) => these messages should be sent in unacknowledged mode
(in UI-frames)
– no degradation of call processing will be observed if measurement results are lost
– any loss of channel required messages is compensated by the MS itself (as it re-sends
For internal use
8
Random Access if no response
© Nokia Siemens Networks
from the BTS is received within the specified time)
Gemini / April 2009 / SA NE
GEMINI features
LAPD multiplexing

• LAPD multiplexing in GEMINI (9/9): LAPD overload handling

• uplink (stepwise mechanism):

0% 100
1L 1H 2L 2H %
ramp up MR load
LAPD overload
- with step of 10%/sec
- discard low/medium prio messages
- except init phase
suspend MR load
ramp down MR load
- with step of 10%/sec
- expect the case just after 1H exceeded
(when MR load is totally discarded)

– Step 3: all frames which do not fit in transmit queues are discarded, no re-ordering or selection of
certain message types performed (2H ↔ 100%)
– Note: LAPD overload message is not sent to BSC in GEMINI

• downlink:
– main reason for overload: paging load
– BSC observes its transmit queues, when they reach certain length paging and immediate assignment
reject messages are discarded
– LAPD overload in DL is also additionally prevented by BCSU processor overload protection
mechanism
For internal use
9 © Nokia Siemens Networks Gemini / April 2009 / SA NE