TMO18096 - V2 SG B12 Ed1 - CE PDF

Passing on and copying of this document, use and communication of its
contents not permitted without written authorization from Alcatel-Lucent
Copyright 2013 Alcatel-Lucent. All Rights Reserved.

TERMS OF USE AND LEGAL NOTICE
Alcatel-Lucent provides this training course to you subject to these Terms of Use and Legal Notice. Your use of this training
course and/or this site constitutes your acceptance of and agreement to these Terms of Use and Legal Notice. These Terms
of Use and Legal Notice, as well as the contents of this training course, may be updated or amended by Alcatel-Lucent from
time to time without prior notice to you. Your use of the Alcatel-Lucent training materials after such update or amendment
constitutes your acceptance of and agreement to said updated or amended Terms of Use and Legal Notice.
SAFETY WARNING
Alcatel-Lucent training materials can be for products or refer to products that have both lethal and dangerous voltages
present. Always observe all safety precautions and do not work on the equipment alone. The user is strongly advised not to
wear conductive jewelry while working on the products. Equipment referred to or used during this course may be
electrostatic sensitive. Please observe correct anti-static precautions.
PERMISSION TO USE CONTENT

The information, communications, scripts, photos, text, video, graphics, music, sounds, images and other materials provided
in this training course (collectively the "Content"), is intended for the lawful use of employees of Alcatel-Lucent and other
authorized participants in this Alcatel-Lucent training course. You are hereby granted a non-exclusive, non-transferable
permission to access and use the Content solely for your personal training and non-commercial use. This permission may be
terminated by Alcatel-Lucent at any time for any reason or no reason, with or without notice. You must immediately cease
use of the Content upon such termination.
COPYRIGHTS AND TRADEMARKS

The unauthorized copying, displaying or other use of any Content from this training course is a violation of the law and
Alcatel-Lucents corporate policies. The Content is protected in France, the U.S. and other countries by a variety of laws,
including but not limited to, copyright laws and treaty provisions, trademark laws, patent laws and other proprietary rights
laws (collectively, "IP Rights"). In addition to Alcatel-Lucents IP Rights in the Content, in part and in whole, Alcatel-Lucent,
and any of the third parties who have licensed and/or contributed to the Content, owns a copyright in the formatting and
presentation of the Content.
Alcatel-Lucent does not grant you any permission to use the Content other than the permission expressly stated in these
Terms of Use and Legal Notice. All other use of Content from this training course, including, but not limited to, modification,
publication, transmission, participation in the transfer or sale of, copying, reproduction, republishing, creation of derivative
works from, distribution, performance, display, incorporation into another training course or presentation, or in any other way
exploiting any of the Content, in whole or in part, for uses other than those expressly permitted herein is strictly prohibited
and shall not be made without Alcatel-Lucents prior written consent. All characters appearing in this training course are
fictitious. Any resemblance to real persons, living or dead, is purely coincidental.
There may be a number of proprietary logos, marks, trademarks, slogans and product designations found in the
Content. Alcatel, Lucent, Alcatel-Lucent and the Alcatel-Lucent logos are trademarks of Alcatel-Lucent. All other trademarks
are the property of their respective owners. Alcatel-Lucent does not grant you a license to use any of the foregoing logos,
marks, trademarks, slogans and product designations in any fashion. Granting of the right to access and use the Content for
training purposes does not confer upon you any license under any of Alcatel-Lucents or any third party's IP Rights.
DISCLAIMER
ALCATEL-LUCENT DISCLAIMS ALL WARRANTIES REGARDING THE TRAINING COURSES OR THE CONTENT, EXPRESS OR
IMPLIED, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE. THE ALCATEL-LUCENT WILL NOT BE RESPONSIBLE OR LIABLE FOR ANY INJURY, LOSS, CLAIM,
DAMAGE, OR ANY SPECIAL, EXEMPLARY, PUNITIVE, INDIRECT, INCIDENTAL OR CONSEQUENTIAL DAMAGES OF ANY KIND
(INCLUDING WITHOUT LIMITATION LOSS PROFITS OR LOSS SAVINGS), WHETHER BASED IN CONTRACT, TORT, STRICT
LIABILITY OR OTHERWISE, THAT ARISES OUT OF OR IS IN ANY WAY CONNECTED WITH (A) ANY USE OR MISUSE OF THE
CONTENT OR THE TRAINING COURSES BY YOU, OR (B) ANY FAILURE OR DELAY BY ALCATEL-LUCENT, ITS OFFICERS,
DIRECTORS, AGENTS OR EMPLOYEES IN CONNECTION WITH THE CONTENT OR THE TRAINING COURSES (INCLUDING,
WITHOUT LIMITATION, THE USE OF OR INABILITY TO USE ANY COMPONENT OF THE CONTENT OR TRAINING BY
YOU). SOME JURISDICTIONS LIMIT OR PROHIBIT SUCH EXCLUSION OF WARRANTIES OR LIMITATION OF LIABILITIES
AND SO THE FOREGOING EXCLUSION OF WARRANTIES OR LIMITATION OF LIABILITY MAY NOT APPLY TO YOU.
GOVERNING LAW
These Terms of Use and Legal Notice are governed by the laws of France. The operation and use of the training course is
governed by the laws of the country that governs your employment contract, if applicable. If any provision of these Terms of
Use and Legal Notice, or the application thereto to a person or circumstance, is held invalid or unenforceable by law, statute
or a court of competent jurisdiction, for any reason, then such provision shall be modified and/or superseded by a provision
that reflects the intent of the original provision as closely as possible. All other provisions of these Terms of Use and Legal
Notice shall remain in full force and effect. You may not assign these Terms of Use or any permission granted hereunder
without Alcatel-Lucents prior written consent. Nothing herein shall be deemed an employment agreement or an offer of
employment or an alteration in any way of a users terms of employment with or within Alcatel-Lucent.
Copyright 2013 Alcatel-Lucent. All Rights Reserved

Welcome to BSS
B12 GSM Quality of Service and Traffic Load
Monitoring
1. GSM QoS Monitoring

1. Introduction
2. Indicators_Overview
3. Call_Establishment
4. TCH_Established_Phase
5. Handover_Indicators
2. GSM Traffic Monitoring
1. Traffic_Indicators
3. Radio Measurements Statistics
1. RMS_Overview
2. RMS_Counters
3. RMS_Based_Radio_Network_Optimization
4. Annexes
1. Annexes

BSS
B12 GSM Quality of Service and Traffic Load Monitoring
Upon completion of this course, you should be able to:
Your feedback is appreciated!

Please feel free to Email your comments to:
training.feedback@alcatel-lucent.com
Please include the following training reference in your email:

TMO18096_V2-SG Edition 1
Thank you!

TMO18096_V2-SG-B12-Ed1 Module 1.1 Edition 1
Section 1 Module 1 Page 1
This page is left blank intentionally
Document History
Edition Date Author Remarks
01 YYYY-MM-DD Last name, first name First edition


Page
1 Monitoring the QoS of the BSS 7

2 Monitoring the traffic load of the BSS 10
3 QoS monitoring tools 12
4 Introduction to K1205 PC emulation 20


9153-RA OMC-R: Operation and Maintenance Center Radio.
NPO product reference is now 9959, instead of 9159
Starting from the B12 release, the OMC-R facilities to display Performance Management data are now offered by
two different means:
l Either
by using NPO connected to the OMC-R: the OMC-R provides a way to navigate from OMC-R views to
NPO Analysis Desktop. From an OMC-R user perspective, this change offers the same service when MPM
was embedded inside the OMC-R. The only differences are the fact that the OMC-R user has now access to
extended data and services:
History of data up to 2 years instead of 7 days
Reporting facilities of NPO
Access to RMS data (was not available in MPM)
Access to parameters thanks to NPO capabilities
Weekly, Monthly aggregation (was not available in MPM)
Customer indicators
l Orby using an MPM running on a standalone machine: this can be achieved by using an HPsmall
configuration.

A interface:
The main advantage of the A interface is to allow the detection of Call Setup failures either due to the User or to
the NSS (or PSTN).
Some typical user failure causes are: Some typical NSS failure causes are:
IMSI Unknown in VLR Temporary Failure
IMSI Unknown in HLR Resource Unavailable
IMEI Not Accepted Switching Equipment Congestion
PLMN Not Allowed Normal Unspecified
Service Option Not Supported Recovery on Timer Expiry
Requested Service Not Supported Call Reject
Unassigned Number Interworking
Operator Determined Barring Protocol Error
User Alerting Network Failure
Facility Not Subscribed Congestion
No Route to Destination
Normal Call Clearing
User Busy
Invalid Number Format
Call Reject
Interworking
Normal Unspecified
CAUTION: In order to assess the QoS of a BSS or some cells of a BSS, all N7 links between this BSC and the
MSC must be traced. Indeed, as the N7 signaling load is spread over all N7 links, signaling messages relating to
one call can be conveyed on any of the active N7 links.
K1103 protocol analyzer can trace up to 8 COCs at the same time but on maximum 4 PCM physical links.
K1205 protocol analyzer can trace up to 32 COCs at the same time but on maximum 16 PCM physical links.
Abis interface: The main advantage of the Abis trace is to allow a detailed and precise assessment of the radio
quality of a cell at TRX level. Both DL and UL paths can be observed and compared.
Air Interface: The main advantage of the Air trace is to associate a radio quality measurements with a given
geographical area of the network.
From the B7 release, the RMS feature implemented in the BSS provides a good level of information allowing one
to reduce the number of Abis traces and drive test to be done for radio network optimization.

Click on the Filter button and filter out all protocol layers and messages except for:
l all DTAP messages,
l all BSSMAP messages except for "Paging,
l SCCP CR (Connection Request) and CC (Connection Confirm) messages.

Document History


Page
1 Indicator definition 7
2 Indicator classification 12
3 Methodological precautions 27


A standard PM type can be activated for the whole network. It means that the related counters are
reported for all the Network Elements they are implemented on (TRX, CELL, N7 link, X25 link, LAPD link,
Adjacency).
A detailed PM type can be activated only on a sub-set of the network. It means that the related counters
are reported only for a limited number of Network Elements:
l 40 cells per BSS for PM types 1, 2, 3, 4, 5, 6, 26, 29
l 15 cells per BSS for PM types 10, 12, 13, 14, 15
l 1 cell per BSS for PM types 11, 27
Counter numbering rules:

l Cyz: cumulative or inspection counters in PM types 1, 2, 3, 4, 5, 6, 18, 19, 25, 26, 27, 28, 29, 30, 32,
180
l Ly.z: cumulative counters in PM type 7 (L stands for LAPD link)
l Xy.z: cumulative counters in PM type 8 (X stands for X25 link)
l Ny.z: cumulative counters in PM type 9 (N stands for N7 link)
l Syz: observation counters in PM type 10 (S stands for SDCCH)
l Ryz:: observation counters in PM type 11 (R stands for Radio measurements)
l HOyz: observation counters in PM type 12, 13, 14 (HO stands for HandOver)
l Tyz: observation counters in PM type 15 (T stands for TCH)
l RMSyz: cumulative counters in PM type 31 (RMS stands for Radio Measurement Statistics)
l MCyz or MNy.z: cumulative counters in PM type 110 (M stands for Major)
In the B12 release, a new PM type 37 is created for VAMOS.

VAMOS counters are transmitted in new specific blocks and only when VAMOS is activated.
Please refer to the list and definitions of VAMOS specific counters provided in PM Counters Dictionary.

The Traffic model section includes indicators for:
l number of SDCCH connection requests and successes (Immediate Assignment, HO).
l distribution
of SDCCH connection success (MO and MT connections versus all MO+MT connections,
type of MO connections versus all MO connection types).
The MS penetration rate section includes the indicator for percentage of multiband MS SDCCH access
(except for LU) versus all MS SDCCH accesses.
The Resource occupancy section includes indicators for:

l SDCCH traffic in Erlang.
l average duration in seconds of SDCCH channel usage.

The Speech Version and Channel Type section includes indicators for:
l distribution of TCH allocation requests (FR/DR/DR+EFR/AMR/DATA).
l distribution of TCH allocation successes (FR/DR/DR+EFR/AMR/DATA).
l rate of TCH AMR allocation successes.
l rate of TFO calls versus all speech calls.
The Traffic model section includes indicators for:

l number of TCH connection requests and successes (Normal Assignment, HO, DR).
l rate of TCH allocation successes for HO+DR versus all TCH allocations (NA+HO+DR).
l number of HOs per call.
The Resource occupancy section includes indicators for:

l RTCH traffic in Erlang (FR+HR, FR, HR, multiband).
l average duration in seconds of RTCH channel usage (FR+HR, FR, HR).
l number of TCH FR allocations and number of TCH HR allocations.
l rate of TCH HR allocations versus all TCH allocations (FR+HR).
l TCH peak of blocking (TCH congestion time).

if p is the probability of success for a complete population
if one is measuring the probability P based on a sample of size N
There is a probability of 95 % that p is between:
P +/- 1.96*[(p*(1-p))/n]
Example: for p = 90 % and N = 100 => [ 84,12% ; 95,88% ]
On Alcatel-Lucent QoS monitoring tool (MPM application on OMC-R, NPA or RNO), NEs (BSS, Cell or TRX)
are highlighted with bad QoS indicator values if enough corresponding events have been observed (called
Validity threshold).
Examples:
l Cells
with bad Call Drop rate will be highlighted if CDR > CDR_threshold and if the Number of Calls is
greater than the CDR Validity threshold.
l Cellswith a bad Outgoing handover success rate will be highlighted if OHOSUR > OHOSUR_threshold
and if the Number of Outgoing Handovers is greater than the OHO Validity threshold.

Usually:
l Cell Busy Hour = hour of the day where max TCH traffic (in erlang) is observed.
l BSC Busy Hour = hour of the day where max TCH traffic (as the sum of the TCH traffic of all cells of
the BSS) is observed.

Document History


Page
1 Call setup principles 7

2 Radio and link establishment 16
3 SDCCH phase 40
4 TCH assignment 51
5 Key performance indicators 67

Page

Steps of a Basic SS7 Call:
1. The caller takes the phone "off-hook and dials the destination number. The subscriber signaling
passes this information to the local calling office.
2. The local originating office which uses SS7, encapsulates the dialed number and the Calling Party
Category (CPC) information into the first signal Initial Address Message (IAM) to set up the call
to the destination office. In some cases, IAM can be replaced with Initial Address Message (IAI) with
Additional Information to pass more information.
3. On the route to the destination, each receiving office checks the Destination Point Code (DPC) with
its own Point Code to see if the message is destined to itself. If not, it transfers the message to the
next office in the route. When the destination office finally receives the IAM or IAI, it checks the
subscriber number to see if it's free. If free, then it sends back the Address Complete Message
(ACM).
4. At this point, the voice circuit is opened, ring back tone is put on the circuit back to the caller and
ringing current is sent to the dialed number's phone.
5. When the called subscriber answers, the destination switching office sends back Address Charge
Message (ANC) to the first office to begin call charging.
6. When the conversation is over, to release the call circuit, the originating switching office sends
Clear Forward (CLF) and the destination switching office sends back the Release Guard (RLG()
signals.

LA: Location Area (LAC: Location Area Code)
In the CS PAG (CS-Paging) message, the LAC that should be paged is included.

Since B10, the BSC can send Multiple Paging Command.
The MSC sends a PAGING message and starts the timer T3113 to supervise the PAGING RESPONSE
message from the MS. T3113 is started for each Paging!
The MSC may repeat the PAGING message if no answer arrives before T3113 expiry.
The BSC starts the T_SEND_MULTIPLE_PAGING_CMD timer (assumed to be not yet running) when
the first PAGING message (MS1) is received.
When the number of PAGING messages queued in the BSC equals

NB_MAX_MSG_MULTIPLE_PAGING_CMD, or at T_SEND_MULTIPLE_PAGING_CMD expiry:
Multiple Paging Command is built and sent to the cells.

In case of RSL DL Congestion (= LAPD Congestion), the Pagings are no longer sent on the Abis interface.
But since Pagings are sent on LapD "I Frames" (which require acknowledgment), and since they were not-
ack, then the BSC will autonomously resend the pagings to the "rsl-congested" BTS.
IF MSC timer T3113 expires, the MSC will retransmit the paging over the whole LAC or even more (whole
BSC, whole network, etc.).

In this table, TMSI can be replaced by P-TMSI (in case of PS Paging). A PS Paging can be merged with a CS
Paging.

The SDCCH resource allocation is performed by the BSC. Once allocated, the SDCCH channel is activated by
the BTS on BSC request.
T3101 is the guard timer for the SDCCH access from the MS. The Default value is 3 seconds.
The SCCP Connection Request message is conveyed on an A interface PCM timeslot chosen by the BSC
(called COC).
The SCCP Connection Confirm message is conveyed on a COC chosen by the MSC which can be located
on a different PCM than the one of the COC used by the BSC to send signaling messages to the MSC.
l Originating + Destination Point Codes: N7 physical address
l Originating + Destination References: Coc (call signaling) reference between MSC and BSC
Multiple SACCH Modify: request to send ASAP some system information messages that should be
updated when the MS moves from Idle Mode to Dedicated Mode (usually, the SI5, with the list of
neighbors).

A paging message is broadcast by the MSC to all BSCs controlling cells belonging to the same Location Area
as the one of the paged MS.
In case no MS is accessing the SDCCH channel (T3101 expiry), then the BSC does not repeat the Immediate
Assignment since the MS may have accessed an SDCCH in another BSS. It is up to the MSC to repeat Paging
if T3113 expires (usually around 7 seconds).
MC8A counts the number of Paging Command messages sent on a cell.
MC01 counts the number of MSs which have successfully accessed an SDCCH in a cell as part of a Mobile
Terminating (MT) call.
CR: Complete L3 Info

NECI: New Establishment Cause Indication (0: not supported, 1: supported)
Answer to Paging:

Call Re-establishment (3GPP 24.008, 4.5.1.6)
The re-establishment takes place when a lower layer failure occurs and at least one MM connection is active
(i.e., the mobile station's MM sub-layer is either in state 6 "MM CONNECTION ACTIVE" or state 20 "WAIT
FOR ADDITIONAL OUTGOING MM CONNECTION").
Supplementary services (SS) in GSM are a means of enriching the user experience. An SS may, for example,
forward a call in the case of no reply from the called party, bar certain outgoing or incoming calls, show the
number of the calling party to the called party, etc. The subscription to supplementary services is contained
in the HLR and sent to the MSC/VLR during registration.
Name identification Calling Name Presentation (CNAP)
Call Forwarding Unconditional (CFU)
Call Forwarding Busy (CFB)
Call Forwarding No Reply (CFNRY)
Call Forwarding Not Reachable (CFNRC)
etc.

LAPD Congestion will lead to:
1. Defense mechanism:
n if UL RSL Congestion: Channel Requests, SMS and Detecion of Call drop due to Remote
Transcoder are discarded
n if DL RSL Congestion: Paging, "SDCCH" Channel activation and SMS are discarded
2. If congestion continues and the Lapd buffers overflow, then the LapD link is RESET.
Congestion and Reset are counted in the LapD counters.

T3120 is computed by the MS as a random number of slots between:
* 250 and 250+T-1 for a phase 1 MS where:
T=Tx_integer parameter (1 value per cell chosen between 3 to 50 slots)
* S and T+S for a phase 2 MS where:

T=Tx_integer parameter (1 value per cell chosen between 3 to 50 slots, with 1 slot = 0.577 ms)
S is a parameter depending on the CCCH configuration and on the value of Tx_integer as defined in the
following table:
TX_integer S(CCCH Not Comb) S(CCCH Combined)
3, 8, 14, 50 55 41
4, 9, 16 76 52
5, 10, 20 109 58
6, 11, 25 163 86
7, 12, 32 217 115
By default Tx_integer=32, then S=217. Therefore T3120 is between 125 ms and 144 ms.
T3126 is MS dependent, greater than T3120 but less than 5s.

After T3126 expiry, the MS displays "Network Error", except in case of LU, in which case the MS attempts to
reselect another cell and repeats the procedure.

WI_CR: Value of Wait Indication for Establishment cause = Call Re-establishment.
WI_DTM: Value of Wait Indication for DTM requests
WI_EC: Value of Wait Indication for Establishment cause = Emergency call.
WI_OC: Value of Wait Indication for Establishment cause = Originating call.
WI_OP: Value of Wait Indication for Establishment cause = Location updating or Other procedures which
can be completed with an SDCCH.
Wait indication used in IMMEDIATE ASSIGNMENT REJECT or PACKET ACCESS REJECT, when not in PMU
CPU overload situation.
Wait indication used in IMMEDIATE ASSIGNMENT REJECT or PACKET ACCESS REJECT, when in PMU CPU
overload situation.

Subscriber attempt = when the subscriber presses the "Call" button

SDCCH congestion can be too high because of the subscribers' traffic demand in terms of calls / LUs.
Solution = add a TRX or site / redesign the LA plan
High SDCCH congestion can be observed at peculiar period of the day due to a peak of LU requests
generated by a big group of subscribers entering a new LA at the same time (bus, train, plane).
Solution = redesign the LA plan or play on radio parameters (CELL_RESELECT_HYSTERESIS, WI_OP)
High SDCCH congestion can be abnormally observed without real MS traffic in case a high level of noise or
the proximity of a non-GSM radio transmitter.
Solution = change the BCCH frequency or put an RX filter
High SDCCH congestion can also be abnormally observed in a cell in case one of its neighboring cell is
barred.
Solution = Remove the barring

SDD possible in all TRXs except for the first TRX if m-CCCH is enabled!
SPECIFIC COUNTERS (Type 110 / Cell Level):

l MC800 Average number of available dynamic SDCCH/8 timeslots.
l MC801 & MC802 counters are Inspection Counters; that means that the resource is checked regularly by the BSC and at the
end of the period, an average is done. Example: 3 physical channels are defined as Dyn SDCCH and the counter gives the
following indication:
MC801a = 1.7 that means sometimes the 3 Dyn SDs are allocated as TCH, sometimes only 2 of them, sometimes 1 or 0 and the
average is 1.7.
The FOLLOWING COUNTERS ARE IMPACTED BY the Dynamic SDCCH Allocation feature:
l MC28, MC29 The Number of busy radio timeslots in TCH usage takes into account the busy TCH timeslots and the dynamic
SDCCH/8 timeslots allocated as TCH.
l C30, MC31 The Number of busy SDCCH sub-channels takes into account the SDCCH sub-channels allocated on the static and
dynamic SDCCH/8 timeslots.
l C370a, MC370a, C370b, MC370b The Number of times the radio timeslots are allocated for TCH usage (FR / HR) takes into
account the busy TCH timeslots and the dynamic SDCCH/8 timeslots allocated as TCH.
l C/MC380a/b C/MC381a/b The Cumulated time (in second) the radio timeslots are allocated for TCH usage (FR or HR) does
not take care whether the TCHs are allocated on the TCH radio timeslot or on the dynamic SDCCH/8 timeslots.
l C39, MC390, C40, MC400 The Number of times or the Cumulated time (in second) the SDCCH sub-channels are busy does
not take care whether the SDCCH sub-channels are allocated on the static or dynamic SDCCH/x timeslot.
l C/MC34 C/MC380 The Cumulated time (in second) all TCHs / SDCCHs in the cell are busy does not take care whether the
TCHs / SDCCHs are allocated on the TCH radio timeslot /SDCCH/x timeslot or on the dynamic SDCCH/8 timeslots.
l C/MC320a/b/c/d/e Free TCH radio timeslots count the free TCH timeslots and the free dynamic SDCCH/8 timeslots.

Unbalanced Power Budget:
AGCH
RACH
Max Path Loss DL

Max Path Loss UL
Bad coverage:
Channel Request
BTS
building Access Grant
Interference: RACH
AGCH lost
DL interference area

Some of those reasons are "Real" ghost (= noise)
Others have a known and predictable cause

For this Channel Required, the establishment cause is valid (Call re-establishment) but the Access Delay
(corresponding to the distance between the MS and the BTS) is high.
Indeed, the Access Delay being equal to the Timing Advance is coded in slot unit representing a distance of
550 m. It can take values from 0 (0 m) to 63 (35 km).
Thus, the Channel Required above is received from an MS located at 19 km from the site. It may therefore
be rather a ghost RACH than a real MS that wants to re-establish a call.
In the Alcatel-Lucent BSS, it is possible to filter the Channel Required received from a distance greater than
a distance defined as a parameter value: RACH_TA_FILTER tunable on a per-cell basis. Caution should be
taken since a too low value may reduce the network coverage.

The CHANNEL REQUEST (2) is followed by Channel Required, Ch. Act, Ch Act Ack but they are not
represented here. Only the Immediate Assignment(2) is shown.
Round-Trip Delay
The CHANNEL REQUEST (2) is followed by Channel Required, Ch. Act, Ch Act Ack but they are not
represented here. Only the Immediate Assignment(2) is shown.
Round-Trip Delay

Different BSIC will prevent this problem from happening.
BSIC = BCC (3 bit) + NCC (3 bit)
l BCC: BTS Color Code
l NCC: Network Color Code
TB: Tail Burst (0,0,0)
GP: Guard Period

BSIC = BCC (3 bit) + NCC (3 bit)
l BCC: BTS Color Code
l NCC: Network Color Code

SDCCH_assign_cong
SDCCH_assign_fail_BSS
SDCCH_assign_fail_radio
SDCCH_assign_unsuccess_rate

DTAP: Direct Transfer Application Part, used for 3 purposes:
l DTAP - RR: Radio Resources
l DTAP - MM: Mobility Management
l DTAP - CC: Call Control

DTAP : Direct Transfer Application Part, used for 3 purposes:
DTAP - RR: Radio Resources
DTAP - MM: Mobility Management
DTAP - CC: Call Control

BSS_SEND_CM_ENQUIRY
This flag is set by O&M to inform the BSC about the conditions in which to send the CLASSMARK ENQUIRY
message to the MS.
The parameter has three defined values:
1. The CLASSMARK ENQUIRY is never initiated by the BSC.
2. On reception of an LU REQUEST with ES IND flag set to 0, the BSC will always initiate a CLASSMARK
ENQUIRY.
3. On reception of a LU REQUEST with ES IND flag set to 0, the BSC will initiate the CLASSMARK ENQUIRY
only if algorithm A5/1 is not available (information available in MS classmark 1 IE sent in the LOCATION
UPDATING REQUEST).
The MS classmark data is collected and stored by the Alcatel-Lucent BSS and is used in almost all the
procedures performed by the Alcatel-Lucent BS.
The MS classmark data collected by the BSS classmark handling entity is:
l the MS revision level,
l the MS ciphering capabilities which are supported by the BSS,
l the MS frequency capabilities which are supported by the BSS,
l the MS RF power capabilities in every frequency band supported by the MS and the BSS,
l the MS classmark handling capabilities,
l the MS Utran classmark.

Generally SDCCH handovers are disabled in the network since the average SDCCH duration is only around 2
to 3 seconds (parameter SDCCH_HO, with 0: SDCCH HO enabled, 1: SDCCH HO disabled).

MC138 counts the number of SDCCH channel drops due to radio problems.
Radio problems can be due to coverage, interference and sometimes BSS dysfunction which is not detected
as a system alarm by the O&M Fault Management application.
MC138 is triggered when either:
1. RADIOLINK TIMEOUT reaches "0" in the BTS (generating a Connection Failure Indication "Radio link
failure") Default setting = 18 SACCH = 8.64s.
2. or, LApD link failure, after (N200+1) * T200 seconds (24 * 220ms = 5.28s)

MC137 counts the number of SDCCH channel drops due to BSS problems.
A BSS problem can be a BTS/BSC hardware or software failure, or an O&M action on the DTC board. It can
also be due to a problem on the Abis interface (due to Micro Wave transmission for instance).
Triggers:
1. LapD failure detected during the stable phase of an SDCCH transaction.
2. SDCCH was released due to 48.058 ERROR REPORT with any cause value being received during the
stable phase of an SDCCH transaction (ciphering problems, or any other problem detected by the
TRX).
3. Telecom Supervisory module caused the call to be cleared.
4. SDCCH was released due to 0180 CLEAR_CMD message being received from BSSAP during the
stable phase of an SDCCH transaction: O&M has disabled the DTC.

MC07 counts the number of SDCCH channel drops due to handover failure.
Internal inter-cell SDCCH handover: whenever the timer supervising the handover procedure (T3103)
expires.

Refer to BSS - DEFINITION OF QUALITY OF SERVICE INDICATORS:
GLOBAL Quality of service INDICATORS > SDCCH > Established phase
l GSDCDR: SDCCH drop rate (Global)
l GSDCDRR: SDCCH drop rate due to radio problem
l GSDCDBR: SDCCH drop rate due to BSS problem
l GSDCDHR: SDCCH drop rate due to HO failure

RMS31: counted by the TRX, Whenever an ESTABLISH INDICATION message is received from the MS to
indicate the activation of a TCH channel for normal assignment or handover. Beware it is an RMS counter,
it is measured during the daily RMS campaign only.
MC718: Number of TCH (in HR or FR usage) normal assignment successes, per TRX. This counter also
takes into account normal assignment successes for TCH establishment in signaling mode (FR usage only),
for DTM.
VAMOS Related Counters:

l MC1403a: NB_TCH_PAIR_SUCC _NON_SAIC
Number of requests coming from legacy non-SAIC capable MS that are established successfully in
VAMOS mode (after pairing)
l MC1403b: NB_TCH_PAIR_SUCC_SAIC
Number of requests coming from legacy SAIC capable MS that are established successfully in VAMOS
mode (after pairing)
l MC1403c: NB_TCH_PAIR_SUCC_VAMOS1
Number of requests coming from VAMOS-1 MS that are established successfully in VAMOS mode (after
pairing)
l MC1403d: NB_TCH_PAIR_SUCC_VAMOS2
Number of requests coming from VAMOS-2 MS that are established successfully in VAMOS mode (after
pairing)

Preparation phase: preparation of the resources, ends with a message SENT over the Air interface
Execution phase: validation that the new radio channel allows communication in both directions

When A user plane over IP is used, the CIC has no more meaning. For AUoTDM, the CIC allocated by the MSC to a
given call defines the user path of that call and its identification in each NE.
But for AUPoIP, the 3GPP has decided to dissociate the user path definition from the call identification:
l The A user path will be defined with the corresponding IP address and UDP port of the terminating points of the
call segment in each entity, so-called AoIP Transport Layer Address.
l The call identification will be a random number allocated by the MSC, so-called Call Identifier.
The A user plane type choice (over IP or over TDM) and the call identification (CIC vs AoIP Transport Layer Address
and Call Identifier) shall take place at the very beginning of any call segment (Call Setup, Handover).
The Codec Type and A user plane type choice and the call identification shall take place at the very beginning of any
call setup and Handover. This is done by adding new information elements to the messages related to the assignment
and handover procedure.
Here we have a call setup with the feature AUoIP activated.
In the ASSIGNMENT REQUEST, the Codec List includes all the codecs currently supported by the MS and preferred by
the MSC. Codec preference (top of the list) goes to the ones that may enable TrFO or TFO.
CIC and/or AOIP transport Layer address (MGW) may be given depending on the proposed A-interface types for the
preferred codec.
The BSC preferentially accepts the preferred codec proposed by the MSC. However, the BSC may allocate HR channels
instead of FR channels because the load of the cell is increasing.
If both interfaces (TDM and IP) are proposed for the chosen codec, IP interface is chosen.
ASSIGNMENT COMPLETE message includes the identity of the local IP endpoint included in the AoIP Transport Layer
Address allocated by the BSS.
Please note that an External Handover follows the same principle: new info about the IP transport is included in HO
REQUIRED, HO REQUEST and HO REQUEST ACK.

Counters Related to TCH normal assignments requests/Success introduced with the AUoIP feature:
MC701i: Number of TCH normal assignments requests for TDM only A user plane interface
MC718i: Number of TCH normal assignments successes for TDM A user plane interface
MC701j: Number of TCH normal assignments requests for IP only A user plane interface
MC718j: Number of TCH normal assignments successes for IP A user plane interface
VAMOS Related counters:
l MC1401a: NB_TCH_REQ_NON_SAIC
Number of requests coming from legacy non-SAIC capable MS

l MC1401b: NB_TCH_REQ_SAIC
Number of requests coming from legacy SAIC capable MS

l MC1401c: NB_TCH_REQ_VAMOS1
Number of requests coming from VAMOS-1 MS

l MC1401d: NB_TCH_REQ_VAMOS2
Number of requests coming from VAMOS-2 MS

l MC1402a: NB_TCH_PAIR_ATPT _NON_SAIC
Number of requests coming from legacy non-SAIC capable MS for which pairing attempt is triggered
l MC1402b: NB_TCH_PAIR_ATPT_SAIC
Number of requests coming from legacy SAIC capable MS for which pairing attempt is triggered
l MC1402c: NB_TCH_PAIR_ATPT_VAMOS1
Number of requests coming from VAMOS-1 MS for which pairing attempt is triggered
l MC1402d: NB_TCH_PAIR_ATPT_VAMOS2
Number of requests coming from VAMOS-2 MS for which pairing attempt is triggered

MC746B counts the number of TCH access failures due to radio problems.
The MC746B counter is implemented at TRX level.
In case of TCH access failure, the MS will try to revert back to the SDCCH channel. Whether it succeeds in
reverting to the SDCCH or not, the call establishment fails. On the other hand, some MSCs may resend the
ASSIGNMENT REQUEST again.

"Probable cause" is just a possibility. It is not the only possible cause!

Report: Alc_Mono_Call

Report: Alc_Mono_Call

GLOBAL Quality of service INDICATORS > SDCCH > Assignment phase
GSDNACGR: SDCCH assignment failure rate due to congestion (Global)

GLOBAL Quality of service INDICATORS > SDCCH > Assignment phase

In a dense network, SDCCH drop rate should be lower than 1%. Indeed, the probablity to drop a radio link
when the MS is on SDCCH is less than on TCH since the SDCCH phase is shorter (less than 5 seconds) than
TCH phase (duration of a call = several tens of seconds).

In a dense network, the TCH assignment unsuccess rate should be lower than 1%.
INDICATOR TCH ASSIGN REQUESTS
DEFINITION Number of TCH seizure requests for normal assignment procedure.
FORMULA B8 cell
cel MC140a
THRESHOLD
COMMENT MC140a: new counter introduced in B8 release.

MC140a (type 110): NB_TCH_NOR_ASS_REQ that indicates the number of normal assignment
requests for TCH establishment (in HR or FR usage)
REF NAME TCNARQN UNIT Number
INDICATOR TCH ASSIGN SUCCESS
DEFINITION Number of TCH successfully seized by MS for normal assignment procedure.

FORMULA B8 TRX
(MC718)
THRESHOLD
COMMENT
REF NAME TCNASUN UNIT Number

This counter intends to give a measurement of the TCH congestion of the whole network.
It is implemented on the Alcatel-Lucent tools but other indicators can be defined.
l RTCH_assign_cong new:MC812, old:MC812
l HO_Inc_cong = HO_Inc_MSC_cong + HO_Inc_BSC_cong
l RTCH_assign_request = new:MC140a-(MC142e+MC142f), old:MC140a-(MC142e+MC142f)
l RTCH_HO_allocated = new:MC15b + MC15a, old:MC15b + MC15a

l HO_Inc_cong = HO_Inc_MSC_cong + HO_Inc_BSC_cong
Note: The congestion counted in those indicators is linked to the following issues:
l all TCHs are busy and no TCH could be allocated for the request
l or the CCP board in the MX-BSC reaches the limit MAX_TCH_PER_CCP (default = 1000)
MC926: Number of TCH channel allocatiosn rejected for cause: Maximum TCH processing capacity of CCP
reached
Whenever a TCH cannot be allocated due to the TCH processing capacity of CCP reaches the limit defined by
the MAX_TCH_PER_CCP parameter.

GQSEECSSR will always be smaller than the GQSCSSR because all failures due to NSS are now taken into
account. They were not counted in the CSSR.

Ghost Racks which correspond to a valid establishment cause are not identified by the BSS. Therefore, they
can lead to a high SDCCH assignment failure rate if they are too numerous.
As the end user is not impacted by this phenomenon if no SDCCH congestion is induced, the SDCCH
assignment phase is not considered in the computation of the Call Setup Success rate provided by Alcatel-
Lucent tools.
In a dense network, the Call Setup Success Rate should be greater than 98%.
The SDCCH congestion rate should also be considered to have a complete picture of Call Setup efficiency.

In a dense network, the Call Setup Success Rate should be greater than 97%.

GQSEECSSR will always be smaller than the GQSCSSR, because all failures due to NSS are now taking into
account. They were not counted in the CSSR.

MC718: Number of TCH (in HR or FR usage) normal assignment successes, per TRX (ASSIGNMENT
COMPLETE).
MC142e: Number of outgoing normal & forced internal directed retry (towards a TCH channel in HR or FR
usage) successes.
MC142f: Number of outgoing normal & forced external directed retry (towards a TCH channel in HR or FR
usage) successes.
MC01: Number of immediate assignment plus SDCCH normal assignment successes for Mobile Terminating
procedure (ESTABLISH INDICATION w/ PAGING RESPONSE).
MC191: Number of Mobile Terminating SMS connections on SDCCH.
MC02e: ESTABLISH INDICATION w/ CM RE-ESTABLISHMENT REQUEST.
MC02d: ESTABLISH INDICATION w/ LOCATION UPDATING REQUEST with FORWARDING.
MC02f: ESTABLISH INDICATION w/ unknown causes but forwarded to MSC (= leading to TCH
establishment).
MC02h: ESTABLISH INDICATION w/ CM SERVICE REQUEST Normal Call or Emergency Call.

GLOBAL Quality of service INDICATORS > Call statistics > Call success
l GQSCSSR: Call setup success rate (Global)
l GQSCCR: Call success rate (Global)
l GQSEECSSR: End to End Call Setup Success Rate (Global)

Document History


Page
1 TCM phase 7
2 Call release 10
3 Call drop causes 14
4 Which KPI to monitor dropped calls? 27
5 Call drop with specific radio causes 36
6 Summary of call setup and call phases 42
7 Traps and restrictions of indicators 47
8 Indicator interpretation 53

Page

These messages are "DTAP" messages, transparent for the BSC and the BTS.
Alerting time can last a very long time. This has to be taken into account!!

For NSS, before the CONNECT ACK is still considered as a CALL SETUP FAILURE.
MS BTS BSC MSC

TCH ASSIGNMENT PHASE (OC or TC)
< -----------------------------------
ASSIGNMENT REQUEST
< --------------------------------------------------------
PHYSICAL CONTEXT REQUEST
-------------------------------------------------------- >
PHYSICAL CONTEXT CONFIRM
< --------------------------------------------------------
CHANNEL ACTIVATION (TCH)
Call Setup -------------------------------------------------------- >
CHANNEL ACTIVATION ACKNOWLEDGE Call Setup
< ----------------------------------------------------------------------------------- Start T3107
(SDCCH) ASSIGNMENT COMMAND
---------------------- >
TCH SABM -------------------------------------------------------- >
< ---------------------- ESTABLISH INDICATION
UA
----------------------------------------------------------------------------------- > Stop T3107

ASSIGNMENT COMPLETE
----------------------------------- >
ASSIGNMENT COMPLETE
< ---------------------------------------------------------------------------------------------------------------------------
Call phase
ALERTING
< ---------------------------------------------------------------------------------------------------------------------------
CONNECT
---------------------------------------------------------------------------------------------------------------------------->
CONNECT ACK
Call phase

1. The MSC initiates the release by sending the CLEAR COMMAND.
2. The BSC releases any A Channel resources, requests the TC to release Atermux nibble-TIC connection
(if there is such a connection), switches off the traffic path in the BSC and returns immediately the
CLEAR COMPLETE message to the MSC. Note that the BSC will accept any CLEAR COMMAND message
even if the MIE is not present or the cause is unknown.
l In the case where there is a channel change procedure in progress, the whereabouts of the MS is
awaited before the release is initiated on Radio and A-bis.
l The MSC upon reception of the CLEAR COMPLETE releases any A Channel resources associated
with the connection and should initiate the release of the SCCP resource.
3. The BSC starts the timer T9101 to supervise the release of the SCCP resource.
4. The MSC releases the SCCP resource by sending the SCCP RELEASED message to the BSC. The BSC
stops T9101 and returns the SCCP RELEASE COMPLETE message and the SCCP resources are now
considered released.

1. The BSC detects an event and signals the requirement to release the connection by sending the CLEAR
REQUEST to the MSC, and starts the timer T9104 to supervise the procedure.
2. The MSC responds by sending a CLEAR COMMAND. The BSC stops the timer T9104. If the MS is still
connected, the BSC will initiate a call release scenario towards the MS and then release the resources in
the BTS.
3. The BSC releases any associated A channel, Atermux nibble-TIC connection and any associated traffic
path, and sends the CLEAR COMPLETE. The release of the SCCP connection is awaited. The timer
T9101 is started to guard the release of the SCCP connection by the MSC.
4. The MSC, on reception of the CLEAR COMPLETE, should release any associated A channel resource and
release the SCCP connection by sending the SCCP RELEASED message to the BSC. The BSC should
respond with the SCCP RELEASE COMPLETE and stop T9101.

MC994:NB_AMR_TCH_DROP_RLF_TRX_RSACCH
Number of AMR TCHs (NB or WB AMR) for which Repeated SACCH is activated, dropped in established TCH
phase due to radio link failure (radio link timeout or Lapdm timer expiry), per TRX. This counter takes into
account TCH in traffic.
MC993: NB_AMR_TCH_DROP_RLF_TRX
Number of AMR TCHs (NB or WB AMR) for which Repeated SACCH is not activated, dropped in established
TCH phase due to radio link failure (radio link timeout or Lapdm timer expiry), per TRX.
MC736: NB_TCH_DROP_EST_PHAS_RLF_TRX
Number of non-AMR TCH (in HR or FR usage) drops due to radio link failure (radio link timeout
or LAPDm timer expiry), per TRX. This counter takes into account TCH in traffic or in signaling mode.
MC736 = C736
MC1610:OLC_NB_TCH_DROP_EST_PHAS_RLF_TRX
Number of TCH (in HR or FR usage) drops due to radio link failure (radio link timeout or LAPDm
timer expiry), in OLC configuration, per TRX and per site.
This counter takes into account TCH in traffic or in signaling mode.

For each active radio channel, a counter S is:
l decremented by 1 each time an SACCH frame cannot be decoded (BFI=1)
l incremented by 2 each time a valid SACCH frame is received
Initial value of S = RADIO_LINK_TIMEOUT_BS for non-AMR calls or AMR calls with RSACCH + RDFACCH
l if S reaches N_BSTXPWR_M, a radio link recovery is triggered (optional)
l if S reaches 0, a radio link failure is detected
Radio link Timeout parameters have been introduced for AMR calls without RxACCH:
l RADIO_LINK_TIMEOUT_BS_AMR
l RADIO_LINK_TIMEOUT_AMR
When S=0, RADIO CALL DROP !!!
RADIOLINK_TIMEOUT_BS RADIOLINK_TIMEOUT is important because the mobile must release the radio
channel first. If BTS releases the TCH, then it can be reallocated to another MS.
Use RADIOLINK_TIMEOUT_BS_AMR instead of RADIOLINK_TIMEOUT_BS if:
AMR (NB or WB) codec is used
AND
l RSACCH is not activated by the BSC for this call
OR
l RDFACCH is not activated by the BSC for LAPDM command frames of this call

RSACCH: Repeated SACCH
l The
RDSACCH mechanism means that the BSS may send a DL SACCH frame twice with exactly the
same contents to improve the DL SACCH performance thanks to combining in the MS.
l TheRUSACCH mechanism means that an MS shall send upon BSS order a UL SACCH frame twice
with exactly the same contents to improve the UL SACCH performance thanks to combining in the
BTS.
When an SACCH block is received:

l If EN_REP_SACCH=0: If the SACCH block can be decoded, then S is incremented by 2,
n Else S is decremented by 1.
l If EN_REP_SACCH=1: If the SACCH block can be decoded, then S is incremented by 2,
n Else If the second attempt to decode it after combining with the previous SACCH block, then
then S is incremented by 2,
Else S is decremented by 1.
NB: the BTS does not know whether a UL SACCH frame is a repetition or not.

MC739 counts the number of TCH channel drops due to BSS problems reported as "remote TransCoder
failure".
The MC739 counter is implemented at TRX level.
The counter is incremented whenever a 48.058 CONNECTION FAILURE INDICATION message with cause
"Remote Transcoder Failure" is received on Abis interface for an established TCH connection.
The BSC considers a TCH connection as "established" once a 44.018 ASSIGNMENT COMPLETE message (in
case of normal assignments or an internal intra-cell handovers) or a 44.018 HANDOVER COMPLETE message
(in case of an internal inter-cell incoming HO or an external inter-cell incoming HO) has been received for
the TCH connection. Whether A User plane Interface over IP AUPoIP applies to the call, in case of normal
assignment or directed retry cases, the BSC considers a TCH connection as "established" only once first
DL RTP has been received from MGW.
It can usually be a bad quality of the transmission on the Abis interface (Micro Wave) or a faulty hardware
component in the TransCoder or even sometimes BSS software/hardware problems.
UFE: Uplink Frame Error is a field in the TRAU frame indicating a loss of synchro.
T_SYNC (TDM Mode) or TRAU_Connection_Timeout (IP mode): Timer used in the BTS to detect a loss of
synchronisation between BTS and transcoder (default: 1s)
A loss of frame synchronisation is assumed as soon as a single TRAU frame with a frame synchronization
error is received.
MC1611: OLC_NB_TCH_DROP_EST_PHAS_REM_TRANS_FAIL_TRX
Number of TCH (in HR or FR usage) drops due to remote transcoder failures in OLC configuration, per TRX
and per site.

MC14c:
Number of TCH (in HR or FR usage) drops due to BSS problem.
It may happen that several causes of failures mentioned below are detected consecutively. In that case, the
counter will only be incremented once, as soon as the call is released. This counter takes into account TCH
in traffic or in signaling mode. It is not incremented in case of TCH drop during a normal assignment, a
handover or a DTM assignment.
1. Whenever a 48.058 ERROR REPORT message with a cause value of "O&M intervention" is received on
Abis interface after TCH seizure and leads to a loss of call.
2. Whenever a 48.058 ERROR REPORT message on SAPI 0 with a cause value of "message sequence
error" is received on Abis interface after TCH seizure and leads to a loss of call.
3. Whenever a LAPD failure is reported to the Layer 3 of the BSC (for an RSL supporting a TCH transaction
after successful TCH seizure) and leads to a loss of call.
4. Whenever a TCH call release is initiated by the BSS O&M FAULT MANAGEMENT application part or by
the BSS TELECOM application part as the result of a system defense action which may be due to BSS
equipment failures external to the BSC (e.g. RSL failure or CU recovery failure), or due to BSC internal
hardware problems (e.g. TCU failure or DTC failure) or due to BSC internal software problems (e.g.
inconsistencies detected between software modules or lack of software resources (memory, timer
reference, file reference, etc.) or communication problems between different processor boards).
MC1613: OLC_NB_TCH_DROP_EST_PHAS_BSS_PB_TRX
Number of TCH (in HR or FR usage) drops due to BSS problem in OLC configuration, per TRX and per site.
It may happen that several causes of failures mentioned below are detected consecutively. In that case, the
counter will only be incremented once, as soon as the call is released.
This counter takes into account TCH in traffic or in signaling mode. It is not incremented in case of TCH drop
during a normal assignment, a handover or a DTM assignment.

HO is "failed" and leads to a call drop:
1. Inter-cell TCH handover: whenever the timer supervising the handover procedure (T3103) expires.
2. External TCH handover (2G -> 2G): whenever the timer supervising the handover procedure on the
serving cell (T8) expires
3. Intra-cell TCH handover: whenever the timer supervising the handover procedure (T3107) expires.
4. 2G -> 3G HO: whenever the timer supervising the 2G-3G handover procedure on the serving cell
(T3121) expires
MC621: NB_TCH_DROP_OUT_HO_EXEC_TRX
Number of non-AMR TCH drops during the execution of any TCH outgoing handover, per TRX. This counter
takes into account handovers from TCH in traffic or in signaling mode.
MC621 = C621
MC995: NB_AMR_TCH_DROP_OUT_HO_TRX
Number of TCHs using AMR codecs (NB or WB) but with Repeated FACCH not activated, dropped during the
execution of any TCH outgoing handover, per TRX. This counter takes into account handovers from TCH in
traffic.

MC921b: NB_PREEMPT_CAP_ALLOC_SUCC
Number of preemption capable calls served with resources in the cell (with or without using the preemption
feature).
Whenever the BSC has selected a channel to activate a TCH channel related to either 48.008 ASIGNMENT
REQUEST, 48.008 VGCS/VBS ASSIGNMENT REQUEST, 48.008 HANDOVER REQUEST, 48.008 ESTABLISH
INDICATION with the L3_INFORMATION field including a 44.018 NOTIFICATION RESPONSE message and
the call has the ability to pre-empt another call with lower priority (i.e. pci = 1).
MC921C counts the number of TCH channel drops due to preemption for another call to be established.
The MC921C counter exists from B7 as linked to the feature Preemption.

RTCH_success_end: RTCH_success - RTCH_HO_Out_success

MC736: NB_TCH_DROP_EST_PHAS_RLF_TRX (non AMR calls)
MC621: NB_TCH_DROP_OUT_HO_EXEC_TRX
MC739: NB_TCH_DROP_EST_PHAS_REM_TRANS_FAIL_TRX
MC14c: NB_TCH_DROP_EST_PHAS_BSS_PB
MC921c: NB_PREEMPTED_CALLS

MC1406a-NB_TCH_EST_PAIR_DROP_NON_SAIC
Number of 48.008 CLEAR REQUEST sent to the MSC for speech CS calls in TCH established phase (traffic)
in VAMOS mode related to non-SAIC capable MS. Handover failures are not taken into account.
MC1406b - NB_TCH_EST_PAIR_DROP_SAIC
in VAMOS mode related to SAIC capable MS. Handover failures are not taken into account
MC1406c - NB_TCH_EST_PAIR_DROP_VAMOS1
Number of 48.008 CLEAR REQUEST sent to the MSC for speech calls in TCH established phase (traffic) in
VAMOS mode related to VAMOS-1 capable MS. Handover failures are not taken into account
MC1406d - NB_TCH_EST_PAIR_DROP_VAMOS2
in VAMOS mode related to VAMOS-2 capable MS. Handover failures are not taken into account
MC1407a - NB_TCH_EST_UNPAIR_DROP_NON_SAIC
in non VAMOS mode related to non-SAIC capable MS. Handover failures are not taken into account
MC1407b - NB_TCH_EST_UNPAIR_DROP_SAIC
in non VAMOS mode related to SAIC capable MS. Handover failures are not taken into account
MC1407c - NB_TCH_EST_UNPAIR_DROP_VAMOS1
in non VAMOS mode related to VAMOS-1 capable MS. Handover failures are not taken into account
MC1407d - NB_TCH_EST_UNPAIR_DROP_VAMOS2
in non VAMOS mode related to VAMOS-2 capable MS. Handover failures are not taken into account

GQSCDN = call drop
= drop radio + drop TC + drop internal BSS + drop HO + drop Preemption
= MC736 + MC739 + MC14C + MC621 + MC921C
GTCQHCCN = RTCH success end
= assignment success + incoming (HO+DR) success - outgoing HO
= MC718 + (MC717A+MC717B) - MC712
rtch incoming (HO+DR) success is also counting the intracell HO, so they are included in "rtch outgoing HO
success"
in this example, intracell HO = 0

GQSCDN = call drop
= drop radio + drop TC + drop internal BSS + drop HO + drop Preemption
= MC736 + MC739 + MC14C + MC621 + MC921C
GTCQHCCN = RTCH success being
= assignment success + incoming (HO+DR) success - outgoing HO
= MC718 + (MC717A+MC717B) MC662

The number of outgoing HOs cannot be counted per TRX!
The number of BSS Internal drops cannot be counted per TRX!
Therefore, it is not possible to have a global drop rate per TRX (only radio, rtc or HO), and not possible to
take into account outgoing HO
GTCQHCCN = RTCH success

= assignment success + incoming (HO+DR) success (intracell, intercell)
= MC718 + (MC717A+MC717B)

When there is only a little amount of HO transiting through the cell, the difference between CDR and RTCH
DR is small.

An outgoing HO in cell A is probably an incoming HO in cell B!
Amount of TCHs in the BSC = 35.000
Amount of Drops = 6.500
6.500 / 35.000 = 18.6%

Report : Alc_Mono_Call

Available since B10
It can be seen in NPO (indicator call drop causes)
The BSC calculates the average value of AV_RXQUAL_UL_HO and AV_RXLEV_UL_HO as following:
If window_size is full, then the average values are calculated by using the Window_Size. Otherwise, the
average values are calculated by using the number of received measurements.

The indicators computation can be performed from several counters or by a simple counter mapping.
Example:
l call drop rate = Call Drop nb / Call nb = f(counters)
l call drop = Call drop nb = 1 counter

Document History


Page
1 Handovers overview 7
2 Intra-cell handovers 10
3 Internal intercell handovers 18
4 External intercell handovers 36
5 Handovers QoS per adjacency 51
6 Inter-RAT and inter-PLMN handovers 58
7 KPI 69

Page

note: Handovers are not only from TCH to TCH:
HO SDCCH to SDCCH (SDCCH HO)
HO SDCCH to TCH (=directed retry)

Both SDCCH and TCH are counted together.
The T3107 timer is also used as the guard timer of the channel change procedure during an intra cell
handover. The default value for T3107 is 14 seconds.
l MC870=C270+C360 MC871=C271+C361 MC662=C62+C102
VAMOS Mode:
In CHANNEL ACTIVATION,
l The channel/subchannel number is given in Channel Number IE
l TSC set and TSC are sent to BTS in Channel Identification IE. Couple (TSC set,TSC) is given by RAM
in "channel selected".
l BS power gives the number of two dB steps by which the attenuated power shall be reduced by the
BTS. It allows to deduce the maximum AQPSK power that may be transmitted by the BTS, taking into
account the BS_TXPWR_ATTENUATION(_INNER) value. It is the power of the VAMOS channel globally
(sum of the power of both subchannels).
Furthermore, BSC sends a BS POWER CONTROL command related to the VAMOS subchannel already
active, using the same Power and SCPIR as in CHANNEL ACTIVATION.
In ASSIGNMENT COMMAND,
The couple (TSC set, TSC) is sent to the MS in addition to the channel/subchannel identification
(Timeslot Number, Subchannel Number if TCH/H). For a TCH allocated in VAMOS mode and when the MS
supports VAMOS-2 capability, dedicated mode fields have to be used in Channel Mode IE.

In this example, the Downlink path on the new channel is faulty (interference, path unbalance ).
It is also possible the MS immediately sends an Assign Failure (without even attempting to connect to the
new channel).
N200_TTF = 34
T200_TF = 200ms
200 * 35 = 7seconds
MC667 = C107 (sdcch intracell ho fail roc) + C67 (tch intracell ho fail roc)

MC663 = C103 (sdcch) + C63 (tch)

Intra cell HO failures due to BSS problems are deduced from other counters.

MC830=C230 (tch) + C330 (sdcch)
After the HO PERFORMED is sent to the MSC.

l if
DTM is enabled in the old cell, it sends a BSCGP BSC shared DTM info indication (CS_Flag = 0) to the
MFS.
l if
DTM is enabled in the new cell, it send a BSCGP BSC shared DTM info indication (CS_flag = 1) to the
MFS.
The MFS in the old cell deletes the MS context and creates an MS context according to the information
received in the BSCGP BSC shared DTM info indication.
In case of Sync HO, the HO COMMAND contains a valid timing advance value, so that the MS will use this
timing advance in the target cell.
If the HO is not sync, then the HO COMMAND indicates that the HO is async, and the MS will send the HO
ACCESS with TA=0. The target BTS will need to compute the TA.
If AUPoIP feature is activated, the Speech codec (Chosen) is included in the Handover Performed message
if the codec has been changed by the BSS due to the handover.
If AUPoIP feature is activated, the up-to-date Codec capability of the BSC is included in the Handover
Performed message (Codec List (BSS supported)). The MSC may use this in future e.g. at Codec re-
negotiation towards the remote end.

It may happen that the Codec Type supported in the target cell differs from the one used in the serving
cell, possibly leading to a change of the A user interface type, or (even if AUPoIP is still on going) to a
change of the IP address or UDP port in the BSS or in the MSC/MGW. Thus, it is necessary to inform the
MSC of such a change and to re-negotiate the new A user plane type characteristics.
For doing so, the 3GPP has defined a procedure, so-called BSS Internal handover with MSC support and
executed thanks to three new messages: INTERNAL HANDOVER REQUIRED, INTERNAL HANDOVER
COMMAND, INTERNAL HANDOVER REQUIRED REJECT
The AoIP Transport Layer Address, the call identifier, the Codec list are exchanged between the BSC and
MSC server
MC975a - NB_BSS_Int_HO_with_MSC_REQ: Number of "BSS internal handover with MSC support"
request. BSC selects a BSS internal handover with MSC support when AoIP interface applies with the
sending to the MSC of INTERNAL HANDOVER REQUIRED
MC975b - NB_BSS_Int_HO_with_MSC_SUCC: Number of "BSS internal handover with MSC support"
success. Whenever a 44.018 ASSIGNMENT COMPLETE/HANDOVER COMPLETE message is received on Abis
interface from the target cell for a TCH channel that is involved in an BSS internal handover with MSC
support and is reported to MSC in HANDOVER COMPLETE message.
MC975c - NB_BSS_Int_HO_with_MSC_ALLOC: Number of allocation due to "BSS internal handover
with MSC support 08.58 CHANNEL ACTIVATION to be sent to the BTS due to receipt of INTERNAL
HANDOVER COMMAND from MSC.
MC975d - NB_BSS_Int_HO_with_MSC_ATPT: Number of "BSS internal handover with MSC support"
attempts. Sending of 04.08ASSIGNMENT COMMAND/HANDOVER COMMAND to the MS on the serving
channel. Only handovers which has triggered "BSS internal handover with MSC support" procedure shall be
taken into account.

To ensure that the best fit of dedicated resources (that is; Codec Type, Codec Configuration and Interface
Type) are allocated to the ongoing call, The MSC may also trigger the BSS Internal Handover procedure
The message Internal Handover Enquiry is sent by the MSC to BSC; its goal is to get back the updated BSS
Codec capabilities to handle a specific call and no specific target cell is indicated in the message (the
primary goal is to change the Codec, not necessarily the cell, and typically an intra-cell handover would be
finally triggered in this case). The resource preferred by the MSC is given in "Speech Codec (MSC chosen)"
parameter.
Then the BSC triggers an "BSS internal handover with MSC support" or may respond with an HANDOVER
FAILURE message with cause value "INTERNAL HANDOVER ENQUIRY reject
MC490a - NB_HO_INTRA_ATPT_33_MSC_trigg_int
Number of MSC initiated internal handover (cause 33: codec change triggered by the core network)
triggering an intra cell handover
MC490b - NB_HO_INTER_ATPT_33_MSC_trigg_int
Number of MSC initiated internal handover (cause 33: codec change triggered by the core network)
triggering an inter cell handover

MC830 - NB_INC_INT_HO_REQ
MC830=C230+C330
MC551 - NB_INC_INT_TCH_HO_PREP_FAIL_CONG_R_ABIS
Number of incoming internal inter-cell TCH (in HR or FR usage) handover -preparation failures due to
congestion.
Whenever an internal inter-cell TCH handover cannot be performed, because the target cell is congested
(no free TCH channel).
Note 1: In MX BSC, this counter is incremented whenever an internal inter-cell TCH handover cannot be
performed due to the TCH processing capacity of CCP reaches the limit defined by the MAX_TCH_PER_CCP
parameter. In this case, MC926 is also incremented by one.
Note 2: In IP mode, this counter is increased by 1 if:
l the cell mapped on a BTS is in IP congestion status;
l or
the TCH processing capacity of AbisBTSGroup reaches the limit defined by the
NB_MAX_ACTIVE_TCH_TS parameter

MC660 - NB_OUT_INT_HO_ATPT
MC660=C60+C100
MC653 - NB_INC_INT_HO_EXEC_FAIL_MS_ACCESS
MC653=C53+C93
All incoming internal HO failures due to radio problems are counted in the same counter MC653.
Both radio failures with Reversion Old Channel and radio drop are counted together.

MC660 - NB_OUT_INT_HO_ATPT
MC660=C60+C100
MC653 - NB_INC_INT_HO_EXEC_FAIL_MS_ACCESS
MC653=C53+C93
All incoming internal HO failures due to radio problems are counted in the same counter MC653.

Handover Statistics INDICATORS > Incoming handover > Incoming Intra BSC
lGHOIBEFR: efficiency of the incoming internal HO execution
lGHOIBCGR: rate of incoming internal HO failures due to congestion
lGHOIBPFR: rate of incoming internal HO failures due to BSS during the preparation phase
lGHOIBFLRR: rate of incoming internal HO failures due to radio problems
lGHOIBFLBR: rate of incoming internal HO failures due to BSS during the execution phase

Both SDCCH and TCH are counted together.
From B7, MC645A replaces MC645 of B6.
MC645a is only counting HANDOVER REQUIRED messages that are linked to a handover trial and not those that are
linked to the update of the candidate cell list for handover / directed retry. This is leading to a more accurate
computation of the External outgoing HO success rate.
Only Outgoing inter PLMN HO is allowed.
6 counters provide information for "Inter-PLMN HO" (Incoming and Outgoing) (From B8)
l MC462a (equivalent of MC645A for intra PLMN external HO)
Number of inter-PLMN TCH outgoing handovers or directed retry requests:
HANDOVER REQUIRED sent to the MSC for an external TCH HO or an external DR triggered towards a cell
belonging to a PLMN different from the PLMN of the serving cell.
l MC462b (equivalent of MC650 for intra PLMN external HO)
Number of inter-PLMN TCH outgoing handovers or directed retry attempts:
HANDOVER COMMAND sent to the MS on Abis for an external TCH HO or an external DR triggered towards a cell
belonging to a PLMN different from the PLMN of the serving cell.
l MC462c (equivalent of MC646 for intra PLMN external HO)
Number of inter-PLMN TCH outgoing handovers or directed retry successes:
CLEAR COMMAND with Cause "Handover successful" received from the MSC for an external TCH HO or an external
DR triggered towards a cell belonging to a PLMN different from the PLMN of the serving cell.
l MC463a (equivalent of MC820 for intra PLMN external HO)
Number of inter-PLMN TCH incoming handovers or directed retry requests:
HANDOVER REQUEST received from the MSC for an external TCH HO or an external DR triggered towards the
target cell from a serving cell belonging to a PLMN different from the PLMN of the target cell.
l MC463b (equivalent of MC821 for intra PLMN external HO)
Number of inter-PLMN TCH incoming handovers or directed retry attempts:
HANDOVER REQUEST ACK sent by the target BSC containing the HANDOVER COMMAND for an external TCH HO or
an external DR triggered towards the target cell from a serving cell belonging to a PLMN different from the PLMN
of the target cell.
l MC463c (equivalent of MC642 for intra PLMN external HO)
Number of inter-PLMN TCH incoming handovers or directed retry successes:
HANDOVER COMPLETE received from the MS on Abis for an external TCH HO or an external DR triggered towards
the target cell from a serving cell belonging to a PLMN different from the PLMN of the target cell.
Note than all other (previous) counters related to HO continue to be based on Intra PLMN only.

"deduced" : shows all the failures that were not counted by dedicated counters, by computing the missing
successes.

MC541a - NB_INC_EXT_TCH_HO_PREP_FAIL_CONG_R_ABIS
Number of incoming external TCH (in HR or FR usage) handover -preparation failures due to congestion.
Whenever a 48.008 HANDOVER FAILURE message with a cause value of "no radio resource available" is
sent on A interface from the target BSC to the MSCduring an external TCH handover.
Note 1: This counter counts both inter-PLMN and intra-PLMN handover events.
Note 2: In MX BSC, this counter is incremented whenever a 48.008 HANDOVER FAILURE message with a
cause value of "no radio resource available" is sent due to the TCH processing capacity of CCP reaches the
limit defined by the MAX_TCH_PER_CCP parameter. In this case, MC926 is also incremented by one.
Note 3: In IP mode, this counter is increased by 1 if:
l the cell mapped on a BTS is in IP congestion status;
l or
the TCH processing capacity of AbisBTSGroup reaches the limit defined by the
NB_MAX_ACTIVE_TCH_TS parameter

MC41b - NB_INC_EXT_TCH_HO_PREP_FAIL_NO_TTCH
Number of incoming external TCH (in HR or FR usage) handover -preparation failures due to A-traffic-
channel status mismatch between the BSC and theMSC.
1) Whenever a 48.008 HANDOVER FAILURE message with a cause value of "requested terrestrial resource
unavailable" is sent on A interface from the target BSC to the MSC.
2) Whenever a 48.008 HANDOVER FAILURE message with a cause value of "terrestrial circuit already
allocated" is sent on A interface from the target BSC to the MSC.
3) Whenever a 48.008 HANDOVER FAILURE message with a cause value of "BSS not equipped" is sent on A
interface from the target BSC to the MSC.
Note: This counter counts both inter-PLMN and intra-PLMN handover events.

All incoming external HO failures due to radio problems are counted in the same counter MC643.

All incoming external HO failures due to radio problems are counted in the same counter MC643.

Handover Statistics INDICATORS > Incoming handover > Incoming Inter BSC
l GHOIMEFR: efficiency of the incoming external HO execution
l GHOIMCGR: rate of incoming external HO failures due to radio congestion (Air or Abis TCH)
l GHOIMAMR: rate of incoming external HO failures due to CIC congestion (A TCH)
l GHOIMPFR: rate of incoming external HO failures due to BSS during the preparation phase
l GHOIMFLRR: rate of incoming external HO failures due to radio problems
l GHOIMFLBR: rate of incoming external HO failures due to BSS during the execution phase
Inter PLMN Incoming External HO Indicators (from B8)

An indicator is created for each counter:
l REQUESTS
l ATTEMPTS
l SUCCESS
In addition, these indicators show:

l the success rate of incoming inter-PLMN HOs,
l the ratio of incoming inter-PLMN HO to incoming intra-PLMN and inter-PLMN HO.

Refer to BSS - DEFINITION OF QUALITY OF SERVICE INDICATORS RELEASE:
Handover Statistics INDICATORS > Outgoing handover > Outgoing Inter BSC
l GHOOMRQR: efficiency of the outgoing external HO preparation
l GHOOMEFR: efficiency of the outgoing external HO execution
l GHOOMOCR: rate of outgoing external HO failures due to radio problems with Reversion Old Channel
l GHOOMCDRR: rate of outgoing external HO failures due to radio problems with drop
l GHOOMCDR: rate of incoming external HO failures with drop (radio + BSS)
Inter PLMN Outgoing External HO Indicators (From B8)

An indicator is created for each counter:
l REQUESTS
l ATTEMPTS
l SUCCESS
In addition, these indicators show:

l the success rate of outgoing inter-PLMN HOs,
l the ratio of outgoing inter-PLMN HO to outgoing intra-PLMN and inter-PLMN HO.

According to the definition of C40i counters:
l C400(Sn,T) = MC820(T) + MC830(T)
l C401(Sn,T) = MC821(T) +MC831(T)
l C402(Sn,T) = MC642(T) + MC652(T)
n where
n Sn are the serving cells considering the incoming adjacencies to cell T.
n MC820(T), MC821(T), MC642(T) are the counters relating to the incoming external handovers
requested, attempted and successfully performed to cell T.
n MC830(T), MC831(T), MC646(T) are the counters relating to the incoming internal handovers
requested, attempted and successfully performed to cell T.
Set of incoming external or internal inter-cell SDCCH or TCH (in HR or FR usage) handover counters
provided per adjacency: variable serving cell - variable target cell. The internal and external directed retries
are counted. Only handovers / directed retries from 2G cells are taken into account (i.e. handovers from 3G
are not counted in type 180).

Note : in NPO, when n/a is seen in the table, it means "0" (= no HO were done during the period)

Handover Statistics > HO Statistics per couple of cells > Indicators with counter type 180
l Theseindicators can also be used to check if a recently handover relationship is generating handover
as expected.
l Theywill also allow to identify the handover relationships which should be deleted since no (or very
few) handover is observed.

Other counters are provided:
l C734(Sx,T): Incoming handovers attempted from Sx to T for an emergency cause.
l C735(Sx,T): Incoming handovers attempted from Sx to T for a better cell cause.
l C737(Sx,T): Incoming handovers attempted from Sx to T for a traffic cause.
l C738(Sx,T): Incoming handovers attempted from Sx to T for a forced directed retry cause.
The set of Type 27 counters can be retrieved for only one cell per BSS at once.

Handover Statistics > HO Statistics per couple of cells > Indicators with counter type 27

(1) Need of Handover to 3G cell is detected (see the Cause 31 Detection and HO Candidate Cell
Evaluation).
T7 is started
T_HO_REQD_LOST is started to guard against no response from the MSC.
(2) The BSC initiates an intersystem to UMTS external channel change by sending a HANDOVER
REQUIRED message with the 3G cell in the top of the cell list.
Note: the HANDOVER REQUIRED message may contain the OIE Response Request
depending on the O&M parameter RESP_REQ.
(3) The MSC performs the handover required procedure with the target RNC. The protocol shown in the
figure is for example only: it may deviate, as it is not in the scope of this training.
(4) The MSC indicates to the serving BSS that the handover is accepted by the UMTS, in a HANDOVER
COMMAND message.
The L3 INTERSYSTEM TO UTRAN HANDOVER COMMAND is included in that HANDOVER COMMAND.
(5) The serving BSC: stops T_HO_REQD_LOST; sends the INTERSYTEM TO UTRAN HANDOVER IE
COMMAND to the UE/MS; starts T3121.
(6) The UE/MS on reception of the INTERSYTEM TO UTRAN HANDOVER COMMAND: disconnects the
old channel; synchronizes to the new cell and sends a HANDOVER COMPLETE message to the target RNC.
(7) The target RNC terminates the protocol to the MSC.
(8) The serving BSS RF channel and terrestrial resources are released. This is performed by the MSC
sending the CLEAR COMMAND (cause "Handover successful") , T3121 and T7 are stopped.

HO_Inc_MSC_3G_2G_HOreject_HL_Time:
l Cumulative time (in seconds) during which the Cell is in 3G high load state
l i.e.Whenever the 3G_HOReject_Load State in the cell is reported as high or reported as indefinite
while the previous state was high. This counter shall be incremented only if
THR_CELL_LOAD_3G_REJECT < 100%.

The call flow for a voice handover from LTE to 2G RAN:
1. UE sends measurement reports to E-UTRAN.
2. Based on UE measurement reports the source E-UTRAN decides to trigger an SRVCC handover to
GERAN.
3. Source E-UTRAN sends Handover Required (Target ID, generic Source to Target Transparent Container,
SRVCC HO Indication) message to the source MME. The E-UTRAN places the "old BSS to new BSS
information IE" for the CS domain in the generic Source to Target Transparent Container.
4. Based on the QCI associated with the voice bearer (QCI 1) and the SRVCC HO indication, the source
MME splits the voice bearer from the non voice bearers and initiates a PS-CS handover procedure for
the voice bearer only towards MSC Server.
6. The MSC Server interworks the PS-CS handover request with a CS inter-MSC handover request by
sending a Prepare Handover Request message to the target MSC. The MSC Server assigns a default SAI
as Source ID on the interface to the target BSS and uses BSSMAP encapsulated for the Prepare Handover
Request. The value of the default SAI is configured in the MSC and allows a release 8 and later BSC to
identify that the source for the SRVCC Handover is E-UTRAN. To ensure correct statistics in the target
BSS the default SAI should be different from the SAIs used in UTRAN.
10. MSC Server initiates the Session Transfer by using the STN-SR e.g. by sending an ISUP IAM (STN-SR)
message towards the IMS. IMS Service Continuity IMS Service Continuity procedures are applied for
execution of the Session Transfer, see TS 23.237
11-12. During the execution of the Session Transfer procedure the remote end is updated with the SDP of
the CS access leg. The downlink flow of VoIP packets is switched towards the CS access leg at this point.
Source IMS access leg is released as per TS 23.237
16. UE tunes to GERAN.
17. Handover Detection at the target BSS occurs. The UE sends a Handover Complete message via the
target BSS to the target MSC. If the target MSC is not the MSC Server, then the Target MSC sends an SES
(Handover Complete) message to the MSC Server.
18. The UE starts the Suspend procedure specified in TS 23.060 , clause 16.2.1.1.2. The TLLI and RAI pair
are derived from the GUTI as described in TS 23.003. This triggers the Target SGSN to send a Suspend
Notification message to the Source MME. The MME returns a Suspend Acknowledge to the Target SGSN.

The 3GPP has defined the VCC (Voice Call Continuity) which provides the capability to transfer the path of
an existing voice call between a 3GPP CS system (GSM/UMTS) and IMS, and vice versa.
The SRVCC (Single Radio Voice Call Continuity) is the 3GPP way to perform a handover for voice calls from
LTE (PS domain) to GSM (CS domain).
Three scenarios are presented:
l without DTM
l with DTM but without DTM HO support
l with DTM HO support.
DTM is supported in ALU BSS while DTM HO is not. The third scenario is then not relevant for ALU BSS.
This feature implements a mean for the BSS to reject LTE to GSM handovers, based upon the target cell
load (similar to what has been already implemented for 3G to GSM handovers); this is the load based
filtering procedure.
With the introduction of this feature, the BSC either accepts or rejects a handover from a LTE network,
based on its own traffic load and the handover cause. If the load exceeds the threshold defined for the LTE
network, only emergency handovers are allowed.

MCC is the Mobile Country Code, MNC is the Mobile Network Code, LAC is the Location Area Code, CI is the
Cell Identification.
Handovers towards cells belonging to a different PLMN are not possible if CGI_REQD is set to 0.
Handovers towards UMTS cells belonging to a different PLMN are not possible if CGI_3G_REQUIRED is
set to 0.
The MS will only measure those Neighbour cells which have a BSIC whose PLMN colour code matches with
the coding in the NCC Permitted transmitted to the MS in the SYSTEM INFORMATION TYPE 6.

RTCH_HO_Inc_InterPLMN_request_ratio : RTCH_HO_Inc_InterPLMN_request / RTCH_HO_request

The Global HO cause standard indicator is defined as below:
where:
l MC670: Number of handover attempts cause 2: "uplink quality too low"
l MC672: Number of handover attempts cause 4: downlink quality too low"
l MC671: Number of handover attempts cause 3: "uplink level too low"
l MC673: Number of handover attempts cause 5: "downlink level too low"
l MC676: Number of handover attempts cause 15: "too high uplink interference level"
l MC677: Number of handover attempts cause 16: "too high downlink interference level"
l MC678: Number of handover attempts cause 12: "too low power budget"
l MC674: Number of handover attempts cause 6: "MS-BTS distance too long"

Handover statistics INDICATORS > Handover causes
GHCXXYYYYR: Rate of specific HO cause xxyyyy versus all HO causes (Global)
l where XX = ST (standard) or MC (micro cell) or CC (concentric cell) or MB (multi band)
l and YYYY is specific to the cause

Handover statistics INDICATORS > Handover causes
GHCXXYYYYR: Rate of specific HO cause xxyyyy versus all HO causes (Global)
l where XX = ST (standard) or MC (micro cell) or CC (concentric cell) or MB (multi band)
l and YYYY is specific to the cause

Global Outgoing HO success rate: represents the global efficiency of the outgoing handovers performed from
one cell to any of its neighboring cells (same BSS or not).
Efficiency of Outgoing HO execution: represents the efficiency of the channel change procedure during
outgoing handovers performed from one cell to any of its neighboring cells (same BSS or not). It does not
take into account the HO failures that can occur during the preparation phase when the new channel is
being selected and activated.
HO_Out_success = HO_Out_MSC_2G_3G_success + HO_Out_MSC_2G_2G_success +

HO_Out_BSC_success
HO_Out_required =
HO_Out_MSC_2G_2G_required+HO_Out_BSC_required+HO_Out_MSC_2G_3G_required
HO_Out_request = HO_Out_MSC_2G_2G_request+HO_Out_BSC_request+HO_Out_MSC_2G_3G_request

Global Incoming HO success rate: represents the global efficiency of the incoming handovers performed to
one cell from any of its neighboring cells (same BSS or not).
Efficiency of Incoming HO execution: represents the efficiency of the channel change procedure during
incoming handovers performed to one cell from any of its neighboring cells (same BSS or not). It does not
take into account the HO failures that can occur during the preparation phase when the new channel is
being selected and activated.
HO_Inc_success = HO_Inc_MSC_success + HO_Inc_BSC_success

HO_Inc_request = HO_Inc_MSC_request + HO_Inc_BSC_request
HO_Inc_allocated = HO_Inc_MSC_allocated + HO_Inc_BSC_allocated

Document History


Page
1 Call mix definition 7

2 Basis of traffic theory 15
3 TCH resource allocation indicators 29
4 Resource occupancy indicators 34
5 Traffic model indicators 38
6 Preemption indicators 43


In a GSM network, telecom procedures involve different kind of resources in the BSS:
l Location Update: RACH, AGCH, SDCCH and SCCP
l Originated Call: RACH, AGCH, SDCCH, TCH and SCCP
l Terminated Call: PCH, RACH, AGCH, SDCCH, TCH and SCCP
l Handover: TCH, SCCP
l etc.
Elementary traffic
Set of elementary events of the same type generated by the system environment with certain intensity
which
demand system resources
We give here as example a list of telecom elementary traffics:
l Mobile Originating Call,
l Mobile Terminating Call,
l Location Update,
l Handover,
l IMSI attach,
l IMSI detach,
l SMS originating,
l SMS terminating,
l Paging,
l Location request.

A Call mix can be defined through:
l data given by the Marketing team.
l data measured from the living network.
Before network design, a Call Mix is assessed from Marketing Studies or observations from other networks.
After commercial opening, a Call Mix is measured from the real traffic.
Caution: Call duration means here TCH duration. The duration of a call from call setup to call release is an
NSS notion.

After commercial opening, the number of calls per hour will be measured from traffic counters.
Usually the Marketing team will provide:
l on a per geographical area or morphostructure basis:
n the traffic per km2 (in Erlang),
n the traffic per subscriber (in mErl).
l the number of calls per hour.

On some university campus, an SMS/call is often higher than the average.

A Call Mix will be used at Radio Network Design and Radio Network Planning stages in order to define the
capacity of the network (number of sites, TRXs per site, radio configuration, number of Abis-PCM, A-PCM).
When the network is in operation, a Call Mix is used in order to anticipate network extension or re-
dimensioning.

ERLANG law computes blocking probability with some assumptions on traffic statistical properties:
l ERLANG B law this is the formula to use when a blocked call is really blocked, its built
around three variables: servers, traffic and grade of service. If we know any two of those, the formula
will calculate the third one.
l ERLANG C law use this formula when a blocked call is delayed. It uses the same three
variables, plus the average length of each call to calculate the probability of being delayed and how
long the delay is likely to be.

The Erlang B law is not fully accurate since it assumes that:
l the subscriber requests are not queued, which is not always the case (TCH queued in the BSC),
l the subscriber does not repeat his call request if rejected, which is almost never the case.
Therefore the higher the blocking rate, the worse is the approximation of the Erlang B law.
The Erlang C law modelizes better the TCH resource usage of the BSS since it takes into account the
queuing.
However, the Erlang C law is never used since parameters like size of the queue and time spent into the
queue have to be tuned.

The Erlang B law is less relevant for SDCCH dimensioning since SDCCH traffic cannot be modelized like TCH
traffic. Indeed, SDCCH is not only due to subscriber traffic but also to Location Update, SMS, IMSI Detach,
etc.
For SDCCH dimensioning, some typical configurations are used according to the number of TRXs in the cell,
the LA plan.

Traffic Load and Traffic Model > TCH traffic > Speech version and Channel type
These indicators can only be computed if PM Type 1 is activated in B7. From B8, the counters needed for these
indicators are added to type 110.
The following indicators are also computed:

l Ratio of TCH normal assignment requests from FR mobiles over all TCH normal assignment requests from all
mobile types
= TCNARQMTO = MC701A / (MC701A+MC701B+MC701C+MC701D+MC701E)
l Ratio of TCH normal assignment requests from DR mobiles over all TCH normal assignment requests from all
mobile types
= TCNARQBTO = MC701B / (MC701A+MC701B+MC701C+MC701D+MC701E)
l Ratio of TCH normal assignment requests from DR+EFR mobiles over all TCH normal assignment requests from all
mobile types
= TCNARQTTO = MC701C / (MC701A+MC701B+MC701C+MC701D+MC701E)
l Ratio of TCH normal assignment requests from AMR mobiles over all TCH normal assignment requests from all
mobile types
= TCNA3RQTTO = MC701D / (MC701A+MC701B+MC701C+MC701D+MC701E)
l Ratio of TCH normal assignment requests for Data calls over all TCH normal assignment requests from all mobile
types
= TCNARQDTO = MC701E / (MC701A+MC701B+MC701C+MC701D+MC701E)
MC701j - NB_TCH_AIP_REQ
Receipt of 48.008 ASSIGNMENT REQUEST from the MSC with IP A interface only allowed in Codec List (MSC Preferred)
MC701i - NB_TCH_ATDM_REQ
Receipt of 48.008 ASSIGNMENT REQUEST from the MSC with TDM A interface only allowed in Codec List (MSC
Preferred)

Traffic Load and Traffic Model > TCH traffic > Speech version and Channel type
The following indicators are also computed:

l Ratio
of TCH allocations with FR SV1 over all TCH allocations during normal assignment
= TCNACAFTO = MC702A / (MC702A+MC702B+MC702C+MC704A+MC704B+MC705)
l Ratio
of TCH allocations with HR SV1 over all TCH allocations during normal assignment
= TCNACAHTO = MC702B / (MC702A+MC702B+MC702C+MC704A+MC704B+MC705)
l Ratio
of TCH allocations with EFR over all TCH allocations during normal assignment
= TCNACAETO = MC702C / (MC702A+MC702B+MC702C+MC704A+MC704B+MC705)
l Ratio
of TCH allocations with AMR FR over all TCH allocations during normal assignment
= TCNA3CAFTO = MC704A / (MC702A+MC702B+MC702C+MC704A+MC704B+MC705)
l Ratio
of TCH allocations with AMR HR over all TCH allocations during normal assignment
= TCNA3CAHTO = MC704A / (MC702A+MC702B+MC702C+MC704A+MC704B+MC705)
l Ratio
of TCH allocations for Data calls over all TCH allocations during normal assignment
= TCNACADTO = MC705 / (MC702A+MC702B+MC702C+MC704A+MC704B+MC705)
l Rate
of successful TCH allocations with AMR SV over all AMR MS requests
= TCNA3SUR = (MC704A+MC704B) / MC701D
l MC931 - NB_TCH_NOR_AMR_WB_GMSK_FR_ALLOC
Number of TCH normal assignment/mode modify in FR AMR WB GMSK usage - whose channel is allocated
in the BSC. This counter takes into account mode modify from TCH signaling to TCH traffic (following a
DTM assignment with a TCH in signaling mode).

Traffic Load and Traffic Model > TCH traffic > Resource occupancy
l MC370A = Number of FR TCH allocations (FR+EFR+AMR FR)

l MC370B = Number of HR TCH allocations (HR+AMR HR)
l MC703 = Number of TCH allocations for Normal Assignment

l MC15A = Number of TCH allocations for Internal Directed Retry
l MC15B = Number of TCH allocations for Handover (intra cell, internal, external)
TCNACAN indicator is also available as the MAX value of the day on the NPO tool.
Some of these indicators are also available for SDCCH:

l SDCCH allocation distribution per TRX through the number of SDCCH allocations
SDAHCAN = MC390
l SDCCH Assignment/HO distribution through the ratio of SDCCH allocations for Assignment
SDNACAO = MC148 / MC390

Traffic Load and Traffic Model > TCH traffic > Resource occupancy
l MC380A = Cumulated FR TCH duration per TRX

l MC380B = Cumulated HR TCH duration per TRX
The following indicators can also be computed:
l TCTRME = Multiband MS TCH traffic in Erlang = MC381 / 3600
l TCTRSE = Single band MS TCH traffic in Erlang = ([MC380A+MC380B] - MC381) / 3600
l MC381 = Cumulated (FR+HR) TCH duration of Multiband mobiles per TRX

A split of counters (MC380a and MC380b) is added, in B8, to make the distinction between traffic in
different frequency bands: here after the corresponding stored indicators (type 110):
l TCTRFTTGT = Time (in seconds) during which the TCH radio timeslot or dynamic SDCCH/8 timeslot in
the GSM frequency band is busy in FR usage = MC380C
l TCTRHTTGT = Time (in seconds) during which the TCH radio timeslot or dynamic SDCCH/8 timeslot in
the GSM frequency band is busy in HR usage = MC380D
l TCTRFTTDT = Time (in seconds) during which the TCH radio timeslot or dynamic SDCCH/8 timeslot in
the DCS/PCS frequency band is busy in FR usage = MC380E
l TCTRHTTDT = Time (in seconds) during which the TCH radio timeslot or dynamic SDCCH/8 timeslot in
the DCS/PCS frequency band is busy in HR usage = MC380F

TCH resource occupancy
l TCH traffic in Erlang
TCTRE= (MC380A+MC380B) / 3600
l TCH mean holding time (TCH average duration)
TCTRMHT= (MC380A+MC380B) / (MC370A+MC370B)
l FR TCH traffic in Erlang
TCTRE= MC380A / 3600
l FR TCH mean holding time
TCTRFMHT= MC380A/ MC370A
l HR TCH traffic in Erlang
TCTRE= MC380B / 3600
l HR TCH mean holding time
TCTRHMHT= MC380B/ MC370B
TCTRFTTGT = Time (in seconds) during which the TCH radio timeslot or dynamic SDCCH/8 timeslot in the
GSM frequency band is busy in FR usage = MC380C
l TCTRHTTGT = Time (in seconds) during which the TCH radio timeslot or dynamic SDCCH/8 timeslot in
the GSM frequency band is busy in HR usage = MC380D
l TCTRFTTDT = Time (in seconds) during which the TCH radio timeslot or dynamic SDCCH/8 timeslot in
the DCS/PCS frequency band is busy in FR usage = MC380E
l TCTRHTTDT = Time (in seconds) during which the TCH radio timeslot or dynamic SDCCH/8 timeslot in
the DCS/PCS frequency band is busy in HR usage = MC380F

Traffic Load and Traffic Model > SDCCH traffic > Resource occupancy
l MC400 = Cumulated SDCCH duration per TRX
l MC380 = Number of SDCCH allocations per TRX
C750 and C751 are 2 counters introduced from B7 in type 18. Both are provided per TTCH (A channel):
l C750 = TIME_A_CHANNEL_BUSY: Time (in seconds) during which the A channel is busy (allocated)
l C751 = NB_A_CHANNEL_ALLOC: Number of allocations of the A channel

Traffic Load and Traffic Model > SDCCH traffic > Traffic model
SDCCH ASSIGN SUCCESS = Total number of SDCCH establishments for network access = MC01 + MC02
These indicators allow one to get call mix data from the network.

l Traffic Load and Traffic Model > SDCCH traffic > MS penetration rate
l Traffic Load and Traffic Model > TCH traffic > Speech version and Channel type
l [MC01+MC02]-[MC02A+MC02D+MC02G] = Total number of initial accesses for call establishment

(except location update)
l MC706 = Number of initial accesses for call establishment (except location update) of MS supporting
the E-GSM band
l MC850 = Number of initial accesses for call establishment (except location update) of MS supporting
two frequency bands (ex: GSM900 and DCS1800)
l MC703 = Total number of TCH allocations (FR+HR) for Normal Assignment
l MC704A = Number of TCH allocations (FR) for Normal Assignment of AMR mobiles only
l MC704B = Number of TCH allocations (HR) for Normal Assignment of AMR mobiles only
MC704 (Allocation AMR FR+HR) is removed in B8
l MC170 = Number of TCH calls for which a TFO has been successfully established

On Preemption capable TCH Request occurrence:
1. 1. The TCH is established through Preemption if a lower priority level on-going call is preemptable.
In this case, the on-going call is released and the freed TCH is served to the new request.
2. 2. If no preemption is possible:
n If queuing is possible: the TCH request is queued and either a Directed Retry or a Fast Traffic
HO can be performed.
n If queuing is not possible: the TCH request is rejected and an ASSIGNMENT or HANDOVER
FAILURE "no radio resource available" message is sent to the MSC.

GLOBAL Quality of service INDICATORS> RTCH > Preemption feature

GLOBAL Quality of service INDICATORS> RTCH > Preemption feature

Document History


Page
1 Introduction 7
2 How does it work? 11
3 RMS job activation 14
4 RMS message flow scenario 19
5 MAFA 23


Frequently asked question:
Will activating RMS overload the network?
No, activating RMS wont overload the network since most of the work is done in the BTS.
That's why RMS can be activated permanently on all the cells of the network. This has been done on
several main Alcatel-Lucent networks.

Document History


Page
1 General information 7
2 The neighbor cell statistics 10
3 Radio quality related statistics 20
4 Voice quality statistics 40
5 AMR statistics 58
6 TA statistics 68

Page

RNO RMS Indicators:
l RMS_info_CI_overload_indication:
n Flag indicating that the upper limit of 42 C/I vectors is exceeded during RMS job duration. In
this case, new C/I vectors are not taken into account
n The list of frequencies to be monitored by the mobile is limited to 33 but due to resurgence the
same frequency can be reported several times (each time with a different BSIC). If the number
of reported cells is above the dimensioning limit (maximum 42 CI-vectors are reported), the
extra new reported frequencies are not taken into account anymore. In the result report the
related overflow indicator is set accordingly.
l RMS_info_overload_indication:
Indication whether a TRX overload occurred during RMS job duration. In this case, the measurements
data collection is interrupted until the overload situation disappears. RMS statistics are thus based on
partial measurements collection
l RMS_info_Partial_Restart_indication:
Bit map indicating that the measurements (for and only for CI vector computation) on either
Neighbour cells or on MAFA frequencies or on both or none were restarted during RMS job duration.
The bitmap is represented as follows:
0: no CI partial result

RMS_Extended_Meas_Report_total:
Total number of extended measurements (through MAFA) during the RMS statistics retrieval

The BCCH ARFCN is deduced in the BTS from the BCCH frequency index and the list of indexed frequencies
(sent by the BSC at the beginning of the RMS job).
In case of a frequency reported via Extended Measurement Reporting, no BSIC is required : the frequency
ARFCN is not directly linked to a BCCH frequency. The ARFCN value of the frequency is deduced in the BTS
from the place of the measurement in the EXTENDED_ MEASUREMENT_REPORT and from the ordered list
of the EMO-frequencies. This list is built by the OMCR and passed via BSC to BTS at the beginning of the
RMS job.
The CI-vector shall be provided for each requested (by operator) frequency in context of Extended
Measurement Reporting. The maximum number of frequencies in the order (EMO) is the maximum defined
in 3GPP (=21). Hence the maximum in the report is 21 also. When in exceptional cases, more results are
available (future expansion in 3GPP), only the first 21 are reported.

The difference of (BS_TXPWR - BS_TXPWR_MAX) has been introduced in order to compensate the
differences of the power transmission levels due to the DL power control.
The expression (RXLEV_DL + abs(BS_TXPWR - BS_TXPWR_MAX)) can be seen as a kind of normalized
received power level in case the BTS would always have used the maximum allowed power level.
Note that the formula is written independently of the coding used for the variables.
RXLEV_DL and RXLEV_NCELL are the received signal levels of the serving and of the neighbor cells,
expressed in dBm.
BS_TXPWR is the BTS transmitted power and BS_TXPWR_MAX is the maximum allowed BTS transmission
power.
Both are defined relatively to the maximum absolute output power of the BTS
(BTS_MAX_OUTPUT_POWER).
BS_TXPWR and BS_TXPWR_MAX are expressed in dB.
The function abs() gives the absolute value of its argument.

The difference of (BS_TXPWR - BS_TXPWR_MAX) has been introduced in order to compensate the
differences of the power transmission levels due to the DL power control.
The expression (RXLEV_DL + abs(BS_TXPWR - BS_TXPWR_MAX)) can be seen as a kind of normalized
received power level in case the BTS would always have used the maximum allowed power level.
Note that the formula is written independently of the coding used for the variables.
RXLEV_DL and RXLEV_NCELL are the received signal levels of the serving and of the neighbor cells,
expressed in dBm.
BS_TXPWR is the BTS transmitted power and BS_TXPWR_MAX is the maximum allowed BTS transmission
power.
Both are defined relatively to the maximum absolute output power of the BTS
(BTS_MAX_OUTPUT_POWER).
BS_TXPWR and BS_TXPWR_MAX are expressed in dB.
Note:
From B9, the variable BTS_MAX_OUTPUT_POWER (used for the power control and the path balance
statistics) should be reported as a new RMS counter.

C/I band 1 is defined by : -63 dB <= C/I < MEAS_STAT_C/I_1
C/I band 2 is defined by : MEAS_STAT_C/I_1 <= C/I < MEAS_STAT_C/I_2
:
:
:
C/I band 10 is defined by : MEAS_STAT_C/I_9 <= C/I <= 63 dB

To save on the memory resources, these counters are in a coded format.
The used coding mechanism is the following:

The counters in the table (C1,C10) are one-byte percentage-counters. In fact the counters indicate the
fraction of the row-maximum. (see Max).
At coding time the coded values (the fraction) are determined as follows:
Ci = Vi x 254 / row_maximum
Notes:
Vi represents the real number of measurements
the value Ci=0 indicates number_of_meas = 0
the value Ci=254(0FE) indicates number_of_meas = row_max
the value Ci=255(0FF) is reserved to indicate overflow
At decoding time the real values are determined as follows:
Vi = Ci x row_maximum / 254
Max: The maximum number of measurement reports received.
Max = max of (V1,V2,V10)

C/I band 1 is defined by : -63 dB <= C/I < MEAS_STAT_C/I_1
:
:
:
C/I band 10 is defined by : MEAS_STAT_C/I_9 <= C/I <= 63 dB
To save on the memory resources, these counters are in a coded format. The used coding mechanism is
the following:
The counters in the table (C1,C10) are one-byte percentage-counters. In fact the counters indicate the
fraction of the row-maximum. (see Max).
At coding time the coded values (the fraction) are determined as follows:
Ci = Vi x 254 / row_maximum
Notes:
Vi represents the real number of measurements
the value Ci=0 indicates number_of_meas = 0
the value Ci=254(0FE) indicates number_of_meas = row_max
the value Ci=255(0FF) is reserved to indicate overflow
At decoding time the real values are determined as follows:
Vi = Ci x row_maximum / 254

This counter RMS3a=TPR_RXQUAL_UL_RXLEV_UL is a matrix
l represented on the left side
This counter RMS3b=TMR_RXQUAL_UL_RXLEV_UL is a vector
l represented on the right side
The real number of Measurement Results in which UL RxQual is equal to i and UL RxLev is in RXLEV band j,
is equal to:
l S(RXQUAL i, RXLEV band j) x Max j / 254
l TPR_RXQUAL_UL_RXLEV_UL(i,j) x TMR_RXQUAL_UL_RXLEV_UL(j) / 254

There are 10 levels bands which are defined through 9 thresholds parameters, tuneable on a per RMS
template basis, as follows:
l Level band 1 is defined by: -47 dBm >= RXLEV > MEAS_STAT_LEV_1
l Level band 2 is defined by: MEAS_STAT_LEV_1 >= RXLEV > MEAS_STAT_LEV_2
l:
l Level band 10 is defined by: MEAS_STAT_LEV_9 >= RXLEV >= -110 dBm
C1,C80: Indicate the number of measurement reports received for the corresponding row and column. To
save on the memory resources, these counters are in a coded format. The used coding mechanism is as
described in the CI-vector section.
Max1,Max10: The maximum number of measurement reports received for the corresponding ROW.
l Max_1 = max of (V1,V2,V8)
l :
l Max_10 = max of (V72,V73,V80)
In order to provide correct averages, the TRE cumulates the MS_TXPWR and timing advance. Therefore
during measurement the TRE requires a 4 byte-storage for every counter. At the end of the observation,
before passing it to the BSC, the TRE determines the average value (with one decimal) and coded it into a
one_byte_average value.

There are 10 levels bands which are defined through 9 thresholds parameters, tuneable on a per RMS
template basis, as follows:
l Level band 1 is defined by: -47 dBm >= RXLEV > MEAS_STAT_LEV_1
l:
l Level band 10 is defined by : MEAS_STAT_LEV_9 >= RXLEV >= -110 dBm
C1,C80: Indicate the number of measurement reports received for the corresponding row and column. To
save on the memory resources, these counters are in a coded format. The used coding mechanism is as
described in the CI-vector section.
l :
l Max_10 = max of (V72,V73,V80)

BS_TXPWR is the BTS transmitted power defined relatively to the maximum absolute output power of the
BTS.
BS_TXPWR is expressed in dB,
whereas BTS_MAX_OUTPUT_POWER is expressed in dBm.
The function abs( ) gives the absolute value of its argument
Remark: In order to provide correct averages, the TRE cumulates the BS_TXPWR and timing advance.
Therefore during measurement the TRE requires a 4 byte-storage for every counter. At the end of the
observation, before passing it to the BSC, the TRE determines the average value (with one decimal) and
coded it into a 1-byte_average value.

Consecutive Frame Erasure (CFE):
l MEAS_STAT_BFIi parameters define 9 intervals of cumulated numbers of consecutive speech frames
which have a Bad Frame Indicator value set to 1 (it means that the speech frame is considered as
erroneous by the BTS).
As the TC will erase speech frames for which a Bad Frame Indicator flag (BFI) has been set to the
value 1 by the BTS, a BFI is used in the RMS counters description whereas the CFE is used in the RMS
indicators defined in the RNO tool.
l Note: By default, a BFI relates to a speech frame. When considering SACCH measurement, SACCH_BFI
should be used.

The number of consecutive BFI is computed over one SACCH multiframe in the following way :
In the period of the SACCH multiframe, a counter counts the number of speech frames which are
consecutive and with BFI = 1 (it means that the speech frame is counted if its BFI = 1 and the previous
frame has also BFI = 1). The counter must hold concurrently several periods of consecutive bad speech
frames within the SACCH multiframe.
Consecutive Frame Erasure (CFE):

l MEAS_STAT_BFIi parameters define 9 intervals of cumulated numbers of consecutive speech frames
which have a Bad Frame Indicator value set to 1 (it means that the speech frame is considered as
erroneous by the BTS).
As the TC will erase speech frames for which a Bad Frame Indicator flag (BFI) has been set to the
value 1 by the BTS, a BFI is used in the RMS counters description whereas the CFE is used in the RMS
indicators defined in the RNO tool.
l Note:
By default, a BFI relates to a speech frame. When considering SACCH measurement,
SACCH_BFI should be used.
If during this SACCH multiframe, DTX is applied on the uplink path (DTX_UL =1), the counter on
consecutive BFI shall be ignored and the corresponding report shall not be taken into account in the
statistics. Otherwise, the counter of consecutive BFI is computed over 25 frames (the 24 speech frames and
the SACCH frame).

Level bands are defined as previously.

BFI band 1 is defined by :0 <= Consecutive BFI counter < MEAS_STAT_BFI_1
BFI band 2 is defined by :MEAS_STAT_BFI_1 <= Consecutive BFI counter < MEAS_STAT_BFI_2
BFI band 3 is defined by :MEAS_STAT_BFI_2 <= Consecutive BFI counter < MEAS_STAT_BFI_3
:
:
:
BFI band 10 is defined by : MEAS_STAT_BFI_9 <= Consecutive BFI counter <= 25
Max_1 = max of (V1,V2,V10)
Max_2 = max of (V11,V12,V20)
:
Max_10 = max of (V90,V91,V100)
To save on the memory resources, these counters are in a coded format. The used coding mechanism is as
described in the CI-vector section

To save on the memory resources, these counters are in a coded format. The used coding mechanism is as
described in the CI-vector section
The real number of Measurement Results in which Uplink Radio Link Counter is in S band j, is equal to:
S(S band j) x Max / 254
TPR_RADIO_LINK(j) x MAX_RADIO_LINK / 254
Recall on the Uplink Radio Link Supervision procedure:

l For each active dedicated radio channel in a cell, a counter S called Radio Link Counter is:
n decremented by 1 by the BTS each time an SACCH measurement from the mobile cannot be
decoded (SACCH_BFI=1).
n incremented by 2 by the BTS each time a valid SACCH measurement is received from the mobile
(SACCH_BFI=0).
l Initial value of S = RADIOLINK_TIMEOUT_BS (cell parameter)
n if S reaches N_BSTXPWR_M, a radio link recovery is triggered (BTS and MS power increased at
their maximum).
n if S reaches 0, a Radio Link Failure is triggered (channel drop).
l Therefore the value of S gives a measure of the quality of the radio uplink.
l RADIOLINK_TIMEOUT_BS: Counter threshold to detect a radio link failure on the uplink path.
n Min value : 1
n Max value: 128 Samfr
n Default value: 18 Samfr

S band 1 is defined by: 0 <= S < MEAS_STAT_S_1
S band 2 is defined by: MEAS_STAT_S_1 <= S < MEAS_STAT_S_2
S band 3 is defined by: MEAS_STAT_S_2 <= S < MEAS_STAT_S_3
:
:
:
S band 10 is defined by: MEAS_STAT_S_9 <= S <= 128


S: counter managed by the BTS on a per call basis
S = RADIOLINK_TIMEOUT_BS if good radio conditions
S decremented if bad radio conditions
The BSS triggers a call drop when S = 0

BS_TXPWR is the BTS transmitted power defined relatively to the maximum absolute output power of the
BTS.
BS_TXPWR is expressed in dB,
BTS_MAX_OUTPUT_POWER is expressed in dBm. It is the maximum power level at the combiner output
(given by the BTS).
RXLEV_UL and RXLEV_DL are the received signal levels by the base station and by the mobile station
respectively. They are expressed in dBm.
MS_TXPWR is the transmission power of the mobile station and expressed in dBm.
Path Balance enables to detect System or aerials problems that can induce bad coverage but not real bad
coverage problems.
RMS_PathBalance_avg=
l If more than 3dB (considering the absolute value), some problems may occur.
NOTE: Additional asymetric DL loss (external combiner) or UL gain (TMA) are not taken into account in the
computation, so they must be considered when interpreting the RMS results.

Path balance band 1 is defined by:-110 dB <= Path balance < MEAS_STAT_PATH_BALANCE_1
Path balance band 2 is defined by:MEAS_STAT_PATH_BALANCE_1 <= Path balance <
MEAS_STAT_PATH_BALANCE_2
Path balance band 3 is defined by:MEAS_STAT_PATH_BALANCE_2 <= Path balance <
MEAS_STAT_PATH_BALANCE_3
:
:
l Path balance band 10 is defined by: MEAS_STAT_PATH_BALANCE _9 <= Path balance <= 110
dB
l Max: The maximum number of measurement reports received.

l Max = max of (V1,V2,V10)
To save on the memory resources, C1,C10 counters are in a coded format. The used coding mechanism
is as described in the CI-vector section

VQ_AVERAGE:
l Average window size on measurements to obtain samples for Voice Quality statistics.
l changeable at the OMC-R on a per BSS basis
l Default value: 6 SAMFR (6 SACCH Multiframe)
AV_RXLEV_UL_VQ = (RxlevUL1++RxlevUL6) / 6
AV_RXLEV_DL_VQ = (RxlevDL1++RxlevDL6) / 6
AV_RXQUAL_UL_VQ = (RxqualUL1++RxqualUL6) / 6
AV_RXQUAL_DL_VQ = (RxqualDL1++RxqualDL4) / 6
AV_RXFER_UL_VQ = (Nb of speech frames wrongly decoded (BFI=1) / Total nb of speech frames of the
CQS)
CQS = Call Quality Sample = (VQ_AVERAGE x SAMFR)
Voice Quality statistics are only performed on traffic channels (TCH) and only related to speech calls. They
will be computed on a per TRX basis.

CQS: Call Quality Sample
VQ_RXQUAL:
l Radio quality threshold to specify bad quality samples for Voice Quality statistics.
l Default value: 4
VQ_RXLEV:
l Radio level threshold to specify bad quality samples for Voice Quality statistics.
l Default value: -95dBm

A coverage problem is observed when a significant amount of the traffic of a cell is suffering from both low
level and bad quality (RxQual).
To confirm the distribution of samples per RXLEV band, should be also considered to know the proportion
of calls which are experiencing a low signal level.
If a lot of samples of low level and bad quality are observed for only a sub-part of the TRXs (can be one
only) then a BTS hardware problem or a problem on the aerials should be suspected.
If all the TRXs are experiencing a lot of samples of low level and bad quality then a coverage problem shall
be suspected.
These RMS indicators are provided on the RNO tool per TRX, per Cell:
l Matrix
of Number of Measurement Results per DL RxQual value and per DL RxLev band
RMQLDSAM = RMS_DL_RxQuality_RxLevel_sample
l Vector
of Percentage of Samples per DL RxLev band
RMQLDLVDV = RMS_DL_RxLevel_distrib
l Vector
of Percentage of Samples per DL RxQual band
RMQLDQUDV = RMS_DL_RxQuality_distrib

The parameters VQ_RXLEV, VQ_RXQUAL, VQ_BAD_RXFER, VQ_GOOD_RXFER and VQ_RXQUAL_VS_RXFER
are changeable at the OMC-R side on a per BSS basis.
VQ_RXQUAL_VS_RXFER:
Radio quality threshold to specify a bad or a good quality CQS correlated to bad or good
FER measurements for noisy call statistics (0 to 7)
default value = 4
VQ_BAD_RXFER:
FER threshold to specify a bad FER CQS for noisy call statistics (0 to 20%)
default value = 3%
All these parameters are included in the RMS PM Type 31 result files as RMS counters:
l RMSpc = PAR_VQ_AVERAGE
l RMSpd = PAR_VQ_RXLEV
l RMSpe = PAR_VQ_RXQUAL
l RMSpf = PAR_VQ_RXQUAL_VS_RXFER
Note:The fact that FER measurements are more reliable than RXQUAL ones to assess the VQ is even more
true when using Slow Frequency Hopping. In this case, RXQUAL values are not anymore correlated to Voice
Quality as perceived by the end user.
FER measurements are available for the uplink path only.

At the end of the call (or after an intracell or intercell handover),if 100* (interfered_ul_samples /
num_ul_samples) > VQ_INTF_THRESHOLD then the counter VQ_NOISY_UL_INTERFERENCE is
incremented
VQ_INTF_THRESHOLD:
l Radio interference threshold to detect noisy calls for Voice Quality statistics
l Default value = 30%
NUM_UL_SAMPLES: total number of averages calculated on UL measurements during the call on the
considered TRX

At the end of the call (or after an intracell or intercell handover),if 100* (interfered_dl_samples /
num_dl_samples) > VQ_INTF_THRESHOLD then the counter VQ_NOISY_DL_INTERFERENCE is
incremented
VQ_INTF_THRESHOLD:
l Radio interference threshold to detect noisy calls for Voice Quality statistics

At the end of the call (or after an intracell or intercell handover), If 100*(bad_coverage_ul_samples /
num_ul_samples) > VQ_INTF_THRESHOLD
then the counter VQ_NOISY_UL_BAD_COVERAGE is incremented.

At the end of the call (or after an intracell or intercell handover), If 100*(bad_coverage_dl_samples /
num_dl_samples) > VQ_INTF_THRESHOLD
then the counter VQ_NOISY_DL_BAD_COVERAGE is incremented.

VQ_FER_THRESHOLD:
l Radio FER threshold to detect calls with bad speech quality for Voice Quality statistics.

Measurement of AMR codec usage in RMS will allow monitoring the proper operation of AMR and the
quality of the radio coverage in a cell. It also gives the possibility to tune the AMR parameters. Indeed,
statistics about frame erasure rate in uplink and comparison between codec distribution and RXLEV allow to
assess the voice quality, and adapt AMR thresholds to the situation of a given cell
AMR measurements are available only in Evolium cells.
Be careful:
Whenever, during the measurement period, the AMR parameters (codec set, thresholds, and hysteresis) are
modified, in FR or in HR, the measurement will continue with the new parameters. This will not be reported
to the operator
Reminder: AMR Principle

l TheAMR principle is to have a set of speech codecs and, for any radio conditions, to use the one with
the best speech quality.
l Undergood radio conditions, a codec with a high bit-rate is used. Speech is encoded with more
information so the quality is better. In the channel coding, only little place is left for redundancy
l Underpoor radio conditions, a codec with a low bit-rate is chosen. Speech is encoded with less
information, but this information can be well protected due to redundancy in the channel coding.
l TheBSS adapts dynamically the codec in uplink direction and in downlink direction, taking into account
the C/I measured by the BTS (for uplink adaptation) and by the MS (for downlink adaptation).
l The codec used in uplink and used in downlink can be different: the adaptation is independent in each
direction

Results are provided at TRX level, as TRXs are not homogeneous within one cell : in terms of transmit
power (concentric cells), frequency bands (multiband cells), frequency planning (NH/FH), interference
(BCCH, TCH).

At the end of the measurement period (i.e. before uploading the results to the BSC), the TRE calculates the
usage of each codec as follows:
Where:
l Nk represents the total number of bad speech frames counted in a TRX for a given AMR codec
l row_max represents the maximum value of all Nk
l Ci = 0 indicates that number of measurements = 0
l Ck = 254 (FE) means that number of measurements = row_max
l Ck = 255 is reserved for overflow
AMR_FR_UL_BAD= RMS44a that has 8 cells (1 for each FR codec) with the relative number of bad
speech frames received in uplink.
MAX_AMR_FR_UL_BAD= RMS44b that indicates the maximum number of bad speech frames received
in uplink in one FR codec.

AMR_HR_UL_BAD= RMS45a that has 5 cells (1 for each HR codec) with the relative number of bad
speech frames received in uplink.
MAX_AMR_HR_UL_BAD= RMS45b that indicates the maximum number of bad speech frames received
in uplink in one HR codec.

X = DL ou UL
RXLEV XL bands are defined as follows:
l Level B1 is defined by: -47 dBm >= RXLEV > MEAS_STAT_LEV_1
l Level B2 is defined by: MEAS_STAT_LEV_1 >= RXLEV > MEAS_STAT_LEV_2
l
l Level B10 is defined by:MEAS_STAT_LEV_9 >= RXLEV >= -110 dBm
The number of frames using one specific AMR codec mode is computed over one SACCH multiframe in the
following way
l Inthe period of the SACCH multiframe, the TRE counts for each AMR call and for each AMR FR codec
the number of correct speech frames received from the MS in uplink, N1 to N8.
l At
reception of the measurement report of a given MS, the results are gathered in the line of the
matrix corresponding to reported XL RXLEV.
l Atthe end of the measurement period (i.e. before uploading the results to the BSC), the TRE
calculates the usage of each codec as follows :
Where:
l Nik represents the total number of speech frames counted in a TRX for AMR codec k, and RXLEV band
i
l row_maxi represents the maximum value of all Nik for line i
l Cik = 254 (FE) means that number of measurements = row_maxi

X = UL ou DL
RXLEV XL bands are defined as follows:
l Level B1 is defined by: -47 dBm >= RXLEV > MEAS_STAT_LEV_1
l Level B2 is defined by: MEAS_STAT_LEV_1 >= RXLEV > MEAS_STAT_LEV_2
l
l Level B10 is defined by:MEAS_STAT_LEV_9 >= RXLEV >= -110 dBm
The number of frames using one specific AMR codec mode is computed over one SACCH multiframe in the
following way
l Inthe period of the SACCH multiframe, the TRE counts for each AMR call and for each AMR HR codec
the number of correct speech frames received from the MS in uplink, N1 to N8.
l At
reception of the measurement report of a given MS, the results are gathered in the line of the
matrix corresponding to reported XL RXLEV.
l Atthe end of the measurement period (i.e. before uploading the results to the BSC), the TRE
calculates the usage of each codec as follows :
Where:
l Nik represents the total number of speech frames counted in a TRX for AMR codec k, and RXLEV band
i
l row_maxi represents the maximum value of all Nik for line i
l Cik = 254 (FE) means that number of measurements = row_maxi

In B8, two counters only are defined for Timing Advance (TA):
l PERC_TA_GT_TA_STAT
l MAX_TA
PERC_TA_GT_TA_STAT:
Percentage of measurement results reported with a TA value higher then the TA_STAT parameter.
MAX_TA:
Maximum value of TA among all TA values reported in the measurement results used for RMS.
The aim of this feature is to provide statistics information on TA, in order to understand geographical traffic
distribution in a cell and to identify resurgences and hot spots.
B8 RMS statistics are still available in B9.
Statistics on timing advance are available only in Evolium cells.

TA Band B1 is defined by: 0 <= TA < Meas_STAT_TA_1
TA Band B2 is defined by: MEAS_STAT_TA_1 <= TA < MEAS_STAT_TA_2
TA Band B10 is defined by: MEAS_STAT_TA_9 <= TA < 63
The TRE counts for each TA band the number of measurement results, N1 to N10. To save on the memory
resources, these counters are sent to the BSC in a coded format.
At the end of counting period, the coded values are computed as follow:
Where:
l Nk represents the real number of measurements
l row_max represents the maximum value of all Ni
l Ck = 0 indicates that number of measurements = 0
l Ck = 254 (FE) means that number of measurements = row_max
l Ck = 255 is reserved for overflow

Document History


Page
1 RMS activation 7
2 Global analysis of the RMS results 9
3 Detailed analysis of the worst cell 18
4 Detection of coverage problems using RMS 32
5 Analysis of coverage problems using RMS 41
6 Detection of interference problems using RMS 51
7 Analysis of interference problems using RMS 60

Page

Template 1 (with default values) should be used at the first analysis.

In this table, the figures in gray are not valid and the figures in red are the most important ones

From Alc_warning_top_worst_rms_radio_link, the worst cells can be filtered by:
l Average RxLevel (UL/DL)
l Average RxQuality (UL/DL)
l Average Power (UL/DL)
l Average PathBalance
l Average Uplink RadioLinkCounter
l Average Timing Advance
l Average Uplink Consecutive Frame Erasure
From Alc_warning_top_worst_rms_ul/dl_voice_quality, the worst cells can be detected by:
l Split of uplink/downlink noisy calls causes
l Bad Coverage
l Interference
l Undefined

It is also important that these figures are based on sufficient calls, so as to give reliable statistics. In the case
of the three cells above, each of them had more than 5000 calls during the RMS job. It is seen as quite
sufficient to get reliable results.

Others cells could be found, for example if main criteria was Consecutive Frame Erasure:
For example, cell CI 13647 shows the highest average CFE (0.42) but calls do not suffer from bad RxQuality:
they suffer only from bad frame Erasure Rate. Thats why, for this cell, UL noisy call rate is low (below 5 %)
but calls suffering from abnormal bad FER (bad FER while RxQual is fair) are a lot: more than half of the calls
(exactly 54 %) suffer from bad FER. It is not quite clear in which radio conditions such results can be found,
and it probably indicates a TRX failure.
Correlate with main QoS:

l In terms of call drop rate, cells 11075 and 12175 are respectively ranked as the second and the fourth
worst cell in the BSC (with call drop rate equal to respectively 3.48% and 2.95%, with a large part due to
radio problems)
l In terms of call setup success rate, cells 11075 and 12175 are respectively ranked as the second and the
eighth worst cell in the BSC (with a call setup success rate equal to respectively 95.24% and 96.11%).
l In terms of incoming HO unsuccess rate, cell 11075 is ranked as the seventh worst cell (with the highest
incoming handover failure rate, equal to 7.72%).
l In terms of outgoing HO unsuccess rate, these cells are not seen in the 10 worst cells. This can be seen
as normal as radio problems in one cell do not really impact its outgoing HO success rate.
So, it seems more valuable to investigate RMS on the cell 11075, so as to try to improve not only the radio
link quality in this cell but also the quality of service provided to subscribers (another important criteria to take
into account would also be the amount of traffic in this cell compared to the total traffic in the BSC, but this
was not done in this example).

At this level, it can be interesting to look at the power control behavior, to check if it does not reduce too
much MS power, leading to this quality problems at low received levels on the uplink path.
For this to be possible, it is interesting to look at the Average MS power according to UL RxLevel graph and
the Average MS power according to UL RxQuality grap

Upper and lower thresholds are high (upper at 80 dBm and lower at 90 dBm).
POW_INC_FACTOR and POW_RED_FACTOR (Power increase and reduction factor) have default tuning (0.8
for the increase, 0.5 for the reduction).
POW_INC_STEP_SIZE and POW_RED_STEP_SIZE (Power increase and reduction step size in case of only
quality problems) are equal respectively to 6 dB and 2 dB.
One could imagine to make the power control more reactive while putting POW_INC_FACTOR to 1.0, so that
the MS power is quicker increase when quality and level problems occur.
However, power control fine tuning does not seem to be the sufficient solution for this problem. The good
solution would be to identify the coverage hole where UL interference occur (one could for example, imagine
a high building where indoor is not well covered and interfered by many cells at high floors).

The C/I overlap correspond to the average C/I computed from C/I distribution. It is called overlap because
more than interference, it shows the overlap between cells, that may or cannot interfere (for example, co-
located 900 and 1800 cells will have a very low C/I but it does not mean they interfere each other, it only
means that they have a strong overlap between them).

The C/I overlap correspond to the average C/I computed from C/I distribution. It is called overlap because
more than interference, it shows the overlap between cells, that may or cannot interfere (for example, co-
located 900 and 1800 cells will have a very low C/I but it does not mean they interfere each other, it only
means that they have a strong overlap between them).

The case of good low RxLevel and bad RxQuality is identified as being interference problems

In theses graphs the cells are sorted according to the lowest Rxlevel, worst RxQuality and highest Timing
advance.

On the contrary, Welgedacht_2 has the lowest average UL received level (-87.12 dBm) and the highest
average Timing advance (3.32). But it does no show bad RxQual, neither in UL path, nor in DL path. So,
even if this cell has a wide coverage, there is no reason why coverage should be improved

On the downlink path, it can be seen that no cells present a majority of noisy calls due to bad coverage: for
all the cells with highest DL noisy call rate, DL noisy calls come mainly from interference problems.
However, if the cells are sorted according to the highest DL noisy call rate due to bad coverage, it can be
seen that Parrow_North_3 is in good position: 3.81% of the calls in this cell are noisy calls due to bad
coverage on the downlink path.
The fact that the bad coverage issue can be detected both on the UL and DL path makes clear that the
problem should come from a coverage hole in the service area or at the edge of the cell.
Otherwise (if the detection can be done only in UL or DL path), the bad coverage issue could also be linked
due to path balance problems

The analysis of coverage hole can thus follow two axis: one concerning the coverage hole at the border
of the cell and another concerning the coverage hole within the service area of the cell.

Another way to detect an interfered frequency on one cell is to study the RMS statistics (especially RxQual
statistics) on a per TRX basis, considering that each TRX corresponds to one particular frequency.
However, such method has the drawback to require the disabling of all the hopping modes (Base band
Hopping, Radio Hopping) , in order to see which frequency is the cause of interference.
After, there should the frequencies that are causing the problem should be changed. In order to find new
frequencies, it is possible to declare extra-frequencies to be monitored by the MS when it is in dedicated
mode. The selected method is the application of the Extended Measurement Reporting (GSM feature MAFA).

Document History


Page
1 GSM BSS protocol stacks 7

2 A User Plan over IP 18
3 Directed Retry indicators 43
4 Counters on Electromagnetic Emission (EME) 67

Page

The main protocols involved on the signaling plane or Control plane:
RSL: the protocol used for call control and BTS measurements between BSC and BTS, is RSL/LAPD/UDP/IP
l- RSL-I (acknowledged) is used to carry the call signalling
l- RSL-UI (unacknowledged) is used to carry the HO measurements
IP_BSSAsig Protocol: The protocol used for call control between the BSC and core network is:
SCCP/MTP3/M3UA/SCTP/IP
IPGCH-c Protocol: this is the protocol used to handle control messages between BTS and MFS; it is based
on TCP/IP
IPGSL: Between BSC and MFS, for BSCGP. The stack is BSCGP/TCP/IP

On the user plane:
l IPTCHis the GSM protocol for CS voice traffic. In case of Full IP over Ethernet BSS; it is used between
BTS and BSC. The stack is TRAUP/MUXTRAUP/UDP/IP
l For
PS, IPGCH provides a reliable transmission between BTS and MFS, the IPGCH user plane; IPGCHU
conveys the UL/DL LLC PDUs, it is supported by an UDP/IP stack.
We will have more details about IPTCH and IPGCH in the next slides.

In B11, Alcatel-Lucent introduced the A signaling over IP . It is required to ease the connection of the
BSS to the NGN core network that already supports IP transport between its elements;
we would like to remind you here the NGN core network elements: MSC server and Media gateways. The
MSC server mainly comprises the call control (CC) and mobility control parts of a MSC. On the other hand
the MGW terminates bearer channels (that is; A trunk or IP packet) from a switched circuit network.
For Legacy AUPoTDM Network, the Architecture is as described here: The SS7 protocol is carried over IP
network (SIGTRAN protocol)*, The User plane is still carried over TDM*. And the Speech and CS data are
transcoded in the TC equipment

We have seen that before B12 the A-Signaling over IP feature already splits UP and CP on the A
Interface and allows to manage A signaling over IP, the User plane being still carried over TDM.
In B12, The A-Interface over IP feature completes the picture and allows to manage the A User plane
over IP.
Please note that To have already activated the A interface control plane over IP feature is a prerequisite to
have the A interface User plane over IP feature

The Expected benefits for Alcatel-Lucents customers are:
lA better OPEX: lower transmissions cost, higher bandwidth efficiency, easier network configuration,
including A-Flex.
lA better CAPEX: with a TC-less BSS the number of TCs is expected to globally decrease. Additionally
remaining TCs will be concentrated in the Core Network (MGWs).
l Anincreased flexibility towards vendors; as far as the Core Network is concerned CP and UP nodes can
be bought from different vendors.
l Anincreased speech quality due to both the possibility to use the TrFO feature and speech delay
reduction.

With the mixed IP/TDM A interface architecture:
l The TC rack is present in the BSS.
l Support of AUPoIP with Transcoding in MGW and/or in TC rack:
l For AUPoIP, the transcoding is only in the MGW, if needed, TrFO may lead to no transcoding.
l For AUPoTDM, the transcoding is in the TC.

With the full AUPoIP architecture the UP is fully carried over IP. Additionally instead of being performed in
the BSS transcoding is performed by the MGW if needed therefore TCs are removed from the BSS
l Notethat there is No restriction on compatibility between BSS transport mode (TDM or IP) and A User
plane interface (over IP).
l Note also that the AUPoIP with Transcoding in BSS (G711 on IP) is not supported.

For AUPoIP Transport User plane is based upon the use of an RTP/UDP/IP
The Physical Layer is Ethernet *
The IP version is IPv4*
The User Datagram Protocol UDP provides a simple, connectionless, unreliable datagram delivery
service. The service is similar to the service that is provided by IP, although UDP has port addresses to
support multiplexing between different applications. When an application wants to exchange data with
another one, no connection is establishes, the data are just sent. *
UDP is used when an application does not need a reliable transfer mechanism or if the application needs to
avoid the additional overhead of TCP.
The RTP protocol is used To compensate the unreliability of UDP while keeping its fastness, remember
that with RTP a Sequence number added in packets allowing the receiver: to reorder packets in correct
order*
The RTP protocol is by default managed in non-multiplexed RTP mode (one UDP port / call); in RTP
multiplexed mode a single UDP port manages several calls
Finally, RTCP provides out-of-band statistics and control information for an RTP flow.*
Please note that This stack is independent from the session control protocol used in the Core Network

TPGSM board with a TPIP daughter board supports the Full AUPoIP and the mixed IP/TDM A interface
architecture.
This TPIP board performs the MUXTRAUP and MUXRTP mediation between MGW and BTS and the
MUXTRAUP forwarding between the BTS and the TC G2.5

When A user plane over IP is used the CIC has no more meaning. For AUoTDM the CIC allocated by the
MSC to a given call defines the user path of that call and its identification in each NE.
But for AUPoIP, the 3GPP has decided to dissociate the user path definition from the call identification:
l TheA user path will be defined with the corresponding IP address and UDP port of the terminating
points of the call segment in each entity, so-called AoIP Transport Layer Address.
l The call identification will be a random number allocated by the MSC, so-called Call Identifier.
The A user plane type choice (over IP or over TDM) and the call identification (CIC vs AoIP Transport
Layer Address and Call Identifier) shall take place at the very beginning of any call segment (Call Setup,
Handover).

The Codec Type and A user plane type choice and the call identification shall take place at the very
beginning of any call setup and Handover. This is done by adding new information elements to the
messages related to the assignment and handover procedure
Here we have a call setup with the feature AUoIP activated.
In the ASSIGNMENT REQUEST * The Codec List includes all the codecs currently supported by the MS and
preferred by the MSC. Codec preference (top of the list) goes to the ones that may enable TrFO or TFO.
CIC and/or AOIP transport Layer address (MGW) may be given depending on the proposed A-interface
types for the preferred codec.
The BSC preferentially accepts the preferred codec proposed by the MSC. However the BSC may allocate
HR channels instead of FR channels because the load of the cell is increasing.
If both interfaces (TDM and IP) are proposed for the chosen codec, IP interface is chosen.
ASSIGNMENT COMPLETE * message includes the identity of the local IP endpoint included in the AoIP
Transport Layer Address allocated by the BSS.
Please Note that an External Handover follows the same principle : new info about the IP transport is
included in HO REQUIRED, HO REQUEST and HO REQUEST ACK.

It may happen that the Codec Type supported in the target cell differs from the one used in the serving
cell, possibly leading to a change of the A user interface type, or (even if AUPoIP is still on going) to a
change of the IP address or UDP port in the BSS or in the MSC/MGW. Thus, it is necessary to inform the
MSC of such a change and to re-negotiate the new A user plane type characteristics.
For doing so, the 3GPP has defined a new procedure, so-called BSS Internal handover with MSC support
and executed thanks to three new messages: INTERNAL HANDOVER REQUIRED *, INTERNAL HANDOVER
COMMAND*, INTERNAL HANDOVER REQUIRED REJECT*
The AoIP Transport Layer Address, the call identifier, the Codec list are exchanged between the BSC and
MSC server

To ensure that the best fit of dedicated resources (that is; Codec Type, Codec Configuration and Interface
Type) are allocated to the ongoing call, The MSC may also trigger the BSS Internal Handover procedure
The message Internal Handover Enquiry* is sent by the MSC to BSC; its goal is to get back the updated
BSS Codec capabilities to handle a specific call and no specific target cell is indicated in the message (the
primary goal is to change the Codec, not necessarily the cell, and typically an intra-cell handover would be
finally triggered in this case). The resource preferred by the MSC is given in "Speech Codec (MSC chosen)"
parameter.
Then the BSC triggers an "BSS internal handover with MSC support" or may respond with an HANDOVER
FAILURE message with cause value "INTERNAL HANDOVER ENQUIRY reject

Some other telecoms procedures are also impacted when the IP transport mode is used on the A interface:
AMR*:
l AMR codec adaptation (codec mode change) is performed in-band for AUPoIP in the same manner
than for AUPoTDM (Codec Mode Indication/Codec Mode Request)
DTX*:
l DTXDL related control bits becomes useless with AUPoIP as the decision to activate DTX DL does not
come anymore from the BSS but from the Core Network.
TFO*:
l If
the IP Transport mode is used TFO is not relevant anymore. TrFO should be used instead by the
MSC

The parameters introduced by AUPoIP:
l EN_AUP_OVER_IP: Enables/disables the support of "A user plane over IP" in "Full AUPoIP"
architecture, or in "Mixed IP/TDM A interface" architecture.
l EN_INT_HO_INITIATED_BY_MSC: Enables/disables the processing of the internal handover initiated
by the MSC
l AUP_OVER_TDM_CODEC_SUP: Bitmap (8 bits) defining the codec types supported for the A Interface
user plane over TDM
l AUP_OVER_IP_CODEC_SUP: Bitmap (8 bits) defining the codec types supported for the A Interface
user plane over IP
The list of parameters provided here is not exhaustive, please check the BSS Telecom Parameters
Catalogue for all new or modified parameter introduced by AUPoIP

These counters to trace the number of "BSS internal handover with MSC support" procedure triggered by
the BSC and the number of attempt and success are introduced.

The queuing of TCH requests is also performed for incoming external TCH handovers but not for incoming
internal TCH handovers.
T11 : BSC parameter, Maximum queuing time for Assignment Requests (values : 0 to 19 s; default 6s)

If the BSC has enough queuing buffers to queue the request or there is a lower priority request that can be
dequeued, BSC puts the request in a queue and starts the queuing timer T11.
l Thischart describes the case where the congestion situation ends as a result of a TCH being made
available on the serving BTS. Note that the congestion situation can also be handled by the Directed
retry procedure, in which case the MS is handed over to a Point-to-Point TCH located on another BTS,
see next slides.
l If
the queuing is not allowed by the MSC, but QUEUE_ANYWAY = TRUE, no QUEUING INDICATION
message is sent to the MSC
l ATER CONN REQ procedure is done only for TDM BTS in case of BSS transport mode = IP.
MC13a - NB_TCH_NOR_ASS_QUEUED
Further to the receipt of a 48.008 ASSIGNMENT REQUEST message for TCH, the counter is incremented:
i) upon the sending of a 48.008 QUEUING INDICATION message if the queuing is authorised by the MSC,
or,
ii) when the assignment request is queued in the cell if the queuing is not authorised by the MSC and the
parameter QUEUE_ANYWAY is set (in particular when the assignment request is queued due to a forced
directed retry (cause 20) or preferred band forced directed retry (cause 36)), or,
iii) when the assignment request is queued in the cell if the queuing is not authorised by the MSC and the
request has its pre-emption indicator set (provided that the flag EN_TCH_PREEMPT is set to 'Enable').
Note 1: MC13a = C13a
Note 2: The HMI name of the parameter QUEUE_ANYWAY is "FORCED_QUEUING".

There is no Intracell Directed Retry contrary to HO:
An Intracell Directed is a Call Setup!)
Please refer to Annexes for Directed Retry counters details.
A TCH is never allocated in VAMOS mode on a directed retry

The following DR counters are provided in Type 110
l for the target cell:
n MC13A: TCH requests for Normal Assignment that are put into the queue,
n MC153: incoming internal DR requests,
n MC15A: TCH allocations for incoming internal DR,
n MC151: incoming internal DR successes per cell,
n MC717A: incoming internal DR successes per TRX.
l for the serving cell:
n MC144E: outgoing internal DR requests,
n MC142E: outgoing internal DR successes,
n MC607: outgoing internal+external DR attempts.
l The following DR counters are provided in Type 29 (this type becomes a standard type in B8)
l for the target cell:
n C153: incoming internal DR requests,
n C154: incoming internal DR attempts,
n C151: incoming internal DR successes.
l for the serving cell:
n C144A: forced outgoing internal DR requests,
n C144C: normal outgoing internal DR requests,
n C145A: forced outgoing internal DR attempts,
n C145C: normal outgoing internal DR attempts,
n C142A: forced outgoing internal DR successes,
n C142C: normal outgoing internal DR successes.
All the counters here and in the next slides concerning directed retry and relative to type 29 can be activated for all
cells of the BSC at once from B8. (Type 29 becomes a standard type in B8):
C142a, C142b, C142c, C142d, C143a, C143b, C143c, C143d, C143e, C143f, C143g, C143h, C144a, C144b,
C144c, C144d, C145a, C145b, C145c, C145d, C151, C152,C153, C154, C555

C155 is available in Type 29.

All incoming internal DR failures due to radio problems are counted in the same counter C152.
This counter is provided in Type 29
Both radio failures with Reversion Old SDCCH Channel and radio drop are counted together.

All MCxxx counters are available in Type 110.
All Cxxx counters are available in Type 29.
Type 29 counter becomes a standard in B8.

Refer to BSS - DEFINITION OF QUALITY OF SERVICE INDICATORS
l Specific indicators for densification techniques > Directed Retry > Incoming DR
n DRIBCAR: efficiency of the incoming internal DR preparation = MC15A/MC153
n DRIBCNR: rate of incoming internal DR failures due to congestion = MC155/MC153
n DRIBEFR: efficiency of the incoming internal DR execution = MC717A/MC153
l Other indicators can be computed:

from Type 110 counters:
n DRIBSUR: global efficiency of incoming internal DR
= MC717A/MC153 = MC151/MC153
from Type 29 counters
n rate of incoming internal DR preparation failures due to BSS problems
= (C153-C154-C155)/C153
n rate of incoming internal DR execution failures due to BSS problems
= (C154-C151-C152)/C154
n rate of incoming internal DR execution failures due to radio access problems
= C152/C154

Counters C144A, C143B, C144C, C143F are type 29.

l Specific indicators for densification techniques > Directed Retry > Outgoing DR
n DROBSUR: global efficiency of outgoing internal DR = MC142E/MC144E
l Other indicators can be computed

n efficiency of the outgoing internal DR preparation
= (C145A+C145C)/(C144A+C144C)
n efficiency of the outgoing internal DR execution
= (C142A+C142C)/(C145A+C145C)
n rate of outgoing internal DR execution failures due to BSS problems
= [(C145A+C145C) - (C143A+C143E+C143B+C143F)] / (C145A+C145C)
n rate of outgoing internal DR execution failures due to radio problems with reversion old channel
= (C143A+C143E) / (C145A+C145C)
n rate of outgoing internal DR execution failures due to radio problems with drop
= (C143B+C143F) / (C145A+C145C)
type 29 counters are defined:

DRFOSUIN C142a NB_OUT_FORCED_IDR_SUCC
DRFOSUEN C142b NB_OUT_FORCED_EDR_SUCC
DROBSUIN C142c NB_OUT_NOR_IDR_SUCC
DROMSUEN C142d NB_OUT_NOR_EDR_SUCC
DRFORDIN C144a NB_OUT_FORCED_IDR_REQ
DRFORDEN C144b NB_OUT_FORCED_EDR_REQ
DROBRDIN C144c NB_OUT_NOR_IDR_REQ
DROMRDEN C144d NB_OUT_NOR_EDR_REQ
DROBRQIN C145c NB_OUT_NOR_IDR_ATPT
DROMRQEN C145d NB_OUT_NOR_EDR_ATPT

The following DR counters are provided in Type 110 for the serving cell:
l MC144F: outgoing external DR requests,
l MC142F: outgoing external DR successes.
The following DR counters are provided in Type 29 for the serving cell:
l C144B: forced outgoing external DR requests,
l C144D: normal outgoing external DR requests,
l C145B: forced outgoing external DR attempts,
l C145D: normal outgoing external DR attempts,
l C142B: forced outgoing external DR successes,
l C142D: normal outgoing external DR successes.
As for internal DR, external DR Counters are available permanently
No counter is provided for the target cell for an external DR since an incoming DR cannot always be
discriminated from an incoming external HO. Therefore incoming external DRs are counted together with
incoming external HOs in the related counters.

l Specific indicators for densification techniques > Directed Retry > Outgoing DR
n DROMSUR: global efficiency of outgoing external DR = MC142F/MC144F
l Other indicators can be computed

n efficiency of the outgoing internal DR preparation
= (C145B+C145D)/(C144B+C144D)
n efficiency of the outgoing internal DR execution
= (C142B+C142D)/(C145B+C145D)
n rate of outgoing internal DR execution failures due to BSS problems
= [(C145B+C145D) - (C143C+C143G+C143D+C143H)] / (C145B+C145D)
n rate of outgoing internal DR execution failures due to radio problems with reversion old
channel
= (C143C+C143G) / (C145B+C145D)
n rate of outgoing internal DR execution failures due to radio problems with drop
= (C143D+C143H) / (C145B+C145D)
l Interesting indicator:
n TCQUSUDSR: rate of outgoing internal and external directed retries (forced + normal)
successfully performed over all RTCH requests queued during normal assignment.

Rejected: A queued request is rejected because another request is placed in the queue, with a higher
priority.
Timeout: The queued request stayed T11 in the queue and is then removed.

There is also an indicator (not in this graph) that counts only the number of FDR attempts (DR_forced,
GDRFORQN = MC607)
This indicator can be compared to MC144e/f in order to know the ratio FDR vs. normal DR.

Measurements:
l Only with Evolium BTS
l DLpower data are collected by each TRE for each band (2 considered bands: 850/900 and
1800/1900)
l Recording of power effectively transmitted to the antenna in Watt
l Power control, DTX and unused TS are taken into account
l Lossdue to stages (Any, AN) and cables between TRE output and BTS antenna output connector
taken into account
l Measurements averaged every hour per cell and per frequency band
2 new cell parameters: threshold values

l EME_PWR_MAX_GSM (frequency band 850/900)
l EME_PWR_MAX_DCS (frequency band 1800/1900)
Possible massively updated through an OMC Java script

All Rights Reserved Alcatel-Lucent 2013
All rights reserved Alcatel-Lucent
Passing on and copying of this document, use and communication of its
contents not permitted without written authorization from Alcatel-Lucent
All Rights Reserved Alcatel-Lucent 2013

TMO18096 - V2 SG B12 Ed1 - CE PDF

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

TMO18096 - V2 SG B12 Ed1 - CE PDF

Hochgeladen von

Copyright:

Verfügbare Formate

Passing on and copying of this document, use and communication of its

contents not permitted without written authorization from Alcatel-Lucent

Copyright 2013 Alcatel-Lucent. All Rights Reserved.

PERMISSION TO USE CONTENT

COPYRIGHTS AND TRADEMARKS

Copyright 2013 Alcatel-Lucent. All Rights Reserved.

1. GSM QoS Monitoring

Copyright 2013 Alcatel-Lucent. All Rights Reserved.

Upon completion of this course, you should be able to:

Your feedback is appreciated!

Please include the following training reference in your email:

Copyright 2013 Alcatel-Lucent. All Rights Reserved.

Edition Date Author Remarks

01 YYYY-MM-DD Last name, first name First edition

Copyright 2013 Alcatel-Lucent. All Rights Reserved.

Copyright 2013 Alcatel-Lucent. All Rights Reserved.

1 Monitoring the QoS of the BSS 7

Copyright 2013 Alcatel-Lucent. All Rights Reserved.

Copyright 2013 Alcatel-Lucent. All Rights Reserved.

NPO product reference is now 9959, instead of 9159

Copyright 2013 Alcatel-Lucent. All Rights Reserved.

Copyright 2013 Alcatel-Lucent. All Rights Reserved.

Copyright 2013 Alcatel-Lucent. All Rights Reserved.

Edition Date Author Remarks

01 YYYY-MM-DD Last name, first name First edition

Copyright 2013 Alcatel-Lucent. All Rights Reserved.

Copyright 2013 Alcatel-Lucent. All Rights Reserved.

Copyright 2013 Alcatel-Lucent. All Rights Reserved.

Copyright 2013 Alcatel-Lucent. All Rights Reserved.

l 15 cells per BSS for PM types 10, 12, 13, 14, 15

l 1 cell per BSS for PM types 11, 27

Counter numbering rules:

l Xy.z: cumulative counters in PM type 8 (X stands for X25 link)

l Ny.z: cumulative counters in PM type 9 (N stands for N7 link)

l Syz: observation counters in PM type 10 (S stands for SDCCH)

l Ryz:: observation counters in PM type 11 (R stands for Radio measurements)

l Tyz: observation counters in PM type 15 (T stands for TCH)

l MCyz or MNy.z: cumulative counters in PM type 110 (M stands for Major)

In the B12 release, a new PM type 37 is created for VAMOS.

Copyright 2013 Alcatel-Lucent. All Rights Reserved.

The Resource occupancy section includes indicators for:

Copyright 2013 Alcatel-Lucent. All Rights Reserved.

The Traffic model section includes indicators for:

The Resource occupancy section includes indicators for:

Copyright 2013 Alcatel-Lucent. All Rights Reserved.

Copyright 2013 Alcatel-Lucent. All Rights Reserved.

Copyright 2013 Alcatel-Lucent. All Rights Reserved.

Edition Date Author Remarks

01 YYYY-MM-DD Last name, first name First edition

Copyright 2013 Alcatel-Lucent. All Rights Reserved.

Copyright 2013 Alcatel-Lucent. All Rights Reserved.

1 Call setup principles 7

Copyright 2013 Alcatel-Lucent. All Rights Reserved.

Copyright 2013 Alcatel-Lucent. All Rights Reserved.

Copyright 2013 Alcatel-Lucent. All Rights Reserved.

Copyright 2013 Alcatel-Lucent. All Rights Reserved.

When the number of PAGING messages queued in the BSC equals

Copyright 2013 Alcatel-Lucent. All Rights Reserved.

Copyright 2013 Alcatel-Lucent. All Rights Reserved.

Copyright 2013 Alcatel-Lucent. All Rights Reserved.

Copyright 2013 Alcatel-Lucent. All Rights Reserved.

CR: Complete L3 Info

Copyright 2013 Alcatel-Lucent. All Rights Reserved.