BSS Signaling Analysis Guide

HUAWEI BSC6000 Base Station Subsystem V900R008
BSS Signaling Analysis Guide
Issue Date INTERNAL
01 2008-06-10
Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd
Huawei Technologies Co., Ltd. provides customers with comprehensive technical support and service. For any assistance, please contact our local office or company headquarters.
Huawei Technologies Co., Ltd.

Address: Huawei Industrial Base Bantian, Longgang Shenzhen 518129 People's Republic of China http://www.huawei.com [email protected]
Website: Email:
Copyright Huawei Technologies Co., Ltd. 2008. All rights reserved. No part of this document may be reproduced or transmitted in any form or by any means without prior written consent of Huawei Technologies Co., Ltd.
Trademarks and Permissions

and other Huawei trademarks are the property of Huawei Technologies Co., Ltd. All other trademarks and trade names mentioned in this document are the property of their respective holders.
Notice
The information in this document is subject to change without notice. Every effort has been made in the preparation of this document to ensure accuracy of the contents, but the statements, information, and recommendations in this document do not constitute a warranty of any kind, express or implied.
HUAWEI BSC6000 Base Station Subsystem BSS Signaling Analysis Guide
Contents
Contents
About This Document.....................................................................................................................1 1 Fundamentals of BSS Signaling..............................................................................................1-1
1.1 A Interface (TDM)..........................................................................................................................................1-2 1.1.1 Protocol Stack on the A Interface (TDM)..............................................................................................1-2 1.1.2 Physical Layer on the A Interface (TDM)..............................................................................................1-3 1.1.3 MTP Layer on the A Interface...............................................................................................................1-3 1.1.4 SCCP Layer on the A Interface..............................................................................................................1-6 1.1.5 BSSAP Layer on the A Interface...........................................................................................................1-6 1.2 A Interface (IP)..............................................................................................................................................1-10 1.2.1 Protocol Stack on the A Interface (IP).................................................................................................1-11 1.2.2 Physical Layer on the A Interface (IP).................................................................................................1-12 1.2.3 IP Layer on the A Interface..................................................................................................................1-12 1.2.4 SCTP/M3UA Layer on the A Interface................................................................................................1-14 1.2.5 SCCP Layer on the A Interface............................................................................................................1-15 1.2.6 BSSAP Layer on the A Interface.........................................................................................................1-16 1.3 Abis Interface (TDM)....................................................................................................................................1-20 1.3.1 Protocol Stack on the Abis Interface (TDM).......................................................................................1-20 1.3.2 Abis Interface Structure.......................................................................................................................1-21 1.3.3 Physical Layer on the Abis Interface (TDM).......................................................................................1-23 1.3.4 LAPD Layer on the Abis Interface.......................................................................................................1-23 1.3.5 Layer 3 Traffic Management Messages on the Abis Interface............................................................1-24 1.3.6 Layer 3 OM Messages on the Abis Interface.......................................................................................1-27 1.4 Abis Interface (HDLC)..................................................................................................................................1-29 1.4.1 Protocol Stack on the Abis Interface (HDLC).....................................................................................1-30 1.4.2 Physical Layer on the Abis Interface (HDLC).....................................................................................1-30 1.4.3 HDLC Layer on the Abis Interface......................................................................................................1-31 1.4.4 LAPD Layer on the Abis Interface.......................................................................................................1-31 1.4.5 Layer 3 Traffic Management Messages on the Abis Interface............................................................1-32 1.4.6 Layer 3 OM Messages on the Abis Interface.......................................................................................1-35 1.5 Abis Interface (IP).........................................................................................................................................1-37 1.5.1 Protocol Stack on the Abis Interface (IP).............................................................................................1-38 1.5.2 Physical Layer on the Abis Interface (IP)............................................................................................1-38 1.5.3 UDP/IP Layer on the Abis Interface....................................................................................................1-39 Issue 01 (2008-06-10) Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd i
Contents
HUAWEI BSC6000 Base Station Subsystem BSS Signaling Analysis Guide 1.5.4 LAPD Layer on the Abis Interface.......................................................................................................1-41 1.5.5 Layer 3 Traffic Management Messages on the Abis Interface............................................................1-42 1.5.6 Layer 3 OM Messages on the Abis Interface.......................................................................................1-44
1.6 Um Interface..................................................................................................................................................1-47 1.6.1 Physical Layer on the Um Interface.....................................................................................................1-47 1.6.2 LAPD Layer on the Um Interface........................................................................................................1-48 1.6.3 Layer 3 Entity on the Um Interface......................................................................................................1-49 1.7 Gb Interface...................................................................................................................................................1-53 1.7.1 Protocol Stack on the Gb Interface......................................................................................................1-53 1.7.2 FR/IP....................................................................................................................................................1-54 1.7.3 NS.........................................................................................................................................................1-54 1.7.4 BSSGP..................................................................................................................................................1-55
2 BSS Signaling Tracing.............................................................................................................. 2-1

2.1 Tracing CS Messages......................................................................................................................................2-2 2.1.1 Tracing the Messages on the A Interface...............................................................................................2-2 2.1.2 Tracing the Messages on the Abis Interface........................................................................................2-15 2.1.3 Tracing the Messages on the Pb Interface............................................................................................2-25 2.1.4 Tracing CS Domain Messages on the Um Interface............................................................................2-30 2.1.5 Tracing User Messages........................................................................................................................2-32 2.1.6 Tracing Messages on the BSC-CBC Interface.....................................................................................2-35 2.2 Tracing PS Messages....................................................................................................................................2-37 2.2.1 Tracing the Messages on the Gb Interface...........................................................................................2-38 2.2.2 Tracing PS Domain Messages on the Um Interface.............................................................................2-42
3 BSS System Information...........................................................................................................3-1

3.1 BSS System Information Type........................................................................................................................3-2 3.1.1 System Information Type 1....................................................................................................................3-2 3.1.2 System Information Types 2, 2bis, 2ter, and 2quater.............................................................................3-6 3.1.3 System Information Type 3....................................................................................................................3-8 3.1.4 System Information Type 4..................................................................................................................3-12 3.1.5 System Information Types 5, 5bis, and 5ter.........................................................................................3-13 3.1.6 System Information Type 6..................................................................................................................3-14 3.1.7 System Information Type 7..................................................................................................................3-15 3.1.8 System Information Type 8..................................................................................................................3-16 3.1.9 System Information Type 13................................................................................................................3-16 3.2 Internal BSC Signaling Procedure of the System Information.....................................................................3-17
4 Immediate Assignment.............................................................................................................4-1
4.1 Immediate Assignment Procedure..................................................................................................................4-2 4.2 Internal BSC Signaling Procedure (Immediate Assignment).........................................................................4-4 4.3 Abnormal Cases and Handling Suggestions (Immediate Assignment)..........................................................4-4 4.3.1 Failure to Receive an Establish Indication Message After Channel Activation (Case Study)...............4-5 4.3.2 BSC Sending an Immediate Assignment Reject Message (Case Study)...............................................4-5 ii Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd Issue 01 (2008-06-10)
Contents
5 Classmark Update......................................................................................................................5-1
5.1 Classmark Update Procedure..........................................................................................................................5-2
6 Location Update..........................................................................................................................6-1
6.1 Location Update Procedure.............................................................................................................................6-2 6.1.1 Periodic Location Update Procedure......................................................................................................6-2 6.1.2 IMSI Attach Procedure...........................................................................................................................6-4 6.1.3 Generic Location Update Procedure......................................................................................................6-4 6.2 Internal BSC Signaling Procedures (Location Update)..................................................................................6-6 6.3 Abnormal Cases and Handling Suggestions (Location Update).....................................................................6-7 6.3.1 Location Update Not Started or Terminated on the MS Side (Case Study)...........................................6-7 6.3.2 Location Update Failure on the Network Side (Case Study).................................................................6-8
7 Authentication............................................................................................................................7-1
7.1 Authentication Principles................................................................................................................................7-2 7.2 Authentication Procedure................................................................................................................................7-2 7.3 Authentication Reject......................................................................................................................................7-3 7.4 Internal BSC Signaling Procedure (Authentication).......................................................................................7-4 7.5 Abnormal Cases and Handling Suggestions (Authentication)........................................................................7-4 7.5.1 Authentication Failure Caused by RR Connection Failure (Case Study)..............................................7-5 7.5.2 Authentication Failure Caused by Timer T3260 Expiry (Case Study)..................................................7-5 7.5.3 Authentication Failure Caused by SIM Unregistered (Case Study).......................................................7-5
8 Ciphering.....................................................................................................................................8-1
8.1 Ciphering Procedure........................................................................................................................................8-2 8.2 Ciphering Mode Change.................................................................................................................................8-3 8.3 Internal BSC Signaling Procedure (Ciphering)...............................................................................................8-3 8.4 Abnormal Cases and Handling Suggestions (Ciphering)................................................................................8-4 8.4.1 Ciphering Failure Caused by BSS Sending a Cipher Mode Reject Message (Case Study)...................8-4 8.4.2 Ciphering Failure Caused by MS Doing No Processing (Case Study)..................................................8-4
9 TMSI Reallocation.....................................................................................................................9-1
9.1 TMSI Reallocation Procedure.........................................................................................................................9-2 9.2 Internal BSC Signaling Procedure (TMSI Reallocation)................................................................................9-2 9.3 Abnormal Cases and Handling Suggestions (TMSI Reallocation).................................................................9-3 9.3.1 TMSI Reallocation Caused by RR Connection Failure on the Network Side (Case Study)..................9-3 9.3.2 TMSI Reallocation Caused by T3250 Expiry (Case Study)..................................................................9-3
10 Speech Channel Assignment...............................................................................................10-1

10.1 Speech Channel Assignment Procedure......................................................................................................10-2 10.2 Channel Mode Modification Procedure......................................................................................................10-3 10.3 Internal BSC Signaling Procedure (Speech Channel Assignment).............................................................10-4 10.4 Abnormal Cases and Handling Suggestions (Speech Channel Assignment)..............................................10-5 10.4.1 BSC Sending an Assignment Failure Message (Case Study)............................................................10-5 10.4.2 BSC Receiving a Connection Failure Indication Message (Case Study)...........................................10-6 Issue 01 (2008-06-10) Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd iii
Contents
HUAWEI BSC6000 Base Station Subsystem BSS Signaling Analysis Guide 10.4.3 BSC Receiving an Error Indication Message (Case Study)...............................................................10-7
11 Mobile Originated Call.........................................................................................................11-1

11.1 Mobile Originated Call Establishment Procedure.......................................................................................11-2 11.1.1 Early Assignment Procedure..............................................................................................................11-2 11.1.2 Late Assignment Procedure...............................................................................................................11-4 11.1.3 Very Early Assignment Procedure.....................................................................................................11-6 11.2 Internal BSC Signaling Procedure (Mobile Originated Call).....................................................................11-7 11.3 Abnormal Cases and Handling Suggestions (Mobile Originated Call)......................................................11-7 11.3.1 Calling MS Cannot Be Heard (Case Study).......................................................................................11-8 11.3.2 MSC Releasing the Call After Sending a CM Service Reject Message (Case Study).......................11-8 11.3.3 Abnormal Case Caused by MS in Busy State (Case Study)..............................................................11-9 11.3.4 MSC Sending a Disconnect Message Instead of an Assignment Request Message (Case Study)....11-9 11.3.5 Abnormal Cases Caused by MS Hangup (Case Study).....................................................................11-9 11.3.6 Abnormal Cases Caused by MSC Sending a Clear Command Message or a Disconnect Message (Case Study)..........................................................................................................................................................11-10 11.3.7 LAPD Reporting an Error Indication Message During Call Establishment (Case Study)...............11-11
12 Mobile Terminated Call........................................................................................................12-1

12.1 Mobile Terminated Call Establishment Procedure.....................................................................................12-2 12.2 Internal BSC Signaling Procedure (Mobile Terminated Call)....................................................................12-3 12.3 Abnormal Cases and Handling Suggestions (Mobile Terminated Call).....................................................12-3 12.3.1 No Paging Command on the A Interface (Case Study).....................................................................12-4 12.3.2 No Paging Command on the Abis Interface (Case Study).................................................................12-4 12.3.3 No Paging Response on the Abis Interface (Case Study)..................................................................12-5 12.3.4 No Paging Response on the A Interface (Case Study).......................................................................12-6
13 BSC Release.............................................................................................................................13-1
13.1 Normal Release Procedure..........................................................................................................................13-2 13.2 Local Release Procedure.............................................................................................................................13-4
14 Handover..................................................................................................................................14-1
14.1 Handover Procedures..................................................................................................................................14-2 14.1.1 Intra-BSC Handover Procedure.........................................................................................................14-2 14.1.2 Inter-BSC Handover Procedure.........................................................................................................14-4 14.1.3 Inter-MSC Handover Procedure.........................................................................................................14-6 14.1.4 Inter-RAT Handover Procedure.........................................................................................................14-7 14.2 Internal BSC Signaling Procedures (Handover).........................................................................................14-9 14.2.1 Internal BSC Signaling Procedure (Intra-BSC Handover)................................................................14-9 14.2.2 Internal BSC Signaling Procedure (Inter-BSC Handover)..............................................................14-10 14.2.3 Internal BSC Signaling Procedure (Inter-MSC Handover)..............................................................14-10 14.2.4 Internal BSC Signaling Procedure (Inter-RAT Handover)..............................................................14-11 14.3 Abnormal Cases and Handling Suggestions (Handover)..........................................................................14-11 14.3.1 No Available Channels in the Target Cell (Case Study)..................................................................14-11 14.3.2 Old BSS Not Receiving a Specified Message Upon T8 Expiry (Case Study).................................14-12 iv Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd Issue 01 (2008-06-10)
Contents
14.3.3 MS Returning to the Old Channel After Inter-Cell Handover Failure (Case Study).......................14-12 14.3.4 BSC Receiving a Connection Failure Indication Message (Case Study).........................................14-13 14.3.5 Forced Handover Failure (Case Study)............................................................................................14-13 14.3.6 Handover Failure Caused by CIC Malfunction (Case Study)..........................................................14-14 14.3.7 Handover Failure Caused by MS Access Failure (Case Study).......................................................14-14
15 Call Re-Establishment...........................................................................................................15-1
15.1 Call Re-Establishment Procedure................................................................................................................15-2 15.2 Internal BSC Signaling Procedure (Call Re-Establishment).......................................................................15-4 15.3 Abnormal Cases and Handling Suggestions (Call Re-Establishment)........................................................15-4 15.3.1 Network Sending a CM Service Reject Message (Case Study).........................................................15-4 15.3.2 Call Re-Establishment Not Allowed or Re-Establishment Failure (Case Study)..............................15-5 15.3.3 Call Re-Establishment Failure Caused by RR Connection Failure (Case Study)..............................15-5
16 Directed Retry.........................................................................................................................16-1
16.1 Directed Retry Procedures..........................................................................................................................16-2 16.1.1 Intra-BSC Directed Retry Procedure..................................................................................................16-2 16.1.2 Inter-BSC Directed Retry Procedure..................................................................................................16-4 16.1.3 Inter-MSC Directed Retry Procedure.................................................................................................16-6 16.2 Internal BSC Signaling Procedures (Directed Retry)..................................................................................16-7 16.2.1 Internal BSC Signaling Procedure (Intra-BSC Directed Retry).........................................................16-8 16.2.2 Internal BSC Signaling Procedure (Inter-BSC Directed Retry).........................................................16-8 16.2.3 Internal BSC Signaling Procedure (Inter-MSC Directed Retry)........................................................16-9 16.3 Abnormal Cases and Handling Suggestions (Directed Retry)....................................................................16-9 16.3.1 Directed Retry Failure Caused by No Available Channels in the Target Cell (Case Study).............16-9 16.3.2 Directed Retry Failure Caused by Channel Activation Failure (Case Study)..................................16-10
17 BSC Re-Assignment...............................................................................................................17-1
17.1 BSC Re-Assignment Procedure..................................................................................................................17-2 17.2 Internal BSC Signaling Procedure (BSC Re-Assignment).........................................................................17-3 17.3 Abnormal Cases and Handling Suggestions (BSC Re-Assignment)..........................................................17-3 17.3.1 BSC Failure to Initiate a Re-Assignment Procedure (Case Study)....................................................17-4
18 Queuing and Preemption.....................................................................................................18-1

18.1 Queuing Procedure......................................................................................................................................18-2 18.2 Preemption Procedure.................................................................................................................................18-3 18.3 Internal BSC Signaling Procedure (Queuing and Preemption)...................................................................18-4 18.4 Abnormal Cases and Handling Suggestions (Queuing and Preemption)....................................................18-4 18.4.1 BSC Sending a Clear Request Message to the MS (Case Study)......................................................18-4
19 Short Messages.......................................................................................................................19-1
19.1 Short Message Procedures..........................................................................................................................19-2 19.1.1 Short Message Sending Procedure of an Idle MS..............................................................................19-2 19.1.2 Short Message Receiving Procedure of an Idle MS...........................................................................19-3 19.1.3 Short Message Sending Procedure of a Busy MS..............................................................................19-5 Issue 01 (2008-06-10) Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd v
Contents
19.1.4 Short Message Receiving Procedure of a Busy MS...........................................................................19-5 19.2 Internal BSC Signaling Procedure (Short Messages).................................................................................19-6 19.3 Abnormal Cases and Handling Suggestions (Short Messages)..................................................................19-7 19.3.1 Short Message Sending Failure Caused by Disabled Authentication and Ciphering (Case Study) .......................................................................................................................................................................19-7
20 Cell Broadcast Messages.......................................................................................................20-1

20.1 Cell Broadcast Message Procedures...........................................................................................................20-2 20.1.1 CBS-BSC Message Procedure...........................................................................................................20-2 20.1.2 BSC-BTS Message Procedure...........................................................................................................20-5 20.2 Internal BSC Signaling Procedure (Cell Broadcast Messages)...................................................................20-6 20.3 Abnormal Cases and Handling Suggestions (Cell Broadcast Messages)...................................................20-7 20.3.1 MS Failure to Receive Broadcast Messages (Case Study)................................................................20-7 20.3.2 Cell Not Configured with CBCH (Case Study).................................................................................20-8
21 GPRS.........................................................................................................................................21-1
21.1 GPRS Procedure..........................................................................................................................................21-2 21.1.1 Uplink TBF Establishment Procedure (CCCH Phase One Access)...................................................21-3 21.1.2 Uplink TBF Establishment Procedure (CCCH Phase Two Access)..................................................21-4 21.1.3 Uplink TBF Establishment Procedure (PACCH Access)..................................................................21-4 21.1.4 Uplink TBF Release Procedure..........................................................................................................21-5 21.1.5 Downlink TBF Establishment Procedure (CCCH)............................................................................21-6 21.1.6 Downlink TBF Establishment Procedure (PACCH)..........................................................................21-8 21.1.7 Downlink TBF Release Procedure.....................................................................................................21-9 21.1.8 GPRS Attach Procedure...................................................................................................................21-10 21.1.9 GPRS Detach Procedure..................................................................................................................21-12 21.1.10 Routing Area Update Procedure....................................................................................................21-14 21.1.11 PDP Context Activation Procedure................................................................................................21-17 21.1.12 PDP Context Deactivation Procedure............................................................................................21-19 21.1.13 PDP Context Modification Procedure............................................................................................21-21 21.1.14 Circuit Paging Procedure...............................................................................................................21-21 21.1.15 Packet Paging Procedure................................................................................................................21-22 21.1.16 GPRS Suspension and Resumption Procedure..............................................................................21-23 21.2 Internal BSC Signaling Procedures...........................................................................................................21-25 21.3 Abnormal Cases and Handling Suggestions (GPRS)................................................................................21-26 21.3.1 Abnormal PCU Cell Startup (Case Study).......................................................................................21-26 21.3.2 GPRS Service Access Not Allowed (Case Study)...........................................................................21-28
vi
Issue 01 (2008-06-10)
Figures
Figures
Figure 1-1 Protocol stack on the A interface........................................................................................................1-3 Figure 1-2 L3 signaling message processing procedure.......................................................................................1-5 Figure 1-3 Protocol Stack on the A Interface (IP)..............................................................................................1-11 Figure 1-4 Protocol stack on the Abis interface.................................................................................................1-21 Figure 1-5 Abis interface structure.....................................................................................................................1-22 Figure 1-6 Logical links on the Abis interface...................................................................................................1-23 Figure 1-7 Management objects.........................................................................................................................1-27 Figure 1-8 Protocol stack on the Abis interface (HDLC)...................................................................................1-30 Figure 1-9 Management objects.........................................................................................................................1-35 Figure 1-10 Protocol stack on the Abis interface (IP)........................................................................................1-38 Figure 1-11 Management objects.......................................................................................................................1-45 Figure 1-12 Interfaces of L1 on the Um interface..............................................................................................1-48 Figure 1-13 L3 signaling message processing procedure...................................................................................1-51 Figure 1-14 Services provided by the RR sublayer............................................................................................1-52 Figure 1-15 Services provided by the MM sublayer..........................................................................................1-53 Figure 1-16 Protocol stack on the Gb interface..................................................................................................1-54 Figure 1-17 Service model of BSSGP................................................................................................................1-56 Figure 2-1 Trace BSSAP Message on the A Interface dialog box.......................................................................2-3 Figure 2-2 Tracing BSSAP messages on the A interface.....................................................................................2-4 Figure 2-3 Trace SCCP Message on the A Interface dialog box.........................................................................2-5 Figure 2-4 Tracing SCCP messages on the A interface.......................................................................................2-6 Figure 2-5 Trace MTP3 Message on the A Interface dialog box.........................................................................2-7 Figure 2-6 Tracing MTP3 messages on the A interface.......................................................................................2-8 Figure 2-7 Trace MTP2 Message on the A Interface dialog box.........................................................................2-9 Figure 2-8 Tracing MTP2 messages on the A interface.....................................................................................2-10 Figure 2-9 Trace SCTP Message on the A Interface dialog box........................................................................2-11 Figure 2-10 Tracing SCTP messages on the A interface...................................................................................2-12 Figure 2-11 Trace M3UA Message on the A Interface dialog box....................................................................2-13 Figure 2-12 Tracing M3UA messages on the A interface..................................................................................2-14 Figure 2-13 Trace RSL Message on the Abis Interface dialog box...................................................................2-16 Figure 2-14 Tracing RSL messages on the Abis interface.................................................................................2-17 Figure 2-15 Trace OML Message on the Abis Interface dialog box..................................................................2-18 Figure 2-16 Tracing OML messages on the Abis interface...............................................................................2-19 Issue 01 (2008-06-10) Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd vii
Figures
Figure 2-17 Trace ESL Message on the Abis Interface dialog box...................................................................2-20 Figure 2-18 Tracing ESL messages on the Abis interface.................................................................................2-21 Figure 2-19 Trace EML Message on the Abis Interface dialog box..................................................................2-22 Figure 2-20 Trace EML Message on the Abis Interface dialog box..................................................................2-23 Figure 2-21 Trace LAPD Message on the Abis Interface dialog box................................................................2-24 Figure 2-22 Tracing LAPD messages on the Abis interface..............................................................................2-25 Figure 2-23 Trace Application Message on the Pb Interface dialog box...........................................................2-26 Figure 2-24 Tracing application messages on the Pb interface..........................................................................2-27 Figure 2-25 Trace LAPD Message on the Pb Interface dialog box...................................................................2-29 Figure 2-26 Tracing LAPD messages on the Pb interface.................................................................................2-30 Figure 2-27 Trace Message on the Um interface dialog box (set TRX as the filter condition).........................2-31 Figure 2-28 Tracing messages on the Um interface...........................................................................................2-32 Figure 2-29 Trace User Message dialog box......................................................................................................2-33 Figure 2-30 Tracing user messages....................................................................................................................2-34 Figure 2-31 Trace the Message at BSC-CBC Interface dialog box...................................................................2-36 Figure 2-32 Tracing Messages on the BSC-CBC Interface ..............................................................................2-37 Figure 2-33 Trace SIG Message on the Gb Interface dialog box.......................................................................2-39 Figure 2-34 Tracing SIG messages on the Gb interface.....................................................................................2-40 Figure 2-35 Trace PTP Message on the Gb Interface dialog box......................................................................2-41 Figure 2-36 Tracing PTP messages on the Gb interface....................................................................................2-42 Figure 2-37 Trace PS Message on the Um Interface dialog box........................................................................2-43 Figure 2-38 Trace PS Message on the Um Interface dialog box........................................................................2-44 Figure 3-1 Set Cell Attributes dialog box..........................................................................................................3-19 Figure 4-1 Immediate assignment procedure.......................................................................................................4-2 Figure 5-1 Classmark update procedure...............................................................................................................5-2 Figure 6-1 Periodic location update procedure....................................................................................................6-2 Figure 7-1 Authentication procedure....................................................................................................................7-3 Figure 7-2 Unsuccessful authentication procedure..............................................................................................7-4 Figure 8-1 Ciphering procedure...........................................................................................................................8-2 Figure 9-1 TMSI reallocation procedure..............................................................................................................9-2 Figure 10-1 Speech channel assignment procedure...........................................................................................10-2 Figure 10-2 Channel mode modification procedure...........................................................................................10-4 Figure 11-1 Early assignment procedure............................................................................................................11-3 Figure 11-2 Late assignment procedure.............................................................................................................11-5 Figure 11-3 Very early assignment procedure...................................................................................................11-6 Figure 12-1 Mobile terminated call establishment procedure............................................................................12-2 Figure 13-1 Normal release procedure...............................................................................................................13-3 Figure 13-2 Local release procedure..................................................................................................................13-5 Figure 14-1 Intra-BSC handover procedure.......................................................................................................14-2 Figure 14-2 Inter-BSC handover procedure.......................................................................................................14-5 Figure 14-3 Inter-MSC handover procedure......................................................................................................14-7 Figure 14-4 GSM-to-UMTS handover procedure..............................................................................................14-8 viii Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd Issue 01 (2008-06-10)
Figures
Figure 14-5 UMTS-to-GSM handover procedure..............................................................................................14-9 Figure 15-1 Call re-establishment procedure.....................................................................................................15-2 Figure 16-1 Intra-BSC directed retry procedure................................................................................................16-3 Figure 16-2 Inter-BSC directed retry procedure................................................................................................16-5 Figure 16-3 Inter-MSC directed retry procedure................................................................................................16-7 Figure 17-1 BSC re-assignment procedure........................................................................................................17-2 Figure 18-1 Queuing procedure.........................................................................................................................18-2 Figure 18-2 Preemption procedure.....................................................................................................................18-3 Figure 19-1 Short message sending procedure of an idle MS............................................................................19-2 Figure 19-2 Short message receiving procedure of an idle MS.........................................................................19-4 Figure 19-3 Short message sending procedure of a busy MS............................................................................19-5 Figure 19-4 Short message receiving procedure of a busy MS..........................................................................19-6 Figure 20-1 Procedure for sending or replacing a message...............................................................................20-2 Figure 20-2 Procedure for deleting an existing message....................................................................................20-3 Figure 20-3 Procedure for querying the CBCH status.......................................................................................20-3 Figure 20-4 Procedure for querying the message status.....................................................................................20-4 Figure 20-5 Procedure for resetting a cell..........................................................................................................20-4 Figure 20-6 Procedure for setting the DRX.......................................................................................................20-5 Figure 20-7 BSC sending an SMS broadcast command message......................................................................20-6 Figure 20-8 BTS sending the BSC a CBCH Loading Indication message........................................................20-6 Figure 20-9 SMSCB procedure..........................................................................................................................20-7 Figure 21-1 Uplink TBF establishment procedure (CCCH phase one access)..................................................21-3 Figure 21-2 Uplink TBF establishment procedure (CCCH phase two access)..................................................21-4 Figure 21-3 Uplink TBF establishment procedure (PACCH access).................................................................21-5 Figure 21-4 Uplink TBF release procedure........................................................................................................21-6 Figure 21-5 Downlink TBF establishment procedure (CCCH).........................................................................21-7 Figure 21-6 Downlink TBF establishment procedure on the uplink PACCH...................................................21-8 Figure 21-7 Downlink TBF establishment procedure on the downlink PACCH...............................................21-9 Figure 21-8 Downlink TBF release procedure.................................................................................................21-10 Figure 21-9 Combined GPRS/IMSI attach procedure.....................................................................................21-11 Figure 21-10 MS initiating the GPRS detach procedure..................................................................................21-13 Figure 21-11 SGSN initiating the GPRS detach procedure.............................................................................21-13 Figure 21-12 HLR initiating the GPRS detach procedure...............................................................................21-14 Figure 21-13 Intra-SGSN routing area update procedure................................................................................21-15 Figure 21-14 Inter-SGSN routing area update procedure................................................................................21-16 Figure 21-15 MS-requested PDP context activation procedure.......................................................................21-17 Figure 21-16 Network-requested PDP context activation procedure...............................................................21-18 Figure 21-17 Procedure of the PDP context deactivation initiated by the MS................................................21-19 Figure 21-18 Procedure of the PDP context deactivation initiated by the SGSN............................................21-20 Figure 21-19 Procedure of the PDP context deactivation initiated by the GGSN...........................................21-20 Figure 21-20 Procedure of the PDP context modification initiated by the SGSN...........................................21-21 Figure 21-21 Circuit paging procedure initiated through the SGSN................................................................21-22 Issue 01 (2008-06-10) Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd ix
Figures
Figure 21-22 Procedure of packet paging........................................................................................................21-23 Figure 21-23 GPRS suspension and resumption procedure.............................................................................21-24 Figure 21-24 Normal PCU cell startup procedure............................................................................................21-27
Issue 01 (2008-06-10)
Tables
Tables
Table 1-1 BSSAP protocol functionality..............................................................................................................1-8 Table 1-2 BSSAP protocol functionality............................................................................................................1-17 Table 1-3 Administrative State...........................................................................................................................1-28 Table 1-4 Operational State................................................................................................................................1-28 Table 1-5 Available State...................................................................................................................................1-28 Table 1-6 Administrative State...........................................................................................................................1-35 Table 1-7 Operational State................................................................................................................................1-36 Table 1-8 Available State...................................................................................................................................1-36 Table 1-9 Administrative State...........................................................................................................................1-45 Table 1-10 Operational State..............................................................................................................................1-46 Table 1-11 Available State.................................................................................................................................1-46 Table 3-1 Contents of System Information Type 1..............................................................................................3-3 Table 3-2 Format of cell channel description.......................................................................................................3-3 Table 3-3 Format of cell channel description.......................................................................................................3-3 Table 3-4 Relation between "S" and "T"..............................................................................................................3-5 Table 3-5 Contents of System Information Type 2, 2bis, 2ter, and 2quater........................................................ 3-6 Table 3-6 Multiband reporting............................................................................................................................. 3-8 Table 3-7 Contents of System Information Type 3..............................................................................................3-8 Table 3-8 Meaning of the CCCH-CONF............................................................................................................. 3-9 Table 3-9 Parameters affecting cell priority in cell selection.............................................................................3-11 Table 3-10 Contents of System Information Type 4..........................................................................................3-12 Table 3-11 Contents of System Information Type 5, 5bis, and 5ter..................................................................3-14 Table 3-12 Contents of System Information Type 6..........................................................................................3-15 Table 3-13 Contents of System Information Type 7..........................................................................................3-15 Table 3-14 Contents of System Information Type 8..........................................................................................3-16 Table 3-15 Contents of System Information Type 13........................................................................................3-16 Table 3-16 Mapping between RACH control parameters in System Information Type 1 and the corresponding parameters on the BSC6000 Local Maintenance Terminal.............................................................................3-18 Table 3-17 Control channel parameters in System Information Type 3 and the corresponding parameters on the BSC6000 Local Maintenance Terminal..........................................................................................................3-20 Table 3-18 Cell option parameters in System Information Type 3 and the corresponding parameters on the BSC6000 Local Maintenance Terminal..........................................................................................................3-20 Table 3-19 Cell selection parameters in System Information Type 3 and the corresponding parameters on the BSC6000 Local Maintenance Terminal..........................................................................................................3-21 Issue 01 (2008-06-10) Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd xi
Tables
HUAWEI BSC6000 Base Station Subsystem BSS Signaling Analysis Guide Table 3-20 Rest Oct parameters in System Information Type 4 and the corresponding parameters on the BSC6000 Local Maintenance Terminal...........................................................................................................................3-22
xii
Issue 01 (2008-06-10)
About This Document
About This Document
Purpose
This document describes the GBSS signaling fundamental, signaling trace, and system information, as well as the procedures such as location update, authentication, encryption, and call procedure.
Product Version
The following table lists the product versions related to this document. Product Name BSC BTS Model BSC6000 BTS3012 BTS3012AE BTS3006C BTS3002E BTS3036/BTS3900 GSM BTS3036A/BTS3900A GSM DBS3036/DBS3900 GSM PCU PCU6000 Product Version V900R008C01 V300R004&V300R005&V300R006 V300R005&V300R006 V300R005&V300R006 V300R005 V300R008 V300R008 V300R008 V300R008
Intended Audience
This document is intended for:
l l l
Network planners Field engineers System engineers

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd 1
Issue 01 (2008-06-10)
About This Document

l l l
Shift operators Network operators Network administrators
Change History
For changes in the document, refer to Changes in BSS Signaling Analysis Guide.
Organization
1 Fundamentals of BSS Signaling The external BSS interfaces, which are the Um interface between the BSS and the MS, the A interface between the BSS and the MSC, and the Gb interface between the BSS and the SGSN, are standard interfaces. The Abis interface between the BSC and the BTS is an internal interface. 2 BSS Signaling Tracing This describes the BSS signaling tracing, which consists of the signaling tracing on the Um interface, Abis interface, A interface, Pb interface, Gb interface, and BSC-CBC interface, and single user signaling tracing. 3 BSS System Information System information (SI) refers to the major radio network parameters on the Um interface such as the network identification parameters, cell selection parameters, system control parameters, and network functional parameters. 4 Immediate Assignment This describes immediate assignment, which consists of the immediate assignment procedure, internal BSC signaling procedure, and abnormal cases and handling suggestions. 5 Classmark Update The MS classmark specifies the service capability, supported frequency bands, power capability, and ciphering capability of an MS in the GSM network. It is categorized into classmark 1, classmark 2, and classmark 3. 6 Location Update In the GSM system, MS location information is stored in the HLR, the VLR, and the MS. When the MS location information is changed, a location update procedure is initiated to maintain consistency among the previous three network elements. 7 Authentication The purpose of authentication is to permit the network to check whether the identity provided by the MS is acceptable and to prevent the private information on the legal subscribers from being stolen. 8 Ciphering Ciphering is used to secure the information exchange between an MS and a BTS. The information consists of the signaling information and the subscriber information. The subscriber information consists of the subscriber data and the subscriber voice. 9 TMSI Reallocation
2 Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd Issue 01 (2008-06-10)
About This Document
The TMSI reallocation takes place in ciphering mode. It is generally related to another procedure, such as location update or call establishment. 10 Speech Channel Assignment The speech channel assignment is the procedure for assigning TCHs to the MS according to the service requests. 11 Mobile Originated Call Mobile originated call refers to a call procedure in which an MS calls another MS or a fixed phone. 12 Mobile Terminated Call Mobile terminated call refers to a call procedure in which an MS is called by another MS or a fixed phone. 13 BSC Release BSC release consists of the normal release procedure and the local release procedure. 14 Handover Handover is one of the basic functions of the GSM. It enables calls to be set up in better cells and reduces call drops. Handover also lowers cross interference. The handover procedure involves handover triggering, handover preparation, handover decision, and handover execution. 15 Call Re-Establishment The call re-establishment procedure allows an MS to resume a connection after a radio link failure. It may take place in a new cell or a new location area. 16 Directed Retry Directed retry is a special type of handover. When no radio resource is available for allocation in a serving cell during channel assignment, the BSS hands over the channel request from the serving cell to a neighbor cell. 17 BSC Re-Assignment This describes BSC re-assignment. BSC re-assignment refers to a TCH assignment procedure initiated by the BSC after the BSC receives an Assignment Failure message from the MS on the SDCCH. BSC re-assignment raises the success rate of assignments on the Um interface. 18 Queuing and Preemption This describes queuing and pre-emption. 19 Short Messages For an idle MS, short messages are transferred on the SDCCH. For a busy MS, however, short messages are transferred on the SACCH. The short message procedure comprises two fundamental procedures: mobile originating short message transfer procedure and mobile terminating short message transfer procedure. 20 Cell Broadcast Messages The short message service cell broadcast (SMSCB) is similar to the paging station broadcast service. The operators broadcast messages to the subscribers in the specified areas. The subscribers that subscribe to the service receive the messages broadcast by the operators.
Issue 01 (2008-06-10) Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd 3
About This Document
21 GPRS This describes the procedure related to PS services, the internal processing procedure, the exceptional procedure, and the handling suggestions.
Conventions
1. Symbol Conventions The following symbols may be found in this document. They are defined as follows Symbol Description Indicates a hazard with a high level of risk that, if not avoided, will result in death or serious injury. Indicates a hazard with a medium or low level of risk which, if not avoided, could result in minor or moderate injury. Indicates a potentially hazardous situation that, if not avoided, could cause equipment damage, data loss, and performance degradation, or unexpected results. Indicates a tip that may help you solve a problem or save your time. Provides additional information to emphasize or supplement important points of the main text.
DANGER
WARNING
CAUTION
TIP
NOTE
2. General Conventions Convention Times New Roman Boldface Italic Courier New 3. Command Conventions Convention Boldface Italic []
4
Description Normal paragraphs are in Times New Roman. Names of files,directories,folders,and users are in boldface. For example,log in as user root . Book titles are in italics. Terminal display is in Courier New.
Description The keywords of a command line are in boldface. Command arguments are in italic. Items (keywords or arguments) in square brackets [ ] are optional.
Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd Issue 01 (2008-06-10)
About This Document
Convention {x | y | ...} [ x | y | ... ] { x | y | ... } * [ x | y | ... ] *
Description Alternative items are grouped in braces and separated by vertical bars.One is selected. Optional alternative items are grouped in square brackets and separated by vertical bars.One or none is selected. Alternative items are grouped in braces and separated by vertical bars.A minimum of one or a maximum of all can be selected. Alternative items are grouped in braces and separated by vertical bars.A minimum of zero or a maximum of all can be selected.
4. GUI Conventions Convention Boldface > Description Buttons,menus,parameters,tabs,window,and dialog titles are in boldface. For example,click OK. Multi-level menus are in boldface and separated by the ">" signs. For example,choose File > Create > Folder .
5. Keyboard Operation Convention Key Key1+Key2 Key1,Key2 Description Press the key.For example,press Enter and press Tab. Press the keys concurrently.For example,pressing Ctrl+Alt+A means the three keys should be pressed concurrently. Press the keys in turn.For example,pressing Alt,A means the two keys should be pressed in turn.
6. Mouse Operation Action Click Double-click Drag Description Select and release the primary mouse button without moving the pointer. Press the primary mouse button twice continuously and quickly without moving the pointer. Press and hold the primary mouse button and move the pointer to a certain position.
Issue 01 (2008-06-10)
1 Fundamentals of BSS Signaling
Fundamentals of BSS Signaling
About This Chapter

The external BSS interfaces, which are the Um interface between the BSS and the MS, the A interface between the BSS and the MSC, and the Gb interface between the BSS and the SGSN, are standard interfaces. The Abis interface between the BSC and the BTS is an internal interface. 1.1 A Interface (TDM) The A interface, which is a standard interface, is a communication interface between the NSS and the BSS. 1.2 A Interface (IP) The A interface, which is a standard interface, is a communication interface between the NSS and the BSS. 1.3 Abis Interface (TDM) The Abis interface lies between the BTS and the BSC. It is an internal interface. 1.4 Abis Interface (HDLC) The Abis interface lies between the BTS and the BSC. It is an internal interface. 1.5 Abis Interface (IP) This describes the Abis interface (IP). The Abis interface lies between the BTS and the BSC. It is an internal interface. 1.6 Um Interface The Um interface lies between an MS and the BTS. It is used for the interworking between the MS and the fixed part of the GSM system. The links on the Um interface are radio links. The Um interface transmits the information about radio resource management, mobility management, and connection management. 1.7 Gb Interface This describes the Gb interface. The Gb interface lies between the BSS and the SGCN. It is a standard interface.
Issue 01 (2008-06-10)
1-1
1.1 A Interface (TDM)

The A interface, which is a standard interface, is a communication interface between the NSS and the BSS. 1.1.1 Protocol Stack on the A Interface (TDM) This describes the protocol stack on the A interface that consists of the physical layer, MTP layer, SCCP layer, and BSSAP layer. 1.1.2 Physical Layer on the A Interface (TDM) This describes the characteristics of the physical layer on the A interface when TDM transmission mode is used, including the interface type, transmission rate, and specifications to comply with. 1.1.3 MTP Layer on the A Interface The MTP layer on the A interface provides reliable signaling message transmission in the signaling network. In case of system failure and signaling network failure, it takes measures to avoid or reduce the message loss, repetition, and out of sequence. 1.1.4 SCCP Layer on the A Interface The SCCP, with the help of MTP L3, provides complete network layer functions and reliable services for information exchange in any form. 1.1.5 BSSAP Layer on the A Interface The BSSAP layer on the A interface is an application layer. It describes two types of messages, BSSMAP messages and DTAP messages.
1.1.1 Protocol Stack on the A Interface (TDM)

This describes the protocol stack on the A interface that consists of the physical layer, MTP layer, SCCP layer, and BSSAP layer. The A interface is defined as the communication interface between the NSS and the BSS, namely, the interface between the MSC and the BSC. The A interface transmits the information about MS management, mobility management, connection management, and service flow control. The A interface is a standard interface and uses the SS7 protocol. The protocol reference model is shown in Figure 1-1.
1-2
Issue 01 (2008-06-10)
Figure 1-1 Protocol stack on the A interface

BSS BSSAP DTAP BSSMAP BSSAP DTAP BSSMAP MSC
Allocation function SCCP MTP Physical layer
Allocation function SCCP MTP
A
DTAP: Direct Transfer Application MTP: Message Transfer Part Part BSSAP: Base Station Subsystem Application Part BSSMAP: Base Station Subsystem Management Application Part SCCP: Signaling Connection Control Part
1.1.2 Physical Layer on the A Interface (TDM)

This describes the characteristics of the physical layer on the A interface when TDM transmission mode is used, including the interface type, transmission rate, and specifications to comply with. In TDM transmission mode, E1/T1 electrical interface and STM-1 optical interface are supported. The transmission rates are as follows:
l l l
E1 transmission rate: 2.048 Mbit/s T1 transmission rate: 1.544 Mbit/s STM-1 transmission rate: 155.52 Mbit/s
The specifications to comply with at the physical layer are as follows:

l l l l l l
E1 complies with the G.703, G.704, and G.823. T1 complies with the G.703, G.704, G.824, and T1.403. STM-1 complies with the G.707, G.957, G.783, and G.825. Frame structure, synchronization, and timing comply with the G.705. Fault management complies with the G.732. CRC4 complies with the G.704.
1.1.3 MTP Layer on the A Interface

The MTP layer on the A interface provides reliable signaling message transmission in the signaling network. In case of system failure and signaling network failure, it takes measures to avoid or reduce the message loss, repetition, and out of sequence.
Issue 01 (2008-06-10) Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd 1-3
The MTP protocols are defined in ITU-T Q.701Q.710 recommendations. The MTP layer comprises three function layers, the signaling data link layer, signaling link layer, and signaling network layer.
Signaling Data Link Layer

Signaling data link layer (L1) transmits signaling in both directions at a rate of 64 kbit/s. Generally, a signaling data link occupies timeslot 16 of a trunk. The specific timeslot is determined through the negotiation between the BSC and the MSC. The timeslot can be used to establish a semi-permanent connection. A signaling data link serves as an information bearer of SS7. One of the important features of the signaling data link is that the link is transparent, that is, the data transmitted on the link cannot be changed. Therefore, equipment such as echo canceler, digital attenuator, and A/u rate converter, cannot be connected to this link.
Signaling Link Function Layer

Signaling link function layer (L2) specifies the functions and procedures for sending signaling to data links. Together with L1, it provides reliable signaling message transmission between two directly connected signaling points. L2 guarantees error-free transmission of message codes when there are bit errors at L1. L2 performs signaling unit delimitation, signaling unit alignment, error detection, error correction, initial alignment, processor fault detection, flow control, and signaling link error rate monitoring.
Signaling Network Function Layer

By controlling the route and performance of the signaling network, signaling network function layer (L3) guarantees reliable transmission of signaling information to the user part, regardless of whether the signaling network is functional or not. The signaling network is functionally classified into the signaling message processing part and the signaling network management part.
l
Signaling message processing part The signaling message processing part sends signaling messages from the user part of a signaling point to the target signaling links or user parts. The user part in the BSS refers to the SCCP only. The signaling message processing part comprises three smaller parts: message routing (MRT), message discrimination (MDC), and message distribution (MDT), as shown in Figure 1-2.
1-4
Issue 01 (2008-06-10)
Figure 1-2 L3 signaling message processing procedure

MTP user part
Message distribution Messages to the local signaling point Messages to the other signaling points Message Message routing discrimination
MTP2 signaling link
Message Routing (MRT) The MRT selects message routes. By using the information contained in the route mark, destination signaling point code (DPC), and signaling link selection code (SLS), the MRT selects a signaling link that transmits the signaling messages to a destination signaling point.
Message Discrimination (MDC) The MDC part receives the messages from L2 to ascertain whether the destination of the messages is the local signaling point.
If the destination of the messages is the local signaling point, the MDC part transmits the message to the MDT part. If the destination of the messages is not the local signaling point, the MDC part transmits the message to the MRT part.
Message Distribution (MDT) The MDT part allocates the messages from the MDC part to the user part, the signaling network management part, and the test & maintenance part.
Signaling network management part The signaling network management part reconstructs the signaling network, and keeps and recovers the normal transmission of signaling units when the signaling network fails. It consists of three smaller parts: signaling traffic management (STM), signaling link management (SLM), and signaling route management (SRM).
Signaling Traffic Management (STM) The STM part transmits the signaling data from one link or route to another or to multiple available links or routes when the signaling network fails. It also temporarily reduces signaling traffic in case of congestion at a signaling point.
Signaling Link Management (SLM) The SLM part recovers, enables, or disconnects the signaling links in the signaling network. It ensures the provisioning of certain pre-determined link groups. The
Issue 01 (2008-06-10)
1-5
connections between signaling data links and signaling terminals are normally established through man-machine commands. The operations in the signaling system cannot automatically change the previous connection relations. The SLM comprises link test, link prohibition and unprohibition, link switchover and switchback, as well as link activation and deactivation.
Signaling Route Management (SRM) The SRM ensures reliable exchange of signaling route availability information between signaling points so that signaling routes can be blocked or unblocked. It comprises prohibited transfer, allowed transfer, controlled transfer, and restricted transfer, as well as signaling route group test and signaling route group congestion test.
1.1.4 SCCP Layer on the A Interface

The SCCP, with the help of MTP L3, provides complete network layer functions and reliable services for information exchange in any form. The network layer services provided by the SCCP are classified into connectionless service and connection-oriented service.
l
The connectionless service indicates that an MS does not establish a signaling or connection in advance, but uses the routing function of the SCCP and of the MTP to directly transmit data in the signaling network. The connectionless service is applicable to the transmission of a small quantity of data. The connection-oriented service indicates that an MS establishes a signaling connection in advance and directly transfers data on the signaling connection, instead of using the route selection function of the SCCP. The connection-oriented service is applicable to the transmission of a large quantity of data, and effectively shortens the delay of batch data transmission.
The SCCP also performs routing and network management functions.

l
The SCCP performs addressing based on the address information such as the destination singling point code (DPC), subsystem number (SSN), and global title (GT). The DPC is the destination signaling point code used by the MTP. The SSN is the subsystem number that are used to identify different SCCP users, such as the ISUP users, MAP users, TCAP users, and BSSAP users in the same node. It helps to compensate the insufficiency of MTP users and to enlarge the addressing scope. The BSS does not use the GT addressing mode, which is not described here. The SCCP performs signaling point state and subsystem state management, active/standby subsystem switchover, status information broadcast, and subsystem state test. The SCCP management (SCMG) maintains the network functions by reselecting a route or adjusting the traffic volume in case of network failure or congestion.
The SCCP protocols are defined in ITU-T Q.711Q.716 recommendations.
1.1.5 BSSAP Layer on the A Interface

The BSSAP layer on the A interface is an application layer. It describes two types of messages, BSSMAP messages and DTAP messages.
Overview of the BSSAP Protocol

The BSSAP protocol describes two types of messages.
1-6 Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd Issue 01 (2008-06-10)

l
BSSMAP messages: these messages are in charge of service flow control, they should be processed by corresponding internal functional modules on the A interface. DTAP messages: for these messages, the A interface is merely equivalent to a transport channel. On the BSS side, DTAP messages are directly transmitted to radio channels. On the NSS side, DTAP messages are transmitted to the specific functional processing units.
The BSSAP protocol is defined in GSM Rec. 08.08 and 04.08.
Typical Messages
l
DTAP messages Based on the functional units of DTAP messages processed on the NSS side, the DTAP messages are classified into Mobile Management (MM) messages and Call Control (CC) messages.
The MM messages include messages related to authentication, Configuration Management (CM) service request, identification request, IMSI detach, location update, MM state, and TMSI reallocation. The CC messages include messages related to alerting, call proceeding, connection, establishment, modification, release, disconnection, notification, state query, and DTMF startup.
BSSMAP messages The BSSMAP messages are classified into connectionless messages and connectionoriented messages.
Connectionless messages
The connectionless messages include block, unblock, handover, resource, reset, and paging messages. The block and unblock messages consist of block, block acknowledge, unblock, and unblock acknowledge messages. The group block and unblock messages consist of group block, group block acknowledge, group unblock, and group unblock acknowledge messages. The handover messages include handover candidate request messages and handover candidate response messages. The resource messages include resource request messages and resource indication messages. The reset messages include reset and reset acknowledge messages. The connection-oriented messages include messages related to assignment, handover, clear, and ciphering. The Assignment messages include the assignment request message, assignment complete message, and assignment failure message. The handover messages include the Handover Request, Handover Request Ackowledge, Handover Command, Handover Complete, and Handover Failure messages. The clear messages include the Clear Request, Clear Command, and Clear Complete messages. The ciphering messages include the Cipher Mode Command and the Cipher Mode Complete messages.
Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd 1-7
Connection-oriented messages
Issue 01 (2008-06-10)
BSSAP Protocol Functionality

The BSSAP protocol functions in connection-oriented mode or connectionless mode. When an MS needs to exchange service-related messages with the NSS on radio channels and there is no MS-related SCCP connection between the BSS and the MSC, a new connection must be established.
l
When an MS sends an Access Request message on the RACH, the BSS assigns a dedicated channel (DCCH or TCH) to the MS. After an L2 connection is established, the BSS starts a connection establishment. When the MSC decides to perform an external handover (the target BSS might be the serving BSS), it must reserve a new DCCH or TCH from the target BSS. Then the MSC starts a connection establishment.
Table 1-1 lists the functions implemented by the BSSAP protocol. Table 1-1 BSSAP protocol functionality Function Assignment Description Assignment ensures that dedicated radio resources are properly allocated or re-allocated to an MS. The BSS automatically processes the random access and immediate assignment of an MS, without the control of the MSC. If the BSS considers that some terrestrial circuits become unavailable or available, it notifies the MSC by initiating a Block/Unblock procedure. Resource indication serves to notify the MSC of the following:
l
Block / Unblock Circuit
Resource Indication
Number of radio resources that can be used as TCHs in the BSS Number of available and allocated radio resources The MSC does not easily obtain the previous information directly from the MSC-controlled services. The MSC must take the information into consideration when the it decides to perform an external handover.
l l
Reset
The purpose of reset is to initialize the faulty BSS or the MSC.

l
If the BSS is faulty and loses all the reference messages about processing, it sends a Reset message to the MSC. Upon receiving the Reset message, the MSC releases the affected calls, deletes the affected reference messages, and sets all the circuits related to the BSS to idle. If the MSC or BSS is only partially faulty, the affected parts can be cleared through the Clear procedure.
1-8
Issue 01 (2008-06-10)
Function Handover Required
Description The BSS may send the MSC a Handover Required message, requesting the MSC to hand over an MS that are allocated with dedicated resources. The handover reasons are as follows:
l l
The BSS detects a radio cause for a handover. The MSC starts a handover candidate enquiry procedure, and the MS is waiting for a handover. Due to congestion, the serving cell must be changed during call establishment, for example, directed retry.
The Handover Required message is resent at a certain interval till one of the following situations occurs:
l
A Handover Command message is received from the MSC. A Reset message is received. All the communications with MSs are disrupted and the processing is stopped. The processing is complete, for example, the call is cleared.
l l
Handover Resource Allocation
Through handover resource allocation, the MSC requests resources from the target BSS based on the handover request, and the target BSS reserves resources and waits for an MS to access the reserved resources (channel). Handover procedure is a procedure in which the MSC instructs an MS to access the radio resources in a target cell. When handover is performed, the original dedicated radio resources and terrestrial resources are maintained until the MSC sends a Clear Command message or until the resources are reset.
l
Handover Procedure
Radio and Terresterial Resource Release
If the MSC needs to release resources, it sends the BSS a Clear Command message, requesting the BSS to release radio resources. Upon receiving the Clear Command message, the BSS starts a clear procedure on the Um interface, sets the configured terrestrial circuits to idle, and responds the MSC with a Clear Complete message. Upon receiving the Clear Complete message, the MSC releases the terrestrial resources. If the BSS needs to release resources, it sends the MSC a Clear Request message. Then the MSC initiates a release procedure to release the specific terrestrial and radio resources.
Issue 01 (2008-06-10)
1-9
Function Paging
Description The paging to an MS is transmitted through the SCCP connectionless service over the BSSMAP. When the BSS receives a Paging Response message on the Um interface, it establishes an SCCP connection to the MSC. The paging response message, which is carried in the Complete L3 Information, is transmitted to the MSC through this SCCP connection. Flow control ensures stable working state of an entity by preventing the entity from receiving too much traffic. Flow control on the A interface is performed through traffic control at the traffic source. It comprises five levels which are performed based on subscriber classes. Classmark update serves to notify a receiving entity of the classmark messages. Generally, the BSS notifies the MSC upon receiving the classmark messages from an MS. When a handover is complete, the MSC sends the new BSS the classmark messages from the relevant MS on the A interface. The cipher mode control procedure allows the MSC to send the Cipher Mode Control message to the BSS and to start the subscriber equipment and the signaling cipher equipment using a correct ciphering key (Kc). The queue indication procedure serves to notify the MSC that the BSS will delay the allocation of some radio resources. The procedure takes effect only when the queuing function is used for traffic channel assignment and traffic channel handover in the BSS. Load indication serves to notify all neighbor BSSs of the traffic state of a cell so that the handover services in an MSC can be controlled as a whole. In a certain period, the neighbor BSSs take the traffic states of neighbor cells into account during a handover.
Flow Control
Classmark Update
Cipher Mode Control
Queue Indication
Load Indication
1.2 A Interface (IP)

The A interface, which is a standard interface, is a communication interface between the NSS and the BSS. 1.2.1 Protocol Stack on the A Interface (IP) This describes the protocol stack on the A interface (IP) that consists of the physical layer, IP layer, SCTP/M3UA layer, SCCP layer, and BSSAP layer. 1.2.2 Physical Layer on the A Interface (IP) This describes the interface type, transmission rate, working mode, and specifications to comply with at the physical layer when the IP transmission mode is used on the A interface.
1.2.3 IP Layer on the A Interface This describes the IP layer on the A interface. This layer supports IPv4 and is responsible for addressing, routing, fragmentation, and reassembly. For related standards, refer to ITEF RFC791. 1.2.4 SCTP/M3UA Layer on the A Interface This describes the SCTP/M3UA layer on the A interface. This layer implements the interworking between SS7 and IP. In addition, the layer carries the MTP3 user information and transmits signaling through the IP network. 1.2.5 SCCP Layer on the A Interface The SCCP, with the help of MTP L3, provides complete network layer functions and reliable services for information exchange in any form. 1.2.6 BSSAP Layer on the A Interface The BSSAP layer on the A interface is an application layer. It describes two types of messages, BSSMAP messages and DTAP messages.
1.2.1 Protocol Stack on the A Interface (IP)

This describes the protocol stack on the A interface (IP) that consists of the physical layer, IP layer, SCTP/M3UA layer, SCCP layer, and BSSAP layer. The A interface is defined as the communication interface between the NSS and the BSS, namely, the interface between the MSC and the BSC. When the IP transmission mode is used on the A interface, the A interface signaling protocol reference model is applied, as shown in Figure 1-3. Figure 1-3 Protocol Stack on the A Interface (IP)
BSSAP DT AP BSSM AP
BSSAP DT AP BSSM AP
Allocation function
Allocation function
SCCP M3UA SCTP IP Physical layer
SCCP M3UA SCTP IP
DTAP: Direct Transfer Application BSSAP: Base Station Subsystem Part Application Part SCCP: Signaling Connection Control Part M3UA: MTP3 User Adaptation layer
BSSMAP: Base Station Subsystem Management Application Part SCTP: Stream Control Transmission Protocol
Issue 01 (2008-06-10)
1-11

IP: Internet Protocol

Physical layer: Ethernet transmission part
When the IP transmission mode is used on the A interface, signaling on the A interface is transmitted through the SIGTRAN system. The transmitted information includes MS management, mobility management, connection management, and service flow control.
1.2.2 Physical Layer on the A Interface (IP)

This describes the interface type, transmission rate, working mode, and specifications to comply with at the physical layer when the IP transmission mode is used on the A interface. IP transmission supports the following types of Ethernet interfaces:
l
FE electrical interface: uses Category 5 twisted-pair wires for data transmission and complies with the 100BASE-TX specification. GE electrical interface: complies with the 1000BASE-T specification. GE optical port: complies with the 1000BASE-LX and 1000BASE-SX specification. FE electrical interface: 10 Mbit/s or 100 Mbit/s GE electrical interface: 10 Mbit/s, 100 Mbit/s, or 1000 Mbit/s GE optical interface: 1000 Mbit/s An electrical interface supports the half-duplex and full-duplex modes and has the automatic negotiation function. The working mode and transmission rate of an electrical port should be determined with full consideration to other network equipment. An optical interface supports only the full-duplex mode and can work only at the rate of 1000 Mbit/s. In addition, an optical interface does not support the automatic negotiation function. RJ45 standard that an electrical interface complies with SFP standard that an optical interface complies with 802.3 protocol that the MAC layer supports
l l
The transmission rates for the three types of interfaces are as follows:
l l l
The working modes of an electrical interface and an optical interface are as follows:
l

l l l
1.2.3 IP Layer on the A Interface

This describes the IP layer on the A interface. This layer supports IPv4 and is responsible for addressing, routing, fragmentation, and reassembly. For related standards, refer to ITEF RFC791.
IP Address
An IP address is a logical IP address that is allocated to uniquely identify an internet host. Each port on the A interface board is assigned an IP address.
IP Routing
When network equipment supporting IP forwarding receives an IP packet, the network equipment checks whether the destination address is the IP address of the local equipment,
multicast address, or broadcast address. If the destination address is the IP address of the local equipment, multicast address, or broadcast address, the network equipment submits the IP packet to a corresponding program for handling. Otherwise, the network equipment forwards the IP packet.
Fragmentation and Reassembly Related Concepts

The process of fragmentation and reassembly is related to the MTU, Identification, Flags, and Fragment Offset.
l
MTU MTU refers to the maximum length of a data frame that can be transmitted on a link. When data at the IP layer needs to be transmitted, packets must be fragmented at the IP layer and reassembled on the receiving end if the length of a data frame, which is yielded by IP header plus IP data part, is greater than the MTU at the data link layer.
Identification There is a 16-bit identification filed in the IP header. This filed uniquely identifies each packet sent by a host. When a packet is fragmented into pieces, the identification field is copied into all fragments on fragmentation. When a packet is reassembled, the identification field is used to distinguish the fragments of one datagram from those of another.
Flags The flags field is behind the identification field and has 3 bits. The purposes of each bit are as follows:

Bit 0: reserved, must be zero. Bit 1: (DF) 0 = May Fragment, 1 = Don't Fragment. When the DF field is 1, packets are discarded if these packets need to be fragmented. Bit 2: (MF) 0 = Last Fragment, 1 = More Fragments.
Fragment Offset The Fragment Offset field is behind the flags field and has 13 bits. This field identifies the fragment location, relative to the beginning of the original unfragmented datagram. Irrespective of how many times datagrams are fragmented, the fragment offset fields of all fragments tell the receiver the positions of fragments in the original datagrams. These fields provide sufficient information to reassemble datagrams.

For a complete datagram, MF and Fragment Offset are set to zero. When either MF or Fragment Offset is not set to zero, you can infer that a datagram is fragmented. Fragment Offset of the first fragment must be zero. Fragment Offset is measured in units of 8 octets (64 bits). Except the last fragment, the data portions of other fragments must be an integral multiple of 8 octets. This is because that the Fragment Offset field has 13 bits but a datagram has 16 bits.
Fragmentation
The fragmentation of a datagram at the IP layer has the following situations:
l
If the length of a datagram is less than or equal to that of the MTU, the internet protocol directly sends the datagram to the next hop.
Issue 01 (2008-06-10)
1-13

l
If the length of a datagram is greater than MTU and moreover the datagram cannot be fragemented, the internet protocol discards the datagram and then displays the ICMP error control datagram. If the length of a datagram is greater than MIU and moreover the datagram can be fragmented, the internet protocol fragments the datagram. If the length of a datagram is greater than MTU and moreover the datagram can be fragmented, the internet protocol cuts the datagram into two fragments. The first fragment, which is less than or equal to MTU, is set to an integral multiple of 8 octets. The second fragment is the rest of the datagram. The internet protocol sends the first fragment to the next hop. If the second fragment is still greater than MTU, continute to cut the datagram until all fragments are less than MTU.
The procedure for fragmenting a datagram at the IP layer is as follows: 1.
2. 3.
When MTU is used as the basic length to fragment a datagram, the fragmentation efficiency is highest. In practise, it is not mandatory to use MTU as the basic fragmentation length. During fragmentation, information at the transport layer is located in the first fragment. Other fragments have only common IP datagrams and do not contain information at the transport layer.
Reassembly
When one fragment of a datagram arrives, the receiver does not a datagram that has the same datagram identification previously. Then, the reassembly procedure is initiated. The procedure for fragmenting a datagram at the IP layer is as follows: 1. 2. 3. 4. 5. 6. 7. 8. When the first fragment of a datagram is received (Fragment Offset is zero), the data from the fragment is placed in the data buffer that is dedicated to the first fragment. When other fragments except the first fragment and the last fragment are received, the data from these fragments is placed in the public data buffer. If the last fragment (that is the more fragments field is zero) is received, the total data length is computed (Fragment Offest x 8 + data length of the last fragment). A data buffer is assigned to the datagram, the datagram is reassembled, and the timer is started. The timer is refreshed every time a fragment is received. The received fragments are padded to the data buffer according to attached offset. The last fragment is used if some received fragments are identical. If the timer runs out during datagram reassembly, datagram ressembly is over and all the received fragments are discarded. Datagram ressembly is over when all the fragments are received.
1.2.4 SCTP/M3UA Layer on the A Interface

This describes the SCTP/M3UA layer on the A interface. This layer implements the interworking between SS7 and IP. In addition, the layer carries the MTP3 user information and transmits signaling through the IP network.
1-14
Issue 01 (2008-06-10)
SCTP
The Stream Control Transmission Protocol (SCTP) is a reliable transmission protocol based on a connectionless network such as the IP network. The SCTP can transmit signaling on the PSTN or other networks through the IP network. SCTP has the following functions:
l l l l l l
Point-to-point transmission Sequenced stream transmission Disassembling and reassembling of user data Binding of data packets Path management Verification of message packets
M3UA
The MTP3 User Adaptation Layer (M3UA) implements the interworking between SS7 and IP and carries the MTP3 user information through the IP network. M3UA is a subprotocol of the SIGTRAN protocol stack and provides services based on SCTP. M3UA has the following functions:
l l
Supporting the transmission of all MTP3 user information, such as SUP, TUP, or SCCP Supporting the seamless interaction between the same type of MTP3s that are located in different network areas, such as the interaction between the ISUP of the SCN and the ISUP of the IP network Supporting the SCTP connection and service management between SG and MGC, or between SG and database within the IP network, or between SG and IPSP. SCTP connection implements redundancy protection in active/standby mode or load balancing mode. Supporting the interworking with the MTP3 network management function Supporting the address interpretation mapping between SS7 and IP Supporting redundancy management Supporting SCTP flow mapping Supporting congestion control Supporting seamless network management interaction
l l l l l l
1.2.5 SCCP Layer on the A Interface

The SCCP, with the help of MTP L3, provides complete network layer functions and reliable services for information exchange in any form. The network layer services provided by the SCCP are classified into connectionless service and connection-oriented service.
l
The connectionless service indicates that an MS does not establish a signaling or connection in advance, but uses the routing function of the SCCP and of the MTP to directly transmit data in the signaling network. The connectionless service is applicable to the transmission of a small quantity of data. The connection-oriented service indicates that an MS establishes a signaling connection in advance and directly transfers data on the signaling connection, instead of using the route
Issue 01 (2008-06-10)
selection function of the SCCP. The connection-oriented service is applicable to the transmission of a large quantity of data, and effectively shortens the delay of batch data transmission. The SCCP also performs routing and network management functions.
l
The SCCP performs addressing based on the address information such as the destination singling point code (DPC), subsystem number (SSN), and global title (GT). The DPC is the destination signaling point code used by the MTP. The SSN is the subsystem number that are used to identify different SCCP users, such as the ISUP users, MAP users, TCAP users, and BSSAP users in the same node. It helps to compensate the insufficiency of MTP users and to enlarge the addressing scope. The BSS does not use the GT addressing mode, which is not described here. The SCCP performs signaling point state and subsystem state management, active/standby subsystem switchover, status information broadcast, and subsystem state test. The SCCP management (SCMG) maintains the network functions by reselecting a route or adjusting the traffic volume in case of network failure or congestion.
The SCCP protocols are defined in ITU-T Q.711Q.716 recommendations.
1.2.6 BSSAP Layer on the A Interface

The BSSAP layer on the A interface is an application layer. It describes two types of messages, BSSMAP messages and DTAP messages.
Overview of the BSSAP Protocol

The BSSAP protocol describes two types of messages.
l
BSSMAP messages: these messages are in charge of service flow control, they should be processed by corresponding internal functional modules on the A interface. DTAP messages: for these messages, the A interface is merely equivalent to a transport channel. On the BSS side, DTAP messages are directly transmitted to radio channels. On the NSS side, DTAP messages are transmitted to the specific functional processing units.
The BSSAP protocol is defined in GSM Rec. 08.08 and 04.08.
Typical Messages
l
DTAP messages Based on the functional units of DTAP messages processed on the NSS side, the DTAP messages are classified into Mobile Management (MM) messages and Call Control (CC) messages.
The MM messages include messages related to authentication, Configuration Management (CM) service request, identification request, IMSI detach, location update, MM state, and TMSI reallocation. The CC messages include messages related to alerting, call proceeding, connection, establishment, modification, release, disconnection, notification, state query, and DTMF startup.
BSSMAP messages The BSSMAP messages are classified into connectionless messages and connectionoriented messages.
1-16
Issue 01 (2008-06-10)
Connectionless messages
The connectionless messages include block, unblock, handover, resource, reset, and paging messages. The block and unblock messages consist of block, block acknowledge, unblock, and unblock acknowledge messages. The group block and unblock messages consist of group block, group block acknowledge, group unblock, and group unblock acknowledge messages. The handover messages include handover candidate request messages and handover candidate response messages. The resource messages include resource request messages and resource indication messages. The reset messages include reset and reset acknowledge messages. The connection-oriented messages include messages related to assignment, handover, clear, and ciphering. The Assignment messages include the assignment request message, assignment complete message, and assignment failure message. The handover messages include the Handover Request, Handover Request Ackowledge, Handover Command, Handover Complete, and Handover Failure messages. The clear messages include the Clear Request, Clear Command, and Clear Complete messages. The ciphering messages include the Cipher Mode Command and the Cipher Mode Complete messages.
Connection-oriented messages
BSSAP Protocol Functionality

The BSSAP protocol functions in connection-oriented mode or connectionless mode. When an MS needs to exchange service-related messages with the NSS on radio channels and there is no MS-related SCCP connection between the BSS and the MSC, a new connection must be established.
l
When an MS sends an Access Request message on the RACH, the BSS assigns a dedicated channel (DCCH or TCH) to the MS. After an L2 connection is established, the BSS starts a connection establishment. When the MSC decides to perform an external handover (the target BSS might be the serving BSS), it must reserve a new DCCH or TCH from the target BSS. Then the MSC starts a connection establishment.
Table 1-2 lists the functions implemented by the BSSAP protocol. Table 1-2 BSSAP protocol functionality Function Assignment Description Assignment ensures that dedicated radio resources are properly allocated or re-allocated to an MS. The BSS automatically processes the random access and immediate assignment of an MS, without the control of the MSC.
Issue 01 (2008-06-10)
Function Block / Unblock Circuit
Description If the BSS considers that some terrestrial circuits become unavailable or available, it notifies the MSC by initiating a Block/Unblock procedure. Resource indication serves to notify the MSC of the following:
l
Resource Indication
Number of radio resources that can be used as TCHs in the BSS Number of available and allocated radio resources The MSC does not easily obtain the previous information directly from the MSC-controlled services. The MSC must take the information into consideration when the it decides to perform an external handover.
l l
Reset
The purpose of reset is to initialize the faulty BSS or the MSC.

l
If the BSS is faulty and loses all the reference messages about processing, it sends a Reset message to the MSC. Upon receiving the Reset message, the MSC releases the affected calls, deletes the affected reference messages, and sets all the circuits related to the BSS to idle. If the MSC or BSS is only partially faulty, the affected parts can be cleared through the Clear procedure.
Handover Required
The BSS may send the MSC a Handover Required message, requesting the MSC to hand over an MS that are allocated with dedicated resources. The handover reasons are as follows:
l l
The BSS detects a radio cause for a handover. The MSC starts a handover candidate enquiry procedure, and the MS is waiting for a handover. Due to congestion, the serving cell must be changed during call establishment, for example, directed retry.
The Handover Required message is resent at a certain interval till one of the following situations occurs:
l
A Handover Command message is received from the MSC. A Reset message is received. All the communications with MSs are disrupted and the processing is stopped. The processing is complete, for example, the call is cleared.
l l
1-18
Issue 01 (2008-06-10)
Function Handover Resource Allocation
Description Through handover resource allocation, the MSC requests resources from the target BSS based on the handover request, and the target BSS reserves resources and waits for an MS to access the reserved resources (channel). Handover procedure is a procedure in which the MSC instructs an MS to access the radio resources in a target cell. When handover is performed, the original dedicated radio resources and terrestrial resources are maintained until the MSC sends a Clear Command message or until the resources are reset.
l
Handover Procedure
Radio and Terresterial Resource Release
If the MSC needs to release resources, it sends the BSS a Clear Command message, requesting the BSS to release radio resources. Upon receiving the Clear Command message, the BSS starts a clear procedure on the Um interface, sets the configured terrestrial circuits to idle, and responds the MSC with a Clear Complete message. Upon receiving the Clear Complete message, the MSC releases the terrestrial resources. If the BSS needs to release resources, it sends the MSC a Clear Request message. Then the MSC initiates a release procedure to release the specific terrestrial and radio resources.
Paging
The paging to an MS is transmitted through the SCCP connectionless service over the BSSMAP. When the BSS receives a Paging Response message on the Um interface, it establishes an SCCP connection to the MSC. The paging response message, which is carried in the Complete L3 Information, is transmitted to the MSC through this SCCP connection. Flow control ensures stable working state of an entity by preventing the entity from receiving too much traffic. Flow control on the A interface is performed through traffic control at the traffic source. It comprises five levels which are performed based on subscriber classes. Classmark update serves to notify a receiving entity of the classmark messages. Generally, the BSS notifies the MSC upon receiving the classmark messages from an MS. When a handover is complete, the MSC sends the new BSS the classmark messages from the relevant MS on the A interface.
Flow Control
Classmark Update
Issue 01 (2008-06-10)
1-19
Function Cipher Mode Control
Description The cipher mode control procedure allows the MSC to send the Cipher Mode Control message to the BSS and to start the subscriber equipment and the signaling cipher equipment using a correct ciphering key (Kc). The queue indication procedure serves to notify the MSC that the BSS will delay the allocation of some radio resources. The procedure takes effect only when the queuing function is used for traffic channel assignment and traffic channel handover in the BSS. Load indication serves to notify all neighbor BSSs of the traffic state of a cell so that the handover services in an MSC can be controlled as a whole. In a certain period, the neighbor BSSs take the traffic states of neighbor cells into account during a handover.
Queue Indication
Load Indication
1.3 Abis Interface (TDM)

The Abis interface lies between the BTS and the BSC. It is an internal interface. 1.3.1 Protocol Stack on the Abis Interface (TDM) The protocol stack on the Abis interface consists of the physical layer, LAPD layer, and layer 3. 1.3.2 Abis Interface Structure The Abis interface supports three types of internal BTS configurations. 1.3.3 Physical Layer on the Abis Interface (TDM) This describes the characteristics of the physical layer on the Abis interface when TDM transmission mode is used, including the interface type, transmission rate, and specifications to comply with. 1.3.4 LAPD Layer on the Abis Interface The data link layer (L2) on the Abis interface uses the LAPD protocol. It receives data from the physical layer (L1) and provides connection-oriented or connectionless services for L3. 1.3.5 Layer 3 Traffic Management Messages on the Abis Interface L3 traffic management messages on the Abis interface enables the MS to exchange information with the BSS or NSS on the Um interface and to perform some radio resource management functions under the control of the BSC. 1.3.6 Layer 3 OM Messages on the Abis Interface This describes the L3 OM messages on the Abis interface.
1.3.1 Protocol Stack on the Abis Interface (TDM)

The protocol stack on the Abis interface consists of the physical layer, LAPD layer, and layer 3. Figure 1-4 shows the protocol stack on the Abis interface.
Figure 1-4 Protocol stack on the Abis interface

BTS BSC RR BTSM LAPD Layer1 BTSM LAPD Layer1
Abis interface
BTSM: BTS Management RR: Radio Resource Management LAPD: Link Access Protocol on the D Channel
The following describes the Abis interface protocol stack:

l
Layer 1 on the Abis interface is a bottom-layer driver based on the hardware. It transfers data to the physical link. The layer 2 protocol on the Abis interface is based on the LAPD. The LAPD addresses a Transceiver (TRX) or Base Control Function (BCF) through the Terminal Equipment Identifier (TEI). The LAPD uses different logical links for message transmissions.

Radio signaling links (RSLs) transmit service management messages. Operation and maintenance links (OMLs) transmit network management messages. Layer 2 management links (L2MLs) transmit L2 management messages.
RR messages are mapped onto the BSSAP by the BSC. Most RR messages are transparently transmitted by the BTS, except for some messages that must be interpreted and executed. For example, ciphering, random access, paging, and assignment messages are processed by the BTS Management (BTSM) entities in the BSC and in the BTS. Neither the BSC nor the BTS interprets Connection Management (CM) messages or Mobility Management (MM) messages. These messages are transmitted on the A interface by the Direct Transfer Application Part (DTAP). On the Abis interface, DTAP messages are transmitted as transparent messages.
1.3.2 Abis Interface Structure

The Abis interface supports three types of internal BTS configurations. Figure 1-5 shows the Abis interface structure. The three types of BTS configurations on the Abis interface are as follows:
l l l
A single TRX Multiple TRXs connected to the BSC through one physical link Multiple TRXs connected to the BSC through different physical links
Issue 01 (2008-06-10)
1-21
Figure 1-5 Abis interface structure

BSS Abis TRX BCF TRX A MSC BSC TRX Abis TRX BCF Abis TRX TRX TRX TRX BCF BTS3 BTS2 BTS1
Transceiver (TRX) is a functional entity defined in the GSM that supports eight physical channels of one TDMA frame. The Base Control Function (BCF) is a functional entity that performs common control functions, including BTS initialization, software loading, channel configuration, and operation and maintenance. Traffic channels of 8 kbit/s, 16 kbit/s, and 64 kbit/s, which carry speech or data from radio channels Signaling channels of 16 kbit/s, 32 kbit/s, and 64 kbit/s, which carry signaling between the BSC and an MS, and between the BSC and the BTS
The following two types of channels are on the Abis interface:

l
A terminal equipment identifier (TEI) is assigned to obtain the unique address of a TRX. Each BCF has a unique TEI. Three different logical links are defined with a TEI, as shown in Figure 1-6.
l l l
RSL: used to support traffic management procedures, one for each TRX OML: used to support network management procedures, one for each BCF L2ML: used to transmit L2 management messages
1-22
Issue 01 (2008-06-10)
Figure 1-6 Logical links on the Abis interface

BSC RSL SAPI=0 OML SAPI=62 L2ML SAPI=63 BCF RSL SAPI=0 LAYER 2 TEI OML SAPI=62 L2ML SAPI=63 BCF RSL SAPI=0 OML SAPI=62 MANA GEMENT L2ML SAPI=63 BCF OML SAPI=62 L2ML SAPI=63 BCF TEI4 TRX TEI3 TRX TEI2 BTS
TRX TEI1
BCF
1.3.3 Physical Layer on the Abis Interface (TDM)

This describes the characteristics of the physical layer on the Abis interface when TDM transmission mode is used, including the interface type, transmission rate, and specifications to comply with. In TDM transmission mode, E1/T1 electrical interface and STM-1 optical interface are supported. The transmission rates are as follows:
l l l
E1 transmission rate: 2.048 Mbit/s T1 transmission rate: 1.544 Mbit/s STM-1 transmission rate: 155.52 Mbit/s
The specifications to comply with on the physical layer are as follows:

l l l l l l
E1 complies with the G.703, G.704, and G.823. T1 complies with the G.703, G.704, G.824, and T1.403. STM-1 complies with the G.707, G.957, G.783, and G.825. The frame structure, synchronization, and timing comply with the G.705. The fault management complies with the G.732. CRC4 complies with the G.704.
1.3.4 LAPD Layer on the Abis Interface

The data link layer (L2) on the Abis interface uses the LAPD protocol. It receives data from the physical layer (L1) and provides connection-oriented or connectionless services for L3.
Overview
The Service Access Point (SAP) of L2 is the connection point for providing services for L3. An SAP is identified by a Service Access Point Identifier (SAPI).
l
From the perspective of L3, a data link connection endpoint is identified by a data link connection endpoint identifier. From the perspective of L2, a data link connection endpoint is identified by a Data Link Connection Identifier (DLCI).
For the information exchange between two or more L3 entities, data links must be established between L3 entities. The co-operation between L2 entities is controlled by the protocol of the peer layer. The message units at L2 are transmitted between L2 entities through L1. Inter-layer service requests are processed through service primitives.
Function
The LAPD reliably transfers end-to-end information between L3 entities through the D channel. Specifically, the LAPD supports:
l l
Multiple terminal devices between MSs and physical ports Multiple L3 entities
The functions of the LAPD layer on the Abis interface are as follows:
l l
Providing one or multiple data links on the D channel Delimiting, locating, and transparently transmitting frames so that a string of bits transmitted in the form of frames on the D channel can be identified Controlling and keeping the sequence of frames Checking for transmission errors, format errors, and operation errors on data link connections Making recoveries based on the detected transmission errors, format errors, and operation errors Notifying the management layer entities of unrecoverable errors Performing flow control
l l
l l
The LAPD layer on the Abis interface provides the means for information transfer between multiple combinations of data link connection points. The information may be transferred through point-to-point data link connections or broadcast data link connections.
1.3.5 Layer 3 Traffic Management Messages on the Abis Interface

L3 traffic management messages on the Abis interface enables the MS to exchange information with the BSS or NSS on the Um interface and to perform some radio resource management functions under the control of the BSC. In terms of processing, traffic management messages are classified into transparent and nontransparent messages.
l
The transparent messages refer to the messages directly forwarded without interpretation or processing by the BTS.
1-24

l
The non-transparent messages refer to the messages that are transmitted between the BSC and the BTS and that must be processed and structured by the BTS. Radio link layer management messages that are used to manage the data link layer on radio channels Dedicated channel management messages that are used to manage dedicated channels such as the SDCCH and TCH Common control channel management messages that are used to manage common control channels TRX management messages that are used to manage TRXs
NOTE
In terms of functions, traffic management messages are classified into the following:
l
The transparency and group of traffic management messages are determined by the message discriminator at the header of the messages.
Radio link management procedures

Radio link management procedures consist of the following:
l
Link establishment indication procedure: used by the BTS to notify the BSC that an MSoriginated multi-frame-mode link establishment is successful. Upon receiving the indication from the BTS, the BSC establishes an SCCP link to the MSC. Link establishment request procedure: used by the BSC to request the establishment of a multi-frame link on a radio channel. Link release indication procedure: used by the BTS to notify the BSC that an MS-initiated radio link release is complete. Link release request procedure: used by the BSC to request the release of a radio link. Transmission of transparent L3 messages on the Um interface in acknowledged mode: used by the BSC to request the transmission of a transparent Radio Interface Layer 3 (L3) message in acknowledged mode. Reception of transparent L3 messages on the Um interface in acknowledged mode: used by the BTS to notify the BSC that a transparent L3 message is received on the Um interface in acknowledged mode. Transmission of transparent RIL3 messages on the Um interface in unacknowledged mode: used by the BSC to request the transmission of a transparent L3 message on the Um interface in unacknowledged mode. Reception of transparent RIL3 messages on the Um interface in unacknowledged mode: used by the BTS to notify the BSC that a transparent L3 message is received on the Um interface in unacknowledged mode. Link error indication procedure: used by the BTS to notify the BSC in case of errors at the radio link layer.
l l
Dedicated Channel Management Procedures

The dedicated channel management procedures consist of the following:
l
Channel activation procedure: used by the BSC to request the BTS to activate a dedicated channel for an MS. Then the BSC assigns the activated channel to the MS through an Immediate Assignment, Assignment Command, Additional Assignment, or Handover Command message.
Issue 01 (2008-06-10)

l
Channel mode modification procedure: used by the BSC to request the BTS to change the mode of an activated channel. Handover detection procedure: used on the Abis interface between the target BTS and the target BSC to detect the access of an MS being handed over. Ciphering mode command procedure: used to start the ciphering procedure defined in GSM Rec. 04.08. Measurement report procedure: consists of the mandatory basic measurement report procedure and optional measurement report preprocessing procedure. The BTS reports all the parameters related to handover decisions to the BSC through this procedure. SACCH deactivation procedure: used by the BSC to deactivate the SACCH related to a TRX according to the channel release procedure defined in GSM Rec. 04.08. Radio channel release procedure: used by the BSC to release a radio channel that is no longer needed. MS power control procedure: used by the BSS to control the transmit power of an MS for which a channel is already activated. The power control decision must be performed in the BSC. It can also be performed in the BTS. BTS transmit power control procedure: used by the BSS to control the transmit power of a TRX with an activated channel. The BTS transmit power control decision must be performed in the BSC. It can also be performed in the BTS. Connection failure procedure: used by the BTS to notify the BSC that an activated dedicated channel is unavailable. Physical context request procedure: used by the BSC to obtain the information about the physical context of a radio channel prior to a channel change. It is an optional procedure. SACCH information modification procedure: used by the BSC to request the BTS to change the filling system information on a specific SACCH.
Common channel management procedures

The common channel management procedures consist of the following:
l
MS-initiated channel request procedure: triggered when a TRX detects a Channel Request message from an MS. Paging procedure: used to page an MS on a specific paging sub-channel. This procedure is used in the mobile terminated call. It is initiated by the MSC through the BSC. Based on the IMSI of the called MS, the BSC determines the paging group to be used. Then it sends the BTS the paging group number together with the identity of the MS. Immediate assignment procedure: used by the BSC to immediately assign a dedicated channel to an MS when the MS accesses the BTS. Delete indication procedure: used by the BTS to notify the BSC that an Immediate Assign Command message is deleted due to AGCH overload. CCCH load indication procedure: used by the BTS to notify the BSC of the load on a specified CCCH if the load exceeds the preset threshold on the OMC. The indication period is also set on the OMC. Broadcast information modification procedure: used by the BSC to notify the BTS of the new system information to be broadcast on the BCCH. Short message service cell broadcast procedure: used by the BSC to request short message service cell broadcast messages from the BTS.
1-26
TRX management procedures

The TRX management procedures consist of the following:
l
SACCH filling information modify procedure: used by the BSC to notify the BTS of the new system information to be used as filling information on all downlink SACCHs. Radio resource indication procedure: used by the BTS to notify the BSC of the interference levels on the idle channels of a TRX. Flow control procedure: used by the Frame Unit Controller (FUC) in a TRX to notify the BSC of the TRX overload due to CCCH overload, ACCH overload, or TRX processor overload. Error reporting procedure: used by the BTS to notify the BSC of the detected downlink message errors, which cannot be reported through any other procedure.
1.3.6 Layer 3 OM Messages on the Abis Interface

This describes the L3 OM messages on the Abis interface.
OM Information Model
The OM information model consists of the following:
l
Management objects The management objects are site, cell, carrier (TRX), and channel. Figure 1-7 shows the management objects. Figure 1-7 Management objects
SITE
CELL 0
CELL 1
CELL n
TRX0
TRX1
TRXm
BTS
TRX
Chann el 0
l
Chann el 1
Chanel 7
Addressing of management objects Network management messages are addressed through the classes and instances of the management objects. Each object instance in the BTS has a complete L2 connection description. The first established connection is assigned a semi-permanent or permanent default TEI. The subsequent connections are assigned the TEIs provided during the establishment of TEI procedures. Object instances can also use L3 addresses. The mixed use of L2 addressing and L3 addressing enables one site to have one or multiple physical links.
Issue 01 (2008-06-10)
1-27

l
Management object state A management object can be in three states, the administrative state, operational state, and availability state. For details, see Table 1-3, Table 1-4, and Table 1-5. The available state further describes the operational state, and only the BSC controls the administrative state. Table 1-3 Administrative State Status Locked Description The BSC has disconnected all the calls passing this management object, and no new services can be connected to this object. No new services can be connected to this management object, and ongoing calls are maintained. New services can be connected to this management object.
Shut Down Unlocked
Table 1-4 Operational State Status Disabled Enabled Description Resources are totally inoperable and can no longer provide services for MSs. Resources are partially or fully operable.
Table 1-5 Available State Status In Test Failed Power Off Offline Description The resource is undergoing a test procedure. The operational state is disabled. The resource has an internal fault that prevents it from operating. The operational state is disabled. The resource requires power and is not powered on. The operational state is disabled. The resource requires automatic or manual operations to make it available for use. The operational state is disabled. The resource cannot operate because some other resources on which it depends are unavailable. The operational state is disabled. The service is degraded due to some reasons such as speed or capacity. The operational state is enabled.
Dependency
Degraded
1-28
Issue 01 (2008-06-10)
Status Not Installed
Description The hardware or software of the management object is not installed. The operational state is disabled.
Basic Procedures
All procedures are based on formatted OM messages. Most formatted OM messages initiated by the BSC or the BTS require the peer L3 to respond with formatted OM messages. This pair of formatted OM messages or a formatted OM message that does not require a response is called a basic procedure. All formatted OM messages are sent on L2 in the form of I frames. A group of messages, also called structured procedures, are based on the combination of some basic procedures. When there is no response to a formatted OM message from the peer L3 upon L3 timer expiry, the basic procedure is considered as not "completed". For a specific object instance, if a certain basic procedure is not complete, the system does not start the subsequent basic procedures. When there is no response (ACK or NACK) in the previous basic procedure before L3 timeout, no subsequent basic procedure is sent to this object instance. The default value for L3 timeout is 10 seconds.
l
If part of an original message is not understood or supported, the entire message is discarded. An ACK message from an object instance indicates an affirm response. It is used to notify the sender that the command is executed or will be executed. An NACK message from an object instance indicates a disaffirm response. It is used to notify the sender of the unsuccessful execution of the command and of the failure cause.
The basic procedures are classified into the following:

l l l l l l l l
Software loading management procedure Abis interface management procedure Transmission management procedure Um interface management procedure Test management procedure State management and event report procedure Equipment state management procedure Other procedures
1.4 Abis Interface (HDLC)

The Abis interface lies between the BTS and the BSC. It is an internal interface. 1.4.1 Protocol Stack on the Abis Interface (HDLC) This describes the protocol stack on the Abis interface. The protocol stack on the Abis interface consists of the physical layer, HDLC layer, LAPD layer, and layer 3. 1.4.2 Physical Layer on the Abis Interface (HDLC)
This describes the interface type, transmission rate, working mode, and specifications to comply with at the physical layer when the HDLC transmission mode is used on the Abis interface. 1.4.3 HDLC Layer on the Abis Interface This describes the High-level Data Link Control (HDLC) layer on the Abis interface. The HDLC is a bit-oriented high-level data link control procedure. It provides the powerful error detection function to ensure reliable data transmission. 1.4.4 LAPD Layer on the Abis Interface The data link layer (L2) on the Abis interface uses the LAPD protocol. It receives data from the physical layer (L1) and provides connection-oriented or connectionless services for L3. 1.4.5 Layer 3 Traffic Management Messages on the Abis Interface L3 traffic management messages on the Abis interface enables the MS to exchange information with the BSS or NSS on the Um interface and to perform some radio resource management functions under the control of the BSC. 1.4.6 Layer 3 OM Messages on the Abis Interface This describes the L3 OM messages on the Abis interface.
1.4.1 Protocol Stack on the Abis Interface (HDLC)

This describes the protocol stack on the Abis interface. The protocol stack on the Abis interface consists of the physical layer, HDLC layer, LAPD layer, and layer 3. Figure 1-8 shows the protocol stack on the Abis interface (HDLC). Figure 1-8 Protocol stack on the Abis interface (HDLC)
BTS RSL/OML LAPD HDLC Layer1 BSC RSL/OML LAPD HDLC Layer1
Abis interface
HDLC: High Level Data Link Control OML: Operation and Maintenance Link
LAPD: Link Access Procedure on the D Channel RSL: Radio Signaling Link
1.4.2 Physical Layer on the Abis Interface (HDLC)

This describes the interface type, transmission rate, working mode, and specifications to comply with at the physical layer when the HDLC transmission mode is used on the Abis interface. When the HDLC transmission mode is used on the Abis interface, the physical layer supports the E1/T1 electrical port at the following rates:
l l
E1 transmission rate: 2.048 Mbit/s T1 transmission rate: 1.544 Mbit/s


l l l l l
E1 complies with the G.703, G.704, and G.823. T1 complies with the G.703, G.704, G.824, and T1.403. The frame structure, synchronization, and timing comply with the G.705. Fault management complies with the G.732. CRC4 complies with the G.704.
1.4.3 HDLC Layer on the Abis Interface

This describes the High-level Data Link Control (HDLC) layer on the Abis interface. The HDLC is a bit-oriented high-level data link control procedure. It provides the powerful error detection function to ensure reliable data transmission. The HDLC protocol, which is a kind of protocol at the data link layer, ensures that the next-layer data can be exactly received. The HDLC protocl has the following features:
l l l l
Data messages can be transmitted transparently. Full-duplex communication is used. The window mechanism and piggyback acknowledgment are used. The frame check sequence is used and information frames are numbered to prevent the incomplete receiving of data or the resending of data. Therefore, transmission is reliable. The transmission control function and the transmission processing function are independent and can be flexibly used. Phase of establishing data links Phase of transferring information frames Phase of releasing data links
HDLC is responsible for controlling data transmission and generally has three phases:
l l l

Overview
l
Function
l l
l l
l l
l l

l
The transparent messages refer to the messages directly forwarded without interpretation or processing by the BTS. The non-transparent messages refer to the messages that are transmitted between the BSC and the BTS and that must be processed and structured by the BTS. Radio link layer management messages that are used to manage the data link layer on radio channels Dedicated channel management messages that are used to manage dedicated channels such as the SDCCH and TCH Common control channel management messages that are used to manage common control channels TRX management messages that are used to manage TRXs
NOTE
l
1-32
Issue 01 (2008-06-10)

l
l l

l
Channel activation procedure: used by the BSC to request the BTS to activate a dedicated channel for an MS. Then the BSC assigns the activated channel to the MS through an Immediate Assignment, Assignment Command, Additional Assignment, or Handover Command message. Channel mode modification procedure: used by the BSC to request the BTS to change the mode of an activated channel. Handover detection procedure: used on the Abis interface between the target BTS and the target BSC to detect the access of an MS being handed over. Ciphering mode command procedure: used to start the ciphering procedure defined in GSM Rec. 04.08. Measurement report procedure: consists of the mandatory basic measurement report procedure and optional measurement report preprocessing procedure. The BTS reports all the parameters related to handover decisions to the BSC through this procedure. SACCH deactivation procedure: used by the BSC to deactivate the SACCH related to a TRX according to the channel release procedure defined in GSM Rec. 04.08. Radio channel release procedure: used by the BSC to release a radio channel that is no longer needed.
Issue 01 (2008-06-10)

l
MS power control procedure: used by the BSS to control the transmit power of an MS for which a channel is already activated. The power control decision must be performed in the BSC. It can also be performed in the BTS. BTS transmit power control procedure: used by the BSS to control the transmit power of a TRX with an activated channel. The BTS transmit power control decision must be performed in the BSC. It can also be performed in the BTS. Connection failure procedure: used by the BTS to notify the BSC that an activated dedicated channel is unavailable. Physical context request procedure: used by the BSC to obtain the information about the physical context of a radio channel prior to a channel change. It is an optional procedure. SACCH information modification procedure: used by the BSC to request the BTS to change the filling system information on a specific SACCH.

l

l
1-34

l
SITE
CELL 0
CELL 1
CELL n
TRX0
TRX1
TRXm
BTS
TRX
Chann el 0
Chann el 1
Chanel 7
Management object state A management object can be in three states, the administrative state, operational state, and availability state. For details, see Table 1-6, Table 1-7, and Table 1-8. The available state further describes the operational state, and only the BSC controls the administrative state. Table 1-6 Administrative State Status Locked Description The BSC has disconnected all the calls passing this management object, and no new services can be connected to this object.
Issue 01 (2008-06-10)
1-35
Status Shut Down Unlocked
Description No new services can be connected to this management object, and ongoing calls are maintained. New services can be connected to this management object.
Table 1-8 Available State Status In Test Failed Power Off Offline Description The resource is undergoing a test procedure. The operational state is disabled. The resource has an internal fault that prevents it from operating. The operational state is disabled. The resource requires power and is not powered on. The operational state is disabled. The resource requires automatic or manual operations to make it available for use. The operational state is disabled. The resource cannot operate because some other resources on which it depends are unavailable. The operational state is disabled. The service is degraded due to some reasons such as speed or capacity. The operational state is enabled. The hardware or software of the management object is not installed. The operational state is disabled.
Dependency
Degraded Not Installed
Basic Procedures
All procedures are based on formatted OM messages. Most formatted OM messages initiated by the BSC or the BTS require the peer L3 to respond with formatted OM messages. This pair of formatted OM messages or a formatted OM message that does not require a response is called a basic procedure.
All formatted OM messages are sent on L2 in the form of I frames. A group of messages, also called structured procedures, are based on the combination of some basic procedures. When there is no response to a formatted OM message from the peer L3 upon L3 timer expiry, the basic procedure is considered as not "completed". For a specific object instance, if a certain basic procedure is not complete, the system does not start the subsequent basic procedures. When there is no response (ACK or NACK) in the previous basic procedure before L3 timeout, no subsequent basic procedure is sent to this object instance. The default value for L3 timeout is 10 seconds.
l

l l l l l l l l
1.5 Abis Interface (IP)

This describes the Abis interface (IP). The Abis interface lies between the BTS and the BSC. It is an internal interface. 1.5.1 Protocol Stack on the Abis Interface (IP) This describes the protocol stack on the Abis interface (IP). The protocol stack on the Abis interface consists of the physical layer, UDP/IP layer, LAPD layer, and layer 3. 1.5.2 Physical Layer on the Abis Interface (IP) This describes the interface type, transmission rate, working mode, and specifications to comply with at the physical layer when the IP transmission mode is used on the Abis interface. 1.5.3 UDP/IP Layer on the Abis Interface This describes the UDP/IP layer on the Abis interface. The UDP/IP layer on the Abis interface is responsible for addressing, routing, fragmentation, reassembly, and data transmission. 1.5.4 LAPD Layer on the Abis Interface The data link layer (L2) on the Abis interface uses the LAPD protocol. It receives data from the physical layer (L1) and provides connection-oriented or connectionless services for L3. 1.5.5 Layer 3 Traffic Management Messages on the Abis Interface
L3 traffic management messages on the Abis interface enables the MS to exchange information with the BSS or NSS on the Um interface and to perform some radio resource management functions under the control of the BSC. 1.5.6 Layer 3 OM Messages on the Abis Interface This describes the L3 OM messages on the Abis interface.
1.5.1 Protocol Stack on the Abis Interface (IP)

This describes the protocol stack on the Abis interface (IP). The protocol stack on the Abis interface consists of the physical layer, UDP/IP layer, LAPD layer, and layer 3. Figure 1-10 shows the protocol stack on the Abis interface (IP). Figure 1-10 Protocol stack on the Abis interface (IP)
BTS RSL/OML LAPD UDP/IP Layer1 BSC RSL/OML LAPD UDP/IP Layer1
Abis interface
IP: Internet Protocol OML: Operation and Maintenance Link UDP: User Datagram Protocol LAPD: Link Access Procedure on the D Channel RSL: Radio Signaling Link
1.5.2 Physical Layer on the Abis Interface (IP)

This describes the interface type, transmission rate, working mode, and specifications to comply with at the physical layer when the IP transmission mode is used on the Abis interface. When the IP transmission mode is used on the Abis interface, the physical layer supports the following Ethernet interfaces that are classfied into three types:
l
FE electrical interface: uses Category 5 twisted-pair wires for data transmission and complies with the 100BASE-TX specification. GE electrical interface: complies with the 1000BASE-T specification. GE optical port: complies with the 1000BASE-LX and 1000BASE-SX specifications.
l l
The transmission rates for the three types of interfaces are as follows:
l l l
FE electrical interface: 10 Mbit/s or 100 Mbit/s GE electrical interface: 10 Mbit/s, 100 Mbit/s, or 1000 Mbit/s GE optical interface: 1000 Mbit/s
The working modes of an electrical interface and an optical interface are as follows:

l
An electrical interface supports the half-duplex and full-duplex modes and has the automatic negotiation function. The working mode and transmission rate of an electrical port should be determined with full consideration to other network equipment. An optical interface supports only the full-duplex mode and can work only at the rate of 1000 Mbit/s. In addition, an optical interface does not support the automatic negotiation function.

l l l
RJ45 standard that an electrical interface complies with SFP standard that an optical interface complies with 802.3 protocol that the MAC layer supports
1.5.3 UDP/IP Layer on the Abis Interface

This describes the UDP/IP layer on the Abis interface. The UDP/IP layer on the Abis interface is responsible for addressing, routing, fragmentation, reassembly, and data transmission.
IP Address
An IP address is a logical IP address that is allocated to uniquely identify an internet host. Each port on the A interface board is assigned an IP address.
IP Routing
When network equipment supporting IP forwarding receives an IP packet, the network equipment checks whether the destination address is the IP address of the local equipment, multicast address, or broadcast address. If the destination address is the IP address of the local equipment, multicast address, or broadcast address, the network equipment submits the IP packet to a corresponding program for handling. Otherwise, the network equipment forwards the IP packet.
Fragmentation and Reassembly Related Concepts

The process of fragmentation and reassembly is related to the MTU, Identification, Flags, and Fragment Offset.
l
MTU MTU refers to the maximum length of a data frame that can be transmitted on a link. When data at the IP layer needs to be transmitted, packets must be fragmented at the IP layer and reassembled on the receiving end if the length of a data frame, which is yielded by IP header plus IP data part, is greater than the MTU at the data link layer.
Identification There is a 16-bit identification filed in the IP header. This filed uniquely identifies each packet sent by a host. When a datagram is cut into pieces, the identification field is copied into all fragments on fragmentation. When a packet is reassembled, the identification field is used to distinguish the fragments of one datagram from those of another.
Flags The flags field is behind the identification field and has 3 bits. The purposes of each bit are as follows:
Bit 0: reserved, must be zero.

Issue 01 (2008-06-10)
Bit 1: (DF) 0 = May Fragment, 1 = Don't Fragment. When the DF field is 1, packets are discarded if these packets need to be fragmented. Bit 2: (MF) 0 = Last Fragment, 1 = More Fragments.
Fragment Offset The Fragment Offset field is behind the flags field and has 13 bits. This field identifies the fragment location, relative to the beginning of the original unfragmented datagram. Irrespective of how many times datagrams are fragmented, the fragment offset fields of all fragments tell the receiver the positions of fragments in the original datagrams. These fields provide sufficient information to reassemble datagrams.

For a complete datagram, MF and Fragment Offset are set to zero. When either MF or Fragment Offset is not set to zero, you can infer that the datagram is fragmented. Fragment Offset of the first fragment must be zero. Fragment Offset is measured in units of 8 octets (64 bits). Except the last fragment, the data portions of other fragments must be an integral multiple of 8 octets. This is because that the Fragment Offset field has 13 bits but a datagram has 16 bits.
Fragmentation
The fragmentation of a datagram at the IP layer has the following situations:
l
If the length of a datagram is less than or equal to that of the MTU, the internet protocol directly sends the datagram to the next hop. If the length of a datagram is greater than MTU and moreover the datagram cannot be fragemented, the internet protocol discards the datagram and then displays the ICMP error control datagram. If the length of a datagram is greater than MIU and moreover the datagram can be fragmented, the internet protocol fragments the datagram. If the length of a datagram is greater than MTU and moreover the datagram can be fragmented, the internet protocol cuts the datagram into two fragments. The first fragment, which is less than or equal to MTU, is set to an integral multiple of 8 octets. The second fragment is the rest of the datagram. The internet protocol sends the first fragment to the next hop. If the second fragment is still greater than MTU, continute to cut the datagram until all fragments are less than MTU.
The procedure for fragmenting a datagram at the IP layer is as follows: 1.
2. 3.
When MTU is used as the basic length to fragment a datagram, the fragmentation efficiency is highest. In practise, it is not mandatory to use MTU as the basic fragmentation length and a length smaller than MTU is also allowed. During fragmentation, information at the transport layer is located in the first fragment. Other fragments have only common IP datagrams and do not contain information at the transport layer.
Reassembly
When one fragment of a datagram arrives, the receiver does not receive a datagram that has the same datagram identification previously. Then, the reassembly procedure is initiated. The procedure for fragmenting a datagram at the IP layer is as follows:
1. 2. 3. 4. 5. 6. 7. 8.
When the first fragment of a datagram is received (Fragment Offset is zero), the data from the fragment is placed in the data buffer that is dedicated to the first fragment. When other fragments except the first fragment and the last fragment are received, the data from these fragments is placed in the public data buffer. If the last fragment (that is the More Fragments field is zero) is received, the total data length is computed (Fragment Offest x 8 + data length of the last fragment). A data buffer is assigned to the datagram, the datagram is reassembled, and the timer is started. The timer is refreshed every time a fragment is received. The received fragments are padded to the data buffer according to attached offset. The last fragment is used if some received fragments are identical. If the timer runs out during datagram reassembly, datagram ressembly is over and all the received fragments are discarded. Datagram ressembly is over when all the fragments are received.
UDP
UDP is a transport layer protocol that is oriented to datagrams. Data transmission through UDP is characterized by less overhead and higher real-time performance. Therefore, UDP is widely used. Connectionless features of UDP are applied on the Abis interface (IP) to map Um channels and Abis resources, to establish a type of connectionless Socket, and to transmit packets to GFGUB of the BSC.

Overview
l
Function

l l
l l
l l
l l

l
The transparent messages refer to the messages directly forwarded without interpretation or processing by the BTS. The non-transparent messages refer to the messages that are transmitted between the BSC and the BTS and that must be processed and structured by the BTS. Radio link layer management messages that are used to manage the data link layer on radio channels Dedicated channel management messages that are used to manage dedicated channels such as the SDCCH and TCH Common control channel management messages that are used to manage common control channels TRX management messages that are used to manage TRXs
NOTE
l


l
l l

l
Channel activation procedure: used by the BSC to request the BTS to activate a dedicated channel for an MS. Then the BSC assigns the activated channel to the MS through an Immediate Assignment, Assignment Command, Additional Assignment, or Handover Command message. Channel mode modification procedure: used by the BSC to request the BTS to change the mode of an activated channel. Handover detection procedure: used on the Abis interface between the target BTS and the target BSC to detect the access of an MS being handed over. Ciphering mode command procedure: used to start the ciphering procedure defined in GSM Rec. 04.08. Measurement report procedure: consists of the mandatory basic measurement report procedure and optional measurement report preprocessing procedure. The BTS reports all the parameters related to handover decisions to the BSC through this procedure. SACCH deactivation procedure: used by the BSC to deactivate the SACCH related to a TRX according to the channel release procedure defined in GSM Rec. 04.08. Radio channel release procedure: used by the BSC to release a radio channel that is no longer needed. MS power control procedure: used by the BSS to control the transmit power of an MS for which a channel is already activated. The power control decision must be performed in the BSC. It can also be performed in the BTS.
Issue 01 (2008-06-10)

l
BTS transmit power control procedure: used by the BSS to control the transmit power of a TRX with an activated channel. The BTS transmit power control decision must be performed in the BSC. It can also be performed in the BTS. Connection failure procedure: used by the BTS to notify the BSC that an activated dedicated channel is unavailable. Physical context request procedure: used by the BSC to obtain the information about the physical context of a radio channel prior to a channel change. It is an optional procedure. SACCH information modification procedure: used by the BSC to request the BTS to change the filling system information on a specific SACCH.

l

l

l
SITE
CELL 0
CELL 1
CELL n
TRX0
TRX1
TRXm
BTS
TRX
Chann el 0
l
Chann el 1
Chanel 7
Management object state A management object can be in three states, the administrative state, operational state, and availability state. For details, see Table 1-9, Table 1-10, and Table 1-11. The available state further describes the operational state, and only the BSC controls the administrative state. Table 1-9 Administrative State Status Locked Description The BSC has disconnected all the calls passing this management object, and no new services can be connected to this object. No new services can be connected to this management object, and ongoing calls are maintained. New services can be connected to this management object.
Shut Down Unlocked
Issue 01 (2008-06-10)
Table 1-11 Available State Status In Test Failed Power Off Offline Description The resource is undergoing a test procedure. The operational state is disabled. The resource has an internal fault that prevents it from operating. The operational state is disabled. The resource requires power and is not powered on. The operational state is disabled. The resource requires automatic or manual operations to make it available for use. The operational state is disabled. The resource cannot operate because some other resources on which it depends are unavailable. The operational state is disabled. The service is degraded due to some reasons such as speed or capacity. The operational state is enabled. The hardware or software of the management object is not installed. The operational state is disabled.
Dependency
Degraded Not Installed
Basic Procedures
All procedures are based on formatted OM messages. Most formatted OM messages initiated by the BSC or the BTS require the peer L3 to respond with formatted OM messages. This pair of formatted OM messages or a formatted OM message that does not require a response is called a basic procedure. All formatted OM messages are sent on L2 in the form of I frames. A group of messages, also called structured procedures, are based on the combination of some basic procedures. When there is no response to a formatted OM message from the peer L3 upon L3 timer expiry, the basic procedure is considered as not "completed". For a specific object instance, if a certain basic procedure is not complete, the system does not start the subsequent basic procedures. When there is no response (ACK or NACK) in the previous basic procedure before L3 timeout, no
subsequent basic procedure is sent to this object instance. The default value for L3 timeout is 10 seconds.
l

l l l l l l l l
1.6 Um Interface
The Um interface lies between an MS and the BTS. It is used for the interworking between the MS and the fixed part of the GSM system. The links on the Um interface are radio links. The Um interface transmits the information about radio resource management, mobility management, and connection management. 1.6.1 Physical Layer on the Um Interface The physical layer on the Um interface defines the radio access capabilities of the GSM and provides basic radio channels for information transmission at higher layers. 1.6.2 LAPD Layer on the Um Interface The LAPD Layer on the Um interface is a data link layer. It uses the LAPDm protocol, and defines various data transmission structures for controlling data transmission. 1.6.3 Layer 3 Entity on the Um Interface The L3 entity on the Um interface consists of many functional program blocks.
1.6.1 Physical Layer on the Um Interface

The physical layer on the Um interface defines the radio access capabilities of the GSM and provides basic radio channels for information transmission at higher layers. The physical layer is the bottom layer on the Um interface. It provides physical links for transmitting bit streams. It also provides higher layers with various logical channels, including traffic channels and signaling channels. Each logical channel has its own logical access point. Figure 1-12 shows the interfaces between L1 and the data link layer (L2), the radio resource management sublayer (RR) of L3, and other functional units.
Figure 1-12 Interfaces of L1 on the Um interface

Radio resource management (3) Data link layer MPH primitive Other functional units TCH
PH primitive Physical layer
L1 provides the following services:

l
Access capability L1 provides a series of limited logical channels for transmission service. Logical channels are multiplexed onto physical channels. Each TRX has eight physical channels. Through data configuration, logical channels are mapped to physical channels.
Bit error detection L1 provides error protection transmission, including error detection and correction. Ciphering Based on a selected ciphering algorithm, the BSS ciphers the bit sequence.
1.6.2 LAPD Layer on the Um Interface

The LAPD Layer on the Um interface is a data link layer. It uses the LAPDm protocol, and defines various data transmission structures for controlling data transmission. L2 provides reliable dedicated data links between an MS and the BTS. It uses the LAPDm protocol that evolves from the LAPD protocol. The LAPDm layer receives the services from the physical layer and provides services for L3 through the SAP of L2. An SAP is identified by an SAPI. Each SAP is associated with one or multiple DLCEPs. Currently, two SAPI values, 0 (main signaling) and 3 (short message), are defined in the LAPDm protocol.
Function
LAPDm transfers information between L3 entities through the Dm channel on the Um interface. LAPDm supports multiple L3 entities, L1 entities, and signaling on BCCH, PCH, AGCH, and DCCH.
NOTE
The Dm channel is a generic term for all the signaling channels on the Um interface in the GSM system. For example, the Dm channel can be a PCH or BCCH.
LAPDm performs the following functions:

l
Providing one or more data link connections (DLCs) on the Dm channel. Each DLC is identified by a data link connection identifier (DLCI). Allowing frame type identification Allowing L3 message units to be transparently transmitted between L3 entities Performing sequence control to maintain the order of the frames transmitted through a DLC Detecting format errors and operation errors on data links
l l l l
1-48

l l
Performing flow control Establishing a contention resolution on a data link after an access request is detected on the RACH
Operation Type
L2 transmits L3 information in unacknowledged and acknowledged modes. One Dm channel can be in both modes at the same time.
l
Unacknowledged mode In unacknowledged mode, L3 information is transferred in Unnumbered Information (UI) frames. L2 does not acknowledge the UI frames or perform flow control or error correction. The unacknowledged mode is applicable to different types of control channels except the RACH.
Acknowledged mode In acknowledged mode, L3 information is transferred in numbered Information (I) frames. L2 acknowledges the I frames. It performs error correction by resending unacknowledged frames. When L2 fails to correct errors, it informs the management layer of the correction failure. Flow control procedures are also defined. The acknowledged mode is applicable to the DCCH.
Information Transfer Mode

Information is transferred in different modes on different channels.
l
Information transfer on the BCCH: The BCCH transfers the broadcast messages from the BTS to the MS. Only the acknowledged mode can be used on the BCCH. Information transfer on the PCH+AGCH: These channels transfer messages from the BTS to the MS. Only the unacknowledged mode is applicable to the PCH+AGCH. Information transfer on the DCCH: Either the acknowledged or the unacknowledged mode can be used. The transfer mode is determined by L3.
Data Link Release

L2 release is initiated by L3. The data links in frame mode are released in the following modes:
l
Normal release The BTS and the MS exchange DISC frames and UA frames or DM frames. Local release No frame is exchanged. Generally used in abnormal cases.
1.6.3 Layer 3 Entity on the Um Interface

The L3 entity on the Um interface consists of many functional program blocks.
Overview
The L3 entity on the Um interface consists of many functional program blocks. These program blocks transfer message units between all L3 entities and between L3 and its adjacent layers. L3 performs the following functions:

l l l l l
Establishing, operating, and releasing dedicated radio channels (RR) Performing location update, authentication, and TMSI reallocation (MM) Establishing, maintaining, and terminating circuit-switched calls (CC) Supporting supplementary services (SS) Supporting short message services (SMS)
L3 uses L3 signaling protocols between the MS and the network. Here the functions of different entities in the BSS are not taken into consideration. L3 and its supported lower layers, therefore, provide the Mobile Network Signaling (MNS) service for the higher layers. The service interfaces between L3 and higher layers and the interactions between the adjacent sublayers in L3 are described in primitives and parameters. The three sublayers in L3 perform information exchange between peer entities.
Structure and Functions

L3 consists of three sublayers. The CM sub-layer (the highest sub-layer) consists of three functional entities: Call Control (CC), Short Message Service (SMS), and Supplementary Service (SS). In total, L3 on the Um interface has five functional entities. They perform the following functions:
l
Radio Resource Management (RR) Establishing, maintaining, and releasing physical channels and logical channels, as well as performing cross-cell connection upon the request from the CM sublayer
Mobility Management (MM) Performing MS-specific functions and notifying the network when an MS is activated and deactivated, or when the location area of an MS changes. It is also responsible for the security of activated radio channels.
Call Control (CC) Performing all necessary functions to establish or release CS connections Supplementary Service (SS) Performing all necessary functions to support GSM supplementary services Short Message Service (SMS) Performing all necessary functions to support point-to-point GSM short message services
In addition to the previous functions, L3 performs functions related to the transmission of messages, for example, multiplexing and splitting. These functions are defined in the Radio Resource Management and Mobility Management. They route messages according to the protocol discriminator (PD) and transaction identifier (TI), which are part of the message header.
l
The routing function of the MM enables the MM to route the messages of the CM entities and the messages of the MM entity to the RR service access point (RR-SAP), and multiplexes the messages in case of concurrent transactions. The routing function of the RR distributes the to-be-sent messages according to their PD and the actual channel configuration. The messages provided at different service access points of layer 2 are split by the RR routing function according to the PD. If a message belongs to the RR sublayer, this message is transmitted to the RR entity based on the TI. The other messages are sent to the MM sublayer through the RR-SAP. If a message belongs to the MM sublayer, the message is
1-50
transmitted to the MM entity based on the TI. The other messages are sent to the CM sublayer through the MM-SAPs, and then to the CM entities. Figure 1-13 shows the L3 signaling protocol model on the Um interface. Figure 1-13 L3 signaling message processing procedure
Mobile network service MNCC-SAP MNSS-SAP MNSMS-SAP
CC
SS
SMS
MMSS-SAP MMCC-SAP MMREG -SAP MMSMS-SAP
MM Layer 3 signaling
MM
CC
SS
SMS
RR-SAP RR PD RR RR
SAPI 0
SAPI 3
AGCH+PCH
BCCH
SDCCH
The RR sublayer at the bottom receives the services from L2 through various service access points (that is, various types of channels) of L2, and provides services to the MM sublayer through RR-SAP. The MM sublayer provides services to different entities through different SAPs: to the CC through MMCC-SAP, to the SS through MMSS-SAP, to the SMS through MMSMS-SAP, and to the high layer through MMREG-SAP. The three independent entities (CC, SS, and SMS) of the CM sublayer provide services to higher layers through MNCC-SAP, MNSS-SAP, and MNSMS-SAP respectively.
Service Feature
L3 on the MS side provides the following services:
RACCH
SDCCH SACCH
SACCH FACCH

l l
Registration services, that is, IMSI attach and detach Call control services, including normal establishment of MS originating calls, emergency establishment of MS originating calls, call hold, call termination, and support for callrelated supplementary services Support for call independent supplementary services Support for short messages service
l l
L3 on the network side provides the following services:

l
Call control services, including call establishment, call hold, call termination, and support for call-related supplementary services Support for call independent supplementary services Support for short messages service
l l
L3 provides the following services between the MS and the network:

l
For the services provided by the RR, see Figure 1-14. These services are provided to the MM through RR-SAP. They are used to set up control channel connections and traffic channel connection, indicate ciphering mode, release control channel connections, and transmit control data. Figure 1-14 Services provided by the RR sublayer
MS side Mobile management sublayer RRprimitive RR SAP Protocol of the peer layer of the RR sublayer Network side
Radio resource management sublayer

l
For the services provided by the MM, see Figure 1-15. These services are used to manage the three entities (CC, SS, and SMS) of the CM sublayer.
1-52
Issue 01 (2008-06-10)
Figure 1-15 Services provided by the MM sublayer

MS side CC SS SMS CC Network side SS SMS
Mobile management sublayer
Protocol of the peer layer of the MM sublayer
Mobile management sublayer
1.7 Gb Interface
This describes the Gb interface. The Gb interface lies between the BSS and the SGCN. It is a standard interface. 1.7.1 Protocol Stack on the Gb Interface The protocol stack on the Gb interface consists of the physical layer, NS layer, and BSSGP layer. 1.7.2 FR/IP This describes FR/IP. The physical layer on the Gb interface supports the FR or IP connection mode. 1.7.3 NS This describes NS. The NS is present at both sides of the Gb interface. The functions of NS at the two sides are symmetrical. 1.7.4 BSSGP This describes BSSGP. The BSSGP is present at both sides of the Gb interface. The functions of BSSGP at the two sides are asymmetrical.
1.7.1 Protocol Stack on the Gb Interface

The protocol stack on the Gb interface consists of the physical layer, NS layer, and BSSGP layer. Figure 1-16 shows the protocol stack on the Gb interface.
Issue 01 (2008-06-10)
1-53
Figure 1-16 Protocol stack on the Gb interface

SGSN GMM/SM BSC BSSGP NS FR/IP LLC BSSGP NS FR/IP
Gb interface NS: Network Service LLC: Logical Link Control BSSGP: Base Station Subsystem GPRS Protocol GMM/SM: GPRS Mobility Management and Session Management
The explanations of the protocol stack on the Gb interface are as follows:

l
The physical layer on the Gb interface can use the FR or IP protocol. This physical layer can be connected in point-to-point mode, or through the frame relay network, or through the IP network. The physical layer provides communication services for NS. The Network Server (NS) layer is responsible for configuring and managing the NSVC or NSVL, for selecting routes for uplink data, for providing data transmission at the user plane, and for providing communication services for BSSGP. The BSSGP layer is responsible for transmitting the uplink/downlink signaling and data at the Logical Link Control (LLC) layer, for controlling downlink data flow, and for blocking, unblocking, or restarting the BSSGP Virtual Connection (BVC).
1.7.2 FR/IP
This describes FR/IP. The physical layer on the Gb interface supports the FR or IP connection mode. FR/IP provides transmission paths for the upper layer.
l
When physical connection uses FR, FR detects network status at the physical layer. When network status changes, FR reports the status and service condition of the network to the NS layer. When physical connection uses IP, IP detects the status of IP ports at the physical layer. When the IP port status changes, IP reports the status to the NS layer.
1.7.3 NS
This describes NS. The NS is present at both sides of the Gb interface. The functions of NS at the two sides are symmetrical. The difference in using the FR and IP protocol on the Gb interface lies in NS.

l
In Gb Over FR mode, the NS manages the NSVC and transmits the NS Service Digital Unit (SDU). NSVC management consists of the Reset operation, Block/Unblock operation, and Alive procedure.

The purpose of the Reset operation is set to revert the NSVC to the original state. The purpose of the Block/Unblock operation is to control whether the NSVC is logically usable. The purpose of the Alive procedure is to test whether the NSVC is physically usable.
In Gb Over IP mode, NS manages IP paths and transmits NS SDUs. IP path management consists of the dynamic configuration procedure and the ALIVE procedure.
The dynamic configuration procedure is performed to configuration data for the interactive NSVL between the BSS and the SGSN. The ALIVE procedure is performed to detect whether an IP path is usable.
NS provides the following services for BSSGP:

l
NS SDU transmission All the messages that are transmitted on BSSGP are transmitted at NS in the format of NS SDU. NS provides reliable transmission paths for the upper-layer protocol.
Load balancing between NSVCs or IP paths When NS SDU is transmitted at NS, NS select one or more NSVCs (or IP paths) from the NSVCs (or IP paths) that can transmit services to transmit user datagrams. In this way, the load at NS is evenly shared on all unblocked NSVCs (or IP paths) under the same NSE.
Network congestion indication When NS detects that congestion on the bottom links occurs or dispears, NS notifies the upper layer through a congestion indication message.
NS status indication When NS finds that faults on the bottom links occur or are rectified, transmission capacity changes. NS notifies the upper layer of specific faults or fault recovery.
1.7.4 BSSGP
This describes BSSGP. The BSSGP is present at both sides of the Gb interface. The functions of BSSGP at the two sides are asymmetrical. The 3GPP 48018 protocol describes the service model of the BSSGP module, as shown in Figure 1-17.
Issue 01 (2008-06-10)
1-55
Figure 1-17 Service model of BSSGP

Service model in a BSS Service model in an SGSN
RELAY
GMM
NM
LLC
GMM
NM
GSM 03.64 RLC/MAC
RL
GMM
NM
BSSGP
GMM
NM
BSSGP GSM 08.16 Network service
BSSGP
GSM 08.16 Network service
The functions of BSSGP on the BSS side are divided into Relay, GMM, and NM. BSSGP exchanges PDU datagrams with RLC/MAC in Relay mode, and then transmits datagrams to the peer end on the Gb interface in connectionless mode. The NM module is a BSSGP network management module and has the following functions:
l
BVC management BVC management involves the BVC resetting, blocking, and unblocking. Flow control management Because the transmission rate on the Gb interface is greater than the transmission rate on the Um interface, flow control is required for the Gb interface. Flow control is categorized into two types, that is, cell flow control and MS flow control.
LLC_DISCARD When the expired datagrams on the BSS side are discarded, this message is used to notify the SGSN.
The GMM module is a BSSGP mobility management module and has the following functions:
l
Paging After the BSS receives the PS paging or CS paging message from the SGSN, the BSS analyzes the message based on paging areas, sends a paging message to related cells, and then delivers the paging message to the Um interface.
Suspending and resuming PS services If an MS of class B needs to use CS services when the MS operate PS services, the MS uses this function to pause ongoing PS services. After CS services are over, the BSS informs the SGSN to resume the previously pasused PS services.
Notification and update of radio capability The BSS performs this function to obtain parameters related to radio capability from the SGSN.
The BSSGP protocol has the following functions:

l l
Sending signaling information and user data Performing flow control for downlink data
1-56

l l l
Blocking and unblocking the BVC Configuring and managing the BVC dynamically Detecting errors of interface messages
BSSGP has the following basic procedures:

l l l l l l l l l l l
Procedure of transmitting uplink and downlink data Paging procedure Notification procedure of radio access capability Request and response procedure of radio access capability Radio status procedure Procedure of suspending and resuming FLUSH_LL (Logic Link) procedure Flow control procedure Procedure of blocking and unblocking the PTP BVC Procedure of resetting the BVC Tracing procedure
Issue 01 (2008-06-10)
1-57
2 BSS Signaling Tracing
2
About This Chapter
BSS Signaling Tracing
This describes the BSS signaling tracing, which consists of the signaling tracing on the Um interface, Abis interface, A interface, Pb interface, Gb interface, and BSC-CBC interface, and single user signaling tracing. 2.1 Tracing CS Messages This describes how to trace the CS messages such as the messages on the A interface, Abis interface, Pb interface, Um interface, BSC-CBC interface, and user messages. 2.2 Tracing PS Messages This describes how to trace messages on the Gb interface and Um interface.
Issue 01 (2008-06-10)
2-1
2.1 Tracing CS Messages

This describes how to trace the CS messages such as the messages on the A interface, Abis interface, Pb interface, Um interface, BSC-CBC interface, and user messages. 2.1.1 Tracing the Messages on the A Interface This describes how to trace the BSSAP, MTP2, MTP3, and SCCP messages on the A interface. 2.1.2 Tracing the Messages on the Abis Interface This describes how to trace the RSL, OML, ESL, LAPD messages on the Abis interface. 2.1.3 Tracing the Messages on the Pb Interface When the PCU is in external mode, you can trace the messages on the Pb interface on the BSC6000 Local Maintenance Terminal. This describes how to trace the application messages and LAPD messages on the Pb interface. 2.1.4 Tracing CS Domain Messages on the Um Interface This describes how to trace all the layer 3 signaling messages on the Um interface on the LMT. Tracing the messages based on TRX or cell is supported. 2.1.5 Tracing User Messages This describes how to trace signaling messages on the A/Abis/Um interface on the LMT. Using the IMSI, IMEI, TMSI, MSISDN, or channel to specify a user to be traced 2.1.6 Tracing Messages on the BSC-CBC Interface This describes how to trace signaling messages of the interfaces between the BSC and CBC through the LMT.
2.1.1 Tracing the Messages on the A Interface

This describes how to trace the BSSAP, MTP2, MTP3, and SCCP messages on the A interface. 2.1.1.1 Tracing BSSAP Messages on the A Interface This describes how to trace all signaling messages on the A interface on the LMT. The messages consist of DTAP message, BSSMAP message, Paging message, and other messages. 2.1.1.2 Tracing SCCP Messages on the A Interface This describes how to trace the SCCP messages on the A interface based on the DPC, the SCCP user message, and the MTP3 primal message. 2.1.1.3 Tracing MTP3 Messages on the A Interface This describes how to tracing the MTP3 messages on the A interface based on link number, link set, and the Destination Signaling Point(DSP). The MTP3 messages consist of SNM message, SLT message, MT message, and L2_CHANGE message. 2.1.1.4 Tracing MTP2 Messages on the A Interface This describes how to trace the MTP2 messages on the A interface based on a specified subrack, slot, and link number. The MTP2 messages consist of LSSU message and MSU message. 2.1.1.5 Tracing SCTP Messages on the A Interface This describes how to trace SCTP messages based on specified subrack, slot, CPU number, and link number on the LMT. The messages consist of control message, data message, and heartbeat message. 2.1.1.6 Tracing M3UA Messages on the A Interface
This describes how to trace M3UA messages based on specified subrack, slot, CPU number, and link number on the LMT. The messages consist of management message, transferring message, SS7 network management message, ASP service maintenance message, ASP state maintenance message, and routing key word message
Tracing BSSAP Messages on the A Interface

This describes how to trace all signaling messages on the A interface on the LMT. The messages consist of DTAP message, BSSMAP message, Paging message, and other messages.
Prerequisite
l l
The LMT runs normally. The communication between the BSC and the MSC is normal.
Context
Tracing BSSAP messages on the A interface based on cells (a maximum of 16 cells). For details of Message Type, refer to Message Types. For details of Tracing Mode, refer to Tracing Modes. The following description is based on the configuration using the GOMU.
Procedure
Step 1 On the Trace & Monitor tab page, choose Trace > Trace Message on the A Interface > BSSAP Message. A dialog box is displayed, as shown in Figure 2-1. Figure 2-1 Trace BSSAP Message on the A Interface dialog box
Step 2 Set Message Type, Color, Tracing Mode, and Site. Select cells from the Candidate Cells box and add them to the Selected Cells box.
Step 3 Click OK. ----End
Result
l
If the operation is successful:
If the tracing mode is Save on GOMU/GBAM, the LMT does not display the traced messages. You can review the output file of the traced message. For details, refer to Reviewing Trace Message Files. If the tracing mode is Report, a dialog box is displayed, prompting the information of the message tracing task, as shown in Figure 2-2. Figure 2-2 Tracing BSSAP messages on the A interface
If the operation fails, a dialog box is displayed, prompting the possible causes.
Postrequisite
You can double-click a message to view the detailed information. Right-click the message to be analyzed. The shortcut menu provides the following options:
l l l l l l l
Clear Message: Clear the displayed messages. Stop Scroll: Stop scrolling the displayed messages. Stop Trace: Stop the current tracing task. Restart Trace: Restart the tracing task. View Task: View the established tracing task. Search: Search for the specified character string in the displayed messages. Save Selection: Save the selected messages.
2-4

l
Save All: Save all the traced messages.
Tracing SCCP Messages on the A Interface

This describes how to trace the SCCP messages on the A interface based on the DPC, the SCCP user message, and the MTP3 primal message.
Prerequisite
l l l
The LMT runs normally. The communication between the LMT and the BSC is normal. The SCCP link is configured.
Context
For details of Message Type, refer to Message Types. For details of Tracing Mode, refer to Tracing Modes. The following description is based on the configuration using the GOMU.
Procedure
Step 1 On the Trace & Monitor tab page, choose Trace > Trace Message on the A Interface > SCCP Message. A dialog box is displayed, as shown in Figure 2-3. Figure 2-3 Trace SCCP Message on the A Interface dialog box
Step 2 Set the parameters in the Tracing Type, Location, Tracing Mode, and Color areas. Step 3 Click OK. ----End
Result
l
If the tracing mode is Save on GOMU/GBAM, the LMT does not display the traced messages. You can review the output file of the traced message. For details, refer to Reviewing Trace Message Files. If the tracing mode is Report, a dialog box is displayed, prompting the information of the message tracing task, as shown in Figure 2-4. Figure 2-4 Tracing SCCP messages on the A interface
Postrequisite
l l l l l l l l
Clear Message: Clear the displayed messages. Stop Scroll: Stop scrolling the displayed messages. Stop Trace: Stop the current tracing task. Restart Trace: Restart the tracing task. View Task: View the established tracing task. Search: Search for the specified character string in the displayed messages. Save Selection: Save the selected messages. Save All: Save all the traced messages.
2-6
Issue 01 (2008-06-10)
Tracing MTP3 Messages on the A Interface

This describes how to tracing the MTP3 messages on the A interface based on link number, link set, and the Destination Signaling Point(DSP). The MTP3 messages consist of SNM message, SLT message, MT message, and L2_CHANGE message.
Prerequisite
l l l l
The LMT runs normally. The communication between the LMT and the BSC is normal. The communication between the BSC and the MSC is normal. The MTP3 links are configured.
Context
Procedure
Step 1 On the Trace & Monitor tab page, choose Trace > Trace Message on the A Interface > MTP3 Message. A dialog box is displayed, as shown in Figure 2-5. Figure 2-5 Trace MTP3 Message on the A Interface dialog box
Step 2 Set Message Type, Tracing Type, Location, Message Filter, Tracing Mode, and Color. Step 3 Click OK. ----End
Result
l
If the tracing mode is Save on GOMU/GBAM, the LMT does not display the traced messages. You can review the output file of the traced message. For details, refer to Reviewing Trace Message Files. If the tracing mode is Report, a dialog box is displayed, prompting the information of the message tracing task, as shown in Figure 2-6. Figure 2-6 Tracing MTP3 messages on the A interface
Postrequisite
l l l l l l l l
2-8
Issue 01 (2008-06-10)
Tracing MTP2 Messages on the A Interface

This describes how to trace the MTP2 messages on the A interface based on a specified subrack, slot, and link number. The MTP2 messages consist of LSSU message and MSU message.
Prerequisite
l l l l
The LMT runs normally. The communication between the LMT and the BSC is normal. The communication between the BSC and the MSC is normal. The MTP2 links are configured.
Context
Procedure
Step 1 On the Trace & Monitor tab page, choose Trace > Trace Message on the A Interface > MTP2 Message. A dialog box is displayed, as shown in Figure 2-7. Figure 2-7 Trace MTP2 Message on the A Interface dialog box
Step 2 Set Message Type, Location, Tracing Mode, and Color.

Result
l
If the tracing mode is Save on GOMU/GBAM, the LMT does not display the traced messages. You can review the output file of the traced message. For details, refer to Reviewing Trace Message Files. If the tracing mode is Report, a dialog box is displayed, prompting the information of the message tracing task, as shown in Figure 2-8. Figure 2-8 Tracing MTP2 messages on the A interface
Postrequisite
l l l l l l l
2-10

l
Tracing SCTP Messages on the A Interface

This describes how to trace SCTP messages based on specified subrack, slot, CPU number, and link number on the LMT. The messages consist of control message, data message, and heartbeat message.
Prerequisite
l l l
The LMT runs normally. The communication between the LMT and the BSC is normal. An SCTP link is configured.
Context
Procedure
Step 1 On the Trace & Monitor tab page, choose Trace > Trace CS Message > Trace A Interface Message > SCTP Message. A dialog box is displayed, as shown in Figure 2-9. Figure 2-9 Trace SCTP Message on the A Interface dialog box
Step 2 Set the parameters in the Message Type, Location, and Tracing Mode areas, and select Save File. Step 3 Click OK. ----End
Result
l
If the tracing mode is Save on GOMU/GBAM, the LMT does not display the traced messages. You can review the output file of the traced message. For details, refer to Reviewing Trace Message Files. If the tracing mode is Report, a dialog box is displayed, prompting the information of the message tracing task, as shown in Figure 2-10.
Figure 2-10 Tracing SCTP messages on the A interface
Postrequisite
l l l l l l l
2-12

l
Tracing M3UA Messages on the A Interface

This describes how to trace M3UA messages based on specified subrack, slot, CPU number, and link number on the LMT. The messages consist of management message, transferring message, SS7 network management message, ASP service maintenance message, ASP state maintenance message, and routing key word message
Prerequisite
l l l
The LMT runs normally. The communication between the LMT and the BSC is normal. An M3UA link is configured.
Context
Procedure
Step 1 On the Trace & Monitor tab page, choose Trace > Trace CS Message > Trace A Interface Message > M3UA Message. A dialog box is displayed, as shown in Figure 2-11. Figure 2-11 Trace M3UA Message on the A Interface dialog box
Step 2 Set Message Type, Location, and Tracing Mode. Step 3 Click OK. ----End
Result
l
Figure 2-12 Tracing M3UA messages on the A interface
Postrequisite
l l l l l l l l
2-14
2.1.2 Tracing the Messages on the Abis Interface

This describes how to trace the RSL, OML, ESL, LAPD messages on the Abis interface. 2.1.2.1 Tracing RSL Messages on the Abis Interface This describes how to trace all the Radio signaling link(RSL) messages on the Abis interface on the LMT. The messages consist of measurement report, channel request message, paging message, RLM message, and TRXM message. 2.1.2.2 Tracing OML Messages on the Abis Interface This describes how to trace operation and maintenance link(OML) signaling messages on the Abis interface on the LMT. The messages consist of common message and OM message. 2.1.2.3 Tracing ESL Messages on the Abis Interface This describes how to trace all the extend signalling link(ESL) messages on the Abis interface on the LMT. The messages consist of common message and OM message. 2.1.2.4 Tracing EML Messages on the Abis Interface This describes how to trace extend maintenance link(EML) messages on the Abis interface based on site location on the LMT. The messages consist of common message and OM message. 2.1.2.5 Tracing LAPD Messages on the Abis Interface This describes how to trace LAPD messages on the Abis interface on the LMT. The LAPD messages consist of RSL message, EML message, OML message, and ESL message. TRX tracing and site tracing are supported.
Tracing RSL Messages on the Abis Interface

This describes how to trace all the Radio signaling link(RSL) messages on the Abis interface on the LMT. The messages consist of measurement report, channel request message, paging message, RLM message, and TRXM message.
Prerequisite
l l
The LMT runs normally. The communication between the BSC and the BTS is normal.
Context
Tracing messages based on TRXs or cells (a maximum of 16 cells) For details of Message Type, refer to Message Types. For details of Tracing Mode, refer to Tracing Modes.
CAUTION
After the BTS connected to the Abis interface is moved manually, close the message trace of this type and restart the message trace function. The following description is based on the configuration using the GOMU.
Procedure
Step 1 On the Trace & Monitor tab page, choose Trace > Trace Message on the Abis Interface > RSL Message. A dialog box is displayed, as shown in Figure 2-13. Figure 2-13 Trace RSL Message on the Abis Interface dialog box
Step 2 Set Message Type, Filtering Condition, Color, and Tracing Mode. Step 3 Click OK. ----End
Result
l
2-16
Issue 01 (2008-06-10)
Figure 2-14 Tracing RSL messages on the Abis interface
Postrequisite
l l l l l l l l
Tracing OML Messages on the Abis Interface

This describes how to trace operation and maintenance link(OML) signaling messages on the Abis interface on the LMT. The messages consist of common message and OM message.
Prerequisite
l l
Issue 01 (2008-06-10)
2-17
Context
Tracing the OML messages at Abis interface based on sites (a maximum of 16 sites) For details of Message Type, refer to Message Types. For details of Tracing Mode, refer to Tracing Modes. The following description is based on the configuration using the GOMU.
Procedure
Step 1 On the Trace & Monitor tab page, choose Trace > Trace Message on the Abis Interface > OML Message. A dialog box is displayed, as shown in Figure 2-15. Figure 2-15 Trace OML Message on the Abis Interface dialog box
Step 2 Set Message Type, Color, and Tracing Mode. Select cells from the Candidate Cells box and add them to the Selected Cells box. Step 3 Click OK. ----End
Result
l
2-18
Issue 01 (2008-06-10)
Figure 2-16 Tracing OML messages on the Abis interface
Postrequisite
l l l l l l l l
Tracing ESL Messages on the Abis Interface

This describes how to trace all the extend signalling link(ESL) messages on the Abis interface on the LMT. The messages consist of common message and OM message.
Prerequisite
l l
Issue 01 (2008-06-10)
2-19
Context
Tracing the ESL messages on the Abis interface based on sites (a maximum of 16 sites) For details of Message Type, refer to Message Types. For details of Tracing Mode, refer to Tracing Modes. The following description is based on the configuration using the GOMU.
Procedure
Step 1 On the Trace & Monitor tab page, choose Trace > Trace Message on the Abis Interface > ESL Message. A dialog box is displayed, as shown in Figure 2-17. Figure 2-17 Trace ESL Message on the Abis Interface dialog box
Step 2 Set Message Type, Color, and Tracing Mode. Select cells from the Candidate Cells box and add them to the Selected Cells box. Step 3 Click OK. ----End
Result
l
2-20
Issue 01 (2008-06-10)
Figure 2-18 Tracing ESL messages on the Abis interface
Postrequisite
l l l l l l l l
Tracing EML Messages on the Abis Interface

This describes how to trace extend maintenance link(EML) messages on the Abis interface based on site location on the LMT. The messages consist of common message and OM message.
Prerequisite
l l
The LMT runs normally. The communication between the LMT and the BSC is normal.
Issue 01 (2008-06-10)
Context
Procedure
Step 1 On the Trace & Monitor tab page, choose Trace > Trace CS Message > Trace Abis Interface Message > EML Message. A dialog box is displayed, as shown in Figure 2-19. Figure 2-19 Trace EML Message on the Abis Interface dialog box
Step 2 Set Message Type, Location, and Tracing Mode. Step 3 Click OK. ----End
Result
l
2-22
Issue 01 (2008-06-10)
Figure 2-20 Trace EML Message on the Abis Interface dialog box
Postrequisite
l l l l l l l l
Tracing LAPD Messages on the Abis Interface

This describes how to trace LAPD messages on the Abis interface on the LMT. The LAPD messages consist of RSL message, EML message, OML message, and ESL message. TRX tracing and site tracing are supported.
Prerequisite
l
The LMT runs normally.

Issue 01 (2008-06-10)

l
The communication between the BSC and the BTS is normal.
Context
Procedure
Step 1 On the Trace & Monitor tab page, choose Trace > Trace Message on the Abis Interface > LAPD Message. A dialog box is displayed, as shown in Figure 2-21. Figure 2-21 Trace LAPD Message on the Abis Interface dialog box
Step 2 Set the parameters in the Link Type, Port, Location, Color, and Tracing Mode areas. Step 3 Click OK. ----End
Result
l
2-24
Figure 2-22 Tracing LAPD messages on the Abis interface
Postrequisite
l l l l l l l l
2.1.3 Tracing the Messages on the Pb Interface

When the PCU is in external mode, you can trace the messages on the Pb interface on the BSC6000 Local Maintenance Terminal. This describes how to trace the application messages and LAPD messages on the Pb interface. 2.1.3.1 Tracing Application Messages on the Pb Interface This describes how to trace application messages on the Pb interface on the LMT. The messages consist of paging message, confusion message, PCIC message, and other messages. 2.1.3.2 Tracing LAPD Messages on the Pb Interface This describes how to trace the layer 2 messages on the Pb interface through the LMT. You can trace the LAPD messages on the Pb interface based on the specified link.
Tracing Application Messages on the Pb Interface

This describes how to trace application messages on the Pb interface on the LMT. The messages consist of paging message, confusion message, PCIC message, and other messages.
Prerequisite
l l l l
The LMT runs normally. The communication between the LMT and the BSC is normal. The communication between the BSC and the PCU is normal. The external PCU is configured.
Context
The application messages on the Pb interface can be traced. A maximum of 16 cells are supported. For details of Message Type, refer to Message Types. For details of Tracing Mode, refer to Tracing Modes. The following description is based on the configuration using the GOMU.
Procedure
Step 1 On the Trace & Monitor tab page, choose Trace > Trace Message on the Pb Interface > Application Message. A dialog box is displayed, as shown in Figure 2-23. Figure 2-23 Trace Application Message on the Pb Interface dialog box
Step 2 Set Message Type, Location, Color, and Tracing Mode. Select cells from the Candidate Cells box and add them to the Selected Cells box. Step 3 Click OK. ----End
Result
l
If the tracing mode is Save on GOMU/GBAM, the LMT does not display the traced messages. You can review the output file of the traced message. For details, refer to Reviewing Trace Message Files. If the tracing mode is Report, a dialog box is displayed, prompting the information of the message tracing task, as shown in Figure 2-24. Figure 2-24 Tracing application messages on the Pb interface
Postrequisite
l l l l l l l
Issue 01 (2008-06-10)

l
Tracing LAPD Messages on the Pb Interface

This describes how to trace the layer 2 messages on the Pb interface through the LMT. You can trace the LAPD messages on the Pb interface based on the specified link.
Prerequisite
l l l
The LMT runs normally. The communication between the BSC and the BTS is normal. The external PCU is configured.
Context
For details of Tracing Mode, refer to Tracing Modes. The following description is based on the configuration using the GOMU.
Procedure
Step 1 On the Trace & Monitor tab page, choose Trace > Trace Message on the Pb Interface > LAPD Message. A dialog box is displayed, as shown in Figure 2-25.
2-28
Issue 01 (2008-06-10)
Figure 2-25 Trace LAPD Message on the Pb Interface dialog box
Step 2 Set the parameters in the Message Type, Color, and Tracing Mode areas. Step 3 Click OK. ----End
Result
l
Issue 01 (2008-06-10)
2-29
Figure 2-26 Tracing LAPD messages on the Pb interface
Postrequisite
l l l l l l l l
2.1.4 Tracing CS Domain Messages on the Um Interface

This describes how to trace all the layer 3 signaling messages on the Um interface on the LMT. Tracing the messages based on TRX or cell is supported.
Prerequisite
l

2-30

l
The communication between the BSC and the BTS is normal.
Context
When the messages are traced based on cells, a maximum of 16 cells are supported. For details of Tracing Mode, refer to Tracing Modes. The following description is based on the configuration using the GOMU.
Procedure
Step 1 On the Trace & Monitor tab page, choose Trace > Trace Message on the Um Interface. A dialog box is displayed, as shown in Figure 2-27. Figure 2-27 Trace Message on the Um interface dialog box (set TRX as the filter condition)
Step 2 To trace messages on the Um interface, set the parameters in Filter Condition, Tracing Mode, and Color.
NOTE
When the Filter Condition is set to TRX or Cell, the execution interfaces are different. In this topic, the instance when the Filter Condition is set to TRX is illustrated. Max Number: 16 indicates that the maximum number of cells that can be selected is 16.
Result
l
If the tracing mode is Save on GOMU/GBAM, the LMT does not display the traced messages. You can review the output file of the traced message. For details, refer to Reviewing Trace Message Files.
Issue 01 (2008-06-10)
If the tracing mode is Report, a dialog box is displayed, prompting the information of the message tracing task, as shown in Figure 2-28. Figure 2-28 Tracing messages on the Um interface
Postrequisite
l l l l l l l l
2.1.5 Tracing User Messages

This describes how to trace signaling messages on the A/Abis/Um interface on the LMT. Using the IMSI, IMEI, TMSI, MSISDN, or channel to specify a user to be traced
Prerequisite
l

2-32

l l l
The communication between the BSC and the BTS is normal. The communication between the BSC and the MSC is normal. Tracing BSSAP Messages on the A Interface is successful.
Context
Procedure
Step 1 On the Trace & Monitor tab page, choose Trace > Trace User Message. A dialog box is displayed, as shown in Figure 2-29. Figure 2-29 Trace User Message dialog box
Step 2 Select Interface Type and Tracing Mode, and set the IMSI, TMSI, MSISDN, IMEI, or Channel.
Issue 01 (2008-06-10)
2-33

NOTE
If you trace the user messages through MSISDN (you are advised to trace the calling ID through the called ID):
l l
If you trace the calling party, the MSISDN is the called ID, that is, the ID that the MS calls. For example, if the MS calls 12345, then the MSISDN is 12345. If you trace the called party, the MSISDN is the calling ID. The MS must be enabled with caller ID display. If 54331 is displayed on the MS, specify the MSISDN with 54321; if 8654321 is displayed on the MS, specify the MSISDN with 8654321.
If you trace the user messages through TMSI or IMSI, you must determine the reassignment strategy on the MSC side:
l l
If TMSI is carried, you can trace the MS through the TMSI. If IMSI is carried, you can trace the MS through the IMSI.
If you trace the user messages through IMEI, you must determine whether the IMEI is available to the MSC.
Result
l
If the tracing mode is Save on GOMU/GBAM, the LMT does not display the traced messages. You can review the output file of the traced message. For details, refer to Reviewing Trace Message Files. If the tracing mode is Report, a dialog box is displayed, prompting the information of the message tracing task, as shown in Figure 2-30. Figure 2-30 Tracing user messages
2-34
Postrequisite
l l l l l l l l
2.1.6 Tracing Messages on the BSC-CBC Interface

This describes how to trace signaling messages of the interfaces between the BSC and CBC through the LMT.
Prerequisite
l l l
The LMT runs normally. The communication between the LMT and the BSC is normal. The communication between the BSC and the CBC is normal.
Context
Procedure
Step 1 On the Trace & Monitor tab page, choose Trace > Trace Message on the BSC-CBC Interface. A dialog box is displayed, as shown in Figure 2-31.
Issue 01 (2008-06-10)
2-35
Figure 2-31 Trace the Message at BSC-CBC Interface dialog box
Step 2 Select Tracing Mode and Color. Step 3 Click OK. ----End
Result
l
2-36
Issue 01 (2008-06-10)
Figure 2-32 Tracing Messages on the BSC-CBC Interface
Postrequisite
l l l l l l l l
2.2 Tracing PS Messages

This describes how to trace messages on the Gb interface and Um interface.
Context
During PS message tracing, five tracing tasks with different location information can be performed simultaneously. 2.2.1 Tracing the Messages on the Gb Interface This describes how to trace the PTP messages and SIG messages on the Gb interface.
2.2.2 Tracing PS Domain Messages on the Um Interface This describes how to trace the PS domain messages on the Um interface based on the specified TRX or cell on the LMT when the PCU is installed inside the BSC. The messages consist of DUMMY message, system message, null paging message, and data block message.
2.2.1 Tracing the Messages on the Gb Interface

This describes how to trace the PTP messages and SIG messages on the Gb interface. 2.2.1.1 Tracing SIG Messages on the Gb Interface This describes how to trace SIG signaling messages on the Gb interface based on NSEI on the LMT when the PCU is installed inside the BSC. 2.2.1.2 Tracing PTP Messages on the Gb Interface This describes how to trace the PTP signaling messages on the Gb interface based on cell or NSEI+BVCI on the LMT when the PCU is installed inside the BSC.
Tracing SIG Messages on the Gb Interface

This describes how to trace SIG signaling messages on the Gb interface based on NSEI on the LMT when the PCU is installed inside the BSC.
Prerequisite
l l l
The LMT runs normally. The communication between the BSC and the SGSN is normal. The NSE and the association between BVCs and cells are already configured.
Context
Procedure
Step 1 On the Trace & Monitor tab page, choose Trace > Trace PS Message > Trace Gb Interface Message > SIG Message. A dialog box is displayed, as shown in Figure 2-33.
2-38
Issue 01 (2008-06-10)
Figure 2-33 Trace SIG Message on the Gb Interface dialog box
Step 2 Set the parameters in the Location and the Tracing Mode areas, and select Save File. Step 3 Click OK. ----End
Result
l
Issue 01 (2008-06-10)
2-39
Figure 2-34 Tracing SIG messages on the Gb interface
Postrequisite
l l l l l l l l
Tracing PTP Messages on the Gb Interface

This describes how to trace the PTP signaling messages on the Gb interface based on cell or NSEI+BVCI on the LMT when the PCU is installed inside the BSC.
Prerequisite
l l
The LMT runs normally. The communication between the BSC and the SGSN is normal.
2-40

l
The NSE and the association between BVCs and cells are already configured.
Context
Procedure
Step 1 On the Trace & Monitor tab page, choose Trace > Trace PS Message > Trace Gb Interface Message > PTP Message. A dialog box is displayed, as shown in Figure 2-35. Figure 2-35 Trace PTP Message on the Gb Interface dialog box
Step 2 Set parameters in the Location and Tracing Mode areas. Step 3 Click OK. ----End
Result
l
Issue 01 (2008-06-10)
2-41
Figure 2-36 Tracing PTP messages on the Gb interface
Postrequisite
l l l l l l l l
2.2.2 Tracing PS Domain Messages on the Um Interface

This describes how to trace the PS domain messages on the Um interface based on the specified TRX or cell on the LMT when the PCU is installed inside the BSC. The messages consist of DUMMY message, system message, null paging message, and data block message.
Prerequisite
l

2-42

l l l
The communication between the LMT and the BSC is normal. The communication between the BSC and the BTS is normal. The communication between the BSC and the SGSN is normal.
Context
Procedure
Step 1 On the Trace & Monitor tab page, choose Trace > Trace PS Message > Trace Um Interface Message. A dialog box is displayed, as shown in Figure 2-37. Figure 2-37 Trace PS Message on the Um Interface dialog box
Step 2 Set parameters in the Location and Tracing Mode areas. Step 3 Click OK. ----End
Result
l
Issue 01 (2008-06-10)
Figure 2-38 Trace PS Message on the Um Interface dialog box
Postrequisite
l l l l l l l l
2-44
Issue 01 (2008-06-10)
3 BSS System Information
3
About This Chapter
BSS System Information
System information (SI) refers to the major radio network parameters on the Um interface such as the network identification parameters, cell selection parameters, system control parameters, and network functional parameters. 3.1 BSS System Information Type The BSS system information consists of System Information Type 1, System Information Type 2, System Information Type 2bis, System Information Type 2ter, System Information Type 2quater, System Information Type 3, System Information Type 4, System Information Type 5, System Information Type 5bis, System Information Type 5ter, System Information Type 6, System Information Type 7, System Information Type 8, and System Information Type 13. 3.2 Internal BSC Signaling Procedure of the System Information This describes the internal BSC signaling procedure of the system information.
Issue 01 (2008-06-10)
3-1
3.1 BSS System Information Type

The BSS system information consists of System Information Type 1, System Information Type 2, System Information Type 2bis, System Information Type 2ter, System Information Type 2quater, System Information Type 3, System Information Type 4, System Information Type 5, System Information Type 5bis, System Information Type 5ter, System Information Type 6, System Information Type 7, System Information Type 8, and System Information Type 13. 3.1.1 System Information Type 1 This describes the functions and contents of System Information Type 1. 3.1.2 System Information Types 2, 2bis, 2ter, and 2quater This topic describes the functions and contents of System Information Types 2, 2bis, 2ter, and 2quater. 3.1.3 System Information Type 3 This describes the functions and contents of System Information Type 3. 3.1.4 System Information Type 4 This describes the functions and contents of System Information Type 4. 3.1.5 System Information Types 5, 5bis, and 5ter This describes the functions and contents of System Information Types 5, 5bis, and 5ter. 3.1.6 System Information Type 6 This describes the functions and contents of System Information Type 6. 3.1.7 System Information Type 7 This describes the functions and contents of System Information Type 7. 3.1.8 System Information Type 8 This describe the functions and contents of System Information Type 8. 3.1.9 System Information Type 13 This describe the functions and contents of System Information Type 13.
3.1.1 System Information Type 1

This describes the functions and contents of System Information Type 1.
Functions
System Information Type 1 is sent on the BCCH by the network to all the MSs within the cell. It provides information about the Random Access Channel (RACH) control and the cell allocation (CA).
Contents
Table 3-1 lists the contents of System Information Type 1.
3-2
Issue 01 (2008-06-10)
Table 3-1 Contents of System Information Type 1 Type SYS INFO 1 Contents Cell Channel Desc RACH Control Para SI 1 Rest Octets
The contents of System Information Type 1 are described as follows:

l
CA table One cell can be configured with a maximum of 64 frequencies. The actual configuration of cell frequencies is subject to the Table 3-2. The BSC selects a format of cell channel description based on the configuration of cell frequencies. The format of cell channel description is defined by octet 2, Format ID (Bit 128, Bit 127, Bit 124, Bit 123, and Bit 122), as shown in Table 3-3. Table 3-2 Format of cell channel description 8 7 6 5 4 3 2 1 octet 1 Bit 122 Bit 114 Bit 2 Bit 121 Bit 113 Bit 1 octet 2
Cell Channel Description IEI Bit 128 Bit 120 Bit 8 Bit 127 Bit 119 Bit 7 0 Spar e Bit 118 Bit 6 0 Spare Bit 117 Bit 5 Bit 124 Bit 116 Bit 4 Bit 123 Bit 115 Bit 3
octet 3 octet 17
Table 3-3 Format of cell channel description Bit 128 0 1 1 1 Bit 127 0 0 0 0 Bit 124 X 0 1 1 Bit 123 X X 0 0 Bit 122 X X 0 1 Format Notation bit map 0 1024 range 512 range 256 range
Issue 01 (2008-06-10)
3-3
Bit 128 1 1
Bit 127 0 0
Bit 124 1 1
Bit 123 1 1
Bit 122 0 1
Format Notation 128 range variable bit map
Different formats of cell channel description correspond to different numbers of available cell frequencies. Assume that the number of available frequencies for a cell is n (except for duplicate and invalid frequencies). ARFCN(i) (i=1,,n) represents the Absolute Radio Frequency Channel Number. The numbers of available frequencies for different formats of cell channel description are as follows:
Bit map 0 The bit map 0 format is used for GSM 900 frequencies. The number of available frequencies is 64 if 1 ARFCN(i) 124.
1024 range If the 1024 range format is used, the number of available frequencies for a cell is equal to or smaller than 16. For a GSM 900 cell, 1 ARFCN (i) 124. For a GSM 1800 cell, 512 ARFCN (i) 885.
512 range If the 512 range format is used, the number of available frequencies for a cell is equal to or smaller than 18. The interval between any two frequencies must be less than 512.
256 range If the 256 range format is used, the number of available frequencies for a cell is equal to or smaller than 22. The interval between any two frequencies must be less than 256. For example, in 128 range format, frequency 512 and frequency 812 cannot be configured together.
128 range If the 128 range format is used, the number of available frequencies for a cell is equal to or smaller than 29. The interval between any two frequencies must be less than 128. For example, in 128 range format, frequency 512 and frequency 712 cannot be configured together.
Variable bit map If the variable bit map format is used, the number of available frequencies for a cell is equal to or smaller than 64. The interval between any two frequencies must be 1111. For example, in variable bit map format, you can configure 64 frequencies numbered from 512 to 575 with an increment of 1. However, you cannot configure 64 frequencies numbered from 512 to 638 with an increment of 2.
NOTE
The early-mentioned restrictions are mainly for the GSM1800 frequencies.

l
RACH Control Para The RACH control parameters include the following:
Max Retrans Maximum number of retransmissions (Max Retrans) defines the maximum number of channel request messages that can be resent before a MS receives an immediate
3-4
Issue 01 (2008-06-10)
assignment message. Therefore, the number of channel request messages that an MS can send is M (Max Retrans) plus 1. The parameter has two bits, ranging from 0 to 3. The corresponding maximum numbers of retransmissions are 1, 2, 4, and 7.
Tx_integer Number of slots to spread transmission (Tx-integer) defines the number of timeslots between two consecutive transmissions of channel request messages.
Cell Bar Access Cell Bar Access (CBA) determines whether an MS can gain access to a cell. It has only one bit. Value 0 of this bit means that the MS can access the cell, and value 1 of this bit means the MS cannot access the cell. This parameter does not affect the handover access of the MS.
AC Access Control Class N (AC CN) defines the access class for an MS. Each class is represented by a bit. N = 0, 1, 9, 11, , 15, totally 16 bits. If the AC CN bit is 1, the access of an MS with AC C = N is barred. Otherwise, the access of the MS with AC C = N is permitted. The MSs of classes 1115 have a higher access priority than the MSs of classes 09. The MSs of classes 11-15 have the same priority. So do the MSs of classes 09.
RE Call reestablishment allowed (RE) determines whether call reestablishment is allowed when call drops occur. The parameter has one bit. Value 0 means that call reestablishment is allowed in the cell. Value 1 means that call reestablishment is not allowed in the cell.
EC Emergency call allowed (EC) determines whether emergency calls are allowed when there is no SIM or the access is barred. The parameter has one bit. Value 0 means that emergency calls are allowed in the cell to all MSs. Value 1 means that emergency calls are not allowed in the cell except for the MSs that belong to classes 1115.
NOTE
A random value, which belongs to {S, S+1,....S+T-1}, is used as the time interval between two consecutive transmissions of channel request messages sent by an MS. The units of timeslot intervals are TDMA frames. "S" is subject to the configuration of common channels. "T" is Txinteger. Table 3-4 lists the relation between "S" and "T". Table 3-4 Relation between "S" and "T" Tx-Integer 3, 8, 14, 50 4, 9, 16 5, 10, 20 6, 11, 25 Non Combined CCCH 55 76 109 163 Combined CCCH 41 52 58 86
Issue 01 (2008-06-10)
3-5

Non Combined CCCH 217
Tx-Integer 7, 12, 32
Combined CCCH 115
When satellite transmission is used, Huawei recommends that Max retrans be set to 4 and Txinteger be set to 32 to reduce the delay caused by satellite transmission.
l
SI 1 Rest Octets The SI 1 Rest Octets information element has eight bits. It contains indication information about the PCS1900 and the DCS1800 and spare bits.
3.1.2 System Information Types 2, 2bis, 2ter, and 2quater

This topic describes the functions and contents of System Information Types 2, 2bis, 2ter, and 2quater.
Functions
l
System Information Type 2 is sent on the BCCH. It provides information about the RACH control, NCC Permitted, and the BCCH allocation (BA1) in the neighbor cells.
Generally, System Information Types 2, 2bis, and 2ter describe different parts of the BA1 list. The MS reads and decodes the BA1 list and then performs cell reselection in idle mode. A PHASE1 MS in GSM900 recognizes only the neighbor cell frequencies described in System Information Type 2 and ignores that described in System Information Types 2bis and 2ter.
System Information Type 2bis is sent optionally on the BCCH. It provides information about the RACH control and the extension of the BCCH allocation in the neighbor cells (part of BA1). System Information Type 2 does not describe all the frequencies in the BA1 list. Therefore, System Information Type 2bis describes the rest of the frequencies that are on the same frequency band. System Information Type 2ter is sent on the BCCH. It provides information about the extension of the BCCH allocation in the neighbor cells (part of BA1). Only the dual-band MSs read this message. The GSM900 MSs and the GSM1800 MSs ignore this message because of band difference. System Information Type 2quater provides information about the BCCH allocation in the 3G neighbor cells under the condition that the inter-system handover is supported and the 3G neighbor cells are configured. It is used for the reselection of 3G cells.
Contents
Table 3-5 lists the contents of System Information Type 2, 2bis, 2ter, and 2quater. Table 3-5 Contents of System Information Type 2, 2bis, 2ter, and 2quater Type SYS INFO 2 Contents Neighbor Cell Desc NCC permitted
Type
Contents RACH Control Para
SYS INFO 2 BIS
Neighbor Cell Desc RACH Control Para
SYS INFO 2TER SYS INFO 2QUATER
Neighbor Cell Desc. (Extended) SI 2quater Rest Octets
The contents of System Information Type 2, 2bis, 2ter, and 2quater are described as follows:
l
Neighbor Cell Description (BA1) The Neighbor Cell Description information element provides the absolute channel numbers of the BCCH carriers in the neighbor cells of the current cell. Currently, Huawei supports a maximum of 32 neighbor cells per cell. Except for bit 5 (BA-IND) and bit 6 (EXT-IND) of octet 2, the Neighbor Cell Description information element is coded as the Cell Channel Description information element. For details, refer to the cell channel description in 3.1.1 System Information Type 1.
The extension indication (EXT-IND) is sent in System Information Types 2 and 5. It indicates whether there are extended neighbor cell frequencies sent in System Information Types 2bis and 5bis. If the EXT-IND bit is set to 0, System Information Types 2 and 5 carry the complete BA. If the EXT-IND bit is set to 1, System Information Types 2 and 5 carry only a part of the BA. The BA indication (BA-IND) is sent in System Information Types 2 and 5. It has one bit and is used by the MS to discriminate the changes in the BA1 or the BA2. If the neighbor cell relation and the BA2 are modified during the conversation, the BA-IND bit in System Information Type 5 should be 1, indicating that the MS should decode the neighbor cell frequencies again.
NCC Permitted The NCC Permitted information element is sent in System Information Types 2 and 6. It has eight bits and provides all the NCCs required by MSs. If bit N is 0 (0 N 7), the MS does not measure the power level of the cell where the NCC is N, which means that the MS is not handed over to the network where the NCC is N. The NCC Permitted information element is mainly used for handovers and cell reselection.
RACH Control Para For details about the RACH Control Para information element, refer to 3.1.1 System Information Type 1.
Neighbor Cell Desc. (Extended) The Neighbor Cell Desc. (Extended) information element is sent in System Information Types 2ter and 5ter. Except for bit 5 (BA-IND) and bits 6 and 7 (Multiband_Reporting) of octet 2, this information element is coded as the Cell Channel Description information element. For details, refer to 3.1.1 System Information Type 1.
Multiband_Reporting The Multiband Reporting information element is sent in System Information Types 2ter and 5ter. It has two bits and is used to request the dual-band MS to report information about neighbor cells of multiple bands. For details, refer to Table 3-6.
Issue 01 (2008-06-10)
3-7
Table 3-6 Multiband reporting Multiband Reporting (2 bits) 0 1 Meaning The MS reports six cells where the signal strength is the strongest, irrespective of the band used. The MS reports a neighbor cell that is on a different band. It reports in the other five positions the neighbor cells that are on the same band. The MS reports two neighbor cells that are on a different band. It reports in the other four positions the neighbor cells that are on the same band. The MS reports three neighbor cells that are on a different band. It reports in the other three positions the neighbor cells that are on the same band.
10
11
SI 2quater Rest Octets The SI 2quater Rest Octets information element has the following parameters:

BA_IND, 3G_BA_IND, and MP_CHANGE_MARK 3G Neighbor Cell Description and Index_Start_3G UTRAN FDD Description and UTRAN TDD Description 3G MEASUREMENT PARAMETERS Description

Functions
System Information Type 3 describes the location area identification, cell identity, RACH control, and parameters of cell selection. They are mandatory and sent on the BCCH.
Contents
Table 3-7 lists the contents of System Information Type 3. Table 3-7 Contents of System Information Type 3 Type SYS INFO 3 Contents Cell Identity LAI Cell Option (BCCH) Cell Selection Para RACH Control Para
Type
Contents SI 3 Rest Octets

l
CGI The Cell Global Identification (CGI) consists of the Location Area Identification (LAI) and the Cell Identity (CI). The LAI consists of the Mobile Country Code (MCC), the Mobile Network Code (MNC), and the Location Area Code (LAC). System Information Types 3, 4, and 6 contain all or part of the CGI information. Upon receiving the system information, the MS decodes the CGI. Based on the MCC and the MNC, the MS determines whether to access the network of the cell and whether the current location area has changed or not. If the location area has changed, the MS initiates a location update procedure.
The MCC is unique worldwide. It consists of three decimal numerals. For example, the MCC of China is 460. The MNC is unique nationwide. It consists of two decimal numerals. For example, the MNC of China Mobile is 00, and the MNC of China Unicom is 01. The LAC and the CI are planned by each GSM network operator. Both the LAC and the CI have two octets. The CI ranges from 0X0001 to 0XFFFE. 0X0000 and 0XFFFF are reserved.
Control Channel Desc The Control Channel Description information element has the following parameters:
MSCR The MSC Release (MSCR) parameter indicates the release of an MSC. The parameter has one bit. If the bit is 0, the MSC is released in 1998 or earlier. If it is 1, the MSC is released in 1999 or later.
ATT The Attach-Detach Allowed (ATT) parameter indicates whether the MS is allowed to initiate an IMSI attach and detach procedure. The ATT has one bit. If it is 0, the procedure is not allowed. If it is 1, the procedure is allowed.
CCCH-CONF The CCCH-CONF parameter determines the combination mode of the CCCH. The CCCH-CONF has three bits. Table 3-8 describes the meaning of the CCCH-CONF. Table 3-8 Meaning of the CCCH-CONF CCCH-CONF (Three Bits) Number of CCCH Message Blocks in One BCCH Multiframe 9 Meaning
000
One basic physical channel used for CCCH, not shared with SDCCHs
Issue 01 (2008-06-10)
3-9
CCCH-CONF (Three Bits)
Number of CCCH Message Blocks in One BCCH Multiframe 3 18
Meaning
001 010
One basic physical channel used for CCCH, shared with SDCCHs Two basic physical channels used for CCCH, not shared with SDCCHs Three basic physical channels used for CCCH, not shared with SDCCHs Four basic physical channels used for CCCH, not shared with SDCCHs Reserved
100
27
110
36
Others
BS_AG_BLKS_RES The BS_AG_BLKS_RES parameter indicates the proportion of AGCH message blocks in the CCCH message blocks.

If the CCCH-CONF is 001, the BS_AG_BLKS_RES ranges from 0 to 2. If the CCCH-CONF is not 001, the BS_AG_BLKS_RES ranges from 0 to 7. After the CCCH-CONF is set, the BS_AG_BLKS_RES is actually used to determine the proportions of AGCHs and PCHs on the CCCH. You can modify the BS_AG_BLKS_RES to balance the loading of AGCHs and PCHs.
BS-PA-MFRAMS The BS-PA-MFRAMS parameter indicates the number of multiframes contained in the period of a paging subchannel. It actually determines the number of paging subchannels contained in the paging channel of a cell. It has three bits. The value range is 0-7, representing 2-9 multiframes contained in the period of a paging subchannel respectively.
T3212 The timeout value of timer T3212 indicates the frequency of periodic location update. It has eight bits. The value range is 0-255. Each unit indicates six minutes. Value 0 indicates that periodic location update is not performed.
Cell Selection Para The Cell Selection Para affect the activities of an MS after it is switched on. These parameters include the following:
Cell Reselection Hysteresis An MS can perform cell reselection only if the difference between the signal level of the neighbor cell (in a different location area) and the C2 of the local cell is greater than the value of Cell Reselection Hysteresis. The parameter has three bits. The value range is 0-7, representing 0-14 dB respectively.
MS_TXPWR_MAX_CCH
3-10
The MS_TXPWR_MAX_CCH parameter indicates the transmit power the MS may use before it receives the power control command. The parameter has five bits, ranging from 0 to 31. Each value corresponds to the output power of an MS.
RXLEV_ACCESS_MIN The RXLEV_ACCESS_MIN indicates the minimum received signal level required for the MS to access the system. It has six bits. The value range is 0-63, representing the signal level of -110 dBm to -47 dBm respectively.
ACS The ACS parameter indicates whether the MS uses C2 during cell reselection. It has only one bit. In System Information Type 3, this parameter is meaningless. In System Information Type 4, value 0 of the bit indicates that the SI4 REST of System Information Type 4 is used to calculate the parameters related to C2. Other values indicate that the REST of System Information Types 7 and 8 are used to calculate the parameters related to C2.
NECI The NECI parameter indicates whether the current cell supports half rate services or not. It has only one bit. Value 0 of the bit indicates that the current cell does not support half rate services. Value 1 of the bit indicates that the current cell supports half rate services.
RACH Control Para For details, refer to 3.1.1 System Information Type 1. SI 3 Rest Octets The SI3 Rest Octets information element has the following parameters:
PI The PI parameter indicates whether the MS uses C2 as the cell reselection parameter and whether the parameter used to calculate C2 exists or not. It has only one bit. Value 0 of the bit indicates that the MS uses C1 as the cell reselection parameter. Value 1 of the bit indicates that the MS uses C2 that is derived from the system information as the cell reselection parameter.
CBQ The Cell Bar Qualify (CBQ) parameter has only one bit. Along with CELL_BAR_ACCESS, it indicates the priority of a cell. For details, refer to Table 3-9. Table 3-9 Parameters affecting cell priority in cell selection CBQ 0 0 1 1 CBA 0 1 0 1 Priority of Cell Selection Normal Barred Low Low Status of Cell Reselection Normal Barred Normal Normal
CRO
Issue 01 (2008-06-10)
The CELL_RESELECT_OFFSET (CRO) parameter applies an offset to C2. It has six bits. The range of the signal level is 0126 dB. Along with TO and PT, the CRO is used to regulate C2 manually.
TO The value range of the TEMPORARY_OFFSET (TO) parameter is 07. Each level represents 10 dB. For example, 0 refers to 0 dB, 1 refers to 10 dB, 6 refers to 60 dB, and 7 refers to infinity.
PT The value range of the PENALTY_TIME (PT) parameter is 031. Each level represents 20 seconds. For example, 0 refers to 20 s and 30 refers to 620 s. 31 is reserved to indicate that CRO is subtracted from C2 and that TO is ignored.
2TerI The 2TerI parameter indicates whether System Information Type 2ter can be obtained or not.
ECSC The Early Classmark Sending Control (ECSC) parameter indicates whether the ECSC is allowed or not.
GPRS The GPRS parameter indicates whether the GPRS is supported or not. SI2quaterI The SI2quaterI parameter indicates whether System Information Type 2quater can be obtained or not.

Functions
System Information Type 4 provides information about the location area identification, RACH control, cell selection parameters, and CBCH.
l
Information about location area identification, RACH control, cell selection parameters is mandatory, it is sent on the BCCH. Information about CBCH is optional. It describes the configurations of the CBCH and the related frequency information and is used when the system supports cell broadcast.
Contents
Table 3-10 lists the contents of System Information Type 4. Table 3-10 Contents of System Information Type 4 Type SYS INFO 4 Contents LAI Cell Selection Para RACH Control Para
Type
Contents CBCH Channel Desc. (optional) CBCH Mobile Allocation (optional) SI4 Rest Oct

l
Location Area Identification (LAI) For details, refer to 3.1.3 System Information Type 3. Cell Selection Para. For details, refer to 3.1.3 System Information Type 3. RACH Control Para. For details, refer to 3.1.2 System Information Types 2, 2bis, 2ter, and 2quater. CBCH Channel Description and CBCH Mobile Allocation (CBCH MA) Both CBCH Channel Description and CBCH MA are optional. If the system supports cell broadcast, CBCH Channel Description indicates the configuration of the CBCH. If the CBCH is in frequency hopping mode, CBCH MA is mandatory.
SI4 Rest Oct. If the cell selection parameter ACS is set to No, the SI4 Rest Oct. is used to calculate the cell reselection parameter C2. The criteria for cell reselection are as follows:

If PENALTY_TIME = 31, C2 = C1 - CELL_RESELECT_OFFSET If PENALTY_TIME is not equal to 31, C2 = C1 + CELL_RESELECT_OFFSET TEMPORARY_OFFSET x H(PENALTY_TIME-T) For a non-serving cell, if x < 0, H (x) = 0; if x >= 0, H (x) = 1. For a serving cell, H (x) = 0.
The SI4 Rest Oct. information element has the following parameters:
PI For details, refer to 3.1.3 System Information Type 3. Cell Bar Qualify (CBQ) For details, refer to 3.1.3 System Information Type 3. CELL_RESELECT_OFFSET (CRO) For details, refer to 3.1.3 System Information Type 3. TEMPORARY_OFFSET (TO) For details, refer to 3.1.3 System Information Type 3. PENALTY_TIME (PT) For details, refer to 3.1.3 System Information Type 3.
3.1.5 System Information Types 5, 5bis, and 5ter

This describes the functions and contents of System Information Types 5, 5bis, and 5ter.
Functions
l
System Information Type 5 provides the frequency information of the neighbor cells (BA2). This information is mandatory and is sent on the SACCH. Different from System Information Type 2, the MS can read the frequency information described in System Information Type 5 when it is in the conversation state and report the information about the neighbor cells in the measurement report. Such information is used for handovers. A PHASE1 MS in GSM900 recognizes only the neighbor cell frequencies described in System Information Type 5 and ignores the neighbor cell frequencies described in System Information Types 5bis and 5ter. System Information Type 5bis provides the frequency information of the neighbor cells (part of BA2). This information is optional and is sent on the SACCH. System Information Type 5 does not describe all the frequencies in the BA1 list. Therefore, System Information Type 5bis describes the rest of the frequencies in the BA2 that are on the same frequency band. System Information Type 5ter provides the frequency information of the neighbor cells (part of BA2). This information is sent on the SACCH and is read only by the dual-band MSs. The GSM900 MSs and the GSM1800 MSs ignore this information.
Contents
Table 3-11 lists the contents of System Information Type 5, 5bis, and 5ter. Table 3-11 Contents of System Information Type 5, 5bis, and 5ter Type SYS INFO 5 SYS INFO 5 BIS SYS INFO 5TER Contents Neighbor Cell Desc Neighbor Cell Desc Neighbor Cell Desc. (Extended)
The contents of System Information Type 5, 5bis, and 5ter are described as follows:
l
Neighbor Cell Desc For details, refer to 3.1.2 System Information Types 2, 2bis, 2ter, and 2quater. Neighbor Cell Desc. (Extended) For details, refer to 3.1.2 System Information Types 2, 2bis, 2ter, and 2quater.

Functions
System Information Type 6 provides information about the location area identification, cell identity, and other parameters of cell functions. These information is mandatory and is sent on the SACCH.
Contents
Table 3-12 lists the contents of System Information Type 6. Table 3-12 Contents of System Information Type 6 Type SYS INFO 6 Contents LAI Cell Identity Cell Option (SACCH) NCC Permitted

l
Cell Global Identification (CGI) For details, refer to 3.1.3 System Information Type 3. Cell Option For details, refer to 3.1.3 System Information Type 3. NCC Permitted For details, refer to 3.1.2 System Information Types 2, 2bis, 2ter, and 2quater.

Functions
System Information Type 7 is sent on the BCCH. It provides information about cell reselection parameters.
Contents
Table 3-13 lists the contents of System Information Type 7. Table 3-13 Contents of System Information Type 7 Type SYS INFO 7 Contents SI 7 Rest Octets

l
SI 7 Rest Octets contains the cell selection and reselection parameters used by the MS. It may also contain the Power Offset parameter used by the DCS1800 Class 3 MS.
Issue 01 (2008-06-10)

l
The coding scheme of SI 7 Rest Octets is the same as that of SI 4 Rest Octets. For details, refer to 3.1.4 System Information Type 4.

This describe the functions and contents of System Information Type 8.
Functions
System Information Type 8 is mandatory and is sent on the BCCH. It provides information about cell reselection parameters.
Contents

l
The SI 8 Rest Octets information element contains the cell reselection parameters used by the MS. It may also contain the Power Offset parameter used by the DCS1800 Class 3 MS. The coding scheme of SI 8 Rest Octets is the same as that of SI 4 Rest Octets. For details, refer to 3.1.4 System Information Type 4.

This describe the functions and contents of System Information Type 13.
Functions
System Information Type 13 is sent on the BCCH by the network. It provides information about parameters related to GPRS services.
Contents
The SI 13 Rest Octets information element has the following parameters:


l
BCCH_CHANGE_MARK The BCCH_CHANGE_MARK parameter has three bits. It changes according to the messages sent on the BCCH.
SI_CHANGE_FIELD The SI parameter is binary and indicates that the last bit of the BCCH_CHANGE_MARK parameter has changed. It has four bits and ranges from 0 to 15.
SI13_CHANGE_MARK The SI13_CHANGE_MARK parameter ranges from 0 to 3. RAC The RAC parameter is binary and indicates the routing area code. It has eight bits. SPGC_CCCH_SUP The SPGC_CCCH_SUP parameter indicates whether the CCCH supports the SPLIT_PG_CYCLE parameter. Value 0 indicates that the CCCH does not support SPLIT_PG_CYCLE. Value 1 indicates that the CCCH supports SPLIT_PG_CYCLE.
PRIORITY_ACCESS_THR The PRIORITY_ACCESS_THR parameter indicates whether packet access is supported. It has three bits. Value 000 indicates that packet access is not supported. Values 001 and 010 are reserved, indicating by default that packet access are not supported. Values 011, 100, 101, and 110 indicate that users of priorities 1, 1 and 2, 1 to 3, and 1 to 4, respectively, support packet access. Value 111 is reserved, indicating that packet access is supported.
NETWORK_CONTROL_ORDER The NETWORK_CONTROL_ORDER parameter has two bits. Value 00 indicates that the cell controls cell reselection and no measurement reports are sent. Value 01 indicates that the cell controls cell reselection and the MS sends the measurement reports. Value 10 indicates that the network controls cell reselection and the MS sends the measurement reports. Value 11 is reserved.
PSI1_REPEAT_PERIOD The PSI1_REPEAT_PERIOD parameter indicates the retransmit period of the PSI1. It has four bits. Value 0000 indicates that the retransmit period is one multiframe. Value 0001 indicates that the retransmit period is two multiframes. Value 0010 indicates that the retransmit period is three multiframes. By analogy, value 1110 indicates that the retransmit period is 15 multiframes and value 1111 indicates that the retransmit period is 16 multiframes.
System Information Type 13 also includes parameters such as the GPRS Mobile Allocation, GPRS Cell Options, GPRS Power Control, Parameters struct, and PBCCH Description struct.
3.2 Internal BSC Signaling Procedure of the System Information

This describes the internal BSC signaling procedure of the system information.
System Information Type 1

You can obtain the Cell Frequency in System Information Type 1 in the Set Cell Attributes dialog box.
Table 3-16 describes the mapping between the RACH control parameters in System Information Type 1 and the corresponding parameters on the BSC6000 Local Maintenance Terminal. Table 3-16 Mapping between RACH control parameters in System Information Type 1 and the corresponding parameters on the BSC6000 Local Maintenance Terminal RACH Control Parameters in System Information Type 1 Max Retrans Tx_interger Cell Bar Access AC RE EC Parameters on the BSC6000 Local Maintenance Terminal MS MAX Retrans Tx_interger Cell_Bar_ Access Common Access Control Class and Special Access Control Class Call Reestablishment Forbidden EC allowed
To configure the parameters listed in the table on the BSC6000 Local Maintenance Terminal, do as follows:
l
In the dialog box shown in Figure 3-1, click Call Control. Then set MS MAX retrans, Common Access Control Class, Special Access Control Class, and Emergent Call Disable. In the dialog box shown in Figure 3-1, click Idle Mode. Set Tx-integer (RACH Timeslot that equals to a TDMA frame, 4.615ms) and Cell_Bar_Access. In the dialog box shown in Figure 3-1, set Call Reestablishment Forbidden.
3-18
Issue 01 (2008-06-10)
Figure 3-1 Set Cell Attributes dialog box
NOTE
If cell flow control is enabled, the MAX Retrans and Tx_interger parameters in System Information Type 1 are automatically regulated according to the current flow control system.
System Information Types 2, 2bis, 2ter, and 2quater

l
The information on neighbor cell frequencies in System Information Types 2, 2bis, and 2ter is obtained from the 2G BA1 Table.
The NCC Permitted parameter in System Information Type 2 is obtained from the NCC Permitted field in Idle Mode. The RACH Control Parameters in System Information Types 2 and 2bis are the same as that in System Information Type 1. For details, refer to Table 3-16.
The information in System Information Type 2quater is obtained from the UTRAN System Message, UTRAN FDD Cell BA1, and UTRAN TDD Cell BA1.
Issue 01 (2008-06-10)
l
In the dialog box shown in Figure 3-1, click Idle Mode, select Advanced, and then set the neighbor cell frequency in 2G BA1 Table. In the dialog box shown in Figure 3-1, click Idle Mode. Then set NCC Permitted. In the dialog box shown in Figure 3-1, click Call Control, and then click Advanced. Then set the UTRAN system message in UTRAN System Message. In the dialog box shown in Figure 3-1, click Idle Mode, and then click Advanced. Then set the UTRAN neighbor cell frequency in UTRAN FDD Cell BA1. In the dialog box shown in Figure 3-1, click Idle Mode, and then click Advanced. Then set the UTRAN neighbor cell frequency in UTRAN TDD Cell BA1.
l l

The CGI in System Information Type 3 is obtained from the Set Cell Attributes dialog box. Table 3-17 lists the control channel parameters in System Information Type 3 and the corresponding parameters on the BSC6000 Local Maintenance Terminal. Table 3-17 Control channel parameters in System Information Type 3 and the corresponding parameters on the BSC6000 Local Maintenance Terminal Control Channel Parameters in System Information Type 3 ATT CCCH-CONF BS_AG_BLKS_RES BS-PA-MFRAMS T3212 Parameters on the BSC6000 Local Maintenance Terminal ATT CCCH Conf BS_AG_BLKS_RES BS-PA-MFRARMS Period of Periodic Location Update (6 minutes)
To configure the parameters listed in the table on the BSC6000 Local Maintenance Terminal, do as follows: In the dialog box shown in Figure 3-1, click Idle Mode. Set ATT, CCCH-CONF, BS_AG_BLKS_RES, BS-PA-MFRAMS, andT3212. Table 3-18 lists the cell option parameters in System Information Type 3 and the corresponding parameters on the BSC6000 Local Maintenance Terminal. Table 3-18 Cell option parameters in System Information Type 3 and the corresponding parameters on the BSC6000 Local Maintenance Terminal Cell option parameters in System Information Type 3 PWRC
3-20
Parameters on the BSC6000 Local Maintenance Terminal PWRC
Issue 01 (2008-06-10)
Cell option parameters in System Information Type 3 DTX Radio Link Timeout
Parameters on the BSC6000 Local Maintenance Terminal UL DTX Radio Link Timeout
l
In the dialog box shown in Figure 3-1, click Other Attributes, and then click Advanced. On the Public Channel Control tab page, set PWRC. In the dialog box shown in Figure 3-1, set UL DTX. In the dialog box shown in Figure 3-1, click Call Control. Set Radio Link Timeout (SACCH period (480ms)).
l l
Table 3-19 lists the cell option parameters in System Information Type 3 and the corresponding parameters on the BSC6000 Local Maintenance Terminal. Table 3-19 Cell selection parameters in System Information Type 3 and the corresponding parameters on the BSC6000 Local Maintenance Terminal Cell Selection Parameters in System Parameters on the BSC6000 Local Information Type 3 Maintenance Terminal Cell Reselection Hysteresis MS_TXPWR_MAX_CCH RXLEV_ACCESS_MIN ACS NECI CRH MS_TXPWR_MAX_CCH RXLEV_ACCESS_MIN PI Support Half Rate
l l
In the dialog box shown in Figure 3-1, click Idle Mode. Set CRH and ACS. In the dialog box shown in Figure 3-1, click Other Attributes, select Advanced and Common Channel Control, and then set MS_TXPWR_MAX_CCH and Half rate supported. In the dialog box shown in Figure 3-1, set RXLEV_ACCESS_MIN.
The RACH Control Parameters information element in System Information Type 3 is the same as that in System Information Type 1. For details, refer to Table 3-16.

The Location Area Identification in System Information Type 4 is obtained from the Set Cell Attributes dialog box.
For the Cell Selection Parameters, see Table 3-19. The RACH Control Parameters information element in System Information Type 4 is the same as that in System Information Type 1. For details, see Table 3-16. Table 3-20 lists the Rest Oct parameters in System Information Type 4 and the corresponding parameters on the BSC6000 Local Maintenance Terminal. Table 3-20 Rest Oct parameters in System Information Type 4 and the corresponding parameters on the BSC6000 Local Maintenance Terminal Rest Oct Parameters in System Information Type 4 PI CBQ Cell Bar Quality CRO TO TO, TEMPORARY_OFFSET PT Parameters on the BSC6000 Local Maintenance Terminal PI Cell_Bar_Qualify CRO (2dB) TO PT (s)
l l
In the dialog box shown in Figure 3-1, click Idle Mode. Set PI, CBQ, and CRO (2 dB). In the dialog box shown in Figure 3-1, click Idle Mode, and then click Advanced. On the Idle Parameter tab page, set TO and PT.
Other System Information

l
The information on neighbor cell frequencies in System Information Types 5, 5bis, and 5ter is obtained from the 2G BA2 Table, UTRAN FDD Cell BA1, and UTRAN TDD Cell BA1. To configure the parameters listed in the table on the BSC6000 Local Maintenance Terminal, do as follows:
Click HO Data, and then select Advanced and 2G BA2 Table. Then set the corresponding parameters. In the dialog box shown in Figure 3-1, click HO Data, and then select Advanced and UTRAN FDD Cell BA1. Then set the corresponding parameters. In the dialog box shown in Figure 3-1, click HO Data, and then select Advanced and UTRAN TDD Cell BA1. Then set the corresponding parameters.
The CGI in System Information Type 6 is obtained from the Set Cell Attributes dialog box. The Cell Options information element in System Information Type 6 is the same as that in System Information Type 3. For details, see Table 3-18. The procedure for configuring NCC Permitted is the same as that for configuring NCC Permitted in System Information Type 2.
3-22
Issue 01 (2008-06-10)

l
The Rest Oct in System Information Type 7 is the same as that in System Information Type 4. For details, see Table 3-20. The Rest Oct in System Information Type 8 is the same as that in System Information Type 4. For details, see Table 3-20. System Information Type 13 is not processed in the BSC and is directly forwarded to the BTS.
Issue 01 (2008-06-10)
3-23
4 Immediate Assignment
4
About This Chapter
Immediate Assignment
This describes immediate assignment, which consists of the immediate assignment procedure, internal BSC signaling procedure, and abnormal cases and handling suggestions. 4.1 Immediate Assignment Procedure This describes the immediate assignment procedure. 4.2 Internal BSC Signaling Procedure (Immediate Assignment) This describes the internal BSC signaling procedure of immediate assignment. 4.3 Abnormal Cases and Handling Suggestions (Immediate Assignment) This describes the abnormal cases of immediate assignment, probable causes, and handling suggestions.
Issue 01 (2008-06-10)
4-1
4.1 Immediate Assignment Procedure

This describes the immediate assignment procedure. The purpose of immediate assignment is to establish a Radio Resource (RR) connection between an MS and the network on the Um interface. The immediate assignment procedure is initiated by the MS. Figure 4-1 shows the immediate assignment procedure. Figure 4-1 Immediate assignment procedure
MS Channel Request(1) RACH Channel Required(2) Channel Activation(3) Channel Activation Acknowledge(4) Immediate Assignment Command(5) AGCH SABM(6) main DCCH UA(7) main DCCH Establish Indication(8) Start T3101 BTS BSC
Stop T3101
The previous procedure is described as follows: 1. The MS sends the BTS a Channel Request message on the RACH. The Channel Request message contains the Establish Cause and Random Reference parameters. It has eight bits. Bits 3 to 6 indicate the access cause, and bits 5 to 2 carry the identifier. Based on a Channel Request message, a maximum of 32 MSs are distinguished. The UA response messages on the Um interface are used to distinguish more MSs. 2. The BTS sends the BSC a Channel Required message. The Channel Required message contains the Request Reference and Access Delay parameters. The Request Reference information element contains the random access reference value and the absolute frame number of the received access burst. The Access Delay is the delay of the access burst. 3. Upon receiving the Channel Required message, the BSC assigns a signaling channel and sends the BTS a Channel Activation message to activate the resources. The Channel
4-2
Activation message carries the activation type, channel description, level, and time advance (TA). 4. Upon receiving the Channel Activation message, if the activated parameter is correct, the BTS turns on the power amplifier on the specified channel to receive information in the uplink direction and sends the BSC a Channel Activation Acknowledge message. The message contains the absolute frame number so that the BSC can determine the Starting Time parameter. The BSC sends through the BTS to the MS an Immediate Assignment Command message. On the Um interface, the message is sent on the AGCH. It carries the Immediate Assignment Extend message so that the channel efficiency is enhanced. The Immediate Assignment Extend message contains the assignment information about two MSs. The Immediate Assignment Command message has the following information elements:
l
5.
Dedicated mode or TBF The Dedicated mode or TBF information element requests the MS to decode the rest of the message to an Immediate Assignment message or to allocate a Temporary Block Flow.
Page Mode The Paging Mode information element controls the action of the MSs in a paging group. Channel Description The Channel Description information element describes the Channel Type, TDMA offset, timeslot, and absolute RF channel number of an assigned channel and the corresponding SACCH.
Request Reference The Request Reference information element contains the random access reference value and the absolute frame number of the received access burst. The Access Delay is the delay of the access burst.
Time Advance This Time Advance information element provides the initial timing advance value.
If the BSC has no available channels, it sends the MS an Immediate Assignment Reject message or an Immediate Assignment Extend Reject message.
l
After receiving the Immediate Assignment Reject message, the MS starts timer T3122 upon receiving one of the last three channel requests. Before timer T3122 expires, the MS is not permitted to access the network. In addition, the MS returns to the idle mode and waits on the paging channel. Before timer T3122 expires, the MS is not permitted to initiate new access attempts except emergency calls in the same cell. If the Immediate Assignment Reject message is received for the first time, the MS starts timer T3126. Timer T3126 starts when the number of Channel Request messages sent by the MS reaches the maximum value. When timer T3126 expires, the immediate assignment procedure fails.
6.
The MS sends an SABM frame on the main DCCH. The SABM is a frame in the LAPDm protocol at the data link layer. It is the first frame to establish a multiframe acknowledged mode. Two types of message flows co-exist on the Um interface: signaling and short messages. They are identified by the Service Access Point Identifier (SAPI). The service access point is the point at which the data link layer provides services to layer 3. SAPI 0 supports the transfer of signaling, and SAPI 3 supports the transfer of short messages. In the GSM network, an SABM frame carries the layer 3 service request message, which contains the
Issue 01 (2008-06-10)
4-3
identity of the MS and indicates which service the MS is requesting. The layer 3 service request messages are categorized into CM service requests, location update requests, IMSI detach, and paging responses. All these messages contain the IMSI of the MS, detailed access cause, and MS classmarks.
NOTE
The main DCCH is the primary signaling channel and is generally the SDCCH, FACCH, and SACCH.
7.
The BTS responds with a UA frame on the main DCCH. The UA frame is an unnumbered acknowledge frame of the LAPDm protocol at the data link layer. It confirms the SABM frame. When the Channel Request messages sent by two MSs have the same contents, the two MSs may be assigned the same dedicated channel. Upon receiving the SABM frame, the BTS sends the MS a UA frame that contains the same information as the received SABM frame. If the IMSI contained in the SABM frame is different from that in the UA frame, the MS leaves this channel and starts another access attempt. If the IMSI contained in the SABM frame is the same as that in the UA frame, the MS stays on the assigned channel.
8.
The BTS sends the BSC an Establish Indication message. This Establish Indication message indicates the establishment of a radio connection in multi-frame mode and contains parameters Link Identifier and L3 Information. The Link Identifier parameter identifies the signaling channel type and the message priority of SAPI and SAPI 0. L3 Information is a complete layer 3 message.
4.2 Internal BSC Signaling Procedure (Immediate Assignment)

This describes the internal BSC signaling procedure of immediate assignment.
l
Upon receiving the Channel Required message from the BTS, the BSC assigns a signaling channel according to the specified channel type and channel algorithm. During random access, upon receiving the Establish Indication message from the BTS, the BSC sends the MSC a CM Service Request message that carries the target CGI based on the MCC, MNC, LAC, and CI parameters in the Set Cell Attributes dialog box.
4.3 Abnormal Cases and Handling Suggestions (Immediate Assignment)

This describes the abnormal cases of immediate assignment, probable causes, and handling suggestions. 4.3.1 Failure to Receive an Establish Indication Message After Channel Activation (Case Study) This describes the fault, probable causes, and handling suggestions. 4.3.2 BSC Sending an Immediate Assignment Reject Message (Case Study) This describes the fault, probable causes, and handling suggestions.
4-4
Issue 01 (2008-06-10)
4.3.1 Failure to Receive an Establish Indication Message After Channel Activation (Case Study)
This describes the fault, probable causes, and handling suggestions.
Description
The BSC sends the MS an Immediate Assignment Command message but does not receive an Establish Indication message from the BTS.
Analysis
The probable causes are as follows: 1. The design of the MS does not comply with the protocols. The MS sends the Channel Request message for many times and thus the BSS assigns and activates multiple signaling channels. Even when the BSS is functional, the MS may send several Channel Request messages during one RR connection attempt. The BSS activates multiple signaling channels, but the MS uses only one of them. The BSC cannot receive the Establish Indication messages from the MS through other channels and therefore releases the channels after timer T3101 expires. If the number of slots for spread transmission (Tx-integer) is set properly, the reason may be that the BTS receives the uplink signals correctly but the MS cannot receive the downlink signals. Meanwhile, as indicated in the signaling tracing on the Um interface on the MS side, the BSC does not receive a response message from the BTS after sending a Channel Request message. The Tx-integer and the CCCH are not set correctly. The settings of the Tx-integer and the CCCH affect the interval at which an MS resends the Channel Request messages.
2.
3.
Handling Suggestions
l l
For reason 1, ensure that the MS is functional. Make another attempt by using another MS. For reason 2, check that the receive level and receive quality on the uplink and downlink are normal. If the MS is near the BTS, but the receive level is low and the receive quality is poor, check that the antenna system, MS antenna, and MS battery are functional. For reason 3, check that the Tx-integer and the CCCH are set correctly.
4.3.2 BSC Sending an Immediate Assignment Reject Message (Case Study)

Description
Upon receiving the Channel Required message, the BSC sends the MS an Immediate Assignment Reject message.
Analysis
The probable causes are as follows:
1. 2.
The BSC finds no suitable signaling channel, that is, a SDCCH or a TCH, to assign to the MS. This is because that the channels are busy or blocked. Upon receiving a Channel Activation message, the BTS sends the BSC many Channel Activation Negative Acknowledge messages.
l
For reason 1, check that the TRXs are functional and check whether all the channels of the cell are busy or blocked. If all the channels of the cell are busy or blocked, add TRXs to the BTS, modify the access threshold, and enable the directed retry. For reason 2, check whether the channel states on the BSC and the BTS are the same. If not, you can infer that the transmission on the Abis interface is unstable. Check also the BTS boards.
4-6
Issue 01 (2008-06-10)
5 Classmark Update
5
About This Chapter
5.1 Classmark Update Procedure This describes the classmark update procedure.
Classmark Update
The MS classmark specifies the service capability, supported frequency bands, power capability, and ciphering capability of an MS in the GSM network. It is categorized into classmark 1, classmark 2, and classmark 3.
Issue 01 (2008-06-10)
5-1
5 Classmark Update
5.1 Classmark Update Procedure

This describes the classmark update procedure. Figure 5-1 shows the classmark update procedure. Figure 5-1 Classmark update procedure
MS System Information Type3 BSS MSC
SABM SDCCH UA SDCCH Classmark Change(1) SDCCH Classmark Enquiry(4) main DCCH Classmark Change(5) main DCCH Classmark Update(6) Complete Layer 3 Inforamtion Classmark Update(2) Classmark Request(3)
The previous procedure is described as follows: 1. Upon receiving the Classmark Change message, the BSS sends the MSC a Classmark Update message. The Classmark Update message carries the classmark 2 and classmark 3 information elements.
NOTE
The Classmark Update message is bi-directional.
2.
When an MM connection is established between the MS and the MSC, the MSC initiates a classmark update procedure by sending the BSS a Classmark Request message on an SCCP. Upon receiving the Classmark Request message, the BSS:
l l l
3.
Sends the MSC a Classmark Update message Sends the MS a Classmark Enquiry message Takes no action
4.
Upon receiving the Classmark Enquiry message, the MS sends the BSS a Classmark Change message. The Classmark Change message has the same contents as the Classmark Change message described in 1.
5-2

NOTE
5 Classmark Update
If the Early Classmark Sending Control (ECSC) is allowed in System Information Type 3, an MS, for example, a dual-band MS or a vehicle mounted MS, can automatically initiate a classmark update procedure. The MS sends a Classmark Change message on the dedicated channel assigned by the network. The Classmark Change message carries the updated classmark 2 information element or even a classmark 3 information element.
The description of Figure 5-1 is as follows:

l
Figure 5-1 is divided into three parts by the dashed lines, in which the upper part indicates whether the ECSC is supported. Steps (1)-(2) in Figure 5-1 show the classmark update procedure initiated by the MS when the ECSC is allowed in System Information Type 3. Steps (3)-(6) in Figure 5-1 show the classmark update procedure initiated by the MSC.
Issue 01 (2008-06-10)
5-3
6 Location Update
6
About This Chapter
Location Update
In the GSM system, MS location information is stored in the HLR, the VLR, and the MS. When the MS location information is changed, a location update procedure is initiated to maintain consistency among the previous three network elements. 6.1 Location Update Procedure The location update procedure is a general one. It is classified into the generic location update, periodic location update, and IMSI attach procedures. 6.2 Internal BSC Signaling Procedures (Location Update) This describes the internal BSC signaling procedures of location update. 6.3 Abnormal Cases and Handling Suggestions (Location Update) This describes the abnormal cases of location update, probable causes, and handling suggestions.
Issue 01 (2008-06-10)
6-1
6 Location Update
6.1 Location Update Procedure

The location update procedure is a general one. It is classified into the generic location update, periodic location update, and IMSI attach procedures. 6.1.1 Periodic Location Update Procedure This describes the periodic location update procedure and its functions. 6.1.2 IMSI Attach Procedure The IMSI attach procedure is the complement of the IMSI detach procedure. It is used to indicate that the IMSI is active in the network. 6.1.3 Generic Location Update Procedure The generic location update procedure mainly consists of the following: network requesting additional MS capability information, network requesting for identification, and authentication.
6.1.1 Periodic Location Update Procedure

This describes the periodic location update procedure and its functions.
Periodic Location Update Procedure

The generic location update, periodic location update, and IMSI attach procedures are similar. Figure 6-1 shows the periodic location update procedure. Figure 6-1 Periodic location update procedure
MS Channel Request(1) RACH Immediate Assignment Procedure Establish Indication (Location Update Request)(2) Location Updationg Accepted(4) Location Updationg Rejected(5) TMSI Reallocation Complete(6) Clear Command(7) Clear Complete(7) CR(Complete Layer3 Information) CC(3) BTS BSC MSC
SDCCH SDCCH
SDCCH
NOTE
If the location update request is rejected, the MSC returns a Location Updating Reject message.
6-2
Issue 01 (2008-06-10)
6 Location Update
The previous procedure is described as follows: 1. 2. 3. 4. 5. 6. 7. The Immediate Assignment Procedure is initiated. The BTS sends the BSC an Establish Indication message, containing the Location Updating Request message. The BSC establishes an SCCP connection on the A interface and sends the MSC a Complete Layer3 Information message, containing the CGI of the current cell. The MSC responds to the BSC with a Connection Confirm message. The MSC responds to the MS with a Location Updating Accepted message, indicating that the location update is successful. If the network reject this location update, it sends a Location Updating Rejected message to the MS. If Allocate TMSI upon location updating is set to No on the MSC side, the MS does not report the TMSI Reallocation Complete message during the location update. The MSC sends the BSC a Clear Command message to start the resource release procedure on the network side. For details, refer to the Normal Release Procedure.
NOTE
During the Immediate Assignment Procedure, the MS sends the BTS a Channel Request message on the RACH over the Um interface. The cause value carried in this message is location update.
Functions of Periodic Location Update

Periodic location update is used to periodically notify the network of the MS availability. The location update type information element in the Location Updating Request message indicates periodic update. The periodic location update procedure is controlled by timer T3212 in the MS. If the timer is not started, it is started each time the MS enters the Normal Service or Attempting to Update state of the MM Idle state. When the MS leaves the MM Idle state, timer T3212 continues running until it expires. The MM Idle state indicates that the MS is not activated, and does not process any call. For example, in the mobile originated or terminated call procedure, the MS leaves the MM Idle state. Timer T3212 is stopped (and is reset to 0) when:
l l l
A Location Updating Accept or Location Updating Reject message is received. An Authentication Reject message is received. The first MM message such as the Location Updating Accepted or the CM Service Accept message is received, or ciphering mode setting is complete when the MM connection is set up, except when the most recent service state is Limited Service. The MS has responded to paging and has received the first correct layer 3 message except the RR message. Timer T3212 expires. The MS is deactivated, that is, the MS is powered off or the SIM is removed.
l l
When timer T3212 expires, the following cases may occur:

l
The location update procedure is started and the timer shall be set to its initial value for the next start. If the MS is in other states than MM Idle, the location update procedure is delayed until the MS enters the MM Idle state.
Issue 01 (2008-06-10)
6 Location Update
l
If the MS is in the No Cell Available, Limited Service, PLMN Search, or PLMN SearchNormal Service state, the location update procedure is delayed until the MS leaves the service state. If the system information indicates that periodic location update shall not be used, the procedure is not started. The timeout value of timer T3212 is carried by the Control Channel Description IE in the System Information Type 3 message.
The timeout value of timer T3212 is not changed in the No Cell Available, Limited Service, PLMN Search, or PLMN Search-Normal Service states. When timer T3212 is working, if the timeout value is changed because of the change of serving cell or the broadcast of the timeout value of timer T3212, the MS restarts the timer with the value t modulo t1, where t1 is the new timer value, and t is the current timer value. When timer T3212 stops, the MS restarts a new timer with a random value between 1 and t1.
6.1.2 IMSI Attach Procedure

The IMSI attach procedure is the complement of the IMSI detach procedure. It is used to indicate that the IMSI is active in the network. The System Information Type 3 message carries an ATT flag that indicates whether the attach and detach procedures are required to be used. If the IMSI attach and detach procedures are required by the network, the MS will trigger the IMSI attach procedure during IMSI activation. When the MS activates the IMSI within the network coverage area or moves into the coverage area, the IMSI attach procedure is triggered only when the Update Status is Updated and the stored LAI is the same as that broadcast on the BCCH of the current serving cell. Otherwise, a generic location update procedure is triggered, which is independent of the ATT flag indication. IMSI attach is performed through the generic location update procedure. The location update type information element in the Location Updating Request message must in this case indicate IMSI attach.
6.1.3 Generic Location Update Procedure

The generic location update procedure mainly consists of the following: network requesting additional MS capability information, network requesting for identification, and authentication. The generic location update procedure is complicated. It contains the following: network requesting additional MS capability information, network requesting for identification, authentication, ciphering mode setting, and release of the RR connection after location update. If the network does not accept location update, the generic location update procedure also contains the location update reject. To limit the location update attempts, an attempt counter is required.
Network Requesting Additional MS Capability Information

The network may initiate a classmark interrogation procedure to obtain the MS capability information such as the encryption capability and the short message transmission and reception capability.
6-4
Issue 01 (2008-06-10)
6 Location Update
Network Requesting for Identification

The network may initiate an identification request procedure if it cannot get the IMSI from the TMSI and LAI or it requires the IMEI.
Authentication
The authentication procedure may be initiated by the network upon receipt of the Location Updating Request message from the MS.
Ciphering Mode Setting

The ciphering mode setting procedure may be initiated by the network if a new TMSI has to be allocated.
Location Update Reject

If the location update is not accepted, the network sends a Location Updating Reject message to the MS. The MS receiving a Location Updating Reject message stops timer T3210, stores the reject cause, starts timer T3240, enters state Location Updating Rejected, and awaits the release of the RR connection triggered by the network. It deletes the Equivalent PLMNs list when the reject cause is not #12, #14, or #15. Upon the release of the RR connection, the MS takes the following actions depending on the stored reject cause:
l l l
# 2 (IMSI Unknown in HLR) # 3 (Illegal MS) # 6 (Illegal ME)
If the reject value is #2, #3, or #6, the MS sets the update state to Roaming Not Allowed, deletes any TMSI, stored LAI, and ciphering key sequence number, and considers the SIM as invalid until it is switched off or the SIM is removed.
l l l l
# 11 (PLMN not Allowed) # 12 (Location Area not Allowed) # 13 (Roaming not Allowed in This Location Area) # 15 (No Suitable Cells in Location Area)
If the reject value is #11, #12, #13, or #15, the MS deletes any LAI, TMSI, and ciphering key sequence number stored in the SIM, resets the attempt counter, and sets the update state to Roaming Not Allowed. The MS stores the LAI and the PLMN ID in a suitable forbidden list.
l l
If the reject value is #11, the PLMN ID should be stored in the Forbidden PLMN List. If the reject value is #12, the LAI should be stored in the list of Forbidden Location Areas for Regional Provision of Service. If the reject value is #13, the LAI should be stored in the list of Forbidden Location Areas for Roaming. The MS performs a PLMN selection instead of a cell selection when it returns to the MM Idle state. If the reject value is #15, the LAI should be stored in the list of Forbidden Location Areas for Roaming. The MS searches for a suitable cell in another location area of the same PLMN.
Issue 01 (2008-06-10)
6 Location Update
Other reject values are considered as abnormal cases.
Release of the RR Connection After Location Update

When the location update procedure is complete, the MS (except when it has a follow-on application request and has received the proceed indication from the network) sets timer T3240 and enters the Wait For Network Command state, expecting the release of the RR connection. The network may keep the RR connection for a network-initiated MM connection, or may allow a mobile-initiated MM connection. Any release of the RR connection is initiated by the network. If the RR connection is not released when timer T3240 expires, the MS terminates the RR connection. Then the MS enters the MM Idle state. When the MS enters the Normal Service or Attempting to Update state, either timer T3212 or timer T3211 is restarted.
Attempt Counter
When a location update fails, an attempt counter is required. The counter counts the number of consecutive unsuccessful location update attempts and increases by 1 when a location update fails. The attempt counter is reset when:
l l l l
The MS is switched on. A SIM is inserted. A location update is complete. A location update with the cause value 11 (PLMN not Allowed), 12 (Location Area not Allowed), 13 (Roaming not Allowed in This Location Area), or 15 (No Suitable Cells in Location Area) is complete. The service state changes from Attempting to Update. The MS enters a new location area. Timer T3212 expires. The location update is triggered by the CM sublayer requests.
l l l l
The attempt counter is used to decide whether a location update needs to be initiated after timer T3211 expires.
6.2 Internal BSC Signaling Procedures (Location Update)

This describes the internal BSC signaling procedures of location update. On receiving the Channel Required message from the BTS, the BSC assigns a signaling channel. During random access, on receiving the Establish Indication message from the BTS, the BSC sends the MSC a Location Updating Request message that carries the target CGI based on the MCC, MNC, LAC, and CI parameters in the Set Cell Attributes dialog box.
NOTE
You can find the periodic location update time in the Periodic Location Update Time Limit by selecting Idle Mode in the Set Cell Attributes dialog box. The periodic location update time is delivered to the MS through the System Information Type 3 message.
6-6
Issue 01 (2008-06-10)
6 Location Update
6.3 Abnormal Cases and Handling Suggestions (Location Update)

This describes the abnormal cases of location update, probable causes, and handling suggestions. 6.3.1 Location Update Not Started or Terminated on the MS Side (Case Study) This describes the fault, probable causes, and handling suggestions. 6.3.2 Location Update Failure on the Network Side (Case Study) This describes the fault, probable causes, and handling suggestions.
6.3.1 Location Update Not Started or Terminated on the MS Side (Case Study)
Description
The location update procedure is not started or is terminated.
Analysis
l
Access barred because of access class control The location update procedure is not started. The MS stays in the current serving cell and starts the normal cell reselection procedure. The MS starts the location update procedure as soon as it gains access or at cell change.
Receiving an Immediate Assignment Reject message during random access (in A/Gb mode only) The location update procedure is not started. The MS stays in the selected serving cell and starts the normal cell selection procedure. Timer T3122 is reset when a cell change occurs. The location update procedure is started as soon as timer T3122 expires.
Random access failure (in A/Gb mode only) Timer T3213 is started when random access fails. When it expires, the procedure is attempted again if still necessary. If two successive random access attempts fail, the location update procedure attempt is terminated.
RR connection failure The location update procedure is terminated. T3212 expiry The location update and the RR connection are terminated. RR release before the normal end of procedure The location update procedure is terminated. RR connection establishment failure (in Iu mode only) The location update procedure is terminated.
Issue 01 (2008-06-10)
6-7
6 Location Update
Based on the cause values carried by the Location Updating Rejected message, you can also refer to the following suggestions:
l
If the reject value is #2, #3, #6, #11, #12, or #13, check that the subscription information in the HLR and the subscriber data in the VLR are correct. If the reject value is #15, check that the CGI and LAC are consistent on the MSC and BSC sides.
6.3.2 Location Update Failure on the Network Side (Case Study)

Description
Location update fails, and the network sends a Location Updating Reject message.
Analysis
l
RR connection failure
If an RR connection fails during a common procedure integrated with the location update procedure, the behavior of the network is the same as that in a common procedure. If an RR connection fails when a common procedure does not exist, the location update procedure for the MS is terminated.
Location update not accepted by the network If the Location Updating Request message is received with a protocol error, the network returns a Location Updating Reject message with one of the following reject causes:

#03 (Illegal MS) #97 (Message Type Non-Existent or not Implemented) #98 (Message Type not Compatible with the Protocol State) #111 (Protocol Error, Unspecified)
Upon sending the response, the network starts the channel release procedure.
l
Network failure If the MSC, VLR, or HLR is faulty, the network sends a Location Updating Reject message with the cause value #17 (Network Failure). Generally, if the CGI or LAC on the MSC side is inconsistent with that on the BSC side, the cause value may also be #17.
If the cause value is #17, refer to the following suggestions: 1. 2.
6-8
Check that CGI and LAC are correct on the MSC and BSC. Check that both the LAC and the CI are decimal or hexadecimal. Check that the MSC, VLR, and HLR are functional with normal communications.
7 Authentication
7
About This Chapter
7.2 Authentication Procedure This describes the authentication procedure. 7.3 Authentication Reject This describes the authentication reject procedure.
Authentication
The purpose of authentication is to permit the network to check whether the identity provided by the MS is acceptable and to prevent the private information on the legal subscribers from being stolen. 7.1 Authentication Principles The authentication procedure is always initiated and controlled by the network.
7.4 Internal BSC Signaling Procedure (Authentication) This describes the internal BSC signaling procedure of authentication. 7.5 Abnormal Cases and Handling Suggestions (Authentication) This describes the abnormal cases of authentication, probable causes, and handling suggestions.
Issue 01 (2008-06-10)
7-1
7 Authentication
7.1 Authentication Principles

The authentication procedure is always initiated and controlled by the network. The network initiates the authentication procedure in the following cases:
l l
The MS applies to change the subscriber information in the VLR or the HLR. Service access is initiated. For example, when the MS originates a call, is called, activated, or deactivated, or the supplementary service is initiated. The MS accesses the network for the first time after the MSC/VLR restarts. The ciphering key Kc on the network does not match that on the MS.
l l
The authentication has two purposes:

l l
To permit the network to check whether the identity provided by the MS is acceptable To provide parameters that enable the MS to calculate a new ciphering key
The authentication procedure uses an Authentication Triplet, namely RAND, Kc, and SERS. The Authentication Triplet is calculated in the authentication center of the GSM network. When registering in a GSM network, each subscriber is assigned a Mobile Station International ISDN Number (MSISDN) and an International Mobile Subscriber Identity (IMSI). The IMSI is written into the SIM through a SIM writer. The SIM writer also generates an authentication parameter Ki, which is stored in the SIM and the authentication center as well. The IMSI and Ki are permanent information. A pseudo-random number generator is used in the authentication center to generate an unpredictable pseudo random number RAND. In the authentication center, the RAND and Ki generate a signed response (SRES) through algorithm A3 and a ciphering key Kc through algorithm A8. The three parameters RAND, Kc, and SERS constitute an Authentication Triplet, which is stored as part of the subscriber data in the HLR. Generally, the authentication center sends five groups of Authentication Triplet to the HLR at one time. The HLR automatically stores them. The HLR can store ten groups of Authentication Triplet. Upon request, the HLR sends five groups of Authentication Triplet to the MSC/VLR at one time. The MSC/VLR uses the Authentication Triplet one by one. When only two groups are left, the MSC/VLR requests the HLR for the Authentication Triplet again.
7.2 Authentication Procedure

This describes the authentication procedure. Figure 7-1 shows the authentication procedure.
7-2
Issue 01 (2008-06-10)
7 Authentication
Figure 7-1 Authentication procedure

MS BTS BSC MSC
Authentication Request(1) SDCCH Start T3260 Authentication Response(2) SDCCH StopT3260
The previous procedure is described as follows: 1. The network initiates an authentication procedure by sending an Authentication Request message to the MS and starts timer T3260. The Authentication Request message carries a 128-bit RAND that is used to calculate the response parameters. It also carries the Ciphering Key Sequence Number (CKSN) assigned to the ciphering key. Upon receiving the Authentication Request message, the MS calculates the SRES required by the Authentication Response message and the new ciphering key Kc. The SRES is calculated based on the RAND and Ki through algorithm A3. After writing the new ciphering key Kc and the CKSN in the SIM, the MS sends the network an Authentication Response message. Upon receiving the Authentication Response message, the network stops timer T3260 and compares the stored SRES with the SRES in the Authentication Response message. If the SRESs are the same, the authentication procedure is complete, and the successive procedures, for example, the ciphering procedure, start.
2.
7.3 Authentication Reject

This describes the authentication reject procedure. If authentication fails, that is, if the response is not valid, the network may distinguish between the following two ways of identification used by the MS: 1. If the TMSI is used, the network initiates the identification procedure.
l
If the IMSI given by the MS differs from that in the network, the network restarts the authentication procedure. If the IMSI given by the MS is the expected one, the network returns an Authentication Reject message.
2.
If the IMSI is used, the network sends an Authentication Reject message. Figure 7-2 shows the unsuccessful authentication procedure.
Issue 01 (2008-06-10)
7-3
7 Authentication
Figure 7-2 Unsuccessful authentication procedure

MS BTS BSC MSC
Authentication Request(1) SDCCH Authentication Response(2) SDCCH Authentication Reject(3) SDCCH
In either of the following cases, the MS enters the No IMSI substate of the MM Idle state.
l
If the Authentication Reject message is received when the MS is in the IMSI Detach Initiated state, timer T3220 will be stopped after the RR connection is released. If possible, the MS starts the local release procedure after the normal release procedure or timer T3220 expiry. If not possible, for example, during IMSI detachment at MS power-down, the RR sublayer on the MS side is aborted. If the Authentication Reject message is received in any other state, the MS terminates any MM connection establishment or call re-establishment procedure, stops all the timers T3210 or T3230, releases all the MM connections, starts timer T3240, and enters the Wait For Network Command state, expecting the release of the RR connection. If the RR connection is not released when timer T3240 expires, the MS terminates the RR connection.
7.4 Internal BSC Signaling Procedure (Authentication)

This describes the internal BSC signaling procedure of authentication. The authentication is initiated and controlled by the MSC, and the BSC does no special processing.
7.5 Abnormal Cases and Handling Suggestions (Authentication)

This describes the abnormal cases of authentication, probable causes, and handling suggestions. 7.5.1 Authentication Failure Caused by RR Connection Failure (Case Study) This describes the fault, probable causes, and handling suggestions. 7.5.2 Authentication Failure Caused by Timer T3260 Expiry (Case Study) This describes the fault, probable causes, and handling suggestions. 7.5.3 Authentication Failure Caused by SIM Unregistered (Case Study) This describes the fault, probable causes, and handling suggestions.
7 Authentication
7.5.1 Authentication Failure Caused by RR Connection Failure (Case Study)

Description
The authentication procedure fails, and the network releases all the MM connections.
Analysis
Upon detecting an RR connection failure before an Authentication Response message is received, the network releases all the MM connections (if any) and terminates any ongoing MMspecific procedure.
Check that the quality of radio signals on the Um interface is proper.
7.5.2 Authentication Failure Caused by Timer T3260 Expiry (Case Study)

Description
The authentication procedure fails.
Analysis
If timer T3260 expires before an Authentication Response message is received, the network releases the RR connection and all the MM connections, terminates the authentication procedure and all the ongoing MM connections (if any), and starts the RR connection release procedure.
Check that the length of timer T3260 is proper.
7.5.3 Authentication Failure Caused by SIM Unregistered (Case Study)

Description
The network directly responds to the MS with an Authentication Reject message.
Analysis
If the SIM of an MS is not registered in the network, the network returns an Authentication Reject message to the MS.
7 Authentication
Register the SIM correctly.
7-6
Issue 01 (2008-06-10)
8 Ciphering
8
About This Chapter
8.1 Ciphering Procedure This describes the ciphering procedure. 8.2 Ciphering Mode Change This describe the ciphering mode change procedure. 8.3 Internal BSC Signaling Procedure (Ciphering) This describes the internal BSC signaling procedure of ciphering.
Ciphering
Ciphering is used to secure the information exchange between an MS and a BTS. The information consists of the signaling information and the subscriber information. The subscriber information consists of the subscriber data and the subscriber voice.
8.4 Abnormal Cases and Handling Suggestions (Ciphering) This describes the abnormal cases of ciphering, probable causes, and handling suggestions.
Issue 01 (2008-06-10)
8-1
8 Ciphering
8.1 Ciphering Procedure

This describes the ciphering procedure. Whether ciphering is used is determined by the radio resource management entity. The ciphering procedure is initiated by the network and is performed in the BTS. To cipher the user data, you must enter the corresponding parameters in the ciphering program. The ciphering key Kc is generated by the AUC, is stored in the MSC/VLR, and is sent to the BTS before ciphering. Figure 8-1 shows the ciphering procedure. Figure 8-1 Ciphering procedure
MS BTS Encryption Mode Command(2) BSC Ciphering Mode Command(1) MSC
Ciphering Mode Command(3) SDCCH Ciphering Mode Complete(4) SDCCH
Ciphering Mode Complete(5)
The previous procedure is described as follows: 1. The MSC sends the BSC a Ciphering Mode Command message. The Ciphering Mode Command message carries the required ciphering algorithms including A5/0, the ciphering key Kc, and whether the Ciphering Mode Complete message sent by the MS must carry the IMEI. According to the ciphering algorithm in the Ciphering Mode Command message, the ciphering algorithm allowed by the BSC, and the ciphering algorithm supported by the MS, the BSC determines the algorithm to be used and notifies the BTS. The BTS sends the Ciphering Mode Command message to notify the MS of the ciphering algorithm. Upon receiving the Ciphering Mode Command message, the MS starts sending the ciphering mode and then responds the BSC with a Cipher Mode Complete message. Upon receiving the Ciphering Mode Complete message from the MS, the BSC notifies the MSC of the ciphering completion.
2.
3. 4. 5.
The description of ciphering is as follows:

l
A5 ciphering algorithm As specified in the GSM protocol, there are eight ciphering algorithms, A5/0A5/7, in which A5/0 indicates Not Ciphered. The ciphering mode setting procedure is initiated by the network. The required ciphering algorithm is specified in the Ciphering Information element of the Ciphering Mode Command message.
8-2
Issue 01 (2008-06-10)

l
8 Ciphering
Ciphering algorithm selection When an MS initiates a call, it sends a CM Service Request message that carries classmark 2 and classmark 3, which contains the ciphering algorithm supported by the MS. The MSC sends a Ciphering Mode Command message based on the ciphering data configurations. According to the ciphering algorithm in the Ciphering Mode Command message, the ciphering algorithm allowed by the BSC, and the ciphering algorithm in the CM Service Request message, the BSC determines the algorithm to be used. In a reverse order, the BSC selects an applicable algorithm from the intersection of the early-mentioned three algorithms. The priority of the algorithms is A5/7 > A5/6 > A5/5 > A5/4 > A5/4 > A5/3 > A5/2 > A5/1 > A5/0.
NOTE
When the ECSC is set to 1, classmark 3 is carried in the CM Service Request message. When the ECSC is set to 0, classmark 3 can only be carried in the CM Service Request message through classmark change or update. Therefore, set the ECSC to 1 when ciphering is used.
l
Ciphering during handover The Handover Request message carries an Ciphering Information element. The Ciphering Information element specifies the required ciphering algorithm and the ciphering key. If one of the two A interfaces of the two BSSs is in PHASE I, because of the defects in the ETSI GSM PHASE I protocol (no ciphering mode setting information unit is included in the Handover Command message), the two BSSs interoperate only when they use the same ciphering algorithm such as A5/0 or A5/2. Otherwise, special processing (modifying the inter-BSC handover command) is required in the target MSC or the target BSC (or the serving MSC or the serving BSC). During the interconnection on the A interface in ciphering mode, to avoid unsuccessful handovers, you must know whether additional data configuration is required on the BSCs and MSCs from different manufacturers.
8.2 Ciphering Mode Change

This describe the ciphering mode change procedure. The BTS performs and manages ciphering. The BSC does no processing. When the ciphering mode changes, the MSC sends a Ciphering Mode Change command and the BTS changes the ciphering mode. The ciphering mode change procedure is as follows: 1. 2. 3. The BTS performs the sending configuration in old mode and the receiving configuration in new mode. The MS is configured in a completely new mode, including transmission and reception. The BTS is configured in a completely new mode.
8.3 Internal BSC Signaling Procedure (Ciphering)

This describes the internal BSC signaling procedure of ciphering. The internal BSC signaling procedure of ciphering is as follows: 1. Upon receiving the Ciphering Mode Command message from the MSC, the BSC checks the classmarks of the MS and the settings of the Ciphering Algorithm in the Set Cell Attributes dialog box.
Issue 01 (2008-06-10)
8 Ciphering
2.
According to the ciphering algorithm in the Ciphering Mode Command message, the ciphering algorithm allowed by the BSC, and the ciphering algorithm in the CM Service Request message, the BSC determines the algorithm to be used. In a reverse order, the BSC selects an applicable algorithm from the intersection of the early-mentioned three algorithms. The priority of the algorithms is A5/7 > A5/6 > A5/5 > A5/4 > A5/4 > A5/3 > A5/2 > A5/1 > A5/0. The determined ciphering mode is carried in the Cipher Mode Command message that is sent to the BTS.
3.
8.4 Abnormal Cases and Handling Suggestions (Ciphering)

This describes the abnormal cases of ciphering, probable causes, and handling suggestions. 8.4.1 Ciphering Failure Caused by BSS Sending a Cipher Mode Reject Message (Case Study) This describes the fault, probable causes, and handling suggestions. 8.4.2 Ciphering Failure Caused by MS Doing No Processing (Case Study) This describes the fault, probable causes, and handling suggestions.
8.4.1 Ciphering Failure Caused by BSS Sending a Cipher Mode Reject Message (Case Study)
Description
The BSS sends the MSC a Cipher Mode Reject message.
Analysis
The probable causes are as follows: 1. The BSS does not support the ciphering algorithm specified in the Ciphering Mode Command message. It sends the MSC a Cipher Mode Reject message with the cause value Ciphering Algorithm Not Supported. If the BSS has initiated ciphering before the MSC requires changing the ciphering algorithm, the BSS sends the MSC a Cipher Mode Reject message.
2.
l
For reason 1, check that the BSS supports the ciphering algorithm specified in the Ciphering Mode Command message. For reason 2, check that the BSS has initiated ciphering.
8.4.2 Ciphering Failure Caused by MS Doing No Processing (Case Study)

Description
Upon receiving the Ciphering Mode Command message, the MS does no processing.
8 Ciphering
Analysis
The Ciphering Mode Command message is considered as valid when:
l l l
It carries an Algorithm Identifier and is received by the MS in No Ciphering mode. It carries No Algorithm Identifier and is received by the MS in No Ciphering mode. It carries No Algorithm Identifier and is received by the MS in Ciphering mode.
The Ciphering Mode Command message received in other cases is considered as invalid. For example, if the MS in Ciphering mode receives the Ciphering Mode Command message, the MS sends an RR Status message with the cause value Protocol Error and does not take any other actions.
Confirm the mode which the MS is in and check that the contents in the Ciphering Mode Command message are correct.
Issue 01 (2008-06-10)
8-5
9 TMSI Reallocation
9
About This Chapter
9.1 TMSI Reallocation Procedure This describes the TMSI reallocation procedure.
TMSI Reallocation
The TMSI reallocation takes place in ciphering mode. It is generally related to another procedure, such as location update or call establishment.
9.2 Internal BSC Signaling Procedure (TMSI Reallocation) This describes the internal BSC signaling procedure of TMSI reallocation. 9.3 Abnormal Cases and Handling Suggestions (TMSI Reallocation) This describes the abnormal cases of TMSI reallocation, probable causes, and handling suggestions.
Issue 01 (2008-06-10)
9-1
9 TMSI Reallocation
9.1 TMSI Reallocation Procedure

This describes the TMSI reallocation procedure. The purpose of the TMSI reallocation procedure is to provide identity confidentiality, that is, to protect a user from being identified and located by an intruder. Generally, the TMSI reallocation is performed at each change of a location area. It can be initiated at any time by the network if an RR connection exists between the network and an MS. Figure 9-1 shows the TMSI reallocation procedure. Figure 9-1 TMSI reallocation procedure
MS BTS BSC MSC
TMSI Reallocation Command(1) SDCCH Start T3250
TMSI Reallocation Complete(2) SDCCH
StopT3250
The previous procedure is described as follows: 1. The network initiates the TMSI reallocation procedure by sending a TMSI Reallocation Command message to the MS and starts timer T3250. The TMSI Reallocation Command message carries a TMSI and LAI newly allocated by the network or an LAI and the IMSI if the used TMSI is deleted. Usually, the TMSI Reallocation Command message is sent to the MS using an RR connection in ciphering mode. Upon receiving the TMSI Reallocation Command message, the MS stores the LAI in the SIM. If the received identity is the IMSI of the relevant MS, the MS deletes any TMSI. If the received identity is a TMSI, the MS stores the TMSI in the SIM. In both cases, the MS sends a TMSI Reallocation Complete message to the network. Upon receiving the TMSI Reallocation Complete message, the network stops timer T3250. If a TMSI is sent to the MS, the network considers the new TMSI as valid. If an IMSI is sent to the MS, the network considers the old TMSI as deleted.
2.
3.
9.2 Internal BSC Signaling Procedure (TMSI Reallocation)

This describes the internal BSC signaling procedure of TMSI reallocation. The network initiates and controls the TMSI reallocation procedure and the BSC does no special processing.
9 TMSI Reallocation
9.3 Abnormal Cases and Handling Suggestions (TMSI Reallocation)

This describes the abnormal cases of TMSI reallocation, probable causes, and handling suggestions. 9.3.1 TMSI Reallocation Caused by RR Connection Failure on the Network Side (Case Study) This describes the fault, probable causes, and handling suggestions. 9.3.2 TMSI Reallocation Caused by T3250 Expiry (Case Study) This describes the fault, probable causes, and handling suggestions.
9.3.1 TMSI Reallocation Caused by RR Connection Failure on the Network Side (Case Study)
Description
The TMSI is reallocated due to RR connection failure on the network side.
Analysis
If the RR connection fails before the network receives the TMSI Reallocation Complete message, all MM connections are released and both the old and the new TMSIs are considered as occupied for a certain recovery time. During this period the network may:
l
Use the IMSI for paging if the MS is the called party. Upon response from the MS, the TMSI reallocation is restarted. Consider the new TMSI as valid if the MS is the calling party.
Initiate an identification procedure followed by a new TMSI reallocation if the MS uses the old TMSI.
No handling is required.
9.3.2 TMSI Reallocation Caused by T3250 Expiry (Case Study)

Description
The network releases the RR connection.
Analysis
The TMSI reallocation is supervised by the timer T3250 in the network. At the first expiry of timer T3250, the network releases the RR connection. In this case, the network suspends the
9 TMSI Reallocation
reallocation procedure, releases all MM connections, and follows the rules for RR connection failure.
No handling is required on the BSC side.
9-4
Issue 01 (2008-06-10)
10 Speech Channel Assignment
10
About This Chapter
Speech Channel Assignment
The speech channel assignment is the procedure for assigning TCHs to the MS according to the service requests. 10.1 Speech Channel Assignment Procedure This describes the speech channel assignment procedure. 10.2 Channel Mode Modification Procedure This describes the channel mode modification procedure. 10.3 Internal BSC Signaling Procedure (Speech Channel Assignment) This describes the internal BSC signaling procedure of speech channel assignment. 10.4 Abnormal Cases and Handling Suggestions (Speech Channel Assignment) This describes the abnormal cases of speech channel assignment, probable causes, and handling suggestions.
Issue 01 (2008-06-10)
10-1
10.1 Speech Channel Assignment Procedure

This describes the speech channel assignment procedure. Figure 10-1 shows the speech channel assignment procedure. Figure 10-1 Speech channel assignment procedure
MS BTS BSC Assignment Request(1) Channel Activation(2) Channel Activation Acknowledge(3) Assignment Command(4) main DCCH Start T3107 SABM(5) FACCH UA(6) FACCH Assignment Complete(8) FACCH Stop T3107 Assignment Complete(9) Establishment Indication(7) Start T10 MSC
Stop T10
The previous procedure is described as follows: 1. Based on the service request, the MSC requests radio resources from the BSS through SCCP connection, sends an Assignment Request message to the BSS, and starts timer T10. The Assignment Request message carries the Channel Type, Priority, Circuit Identity Code, and Downlink DTX Flag parameters.
l
The Channel Type parameter has five to ten bytes. The third byte "speech / data indicator" indicates speech, data, or signaling. The fourth byte "channel rate and type" indicates the number of half-rate channels or full-rate channels and the number of related physical channels. The remaining bytes indicate speech versions 15. The Priority parameter indicates different priority levels and whether queuing and preemption are performed.
10-2

l
The Circuit Identity Code parameter is used for the physical connection between the BSC and the MSC. The Downlink DTX Flag parameter indicates whether discontinuous transmission is allowed.
2. 3. 4.
For details about the Channel Activation message, refer to 4 Immediate Assignment. For details about the Channel Activation Acknowledge message, refer to 4 Immediate Assignment. Upon receiving the Channel Activation Acknowledge message, the BSC sends the MS an Assignment Command message on the SDCCH and starts timer T3107. The Assignment Command message carries the Channel Description, Power Command, and Channel Mode. For details about these parameters, refer to the Immediate Assignment Procedure. Upon receiving the Assignment Command message from the BTS, the MS adjusts the signaling to the TCH and sends the SABM frame on the FACCH. The SABM frame is the first frame during the setup of multi-frame verification mode and does not carry layer 3 messages. Upon receiving the SABM frame, the BTS responds to the MS with a UA frame on the FACCH. The UA frame does not carry layer 3 messages. Then the BTS sends the BSC an Establishment Indication message. The Establishment Indication message does not carry layer 3 messages. The system responds with a UA Acknowledgement frame. Upon receiving the UA frame, the MS sends an Assignment Complete message on the FACCH to notify the BSC of the channel assignment completion. Upon receiving the message, the BSC stops timer T3107. The BSC sends an Assignment Complete message to the MSC. Upon receiving the message, the MSC stops timer T10. The Assignment Complete message carries the Chosen Channel, Circuit Pool, and Speech version parameters. The meanings of the parameters are as follows:
l
5.
6. 7.
8.
9.
Chosen Channel Inidicates the type of the assigned channel Circuit Pool Indicates the circuit pool information Speech Version Indicates the speech coding algorithm
10.2 Channel Mode Modification Procedure

This describes the channel mode modification procedure. Figure 10-2 shows the channel mode modification procedure.
Issue 01 (2008-06-10)
10-3
Figure 10-2 Channel mode modification procedure

MS BTS BSC Assignment Request(1) Start T10 Mode Modify(2) Mode Modify Acknowledge(3) Channel Mode Modify(4) main DCCH Channel Mode Modify Acknowledge(5) main DCCH Assignment Commplete(6) StopT10 MSC
The previous procedure is described as follows: 1. 2. 3. For details about the Assignment Request message, refer to 10.1 Speech Channel Assignment Procedure. Upon receiving the Assignment Request message, the BSC sends the BTS a Mode Modify message. The Mode Modify message carries the Channel Mode parameter. If the channel mode is changed, the BTS sends the BSC a Mode Modify Acknowledge message to the BSC. If the channel mode cannot be changed, the BTS sends the BSC a Mode Modify Negative Acknowledge message. Upon receiving the Mode Modify Acknowlege message, the BSC sends the MS a Channel Mode Modify message. The Channel Mode Modify message carries the information on the channel to be changed and the mode of channel after change. If the channel mode is changed, the MS sends the BSC a Channel Mode Modify Acknowledge message. If the MS does not support the specified mode, it stays in the original mode. The Channel Mode Modify Acknowledge message carries the mode information. For details about the Assignment Complete message, refer to 10.1 Speech Channel Assignment Procedure.
4.
5.
6.
10.3 Internal BSC Signaling Procedure (Speech Channel Assignment)

This describes the internal BSC signaling procedure of speech channel assignment. The internal BSC signaling procedure of speech channel assignment is as follows: 1. On receiving the Assignment Request message from the MSC, the BSC checks the channel type. In the Set Cell Attributes dialog box, choose Other Attributes > Advanced >
10-4
Other Parameters. Check whether the Data Service Allowed is enabled. If not, the BSC responds with an Assignment Failure message. 2. When different transmission types are used on the A interface, the contents of the Assignment Request message sent by the MSC are different and the BSC handles in different ways.
l
When TDM transmission is used on the A interface, based on the CIC in the Assignment Request message, the BSC checks the E1 timeslots on the A interface and confirms the existence of CIC. It also checks whether the circuit pool of the configured CIC, the channel type in the Assignment Request message, and the support capability of the board collide. If they collide, the BSC responds with an Assignment Failure message. When IP transmission is used on the A interface, the Assignment Request message sent by the MSC contains the following information elements: Transport Layer Address and Speech SDP Information list. Based on the Assignment Request message, the BSC checks whether the IP address of the A interface, the port number, and the support capability of the board meet the requirements. If not, the BSC responds with an Assignment Failure message.
NOTE
Transport Layer Address carries the IP address and port number of the A interface. Speech SDP Information list carries the related information about the IP user plane, for example, PT, ClockRate, and PTime.
3.
On receiving the Assignment Complete message from the MS, the BSC fills the message with the A Interface Tag and sends the message to the MSC. You can choose BSC Property > Basic Data to display the A Interface Tag.
10.4 Abnormal Cases and Handling Suggestions (Speech Channel Assignment)

This describes the abnormal cases of speech channel assignment, probable causes, and handling suggestions. 10.4.1 BSC Sending an Assignment Failure Message (Case Study) This describes the fault, probable causes, and handling suggestions. 10.4.2 BSC Receiving a Connection Failure Indication Message (Case Study) This describes the fault, probable causes, and handling suggestions. 10.4.3 BSC Receiving an Error Indication Message (Case Study) This describes the fault, probable causes, and handling suggestions.
10.4.1 BSC Sending an Assignment Failure Message (Case Study)

Description
Upon receiving the Assignment Request message, the BSC responds with an Assignment Failure message.
Analysis
1.
Radio Interface Message Failure The MS fails to access the speech channel. It sends an Assignment Failure message on the signaling channel. Due to the particularity of the transmission on the Um interface, this case happens the most frequently and cannot be solved.
2. 3.
Equipment Failure The BSC hardware is faulty. No Radio Resource Available The BSC has no appropriate speech channels for assignment. The possible reason is that all the speech channels are busy or that the speech channels are blocked.
4. 5. 6. 7. 8. 9.
Requested Terrestrial Resource Unavailable Requested Transcoding/Rate Adaption Unavailable Terrestrial Resource Already Allocated Invalid Message Contents Radio Interface Failure Reversion To Old Channel Requested Speech Version Unavailable
10. Timer T3107 expiry
The respective handling suggestions are as follows:
l
For reason 1, check the access-related parameters of the antenna system, BTS boards, and BSC data configuration. For reason 2, check the following:

Communication between modules and subracks in the BSC Communication on the A interface, for example, the cable connections between GEIUAs and subracks
For reason 3, add TRXs to the BTS, modify the access threshold, and enable the directed retry. For reason 4, check that the A interface data configurations on the MSC and BSC sides are correct and consistent. For reason 5, check the transmission on the A interface. For reason 6, check whether the configurations of A interface terrestrial circuits on the BSC and MSC sides are consistent. If not, reset the terrestrial circuits through the BSC6000 Local Maintenance Terminal. For reason 7, check that the message complies with the protocols. For reason 8, check the signal quality on the Um interface, for example, the receive signal level on the Um interface. For reason 9, check that the BSC supports the requested speech version. For reason 10, check that the length of timer T3107 is proper.
l l
l l
l l
10.4.2 BSC Receiving a Connection Failure Indication Message (Case Study)

Description
During the assignment procedure, the BSC receives a Connection Failure Indication message.
Analysis
l l
Radio link failure Hardware failure
The handling suggestions are as follows:
l l
Check the resources on the Um interface. Check the following items:

Communication between subracks Communication on the A interface, for example, the cable connections between GEIUBs and subracks
10.4.3 BSC Receiving an Error Indication Message (Case Study)

Description
During the assignment procedure, the BSC receives an Error Indication message.
Analysis
l l l l
Inconformity with protocols Link layer failure Timer T200 expiry MS failure in receiving a UA frame
l l l l
Check that the contents of the frames at the data link layer are correct. Check the status of the data link layer. Check that the settings of timer T200 are correct. Check that the contents of the SABM frame are correct.
Issue 01 (2008-06-10)
10-7
11 Mobile Originated Call
11
About This Chapter
Mobile Originated Call
Mobile originated call refers to a call procedure in which an MS calls another MS or a fixed phone. 11.1 Mobile Originated Call Establishment Procedure In terms of the assignment type, the mobile originated call establishment procedure is categorized into the early assignment procedure, late assignment procedure, and very early assignment procedure. The MSC determines the early assignment procedure and the late assignment procedure. The BSS determines the very early assignment procedure based on the radio resources. 11.2 Internal BSC Signaling Procedure (Mobile Originated Call) This describes the internal BSC signaling procedure of mobile originated call establishment. 11.3 Abnormal Cases and Handling Suggestions (Mobile Originated Call) This describes the abnormal cases of mobile originated call establishment, probable causes, and handling suggestions.
Issue 01 (2008-06-10)
11-1
11.1 Mobile Originated Call Establishment Procedure

In terms of the assignment type, the mobile originated call establishment procedure is categorized into the early assignment procedure, late assignment procedure, and very early assignment procedure. The MSC determines the early assignment procedure and the late assignment procedure. The BSS determines the very early assignment procedure based on the radio resources. 11.1.1 Early Assignment Procedure This describes the early assignment procedure, namely the mobile originated call establishment without OACSU procedure. 11.1.2 Late Assignment Procedure This describes the late assignment procedure, namely the mobile originated call establishment with OACSU procedure. 11.1.3 Very Early Assignment Procedure This describes the very early assignment procedure, namely the Mobile Originated Call Establishment with OACSU procedure.
11.1.1 Early Assignment Procedure

This describes the early assignment procedure, namely the mobile originated call establishment without OACSU procedure. Figure 11-1 shows the early assignment procedure.
11-2
Issue 01 (2008-06-10)
Figure 11-1 Early assignment procedure

MS BTS BSC MSC
Immediate Assignment Procedure Establish Indication (CM Service Request)(1)
CR(L3:CM Service Request)(2) CC(3)
CM Service Accepted(4) FACCH Setup(5) SDCCH Call Proceeding(6) SDCCH TCH Assignment Procedure Alerting(7) FACCH Connect(8) FACCH Connect Acknowledge(9) SDCCH Talking(10) Release Procedure
The previous procedure is described as follows: 1. The BTS sends the BSC an Establishment Indication message. The Establishment Indication message accurately indicates the reason for the access of an MS, for example, the cause values for mobile originated call establishment and for IMSI detach are different. The message also carries the content of the CM Service Request message. The BSC establishes an SCCP link connection on the A interface and sends the MSC a CM Service Request message. The MSC sends the BSC a Connect Confirm message. The MSC sends the MS a CM Service Accepted message on the SDCCH on the Um interface.
2. 3. 4.
Issue 01 (2008-06-10)
11-3
5.
The calling MS sends a Setup message on the SDCCH. The Setup message carries all the information required on the network side for processing the call, including the number of the called MS. The MSC sends the calling MS a Call Proceeding message on the SDCCH on the Um interface. The Call Proceeding message indicates that a call is being processed and the mobile originated call processing procedure is initiated. The MSC sends the MS an Alerting message on the FACCH on the Um interface. Then the calling MS hears a ringing tone. The MSC sends the calling MS a Connect message on the FACCH on the Um interface. The Connect message is used to notify the MS that the connection is established. The calling MS responds to the MSC with a Connect Acknowledge message on the FACCH.
6.
7. 8. 9.
10. The calling and the called MSs enter the session state.
11.1.2 Late Assignment Procedure

This describes the late assignment procedure, namely the mobile originated call establishment with OACSU procedure. Figure 11-2 shows the late assignment procedure.
11-4
Issue 01 (2008-06-10)
Figure 11-2 Late assignment procedure

MS BTS BSC MSC
Immediate Assignment Procedure Establish Indication (CM Service Request)(1)
CM Service Accepted(4) SDCCH Setup(5) SDCCH Call Proceeding(6) SDCCH Alerting(7) SDCCH TCH Assignment Procedure Connect(8) FACCH Connect Acknowledge(9) SDCCH Talking(10) Release Procedure
For details of each message shown in Figure 11-2, refer to 11.1.1 Early Assignment Procedure. 1. The difference between Figure 11-2 and the flowchart in 11.1.1 Early Assignment Procedure is that the assignment procedure of the former takes place after the Alerting message is sent. The late assignment saves the seizure time of speech channels. The disadvantage of the procedure shown in Figure 11-2 is that if the subsequent assignment is unsuccessful, the called MS can only hear the ring tone but cannot make calls. In actual application, the early assignment procedure is used instead of the late assignment procedure.
2. 3.
Issue 01 (2008-06-10)
11-5
11.1.3 Very Early Assignment Procedure

This describes the very early assignment procedure, namely the Mobile Originated Call Establishment with OACSU procedure. Figure 11-3 shows the very early assignment procedure. Figure 11-3 Very early assignment procedure
MS BTS BSC MSC
Immediate Assignment TCH Procedure Establish Indication (CM Service Request)(1)
CM Service Accepted(4) FACCH Setup(5) FACCH Call Proceeding(6) FACCH TCH Mode Modify Alerting(7) FACCH Connect(8) FACCH Connect Acknowledge(9) FACCH Talking(10) Release Procedure
For details of each message shown in Figure 11-3, refer to 11.1.1 Early Assignment Procedure. 1. The difference between the very early assignment procedure and the 11.1.1 Early Assignment Procedure is that in the former, the TCH is assigned as a signaling channel during the immediate assignment procedure. Therefore, no TCH needs to be assigned during the assignment procedure, and the assigned TCH is adjusted to a speech channel through the Mode Modify message.
11-6
2.
During the immediate assignment procedure, if no idle SDCCHs but TCHs are available and TCH immediate assignment is allowed in the BSC data configuration, the very early assignment procedure will take place.
11.2 Internal BSC Signaling Procedure (Mobile Originated Call)

This describes the internal BSC signaling procedure of mobile originated call establishment. The internal BSC signaling procedure of mobile originated call establishment is as follows: 1. On receiving the Channel Required message from the BTS, the BSC assigns a signaling channel according to the channel type and channel assignment algorithm in the Channel Required message. The TCH Immediate Assignment Allowed in the Set Cell Attributes dialog box may be involved in the channel assignment. During random access, on receiving the Establish Indication message from the BTS, the BSC sends the MSC a CM Service Request message that carries the target CGI based on the MCC, MNC, LAC, and CI parameters in the Set Cell Attributes dialog box. On receiving the Assignment Request message from the MSC, the BSC checks the channel type. In the Set Cell Attributes dialog box, choose Other Attributes > Advanced > Other Parameters. Check whether Data Service Allowed is supported. If the data service is not supported, an Assignment Failure message is returned. Based on the CIC in the Assignment Request message, the BSC checks the E1 timeslots on the A interface and confirms the existence of CIC. It also checks whether the circuit pool of the configured CIC, the channel type in the Assignment Request message, and the capacity of the GDPUC collide. If they collide, the BSC responds to the MSC with an Assignment Failure message. On receiving the Assignment Complete message from the MS, the BSC fills the message with the A Interface Tag and sends the message to the MSC. You can choose BSC Property > Basic Data to display the A Interface Tag.
2.
3.
4.
5.
11.3 Abnormal Cases and Handling Suggestions (Mobile Originated Call)

This describes the abnormal cases of mobile originated call establishment, probable causes, and handling suggestions. 11.3.1 Calling MS Cannot Be Heard (Case Study) This describes the fault, probable causes, and handling suggestions. 11.3.2 MSC Releasing the Call After Sending a CM Service Reject Message (Case Study) This describes the fault, probable causes, and handling suggestions. 11.3.3 Abnormal Case Caused by MS in Busy State (Case Study) This describes the abnormal case, probable causes, and handling suggestions. 11.3.4 MSC Sending a Disconnect Message Instead of an Assignment Request Message (Case Study) This describes the fault, probable causes, and handling suggestions. 11.3.5 Abnormal Cases Caused by MS Hangup (Case Study)
This describes the fault, probable causes, and handling suggestions. 11.3.6 Abnormal Cases Caused by MSC Sending a Clear Command Message or a Disconnect Message (Case Study) This describes the fault, probable causes, and handling suggestions. 11.3.7 LAPD Reporting an Error Indication Message During Call Establishment (Case Study) This describes the fault, probable causes, and handling suggestions.
11.3.1 Calling MS Cannot Be Heard (Case Study)

Description
When late assignment is enabled, the called MS cannot hear the calling MS.
Analysis
TCH assignment fails.
Disable the late assignment.
11.3.2 MSC Releasing the Call After Sending a CM Service Reject Message (Case Study)
Description
After sending a CM Service Reject message, the MSC sends a Clear Command message to release the call.
Analysis
l l l l
The MSC cannot find the subscriber information and considers that the subscriber is illegal. Authentication or encryption fails. The MSC does not support the applied service in the CM Service Request message. The MSC does not have sufficient resources to perform access.
l l l
The MS makes a subscription under the MSC. Check the subscriber information. Hand over the MS to a cell under another MSC.
11-8

l
Wait for the MSC to release the resources, or expand the MSC transmission capability on the A interface.
11.3.3 Abnormal Case Caused by MS in Busy State (Case Study)

This describes the abnormal case, probable causes, and handling suggestions.
Description
After the assignment success of the calling MS, the network sends a Disconnect message with the cause value User Busy. The onhook by the calling MS or a Clear Command message sent by the MSC triggers the release of the BSC resources.
Analysis
The MS is busy.
Wait for the onhook of the called MS and make a second call.
11.3.4 MSC Sending a Disconnect Message Instead of an Assignment Request Message (Case Study)
Description
The MSC does not send an Assignment Request message. It sends a Disconnect message to clear the call.
Analysis
The A interface may be faulty.
Check the following:
l l
The state of the A interface circuit on the MSC side The consistency of the A interface data on the MSC and the BSC, especially the circuit pool data
11.3.5 Abnormal Cases Caused by MS Hangup (Case Study)

Description
The call establishment procedure is terminated.
Analysis
l l
The MS hangs up. The calling or the called MS hangs up during a procedure, which causes abnormality in the subsequent procedures. For example, after the BSC receives an Assignment Request message from the MSC, the MS suddenly hangs up. In that case, the call establishment procedure may be terminated before the BSC responds to the MSC with an Assignment Complete message or an Assignment Failure message. As a result, the procedure is neither a successful assignment procedure (The BSC sends an Assignment Complete message.) nor an unsuccessful assignment procedure (The BSC sends an Assignment Failure message.).
No handling is required.
11.3.6 Abnormal Cases Caused by MSC Sending a Clear Command Message or a Disconnect Message (Case Study)
Description
The MSC sends a Clear Command message or a Disconnect message.
Analysis
Check the following:
l
The cause value in the Clear Command message If a call terminates normally, the cause value in the Clear Command message is Call Control. Otherwise, the cause value may be Protocol Error or Equipment Failure.
The time difference between the previous message and the Clear Command message or the Disconnect message Check whether the abnormal procedure is triggered by timeout.
l
If the cause value in the Clear Command message is Call Control, no abnormality exists. If the cause value in the Clear Command message is Protocol Error, refer to the related protocols. If the cause value in the Clear Command message is Equipment Failure, check the related BSC hardware:
Inter-subrack communication (connection on the Ater interface, if the Ater interface exists) A interface board on the BSC side
Based on different messages and different time differences, check that the settings of the related timers are correct.
11-10
11.3.7 LAPD Reporting an Error Indication Message During Call Establishment (Case Study)
Description
The LAPD reports an Error Indication message during call establishment.
Analysis
l l l l
Inconformity with protocols LAPD link failure Timer T200 expiry MS failure in receiving a UA frame
l l l l
Check that the contents of the frames at the data link layer are correct. Check the status of the data link layer. Check that the settings of timer T200 are correct. Check that the contents of the SABM frame are correct.
Issue 01 (2008-06-10)
11-11
12 Mobile Terminated Call
12
About This Chapter
Mobile Terminated Call
Mobile terminated call refers to a call procedure in which an MS is called by another MS or a fixed phone. 12.1 Mobile Terminated Call Establishment Procedure This describes the mobile terminated call establishment procedure. For details, refer to GSM Rec. 24008, 24080, 48008, 48018, and 48058. 12.2 Internal BSC Signaling Procedure (Mobile Terminated Call) This describes the internal BSC signaling procedure of mobile terminated call establishment. 12.3 Abnormal Cases and Handling Suggestions (Mobile Terminated Call) This describes the abnormal cases of mobile terminated call establishment, probable causes, and handling suggestions.
Issue 01 (2008-06-10)
12-1
12.1 Mobile Terminated Call Establishment Procedure

This describes the mobile terminated call establishment procedure. For details, refer to GSM Rec. 24008, 24080, 48008, 48018, and 48058. Figure 12-1 shows the mobile terminated call establishment procedure. Figure 12-1 Mobile terminated call establishment procedure
MS BTS BSC Paging(1) Paging Command(2) Paging Request(3) PCH Channel Request(4) RACH Immediate Assignment Procedure Establish Indication (Paging Response)(5) MSC
CR(CL31)(6) CC(7)
CM Service Accepted(8) SDCCH SDCCH SDCCH TCH Assignment Procedure Alerting(11) FACCH FACCH FACCH Connect(12) Connect Acknowledge(13) Talking(14) Release Procedure Setup(9) Call Confirmmed(10)
The previous procedure is described as follows: 1. When the paged MS is in the service area of the MSC, the MSC sends the BSC a Paging message, which carries a list of paging cells (optional), TMSI, and IMSI.
12-2
Issue 01 (2008-06-10)

NOTE
The Paging message can be sent to the BSC from the MSC directly. Alternatively, it can be sent to the SGSN first, and then to the PCU over the Gb interface, and finally to the BSC over the Pb interface.
2. 3.
The BSC sends the BTS a Paging Command message that carries the number of the occupied timeslot and the number of the paging sub-channel. Upon receiving the Paging Command message from the BSC, the BTS sends the paged MS a Paging Request message on the paging sub-channel. The Paging Request message carries the IMSI or TMSI of the paged MS. After decoding the Paging message, if the MS finds itself the paged MS, it sends the BTS a Channel Request message to trigger an Initial Channel Assignment procedure. For details about other messages, refer to 11.1 Mobile Originated Call Establishment Procedure.
4. 5.
12.2 Internal BSC Signaling Procedure (Mobile Terminated Call)

This describes the internal BSC signaling procedure of mobile terminated call establishment. The internal BSC signaling procedure of mobile terminated call establishment is as follows: 1. On receiving the Paging message, the BSC forwards the message to the service module in the BM subrack that is configured with SS7. Based on the CGI in the Paging message, the service module checks the information on the paged cell. If the paged cell is in the BM subrack where the service module is located, the service module directly sends the Paging message to the cell. If the paged cell is in another BM subrack, the service module forwards the Paging message to the service module in that BM subrack. The service module in the BM subrack first checks whether the Allow eMLPP is set to Yes in Call Control of > Set Cell Attributes. Then the service module determines the paging packet based on the BS_AG_BLKS_RES, CCCH_CONF, and BS_PA_MFRAMES in Idle Mode of > Set Cell Attributes. After that, it sends the Paging message to the BTS.
2.
12.3 Abnormal Cases and Handling Suggestions (Mobile Terminated Call)

This describes the abnormal cases of mobile terminated call establishment, probable causes, and handling suggestions. 12.3.1 No Paging Command on the A Interface (Case Study) This describes the fault, probable causes, and handling suggestions. 12.3.2 No Paging Command on the Abis Interface (Case Study) This describes the fault, probable causes, and handling suggestions. 12.3.3 No Paging Response on the Abis Interface (Case Study) This describes the fault, probable causes, and handling suggestions. 12.3.4 No Paging Response on the A Interface (Case Study) This describes the fault, probable causes, and handling suggestions.
12.3.1 No Paging Command on the A Interface (Case Study)

Description
The MSC does not send a Paging message to the BSC, as indicated in the signaling tracing on the A interface.
Analysis
The probable cause lies on the NSS side.
Check the data configuration and subscriber information in the MSC/VLR and the HLR. Power off the called MS and then power it on to make test calls.
l
Check that the subscriber data in the VLR is correct. When an MS is called, the MSC determines the current state of the MS based on the subscriber data in the VLR. The subscriber data includes the the active state, registered location area, and registered cells. Then, the MSC determines whether to and how to send a Paging message. If the state of the MS changes, for example, the MS is switched off or moves to another location area, but it has not registered in the network and thus the subscriber data in the VLR is not updated, the paging fails. In this case, the MS needs to originate a location update procedure to ensure that the subscriber data in the VLR is correct. On the BSC side, the system information indicates the location update period of the MS. On the MSC side, there is also a location update period. The MS must originate a location update within the period specified by the MSC, so the location update period on the BSC side must be shorter than that on the MSC side.
Check that the parameters of location areas and cells on the MSC side are correct. Incorrect parameter configuration of location areas and cells on the MSC side may lead to unsuccessful transmission of the Paging message. For example, if the target BSC is incorrectly selected, the Paging message may be sent to a wrong BSC.
12.3.2 No Paging Command on the Abis Interface (Case Study)

Description
Upon receiving the Paging message from the MSC, the BSC does not send a Paging Command message to the BTS, as indicated in the message tracing on the Abis interface.
Analysis
The fault lies in the BSC side.
l
Check whether the flow control procedure is triggered.
Check whether the PCH or AGCH is overloaded due to a sharp increase in short messages or a burst of access requests. You can verify the change by comparing the values of the counters Immediate Assignment Requests and MSC Paging Requests (Circuit Service) before and after the problem occurs.
Choose BSC Property > Flow Control Data. Check that the flow control parameters are consistent with those described in the Version Matching Guide. Check that the CGI on the BSC side is consistent with that in the LAC carried in the Paging message. On the BSC6000 Local Maintenance Terminal, check that the cell configuration data is correct. Incorrect parameter configuration of location areas and cells on the MSC side may lead to unsuccessful transmission of the Paging message. For example, if the target BSC is incorrectly configured, the Paging message is sent to a wrong BSC.
Check the data correctness.
Check that the paging-related parameters on the BSC side are configured correctly. Choose Set Cell Attributes > Idle Mode. Check that the parameters BS_AG_BLKS_RES, CCCH_CONF, and BS_PA_MFRAMES are set correctly.
Check the communications between the subracks in the BSC. If the BSC has multiple subracks, on receiving the Paging message from the MSC, the BSC starts paging based on the location area and cell information in the Paging message. The Paging Command message sent from the BSC to the BTS may be forwarded between subracks. If the communication between the subracks is abnormal, the Paging Command message may not be forwarded, and no Paging Command message is sent on the Abis interface. By viewing the BSC alarms, check that the communications between the subracks are normal.
12.3.3 No Paging Response on the Abis Interface (Case Study)

Description
After sending the BTS a Paging Command message, the BSC does not receive an Establishment Indication (Paging Response) message, as indicated in the message tracing on the Abis interface.
Analysis
The fault may be caused by faulty data configuration or poor radio signal coverage.
l
Check whether the PCH or AGCH is overloaded due to a sharp increase in short messages or a burst of access requests. You can verify the change by comparing the values of the counters Immediate Assignment Requests and MSC Paging Requests (Circuit Service) before and after the problem occurs.
Issue 01 (2008-06-10)
12-5

l
Replace the MS and check that the MS or SIM is normal. Faulty MS or SIM may lead to no paging response.

Insert another SIM into the MS to check whether the problem lies in the SIM. Insert the SIM into another MS to check whether the problem lies in the MS. Other cells under the same BTS Other sites of the same site type Other sites of a different site type Sites from other manufacturers Check that the paging-related parameters on the BSC side are configured correctly.
To check whether the problem lies in the BTS, make test calls in the following locations:

Check the data configurations.
Choose Set Cell Attributes > Idle Mode. Check that the parameters BS_AG_BLKS_RES, CCCH_CONF, BS_PA_MFRAMES, and Tx-integer are set correctly. Choose Set Cell Attributes > Call Control. Check that the parameters such as the MS MAX Retrans are set correctly.
Check that the values of the Location Update Period on the BSC and the MSC are set correctly.
Choose Set Cell Attributes > Call Control. Check that the parameters such as the Period of Periodic Location Update (6 minutes) are set correctly. The location update period on the BSC side must be shorter than that on the MSC side. For details, refer to 6.1 Location Update Procedure.
Check the radio signal coverage. Poor radio signal coverage may lead to the existence of dead zones where an MS cannot receive the Paging Request message. Thus, the MS cannot be paged.
12.3.4 No Paging Response on the A Interface (Case Study)

Description
Upon receiving the Establishment Indication (Paging Response) message from the BTS, the BSC does not send any message to the MSC, as indicated in the message tracing on the Abis interface and the A interface.
Analysis
Generally, the cause is that the SS7 signaling link is faulty.
Check that the SS7 signaling link is normal. Rectify the fault in the signaling link, if any.
12-6
Issue 01 (2008-06-10)
13 BSC Release
13
About This Chapter
13.1 Normal Release Procedure This describes the normal release procedure. 13.2 Local Release Procedure This describes the local release procedure.
BSC Release
BSC release consists of the normal release procedure and the local release procedure.
Issue 01 (2008-06-10)
13-1
13 BSC Release
13.1 Normal Release Procedure

This describes the normal release procedure. The normal release procedure can be originated by the MS or the MSC. Upon onhook, the calling MS sends a Disconnect message to the MSC. Then, the corresponding MSC sends the Disconnect message to the called MS. After the access of the MS, the BSC initiates the release procedure upon service requests, for example, MS onhook. Figure 13-1 shows the BSC normal release procedure.
13-2
Issue 01 (2008-06-10)
13 BSC Release
Figure 13-1 Normal release procedure

MS BTS Disconnect(1) FACCH Start T305 Release(2) FACCH Stop T305 Release Complete(3) FACCH Stop T308 Clear Command(4) Channel Release(5) FACCH Start T3109 Deactivate SACCH(8) DISC(6) FACCH UA(7) FACCH Release Indication(9) Stop T3109 Start T3111 Stop T3111 Start T308 BSC MSC
RF Channel Release(10) RF Channel Release Acknowledge(12) Clear Complete(11)
RLSD(13) RLC(14)
The previous procedure is described as follows: 1. 2. Upon onhook, the calling MS sends a Disconnect message to the MSC and starts timer T305. The Disconnect message carries the cause for disconnection. The MSC sends the calling MS a Release message and at the same time sends the called MS a Disconnect message. The network starts timer T308.
Issue 01 (2008-06-10)
13-3
13 BSC Release
3. 4.
Upon receiving the Release message, the calling MS stops timer T305, releases the MM connection, and sends the MSC a Release Complete message. Upon receiving the Release Complete message, the MSC stops timer T308, releases the MM connection, and sends the BSC a Clear Command message. The Clear Command message notifies the BSC of releasing the resources on the A interface and the Um interface. The BSC sends a Channel Release message and starts timer T3109. The Channel Release message carries the RR cause filed and notifies the MS and the BTS of releasing the logic channels on the Um interface. Upon receiving the Channel Release message, the MS disconnects the uplink signaling link and sends the BTS a DISC frame, indicating that the logic channels are released. The BTS sends the MS a UA frame. Upon receiving the UA frame, the MS returns to the CCCH and enters the idle state. The BSC sends the BTS a Deactivate SACCH message, deactivates the associated signaling channels, and releases the downlink associated signaling links. Upon receiving the DISC frame from the MS, the BTS sends the BSC a Release Indication message, indicating that the MS has released the logic channels on the Um interface. At the same time, the BSC stops timer T3109, and starts timer T3111.
5.
6. 7. 8. 9.
10. Upon timer T3111 expiry, the BSC sends the BTS an RF Channel Release message. Timer T3111 is used to reserve a period for the acknowledgement of disrupted connection. 11. The BTS sends the BSC an RF Channel Release Acknowledge message, indicating that the RF channels on the radio interface are released and can be used for re-assignment. 12. The BSC responds to the MSC with a Clear Complete message. 13. The MSC sends the BSC an RLSD message to release the SCCP signaling link. 14. The BSC responds to the MSC with an RLC message, indicating that the SCCP signaling link is released. The previous procedure is summarized as follows:
l
Steps 1 through 3 shown in Figure 13-1 describe the call connection release.
NOTE
Figure 13-1 shows the MS originating release procedure. For the network originating release procedure, the directions of only the three transparent transmission messages are opposite.
l
Steps 4 through 14 shown in Figure 13-1 describe the radio resource release. After the connections at the CC layer and at the MM layer are released, the network sends the BSC a Clear Command message to request the release of the SCCP signaling link. The Clear Command message carries the clear causes such as the Handover Successful or Call Control. If the release is caused by radio interface message failures, radio link failures, or equipment failures, the BSC sends a Clear Request message to the system. Then, the MSC delivers the Clear Command message.
13.2 Local Release Procedure

This describes the local release procedure. The local release procedure is initiated by the BSC, as shown in Figure 13-2.
13-4
Issue 01 (2008-06-10)
13 BSC Release
Figure 13-2 Local release procedure

BTS
Deactivate SACCH (1) Release Request (2) Release Confirm (3) RF Channel Release(4) RF Channel Release Acknowledge (5)
BSC
The previous procedure is described as follows: 1. 2. 3. The BSC sends the BTS a Deactivate SACCH message to deactivate the associated signaling channels. The BSC sends the BTS a Release Request message with the cause value Local End Release. In this case, the release procedure has nothing to do with the MS. Upon receiving the Release Request message with the cause value Local End Release, the BTS responds to the BSC with a Release Confirm message. If the Release Request message carries other cause values, the BTS sends a DISC frame to the MS. Only after receiving the UA frame or DM frame from the MS, the BTS sends the Release Confirm message to the BSC. The BSC sends an RF Channel Release message to the BTS. The BTS sends an RF Channel Release Acknowledge message to the BSC.
4. 5.
Issue 01 (2008-06-10)
13-5
14 Handover
14
About This Chapter
Handover
Handover is one of the basic functions of the GSM. It enables calls to be set up in better cells and reduces call drops. Handover also lowers cross interference. The handover procedure involves handover triggering, handover preparation, handover decision, and handover execution. 14.1 Handover Procedures The handover procedures are categorized into the intra-BSC handover procedure, inter-BSC handover procedure, inter-MSC handover procedure, and inter-RAT handover procedure. 14.2 Internal BSC Signaling Procedures (Handover) The internal BSC signaling procedures of handover are categorized into the intra-BSC handover, inter-BSC handover, inter-MSC handover, and inter-RAT handover. 14.3 Abnormal Cases and Handling Suggestions (Handover) This describes the abnormal cases of handover, probable causes, and handling suggestions.
Issue 01 (2008-06-10)
14-1
14 Handover
14.1 Handover Procedures

The handover procedures are categorized into the intra-BSC handover procedure, inter-BSC handover procedure, inter-MSC handover procedure, and inter-RAT handover procedure. 14.1.1 Intra-BSC Handover Procedure This describes the intra-BSC handover procedure. 14.1.2 Inter-BSC Handover Procedure This describes the inter-BSC handover procedure. 14.1.3 Inter-MSC Handover Procedure This describes the inter-MSC handover procedure. 14.1.4 Inter-RAT Handover Procedure This describes the inter-RAT handover procedure.
14.1.1 Intra-BSC Handover Procedure

This describes the intra-BSC handover procedure. Figure 14-1 shows the intra-BSC handover procedure. Figure 14-1 Intra-BSC handover procedure
MS BTS2 BSC BTS1 Measurement Report(1) SACCH Channel Modify Prepare(5) Handover Command(6) Start T3103 FACCH MS MSC
Channel Activation(3) Channel Activation Acknowledge(4) Handover Access(7) FACCH Start T3124 Handover Access FACCH PHY INFO(9) FACCH Stop T3124 SABM(10) FACCH UA(12) FACCH FACCH Handover Complete(13) Establish Indication(11)
Measurement Result(2)
Handover Detect(8)
Stop T3103 Handover Perfomed(14)
14-2
Issue 01 (2008-06-10)
14 Handover
The previous procedure is described as follows: 1. 2. 3. 4. The MS sends BTS1 a measurement report on an SACCH on the Um interface. BTS 1 forwards the measurement report to the BSC. Based on the measurement report, the BSC determines whether to hand over the MS to another cell. If a handover is required, the BSC sends BTS 2 a Channel Activation message. Upon receiving the Channel Activation message, if the channel type is correct, BTS 2 turns on the power amplifier on the specified channel to receive information on the uplink, and sends a Channel Activation Acknowledge message to the BSC. After receiving a Channel Activation Acknowledge message from BTS 2, if the target channel uses a different payload type (PT) from the originating channel, the BSC sends the MSC a Channel Modify Prepare message, notifying the MSC that the PT of the current call is changed. The BSC sends a Handover Command message to BTS 1 and BTS 1 forwards the message to the MS on the FACCH. BTS 1 starts timer T3103. The Handover Command message has all the information to be transferred on the new channel and the data required for accessing the MS. It also indicates whether the handover is synchronous or asynchronous. Upon receiving the Handover Command message, the MS attempts the access and sends BTS 2 a Handover Access message on the FACCH. After receiving the Handover Access message from the MS, BTS 2 sends a Handover Detect message to the BSC. Whether a PHY INFO message is sent depends on the handover type.
l
5.
6.
7. 8. 9.
Asynchronous handover After the channels of BTS 2 are activated, BTS 2 waits for the access of the MS on a dedicated channel until timer T3103 expires. Upon detecting the Handover Access message from the MS, BTS 2 sends the BSC a Handover Detect message and at the same time to the MS a PHY INFO message on an FACCH. The PHY INFO message carries the new TA calculated by BTS 2. Upon receiving the PHY INFO message, the MS sends BTS 2 an SABM frame.
Synchronous handover BTS 2 does not send the PHY INFO message. Upon sending the Handover Access message, the MS sends BTS 2 the SABM frame.
10. When the PHY INFO message is sent depends on the handover type.
l
Asynchronous handover The MS starts timer T3124 upon sending the Handover Access message for the first time. It stops timer T3124 upon receiving the PHY INFO message, and sends BTS 2 an SABM frame on an FACCH.
Synchronous handover Upon sending the Handover Access message, the MS sends BTS 2 an SABM frame.
11. Upon receiving the first SABM frame, BTS 2 sends an Establishment Indication message to notify the BSC of radio link establishment. 12. At the same time, BTS 2 sends a UA frame on an FACCH to notify the MS of radio link establishment. 13. The MS sends BTS 2 a Handover Complete message on the FACCH. BTS 2 forwards the message to notify the BSC of the handover success. The Handover Complete message carries only the handover complete indication. The MS does not return to the old channel
14 Handover
after sending this message. If the MS does not receive the PHY INFO message or the UA frame from the target cell, it sends a Handover Failure message on the old channel. 14. Upon receiving the Handover Complete message, the BSC stops timer T3103 and sends a Handover Performed message to notify the MSC of the handover completion. The Handover Performed message carries the handover type. At the same time, the BSC sends an RF Channel Release message to notify BTS 1 of channel release. The target cell forwards to the BSC the Handover Complete message it receives from the MS. Upon receiving the Handover Complete message, the BSC sends an RF Channel Release message to notify BTS 1 of channel release. Upon receiving the RF Channel Release message, BTS 1 sends an RF Channel Release Acknowledge message. The message indicates that the radio channel is released and ready for reallocation.
14.1.2 Inter-BSC Handover Procedure

This describes the inter-BSC handover procedure. Figure 14-2 shows the inter-BSC handover procedure.
14-4
Issue 01 (2008-06-10)
14 Handover
Figure 14-2 Inter-BSC handover procedure

MS BTS1 BSC1 MSC BSC2 BTS2 MS
Measurement Report from MS(1) SACCH
Handover Required(2) Start T7 Handover Command(7) Stop T7
Handover Request(3) Handover Request Acknowledge(6)
Channel Activation(4) Channel Activation Acknowledge(5)
Handover Command(9) FACCH
Handover Command(8) Start T8
Handover Access(9) Start T3124 Handover Detect(11) Handover Access(10) FACCH PHY INFO(13) FACCH Stop T3124 Establish Indication(15) SABM(14) FACCH UA(16) FACCH Handover Complete(19) Handover Complete(18) Handover Complete(17) FACCH
Handover Detect(12)
Clear Command(20) Stop T8 Clear Complete(21)
The difference between the inter-BSC handover procedure and the intra-BSC handover procedure lies in the signaling procedures on the A interface. Only the different signaling procedures are described as follows: 1. When an MS needs to be handed over to a cell controlled by BSC 2, BSC 1 sends the MSC a Handover Required message and starts timer T7. This message carries the Cell Identity (CI) of the target cell group and the serving cell, and the handover cause. Upon receiving the Handover Required message, if the MSC finds that the location area of the target cell is under the MSC, it sends BSC 2 a Handover Request message. The Handover Request message carries the information, transmission mode, MS classmark, and required channel classmark of the serving and the target cells. Upon receiving the Handover Request message, BSC 2 sends the MSC an SCCP Connection Confirm message, indicating
2.
Issue 01 (2008-06-10)
14-5
14 Handover
that its connection to the MSC is established. The A interface messages are sent through this SCCP connection. 3. BSC 2 activates a new channel and sends a Handover Request Acknowledge message to notify the MSC that the channel is now available. The Handover Request Acknowledge message carries the information on the allocated handover resources and the handover command indicating that the BSC is ready. Upon receiving the Handover Request Acknowledge message, the MSC sends BSC 1 a Handover Command message. Then BSC 1 stops timer T7. BSC 1 sends the MS a Handover Command message and starts timer T8, requesting the MS to access the new channel. The Handover Command message carries the CI, channel type, and handover reference. Upon receiving the Handover Complete message from BSC 2, the MSC sends BSC 1 a Clear Command message, which carries the clearing cause (for example, handover clearing). BSC 1 stops timer T8, initiates a local release procedure, releases the old channel, and sends the MSC a Clear Complete message, indicating that the clearing is complete.
4.
5.
For details about other signaling messages, refer to 14.1.2 Inter-BSC Handover Procedure.
NOTE
If the serving cell and the target cell are in different location areas, the MS initiates a location update procedure after a call is complete.
14.1.3 Inter-MSC Handover Procedure

This describes the inter-MSC handover procedure. Figure 14-3 shows the inter-MSC handover procedure.
14-6
Issue 01 (2008-06-10)
14 Handover
Figure 14-3 Inter-MSC handover procedure

MS BTS1 BSC1 MSC1 MSC2 BSC2 BTS2 MS
Measurement Report from MS(1) SACCH
Handover Required(2)
Perform Handover(3)
Handover Request(4)
Channel Activation(5) Channel Activation Acknowledge(6)
Radio Channel Ack(8) IAM(9) Handover Command(12) FACCH Handover Command(11) ACM(10)
Handover Request Acknowledge(7)
Handover Detect(15)
Handover Detect(14)
Handover Access(13) FACCH PHY INFO(16) FACCH PHY INFO(17) FACCH
Establish Indication(19)
SABM(18) FACCH UA(20) FACCH Handover Complete(21) FACCH
Clear Command(25) Clear Complete(26)
Send End Signal(24)
Handover Complete(23)
For the inter-MSC handover procedure, refer to 14.1.1 Intra-BSC Handover Procedure and 14.1.2 Inter-BSC Handover Procedure. The messages on the E interface are as follows: 1. 2. 3. 4. 5. Perform Handover: MAP layer message. It contains the CGI of the serving cell and the target cell and the required channel type. It informs MSC 2 that a handover will be initiated. Radio Channel Acknowledge: MAP layer message. It carries the information about the new channel in the target cell and the handover number. IAM: initial address message. It is a TUP/ISUP message. ACM: address complete message. It is a TUP/ISUP message. Send End Signal: MAP layer message. It indicates the end of transmission.
14.1.4 Inter-RAT Handover Procedure

This describes the inter-RAT handover procedure.
14 Handover
Figure 14-4 and Figure 14-5 show the inter-RAT handover procedure. Figure 14-4 GSM-to-UMTS handover procedure
MS BSS MSC Handover Required(1) Handover Command(3) FACCH Inter System to UTRAN Handover Command(2) Start T3121 Handover Complete(5) Stop T3121 Clear Command(6) Clear Complete(7) Handover to UTRAN Complete(4) FACCH RNC MS
The GSM-to-UMTS handover procedure is as follows: 1. 2. 3. 4. 5. 6. The BSS sends a Handover Required message to the MSC. Upon receiving the Handover Required message, the MSC sends the BSS an Inter System To UTRAN Handover Command message and starts timer T3121. Upon receiving the Inter System To UTRAN Handover Command message, the BSS sends the MS a Handover Command message on an FACCH. After the connection is successfully established, the MS sends the RNC a Handover to UTRAN Complete message on a UTRAN channel. The RNC forwards the Handover Complete message to the MSC. Upon receiving the Handover Complete message, the MSC stops timer T3121 and initiates a channel release procedure.
14-8
Issue 01 (2008-06-10)
14 Handover
Figure 14-5 UMTS-to-GSM handover procedure

MS BSS Handover Request(1) Handover Request Acknowledge(2) Handover Access(5) FACCH Handover Access(7) FACCH Handover Detect(6) Handover Complete(8) MSC RNC MS
Handover Request Acbowledge(3)
Handover Command(4) FACCH
For the UMTS-to-GSM handover procedure, refer to the GSM-to-UMTS handover procedure mentioned earlier.
14.2 Internal BSC Signaling Procedures (Handover)

The internal BSC signaling procedures of handover are categorized into the intra-BSC handover, inter-BSC handover, inter-MSC handover, and inter-RAT handover. 14.2.1 Internal BSC Signaling Procedure (Intra-BSC Handover) This describes the internal BSC signaling procedure of the intra-BSC handover. 14.2.2 Internal BSC Signaling Procedure (Inter-BSC Handover) This describes the internal BSC signaling procedure of the inter-BSC handover. 14.2.3 Internal BSC Signaling Procedure (Inter-MSC Handover) This describes the internal BSC signaling procedure of the inter-MSC handover. 14.2.4 Internal BSC Signaling Procedure (Inter-RAT Handover) This describes the internal BSC signaling procedure of the inter-RAT handover.
14.2.1 Internal BSC Signaling Procedure (Intra-BSC Handover)

This describes the internal BSC signaling procedure of the intra-BSC handover. 1. If the BSC considers that a call meets the handover trigger conditions, it selects a candidate cell from the candidate cell list based on the priority in a descending order. If the candidate cell is internal BSC, the BSC notifies the candidate cell of initiating an intra-BSC handover procedure, and the candidate cell will be the target cell. The BSC assigns a proper channel and notifies the BTS2 that serves the target cell to activate the channel. If IP transmission is used on the A interface and if the target channel uses a different payload type (PT) from the originating channel, the BSC sends a Channel Modify Prepare message to the MSC, notifying the MSC of the PT change in the current call.
2. 3.
Issue 01 (2008-06-10)
14 Handover
4. 5. 6. 7.
The BSC notifies the originating cell to send a Handover Command message to the MS, and starts timer T3103. After receiving the Handover Detect message, BTS 2 continues to wait for the Establishment Indication message and the Handover Complete message. After BTS 2 receives the Handover Complete message, BSC 2 stops timer T3103 and considers that the call is set up in the target cell. BSC 1 notifies BTS 1 of initiating a local release procedure. At the same time, it sends a Handover Performed message to notify the MSC of the handover completion. If IP transmission is used on the A interface, the message must carry the information elements: Chosen Channel and Speech Version (Chosen). The message is not controlled by the software parameter Controlling of Cic IE In BssMap Messages.
14.2.2 Internal BSC Signaling Procedure (Inter-BSC Handover)

This describes the internal BSC signaling procedure of the inter-BSC handover. 1. If the BSC considers that a call meets the handover trigger conditions, it selects a candidate cell from the candidate cell list based on the priority in a descending order. If the candidate cell is an external 2G cell, the outgoing BSC handover procedure is triggered. For the serving cell, the external cell is the target cell, and the BSC where the target cell is located is the target BSC, namely BSC 2. Upon handover initiation, BTS 1 sends the MSC a Handover Required message and starts timer T7 to wait for a Handover Command message. Upon receiving the Handover Request message from the MSC, the target BSC allocates and activates channels according to the target cell identity in the message. After channel activation, BTS 2 sends the MSC a Handover Request Acknowledge message that carries the Handover Command message. BTS1 forwards to the MS the Handover Command message that BSC 1 receives from the MSC and at the same time starts timer T8 to wait for the handover completion.
l
2. 3.
4.
If the Clear Command message with the cause value Handover Success is received before timer T8 expires, BSC 1 considers that the handover is successful. If the MS returns to the old channel before timer T8 expires, BSC 1 stops T8 and sends the MSC a Handover Failure message. If timer T8 expires, BSC 1 considers that the call drops and sends the MSC a Clear Request message.
5. 6. 7.
BTS 2 forwards the Handover Detect message to the MSC and continues to wait for the Establishment Indication message and the Handover Complete message. Upon receiving the Handover Complete message, BTS 2 sends a Handover Complete message to notify the MSC of handover completion. Upon receiving the Clear Command message, BTS 1 releases the radio resources that the call occupies and returns the MSC a Clear Complete message.
14.2.3 Internal BSC Signaling Procedure (Inter-MSC Handover)

This describes the internal BSC signaling procedure of the inter-MSC handover. The internal BSC signaling procedure of the inter-MSC handover is the same as that described in 14.2.2 Internal BSC Signaling Procedure (Inter-BSC Handover).
14 Handover
14.2.4 Internal BSC Signaling Procedure (Inter-RAT Handover)

This describes the internal BSC signaling procedure of the inter-RAT handover. The internal BSC signaling procedure of the inter-RAT handover is similar to that of the interBSC handover. The differences are as follows:
l
Obtaining the UTRAN neighbor cell information and the UTRAN system parameters from the Idle Mode, Handover Data, and Other Attributes Recording the capability of the MS
14.3 Abnormal Cases and Handling Suggestions (Handover)

This describes the abnormal cases of handover, probable causes, and handling suggestions. 14.3.1 No Available Channels in the Target Cell (Case Study) This describes the fault, probable causes, and handling suggestions. 14.3.2 Old BSS Not Receiving a Specified Message Upon T8 Expiry (Case Study) This describes the fault, probable causes, and handling suggestions. 14.3.3 MS Returning to the Old Channel After Inter-Cell Handover Failure (Case Study) This describes the fault, probable causes, and handling suggestions. 14.3.4 BSC Receiving a Connection Failure Indication Message (Case Study) This describes the fault, probable causes, and handling suggestions. 14.3.5 Forced Handover Failure (Case Study) This describes the fault, probable causes, and handling suggestions. 14.3.6 Handover Failure Caused by CIC Malfunction (Case Study) This describes the fault, probable causes, and handling suggestions. 14.3.7 Handover Failure Caused by MS Access Failure (Case Study) This describes the fault, probable causes, and handling suggestions.
14.3.1 No Available Channels in the Target Cell (Case Study)

Description
No channels are available in the target cell.
Analysis
l l l
During an inter-cell handover, no TCHs are available in the target cell. During a cross-cell handover, no SDCCHs are available in the target cell. During an intra-cell handover due to bad quality, no TCHs are available in the cell.
Issue 01 (2008-06-10)
14 Handover
l l
Check whether the target cell is congested. If yes, add TRXs to the target cell. Choose Set Cell Attributes > Channel Management > Advanced > Huawei Channel Allocation Algorithm II and Radio Channel Management and Control. Check that the TCH Traffic Busy Threshold parameter is set to a proper value. Choose Set Cell Attributes > Channel Management. Check that the Advanced Channel Type Change Permission parameter is set to a proper value.
14.3.2 Old BSS Not Receiving a Specified Message Upon T8 Expiry (Case Study)
Description
The old BSS does not receive a Clear Command message from the MSC or a Handover Failure message from the MS upon T8 expiry.
Analysis
The probable causes are analyzed as follows: 1. 2. 3. 4. 5. If the old BSS does not receive a Clear Command message from the MSC or a Handover Failure message from the MS upon T8 expiry, it releases the dedicated channels. The BSC sends the MSC a Clear Request message with the cause value Radio Interface Message Failure. Before a Clear Command message is received, the terrestrial resources on the old BSS side remain allocated. On receiving the Clear Command message, the old BSS changes the state of the terrestrial resources to idle and sends a Clear Complete message to the MSC. The MSC releases the SCCP connection to the old BSS and thus terminates the connection with the BSS.
In the Set Cell Attributes dialog box, choose Other Attributes > Advanced > Cell Timer. Check that the length of T8 is set properly.
14.3.3 MS Returning to the Old Channel After Inter-Cell Handover Failure (Case Study)
Description
The MS returns to the old channel after inter-cell handover failure.
14 Handover
Analysis
The probable cause can be either of the following: first, poor signal quality or low receive level on the Um interface; second, wrong data configurations of the external cells.
Check the signal quality and receive level on the Um interface. Check that the data configurations of the external cells are correct.
14.3.4 BSC Receiving a Connection Failure Indication Message (Case Study)

Description
Calls drop.
Analysis
l l
Radio link failure Hardware faults
l l
Check the resources on the Um interface. Check the antenna system and the power amplifier.
14.3.5 Forced Handover Failure (Case Study)

Description
Forced handover fails.
Analysis
l l l l
No neighbor cell Incorrect configuration of the neighbor cell No resources in the neighbor cell Bad radio conditions in the neighbor cell
Check the neighbor cell for its data configuration and radio signal quality, for example, the quality of receive level.
14 Handover
14.3.6 Handover Failure Caused by CIC Malfunction (Case Study)

Description
Handover fails. The cause value of the Handover Failure message is Requested Terrestrial Resource Unavailable.
Analysis
If the CIC in the Handover Request message received by the target BSC is labeled BLOCK, the target BSC responds to the MSC with a Handover Failure message with the cause value Requested Terrestrial Resource Unavailable.
Check the state of the CIC.
14.3.7 Handover Failure Caused by MS Access Failure (Case Study)

Description
The MS cannot be handed over.
Analysis
l l
The system does not trigger the handover. The configurations of the neighbor cell are faulty.
l l l l
Check whether the handover trigger conditions are met. Check whether there is a neighbor cell list in the measurement report. Check whether the neighbor cell has available channels. Check whether the data of the neighbor cell is incorrect, for example, whether there is inconsistency in CGI.
14-14
Issue 01 (2008-06-10)
15 Call Re-Establishment
15
About This Chapter
Call Re-Establishment
The call re-establishment procedure allows an MS to resume a connection after a radio link failure. It may take place in a new cell or a new location area. 15.1 Call Re-Establishment Procedure This describes the call re-establishment procedure. 15.2 Internal BSC Signaling Procedure (Call Re-Establishment) The call re-establishment is controlled by the MSC, and the BSC does no special processing. 15.3 Abnormal Cases and Handling Suggestions (Call Re-Establishment) This describes the abnormal cases of call re-establishment, probable causes, and handling suggestions.
Issue 01 (2008-06-10)
15-1
15.1 Call Re-Establishment Procedure

This describes the call re-establishment procedure. Figure 15-1 shows the call re-establishment procedure. Figure 15-1 Call re-establishment procedure
MS BTS BSC MSC
Connection Failure Indication(radio link failure)(1) Channel Request(5) RACH
Clear Request(2) Clear Command(3) CM Re-establishment Request(7) CC(8) Cipher Mode Command(10) Cipher Mode Complete(11) Assignment Request(12) Assignment Complete(13) Start T322
Establish Indication(CM Reestablishment Request)(6)
CM Service Accepted (9)
Start T3230
Status Enquiry(14) FACCH Status(15) FACCH Stop T3230
Stop T322
The previous procedure is described as follows: 1. 2. 3. 4. After a radio link failure is detected, the BTS sends the BSC a Connection Failure Indication message, which contains the cause value for radio link failure. The BSC sends the MSC a Clear Request message, which contains the cause for the abnormal release. On receiving the Clear Request message, the MSC sends the BSC a Clear Command message, requesting the release of radio resources. The BSC initiates a release procedure, releases the channel resources on the Um interface, and returns a Clear Complete message to the MSC.
15-2
5. 6.
The MS sends the BTS a Channel Request message (cause value: Call re-establishment) and initiates an Immediate Assignment Procedure (Seizing Signaling Channel). The BTS initiates a call re-establishment procedure by sending the BSC a CM Reestablishment Request message. In addition, the MM entity of the MS starts timer T3230, gives an indication to all CM entities that are being re-established, and remains in the MM sublayer state Wait For Reestablish. The CM Re-Establishment Request message contains the IMSI (or TMSI), classmark 2, and Ciphering Key Sequence Number (CKSN). The BSC establishes an SCCP link connection on the A interface and sends the MSC a CM Service Request message. The MSC sends the BSC a Connect Confirm message. The MSC sends the MS a CM Service Accepted message on the SDCCH on the Um interface.
7. 8. 9.
10. The MSC initiates the ciphering mode setting procedure by sending a Cipher Mode Command message. For details, refer to Ciphering Procedure. Once the ciphering procedure is complete or the CM Service Accepted message is received, the MS stops timer T3230 and enters the MM Connection Active state. 11. The BSC returns a Cipher Mode Complete message to the MSC. 12. The MSC sends the BSC an Assignment Request message and initiates a signaling processing procedure. For details about the signaling procedure, refer to 11.1 Mobile Originated Call Establishment Procedure. 13. The BSC returns an Assignment Complete message to the MSC. 14. The MSC initiates the status enquiry procedure by sending the MS a Status Enquiry message. At the same time, timer T322 is started. 15. The MS reports its call state or attach state to the MSC. The MSC stops timer T322 accordingly. The previous procedure is summarized as follows: 1. 2. 3. 4. 5. Steps 1 through 4 shown in Figure 15-1 describe the radio resource release procedure, which is the same as the normal release procedure. Steps 5 through 9 shown in Figure 15-1 describe the immediate assignment procedure, namely, the signaling channel seizure procedure. Steps 10 and 11 shown in Figure 15-1 describe the ciphering procedure. Steps 12 and 13 shown in Figure 15-1 describe the assignment procedure. Initiation of the call re-establishment procedure
l
If a cell is required to support call re-establishment, Call Reestablishment Forbidden in Set Cell Attributes must not be selected, and the cell cannot be in barred state. Upon detection of a link failure, the MS sends a Channel Request message with the cause value Call Re-Establishment in the selected cell. The previous channel resources are released by the BSC after the timer on the BTS side expires. Upon detection of a link failure, the BTS sends the BSC a Connection Failure message with the cause value Radio Link Failure. Then the BSC releases the corresponding radio resources and waits for the call re-establishment request from the MS.
6.
Mode of the MS in the call re-establishment procedure The MS cannot return to idle mode during a call re-establishment procedure. Therefore, if the cell selected for call re-establishment is not the location area, the MS cannot perform location update until the call re-establishment procedure is complete.
Issue 01 (2008-06-10)
15-3
15.2 Internal BSC Signaling Procedure (Call ReEstablishment)

The call re-establishment is controlled by the MSC, and the BSC does no special processing.
15.3 Abnormal Cases and Handling Suggestions (Call ReEstablishment)

This describes the abnormal cases of call re-establishment, probable causes, and handling suggestions. 15.3.1 Network Sending a CM Service Reject Message (Case Study) This describes the fault, probable causes, and handling suggestions. 15.3.2 Call Re-Establishment Not Allowed or Re-Establishment Failure (Case Study) This describes the fault, probable causes, and handling suggestions. 15.3.3 Call Re-Establishment Failure Caused by RR Connection Failure (Case Study) This describes the fault, probable causes, and handling suggestions.
15.3.1 Network Sending a CM Service Reject Message (Case Study)

Description
After the MSC receives a CM Re-Establishment Request message, if the RR sublayer sends an indication that the ciphering mode setting procedure is complete, or if a CM Service Accept message is received, you can infer that the MS accepts the services. The MS re-enters the MM sublayer state MM Connection Active. If the re-establishment request from the MS does not correspond to its current call state, the network returns the MS a CM Service Reject message.
Analysis
If the network cannot process the re-establishment request, it sends a CM Service Reject message with one of the following cause values:
l l l l l l
IMSI Unknown in VLR Illegal MS Network Failure Congestion Service Option not Supported Service Option Temporarily out of Order
Upon receiving the CM Service Reject message, the MS releases the MM connection and the relevant RR connection.
l
If the cause value is IMSI Unknown In VLR, check that the location update procedure is performed successfully to ensure that the IMSI is loaded to the VLR. In addition, check that the IMSI exists in the HLR. If the cause value is Illegal MS, check that the MS can access the network and can perform location update. If not, replace the MS with a new one that can access the network. If cause value is Network Failure, modify the configuration that corresponds to call reestablishment on the network side. If the cause value is Congestion, configure more channels. If the cause value is Service Option Not Supported, modify the configuration that corresponds to call re-establishment on the network side. If the cause value is Service Option Temporarily Out Of Order, modify the configuration that corresponds to call re-establishment on the network side, for example, the CM service related functions. If the previously mentioned measures do not work, analyze the values of the corresponding information elements to find out in which network element the fault takes place. Then perform detailed analysis in the located network element.
l l
15.3.2 Call Re-Establishment Not Allowed or Re-Establishment Failure (Case Study)

Description
When an MM connection is established, the MM layer sends an indication to the CC layer. If the MM layer is disconnected, the connection may be re-established through a CC request.
Analysis
l
If re-establishment is not allowed, and the call is initiated within the establishment or clearing period, the CC layer releases the MM connection. If re-establishment is unsuccessful, the MM connection is released, and a release indication is sent to the CC layer.
Check whether the Call Reestablishment Forbidden parameter of the cell where the reestablishment procedure is initiated is set correctly and whether the cell is barred.
15.3.3 Call Re-Establishment Failure Caused by RR Connection Failure (Case Study)

Description
Upon detection of a random access failure or an RR connection failure, the MS stops timer T3230, aborts the call re-establishment procedure, and releases all active MM connections. Upon detection of an RR connection failure, the MSC aborts the call re-establishment procedure and releases all active MM connections.
Analysis
l l l
Signal quality on the Um interface is poor. Channels on the Um interface are congested. The network side has no response.
l
If the transmission quality on the Um interface is poor, use a test MS to measure the uplink and downlink receive quality and the power level. Improve the transmit and receive quality and reduce the interference. If the channels are congested, register and observe the relevant traffic statistics to determine the severity level of congestion. Expand the system capacity if the congestion rate is high. If the problem lies in the network, make adjustments on the network side to locate the phases in which serious response delay occurs.
15-6
Issue 01 (2008-06-10)
16 Directed Retry
16
About This Chapter
Directed Retry
Directed retry is a special type of handover. When no radio resource is available for allocation in a serving cell during channel assignment, the BSS hands over the channel request from the serving cell to a neighbor cell. 16.1 Directed Retry Procedures This describes directed retry procedures. The directed retry procedures are categorized into the intra-BSC directed retry procedure, inter-BSC directed retry procedure, and inter-MSC directed retry procedure. 16.2 Internal BSC Signaling Procedures (Directed Retry) This describes internal BSC signaling procedures (directed retry). The internal BSC signaling procedures are categorized into the intra-BSC directed retry procedure, inter-BSC directed retry procedure, and inter-MSC directed retry procedure. 16.3 Abnormal Cases and Handling Suggestions (Directed Retry) This describes the abnormal directed retry cases.
Issue 01 (2008-06-10)
16-1
16 Directed Retry
16.1 Directed Retry Procedures

This describes directed retry procedures. The directed retry procedures are categorized into the intra-BSC directed retry procedure, inter-BSC directed retry procedure, and inter-MSC directed retry procedure. 16.1.1 Intra-BSC Directed Retry Procedure This describes the intra-BSC directed retry procedure. 16.1.2 Inter-BSC Directed Retry Procedure This describes the inter-BSC directed retry procedure. 16.1.3 Inter-MSC Directed Retry Procedure This describes the inter-MSC directed retry procedure.
16.1.1 Intra-BSC Directed Retry Procedure

This describes the intra-BSC directed retry procedure. Figure 16-1 shows the intra-BSC directed retry procedure.
16-2
Issue 01 (2008-06-10)
16 Directed Retry
Figure 16-1 Intra-BSC directed retry procedure

MS Channel Request(1) RACH Immediate Assignment Command(5) AGCH SABM(6) UA(7) SDCCH Establish Indication (CM Service Request)(8) CM Service Accepted(11) Setup(12) SDCCH SDCCH Call Proceeding(13) Assignment Request(14) Channel Activation(15) Channel Activation Acknowledge(16) Handover Command(17) SDCCH Start T3103 Handover Detect(19) Handover Access(18) FACCH PHY INFO(20) FACCH PHY INFO(21) FACCH Establish Indication(23) Handover Complete(25) Stop T3103 Assignment Complete(26) SABM(22) FACCH UA(24) FACCH BTS1 Channel Required(2) Channel Activation(3) Channel Activation Acknowledge(4) BSC MSC BTS2 MS
CR(Complete L3 Information)(9) CC(10)
The previous procedure is described as follows: 1. 2. The MS sends the BTS a Channel Request message on the RACH. The BTS sends the BSC a Channel Required message.
Issue 01 (2008-06-10)
16-3
16 Directed Retry
3. 4.
Upon receiving the Channel Required message, the BSC assigns a signaling channel and sends the BTS a Channel Activation message. Upon receiving the Channel Activation message, if the channel type is correct, the BTS turns on the power amplifier on the specified channel to receive information on the uplink, and sends a Channel Activation Acknowledge message to the BSC. Upon receiving the Channel Activation Acknowledge message, the BSC sends an Immediate Assignment Command message on the AGCH to notify the MS of channel access. After the MS successfully accesses the channel, the MSC sends the BSC an Assignment Request message requesting for TCH radio resources. If a terrestrial circuit is required between the MSC and the BSC, the Assignment Request message contains information related to the terrestrial circuit. If no qualified TCH is available in the serving cell, the BSC attempts to hand over the MS to a neighbor cell that provides voice services. If the target cell and the serving cell are controlled by the same BSC, the directed retry is an intra-BSC directed retry.
5.
6.
The previous procedure is summarized as follows: 1. 2. Steps 1 through 8 in the procedure shown in Figure 16-1 are the random access and immediate assignment procedures, in which the BSS assigns a signaling channel to the MS. Steps 14 through 24 in the procedure shown in Figure 16-1 are TCH directed retry procedure, in which the BSS assigns a speech channel to the MS.
16.1.2 Inter-BSC Directed Retry Procedure

This describes the inter-BSC directed retry procedure. Figure 16-2 shows the inter-BSC directed retry procedure.
16-4
Issue 01 (2008-06-10)
16 Directed Retry
Figure 16-2 Inter-BSC directed retry procedure

MS BTS1 Channel Request(1) RACH BSC1 MSC BSC2 BTS2 MS
Channel Required(2) Channel Activation(3) Channel Activation ACK(4)
Immediate Assignment Command(5) AGCH SABM(6) SDCCH UA(7) CM Service Accepted(11) SDCCH SDCCH SDCCH
Establish Indication (CM Service Request)(8)
CR (Complete Layer3 Information)(9) CC(10)
Setup(12) Call Proceeding(13) Assignment Request(14) Handover Required(15) Handover Request(16) Start T10 Channel Activation(17)
Handover Command(20) Handover Command(21) SDCCH Start T8
Handover Channel Activation Request Acknowledge(19) Acknowledge(18)
Handover Detect(24)
Handover Detect(23)
Handover Access(22) FACCH PHY INFO(25) FACCH PHY INFO(26) FACCH
SABM(27) FACCH UA(29) FACCH
Handover Complete(30) Stop T10 Clear Command(32) Stop T8 Clear Complete(33) Handover Complete(31) FACCH
Issue 01 (2008-06-10)
16-5
16 Directed Retry
The inter-BSC directed retry procedure differs from the intra-BSC directed retry procedure in A-interface signaling procedures. These signaling procedures are described as follows: 1. When the MS must be directly retried to a cell under BSC2, BSC1 sends the MSC a Handover Required message requesting the MS to initiate an outgoing inter-BSC handover.
NOTE
Direct retry is a special type of handover.
2. 3. 4.
Upon receiving the Handover Required message, the MSC sends BSC2 a Handover Request message. BSC2 activates a new channel and sends a Handover Request Acknowledge message to notify the MSC that the channel is now available. Upon receiving the Handover Request Acknowledge message, the MSC sends BSC1 a Handover Command message. BSC1 forwards the Handover Command message on a TCH to notify the MS of channel access. Upon receiving the Handover Complete message from BSC2, the MSC sends BSC1 a Clear Command message. BSC1 initiates a local release procedure and sends the MSC a Clear Complete message.
5.
For details about other signaling messages, refer to 16.1.1 Intra-BSC Directed Retry Procedure.
16.1.3 Inter-MSC Directed Retry Procedure

This describes the inter-MSC directed retry procedure. Figure 16-3 shows the inter-MSC directed retry procedure.
16-6
Issue 01 (2008-06-10)
16 Directed Retry
Figure 16-3 Inter-MSC directed retry procedure

MS BTS1 BSC1 MSC1 MSC2 BSC2 BTS2 MS
Assignment Request(1) Handover Required(2) Perform Handover(3) Handover Request(4) Start T10 Channel Activation(5) Channel Handover Activation Request Acknowledge(6) Radio Channel Acknowledge(7) Acknowledge(8) IAM(9) Handover Command(11) Hand Command(12) SDCCH Start T8 Handover Detect(14) Handover Access(13) FACCH PHY INFO(15) FACCH PHY INFO(16) Handover Detect(17) FACCH Establish Indication(19 Handover Complete(21) Stop T10 Clear Command(24) Stop T8 Clear Complete(25) Send End Signal(23) Handover Complete(22) SABM(18) FACCH UA(20 FACCH FACCH ACM(10)
For details about the inter-MSC directed retry procedure, refer to 16.1.2 Inter-BSC Directed Retry Procedure.
16.2 Internal BSC Signaling Procedures (Directed Retry)

This describes internal BSC signaling procedures (directed retry). The internal BSC signaling procedures are categorized into the intra-BSC directed retry procedure, inter-BSC directed retry procedure, and inter-MSC directed retry procedure. 16.2.1 Internal BSC Signaling Procedure (Intra-BSC Directed Retry) This describes the internal BSC signaling procedure of the intra-BSC directed retry. 16.2.2 Internal BSC Signaling Procedure (Inter-BSC Directed Retry)
16 Directed Retry
This describes the internal BSC signaling procedure of the inter-BSC directed retry. 16.2.3 Internal BSC Signaling Procedure (Inter-MSC Directed Retry) This describes the internal BSC signaling procedure of the inter-MSC directed retry.
16.2.1 Internal BSC Signaling Procedure (Intra-BSC Directed Retry)

This describes the internal BSC signaling procedure of the intra-BSC directed retry. After the BSC receives the Assignment Request message from the MSC, a directed retry procedure is triggered if the cell where the call is originated has no available TCHs or Assignment Cell Load Judge is enabled, and the Directed Retry Allowed in the Cell Attributes window is selected.
NOTE
A directed retry procedure is a handover procedure.
The procedure for the intra-BSC directed retry is described as follows: 1. If the BSC considers that the call meets the handover trigger conditions, it selects a candidate cell from the candidate cell list based on the priority in a descending order. If the candidate cell is under the same BSC as the serving cell, the BSC notifies the candidate cell of initiating an intra-BSC directed retry procedure, and the candidate cell will be the target cell. A channel in the target cell is assigned and the BTS2 that serves the target cell is notified to activate the channel. After BTS2 activates the channel, the BSC notifies the MS to send a Handover Command message to BTS1. Meanwhile, BSC2 starts timer T3103 to wait for the Handover Complete message. On receiving the Handover Detect message, BTS2 continues to wait for the Establishment Indication message and the Handover Complete message. On receiving the Handover Complete message, BSC2 stops timer T3103 and considers that the call is set up in the target cell. The BSC sends an Assignment Complete message to notify the MSC that assignment is over. The Assignment Complete message carries the information about a new cell. At the same time, BSC1 notifies BTS1 to initiate a local release procedure.
2. 3.
4. 5. 6.
16.2.2 Internal BSC Signaling Procedure (Inter-BSC Directed Retry)

This describes the internal BSC signaling procedure of the inter-BSC directed retry. After the BSC receives the Assignment Request message from the MSC, a directed retry procedure is triggered if the cell where the call is originated has no available TCHs or Assignment Cell Load Judge is enabled, and the Directed Retry Allowed in the Cell Attributes window is selected. If the target cell of the directed retry is an external cell, the inter-BSC directed retry procedure is triggered.
NOTE
A directed retry procedure is actually a handover procedure.
The BSC starts an eight-second timer awaiting the Handover Detect message from the BTS. At the same time, the BSC initiates a forced handover procedure. The forced handover procedure is described as follows: 1. If the BSC considers that the call meets the handover trigger conditions, it selects a candidate cell from the candidate cell list based on the priority in a descending order. If the
16-8
16 Directed Retry
candidate cell is an external cell, the outgoing BSC directed retry procedure, namely the inter-BSC handover procedure is triggered. 2. Upon the initiation of the inter-BSC handover procedure, BTS1 sends the MSC a Handover Required message and starts timer T7 to wait for a Handover Command message from the MSC. On receiving the Handover Request message from the MSC, BSC2 allocates and activates a channel according to the target cell ID in the message. After channel activation, BTS2 sends the MSC a Handover Request Acknowledge message that carries the Handover Command message. BTS1 forwards to the MS the Handover Command message that BSC1 receives from the MSC and at the same time starts timer T8 to wait for the handover completion.
l
3.
4.
If the Clear Command message with the cause value as Handover Success or Call Control is received before timer T8 expires, BSC1 considers that the handover is successful. If the MS returns to the old channel before timer T8 expires, BSC1 stops timer T8 and sends the MSC a Handover Failure message. If timer T8 expires, BSC1 considers that the call drops and sends the MSC a Clear Request message.
5. 6. 7.
BTS2 forwards the Handover Detect message to the MSC and continues to wait for the Establishment Indication message and the Handover Complete message. On receiving the Handover Complete message, BTS2 stops timer T3103B2 and sends a Handover Complete message to notify the MSC of handover completion. On receiving the Clear Command message, BTS1 releases the radio resources that the call occupies and returns the MSC a Clear Complete message.
16.2.3 Internal BSC Signaling Procedure (Inter-MSC Directed Retry)

This describes the internal BSC signaling procedure of the inter-MSC directed retry. The internal BSC signaling procedure of the inter-MSC directed retry is the same as that of the inter-BSC directed retry.
16.3 Abnormal Cases and Handling Suggestions (Directed Retry)

This describes the abnormal directed retry cases. 16.3.1 Directed Retry Failure Caused by No Available Channels in the Target Cell (Case Study) This describes the fault, probable causes, and handling suggestions. 16.3.2 Directed Retry Failure Caused by Channel Activation Failure (Case Study) This describes the fault, probable causes, and handling suggestions.
16.3.1 Directed Retry Failure Caused by No Available Channels in the Target Cell (Case Study)
16 Directed Retry
Description
When no channel is available in the target cell, BSC2 sends BSC1 a handover failure message, and BSC1 sends the MSC an Assignment Failure message.
Analysis
No TCH is available in the target cell.
Check whether the target cell is congested. If yes, add TRXs to the target cell.
16.3.2 Directed Retry Failure Caused by Channel Activation Failure (Case Study)
Description
When channel activation in the target cell fails, BSC2 sends the MSC an Assignment Failure message.
Analysis
The desired channel in the target cell fails to be activated due to TRX failure.
Locate the channel number in the Channel Activation Negative Acknowledge message, and check whether the corresponding TRX is faulty. If the TRX is faulty, replace it.
16-10
Issue 01 (2008-06-10)
17 BSC Re-Assignment
17
About This Chapter
BSC Re-Assignment
This describes BSC re-assignment. BSC re-assignment refers to a TCH assignment procedure initiated by the BSC after the BSC receives an Assignment Failure message from the MS on the SDCCH. BSC re-assignment raises the success rate of assignments on the Um interface. 17.1 BSC Re-Assignment Procedure This describes the BSC re-assignment procedure. 17.2 Internal BSC Signaling Procedure (BSC Re-Assignment) This describes the internal BSC signaling procedure of BSC re-assignment. 17.3 Abnormal Cases and Handling Suggestions (BSC Re-Assignment) This describes the abnormal cases of BSC re-assignment, probable causes, and handling suggestions.
Issue 01 (2008-06-10)
17-1
17.1 BSC Re-Assignment Procedure

This describes the BSC re-assignment procedure. Figure 17-1 shows the BSC re-assignment procedure. Figure 17-1 BSC re-assignment procedure
MS BTS Assignment Command SDCCH Assignment Failure SDCCH Start T3107 BSC MSC
Stop T3107 Channel Activation(1) Channel Activation Acknowldge(2)
Assignment Command(3) SDCCH SABM(4) FACCH

UA(5)
Start T3107
FACCH Assignment Complete(7) FACCH
Stop T3107
The previous procedure is described as follows: 1. After the BSC receives the Assignment Failure message from the MS, the BSS stops timer T3107. After a series of BSC internal processing, the BSC sends the BTS a Channel Activate message and waits for a Channel Activation Acknowledge message from the BTS. Upon receiving the Channel Activation Acknowledge message from the BTS, the BSC performs internal processing. The BSC sends the MS an Assignment Command message on the SDCCH that is not released, and waits for an Establish Indication message from the MS.
2. 3.
17-2
Issue 01 (2008-06-10)
4. 5. 6. 7. 8.
The MS sends the BTS an SABM frame on the main DCCH specified in the Assignment Command message. The BTS sends the MS a UA frame on the main DCCH. The BTS sends the BSC an Establishment Indication message. Upon accessing the speech channel, the MS sends the BSC an Assignment Complete message on the main DCCH. Upon successful assignment of a TCH and a terrestrial circuit, the BSC sends the MSC an Assignment Complete message on the occupied TCH, indicating that the call enters the session state.
17.2 Internal BSC Signaling Procedure (BSC ReAssignment)

This describes the internal BSC signaling procedure of BSC re-assignment. The BSC sends the BTS an Assignment Command message and starts timer T3107. Before timer T3107 expires, the BSC receives an Assignment Failure message from the BTS. 1. Based on the Assignment Request message, the BSC selects an appropriate TRX, activates a channel, and sends the BTS an Assignment Command message. The Assignment Command message carries the information about the new channel and informs the MS to access the new channel. The BSC records the information on the first assignment, such as the channel assignment requirements, voice version supported by the MSC, TRX number, band attributes, MS maximum and minimum power, call type, handover type, indexes of neighbor cells, requirements for downlink DTX, classmark 2, classmark 3, and cell number. Based on the circuit pool number in the first assignment, the BSC obtains the circuit capability and attaches the channel type parameter in the Channel Assignment Command message. Based on the channel priority in the Assignment Request message from the MSC, the BSC fills the channel priority in the Assignment Command message. Based on the cell type in the first assignment, the BSC fills cell type in the Assignment Command message. After all relevant requirements are specified, the BSC assigns a channel as required. The subsequent procedure is the same as that of the first assignment.
2.
3.
4. 5. 6.
17.3 Abnormal Cases and Handling Suggestions (BSC ReAssignment)

This describes the abnormal cases of BSC re-assignment, probable causes, and handling suggestions. 17.3.1 BSC Failure to Initiate a Re-Assignment Procedure (Case Study) This describes the fault, probable causes, and handling suggestions.
Issue 01 (2008-06-10)
17-3
17.3.1 BSC Failure to Initiate a Re-Assignment Procedure (Case Study)

Description
After sending an Assignment Command message, the BSC does not initiate a re-assignment procedure even though re-assignment is enabled.
Analysis
The BSC starts timer T3107. If timer T3107 expires, the BSC does not initiate a re-assignment procedure. Upon receiving a Connect Failure message from the BTS, the BSC does not initiate a reassignment procedure. When timer T3107 expires or a Connect Failure message is received, the BSC releases related resources.
NOTE
For details, refer to GSM Rec. 0858 and 0808.
If the BSC receives a Connect Failure message from the BTS, the transmission quality on the A interface should be improved. To improve the transmission quality on the Um interface and to reduce interference, perform a drive test to check the signaling level on the downlink and uplink channels.
17-4
Issue 01 (2008-06-10)
18 Queuing and Preemption
18
About This Chapter
Queuing and Preemption
This describes queuing and pre-emption. 18.1 Queuing Procedure This describes the queuing procedure. 18.2 Preemption Procedure This describes the preemption procedure. 18.3 Internal BSC Signaling Procedure (Queuing and Preemption) This describes the internal BSC signaling procedure of queuing and pre-emption. 18.4 Abnormal Cases and Handling Suggestions (Queuing and Preemption) This describes the abnormal cases of queuing and preemption, probable causes, and handling suggestions.
Issue 01 (2008-06-10)
18-1
18.1 Queuing Procedure

This describes the queuing procedure. If no TCHs are available and queuing is allowed, the assignment requests are placed in a waiting queue. When the TCHs are available, they are assigned in the queuing sequence. Figure 18-1 shows the queuing procedure. Figure 18-1 Queuing procedure
MS BTS BSC MSC
Immediate Assignment Procedure Setup SDCCH Call Proceeding SDCCH Assignment Request(1) Queuing Indication Start T11 Start Tqho
StopT11
TCH Assignment Procedure(2) Assignment Complete StopTqho TALKING Release Procedure
The previous procedure is described as follows: 1. The MSC sends the BSC an Assignment Request message and finds that no speech channel is available. If queuing is allowed, the assignment request is placed in a queue, and timer T11 is started.
18-2
Issue 01 (2008-06-10)
2.
When a speech channel is assigned, the queuing procedure is complete, and timer T11 stops.
18.2 Preemption Procedure

This describes the preemption procedure. Preemption refers to handing over an MS with a lower priority to another speech channel or cell so that an MS with a higher priority acquires the speech channel resources. Figure 18-2 shows the preemption procedure. Figure 18-2 Preemption procedure
Low Priority MS High Priority MS BTS BSC MSC
Talking Assignment Request
Release Procedure or Handover Procedure(2)
Preemption Start (1)
Start T11 Start Tqho StopT11
TCH Assignment Procedure Assignment Complete StopTqho TALKING
Release Procedure
The previous procedure is described as follows: 1. The MSC sends the BSC an Assignment Request message and finds that no speech channel is available. If pre-emption is allowed and the priority of the subscriber is higher than the priority of the subscriber that occupies the speech channel, the preemption procedure is initiated. The subscriber with a lower priority is handed over to another speech channel or cell. The subscriber with a higher priority seizes the speech channel and the pre-emption procedure is complete.
2. 3.
Issue 01 (2008-06-10)
18.3 Internal BSC Signaling Procedure (Queuing and Preemption)

This describes the internal BSC signaling procedure of queuing and pre-emption. 1. Internal BSC signaling procedure of queuing The BSC processes the requests from the MSC, manages the queuing, and determines whether queuing is allowed. Only assignment requests and inter-cell handover requests can be queued. Upon receiving an Assignment Request message, the BSC searches for an available channel. If no channel is available, the BSC sends the MSC a Queuing Indication message and starts timer T11. The duration of the timer is configurable. The BSC places the Assignment Request message in a queue and starts the message when appropriate. Upon assigning a TCH, the BSC stops timer T11 and sends the MSC an Assignment Complete message. 2. Internal BSC signaling procedure of pre-emption If no TCH is available, the BSC checks the pre-emption settings and starts a pre-emption procedure. Among all occupied TCHs, the BSC searches for a TCH that has comparatively lower priority and that meets the pre-emption requirements. If no such TCHs are available, the queuing procedure is triggered. The BSC checks whether eMLPP is enabled. If eMLPP is enabled in the current cell, the preempted call with a lower priority is forced to perform an outgoing cell handover. The call with a higher priority preempts the released TCH. If eMLPP is not enabled, the call with a lower priority is directly released, and the call with a higher priority preempts the TCH.
18.4 Abnormal Cases and Handling Suggestions (Queuing and Preemption)

This describes the abnormal cases of queuing and preemption, probable causes, and handling suggestions. 18.4.1 BSC Sending a Clear Request Message to the MS (Case Study) This describes the fault, probable causes, and handling suggestions.
18.4.1 BSC Sending a Clear Request Message to the MS (Case Study)

Description
The BSC sends the MSC a Clear Request message.
18-4
Issue 01 (2008-06-10)
Analysis
l
If the BSC finds no available TCH after timer T11 expires, the BSC removes the Assignment Request message from the queue and sends the MSC a Clear Request message with the cause No Radio Resource Available. After TCH allocation fails, the BSC sends the MSC an Assignment Failure message. Then, the MSC stops timer Tqho.
Check whether there is an allocable TCH inside the BSC.
Issue 01 (2008-06-10)
18-5
19 Short Messages
19
About This Chapter
Short Messages
For an idle MS, short messages are transferred on the SDCCH. For a busy MS, however, short messages are transferred on the SACCH. The short message procedure comprises two fundamental procedures: mobile originating short message transfer procedure and mobile terminating short message transfer procedure. 19.1 Short Message Procedures The short message transfer procedure comprises the short message sending and receiving procedures initiated by an idle or a busy MS. 19.2 Internal BSC Signaling Procedure (Short Messages) This describes the internal BSC signaling procedure of short messages transfer. 19.3 Abnormal Cases and Handling Suggestions (Short Messages) This describes the abnormal cases of short messages, probable causes, and handling suggestions.
Issue 01 (2008-06-10)
19-1
19 Short Messages
19.1 Short Message Procedures

The short message transfer procedure comprises the short message sending and receiving procedures initiated by an idle or a busy MS. 19.1.1 Short Message Sending Procedure of an Idle MS This describes the short message sending procedure initiated by an idle MS. 19.1.2 Short Message Receiving Procedure of an Idle MS This describes the short message receiving procedure initiated by an idle MS. 19.1.3 Short Message Sending Procedure of a Busy MS This describes the short message sending procedure initiated by a busy MS. 19.1.4 Short Message Receiving Procedure of a Busy MS This describes the short message receiving procedure initiated by a busy MS.
19.1.1 Short Message Sending Procedure of an Idle MS

This describes the short message sending procedure initiated by an idle MS. Figure 19-1 shows the short message sending procedure initiated by an idle MS. Figure 19-1 Short message sending procedure of an idle MS
MS BTS BSC MSC
Immediate Assignment Procedure Authentication Request SDCCH SDCCH SDCCH SDCCH SDCCH SABM (SAPI 3)(2) SDCCH UA(4) SDCCH SDCCH SDCCH SDCCH SDCCH Release Procedure CP DATA(5) CP Acknowledge(6) CP DATA(7) CP Acknowledge(8) Establish Indication (SAPI)(3) Authentication Response Ciphering Mode Command Ciphering Mode Complete CM Service Accepted (1)
19-2
Issue 01 (2008-06-10)
19 Short Messages
The short message sending procedure initiated by an idle MS is described as follows: 1. 2. The MS sends an SABM frame again, notifying the network side that a user needs to establish the SMS. The BSC provides a transparent-transmission channel for short message exchange between the MS and the MSC.
In this procedure, the MSC, if possible, sends the BSC an Access Request message for channel allocation. The time for sending the Access Request message is the same as that for an ordinary call. The BSC provides the SMS either by allocating a new channel or by using the original SDCCH. The protocol on point-to-point SMS covers four layers, which are the connection management layer (CM), relay layer (RL), transport layer (TL), and application layer (AL). Both the CP DATA message and the CP Acknowledge message shown in Figure 19-1 are transferred at the CM layer. The CP DATA message carries the contents of the messages at the RL and AL layers. The CP Acknowledge message is the acknowledgement message of the CP DATA message. The previous procedure is summarized as follows: 1. 2. Steps 1 through 4 in the procedure are the random access and immediate assignment procedures, in which the BSS assigns a signaling channel to the MS. Steps 5 through 8 are the short message sending procedure.
19.1.2 Short Message Receiving Procedure of an Idle MS

This describes the short message receiving procedure initiated by an idle MS. Figure 19-2 shows the short message receiving procedure initiated by an idle MS.
Issue 01 (2008-06-10)
19-3
19 Short Messages
Figure 19-2 Short message receiving procedure of an idle MS

MS BTS BSC Paging(1) Paging Request PCH Immediate Assignment Prcedure CR(Complete Layer3 Information(3) CC(4) Authentication Request(5) SDCCH Authentication Response(6) SDCCH SDCCH SDCCH Establis Request(SAPI 3)(10) SABM(SAPI 3)(11) SDCCH UA(12) SDCCH Establish Confirm(SAPI 3)(13) CP DATA(14) SDCCH CP Acknowledge(15) SDCCH SDCCH SDCCH Release Procedure CP DATA(16) CP Acknowledge(17) Cipherding Mode Commnd(7) Cipherding Mode Complete(8) CP DATA(9) Paging Command(2) MSC
The previous procedure is summarized as follows:

l
Steps 1 through 3 is the paging response and immediate assignment procedure. The MSC sends a Paging Command message. The MS requests an SDCCH channel and returns a Paging Response message.
Steps 14 through 17 is a connection establishment and short message sending procedure. During the short message mobile terminating procedure, the BSC sends the MS an Establishment Request message, requesting for connection establishment. If the BSC
19-4
Issue 01 (2008-06-10)
19 Short Messages
receives an Establishment Confirm message from the MS, the channel for SMS is established. The BSC transfers short messages on the transparent channel until the procedure is complete.
19.1.3 Short Message Sending Procedure of a Busy MS

This describes the short message sending procedure initiated by a busy MS. Figure 19-3 shows the short message sending procedure initiated by a busy MS. Figure 19-3 Short message sending procedure of a busy MS
MS BTS BSC MSC
ACTIVE CALL
CM Service Request(1)
FACCH
CM Service Accepted(2)
FACCH
SABM (SAPI 3)(3) Establish Indication(4)
FACCH
UA(5)
FACCH
CP DATA(6)
SACCH
CP Acknowledge(7)
SACCH
CP DATA(8)
SACCH SACCH
CP Acknowledge(9)
ACTIVE CALL
The short message sending procedure initiated by a busy MS is described as follows: 1. 2. The MS sends the MSC a CM Service Request message on the FACCH. If the MSC responds with a CM Service Accepted message, a link at the CC layer is established. A link at the CC layer is established on the SACCH for sending short messages.
19.1.4 Short Message Receiving Procedure of a Busy MS

This describes the short message receiving procedure initiated by a busy MS. Figure 19-4 shows the short message receiving procedure initiated by a busy MS.
19 Short Messages
Figure 19-4 Short message receiving procedure of a busy MS

MS BTS BSC MSC
ACTIVE CALL Establish Request(SAPI 3)(2) SABM (SAPI 3)(3) FACCH UA(4) FACCH Establish Confirm (SAPI 3)(5) CP DATA(6) SACCH SACCH SACCH SACCH ACTIVE CALL CP Acknowledge(7) CP DATA(8) CP Acknowledge(9) CP DATA(1)
The short message receiving procedure initiated by a busy MS is described as follows: 1. 2. Upon receiving a CP DATA message from the MSC, the BSC establishes a link for receiving short messages at the RR layer. Upon receiving a CP Acknowledge message from the MS, the MSC sends short messages.
19.2 Internal BSC Signaling Procedure (Short Messages)

This describes the internal BSC signaling procedure of short messages transfer. 1. 2. Based on the classmark reported by the MS, the BSC records whether the MS supports SMS. Upon receiving short messages from the MS, the BSC checks the Short message uplink disabled parameter by choosing Cell Attributes > Call Control > Advanced > Call Control. If the parameter is set to Yes, short messages cannot be sent. Upon receiving short messages from the MSC, the BSC checks the Short message uplink disabled parameter by choosing Cell Attributes > Call Control > Advanced > Call Control. If the parameter is set to Yes, short messages cannot be sent.
3.
19-6
Issue 01 (2008-06-10)
19 Short Messages
19.3 Abnormal Cases and Handling Suggestions (Short Messages)

This describes the abnormal cases of short messages, probable causes, and handling suggestions. 19.3.1 Short Message Sending Failure Caused by Disabled Authentication and Ciphering (Case Study) This describes the fault, probable causes, and handling suggestions.
19.3.1 Short Message Sending Failure Caused by Disabled Authentication and Ciphering (Case Study)
Description
Some MSs fail to send short messages because the authentication and ciphering function is disabled.
Analysis
The short message procedure specified in the GSM protocols involves the authentication and ciphering procedure. For some MSs, short message sending fails if no authentication and ciphering procedure is involved in the short message procedure.
Initiates an authentication and ciphering procedure on the MSC side.
Issue 01 (2008-06-10)
19-7
20 Cell Broadcast Messages
20
About This Chapter
Cell Broadcast Messages
The short message service cell broadcast (SMSCB) is similar to the paging station broadcast service. The operators broadcast messages to the subscribers in the specified areas. The subscribers that subscribe to the service receive the messages broadcast by the operators. 20.1 Cell Broadcast Message Procedures The cell broadcast procedure comprises the CBC-BSC message procedure and the BSC-BTS message procedure. 20.2 Internal BSC Signaling Procedure (Cell Broadcast Messages) This describes the internal BSC signaling procedure of the SMSCB. 20.3 Abnormal Cases and Handling Suggestions (Cell Broadcast Messages) This describes the abnormal cases of cell broadcast messages, probable causes, and handling suggestions.
Issue 01 (2008-06-10)
20-1
20.1 Cell Broadcast Message Procedures

The cell broadcast procedure comprises the CBC-BSC message procedure and the BSC-BTS message procedure. 20.1.1 CBS-BSC Message Procedure This describes the CBC-BSC message procedure. 20.1.2 BSC-BTS Message Procedure This describes the BSC-BTS message procedure.
20.1.1 CBS-BSC Message Procedure

This describes the CBC-BSC message procedure.
Procedure for Sending or Replacing a Message

Figure 20-1 shows the procedure for sending or replacing a message. Figure 20-1 Procedure for sending or replacing a message
CBC BSC
Write Replace Request(1)
Report Response(2)
The previous procedure is described as follows: 1. The BSC receives a Write Replace Request message sent by the CBC.
l l
If the message is new, the BSC saves the message in the message library. If the message is sent for replacing the existing message, the BSC deletes the existing message and saves the new message in the message library. If the parameters in the Write Replace Request message are legal, the BSC sends the CBC a Report Response message. If the parameters in the Write Replace Request message are illegal, the BSC sends the CBC a Reject Response message.
2.
The BSC sends the CBC a response message.

l
Deleting an Existing Message

Figure 20-2 shows the procedure for deleting an existing message.
Figure 20-2 Procedure for deleting an existing message

CBC BSC
Kill Request(1)
Report Response(2)
The previous procedure is described as follows: 1. 2. The CBC sends a Kill Request message to the BSC. The BSC sends a response message to the CBC.
l
If the parameters in the Kill Request message are legal, the BSC deletes the existing message and sends a Report Response message to the CBC. If the parameters in the Kill Request message are illegal, the BSC sends a Reject Response message to the CBC.
Querying the CBCH Status

Figure 20-3 shows the procedure for querying the CBCH status. Figure 20-3 Procedure for querying the CBCH status
CBC BSC
Status CBCH Query Request(1)
Status CBCH Query Response(2)
The previous procedure is described as follows: 1. 2. The CBC sends the BSC a Status CBCH Query Request message. The BSC sends the CBC a response message.
l
If the parameters in the Status CBCH Query Request message are legal, the BSC sends the CBC a Status CBCH Query Response message. If the parameters in the Status CBCH Query Request message are illegal, the BSC sends the CBC a Reject Response message.
Issue 01 (2008-06-10)
Querying the Message Status

Figure 20-4 shows the procedure for querying the message status. Figure 20-4 Procedure for querying the message status
CBC BSC
Status Message Query Request(1)
Status Message Query Response(2)
The previous procedure is described as follows: 1. 2. The CBC sends the BSC a Status Message Query Request message. The BSC sends the CBC a response message.
l
If the parameters in the Status Message Query Request message are legal, the BSC sends the CBC a Status Message Query Response message. If the parameters in the Status Message Query Request message are illegal, the BSC sends the CBC a Reject Response message.
Resetting a Cell
Figure 20-5 shows the procedure for resetting a cell. Figure 20-5 Procedure for resetting a cell
CBC BSC
Reset Request(1)
Restart Indication Response(2)
The previous procedure is described as follows: 1. 2. The CBC sends a Reset Request message to the the BSC. The BSC sends a response message to the CBC.
l
If the CBCH of the specified cell is normal before the cell is reset, the BSC sends the CBC a Restart Indication Response message.
20-4

l
If the CBCH of the specified cell is abnormal (for example, a cell is faulty or not installed, or the CBCH is blocked), the BSC sends the CBC a Failure Indication Response message.
Setting the DRX

Figure 20-6 shows the procedure for setting the discontinuous reception (DRX). Figure 20-6 Procedure for setting the DRX
CBC BSC
Set DRX Request(1)
Set DRX Response(2)
The previous procedure is described as follows: 1. 2. The CBC sends the BSC a Set DRX Request message. The BSC sends the CBC a response message.
l
If the parameters in the Set DRX Request message are legal, the BSC sends a Set DRX Response message to the CBC. If the parameters in the Set DRX Request message are illegal, the BSC sends a Reject Response message to the CBC.
20.1.2 BSC-BTS Message Procedure

This describes the BSC-BTS message procedure. WW The BSC sends the Cell Broadcast Services (CBS) information to the BTS through an SMS Broadcast Command message and specifies the channels to be used by the BTS, as shown in Figure 20-7.
Issue 01 (2008-06-10)
20-5
Figure 20-7 BSC sending an SMS broadcast command message

BSC
SMS Broadcast Command
BTS
MS
SMS 1(1)
CBCH
SMS 2(2)
CBCH
SMS n(3)
CBCH
The BTS reports the load status of the CBCH to the BSC through a CBCH Loading Indication message and requests the BSC to perform flow control, as shown in Figure 20-8. Figure 20-8 BTS sending the BSC a CBCH Loading Indication message
BSC CBCH Loading Indication(1) BTS
20.2 Internal BSC Signaling Procedure (Cell Broadcast Messages)

This describes the internal BSC signaling procedure of the SMSCB. The internal BSC signaling procedure for cell broadcast messages is described as follows: 1. 2. 3. 4. The cell broadcast function can operate only on the CPUP in the basic frame. When the BSC6000 cell broadcast system operates, the CPU3 obtains the IP address of the CBC from the database and then establishes the communication with the CBC. The CPU3 obtains the cell information from the database, filters the cells without CBCHs, and writes in the cell information library the information about the cells with CBCHs . The CPU3 obtains the contents of short messages to be broadcast from the CBC and writes the contents in the message library. The contents include the number of retransmissions and the interval of retransmissions. The GXPUM receives the messages sent from the CBC to the BSC, and the CPU3 processes the messages. After the broadcast message sending timer expires, the CPU3 checks every cell for messages to be broadcast.
5. 6.
20-6

l
If there are messages to be broadcast, the CPU3 sends the messages to the corresponding GXPUM, and the GEHUB forwards the messages to the corresponding BTS. If there are no messages to be broadcast, no processing is required.
NOTE
The delivery of the cell broadcast messages is triggered by the expiry of SMSCB timer.
Figure 20-9 SMSCB procedure

G X P U M G S C U G E H U B
GMPS
GEPS
G S C U
G E H U B
20.3 Abnormal Cases and Handling Suggestions (Cell Broadcast Messages)

This describes the abnormal cases of cell broadcast messages, probable causes, and handling suggestions. 20.3.1 MS Failure to Receive Broadcast Messages (Case Study) This describes the fault, probable causes, and handling suggestions. 20.3.2 Cell Not Configured with CBCH (Case Study) This describes the fault, probable causes, and handling suggestions.
20.3.1 MS Failure to Receive Broadcast Messages (Case Study)

Description
The MS fails to receive call broadcast messages.
Analysis
The probable causes are as follows: 1. 2.
Issue 01 (2008-06-10)
The cell broadcast receive switch of the MS is not turned on and the corresponding channel numbers are not set. The setting of the IP address in the GXPUM and that in the CBC are different.
3.
The communication between the GXPUM and the CBC is disrupted. If any alarm is generated, refer to 102 Disrupted Connection with the CBC
Locate the problem through the message tracing function and the site maintenance function and handle it as follows: 1. 2. Check whether SMS Broadcast Command messages exist on the Abis interface of the relevant cell. Send a system message in the cell through the site maintenance function and check whether the IE CBCH DESP message in System Information Type 4 is correct through interface tracing.
20.3.2 Cell Not Configured with CBCH (Case Study)

Description
l l l l
The cell is abnormal. The CBC cannot perform any operation or the operation fails. Cell broadcast messages cannot be sent. The MS does not receive any cell broadcast message.
Analysis
The cause value of the failed signaling is Specified Cell Not Found. The problem lies in that the CBCH of the cell is not configured.
Ensure that the CBCH of a cell is configured. If the CBCH of a cell is not configured, add the CBCH through the BSC6000 Local Maintenance Terminal.
20-8
Issue 01 (2008-06-10)
21 GPRS
21
About This Chapter
GPRS
This describes the procedure related to PS services, the internal processing procedure, the exceptional procedure, and the handling suggestions. 21.1 GPRS Procedure This describes the GPRS procedure. The GPRS procedure consists of TBF related procedure, PDP context related procedure, circuit paging procedure, packet paging procedure, and procedure of suspending and resuming GPRS services. 21.2 Internal BSC Signaling Procedures This describes the internal BSC signaling procedures of the circuit paging and packet paging initiated by the packet domain in the case of built-in PCU. 21.3 Abnormal Cases and Handling Suggestions (GPRS) This describes the abnormal GPRS cases, probable causes, and handling suggestions.
Issue 01 (2008-06-10)
21-1
21 GPRS
21.1 GPRS Procedure

This describes the GPRS procedure. The GPRS procedure consists of TBF related procedure, PDP context related procedure, circuit paging procedure, packet paging procedure, and procedure of suspending and resuming GPRS services. 21.1.1 Uplink TBF Establishment Procedure (CCCH Phase One Access) This describes the uplink TBF establishment procedure (CCCH phase one access). 21.1.2 Uplink TBF Establishment Procedure (CCCH Phase Two Access) This describes the uplink TBF establishment procedure (CCCH phase two access). 21.1.3 Uplink TBF Establishment Procedure (PACCH Access) This describes the uplink TBF establishment procedure (PACCH access). 21.1.4 Uplink TBF Release Procedure This describes the uplink TBF release procedure. 21.1.5 Downlink TBF Establishment Procedure (CCCH) This describes the downlink TBF establishment procedure (CCCH). 21.1.6 Downlink TBF Establishment Procedure (PACCH) This describes the downlink TBF establishment procedure (PACCH). 21.1.7 Downlink TBF Release Procedure This describes the downlink TBF release procedure. 21.1.8 GPRS Attach Procedure This describes the GPRS attach procedure. 21.1.9 GPRS Detach Procedure This describes the GPRS detach procedure. 21.1.10 Routing Area Update Procedure This describes the routing area update procedure. 21.1.11 PDP Context Activation Procedure This describes the PDP context activation procedure. 21.1.12 PDP Context Deactivation Procedure This describes the PDP context deactivation procedure. 21.1.13 PDP Context Modification Procedure This describes the PDP context modification procedure. 21.1.14 Circuit Paging Procedure This describes the circuit paging procedure that is initiated through the SGSN. 21.1.15 Packet Paging Procedure This describes the packet paging procedure. 21.1.16 GPRS Suspension and Resumption Procedure This describes the GPRS suspension and resumption procedure.
21-2
Issue 01 (2008-06-10)
21 GPRS
21.1.1 Uplink TBF Establishment Procedure (CCCH Phase One Access)

This describes the uplink TBF establishment procedure (CCCH phase one access). Figure 21-1 shows the uplink TBF establishment procedure (CCCH phase one access). Figure 21-1 Uplink TBF establishment procedure (CCCH phase one access)
MS Channel request(1) Immediate assignment(4) RLC data block (with TLLI)(5) Packet Uplink Ack/Nack (with TLLI)(6) RLC data block (without TLLI)(7) BTS BSC CHAN_REQ(2) IMM_ASS_CMD(3) PCU
...
RLC data block (without TLLI)(8)
Packet Uplink Ack/Nack (without TLLI)(9) RLC data block (without TLLI)(10)
The previous procedure is described as follows: 1. 2. The MS sends a packet channel request from the RACH of the CCCH and the BSC sends the request to the PCU. The PCU sends on the AGCH an Immediate assignment message to the MS through the BSC. The packet uplink immediate assignment message contains an assigned uplink channel and also the TFI and USF of the TBF. The BSS sets the USF on the assigned uplink packet channel, and then the MS sends the uplink RLC data block. After the BSS receives the data block that contains the TLLI of the MS, the BSS responds with Packet Uplink ACK/NACK message that contains the TLLI to solve conflicts. After conflicts are solved, the uplink RLC data block sent by the MS does not contain the TLLI. Each time when the BSS receives 32 RLC data blocks or S1 in the received uplink RLC data blocks is 1, the Packet Uplink Ack/Nack message is displayed to acknowledge the received uplink RLC data blocks.
...
3.
4.
Issue 01 (2008-06-10)
21-3
21 GPRS
21.1.2 Uplink TBF Establishment Procedure (CCCH Phase Two Access)

This describes the uplink TBF establishment procedure (CCCH phase two access). Figure 21-2 shows the uplink TBF establishment procedure (CCCH phase two access). Figure 21-2 Uplink TBF establishment procedure (CCCH phase two access)
MS Channel request(1) CHAN_REQ(2) Immediate assignment(4) Packet Resource Request(with TLLI)(5) Packet Uplink Assignment(with TLLI)(6) RLC data block (without TLLI)(7) IMM_ASS_CMD(3) BTS BSC PCU
...
RLC data block (without TLLI)(8)
Packet Uplink Ack/Nack (without TLLI)(9) RLC data block (without TLLI)(10)
The differences between the uplink TBF establishment procedure (CCCH phase one access) and the uplink TBF establishment procedure (CCCH phase two access) are as follows: 1. 2. 3. The BSS assigns an uplink data block in the packet uplink immediate assignment message. The MS sends on the assigned uplink data block a packet resource request message that contains the TLLI. The BSS allocates uplink channels according to the packet resource request message. The BSS sends a Packet Uplink Assignment (with TLLI) message on the packet channel in which the MS sends the packet resource request message to solve conflicts. The BSS set the USF on the assigned uplink packet channel, and then the MS sends the uplink RLC data block that does not contain the TLLI. The following procedures are the same as the procedures listed in CCCH phase one access.
...
4. 5.
21.1.3 Uplink TBF Establishment Procedure (PACCH Access)

This describes the uplink TBF establishment procedure (PACCH access). Figure 21-3 shows the uplink TBF establishment procedure (PACCH access).
21 GPRS
Figure 21-3 Uplink TBF establishment procedure (PACCH access)

MS BTS BSC RLC data block(1) PCU
...
RLC data block(2) RLC data block(S/P=1)(3) Packet Downlink Ack/Nack (with Channel Request Description)(4) Packet Uplink Assignment(with TLLI)(5) RLC data block(6)
The previous procedure is described as follows: 1. During the transmission of the downlink TBF, if the MS needs to send uplink data, the Channel Request Description is added to the Packet Downlink Ack/Nack message. The BSS sends on the PACCH of the downlink TBF the packet uplink assignment message that is marked by the TLLI of the MS. Establishing the transmission channel of the uplink TBF during the transmission of the downlink TBF does not have conflicts. The BSS set the USF on the assigned uplink packet channel, and then the MS sends the uplink RLC data block that does not contain the TLLI.
...
2.
21.1.4 Uplink TBF Release Procedure

This describes the uplink TBF release procedure. Figure 21-4 shows the uplink TBF release procedure.
Issue 01 (2008-06-10)
21-5
21 GPRS
Figure 21-4 Uplink TBF release procedure

MS RLC data block(CV=0)(1) Packet Uplink Ack/Nack(FAI=1)(2) BTS BSC PCU
Packet Control Ack(AB or NB)(3)
The previous procedure is described as follows: 1. The MS sets the Countdown Value (CV) to 0 in the last uplink RLC data block. After the BSS receives all the RLC data blocks, the BSS responds with the Packet Uplink ACK/ NACK message in which the Final ACK Indication (FAI) is set to 1. The MS receives the Packet Uplink ACK/NACK message and then sends the Packet Control ACK message to release the uplink TBF.
2.
21.1.5 Downlink TBF Establishment Procedure (CCCH)

This describes the downlink TBF establishment procedure (CCCH). Figure 21-5 shows the downlink TBF establishment procedure (CCCH).
21-6
Issue 01 (2008-06-10)
21 GPRS
Figure 21-5 Downlink TBF establishment procedure (CCCH).

MS BTS BSC IMM ASS CMD(1) PCU
Immediate Assignment(2)
Packet Polling Request(with TFI)(3) Packet Control Ack(AB)(4) Packet Power Control/ Timing Advance(5) Packet Downlink Assignment(6) RLC data block(7)
...
RLC data block(S/ P=1)(8)
Packet Downlink Ack/Nack(9) RLC data block(10)
The previous procedure is described as follows: 1. The PCU receives the downlink PDU from the SGSN and then delivers a downlink immediate assignment message on the CCCH through the BSC. The message contains a downlink packet channel and the start time of the TFI and the TBF. When the downlink TBF starts, the BSS sends on the PACCH of the downlink TBF the Packet Polling Request message that is marked by the TFI. The MS responds with a packet control acknowledgment message of the ACCESS BURST type. The BSS extracts the time advance from AB, notifies the MS through the Packet Power Control/Timing Advance message, and sends the packet downlink assignment message to allocate multiple channels to the MS. If the channels that are allocated to the MS in the immediate assignment message does not meet the multislot capability of the MS, the PCU actively initiates the reassignment procedure. The BSS cuts the downlink PDU into downlink RLC data blocks and sends these blocks to the MS through the allocated downlink packet channel. Each time the BSS sends 20 downlink RLC data blocks, the BSS sets the RRBP in downlink RLC data blocks. The MS sends a Packet Downlink Ack/Nack message to acknowledge the downlink RLC data blocks.
...
2.
3.
4.
Issue 01 (2008-06-10)
21-7
21 GPRS
21.1.6 Downlink TBF Establishment Procedure (PACCH)

This describes the downlink TBF establishment procedure (PACCH). The downlink TBF establishment procedure (PACCH) consists of the downlink TBF establishment on the uplink PACCH and the downlink TBF establishment on the downlink PACCH.
Downlink TBF Establishment Procedure on the Uplink PACCH

Figure 21-6 shows the downlink TBF establishment procedure on the uplink PACCH. Figure 21-6 Downlink TBF establishment procedure on the uplink PACCH
MS RLC data block(1) RLC data block(2) BTS BSC PCU
...
RLC data block(3) Packet Downlink Assignment (Uplink TFI, S/P=1)(4) Packet Control Acknowledgement (AB or NB)(5) RLC data block(6) RLC data block(7)
The previous procedure is described as follows: 1. During the uplink TBF transmission, the PCU receives the downlink LLC PDU from the SGSN and directly sends on the PACCH of the uplink TBF the packet downlink assignment message that is marked with the TFI of the uplink TBF. The RRBP is set in the message. The MS responds with a packet control acknowledgment message at a position specified by the RRBP. Whether the type of the packet control acknowledgment message is AB or NB is determined by SI13. The BSS receives the packet control acknowledgment message, notifying that the downlink TBF is successfully established and the downlink RLC data block can be sent.
2.
3.
Downlink TBF Establishment Procedure on the Downlink PACCH

After the downlink TBF is normally released, the MS continues to monitor the packet channel of the downlink TBF within the duration of timer T3192 (duration is determined by SI13). Figure 21-7 shows the downlink TBF establishment procedure on the downlink PACCH.
21 GPRS
Figure 21-7 Downlink TBF establishment procedure on the downlink PACCH

MS BTS BSC RLC data block(1) RLC data block(2) PCU
...
RLC data block (FBI=1, S/P=1)(3)
Packet Downlink Ack/Nack(FAI=1)(4) Start T3192 Packet Downlink Assignment(with Downlink TFI)(5) Packet Control Acknowledgement (AB or NB)(6) Stop T3192 RLC data block(7) RLC data block(8) Start T3193
Stop T3193
The previous procedure is described as follows: 1. After the downlink TBF is normally released, the PCU receives the downlink PDU from the SGSN before timer T3193 expires. The BSS sends on the PACCH of the original downlink TBF the packet downlink assignment message that is marked by the TFI of the original downlink TBF. The RRBP is set in the message.
NOTE
T3193 is the timer on the BSS side. The duration of timer T3193 is shorter than the duration of timer T3192 for the MS.
2.
The MS responds with a packet control acknowledgment message at a position specified by the RRBP. Whether the type of the packet control acknowledgment message is AB or NB is determined by SI13. The BSS receives the packet control acknowledgment message, notifying that the downlink TBF is successfully established and the downlink RLC data block can be sent. If timer T3193 has expired when the downlink PCU arrives, the BSS establishes the downlink TBF on the CCCH. For the detailed procedure, see 21.1.5 Downlink TBF Establishment Procedure (CCCH).
3. 4.
21.1.7 Downlink TBF Release Procedure

This describes the downlink TBF release procedure. Figure 21-8 shows the downlink TBF release procedure.
Issue 01 (2008-06-10)
21-9
21 GPRS
Figure 21-8 Downlink TBF release procedure

MS BTS BSC PCU
RLC Data Block(FBI=1,S/P=1)(1)
Packet Downlink Ack/Nack(FAI=1)(2)
The previous procedure is described as follows: 1. The BSS set the Final Block Indicator (FBI) to 1 in the last downlink RLC data block. If the MS has collected all the downlink RLC data blocks, the Packet Downlink Ack/Nack message with FAI as 1 is sent. Otherwise, the Packet Downlink Ack/Nack with FAI as 0 is sent to ask the BSS to resend unreceived data blocks. The downlink TBF is complete after the BSS receives the Packet Downlink Ack/Nack message in which FAI is set to 1.
2.
21.1.8 GPRS Attach Procedure

This describes the GPRS attach procedure.
GPRS Attach Function

After the MS completes the GPRS attach procedure, the MS is in the READY status and the MM context of the MS is established between the MS and the SGSN. Hereafter, the MS activates the PDP context through the activation procedure of the PDP context.
l
If the network operation mode is I and the MS is attached to the GPRS, IMSI attach can be achieved through the combined RA/LA update procedure. If the network operation mode is II or III, or the MS is not attached to the GPRS, IMSI attach is achieved according to the IMSI attach procedure in GSM specifications.
GPRS Attach Procedure

In the GPRS attach procedure, the MS informs the network of its attach type and identity. If the MS has a valid P-TMSI, P-TMSI and then IMSI are used to recognize the identity of the MS.
NOTE
There are three attach types, that is, IMSI attach, GPRS attach, and unified IMSI/GPRS attach.
An MS of Class C must be in the GPRS detach status before performing IMSI attach and in the IMSI detached status before performing GPRS attach. A pure GPRS attach procedure is simple. Figure 21-9 shows the GPRS attach procedure by taking the combination of GPRS/IMSI attach as an example.
21 GPRS
Figure 21-9 Combined GPRS/IMSI attach procedure

MS BSS SGSN(new) SGSN(old) GGSN EIR MSC/VLR(new) HLR MSC/VLR(old)
Attach Request(1)
Identification Request(2) Identity Request(4) Identity Response(5) Identification Response(3)
Authentication(6) IMEI Check(7) Update Location(8) Cancel Location(9) Insert Subscriber Data(11) Insert Subscriber Data Ack(12) Update Location Ack(13) Location Update Request(14) Update Location(15) Cancel Location Ack(10)
Cancel Location(16) Cancel Location Ack(17)
Insert Subscriber Data(18) Insert Subscriber Data Ack(19) Attach Accept(22) Attach Complete(23) Location Update Accept(21) TMSI Reallocation Complete(24) Update Location Ack(20)
The previous procedure is described as follows: 1. If the identity of an MS is P-TMSI and moreover the SGSN where the MS resides has changed after the MS detaches GPRS, the new SGSN requests the IMSI of the MS from the old SGSN. The new SGSN sends an Identification Request message to the old SGSN and requires the response from the old SGSN. If the old SGSN does not successfully respond, the new SGSN asks the MS to report its IMSI. After the SGSN sends the Identity Request message to the MS, the SGSN requires the response from the MS.
l l
2.
3.
If the MML context of the MS is not available on the network, this process is mandatory. In other cases, this process is optional.
4.
Authentication and IMEI identity check are optional.
Issue 01 (2008-06-10)
21-11
21 GPRS
5.
the SGSN where the MS resides has changed after detaching GPRS or the MS is attached for the first time, the SGSN needs to notify the HL of the location update of the MS. The HLR needs to send the data subscribed by the MS to the SGSN. If the attach type indicated by step 1 is GPRS attach with the precondition of IMSI attach, or combined GPRS/IMSI attach. In addition, the SGSN and the VLR support the Gs interface, the SGSN needs to initiate location update towards the MSC/VLR (new) so that association between the SGSN and the MSC/VLR is maintained. Steps 15 through 20 refer to inter-MSC location update. If P-TMSI/TMSI has changed, the MS checks whether it has receives the TMSI. If TMSI has changed, the SGSN checks with the VLR whether the MS receives the new TMSI.
6.
7. 8.
21.1.9 GPRS Detach Procedure

This describes the GPRS detach procedure.
GPRS Detach Function

Through the GPRS detach procedure, an MS disconnects the GPRS/GSM network. After the MS is detached from the GPRS network, the MS enters the MM IDLE state. Detach types consist of:
l l l
IMSI detach GPRS detach Combined IMSI/GPRS detach

NOTE
Currently, only the combined IMSI/GPRS detach initiated by the MS is supported.
The GPRS detach of an MS can use explicit detach and implicit detach.
l
Explicit detach means that an MS or a SGSN sends a detach request, asking for GPRS detach. Implicit detach means that detach is caused by the expiration of a ready timer, or an irrecoverable error on a radio link if a logical link is available.
The way of implementing the IMSI detach of an MS varies with whether GPRS attach is available.
l
The MS that is attached to the GPRS can initiate IMSI detach through the SGSN and besides. In addition, the MS can detach the IMSI when detaching from the GPRS network. The MS that is not attached to the GPRS can detach the IMSI by using the same detach procedure as the GSM IMSI detach procedure.
The GPRS detach procedure is generally initiated by the MS. The network can also initiate the GPRS detach procedure.
GPRS Detach Procedure

The following part illustrates the detach procedure initiated by different NEs.
l
MS initiating detach Figure 21-10 shows the detach procedure initiated by the MS.
21-12
Issue 01 (2008-06-10)
21 GPRS
Figure 21-10 MS initiating the GPRS detach procedure

MS Detach Request(1) BSS SGSN GGSN MSC/VLR
Delete PDP Context Request(2) Delete PDP Context Response(3) IMSI Detach Indication(4)
Detach Accept(6)
GPRS Detach Indication(5)
The previous procedure is described as follows: 1. 2. The MS sends a Detach Request message to the SGSN. The message contains the detach type and disconnection. For GPRS detach, after the SGSN receives the Detach Request message, the SGSN sends a Delete PDP Context Request to the GGSN. The GGSN responds to the SGSN with a Delete PDP Context Response message. For IMSI detach, the SGSN sends an IMSI Detach Indication message to the MSC/ VLR. For GPRS detach, the SGSN sends a GPRS Detach Indication message to the MSC/ VLR. The SGSN sends detach acknowledgment to the MS.
3. 4. 5.
l
SGSN initiating detach Figure 21-11 shows the detach procedure initiated by the SGSN.
Figure 21-11 SGSN initiating the GPRS detach procedure

MS Detach Request(1) BSS SGSN Delete PDP Context Request(2) Delete PDP Context Response(3) Detach Accept(5) GGSN MSC/VLR
The previous procedure is described as follows:

21 GPRS
1. 2. 3. 4.
l
The SGSN sends a Detach Request message to the MS. The message contains the detach type. The SGSN sends a Delete PDP Context Request message to the GGSN. Then, the GGSN responds to the SGSN with a Delete PDP Context Response message. The SGSN sends a GPRS Detach Indication message to the MSC/VLR. The MS sends a Detach Accept message to the SGSN.
HLR initiating detach procedure To fulfill the demand of the telecom operator, the HLR can request the deletion of MM and PDP context of a user from the SGSN. Figure 21-12 shows the detach procedure initiated by the HLR.
Figure 21-12 HLR initiating the GPRS detach procedure

MS Detach Request(2) BSS SGSN Cancel Location(1) Delete PDP Context Request(3) Delete PDP Context Response(4) Detach Accept(6) Cancel Location Ack(7) GGSN HLR MSC/VLR
The previous procedure is described as follows: 1. 2. 3. 4. 5. 6. The HLR sends a Cancel Location message to the SGSN. The message contains the IMSI and the cancellation type. After receiving the Cancel Location message, the SGSN sends the MS a Detach Request message that contains the detach type. The SGSN sends a Delete PDP Context Request message to the GGSN. The GGSN responds to the SGSN with a Delete PDP Context Response message. The SGSN sends a GPRS Detach Indication message to the MSC/VLR. The MS sends a Detach Accept message to the SGSN. The SGSN sends a Cancel Location Ack message to the HLR.
21.1.10 Routing Area Update Procedure

This describes the routing area update procedure. When an MS in the GPRS attach state enters a new routing area, or the timer of periodic routing area update for the MS expires, the MS initiates the routing area update procedure. The SGSN checks whether the message requesting the routing area update carries the identification of the old routing area to decide the execution of the routing area update procedure within the SGSN, or the routing area update procedure between SGSNs. The periodic routing area update procedure is always initiated within the SGSN.
21 GPRS
Intra-SGSN Routing Area Update

Figure 21-13 shows the intra-SGSN routing area update procedure. Figure 21-13 Intra-SGSN routing area update procedure
MS Routing Area Update Request(1) Security Functions(2) Routing Area Update Accept(3) Routing Area Update Complete(4) BSS SGSN
The previous procedure is described as follows: 1. The MS sends a Routing Area Update Request message to the SGSN. The message contains the original RAI, original P-TMSI signature, and update type. The BSS adds the CGI of RAN and LAC to the message. Starting the security functions is optional. The SGSN updates the MM context of the MS and allocates a new P-TMSI when necessary. Then, the SGSN responds to the MS with a Routing Area Update Accept message. This message contains the signature of P-TMSI and P-TMSI. If a new P-TMSI is assigned, the MS displays a Routing Area Update Complete message. This message contains P-TMSI.
NOTE
2. 3.
4.
If the routing area update procedure is unsuccessful and the number of failures exceeds the maximum allowed times, or the SGSN displays a Routing Area Update Reject message, then the MS enters the IDLE state.
Inter-SGSN Routing Area Update

Figure 21-14 shows the inter-SGSN routing area update procedure.
Issue 01 (2008-06-10)
21-15
21 GPRS
Figure 21-14 Inter-SGSN routing area update procedure

MS BSS new SGSN old SGSN GGSN HLR
Routeing Area Update Request(1)
SGSN Context Request(2) SGSN Context Response(3) SGSN Context Acknowledge(5) Forward Packets(6) Update PDP Context Request(7) Update PDP Context Response(8) Update Location(9) Cancel Location(10) Insert Subscriber Data(12) Insert Subscriber Data Ack(13) Update Location Ack(14) Cancel Location Ack(11)
Security Functions(4)
Routeing Area Update Accept(15) Routeing Area Update Complete(16)
The previous procedure is described as follows: 1. The MS sends a Routing Area Update Request message to a new SGSN. The message contains the original RAI, original P-TMSI signature, and update type. The BSS adds the CGI of RAN and LAC to the message. The new SGSN sends a SGSN Context Request message to the old SGSN so that the MM context and PDP context of the MS are obtained. This message contains the original RAI, TLLI, original P-TMSI signature, and new SGSN address. Perform the encryption function, optional. The new SGSN responds to the old SGSN with a SGSN Context Acknowledge message. After the old SGSN receives the SGSN Context Acknowledge message, the old SGSN labels information such as the MSC/VLR associated information in the MS context as invalid. If the previous authentication does not pass, the new SGSN should reject the routing area update request initiated by the MS, and the old SGSN operates as before. After receiving the SGSN Context Acknowledge message from the new SGSN, the old SGSN forwards the related N-PDU to the new SGSN within a certain period.
2.
3. 4.
5.
21-16
21 GPRS
6.
The new SGSN sends an Update PDP Context Request message to the GGSN. This message contains the new SGSN address, TID, and negotiated QoS. The GGSN responds to the new SGSN with an Update PDP Context Response message that contains TID. The new SGSN sends an Update Location message to the HLR. This message contains the SGSN numbering, SGSN address, and IMSI. The HLR sends a Cancel Location message to the old SGSN. This message contains the TMSI and the cancellation type. The old SGSN deletes corresponding MM and PDP contexts and then responds to the HLR with a Cancel Location Ack message that contains the IMSI. The HLR sends an Insert Subscriber Data to the new SGSN. This message contains IMSI and GPRS subscription data. The new SGSN creates a corresponding MM context and then responds to the HLR with an Insert Subscriber Data Ack message that contains IMSI.
7. 8.
9.
10. The HLR responds to the SGSN with an Update Location Ack message that contains IMSI. 11. The new SGSN re-establishes the MM context and the PDP context of the MS to allocate a new P-TMSI to the MS. The new SGSN sends a Routing Area Update Accept message to the MS. This message contains P-TMSI, LLC acknowledgment, and P-TMSI signature. 12. The MS responds to the SGSN with a Routing Area Update Complete message that contains P-TMSI and LLC.
21.1.11 PDP Context Activation Procedure

This describes the PDP context activation procedure. The PDP context activation procedure is classified into two types: MS-requested PDP context activation procedure and network-requested PDP context activation procedure.
MS-Requested PDP Context Activation Procedure

Figure 21-15 shows the MS-requested PDP context activation procedure. Figure 21-15 MS-requested PDP context activation procedure
MS Activate PDP Context Request(1) Security Functions(2) Create PDP Context Request(3) Create PDP Context Response(4) SGSN GGSN
Activate PDP Context Accept(5)
The previous procedure is described as follows: 1. 2.

Issue 01 (2008-06-10)
The MS sends an Activate PDP Context Request (NSAPI, TI, PDP Type, APN, Qos Requested, PDP Configuration Options) message to the SGSN. Security functions may be executed.
21 GPRS
3.
The SGSN tries to derive the GGSN address by using the APN selection criteria based on the activation type, PDP address, and APN provided by the MS, and then checks whether the request is valid.
l
If no GGSN address can be derived or if the SGSN has determined that the Activate PDP Context Request is not valid, the SGSN rejects the PDP context activation request. If a GGSN address can be derived, the SGSN creates a TID for the requested PDP context by combining the IMSI with the NSAPI, and sends a Create PDP Context Request (PDP Type, PDP Address, APN, Qos Negotiated, Selection Mode, PDP Configuration Options) message to the GGSN.
4.
Based on the information provided by the SGSN, the GGSN determines the external PDN, allocates dynamic addresses, starts charging, and limits the QoS.
l
If the Qos Negotiated is met, the GGSN sends a Create PDP Context Response (TID, PDP Address, BB protocol, re-sequencing request, PDP Configuration Options, Qos Negotiated, Charging Id, Cause) message to the SGSN. If the negotiated QoS is not met, the GGSN sends a reject message to the SGSN. The QoS profiles are configured by the GGSN operator.
5.
After receiving the Create PDP Context message from the GGSN, the SGSN inserts the NSAPI, GGSN address, and dynamic PDP address into the PDP context, selects Radio Priority based on Qos Negotiated, and then returns an Activate PDP Context Accept (PDP Type, PDP Address, TI, Qos Negotiated, Radio Priority, PDP Configuration Options) message to the MS. The SGSN is now able to route PDP PDUs between the GGSN and the MS, and to start charging.
Network-Requested PDP Context Activation Procedure

Figure 21-16 shows the network-requested PDP context activation procedure. Figure 21-16 Network-requested PDP context activation procedure
MS SGSN HLR GGSN PDP PDU(1) Send Routeing Info for GPRS(2) Send Routeing Info for GPRS Ack(3)
PDU Notification Request(4) Request PDP Context Activation(6) PDU Notification Response(5) PDP Context Activation procedure(7)
The previous procedure is described as follows: 1. After receiving a PDP PDU from the external PDN, the GGSN stores the PDP PDU and sends a Send Routeing Info for GPRS (IMSI) message to the HLR.
21-18
21 GPRS
2.
If the HLR determines that the request can be served, it returns a Send Routeing Info for GPRS Ack (IMSI, SGSN Address, Mobile Station Not Reachable Reason) message to the GGSN. If the HLR determines that the request cannot be served (for example, IMSI unknown in HLR), the HLR shall send a Send Routeing Info for GPRS Ack (IMSI, MAP Error Cause) message. After receiving the Send Routeing Info for GPRS Ack message from the HLR, the GGSN sends a PDU Notification Request (IMSI, PDP Type, PDP Address) message to the SGSN indicated by the HLR. Then the SGSN returns a PDU Notification Response message to the GGSN. The SGSN sends a Request PDP Context Activation (TI, PDP Type, and PDP Address) message to the MS. The subsequent procedure is the same as the MS-requested PDP context activation procedure. For details, refer to the MS-requested PDP context activation procedure.
3.
4. 5.
21.1.12 PDP Context Deactivation Procedure

This describes the PDP context deactivation procedure. The procedure of PDP context deactivation can be initiated by different network elements:
l l l
The procedure of PDP context deactivation initiated by the MS The procedure of PDP context deactivation initiated by the SGSN The procedure of PDP context deactivation initiated by the GGSN
Procedure of the PDP Context Deactivation Initiated by the MS

Figure 21-17 shows the procedure of the PDP context deactivation initiated by the MS. Figure 21-17 Procedure of the PDP context deactivation initiated by the MS
MS SGSN GGSN
Deactivate PDP Context Request(1) Security Functions(2) Delete PDP Context Request(3) Delete PDP Context Response(4) Deactivate PDP Context Accept(5)
The previous procedure is described as follows: 1. 2. 3. The MS sends a Deactivate PDP Context Request (TI) message to the SGSN. Security functions may be executed. The SGSN sends a Delete PDP Context Request (TID) message to the GGSN. After receiving this message, the GGSN removes the PDP context, releases the dynamic PDP address, and returns a Delete PDP Context Response (TID) message to the SGSN.
Issue 01 (2008-06-10)
21 GPRS
4.
The SGSN returns a Deactivate PDP Context Accept (TI) message to the MS.
Procedure of the PDP Context Deactivation Initiated by the SGSN

Figure 21-18 shows the procedure of the PDP context deactivation initiated by the SGSN. Figure 21-18 Procedure of the PDP context deactivation initiated by the SGSN
MS SGSN Delete PDP Context Request(1) Deactivate PDP Context Request(3) Deactivate PDP Context Accept(4) Delete PDP Context Response(2) GGSN
The previous procedure is described as follows: 1. The SGSN sends a Delete PDP Context Request (TID) message to the GGSN. After receiving this message, the GGSN removes the PDP context, releases the dynamic PDP address, and sends a Delete PDP Context Response (TID) message to the SGSN. The SGSN sends a Deactivate PDP Context Request message (TI) to the MS. The MS removes the PDP context, and then returns a Deactivate PDP Context Accept message to the SGSN.
2. 3.
Procedure of the PDP Context Deactivation Initiated by the GGSN

Figure 21-19 shows the procedure of the PDP context deactivation initiated by the GGSN. Figure 21-19 Procedure of the PDP context deactivation initiated by the GGSN
MS SGSN Delete PDP Context Request(1) Deactivate PDP Context Request(2) Deactivate PDP Context Accept(3) GGSN
Delete PDP Context Response(4)
The previous procedure is described as follows: 1.

21-20
The GGSN sends a Delete PDP Context Request (TID) message to the SGSN.
21 GPRS
2.
The SGSN sends a Deactivate PDP Context Request (TI) message to the MS. After receiving this message, the MS removes the PDP context, and then returns a Deactivate PDP Context Accept message to the SGSN. The SGSN returns a Delete PDP Context Response (TID) message to the GGSN. After receiving this message, the GGSN releases the dynamic PDP address and the corresponding PDP context.
3.
21.1.13 PDP Context Modification Procedure

This describes the PDP context modification procedure. The SGSN can initiate the PDP context modification to modify the parameters in the PDP context, such as QoS Negotiated and Radio Priority. Figure 21-20 shows the modification procedure. Figure 21-20 Procedure of the PDP context modification initiated by the SGSN
MS SGSN Update PDP Context Request(1) Modify PDP Context Request(3) Modify PDP Context Accept(4) Update PDP Context Response(2) GGSN
The previous procedure is described as follows: 1. 2. The SGSN sends a Update PDP Context Request (TID, QoS Negotiated) message to the GGSN. After receiving the Updata PDP Context Request message, the GGSN responds as follows:
l
If QoS Negotiated received from the SGSN is incompatible with the PDP context being modified, then the GGSN rejects the Update PDP Context Request. The compatible QoS profiles are configured by the GGSN operator. If the QoS Negotiated can be met, the GGSN stores QoS Negotiated, and returns an Update PDP Context Response (TID, QoS Negotiated, Radio Priority) message to the SGSN. If the QoS Negotiated cannot be met, the GGSN rejects the request.
3.
After receiving the Update PDP Context Response message from the GGSN, the SGSN sends a Modify PDP Context Request (TID, QoS Negotiated, Radio Priority) message to the MS. After receiving the Modify PDP Context Request message from the SGSN, the MS responds as follows: If the MS accepts the new QoS Negotiated and TI, it returns a Modify PDP Context Accept message to the SGSN. If the MS does not accept the new QoS Negotiated and TI, it deactivates the PDP context, with the reject cause of QoS not accepted.
4.
21.1.14 Circuit Paging Procedure

This describes the circuit paging procedure that is initiated through the SGSN.
21 GPRS
If an MS is attached to both the GPRS network and the GSM network and besides network operation mode I is used, the MSC/VLR initiates the circuit paging procedure through the SGSN.
l l
If an MS is in the STANDBY status, paging is performed in routing areas. If an MS is in the READY status, paging is performed in cells.
Figure 21-21 shows the circuit paging procedure initiated through the SGSN. Figure 21-21 Circuit paging procedure initiated through the SGSN.
MS BSS SGSN MSC/VLR
Page(1) Paging Request(2) Paging Request(3) Paging Response(4)
SCCP Connection Request (Paging Response)(5)
The circuit paging procedure is described as follows: 1. The SGSN receives a paging message from the MSC. This message contains the IMSI, TLLI, VLR TMSI, channel requirement, priority, and location information. Channel requirement indicates which types of CS channels of the MS need to be requested in the response message. VLR TMSI and channel requirement are optional parameters. Priority is a parameter determining the priority of circuit switched paging. The SGSN maps priority to QoS. The SGSN sends a paging request message to the BSS. This message contains the IMSI, TLLI, VLR TMSI, area, channel requirement, and QoS. Area refers to a cell of an MS in the READY status, or a routing area of an MS in the STANDBY status. The BSS interprets the received paging request message as the radio paging request message of each cell. If the BSS assigns dedicated radio resources to the MS to be paged in a cell, the BSS sends a paging request message to the MS through these radio resources. Otherwise, the BSS pages the MS by sending a paging request message on appropriate paging channels The message contains VLR TMSI/IMSI and channel requirement. On receiving the paging request message of CS services, the MS responds to the message if the request is accepted. Later, the MS adheres to the process of CS paging response. This process contains random access, immediate assignment, and paging response. After the BSS receives the paging response message, the BSS sends the message to the MSC. Then, the MSC stops the paging response timer.
2.
3.
4.
5.
21.1.15 Packet Paging Procedure

This describes the packet paging procedure.
21 GPRS
When the network side wants to send downlink data to an MS, the SGSN initiates packet paging to locate the MS. Figure 21-22 shows the procedure of packet paging. Figure 21-22 Procedure of packet paging
MS BTS BSC Page Req(2) Paging Req(3) Channel Request(4) Channel Req(5) Immediate Assigment(7) RLC Data block (TLLI,CV=0)(8) Packet Uplink Ack/Nack(FAI=1)(10) Packet DL Assigment (Uplink TFI,S/P=1)(12) Packet Control Ack(AB or NB)(13) Packet Control Ack(AB or NB)(14) RLC Data Block(15) RLC Data Block(16) IMM_ASS CMD(6) PCU SGSN PS paging Req PDU(1)
UL PDU(9) DL PDU(11)
The previous procedure is described as follows: 1. The SGSN sends the PS paging Req PDU to the PCU through the Gb interface. The PCU transforms the PDU into a Packet Paging Request message and then sends the message on the PCH.
NOTE
If the BSS is configured with PCCCH, this message is transmitted on the PPCH.
...
2.
After receiving the Paging Req message, the MS initiates the uplink TBF establishment procedure, sends the paging response packet to the PCU in data format over the Um interface. The PCU then forwards the packet to the SGSN. After receiving the paging response message, the SGSN processes the message and starts transmitting downlink data, thus initiating the downlink TBF establishment procedure.
3.
21.1.16 GPRS Suspension and Resumption Procedure

This describes the GPRS suspension and resumption procedure. When an MS that works in GPRS packet transfer mode initiates the GSM circuit service, and when the MS is unable to perform GPRS service and GSM CS service simultaneously, the MS shall request the network for suspension of GPRS services. When the GSM circuit service is complete, the network notifies the MS to resume the suspended GPRS service. Figure 21-23 shows the GPRS suspension and resumption procedure.
21 GPRS
Figure 21-23 GPRS suspension and resumption procedure

MS BTS BSC RLC data block(2) Dedicated Mode Entered(3) GPRS suspension(4) SUSPEND(5) Suspend PDU(6) Suspend Ack/Nack(7) SUSPEND ACK(8) RESUME(9) Resume PDU(10) Resume Ack/Nack(11) RESUME ACK(12) DL PDU(14) DL PDU(15) Routing Area Updating Procedure(16) PCU DL PDU(1) SGSN MSC/VLR
Channel Release (R) (13)
The previous procedure is described as follows: 1. The MS in the packet transfer mode enters the dedicated mode. The MS sends an RR Suspend (TLLI, RAI) message to the PCU through the BSC, indicating that the ongoing PS service is to be suspended and the services in dedicated mode are to be started. The PCU may terminate any ongoing GPRS traffic for this TLLI. The PCU sends a Suspend (TLLI, RAI) message to the SGSN, notifying the SGSN that the ongoing PS service is to be suspended. The SGSN stops transmitting PDU to the MS, saves the current PS service state, and returns a Suspend Ack message to the PCU. After receiving the Suspend Ack message, the PCU notifies the BSC to start dedicated service, and saves the TLLI and RAI of the MS so that the MS can request the SGSN to resume the GPRS when it no longer works in dedicated mode. The MS starts the dedicated service. Upon detection of the completion of dedicated service, the BSC gets ready to release the CS service channel, and notifies the PCU of the current location of the MS. If the PCU can request the SGSN to resume the GPRS, it sends a Resume (TLLI, RAI) message to the SGSN, requesting the SGSN to resume the PS service, and reports the current MS location to the SGSN. The SGSN returns a Resume Ack message to the PCU to confirm the resumption, and starts to send PDUs.
...
2.
3.
4.
5.
21-24
21 GPRS
6.
The PCU notifies the BSC to resume the PS service. The BSC releases the resources being occupied in dedicated mode, and sends a Channel Release (Resume) message to the MS to notify the MS whether to resume the PS service. The Resume message indicates whether the request from the BSS for the SGSN to resume the GPRS of the MS is successful, that is, whether the BSS has received the Resume Ack message before sending the Channel Release message.
NOTE
If the MS does not receive the Channel Release (Resume) message before ending the dedicated mode, or if the Channel Release (Resume) message indicates that the BSS fails to request the SGSN to resume the GPRS, the MS sends a routing area updating request message to the SGSN to resume the GPRS. The SGSN and BSS suspend the MS separately. Note: The SGSN cannot paging a suspended MS.
7.
The MS enters the packet transfer mode and starts to send and receive packets.
21.2 Internal BSC Signaling Procedures

This describes the internal BSC signaling procedures of the circuit paging and packet paging initiated by the packet domain in the case of built-in PCU.
Circuit Paging Procedure

The circuit paging can be initiated by the packet domain only when the Network Operation Mode is set to Network Operation Mode I. The VLR sends the CS paging message to the SGSN through the Gs interface. The SGSN then sends the CS paging message to the BSC. The CS paging message contains the IMSI, BVCI, and paging area. The BSC processes the CS paging as follows: 1. 2. 3. The BSC obtains the list of target paging cells in the NSE according to the BVCI and paging area. If the paged MS has a PS connection, the BSC sends the paging message on the PACCH of the cell where the MS camps. If the paged MS does not have a PS connection, the paging message is sent as follows:
l l
If the target cell is configured with the PCCCH, the paging message is sent on the PPCH. In other cases, the paging message is sent on the PCH.
Packet Paging Procedure

The PS paging message sent from the SGSN to the BSC contains the IMSI, BVCI, and paging area. The BSC processes the PS paging as follows: 1. 2. 3. The BSC obtains the list of target paging cells in the NSE according to the BVCI and paging area. If the paged MS has a PS connection, the BSC sends the paging message on the PACCH of the cell where the MS camps. If the paged MS does not have a PS connection, the paging message is sent as follows:
l
If the Network Operation Mode is set to Network Operation Mode II, the paging message is sent on the PCH. If the Network Operation Mode is set to Network Operation Mode I or Network Operation Mode III and the cell is not configured with PCCCH, the paging message is sent on the PCH.
Issue 01 (2008-06-10)
21 GPRS
l
In other cases, the paging message is sent on the PPCH.
21.3 Abnormal Cases and Handling Suggestions (GPRS)

This describes the abnormal GPRS cases, probable causes, and handling suggestions. 21.3.1 Abnormal PCU Cell Startup (Case Study) This describes how to check whether the initialization of a GPRS cell is normal by tracing and observing signaling on the Pb interface, and how to locate failure by checking the failure information. 21.3.2 GPRS Service Access Not Allowed (Case Study) This describes the fault, probable causes, and handling suggestions.
21.3.1 Abnormal PCU Cell Startup (Case Study)

This describes how to check whether the initialization of a GPRS cell is normal by tracing and observing signaling on the Pb interface, and how to locate failure by checking the failure information. The PCU cell startup procedure shows the signaling procedure between the PCU and BSC on the Pb interface when a GPRS cell starts up. You can check whether the initialization of the GPRS cell is normal by tracing and observing the signaling on the Pb interface, and know the cell-related information by checking the message explanation information in the signaling. You can also locate the failure through interface tracing and the contents of the message. Figure 21-24 shows a normal procedure of PCU cell startup. The procedure is started when the PCU starts the cell.
21-26
Issue 01 (2008-06-10)
21 GPRS
Figure 21-24 Normal PCU cell startup procedure

BSC PCU
PCU_BSC_CELL_RESET(1) BSC_PCU_CELL_RESET_ACK(2) PCU_BSC_CELL_CONFIG_REQ(3) BSC_PCU_CELL_INFO(4) PCU_BSC_CELL_INFO_CNF(5) BSC_PCU_CHAN_INFO(6) PCU_BSC_CHAN_INFO_CNF(7)
BSC_PCU_CHAN_INFO(8) PCU_BSC_CHAN_INFO_CNF(9) BSC_PCU_CELL_CONFIG_ACK(10)
PCU_BSC_PDCH_REQ(11) BSC_PCU_PDCH_ACK(12)
PCU_BSC_PDCH_REQ(13) BSC_PCU_PDCH_ACK(14)
The circuit paging procedure is described as follows: 1. 2. The PCU initializes the cell. It sends a PCU_BSC_CELL_RESET message to the BSC through the Pb interface. After receiving a BSC_PCU_CELL_RESET_ACK message from the BSC, the PCU sends a PCU_BSC_CELL_CONFIG_REQ message to the BSC. The cell configuration obtaining procedure is started. The BSC sends a BSC_PCU_CELL_INFO and a BSC_PCU_CHAN_INFO message to the PCU. The PCU returns a PCU_BSC_CELL_INFO_CNF and a PCU_BSC_CELL_INFO_CNF message. The BSC sends cell information and channel
... ... ...
3.
Issue 01 (2008-06-10)
21 GPRS
information messages to the PCU in succession. Each message is sent after the BSC receives the acknowledgement of the previous message from the PCU. 4. After all the cell configuration messages and channel configuration messages are sent, and the acknowledgement of the last message is received, the BSC sends a BSC_PCU_CELL_CONFIG_ACK message to the PCU. The cell configuration obtaining procedure is complete. The PCU sends a PCU_BSC_PDCH_REQ message to the BSC through the Pb interface to request fixed channels. The PCU receives a BSC_PCU_PDCH_REQ_ACK message from the BSC. The PCU requests multiple channels simultaneously.
5.
The above is a normal cell startup procedure. Usually, a abnormal procedure refers to a procedure that is unable to complete or appears with a NACK message. The problem can be located by analyzing the contents of the NACK message. An abnormal PCU cell startup may caused by the following reasons:
l
Timeout when waiting for acknowledgement In the case of timeout, the system resends the message for many times. If timeout persists, the handling is as follows:
Timeout when waiting for the BSC cell reset message: the initialization of the local cell fails. Initialize the local cell after other cells are initialized. Timeout when waiting for the acknowledgement message of the BSC configuration obtaining: the initialization of the local cell fails. Initialize the local cell after other cells are initialized. Timeout when waiting for the acknowledgement message in other steps: continue with the rest steps until the initialization is complete.
A NACK message is received. The BSC may return a BSC_PCU_CELL_CONFIG_NACK message after receiving a PCU_BSC_CELL_CONFIG_REQ message from the PCU. The proboble causes are as follows:
The cell does not exist, the cell does not support GPRS, or the BSC is resetting the cell. For the cause that the cell does not exist or the cell does not support GPRS, the cell initialization is no longer performed. For the cause that the BSC is resetting the cell or other causes, the initialization of the cell is performed after other cells are initialized. The BSC may return a BSC_PCU_PDCH_REQ_NACK message after receiving a PCU_BSC_PDCH_REQ message from the PCU. The PCU continue with the rest steps until the initialization completes. The cause value of the NACK message can be analyzed by checking the detail information of the corresponding message.
21.3.2 GPRS Service Access Not Allowed (Case Study)

Description
If an external PCU is used, GPRS services in a cell cannot operate. After the GPRS performance measurement result is analyzed, it is found that the the number of packet immediate assignment requests in a cell is more than 10 and the number of successful packet immediate assignments is 0.
21 GPRS
Analysis
On the BSC, after the dynamic data configuration command related to "Modify TRX Attributes" or "Modify TRX Frequencies" is run, the BSC needs to inform the PCU to reset the cell so that the PCU can obtain cell-related attributes again. After the PCU performs the cell reset procedure on the Pb interface, the PCU needs to request the PDCH from the BSC. The BSC can assign the PDCH to the PCU after the BTS approves the assignment. If the uplink frequency scanning is started on the PDCH when the BTS handles the message sent by the BSC for setting PDCH attributes, the BTS regards that it is unsuitable to set the channel to PDCH and displays the NACK message. As a result, the PCU fails to obtain the PDCH and cannot provide GPRS services. Till now, the main flow of cell resetting is complete. A packet system message of the cell can still be normally sent. Therefore, traffic measurement of the BSC indicates there is a packet access request. In the PCU, however, the number of successful packet accesses is 0. After the BTS is reset, channels are reselected to scan frequencies. If the system selects the frequency scanning of TRXs without the PDCH, this problem does not occur temporarily. Conclusion The BTS has unreasonable requirement balance between the GPRS services and the frequency scanning function. As a result, the PDCH is not set for the TRX during frequency scanning.
NOTE
Uplink frequency scanning: If cell frequency scanning traffic measurement is registered on a frequency, this traffic measurement selects a radio channel for frequency scanning.
Do not register cell frequency scanning traffic measurement on the TRX that is configured with the PDCH, if not required. In later BSC versions, some improvements have been made and this limitation does not exist.
Issue 01 (2008-06-10)
21-29
A Message Interpretation
Message Interpretation
This appendix provides the message contents of some key messages on the A and Abis interfaces.
A.1 Key Messages on the A interface

The same elements appear in various orders depending on the message. The messages on the A interface described here are based on Phase 2+ GSM Rec. 08.08 version 8.13.0 Release 1999. Table A-1 lists the key BSSMAP messages. Table A-1 Key BSSMAP messages Message Name Assignment Request Assignment Complete Assignment Failure Handover Request Handover Request Acknowledge Handover Required Handover Required Reject Handover Command Handover Complete Handover Failure Handover Performed Paging Clear Request Reference Assignment Request Assignment Complete Assignment Failure Handover Request Handover Request Acknowledge Handover Required Handover Required Reject Handover Command Handover Complete Handover Failure Handover Performed Paging Clear Request
Issue 01 (2008-06-10)
A-1
Message Name Clear Command Classmark Request Classmark Update Cipher Mode Command Cipher Mode Complete Cipher Mode Reject Complete Layer 3 Information
Reference Clear Command Classmark Request Classmark Update Cipher Mode Command Cipher Mode Complete Cipher Mode Reject Complete Layer 3 Information
A.1.1 Message Contents

Assignment Request
The Assignment Request message is sent from the MSC to the BSS through the relevant SCCP connection to request the BSS to assign radio resources. This message defines the the attributes of the radio resourceswhich are defined within the message. The message may also include the terrestrial circuit to be used. Table A-2 lists the information elements (IEs) of the Assingment Request message. Table A-2 IEs of the Assignment Request message Information Element Message Type Channel Type Layer 3 Header Information Priority Circuit Identity Code Downlink DTX Flag Interference Band To Be Used Classmark Information 2 Group Call Reference Talker Flag Configuration Evolution Indication LSA Access Control Suppression Reference 1.2.1 1.2.2 1.2.3 1.2.4 1.2.5 1.2.6 1.2.7 1.2.8 1.2.9 1.2.10 1.2.42 1.2.11 Direction MSC-BSS MSC-BSS MSC-BSS MSC-BSS MSC-BSS MSC-BSS MSC-BSS MSC-BSS MSC-BSS MSC-BSS MSC-BSS MSC-BSS Type M M O (3) O O (1) O (2) O O (4) O (5) O (6) O (7) O (8) Length 1 510 4 3 3 2 2 45 38 1 2 2
A-2
Issue 01 (2008-06-10)
Information Element Service Handover
Reference 1.2.38
Direction MSC-BSS
Type O (9)
Length 3
The explanations of the IEs are as follows: The Circuit Identity Code is included only when the MSC allocates the circuits on the A interface and the information element (IE) of channel type indicates speech or data. The Downlink DTX Flag is included only when a speech TCH exists. If it is not included, the DTX function in the BSS is not affected. The Layer 3 Header Information does not serve any useful purpose. MSCs should not send this IE unless it is required by the recipients owning to the need to interwork with older versions of the protocol. It is expected that in future versions of GSM Rec. 08.08, Layer 3 Header Information is deleted from this message. The Classmark Information 2 may be included if the information is known by the MSC. The Group Call Reference is included by the MSC for either a talking or listening subscriber in a group call. The Talker Flag is included for group calls. When this element is included, the mobile is a talker in the call or the mobile is a listener. The Configuration Evolution Indication is indicated by the MSC if known. The LSA Access Control Suppression is included if LSA access control function shall be suppressed in the BSS. The Service Handover is included if a preference for other radio access technologies shall be applied to the MS connection.
Assignment Complete
The Assignment Complete message is sent from the BSS to the MSC and indicates that the requested assignment is completed correctly. The Assignment Complete message is sent through the BSSAP-SCCP connection associated with the dedicated resources. Table A-3 lists the IEs of the Assingment Complete message. Table A-3 IEs of the Assignment Complete message Information Element Message Type RR Cause Circuit Identity Code Cell Identifier Chosen Channel Chosen Encryption Algorithm Circuit Pool Reference 1.2.1 1.2.12 1.2.5 1.2.13 1.2.14 1.2.15 1.2.16 Direction BSS-MSC BSS-MSC BSS-MSC BSS-MSC BSS-MSC BSS-MSC BSS-MSC Type M O O (4) O (1) O (3) O (5) O (2) Length 1 2 3 310 2 2 2
Issue 01 (2008-06-10)
A-3
Information Element Speech Version (Chosen) LSA Identifier
Reference 1.2.17 1.2.18
Direction BSS-MSC BSS-MSC
Type O (6) O (7)
Length 2 5
The explanations of the IEs are as follows: If during the assignment the serving cell is changed, the Cell Identifier is used to indicate a new cell. The Circuit Pool shall be included when several circuit pools are present on the A interface and a circuit is allocated by the Assignment Request message. The Chosen Channel is included at least when the channel rate/type choice is done by the BSS. The Circuit Identity Code is included mandatory by the BSS if the BSS allocates the Ainterface circuits and a circuit is needed. The Chosen Encryption Algorithm is included at least when the encryption algorithm is changed by the BSS. The Speech Version (Chosen) is included at least when the speech version choice is done by the BSS. The LSA Identifier shall be included if current LSA in the serving cell is identified (see GSM Rec. 03.73). If the LSA Identifier is not included, there is no current LSA in the serving cell.
Assignment Failure
The Assignment Failure message is sent from the BSS to the MSC through the relevant SCCP connection. It indicates that there is a failure in the assignment process on the BSS side and that the assignment procedure is aborted. Table A-4 lists the IEs of the Assingment Failure message. Table A-4 IEs of the Assignment Failure message Information Element Message Type Cause RR Cause Circuit Pool Circuit Pool List Reference 1.2.1 1.2.19 1.2.12 1.2.16 1.2.20 Direction BSS-MSC BSS-MSC BSS-MSC BSS-MSC BSS-MSC Type M M O O (1) O (2) Length 1 34 2 2 V
The explanations of the IEs are as follows: The Circuit Pool shall be included when several circuit pools are present on the A interface. The Circuit Pool List may be included when cause is "circuit pool mismatch" or "switch circuit pool" to indicate circuit pool preferences.
A-4
Issue 01 (2008-06-10)
Typical cause values are as follows: Radio interface message failure O&M intervention Equipment failure No radio resource available Requested terrestrial resource unavailable Requested transcoding/rate adaption unavailable Terrestrial resource already allocated Invalid message contents Radio interface failure, reversion to old channel Directed retry Circuit pool mismatch Switch circuit pool Requested speech version unavailable
Handover Request
The Handover Request message is sent from the MSC to the BSS through the relevant SCCP connection to indicate that the MS is handed over to that BSS. Table A-5 lists the IEs of the Handover Request message. Table A-5 IEs of the Handover Request message Information Element Message Type Channel Type Encryption Information Classmark Information 1 Or Classmark Information 2 Cell Identifier (Serving) Priority Circuit Identity Code Downlink DTX Flag Cell Identifier (Target) Interference Band To Be Used Cause Classmark Information 3 Current Channel type 1 1.2.8 1.2.13 1.2.4 1.2.5 1.2.6 1.2.13 1.2.7 1.2.19 1.2.23 1.2.24 MSC-BSS MSC-BSS MSC-BSS MSC-BSS MSC-BSS MSC-BSS MSC-BSS MSC-BSS MSC-BSS MSC-BSS M (6) M (20) O O (7) O (3) M (17) O O (9) O (4) O (8) 45 510 3 3 2 310 2 34 314 2 Reference 1.2.1 1.2.2 1.2.21 1.2.22 Direction MSC-BSS MSC-BSS MSC-BSS MSC-BSS Type M M M (1) M# Length 1 510 3-n 2
Issue 01 (2008-06-10)
A-5
Information Element Speech Version (Used) Group Call Reference Talker Flag Configuration Evolution Indication Chosen Encryption Algorithm (Serving) Old BSS to New BSS Information LSA Information LSA Access Control Suppression Service Handover IMSI Source RNC to Target RNC Transparent Information (UMTS) Source RNC to Target RNC Transparent Information (cdma2000)
Reference 1.2.17 1.2.9 1.2.10 1.2.27 1.2.15 1.2.26 1.2.25 1.2.11 1.2.38 1.2.39 1.2.40 1.2.41
Direction MSC-BSS MSC-BSS MSC-BSS MSC-BSS MSC-BSS MSC-BSS MSC-BSS MSC-BSS MSC-BSS MSC-BSC MSC-BSS MSC-BSS
Type O (10) O (5) O (11) O (12) O (2) O(13) O(14) O (15) O (21) O (16) O (18) O (19)
Length 2 38 1 2 2 2n 3+4n 2 3 310 nm nm
The explanations of the IEs are as follows: If the MSC sends a Cipher Mode Command for this RR connection or rejects all such Cipher Mode Commands with Cipher Mode Reject messages, then the MSC shall indicate that the only permitted algorithm is no encryption. If the Chosen Encryption Algorithm (Serving) is included, it shall be equal to the last received Chosen Encryption Algorithm IE. The Downlink DTX Flag is included only when a speech TCH exists. If it is not included, the DTX function in the BSS is not affected. The Classmark Information 3 is included if the MSC receives such information. The Group Call Reference is included if the MS is in a voice broadcast or voice group call. One of these two elements is sent. The Circuit Identity Code is included only when the channel type indicates speech or data. The Current Channel type 1 is included at least when the message is sent as a reaction to reception of a Handover Required message containing a Current channel type 1. In this case, the Current Channel type 1 shall be equal to the received element. The Cause should always be included. Its cause value should be the same as that indicated in the corresponding Handover Required message. The Speech Version (Used) is included at least when the message is sent as a reaction to reception of a Handover Required message containing a Speech version (used) IE. In this case, the Speech Version (Used) shall be equal to the received element. The Talker Flag is included for voice group call. When the Talker Flag is included, the mobile is a talker in the call or the mobile is a listener.
A-6
Issue 01 (2008-06-10)
The Configuration Evolution Indication is indicated by the MSC if known The Old BSS to New BSS Information is included only if the message is sent as a reaction to the reception of a Handover Required message containing an old BSS to new BSS information. The contents of the Old BSS to New BSS Information shall be equal to the received element. The LSA Information is included when the subscriber localizes service area support. The LSA Access Control Suppression is included if LSA access control function shall be suppressed in the BSS. The IMSI is included at least when the MS is dual transfer mode capable and the IMSI is available on the MSC side. If inter-RAT handover from GSM to UMTS or to cdma 2000 is performed, the Cell Identifier (Target) indicates the target RNC-ID. The Source RNC to Target RNC Transparent Information (UMTS) shall be included when inter-RAT handover (UMTS) is performed. This element is included only if the message is sent as a reaction to the reception of a Handover Required message containing a "Source RNC to Target RNC transparent information (UMTS)". Its contents shall be equal to the received element. Note; only provided in the Handover Request message on the MAP-E interface. The Source RNC to Target RNC Transparent Information (cdma2000) shall be included when inter-RAT handover (cdma2000) is performed. This element is included only if the message is sent as a reaction to the reception of a Handover Required message containing an "Source RNC to Target RNC transparent information (cdma2000)". Its contents shall be equal to the received element.
The Source RNC to Target RNC Transparent Information (cdma2000) is only provided in the Handover Request message on the MAP-E interface.
In inter-RAT handover from UMTS (or cdma2000) to GSM, the Cell Identifier (Serving) indicates the serving area of the UE. The Service Handover is included if a preference for other radio access technologies shall be applied to the MS connection. Typical cause values are as follows: Uplink quality Uplink strength Downlink quality Downlink strength Distance Better cell Response to MSC invocation O&M intervention Directed retry Switch circuit pool Traffic Preemption
Issue 01 (2008-06-10)
A-7
Handover Request Acknowledge

The Handover Request Acknowledge message is sent from the BSS to the MSC. It indicates that the request to support a handover at the target BSS can be supported by the BSS. It also indicates the radio channels to which the MS should be directed. The Handover Request Acknowledge message is sent through the BSSAP-SCCP connection associated with the dedicated resource. Table A-6 lists the IEs of the Handover Request Acknowledge message. Table A-6 IEs of the Handover Request Acknowledge message Information Element Message Type Layer 3 Information Chosen Channel Chosen Encryption Algorithm Circuit Pool Speech Version (Chosen) Circuit Identity Code LSA Identifier Reference 12.1 1.2.3 1.2.14 1.2.15 1.2.16 1.2.17 1.2.5 1.2.18 Direction BSS-MSC BSS-MSC BSS-MSC BSS-MSC BSS-MSC BSS-MSC BSS-MSC BSS-MSC Type M M (1) O (4) O (5) O (2) O (6) O (3) O (7) Length 1 11n 2 2 2 2 3 5
The explanations of the IEs are as follows: The Layer 3 Information carries a Handover Command message on the radio interface. The Circuit Pool shall be included when several circuit pools are present on the A interface and a circuit is allocated by the Handover Request message. The Circuit Identity Code is included mandatory by the BSS if the BSS allocates the circuits on the A interface and a circuit is needed. The Chosen Channel is included at least when the channel rate/type choice is done by the BSS. The Chosen Encryption Algorithm is included at least when the encryption algorithm is selected by the BSS. The Speech Version (Chosen) is included at least when the speech version choice is done by the BSS. The LSA Identifier shall be included if a new potential current LSA in the target cell is identified. For details, see GSM Rec. 03.73. If the LSA Identifier is not included, there is no potential current LSA in the target cell.
Handover Required
The Handover Required message is sent from the BSS to the MSC. It indicates that for a given MS to which radio resources are assigned, a handover is required for the reason given by the cause element.
A-8
Issue 01 (2008-06-10)
The Handover Required message is sent through the BSSAP-SCCP connection associated with the dedicated resources. Table A-7 lists the IEs of the Handover Required message. Table A-7 IEs of the Handover Required message Information Element Message Type Cause Response Request Cell Identifier List (Preferred) Reference 1.2.1 1.2.19 1.2.28 1.2.29 Direction BSS-MSC BSS-MSC BSS-MSC BSS-MSC Type M M O M Length 1 34 1 2n+3 to 7n+3 Circuit Pool List Current Channel Type 1 Speech Version (Used) Queuing Indicator Old BSS to New BSS Information Source RNC to target RNC transparent information (UMTS) Source RNC to target RNC transparent information (cdma2000) 1.2.20 1.2.24 1.2.17 1.2.30 1.2.26 1.2.40 1.2.41 BSS-MSC BSS-MSC BSS-MSC BSS-MSC BSS-MSC BSS-MSC BSS-MSC O (1) O (2) O (3) O O O (5) O (6) V 2 2 2 2n 3m nm
The explanations of the IEs are as follows: The Circuit Pool List is included when cause is "switch circuit pool" and the MSC allocates the circuit on the A interface. The Current Channel Type 1 should always be included. The Speech Version (Used) should always be included only when the channel mode is speech. Typical cause values are as follows: Uplink quality Uplink strength Downlink quality Downlink strength Distance Better cell Response to MSC invocation O&M intervention
Issue 01 (2008-06-10)
A-9
Directed retry Switch circuit pool Traffic Preemption
Handover Required Reject

The Handover Required Reject message is sent from the MSC to the BSS through the relevant SCCP connection. It indicates to the BSS that the Handover Required message does not result in handover. Table A-8 lists the IEs of the Handover Required Reject message. Table A-8 IEs of the Handover Required Reject message Information Element Message Type Cause Reference 1.2.1 1.2.19 Direction MSC-BSS MSC-BSS Type M M Length 1 34
Typical cause values are as follows: Equipment failure No radio resource available Requested terrestrial resource unavailable Invalid message contents Requested transcoding/rate adaptation unavailable O&M intervention
Handover Command
The Handover Command message is sent from the MSC to the BSS through the relevant SCCP connection. It contains the target channel to which the MS should retune. Table A-9 lists the IEs of the Handover Command message. Table A-9 IEs of the Handover Command message Information Element Message Type Layer 3 Information Cell Identifier Reference 1.2.1 1.2.31 1.2.13 Direction MSC-BSS MSC-BSS MSC-BSS Type M M (1) O Length 1 11n 310
The Layer 3 Information carries a Handover Command message on the radio interface.
A-10
Issue 01 (2008-06-10)
Handover Complete
The Handover Complete message is sent from the BSS to the MSC through the relevant SCCP connection. It indicates that the correct MS successfully accesses the target cell. Table A-10 lists the IEs of the Handover Complete message. Table A-10 IEs of the Handover Complete message Information Element Message Type RR Cause Reference 1.2.1 1.2.12 Direction BSS-MSC BSS-MSC Type M O Length 1 2
Handover Failure
The Handover Failure message is sent from the BSS to the MSC through the relevant SCCP connection. It indicates to the MSC that there is a failure in the resource allocation process on handover, and that the handover is aborted. Table A-11 lists the IEs of the Handover Failure message. Table A-11 IEs of the Handover Failure message Information Element Message Type Cause RR Cause Circuit Pool Circuit Pool List Reference 1.2.1 1.2.19 1.2.12 1.2.16 1.2.20 Direction BSS-MSC BSS-MSC BSS-MSC BSS-MSC BSS-MSC Type M M O O (1) O (2) Length 1 34 2 2 V
The Circuit Pool shall be included when several circuit pools are present on the A interface. The Circuit Pool List may be included when cause is "circuit pool mismatch" or "switch circuit pool" to indicate circuit pool preferences. Typical cause values are as follows: Radio interface message failure O&M intervention Equipment failure No radio resource available Requested terrestrial resource unavailable Requested transcoding/rate adaption unavailable Terrestrial resource already allocated Invalid message contents
Issue 01 (2008-06-10)
A-11
Radio interface failure - reversion to old channel Ciphering algorithm not supported Circuit pool mismatch Switch circuit pool Requested speech version unavailable
Handover Performed
The Handover Performed message is sent from the BSS to the MSC to indicate that the BSS performs an internal handover. The cell identifier and (if required for O&M reasons) optionally the new channel identity is included. The Handover Performed message is sent through the BSSAP-SCCP connection associated with the dedicated resources. Table A-12 lists the IEs of the Handover Performed message. Table A-12 IEs of the Handover Performed message Information Element Message Type Cause Cell Identifier Chosen Channel Chosen Encryption Algorithm Speech Version (Chosen) LSA Identifier Reference 1.2.1 1.2.19 1.2.13 1.2.14 1.2.15 1.2.17 1.2.18 Direction BSS-MSC BSS-MSC BSS-MSC BSS-MSC BSS-MSC BSS-MSC BSS-MSC Type M M M O (1) O (2) O (3) O (4) Length 1 34 310 2 2 2 5
The explanations of the IEs are as follows: The Chosen Channel is included at least when the channel rate/type changes during the handover. The Chosen Encryption Algorithm is included at least when the encryption algorithm is changed by the BSS. The Speech Version (Chosen) is included at least when the speech version is changed by the BSS. The LSA Identifier shall be included if current LSA in the new serving cell is identified (see GSM Rec. 03.73). If the LSA Identifier is not included, there is no current LSA in the new serving cell. Typical cause values: as for the handover required message, except response to MSC invocation.
A-12
Issue 01 (2008-06-10)
Paging
The Paging message is sent from the MSC to the BSS. It contains sufficient information to allow the paging message to be transmitted by the correct cells at the correct time. The Paging message is sent as a connectionless SCCP message. Table A-13 lists the IEs of the Paging message. Table A-13 IEs of the Paging message Information Element Message Type IMSI TMSI Cell Identifier List Channel Needed eMLPP Priority Reference 1.2.1 1.2.32 1.2.33 1.2.29 1.2.34 1.2.35 Direction MSC-BSS MSC-BSS MSC-BSS MSC-BSS MSC-BSS MSC-BSS Type M M O (1) M O (2) O (3) Length 1 310 6 3 to 3+7n 2 2
The explanations of the IEs are as follows: The TMSI is omitted in the exceptional case where the IMSI is used instead of the TMSI as a paging address on the radio interface. If the channel needed is not present, the default value is assumed to be 00 (any channel). If the BSS implements the eMLPP feature, it should use the eMLPP Priority to build the Paging request messages on the radio interface. If the BSS does not implement the eMLPP feature, the eMLPP Priority may be considered as an unrecognizable IE.
Clear Request
The Clear Request message is sent from the BSS to the MSC to indicate to the MSC that the BSS wishes to release the associated dedicated resources. The Clear Request message is sent through the BSSAP-SCCP connection associated with the dedicated resources. Table A-14 lists the IEs of the Clear Request message. Table A-14 IEs of the Clear Request message Information Element Message Type Cause Reference 1.2.1 1.2.19 Direction BSS-MSC BSS-MSC Type M M Length 1 34
Typical cause values are as follows: Radio interface message failure
Issue 01 (2008-06-10)
A-13
O&M intervention Equipment failure Joined group call channel Protocol error between the BSS and the MSC Preemption
Clear Command
The Clear Command message is sent from the MSC to the BSS to instruct the BSS to release the associated dedicated resources. The Clear Command message is sent through the BSSAP-SCCP connection associated with the dedicated resources. Table A-15 lists the IEs of the Clear Command message. Table A-15 IEs of the Clear Command message Information Element Message Type Layer 3 Header Information Cause Reference 1.2.1 1.2.3 1.2.19 Direction MSC-BSS MSC-BSS MSC-BSS Type M O (1) M Length 1 4 34
The Layer 3 Header Information does not serve any useful purpose. MSCs should not send the IE unless it is required by the recipients owning to the need to interwork with older versions of the protocol. It is expected that in future versions of GSM Rec. 08.08, this IE is deleted from this message. Typical cause values are as follows: Call control O&M intervention Equipment failure Handover successful Protocol error between the BSS and the MSC
Classmark Request
The Classmark Request message is sent from the MSC to the BSS through the relevant SCCP connection associated with that MS transaction. It requests an update of the classmark parameters for the concerned MS. Table A-16 lists the IEs of the Classmark Request message. Table A-16 IEs of the Classmark Request message Information Element Message Type Reference 1.2.1 Direction MSC-BSS Type M Length 1
A-14
Issue 01 (2008-06-10)
Classmark Update
The Classmark Update message is sent from the BSS to the MSC or from the MSC to the BSS through the relevant SCCP connection associated with that MS transaction. It updates the classmark parameters for the concerned MS. Table A-17 lists the IEs of the Classmark Update message. Table A-17 IEs of the Classmark Update message Information Element Message Type Classmark Information Type 2 Classmark Information Type 3 Reference 1.2.1 1.2.8 1.2.23 Direction Both Both Both Type M M O (1) Length 1 45 314
The Classmark Information Type 3 is included by the BSS if it is received from the MS. It is included by the MSC if this IE is received by the MSC.
Cipher Mode Command

The Cipher Mode Command message is sent from the MSC to the BSS through the relevant SCCP connection associated with that MS transaction. It updates the encryption parameters for the concerned MS. Table A-18 lists the IEs of the Cipher Mode Command message. Table A-18 IEs of the Cipher Mode Command message Information Element Message Type Layer 3 Header Information Encryption Information Cipher Response Mode Reference 1.2.1 1.2.3 1.2.21 1.2.36 Direction MSC-BSS MSC-BSS MSC-BSS MSC-BSS Type M O (1) M O Length 1 4 3n 2
The Layer 3 Header Information does not serve any useful purpose. MSCs should not send the IE unless it is required by the recipients owing to the need to interwork with older versions of the protocol. It is expected that in future versions of GSM Rec. 08.08, this IE is deleted from this message.
Cipher Mode Complete

The Cipher Mode Complete message is sent from the BSS to the MSC through the relevant SCCP connection. It indicates that a successful cipher synchronization is achieved across the radio interface. Table A-19 lists the IEs of the Cipher Mode Complete message.
Issue 01 (2008-06-10)
A-15
Table A-19 IEs of the Cipher Mode Complete message Information Element Message Type Layer 3 Message Contents Chosen Encryption Algorithm Reference 1.2.1 1.2.37 1.2.15 Direction BSS-MSC BSS-MSC BSS-MSC Type M O O (1) Length 1 2n 2
The Chosen Encryption Algorithm is included at least when the encryption algorithm is selected by the BSS.
Cipher Mode Reject

The Cipher Mode Reject message is sent from the BSS to the MSC through the relevant SCCP connection associated with that MS transaction. It indicates that the BSS is unable to perform the requested ciphering. Table A-20 lists the IEs of the Cipher Mode Reject message. Table A-20 IEs of the Cipher Mode Reject message Information Element Message Type Cause Reference 1.2.1 1.2.19 Direction BSS-MSC BSS-MSC Type M M Length 1 34
Typical cause values are as follows: Ciphering algorithm not supported Invalid message contents
Complete Layer 3 Information

The Complete Layer 3 Information message is sent from the BSS to the MSC through the BSSAP-SCCP connection established for the associated dedicated resources. Table A-21 lists the IEs of the Complete Layer 3 Information message. Table A-21 IEs of the Complete Layer 3 Information message Information Element Message Type Cell Identifier Layer 3 Information Chosen Channel LSA Identifier List Reference 1.2.1 1.2.13 1.2.31 1.2.14 1.2.38 Direction BSS-MSC BSS-MSC BSS-MSC BSS-MSC BSS-MSC Type M M M O (1) O (2) Length 1 310 3n 2 3+3n
A-16
Issue 01 (2008-06-10)
The explanations of the IEs are as follows: The Chosen Channel is optionally used by the BSS to give the MSC a description of the channel rate/type on which the initial layer 3 message is received. The LSA Identifier List shall be included at least when the current cell belongs to one or more LSAs.
A.1.2 Signaling Element Coding

This paragraph contains the coding of the signaling elements used. The following conventions are assumed for the sequence of transmission of bits and bytes: Each bit position is marked as 1 to 8. Bit 1 is the least significant bit and is transmitted first. In element octets are identified by number, octet 1 is transmitted first, then octet 2 etc. When a field extends over more than one octet, the order of bit values progressively decreases as the octet number increases. The least significant bit of the field is represented by the lowest numbered bit of the highest numbered octet of the field. For variable length elements, a length indicator is included. The length indicator indicates the number of octets following in the element. All fields within IEs are mandatory unless otherwise specified. The IE Identifier shall always be included. All the spare bits are set to 0. The elements used and their coding are: Element Identifier Coding 0000 0001 0000 0010 0000 0011 0000 0100 0000 0101 0000 0110 0000 0111 0000 1000 0000 1001 0000 1010 0000 1011 0000 1100 0000 1101 0000 1110 0000 1111 Element Name Circuit Identity Code Reserved Resource Available Cause Cell Identifier Priority Layer 3 Header Information IMSI TMSI Encryption Information Channel Type Periodicity Extended Resource Indicator Number Of MSs Reserved
Issue 01 (2008-06-10)
A-17
Element Identifier Coding 0001 0000 0001 0001 0001 0010 0001 0011 0001 0100 0001 0101 0001 0110 0001 0111 0001 1000 0001 1001 0001 1010 0001 1011 0001 1100 0001 1101 0001 1110 0001 1111 0010 0000 0010 0001 0010 0010 0010 0011 0010 0100 0010 0101 0010 0110 0010 0111 0010 1000 0010 1001 0010 1010 0010 1011 0010 1100 0010 1101 0010 1110
Element Name Reserved Reserved Classmark Information Type 2 Classmark Information Type 3 Interference Band To Be Used RR Cause Reserved Layer 3 Information DLCI Downlink DTX Flag Cell Identifier List Response Request Resource Indication Method Classmark Information Type 1 Circuit Identity Code List Diagnostic Layer 3 Message Contents Chosen Channel Total Resource Accessible Cipher Response Mode Channel Needed Trace Type Trigger id Trace Reference Transaction id Mobile Identity OMC Id Forward Indicator Chosen Encryption Algorithm Circuit Pool Circuit Pool List
A-18
Issue 01 (2008-06-10)
Element Identifier Coding 0010 1111 0011 0000 0011 0001 0011 0010 0100 0000 0011 0011 0011 0101 0011 0110 0011 0111 0011 1000 0011 1001 0011 1010 0011 1011 0011 1100 0011 1101 0011 1110 0011 1111 0100 0011 0100 0100 0100 0101 0100 0110 0100 0111 0100 1000 0100 1001 0100 1010 0100 1011 0100 1100 0100 1101 0100 1110 0100 1111
Element Name Time Indication Resource Situation Current Channel type 1 Queuing Indicator Speech Version Assignment Requirement Talker Flag Connection Release Requested Group Call Reference eMLPP Priority Configuration Evolution Indication Old BSS to New BSS Information LSA Identifier LSA Identifier List LSA Information LCS QoS LSA access control suppression LCS Priority Location Type Location Estimate Positioning Data LCS Cause LCS Client Type APDU Network Element Identity GPS Assistance Data Deciphering Keys Return Error Request Return Error Cause Segmentation
Issue 01 (2008-06-10)
A-19
A.1.3 Message Type

Message Type uniquely identifies the message being sent. It is a single octet element, mandatory in all messages. Bit 8 is reserved for future extension of the code set. All unassigned codes are spare. 87654321 00000000 Assignment messages 00000001 00000010 00000011 Handover messages 00010000 00010001 00010010 00010011 00010100 00010101 00010110 00010111 00011000 00011001 00011010 00011011 Release messages 00100000 00100001 00100010 00100011 00100100 00100101 00100110 Clear Command Clear Complete Clear Request Reserved Reserved Sapi n Reject Confusion Handover Request Handover Required Handover Request Acknowledge Handover Command Handover Complete Handover Succeeded Handover Failure Handover Performed Handover Candidate Enquire Handover Candidate Response Handover Required Reject Handover Detect Assignment Request Assignment Complete Assignment Failure Reserved
A-20
Issue 01 (2008-06-10)
87654321 Other connection related messages 00101000 00101001 00101010 00101011 00101100 00101101 00101110 General messages 00110000 00110001 00110010 00110011 00110100 00110101 00110110 00110111 00111010 Reset Reset Acknowledge Overload Reserved Reset Circuit Reset Circuit Acknowledge MSC Invoke Trace BSS Invoke Trace Connectionless Information Suspend Resume Connection Oriented Information Perform Location Request LSA Information Perform Location Response Perform Location Abort
Terrestrial resource messages 01000000 01000001 01000010 01000011 01000100 01000101 01000110 01000111 01001000 01001110 01001111 Block Blocking Acknowledge Unblock Unblocking Acknowledge Circuit Group Block Circuit Group Blocking Acknowledge Circuit Group Unblock Circuit Group Unblocking Acknowledge Unequipped Circuit Change Circuit Change Circuit Acknowledge
Issue 01 (2008-06-10)
A-21
87654321 Radio resource messages 01010000 01010001 01010010 01010011 01010100 01010101 01010110 01010111 01011000 01011001 01011010 VGCS/VBS 00000100 00000101 00000110 00000111 00011100 00011101 00011110 00011111 00100111 01001001 01001010 01001011 01001100 01001101 VGCS/VBS Setup VGCS/VBS Setup Ack VGCS/VBS Setup Refuse VGCS/VBS Assignment Request VGCS/VBS Assignment Result VGCS/VBS Assignment Failure VGCS/VBS Queuing Indication Uplink Request Uplink Request Acknowledge Uplink Request Confirmation Uplink Release Indication Uplink Reject Command Uplink Release Command Uplink Seized Command Resource Request Resource Indication Paging Cipher Mode Command Classmark Update Cipher Mode Complete Queuing Indication Complete Layer 3 Information Classmark Request Cipher Mode Reject Load Indication
Channel Type
This element contains all of the information that the BSS requires to determine the required radio resources.
A-22
Issue 01 (2008-06-10)
The channel type IE has a minimum length of 5 octets and a maximum length of 10 octets. It is coded as follows: 8 7 6 5 4 3 2 1 Octet 1 Octet 2 Speech/data indicator Octet 3 Octet 4 Octet 5 or octet 5 with extension*
Element identifier Length Spare Channel rate and type Permitted speech version indication / data rate + transparency indicator
* If the speech / data indicator (octet 3) indicates "speech" or data, octet 5 may be extended. Otherwise, octet 5 shall not be extended.
The "speech/data indicator" field is coded as follows: 0001 0010 0011 Speech Data Signaling
All other values are reserved. For values 0001 and 0010, a dedicated terrestrial resource is also required. The "channel rate and type" is coded as follows: If octet 3 indicates data then octet 4 shall be coded as: 0000 1000 0000 1001 Full rate TCH channel Bm Half rate TCH channel Lm
0000 1010 Full or Half rate TCH channel, Full rate preferred, changes allowed also after first channel allocation as a result of the request. 0000 1011 Full or Half rate TCH channel, Half rate preferred, changes allowed also after first channel allocation as a result of the request. 0001 1010 Full or Half rate TCH channel, Full rate preferred, changes not allowed after first channel allocation as a result of the request. 0001 1011 Full or Half rate TCH channel. Half rate preferred, changes not allowed after first channel allocation as a result of the request. 0010 0xxx Full rate TCH channels in a multislot configuration, changes by the BSS of the number of TCHs and if applicable the used radio interface rate per channel allowed after first channel allocation as a result of the request. 0011 0xxx Full rate TCH channels in a multislot configuration, changes by the BSS of the number of TCHs or the used radio interface rate per channel not allowed after first channel allocation as a result of the request. xxx (bits 3-1) indicates maximum number of traffic channels. 321 000 1 TCHs 001 2 TCHs
Issue 01 (2008-06-10)
A-23
010 3 TCHs 011 4 TCHs 100 5 TCHs 101 6 TCHs 110 7 TCHs 111 8 TCHs All other values are reserved. If octet 3 indicates speech, then octet 4 shall be coded as: 0000 1000 Full rate TCH channel Bm. Preference between the permitted speech versions for full rate TCH as indicated in octet 5, 5a etc.. 0000 1001 Half rate TCH channel Lm. Preference between the permitted speech versions for half rate TCH as indicated in octet 5, 5a etc.. 0000 1010 Full or Half rate TCH channel, Full rate preferred, changes between full rate and half rate allowed also after first channel allocation as a result of the request. Preference between the permitted speech versions for the respective channel rates as indicated in octet 5, 5a etc. 0000 1011 Full or Half rate TCH channel, Half rate preferred, changes between full rate and half rate allowed also after first channel allocation as a result of the request. Preference between the permitted speech versions for the respective channel rates as indicated in octet 5, 5a etc. 0001 1010 Full or Half rate TCH channel, Full rate preferred, changes between full rate and half rate not allowed after first channel allocation as a result of the request. Preference between the permitted speech versions for the respective channel rates as indicated in octet 5, 5a etc. 0001 1011 Full or Half rate TCH channel. Half rate preferred, changes between full rate and half rate not allowed after first channel allocation as a result of the request. Preference between the permitted speech versions for the respective channel rates as indicated in octet 5, 5a etc. 0000 1111 Full or Half rate TCH channel. Preference between the permitted speech versions as indicated in octet 5, 5a etc., changes between full and half rate allowed also after first channel allocation as a result of the request 0001 1111 Full or Half rate TCH channel. Preference between the permitted speech versions as indicated in octet 5, 5a etc., changes between full and half rate not allowed after first channel allocation as a result of the request All other values are reserved. If octet 3 indicates signaling then octet 4 shall be coded as: 0000 0000 0000 0001 0000 0010 0000 0011 0000 1000 0000 1001 0000 1010 SDCCH or Full rate TCH channel Bm or Half rate TCH channel Lm SDCCH SDCCH or Full rate TCH channel Bm SDCCH or Half rate TCH channel Lm Full rate TCH channel Bm Half rate TCH channel Lm Full or Half rate TCH channel, Full rate preferred, changes allowed also after first channel allocation as a result of the request.
A-24
Issue 01 (2008-06-10)
0000 1011
Full or Half rate TCH channel, Half rate preferred, changes allowed also after first channel allocation as a result of the request.
0001 1010
Full or Half rate TCH channel, Full rate preferred, changes not allowed after first channel allocation as a result of the request.
0001 1011
Full or Half rate TCH channel. Half rate preferred, changes not allowed after first channel allocation as a result of the request.
All other values are reserved. The "permitted speech version indication / data rate + transparency indicator" octet is coded as follows: If octet 3 indicates speech, then octet 5 shall be coded as follows: 8 ext ext ext ext ext 0 7 6 5 4 3 2 1 Octet 5 Octet 5a Octet 5b Octet 5c Octet 5d Octet 5e
permitted speech version identifier permitted speech version identifier permitted speech version identifier permitted speech version identifier permitted speech version identifier permitted speech version identifier
Bit 8 indicates extension of octet 5. 0 1 no extension, that is, value "0" indicates that this octet is the last octet. extension, that is, value "1" indicates that at least one additional octet is included.
If more than one permitted speech version is indicated by octet 5 (with extension), then the speech version choice is left to the BSS. Bits 7-1 indicate the permitted speech version identifier; 765 4321 000 0001 GSM speech full rate version 1 001 0001 GSM speech full rate version 2 010 0001 GSM speech full rate version 3 000 0101 GSM speech half rate version 1 001 0101 GSM speech half rate version 2 010 0101 GSM speech half rate version 3
Issue 01 (2008-06-10)
A-25
Bits 7-1 indicate six speech versions. The GSM speech full rate version 3 is also referred as the adaptive multi-rate full rate speech version 1 The GSM speech half rate version 3 is also referred as the adaptive multi-rate half rate speech version 1
All other values of permitted speech version identifiers are for future use. If an unknown value is received and more than one octet 5 is received, the sender expects the receiver to behave as if it makes a choice of speech version. The rules for coding preferences in octet 5 and 5a5e are the following: In those cases when one specific channel rate is indicated in octet 4, the non-empty set of permitted speech versions is included. Within this set, the permitted speech versions are included in order of speech version preferences. In those cases when a preference for a channel rate is indicated in octet 4, the non-empty sets of permitted speech versions for the respective channel rate are included in order of the channel rate preferences indicated in octet 4. Within a set of permitted speech versions for a channel rate, the permitted speech versions are included in order of speech version preferences. In those cases when no preference or specific channel rate is indicated in octet 4, the permitted speech versions are included in order of speech version preferences. Octet 5 always has the highest preference followed by octet 5a. For each channel rate allowed by octet 4, at least one speech version shall be present. If octet 5 indicates no extension and bits 71 is coded "000 0001", then the preference is interpreted based on the octet 4 value as follows: When octet 4 indicates one specific channel rate, then speech version 1 for the indicated channel rate is permitted. When octet 4 indicates a preference for a channel rate, then speech version 1 for any of the allowed channel rates is permitted. When octet 4 does neither indicate a preference for a channel rate nor a specific channel rate, then speech version 1 for any of the allowed channel rates is permitted and speech full rate version 1 is preferred. If octet 3 indicates data, and octet 4 does not indicate multislot configuration, then octet 5 shall be coded as follows: 8 ext ext 7 T/NT spare 6 Rate allowed radio interface rates 5 4 3 2 1 Octet 5 Octet 5a
Bit 8 indicates extension of octet 5. 0 1 no extension, that is, value "0" indicates that this octet is the last octet. extension, that is, value "1" indicates that at least one additional octet is included.
Bit 7: 0 Transparent service
A-26
Issue 01 (2008-06-10)
Non-transparent service
For non-transparent service bits 6-1 indicate the radio interface data rate. 65 4321 00 0000 12 kbit/s if the channel is a full rate TCH, or 6 kbit/s if the channel is a half rate TCH 01 1000 14.5 kbit/s 01 0000 12 kbit/s 01 0001 6 kbit/s
If bit 7 in octet 5 indicates non-transparent service and octet 5a is included, the rate in octet 5 indicates the wanted data rate on the air interface and the allowed r i/f rates indicates the other possible data rates allowed. All other values are reserved. For transparent service, bits 6-1 indicate the data rate. 65 4321 01 1000 14.4 kbit/s 01 0000 9.6 kbit/s 01 0001 4.8 kbit/s 01 0010 2.4 kbit/s 01 0011 1.2 kbit/s 01 0100 600 bit/s 01 0101 1200/75 bit/s (1200 network-to-MS / 75 MS-to-network) If bit 7 in octet 5 indicates transparent service octet 5 shall not be extended. All other values are reserved. Octet 5a shall be coded as follows: Bit 8 reserved for extension. A coding of 0 indicates no extension Bits 4 to 1 indicate allowed data rate on the radio interface, per channel: Bit 4: 0 14.5 kbit/s (TCH/F14.4) not allowed 1 14.5 kbit/s (TCH/F14.4) allowed Bit 3: Bit 2: Spare 0 12.0 kbit/s (TCH/F9.6) not allowed 1 12.0 kbit/s (TCH/F9.6) allowed Bit 1: 0 6.0 kbit/s (TCH/F4.8) not allowed 1 6.0 kbit/s (TCH/F4.8) allowed
Issue 01 (2008-06-10)
A-27
If octet 3 indicates data and octet 4 indicates full-rate TCH channels in a multislot configuration, octet 5 and 5a shall be coded as follows. 8 ext ext 7 T/NT spare 6 Rate allowed radio interface rates 5 4 3 2 1 Octet 5 Octet 5a
Octet 5 shall be coded as follows. Bit 8: extension bit
0 indicates no extension 1 indicates that at least one additional octet is included Bit 7: 0 1 Transparent service Non-transparent service.
For non-transparent service, bits 6-1 indicate wanted total data rate on the radio interface. 65 4321 01 0110 58 kbit/s (4x14.5 kbit/s) 01 0100 01 0011 01 0010 01 0001 01 0000 48.0 / 43.5 kbit/s (4x12 kbit/s or 3x14.5 kbit/s) 36.0 / 29.0 kbit/s (3x12 kbit/s or 2x14.5 kbit/s) 24.0 / 24.0 (4x6 kbit/s or 2x12 kbit/s) 18.0 / 14.5 kbit/s (3x6 kbit/s or 1x14.5 kbit/s) 12.0 / 12.0 kbit/s (2x6 kbit/s or 1x12 kbit/s)
All other values are reserved. For transparent service, bits 61 indicate requested user rate on the air interface. 65 4321 01 1111 01 1110 01 1101 01 1011 01 1001 01 1000 01 0000 64 kbit/s, bit transparent 56 kbit/s, bit transparent 56 kbit/s 38.4 kbit/s 19.2 kbit/s 14.4 kbit/s 9.6 kbit/s
01 1100 48 kbit/s 01 1010 28.8 kbit/s
All other values are reserved. Octet 5a shall be coded as follows. Bit 8 reserved for extension. A coding of 0 indicates no extension.
Bits 4 to 1 indicate allowed data rate per channel on the radio interface.
A-28
Issue 01 (2008-06-10)
Bit 4:
14.5/14.4 kbit/s (TCH/F14.4) not allowed 1 14.5/14.4 kbit/s (TCH/F14.4) allowed
Bit 3: Bit 2: 0
Spare 12.0/9.6 kbit/s (TCH F/9.6) not allowed 1 12.0/9.6 kbit/s (TCH F/9.6) allowed
Bit 1:
6.0/4.8 kbit/s (TCH F/4.8) not allowed 1 6.0/4.8 kbit/s (TCH F/4.8) allowed
If octet 5a is not included, allowance of data rates of 12 kbit/s and 6 kbit/s on the radio interface shall be presumed.
For data services, the information in the channel type is used to set the "E-bits" and map the "D-bits" (as described in GSM Rec. 04.21 and 08.20) and to select the correct channel coding.
If octet 3 indicates signaling, then octet 5 is spare. Layer 3 Header Information This element is used to supply the BSS with information that needs to be included in the header of layer 3 messages over the radio interface. 8 7 6 5 4 3 2 1 Octet 1 Octet 2 Octet 3 Octet 4
Element identifier Length Protocol discriminator Transaction identifier
The length indicator is a binary indication of the number of octets following in the element. The transaction identifier and protocol discriminator fields are coded as defined in GSM Rec. 04.08. The protocol discriminator occupies bit 1 to 4 in octet 3 of the Layer 3 header information, the Transaction identifier occupies bit 1 to 4 in octet 4 of the Layer 3 header information. Priority This element indicates the priority of the request. It is coded as follows: 8 7 6 5 4 3 2 1 Octet 1 Octet 2 Octet 3
Element identifier Length Priority
Octet 2 is a binary indication of the length of the rest of the element.
Issue 01 (2008-06-10)
A-29
Octet 3 is coded as follows: 8 spare 7 pci 6 5 4 3 2 qa 1 pvi Octet 1
priority level
Bit 8 is spare, set to 0 pci = Preemption Capability indicator (see note) 0 1 this allocation request shall not preempt an existing connection. this allocation request may preempt an existing connection.
priority level: 6543 0000 0001 0010 1110 1111 spare priority level 1 = highest priority priority level 2 = second highest priority priority level 14 = lowest priority priority not used
qa = queuing allowed indicator 0 1 queuing not allowed queuing allowed (see note)
pvi = Preemption Vulnerability indicator 0 1
this connection shall not be preempted by another allocation request. this connection might be preempted by another allocation request.
Preemption Capability indicator applies to the allocation of resources for an event and as such it provides the trigger to the preemption procedures/processes of the BSS. Preemption Vulnerability indicator applies for the entire duration of a connection and as such indicates whether the connection is a target of the preemption procedures/processes of the BSS.
Circuit Identity Code This element defines the terrestrial channel over which the call passes. If a 2048 Kbits/s digital path is used, then the circuit identification code contains in the 5 least significant bits a binary representation of the actual number of the timeslot that is assigned to the circuit. The remaining bits in the CIC are used where necessary, to identify one among several systems interconnecting an originating and destination point. The element is 2 octets in length: 8 7 6 5 4 3 2 1 octet 1
Element identifier
A-30
Issue 01 (2008-06-10)
8 a i
7 b j
6 c k
5 d X
4 e X
3 f X
2 g X
1 h X octet 2 octet 3
a-k defines the PCM multiplex in use. XXXXX define the actual timeslot in use. The circuit identity code defines the PCM multiplex and timeslot in use on the MSC side. In cases where remultiplexing takes place between the MSC and the BSS a translation may be necessary on the BSS side. If a 1544 kbit/s digital path is used, then the format of the circuit identity code (CIC) shall be as shown below: The element is 2 octets in length: 8 7 6 5 4 3 2 1 Octet 1 Octet 2 Octet 3
Element identifier CIC (least significant bits) CIC (most significant bits)
Downlink DTX Flag A fixed length element indicating whether the DTX function in the BSS is disabled on a particular radio channel. 8 7 6 5 4 3 2 1 Octet 1 Octet 2
Element identifier Downlink DTX flag
The Downlink DTX Flag is coded as follows: bits 8 to 2 are spare.
bit 1 is set to one if the MSC forbids the BSS to activate DTX in the downlink direction; it is set to 0 otherwise. Interference Band to Be Used This fixed length element is coded as follows: 8 7 6 5 4 3 2 1 Octet 1 Octet 2
Element identifier Band to be used
Issue 01 (2008-06-10)
A-31
Octet 2 is coded as: Bits 876 Spare Bits 54321 A bit map indicating which interference bands are acceptable, the LSB represents the least level of interference. Classmark Information Type 2 The classmark information type 2 defines certain attributes of the mobile station equipment in use on a particular transaction. It is coded as follows: 8 7 6 5 4 3 2 1 Octet 1 Octet 2 Octet 3 - 5
Element identifier Length Classmark
Octet 2 is a binary indication of the length of the remainder of the element in octets. The length shall be determined by the length of the Mobile Station Classmark 2 element of GSM Rec. 04.08. The classmark octets 3, 4, and 5 are coded in the same way as the equivalent octets in the Mobile station classmark 2 element of GSM Rec. 04.08. Group Call Reference It is coded as follows: 8 7 6 5 4 3 2 1 Octet 1 Octet 2 Octet 3 - 8
Element identifier Length Descriptive group or broadcast call reference
Octet 2 is a binary indication of the length of the remainder of the element in octets. Octets 38 are coded in the same way as octets 26 in the Descriptive group or broadcast call reference IE as defined in GSM Rec. 04.08. Talker Flag 8 7 6 5 4 3 2 1 Octet 1
Element identifier
LSA Access Control Suppression
A-32
Issue 01 (2008-06-10)
This IE is included if LSA access control function shall be suppressed in the BSS. It is coded as follows: 8 7 6 5 4 3 2 1 Octet 1 EM Octet 2
Element identifier spare
If the connection is an emergency call, the MSC shall set the emergency field (bit 1 of octet 2) to 1. If the emergency field is set to 1, the BSS shall suppress exclusive access, LSA only access and preferential access functionality. RR Cause This fixed length element is passed from the radio interface to the MSC transparently, when received in a message that complies with GSM Rec. 04.08. 8 7 6 5 4 3 2 1 Octet 1 Octet 2
Element identifier RR cause
Octet 2 is coded as the equivalent field from GSM Rec. 04.08. Cell Identifier This element uniquely identifies a cell within a BSS and is of variable length containing the following fields: 8 7 6 5 4 3 2 1 Octet 1 Octet 2 Cell identification discriminator Octet 3 Octet 4n
Element identifier Length Spare Cell identification
The coding of octet 2 is a binary number indicating the length of the remaining element. The length depends on the Cell identification discriminator (octet 3). The coding of "Cell identification discriminator" (bits 1 to 4 of octet 3) is a binary number indicating if the whole or a part of Cell Global Identification, CGI, according to GSM Rec. 03.03 is used for cell identification in octet 4n. The "Cell identification discriminator" is coded as follows: 0000 0001 0010 The whole Cell Global Identification, CGI, is used to identify the cell. Location Area Code, LAC, and Cell Identity, CI, is used to identify the cell. Cell Identity, CI, is used to identify the cell.
Issue 01 (2008-06-10)
A-33
0011
No cell is associated with the transaction.
All other values are reserved. The coding of octets 4n depends on the Cell identification discriminator (octet 3). Below the coding is shown for each Cell identification discriminator: Note that no coding is specified for a Cell identification discriminator value of "0011" as no additional information is required. Coding of Cell Identification for Cell identification discriminator = 0000 For GSM 900 and DCS 1800: 8 7 6 5 4 3 2 1 Octet 4 Octet 5 Octet 6 Octet 7 Octet 8 Octet 9 Octet 10
MCC dig 2 1 1 1 1
MCC dig 1 MCC dig 3 MNC dig 1
MNC dig 2 LAC LAC cont. CI value CI value cont
Octets 48 are coded as shown in GSM Rec. 04.08, Table Location Area Identification information element. Octets 910 are coded as shown in GSM Rec. 04.08, Table Cell Identity information element. For PCS 1900 for NA: 8 7 6 5 4 3 2 1 Octet 4 Octet 5 Octet 6 Octet 7 Octet 8 Octet 9 Octet 10
MCC dig 2 MNC dig 3 MNC dig 2 LAC LAC cont. CI value CI value cont
Octets 48 are coded as shown in GSM Rec. 04.08, Table Location Area Identification information element.
A-34
Issue 01 (2008-06-10)
Octets 910 are coded as shown in GSM Rec. 04.08, Table Cell Identity information element. Coding of Cell Identification for Cell identification discriminator = 0001 8 LAC LAC cont. CI value CI value cont. 7 6 5 4 3 2 1 Octet 4 Octet 5 Octet 6 Octet 7
Coding of Cell Identification for Cell identification discriminator = 0010 8 CI value CI value cont. 7 6 5 4 3 2 1 Octet 4 Octet 5
Octets 45 are coded as shown in GSM Rec. 04.08, Table Cell Identity information element Chosen Channel This IE contains a description of the channel allocated to the MS. For VGCS/VBS calls, this IE contains a description of the channel allocated for the call in the cell. It is coded as follows: 8 7 6 5 4 3 2 1 Octet 1 Channel Octet 2
Element identifier Channel mode
The channel mode field is coded as follows: Bit 8765 0000 1001 no channel mode indication speech (full rate or half rate)
1110 data, 14.5 kbit/s radio interface rate 1011 data, 12.0 kbit/s radio interface rate 1100 data, 6.0 kbit/s radio interface rate 1101 data, 3.6 kbit/s radio interface rate
Issue 01 (2008-06-10)
A-35
1000
signaling only
All other values are reserved. The channel field is coded as follows: Bit 4321 0000 0001 1000 1001 1010 None (Note *) SDCCH 1 Full rate TCH 1 Half rate TCH 2 Full Rate TCHs
1011 3 Full Rate TCHs 1100 4 Full Rate TCHs 1101 5 Full Rate TCHs 1110 6 Full Rate TCHs 1111 7 Full Rate TCHs 0100 8 Full Rate TCHs
All other values are reserved.

*: This value may be returned in the chosen channel information for VGCS/VBS calls in the case where the BSS decides to de-allocate resources or allocate no resources for the call.
Chosen Encryption Algorithm This element indicates the encryption algorithm that is used by the BSS. It is coded as follows: 8 7 6 5 4 3 2 1 Octet 1 Octet 2
Element identifier Algorithm identifier
The algorithm identifier caters for the possible future introduction of different user-data encryption algorithms. It is coded as follows: 0000 0001 0000 0010 0000 0011 0000 0100 0000 0101 0000 0110 No encryption used GSM user data encryption version 1(A5/1). GSM A5/2 GSM A5/3 GSM A5/4 GSM A5/5
A-36
Issue 01 (2008-06-10)
0000 0111 0000 1000
GSM A5/6 GSM A5/7
All other values are reserved for future international use. Circuit Pool This element indicates the circuit pool of a circuit or group of circuits. It is coded as follows: 8 7 6 5 4 3 2 1 Octet 1 Octet 2
Element identifier Circuit pool number
Predefined circuit pools are currently Circuit pool number 1 to Circuit pool number 32. The circuit pool element is coded as follows (along with the definition of the predefined circuit pools): Coding 0000 0001 Pool Circuit pool number 1 Circuit pool number 2 Circuit pool number 3 Supported Channels and Speech Coding Algorithms FR speech version 1 FR data (12, 6, 3.6 kbit/s) HR speech version 1 HR data (6, 3.6 kbit/s) FR speech version 1 FR data (12, 6, 3.6 kbit/s) HR speech version 1 HR data (6, 3.6 kbit/s) 0000 0100 Circuit pool number 4 Circuit pool number 5 FR speech version 2 FR data (12, 6, 3.6 kbit/s) FR speech version 1 FR speech version 2 FR data (12, 6, 3.6 kbit/s) 0000 0110 Circuit pool number 6 FR speech version 2 FR data (12, 6, 3.6 kbit/s) HR speech version 1 HR data (6, 3.6 kbit/s)
0000 0010
0000 0011
0000 0101
Issue 01 (2008-06-10)
A-37
Coding 0000 0111
Pool Circuit pool number 7
Supported Channels and Speech Coding Algorithms FR speech version 1 FR speech version 2 FR data (12, 6, 3.6 kbit/s) HR speech version 1 HR data (6, 3.6 kbit/s)
0000 1000 0000 1001
Circuit pool number 8 Circuit pool number 9
HSCSD max 2 x FR data (12, 6 kbit/s) FR data (12, 6, 3.6 kbit/s) HR data (6, 3.6 kbit/s) HSCSD max 2 x FR data (12, 6 kbit/s)
0000 1010
Circuit pool number 10
FR speech version 1 FR speech version 2 FR data (12, 6, 3.6 kbit/s) HR speech version 1 HR data (6, 3.6 kbit/s) HSCSD max 2 x FR data (12, 6 kbit/s)
0000 1011 0000 1100
HSCSD max 4 x FR data (12, 6 kbit/s) FR data (12, 6, 3.6 kbit/s) HR data (6, 3.6 kbit/s) HSCSD max 4 x FR data (12, 6 kbit/s)
0000 1101
FR speech version 1 FR speech version 2 FR data (12, 6, 3.6 kbit/s) HR speech version 1 HR data (6, 3.6 kbit/s) HSCSD max 4 x FR data (12, 6 kbit/s)
0000 1110 0000 1111 0001 0000 0001 0001 0001 0010
Circuit pool number 14 Circuit pool number 15 Circuit pool number 16 Circuit pool number 17 Circuit pool number 18
HSCSD max 6 x FR data (12, 6 kbit/s) FR data (14.5 kbit/s) HSCSD max 2 x FR data (14.5 kbit/s) HSCSD max 4 x FR data (14.5 kbit/s) FR data (14.5, 12, 6, 3.6 kbit/s) HR data (6, 3.6 kbit/s) HSCSD max 2 x FR data (14.5, 12, 6 kbit/s)
A-38
Issue 01 (2008-06-10)
Coding 0001 0011
Supported Channels and Speech Coding Algorithms FR data (14.5, 12, 6, 3.6 kbit/s) HR data (6, 3.6 kbit/s) HSCSD max 4 x FR data (14.5, 12, 6 kbit/s)
0001 0100
FR speech version 1 FR speech version 2 FR data (14.5, 12, 6, 3.6 kbit/s) HR speech version 1 HR data (6, 3.6 kbit/s)
0001 0101
FR speech version 1 FR speech version 2 FR data (14.5, 12, 6, 3.6 kbit/s) HR speech version 1 HR data (6, 3.6 kbit/s) HSCSD max 2 x FR data (14.5, 12, 6 kbit/s)
0001 0110
FR speech version 1 FR speech version 2 FR data (14.5, 12, 6, 3.6 kbit/s) HR speech version 1 HR data (6, 3.6 kbit/s) HSCSD max 4 x FR data (14.5, 12, 6 kbit/s)
0001 0111
FR speech version 3 HR speech version 3 FR speech version 3 FR data (12, 6, 3.6 kbit/s) HR speech version 3
0001 1000
0001 1001
FR speech version 1 FR speech version 2 FR speech version 3 FR data (12, 6, 3.6 kbit/s) HR speech version 3
0001 1010
FR speech version 1 FR speech version 2 FR speech version 3 FR data (14.5, 12, 6, 3.6 kbit/s) HR speech version 3
Issue 01 (2008-06-10)
A-39
Coding 0001 1011
Supported Channels and Speech Coding Algorithms FR speech version 1 FR speech version 2 FR speech version 3 FR data (12, 6, 3.6 kbit/s) HR speech version 1 HR speech version 3 HR data (6, 3.6 kbit/s)
0001 1100
FR speech version 1 FR speech version 2 FR speech version 3 FR data (14.5, 12, 6, 3.6 kbit/s) HR speech version 1 HR speech version 3 HR data (6, 3.6 kbit/s)
0001 1101
FR speech version 1 FR speech version 2 FR speech version 3 FR data (12, 6, 3.6 kbit/s) HR speech version 1 HR speech version 3 HR data (6, 3.6 kbit/s) HSCSD max 2 x FR data (12, 6 kbit/s)
0001 1110
FR speech version 1 FR speech version 2 FR speech version 3 FR data (14.5, 12, 6, 3.6 kbit/s) HR speech version 1 HR speech version 3 HR data (6, 3.6 kbit/s) HSCSD max 2 x FR data (14.5, 12, 6 kbit/s)
0001 1111
FR speech version 1 FR speech version 2 FR speech version 3 FR data (12, 6, 3.6 kbit/s) HR speech version 1 HR speech version 3 HR data (6, 3.6 kbit/s) HSCSD max 4 x FR data (12, 6 kbit/s)
A-40
Issue 01 (2008-06-10)
Coding 0010 0000
Supported Channels and Speech Coding Algorithms FR speech version 1 FR speech version 2 FR speech version 3 FR data (14.5, 12, 6, 3.6 kbit/s) HR speech version 1 HR speech version 3 HR data (6, 3.6 kbit/s) HSCSD max 4 x FR data (14.5, 12, 6 kbit/s)
1000 xxxx
For national/local use All other values are Reserved for future international use
Speech Version This element indicates the speech version that is used by the BSS. It is coded as follows: 8 7 6 5 4 3 2 1 Octet 1 Octet 2
Element identifier spare Circuit pool number
Bits 71 of octet 2 is coded in the same way as the permitted speech version identifier in the Channel type IE. LSA Identifier This element uniquely identifies a LSA and is of fixed length containing the following fields: 8 7 6 5 4 3 2 1 Octet 1 Octet 2 Octet 3 Octet 4 Octet 5
Element identifier Length LSA ID LSA ID cont. LSA ID cont.
Octets 35 are coded as specified in GSM Rec. 03.03, Identification of Localized Service Area. Bit 8 of octet 3 is the MSB.
Issue 01 (2008-06-10)
A-41
Cause The cause element is used to indicate the reason for a particular event to occur and is coded as shown below. The cause value is a single octet element if the extension bit (bit 8) is set to 0. If it is set to 1 then the cause value is a 2-octet field. If the value of the first octet of the cause field is 1XXX 0000 then the second octet is reserved for national applications, (XXX still indicates the class). 8 7 6 5 4 3 2 1 Octet 1 Octet 2 Octet 3 (Octet 4)
Element identifier Length 0/1 ext Cause Value
The length indicator is a binary representation of the length of the following element. Cause Value: Class (000): Class (001): Class (010): Class (011): Class (100): Class (101): Class (110): Class (111): Normal event Normal event Resource unavailable Service or option not available Service or option not implemented invalid message (for example, parameter out of range) protocol error interworking
In the following table, "reserved for international use" means that this code point should not be used until a meaning is assigned to it following the process of international standardization. "Reserved for national use" indicates code points that may be used by operators without the need for international standardization. Cause Value Class 765 000 000 000 000 000 Value 4321 0000 0001 0010 0011 0100 Radio interface message failure Radio interface failure Uplink quality Uplink strength Downlink quality Cause Number
A-42
Issue 01 (2008-06-10)
Cause Value Class 765 000 000 000 000 000 000 000 000 000 000 000 001 ::: 001 001 ::: 001 010 010 010 010 010 010 010 010 010 010 010 Value 4321 0101 0110 0111 1000 1001 1010 1011 1100 1101 1110 1111 0000 :::: 0111 1000 :::: 1111 0000 0001 0010 0011 0100 0101 0110 0111 1000 1001 1010
Cause Number
Downlink strength Distance O&M intervention Response to MSC invocation Call control Radio interface failure, reversion to old channel Handover successful Better Cell Directed Retry Joined group call channel Traffic } } Reserved for international use } } } Reserved for national use } Equipment failure No radio resource available Requested terrestrial resource unavailable CCCH overload Processor overload BSS not equipped MS not equipped Invalid cell Traffic Load Preemption }
Issue 01 (2008-06-10)
A-43
Cause Value Class 765 ::: 010 011 011 011 011 011 011 011 011 100 100 100 100 100 100 100 101 101 101 101 101 101 101 101 101 101 101 Value 4321 :::: 1111 0000 0001 0010 0011 0100 0101 :::: 1111 0000 0001 :::: 0111 1000 :::: 1111 0000 0001 0010 0011 0100 0101 0110 0111 1000 :::: 1111
Cause Number
} Reserved for national use } Requested transcoding/rate adaption unavailable Circuit pool mismatch Switch circuit pool Requested speech version unavailable LSA not allowed } } Reserved for international use } Ciphering algorithm not supported } } Reserved for international use } } } Reserved for national use } Terrestrial circuit already allocated Invalid message contents Information element or field missing Incorrect value Unknown Message type Unknown IE } } Reserved for international use } }Reserved for national use }
A-44
Issue 01 (2008-06-10)
Cause Value Class 765 110 110 110 110 110 110 110 110 111 111 111 111 111 111 Value 4321 0000 0001 0010 :::: 0111 1000 :::: 1111 0000 :::: 0111 1000 :::: 1111
Cause Number
Protocol Error between BSS and MSC VGCS/VBS call non existent } } Reserved for international use } } } Reserved for national use } } } Reserved for international use } } } Reserved for national use }
Circuit Pool List This element defines a list of BSS preferred circuit pools in order of preference. It is coded as follows: 8 7 6 5 4 3 2 1 Octet 1 Octet 2 Octet 3
Element identifier Length Circuit pool number (1st preferred) : Circuit pool number (nth preferred)
Octet n+2
The Circuit pool number is coded as specified in 1.2.16. Encryption Information This element contains the user data encryption information used to control any encryption equipment on the BSS side.
Issue 01 (2008-06-10)
A-45
It is a variable length element. It is coded as follows: 8 7 6 5 4 3 2 1 Octet 1 Octet 2 Octet 3 Octet 4-n
Element identifier Length Permitted algorithms Key
The length indicator (octet 2) is a binary number that indicates the absolute length of the contents after the length indicator octet. The permitted algorithms octet is a bit map that indicates the A5 encryption algorithms and no encryption. From this bit map, the BSS may select an A5 algorithm or no encryption to be used. Bit No 1 2 3 4 5 6 7 8 No encryption GSM A5/1 GSM A5/2 GSM A5/3 GSM A5/4 GSM A5/5 GSM A5/6 GSM A5/7
A bit position encoded as 1 indicates that the BSS may use the option represented by that bit position. A bit position encoded as 0 indicates that the BSS shall not use the option represented by that bit position. A permitted algorithms octet containing all bits encoded as 0 shall not be used. The key shall be present if at least one of the A5 encryption algorithms is permitted. When present, the key shall be 8 octets long. Classmark Information Type 1 The classmark information type 1 defines certain attributes of the mobile station equipment in use on a particular transaction. It is coded as follows: 8 7 6 5 4 3 2 1 Octet 1 Octet 2
Element identifier Classmark
A-46
Issue 01 (2008-06-10)
The classmark octet 2 is coded in the same way as the equivalent octet in the classmark 1 element of GSM Rec. 04.08. Classmark Information Type 3 The classmark information type 3 defines certain attributes of the mobile station equipment in use on a particular transaction. It is coded as follows: 8 7 6 5 4 3 2 1 Octet 1 Octet 2 Octet 3-14
Element identifier Length Classmark
Octet 2 is a binary indication of the length of the remainder of the element in octets. The length octet has a minimum value of 1 and a maximum of 12. The length shall be determined by the length of the Mobile Station Classmark 3 element of GSM Rec. 04.08. The classmark octets 3 to 14 are coded in the same way as the equivalent octets in the Mobile station classmark 3 element of GSM Rec. 04.08. Current Channel Type 1 This IE contains a description of the channel allocated to the MS. It is coded as follows: 8 7 6 5 4 3 2 1 Octet 1 Channel Octet 2
Element identifier Channel mode
The channel mode field is coded as follows: Bit 8765 0000 0001 0110 0011 0100 0101 signaling only speech (full rate or half rate) data, 14.5 kbit/s radio interface rate data, 12.0 kbit/s radio interface rate data, 6.0 kbit/s radio interface rate data, 3.6 kbit/s radio interface rate
1111is reserved All other values are for future use. If the receiver receives an unknown channel mode, it shall not be rejected but the receiver shall assume that the channel mode is changed. The channel field is coded as follows:
Issue 01 (2008-06-10)
A-47
Bit 4321 0001 SDCCH 1000 1 Full rate TCH 1001 1 Half rate TCH 1010 2 Full Rate TCHs 1011 3 Full Rate TCHs 1100 4 Full Rate TCHs 1101 5 Full Rate TCHs 1110 6 Full Rate TCHs 11117 Full Rate TCHs 0100 8 Full Rate TCHs 0000 is reserved
All other values are for future use. If the receiver receives an unknown channel field, it shall not be rejected but the receiver shall assume that the channel is changed. Consistencies between channel fields and channel modes shall not be checked. LSA Information This element uniquely identifies LSAs, the priority, the preferential access indicator, and the active mode support indicator of each LSA. The access right outside these LSAs is also defined. The element is of variable length containing the following fields: 8 7 6 5 4 3 2 1 Octet 1 Octet 2 LSA only Octet 3 Octet 4-7
Element identifier Length spare LSA identification and attributes 1 : LSA identification and attributes n
to 3+4n
The coding of octet 2 is a binary number that indicates the length of the remaining element. The length depends on the number of LSAs to be identified. If the LSA only access indicator (bit 1 of octet 3) is set to 1, the subscriber has only access to the LSAs that are defined by the LSA. The LSA only access indicator is set to 0 for allowing an emergency call. Coding of the i-th LSA identification with attributes: 8 spare LSA ID LSA ID cont. LSA ID cont. 7 6 act 5 pref 4 priority 3 2 1 Octet x+1 Octet x+2 Octet x+3 Octet x+4
A-48
Issue 01 (2008-06-10)
Where x = 3 + 4(i-1) Bits 1 to 4 of octet (x+1) define the priority of the LSA identification. Bit 4321 0000 0001 :::: priority 16 = highest priority If the preferential access indicator (bit 5 of octet (x+1)) is set to 1 the subscriber has preferential access in the LSA. If the active mode support indicator (bit 6 of octet (x+1)) is set to 1 the subscriber has active mode support in the LSA. The octets (x+2)(x+4) are coded as specified in GSM Rec. 03.03, Identification of Localized Service Area. Bit 8 of octet (x+2) is the MSB. Old BSS to New BSS information This IE is defined as a general container for passing Field Elements transparently between BSSs through the MSC. These Field Elements are passed in the Old BSS to New BSS information elements octet field. 8 7 6 5 4 3 2 1 Octet 1 Octet 2 Octet 3-n priority 1 = lowest priority priority 2 = second lowest priority
Element identifier Length Old BSS to New BSS information elements
The length indicator (octet 2) is a binary number that indicates the absolute length of the contents after the length indicator octet and may be set to zero. The Old BSS to New BSS information elements field is made up of 0 or more Field Elements listed in the table shown below. Field elements may occur in any order in the Old BSS to New BSS information elements field. The construction of the Field Elements allows the receiver to ignore unknown Field Elements. Due to backward compatibility issues, Field Elements in the Old BSS to New BSS information may duplicate the IEs in the Handover Request. When the duplication occurs and the new BSS detects an inconsistency between this IE, then the IE contained in the Old BSS to New BSS information shall take precedence if the coding is understood by the new BSS. Reception of an erroneous Old BSS to New BSS information shall not cause a rejection of the Handover Request message. The Old BSS to New BSS information IE shall be discarded and the handover resource allocation procedure shall continue.
Issue 01 (2008-06-10)
A-49
Field Element Extra information Current Channel Type 2 Target cell radio information GPRS Suspend information MultiRate configuration information
Reference 3.2.3.1 3.2.3.2 3.2.3.3 3.2.3.4 3.2.3.5
Length 3 4 3 19 3-8
Configuration Evolution Indication This IE indicates whether subsequent assignment requests should be expected and the limitation for these subsequent assignments. 8 7 6 5 4 3 2 1 Octet 1 SMI Octet 2
SMI: Subsequent Modification Indication. This indicates the maximum number of TCH/F that could be requested in subsequent assignments. The SMI field is coded as follows: Bit 4321 0000 0001 0010 0011 0100 No Modification is allowed Modification is allowed and maximum number of TCH/F is 1 Modification is allowed and maximum number of TCH/F is 2 Modification is allowed and maximum number of TCH/F is 3 Modification is allowed and maximum number of TCH/F is 4
All other values are reserved. Response Request The presence of this element indicates that a Handover Required Reject message is required by the BSS, if the Handover Required message does not result in a handover. The element has a fixed length of one octet: 8 7 6 5 4 3 2 1 Octet 1
Element identifier
Cell Identifier List This element uniquely identifies cells and is of variable length containing the following fields:
A-50
Issue 01 (2008-06-10)
1 Octet 1 Octet 2
Element identifier Length spare Cell identification 1 : Cell identification n Cell identification discriminator
Octet 3 Octet 4-4+m
to 4+nm
The coding of octet 2 is a binary number that indicates the Length of the remaining element. The Length depends on the Cell identification discriminator (bits 1 to 4 of octet 3) as well as the number of cells to be identified. The coding of the Cell identification discriminator is a binary number indicating whether the whole or a part of Cell Global identification, CGI, according to GSM Rec. 03.03 is used for cell identification of the cells in the list. The Cell identification discriminator is coded as follows: 0000 0001 0010 0011 0100 Area. 0101 0110 The whole Cell Global Identification, CGI, is used to identify the cells. Location Area Code, LAC, and Cell Identify, CI, is used to identify the cells. Cell Identity, CI, is used to identify the cells. No cell is associated with the transaction. Location Area Identification, LAI, is used to identify all cells within a Location Location Area Code, LAC, is used to identify all cells within a location area. All cells on the BSS are identified.
All other values are reserved. Values 0100, 0101 and 0110 are only applicable for page messages. The coding of the Cell Identifications 1 to n (octets 4 to 4+nm) depends on the Cell identification discriminator (octet 3). Below the coding of the i-th Cell Identification is shown for each Cell identification discriminator (with "i" in the range 1 to n): Note that no coding is specified for Cell identification discriminator values of "0011" and "0110" as no additional information is required. Coding of the i-th Cell Identification for Cell identification discriminator = 0000 For GSM 900 and DCS 1800: 8 7 6 5 4 3 2 1 Octet 4 Octet 5 Octet 6
MCC dig 2 1 1 1 1
MNC dig 2
Issue 01 (2008-06-10)
A-51
8 LAC
1 Octet 7 Octet 8 Octet 9 Octet 10
LAC cont. CI value CI value cont
Where x = 3 + 7(i-1). Octets (x+1)(x+5) are coded as shown in GSM Rec. 04.08, Table Location Area Identification information element. Octets (x+6)(x+7) are coded as shown in GSM Rec. 04.08, Table Cell Identity information element. For PCS 1900 for NA: 8 7 6 5 4 3 2 1 Octet x+1 Octet x+2 Octet x+3 Octet x+4 Octet x+5 Octet x+6 Octet x+7
MCC dig 2 MNC dig 3 MNC dig 2 LAC LAC cont. CI value CI value cont
Where x = 3 + 7(i-1). Octets (x+1)(x+5) are coded as shown in GSM Rec. 04.08, Table Location Area Identification information element. Octets (x+6)(x+7) are coded as shown in GSM Rec. 04.08, Table Cell Identity information element. Coding of i-th Cell Identification for Cell identification discriminator = 0001 8 LAC LAC cont. CI value CI value cont. 7 6 5 4 3 2 1 Octet x+1 Octet x+2 Octet x+3 Octet x+4
A-52
Issue 01 (2008-06-10)
Where x = 3 + 4(i-1) Octets (x+1)(x+2) are coded as shown in GSM Rec. 04.08, Table Location Area Identification information element. Octets (x+3)(x+4) are coded as shown in GSM Rec. 04.08, Table Cell Identity information element. Coding of i-th Cell Identification for Cell identification discriminator = 0010 8 CI value CI value cont. 7 6 5 4 3 2 1 Octet x+1 Octet x+2
Where x = 3 + 2(i-1) Octets (x+1)(x+2) are coded as shown in GSM Rec. 04.08, Table Cell Identity information element. Coding of i-th Cell Identification for Cell identification discriminator = 0100 For GSM 900 and DCS 1800: 8 7 6 5 4 3 2 1 Octet x+1 Octet x+2 Octet x+3 Octet x+4 Octet x+5 Octet x+6 Octet x+7
MCC dig 2 1 1 1 1
MNC dig 2 LAC LAC cont. CI value CI value cont.
Where x = 3 + 5(i-1) Octets (x+1)(x+5) are coded as shown in GSM Rec. 04.08, Table Location Area Identification IE. For PCS 1900 for NA: 8 7 6 5 4 3 2 1 Octet x+1 Octet x+2 Octet x+3 Octet x+4
MCC dig 2 MNC dig 3 MNC dig 2 LAC
Issue 01 (2008-06-10)
A-53
1 Octet x+5
LAC cont.
Where x = 3 + 5(i-1) Octets (x+1)(x+5) are coded as shown in GSM Rec. 04.08, Table Location Area Identification IE. Coding of i-th Cell Identification for Cell identification discriminator = 0101 8 LAC LAC cont. 7 6 5 4 3 2 1 Octet x+1 Octet x+2
Where x = 3 + 2(i-1) Octets (x+1)(x+2) are coded as shown in GSM Rec. 04.08, Table Location Area Identification information element. The appropriate coding for not identified cells is "0" for all bits of LAC and CI for all possible Cell Identification Discriminator values. Queuing Indicator This element contains a recommendation of the BSS concerning application of queuing. The element has a fixed length of two octets. 8 7 6 5 4 3 2 1 Octet 1 qri spare Octet 2
Octet 2 is coded as follows: qri = queuing recommendation indicator 0 1 it is recommended not to allow queuing. it is recommended to allow queuing. Layer 3 Information This is a variable length element used to pass messages on the radio interface from one network entity to another. 8 7 6 5 4 3 2 1 Octet 1 Octet 2
Element identifier Length
A-54
Issue 01 (2008-06-10)
1 Octet 3-n
Layer 3 information
Octet 1 identifies the element. Octet 2 gives the length of the following layer 3 information. Octet j (j = 3, 4, ..., n) is the unchanged octet j-2 of a radio interface layer 3 message as defined in GSM Rec. 04.08, n-2 is equal to the length of that radio interface layer 3 message. IMSI The IMSI is coded as a sequence of BCD digits, compressed two into each octet. This is a variable length element, and includes a length indicator. The remainder of this element is coded as defined in GSM Rec. 04.08. The element coding is: 8 7 6 5 4 3 2 1 Octet 1 Octet 2 Octet 3-n
Element identifier Length Rest of element coded as in GSM Rec. 04.08, not including GSM Rec. 04.08 element identifier or GSM Rec. 04.08 octet length value
TMSI The TMSI is a fixed length element. The TMSI is an unstructured number of 4 octets in length. The coding is: 8 7 6 5 4 3 2 1 Octet 1 Octet 2 Octet 3-n
Element identifier Length TMSI
The TMSI field is unstructured. Channel Needed This IE contains an indication for the mobile station of which channel is needed for the transaction linked to the paging procedure. It is coded as follows: 8 7 6 5 4 3 2 1 Octet 1 Channel Octet 2
Issue 01 (2008-06-10)
A-55
The Channel field is coded as follows: Bit 2 1 00 01 10 11 Any channel SDCCH TCH/F (Full rate) TCH/H or TCH/F (Dual rate)
eMLPP Priority This IE contains the eMLPP priority of the call. It is coded as follows: 8 7 6 5 4 3 2 1 Octet 1 Call priority Octet 2
The call priority field (bit 3 to 1 of octet 2) is coded in the same way as the call priority field (bit 3 to 1 of octet 5) in the Descriptive group or broadcast call reference IE as defined in GSM Rec. 04.08. Cipher Response Mode This IE is used by the MSC to indicate whether the IMEI is included in the Ciphering Mode Complete message to be sent by the MS. 8 7 6 5 4 3 2 1 Octet 1 Octet 2
Element identifier Cipher response mode
Octet 2 is coded as:Bits 8,7,6,5,4,3,2 Bit 1 = 0 Bit 1 = 1 Spare
IMEISV must not be included by the Mobile Station IMEISV must be included by the Mobile Station
Layer 3 Message Contents This is a variable length element used to pass the contents (from octet 3 up to the last octet) of the messages on the radio interface from one network entity to another. 8 7 6 5 4 3 2 1 Octet 1 Octet 2
Element identifier Length
A-56
Issue 01 (2008-06-10)
1 Octet 3-n
Layer 3 message contents
The length indicator (octet 2) is a binary number indicating the absolute length of the contents after the length indicator octet. Octet j (j = 3, 4, ..., n) is the unchanged octet j of a radio interface layer 3 message as defined in GSM Rec. 04.08, n is equal to the length of that radio interface layer 3 message. LSA Identifier List This element uniquely identifies LSAs and is of variable length containing the following fields: 8 7 6 5 4 3 2 1 Octet 1 Octet 2 EP Octet 3 Octet 4-6 : to 3+3n
Element identifier Length spare LSA identification 1 : LSA identification 2
The coding of octet 2 is a binary number that indicates the length of the remaining element. The length depends on the number of LSAs to be identified. If the escape PLMN (see GSM Rec. 03.73) is broadcast the EP bit (bit 1 of octet 3) is set to 1, otherwise it is set to 0. 8 LSA ID LSA ID cont. LSA ID cont. 7 6 5 4 3 2 1 Octet x+1 Octet x+2 Octet x+3
Where x = 3 + 3(i-1) Octets (x+1)(x+3) are coded as shown in GSM Rec. 03.03, Identification of Localized Service Area. Bit 8 of octet (x+1) is the MSB. Service Handover The Service Handover defines information to use for handover to UTRAN or cdma2000. It is coded as follows:
Issue 01 (2008-06-10)
A-57
1 Octet 1 Octet 2 Octet 3
Element identifier Length Service Handover information
Octet 2 is a binary indication of the length of the remainder of the element in octets. Service Handover information is coded as follows: Bits 4-8: Spare. Bits 1-3: 321 000 Handover to UTRAN or cdma2000 should be performed Handover to UTRAN or cdma2000 is preferred. The handover evaluation of the target cell for handovers shall take into account the preference for UTRAN or cdma2000. 001 Handover to UTRAN or cdma2000 should not be performed Handover to GSM is preferred. The handover evaluation of the target cell for handovers shall take into account the preference for GSM. 010 Handover to UTRAN or cdma2000 shall not be performed Handover to UTRAN or cdma2000 is not allowed.
All other values are interpreted as no information available for service based handover. IMSI The IMSI is coded as a sequence of BCD digits, compressed two into each octet. This is a variable length element, and includes a length indicator. The remainder of this element is coded as defined in GSM Rec. 04.08. The element coding is: 8 7 6 5 4 3 2 1 Octet 1 Octet 2 Octet 3n
Element identifier Length Rest of element coded as in GSM Rec. 04.08, not including GSM Rec. 04.08 element identifier or GSM Rec. 04.08 octet length value
Source RNC to Target RNC Transparent Information (UMTS)
A-58
Issue 01 (2008-06-10)
This IE is defined as a general container for passing (for example, UE Capability Information, Target Cell ID) the RNC specific information transparently through the core network from the BSS to the RNC. 8 7 6 5 4 3 2 1 Octet 1 Octet 2 Octet 3n
Element identifier Length Source RNC to target RNC information container
The Source RNC to Target RNC Information container structure and encoding is defined in relevant RANAP specification TS 25.413, excluding RANAP tag. Source RNC to target RNC transparent information (cdma2000) This IE is defined as a general container for passing RNC specific information, such as cdma2000 Capability Information and Target Cell ID, transparently through the core network from the BSS to the RNC. 8 7 6 5 4 3 2 1 Octet 1 Octet 2 Octet 3n
Element identifier Length Source RNC to target RNC information container
The Source RNC to Target RNC Information container structure and encoding is defined in relevant RANAP specification TS 25.413, excluding RANAP tag. Configuration Evolution Indication This IE indicates whether subsequent assignment requests are expected and the limitation for these subsequent assignments. 8 7 6 5 4 3 2 1 Octet 1 SMI Octet 2
SMI: Subsequent Modification Indication. This indicates the maximum number of TCH/F that could be requested in subsequent assignments. The SMI field is coded as follows: Bit 4321 0000 No Modification is allowed. 0001 0010 Modification is allowed and maximum number of TCH/F is 1. Modification is allowed and maximum number of TCH/F is 2.
Issue 01 (2008-06-10)
A-59
0011 0100
Modification is allowed and maximum number of TCH/F is 3. Modification is allowed and maximum number of TCH/F is 4.
A.2 Key Messages on the Abis Interface

The same elements appear in various orders depending on the message. The key BSSMAP messages are listed in the following table: Message Name Channel Required Paging Command Channel Activation Channel Activation Acknowledge Channel Activation Negative Acknowledge Immediate Assign Command Connection Failure Indication Error Indication Encryption Command Handover Detection Mode Modify Mode Modify Acknowledge Mode Modify Negative Acknowledge Establish Indication Reference 2.1.1 2.1.2 2.1.3 2.1.4 2.1.5 2.1.6 2.1.7 2.1.8 2.1.9 2.1.10 2.1.11 2.1.12 2.1.13 2.1.14
The messages on the Abis interface described here are based on Phase 2+ GSM Rec. 0858 version 7.4.1 Release 1998.
A.2.1 Message Contents

Channel Required
This message is sent from the BTS to the BSC to indicate the reception of a Channel Request message from an MS. The Channel Request message is a special access burst message. Information Element Message discriminator Reference 2.2.1 Presence M Format V Length 1
A-60
Issue 01 (2008-06-10)
Information Element Message type Channel number Request Reference Access Delay Physical Context
Reference 2.2.2 2.2.3 2.2.4 2.2.5 2.2.6
Presence M M M M O (1)
Format V TV TV TV TLV
Length 1 2 4 2 >=2
The Physical Context is an Optional element for additional physical channel information. The Request Reference element contains the random access reference value sent by the MS in the Channel Request message and some low order bits of the absolute frame number for the reception of the access burst.
Paging Command
This message is sent from the BSC to the BTS to request the paging of an MS. Information Element Message discriminator Message type Channel number Paging Group MS Identity Channel Needed eMLPP Priority Reference 2.2.1 2.2.2 2.2.3 2.2.7 2.2.8 2.2.9 2.2.10 Presence M M M M M O (1) O (2) Format V V TV TV TLV TV TV Length 1 1 2 2 2-10 2 3
If the Channel Needed element is not present, the default value is assumed to be 00 (any channel). If the eMLPP Priority is not present, then the BTS does not include the eMLPP priority in the message on the radio interface. The Paging Group element is used by the BTS to calculate the correct DRX paging block to be used for the transmission of the Paging Request message as defined in GSM Rec. 05.02.
Channel Activation
This message is sent from the BSC to the BTS to activate a radio channel. The attributes of the channel are defined in the message. Information Element Message discriminator Reference 2.2.1 Presence M Format V Length 1
Issue 01 (2008-06-10)
A-61
Information Element Message type Channel number Activation Type Channel Mode Channel Identification Encryption information Handover Reference BS Power MS Power Timing Advance BS Power Parameters MS Power Parameters Physical Context SACCH Information UIC Main channel reference MultiRate configuration MultiRate Control Supported Code Types
Reference 2.2.2 2.2.3 2.2.11 2.2.12 2.2.13 2.2.14 2.2.15 2.2.16 2.2.17 2.2.18 2.2.20 2.2.19 2.2.6 2.2.21 2.2.22 2.2.23 2.2.24 2.2.25 2.2.26
Presence M M M M O (7) O (1) C (2) O (3) O (3) C (3) (4) O (5) O (5) O (6) O (8) O (9) O (10) O (11) O (12) O (12)
Format V TV TV TLV TLV TLV TV TV TV TV TLV TLV TLV TLV TLV TV TLV TV TLV
Length 1 2 2 8-9 8 >=3 2 2 2 2 >=2 >=2 >=2 >=3 3 2 >=4 2 >=5
The Encryption IE is only included if ciphering is applied. The Handover Reference element is only included if activation type is handover. If BS Power, MS Power, and/or Timing Advance elements are present, they are to be used to set the initial transmission power and the initial L1-header. The Timing Advance element must be included if activation type is intra-cell channel change. The BS and MS Power Parameters elements are included to indicate that BS and/or MS power control is performed by the BTS. The maximum power to be used is indicated in the BS and MS Power elements respectively. The Physical Context is an optional element for additional physical channel information. The Channel Identification is included if compatibility with phase 1 is required. The SACCH Information is an optional element for setting the SACCH filling information for this channel. If this element is present, the SACCH filling information as given by this element shall be used for this channel, replacing any SACCH filling information as given by the SACCH Filling messages until the channel is released or the
A-62
Issue 01 (2008-06-10)
information is changed by a SACCH Info Modify message. If this element is not present, the SACCH filling as given by the SACCH Filling messages shall be used. The UIC element may be included for voice group calls. It is used in the same way as the BSIC for decoding the random access bursts when decoding uplink access bursts. If the UIC element not included, the BSIC shall be used for decoding uplink access bursts. The Main channel reference is an optional element for multislot operation. It is used in the case of power control in the BTS. The MultiRate configuration is included if the Channel Mode indicates that a multi-rate speech code is used. The MultiRate Control and Supported Code Types are optionally included if the Channel Mode indicates that a multi-rate speech code is used and TFO control is required or to give to the BTS the possibility to change autonomously the multi-rate code configuration.
Channel Activation Acknowledge

This message is sent from the BSC to the BTS to acknowledge that the requested channel activation is completed correctly. Information Element Message discriminator Message type Channel number Frame number Reference 2.2.1 2.2.2 2.2.3 2.2.27 Presence M M M M Format V V TV TV Length 1 1 2 3
The Frame Number element is used by the BSC to calculate the Starting Time parameter when required.
Channel Activation Negative Acknowledge

This message is sent from the BTS to the BSC to indicate that the channel activation could not be performed as requested. Information Element Message discriminator Message type Channel number Cause Reference 2.2.1 2.2.2 2.2.3 2.2.28 Presence M M M M Format V V TV TLV Length 1 1 2 >=3
If the Channel Activation message is received with an erroneous Channel number IE, the Channel Activation Negative Acknowledge message is returned with the Channel Number IE equal to the received (and erroneous) Channel number and the Cause value "Mandatory Information Element Error" with Diagnostics equal to the Channel number element identifier value.
Issue 01 (2008-06-10)
A-63
Immediate Assign Command

This message is sent from the BSC to the BTS to request the transmission of an Immediate Assignment message. Information Element Message discriminator Message type Channel number Full Imm. Assign Info Reference 2.2.1 2.2.2 2.2.3 2.2.29 Presence M M M M Format V V TV TLV Length 1 1 2 25
The Full Imm. Assign Info element contains the relevant Immediate Assignment message as defined in GSM Rec. 04.08 (Immediate Assignment or Immediate Assignment Extended or Immediate Assignment Reject) with the "Page Mode" element set to the value "no change".
Connection Failure Indication

This message is sent from the BTS to the BSC to indicate that an active connection is broken for some reason. Information Element Message discriminator Message type Channel number Cause Reference 2.2.1 2.2.2 2.2.3 2.2.28 Presence M M M M Format V V TV TLV Length 1 1 2 >=3
Error Indication
This message is sent from the BTS to the BSC to indicate an abnormal case for a radio-link layer connection. Information Element Message discriminator Message type Channel number Link Identifier RLM Cause Reference 2.2.1 2.2.2 2.2.3 2.2.30 2.2.31 Presence M M M M M Format V V TV TV TLV Length 1 1 2 2 2-4
A-64
Issue 01 (2008-06-10)
Encryption Command
This message is sent from the BSC to the BTS to start ciphering mode operation. Information Element Message discriminator Message type Channel number Encryption information Link Identifier L3 Info (CIPH MOD CMD) Reference 2.2.1 2.2.2 2.2.3 2.2.14 2.2.30 2.2.32 Presence M M M M M M Format V V TV TLV TV TLV Length 1 1 2 >=3 2 6
The L3 Info element contains the complete Ciphering Mode Command message as defined in GSM Rec. 04.08.
Handover Detection
This message is sent from the BTS to the BSC when the BTS correctly receives information from an MS on the handover activated channel. Information Element Message discriminator Message type Channel number Access Delay Reference 2.2.1 2.2.2 2.2.3 2.2.5 Presence M M M O (1) Format V V TV TV Length 1 1 2 2
The Access Delay element is included if the sending of the handover detection message is triggered by the reception of a handover access burst with the correct handover reference.
Mode Modify
This message is sent from the BSC to the BTS to request a change of channel mode of an active channel. Information Element Message discriminator Message type Channel number Channel Mode Encryption information Reference 2.2.1 2.2.2 2.2.3 2.2.12 2.2.14 Presence M M M M O (1) Format V V TV TLV TLV Length 1 1 2 8-9 >=3
Issue 01 (2008-06-10)
A-65
Information Element Main channel reference MultiRate configuration Multirate Control Supported Code Types
Reference 2.2.23 2.2.24 2.2.25 2.2.26
Presence O (2) O (3) O (4) O (4)
Format TV TLV TV TLV
Length 2 >=3 2 >=5
The Encryption IE is only included if ciphering is applied. The Main channel reference is an optional element for multislot operation. It may be used in the case of power control in the BTS. The MultiRate configuration is included if the Channel Mode indicates that a multi-rate speech code is used. The Multirate Control and Supported Code Types are optionally included if the Channel Mode indicates that a multi-rate speech code is used and TFO control is required or to give to the BTS the possibility to change autonomously the multi-rate code configuration.
Mode Modify Acknowledge

This message is sent from the BTS to the BSC to confirm the change of channel mode of an active channel. Information Element Message discriminator Message type Channel number Reference 2.2.1 2.2.2 2.2.3 Presence M M M Format V V TV Length 1 1 2
Mode Modify Negative Acknowledge

This message is sent from the BTS to the BSC to indicate that the channel mode modification could not be performed as requested. Information Element Message discriminator Message type Channel number Cause Reference 2.2.1 2.2.2 2.2.3 2.2.28 Presence M M M M Format V V TV TLV Length 1 1 2 >=3
A-66
Issue 01 (2008-06-10)
Establish Indication
This message is sent from the BTS to the BSC to indicate the establishment of a radio-link layer connection in multi-frame mode, initiated by an MS. Information Element Message discriminator Message type Channel number Link Identifier L3 Information Reference 2.2.1 2.2.2 2.2.3 2.2.30 2.2.32 Presence M M M M O (1) Format V V TV TV TLV Length 1 1 2 2 323
The L3 Information field is present only if the SABM frame contains a non-empty information field.
The "establish mode" parameter appearing in GSM Rec. 04.06 is used only on the MS side.
A.2.2 Signaling Element Coding

Message Discriminator
A 1-octet field is used in all messages to discriminate between Transparent and NonTransparent messages and also between Radio Link Layer Management, Dedicated Channel Management, Common Channel Management, and TRX Management messages. 8 G7 7 G6 6 G5 5 G4 4 G3 3 G2 2 G1 1 T
The T-bit is set to 1 to indicate that the message is considered transparent by the BTS. All other messages shall have the T-bit set to 0. The G-bits are used to group the messages as follows: G7 G6 G5 G4 G3 G2 G1 Message Group 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 1 0 0 0 1 1 0 0 0 0 0 1 0 0 0 1 0 0 0 0 Reserved Radio Link Layer Management messages Dedicated Channel Management messages Common Channel Management messages TRX Management messages Location Services messages
All other values are reserved for future use
Issue 01 (2008-06-10)
A-67
Message Type
The Message Type uniquely identifies the function of the message being sent. It is a single octet and coded in the following way: 8 7 6 5 4 3 2 1
EM
Message type
Bit 8 is the extension bit and is reserved for future use. The following message types are used. All other values are reserved. 87654321 0000---0001 0010 0011 0100 0101 0110 0111 1000 1001 1010 1011 0001---0001 0010 0011 0100 0101 0110 0111 1001 Message Radio Link Layer Management messages Data Request Data Indication Error Indication Establish Request Establish Confirm Establish Indication Release Request Release Confirm Release Indication Unit Data Request Unit Data Indication Common Channel Management/TRX Management messages BCCH Information CCCH Load Indication Channel Required Delete Indication Paging Command Immediate Assign Command SMS Broadcast Request RF Resource Indication
A-68
Issue 01 (2008-06-10)
87654321 1010 1011 1100 1101 1110 1111 001----00001 00010 00011 00100 00101 00110 00111 01000 01001 01010 01011 01100 01101 01110 01111 10000 10001 10010 10011 10100 10101 10110 10111 11000
Message SACCH Filling Overload Error Report SMS Broadcast Command CBCH Load Indication Notification Command Dedicated Channel Management messages Channel Activation Channel Activation Acknowledge Channel Activation Negative ACK Connection Failure Deactivate SACCH Encryption Command Handover Detection Measurement Result Mode Modify Request Mode Modify Acknowledge Mode Modify Negative Acknowledge Physical Context Request Physical Context Confirm RF Channel Release MS Power Control BS Power Control Preprocess Configure Preprocessed Measurement Result RF Channel Release Acknowledge SACCH INFO Modify Talker Detection Listener Detection Remote Code Configuration Report Round Trip Delay Report
Issue 01 (2008-06-10)
A-69
87654321 11001 11010 11011 11100 11101 11110 11111 01-----000001
Message Pre-Handover Notification Multirate Code Modification Reqest Multirate Code MOD Acknowledge Multirate Code MOD Negative Acknowledge Multirate Code MOD Performed TFO Report TFO Modification Request Location Service messages Location Information
Channel Number
In the BSC to BTS direction, the Channel Number parameter is used to indicate on which physical channel or subchannel the message is sent. In the BTS to BSC direction, the Channel Number indicates on which physical channel or subchannel the message is received. It is coded in two octets as follows: 8 7 6 5 4 3 2 1
Element identifier C5 C4 C3 C2 C1 TN
The C-bits describe the channel as follows: C5 C4 C3 C2 C1 0 0 0 0 1 1 1 0 0 0 1 0 0 0 0 0 1 T 0 0 0 0 1 T T 0 0 1 1 T T T 0 1 0 Bm + ACCH's Lm + ACCH's SDCCH/4 + ACCH SDCCH/8 + ACCH BCCH Uplink CCCH (RACH) Downlink CCCH (PCH + AGCH)
The T-bits indicate, coded in binary, the sub-channel number as specified in GSM Rec. 05.02. TN is time slot number, binary represented as in GSM Rec. 05.02.
A-70
Issue 01 (2008-06-10)
Request Reference
This element carries the Request Reference parameters used for contention resolution on RACH. 8 7 6 5 4 3 2 1 1 2 T3 (high) T2 3 4
Element identifier RA T1' T3 (low)
Octets 2-4 are coded as the corresponding fields of the Request Reference element of GSM Rec. 04.08. Octet 2. The RA is the Random Access IE set by an MS in the Channel Request message. Octets 3-4 contain the absolute frame number modulo 42432 for the frame number when the access burst is received. For details, see the Starting Time element of GSM Rec. 04.08.
Access Delay
This element contains the delay of the access burst as measured by the BTS at random access or at handover access. 8 7 6 5 4 3 2 1 1 2
Element identifier Access Delay
The Access Delay field contains the delay of the access burst as measured by the BTS. The delay is expressed as defined for the Timing Advance TA in GSM Rec. 05.10, but with the range extended to 8 bits, that is, the six least significant bits of the field correspond to the Timing Advance.
Physical Context
This element contains supplementary information on the transmission/reception process. It is a variable length element. 8 7 6 5 4 3 2 1 1 2 3
Element identifier Length Physical Context Information
Issue 01 (2008-06-10)
A-71
The Physical Context Information field is not specified. This information should not be analyzed by the BSC, but merely forwarded from one TRX or channel to another.
Paging Group
This element carries the paging population of an MS to be paged. 8 7 6 5 4 3 2 1 1 2
Element identifier Paging Group
The Paging Group field (octet 2) contains the binary representation of the paging group as defined in GSM Rec. 05.02.
MS Identity
This element carries the identity of an MS (TMSI or IMSI). It is a variable length element. 8 7 6 5 4 3 2 1 1 2 3 : N
Element identifier Length MS Identity
The MS Identity field (octets 3N) is coded as specified for the Mobile Identity IE of GSM Rec. 04.08, octets 3N.
Channel Needed
This IE is used to indicate to the MS which channel is needed for the transaction linked to the paging procedure. 8 7 6 5 4 3 2 1 1 Channel 2
Element identifier Reserved for future use
The Channel Field (bits 12 of octet 2) indicates the further combination of channel that is needed. It is coded as follows: Value 00 Channel Needed Any Channel
A-72
Issue 01 (2008-06-10)
01 10 11
SDCCH TCH/F (Full rate) TCH/F or TCH/H (Dual rate)
eMLPP Priority
This IE contains the eMLPP priority of the call. It is coded as follows: 8 7 6 5 4 3 2 1 1 call priority 2
The call priority field (bit 3 to 1 of octet 2) is coded in the same way as the call priority field (bit 3 to 1 of octet 5) in the Descriptive group or broadcast call reference IE as defined in GSM Rec. 04.08.
Activation Type
This element is used to indicate the type of activation requested in the Channel Activation message. It is coded in two octets as follows: 8 7 6 5 4 3 2 1 1 A3 A2 A1 2
Element identifier R Reserved
The R bit indicates whether the procedure is an initial activation or a reactivation. R 0 1 Initial activation Reactivation
The A-bits indicate the type of activation, which defines the access procedure and the operation of the data link layer, as follows: A3 A2 A1 0 0 0 1 0 1 0 1 Activation related to intra-cell channel change - related to immediate assignment procedure - related to normal assignment procedure Activation related to inter-cell channel change (handover) - related to asynchronous handover procedure - related to synchronous handover procedure
Issue 01 (2008-06-10)
A-73
0 1
Activation related to secondary channels - related to additional assignment procedure - related to multislot configuration
All other values are reserved for future use.

For the main TCH channel in a Multislot configuration activation types for intra-cell and inter-cell channel change are used.
Channel Mode
This element gives information on the mode of coding/decoding and transcoding/rate adaption of a channel. 8 7 6 5 4 3 2 1 1 2 DTXd DTXu 3 4 5 6
Element identifier Length Reserved for future use Speech or data indicator Channel rate and type Speech coding algor./data rate + transp ind
The DTX bits of octet 3 indicate whether DTX is applied: 1 0 DTX is applied DTX is not applied.
DTXd indicates use of DTX in the downlink direction (BTS to MS) and DTXu indicates use of DTX in the uplink direction (MS to BTS). The "Speech or data indicator" field (octet 4) is coded as follows: 0000 0001 0000 0010 0000 0011 Speech Data Signaling
All other values are reserved. The "Channel rate and type" field (octet 5) is coded as follows: 0000 0001 0000 1000 0000 1001 0000 1010 0001 1010 SDCCH Full rate TCH channel Bm Half rate TCH channel Lm Full rate TCH channel bi-directional Bm, Multislot configuration Full rate TCH channel uni-directional downlink Bm, Multislot configuration
A-74
Issue 01 (2008-06-10)
0001 1000 0001 1001 0010 1000 0010 1001
Full rate TCH channel Bm Group call channel Half rate TCH channel Lm Group call channel Full rate TCH channel Bm Broadcast call channel Half rate TCH channel Lm Broadcast call channel
All other values are reserved. The "speech coding algorithm/data rate + transparency indicator" field (octet 6) is coded as follows: If octet 4 indicates speech, then octet 6 is coded as follows: 0000 0001 0001 0001 0010 0001 GSM speech coding algorithm version 1 GSM speech coding algorithm version 2 GSM speech coding algorithm version 3
All other values are reserved. If octet 4 indicates signaling then octet 6 is coded as follows: 0000 0000 No resources required

GSM speech coding algorithm version 3 is also referred as GSM adaptive multirate speech coding algorithm version 1.
If octet 4 indicates data, then octet 6 is coded as follows: 8 ext 7 T/NT 6 Rate 5 4 3 2 1 octet 6
Bit 8: Bit 7:
Reserved for extension 0 1 Transparent service Non-transparent service
For the non-transparent service, bits 6 to 1 indicate the data rate on the radio interface: 65 4321 01 1000 14.5 kbit/s 01 0000 12 kbit/s 01 0001 6 kbit/s all other values are reserved. For the transparent service, bits 6-1 indicate the data rate: 65 4321 01 1000 14.4 kbit/s
Issue 01 (2008-06-10)
A-75
01 0000 9.6 kbit/s 01 0001 4.8 kbit/s 01 0010 2.4 kbit/s 01 0011 1.2 kbit/s 01 0100 600 bit/s 01 0101 1200/75 bit/s (1 200 network-to-MS, 75 MS-to-network) All other values are reserved.
Channel Identification
This IE describes some aspects of a channel together with its SACCH. 8 7 6 5 4 3 2 1 1 2 * *
Element identifier Length GSM Rec. 04.08 "Channel Description" GSM Rec. 04.08 "Mobile Allocation"
A * denotes that the whole of the GSM Rec. 04.08 element including the element identifier and length should be included. For compatibility reasons, the GSM Rec. 04.08 "Mobile Allocation" shall be included but empty, that is, the length shall be zero.
Encryption information
This element is a variable length element. It contains necessary information to control encryption devices. 8 7 6 5 4 3 2 1 1 2 3 4
Element identifier Length Algorithm identifier Key
The Algorithm Identifier field (octet 3) indicates the relevant ciphering algorithm. It is coded as: 0000 0000 0000 0001 Reserved No encryption shall be used.
A-76
Issue 01 (2008-06-10)
0000 0010 0000 0011 0000 0100 0000 0101 0000 0110 0000 0111 0000 1000
GSM encryption algorithm version 1 (A5/1) GSM A5/2 GSM A5/3 GSM A5/4 GSM A5/5 GSM A5/6 GSM A5/7
All other values are reserved The Key field (octets 4n) indicates the ciphering key. It shall be an integral number of octets and the length is given as the value of the Length field minus 1.
Handover reference
The information is coded in two octets and contains the handover reference value. 8 7 6 5 4 3 2 1 1 2
Element identifier Handover reference
The Handover Reference octet contains the handover reference value as defined in GSM Rec. 04.08.
BS Power
This IE indicates the TRX transmission power level on a particular channel. 8 7 6 5 4 3 2 1 1 Power Level 2
Element identifier Reserved
The Power Level field (octet 2) indicates the number of 2 dB steps by which the power shall be reduced from its nominal value, Pn, set by the network operator to adjust the coverage. Thus, the Power Level values correspond to the following powers (relative to Pn): Value 00000 00001 00010 01110 01111 Power level Pn Pn - 2 dB Pn - 4 dB Pn - 28 dB Pn - 30 dB
Issue 01 (2008-06-10)
A-77
All other values are reserved for future use. See also GSM Rec. 05.05, subclass 4.1.2 and GSM Rec. 05.08, subclass 4.5.
MS Power
This element carries the power level of the MS. 8 7 6 5 4 3 2 1 1 Power Level 2
Element identifier Reserved
The coding and meaning of the Power Level field is as defined in GSM Rec. 05.05 and GSM Rec. 05.08. See also GSM Rec. 04.04.
Timing Advance
This element contains the timing advance to be used by the MS in subsequent communications. It is calculated by the BTS at the reception of a Channel Request message (random access burst) or a handover access burst. 8 7 6 5 4 3 2 1 1 2
Element identifier Reserved Timing Advance
The Timing Advance field contains the timing advance TA as specified in GSM Rec. 05.10. Bits 7-8 of octet 2 are reserved for future use.
MS Power Parameters
This element carries the parameters required by the TRX for MS power control. 8 7 6 5 4 3 2 1 1 2 3
Element identifier Length MS Power Control
Parameters
The MS Power Control Parameters field contains the parameters and limits required when MS power control is performed by the BTS. The coding is operator dependant. Examples of
A-78
Issue 01 (2008-06-10)
possible parameters and algorithms, such as RXLEV, RX-QUAL-FULL, RX-QUAL-UB, DISTANCE (Timing Advance), can be found in GSM Rec. 05.08.
BS Power Parameters
This element carries the parameters required by the TRX for control of its own transmission power. 8 7 6 5 4 3 2 1 1 2 3 : N
Element identifier Length BS Power Control Parameters
The BS Power Control Parameters field contains the parameters and limits required when TRX transmission power control is performed by the BTS. The coding is operator dependant. Examples of possible parameters and algorithms, such as RXLEV, RX-QUAL-FULL, RXQUAL-SUB, DISTANCE (Timing Advance), can be found in GSM Rec. 05.08.
SACCH Information
This element is used to carry the SACCH filling information (System Information messages, or Extended Measurement Order message) that is used on a specific channel. 8 7 6 5 4 3 2 1 1 2 3 4 5 : j
Element identifier Length Number of messages Type of 1st message Length of 1st message 1st message
Type of n'th message Length of n'th message
l l+1 N
n'th message
Issue 01 (2008-06-10)
A-79
The Length field (octet 2) indicates in binary the total remaining length of the element (octets 3N). The Number of SI messages field (octet 3) indicates in binary the number of messages contained in the element. The coding of each of these messages consists of a type field (Type of nth msg), a length field (Length of nth message), and a message field (nth message). The "Type of nth msg" field indicates the type of System Information, or an Extended Measurement Order message that follows in the "nth message" field. It is coded as follows: Value 0000 0000 0000 0000 0100 0101 0110 1101 1110 0111 Message SYSTEM INFORMATION 5 SYSTEM INFORMATION 6 SYSTEM INFORMATION 5bis SYSTEM INFORMATION 5ter EXTENDED MEASUREMENT ORDER
All other values are reserved. The "Length of nth SI message" field indicates in binary the length of the "nth message" field that follows. The "nth message" field contains a complete SACCH message as defended in GSM Rec. 04.08.
UIC
It is coded as follows: 8 7 6 5 4 3 2 1 1 2 3
Element identifier Length UIC information
Octet 3 bits 1 to 6 contain the radio interface octet 2 bits 3 to 8 of the UIC IE as defined in GSM Rec. 04.08. Octet 3 bits 7 and 8 are spare and set to zero.
Main channel reference

This element contains the main channel reference of a multislot connection. It is coded in two octets as follows: 8 7 6 5 4 3 2 1 1
Element identifier
A-80
Issue 01 (2008-06-10)
3 TN
1 2
Reserved for future use
TN is time slot number, binary represented as in GSM Rec. 05.02.
MultiRate configuration
This element gives the description of the multirate speech code configuration to be applied. 8 7 6 5 4 3 2 1 1 2 3n
Element identifier Length Rest of element coded as in GSM Rec. 04.08, not including GSM Rec.04.08 element identifier or GSM Rec. 04.08 octet length value
MultiRate Control
This element indicates whether TFO is enabled or not and whether the BSC authorizes the BTS to perform autonomously multi-rate code changes and whether a handover is expected. It is coded in two octets as follows: 8 7 6 5 4 3 2 1 1 PRE RAE TFO 3
Element identifier Spare
The TFO field (bit 1 of octet 3) indicates if TFO is enabled or not. It is coded as follows: Value 0 1 TFO
Tandem Free Operation is enabled Tandem Free Operation is disabled
The RAE field (bits 23, octet 3) defines whether the RATSCCH mechanism is enabled or not. It is coded as follows: Value RAE
0 0 RATSCCH mechanism is generally enabled, the BTS may change the AMR configuration within the given SCS and MACS constraints and within the given radio and Abis channel. 0 1 RATSCCH mechanism is potentially enabled for one exchange. The BSC uses a MultiRate CODE MOD REQ message for that purpose 1 0 reserved
Issue 01 (2008-06-10)
A-81
1 1 RATSCCH mechanism is generally disabled The PRE field (bit 4 of octet 3) indicates whether a handover is expected soon or not. It is coded as follows: Value 0 1 PRE
Handover is not expected, respectively has failed Handover is expected soon
Supported Code Types

This element indicates the code types supported by the BSS or the remote BSS. It is coded as follows: 8 7 6 5 4 3 2 1 1 2 3 Code List 4n n+1
Element identifier Length Sys-ID ext
Preferred Code Type
The Sys-ID field (octet 3) identifies the system that sends the configuration. It should be set to 0000 0000 for GSM. The Code List field (octet 4) lists the code types that are supported by the BSS and Transcoder, and are therefore potential candidates for TFO establishment. If the Preferred Code Type is not present (this field is set to 1111.1111), then the Code List belongs to the remote BSS, otherwise it is the list of alternative Preferred Code Types. It is coded as follows: Bit 1: Set to 1 if the GSM FR Speech Code is supported. Bit 2: Set to 1 if the GSM HR Speech Code is supported. Bit 3: Set to 1 if the GSM EFR Speech Code is supported. Bit 4: Set to 1 if the GSM FR AMR Speech Code is supported. Bit 5: Set to 1 if the GSM HR AMR Speech Code is supported Bit 67: Reserved, set to 0. Bit 8: Reserved for extension, set to 0. If bit 4 of the Code List field (octet 4) indicates that FR AMR is supported or if bit 5 of the Code List field (octet 4) indicates that HR AMR is supported, the following two octets (octets 56) should be coded as follows: 8 Spare SCS
2 MACS
1 5 6
TFO_VER
A-82
Issue 01 (2008-06-10)
If both FR AMR and HR AMR are supported, the octets 56 shall be sent twice. The first occurrence shall correspond to FR AMR configuration. The second one shall correspond to HR AMR configuration. The MACS field (bits 12 of octet 5, if present) indicates the maximum number of AMR code Modes the BSS can support in the Active Code Set. It should be coded as follows: 0 0: A maximum of four code modes can be supported in the Active Code Set 0.1: A maximum of one code mode can be supported in the Active Code Set 1.0: A maximum of two code modes can be supported in the Active Code Set 1.1: A maximum of three code modes can be supported in the Active Code Set The TFO_VER field (bits 3-4 of octet 5, if present) indicates the TFO_VERSION. 0 0 : Version 0 of TFO All other values reserved for future used The SCS field (octet 6 if present) indicates the Set of AMR Code modes Supported by the BSS. It should be coded as follows: Bit 8: Set to 1 if the AMR 12.2 Code Mode is supported. Bit 7: Set to 1 if the AMR 10.2 Code Mode is supported. Bit 6: Set to 1 if the AMR 7.95 Code Mode is supported. Bit 5: Set to 1 if the AMR 7.40 Code Mode is supported. Bit 4: Set to 1 if the AMR 6.70 Code Mode is supported. Bit 3: Set to 1 if the AMR 5.90 Code Mode is supported. Bit 2: Set to 1 if the AMR 5.15 Code Mode is supported. Bit 1: Set to 1 if the AMR 4.75 Code Mode is supported. The Preferred Code Field (bits 18, octet n+1) indicates the preferred code type for TFO establishment. It is coded as follows; 0 0 0 0 . 0 0 0 0: Full Rate Code is preferred 0 0 0 0 . 0.0 0 1: Half Rate Code is preferred 0 0 0 0 . 0 0 1.0: Enhanced Full Rate Code is preferred 0 0 0 0 . 0 0 1.1: FR Adaptive Multi-Rate Code is preferred 0 0 0 0 . 0 1 0 0: HR Adaptive Multi-Rate Code is preferred 1 1 1 1 . 1 1 1 1: No preferred code type All other values reserved for future used
Frame Number
This element contains the absolute frame number (FN) modulo 42432. It is used to carry the current timing in the BTS to the BSC for calculation of the Starting Time parameter required in some messages.
Issue 01 (2008-06-10)
A-83
1 1
Element identifier T1' T3 (low) T2 T3 (high)
2 3
Octets 2-3 are coded as defined for octets 2-3 of the Starting Time IE of GSM Rec. 04.08.
Cause
The cause element is used to indicate the reason for a particular event to occur and is coded as shown below. 8 7 6 5 4 3 2 1 1 2 Cause Value 3 3a 4 Diagnostic(s) if any N
Element identifier Length E
Cause Extension
The Length field indicates in binary the remaining length of the element (octets 3N). The Cause Value is a single octet field (octet 3) if the extension bit E (bit 8) is set to 0. If it is set to 1 then the cause value is a 2-octet field (octets 3 and 3a). The Cause Value is divided into two fields: a class (bits 57 of octet 3) and a value within the class (bits 14 of octet 3). If the value of the first octet of the cause field is 1XXX 0000 then the second octet is reserved for national applications (XXX still indicates the class). Diagnostic information is not available for every cause, see the table below. When available, it is coded in the same way as the corresponding IE in clause 9. Inclusion of diagnostics is optional. Classes: Class (000): Normal event Class (001): Normal event Class (010): Resource unavailable Class (011): Service or option not available Class (100): Service or option not implemented
A-84
Issue 01 (2008-06-10)
Class (101): Invalid message (e.g. parameter out of range) Class (110): Protocol error Class (111): Interworking CAUSE VALUES: Class 000 000 000 000 000 000 000 000 000 000 000 000 000 001 001 001 001 001 001 001 010 Value Cause Normal Event radio interface failure radio link failure handover access failure talker access failure reserved for international use reserved for international use reserved for international use O&M intervention reserved for international use : : Channel Number Channel Number Channel Number Channel Number Diagnostics
0000 0001 0010 0011 0100 0101 0110 0111 1000 1 :
1110 1111 normal event, unspecified Normal Event reserved for international use : :
0000 0 :
0111 1000 1 : : : reserved for national use
1111 Resource unavailable
010 010 010 010 010
0000 0001 0010 0011 0100
equipment failure radio resource not available terrestrial channel failure CCCH overload ACCH overload Channel Number Channel Number Channel Number Channel Number
Issue 01 (2008-06-10)
A-85
Class 010 010 010 010 010 010 010 010 010 010 010 011 011 011 011 011 011 100 100 100 100 100 100 100 100 100 101 101 101 101
Value 0101 0110 0111 1000 1001 1010 1011 1100 1101 1110 1111 -
Cause processor overload reserved for international use BTS not equipped remote transcoder failure notification overflow reserved for international use reserved for international use reserved for national use reserved for national use reserved for national use resource not available, unspecified Service or Option Not Available requested transcoding/rate adaption not available reserved for international use :
Diagnostics
Channel Number Channel Number
0000 0001 : : :
Channel Number
1110 1111 service or option not available, unspecified Service or Option Not Implemented encryption algorithm not implemented reserved for international use : : Channel Number
0000 0001 0 :
1110 1111 service or option not implemented, unspecified Invalid Message radio channel already activated/allocated reserved for international use : : Channel Number
0000 0001 0 :
A-86
Issue 01 (2008-06-10)
Class 101 101 101 101 101 110 110 110 110 110 110 110 110 110 110 110 110 110 110 110 110 110 111 111 111 111 111 111 111 111
Value 0111 1000 1 : : :
Cause
Diagnostics
reserved for national use
1110 1111 invalid message, unspecified Protocol Error message discriminator error message type error message sequence error general information element error mandatory information element error optional information element error information element non-existent information element length error invalid information element contents reserved for international use reserved for international use reserved for international use reserved for national use reserved for national use reserved for national use protocol error, unspecified Interworking reserved for international use : : Element Identif Element Identif Element Identif Element Identif Inform. Element Message Discrim Message Type Message Type
0000 0001 0010 0011 0100 0101 0110 0111 1000 1001 1010 1011 1100 1101 1110 1111 -
0000 0 :
1110 1111 interworking, unspecified
Issue 01 (2008-06-10)
A-87
Full Immediate Assign Info

This element is used to convey a full L3 Immediate Assignment message (3 types). 8 7 6 5 4 3 2 1 1 2 3
Element identifier Length Indicator Full Immediate Assign Info
25
The Length Indicator field (octet 2) indicates in binary the remaining length of the element (octets 3-25). The Full Immediate Assign Info field (octets 3-25) contains a complete immediate assignment message, that is, an Immediate Assignment or Immediate Assignment Extended or Immediate Assignment Reject message, as defined in GSM Rec. 04.08.
Link Identifier
This element identifies the signaling channel and SAPI of the radio data link. 8 7 6 5 4 3 2 1 1 priority SAPI 2
Element identifier C2 C1 NA
The NA bit (bit 6 in octet 2) is set to 1 to indicate that the Link Identifier is not applicable for this message. In all other cases, it is set to 0. The C-bits indicate the channel type as follows: C2 0 0 C1 0 main signaling channel (FACCH or SDCCH) 1 SACCH
All other values are reserved for future use. The SAPI field contains the SAPI value as defined in GSM Rec. 04.05. The priority field contains the message priority for SAPI 0, as defined in GSM Rec. 04.06, as follows: 00 01 10 normal priority high priority low priority
All other values for SAPI 0 and all values for other SAPIs are reserved for future use.
A-88
Issue 01 (2008-06-10)
RLM Cause
This element is used to indicate the precise protocol error or the reason for a release on the radio link layer. 8 7 6 5 4 3 2 1 1 2 Cause Value 3
Element identifier Length E
The Cause Value is a one-octet field if the extension bit is set to 0. If the extension bit is set to 1, the Cause Value is a two-octet field. The Cause Value field is coded as follows: 87654321 0 0 0 0 0 0 0 0 reserved 0 0 0 0 0 0 0 1 timer T200 expired (N200+1) times 0 0 0 0 0 0 1 0 re-establishment request 0 0 0 0 0 0 1 1 unsolicited UA response 0 0 0 0 0 1 0 0 unsolicited DM response 0 0 0 0 0 1 0 1 unsolicated DM response, multiple frame established state 0 0 0 0 0 1 1 0 unsolicited supervisory response 0 0 0 0 0 1 1 1 sequence error 0 0 0 0 1 0 0 0 U-frame with incorrect parameters 0 0 0 0 1 0 0 1 S-frame with incorrect parameters 0 0 0 0 1 0 1 0 I-frame with incorrect use of M bit 0 0 0 0 1 0 1 1 I-frame with incorrect length 0 0 0 0 1 1 0 0 frame not implemented 0 0 0 0 1 1 0 1 SABM command, multiple frame established state 0 0 0 0 1 1 1 0 SABM frame with information not allowed in this state All other values are reserved for future use.
L3 Information (message name)

This element contains a link-layer service data unit (L3 message). It is used to forward a complete L3 message as specified in GSM Rec. 04.08 between the BTS and the BSC. 8 7 6 5 4 3 2 1 1
Element identifier
Issue 01 (2008-06-10)
A-89
8 Length
1 2
Indicator Link Layer Service Data Unit (i.e. a layer 3 message as defined in GSM Rec. 04.08)
3 4
The Length Indicator field (octets 2-3) indicates in binary the remaining length of the element (octets 4-n). The most significant bit is bit 8 of octet 2 and the least significant bit is bit 1 of octet 3. Octets 4n contain the complete L3 message as defined in GSM Rec. 04.08. In the message format section, the GSM Rec. 04.08 message name to be included is indicated within bracket
A-90
Issue 01 (2008-06-10)
B Differences Between Phase 1, Phase 2, Phase 2+, and R99
Differences Between Phase 1, Phase 2, Phase 2+, and R99
B.1 Differences Between Messages on the A Interface at Different Phases

The GSM technical specification is a standard that is constantly improved. With the introduction of Phase 1, Phase 2, Phase 2+, and R99, GSM provides different new services for users to satisfy the requirements from the market. Phase 1 of the GSM technical specification includes 3.x.x series standards. Phase 2 includes 4.x.x series standards. The subsequent series standards, such as 5.x.x, 6.x.x, and 7.x.x, belong to Phase 2+. The R99 protocol is the first version of the 3GPP protocols. In R99, some new features such as inter-RAT handover, EDGE, and DTM are added. The GSM technical specification has good backward compatibility. This section focuses on the evolution of layer 3 protocol (GSM Rec. 08.08)at different phases on the A interface. To facilitate understanding, the typical protocol at each phase is analyzed and described in the subsequent topics: Phase 1: GSM Rec. 08.08 version 3.10.1 Phase 2: GSM Rec. 08.08 version 4.7.1 Phase 2+: GSM Rec. 08.08 version 7.6.1 R99: GSM Rec. 08.08 version 8.13.0
B.2 Difference Analysis

B.2.1 Differences Between Messages at Phase 1, Phase 2, Phase 2+, and R99
Table B-1 shows differences between messages at Phase 1, Phase 2, Phase 2+, and R99.
Issue 01 (2008-06-10)
B-1
Table B-1 Differences between messages at Phase 1, Phase 2, Phase 2+, and R99 Message Assignment Request Phase 1 Supporting the Assignment Request message Phase 2 Layer 3 header information becomes optional IE Deleting Radio Channel Identity (optional IE) Adding Classmark Information 2 (optional IE) Assignment Complete Supporting the Assignment Complete message Deleting Radio Channel Identity (optional IE) Adding Chosen Channel (optional IE) Adding Chosen Encryption Algorithm (optional IE) Phase 2+ Adding Group Call Reference (optional IE) Adding Talker Flag (optional IE) Adding LSA Access Control Suppression (optional IE) R99 Adding Configurati on Evolution Indication (optional IE) Adding Service Handover (optional IE) Adding Cell Identifier (optional IE)
Adding Circuit Identity Code (optional IE) Adding Circuit Pool (optional IE) Adding Speech Version (Chosen) (optional IE) Adding LSA Identifier (optional IE)
Assignment Failure
Supporting the Assignment Failure message
Basically consistent, Adjusting the cause values
Adding Circuit Pool (optional IE) Adding Circuit Pool List (optional IE) Adding some cause values
Supporting the Assignment Failure message
Block
Supporting the Block message (from BSC to MSC)
Supporting the Block message (from BSC to MSC)
Changing to a bi-directional message Adding Connection Release Requested (optional IE) (from MSC to BSC)
Supporting the Block message
B-2
Issue 01 (2008-06-10)
Message Blocking Acknowledge
Phase 1 Supporting the Blocking Acknowledge message Supporting the Unblock message (from BSC to MSC) Supporting the Unblocking Acknowledge message Supporting the Handover Request message
Phase 2 Supporting the Blocking Acknowledge message Supporting the Unblock message (from BSC to MSC) Supporting the Unblocking Acknowledge message Deleting Radio channel identity optional IE) Adding Cause (optional IE) Adding Classmark Information 3 (optional IE)
Phase 2+ Changing to a bidirectional message Changing to a bidirectional message Changing to a bidirectional message
R99 Supporting the Blocking Acknowledge message Supporting the Unblock message Supporting the Unblocking Acknowledge message Adding Service Handover (optional IE) Adding IMSI (optional IE) Adding Source RNC To Target RNC Transparent Information (UMTS) (optional IE) Adding Source RNC to Target RNC Transparent Information (cdma2000) (optional IE)
Unblock
Unblocking Acknowledge
Handover Request
Adding Current Channel Type 1 (optional IE) Adding Speech Version (Used) (optional IE) Adding Group Call Reference (optional IE) Adding Talker Flag (optional IE) Adding Configuration Evolution Indication (optional IE) Adding Chosen Encryption Algorithm (Serving) (optional IE) Adding Old BSS to New BSS Information (optional IE) Adding LSA Information (optional IE) Adding LSA Access Control Suppression (optional IE)
Issue 01 (2008-06-10)
B-3
Message Handover Required
Phase 1 Supporting the Handover Required message
Phase 2 Changing the property of Cell Identifier List (preferred) from optional IE to mandatory IE Deleting Current Radio Environment (optional IE) Deleting Environment of BS "n" (optional IE)
Phase 2+ Adding Circuit Pool List (optional IE) Adding Current Channel Type 1 (optional IE) Adding Speech Version (Used) (optional IE) Adding Queuing Indicator (optional IE) Adding Old BSS to New BSS Information (optional IE) Adding Circuit Pool (optional IE) Adding Speech Version (Chosen) (optional IE) Adding Circuit Identity Code (optional IE) Adding LSA Identifier (optional IE) Adding Cell Identifier (optional IE) Supporting the Handover Complete message Adding the Handover Succeeded message
R99 Adding Source RNC to Target RNC Transparent Information (UMTS) (optional IE) Adding Source RNC to Target RNC Transparent Information (cdma2000) (optional IE)
Handover Request Acknowledge
Supporting the Handover Request Acknowledge message
Modifying the encoding of Layer 3 Information Adding Chosen Channel (optional IE) Adding Chosen Encryption Algorithm (optional IE)
Adding Layer 3 Information (mandatory IE)
Handover Command
Supporting the Handover Command message Supporting the Handover Complete message Not supporting the Handover Succeeded message
Modifying the encoding of Layer 3 Information Supporting the Handover Complete message Not supporting the Handover Succeeded message
Adding Layer 3 Information (mandatory IE) Supporting the Handover Complete message Supporting the Handover Succeeded message
Handover Complete
Handover Succeeded
B-4
Issue 01 (2008-06-10)
Message Handover Candidate Enquire
Phase 1 Supporting the Handover Candidate Enquire message Supporting the Handover Candidate Response message Supporting the Handover Failure message
Phase 2 Changing the property of Cell Identifier from optional IE to mandatory IE Changing the property of Cell Identifier from optional IE to mandatory IE Supporting the Handover Failure message
Phase 2+ Supporting the Handover Candidate Enquire message Supporting the Handover Candidate Response message Adding Circuit Pool (optional IE) Adding Circuit Pool List (optional IE)
R99 Supporting the Handover Candidate Enquire message Supporting the Handover Candidate Response message Supporting the Handover Failure message
Handover Candidate Response
Handover Failure
Resource Request
Supporting the Resource Request message
Changing the property of Cell Identifier from optional IE to mandatory IE Adding Extended Resource Indicator (optional IE)
Resource Indication
Supporting the Resource Indication message
Adding Resource Indication Method (Mandatory IE) Changing the property of Resource available from Mandatory IE to optional IE Adding Total Resource accessible (optional IE)
Paging
Supporting the Paging message
Changing the TMSI code Adding Channel Needed (optional IE)
Adding eMLPP Priority (optional IE)
Supporting the Paging message
Issue 01 (2008-06-10)
B-5
Message Clear Request
Phase 1 Supporting the Clear Request message Supporting the Clear Command message Supporting the Clear Complete message Supporting the Reset message Supporting the Reset Acknowledge message Supporting the Handover Performed message
Phase 2 Supporting the Clear Request message Changing the property of Layer 3 Header Information from Mandatory IE to optional IE Supporting the Clear Complete message Supporting the Reset message Supporting the Reset Acknowledge message Changing the property of Cell Identifier from Optional IE to mandatory IE Deleting Radio Channel Identity (optional IE) Adding Chosen Channel (optional IE) Adding Chosen Encryption Algorithm (optional IE)
Phase 2+ Supporting the Clear Request message Supporting the Clear Command message
R99 Supporting the Clear Request message Supporting the Clear Command message Supporting the Clear Complete message Supporting the Reset message Supporting the Reset Acknowledge message Supporting the Handover Performed message
Clear Command
Clear Complete
Supporting the Clear Complete message Supporting the Reset message Supporting the Reset Acknowledge message Adding Speech Version (Chosen) (optional IE) Adding LSA Identifier
Reset
Reset Acknowledge
Handover Performed
Overload
Supporting the Overload message Supporting the Trace Invocation message
Supporting the Overload message Changing the Trace Invocation message to two messages: MSC Invoke Trace BSS Invoke Trace
Supporting the Overload message Changing the Trace Invocation message to two messages: MSC Invoke Trace BSS Invoke Trace Supporting the Trace Invocation message
Trace Invocation
B-6
Issue 01 (2008-06-10)
Message MSC Invoke Trace
Phase 1 Not supporting the MSC Invoke Trace message Not supporting the BSS Invoke Trace message Supporting the Classmark Update message (from BSC to MSC)
Phase 2 Adding the MSC Invoke Trace message Adding the BSS Invoke Trace message Changing to a bidirectional message Changing Classmark Information Type 2 (optional IE) Adding Classmark Information Type 3 (optional IE)
Phase 2+ Supporting the MSC Invoke Trace message Supporting the BSS Invoke Trace message Supporting the Classmark Update message
R99 Supporting the MSC Invoke Trace message Supporting the BSS Invoke Trace message Supporting the Classmark Update message
BSS Invoke Trace
Classmark Update
Cipher Mode Command
Supporting the Cipher Mode Command message
Changing the property of Layer 3 Header Information from Mandatory IE to optional IE Adding Cipher Response Mode (optional IE)
Cipher Mode Complete
Supporting the Cipher Mode Complete message
Adding Layer 3 Message Contents (optional IE) Adding Chosen Encryption Algorithm (optional IE)
Complete Layer 3 Information
Supporting the Complete Layer 3 Information message Supporting the Queuing Indication message
Adding Chosen Channel (optional IE)
Adding LSA Identifier List (optional IE) Adding APDU (optional IE)
Supporting the Complete Layer 3 Information message Supporting the Queuing Indication message
Queuing Indication
Supporting the Queuing Indication message
Supporting the Queuing Indication message
Issue 01 (2008-06-10)
B-7
Message SAPI "n" Reject
Phase 1 Supporting the SAPI "n" Reject message Supporting the SAPI "n" Clear Command message Supporting the SAPI "n" Clear Complete message Supporting the Handover Required Reject message Supporting the Reset Circuit message Supporting the Reset Circuit Acknowledge message Supporting the Handover Detect message Not supporting the Circuit Group Block message Not supporting the Circuit Group Blocking Acknowledge message
Phase 2 Supporting the SAPI "n" Reject message Not supporting the SAPI "n" Clear Command message
Phase 2+ Supporting the SAPI "n" Reject message Not supporting the SAPI "n" Clear Command message
R99 Supporting the SAPI "n" Reject message Not supporting the SAPI "n" Clear Command message Not supporting the SAPI "n" Clear Complete message Supporting the Handover Required Reject message Supporting the Reset Circuit message Supporting the Reset Circuit Acknowledge message Supporting the Handover Detect message Supporting the Circuit Group Block message Supporting the Circuit Group Blocking Acknowledge message
SAPI "n" Clear Command
SAPI "n" Clear Complete
Not supporting the SAPI "n" Clear Complete message
Not supporting the SAPI "n" Clear Complete message
Handover Required Reject
Supporting the Handover Required Reject message
Supporting the Handover Required Reject message Supporting the Reset Circuit message Supporting the Reset Circuit Acknowledge message Supporting the Handover Detect message Supporting the bi-directional Circuit Group Block message Supporting the bi-directional Circuit Group Blocking Acknowledge message
Reset Circuit
Supporting the Reset Circuit message Supporting the Reset Circuit Acknowledge message Supporting the Handover Detect message Adding the Circuit Group Block message (from BSC to MSC) Adding the Circuit Group Blocking Acknowledge message (from MSC to BSC)
Reset Circuit Acknowledge
Handover Detect
Circuit Group Block
Circuit Group Blocking Acknowledge
B-8
Issue 01 (2008-06-10)
Message Circuit Group Unblock
Phase 1 Not supporting the Circuit Group Unblock message Not supporting the Circuit Group Unblocking Acknowledge message Not supporting the Confusion message Not supporting the Classmark Request message Not supporting the Unequipped Circuit message Not supporting the Cipher Mode Reject message Not supporting the Load Indication message Not supporting the VGCS.CBS Setup message Not supporting the VGVS/VBS Setup ACK message
Phase 2 Adding the Circuit Group Unblock message (from BSC to MSC) Adding the Circuit Group Unblocking Acknowledge message (from MSC to BSC) Adding the Confusion message
Phase 2+ Supporting the bi-directional Circuit Group Unblock message Supporting the bi-directional Circuit Group Unblocking Acknowledge message Supporting the Confusion message Supporting the Classmark Request message
R99 Supporting the Circuit Group Unblock message Supporting the Circuit Group Unblocking Acknowledge message Supporting the Confusion message Supporting the Classmark Request message Supporting the Unequipped Circuit message Supporting the Cipher Mode Reject message Supporting the Load Indication message Supporting the VGCS.CBS Setup message Supporting the VGVS/VBS Setup ACK message
Circuit Group Unblocking Acknowledge
Confusion
Classmark Request
Adding the Classmark Request message
Unequipped Circuit
Adding the Unequipped Circuit message
Supporting the Unequipped Circuit message
Cipher Mode Reject
Adding the Cipher Mode Reject message
Supporting the Cipher Mode Reject message
Load Indication
Not supporting the Load Indication message
Adding the Load Indication message
VGCS.CBS Setup
Not supporting the VGCS.CBS Setup message
Adding the VGCS.CBS Setup message
VGVS/VBS Setup ACK
Not supporting the VGVS/VBS Setup ACK message
Adding the VGVS/VBS Setup ACK message
Issue 01 (2008-06-10)
B-9
Message VGCS/VBS Assignment Request
Phase 1 Not supporting the VGCS/VBS Assignment Request message Not supporting the VGCS/VBS Assignment Result message Not supporting the VGCS/VBS Assignment Failure message Not supporting the VGCS/VBS Assignment Indication message Not supporting the Uplink Request message Not supporting the Uplink Request Acknowledge message Not supporting the Uplink Request Confirmation message Not supporting the Uplink Release Indication message
Phase 2 Not supporting the VGCS/VBS Assignment Request message
Phase 2+ Adding the VGCS/VBS Assignment Request message
R99 Supporting the VGCS/VBS Assignment Request message Supporting the VGCS/VBS Assignment Result message Supporting the VGCS/VBS Assignment Failure message Supporting the VGCS/VBS Assignment Indication message Supporting the Uplink Request message Supporting the Uplink Request Acknowledge message Adding the Uplink Request Confirmation message Supporting the Uplink Release Indication message
VGCS/VBS Assignment Result
Not supporting the VGCS/VBS Assignment Result message
Adding the VGCS/VBS Assignment Result message
VGCS/VBS Assignment Failure
Not supporting the VGCS/VBS Assignment Failure message
Adding the VGCS/VBS Assignment Failure message
VGCS/VBS Assignment Indication
Not supporting the VGCS/VBS Assignment Indication message
Adding the VGCS/VBS Assignment Indication message Adding the Uplink Request message
Uplink Request
Not supporting the Uplink Request message
Uplink Request Acknowledge
Not supporting the Uplink Request Acknowledge message
Adding the Uplink Request Acknowledge message
Uplink Request Confirmation
Not supporting the Uplink Request Confirmation message
Adding the Uplink Request Confirmation message
Uplink Release Indication
Not supporting the Uplink Release Indication message
Adding the Uplink Release Indication message
B-10
Issue 01 (2008-06-10)
Message Uplink Reject Command
Phase 1 Not supporting the Uplink Reject Command message Not supporting the Uplink Release Command message Not supporting the Uplink Seized Command message Not supporting the Suspend message Not supporting the Resume message Not supporting the Change Circuit message Not supporting the Change Circuit Acknowledge message Not supporting the LSA Information message Not supporting the Location Information Command message
Phase 2 Not supporting the Uplink Reject Command message
Phase 2+ Adding the Uplink Reject Command message Adding the Uplink Release Command message
R99 Supporting the Uplink Reject Command message Supporting the Uplink Release Command message Supporting the Uplink Seized Command message Supporting the Suspend message Supporting the Resume message Supporting the Change Circuit message Supporting the Change Circuit Acknowledge message Supporting the LSA Information message Supporting the Location Information Command message
Uplink Release Command
Not supporting the Uplink Release Command message
Uplink Seized Command
Not supporting the Uplink Seized Command message
Adding the Uplink Seized Command message Adding the Suspend message
Suspend
Not supporting the Suspend message
Resume
Not supporting the Resume message
Adding the Resume message
Change Circuit
Not supporting the Change Circuit message
Adding the Change Circuit message
Change Circuit Acknowledge
Not supporting the Change Circuit Acknowledge message
Adding the Change Circuit Acknowledge message
LSA Information
Not supporting the LSA Information message
Adding the LSA Information message
Location Information Command
Not supporting the Location Information Command message
Adding the Location Information Command message
Issue 01 (2008-06-10)
B-11
Message Location Information Report
Phase 1 Not supporting the Location Information Report message
Phase 2 Not supporting the Location Information Report message
Phase 2+ Adding the Location Information Report message
R99 Supporting the Location Information Report message
B.2.2 Differences Between IEs of the Messages at Phase 1, Phase 2, Phase 2+, and R99
Table B-2 shows differences between IEs of the messages at Phase 1, Phase 2, Phase 2+, and R99. Table B-2 Differences between IEs of the messages on the A interface at Phase 1, Phase 2, Phase 2+, and R99 Element Circuit Identity Code Radio Channel Identity Resource Available Cause Phase 1 Supporting the Circuit Identity Code IE Supporting the Radio Channel Identity IE Supporting the Resource Available IE Supporting the Cause IE Phase 2 Supporting the Circuit Identity Code IE Deleting the Radio Channel Identity IE Supporting the Resource Available IE Adding Directed Retry Adding Invalid Cell Adding Invalid Message Contents Adding IE or Field Missing Adding Incorrect Value Adding Unknown Message Type Adding Unknown Information Element Phase 2+ Adding the support for 1544 kbit/s Deleting the Radio Channel Identity IE Supporting the Resource Available IE Adding Joined group call channel Adding Traffic Adding Traffic Load Adding Preemption Adding Circuit pool mismatch Adding Switch circuit pool Adding Requested speech version unavailable Adding LSA not allowed Adding VGCS/VBS call non existent R99 Supporting the Circuit Identity Code IE Deleting the Radio Channel Identity IE Supporting the Resource Available IE Supporting the Cause IE
B-12
Issue 01 (2008-06-10)
Element Cell Identifier
Phase 1 Supporting the Cell Identifier IE
Phase 2 Supporting the Cell Identifier IE
Phase 2+ Adding the support for PCS1900
R99 Supporting inter-RAT handover Adding four types of Cell Identifiers
Priority Layer 3 Header Information IMSI TMSI Encryption Information
Supporting the Priority IE Supporting the Layer 3 Header Information IE Supporting the IMSI IE Supporting the TMSI IE Supporting the Encryption Information IE (No Encryption and GSM A5/1) Supporting the Channel Type IE
Adding the PCI field Supporting the Layer 3 Header Information IE Supporting the IMSI IE Supporting the TMSI IE Supporting the Encryption Information IE (No Encryption, GSM A5/1, A5/2, A5/3, A5/4, A5/5, A5/6 and A5/7) Adding various combinations of the Channel Rate and Type, such as Full-rate or Half-rate TCH channel, Full rate preferred Supporting speech version 1 Increasing the data rate
Supporting the Priority IE Supporting the Layer 3 Header Information IE Supporting the IMSI IE Supporting the TMSI IE Supporting the Encryption Information IE (No Encryption, GSM A5/1, A5/2, A5/3, A5/4, A5/5, A5/6 and A5/7) Supporting multislot configuration Supporting multiple speech versions, such as EFR, AMR Increasing the data rate
Supporting the IE Supporting the Layer 3 Header Information IE Supporting the IMSI IE Supporting the TMSI IE Supporting the Encryption Information IE
Channel Type
Adding two types of data rates for nontransparent service Adding two types of data rates for transparent service
Periodicity Extended Resource Indicator Number of MSs
Supporting the Periodicity IE Not supporting the Extended Resource Indicator IE Supporting the Number of MSs IE
Supporting the Periodicity IE Adding the Extended Resource Indicator IE
Supporting the Periodicity IE Adding the SM field
Supporting the Periodicity IE Supporting the Extended Resource Indicator IE Supporting the Number of MSs IE
Supporting the Number of MSs IE
Supporting the Number of MSs IE
Issue 01 (2008-06-10)
B-13
Element Current Radio Environment
Phase 1 Supporting the Current Radio Environment IE Supporting the Environment of BS "n" IE Supporting the Classmark Information Type 2 IE Not supporting the Classmark Information Type 3 IE Supporting the Interference Band to Be Used IE Supporting the RR Cause IE Supporting the Trace Number IE Supporting the Layer 3 Information IE Supporting the DLCI IE Supporting the Downlink DTX Flag IE Supporting the Cell Identifier List IE
Phase 2 Deleting the Current Radio Environment IE
Phase 2+ Deleting the Current Radio Environment IE
R99 Deleting the Current Radio Environment IE Deleting the Environment of BS "n" IE Supporting the Classmark Information Type 2 IE Supporting the Classmark Information Type 3 IE Supporting the Interference Band to Be Used IE Supporting the RR Cause IE Deleting the Trace Number IE Supporting the Layer 3 Information IE Supporting the DLCI IE Supporting the Downlink DTX Flag IE Supporting inter-RAT handover Adding 3 types of Cell Identification
Environment of BS "n" Classmark Information Type 2 Classmark Information Type 3 Interference Band to Be Used RR Cause Trace Number
Deleting the Environment of BS "n" IE Modifying the coding of CLASSMARK 2
Deleting the Environment of BS "n" IE Supporting the Classmark Information Type 2 IE
Adding the Classmark Information Type 3 IE
Supporting the Classmark Information Type 3 IE
Supporting the Interference Band to Be Used IE Supporting the RR Cause IE Deleting the Trace Number IE Supporting the Layer 3 Information IE Supporting the DLCI IE Supporting the Downlink DTX Flag IE Supporting the Cell Identifier List IE
Supporting the Interference Band to Be Used IE Supporting the RR Cause IE Deleting the Trace Number IE Supporting the Layer 3 Information IE Supporting the DLCI IE Supporting the Downlink DTX Flag IE Adding the support for PCS1900
Layer 3 Information DLCI Downlink DTX Flag Cell Identifier List
Response Request
Supporting the Response Request IE
B-14
Issue 01 (2008-06-10)
Element Resource Indication Method Classmark Information Type 1 Circuit Identity Code List
Phase 1 Supporting the Resource Indication Method IE Supporting the Classmark Information Type 1 IE Not supporting the Circuit Identity Code List IE Not supporting the Diagnostic IE Not supporting the IE Not supporting the Layer 3 Message Contents IE Not supporting the Total Resource Accessible IE Not supporting the Cipher Response Mode IE Not supporting the Channel Needed IE
Phase 2 Supporting the Resource Indication Method IE
Phase 2+ Supporting the Resource Indication Method IE
R99 Supporting the Resource Indication Method IE Supporting the Classmark Information Type 1 IE Supporting the Circuit Identity Code List IE Supporting the Diagnostic IE Supporting the IE Supporting the Layer 3 Message Contents IE Supporting the Total Resource Accessible IE Supporting the Cipher Response Mode IE Supporting the Channel Needed IE
Supporting the Classmark Information Type 1 IE Adding the Circuit Identity Code List IE
Supporting the Classmark Information Type 1 IE
Supporting the Circuit Identity Code List IE
Diagnostic
Adding the Diagnostic IE Adding
Supporting the Diagnostic IE Supporting the IE
Layer 3 Message Contents Chosen Channel
Adding the Layer 3 Message Contents IE
Adding the channel mode field Adding the support for multiple channels
Total Resource Accessible
Adding the Total Resource Accessible IE
Supporting the Total Resource Accessible IE
Cipher Response Mode
Adding the Cipher Response Mode IE
Supporting the Cipher Response Mode IE
Channel Needed
Adding the Channel Needed IE
Changing the coding of this IE Supporting full-rate or half-rate service
Trace Type
Not supporting the Trace Type IE Not supporting the Trigger Id IE Not supporting the Trace Reference IE
Adding the Trace Type IE Adding the Trigger Id IE
Supporting the Trace Type IE Supporting the Trigger Id IE Supporting the Trace Reference IE
Supporting the Trace Type IE Supporting the Trigger Id IE Supporting the Trace Reference IE
Trigger Id
Trace Reference
Adding the Trace Reference IE
Issue 01 (2008-06-10)
B-15
Element Transaction Id
Phase 1 Not supporting the Transaction Id IE Not supporting the Mobile Identity IE Not supporting the OMC Id IE Not supporting the Forward Indicator IE Not supporting the Chosen Encryption Algorithm IE Not supporting the Circuit Pool IE
Phase 2 Adding the Transaction Id IE Adding the Mobile Identity IE Adding the OMC Id IE Adding the Forward Indicator IE Adding the Chosen Encryption Algorithm IE Not supporting the Circuit Pool IE
Phase 2+ Supporting the Transaction Id IE Supporting the Mobile Identity IE Supporting the OMC Id IE Supporting the Forward Indicator IE Supporting the Chosen Encryption Algorithm IE
R99 Supporting the Transaction Id IE Supporting the Mobile Identity IE Supporting the OMC Id IE Supporting the Forward Indicator IE Supporting the Chosen Encryption Algorithm IE Adding several types of circuit pools for the EDGE and HSCSD services Supporting the Circuit Pool List IE Supporting the Time Indication IE Supporting the Resource Situation IE Supporting the Current Channel Type 1 IE Supporting the Queuing Indicator IE Supporting the Speech Version IE Supporting the Assignment Requirement IE
Mobile Identity
OMC Id Forward Indicator Chosen Encryption Algorithm Circuit Pool
Adding the Circuit Pool IE
Circuit Pool List Time Indication
Not supporting the Circuit Pool List IE Not supporting the Time Indication IE Not supporting the Resource Situation IE Not supporting the Current Channel Type 1 IE Not supporting the Queuing Indicator IE Not supporting the Speech Version IE Not supporting the Assignment Requirement IE
Not supporting the Circuit Pool List IE Not supporting the Time Indication IE Not supporting the Resource Situation IE Not supporting the Current Channel Type 1 IE Not supporting the Queuing Indicator IE Not supporting the Speech Version IE Not supporting the Assignment Requirement IE
Adding the Circuit Pool List IE Adding the Time Indication IE Adding the Resource Situation IE Adding the Current Channel Type 1 IE
Resource Situation Current Channel Type 1
Queuing Indicator Speech Version
Adding the Queuing Indicator IE Adding the Speech Version IE Adding the Assignment Requirement IE
Assignment Requirement
B-16
Issue 01 (2008-06-10)
Element Talker Flag
Phase 1 Not supporting the Talker Flag IE Not supporting the Connection Release Requested IE Not supporting the Group Call Reference IE Not supporting the EMLPP Priority IE Not supporting the Configuration Evolution Indication IE Not supporting the Old BSS to New BSS Information IE Not supporting the LSA Identifier IE Not supporting the LSA Identifier List IE Not supporting the LSA Information IE Not supporting the LCS QoS IE Not supporting the LSA Access Control Suppression IE Not supporting the LCS Priority IE
Phase 2 Not supporting the Talker Flag IE Not supporting the Connection Release Requested IE Not supporting the Group Call Reference IE Not supporting the EMLPP Priority IE Not supporting the Configuration Evolution Indication IE
Phase 2+ Adding the Talker Flag IE
R99 Supporting the Talker Flag IE Supporting the Connection Release Requested IE Supporting the Group Call Reference IE Supporting the EMLPP Priority IE Supporting the Configuration Evolution Indication IE Supporting the Old BSS to New BSS Information IE Supporting the LSA Identifier IE Supporting the LSA Identifier List IE Supporting the LSA Information IE Supporting the LCS QoS IE Supporting the LSA Access Control Suppression IE Supporting the LCS Priority IE
Connection Release Requested Group Call Reference EMLPP Priority Configuration Evolution Indication
Adding the Connection Release Requested IE
Adding the Group Call Reference IE Adding the EMLPP Priority IE Adding the Configuration Evolution Indication IE
Old BSS to New BSS Information LSA Identifier
Not supporting the Old BSS to New BSS Information IE Not supporting the LSA Identifier IE Not supporting the LSA Identifier List IE
Adding the Old BSS to New BSS Information IE
Adding the LSA Identifier IE Adding the LSA Identifier List IE
LSA Identifier List
LSA Information LCS QoS
Not supporting the LSA Information IE Not supporting the LCS QoS IE Not supporting the LSA Access Control Suppression IE Not supporting the LCS Priority IE
Adding the LSA Information IE Adding the LCS QoS IE
LSA Access Control Suppression LCS Priority
Adding the LSA Access Control Suppression IE
Adding the LCS Priority IE
Issue 01 (2008-06-10)
B-17
Element Location Type
Phase 1 Not supporting the Location Type IE Not supporting the Location Estimate IE Not supporting the Positioning Data IE Not supporting the LCS Cause IE Not supporting the LCS Client Type IE Not supporting the APDU IE Not supporting the Network Element Identity IE Not supporting the GPS Assistance Data IE Not supporting the Deciphering Keys IE Not supporting the Return Error Request IE Not supporting the Return Error Cause IE Not supporting the Segmentation IE Not supporting the Service Handover IE
Phase 2 Not supporting the Location Type IE Not supporting the Location Estimate IE Not supporting the Positioning Data IE Not supporting the LCS Cause IE Not supporting the LCS Client Type IE Not supporting the APDU IE Not supporting the Network Element Identity IE Not supporting the GPS Assistance Data IE
Phase 2+ Adding the Location Type IE Adding the Location Estimate IE Adding the Positioning Data IE Adding the LCS Cause IE
R99 Supporting the Location Type IE Supporting the Location Estimate IE Supporting the Positioning Data IE Supporting the LCS Cause IE Supporting the LCS Client Type IE Supporting the APDU IE Supporting the Network Element Identity IE Supporting the GPS Assistance Data IE Supporting the Deciphering Keys IE Supporting the Return Error Request IE Supporting the Return Error Cause IE Supporting the Segmentation IE
Location Estimate Positioning Data LCS Cause
LCS Client Type APDU Network Element Identity GPS Assistance Data
Adding the LCS Client Type IE Adding the APDU IE Adding the Network Element Identity IE
Adding the GPS Assistance Data IE
Deciphering Keys
Not supporting the Deciphering Keys IE
Adding the Deciphering Keys IE
Return Error Request
Not supporting the Return Error Request IE
Adding the Return Error Request IE
Return Error Cause Segmentation
Not supporting the Return Error Cause IE Not supporting the Segmentation IE
Adding the Return Error Cause IE Adding the Segmentation IE
Service Handover
Not supporting the Service Handover IE
Not supporting the Service Handover IE
Adding the Service Handover IE
B-18
Issue 01 (2008-06-10)
Element Source RNC to Target RNC Transparent Information (UMTS)
Phase 1 Not supporting the Source RNC to Target RNC Transparent Information (UMTS) IE Not supporting the Source RNC to Target RNC Transparent Information (cdma2000) IE Not supporting the Dual Transfer Mode Information IE Not supporting the Inter RAT Handover Info IE Not supporting the Cdma2000 Capability Information IE
Phase 2 Not supporting the Source RNC to Target RNC Transparent Information (UMTS) IE
Phase 2+ Not supporting the Source RNC to Target RNC Transparent Information (UMTS) IE
R99 Adding the Source RNC to Target RNC Transparent Information (UMTS) IE Adding the Source RNC to Target RNC Transparent Information (cdma2000) IE Adding the Dual Transfer Mode Information IE Adding the Inter RAT Handover Info IE Adding the Cdma2000 Capability Information IE
Source RNC to Target RNC Transparent Information (cdma2000)
Not supporting the Source RNC to Target RNC Transparent Information (cdma2000) IE
Not supporting the Source RNC to Target RNC Transparent Information (cdma2000) IE
Dual Transfer Mode Information Inter RAT Handover Info
Not supporting the Dual Transfer Mode Information IE Not supporting the Inter RAT Handover Info IE
Not supporting the Dual Transfer Mode Information IE Not supporting the Inter RAT Handover Info IE
Cdma2000 Capability Information
Not supporting the Cdma2000 Capability Information IE
Not supporting the Cdma2000 Capability Information IE
Issue 01 (2008-06-10)
B-19
C Reference for GSM Protocols
C
Number Short Title 01 series: GSM system description 01.00 01.01 01.02 01.04 01.31 01.33 01.48 01.56 01.60 01.61 Working Procedures for SMG Abbreviations and Acronyms
Reference for GSM Protocols
C.1 Reference for GSM Protocols
GSM Release 1999 Specifications General Description of a GSM Public Land Mobile Network (PLMN)
Fraud Information Gathering System (FIGS); Service requirements - Stage 0 Lawful Interception requirements for GSM ISDN-based DECT/GSM interworking; Feasibility Study GSM Cordless Telephony System (CTS) (Phase 1); CTS Authentication and Key Generation Algorithms Requirements GPRS requirements General Packet Radio Service (GPRS)
02 series: GSM services 02.01 02.02 02.03 02.04 02.06 02.07 02.08 Principles of Telecommunication Services Supported by a GSM Public Land Mobile Network(PLMN) Bearer Services (BS) Supported by a GSM Public Land Mobile Network (PLMN) Teleservices Supported by a GSM Public Land Mobile Network (PLMN) General on Supplementary Services Types of Mobile Stations (MS) Mobile Station (MS) Features European digital cellular telecommunication system (Phase 2); Quality of service.
Issue 01 (2008-06-10)
C-1
Number 02.09 02.11 02.16 02.17 02.19 02.22 02.24 02.30 02.31 02.32 02.33 02.34 02.40 02.41 02.42 02.43 02.48 02.53 02.56 02.60 02.63 02.66 02.67 02.68 02.69 02.71 02.72 02.76 02.78 02.79
Short Title Security aspects Service Accessibility International Mobile Station Equipment Identities (IMEI) Subscriber Identity Modules, Functional Characteristics Subscriber Identity Module Application Programming Interface (SIM API); Service descriptionStage 1 Stage 1 for Personalization of GSM ME Description of Charge Advice Information (CAI) Man-machine Interface (MMI) of the Mobile Station (MS) Fraud Information Gathering System (FIGS) Service description - Stage 1 Immediate Service Termination (IST); Service description - Stage 1 Lawful intercept Stage 1 High Speed Circuit Switched Data (HSCSD) - Stage 1 Procedures for Call Progress Indications Operator Determined Barring Network Identity and Time zone (NITZ); Service Description, Stage 1 Support of Localized Service Area (SoLSA); Service description; Stage 1 Security mechanisms for the SIM Application Tool kit; Stage 1 Tandem Free Operation (TFO); Service description; Stage 1 GSM Cordless Telephony System (CTS), Phase 1; Service description; Stage 1 General Packet Radio Service Stage 1 Description Packet Data on Signaling channels Service (PDS) - Stage 1 Support of Mobile Number Portability (MNP); Service description; Stage 1 Enhanced Multi-Level Precedence and Pre-emption Service (eMLPP) - Stage 1 Voice Group Call Service (VGCS); Stage 1(ASCI spec) Voice Broadcast Service (VBS); Stage 1(ASCI spec) Location Services (LCS) - Stage 1 Call Deflection Service description, Stage 1 Noise Suppression for the AMR Customized Applications for Mobile network Enhanced Logic (CAMEL); Service definition (Stage 1) Support of Optimal Routeing (SOR); Service definition(Stage 1)
C-2
Issue 01 (2008-06-10)
Number 02.81 02.82 02.83 02.84 02.85 02.86 02.87 02.88 02.90 02.91 02.93 02.94 02.95 02.96 02.97
Short Title Line Identification Supplementary Services - Stage 1 Call Forwarding (CF) Supplementary Services - Stage 1 Call Waiting (CW) and Call Hold (HOLD) Supplementary Services - Stage 1 MultiParty (MPTY) Supplementary Services - Stage 1 Closed User Group (CUG) Supplementary Services -Stage 1 Advice of Charge (AoC) Supplementary Services Stage 1 User-to-User Signaling (UUS) Service Description, Stage 1 Call Barring (CB) Supplementary Services - Stage 1 Stage 1 Decision of Unstructured Supplementary Service Data (USSD) Explicit Call Transfer (ECT) Completion of Calls to Busy Subscriber (CCBS) Service Description - Stage 1 Follow Me Service description - Stage 1 Digital cellular telecommunications system (Phase 2+); Support of Private Numbering Plan (SPNP); Service description, Stage 1 Name Identification Supplementary Services; Stage 1 Multiple Subscriber Profile (MSP) Service description, Stage 1
03 services: GSM network 03.01 03.02 03.03 03.04 03.05 03.07 03.08 03.09 03.10 03.11 03.12 03.13 03.14 03.15 Network Functions Network Architecture Numbering, Addressing and Identification Signaling requirements relating to routeing of calls to mobile subscribers Technical Performance Objectives Restoration Procedures Organization of Subscriber Data Handover Procedures Public Land Mobile Network (PLMN) Connection Types Technical Realization of Supplementary Services -General Aspects Location Registration Procedures Discontinuous Reception (DRX) in the GSM System Support of Dual Tone Multi-Frequency Signaling(DTMF) through the GSM System Technical Realization of Operator Determined Barring
Issue 01 (2008-06-10)
C-3
Number 03.16 03.18 03.19 03.20 03.22 03.26 03.30 03.31 03.32 03.33 03.34 03.35 03.38 03.39 03.40 03.41 03.42 03.43 03.44 03.45 03.46 03.47 03.48 03.49 03.50 03.52 03.53 03.54
Short Title Subscriber Data Management Basic Call Handling GSM API for SIM toolkit stage 2 Security-related Network Functions Functions related to Mobile Station (MS) in idle mode Multiband operation of GSM/DCS 1800 by a single operator Radio Network Planning Aspects Fraud Information Gathering System (FIGS); Service description - Stage 2 Universal Geographical Area Description (GAD) Lawful Interception - stage 2 High Speed Circuit Switched Data (HSCSD); Stage 2 Immediate Service Termination (IST); Stage 2 Alphabets and Language Specific Information for GSM Digital Cellular Telecommunications System (Phase 2)Interface Protocols for the Connection of Short Message, Service Centers (SMSCs) to Short Message Entities (SMEs) Technical Realization of the Short Message Service(SMS) Point-to-Point (PP) Technical Realization of Short Message Service Cell Broadcast (SMSCB) SMS Compression Support of Videotext Support of Teletext in a Public Land Mobile Network (PLMN) Technical realization of facsimile Group 3 service- transparent Technical realization of facsimile group 3 service - non-transparent Example Protocol Stacks for Interconnecting Service Centre(s) (SC) and Mobile Services Switching Centre(s) (MSC) Tool Kit Security Stage 2 Example Protocol Stacks for Interconnecting Cell Broadcast Centre (CBC) and Base Station Controller (BSC) Transmission Planning Aspects of the Speech Service in the GSM Public Land Mobile Network (PLMN) System Lower layers of the GSM Cordless Telephony System (CTS) radio interface - Stage 2 Tandem Free Operation (TFO); Service description, Stage 2 Description for the use of a Shared Inter Working Function (SIWF) in a GSM PLMN; Stage 2
C-4
Issue 01 (2008-06-10)
Number 03.56 03.57 03.58 03.60 03.63 03.64 03.66 03.67 03.68 03.69 03.70 03.71 03.72 03.73 03.78 03.79 03.81 03.82 03.83 03.84 03.85 03.86 03.87 03.88 03.90 03.91 03.93 03.96 03.97
Short Title GSM Cordless Telephony System (CTS), Phase 1; CTS Architecture Description; Stage 2 Mobile Station Application Execution Environment (MExE); Functional description; Stage 2 Characterization, test methods and quality assessment for handsfree Mobile Stations (MSs) General Packet Radio Service (GPRS) Service description; Stage 2 PDS Stage 2 Overall description of the GPRS radio interface; Stage 2 Support of GSM Mobile Number Portability (MNP);Stage 2 Enhanced Multi-Level Precedence and Preemption Service (EMLPP); Stage 2 Voice Group Call Service (VGCS) - Stage 2 Voice Broadcast service (VBS) - Stage 2 Routeing of calls to/from Public Data Network (PDN) Location Services (LCS) Stage 2 Call Deflection stage 2 Support of Localized Service Area (SoLSA); Stage 2 CAMEL Phase 2; Stage 2 Support of Optimal Routeing Line Identification Supplementary Services; Stage 2 Call Forwarding (CF) Supplementary Services; Stage 2 Call Waiting (CW) and Call Hold (HOLD) Supplementary Services; Stage 2 Multi Party (MPTY) Supplementary Services; Stage 2 Closed user Group (CUG) Supplementary Services; Stage 2 Advice of Charge (AoC) Supplementary Services; Stage 2 User-to-user signaling (UUS); Stage 2 Call Barring (CB) supplementary services - Stage 2 Unstructured Supplementary Service Data (USSD) Explicit Call Transfer (ECT) Supplementary Service; Stage 2 Technical realization of Completion of Calls to Busy Subscriber (CCBS); Stage 2 Name Identification Supplementary Services; Stage 2 Multiple subscriber Profile (MSP); Stage 2
04 series: the MS-BSS Interface and specifications (L2 and L3 contexts on the Um interface) 04.01 Mobile Station - Base Station System (MS-BSS) Interface General Aspects and Principles
Issue 01 (2008-06-10)
C-5
Number 04.02 04.03 04.04 04.05 04.06 04.07 04.08 04.10 04.11 04.12 04.13 04.14 04.18 04.21 04.22 04.30 04.31 04.33 04.35 04.53 04.56 04.57 04.60 04.63 04.64 04.65 04.67
Short Title GSM Public Land Mobile Network (PLMN) Access Reference Configuration Mobile Station - Base Station System (MS - BSS) Interface Channel Structures and Access Capabilities Layer 1 - General Requirements Data Link (DL) Layer General Aspects Mobile Station - Base Stations System (MS - BSS) Interface Data Link (DL) Layer Specification Mobile Radio Interface Signaling Layer 3 General Aspects Mobile Radio Interface - Layer 3 Specification Mobile Radio Interface Layer 3 Supplementary Services Specification - General Aspects Point-to-Point (PP) Short Message Service (SMS) Support on Mobile Radio Interface Short Message Service Cell Broadcast (SMSCB) Support on the Mobile Radio Interface Performance Requirements on Mobile Radio Interface Individual equipment type requirements and interworking; Special conformance testing functions Mobile Radio Interface Layer 3 specification; Radio Resource Control Protocol Rate Adaption on the Mobile Station - Base Station System (MS-BSS) Interface Radio Link Protocol for Data and Telematic Services on the MS-BSS Interface Location Services (LCS); Mobile radio interface layer 3 supplementary services specification; Mobile Originating Location Request (MO-LR) Location Services (LCS); Mobile Station (MS) - Serving Mobile Location Centre (SMLC); Radio Resource LCS Protocol (RRLP) Lawful intercept Stage 3 Location Services (LCS); Broadcast Network Assistance for Enhanced Observed Time Difference (E-OTD) and Global Positioning System (GPS) Positioning Methods Inband Tandem Free Operation of Speech codecs, Service Description, stage 3 GSM Cordless Telephony System (CTS), (Phase 1) CTS Radio Interface Layer 3 Specification GSM Cordless Telephony System (CTS), (Phase 1) CTS supervising system Layer 3 Specification General Packet Radio Service (GPRS); Mobile Station (MS) - Base Station System (BSS) interface; Radio Link Control/ Medium Access Control (RLC/MAC) protocol Packet Data on Signaling channels Service (PDS) Service Description, Stage 3 Mobile Station - Serving GPRS Support Node (MS-SGSN) Logical Link Control (LLC) Layer Specification Mobile Station (MS) - Serving GPRS Support Node (SGSN); Subnetwork Dependent Convergence Protocol (SNDCP) Enhanced Multi-Level Precedence and Pre-emption service (eMLPP) - Stage 3
C-6
Issue 01 (2008-06-10)
Number 04.68 04.69 04.71 04.72 04.80 04.81 04.82 04.83 04.84 04.85 04.86 04.87 04.88 04.90 04.91 04.93 04.96
Short Title Group Call Control (GCC) Protocol Broadcast Call Control (BCC) Protocol - Stage 3 Location Services (LCS) Stage 3 Call Deflection (CD) Supplementary Service; Stage 3 Mobile Radio Interface Layer 3 Supplementary Services Specification Formats and Coding Line Identification Supplementary Services - Stage 3 Call Forwarding (CF) Supplementary Services - Stage 3 Call Waiting (CW) and Call Hold (HOLD) Supplementary Services - Stage 3 Multi Party (MPTY) Supplementary Services - Stage 3 Closed User Group (CUG) Supplementary Services - Stage 3 Advice of Charge (AoC) Supplementary Services - Stage 3 User-to-User Signaling (UUS) Supplementary Service Stage 3 Call Barring (CB) Supplementary Services - Stage 3 Unstructured Supplementary Service Data (USSD) Explicit Call Transfer (ECT) Supplementary Service -Stage 3 Completion of Calls to Busy Subscriber (CCBS); Stage 3 Name Identification Supplementary Services; Stage 3
05 series: physical layer on the radio path (L1 context on the Um interface) 05.01 05.02 05.03 05.04 05.05 05.08 05.09 05.10 05.22 05.50 05.56 Physical Layer on the Radio Path (General Description) Multiplexing and Multiple Access on the Radio Path Channel Coding Modulation Radio Transmission and Reception Radio Subsystem Link Control Link Adaptation Radio Subsystem Synchronization Radio Link management in hierarchical networks Background for RF Requirements CTS-FP Radio Sub-system
06 series: Speech Codec Specifications 06.01 Full Rate Speech Processing Functions
Issue 01 (2008-06-10)
C-7
Number 06.02 06.06 06.07 06.08 06.10 06.11 06.12 06.20 06.21 06.22 06.31 06.32 06.41 06.42 06.51 06.53 06.54 06.55 06.60 06.61 06.62 06.71 06.73 06.74 06.75 06.76 06.77 06.78 06.81 06.82
Short Title Half Rate Speech Processing Functions Half Rate Speech - Part 7: ANSI-C Code for GSM Half Rate Speech Codec Half Rate Speech - Part 8: Test Sequence for GSM Half Rate Speech Codec Half Rate Speech; Performance Characterization of the GSM half rate speech codec Full Rate Speech Transcoding Substitution and Muting of Lost Frames for Full Rate Speech Channels Comfort Noise Aspects for Full Rate Speech Traffic Channels Half Rate Speech Transcoding Substitution and Muting of Lost Frames for Half Rate Speech Traffic Channels Comfort Noise Aspects for Half Rate Speech Traffic Channels Discontinuous Transmission (DTX) for Full Rate Speech Traffic Channels Voice Activity Detection (VAD) Discontinuous Transmission (DTX) for Half Rate Speech Traffic Channels Voice Activity Detection (VAD) for Half Rate Speech Traffic Channels Enhanced full rate speech processing functions: General description ANSI-C code for the enhanced full rate speech codec Test sequences for the GSM Enhanced Full Rate (EFR) Performance characterization of the GSM EFR Speech Codec Enhanced full rate speech transcoding Substitution and muting of lost frames for enhanced full rate speech traffic channels Comfort noise aspects for Enhanced Full Rate (EFR) speech traffic channels Adaptive Multi-Rate speech processing functions; General description ANSI-C code for the GSM Adaptive Multi Rate (AMR) speech codec Test sequences for the GSM Adaptive Multi Rate (AMR) speech codec AMR performance characterization ANSI-C code of the selected AMR-NS algorithm Minimum Performance Requirements for Noise Suppresser Application to the AMR Speech Encoder Results of the AMR noise suppression selection phase Discontinuous Transmission (DTX) for enhanced full rate speech traffic channels Voice Activity Detection (VAD) for enhanced full rate speech traffic channels
C-8
Issue 01 (2008-06-10)
Number 06.85 06.90 06.91 06.92 06.93 06.94
Short Title Subjective tests on the interoperability of the HR/FR/EFR speech codecs; single, tandem and tandem free operation Adaptive Multi-Rate speech transcoding Substitution and muting of lost frames for AMR speech traffic channels Comfort noise aspects for Adaptive Multi-Rate speech traffic channels Discontinuous Transmission (DTX) for Adaptive Multi-Rate speech traffic channels Voice Activity Detector (VAD) for Adaptive Multi Rate(AMR) speech traffic channels
07 series: Terminal Adaptation Functions of Mobile Station 07.01 07.02 07.03 07.05 07.07 07.08 07.10 07.60 General on Terminal Adaptation Functions (TAF) for Mobile Stations (MS) Terminal Adaptation Functions (TAF) for Services Using Asynchronous Bearer Capabilities Terminal Adaptation Functions (TAF) for Services Using Synchronous Bearer Capabilities Use of Data Terminal Equipment - Data Circuit Terminating Equipment (DTE-DCE) Interface for Short Message Services (SMS) and Cell Broadcast Services(CBS) AT Command set for GSM Mobile Equipment GSM Application Programming Interface Terminal Equipment to Mobile Station (TE-MS) multiplexer protocol General Packet Radio Service (GPRS); Mobile Station(MS) supporting GPRS
08 series: BTS-MSC interfaces (the A and Abis interfaces) 08.01 08.02 08.04 08.06 08.08 08.14 08.16 08.18 08.20 General Aspects on the BSS-MSC Interface Base Station System - Mobile Services Switching Centre(BSS-MSC) Interface - Interface Principles Base Station System - Mobile Services Switching Centre (BSS-MSC) Interface Layer 1 Specification Signaling Transport Mechanism Specification for the Base Station System - Mobile Services Switching Centre (BSS-MSC) Interface Mobile Switching Centre - Base Station system (MSC-BSS) Interface Layer 3 Specification General Packet Radio Service (GPRS); Base Station System (BSS) - Serving GPRS Support Node (SGSN) interface; Gb Interface Layer 1 General Packet Radio Service (GPRS); Base Station System (BSS) - Serving GPRS Support Node (SGSN) Interface; Network Service General Packet Radio Service (GPRS); Base Station System (BSS) - Serving GPRS Support Node (SGSN); BSS GPRS Protocol Rate Adaptation on the BSS-MSC Interface
Issue 01 (2008-06-10)
C-9
Number 08.31
Short Title Location Services (LCS); Serving Mobile Location Centre (SMLC) - Serving Mobile Location Centre (SMLC); SMLC Peer Protocol (SMLCPP) Location Centre (SMLC); Radio Resource LCS Protocol (RRLP) Base Station Controller - Base Transceiver Station (BSC-BTS) Interface General Aspects Base Station Controller - Base Transceiver Station (BSC-BTS) Interface - Interface Principles Base Station Controller - Base Transceiver Station (BSC-BTS) Interface Layer 1 Structure of Physical Circuits Base Station Controller - Base Transceiver Station (BSC-BTS) Interface Layer 2 Specification Base Station Controller - Base Transceiver Station (BCS-BTS) Interface Layer 3 Specification BSC-BTS O&M Signaling Transport Inband Control of Remote Transcoders and Rate Adaptors Inband Control of Remote Transcoder and Rate Adaptors;(Half Rate) Inband Tandem Free Operation (TFO) of Speech Codecs; Service Description; Stage 3 Location services (LCS) SMLC-BSS interface L3
08.51 08.52 08.54 08.56 08.58 08.59 08.60 08.61 08.62 08.71
09 series: Network interworking 09.01 09.02 09.03 09.04 09.05 09.06 09.07 09.08 09.09 09.10 General Network Interworking scenarios Mobile Application Part ( MAP) Specification Signaling Requirements on Interworking between the Integrated Services Digital Network (ISDN), or Public Switched Telephone Network (PSTN) and the Public Land Mobile Network (PLMN) Interworking between the Public Land Mobile Network and the CSPDN Interworking between PLMN and PAD access Interworking between PLMN and a Packet Switched Public Data Network/Integrated Services digital, Network (PSPDN/ISDN) for Support of Packet Switched Data Transmission Services General Requirements on Interworking between the Public Land Mobile Network (PLMN) and the Integrated Services Digital Network (ISDN) or Public Switched Telephone Network (PSTN) Application of the Base Station System Application Part (BSSAP) on the E-Interface Detailed Signaling Interworking within the PLMN, with the PSTN/ISDN Information Element Mapping between Mobile Station -Base Station System (MS - BSS) and Base Station System - Mobile-services Switching Centre (BSS - MSC) Signaling Procedures and the Mobile Application Part(MAP) Signaling Interworking for Supplementary Services Application of ISUP Version 2 for the ISDN-PLMN (GSM) signaling Signaling interworking between ISDN supplementary services Application Service Element (ASE) and Mobile Application Part (MAP) protocols
09.11 09.12 09.13
C-10
Issue 01 (2008-06-10)
Number 09.14 09.16 09.18 09.31 09.60 09.61 09.78 09.90 09.91 09.94 10 series 10.00 10.43 10.56 10.57 10.59 10.78
Short Title Application of ISUP Version 3 for the ISDN-PLMN Signaling General Packet Radio Service (GPRS); Serving GPRS Support Node (SGSN) - Visitors Location Register (VLR); Gs interface network service specification General Packet Radio Service (GPRS); Serving GPRS Support Node (SGSN) - Visitors Location Register(VLR); Gs interface layer 3 specification Location Services (LCS); Base Station System Application Part LCS Extension (BSSAP-LE) General Packet Radio Service (GPRS); GPRS Tunneling Protocol (GPT) across the Gn and Gp Interface General Packet Radio Service (GPRS); Interworking between the Public Land Mobile Network (PLMN) supporting GPRS and Packet CAMEL Application Part phase 2 (stage 3) Interworking between Phase 1 Infrastructure and Phase 2 Mobile Stations (MS) Interworking Aspects of the SIM/ME Interface Between Phase 1 and Phase 2 Recommended Infrastructure Measures to Overcome Specific Phase 1 Mobile Stations Faults
Digital Cellular Telecommunication System Feature Description Support of Localized Service Area (SoLSA); Work Item Status Project scheduling and open issues: GSM Cordless Telephony System CTS, Phase 1 Project scheduling and open issues: Mobile Station Execution Environment (MExE) Project scheduling and open issues for EDGE Project scheduling and open issues: CAMEL
11 series: specifications of equipments and models 11.10-1 11.10-2 11.10-3 11.10-4 11.11 11.14 11.17 11.18 11.19 11.21 Conformance Specification Mobile Station (MS) Conformance Specification, Part 2 ICS Mobile Station (MS) Conformance Specification, Part 3 Abstract Test suites SIM Application Toolkit conformance Specification Specification of the Subscriber Identity Module - Mobile Equipment (SIM-ME) Interface Phase 2+ SIM Application Tool kit SIM test specification Specification of the 1.8 Volt Subscriber Identity Module - Mobile Equipment (SIM - ME) Interface CTS SIM Fixed Part GSM Radio Aspects Base Station System Equipment Specification
Issue 01 (2008-06-10)
C-11
Number 11.23 11.24 11.26 11.30 11.31 11.32
Short Title GSM Signaling Aspects Base Station System equipment Specification GSM transcoding and rate adaptation: Base station GSM Repeater Equipment Specification Mobile Services Switching Centre Home Location Register specification Visitor Location Register specification
12 series: O&M 12.00 12.01 12.02 12.03 12.04 12.05 12.06 12.07 12.08 12.11 12.15 12.20 12.21 12.22 12.30 12.71 Objectives and structure of GSM Public Land Mobile Network (PLMN) management Common Aspects of Public Land Mobile Network (PLMN) Management Subscriber, Mobile Equipment (ME) and Services Data Administration Security Management Performance Management and Measurements for a GSM Public Land Mobile Network (PLMN) Subscriber Related Call and Event Data Network Configuration Management and Administration Operations and performance management Subscriber and Equipment trace Fault management of the Base Station System (BSS) General Packet Radio Service (GPRS); GPRS Charging Base Station System (BSS) Management Information Network Management (NM) Procedures and Messages on the Abis Interface Interworking of GSM Network Management (NM) Procedures and Messages at the Base Station Controller (BSC) ETSI Object Identifier Tree; Mobile Domain O&M Location Services (LCS); Location services management
13 series: Attachment requirements for GSM 13.01 13.02 13.11 13.21 Attachment requirements for Global System for Mobile communications (GSM) mobile stations; Access Attachment requirements for mobile stations in the DCS 1800 band and additional GSM 900 band Access Terminal essential requirements (RTTE) BSS Radio aspects requirements (RTTE)
C-12
Issue 01 (2008-06-10)
Number 13.34 13.55 13.56 13.60 13.67 13.68
Short Title Attachment requirements for Global System for Mobile communications (GSM); High Speed Circuit Switched Data (HSCSD) Multislot Mobile Stations Access Attachment requirements for Cordless Telephony System Fixed Part (CTS-FP) Access Cordless Telephony System Mobile Stations (CTS-MS) Access Attachment requirements for Global System for Mobile communications (GSM); General Packet Radio Service (GPRS); Mobile stations Access Attachment requirements for Global System for Mobile communications (GSM); Railways Band(R-GSM); Mobile Stations; Access Attachment requirements for Global System for Mobile communications (GSM); Advanced Speech Call Items (GSM-ASCI) Mobile Stations; Access
Issue 01 (2008-06-10)
C-13
D Timers
D
D.1 Timers of Radio Resource Management
D.1.1 Timers on the MS Side
Timer T3120 Function This timer is started when the MS sends a Channel Request message to the network. This timer is used during the random access. The MS starts timer T3122 after the receipt of an Immediate Assignment Reject message. During the asynchronous handover, the MS starts repeating the Handover Access message and starts timer T3124. Timer Length T3122
Timers
The value of timer T3120 is set to a random value according to relevant rules. The maximum value of this timer is 5 seconds. The value of timer T3122 is given by the network in the Immediate Assignment Reject message. The value of timer T3124 is set to 675 ms if the type of the channel that is allocated in the Handover Command message is an SDCCH (+SACCH). Otherwise, Its value is set to 320 ms. The value of timer T3110 is set to such that the DISC frame is sent twice in case there is no answer from the network.
T3124
T3110
This timer is used to delay the channel deactivation after the receipt of a Channel Release message. The delay is used to let some time elapse before the disconnection of the main signaling link.
D.1.2 Timers on the Network Side

Timer T3101 Function This timer is started when the BSC sends a Channel Activation message to the BTS. This timer is stopped when the BSC receives an Establish Indication message from the BTS. This timer is started when the BSC sends a Handover Command message to the MS. This timer is stopped when the BSC receives the Timer Length The value of timer T3101 must be greater than the maximum time for a L2 establishment attempt.
T3103
The value of timer T3103 > the maximum transmission time of the Handover Command message + the value of timer T3124 + the
Issue 01 (2008-06-10)
D-1
D Timers
Timer
Function Handover Complete message for an intra-BSC handover or the Channel Release message for an inter-BSC handover.
Timer Length maximum duration of an attempt to establish a data link in multiframe mode. This timer is set to such a low value that the Physical Information message is continuously transmitted and the duration for asynchronous handover is minimized. The value of timer T3105 is set to 20 ms, which is close to 18 ms that is the duration for sending four TDMA frames once on the FACCH. The value of timer T3107 must be greater than the maximum transmission time of the Assignment Command message, plus twice the maximum duration of an attempt to establish a data link in multiframe mode.
T3105
During asynchronous handover, the BSC starts timer T3105 when sending the Physical Information message. If this timer expires before the reception of a correctly decoded frame from the MS, the network repeats the Physical Information message and restarts timer T3105. This timer is started when the BSC sends an Assignment Command message to the BTS. This timer is stopped when the BSC receives the Assignment Complete message from the BTS. This timer is used to hold the channel long enough for the MS to return to the original channel and to release the channel if the MS is lost. When an RF program does not run, this timer is started if the network detects a lower layer failure. Timer T3109 is also used in a channel release procedure. This timer is started when the BSC sends a Channel Release message to the MS. This timer is stopped when the BSC receives the Release Indication message from the BTS. This timer is used to delay the channel deactivation after the disconnection of the main signaling link. The delay is used to provide some time for possibly retransmitting the disconnection message. This timer is started when the MSC sends a Paging Request message and is stopped when the MSC receives the Paging Response message. This timer is used during channel mode updating and assignment procedure monitoring. This timer is started when the MSC sends an Assignment Request message to the BSC. This timer is stopped under the following conditions: The BSC sends an Assignment Complete message to the MSC. The BSC sends an Assignment Failure message to the MSC. The BSC sends a Clear Request message to the MSC. The BSC receives a Clear Command message
T3107
T3109
The value of timer T3109 must be greater than the value of RADIO_LINK_TIMEOUT multiplied by 0.480 second.
T3111
The value of timer T3111 is equal to the value of timer T3110.
T3113
The value of timer T3113 must be greater than the value of timer T3120 plus the value of timer T3101. 7 seconds
T10
D-2
Issue 01 (2008-06-10)
D Timers
Timer
Function from the MSC.
Timer Length
D.2 Timers of Mobility Management

Timer T3210 Function This timer is started when the MS sends a Location Updating Request message to the network.This timer is stopped when the MS receives one of the following messages: A Location Updating Accept message A Location Updating Reject message An Authentication Reject message Timer T3210 is also stopped when a lower layer failure occurs on the MS. When timer T3210 expires, the MS starts timer T3211. T3211 This timer is started under one of the following conditions: The MS receives a Location Updating Reject message (cause #17: network failure) from the network. A lower layer failure occurs during the location updating. Timer T3211 is stopped under one of the following conditions: Cell change Request for MM connection establishment Change of LA When timer T3211 expires, the MS restarts the location update procedure. T3212 The timeout value of timer T3212 is set in the BSC and is broadcasted in the System Information Type 3 message. The purpose of timer T3212 is to prompt the MS to initiate the location updating request when timer T3212 expires. After a cell selection or cell reselection, the MS sets the value of timer T3212 to the timeout value that is broadcasted in the System Information Type 3 message of the current serving cell. It is recommended that in the areas with high volumes of signaling and traffic flow, a greater value of timeout should be set for timer T3212, whereas in the areas with low volumes of signaling and traffic flow, a smaller value of timeout should be set for timer T3212. 15 seconds Timer Length 20 seconds
Issue 01 (2008-06-10)
D-3
D Timers
Timer T3213
Function This timer is started when the random access of the location updating procedure fails. When this timer expires, the random access procedure is attempted again. The location updating procedure is terminated when the random accesses of two consecutive location updating requests fail. This timer is started when the IMSI detach procedure is initiated. This timer is stopped when the RR connection is released. When timer T3220 expires, the MS enters the Null state or Idle state without attempting to update. This timer is started when the MS sends a CM Service Request or a CM Reestablishment Request message to the network. Timer T3230 is stopped when the MS receives a message that contains a Cipher mode setting IE. This timer is also stopped when the MS receives a CM Service Reject or a CM Service Accept message from the network. When timer T3230 expires, the MS releases the indication. This timer is started when the local Protocol discriminator is terminated normally, or the MS releases all MM connections. Timer T3240 is stopped when the MS receives from the network a correct message, including a Location Updating Accept, a Location Updating Reject, and a CM Service Abort message. When timer T3240 expires, the MS releases the RR connection.
Timer Length 4 seconds
T3220
5 seconds
T3230
15 seconds
T3240
10 seconds

Timer T3250 Function This timer is started when the MSC sends the MS a TMSI Reallocation Command message or a Location Updating Accept message that contains the new TMSI. This timer is stopped when the MSC receives the TMSI Reallocation Complete message. When timer T3250 expires, the MSC releases the RR connection. This timer is started when the MSC sends an Authentication Request message to the MS. This timer is stopped when the MSC receives the Authentication Response message from the MS. When timer T3250 expires, the MSC releases the RR connection. This timer is started when the MSC sends an Identity Request message to the MS. This timer is stopped when the MSC receives the Identity Response message from the MS. When timer T3250 expires, the MSC releases the RR connection. Timer Length 5 seconds
T3260
5 seconds
T3270
5 seconds
D-4
Issue 01 (2008-06-10)
D Timers
D.3 Timers of Circuit-Switched Call Control

Timer T303 Function This timer is started when the MS sends the CM Service Request message. This timer is stopped when the MS receives a Call Proceeding or a Release Complete message. When timer T303 expires, the MS clears the call. This timer is started when the MS sends a Disconnect message to the MSC. This timer is stopped when the MS receives a Release or a Disconnect message. When timer T305 expires, the MS sends a Release message to the network. This timer is started when the MS sends a Release message to the network. This timer is stopped when the MS receives a Release Complete or a Release message. When timer T308 expires, the MS retransmits the Release message and restarts timer T308. This timer is started when the MS receives a Call Proceeding message. This timer is stopped when the MS receives an Alerting, a Connection, a Disconnect, or a Progress message. When timer T310 expires, the MS sends a Disconnect message to the network. This timer is started when the MS sends a Connect message to the network. This timer is stopped when the MS receives a Connect Acknowledge message. When timer T313 expires, the MS sends a Disconnect message to the network. This timer is started when the MS sends a Modify message to the network. This timer is stopped when the MS receives a Modify Complete or a Modify Reject message. When timer T323 expires, the MS clears the call. Timer Length 30 seconds
T305
30 seconds
T308
30 seconds
T310
30 seconds
T313
30 seconds
T323
30 seconds

Timer T301 Function This timer is started when the MS receives an Alerting message. This timer is stopped when the MSC receives a Connect message. When timer T301 expires, the MSC clears the call. This timer is started when the MSC sends a Setup message. This timer is stopped when the MSC receives a Call Confirmed or a Release Complete message. When timer T301 expires, the MSC clears the call. This timer is started when the MSC sends a Disconnect message that does not contain progress indicator #8. This timer is stopped when the MSC receives a Release or a Disconnect message. When timer T305 expires, the MSC sends a Release message to the MS. This timer is started when the MSC sends a Disconnect message that contains progress indicator #8. This timer Timer Length The minimum value of timer T301 is 180 seconds.
T303
The value of timer T303 is set by the network operator.
T305
30 seconds
T306
30 seconds
Issue 01 (2008-06-10)
D-5
D Timers
Timer
Function is stopped when the MSC receives a Release or a Disconnect message. When timer T306 expires, the MSC stops the tone and announcement and sends a Release message to the MS.
Timer Length
T308
This timer is started when the MSC sends a Release message to the MS. This timer is stopped when the MSC receives a Release Complete or a Release message. When timer T308 expires, the MSC retransmits the Release message and restarts timer T308. This timer is started when the MSC receives a Call Confirmed message. This timer is stopped when the MSC receives an Alerting, a Connection, or a Disconnect message. When timer T301 expires, the MSC clears the call. This timer is started when the MSC sends a Connect message to the MS. This timer is stopped when the MS receives a Connect Acknowledge message. When timer T313 expires, the MSC clears the call. This timer is started when the MSC sends a Modify message to the MS. This timer is stopped when the MSC receives a Modify Complete or a Modify Reject message. When timer T323 expires, the MSC clears the call.
T310
T313
T323
30 seconds
D.4 Timers on the A Interface

D.4.1 Timers on the MSC Side
Timer T2 Function This timer is started when the MSC receives a Reset message from the BSC. When timer T2 expires, the MSC sends a Reset Acknowledge message to the BSC, indicating that the MSC has released the related calls and messages. Meanwhile, the MSC sets all the relevant circuits on the MSC side to the idle state. This timer is started when the MSC sends a Reset Circuit message to the BSC. This timer is stopped when the MSC receives one of the following messages: The Reset Circuit Acknowledge message The Reset message The Block message The Unequipped Circuit message When timer T12 expires, the MSC retransmits the Reset Circuit message and restarts timer T12. Timer Length 25 seconds
T12
60 seconds
D-6
Issue 01 (2008-06-10)
D Timers
Timer T16
Function This timer is started when the MSC sends a Reset message to the BSC. This timer is stopped when the MSC receives a Reset Acknowledge message. When timer T16 expires, the MSC retransmits the Reset message and restarts timer T16.
Timer Length 35 seconds
D.4.2 Timers on the BSC Side

Timer T8 Function This timer is started when the old BSC receives a Handover Command message from the MSC. This timer is stopped when the old BSC receives a Clear Command message from the MSC or an Establish Indication message from the old BTS. When timer T8 expires, the old BSC sends a Clear Request message to the MSC. After the BSC sends an Assignment Request message to the MSC, the Assignment Request message should be put into a queue if there is no available TCH. Then, the BSC sends a Queuing Indication message to the MSC and starts timer T11. Timer T11 is stopped when the BSC sends an Assignment Complete or an Assignment Failure message to the MSC. When timer T11 expires, the Assignment Request message is removed from the queue, and the BSC sends a Clear Request message to the MSC to clear the call. This timer is started when the BSC receives a Reset message from the MSC. When timer T13 expires, the BSC sends a Reset Acknowledge message to the MSC. Timer Length 25 seconds
T11
T13
30 seconds
Issue 01 (2008-06-10)
D-7

BSS Signaling Analysis Guide

Uploaded by

Copyright:

Available Formats

BSS Signaling Analysis Guide

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

BSS Signaling Analysis Guide

Uploaded by

Copyright:

Available Formats

HUAWEI BSC6000 Base Station Subsystem V900R008

BSS Signaling Analysis Guide

Issue Date INTERNAL

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd

Huawei Technologies Co., Ltd.

Trademarks and Permissions

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd

HUAWEI BSC6000 Base Station Subsystem BSS Signaling Analysis Guide

2 BSS Signaling Tracing.............................................................................................................. 2-1

3 BSS System Information...........................................................................................................3-1

HUAWEI BSC6000 Base Station Subsystem BSS Signaling Analysis Guide

10 Speech Channel Assignment...............................................................................................10-1

11 Mobile Originated Call.........................................................................................................11-1

12 Mobile Terminated Call........................................................................................................12-1

HUAWEI BSC6000 Base Station Subsystem BSS Signaling Analysis Guide

18 Queuing and Preemption.....................................................................................................18-1

HUAWEI BSC6000 Base Station Subsystem BSS Signaling Analysis Guide

20 Cell Broadcast Messages.......................................................................................................20-1

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd

HUAWEI BSC6000 Base Station Subsystem BSS Signaling Analysis Guide

HUAWEI BSC6000 Base Station Subsystem BSS Signaling Analysis Guide

HUAWEI BSC6000 Base Station Subsystem BSS Signaling Analysis Guide

HUAWEI BSC6000 Base Station Subsystem BSS Signaling Analysis Guide

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd

HUAWEI BSC6000 Base Station Subsystem BSS Signaling Analysis Guide

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd

HUAWEI BSC6000 Base Station Subsystem BSS Signaling Analysis Guide

About This Document

About This Document

Network planners Field engineers System engineers

About This Document

HUAWEI BSC6000 Base Station Subsystem BSS Signaling Analysis Guide

Shift operators Network operators Network administrators

HUAWEI BSC6000 Base Station Subsystem BSS Signaling Analysis Guide

About This Document

About This Document

HUAWEI BSC6000 Base Station Subsystem BSS Signaling Analysis Guide

HUAWEI BSC6000 Base Station Subsystem BSS Signaling Analysis Guide

About This Document

Convention {x | y | ...} [ x | y | ... ] { x | y | ... } * [ x | y | ... ] *

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd

HUAWEI BSC6000 Base Station Subsystem BSS Signaling Analysis Guide

1 Fundamentals of BSS Signaling

Fundamentals of BSS Signaling

About This Chapter

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd

1 Fundamentals of BSS Signaling

HUAWEI BSC6000 Base Station Subsystem BSS Signaling Analysis Guide

1.1 A Interface (TDM)

1.1.1 Protocol Stack on the A Interface (TDM)

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd

HUAWEI BSC6000 Base Station Subsystem BSS Signaling Analysis Guide

1 Fundamentals of BSS Signaling

Figure 1-1 Protocol stack on the A interface

Allocation function SCCP MTP Physical layer

Allocation function SCCP MTP

1.1.2 Physical Layer on the A Interface (TDM)

The specifications to comply with at the physical layer are as follows:

1.1.3 MTP Layer on the A Interface

1 Fundamentals of BSS Signaling