B10QoS

Section 1 Module 1 Page 1

All Rights Reserved Alcatel-Lucent 20083JK11043AAAAWBZZA Issue 01

Do not delete this graphic elements in here:

11All Rights Reserved Alcatel-Lucent 2008

Module 1Introduction

3JK11043AAAAWBZZA Issue 01

Section 1GSM QoS Monitoring

EVOLIUM Base Station SubsystemIntroduction to Quality of Service and Traffic Load Monitoring - B10

3FL10491ADAAZZZZA Issue 01



All Rights Reserved Alcatel-Lucent 2008

EVOLIUM Base Station Subsystem Introduction to Quality of Service and Traffic Load Monitoring - B10GSM QoS Monitoring Introduction1 1 2

Blank Page

This page is left blank intentionally

First editionLast name, first nameYYYY-MM-DD01

RemarksAuthorDateEdition

Document History





Module Objectives

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

Explain what is QoS and Traffic Load monitoring of the BSS Explain what are the information sources available for that purpose





Module Objectives [cont.]






Table of Contents

Switch to notes view! Page

1 Monitoring the QoS of the BSS 72 Monitoring the Traffic Load of the BSS 103 Information Sources Available 124 Introduction to K1205 PC Emulation 28





Table of Contents [cont.]

Switch to notes view!






1 Monitoring the QoS of the BSS






Definition

l "Monitor" "network" "quality" monitor = measure or ensure? network = BSS? BSS+NSS? BSS+NSS+PSTN quality = service (end-user) and/or system (technical)

l But also detect, localize, diagnose outages detect (decide according to thresholds) localize (which cell, BSC, etc.) diagnose: radio, BSS, TC problems






Usage

QoS ResultsQoS Results

Management network monitoring comparison with competitor comparison of manufacturers contractual requirement: licence quality responsible

Management network monitoring comparison with competitor comparison of manufacturers contractual requirement: licence quality responsible

Radio optimization cell radio quality survey HO quality monitoring assessment of tuning efficiency

Radio optimization cell radio quality survey HO quality monitoring assessment of tuning efficiency

BSS maintenance cell/BSC/TC problem detection

BSS maintenance cell/BSC/TC problem detection

3 usages of QoS data 3 levels of QoS reports: 1. Management team: has to compare Network QoS with competitors' one and to plan Network evolutions.

needs to have a general view of the Network QoS on a monthly (and sometimes weekly) basis.2. Radio Optimization team: has to detect bad QoS areas in the network and to implement and assess

modifications for QoS improvement.

needs to have a detailed status and evolution of the QoS at BSS and cell (and sometimes TRX) levels ona weekly, daily (and sometimes hourly) basis.

3. Supervision and Maintenance team: has to detect dramatic QoS degradations and identify the responsible Network Element (and if possible component).

needs to have the most detailed status of QoS at cell and TRX levels on an hourly basis.





2 Monitoring the Traffic Load of the BSS





2 Monitoring the Traffic Load of the BSS

Definition

l Measure the "quantity" of traffic handled by: the network the BSCs the cells

l Analyze traffic characteristics call, handover, location update, etc.

l As input for dimensioning/architecture team





3 Information Sources Available






Observation Means

l DIFFERENT WAYS TO OBSERVE/MEASURE the GSM network

External Interface AnalysisA interface: MSC/TC-BSCAbis interface: BSC/BTSAir MS/BTS

Counter browser

OMC CountersBSC(NSS)

Tektronix K1205

Gnnettest MPAW&G NPA

QoS data can be built up from different and complementary kinds of information sources.

Usually post-processing applications will build up QoS indicators from:

l OMC-R counters provided by the BSS system itself.

l Signaling messages provided by a protocol acquisition tool on the different interfaces handled by the BSS: Air, Abis, A (or Ater).






A Interface Trace

l INFORMATION SOURCE: EXTERNAL INTERFACE "A"l Capture/decode signaling between MSC and BSC-TC (A or Ater MUX)

with "protocol analyzer" (Wandel, Tektronix, Gnnettest, etc.)+ GSM standard, can be used for arbitrage between manufacturers+ Complete information (message contents, time-stamp)+ Possible detection of User/MS/BSS/TC/NSS problems

- High cost of equipment- Time consuming, "post mortem" (installation of tool, file analysis)- Expertise needed for analysis- Low coverage (K1103/MA10: 8 COCs, K1205/MPA: 32 COCs maximum!) - Large amount of data (>> 10 Mbytes /hour/BSC)

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 FailureIMSI Unknown in HLR Resource UnavailableIMEI Not Accepted Switching Equipment CongestionPLMN Not Allowed Normal UnspecifiedService Option Not Supported Recovery on Timer ExpiryRequested Service Not Supported Call Reject Unassigned Number InterworkingOperator Determined Barring Protocol ErrorUser Alerting Network FailureFacility Not Subscribed CongestionNo Route to DestinationNormal Call ClearingUser BusyInvalid Number FormatCall RejectInterworkingNormal 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.






Example of Trace

l On a K1205 protocol analyzer






Abis Interface Trace

l INFORMATION SOURCE: EXTERNAL INTERFACE "Abis"l Capture/decode signaling between BSC and BTS with "protocol

analyzer" (Wandel, Tektronix, Gnnettest, etc.)+ Complete information (message contents, time-stamp)+ Possible detection of User/MS/BSS/TC/NSS problems+ Complete radio information thanks to measurement messages+ Downlink and uplink

- High cost of equipment- Time consuming, "post mortem" (installation of tool, file analysis)- Important expertise needed for analysis- Very low coverage (A few RSLs, a few cell(s))- Very large amount of data (>> 10 Mbytes/hour/BTS)

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 DownLink and UpLink paths can be observed and compared.

BUT from B7 release, the Radio Measurement Statistics (RMS) feature implemented in the BSS provides a good level of information allowing to reduce the number of Abis traces to be done for radio network optimization.






Air Interface Trace

l INFORMATION SOURCE: EXTERNAL INTERFACE "Air"l Use trace MS to capture signaling and signal characteristics

+ Give precise location (x,y) of problems+ Give downlink radio information+ Only way to localize a lack of coverage+ Only way to monitor competitor

- High cost of equipment- Very time-consuming- Difficulty to perform a lot of calls

-> number of samples insufficient -> only a few streets

- No uplink

The main advantage of the Air trace is to associate a radio quality measurement to a given geographical area of the network.

Even if the RMS feature will allow to assess the radio quality as perceived by the end user, no location of the radio problems is provided through the RMS.






Performance Measurement Counters

l SUB-SYSTEM COUNTERSl Count events seen by sub-system, value reported periodically

(1 hour)

+ Low cost: collected directly at OMC+ Compact data: possibility to store counters for a complete network

- Raw information, having to be consolidated to be understandable- Manufacturer's dependent: questionable/difficult to compare- Weak to analyze other sub-systems

The main advantage of the BSS counters is to provide easily QoS data for permanent QoS monitoring.






Exercise

l Draw the BSS PM counters flow on the chartl In which sub-system are the BSS QoS indicators computed and stored?

BSC

BSC

BSC

OMC-R

OMC-R OMC-R

NPA

RNO






BSS Counters

l Combined into significant formulae: indicatorsl Used to monitor BSS network qualityl Over a complete network, with breakdown per cell/BSC

l SPECIFIC DRAWBACK NSS/PSTN/MS/USER problems not seen

As BSS PM counters are defined in order to provide information to assess the QoS of the BSS and help to detect BSS misbehavior, there is no way to identify QoS problems due to NSS, PSTN or User.






NSS Counters

l Combined into significant formulas: indicatorsl Used to monitor NSS network qualityl Over a complete network, with breakdown per BSC (maximum)

l SPECIFIC DRAWBACKS BSS problems usually not precisely identified No breakdown per cell

The NSS QoS is provided through NSS PM counters and indicators. It is out of the scope ot this training course.






Alcatel-Lucent BSS Counters

l INFORMATION SOURCES: BSS Counters (1/2)l Performance Management implementation Easy and cost-effective way to monitor network and carried traffic

l Principle: For a given duration (granularity period= typically 1 hour) To count pre-defined events occurring on the Abis or A interface, or

internally. Counters stored with breakdown per network component (i.e. cell)

l In the BSS B9, around 1000 counters are available (without GPRS).

Alcatel-Lucent has chosen to implement PM counters in the BSC and to increment them mostly on Abis interface signaling messages.

Other suppliers may have chosen to increment them on A interface signaling messages or to implement them in the BTS.

Therefore caution should be taken when interpreting QoS indicators value since some discrepancies may be observed due to these possible choices.

In order to provide the operators with an easy and cost-effective way to monitor their network and carried traffic, BSS manufacturers have implemented specific software features, called performance management.

The principle is to count for a given duration called granularity period (typically 1 hour) pre-defined events occurring on the Abis or A interface, or internally. These counters are stored for each duration, with breakdown per network component (i.e. cell).






Alcatel-Lucent BSS Counters [cont.]

l INFORMATION SOURCES: BSS Counters (2/2)l In Alcatel-Lucent BSS (except GPRS), counters are computed by the BSC,

based mainly on Abis messages.l Every reporting period, counters values are sent to the OMC-R for

storage.l Several counters are reported to the OMC-R permanently every PM

granularity period: Type 180: per cell adjacency Type 110 per cell Other Types: per TRX / N7 Link / BSC /

l Millions of counters are collected every day






BSS Counter Example

l MC718: counter number

l NB_TCH_NOR_ASS_SUCC_TRX: counter namel Cumulative: method of computationl Type 110: BSS PM measurement type to which the counter belongs l Measured object: minimum object level for which the counter is

provided: TRX or CELL or BSC or N7 LINK or X25 LINK etc.

All counters are described in PM Counters and Indicators.






BSS Counter Characteristics

l Collection mechanism

l Cumulative The counter is incremented at the occurrence of a specific event. Abis or A message, or internal event. At the end of a collection period, the result is the sum of the events.

l Inspection Every 20 or 10 seconds, a task quantifies an internal resource status (usually

a table). At the end of a collection period, the result is the mean value.

l Observation Set of recorded information about a telecom procedure (handover, channel

release, UL & DL measurements reporting).

Main counters are of cumulative type.

Inspection counters are of gauge type.

Observation counters are grouped in a Performance Measurement record associated to a particular GSM BSS telecom procedure: SDCCH channel seizure, TCH channel seizure, internal handover, etc.






BSS Performance Measurement TypesB10

N Type Name Type definition1 Traffic Measurement Set of counters related to the traffic evaluation per telecom procedure2 Resource Availability Measurement Set of counters related to the availability of the CCCH, SDCCH, or TCH channels3 CCCH channel resource usage measurements Set of counters related to the usage of CCCH channel (PCH, AGCH, RACH)4 SDCCH channel resource usage measurements Set of counters related to the usage of SDCCH channel5 TCH channel resource usage measurements Set of counters related to the usage of TCH channel6 TCH Handover Measurements Set of counters related to the TCH handover procedure7 LAPD Measurement Set of counters related to the LapD logical links8 X.25 Measurement Set of counters related to the X25 links OMC-BSC9 N7 Measurement Set of counters related to the N7 Signaling Links

10 SDCCH Observations Observation counters on SDCCH channels allocated11 TCH measurements observations Observation counters on 08.58 MEASUREMENT REPORT for a TCH12 Internal Handover Observations Observation counters on internal intra-cell or inter-cell SDCCH or TCH handover13 Incoming External Handover Observations Observation counters on incoming external SDCCH or TCH handover14 Outgoing External Handover Observations Observation counters on outgoing external SDCCH or TCH handover15 TCH Observation Observation counters on TCH channel allocated18 A Interface measurements different causes of 08.08 CLEAR REQUEST and 08.08 ASSIGNMENT FAILURE19 SMS PP Measurements Set of counters related to Short Message Service Point to Point25 SCCP Measurements Set of counters related to SCCP Layer of the N7 signaling Links26 TCH outgoing Handover per adjency Set of counters related to outgoing TCH handover provided per adjency27 TCH incoming Handover per adjency Set of counters related to incoming TCH handover provided per adjency28 SDCCH Handover Set of counter related to the SDCCH handover procedure29 Directed Retry measurements Set of counter related to the directed retry handover procedure30 SMS CB Measurements Set of counters related to Short Message Service Cell Broadcast31 Radio Measurement Statistics Set of counters providing radio quality measurements for TRX/Cell32 Change of frequency band measurements Set of counters related to handovers including a change of TCH Frequency band33 BTS Power Measurement Average emitted power at the BTS antenna output

110 Overview measurements Set of key counters allowing to access Quality of Service of a given Cell/BSC/Network180 Traffic Flow measurements Set of counters related to incoming inter-cell SDCCH/TCH handover performed per adjencyANNEX 6

Modified B10

BSS Performance Measurement types (PM types) are split into two categories:

l standard types (7, 8, 9, 18, 19, 25, 28, 29, 30, 31, 32,110, 180)l detailed types (1, 2, 3, 4, 5, 6, 10, 11, 12, 13, 14, 15, 26, 27)The most important types for QoS monitoring and Radio Network Optimization are in bold.

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)






Exercise

l Observation Means: find the best source of information.Observation to be done : Best source Why

6- history of network quality for several weeks

8- discriminate problems between BSS/NSS. BSS and NSS coming from different providers9- In a building, one is thinking that an elevator is inducing PCM trouble, how to confirm ?10- Identify potential interfering cells of 1 Cells

5- localise abnormal cells in a network

7- compare networks quality

3- get average network quality

4- localise precise location of a radio pb

1- overall radio quality of 1 cell Counters Type 31: RMS

2- monitor user failures





4 Introduction to K1205 PC Emulation






Usage

l The trace done with K1205 can be read: Directly on K1205 itself On any PC Windows NT with dedicated emulation software

l Practical exercises will be done during the course using this software

l The following slides and exercises are here to teach you the basic skill needed to operate the tool for A Interface decoding






Measurement Scenarios Screen

To select binary trace file

To select binary trace file

To enter in monitoring mode to

analyze the A trace

To enter in monitoring mode to

analyze the A trace

To filter the main GSM protocols and

messages

To filter the main GSM protocols and

messages

1. Start the K1205 Protocol Tester application.

2. In the Recording File box: click on the Open button and select the "PAIB29.rec" file.

3. Select all displayed N7 logical links (corresponding to 4 PCMs in this case).

4. Click on the Browse button and select gsm2_A.stk in the gsm2 sub-directory (corresponding to the GSM Phase 2 A interface protocol stack).

5. Click on OK.

6. Click on the Monitor box to display the content of the recorded trace.






Filter Configuration

l Configure your filter to remove some messages and protocols => Bypass Protocol Filterand select:

SCCP Except UDT Keep all DTAP BSSM Except PAGIN

Select also all Logical Links

ANNEX 4

The ANNEX 4 introduces some basics on the GSM protocol layers that will be traced for the A interface analysis.

UDT: Unit Data (for Signaling Control Point) Remove Paging information






Monitor Screen

Short View1 line / message

Short View1 line / message

Frame ViewFull decoding of

selected message

Frame ViewFull decoding of

selected message

Packet viewMessage content in hexadecimal

Packet viewMessage content in hexadecimal

To extract 1 callTo extract 1 call






Extract a Call

l How to find a specific message? Edit - Find (or ctrl + F3) Select All Logical Links. Choose the protocol. Select the message studied. Use F3 to find another same message.

l How to extract a call from these traces? Click on the Zoom button. Select CC message (Connection Confirm). And UnZoom + Zoom to get: SLR: Source Location Reference LR: Destination Location Reference

At call setup, the first signaling message on the A interface is sent by the BSC to the MSC in order to set up a logical link (called SCCP connection) between the BSS and the NSS.

Both BSS and NSS entities choose a unique reference which has to be used by the other party to identify the SCCP connection on which the messages are conveyed. Both BSS reference (xxx) and NSS reference (yyy) are exchanged during the SCCP Connection Request and Connection Confirm phases. After that only the reference of the other party is used.






Call Extraction

l Then

Click on the Filter button and filter out all protocol layers and messages except:

l all DTAP messages,

l all BSSMAP messages except "Paging,

l SCCP CR (Connection Request) and CC (Connection Confirm) messages.






Exercise

l Use the tool to extract a few calls from file PAIB29.REC1) Zoom on a CC message:

Find the definition of all messages in the Frame View.2) Zoom on a CR message with LUREQ.

How to extract the complete call? 3) Use Find to extract a call with an ALERTING message.

Can you see the CC message? If not, Why?





Self-assessment on the Objectives

l Please be reminded to fill in the formSelf-Assessment on the Objectivesfor this module

l The form can be found in the first partof this course documentation





End of ModuleIntroduction



Do not delete this graphic elements in here:

11All Rights Reserved Alcatel-Lucent 2008

Module 2Global Indicators3JK11044AAAAWBZZA Issue 01

Section 1GSM QoS Monitoring

EVOLIUM Base Station SubsystemIntroduction to Quality of Service and Traffic Load Monitoring - B10

3FL10491ADAAZZZZA Issue 01





Blank Page


First editionLast name, first nameYYYY-MM-DD01

RemarksAuthorDateEdition

Document History





Module Objectives

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

Explain what is a Global indicator and what are the main BSS indicators regarding GSM services provided by the Alcatel-Lucent BSS





Module Objectives [cont.]






Table of Contents


1 Indicators Definition 72 Methodological Precautions 133 Typical Call Failures 204 Description of Global Indicators 835 Traps and Restrictions of Global Indicators 1046 Global Indicators Interpretation 111





Table of Contents [cont.]






1 Indicators Definition






BSS Indicators Definition (Alcatel-Lucent)

l Global / Detailed

Numerical data providing information about network performance regarding: The complete network: GLOBAL indicator An element of the network: DETAILED indicator

TS/TRX/CELL/BTS/BSC/TC

A formulae of several counters Counters vs. Indicators Counters: provided by the BSS equipment Indicators: computed by BSS Monitoring equipment

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






Global Indicators

l Measure the performance of the complete network

l Analyzed according to their trend and values Usually every day (week, month)

l Compared with: Competitor results if available Contractual requirements Internal quality requirements






Thresholds

l EXAMPLE: Thresholds on Call Drop Rate indicator

Weekly CDR "GSM"

0,00%

0,50%

1,00%

1,50%

2,00%

2,50%

3,00%

3,50%

1 5 9 13 17 21 25 29 33 37 41 45week number

CD

R

weekly call drop ratecontractual call drop ratequality CDR

Weekly CDR "GSM"

0,00%

0,50%

1,00%

1,50%

2,00%

2,50%

3,00%

3,50%

1 5 9 13 17 21 25 29 33 37 41 45week number

CD

R

weekly call drop ratecontractual call drop ratequality CDR

The Call Drop rate at network level has to compared to:

l Contractual threshold: can be requested by the operator management to the operational radio team, can be requested by the operator to the provider on swap or network installation

l Quality threshold: fixed internally by radio team management.

Quality thresholds are usually tighter than contractual ones.






Exercise

l Are the indicators in the table below global ones?

INDICATOR DESCRIPTION G ?

average of call setup success rate for the network Yesrate of call lost due to radio pb on cell CI=14, LAC=234 Nocall drop rate in your capitalcall drop rate of the cell covering a specific buidling% of HO with the cause better cell (among other causes) for the networkaverage rate of TCH dropped for all TRX of the network carrying 1 SDCCH8 rate of SDCCH dropped on TRX1 of cell 12,24call success of 1 PLMN% of cells being congested today

INDICATOR DESCRIPTION G ?

average of call setup success rate for the network Yesrate of call lost due to radio pb on cell CI=14, LAC=234 Nocall drop rate in your capitalcall drop rate of the cell covering a specific buidling% of HO with the cause better cell (among other causes) for the networkaverage rate of TCH dropped for all TRX of the network carrying 1 SDCCH8 rate of SDCCH dropped on TRX1 of cell 12,24call success of 1 PLMN% of cells being congested today






Typical KPI of Radio Network

l Example of KPI used on network:

KPI Parameter Source Call Drop Rate OMC/Drive test

Congestion Rate Drive test

Handover Success Rate OMC/Drive test

Busy Hour Traffic OMC

TCH Utilization OMC

Call Setup success rate OMC/Drive test

Coverage Drive test

Quality Drive test

The KPI is a good way to measure the overall performance of the network. Several KPI parameters will be defined in the network to enable the operator to monitor the network performance throughout important events, new release, soft/hardware upgrades, etc.

Normally the formula of KPI are defined by the operator, and usually different operators may consider different KPIs and use different formulas. The KPI can be derived from driving tests and OMC traffic statistics.





2 Methodological Precautions






Objective

l Avoid typical errors regarding indicators interpretation






Global Indicator Value

A good value for a global indicator

All network components are OK regarding this indicator

l Example: A global call drop rate of 1% can hide some cells with 10% of call drop rate






Network Element Aggregation

l The average value of an indicator for a Network: Is not the average of cell results (or any sub-part of it) BUT is the average weighted by the traffic

number of calls number of call drop call drop ratecell 1 390 8 2,10%cell 2 546 29 5,25%cell 3 637 20 3,10%cell 4 1029 12 1,14%cell 5 536 3 0,50%cell 6 2 1 50,00%cell 7 3 1 33,00%cell 8 210 4 2,11%cell 9 432 5 1,20%cell 10 321 4 1,11%

average of cell results 9,95%total nb of drop/total number of calls 2,10%






Global Indicator Validity

l To be reliable, an indicator must be based on a sufficient number of events Estimation theory (MR.Spiegel, theory and problems of probability and

statistics , SCHAUM): 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% ]l This law cannot be used directly for indicators (an hourly indicator is

not based on a random sample), but it is giving a rough estimate of level of confidence one can apply regarding the size of the sample If a sample (number of calls) is too small, one can take it for a longer

duration

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 value 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 Cells with 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.






Time Period Aggregation

l Take care of data consolidation

l Example: Mean cell congestion rate during busy hour: Weighted average of cell congestion at the busy hour of the network? Weighted average of cell congestion rate for its specific busy hour? (definition of busy hour?)

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.






Exercise

l Is the conclusion given for each indicator right?INDICATOR Sample

(calls)conclusion OK ?

call drop = 0.9% in your country 2456435 all the cells have a good call dropNOK

call setup success for cell 15, 145 = 99.5% 2315 there is a good call setup success rate for15, 145

In Paris: 2500 cells with 95% of call setupsuccessIn the rest of France: 5000 cells with98%

3267872for France

In France, call setup success = 97 %

call drop for BSS BSS_1 = 1% 4500 the call drop for BSS_1 is good

call drop for cell 156;13 = 5% 215 cell 156;13 has certainly a trouble

for BSS 1, call drop of 2.0%for BSS 2, call drop of 3.0%

40002000

LA = BSS1 + BSS2 has a call drop of 2.3 %

MSC Stadium has a call setup success of95 %

15346 BSS1 belonging to MSC Stadium has a call setupsuccess of 95%





3 Typical Call Failures






Objective

l Description of the main call success and failures cases, with: Main specific counters Main protocol timers

l Diagnose the main case of failures on A interface traces using the K1205 emulation software






Call Setup phasing

l 4 stages for a call establishment, 2 for a location update:1- Radio link establishment2- "SDCCH phase

then only for "Circuit Switch call"3- TCH assignment4- "Alerting/connection" phase

l Each phase has a specific utility and some weaknesses

Radio Link EstablishmentSDCCH PhaseTCH assignmentAlerting/CNX Phase






Radio Link Establishment - OC success

l Originated Call: RLE success case

T3101: guard timer for SDCCH allocation (Default: 3 seconds) CR/CC are used to exchange SCCP references Any further message related to this call will have one (or 2) of these 2 references K1205 can extract the call using these references (SLR, DLR!!)

MS BTS BSC MSC

CHANNEL REQUEST-------------(RACH)------------> CHANNEL REQUIRED

----------------------------------------------> MC8CCHANNEL ACTIVATION (SDCCH)

IMMEDIATE ASSIGN COMMAND

IMMEDIATE ASSIGN stop T3101

CC






Radio Link Establishment - TC Success

l Terminated Call: RLE success caseMS BTS BSC MSC

PAGINGPAGING COMMAND






Radio Link Establishment - MO Success for DTM

l Terminated Call: RLE success case


MS BTS BSC MSC

CHANNEL REQUEST-------------(RACH) ------------> CHANNEL REQUIRED

----------------------------------------------> MC8CCHANNEL ACTIVATION (SDCCH)


IMMEDIATE ASSIGN






Radio Link Establishment - Paging

l RLE > Paging: MC8A=C8A

Normally all cells of the same Location Area must have the same MC8A counter value since all these cells must be paged for an MT call on an MS located in the Location Area they are included in.

If not: it means that a cell is not declared in the right LA at NSS level.






Radio Link Establishment - RACH Counter

l RLE > RACH: MC8C=C8C

Caution: All Channels Required (therefore RACH) are counted in MC8C: valid and invalid causes (see later). Indeed ghost RACHs are also counted.

The Channel Required content corresponds to the Channel Request message sent by the MS to the BTS.

This Channel Request message is made up of one byte with 2 Information Elements (IEs):8 7 6 5 4 3 2 1

+-----------------------------------------------+ ESTABLISHMENT RANDOM

+ - - - - - - - - + CAUSE REFERENCE +-----------------------------------------------+

lESTABLISHMENT CAUSE: This information field indicates the reason for requesting the establishment of a connection. This field has a variable length (from 3 bits up to 6 bits).

lRANDOM REFERENCE: This is an unformatted field with a variable length (from 5 bits down to 2 bits).

Due to the fact that the NECI bit is always set to 1 in Alcatel-Lucent BSS, Establishment causes can be divided into 2 categories:

l Valid causes: 5 (6 if GPRS)000: Location Update (Normal, Periodic, IMSI Attach)100: Terminating call101: Emergency call 110: Call Re-establishment111: Originating call (not emergency)011: if GPRS is implemented in the cell

l Invalid causes: 3 (2 if GPRS)001: 010: 011: if GPRS is not implemented in the cell





3 Typical Call Ffailures

Radio Link Establishment - OC Success Counters Split

l RLE > success MO split: MC02x=C02x

l MC02 =MC02A+MC02B+MC02C+.+MC02G+MC02H+MC02i

MC02A: LU

MC02B: SMS

MC02C: SS

MC02D: LU follow-on

MC02E: CR

MC02F: unknown

MC02G: IMSI Detach

MC02H: EC or NC

MC02i: LCS

MC02A = Number of SDCCHs successfully seized for Normal or Periodic LU request (IMSI Attach also counted).

MC02B = Number of SDCCHs successfully seized for Short Message Service.

MC02C = Number of SDCCHs successfully seized for Supplementary Service.

MC02D = Number of SDCCHs successfully seized for LU with follow-on bit set to 1 (means that the SDCCH phase will be followed by a TCH assignment for speech call establishment).

MC02E = Number of SDCCHs successfully seized for Call Re-establishment.

MC02F = Number of SDCCHs successfully seized in case of L3 Info (within 08.58 ESTABLISH INDICATION) unknown by the BSC but transferred to the MSC.

MC02G = Number of SDCCHs successfully seized for IMSI Detach.

MC02H = Number of SDCCHs successfully seized for Normal or Emergency call.

MC02i = Number of Mobile Originating SDCCH establishments for LCS purposes.

Also, Evaluation of the Mobiles location (see the next slides)

LCS: Location Services






Radio Link Establishment - SDCCH Congestion Failure

l Main failure cases for Radio Link Establishment Radio Link EstablishmentSDCCH PhaseTCH assignmentAlerting/CNX Phase

SDCCH Access Failure

SDCCH CongestionSDCCH

Congestion

SDCCH Radio Failure

SDCCH Radio Failure

SDCCH BSS Problem

SDCCH BSS Problem






Radio Link Establishment - SDCCH Congestion

l RLE > SDCCH congestion

The Immediate Assignment Reject mechanism can be disabled at OMC-R level It is not activated for answer to paging If disabled, no answer to the MS

The MS will repeat automatically its request in case of congestion (next slides) Waiting for T3122 expiry in case of Immediate Assignment Reject Waiting for T3120 expiry otherwise

MS BTS BSCMSC

CHANNEL REQUEST-------------(RACH)------------> CHANNEL REQUIRED

----------------------------------------------> MC8CNo free SDCCH !!MC04







Radio Link Establishment - SDCCH Congestion Counter

l RLE > SDCCH congestion: MC04=C04






Radio Link Establishment - SDCCH Cong. Consequences

l RLE > SDCCH congestion: MAIN CONSEQUENCES

The MS will try "max_retrans +1 " times before giving up Immediately for phase 1 MS After T3126 for phase 2 MS (still waiting for Immediate Assignment during this timer)

In case of "max_retrans+1" failures, the MS will: Either try an automatic cell reselection Or do nothing

In case of LU, the MS will attempt a new LU request In case of Call establishment, the MS will not re-attempt automatically. It is up to the

subscriber to try to set up the call again







Radio Link Establishment - SDCCH Cong. Causes/Solutions

l RLE > SDCCH congestion: MAIN causes/solutions

Location area border results in excessive location update and SDCCH attempt Inadequate LA design (too many LUs) Modify CRH (Cell Reselect Hysteresis) Modify BSC period location update Solve frequent handover problem between dual-band network

Excessive short messages Add SDCCH channel Enable dynamic SDCCH Dynamic Allocation function

Insufficient system capacity, lack of SDCCH channels Expansion for more TCH and SDCCH channels More SDCCHs should be added

Improper configuration of system parameters, RACH system parameter Increase RACH access threshold (overcoming interference) with care!


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






Radio Link Establishment - SDCCH Cong. Causes/Solutions [cont.]

l RLE > SDCCH congestion: MAIN causes/solutions

Board (TRX) fault and transmission fault result in SDCCH congestion

"Common Transport Effect" Difficult to avoid for small cells

Abnormal SDCCH traffic Phantom" channel requests (seen in SDCCH RF failure session) Neighboring cell barred


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






Radio Link Establishment - SDCCH Cong. Resolution?

l RLE > SDCCH congestionl DYNAMIC SDCCH ALLOCATION

CHANNEL REQUESTCHANNEL REQUIRED

MS BTS BSC

(RACH)

If No free SDCCH, thenrun dynamic SDCCH/8 timeslot allocation

algorithm. If allocation is successful, then

activate dynamic SDCCH sub-channeland serve request

If allocation was unsuccessful, then reject SDCCH request (possiblyusing the Immediate Assignment Reject procedure).

MC801a&b

MC802a&b


SPECIFIC COUNTERS (Type 110 / Cell Level):

l MC800 Average number of available dynamic SDCCH/8 timeslots.

l MC801a Average number of busy dynamic SDCCH/8 timeslots allocated as TCH (FR or HR).

l MC801b Maximum number of busy dynamic SDCCH/8 timeslots allocated as TCH (FR or HR).

l MC802a Average number of busy SDCCH sub-channels allocated on the dynamic SDCCH/8 timeslots.

l MC802b Maximum number of busy SDCCH sub-channels allocated on the dynamic SDCCH/8 timeslots.These four previous counters are Inspection Counters; that means that the resource is checked regulary 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 SD 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.






Radio Link Establishment - SDCCH Radio Failure

l Main failure cases for Radio Link Establishment



Congestion

SDCCH Radio Failure

SDCCH Radio Failure

SDCCH BSS Problem

SDCCH BSS Problem







Radio Link Establishment - SDCCH Radio Access Failure

l RLE > SDCCH RF Failure

MS BTS BSC MSCCHANNEL REQUEST

-------------(RACH)------------> CHANNEL REQUIRED----------------------------------------------> MC8C

CHANNEL ACTIVATION (SDCCH)


IMMEDIATE ASSIGN






Radio Link Establishment - Real Radio Problems


l Main causes > real radio problems

Unbalanced cell power budget Bad coverage (for example a moving car) Interference (for example downlink)

l In case of radio failure, the MS will retry as for SDCCH congestion


Unbalanced Power Budget:

Bad coverage:

Interference:

DL interference area

AGCH lost

RACH

building

BTS

Channel Request

Access Grant

Max Path Loss ULMax Path Loss DL

AGCH

RACH






Radio Link Establishment - Ghost RACH


l Main causes > "Phantom/Ghost/Spurious/Dummy ... RACH"

l Channel request received but not sent: 3 causes Noise decoding Reception of channel request sent to a neighboring cell Reception of HO_ACCESS sent to a neighboring cell






Radio Link Establishment - Ghost RACH Causes

l RLE > SDCCH RF Failurel Main causes > "Phantom/Ghost/Spurious/Dummy ... RACH"l Example of a channel required message

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 550m. It can take values from 0 (0m) to 63 (35km).

Thus the Channel Required above is received from an MS located at 19km from the site. It may therefore be rather a ghost RACH than a real MS which wants to re-establish a call.

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






Radio Link Establishment - Ghost RACH Causes [cont.]

l RLE > SDCCH RF Failurel Main causes > "Phantom RACH" > noise decodingl GSM 05.05: " 0.02 % of Rach Frame can be decoded without error

without real input signal" (No impact for the system) BCCH not combined: 51 Rach/Multi Frame > (3600 * 1000) ms / 4.615 ms at

0.02 %: 156 dummy RACH/hour BCCH combined: 27/51 RACH/Multi-Frame > 83 dummy RACH/hour 3/8 of causes (field of channel request, 5 valid causes over 8) will be unvalid Example of induced SDCCH traffic:

(5/8*156*T3101 (3 sec))/3600 = 0.08 Erlang SDCCH

l Some tips: Dummy Rach load depends on minimum level for decoding configured in

Evolium BTS During period with low real traffic (night), high rate of dummy RACH For dummy RACH, the channel required has a random value of TA

STRUCTURE of the MULTIFRAME in "TIME SLOT" 0

-

R = RACH

DOWNLINKf s b b b b C C C C

31 51 1211 2 3 4 5 6 7 8 9 10 20 41f s f s f s f sC C C C C C C C C C C C C C C C C C C C C C C C C C C C C C C C -

(Multiframes of 51 frames)

f = FCCH s = SCH b = BCCH

f s

C C C C = CCCH (PCH or AGCH)

UPLINKR R R RR R R R R R R RR R R R R R R RR R R R R R R RR R R R R R R RR R R RR R R RR R R R R R

(Non-combined BCCH)

(Combined BCCH)

R = RACH

DOWNLINK

F = FCCH S = SCH B = BCCH C = CCCH (PCH or AGCH)

UPLINK

F S B C F S F S F S -F SC C D0 D1 D2 D3 A0 A1

F S B C F S F S F S -F SC C D0 D1 D2 D3 A2 A3

R R R RR R R R R R R RR R R R R R RR R R R R RR RD3 A2 A3 D0 D1 D2

R R R RR R R R R R R RR R R R R R RR R R R R RR RD3 A0 A1 D0 D1 D2

Dn/An = SDCCH/SACCH/4

51 multiframe duration = 51 x 8 x 0,577 = 235ms







l RLE > SDCCH RF Failurel Main causes > "Phantom RACH" >noise decoding

l No subscriber -> no impact for subscriberl But MC149 incremented -> SDCCH RF access failure is impacted

MS BTS BSC MSC

CHANNEL REQUIRED----------------------------------------------> MC8C



IMMEDIATE ASSIGN







l RLE > SDCCH RF Failurel Main causes > "Phantom RACH" > Channel Request

sent to the neighboring cell

l Subscriber not impacted (real transaction performed elsewhere) l But MC149 incremented -> SDCCH RF access failure is impacted l Usual radio planning rules are sufficient to avoid the trouble

2 cells must not have the same (BCCH, BSIC) couple

M S B T S B S C M SC

C H A N NE L R E Q UIR E D----------------------------------------------> M C 8C

C H AN N E L A C TIV A TIO N (S DCCH )< ---------------------------------------------- M C 148

C HA N N E L A CT IV A TIO N A C K---------------------------------------------->

IM M E D IAT E A SS IG N C O M M A N DIM M E DIA T E A S S IG N < ---------------------------------------------- s tart T 3101 M C 8B

radio fa ilu re

BSIC = BCC (3 bit) + NCC (3 bit)

l BCC: BTS Color Code

l NCC: Network Color Code







l RLE > SDCCH RF Failurel Main causes > "Phantom RACH" > Channel Request due to handover

l During HO, the first message sent to the target cell is HO Accessl This message is an Access Burst like Channel Request

l If received on BCCH, can be understood as a Channel Request (RACH)l A new case of "Phantom RACH"







l RLE > SDCCH RF Failurel Main causes > "Phantom RACH" > Channel Request due to handoverl This case is the most dangerous

The MS usually sends a sequence of HO Access messages, every frame In some cases, this can create a phantom RACH if the frequency of the

TCH is identical or adjacent to the one of interfered BCCH Characteristics of such phantom RACH (Channel Required) Subsequent frame number Random, but stable timing advance

Can block very easily SDCCH






Radio Link Establishment - BSS Failure

l Main failure cases for Radio Link Establishment Radio Link EstablishmentSDCCH PhaseTCH assignmentAlerting/CNX Phase



Congestion

SDCCH Radio Failure

SDCCH Radio Failure

SDCCH BSS Problem

SDCCH BSS Problem






Radio Link Establishment - BSS Problem

l RLE > BSS problem

l No specific counter

MS BTS BSC MSCCHANNEL REQUEST

-------------(RACH)------------> CHANNEL REQUIRED----------------------------------------------> MC8C



IMMEDIATE ASSIGN






Radio Link Establishment - Counters

l RLE counters

Request MC8C

GPRS causes P62CGSM invalid causes unknown

Preparation GSM valid causes unknown

Congestion MC04BSS Pb unknown

Execution Attempt MC148

Radio Access Failure MC149BSS Pb MC148 - (MC01+MC02) - MC149

Success MC01+MC02

Radio Link Establishment

REQUEST

Congestion

ATTEMPT

Radio access failure

SUCCESS

BSS problem

Preparation Failure

Execution Failure

GPRS causes GSM/GPRS invalid causes GSM valid causes

BSS problem


Statistically a ghost RACH can correspond to any kind of establishment cause: valid and invalid.

As ghost RACH which corresponds to a GSM valid cause will lead to an SDCCH allocation which will not be seized by an MS, it will lead to the incrementation of the MC149 counter and therefore counted as an SDCCH access failure due to radio.






Radio Link Establishment - Indicators

l TYPICAL CALL FAILURES: RLE indicators

SDNAFLBNSDNAFLRNSDNACGNSDNAFSUNSDNAFLR


Refer to BSS - DEFINITION OF QUALITY OF SERVICE INDICATORS: GLOBAL Quality of service INDICATORS > SDCCH > Assignment Phase

l SDNAUR: SDCCH assignment unsuccess rate

l SDNACGR: SDCCH assignment failure rate due to congestion (Global)

l SDNAFLRR: SDCCH assignment failure rate due to radio

l SDNAFLBR: SDCCH assignment failure rate due to BSS problem

An SDCCH radio access failure due to ghost RACH occurrence is easily observed during low traffic hour (night time) since ghost RACHs are almost the only cause of failure.






SDCCH Phase - OC Success

l Successful SDCCH phase: OC call

l Transparent message: no dedicated counters

MS BTS BSC MSCSDCCH Phase : Originating Call case

< -------------------------------------------------------------------------------------------------------------------------AUTHENTICATION REQUEST

------------------------------------------------------------------------------------------------------------------------- >AUTHENTICATION RESPONSE

< -------------------------------------------------------------------------------------------------------------------------CIPHERING MODE COMMAND

------------------------------------------------------------------------------------------------------------------------- >CIPHERING MODE COMPLETE

------------------------------------------------------------------------------------------------------------------------- >SETUP

< -------------------------------------------------------------------------------------------------------------------------CALL PROCEEDING


Transparent messages (DTAP) are used in order the NSS performs control procedures to enable the MS to set up a speech call.

Authentication: Checks that the Mobile Station is the required station and not an intruder.

Ciphering: All Information (signaling, Speech and Data) is sent in cipher mode, to avoid monitoring and intruders (who could analyze signaling data).

Setup/Call Processing: call is being processed between the calling Party and the Called Party.






SDCCH Phase - TC Success

l Successful SDCCH phase: TC call


MS BTS BSC MSCSDCCH Phase : Terminating Call case





< -------------------------------------------------------------------------------------------------------------------------SETUP

------------------------------------------------------------------------------------------------------------------------- >CALL CONFIRM


Setup/Call Confirm: the call is being processed between the Calling Party and the Called Party.






SDCCH Phase - LU Success

l Successful SDCCH phase: Location Update


MS BTS BSC MSCSDCCH Phase : Location Update Case (with TMSI reallocation)

------------------------------------------------------------------------------------------------------------------------- >LOCATION UPDATE REQUEST





< -------------------------------------------------------------------------------------------------------------------------LOCATION UPDATE ACCEPT

------------------------------------------------------------------------------------------------------------------------- > TMSI REALLOCATION COMPLETE


Some transparent messages are also exchanged between the MS and the network in case of a Location Update transaction.






SDCCH Phase - Drops

l SDCCH phase

l Loss of connection during SDCCH phase = "SDCCH drop"

l 3 origins of SDCCH drop: Radio problems when connected on SDCCH BSS problems Call lost during an SDCCH HO (handover failure without reversion to old

channel)


Generally SDCCH handovers are disabled in the network since the average SDCCH duration is only around 2 to 3 seconds.






SDCCH Phase - Radio Drop

l SDCCH phase > drop Radio

l Connection lost due to Radio problem

MS BTS BSC MSCSDCCH Phase established

Radio connection lost---------------------------------------------------- > MC138CONNECTION FAILURE INDICATION

(cause : radio link failure)--------------------------------------- >CLEAR REQUEST

Cause : radio interface failure


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.






SDCCH Phase - BSS Drop

l SDCCH phase > drop BSS

l Connection lost due BSS problem


MC137

--------------------------------------- >CLEAR REQUEST

Cause : O&M interventionCause : radio interface failure


MC137 counts the number of SDCCH channel drops due to BSS problems.

A BSS problem can be a BTS/BSC hardware or software failure. It can also be due to a problem on the Abisinterface (due to Micro Wave transmission for instance).






SDCCH Phase - HO drop

l SDCCH phase > drop HO

l Connection lost during Handover


HO FAILURE WITHOUT REVERSION MC07--------------------------------------- >

CLEAR REQUESTRadio Interface Message Failure (Alcatel)


MC07 counts the number of SDCCH channel drops due to handover failure.






SDCCH Phase - Counters

l SDCCH phase counters

SDCCH connection MC01+MC02+MC10

SDCCH Drop Drop radio MC138Drop BSS MC137Drop HO MC07

SDCCH Phase

TCH assignment phase SDCCH drop

SDCCH connection

Normal releas

B10QoS

Documents

Transcript of B10QoS