You are on page 1of 122

B11 MR1 Ed1.

0
Seminar of GSM Network Engineering
Support of CS Paging Coordination in the BSS

Ramy Adel
March 2010

Reference Documentation
SFD
Enhanced DTM & Paging Coordination Release B11 (3BK 10204 0104 DTZZA)
Dual Transfer Mode (3BK 10204 0032 DTZZA)

Step 2
Paging, Access Grant Control and Notification, B11 (3BK 11202 0495 DSZZA)
(E)GPRS Radio Interface - RRM Sublayer PCC (3BK 11202 0513 DSZZA), chapter 5.3

MEMO
B11 Support of Paging coordination in the BSS (Wireless/GSM/R&D/SYT/ rma/036.2007
Ed.02)

MISC.
DTM Functional Specification Release B11 (3BK 11202 0490 DSZZA)
B10: BSS Architecture Service Guideline (3DF 01903 8010 VAZZA 01)

Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

Agenda

1. Feature Overview
Feature aim and principle
Related parameters
2. Activation Strategy
Rules and recommended parameter settings
Compatibility with previous HW generations
3. Feature Assessment
Monitoring methods and Expected Results
Field Trial Results:
CMCC B11 MR1 Ed1.0 FO Tests Results
Velizy On-air Platform Tests Results
4. Conclusion
5. Annex

Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

Feature Overview

Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

Feature Overview
Feature aim and principle Importance of CS paging Coordination (1/2)

Without CS paging Coordination and while in Packet Transfer Mode (PTM):

Class B MS (popular MSs) can lose some CS Paging Messages if the duration of the packet
transfer is longer than the duration of the repetition of CS paging messages from the MSC
side, i.e. MS unreachable.

This is mainly because the CS paging messages will be transmitted on the PCH channel while
in PTM the MS is consuming (receiving / transmitting) the PDTCH/PACCH channels.
TC

BTS

PTM

PCH

BSC

MSC
A

Ater

Abis

CS PAGING
Ater

Gs

PDTCH/PACCH

CLASS B MS

Gb
MFS

SGSN

CS paging messages may be


lost, i.e. MS is unreachable

Network
NetworkModes
ModesofofOperation
Operationand
andMS
MSClasses
Classes

Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

Feature Overview
Feature aim and principle Importance of CS paging Coordination (2/2)

Alcatel-Lucent implementation of the Dual Transfer Mode (DTM) feature


assumes the support of CS paging coordination to be able to receive a DTM
call during a PS transfer.

MS shall receive CS paging while in PTM to go to dedicated mode.


B10
B10DTM
DTMOverview
Overview

With the support of CS paging coordination:


1. The CS paging performance is increased, ensure that the MS can receive CS
paging even during the PS transfer PTM (CS paging will be sent on the PACCH).
2. Full DTM feature support is feasible, since it will be possible to receive a DTM
call during PS transfer.

Note: DTM feature was not tested in any FO and it still needs an FMA
(First Market Application) to be open for commercial use.
Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

Feature Overview
Feature aim and principle CS Paging Coordination Strategies (1/2)
3GPP foresees two ways to support paging coordination:
I.

CS Paging Coordination in the SGSN (Network Operation Mode I NMO I)


- Implement Gs interface between the CS and PS Core (MSC and SGSN)
TC
MS

BTS

BSC

MSC
A

Ater

Abis

CS PAGING
Ater

Gs

PACCH

With CS Paging Coordination in the SGSN


Gs Interface

Gb
MFS

SGSN

- CS paging messages for MS in PTM are transferred from the MSC to the SGSN
through the Gs interface.
- Afterwards, the SGSN forwards the paging messages (through MFS) on the PACCH
of PDCHs allocated to this MS.
CS paging coordination is performed in
SGSN through Gs Interface (NMOI)
Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

Feature Overview
Feature aim and principle CS Paging Coordination Strategies (2/2)
II.

CS Paging Coordination in the BSS (NMO II) Our Concern


IMSI vs MS-Context
table Search
TC
MS
BTS

BSC

MSC
A

Ater

Abis

PCH

CS PAGING
CS Paging Coordination
Request (IMSI)

PACCH

Gs

Ater
Gb

With CS Paging co-ordination in the BSS

Feature
Summary

MFS

SGSN

- The BSC sends the received CS paging messages (from the MSC) on the PCH and
forwards it to the MFS through CS paging Coordination Request message.
- Afterwards the MFS sends it on PACCH whenever MS would be performing a packet
transfer (PTM) by searching the requested MS IMSI in the IMSI vs MS Context table
created internally in the MFS for all MSs in PTM only.
CS paging coordination is performed in the
BSS, Gs interface is not used (NMOII)
Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

Feature Overview
Feature aim and principle - Before B11 and Feature Rationale
CS paging coordination in SGSN (before B11)

To increase the CS paging performance (no CS


paging messages are lost during PTM) Gs
interface is needed in the core network
between the SGSN and the MSC.

CS paging coordination in BSS (B11)


To increase the CS paging (no CS paging messages are
lost during PTM) CS paging Coordination in BSS feature
is activated.

To fully support DTM feature (MS shall receive CS

To fully support DTM feature (MS shall receive

paging while in PTM to go to dedicated mode), CS

CS paging while in PTM to go to dedicated

paging coordination in BSS feature is activated.

mode), Gs interface is assumed to be


implemented in the core network.

Network Mode of Operation 1 (NMOI).

Network Mode of Operation 2 NMOII.


NMOIII is no longer used in ALU BSS (corresponds to the
use of master PDCH).

As some customers (ex: CMCC) are not interested in the usage of Gs interface:
Due to high number of core network providers, a high number of interoperability tests is needed.

This feature was developed in the BSS as a substitute of the Gs interface in performing the CS
paging coordination and therefore saves Core network operational costs.
Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

Feature Overview
Feature aim and principle General Overview

CS Paging Coordination in the BSS:


3 Steps are followed:

1. The MSC sends CS paging requests to the BSC.


2. BSC forwards CS paging requests to the MFS using BSCGP GSL (after filtering some
info) and broadcasts normally all CS paging requests to MS through the PCH channel
(for all cells corresponding to the paging area managed by this BSC).
3. MFS sends these paging requests to the MS through the PACCH of the cell where the
MS camps on (when applicable, MS in PTM).
Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

Feature Overview
Feature aim and principle Details BSC processing of incoming CS paging(1/5)
When the BSC received a paging message from the MSC:
A. It sends the paging messages on the PCH (BSC-BTS paging).
B. It applies some filtering and sends it to the MFS (CS paging to MFS).
For the first point, we have 2 scenarios for single and multiple paging command cases (G2 BSC
and Mx BSC respectively).

Case 1: Single Paging command (G2 BSC)


BTS

BSC

MFS

MSC

PAGING (MS1)
CS paging to MFS
PAGING COMMAND (MS1, pgr1)

Start T3113
for MSn

PAGING COORDINATION REQ

Access Grant from the MSn which


answer to the Paging Request

Stop T3113
for MSn

Paging response (MSn) on SDCCH

The MSC will send the paging request to all concerned BSCs in a given paging area (LAC).
Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

Feature Overview
Feature aim and principle Details BSC processing of incoming CS paging(2/5)
Case 2: Multiple Paging Commands (Mx BSC)
MFS

BSC

BTS

MSC

PAGING (MS1)

T_SEND_MULTIPLE_PAGING_COMMAND

Start T3113
for MS1

PAGING (MS5)

PAGING commands
buffered (or T_SEND_MULTIPLE_PAGING_CO MMAND timer
elapses)

Start T3113
for MS5

NB_MAX_MULTIPLE_PAGING_COMMAND

CS paging to MFS
MULTIPLE PAGING COMMAND (MSn, pgrk)

PAGING COORDINATION REQ

Scenario continues as in single Paging case

When NB_MAX_MSG_MULTIPLE_PAGING_CMD (5) (if >1) Paging commands (received from the
MSC) have been buffered or when T_SEND_MULTIPLE_PAGING_CMD (50 ms) elapses, the
buffered Paging commands are sent on both Abis (as in B10) and GSL (new for B11, due to the
introduction of this feature).
Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

Feature Overview
Feature aim and principle Details BSC processing of incoming CS paging(3/5)
B. CS paging to the MFS
I.

Filtering:

Reason: to prevent sending useless CS paging requests to the MFS, therefore to save
the GSL load and at the same time it should not increase the BSC processing load
(especially in G2 BSC where BSC load is critical).

BSC provides only IMSI to the MFS (paging area is not included) to decrease the GSL
load.

CS paging requests are sent to the MFS only if EN_BSS_PAGING_COORDINATION flag is


enabled (per BSC level).

To handle such filtering per cell is risky concerning the BSC processing load, especially in case
the paging area is a list of cells where not all of them have this flag activated.

This is the reason for managing CS paging coordination on the BSC level.

Note:
The BSC does not filter upon the GPRS operational state because it most likely to
have GPRS supported for all the cells of a BSC, i.e. filtering can then load the BSC
without a big benefit. The same applies for the cell operational/administrative states
(no filtering).
Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

Feature Overview
Feature aim and principle Details BSC processing of incoming CS paging(4/5)
B. CS paging to the MFS (Contd)
II. BSC paging message to the MFS

New message is introduced in the BSCGP to forward CS paging to the MFS PAGING
COORDINATION REQUEST and it is used for both Single Paging command (1
request) and Multiple Paging command (several requests).
New
NewBSCGP
BSCGPmsg.
msg.

In 3GPP TS 48.008, the IMSI is a mandatory field in the PAGING message from the
MSC, even though the TMSI has to be used to page the MS.

TS 48.008 states that IMSI can be used only exceptionally i.e. when TMSI is
unknown).

In BSS paging coordination, all paging requests can be transferred to the MFS;
i.e. the MSC sends the PAGING message with both IMSI and TMSI. The BSC
transfers both TMSI and IMSI to the MFS in the paging coordination message, the
MFS has then to page with this TMSI.
Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

Feature Overview
Feature aim and principle Details BSC processing of incoming CS paging(5/5)

Notes:
In case of multiple paging command:

If the CS paging request for a given IMSI was previously stored in the PAGING
COORDINATION REQ message, further requests to this IMSI will be discarded.

Can be considered as another type of filtering to minimize the GSL load.

The cell parameter PAG_BAR only concerns barring the CS paging on the PCH
channel.

It does NOT prevent the MS from being paged on the PACCH channel.

This parameter does NOT affect CS paging coordination while the MS is in PTM
(either for BSS or SGSN paging coordination).

Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

Feature Overview
Feature aim and principle General Overview

CS Paging Coordination in the BSS:


3 Steps are followed:

1. The MSC sends CS paging requests to the BSC.


2. BSC forwards CS paging requests to the MFS using BSCGP GSL (after filtering some
info) and broadcasts normally all CS paging requests to MS through the PCH channel
(for all cells corresponding to the paging area managed by this BSC).
3. MFS sends these paging requests to the MS through the PACCH of the cell where the
MS camps on (when applicable, MS in PTM).
Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

Feature Overview
Feature aim and principle Details MFS processing of received IMSI (1/4)

When CS Paging Coordination is performed in the SGSN:

The MFS assumes that the SGSN always provides for the paged MS in PTM mode
the most accurate location it is aware of (cell BVCI).

This allows the MFS to easily find the corresponding MS context without knowing
the MS IMSI.

However when CS Paging Coordination is performed in the BSS:

Only the IMSI is provided to the MFS (no Paging Area is provided) by the PAGING
COORDINATION REQ messages sent by the BSC.

MFS has to build and maintain for all MS in PTM mode a set of IMSI vs MS
Context relationships, i.e. the MFS is able to find the MS context (contains the
cell for PACCH paging) provided that EN_BSS_PAGING_COORDIATION parameter is
enabled on this BSC.

Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

Feature Overview
Feature aim and principle Details MFS processing of received IMSI (2/4)

Notes about the IMSI vs MS context table:


When the MS leaves the PTM, the corresponding IMSI vs MS Context entry
has to be deleted.
When the MS enters the PTM mode, the IMSI has to be retrieved.

In case of a DL TBF, the IMSI will be picked from a DL LLC PDU.

In case of an UL TBF, a Radio Access Capacity Update procedure has to be


performed at completion of UL TBF establishment to speed-up the IMSI retrieval.

That is why it is highly recommended to enable the BSC parameter


EN_RA_CAP_UPDATE prior to the activation of the CS paging Coordination in the
BSS.

Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

Feature Overview
Feature aim and principle Details MFS processing of received IMSI (3/4)

When the MFS receives a PAGING COORDINATION REQ message from the BSC, the MFS
shall:
1. Browse through the IMSI MS Context table.
2. If the IMSI is found (i.e. MS is in PTM mode) and the MS context is known, the MFS
will send the CS paging message on the corresponding PACCH.
3. Otherwise (IMSI not found) the MS is not in PTM, MFS will discard the CS paging.

In case of a G2 BSC, the PAGING COORDINATION REQ always contains a single IMSI
(single paging command).

In case of an Mx BSC, the PAGING COORDINATION REQ can contain more than one IMSI
(according to the BSC parameters NB_MAX_MSG_MULTIPLE_PAGING_CMD and
T_SEND_MULTIPLE_PAGING_CMD).

NOTE:
No Ack message is managed as a response for the PAGING COORDINATION REQ.
However the extra GSL load can be monitored through the GSL PM counters (please
refer to monitoring methods section).
Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

Feature Overview
Feature aim and principle Details MFS processing of received IMSI (4/4)

The following diagram summarizes the IMSI processing and CS paging message
forwarding on the PACCH (if MS is in PTM mode):

Note: IMSI vs. MS context is stored in each GPU, thats why when the MFS receives the
Paging Coordination REQ message, there will be for each paging IMSI three possible
cases:
1. IMSI is found: the paging message is sent to the MS via the BTS on PACCH.
2. IMSI is not found: the Paging REQ will be broadcasted to all other GPUs corresponding to this
BSC (Multi-GPU BSC).
3. IMSI is not found in all GPUs corresponding to this BSC: the MFS discards the Paging Request.
Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

Feature Overview
Feature aim and principle - Implemented Solution Summary
Alcatel-Lucent solution Summary:
MFS will maintain a table containing the IMSI vs MS-context for all the mobiles in
PTM mode (MFS is capable of keeping track of the mode of the GPRS attached MSs ,
PTM or PIM); IMSI of the paged mobile will be sent by the BSC.
To perform the previous 3 steps:
1. The BSC receives the CS paging messages from the MSC.
2. It forwards it to the BTSs on the PCH.
3. The BSC does some filtering for the CS paging messages contents and send the
IMSI to the MFS through a Paging Coordination Request message.
4. The MFS, using the key the IMSI, will browse through its IMSI vs MS-context
database. If the IMSI is found then the MS context is known.
5. The MFS sends the CS paging messages on the corresponding PACCH.
6. Therefore, CS paging messages can be received while the MS is in PTM.
Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

Feature Overview
Feature aim and principle - Updated Paging Rules for DTM MS

Paging channel that should be used by the BSS (depending on the state of a GPRSattached DTM MS and the paging coordination solution):
NMO II

NMO I

Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

Feature Overview
Related Parameters
New Parameters:
Parameter Name

Definition

SubCategory/
Instance
System
OMC-R access

Enables the CS paging coordination


EN_BSS_PAGING_COORDINATION (BSC)

managed in the BSS for MS in

Type

Range/
Default
value

BSC

BSS

Site CAE)/
Changeable

Flag

[0, 1] /
0

MFS

BSS

Site CAE)/
Changeable

Flag

[0, 1] /
0

Packet Transfer Mode.


Enables the CS paging coordination
EN_BSS_PAGING_COORDINATION (MFS) managed in the BSS for MS in
Packet Transfer Mode.

On the air interface:


Some messages will be affected by the EN_BSS_PAGING_COORDINATION O&M parameter:
The BSS_PAGING_COORDINATION field in the DTM ASSIGNMENT COMMAND, PACKET
ASSIGNMENT and SI TYPE 13 messages will be set according to the value of
EN_BSS_PAGING_COORDINATION.

Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

Activation Strategy

Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

Activation Strategy
Rules and recommended parameter settings (1/2)
The feature is optional.
Activation is done at the BSC level.
Activation is done from the OMCR using the parameter EN_BSS_PAGING_COORDINATION
(TRUE); then it is sent to both BSC and MFS.
The network_mode_operation <>1 should be 2 (checked also by the OMC).
Remark: NMOIII is no longer used (MPDCH).

NMOI cannot be used with this feature (it only concerns the presence of Gs interface in
the core network).
Remark: Two ways of CS paging coordination can not be handled simultaneously per BSC.

The feature can be used independently from the activation of the DTM feature:

This B11 feature can also be used to improve the CS paging performance while the MS is in
packet transfer mode (PTM) (MS will be paged faster on average on PACCH that on PCH, as
described in the previous slides).

If EN_DTM is enabled at least in one cell in a given BSC, it is highly recommended to activate
this feature for this BSC (NMO<>1).

Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

Activation Strategy
Rules and recommended parameter settings (2/2)
The feature makes sense if GPRS is enabled in at least on cell in the BSC.
If a BSC is connected to a MFS but GPRS is not operational for all the BSC cells it is recommended to
set EN_BSS_PAGING_COORDINATION to Disabled for this BSS.
GPRS through satellite connection on Abis or Ater interface feature is not compatible with the feature
(checked by OMC) because of the GSL load risks.

GSL overload is a problem only if Ater satellite link is used (no problem if Abis satellite link is used with a
terrestrial Ater link).

But the Round_trip_delay parameter used for the check is related to the whole MS-MFS path and therefore it
does not allow to distinguish Ater from Abis.

Round_trip_delay should be < 500 msec (MS-MFS path) for all the cells for the BSC.

It is highly recommended to activate Radio Access Capability update feature EN_RA_CAP_UPDATE (BSC
parameter) prior to the activation of the CS paging Coordination in the BSS (not checked by the OMC).

Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

Activation Strategy
Recommended setting based on experimentation in CMCC B11 MR1 ED1.0 FO
Based on CMCC B11 MR1 ED1.0 FO and the issue discovered:
In case Paging Repetition is enabled at the core (MSC/VLR) side, there is a very
very low risk to have a loss of CS calls during pings with long pause durations.
The RA Capacity Update procedure (EN_RA_CAP_UPDATE) should be enabled to
minimize a bit the losses of CS paging requests (which is triggered at completion
of TBF UL establishment to speed-up the IMSI retrieval).

For more details about this issue please consult ANNEX F, it will also be
discussed in CMCC B11 MR1 ED1.0 test results section.
ANNEX
ANNEXFF

Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

Activation Strategy
Compatibility with previous HW generation and restrictions

The feature does not have a software impact on all the BTS generations, all TRE
generations and all transcoder generations.
The feature only impacts the software of the BSC and the MFS.
BSC: CS Paging filtering and PAGING COORDINATION REQUEST message building.
MFS: PAGING COORDINATION REQ processing, IMSI MS Context relationships building &
browsing.

Restrictions & Limitations


- There is an indirect impact since Multiple Paging on GSL is NOT supported by G2 BSC
as previously described.

Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

Feature Assessment

Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

Monitoring Methods and Expected Results

Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

Feature Assessment
Monitoring methods Main Tests Categories

Tests
TestsPre-requisites
Pre-requisites

Two main tests categories are used to test the feature on-field:
1. Functional unitary tests:
Purpose:
a) to validate the correct functionality of the feature to serve previously discussed
feature interests:
To generally increase the CS paging performance.
To achieve Full DTM feature support.
i.e. ensuring that the MS can receive CS paging during PS transfer (PTM) either
for DTM calls or for normal CS calls (interruption of PS service).
b) to monitor PS performance after feature activation, i.e. data performance nonregression in terms for FTP throughput and Ping success rate and RTT.

2. Statistical tests:
Purpose:
a)
b)
c)
d)

to
to
to
to

ensure non-regression of the main CS and PS QoS KPIs after feature activation
ensure that no regressions occur in equipment availability or stability.
check the feature specific indicators; GSL Paging Coordination Requests.
monitor/estimate GSL load after feature activation (BSCMFS direction).
Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

Feature Assessment
Monitoring methods Functional Unitary Tests Summary
Type of tests

Aim & Procedure of the tests

Unitary
UnitaryTests
Tests
Expected
ExpectedResults
Results
Parameter Setting

To assess the benefit of the feature in increasing the CS paging performance


during an on-going PS session i.e. terminating CS call success rate.
Test Procedure:

FALSE/TRUE

An UL FTP session (2MB, EDGE Mode).

101 Iterations PING session with small PING size 32B with different pause durations between EN_DTM = FALSE
each 2 iterations (0, 1, 2 & 5 sec).

te
st
s

feature

A DL FTP session (5MB, EDGE Mode).

EN_BSS_PAGING_COORDINATION =

ar

without DTM

st
at
ic

CS performance Perform 15 random terminating CS calls towards trace MS during different PS sessions:

ab
ov

each 2 iterations (0, 1, 2, & 5 sec)

101 Iterations PING session with big PING size 1460B with different pause durations between

Al
lt
he

To identify the gain brought by feature to receive CS paging while MS is in PTM EN_BSS_PAGING_COORDINATION =
CS performance to successfully establish a DTM call, i.e. DTM call success % while MS is in PTM.
FALSE/TRUE
with DTM feature Test Procedure:
Same procedure as the previous category but with DTM activated.

EN_DTM = TRUE

To ensure the non-regression of the PS performance after feature activation in


terms of throughput (FTP), Ping Success rate and RTT (Ping).
Test Procedure:
EN_BSS_PAGING_COORDINATION =
Non-regression Perform DL FTP Transfers (using trace MS ex: Nokia N95) for 5MB file in EDGE mode.
PS performance

Perform UL FTP Transfers (using trace MS ex: Nokia N95) for 2MB file in EDGE mode.
Perform PING Session (using trace MS ex: Nokia N95):
Small Ping Size: 32B, 101 iterations with 0 sec pause & with 5 sec pause.
Big Ping Size: 1460B, 101 iterations with 0 sec pause & with 5 sec pause.
Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

FALSE/TRUE
EN_DTM = FALSE

Feature Assessment
Monitoring methods Statistical Tests Details and Expected results (1/6)
1. QoS follow-up:
Expected Results:

Non-regression of the main CS and PS QoS indicators after feature activation.

GPRS acceptable release due to suspend cause (GPRS_xL_TBF_release_suspend) is


subject to increase after feature activation; since with the new feature there is a
higher chance to suspend the on-going GPRS sessions to serve the incoming CS calls.

2. Stability and unavailability follow-up:


Expected Results:

No regressions in the GSM/GPRS/TRX/SS7 availability after feature activation.

No regressions in BSC/BTS/Cell stability after feature activation.

Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

Feature Assessment
Monitoring methods Statistical Tests Details and Expected results (2/6)
3. Feature Specific Indicators check:

Two feature specific counters are implemented in B11 MR1 ED2 upon NE request (CR:
3BKA20CBR275762). Before that, there were no dedicated counters for this feature.

Accordingly, pre-B11 MR1 ED1:


o

We could can only estimate the number of CS paging IEs in PAGING COORDINATION requests
sent on GSL by the help of other existing BSC/MFS counters.

It is an approximation for the paging coordination messages sent on GSL not an accurate
value.

Noting that we still do not have an indication that the feature is working, because these
other counters will always have values whether the feature is activated or not.
Domain

NB_BSS_CS_PAGING_REQ_GPU

Number of CS paging requests coming from the BSC


received by the GPU.
Whenever a PAGING COORDINATION REQUEST message is
received from the BSC the counter is incremented by
number of CS Paging IEs contained within the message.

GPU
(Sub_BSS,
BSC/FABRIC)

Traffic
load

NB_CS_PAGING_REQ_PACCH

Number of CS Paging messages sent on PACCH.


Whenever a CS Paging message is sent on (DL) PACCH the
counter is incremented.

Cell

Traffic
load

ED
2

Definition

B1
1

P390a

Measured
object

Long Name

M
R1

Counter
ref name

P390b

Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

Feature Assessment
Monitoring methods Statistical Tests Details and Expected results (3/6)
3. Feature Specific Indicators check (contd): New Indicators starting B11
MR1 ED2:
NPO
indicator
refname

Formula
NPO B11

LongName NPO

Description

GCPGRQGN

CS_Paging_Request_received

P390a

Number of CS paging requests coming from the BSC


received by the GPU.

GCPGMPACN

CS_Paging_Sent_MS_PACCH_PTM

P390b

Number of CS Paging messages sent on PACCH.

GCPGMPACR

CS_Paging_Sent_MS_PACCH_PTM_rate

P390b/P390a Rate of CS Paging messages sent on PACCH.

Notes:

The 1st & 3rd more meaningful when aggregated on the BSC level, because in case
of multi-GPU BSC the GPU that receives that CS paging coordination request is
not necessarily the one that processes this request and handles it by sending the
CS paging request on the PACCH to the MS.
The 3rd indicator is considered as the benefit brought by the feature to the end
user, meaning that how many (or percentage of) the CS paging requests that
would have been lost if the feature is not active.

The next slide shows how we can estimate the number of CS paging Coordination
messages sent on GSL through other counters (before B11 MR1 ED2), we may use 3
estimation indicators:
Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

Feature Assessment
Monitoring methods Statistical Tests Details and Expected results (4/6)
Paging message received by the BSC
from any MSC (on A interface).

CS Paging
request
MS Message sent on
PACCH in PTM
DTM
MS
CS/PS Paging
requests for MS
on PCH

CS Paging in PTM

TC
CS Paging Message

MC940
BTS
Abis

Cell

MC925g
MC8a

BSC

MSC

AterMUX-CS

P53c

P390b (B11 MR1


ED2)
Gb
P53a
PS Paging Messages on AterMUX-PS
SGSN
MFS PS Paging
PCH
message
GPU
P391a
PAGING_COORDINATION_REQ IEs
P390a (B11 MR1
ED2)
Number of PS paging requests

Channel assignment
downlink message on PCH

Paging command
message (CS+PS Paging)

Number of PAGING COMMAND


received by the BTS on Abis
and had to be sent for CS and
PS traffic to the MS.

processed by the GPU.

MAX (MC925g) - MAX (P391a)


Among all cells managed
by the BSC

Among GPUs of a BSC

The 1st estimation indicator:


The 2nd estimation indicator: MC940. Because when feature is activated, any CS paging message received by the BSC
from MSC (on A-interface) will be forward to the MFS (on GSL) through PAGING COORDINATION REQUEST message.
The 3rd estimation indicator: MAX (GPRS_CS_Paging_Request (GTRPCHCSN) = MC8a - P53a - P53c)
Among cells of a BSC

CMCC FO Results
Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

Feature Assessment
Monitoring methods Statistical Tests Details and Expected results (5/6)
3. Feature Specific Indicators check (contd):
Expected Results:

Pre- B11 MR1 ED2: to conclude the indicator to be used as an approximation


(estimation) of the GSL paging Coordination requests sent from BSC to MFS.

B11 MR1 ED2 and up: to ensure that the new indicators/counters (P390a & P390b)
have consistent values with the activation of the CS paging coordination and to
assess the gain brought by the feature: CS_Paging_Sent_MS_PACCH_PTM_rate (%).

Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

Feature Assessment
Monitoring methods Statistical Tests Details and Expected results (6/6)
4. GSL load monitoring after feature (BSCMFS direction):
Every CS paging received by the BSC on A-interface will be forwarded to the MFS,
that is why the GSL load in BSC MFS direction will increase.
Indicators & counters mentioned in ANNEX G should be checked:
GSL
GSLLoad
LoadMonitoring
Monitoring
Expected Results:

GSL Load study: make use of GSL counters & CS paging coordination indicators
(before / after feature activation to be able to indentify / assess the increase in
GSL load).

Check if re-dimensioning of the GSL is needed after introducing the feature.

Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

Field Trials

Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

Feature Assessment
Field Trials

The feature was assessed in:


CMCC B11 MR1 ED1.0 FO (Xian city Pilot, China)
B11 MR1 ED1.0 On-air Platform (Velizy, France)

Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

CMCC B11 MR1 ED1.0 FO Tests Results

Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

Feature Assessment
CMCC B11 MR1 ED1.0 FO results Highlights (1/2)
Tests Performed in CMCC B11 MR1 ED1.0 FO (Xian Pilot):
1. Unitary CS Performance tests: non-DTM case only.
In CMCC network, DTM feature is not activated and therefore the feature interest for
Full Support DTM of the DTM (second feature interest) could not be validated through
CS Performance unitary (second category of unitary tests).
2. PS non-regression unitary tests.
3. Statistical tests:
a. CS & PS QoS Follow-up, stability and availability Follow-up.
b. Specific indicators Check: the new counters (P390a/b) could not be validated in CMCC FO because
they are only available in B11 MR1 ED2, estimation indicators were used.
c. GSL Load Study: could not performed (see next slides).

Test procedure is the same as described in monitoring methods section.


Tools:
Nemo Tool Chain (Outdoor + Analyze).
Nokia N95 Trace MS + 1 MS used for calling the trace MS.
Wireshark traces were captured.
NPO4U (NPO31_D23) tool was used for statistical tests.
Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

Feature Assessment
CMCC B11 MR1 ED1.0 FO results Highlights (2/2)
Pilot BSC Parameter Settings:
EN_RA_CAP_UPDATE = TRUE
Network Mode of Operation (NMO) = 2

Test Cells Parameter Settings:

EN_FAST_INITIAL_GPRS_ACCESS = FALSE
MAX_GPRS_CS = 4 & MAX_EGPRS_MCS = 9
TBF_xL_INI_MCS = 5 & TBF_xL_INI_CS = 2
Round_trip_delay < 500 msec (not satellite Abis/Ater)

Note: Paging Repetition is not enabled in Huawei MSC managing the Pilot BSC

Radio Conditions:
The tests were performed at cell (suburban environment) TMP_XAD703_0 (CI =
17034, BCCH = 529, BSIC = 70) in good radio conditions:
Average RxLev = -53 dBm to -56 dBm.
Average Mean BEP = 30.7 to 31.
Average CV BEP = 6.9 to 7.
All the tests are static.
Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

Feature Assessment
CMCC B11 MR1 ED1.0 FO results CS Performance Tests (1/10)
CS Paging Coordination
DISABLED

CS Paging Coordination
ENABLED

Terminating CS Calls Success


(Rate%)

Terminating CS Calls Success


(Rate%)

CS Calls During DL FTP (5MB) PS Session

0 (0%)

15 (100%)

CS Calls During UL FTP (2 MB) PS Session

0 (0%)

15 (100%)

CS Calls During PING 32B "Pause 0s" 101 iterations PS Session

0 (0%)

15 (100%)

CS Calls During PING 32B "Pause 1s" 101 iterations PS Session

0 (0%)

15 (100%)

CS Calls During PING 32B "Pause 2s" 101 iterations PS Session

0 (0%)

15 (100%)

CS Calls During PING 32B "Pause 5s" 101 iterations PS Session

8 (53.33%)

81 out of 86 calls (94.18%)

CS Calls During PING 1460B "Pause 0s" 101 iterations PS Session

0 (0%)

15 (100%)

CS Calls During PING 1460B "Pause 1s" 101 iterations PS Session

0 (0%)

15 (100%)

CS Calls During PING 1460B "Pause 2s" 101 iterations PS Session

1 (6.67%)

15 (100 %)

CS Calls During PING 1460B "Pause 5s" 101 iterations PS Session

7 (46.67%)

78 out of 86 calls (90.69%)

PS Session Type

When the feature is not activated, all the CS terminating calls are lost except for PING
sessions with relatively long pauses where CS paging can be received on the CCCH (PCH)
channels (this observation is further described in the next slides).
When the feature is activated, all terminating CS calls are received (100% success)
during different PS sessions except for Ping Sessions with long pause durations where the
CS calls success rate is around 90 92% (this issue is further described next)
Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

Feature Assessment
CMCC B11 MR1 ED1.0 FO results CS Performance Tests (2/10)
The MS knows that the cell is supporting the CS paging coordination feature (i.e. it is
expecting to receive CS paging on PACCH) by the BSS_PAGING_COORDINATION
Flag which present in SI13 & Packet Assignment messages (L3 messages) sent from
the network to the MS, as seen in the below snapshot:

Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

Feature Assessment
CMCC B11 MR1 ED1.0 FO results CS Performance Tests (3/10)
Snapshots from NEMO Analyze for the observed behavior when MS is performing a
PING (2 sec pause) PS session which is interrupted by an incoming CS call (1):

Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

Feature Assessment
CMCC B11 MR1 ED1.0 FO results CS Performance Tests (4/10)
Ping session is interrupted by receiving CS paging on PACCH, leading to the deallocation of the PS timeslots, MS leaves PTM to PIM, CS call setup is ongoing (2):

Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

Feature Assessment
CMCC B11 MR1 ED1.0 FO results CS Performance Tests (5/10)
CS call is released, GPRS is resumed, Ping Session continues (3):

Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

Feature Assessment
CMCC B11 MR1 ED1.0 FO results CS Performance Tests (6/10)
Notes:
1. In case of PING sessions with long Pause durations, the CS paging can be received
either on PCH or PACCH, this is mainly because in this kind of PS sessions, the MS
leaves Packet Transfer Mode (PTM) and enter Packet Idle Mode (PIM) for a certain
duration (according to the Pause values) and accordingly:

If the network pages the MS while it is in PTM, the CS paging message will be
received on PACCH (because the feature is activated).

If the network pages the MS while it is in PIM, the CS paging message will be
received on PCH.

As you can see below in Ping tests with 5 sec pause around one-third 1/3 of the
random CS paging requests are received on PCH:
PS Session Type

Number of CS paging received on


PACCH

Number of CS paging received on


PCH

33 CS Calls During PING 32B "Pause 5s" 101 iterations


PS Session

22 (66.67%)

11 (33.33%)

31 CS Calls During PING 1460B "Pause 5s" 101


iterations PS Session

21 (67.8%)

10 (32.2%)

Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

Feature Assessment
CMCC B11 MR1 ED1.0 FO results CS Performance Tests (7/10)
Notes:
2. When the CS paging is received (on PACCH or PCH), the on-going (E)GPRS session is
suspended until the CS calls ends.

However, in case of performing a long CS call the application may be dropped after
finishing the call, but this is not an issue as it completely depends on the time-out
of the application (application dependant).
For example: In UL/DL FTP sessions performed in CMCC FO, the default FTP TimeOut is 30 sec, it was noticed that in case of short calls (< 30 sec), the FTP UL/DL
will continue after the call is released; however in case of Long calls (> 30 sec), the
FTP UL/DL will be dropped as shown in the next diagram:

Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

Feature Assessment
CMCC B11 MR1 ED1.0 FO results CS Performance Tests (8/10)
Notes:
3. Degradation of RTT & Ping success rate (for Ping Test) and average throughput (for
UL/DL FTP tests) is noticed during the tests when CS paging messages is received
(either on PACCH or PCH) while a PS session is on-going:

This is normal, since the main purpose of the feature is to ensure that MS can
receive paging even it is in PTM.

In the next diagram, we notice degradations in the Ping session performance:


Some Pings are unsuccessful when CS calls are received.
Degradation of the Ping RTT when CS calls are received compared to the nominal RTT
values (no interruption by CS calls).

Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

Feature Assessment
CMCC B11 MR1 ED1.0 FO results CS Performance Tests (8/10)

Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

Feature Assessment
CMCC B11 MR1 ED1.0 FO results CS Performance Tests (9/10)
Observation:
When the feature is not activated and in case the MS is performing Ping Session with
relatively long duration (3 sec, 4 sec ), there is a chance of catching some
terminating CS calls.
These sessions are characterized by alternating PTM PIM changes. Therefore if
the CS paging message (on the CCCH i.e. PCH) is sent by the network while MS is in
PIM, the CS call will be established and the (E)GPRS session will be suspended.
The whole scenario of such cases is shown in:

ANNEX
ANNEXHH

Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

Feature Assessment
CMCC B11 MR1 ED1.0 FO results CS Performance Tests (10/10)
Issue: 3BKA20FAG287622 [CLOSED]
Problem Description:
Sometimes during a Ping session with 1460B or 32B (101 iterations) with relatively long
pause between iterations, the CS paging is not received (i.e. the MS is not reachable)
although the CS paging Coordination feature is activated.
The issue does not appear for Ping sessions with short pause durations (0, 1 sec) and UL/DL
FTP sessions.
Problem details:
PS sessions characterized by changes of MS states PTMPIM (during session) suffer
from this problem. Namely, Ping Sessions with 3, 4, 5, sec pause between iterations.
The most the severe one observed being Ping sessions with 5 sec pause where quick
PIM PTM changes occur.
As the pause duration increases, the MS stays more in PIM and there is a less
probability of losing CS paging.
Problem
ProblemHistory
History&&Details
Details
Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

Conclusion
Conclusion

Feature Assessment
CMCC B11 MR1 ED1.0 FO results Non-regression Data Performance Tests (1/2)
DL and UL FTP transfer PS sessions:

FTP DL (5MB), 3 iterations

CS Paging Coordination
DISABLED

CS Paging Coordination ENABLED

Delta

Average Application DL Throughput (Kbits/sec)

204.69 kbits/sec

202.77 kbits/sec

-1.914931

MCS-9 for 93.5% of the time

MCS-9 for 93.58% of the time

0.08%

4+1

4+1

FTP UL (2MB), 3 iterations

CS Paging Coordination
DISABLED

CS Paging Coordination ENABLED

Delta

Average Application UL Throughput (Kbits/sec)

93.81 kbits/sec

93.92 kbits/sec

0.101599

MCS-9 for 95.9% of the time

MCS-9 for 94.89% of the time

-1.01%

3+2

3+2

DL Coding Scheme
Number of TSs (DL + UL)

UL Coding Scheme
Number of TSs (DL + UL)

Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

Feature Assessment
CMCC B11 MR1 ED1.0 FO results Non-regression Data Performance Tests (2/2)

CS Paging Coordination DISABLED

CS Paging Coordination ENABLED

Average RTT (ms)

Lost Iteration (Ping


Success Rate%)

Average RTT (ms)

Lost Iteration (Ping


Success Rate%)

Delta RTT
(ms)

32B, 0 sec Pause, 101 iterations

194.37

0 (100%)

195.53

0 (100%)

-1.16

32B, 5 sec Pause, 101 iterations

637.69

3 (97%)

634.21

4 (96%)

3.48

1460B, 0 sec Pause, 101 iterations

452.67

0 (100%)

438.87

0 (100%)

13.8

1460B, 5 sec Pause, 101 iterations

1349.29

3 (97%)

1083.38

2 (98%)

265.91

PS Session Type

This large difference is not linked to the feature but it linked to an issue
with Nokia N95 MS, where high variance in the RTT values are encountered
for large Ping Size with long pause durations.

CS paging coordination feature shows non-regression in PS data performance tests


Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

Feature Assessment
CMCC B11 MR1 ED1.0 FO results CS and PS QoS Follow-up (1/12)
QoS non-regression for the main CS indicators:
XA_MXBSC_143
SDCCH_assign_request
SDCCH_assign_cong_rate
SDCCH_assign_cong
SDCCH_assign_reject
SDCCH_assign_reject_rate
SDCCH_assign_reject_ratio
SDCCH_assign_success
SDCCH_assign_fail_radio
SDCCH_assign_fail_BSS
SDCCH_assign_fail_rate
SDCCH_assign_success
SDCCH_drop_radio
SDCCH_drop_HO
SDCCH_drop_BSS
SDCCH_drop
SDCCH_drop_rate
RTCH_assign_request
RTCH_assign_cong_rate
RTCH_assign_cong

Feature Reference
Feature Follow-up
Period (AVG)
Period (AVG)
ALC_SDCCH_ASSIGN_CONGESTION
3353178.57
3614701.00
0.09%
0.02%
3036.14
681.57
2223.43
642.29
0.07%
0.02%
73.23%
94.24%
ALC_SDCCH_ASSIGN_FAILURE
3162906.57
3427704.00
187173.43
186301.86
62.57
13.57
5.58%
5.15%
ALC_SDCCH_DROP
3162906.57
3427704.00
28596.71
27244.00
0.00
0.00
17.00
15.00
28613.71
27259.00
0.90%
0.80%
ALC_RTCH_ASSIGN_CONGESTION
794277.29
796997.14
0.33%
0.28%
2599.57
2241.57

Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

(Follow-up Reference)
261522.43
-0.07%
-2354.57
-1581.14
-0.05%
21.00%
264797.43
-871.57
-49.00
-0.43%
264797.43
-1352.71
0.00
-2.00
-1354.71
-0.11%
2719.86
-0.05%
-358.00

Feature Assessment
CMCC B11 MR1 ED1.0 FO results CS and PS QoS Follow-up (2/12)
QoS non-regression for the main CS indicators:
XA_MXBSC_143
RTCH_assign_request
RTCH_assign_success
RTCH_assign_success_rate
RTCH_assign_fail_radio
RTCH_assign_fail_radio_rate
RTCH_assign_fail_BSS
RTCH_assign_fail_BSS_rate
RTCH_assign_fail_rate
Call_setup_success_rate
Call_success_rate
End_to_End_Call_setup_success_rate
RTCH_success_end
Call_drop_radio
Call_drop_HO
Call_drop_BSS_int_failure
Call_drop_BSS_remote_TC
Call_drop_preemption
Call_drop
Call_drop_rate
RTCH_drop_rate
RTCH_success_begin

Feature Reference
Feature Follow-up Period
Period (AVG)
(AVG)
ALC_RTCH_ASSIGN_EXECUTION
794277.29
796997.14
780457.29
784527.43
98.26%
98.44%
4157.71
3800.29
0.52%
0.48%
-1677.57
-491.14
-0.21%
-0.06%
0.31%
0.42%
ALC_CALL_SUCCESS
97.38%
97.68%
96.80%
97.15%
93.42%
92.96%
ALC_CALL_DROP
788682.29
791736.43
2175.71
2134.00
1893.14
1830.14
386.00
213.00
194.57
61.43
0.00
0.00
4649.14
4238.57
0.59%
0.54%
0.27%
0.24%
1715655.14
1742647.00

Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

(Follow-up Reference)
2719.86
4070.14
0.18%
-357.43
-0.05%
1186.43
0.15%
0.11%
0.30%
0.35%
-0.46%
3054.14
-41.71
-63.00
-173.00
-133.14
0.00
-410.57
-0.05%
-0.03%
26991.86

Due to Peak negative


(wrong) stagnating
value for exe fail BSS on
15/10 from 1h till16h on
1 cell (CI=15854)
Due to Peak drop of
E2E CSSR on 20/10 @
04h and on 22/10 @1h
on 1 cell (CI = 14586)

Feature Assessment
CMCC B11 MR1 ED1.0 FO results CS and PS QoS Follow-up (3/12)
QoS non-regression for the main CS indicators:
XA_MXBSC_143
SDCCH_Erlang_total
SDCCH_duration_avg
RTCH_Erlang_total
RTCH_duration_avg
RTCH_available_nb_avg
RTCH_nb_avg
RTCH_available_nb_avg_rate
RTCH_unavailable_nb_avg
HO_Inc_BSC_cong_rate
HO_Inc_BSC_fail_rate
HO_Inc_BSC_success_rate
HO_Out_BSC_success_rate
HO_Out_BSC_ROC_rate
HO_Out_BSC_drop_rate
HO_Inc_MSC_cong_rate
HO_Inc_MSC_success_rate
HO_Inc_MSC_fail_rate
HO_Out_MSC_2G_2G_success_rate
HO_Out_MSC_2G_2G_ROC_rate
HO_Out_MSC_2G_2G_drop_rate

Feature Reference
Feature Follow-up
Period (AVG)
Period (AVG)
ALC_GSM_TRAFFIC
3469.13
3519.97
3.728571429
3.514285714
19223.00
19459.94
39.54285714
39.42857143
ALC_GSM_RESOURCES
2816.84
2833.34
3501.91
3494.29
80.44%
81.09%
685.09
660.94
ALC_HO_INC_INTRA_BSC
8.64%
6.17%
2.49%
0.00%
87.87%
91.20%
ALC_HO_OUT_INTRA_BSC
87.87%
91.20%
2.57%
2.54%
0.19%
0.18%
ALC_HO_INC_INTER_BSC
1.46%
1.41%
92.07%
93.20%
5.54%
5.33%
ALC_HO_OUT_INTER_BSC
95.22%
95.34%
3.05%
3.06%
0.28%
0.26%
Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

(Follow-up Reference)
50.84
-0.214285714
236.94
-0.114285714
16.50
-7.63
0.65%
-24.14
-2.47%
-2.49%
3.33%
3.33%
-0.02%
-0.01%
-0.05%
1.13%
-0.21%
0.12%
0.00%
-0.02%

Almost stable SDCCH


and TCH traffic (around
1.5% increase only)

Feature Assessment
CMCC B11 MR1 ED1.0 FO results CS and PS QoS Follow-up (4/12)
QoS non-regression for the main CS indicators:
Feature Reference
Period (AVG)

XA_MXBSC_143

Feature Follow-up
Period (AVG)

(Follow-up Reference)

ALC_HANDOVER_CAUSES
CHO_better_cell_rate

43.46%

43.88%

0.42%

CHO_DL_level_rate

8.43%

8.17%

-0.26%

CHO_UL_level_rate

3.34%

3.10%

-0.24%

CHO_DL_quality_rate

20.90%

20.41%

-0.49%

CHO_UL_quality_rate

7.79%

7.40%

-0.39%

CHO_dist_rate

0.00%

0.00%

0.00%

CHO_interference_rate

0.00%

0.00%

0.00%

ALC_CCCH_channels
CCCH_PCH

1998000.71

1971238.14

-26762.57

CCCH_RACH

9314370.43

9322029.29

7658.86

CCCH_AGCH

3350113.14

3614011.00

263897.86

GPRS_AGCH_immediate_assignment

6180552.71

5927079.71

-253473.00

GPRS_PCH_immediate_assignment

1726853.57

1661536.57

-65317.00

GPRS_RACH_channel_request

5857425.71

5628097.57

-229328.14

CS QOS Indicators are stable after feature activation


Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

Almost stable Paging


of PCH (around 1.3%
decrease only)

Feature Assessment
CMCC B11 MR1 ED1.0 FO results CS and PS QoS Follow-up (5/12)
QoS non-regression for the main PS indicators:
XA_MXBSC_143
GPRS_DL_TBF_request
GPRS_DL_TBF_estab_allocated
GPRS_DL_TBF_estab_allocated_rate
GPRS_DL_TBF_success
GPRS_DL_TBF_success_rate
GPRS_DL_TBF_estab_fail_BSS_rate
GPRS_DL_TBF_estab_fail_GB_rate
GPRS_DL_TBF_estab_fail_radio_rate
GPRS_DL_TBF_estab_fail_cong_rate
GPRS_UL_TBF_request
GPRS_UL_TBF_estab_allocated
GPRS_UL_TBF_estab_allocated_rate
GPRS_UL_TBF_success
GPRS_UL_TBF_success_rate
GPRS_UL_TBF_estab_fail_BSS_rate
GPRS_UL_TBF_estab_fail_GB_rate
GPRS_UL_TBF_estab_fail_radio_rate
GPRS_UL_TBF_estab_fail_cong_rate
GPRS_DL_TBF_realloc_request
GPRS_DL_TBF_realloc_T1_request
GPRS_DL_TBF_realloc_T2_request
GPRS_DL_TBF_realloc_T3_request
GPRS_DL_TBF_realloc_T4_request
GPRS_DL_TBF_realloc_success_rate

Feature Reference
Period (AVG)

Feature Follow-up
Period (AVG)

ALC_DL_TBF_ESTABLISHMENT
6276211.29
6308209.29
6274400.00
6307126.29
99.97%
99.98%
6159382.57
6216103.00
98.14%
98.54%
0.25%
0.25%
0.00%
0.00%
1.58%
1.20%
0.03%
0.02%
ALC_UL_TBF_ESTABLISHMENT
15844872.43
15768185.57
15577193.86
15555640.43
98.31%
98.65%
14852069.29
15084304.71
93.73%
95.66%
1.59%
1.17%
0.00%
0.00%
2.98%
1.82%
1.69%
1.35%
ALC_GPRS_DL_RESOURCE_REALLOC
12597465.71
11982911.71
30159.86
30482.43
2422590.86
2521552.14
7303508.29
6716237.71
2841206.86
2714639.57
30.67%
33.91%
Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

(Follow-up - Reference)
31998.00
32726.29
0.01%
56720.43
0.40%
-0.01%
0.00%
-0.38%
-0.01%
-76686.86
-21553.43
0.34%
232235.43
1.93%
-0.42%
0.00%
-1.16%
-0.34%
-614554
322.57
98961.29
-587270.57
-126567.29
3.24%

Feature Assessment
CMCC B11 MR1 ED1.0 FO results CS and PS QoS Follow-up (6/12)
QoS non-regression for the main PS indicators:

Feature Reference Period


Feature Follow-up
(AVG)
Period (AVG)
ALC_GPRS_UL_RESOURCE_REALLOC
GPRS_UL_TBF_realloc_request
9278694.43
8918928.29
GPRS_UL_TBF_realloc_T1_request
13.86
15.57
GPRS_UL_TBF_realloc_T2_request
2228295.00
2234936.43
GPRS_UL_TBF_realloc_T3_request
3195592.00
3006243.71
GPRS_UL_TBF_realloc_T4_request
3854793.86
3677732.57
GPRS_UL_TBF_realloc_success_rate
39.66%
42.11%
ALC_GPRS_DL_DATA_TRANSFER
GPRS_DL_TBF_success
6159382.57
6216103.00
GPRS_DL_TBF_normal_release_rate
96.23%
96.43%
GPRS_DL_TBF_acceptable_release_rate
0.57%
0.60%
GPRS_DL_TBF_drop_GB
0.00
0.00
GPRS_DL_TBF_drop_BSS
1566.14
1212.57
GPRS_DL_TBF_drop_N_stagnatingWindow
12856.57
13374.14
GPRS_DL_TBF_drop_blocking
398.57
218.14
GPRS_DL_TBF_real_drop_radio
182440.43
169850.14
GPRS_DL_TBF_drop_radio
176791.00
165912.00
GPRS_DL_TBF_realloc_execution_fail_radio
12372.29
11532.71
GPRS_DL_TBF_drop_rate
3.20%
2.97%
ALC_GPRS_UL_DATA_TRANSFER
GPRS_UL_TBF_success
14852069.29
15084304.71
GPRS_UL_TBF_normal_release_rate
97.94%
98.20%
GPRS_UL_TBF_acceptable_release_rate
0.16%
0.16%
GPRS_UL_TBF_drop_GB
0.00
0.00
GPRS_UL_TBF_drop_BSS
8150.14
5727.86
GPRS_UL_TBF_drop_N_stagnatingWindow
6135.29
4809.43
GPRS_UL_TBF_drop_blocking
36612.29
31457.71
GPRS_UL_TBF_real_drop_radio
231077.29
205132.71
GPRS_UL_TBF_drop_radio
203155.43
186711.14
GPRS_UL_TBF_realloc_execution_fail_radio
35808.43
26091.29
GPRS_UL_TBF_drop_rate
1.90%
1.64%
XA_MXBSC_143

Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

(Follow-up - Reference)
-359766.14
1.71
6641.43
-189348.29
-177061.29
2.45%
56720.43
0.20%
0.03%
0.00
-353.57
517.57
-180.43
-12590.29
-10879.00
-839.57
-0.23%
232235.43
0.26%
0.00%
0.00
-2422.29
-1325.86
-5154.57
-25944.57
-16444.29
-9717.14
-0.26%

Feature Assessment
CMCC B11 MR1 ED1.0 FO results CS and PS QoS Follow-up (7/12)
QoS non-regression for the main PS indicators:
XA_MXBSC_143

Feature Reference
Period (AVG)

Feature Follow-up
Period (AVG)

ALC_GPRS_DL_TBF_ACCEPTABLE_RELEASE_CAUSES
GPRS_DL_TBF_radio_preemption_release
758.00
430.14
GPRS_DL_TBF_release_suspend
4998.14
9758.00
GPRS_DL_TBF_release_NC2_reselect
0.00
0.00
GPRS_DL_TBF_release_NC0_reselect
29247.71
27309.57
GPRS_DL_TBF_acceptable_release_rate
0.57%
0.60%
ALC_GPRS_UL_TBF_ACCEPTABLE_RELEASE_CAUSES
GPRS_UL_TBF_radio_preemption_release
128.71
78.86
GPRS_UL_TBF_release_suspend
1990.57
4203.43
GPRS_UL_TBF_release_NC2_reselect
0.00
0.00
GPRS_UL_TBF_release_NC0_reselect
22024.57
20469.71
GPRS_UL_TBF_acceptable_release_rate
0.16%
0.16%
ALC_GPRS_DL_SESSIONS
GPRS_DL_biased_transfer_time
54768536.14
54291037.29
GPRS_DL_biased_and_DL_TBF_time
22770570.71
22049025.00
GPRS_DL_biased_and_DL_optimal_allocation_time
16171746.57
16175297.00
GPRS_DL_connection_time_avg
4.34
4.25
GPRS_DL_biased_and_DL_optimal_alloc_percent
71.02%
73.36%
ALC_GPRS_UL_SESSIONS
GPRS_UL_biased_transfer_time
29106294.14
31208582.29
GPRS_UL_biased_and_UL_TBF_time
2097220.71
2115129.43
GPRS_UL_biased_and_UL_optimal_allocation_time
1088996.57
1209025.29
GPRS_UL_connection_time_avg
1.04
0.98
GPRS_UL_biased_and_UL_optimal_alloc_percent
51.93%
57.16%
Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

(Follow-up Reference)
-327.86
4759.86
0.00
-1938.14
0.03%
-49.86
2212.86
0.00
-1554.86
0.00%

See
SeeNext
Next
Slides
Slides

95.23% increase

111.17% increase

-477498.86
-721545.71
3550.43
-0.09
2.34%

2.13% decrease

2102288.14
17908.71
120028.71
-0.06
5.24%

5.37% decrease

Feature Assessment
CMCC B11 MR1 ED1.0 FO results CS and PS QoS Follow-up (8/12)
QoS non-regression for the main PS indicators:
XA_MXBSC_143

Feature Reference Period


(AVG)

ALC_GPRS_DL_RLC_TRAFFIC_ACK
GPRS_DL_useful_bytes_CSx_ack
7086559938.57
GPRS_DL_useful_bytes_MCSx_ack
7117920974.43
GPRS_DL_RLC_bytes_PDTCH_CSx_retransmissing_ack
135024769.57
GPRS_DL_RLC_bytes_PDTCH_MCSx_retransmissing_ack
1274255921.57
GPRS_DL_RLC_bytes_PDTCH_CSx_retrans_ack_rate
1.87%
GPRS_DL_RLC_bytes_PDTCH_MCSx_retrans_ack_rate
15.12%
GPRS_DL_useful_RLC_blocks_MCSx_8PSK_ack_ratio
94.32%
ALC_GPRS_UL_RLC_TRAFFIC_ACK
GPRS_UL_useful_bytes_CSx_ack
2366501578.86
GPRS_UL_useful_bytes_MCSx_ack
1877605079.86
GPRS_UL_RLC_bytes_PDTCH_CSx_retransmissing_ack
40248009.14
GPRS_UL_RLC_bytes_PDTCH_MCSx_retransmissing_ack
120058700.00
GPRS_UL_RLC_bytes_PDTCH_CSx_retrans_ack_rate
1.66%
GPRS_UL_RLC_bytes_PDTCH_MCSx_retrans_ack_rate
5.97%
GPRS_UL_useful_RLC_blocks_MCSx_8PSK_ack_ratio
35.96%
Alc_GPRS_DL_pilled_throughput
GPRS_DL_TBF_pilled_avg
2.13
GPRS_DL_active_connection_GPRS_ack_time
6366943.56
GPRS_DL_active_connection_EGPRS_ack_time
2731439.47
GPRS_DL_useful_throughput_radio_GPRS_TBF_avg
9.07
GPRS_DL_useful_throughput_radio_EGPRS_TBF_avg
21.06
Alc_GPRS_UL_pilled_throughput
GPRS_UL_TBF_pilled_avg
1.37
GPRS_UL_active_connection_GPRS_ack_time
2748762.24
GPRS_UL_active_connection_EGPRS_ack_time
1353686.43
GPRS_UL_useful_throughput_radio_GPRS_TBF_avg
7.00
GPRS_UL_useful_throughput_radio_EGPRS_TBF_avg
11.42

Feature Follow-up
Period (AVG)

(Follow-up - Reference)

7251046394.29
7156559885.86
114859517.29
1101128959.29
1.56%
13.32%
94.91%

164486455.71
38638911.43
-20165252.29
-173126962.29
-0.31%
-1.80%
0.60%

2395199608.00
1813737159.29
34950137.86
108760307.14
1.43%
5.64%
36.43%

28698029.14
-63867920.57
-5297871.29
-11298392.86
-0.23%
-0.34%
0.46%

2.04
5828538.66
2488263.71
10.01
23.22

-0.09
-538404.90
-243175.76
0.94
2.16

1.31
2560661.26
1181430.10
7.55
12.54

-0.06
-188100.99
-172256.33
0.55
1.12

Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

Feature Assessment
CMCC B11 MR1 ED1.0 FO results CS and PS QoS Follow-up (9/12)
QoS non-regression for the main PS indicators:
XA_MXBSC_143

Feature Reference
Period (AVG)

Feature Followup Period (AVG)

(Follow-up Reference)

Alc_EGPRS_LLC
EGPRS_DL_LLC_MS_Context

1239413.29

1213091.57

-26321.71

GPRS_DL_LLC_MS_Context

1095838.86

1111816.14

15977.29

EGPRS_UL_LLC_MS_Context

1215884.00

1193339.29

-22544.71

GPRS_UL_LLC_MS_Context

1131916.14

1142288.00

10371.86

GPRS_DL_LLC_Bytes

13917840939.57

14086696774.71

168855835.14

GPRS_UL_LLC_Bytes

3737802245.29

3688998647.00

-48803598.29

Alc_PDCH_traffic
GPRS_PDCH_GPRS_traffic_time

16397391.14

18112138.57

1714747.43

GPRS_PDCH_EGPRS_traffic_time

20818209.43

21002436.14

184226.71

GPRS_PDCH_active_avg

430.74

452.71

21.97

GPRS_MAX_PDCH_Dyn_avg

852.33

913.67

61.34

PS QOS Indicators are stable after feature activation


Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

GPRS Traffic has


increased by 10.4%
and EGPRS by 0.8%

Feature Assessment
CMCC B11 MR1 ED1.0 FO results CS and PS QoS Follow-up (10/12)

An increase in the DL acceptable release due to Suspend is noticed


after feature activation (around 95.23% increase than in the
reference period)

Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

Feature Assessment
CMCC B11 MR1 ED1.0 FO results CS and PS QoS Follow-up (11/12)

An increase in the UL acceptable release due to Suspend is noticed after


feature activation (around 111.17% increase than in the reference
period)

Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

Feature Assessment
CMCC B11 MR1 ED1.0 FO results CS and PS QoS Follow-up (12/12)
The increase in the acceptable release due to suspend cause is normal after feature activation;
since with the new feature, on-going GPRS sessions are suspended to serve the incoming CS calls.
In other words, we can indentify the gain of the feature by the increase of this indicator;
meaning that the increase in the acceptable release due to suspend cause may give an idea of
the number of CS calls that could have been lost if the feature is not activated.
We notice that GPRS_xL_TBF_acceptable_release_rate did not increase because of the
decrease of other acceptable release causes (namely NCO reselect & radio pre-emption release);
therefore the overall acceptable release rate did not really increase after feature activation.
GPRS_DL_connection_time_avg and GPRS_UL_connection_time_avg has a little bit decreased
(around 2.13% & 5.37% decrease). This is also normal because after feature activation there are a
higher chance to interrupt the on-going DL/UL sessions by the incoming CS calls.
Note: DL PACCH Load did not increase due to the new CS PAGING PACCH messages after feature
activation:
XA_MXBSC_143

Feature Reference Period (W942)

Feature Follow-up Period (W943)

GPRS_DL_PACCH_load(GTRPADE)(%)

4.39%

4.17%

GPRS_UL_PACCH_load(GTRPAUE)(%)

26.06%

26.41%

Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

Feature Assessment
CMCC B11 MR1 ED1.0 FO results Availability and Stability Follow-up (1/5)
Availability
Feature Activation

(Follow-up Reference)

BSC_XA_MXBSC143

Feature Reference
Period (W942)

Feature Follow-up
Period (W943)

Average_CELL2G_GPRS_Availability (%)

80.84%

83.46%

2.62%

Average_BSC_GSM_Availability (%)

100.00%

100.00%

0.00%

Average_CELL2G_GSM_Availability (%)

80.95%

83.61%

2.66%

Average_SS7SL_Availability (%)

100.00%

100.00%

0.00%

Average_TRX_Availability (%)

91.39%

93.17%

1.78%

Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

Feature Assessment
CMCC B11 MR1 ED1.0 FO results Availability and Stability Follow-up (2/5)
Total alarm occurrences:
BSC/BTS/Cell Alarms
Feature Activation

W942
Total_Alarms_Count = 183
Total_Alarms_Raised_Count = 487

W942

W943

Total_Alarms_Count = 161
Total_Alarms_Raised_Count = 347

W943

Feature Activation
Total_Alarms_Count = 43
Total_Alarms_Count = 59
Total_Alarms_Raised_Count = 27
Total_Alarms_Raised_Count = 91

Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

MFS Alarms

Feature Assessment
CMCC B11 MR1 ED1.0 FO results Availability and Stability Follow-up (3/5)
BSC Alarms:
Feature Activation

Feature Reference Period


(W942)

Feature Follow-up Period


(W943)

(Follow-up - Reference)

BSC_Communication_Alarms(nb)

20

18

-2

BSC_Environment_Alarms(nb)

BSC_Equipment_Alarms(nb)

-1

BSC_Processing_Error_Alarms(nb)

-5

BSC_QoS_Alarms(nb)

30

18

-12

TOTAL BSC Alarms

63

43

-20

BSC_XA_MXBSC143

Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

Feature Assessment
CMCC B11 MR1 ED1.0 FO results Availability and Stability Follow-up (4/5)
BTS Alarms:
Feature Activation

(Follow-up Reference)

Feature Reference
Period (W942)

Feature Follow-up
Period (W943)

BTS_Communication_Alarms_Count(BTS_Type1_A_C)(nb)

50

33

-17

BTS_Environment_Alarms_Count(BTS_Type2_A_C)(nb)

-5

BTS_Equipment_Alarms_Count(BTS_Type3_A_C)(nb)

41

52

11

BTS_Processing_Error_Alarms_Count(BTS_Type4_A_C)(nb)

30

21

-9

BTS_QoS_Alarms_Count(BTS_Type5_A_C)(nb)

127

107

-20

BSC_XA_MXBSC143

TOTAL BTS Alarms

Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

Due to a problem on
BTS_xasesn007/2/16 on
the 19th and 20th of
October (fixed after that)

Feature Assessment
CMCC B11 MR1 ED1.0 FO results Availability and Stability Follow-up (5/5)
Cell QoS alarms:

W942

CELL2G_QoS_Alarms_Count = 54

Feature Activation

W943

CELL2G_QoS_Alarms_Count = 54

Conclusion:
No regressions were observed in either availablity or stability after activating
the CS paging coordination feature.

Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

Feature Assessment
CMCC B11 MR1 ED1.0 FO results Paging Coordination Requests Estimation (1/2)
The BSS version in CMCC FO was B11 MR1 ED1.0, P390a/b counters are not available.
Accordingly, in CMCC B11 FO we could use estimation indicators previously
described to estimate the number of CS paging IEs in PAGING COORDINATION requests
sent on GSL:
Estimation
EstimationIndicators
Indicators
The 3 indicators can be an overestimated value for the number of the PAGING
COORDINATION REQUEST IEs received from the BSC, because in case of MxBSC, if
Multiple Paging on Abis is enabled and several Paging messages for same IMSI are
buffered, a single Paging Request is only sent on the GSL.
The next slide shows these 3 estimation indicators computed for the pilot BSC:

Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

Feature Assessment
CMCC B11 MR1 ED1.0 FO results Paging Coordination Requests Estimation (2/2)
Weekend

Weekend

Feature Activation

The 2nd & 3rd indicators have stable and similar values which are inline with the working
days and weekend traffic distribution.
1st indicator has a lot of peaks (sometimes equal to 2 nd & 3rd, sometimes equal to their
double values!). Also its values are not inline with weekly traffic distribution.
Conclusion: if the new counters (P390a & P390b) are not available, it is better to
use MC940 for estimating the number of PAGING COORDINATION REQUEST IEs
received from the BSC.
Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

Feature Assessment
CMCC B11 MR1 ED1.0 FO results GSL Load Monitoring in CMCC FO (1/2)
Normally, GSL counters should be used to monitor the GSL load after feature
activation because of the increased additional load coming from Paging Coordination
Request messages sent from the BSC MFS (as described in the monitoring section).
The PM counters related to GSL exist in Type 7, Type 110 BSC counters and GPMRES
PM MFS counters.
However in CMCC B11 FO, all these GSL PM counters had no values during the
reference and the feature follow-up periods as detailed in: ANNEX H
ANNEX H
Because of these issues the GSL Erlang can not be calculated as per last dimensioning
report done during CMCC FO:
Resource

Needed

Current

Status

Ater Mux PS
GSL
GP
Ater Mux CS
N7

20
?
3
19
4

20
16
3
22
16

OK
*
OK
OK
OK

(*) There are no GSL counters (P41 and P42) for during the observed period.
GSL Erlang can not be computed (?).
Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

Feature Assessment
CMCC B11 MR1 ED1.0 FO results GSL Load Monitoring in CMCC FO (2/2)
An alternative way to dimension the number of needed GSL link based on number of
GSL messages per second sent from MFS to BSC is described in Architecture and
Dimensioning B9 guidelines.
B9_Archi_Works hop
(s lides 59, 67-70)

However this method can not be used to estimate the increased load after feature
activation because we are interested in the opposite direction i.e. CS Paging
Coordination Request message from BSC to MFS.
Conclusion:
Unfortunately, calculation (or estimation) of the GSL load increase after CS paging
coordination feature activation in CMCC B11 MR1.0 FO has failed due to the issues
discussed before!

Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

B11 MR1 ED1.0 On-air Platform Tests Results

Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

Feature Assessment
B11 MR1 On-air platform results Highlights
Tests Performed Summary in B11 MR1 ED1.0 On-air Platform (Velizy):
1. Unitary CS Performance tests: for both DTM and non-DTM cases.
2. PS non-regressions tests.

Test procedure is the same as described in monitoring methods section .


Tools:

NEMO Tool Chain (Outdoor + Analyze).


Nokia N95 trace MS (MS performing PS sessions).
Agilent NITRO with Sagem OT290 trace MS (MS performing CS calls to N95 MS).
Wireshark traces were captured.
K15 Traces on RSL/RLC-MAC (Abis), GSL and A were captured during tests.

Radio Conditions: DL RxLev = -55 dBm to -60 dBm & Mean_BEP = 31.
Parameter Settings:

EN_RA_CAP_UPDATE = TRUE, Network Mode of Operation (NMO) = 2


EN_FAST_INITIAL_GPRS_ACCESS = FALSE
MAX_GPRS_CS = 4 & MAX_EGPRS_MCS = 9
TBF_xL_INI_MCS = 6 & TBF_xL_INI_CS = 2
Round_trip_delay < 500 msec (not satellite Abis/Ater)

Note: Paging Repetition is enabled in the simulated core (LSU) managing the BSC.
Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

Feature Assessment
B11 MR1 On-air platform Results - CS performance tests without DTM feature

Tests Results:
CS Paging Coordination DISABLED

CS Paging Coordination ENABLED

Number of

Call Completion

Number of

Call Completion

Terminating CS Calls

Success (Rate%)

Terminating CS Calls

Success (Rate%)

13

0 (0%)

13

13 (100%)

16

16 (100%)

PS Session Type
CS Calls During DL FTP PS Session
CS Calls During DL FTP PS Session (GPRS Mode)
CS Calls During UL FTP PS Session

13

0 (0%)

13

13 (100%)

CS Calls During PING "Pause 0s" PS Session

11

0 (0%)

11

11 (100%)

CS Calls During PING "Pause 1s" PS Session

10

0 (0%)

10

10 (100%)

CS Calls During PING "Pause 5s" PS Session

17

5 (29.4%)

17

12 (100%)

Notes about Tests Results:


- Same results and observations as CMCC B11 MR1 ED1.0 FO:

Call Completion success rate is 100% when the feature is activated during the different PS
sessions in EDGE and GPRS modes.
When the feature is deactivated all the CS terminating calls are lost (Call Completion success
rate is 0%) except for PING session with relatively long pause durations.

- The issue of losing some CS paging during Ping Sessions with relatively long durations was
not noticed in on-air platform tests. Most probably because Paging Repetition is Enabled in
core (LSU), which decreases the risk of this issue (as previously described).
Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

Feature Assessment
B11 MR1 On-air platform Results - CS performance tests with DTM feature (1/6)

Test Results
CS Paging Coordination DISABLED

CS Paging Coordination ENABLED

DTM is ENABLED

DTM is ENABLED

Number of DTM Calls DTM Call Completion Number of DTM Calls DTM Call Completion
PS Session Type
(incoming CS Calls)

Success (Rate%)

(incoming CS Calls)

Success (Rate%)

CS Calls During DL FTP PS Session

11

0 (0%)

10

10 (100%)

CS Calls During UL FTP PS Session

10

0 (0%)

14

14 (100%)

CS Calls During PING "Pause 0s" PS Session

4 (0%)

7 (100%)

CS Calls During PING "Pause 2s" PS Session

13

2 (15.38%)

Notes about Tests Results:

- DTM Call Completion success rate is 100% when the feature is activated during the different
PS sessions.

- When the feature is deactivated all the DTM calls were not completed (DTM Call Completion
success rate is 0%) except for PING session with 2 sec pause, because of the same reason
mentioned before.

- The same scenario happens (like without DTM) when the feature is deactivated, Call
Disconnect is sent to the Calling MS with cause 18 No user responding.
Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

Feature Assessment
B11 MR1 On-air platform Results - CS performance tests with DTM feature (2/6)

DTM call establishment main procedures overview (FTP UL and CS call):


1. MS is in PTM mode (performing an UL FTP Transfer).
2. CS paging on PACCH (feature activated), MS leaves PTM, CS call is being
established (dedicated mode).
3. CS call is established, MS is transferred to DTM mode (performing an UL FTP
transfer and CS call simultaneously).
4. CS is Released, MS is in PIM then back to PTM.

Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

Feature Assessment
B11 MR1 On-air platform Results - CS performance tests with DTM feature (3/6)

Main procedure snapshots when feature is activated and DTM activated


(FTP UL Transfer Session and CS call) (1):

Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

Feature Assessment
B11 MR1 On-air platform Results - CS performance tests with DTM feature (4/6)

Main procedure snapshots when feature is activated and DTM activated


(FTP UL Transfer Session and CS call) (2):

Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

Feature Assessment
B11 MR1 On-air platform Results - CS performance tests with DTM feature (5/6)

Main procedure snapshots when feature is activated, DTM activated and


FTP UL Transfer Session (3):

Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

Feature Assessment
B11 MR1 On-air platform Results - CS performance tests with DTM feature (6/6)

Main procedure snapshots when feature is activated, DTM activated and


FTP UL Transfer Session (4):

Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

Feature Assessment
B11 MR1 On-air platform Results - PS Non-regressions Tests Results

Test Results:
CS Paging Coordination DISABLED
Average Application

PING

Throughput

Success

(Kbits/sec)

Rate %

2 x DL FTP PS Session

259.63

2 x UL FTP PS Session

PS Session Type

1001 PING 32B "Pause 0s" PS Session

CS Paging Coordination ENABLED


Average Application

PING

Throughput

Success Rate

(Kbits/sec)

259.70

153.35

153.12

100%

100%

Average
RTT (ms)

192.67

Average
RTT (ms)

192.75

- From the above results, we observe no regressions in terms of FTP throughput, Ping
success rate and RTT.

Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

Conclusion

Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

Conclusion (1/2)
CS Paging Coordination FO Results:
Unitary Tests Results:

When the feature is activated, all terminating CS calls performed towards an MS currently
engaged in a PS session are well received (100% success) except for Ping PS session with
relatively long duration (3, 4, 5 .) seconds between iterations where around 90 94%
success is experienced.

After analysis done by TD for this issue, the conclusion is that ALU BSS B11 SW is compliant
to 3GPP specs where no means to avoid losing some CS paging requests in all situations is
described, the explanation for the reason of this problem is to be provided to the customer,
no change is needed in ALU B11 BSS SW.

This issue will probably occur more in networks having Paging Repetition not enabled in the
Core Network (ex: this issue was not encountered during Velizy on-air platform feature
tests because paging repetition was enabled in simulated core (LSU).

No regression in data performance PS tests after feature activation.

Statistical Tests Results:

No regression in CS and PS main KPIs after feature activation.

No regression of availability & stability of the BSC/BTSs/Cells after feature activation


Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

Conclusion (2/2)
Statistical Tests Results Contd:

Increase of DL/UL acceptable release due to suspend cause after feature activation which is
normal because there is higher probability of interrupting the on-going PS session by
incoming CS calls.

If the new counters (P390a & P390b) are not available, it is better to use MC940
counter for estimating the number of PAGING COORDINATION REQUEST IEs received
from the BSC.

GSL Load increase study after feature activation:


Unfortunately, it was not accomplished due to the issues will all PM GSL counters in
CMCC B11 MR1.0 FO and the unavailability of the new feature counters (P390a/b) .

Support of CS paging Coordination in BSS feature is recommended to be activated in


networks hoping for an increase of CS Paging Performance and/or full DTM feature
support without implementing Gs-interface in core network while ensuring no
degradation in end-user data performance, CS & PS QoS KPIs and network stability &
availability as seen in CMCC B11 MR1 ED1.0 FO.
However, GSL load/dimensioning should still be monitored/assessed after feature
activation as no quantification of its expected increase could be accomplished during
FO.
It is worth mentioning that DTM still needs FMA to be open for Commercial use.
Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

www.alcatel-lucent.com
www.alcatel-lucent.com

Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

ANNEX

Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

Annex A
Network Mode of Operation & MS Classes (1/4)
The 3GPP standard has defined three network operation modes for paging
coordination between CS and PS:

Network operation mode I:

The network sends a CS paging message for a GPRS-attached MS, either on the same
channel as the CS paging channel (PCH) or on a GPRS traffic channel (PACCH).

The MS needs only to monitor one paging channel.

It receives CS paging messages on the packet data channel when it has been assigned a
packet data channel. Gs interface is needed between the MSC and SGSN for to carry
the CS paging to SGSN

no CS paging is lost.

MSC
GS

BSS
Gb

SGSN

Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

Annex A
Network Mode of Operation & MS Classes (2/4)

Network operation mode II:

The network sends a CS paging message for a GPRS-attached MS on the CCCH paging
channel, and this channel is also used for GPRS paging.

The MS needs only to monitor the CCCH paging channel.

CS paging continues on CCCH paging channel even if the MS has been assigned a packet
data channel.

CS paging messages received while the MS is in packet transfer mode are lost.

Network operation mode III (in case of MPDCH):

The network sends a CS paging message for a GPRS-attached MS on the CCCH paging
channel, and sends a GPRS paging message on either the packet paging channel
(PPCH) (if allocated in the cell) or on the CCCH paging channel.

A MS that wants to receive paging messages for both circuit-switched and packetswitched services shall monitor both paging channels in the cell, if the packet-paging
channel is allocated.

The network performs no paging coordination.

CS paging messages received while the MS is in packet transfer mode are lost.
Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

Annex A
Network Mode of Operation & MS Classes (3/4)

The below table shows the paging coordination (CS & PS) and the radio channels used in the
different network modes of operation till B10:

Note that BSS paging coordination is not taken into consideration in this table.

Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

Annex A
Network Mode of Operation & MS Classes (4/4)
GPRS MS Modes of Operation:

Class A:
The MS is attached to both GPRS and GSM. MS supports simultaneous
attach, simultaneous activation, simultaneous monitor and simultaneous
traffic. The mobile user can make and/or receive calls/sessions on the two
services simultaneously. Needs 2 independent transmitter/receiver.

Class B:
The MS is attached to both GPRS and GSM, but the MS can only operate one
set of services at a time. When the MS is in both idle mode and packet idle
mode it should be able to monitor paging channels for both circuit-switched
and packet-switched services depending on the mode of network operation
and the implementation of the CS paging coordination in the BSS.

Class C:
The UE is attached to either GPRS or other services. Alternate use only.

BACK
BACK
Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

ANNEX B
B10 Dual Transfer Mode (DTM) (1/6)

Idle Mode:
The mobile is in idle mode when not engaged in a connection for either PS
or CS.
Dedicated Mode:
The MS is in dedicated mode when a SDCCH or a TCH has been established
for a CS call.
Packet Transfer Mode:
The mobile is in packet transfer mode (PTM) when a PS transaction is
established. Contrarily to dedicated mode, the packet transfer mode allows
multiplexing several MS on one or several radio channels.
Dual transfer mode (DTM):
Combination of packet transfer mode and dedicated mode.

Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

ANNEX B
B10 Dual Transfer Mode (DTM) (2/6)
Description:
Allows establishing simultaneously within one single GSM mobile station a packet
transaction and a circuit switched call, without the need for class A mobiles.
Example: sending a photo during a voice call, or browsing through emails while talking
with another person.
Since simultaneous CS/PS traffic capability is natively offered by UMTS, the DTM feature
is particularly interesting for 2G Operators being in competition with 3G operators, or for
2G/3G Operators for 3G services continuity purpose in areas where 3G services are not
offered.
DTM feature is an optional feature since B10.
The DTM feature is introduced by 3GPP:
Feature part of Release 99 specifications with improvements in Release 4, 6 and 7.
B10 implementation is aligned with Release 4 definition of the feature.

Has impact on BSS, MS software and some Core Network dependencies.

Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

ANNEX B
B10 Dual Transfer Mode (DTM) (3/6)
Mode Transitions for DTM capable MSs in 3GPP R4

Dual
transfer

Packet
request

Direct transition from PTM to DTM not possible

Packet
release

First release the TBFs


Establish CS
Then re-establish TBFs in DTM

Direct transition from DTM to PTM not possible


First release TCH and PDCHs
Then re-establish the TBFs in PTM

RR
release

Direct transition from Idle mode to DTM not possible: Dedicated mode is a mandatory phase
Transition from DTM to dedicated mode is possible

Dedicated

Packet
transfer

RR
release

Packet
access
TBF
release

RR
establishment
Idle /
Packet
idle

Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

ANNEX B
B10 Dual Transfer Mode (DTM) (4/6)

Class A DTM Modes of Operation:

Like a class A mobile, but without the need of a dual transmitter/receiver.

Scenario 1: Entering the DTM mode for a MS


already in Packet Transfer Mode and receiving a
CS call request.
Scenario 2: Releasing the CS connection in DTM.
Scenario 3: Releasing the PS connection in DTM,
then releasing the CS connection.

Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

ANNEX B
B10 Dual Transfer Mode (DTM) (5/6)
Supported radio configurations :

DTM Multislot class 5:

1 TCH + 1 DL PDCH and 1 UL PDCH

DTM Multislot class 9:

1 TCH + up to 2 DL PDCH and 1 UL PDCH

DTM Multislot class 11:

1 TCH + up to 2 DL PDCH and 1 UL PDCH


1 TCH + 1 DL PDCH and up to 2 UL PDCH (*)

DTM Multislot class 31:

1 TCH + up to 3 PDCH DL and 1 UL PDCH.

DTM Multislot classes 32, 33:

1 TCH + up to 3 PDCH DL and 1 UL PDCH.


1 TCH + up to 2 PDCH DL and 2 PDCH UL (*)
(*) These configurations require the
activation of the EDA B10 feature.

Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

ANNEX B
B10 Dual Transfer Mode (DTM) (6/6)
DTM requirements:

Only supported by Evolium BTSs.

Only supported in non-extended cells (to simplify implementation).

The MAX_PDCH_HIGH_LOAD 2, at least 2 TS are needed for DTM resource allocation.


The DTM resources will be allocated inside the non-preemptable zone.

No guarantee by ALU of DTM correct behavior when CS paging coordination is absent:


Either through Gs interface (NMO I) CS paging through SGSN or
By activating the B11 feature Support of CS paging coordination in the BSS (NMOII).
This is to avoid loss of CS paging requests while the MS is in Packet Transfer Mode

Support of CS paging coordination is highly recommended with DTM feature.


BACK
BACK
Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

Annex C
Format of PAGING COORDIANTION REQ message

The new PAGING COORINATION REQUEST message sent from the BSC to the MFS
has the following content:

The CS Paging IE Information element is defined as follows:

TMSI and eMLPP Priority fields are optional (their length could be ZERO)
Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

BACK
BACK

ANNEX D
CS paging coordination in SGSN Modification non B11 feature

The assumption that the SGSN always provides for MS in PTM mode the most accurate
cell is true of ALU SGSN but maybe false for other SGSN vendors .

The strategy used in CS Paging coordination in the BSS can be also used in SGSN to
remove the risk of the Assumed SGSN behavior.

The idea is to take profit of IMSI vs MS Context relationships to use a similar


algorithm to manage the Paging Coordination for both cases (in SGSN/in BSS).

When MFS receives a GMM-PAGING-CS message the MFS shall :


1. Browse through the set of IMSI vs MS Context relationships to find the corresponding IMSI;
2. If IMSI is found (i.e. MS is in PTM mode), MS Context is known and the CS Paging is sent on the
corresponding PACCH;
3. Otherwise (IMSI not found), MS is not in PTM mode, the CS Paging has to be sent on PCH (CS
Paging is forwarded to the BSC through the GSL with the Paging Area provided by the SGSN).

This option is linked to the use of Gs interface in the core network and not with the
Support of paging coordination in the BSS B11 feature.
Remark: This option has not been implemented yet in our B11 BSS release. This option (if
implemented in future releases) has to be estimated separately including non-regression tests.
Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

ANNEX E
Monitoring methods Tests Pre-requisites (1/2)
Unitary Tests pre-requisites:
At least 1 cell of one BSC:
o
o
o
o

Not presenting any congestion issue: neither on air nor on transmission resources.
Avoid satellite Abis/Ater cells (Round_trip_delay > 500 msec) feature not functional.
Tests during the reference week EN_BSS_PAGING_COORDINATION = FALSE
Tests during the feature observation week EN_BSS_PAGING_COORDINATION = TRUE

NEMO tool chain (Outdoor + Analyze), 1 trace MS (ex: Nokia N95) + SIM card.
1 additional MS used for performing calls towards the trace MS + SIM card.
(Optional) K15 traces on GSL, A and RSL & RLC-MAC (Abis).
Dedicated server available for FTP transfers & Ping (APN, user name, password).
The radio conditions during tests should be very good:
o At least DL RxLev >=-65dBm, RxQual = 0 and/or Mean_BEP between 27 and 31.

Resources:
o 1 RNE for Data Performance Tests and Post Processing.
o 1 OMC-R Support for changing the parameters.
o (optional) TSC support for taking K15 traces.

Reference and feature observations tests should be performed at the same hour
and in the same location; busy hours of the selected should be avoided.
Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

ANNEX E
Monitoring methods Tests Pre-requisites (2/2)
Statistical Tests pre-requisites:
Reference and observation periods statistical Data for 1 BSC:
o Main CS & PS QoS KPIs, unavailability and stability indicators.

Reference period minimum 1 week (EN_BSS_PAGING_COORDINATION = FALSE).


Observation period minimum 1 week (EN_BSS_PAGING_COORDINATION = TRUE).
Particular periods statistical data for cells were unitary tests took place.
NPO & NPO LASER / NPO4U tool availability.
Reference ACIE files (before &after feature activation, during Unitary tests) should be
stored for parameters check.

BACK
BACK
Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

ANNEX F
Monitoring methods Unitary Expected results (1/2)
CS Performance without DTM Tests Expected Results:
When feature is Deactivated:

All terminating CS calls will be lost (MS is unreachable) while MS is transferring data
(uploading / downloading in UL/DL FTP tests).

While MS is performing PING sessions, it is interesting to notice that some of the


terminating CS calls may be possible (PCH Paging). As the Pause duration increases, the
chance of catching the CS Paging on PCH is higher.

When feature is Activated:

All terminating CS calls performed towards the MS during any PS session should be received
(i.e. 100% success rate). The PS session will be suspended till the CS call finishes.

CS Performance with DTM Tests Expected Results:


When feature is Deactivated:

DTM calls will not be possible, CS paging will be lost while MS is transferring data
(uploading / downloading in UL/DL FTP tests).

However in PING sessions, some DTM calls may be possible (PCH Paging), as the Pause
duration increases, chance of establishing DTM calls is higher.
Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

ANNEX F
Monitoring methods Unitary Expected results (2/2)
CS Performance with DTM Tests Expected Results (Contd):
When feature is Activated:

DTM calls will be established (100% success rate), CS paging will be captured in any PS
sessions.

The PS session will be suspended till the CS call is established, afterwards CS and PS sessions
will be simultaneously active (DTM).

Non-regression PS Performance Tests Expected Results:


1. For UL/DL FTP PS sessions:
Non-regression in terms of UL/DL throughput.
2. For PING session:
Non-regression in terms of RTT and Ping Success Rate.

BACK
BACK
Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

ANNEX G
GSL Load (1/3)
GSL load is the main issue of concern in ALU implemented strategy
4 methods are used to reduce the extra BSCGP load (GSL load):
1. Information sent to the MFS is reduced to the minimum only IMSI (no Paging area is provided).
2. Filtering is performed by the BSC (no load of the GSL with useless CS paging requests).
3. The MS context is NOT shared with the BSC, this is to save any extra MFS to BSC synchronization
messages.

Example for MFSBSC sync: if the MFS will inform the BSC that an MS has entered or leaved the PTM mode,
on the other hand this will avoid conveying useless CS paging requests on the GSL for MS not in PTM mode
(or even for non-GPRS attached MS).

4. Multiple Paging commands is performed on the GSL in same way and in parallel with Multiple
Paging command on Abis (managed by same set of parameters T_SEND_MULTIPLE_PAGING_CMD
and NB_MAX_MSG_MULTIPLE_PAGING_CMD).
Remark: Multiple Paging on GSL is NOT available for G2 BSC.
Due to this extra BSCGP load needed to manage PAGING COORDINATION REQ messages, it may be
necessary to manage a 3rd GSL per GPU.
However there is a very low risk because normally the GSL load occur in the MFSBSC and not in
the opposite direction BSCMFS; however it may be useful to assess / dimension the GSL load.

Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

ANNEX G
GSL Load (2/3)

We can use the normal way in dimensioning the GSL load (as described in BSS Architecture
Guidelines document) based on GSL Bandwidth:

We can use the two MFS counters P41 and P42 (7-day Busy Hour data, recommended) after
activating the feature
P41: Number of kilobytes sent to the BSC on the LapD link.
P42: Number of kilobytes received from the BSC on the LapD link

We will use the following formulas to calculate the number of required GSLs:
Max( P 41,P 42 )
28800
Re quired _ GSL _ traffic Measured _ GSL _ traffic 30%m arg in
Measured _ GSL _ traffic

Nb of Re quired GSL InverseErlangC Required_GSL_traffic; quantile; delay

We will check the GSL load using these 2 formulas, if the GSL load is higher than 80% the
number of GSLs per GPU should be increased:
Measured _ traffic _ 1GSL

GSL _ load

Measured _ GSL _ traffic


Nb of required GSL

Measured _ traffic _ 1GSL


100%
GSL _ Capacity ( 0.78Erlangs )

The assessment based on number GSL messages/sec is only done in the MFS BSC direction
(being the more critical direction), the maximum number of GSL links from both methods will
be used.
Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

ANNEX G
GSL Load (3/3)

New B11 indicators provided at GSL level (type 7) can be consulted to monitor the GSL
load in the BSCMFS direction (UL):

GSL_BSC_MFS_Message_Sent: Number of GSL messages sent by the BSC to the MFS on one GSL link.

GSL_BSC_MFS_Sent_Bytes: Number of bytes sent to the MFS on 1 GSL link.

GSL_BSC_MFS_Sent_Bytes_Max:Maximum number of bytes of the GSL flow sent by the BSC to a given GPU in
one minute during the granularity period of monitoring.

GSL_BSC_MFS_Message_Sent_Max: Maximum number of GSL messages sent by the BSC on a given GSL link to
the MFS in one minute during the granularity period of monitoring.

GSL_BSC_MFS_Message_Sent_Avg: Average number of GSL messages queued in the BSC transmission buffer of
one GSL link (at Layer 2 level).

GSL_MFS_BSC_BSCGP_Message_Received: Number of BSCGP messages received by the MFS from the BSC.

GSL_LAPD_Congestion_Time: Time (s) during which the GSL LapD link is congested in transmission in the BSC.

Starting B11 MR1 ED2, the new counter P390a (counting the number of Paging
Coordination Request received by the GPU) can be used to get the number of CS paging
coordination message / sec sent by the BSC on the GSL interface.

For older B11 versions, the estimation indicator (= MC940) can be used as an
approximate value; however this estimation indicator does not indicate that the
feature is working (because it will have values before/after feature).
o

BACK
BACK

Counter P42 & the above indicators can be consulted and compared after feature activation
which should have higher values as long as we are comparing in steady traffic conditions.
Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

ANNEX H
CS paging success when feature is not activated (1/3)
Ping session (101 iter., 32B, Pause 5 sec) is on-going, many CS calls is continuously
performed randomly, but there was no chance to catch the pause period (MS in PIM)
i.e. CS paging is lost MS is unreachable (1):

Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

ANNEX H
CS paging success when feature is not activated (2/3)
During the 5 sec pause duration (MS in PIM), a CS paging request is received on CCCH
(PCH), leading to the suspension of the (E)GPRS session (2):

Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

ANNEX H
CS paging success when feature is not activated (3/3)
After CS call is released, (E)GPRS Ping session is resumed (3):

BACK
BACK
Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

ANNEX I
Loss of CS calls during pings with relatively long pause between iterations (1/7)
History of the issue and investigations performed:
At first the issue was observed for both Ping Sessions with 32B & 1460B ping sizes and 5 sec pause
between iterations.
Issue being more severe in case of 1460B Pings than in case of 32B Pings.
(CS paging success rate = 94.18% & 90.36% respectively).
Tests were repeated on 2 different cells (in good radio conditions) to make sure that the issue is
not depending on the chosen cell.
Both NEMO Ping and DOS ping tests were tried, CS calls were lost in both Ping sessions i.e. not an
application problem.
High paging load problem was suspected and to check that, the tests were repeated with other
Ping sessions (short pause durations) and FTP DL & UL, all calls were received terminating CS
success rate = 100% i.e. not a high paging load problem.
Normally the CS paging failure is associated with a Ping Success i.e. it is not related to the issue
of big Ping size with long Pause duration (FR: 3BKA45FBR287330).

Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

ANNEX I
Loss of CS calls during pings with relatively long pause between iterations (2/7)
More tests were carried out to check if the above issue also appeared for Ping sessions with other
pause durations (3, 4, 7 and 10 sec). Below were the results we got:
PS Session Type

Number of Lost Calls (Success Rate%)

50 CS Calls During PING 1460B "Pause 3s" 101 iterations PS Sessions

4 (92%)

50 CS Calls During PING 1460B "Pause 4s" 101 iterations PS Sessions

2 (96%)

100 CS Calls During PING 1460B "Pause 5s" 101 iterations PS Sessions on 2 different cells

8 (92%)

50 CS Calls During PING 1460B "Pause 7s" 101 iterations PS Sessions

2 (96%)

50 CS Calls During PING 1460B "Pause 10s" 101 iterations PS Sessions

1 (98%)

From the previous table we can deduce that the issue appears for Ping sessions with relatively long
pause durations between iterations (3, 4 ,5, 7, 10 sec).
The common behavior among all the above Ping sessions is the change of MS states PTMPIM
during the session, as the pause duration increases the MS stays more in PIM and there is a less
probability of losing CS paging.
For PS sessions that always stay in PTM (no PTM PIM changes) that CS paging success rate is
100%. These sessions are UL FTP, DL FTP, Ping with Pauses 0, 1 sec.
NE has suggested the following hypothesis (next slide) that could be the cause of the problem:
Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

ANNEX I
Loss of CS calls during pings with relatively long pause between iterations (3/7)
A. Ping sessions with relatively long pause duration are characterized by this behavior:
TBF is established for the transfer (MS in PTM), MFS creates an IMSI vs MS Context entry
because MS is PTM i.e. CS paging can be sent on PACCH.
After that the Pause duration starts, dummy blocks are sent to extend time when the TBF is
established, i.e. CS paging can still be sent on PACCH.
Because the pause duration is long, the TBFs are released (no TSs allocated) and the mobile
leaves PTM i.e. PIM, MFS deletes IMSI vs MS context entry because MS left PTM, CS paging will
not be sent on PACCH but will only be sent on CCCH channels (PCH).
The TBF is re-established for the next Ping transfer and so on

B. Normally when the BSC receives a CS paging from the MSC:


The BSC forwards this paging on the Abis to the BTSs for paging on PCH.
Also BSC sends on the GSL to the MFS (CS paging coordination request), MFS checks if the MS is in
PTM (has an existing IMSI vs MS context entry); if found it will forward this Paging on PACCH, if
there is no IMSI vs MS context entry the MFS discards the request and does nothing.

Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

ANNEX I
Loss of CS calls during pings with relatively long pause between iterations (4/7)
C. MS goes back to PTM when CS Paging starts while the MFS still believes it is PIM:
Due to this quick change in the MS states PTM PIM back and forth, there may be a chance
when the CS paging is received on PCH and the mobile has just left PIM and entered PTM.
At this instant that MFS "believes" the MS is in idle mode while the MS is actually in PTM mode.
Hence, the MFS discards the corresponding CS paging coordination request (for the MFS the MS
is in idle mode, i.e. no corresponding IMSI vs MS context entry for this MS) and therefore the
CS Paging is NOT sent on PACCH.
Till this entry is created inside MFS, the time during which the MS can be paged is over.
Therefore the CS paging message is lost (i.e. the MS is not reachable).

This NE hypothesis was discussed and agreed with SYT and later it was proven to be
the cause of the problem.
Note: EN_EXTENDED_UL_TBF parameter also impacts the time the MS is in PTM, however issue
also occurred with different settings EN_EXTENDED_UL = (I-EUTM is used) & (EUTM is used).

Further analysis from SYT (and VAL) teams showed that the exact behavior of the
problematic scenario is as follows:
Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

ANNEX I
Loss of CS calls during pings with relatively long pause between iterations (5/7)
Problematic scenario in case of transition from packet idle mode to packet transfer mode:
1) The MS has no traffic (packet idle mode from MFS point of view: the last delayed DL / extended UL
phases are over if there was a previous ping done with the MS).
2) A new ping is triggered MS sends (EGPRS Packet) Channel Request on RACH to establish an UL TBF
3) The MFS sends back an Immediate Assignment to the MS.
4) On reception, the MS passes in Packet Transfer Mode:
Extract from TS 44.018 section 3.5.2.1.3.1: On receipt of an IMMEDIATE ASSIGNMENT message or,
in case of a two-message assignment, a matching pair of IMMEDIATE ASSIGNMENT messages
corresponding to one of its 3 last CHANNEL REQUEST or EGPRS PACKET CHANNEL REQUEST
messages, the mobile station stops T3146 (if running), stops sending CHANNEL REQUEST or
EGPRS PACKET CHANNEL REQUEST messages, and switches to the assigned PDCH.
5) The MFS then begins to schedule USFs.
6) The MS sends the TLLI in the first UL RLC PDU which will allow contention resolution, and will send
the next UL RLC PDUs in sequence.
7) At that stage, the MFS does not know yet the IMSI of the MS (and the previous entry in the IMSI
table of the MFS was anyway removed for this MS, because the MS was in PIM in step 1)).
8) Later, the MFS can know the IMSI either through the RA Cap. update procedure or a DL LLC PDU to
be sent to the MS; Only when such events occur, link between TLLI and IMSI can be done at MFS side.
Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

ANNEX I
Loss of CS calls during pings with relatively long pause between iterations (6/7)
Problem occurs if there is a CS paging request arrives in the BSC between step 4)
(when MS leaves to PTM) and step 8) (IMSI is known inside the MFS), this paging
request will be lost because the MS is in PTM, but the MFS does not send any paging
request on PACCH because it does not know the IMSI of the MS yet (the link between
TLLI and IMSI is not feasible yet).

Conclusion:
From specification point of view, ALU BSS is compliant to 3GPP.
3GPP does not provide the means to avoid losing some CS paging requests in all
situations, in particular like the problematic scenario previously described (when
a CS paging request arrives in the BSC between step 4) and step 8)).
This explanation is to be provided to the customer, no change is needed in ALU
BSS SW.

Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

ANNEX I
Loss of CS calls during pings with relatively long pause between iterations (7/7)
Additional important notes:
In case Paging Repetition is enabled at the core (MSC/VLR) side, there is a very
very low risk to have such issue (loss of CS calls during pings with long pause
durations):

Because the risk of getting more than one collision in same MTC is very low in the

field, that is to say: if the paging repetition at the core side is 1, it is very
unlikely to receive the 2 CS paging messages while the MS is in the
problematic phase (MS is in PTM and IMSI is not yet known at MFS side).
As the paging repetition increases, this risk decreases even more.
The problem was detected in CMCC FO because Paging repetition is not enabled
in Huawei core.
R&D VAL team tests showed that when Paging Repetition is enabled, all MTCs
were received (100% success) during Ping sessions with relatively long pauses.
The RA Capacity Update procedure (EN_RA_CAP_UPDATE) should be enabled to
minimize a bit the losses of CS paging requests (which is triggered at completion of
TBF UL establishment to speed-up the IMSI retrieval).
Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.

BACK
BACK

ANNEX J
GSL PM counters Issue in CMCC B11 MR1.0 FO

New B11 BSC counters 106x (type 110): The new B11 BSC GSL Counters (MC1060 ->
MC1067) in type 110 are empty (FR: CUSA00FAG244164).
New B11 BSC Counters L2.x (type 7): only 1 GSL is reported in the PMTAR T07 files
(instead we should have 16 GSLs) making it impossible to monitor each GSL link.
New MFS counters P7x: After B11 migration, the MFS counters P7a, P7b, P7c_1, P7c_2,
P7d, P7e, P7f, P7g, P7h & P7i are always equal to zero (FR: CUSA00FAG244542).
Old MFS counters: the MFS counters P41 and P42 are without values after B11
migration (not present in the MFS GPMRES PMTAR files) (FR: CUSA00FAG244162).
Old MFS counters: P2a, P2b, P2c, P2d & P32: not present in the MFS GPRMES PMTAR
files, same issue like P41 & P42 because the whole block for BSC_MFS LAPD is not reported
in GPRMES files.

BACK
BACK
Alcatel-Lucent Internal
Proprietary Use pursuant to Company instruction.