BSS Signaling Analysis

HUAWEI BSC6000 Base Station Subsystem

V900R008

BSS Signaling Analysis Guide

Issue 01

Date 2008-06-10

INTERNAL

Huawei Proprietary and ConfidentialCopyright © Huawei Technologies Co., Ltd

Huawei Technologies Co., Ltd. provides customers with comprehensive technical support and service. For anyassistance, please contact our local office or company headquarters.

Huawei Technologies Co., Ltd.Address: Huawei Industrial Base

Bantian, LonggangShenzhen 518129People's Republic of China

Website: http://www.huawei.com

Email: [email protected]

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 writtenconsent 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. NoticeThe information in this document is subject to change without notice. Every effort has been made in thepreparation of this document to ensure accuracy of the contents, but the statements, information, andrecommendations in this document do not constitute a warranty of any kind, express or implied.

Huawei Proprietary and ConfidentialCopyright © Huawei Technologies Co., Ltd

http://www.huawei.com

mailto:[email protected]

Contents

About This Document.....................................................................................................................1

1 Fundamentals of BSS Signaling..............................................................................................1-11.1 A Interface (TDM)..........................................................................................................................................1-2

1.1.1 Protocol Stack on the A Interface (TDM)..............................................................................................1-21.1.2 Physical Layer on the A Interface (TDM)..............................................................................................1-31.1.3 MTP Layer on the A Interface...............................................................................................................1-31.1.4 SCCP Layer on the A Interface..............................................................................................................1-61.1.5 BSSAP Layer on the A Interface...........................................................................................................1-6

1.2 A Interface (IP)..............................................................................................................................................1-101.2.1 Protocol Stack on the A Interface (IP).................................................................................................1-111.2.2 Physical Layer on the A Interface (IP).................................................................................................1-121.2.3 IP Layer on the A Interface..................................................................................................................1-121.2.4 SCTP/M3UA Layer on the A Interface................................................................................................1-141.2.5 SCCP Layer on the A Interface............................................................................................................1-151.2.6 BSSAP Layer on the A Interface.........................................................................................................1-16

1.3 Abis Interface (TDM)....................................................................................................................................1-201.3.1 Protocol Stack on the Abis Interface (TDM).......................................................................................1-201.3.2 Abis Interface Structure.......................................................................................................................1-211.3.3 Physical Layer on the Abis Interface (TDM).......................................................................................1-231.3.4 LAPD Layer on the Abis Interface.......................................................................................................1-231.3.5 Layer 3 Traffic Management Messages on the Abis Interface............................................................1-241.3.6 Layer 3 OM Messages on the Abis Interface.......................................................................................1-27

1.4 Abis Interface (HDLC)..................................................................................................................................1-291.4.1 Protocol Stack on the Abis Interface (HDLC).....................................................................................1-301.4.2 Physical Layer on the Abis Interface (HDLC).....................................................................................1-301.4.3 HDLC Layer on the Abis Interface......................................................................................................1-311.4.4 LAPD Layer on the Abis Interface.......................................................................................................1-311.4.5 Layer 3 Traffic Management Messages on the Abis Interface............................................................1-321.4.6 Layer 3 OM Messages on the Abis Interface.......................................................................................1-35

1.5 Abis Interface (IP).........................................................................................................................................1-371.5.1 Protocol Stack on the Abis Interface (IP).............................................................................................1-381.5.2 Physical Layer on the Abis Interface (IP)............................................................................................1-381.5.3 UDP/IP Layer on the Abis Interface....................................................................................................1-39

HUAWEI BSC6000 Base Station SubsystemBSS Signaling Analysis Guide Contents

Issue 01 (2008-06-10) Huawei Proprietary and ConfidentialCopyright © Huawei Technologies Co., Ltd

i

1.5.4 LAPD Layer on the Abis Interface.......................................................................................................1-411.5.5 Layer 3 Traffic Management Messages on the Abis Interface............................................................1-421.5.6 Layer 3 OM Messages on the Abis Interface.......................................................................................1-44

1.6 Um Interface..................................................................................................................................................1-471.6.1 Physical Layer on the Um Interface.....................................................................................................1-471.6.2 LAPD Layer on the Um Interface........................................................................................................1-481.6.3 Layer 3 Entity on the Um Interface......................................................................................................1-49

1.7 Gb Interface...................................................................................................................................................1-531.7.1 Protocol Stack on the Gb Interface......................................................................................................1-531.7.2 FR/IP....................................................................................................................................................1-541.7.3 NS.........................................................................................................................................................1-541.7.4 BSSGP..................................................................................................................................................1-55

2 BSS Signaling Tracing.............................................................................................................. 2-12.1 Tracing CS Messages......................................................................................................................................2-2

2.1.1 Tracing the Messages on the A Interface...............................................................................................2-22.1.2 Tracing the Messages on the Abis Interface........................................................................................2-152.1.3 Tracing the Messages on the Pb Interface............................................................................................2-252.1.4 Tracing CS Domain Messages on the Um Interface............................................................................2-302.1.5 Tracing User Messages........................................................................................................................2-322.1.6 Tracing Messages on the BSC-CBC Interface.....................................................................................2-35

2.2 Tracing PS Messages....................................................................................................................................2-372.2.1 Tracing the Messages on the Gb Interface...........................................................................................2-382.2.2 Tracing PS Domain Messages on the Um Interface.............................................................................2-42

3 BSS System Information...........................................................................................................3-13.1 BSS System Information Type........................................................................................................................3-2

3.1.1 System Information Type 1....................................................................................................................3-23.1.2 System Information Types 2, 2bis, 2ter, and 2quater.............................................................................3-63.1.3 System Information Type 3....................................................................................................................3-83.1.4 System Information Type 4..................................................................................................................3-123.1.5 System Information Types 5, 5bis, and 5ter.........................................................................................3-133.1.6 System Information Type 6..................................................................................................................3-143.1.7 System Information Type 7..................................................................................................................3-153.1.8 System Information Type 8..................................................................................................................3-163.1.9 System Information Type 13................................................................................................................3-16

3.2 Internal BSC Signaling Procedure of the System Information.....................................................................3-17

4 Immediate Assignment.............................................................................................................4-14.1 Immediate Assignment Procedure..................................................................................................................4-24.2 Internal BSC Signaling Procedure (Immediate Assignment).........................................................................4-44.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-54.3.2 BSC Sending an Immediate Assignment Reject Message (Case Study)...............................................4-5

ContentsHUAWEI BSC6000 Base Station Subsystem


ii Huawei Proprietary and ConfidentialCopyright © Huawei Technologies Co., Ltd

Issue 01 (2008-06-10)

5 Classmark Update......................................................................................................................5-15.1 Classmark Update Procedure..........................................................................................................................5-2

6 Location Update..........................................................................................................................6-16.1 Location Update Procedure.............................................................................................................................6-2

6.1.1 Periodic Location Update Procedure......................................................................................................6-26.1.2 IMSI Attach Procedure...........................................................................................................................6-46.1.3 Generic Location Update Procedure......................................................................................................6-4

6.2 Internal BSC Signaling Procedures (Location Update)..................................................................................6-66.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-76.3.2 Location Update Failure on the Network Side (Case Study).................................................................6-8

7 Authentication............................................................................................................................7-17.1 Authentication Principles................................................................................................................................7-27.2 Authentication Procedure................................................................................................................................7-27.3 Authentication Reject......................................................................................................................................7-37.4 Internal BSC Signaling Procedure (Authentication).......................................................................................7-47.5 Abnormal Cases and Handling Suggestions (Authentication)........................................................................7-4

7.5.1 Authentication Failure Caused by RR Connection Failure (Case Study)..............................................7-57.5.2 Authentication Failure Caused by Timer T3260 Expiry (Case Study)..................................................7-57.5.3 Authentication Failure Caused by SIM Unregistered (Case Study).......................................................7-5

8 Ciphering.....................................................................................................................................8-18.1 Ciphering Procedure........................................................................................................................................8-28.2 Ciphering Mode Change.................................................................................................................................8-38.3 Internal BSC Signaling Procedure (Ciphering)...............................................................................................8-38.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-48.4.2 Ciphering Failure Caused by MS Doing No Processing (Case Study)..................................................8-4

9 TMSI Reallocation.....................................................................................................................9-19.1 TMSI Reallocation Procedure.........................................................................................................................9-29.2 Internal BSC Signaling Procedure (TMSI Reallocation)................................................................................9-29.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-39.3.2 TMSI Reallocation Caused by T3250 Expiry (Case Study)..................................................................9-3

10 Speech Channel Assignment...............................................................................................10-110.1 Speech Channel Assignment Procedure......................................................................................................10-210.2 Channel Mode Modification Procedure......................................................................................................10-310.3 Internal BSC Signaling Procedure (Speech Channel Assignment).............................................................10-410.4 Abnormal Cases and Handling Suggestions (Speech Channel Assignment)..............................................10-5

10.4.1 BSC Sending an Assignment Failure Message (Case Study)............................................................10-510.4.2 BSC Receiving a Connection Failure Indication Message (Case Study)...........................................10-6



iii

10.4.3 BSC Receiving an Error Indication Message (Case Study)...............................................................10-7

11 Mobile Originated Call.........................................................................................................11-111.1 Mobile Originated Call Establishment Procedure.......................................................................................11-2

11.1.1 Early Assignment Procedure..............................................................................................................11-211.1.2 Late Assignment Procedure...............................................................................................................11-411.1.3 Very Early Assignment Procedure.....................................................................................................11-6

11.2 Internal BSC Signaling Procedure (Mobile Originated Call).....................................................................11-711.3 Abnormal Cases and Handling Suggestions (Mobile Originated Call)......................................................11-7

11.3.1 Calling MS Cannot Be Heard (Case Study).......................................................................................11-811.3.2 MSC Releasing the Call After Sending a CM Service Reject Message (Case Study).......................11-811.3.3 Abnormal Case Caused by MS in Busy State (Case Study)..............................................................11-911.3.4 MSC Sending a Disconnect Message Instead of an Assignment Request Message (Case Study)....11-911.3.5 Abnormal Cases Caused by MS Hangup (Case Study).....................................................................11-911.3.6 Abnormal Cases Caused by MSC Sending a Clear Command Message or a Disconnect Message (CaseStudy)..........................................................................................................................................................11-1011.3.7 LAPD Reporting an Error Indication Message During Call Establishment (Case Study)...............11-11

12 Mobile Terminated Call........................................................................................................12-112.1 Mobile Terminated Call Establishment Procedure.....................................................................................12-212.2 Internal BSC Signaling Procedure (Mobile Terminated Call)....................................................................12-312.3 Abnormal Cases and Handling Suggestions (Mobile Terminated Call).....................................................12-3

12.3.1 No Paging Command on the A Interface (Case Study).....................................................................12-412.3.2 No Paging Command on the Abis Interface (Case Study).................................................................12-412.3.3 No Paging Response on the Abis Interface (Case Study)..................................................................12-512.3.4 No Paging Response on the A Interface (Case Study).......................................................................12-6

13 BSC Release.............................................................................................................................13-113.1 Normal Release Procedure..........................................................................................................................13-213.2 Local Release Procedure.............................................................................................................................13-4

14 Handover..................................................................................................................................14-114.1 Handover Procedures..................................................................................................................................14-2

14.1.1 Intra-BSC Handover Procedure.........................................................................................................14-214.1.2 Inter-BSC Handover Procedure.........................................................................................................14-414.1.3 Inter-MSC Handover Procedure.........................................................................................................14-614.1.4 Inter-RAT Handover Procedure.........................................................................................................14-7

14.2 Internal BSC Signaling Procedures (Handover).........................................................................................14-914.2.1 Internal BSC Signaling Procedure (Intra-BSC Handover)................................................................14-914.2.2 Internal BSC Signaling Procedure (Inter-BSC Handover)..............................................................14-1014.2.3 Internal BSC Signaling Procedure (Inter-MSC Handover)..............................................................14-1014.2.4 Internal BSC Signaling Procedure (Inter-RAT Handover)..............................................................14-11

14.3 Abnormal Cases and Handling Suggestions (Handover)..........................................................................14-1114.3.1 No Available Channels in the Target Cell (Case Study)..................................................................14-1114.3.2 Old BSS Not Receiving a Specified Message Upon T8 Expiry (Case Study).................................14-12



iv Huawei Proprietary and ConfidentialCopyright © Huawei Technologies Co., Ltd

Issue 01 (2008-06-10)

14.3.3 MS Returning to the Old Channel After Inter-Cell Handover Failure (Case Study).......................14-1214.3.4 BSC Receiving a Connection Failure Indication Message (Case Study).........................................14-1314.3.5 Forced Handover Failure (Case Study)............................................................................................14-1314.3.6 Handover Failure Caused by CIC Malfunction (Case Study)..........................................................14-1414.3.7 Handover Failure Caused by MS Access Failure (Case Study).......................................................14-14

15 Call Re-Establishment...........................................................................................................15-115.1 Call Re-Establishment Procedure................................................................................................................15-215.2 Internal BSC Signaling Procedure (Call Re-Establishment).......................................................................15-415.3 Abnormal Cases and Handling Suggestions (Call Re-Establishment)........................................................15-4

15.3.1 Network Sending a CM Service Reject Message (Case Study).........................................................15-415.3.2 Call Re-Establishment Not Allowed or Re-Establishment Failure (Case Study)..............................15-515.3.3 Call Re-Establishment Failure Caused by RR Connection Failure (Case Study)..............................15-5

16 Directed Retry.........................................................................................................................16-116.1 Directed Retry Procedures..........................................................................................................................16-2

16.1.1 Intra-BSC Directed Retry Procedure..................................................................................................16-216.1.2 Inter-BSC Directed Retry Procedure..................................................................................................16-416.1.3 Inter-MSC Directed Retry Procedure.................................................................................................16-6

16.2 Internal BSC Signaling Procedures (Directed Retry)..................................................................................16-716.2.1 Internal BSC Signaling Procedure (Intra-BSC Directed Retry).........................................................16-816.2.2 Internal BSC Signaling Procedure (Inter-BSC Directed Retry).........................................................16-816.2.3 Internal BSC Signaling Procedure (Inter-MSC Directed Retry)........................................................16-9

16.3 Abnormal Cases and Handling Suggestions (Directed Retry)....................................................................16-916.3.1 Directed Retry Failure Caused by No Available Channels in the Target Cell (Case Study).............16-916.3.2 Directed Retry Failure Caused by Channel Activation Failure (Case Study)..................................16-10

17 BSC Re-Assignment...............................................................................................................17-117.1 BSC Re-Assignment Procedure..................................................................................................................17-217.2 Internal BSC Signaling Procedure (BSC Re-Assignment).........................................................................17-317.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-118.1 Queuing Procedure......................................................................................................................................18-218.2 Preemption Procedure.................................................................................................................................18-318.3 Internal BSC Signaling Procedure (Queuing and Preemption)...................................................................18-418.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-119.1 Short Message Procedures..........................................................................................................................19-2

19.1.1 Short Message Sending Procedure of an Idle MS..............................................................................19-219.1.2 Short Message Receiving Procedure of an Idle MS...........................................................................19-319.1.3 Short Message Sending Procedure of a Busy MS..............................................................................19-5



v

19.1.4 Short Message Receiving Procedure of a Busy MS...........................................................................19-519.2 Internal BSC Signaling Procedure (Short Messages).................................................................................19-619.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-120.1 Cell Broadcast Message Procedures...........................................................................................................20-2

20.1.1 CBS-BSC Message Procedure...........................................................................................................20-220.1.2 BSC-BTS Message Procedure...........................................................................................................20-5

20.2 Internal BSC Signaling Procedure (Cell Broadcast Messages)...................................................................20-620.3 Abnormal Cases and Handling Suggestions (Cell Broadcast Messages)...................................................20-7

20.3.1 MS Failure to Receive Broadcast Messages (Case Study)................................................................20-720.3.2 Cell Not Configured with CBCH (Case Study).................................................................................20-8

21 GPRS.........................................................................................................................................21-121.1 GPRS Procedure..........................................................................................................................................21-2

21.1.1 Uplink TBF Establishment Procedure (CCCH Phase One Access)...................................................21-321.1.2 Uplink TBF Establishment Procedure (CCCH Phase Two Access)..................................................21-421.1.3 Uplink TBF Establishment Procedure (PACCH Access)..................................................................21-421.1.4 Uplink TBF Release Procedure..........................................................................................................21-521.1.5 Downlink TBF Establishment Procedure (CCCH)............................................................................21-621.1.6 Downlink TBF Establishment Procedure (PACCH)..........................................................................21-821.1.7 Downlink TBF Release Procedure.....................................................................................................21-921.1.8 GPRS Attach Procedure...................................................................................................................21-1021.1.9 GPRS Detach Procedure..................................................................................................................21-1221.1.10 Routing Area Update Procedure....................................................................................................21-1421.1.11 PDP Context Activation Procedure................................................................................................21-1721.1.12 PDP Context Deactivation Procedure............................................................................................21-1921.1.13 PDP Context Modification Procedure............................................................................................21-2121.1.14 Circuit Paging Procedure...............................................................................................................21-2121.1.15 Packet Paging Procedure................................................................................................................21-2221.1.16 GPRS Suspension and Resumption Procedure..............................................................................21-23

21.2 Internal BSC Signaling Procedures...........................................................................................................21-2521.3 Abnormal Cases and Handling Suggestions (GPRS)................................................................................21-26

21.3.1 Abnormal PCU Cell Startup (Case Study).......................................................................................21-2621.3.2 GPRS Service Access Not Allowed (Case Study)...........................................................................21-28



vi Huawei Proprietary and ConfidentialCopyright © Huawei Technologies Co., Ltd

Issue 01 (2008-06-10)

Figures

Figure 1-1 Protocol stack on the A interface........................................................................................................1-3Figure 1-2 L3 signaling message processing procedure.......................................................................................1-5Figure 1-3 Protocol Stack on the A Interface (IP)..............................................................................................1-11Figure 1-4 Protocol stack on the Abis interface.................................................................................................1-21Figure 1-5 Abis interface structure.....................................................................................................................1-22Figure 1-6 Logical links on the Abis interface...................................................................................................1-23Figure 1-7 Management objects.........................................................................................................................1-27Figure 1-8 Protocol stack on the Abis interface (HDLC)...................................................................................1-30Figure 1-9 Management objects.........................................................................................................................1-35Figure 1-10 Protocol stack on the Abis interface (IP)........................................................................................1-38Figure 1-11 Management objects.......................................................................................................................1-45Figure 1-12 Interfaces of L1 on the Um interface..............................................................................................1-48Figure 1-13 L3 signaling message processing procedure...................................................................................1-51Figure 1-14 Services provided by the RR sublayer............................................................................................1-52Figure 1-15 Services provided by the MM sublayer..........................................................................................1-53Figure 1-16 Protocol stack on the Gb interface..................................................................................................1-54Figure 1-17 Service model of BSSGP................................................................................................................1-56Figure 2-1 Trace BSSAP Message on the A Interface dialog box.......................................................................2-3Figure 2-2 Tracing BSSAP messages on the A interface.....................................................................................2-4Figure 2-3 Trace SCCP Message on the A Interface dialog box.........................................................................2-5Figure 2-4 Tracing SCCP messages on the A interface.......................................................................................2-6Figure 2-5 Trace MTP3 Message on the A Interface dialog box.........................................................................2-7Figure 2-6 Tracing MTP3 messages on the A interface.......................................................................................2-8Figure 2-7 Trace MTP2 Message on the A Interface dialog box.........................................................................2-9Figure 2-8 Tracing MTP2 messages on the A interface.....................................................................................2-10Figure 2-9 Trace SCTP Message on the A Interface dialog box........................................................................2-11Figure 2-10 Tracing SCTP messages on the A interface...................................................................................2-12Figure 2-11 Trace M3UA Message on the A Interface dialog box....................................................................2-13Figure 2-12 Tracing M3UA messages on the A interface..................................................................................2-14Figure 2-13 Trace RSL Message on the Abis Interface dialog box...................................................................2-16Figure 2-14 Tracing RSL messages on the Abis interface.................................................................................2-17Figure 2-15 Trace OML Message on the Abis Interface dialog box..................................................................2-18Figure 2-16 Tracing OML messages on the Abis interface...............................................................................2-19

HUAWEI BSC6000 Base Station SubsystemBSS Signaling Analysis Guide Figures


vii

Figure 2-17 Trace ESL Message on the Abis Interface dialog box...................................................................2-20Figure 2-18 Tracing ESL messages on the Abis interface.................................................................................2-21Figure 2-19 Trace EML Message on the Abis Interface dialog box..................................................................2-22Figure 2-20 Trace EML Message on the Abis Interface dialog box..................................................................2-23Figure 2-21 Trace LAPD Message on the Abis Interface dialog box................................................................2-24Figure 2-22 Tracing LAPD messages on the Abis interface..............................................................................2-25Figure 2-23 Trace Application Message on the Pb Interface dialog box...........................................................2-26Figure 2-24 Tracing application messages on the Pb interface..........................................................................2-27Figure 2-25 Trace LAPD Message on the Pb Interface dialog box...................................................................2-29Figure 2-26 Tracing LAPD messages on the Pb interface.................................................................................2-30Figure 2-27 Trace Message on the Um interface dialog box (set TRX as the filter condition).........................2-31Figure 2-28 Tracing messages on the Um interface...........................................................................................2-32Figure 2-29 Trace User Message dialog box......................................................................................................2-33Figure 2-30 Tracing user messages....................................................................................................................2-34Figure 2-31 Trace the Message at BSC-CBC Interface dialog box...................................................................2-36Figure 2-32 Tracing Messages on the BSC-CBC Interface ..............................................................................2-37Figure 2-33 Trace SIG Message on the Gb Interface dialog box.......................................................................2-39Figure 2-34 Tracing SIG messages on the Gb interface.....................................................................................2-40Figure 2-35 Trace PTP Message on the Gb Interface dialog box......................................................................2-41Figure 2-36 Tracing PTP messages on the Gb interface....................................................................................2-42Figure 2-37 Trace PS Message on the Um Interface dialog box........................................................................2-43Figure 2-38 Trace PS Message on the Um Interface dialog box........................................................................2-44Figure 3-1 Set Cell Attributes dialog box..........................................................................................................3-19Figure 4-1 Immediate assignment procedure.......................................................................................................4-2Figure 5-1 Classmark update procedure...............................................................................................................5-2Figure 6-1 Periodic location update procedure....................................................................................................6-2Figure 7-1 Authentication procedure....................................................................................................................7-3Figure 7-2 Unsuccessful authentication procedure..............................................................................................7-4Figure 8-1 Ciphering procedure...........................................................................................................................8-2Figure 9-1 TMSI reallocation procedure..............................................................................................................9-2Figure 10-1 Speech channel assignment procedure...........................................................................................10-2Figure 10-2 Channel mode modification procedure...........................................................................................10-4Figure 11-1 Early assignment procedure............................................................................................................11-3Figure 11-2 Late assignment procedure.............................................................................................................11-5Figure 11-3 Very early assignment procedure...................................................................................................11-6Figure 12-1 Mobile terminated call establishment procedure............................................................................12-2Figure 13-1 Normal release procedure...............................................................................................................13-3Figure 13-2 Local release procedure..................................................................................................................13-5Figure 14-1 Intra-BSC handover procedure.......................................................................................................14-2Figure 14-2 Inter-BSC handover procedure.......................................................................................................14-5Figure 14-3 Inter-MSC handover procedure......................................................................................................14-7Figure 14-4 GSM-to-UMTS handover procedure..............................................................................................14-8

FiguresHUAWEI BSC6000 Base Station Subsystem


viii Huawei Proprietary and ConfidentialCopyright © Huawei Technologies Co., Ltd

Issue 01 (2008-06-10)

Figure 14-5 UMTS-to-GSM handover procedure..............................................................................................14-9Figure 15-1 Call re-establishment procedure.....................................................................................................15-2Figure 16-1 Intra-BSC directed retry procedure................................................................................................16-3Figure 16-2 Inter-BSC directed retry procedure................................................................................................16-5Figure 16-3 Inter-MSC directed retry procedure................................................................................................16-7Figure 17-1 BSC re-assignment procedure........................................................................................................17-2Figure 18-1 Queuing procedure.........................................................................................................................18-2Figure 18-2 Preemption procedure.....................................................................................................................18-3Figure 19-1 Short message sending procedure of an idle MS............................................................................19-2Figure 19-2 Short message receiving procedure of an idle MS.........................................................................19-4Figure 19-3 Short message sending procedure of a busy MS............................................................................19-5Figure 19-4 Short message receiving procedure of a busy MS..........................................................................19-6Figure 20-1 Procedure for sending or replacing a message...............................................................................20-2Figure 20-2 Procedure for deleting an existing message....................................................................................20-3Figure 20-3 Procedure for querying the CBCH status.......................................................................................20-3Figure 20-4 Procedure for querying the message status.....................................................................................20-4Figure 20-5 Procedure for resetting a cell..........................................................................................................20-4Figure 20-6 Procedure for setting the DRX.......................................................................................................20-5Figure 20-7 BSC sending an SMS broadcast command message......................................................................20-6Figure 20-8 BTS sending the BSC a CBCH Loading Indication message........................................................20-6Figure 20-9 SMSCB procedure..........................................................................................................................20-7Figure 21-1 Uplink TBF establishment procedure (CCCH phase one access)..................................................21-3Figure 21-2 Uplink TBF establishment procedure (CCCH phase two access)..................................................21-4Figure 21-3 Uplink TBF establishment procedure (PACCH access).................................................................21-5Figure 21-4 Uplink TBF release procedure........................................................................................................21-6Figure 21-5 Downlink TBF establishment procedure (CCCH).........................................................................21-7Figure 21-6 Downlink TBF establishment procedure on the uplink PACCH...................................................21-8Figure 21-7 Downlink TBF establishment procedure on the downlink PACCH...............................................21-9Figure 21-8 Downlink TBF release procedure.................................................................................................21-10Figure 21-9 Combined GPRS/IMSI attach procedure.....................................................................................21-11Figure 21-10 MS initiating the GPRS detach procedure..................................................................................21-13Figure 21-11 SGSN initiating the GPRS detach procedure.............................................................................21-13Figure 21-12 HLR initiating the GPRS detach procedure...............................................................................21-14Figure 21-13 Intra-SGSN routing area update procedure................................................................................21-15Figure 21-14 Inter-SGSN routing area update procedure................................................................................21-16Figure 21-15 MS-requested PDP context activation procedure.......................................................................21-17Figure 21-16 Network-requested PDP context activation procedure...............................................................21-18Figure 21-17 Procedure of the PDP context deactivation initiated by the MS................................................21-19Figure 21-18 Procedure of the PDP context deactivation initiated by the SGSN............................................21-20Figure 21-19 Procedure of the PDP context deactivation initiated by the GGSN...........................................21-20Figure 21-20 Procedure of the PDP context modification initiated by the SGSN...........................................21-21Figure 21-21 Circuit paging procedure initiated through the SGSN................................................................21-22

HUAWEI BSC6000 Base Station SubsystemBSS Signaling Analysis Guide Figures


ix

Figure 21-22 Procedure of packet paging........................................................................................................21-23Figure 21-23 GPRS suspension and resumption procedure.............................................................................21-24Figure 21-24 Normal PCU cell startup procedure............................................................................................21-27

FiguresHUAWEI BSC6000 Base Station Subsystem


x Huawei Proprietary and ConfidentialCopyright © Huawei Technologies Co., Ltd

Issue 01 (2008-06-10)

Tables

Table 1-1 BSSAP protocol functionality..............................................................................................................1-8Table 1-2 BSSAP protocol functionality............................................................................................................1-17Table 1-3 Administrative State...........................................................................................................................1-28Table 1-4 Operational State................................................................................................................................1-28Table 1-5 Available State...................................................................................................................................1-28Table 1-6 Administrative State...........................................................................................................................1-35Table 1-7 Operational State................................................................................................................................1-36Table 1-8 Available State...................................................................................................................................1-36Table 1-9 Administrative State...........................................................................................................................1-45Table 1-10 Operational State..............................................................................................................................1-46Table 1-11 Available State.................................................................................................................................1-46Table 3-1 Contents of System Information Type 1..............................................................................................3-3Table 3-2 Format of cell channel description.......................................................................................................3-3Table 3-3 Format of cell channel description.......................................................................................................3-3Table 3-4 Relation between "S" and "T"..............................................................................................................3-5Table 3-5 Contents of System Information Type 2, 2bis, 2ter, and 2quater........................................................ 3-6Table 3-6 Multiband reporting............................................................................................................................. 3-8Table 3-7 Contents of System Information Type 3..............................................................................................3-8Table 3-8 Meaning of the CCCH-CONF............................................................................................................. 3-9Table 3-9 Parameters affecting cell priority in cell selection.............................................................................3-11Table 3-10 Contents of System Information Type 4..........................................................................................3-12Table 3-11 Contents of System Information Type 5, 5bis, and 5ter..................................................................3-14Table 3-12 Contents of System Information Type 6..........................................................................................3-15Table 3-13 Contents of System Information Type 7..........................................................................................3-15Table 3-14 Contents of System Information Type 8..........................................................................................3-16Table 3-15 Contents of System Information Type 13........................................................................................3-16Table 3-16 Mapping between RACH control parameters in System Information Type 1 and the correspondingparameters on the BSC6000 Local Maintenance Terminal.............................................................................3-18Table 3-17 Control channel parameters in System Information Type 3 and the corresponding parameters on theBSC6000 Local Maintenance Terminal..........................................................................................................3-20Table 3-18 Cell option parameters in System Information Type 3 and the corresponding parameters on theBSC6000 Local Maintenance Terminal..........................................................................................................3-20Table 3-19 Cell selection parameters in System Information Type 3 and the corresponding parameters on theBSC6000 Local Maintenance Terminal..........................................................................................................3-21

HUAWEI BSC6000 Base Station SubsystemBSS Signaling Analysis Guide Tables


xi

Table 3-20 Rest Oct parameters in System Information Type 4 and the corresponding parameters on the BSC6000Local Maintenance Terminal...........................................................................................................................3-22

TablesHUAWEI BSC6000 Base Station Subsystem


xii Huawei Proprietary and ConfidentialCopyright © Huawei Technologies Co., Ltd

Issue 01 (2008-06-10)

About This Document

Purpose

This document describes the GBSS signaling fundamental, signaling trace, and systeminformation, as well as the procedures such as location update, authentication, encryption, andcall procedure.

Product Version

The following table lists the product versions related to this document.

Product Name Model Product Version

BSC BSC6000 V900R008C01

BTS BTS3012 V300R004&V300R005&V300R006

BTS3012AE V300R005&V300R006

BTS3006C V300R005&V300R006

BTS3002E V300R005

BTS3036/BTS3900GSM

V300R008

BTS3036A/BTS3900AGSM

V300R008

DBS3036/DBS3900GSM

V300R008

PCU PCU6000 V300R008

Intended Audience

This document is intended for:

l Network planners

l Field engineers

l System engineers

HUAWEI BSC6000 Base Station SubsystemBSS Signaling Analysis Guide About This Document


1

l Shift operators

l Network operators

l Network administrators

Change HistoryFor 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 Ainterface 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 Uminterface, Abis interface, A interface, Pb interface, Gb interface, and BSC-CBC interface, andsingle user signaling tracing.

3 BSS System Information

System information (SI) refers to the major radio network parameters on the Um interface suchas 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. Whenthe MS location information is changed, a location update procedure is initiated to maintainconsistency among the previous three network elements.

7 Authentication

The purpose of authentication is to permit the network to check whether the identity providedby the MS is acceptable and to prevent the private information on the legal subscribers frombeing stolen.

8 Ciphering

Ciphering is used to secure the information exchange between an MS and a BTS. The informationconsists of the signaling information and the subscriber information. The subscriber informationconsists of the subscriber data and the subscriber voice.

9 TMSI Reallocation

About This DocumentHUAWEI BSC6000 Base Station Subsystem


2 Huawei Proprietary and ConfidentialCopyright © Huawei Technologies Co., Ltd

Issue 01 (2008-06-10)

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 theservice requests.

11 Mobile Originated Call

Mobile originated call refers to a call procedure in which an MS calls another MS or a fixedphone.

12 Mobile Terminated Call

Mobile terminated call refers to a call procedure in which an MS is called by another MS or afixed 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 cellsand reduces call drops. Handover also lowers cross interference. The handover procedureinvolves 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 linkfailure. 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 allocationin a serving cell during channel assignment, the BSS hands over the channel request from theserving cell to a neighbor cell.

17 BSC Re-Assignment

This describes BSC re-assignment. BSC re-assignment refers to a TCH assignment procedureinitiated by the BSC after the BSC receives an Assignment Failure message from the MS on theSDCCH. 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, shortmessages are transferred on the SACCH. The short message procedure comprises twofundamental procedures: mobile originating short message transfer procedure and mobileterminating short message transfer procedure.

20 Cell Broadcast Messages

The short message service cell broadcast (SMSCB) is similar to the paging station broadcastservice. The operators broadcast messages to the subscribers in the specified areas. Thesubscribers that subscribe to the service receive the messages broadcast by the operators.



3

21 GPRS

This describes the procedure related to PS services, the internal processing procedure, theexceptional 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

DANGERIndicates a hazard with a high level of risk that, if not avoided,will result in death or serious injury.

WARNINGIndicates a hazard with a medium or low level of risk which, ifnot avoided, could result in minor or moderate injury.

CAUTIONIndicates a potentially hazardous situation that, if not avoided,could cause equipment damage, data loss, and performancedegradation, or unexpected results.

TIP Indicates a tip that may help you solve a problem or save yourtime.

NOTE Provides additional information to emphasize or supplementimportant points of the main text.

2. General Conventions

Convention Description

Times New Roman Normal paragraphs are in Times New Roman.

Boldface Names of files,directories,folders,and users are in boldface. Forexample,log in as user root .

Italic Book titles are in italics.

Courier New Terminal display is in Courier New.

3. Command Conventions


Boldface The keywords of a command line are in boldface.

Italic Command arguments are in italic.

[ ] Items (keywords or arguments) in square brackets [ ] are optional.

About This DocumentHUAWEI BSC6000 Base Station Subsystem


4 Huawei Proprietary and ConfidentialCopyright © Huawei Technologies Co., Ltd

Issue 01 (2008-06-10)


{x | y | ...} Alternative items are grouped in braces and separated by verticalbars.One is selected.

[ x | y | ... ] Optional alternative items are grouped in square brackets andseparated by vertical bars.One or none is selected.

{ x | y | ... } * Alternative items are grouped in braces and separated by verticalbars.A minimum of one or a maximum of all can be selected.

[ x | y | ... ] * Alternative items are grouped in braces and separated by verticalbars.A minimum of zero or a maximum of all can be selected.

4. GUI Conventions


Boldface Buttons,menus,parameters,tabs,window,and dialog titles are inboldface. For example,click OK.

> Multi-level menus are in boldface and separated by the ">" signs.For example,choose File > Create > Folder .

5. Keyboard Operation


Key Press the key.For example,press Enter and press Tab.

Key1+Key2 Press the keys concurrently.For example,pressing Ctrl+Alt+Ameans the three keys should be pressed concurrently.

Key1,Key2 Press the keys in turn.For example,pressing Alt,A means the twokeys should be pressed in turn.

6. Mouse Operation

Action Description

Click Select and release the primary mouse button without moving thepointer.

Double-click Press the primary mouse button twice continuously and quicklywithout moving the pointer.

Drag Press and hold the primary mouse button and move the pointerto a certain position.



5

1 Fundamentals of BSS Signaling

About This Chapter

The external BSS interfaces, which are the Um interface between the BSS and the MS, the Ainterface 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 NSSand the BSS.

1.2 A Interface (IP)The A interface, which is a standard interface, is a communication interface between the NSSand 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. Itis an internal interface.

1.6 Um InterfaceThe Um interface lies between an MS and the BTS. It is used for the interworking between theMS and the fixed part of the GSM system. The links on the Um interface are radio links. TheUm interface transmits the information about radio resource management, mobilitymanagement, and connection management.

1.7 Gb InterfaceThis describes the Gb interface. The Gb interface lies between the BSS and the SGCN. It is astandard interface.

HUAWEI BSC6000 Base Station SubsystemBSS Signaling Analysis Guide 1 Fundamentals of BSS Signaling


1-1

1.1 A Interface (TDM)The A interface, which is a standard interface, is a communication interface between the NSSand 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, MTPlayer, 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 TDMtransmission mode is used, including the interface type, transmission rate, and specifications tocomply with.

1.1.3 MTP Layer on the A InterfaceThe MTP layer on the A interface provides reliable signaling message transmission in thesignaling network. In case of system failure and signaling network failure, it takes measures toavoid or reduce the message loss, repetition, and out of sequence.

1.1.4 SCCP Layer on the A InterfaceThe SCCP, with the help of MTP L3, provides complete network layer functions and reliableservices for information exchange in any form.

1.1.5 BSSAP Layer on the A InterfaceThe 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, MTPlayer, 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 aboutMS management, mobility management, connection management, and service flow control.

The A interface is a standard interface and uses the SS7 protocol. The protocol reference modelis shown in Figure 1-1.

1 Fundamentals of BSS SignalingHUAWEI BSC6000 Base Station Subsystem


1-2 Huawei Proprietary and ConfidentialCopyright © Huawei Technologies Co., Ltd

Issue 01 (2008-06-10)

Figure 1-1 Protocol stack on the A interface

DTAP BSSMAP

Allocation function

BSSAP

SCCP

MTP

DTAP BSSMAP

Allocation function

BSSAP

SCCP

MTP

Physical layer

A

BSS MSC

DTAP: Direct Transfer ApplicationPart

MTP: Message Transfer Part SCCP: Signaling ConnectionControl Part

BSSAP: Base Station SubsystemApplication Part

BSSMAP: Base Station SubsystemManagement Application Part

1.1.2 Physical Layer on the A Interface (TDM)This describes the characteristics of the physical layer on the A interface when TDMtransmission mode is used, including the interface type, transmission rate, and specifications tocomply with.

In TDM transmission mode, E1/T1 electrical interface and STM-1 optical interface aresupported. The transmission rates are as follows:

l E1 transmission rate: 2.048 Mbit/s

l T1 transmission rate: 1.544 Mbit/s

l STM-1 transmission rate: 155.52 Mbit/s

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

l E1 complies with the G.703, G.704, and G.823.

l T1 complies with the G.703, G.704, G.824, and T1.403.

l STM-1 complies with the G.707, G.957, G.783, and G.825.

l Frame structure, synchronization, and timing comply with the G.705.

l Fault management complies with the G.732.

l CRC4 complies with the G.704.

1.1.3 MTP Layer on the A InterfaceThe MTP layer on the A interface provides reliable signaling message transmission in thesignaling network. In case of system failure and signaling network failure, it takes measures toavoid or reduce the message loss, repetition, and out of sequence.



1-3

The MTP protocols are defined in ITU-T Q.701–Q.710 recommendations. The MTP layercomprises three function layers, the signaling data link layer, signaling link layer, and signalingnetwork layer.

Signaling Data Link LayerSignaling 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 isdetermined through the negotiation between the BSC and the MSC. The timeslot can be used toestablish a semi-permanent connection.

A signaling data link serves as an information bearer of SS7. One of the important features ofthe signaling data link is that the link is transparent, that is, the data transmitted on the link cannotbe changed. Therefore, equipment such as echo canceler, digital attenuator, and A/u rateconverter, cannot be connected to this link.

Signaling Link Function LayerSignaling link function layer (L2) specifies the functions and procedures for sending signalingto data links. Together with L1, it provides reliable signaling message transmission between twodirectly connected signaling points.

L2 guarantees error-free transmission of message codes when there are bit errors at L1. L2performs 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 LayerBy controlling the route and performance of the signaling network, signaling network functionlayer (L3) guarantees reliable transmission of signaling information to the user part, regardlessof whether the signaling network is functional or not. The signaling network is functionallyclassified into the signaling message processing part and the signaling network managementpart.l Signaling message processing part

The signaling message processing part sends signaling messages from the user part of asignaling point to the target signaling links or user parts. The user part in the BSS refers tothe 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.




Issue 01 (2008-06-10)

Figure 1-2 L3 signaling message processing procedure

MTP user part

Messagedistribution

Messagediscrimination Message routing

Messages to the localsignaling point

Messages to the othersignaling points

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), theMRT selects a signaling link that transmits the signaling messages to a destinationsignaling point.

– Message Discrimination (MDC)The MDC part receives the messages from L2 to ascertain whether the destination ofthe 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 signalingnetwork management part, and the test & maintenance part.

l Signaling network management partThe signaling network management part reconstructs the signaling network, and keeps andrecovers the normal transmission of signaling units when the signaling network fails. Itconsists of three smaller parts: signaling traffic management (STM), signaling linkmanagement (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 multipleavailable links or routes when the signaling network fails. It also temporarily reducessignaling 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 signalingnetwork. It ensures the provisioning of certain pre-determined link groups. The



1-5

connections between signaling data links and signaling terminals are normallyestablished through man-machine commands. The operations in the signaling systemcannot automatically change the previous connection relations. The SLM compriseslink test, link prohibition and unprohibition, link switchover and switchback, as well aslink activation and deactivation.

– Signaling Route Management (SRM)The SRM ensures reliable exchange of signaling route availability information betweensignaling points so that signaling routes can be blocked or unblocked. It comprisesprohibited transfer, allowed transfer, controlled transfer, and restricted transfer, as wellas signaling route group test and signaling route group congestion test.


The network layer services provided by the SCCP are classified into connectionless service andconnection-oriented service.

l The connectionless service indicates that an MS does not establish a signaling or connectionin advance, but uses the routing function of the SCCP and of the MTP to directly transmitdata in the signaling network. The connectionless service is applicable to the transmissionof a small quantity of data.

l The connection-oriented service indicates that an MS establishes a signaling connection inadvance and directly transfers data on the signaling connection, instead of using the routeselection function of the SCCP. The connection-oriented service is applicable to thetransmission of a large quantity of data, and effectively shortens the delay of batch datatransmission.

The SCCP also performs routing and network management functions.

l The SCCP performs addressing based on the address information such as the destinationsingling point code (DPC), subsystem number (SSN), and global title (GT). The DPC isthe destination signaling point code used by the MTP. The SSN is the subsystem numberthat are used to identify different SCCP users, such as the ISUP users, MAP users, TCAPusers, and BSSAP users in the same node. It helps to compensate the insufficiency of MTPusers and to enlarge the addressing scope. The BSS does not use the GT addressing mode,which is not described here.

l The SCCP performs signaling point state and subsystem state management, active/standbysubsystem switchover, status information broadcast, and subsystem state test. The SCCPmanagement (SCMG) maintains the network functions by reselecting a route or adjustingthe traffic volume in case of network failure or congestion.

The SCCP protocols are defined in ITU-T Q.711–Q.716 recommendations.


Overview of the BSSAP Protocol

The BSSAP protocol describes two types of messages.




Issue 01 (2008-06-10)

l BSSMAP messages: these messages are in charge of service flow control, they should beprocessed by corresponding internal functional modules on the A interface.

l DTAP messages: for these messages, the A interface is merely equivalent to a transportchannel. On the BSS side, DTAP messages are directly transmitted to radio channels. Onthe 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 Messagesl DTAP messages

Based on the functional units of DTAP messages processed on the NSS side, the DTAPmessages 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, andDTMF startup.

l BSSMAP messagesThe BSSMAP messages are classified into connectionless messages and connection-oriented messages.– Connectionless messages

– The connectionless messages include block, unblock, handover, resource, reset, andpaging messages.

– The block and unblock messages consist of block, block acknowledge, unblock, andunblock acknowledge messages.

– The group block and unblock messages consist of group block, group blockacknowledge, group unblock, and group unblock acknowledge messages.

– The handover messages include handover candidate request messages and handovercandidate response messages.

– The resource messages include resource request messages and resource indicationmessages.

– The reset messages include reset and reset acknowledge messages.

– Connection-oriented 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 Failuremessages.

– The clear messages include the Clear Request, Clear Command, and Clear Completemessages.

– The ciphering messages include the Cipher Mode Command and the Cipher ModeComplete messages.



1-7

BSSAP Protocol Functionality

The BSSAP protocol functions in connection-oriented mode or connectionless mode. When anMS needs to exchange service-related messages with the NSS on radio channels and there is noMS-related SCCP connection between the BSS and the MSC, a new connection must beestablished.

l When an MS sends an Access Request message on the RACH, the BSS assigns a dedicatedchannel (DCCH or TCH) to the MS. After an L2 connection is established, the BSS startsa connection establishment.

l When the MSC decides to perform an external handover (the target BSS might be theserving BSS), it must reserve a new DCCH or TCH from the target BSS. Then the MSCstarts a connection establishment.

Table 1-1 lists the functions implemented by the BSSAP protocol.

Table 1-1 BSSAP protocol functionality

Function Description

Assignment Assignment ensures that dedicated radio resources areproperly allocated or re-allocated to an MS. The BSSautomatically processes the random access andimmediate assignment of an MS, without the controlof the MSC.

Block / Unblock Circuit If the BSS considers that some terrestrial circuitsbecome unavailable or available, it notifies the MSCby initiating a Block/Unblock procedure.

Resource Indication Resource indication serves to notify the MSC of thefollowing:l Number of radio resources that can be used as TCHs

in the BSSl Number of available and allocated radio resources

l The MSC does not easily obtain the previousinformation directly from the MSC-controlledservices. The MSC must take the information intoconsideration when the it decides to perform anexternal handover.

Reset The purpose of reset is to initialize the faulty BSS orthe MSC.l If the BSS is faulty and loses all the reference

messages about processing, it sends a Resetmessage to the MSC. Upon receiving the Resetmessage, the MSC releases the affected calls,deletes the affected reference messages, and sets allthe circuits related to the BSS to idle.

l If the MSC or BSS is only partially faulty, theaffected parts can be cleared through the Clearprocedure.




Issue 01 (2008-06-10)


Handover Required The BSS may send the MSC a Handover Requiredmessage, requesting the MSC to hand over an MS thatare allocated with dedicated resources. The handoverreasons are as follows:l The BSS detects a radio cause for a handover.

l The MSC starts a handover candidate enquiryprocedure, and the MS is waiting for a handover.

l Due to congestion, the serving cell must be changedduring call establishment, for example, directedretry.

The Handover Required message is resent at a certaininterval till one of the following situations occurs:l A Handover Command message is received from

the MSC.l A Reset message is received.

l All the communications with MSs are disrupted andthe processing is stopped.

l The processing is complete, for example, the call iscleared.

Handover Resource Allocation Through handover resource allocation, the MSCrequests resources from the target BSS based on thehandover request, and the target BSS reservesresources and waits for an MS to access the reservedresources (channel).

Handover Procedure Handover procedure is a procedure in which the MSCinstructs an MS to access the radio resources in a targetcell. When handover is performed, the originaldedicated radio resources and terrestrial resources aremaintained until the MSC sends a Clear Commandmessage or until the resources are reset.

Radio and Terresterial ResourceRelease

l If the MSC needs to release resources, it sends theBSS a Clear Command message, requesting theBSS to release radio resources. Upon receiving theClear Command message, the BSS starts a clearprocedure on the Um interface, sets the configuredterrestrial circuits to idle, and responds the MSCwith a Clear Complete message. Upon receiving theClear Complete message, the MSC releases theterrestrial resources.

l If the BSS needs to release resources, it sends theMSC a Clear Request message. Then the MSCinitiates a release procedure to release the specificterrestrial and radio resources.



1-9


Paging The paging to an MS is transmitted through the SCCPconnectionless service over the BSSMAP. When theBSS receives a Paging Response message on the Uminterface, it establishes an SCCP connection to theMSC. The paging response message, which is carriedin the Complete L3 Information, is transmitted to theMSC through this SCCP connection.

Flow Control Flow control ensures stable working state of an entityby preventing the entity from receiving too muchtraffic. Flow control on the A interface is performedthrough traffic control at the traffic source. Itcomprises five levels which are performed based onsubscriber classes.

Classmark Update Classmark update serves to notify a receiving entity ofthe classmark messages. Generally, the BSS notifiesthe MSC upon receiving the classmark messages froman MS. When a handover is complete, the MSC sendsthe new BSS the classmark messages from the relevantMS on the A interface.

Cipher Mode Control The cipher mode control procedure allows the MSC tosend the Cipher Mode Control message to the BSS andto start the subscriber equipment and the signalingcipher equipment using a correct ciphering key (Kc).

Queue Indication The queue indication procedure serves to notify theMSC that the BSS will delay the allocation of someradio resources. The procedure takes effect only whenthe queuing function is used for traffic channelassignment and traffic channel handover in the BSS.

Load Indication Load indication serves to notify all neighbor BSSs ofthe traffic state of a cell so that the handover servicesin an MSC can be controlled as a whole. In a certainperiod, the neighbor BSSs take the traffic states ofneighbor cells into account during a handover.

1.2 A Interface (IP)The A interface, which is a standard interface, is a communication interface between the NSSand 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, IPlayer, 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 complywith at the physical layer when the IP transmission mode is used on the A interface.




Issue 01 (2008-06-10)

1.2.3 IP Layer on the A InterfaceThis describes the IP layer on the A interface. This layer supports IPv4 and is responsible foraddressing, routing, fragmentation, and reassembly. For related standards, refer to ITEFRFC791.

1.2.4 SCTP/M3UA Layer on the A InterfaceThis describes the SCTP/M3UA layer on the A interface. This layer implements the interworkingbetween SS7 and IP. In addition, the layer carries the MTP3 user information and transmitssignaling through the IP network.



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, IPlayer, 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 Ainterface, the A interface signaling protocol reference model is applied, as shown in Figure1-3.

Figure 1-3 Protocol Stack on the A Interface (IP)

DT AP BSSM AP

Allocation function

SCCP

M3UA

IP

Physical layer

BSSAP

DT AP BSSM AP

Allocation function

SCCP

M3UA

IP

BSSAP

SCTP SCTP

DTAP: Direct Transfer ApplicationPart

BSSAP: Base Station SubsystemApplication Part

BSSMAP: Base Station SubsystemManagement Application Part

SCCP: Signaling ConnectionControl Part

M3UA: MTP3 User Adaptationlayer

SCTP: Stream Control TransmissionProtocol



1-11

IP: Internet Protocol Physical layer: Ethernettransmission part

When the IP transmission mode is used on the A interface, signaling on the A interface istransmitted through the SIGTRAN system. The transmitted information includes MSmanagement, 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 complywith 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.l GE electrical interface: complies with the 1000BASE-T specification.

l GE optical port: complies with the 1000BASE-LX and 1000BASE-SX specification.

The transmission rates for the three types of interfaces are as follows:l FE electrical interface: 10 Mbit/s or 100 Mbit/s

l GE electrical interface: 10 Mbit/s, 100 Mbit/s, or 1000 Mbit/s

l 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 electricalport should be determined with full consideration to other network equipment.

l An optical interface supports only the full-duplex mode and can work only at the rate of1000 Mbit/s. In addition, an optical interface does not support the automatic negotiationfunction.

The specifications to comply with at the physical layer are as follows:l RJ45 standard that an electrical interface complies with

l SFP standard that an optical interface complies with

l 802.3 protocol that the MAC layer supports

1.2.3 IP Layer on the A InterfaceThis describes the IP layer on the A interface. This layer supports IPv4 and is responsible foraddressing, routing, fragmentation, and reassembly. For related standards, refer to ITEFRFC791.

IP AddressAn IP address is a logical IP address that is allocated to uniquely identify an internet host. Eachport on the A interface board is assigned an IP address.

IP RoutingWhen network equipment supporting IP forwarding receives an IP packet, the networkequipment checks whether the destination address is the IP address of the local equipment,




Issue 01 (2008-06-10)

multicast address, or broadcast address. If the destination address is the IP address of the localequipment, multicast address, or broadcast address, the network equipment submits the IP packetto a corresponding program for handling. Otherwise, the network equipment forwards the IPpacket.

Fragmentation and Reassembly Related Concepts

The process of fragmentation and reassembly is related to the MTU, Identification, Flags, andFragment Offset.

l MTU

MTU refers to the maximum length of a data frame that can be transmitted on a link. Whendata at the IP layer needs to be transmitted, packets must be fragmented at the IP layer andreassembled on the receiving end if the length of a data frame, which is yielded by IP headerplus IP data part, is greater than the MTU at the data link layer.

l Identification

There is a 16-bit identification filed in the IP header. This filed uniquely identifies eachpacket sent by a host. When a packet is fragmented into pieces, the identification field iscopied into all fragments on fragmentation. When a packet is reassembled, the identificationfield is used to distinguish the fragments of one datagram from those of another.

l Flags

The flags field is behind the identification field and has 3 bits. The purposes of each bit areas follows:

– Bit 0: reserved, must be zero.

– Bit 1: (DF) 0 = May Fragment, 1 = Don't Fragment. When the DF field is 1, packets arediscarded if these packets need to be fragmented.

– Bit 2: (MF) 0 = Last Fragment, 1 = More Fragments.

l Fragment Offset

The Fragment Offset field is behind the flags field and has 13 bits. This field identifies thefragment location, relative to the beginning of the original unfragmented datagram.Irrespective of how many times datagrams are fragmented, the fragment offset fields of allfragments tell the receiver the positions of fragments in the original datagrams. These fieldsprovide 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 isfragmented.

– Fragment Offset of the first fragment must be zero.

– Fragment Offset is measured in units of 8 octets (64 bits). Except the last fragment, thedata portions of other fragments must be an integral multiple of 8 octets. This is becausethat 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 protocoldirectly sends the datagram to the next hop.



1-13

l If the length of a datagram is greater than MTU and moreover the datagram cannot befragemented, the internet protocol discards the datagram and then displays the ICMP errorcontrol datagram.

l If the length of a datagram is greater than MIU and moreover the datagram can befragmented, the internet protocol fragments the datagram.

The procedure for fragmenting a datagram at the IP layer is as follows:

1. If the length of a datagram is greater than MTU and moreover the datagram can befragmented, 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 secondfragment is the rest of the datagram.

2. The internet protocol sends the first fragment to the next hop.3. If the second fragment is still greater than MTU, continute to cut the datagram until all

fragments are less than MTU.

When MTU is used as the basic length to fragment a datagram, the fragmentation efficiency ishighest. 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. Otherfragments have only common IP datagrams and do not contain information at the transport layer.

ReassemblyWhen one fragment of a datagram arrives, the receiver does not a datagram that has the samedatagram identification previously. Then, the reassembly procedure is initiated. The procedurefor fragmenting a datagram at the IP layer is as follows:

1. When the first fragment of a datagram is received (Fragment Offset is zero), the data fromthe fragment is placed in the data buffer that is dedicated to the first fragment.

2. When other fragments except the first fragment and the last fragment are received, the datafrom these fragments is placed in the public data buffer.

3. If the last fragment (that is the more fragments field is zero) is received, the total data lengthis computed (Fragment Offest x 8 + data length of the last fragment).

4. A data buffer is assigned to the datagram, the datagram is reassembled, and the timer isstarted.

5. The timer is refreshed every time a fragment is received. The received fragments are paddedto the data buffer according to attached offset.

6. The last fragment is used if some received fragments are identical.7. If the timer runs out during datagram reassembly, datagram ressembly is over and all the

received fragments are discarded.8. Datagram ressembly is over when all the fragments are received.

1.2.4 SCTP/M3UA Layer on the A InterfaceThis describes the SCTP/M3UA layer on the A interface. This layer implements the interworkingbetween SS7 and IP. In addition, the layer carries the MTP3 user information and transmitssignaling through the IP network.




Issue 01 (2008-06-10)

SCTPThe Stream Control Transmission Protocol (SCTP) is a reliable transmission protocol based ona connectionless network such as the IP network. The SCTP can transmit signaling on the PSTNor other networks through the IP network.

SCTP has the following functions:l Point-to-point transmission

l Sequenced stream transmission

l Disassembling and reassembling of user data

l Binding of data packets

l Path management

l Verification of message packets

M3UAThe MTP3 User Adaptation Layer (M3UA) implements the interworking between SS7 and IPand carries the MTP3 user information through the IP network. M3UA is a subprotocol of theSIGTRAN protocol stack and provides services based on SCTP.

M3UA has the following functions:l Supporting the transmission of all MTP3 user information, such as SUP, TUP, or SCCP

l Supporting the seamless interaction between the same type of MTP3s that are located indifferent network areas, such as the interaction between the ISUP of the SCN and the ISUPof the IP network

l Supporting the SCTP connection and service management between SG and MGC, orbetween SG and database within the IP network, or between SG and IPSP. SCTP connectionimplements redundancy protection in active/standby mode or load balancing mode.

l Supporting the interworking with the MTP3 network management function

l Supporting the address interpretation mapping between SS7 and IP

l Supporting redundancy management

l Supporting SCTP flow mapping

l Supporting congestion control

l Supporting seamless network management interaction


The network layer services provided by the SCCP are classified into connectionless service andconnection-oriented service.

l The connectionless service indicates that an MS does not establish a signaling or connectionin advance, but uses the routing function of the SCCP and of the MTP to directly transmitdata in the signaling network. The connectionless service is applicable to the transmissionof a small quantity of data.

l The connection-oriented service indicates that an MS establishes a signaling connection inadvance and directly transfers data on the signaling connection, instead of using the route



1-15

selection function of the SCCP. The connection-oriented service is applicable to thetransmission of a large quantity of data, and effectively shortens the delay of batch datatransmission.

The SCCP also performs routing and network management functions.

l The SCCP performs addressing based on the address information such as the destinationsingling point code (DPC), subsystem number (SSN), and global title (GT). The DPC isthe destination signaling point code used by the MTP. The SSN is the subsystem numberthat are used to identify different SCCP users, such as the ISUP users, MAP users, TCAPusers, and BSSAP users in the same node. It helps to compensate the insufficiency of MTPusers and to enlarge the addressing scope. The BSS does not use the GT addressing mode,which is not described here.

l The SCCP performs signaling point state and subsystem state management, active/standbysubsystem switchover, status information broadcast, and subsystem state test. The SCCPmanagement (SCMG) maintains the network functions by reselecting a route or adjustingthe traffic volume in case of network failure or congestion.

The SCCP protocols are defined in ITU-T Q.711–Q.716 recommendations.


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 beprocessed by corresponding internal functional modules on the A interface.

l DTAP messages: for these messages, the A interface is merely equivalent to a transportchannel. On the BSS side, DTAP messages are directly transmitted to radio channels. Onthe 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 Messagesl DTAP messages

Based on the functional units of DTAP messages processed on the NSS side, the DTAPmessages 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, andDTMF startup.

l BSSMAP messagesThe BSSMAP messages are classified into connectionless messages and connection-oriented messages.




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.

– Connection-oriented 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 Failuremessages.

– The clear messages include the Clear Request, Clear Command, and Clear Completemessages.

– The ciphering messages include the Cipher Mode Command and the Cipher ModeComplete messages.

BSSAP Protocol FunctionalityThe BSSAP protocol functions in connection-oriented mode or connectionless mode. When anMS needs to exchange service-related messages with the NSS on radio channels and there is noMS-related SCCP connection between the BSS and the MSC, a new connection must beestablished.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 startsa connection establishment.

l When the MSC decides to perform an external handover (the target BSS might be theserving BSS), it must reserve a new DCCH or TCH from the target BSS. Then the MSCstarts a connection establishment.

Table 1-2 lists the functions implemented by the BSSAP protocol.

Table 1-2 BSSAP protocol functionality


Assignment Assignment ensures that dedicated radio resources areproperly allocated or re-allocated to an MS. The BSSautomatically processes the random access andimmediate assignment of an MS, without the controlof the MSC.



1-17


Block / Unblock Circuit If the BSS considers that some terrestrial circuitsbecome unavailable or available, it notifies the MSCby initiating a Block/Unblock procedure.

Resource Indication Resource indication serves to notify the MSC of thefollowing:l Number of radio resources that can be used as TCHs

in the BSSl Number of available and allocated radio resources

l The MSC does not easily obtain the previousinformation directly from the MSC-controlledservices. The MSC must take the information intoconsideration when the it decides to perform anexternal handover.

Reset The purpose of reset is to initialize the faulty BSS orthe MSC.l If the BSS is faulty and loses all the reference

messages about processing, it sends a Resetmessage to the MSC. Upon receiving the Resetmessage, the MSC releases the affected calls,deletes the affected reference messages, and sets allthe circuits related to the BSS to idle.

l If the MSC or BSS is only partially faulty, theaffected parts can be cleared through the Clearprocedure.

Handover Required The BSS may send the MSC a Handover Requiredmessage, requesting the MSC to hand over an MS thatare allocated with dedicated resources. The handoverreasons are as follows:l The BSS detects a radio cause for a handover.

l The MSC starts a handover candidate enquiryprocedure, and the MS is waiting for a handover.

l Due to congestion, the serving cell must be changedduring call establishment, for example, directedretry.

The Handover Required message is resent at a certaininterval till one of the following situations occurs:l A Handover Command message is received from

the MSC.l A Reset message is received.

l All the communications with MSs are disrupted andthe processing is stopped.

l The processing is complete, for example, the call iscleared.




Issue 01 (2008-06-10)


Handover Resource Allocation Through handover resource allocation, the MSCrequests resources from the target BSS based on thehandover request, and the target BSS reservesresources and waits for an MS to access the reservedresources (channel).

Handover Procedure Handover procedure is a procedure in which the MSCinstructs an MS to access the radio resources in a targetcell. When handover is performed, the originaldedicated radio resources and terrestrial resources aremaintained until the MSC sends a Clear Commandmessage or until the resources are reset.

Radio and Terresterial ResourceRelease

l If the MSC needs to release resources, it sends theBSS a Clear Command message, requesting theBSS to release radio resources. Upon receiving theClear Command message, the BSS starts a clearprocedure on the Um interface, sets the configuredterrestrial circuits to idle, and responds the MSCwith a Clear Complete message. Upon receiving theClear Complete message, the MSC releases theterrestrial resources.

l If the BSS needs to release resources, it sends theMSC a Clear Request message. Then the MSCinitiates a release procedure to release the specificterrestrial and radio resources.

Paging The paging to an MS is transmitted through the SCCPconnectionless service over the BSSMAP. When theBSS receives a Paging Response message on the Uminterface, it establishes an SCCP connection to theMSC. The paging response message, which is carriedin the Complete L3 Information, is transmitted to theMSC through this SCCP connection.

Flow Control Flow control ensures stable working state of an entityby preventing the entity from receiving too muchtraffic. Flow control on the A interface is performedthrough traffic control at the traffic source. Itcomprises five levels which are performed based onsubscriber classes.

Classmark Update Classmark update serves to notify a receiving entity ofthe classmark messages. Generally, the BSS notifiesthe MSC upon receiving the classmark messages froman MS. When a handover is complete, the MSC sendsthe new BSS the classmark messages from the relevantMS on the A interface.



1-19


Cipher Mode Control The cipher mode control procedure allows the MSC tosend the Cipher Mode Control message to the BSS andto start the subscriber equipment and the signalingcipher equipment using a correct ciphering key (Kc).

Queue Indication The queue indication procedure serves to notify theMSC that the BSS will delay the allocation of someradio resources. The procedure takes effect only whenthe queuing function is used for traffic channelassignment and traffic channel handover in the BSS.

Load Indication Load indication serves to notify all neighbor BSSs ofthe traffic state of a cell so that the handover servicesin an MSC can be controlled as a whole. In a certainperiod, the neighbor BSSs take the traffic states ofneighbor cells into account during a handover.

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

1.3.2 Abis Interface StructureThe 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 TDMtransmission mode is used, including the interface type, transmission rate, and specifications tocomply with.

1.3.4 LAPD Layer on the Abis InterfaceThe data link layer (L2) on the Abis interface uses the LAPD protocol. It receives data from thephysical layer (L1) and provides connection-oriented or connectionless services for L3.

1.3.5 Layer 3 Traffic Management Messages on the Abis InterfaceL3 traffic management messages on the Abis interface enables the MS to exchange informationwith the BSS or NSS on the Um interface and to perform some radio resource managementfunctions under the control of the BSC.

1.3.6 Layer 3 OM Messages on the Abis InterfaceThis 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 layer3.

Figure 1-4 shows the protocol stack on the Abis interface.




Issue 01 (2008-06-10)

Figure 1-4 Protocol stack on the Abis interface

Abis interface

BTS BSC

Layer1

LAPD

BTSM

RR

Layer1

LAPD

BTSM

BTSM: BTS Management LAPD: Link Access Protocol on the D Channel

RR: Radio Resource Management

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.l 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 EquipmentIdentifier (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.

l RR messages are mapped onto the BSSAP by the BSC. Most RR messages are transparentlytransmitted by the BTS, except for some messages that must be interpreted and executed.For example, ciphering, random access, paging, and assignment messages are processedby the BTS Management (BTSM) entities in the BSC and in the BTS.

l Neither the BSC nor the BTS interprets Connection Management (CM) messages orMobility Management (MM) messages. These messages are transmitted on the A interfaceby the Direct Transfer Application Part (DTAP). On the Abis interface, DTAP messagesare transmitted as transparent messages.

1.3.2 Abis Interface StructureThe Abis interface supports three types of internal BTS configurations.

Figure 1-5 shows the Abis interface structure. The three types of BTS configurations on theAbis interface are as follows:l A single TRX

l Multiple TRXs connected to the BSC through one physical link

l Multiple TRXs connected to the BSC through different physical links



1-21

Figure 1-5 Abis interface structure

Abis

BTS3

BTS2

BTS1

A

Abis

MSC BSC

TRX

BCF

TRX

BCF

Abis

BSS

TRX

TRX

TRX

TRX

TRX

TRX

BCF

l Transceiver (TRX) is a functional entity defined in the GSM that supports eight physicalchannels of one TDMA frame.

l The Base Control Function (BCF) is a functional entity that performs common controlfunctions, including BTS initialization, software loading, channel configuration, andoperation and maintenance.

The following two types of channels are on the Abis interface:l Traffic channels of 8 kbit/s, 16 kbit/s, and 64 kbit/s, which carry speech or data from radio

channelsl 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

A terminal equipment identifier (TEI) is assigned to obtain the unique address of a TRX. EachBCF has a unique TEI. Three different logical links are defined with a TEI, as shown in Figure1-6.l RSL: used to support traffic management procedures, one for each TRX

l OML: used to support network management procedures, one for each BCF

l L2ML: used to transmit L2 management messages




Issue 01 (2008-06-10)

Figure 1-6 Logical links on the Abis interface

BSC BTS

LAYER 2

TEI

MANA GEMENT

RSL SAPI=0

OML SAPI=62

L2ML SAPI=63TEI1

TRX

BCF

RSL SAPI=0

OML SAPI=62

L2ML SAPI=63

RSL SAPI=0

OML SAPI=62

L2ML SAPI=63

TRX

BCF

TEI2

TRX

BCF

TEI3

OML SAPI=62L2ML SAPI=63 BCF TEI4

BCF

1.3.3 Physical Layer on the Abis Interface (TDM)This describes the characteristics of the physical layer on the Abis interface when TDMtransmission mode is used, including the interface type, transmission rate, and specifications tocomply with.

In TDM transmission mode, E1/T1 electrical interface and STM-1 optical interface aresupported. The transmission rates are as follows:



l STM-1 transmission rate: 155.52 Mbit/s

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



l STM-1 complies with the G.707, G.957, G.783, and G.825.

l The frame structure, synchronization, and timing comply with the G.705.

l The fault management complies with the G.732.





1-23

OverviewThe Service Access Point (SAP) of L2 is the connection point for providing services for L3. AnSAP 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 linkconnection endpoint identifier.

l From the perspective of L2, a data link connection endpoint is identified by a Data LinkConnection Identifier (DLCI).

For the information exchange between two or more L3 entities, data links must be establishedbetween L3 entities.

The co-operation between L2 entities is controlled by the protocol of the peer layer. The messageunits at L2 are transmitted between L2 entities through L1. Inter-layer service requests areprocessed through service primitives.

FunctionThe LAPD reliably transfers end-to-end information between L3 entities through the D channel.Specifically, the LAPD supports:

l Multiple terminal devices between MSs and physical ports

l Multiple L3 entities

The functions of the LAPD layer on the Abis interface are as follows:

l Providing one or multiple data links on the D channel

l Delimiting, locating, and transparently transmitting frames so that a string of bitstransmitted in the form of frames on the D channel can be identified

l Controlling and keeping the sequence of frames

l Checking for transmission errors, format errors, and operation errors on data linkconnections

l Making recoveries based on the detected transmission errors, format errors, and operationerrors

l Notifying the management layer entities of unrecoverable errors

l Performing flow control

The LAPD layer on the Abis interface provides the means for information transfer betweenmultiple combinations of data link connection points. The information may be transferredthrough point-to-point data link connections or broadcast data link connections.


In terms of processing, traffic management messages are classified into transparent and non-transparent messages.

l The transparent messages refer to the messages directly forwarded without interpretationor processing by the BTS.




Issue 01 (2008-06-10)

l The non-transparent messages refer to the messages that are transmitted between the BSCand the BTS and that must be processed and structured by the BTS.

In terms of functions, traffic management messages are classified into the following:l Radio link layer management messages that are used to manage the data link layer on radio

channelsl Dedicated channel management messages that are used to manage dedicated channels such

as the SDCCH and TCHl Common control channel management messages that are used to manage common control

channelsl TRX management messages that are used to manage TRXs

NOTE

The transparency and group of traffic management messages are determined by the message discriminatorat the header of the messages.

Radio link management proceduresRadio link management procedures consist of the following:

l Link establishment indication procedure: used by the BTS to notify the BSC that an MS-originated multi-frame-mode link establishment is successful. Upon receiving theindication from the BTS, the BSC establishes an SCCP link to the MSC.

l Link establishment request procedure: used by the BSC to request the establishment of amulti-frame link on a radio channel.

l Link release indication procedure: used by the BTS to notify the BSC that an MS-initiatedradio link release is complete.

l Link release request procedure: used by the BSC to request the release of a radio link.

l Transmission of transparent L3 messages on the Um interface in acknowledged mode: usedby the BSC to request the transmission of a transparent Radio Interface Layer 3 (L3)message in acknowledged mode.

l Reception of transparent L3 messages on the Um interface in acknowledged mode: usedby the BTS to notify the BSC that a transparent L3 message is received on the Um interfacein acknowledged mode.

l 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 interfacein unacknowledged mode.

l 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 Uminterface in unacknowledged mode.

l Link error indication procedure: used by the BTS to notify the BSC in case of errors at theradio link layer.

Dedicated Channel Management ProceduresThe dedicated channel management procedures consist of the following:

l Channel activation procedure: used by the BSC to request the BTS to activate a dedicatedchannel for an MS. Then the BSC assigns the activated channel to the MS through anImmediate Assignment, Assignment Command, Additional Assignment, or HandoverCommand message.



1-25

l Channel mode modification procedure: used by the BSC to request the BTS to change themode of an activated channel.

l Handover detection procedure: used on the Abis interface between the target BTS and thetarget BSC to detect the access of an MS being handed over.

l Ciphering mode command procedure: used to start the ciphering procedure defined in GSMRec. 04.08.

l Measurement report procedure: consists of the mandatory basic measurement reportprocedure and optional measurement report preprocessing procedure. The BTS reports allthe parameters related to handover decisions to the BSC through this procedure.

l SACCH deactivation procedure: used by the BSC to deactivate the SACCH related to aTRX according to the channel release procedure defined in GSM Rec. 04.08.

l Radio channel release procedure: used by the BSC to release a radio channel that is nolonger needed.

l MS power control procedure: used by the BSS to control the transmit power of an MS forwhich a channel is already activated. The power control decision must be performed in theBSC. It can also be performed in the BTS.

l BTS transmit power control procedure: used by the BSS to control the transmit power ofa TRX with an activated channel. The BTS transmit power control decision must beperformed in the BSC. It can also be performed in the BTS.

l Connection failure procedure: used by the BTS to notify the BSC that an activated dedicatedchannel is unavailable.

l Physical context request procedure: used by the BSC to obtain the information about thephysical context of a radio channel prior to a channel change. It is an optional procedure.

l SACCH information modification procedure: used by the BSC to request the BTS to changethe 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 Requestmessage from an MS.

l Paging procedure: used to page an MS on a specific paging sub-channel. This procedureis used in the mobile terminated call. It is initiated by the MSC through the BSC. Based onthe IMSI of the called MS, the BSC determines the paging group to be used. Then it sendsthe BTS the paging group number together with the identity of the MS.

l Immediate assignment procedure: used by the BSC to immediately assign a dedicatedchannel to an MS when the MS accesses the BTS.

l Delete indication procedure: used by the BTS to notify the BSC that an Immediate AssignCommand message is deleted due to AGCH overload.

l CCCH load indication procedure: used by the BTS to notify the BSC of the load on aspecified CCCH if the load exceeds the preset threshold on the OMC. The indication periodis also set on the OMC.

l Broadcast information modification procedure: used by the BSC to notify the BTS of thenew system information to be broadcast on the BCCH.

l Short message service cell broadcast procedure: used by the BSC to request short messageservice cell broadcast messages from the BTS.




Issue 01 (2008-06-10)

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 thenew system information to be used as filling information on all downlink SACCHs.

l Radio resource indication procedure: used by the BTS to notify the BSC of the interferencelevels on the idle channels of a TRX.

l Flow control procedure: used by the Frame Unit Controller (FUC) in a TRX to notify theBSC of the TRX overload due to CCCH overload, ACCH overload, or TRX processoroverload.

l Error reporting procedure: used by the BTS to notify the BSC of the detected downlinkmessage errors, which cannot be reported through any other procedure.


OM Information ModelThe OM information model consists of the following:l Management objects

The management objects are site, cell, carrier (TRX), and channel. Figure 1-7 shows themanagement objects.

Figure 1-7 Management objects

SITE

CELL 0 CELL 1 CELL n

TRX0 TRX1 TRXm

BTS TRX

Channel 0

Channel 1

Chanel7

…

…

…

l Addressing of management objectsNetwork management messages are addressed through the classes and instances of themanagement objects. Each object instance in the BTS has a complete L2 connectiondescription. The first established connection is assigned a semi-permanent or permanentdefault TEI. The subsequent connections are assigned the TEIs provided during theestablishment of TEI procedures. Object instances can also use L3 addresses. The mixeduse of L2 addressing and L3 addressing enables one site to have one or multiple physicallinks.



1-27

l Management object state

A management object can be in three states, the administrative state, operational state, andavailability state. For details, see Table 1-3, Table 1-4, and Table 1-5. The available statefurther describes the operational state, and only the BSC controls the administrative state.

Table 1-3 Administrative State

Status Description

Locked The BSC has disconnected all the calls passing thismanagement object, and no new services can beconnected to this object.

Shut Down No new services can be connected to this managementobject, and ongoing calls are maintained.

Unlocked New services can be connected to this managementobject.

Table 1-4 Operational State

Status Description

Disabled Resources are totally inoperable and can no longerprovide services for MSs.

Enabled Resources are partially or fully operable.

Table 1-5 Available State

Status Description

In Test The resource is undergoing a test procedure. Theoperational state is disabled.

Failed The resource has an internal fault that prevents it fromoperating. The operational state is disabled.

Power Off The resource requires power and is not powered on. Theoperational state is disabled.

Offline The resource requires automatic or manual operations tomake it available for use. The operational state isdisabled.

Dependency The resource cannot operate because some otherresources on which it depends are unavailable. Theoperational state is disabled.

Degraded The service is degraded due to some reasons such asspeed or capacity. The operational state is enabled.




Issue 01 (2008-06-10)

Status Description

Not Installed The hardware or software of the management object isnot installed. The operational state is disabled.

Basic ProceduresAll procedures are based on formatted OM messages. Most formatted OM messages initiatedby the BSC or the BTS require the peer L3 to respond with formatted OM messages. This pairof formatted OM messages or a formatted OM message that does not require a response is calleda basic procedure.

All formatted OM messages are sent on L2 in the form of I frames. A group of messages, alsocalled 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 certainbasic procedure is not complete, the system does not start the subsequent basic procedures. Whenthere is no response (ACK or NACK) in the previous basic procedure before L3 timeout, nosubsequent basic procedure is sent to this object instance. The default value for L3 timeout is10 seconds.

l If part of an original message is not understood or supported, the entire message isdiscarded.

l An ACK message from an object instance indicates an affirm response. It is used to notifythe sender that the command is executed or will be executed.

l An NACK message from an object instance indicates a disaffirm response. It is used tonotify the sender of the unsuccessful execution of the command and of the failure cause.

The basic procedures are classified into the following:

l Software loading management procedure

l Abis interface management procedure

l Transmission management procedure

l Um interface management procedure

l Test management procedure

l State management and event report procedure

l Equipment state management procedure

l 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 interfaceconsists of the physical layer, HDLC layer, LAPD layer, and layer 3.

1.4.2 Physical Layer on the Abis Interface (HDLC)



1-29

This describes the interface type, transmission rate, working mode, and specifications to complywith at the physical layer when the HDLC transmission mode is used on the Abis interface.

1.4.3 HDLC Layer on the Abis InterfaceThis describes the High-level Data Link Control (HDLC) layer on the Abis interface. The HDLCis a bit-oriented high-level data link control procedure. It provides the powerful error detectionfunction to ensure reliable data transmission.




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 interfaceconsists 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)

Abis interface

BTS BSC

Layer1

HDLC

LAPD

RSL/OML

Layer1

HDLC

LAPD

RSL/OML

HDLC: High Level Data Link Control LAPD: Link Access Procedure on the D Channel

OML: Operation and Maintenance Link 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 complywith 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 supportsthe E1/T1 electrical port at the following rates:



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




Issue 01 (2008-06-10)



l The frame structure, synchronization, and timing comply with the G.705.

l Fault management complies with the G.732.


1.4.3 HDLC Layer on the Abis InterfaceThis describes the High-level Data Link Control (HDLC) layer on the Abis interface. The HDLCis a bit-oriented high-level data link control procedure. It provides the powerful error detectionfunction to ensure reliable data transmission.

The HDLC protocol, which is a kind of protocol at the data link layer, ensures that the next-layerdata can be exactly received.

The HDLC protocl has the following features:l Data messages can be transmitted transparently.

l Full-duplex communication is used.

l The window mechanism and piggyback acknowledgment are used.

l The frame check sequence is used and information frames are numbered to prevent theincomplete receiving of data or the resending of data. Therefore, transmission is reliable.

l The transmission control function and the transmission processing function are independentand can be flexibly used.

HDLC is responsible for controlling data transmission and generally has three phases:l Phase of establishing data links

l Phase of transferring information frames

l Phase of releasing data links


OverviewThe Service Access Point (SAP) of L2 is the connection point for providing services for L3. AnSAP is identified by a Service Access Point Identifier (SAPI).







1-31

Function

The LAPD reliably transfers end-to-end information between L3 entities through the D channel.Specifically, the LAPD supports:
















In terms of functions, traffic management messages are classified into the following:l Radio link layer management messages that are used to manage the data link layer on radio

channelsl Dedicated channel management messages that are used to manage dedicated channels such

as the SDCCH and TCHl Common control channel management messages that are used to manage common control

channelsl TRX management messages that are used to manage TRXs

NOTE





Issue 01 (2008-06-10)

Radio link management procedures

Radio link management procedures consist of the following:










Dedicated Channel Management Procedures

The dedicated channel management procedures consist of the following:










1-33
























Issue 01 (2008-06-10)


OM Information ModelThe OM information model consists of the following:

l Management objects



SITE


TRX0 TRX1 TRXm

BTS TRX

Channel 0

Channel 1

Chanel7

…

…

…

l Addressing of management objects

Network management messages are addressed through the classes and instances of themanagement objects. Each object instance in the BTS has a complete L2 connectiondescription. The first established connection is assigned a semi-permanent or permanentdefault TEI. The subsequent connections are assigned the TEIs provided during theestablishment of TEI procedures. Object instances can also use L3 addresses. The mixeduse of L2 addressing and L3 addressing enables one site to have one or multiple physicallinks.

l Management object state

A management object can be in three states, the administrative state, operational state, andavailability state. For details, see Table 1-6, Table 1-7, and Table 1-8. The available statefurther describes the operational state, and only the BSC controls the administrative state.


Status Description




1-35

Status Description




Status Description




Status Description








Basic Procedures

All procedures are based on formatted OM messages. Most formatted OM messages initiatedby the BSC or the BTS require the peer L3 to respond with formatted OM messages. This pairof formatted OM messages or a formatted OM message that does not require a response is calleda basic procedure.




Issue 01 (2008-06-10)


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 certainbasic procedure is not complete, the system does not start the subsequent basic procedures. Whenthere is no response (ACK or NACK) in the previous basic procedure before L3 timeout, nosubsequent basic procedure is sent to this object instance. The default value for L3 timeout is10 seconds.












l Other procedures

1.5 Abis Interface (IP)This describes the Abis interface (IP). The Abis interface lies between the BTS and the BSC. Itis 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 Abisinterface 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 complywith at the physical layer when the IP transmission mode is used on the Abis interface.

1.5.3 UDP/IP Layer on the Abis InterfaceThis describes the UDP/IP layer on the Abis interface. The UDP/IP layer on the Abis interfaceis responsible for addressing, routing, fragmentation, reassembly, and data transmission.


1.5.5 Layer 3 Traffic Management Messages on the Abis Interface



1-37

L3 traffic management messages on the Abis interface enables the MS to exchange informationwith the BSS or NSS on the Um interface and to perform some radio resource managementfunctions under the control of the BSC.


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 Abisinterface 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)

Abis interface

BTS BSC

Layer1

UDP/IP

LAPD

RSL/OML

Layer1

UDP/IP

LAPD

RSL/OML

IP: Internet Protocol LAPD: Link Access Procedure on the D Channel

OML: Operation and Maintenance Link RSL: Radio Signaling Link

UDP: User Datagram Protocol

1.5.2 Physical Layer on the Abis Interface (IP)This describes the interface type, transmission rate, working mode, and specifications to complywith 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 thefollowing 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.l GE electrical interface: complies with the 1000BASE-T specification.

l GE optical port: complies with the 1000BASE-LX and 1000BASE-SX specifications.

The transmission rates for the three types of interfaces are as follows:l FE electrical interface: 10 Mbit/s or 100 Mbit/s

l GE electrical interface: 10 Mbit/s, 100 Mbit/s, or 1000 Mbit/s

l GE optical interface: 1000 Mbit/s

The working modes of an electrical interface and an optical interface are as follows:




Issue 01 (2008-06-10)

l An electrical interface supports the half-duplex and full-duplex modes and has theautomatic negotiation function. The working mode and transmission rate of an electricalport should be determined with full consideration to other network equipment.

l An optical interface supports only the full-duplex mode and can work only at the rate of1000 Mbit/s. In addition, an optical interface does not support the automatic negotiationfunction.

The specifications to comply with at the physical layer are as follows:l RJ45 standard that an electrical interface complies with

l SFP standard that an optical interface complies with

l 802.3 protocol that the MAC layer supports

1.5.3 UDP/IP Layer on the Abis InterfaceThis describes the UDP/IP layer on the Abis interface. The UDP/IP layer on the Abis interfaceis responsible for addressing, routing, fragmentation, reassembly, and data transmission.

IP AddressAn IP address is a logical IP address that is allocated to uniquely identify an internet host. Eachport on the A interface board is assigned an IP address.

IP RoutingWhen network equipment supporting IP forwarding receives an IP packet, the networkequipment 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 localequipment, multicast address, or broadcast address, the network equipment submits the IP packetto a corresponding program for handling. Otherwise, the network equipment forwards the IPpacket.

Fragmentation and Reassembly Related ConceptsThe process of fragmentation and reassembly is related to the MTU, Identification, Flags, andFragment Offset.l MTU

MTU refers to the maximum length of a data frame that can be transmitted on a link. Whendata at the IP layer needs to be transmitted, packets must be fragmented at the IP layer andreassembled on the receiving end if the length of a data frame, which is yielded by IP headerplus IP data part, is greater than the MTU at the data link layer.

l IdentificationThere is a 16-bit identification filed in the IP header. This filed uniquely identifies eachpacket sent by a host. When a datagram is cut into pieces, the identification field is copiedinto all fragments on fragmentation. When a packet is reassembled, the identification fieldis used to distinguish the fragments of one datagram from those of another.

l FlagsThe flags field is behind the identification field and has 3 bits. The purposes of each bit areas follows:– Bit 0: reserved, must be zero.



1-39

– Bit 1: (DF) 0 = May Fragment, 1 = Don't Fragment. When the DF field is 1, packets arediscarded if these packets need to be fragmented.

– Bit 2: (MF) 0 = Last Fragment, 1 = More Fragments.

l Fragment OffsetThe Fragment Offset field is behind the flags field and has 13 bits. This field identifies thefragment location, relative to the beginning of the original unfragmented datagram.Irrespective of how many times datagrams are fragmented, the fragment offset fields of allfragments tell the receiver the positions of fragments in the original datagrams. These fieldsprovide 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 datagramis 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, thedata portions of other fragments must be an integral multiple of 8 octets. This is becausethat 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.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 errorcontrol datagram.

l If the length of a datagram is greater than MIU and moreover the datagram can befragmented, the internet protocol fragments the datagram.

The procedure for fragmenting a datagram at the IP layer is as follows:

1. If the length of a datagram is greater than MTU and moreover the datagram can befragmented, 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 secondfragment is the rest of the datagram.

2. The internet protocol sends the first fragment to the next hop.3. If the second fragment is still greater than MTU, continute to cut the datagram until all

fragments are less than MTU.

When MTU is used as the basic length to fragment a datagram, the fragmentation efficiency ishighest. In practise, it is not mandatory to use MTU as the basic fragmentation length and alength smaller than MTU is also allowed.

During fragmentation, information at the transport layer is located in the first fragment. Otherfragments 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 thesame datagram identification previously. Then, the reassembly procedure is initiated. Theprocedure for fragmenting a datagram at the IP layer is as follows:




Issue 01 (2008-06-10)

1. When the first fragment of a datagram is received (Fragment Offset is zero), the data fromthe fragment is placed in the data buffer that is dedicated to the first fragment.

2. When other fragments except the first fragment and the last fragment are received, the datafrom these fragments is placed in the public data buffer.

3. If the last fragment (that is the More Fragments field is zero) is received, the total datalength is computed (Fragment Offest x 8 + data length of the last fragment).

4. A data buffer is assigned to the datagram, the datagram is reassembled, and the timer isstarted.

5. The timer is refreshed every time a fragment is received. The received fragments are paddedto the data buffer according to attached offset.

6. The last fragment is used if some received fragments are identical.7. If the timer runs out during datagram reassembly, datagram ressembly is over and all the

received fragments are discarded.8. 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 UDPis characterized by less overhead and higher real-time performance. Therefore, UDP is widelyused.

Connectionless features of UDP are applied on the Abis interface (IP) to map Um channels andAbis resources, to establish a type of connectionless Socket, and to transmit packets toGFGUB of the BSC.


Overview

The Service Access Point (SAP) of L2 is the connection point for providing services for L3. AnSAP is identified by a Service Access Point Identifier (SAPI).





Function

The LAPD reliably transfers end-to-end information between L3 entities through the D channel.Specifically, the LAPD supports:



1-41
















In terms of functions, traffic management messages are classified into the following:

l Radio link layer management messages that are used to manage the data link layer on radiochannels

l Dedicated channel management messages that are used to manage dedicated channels suchas the SDCCH and TCH

l Common control channel management messages that are used to manage common controlchannels

l TRX management messages that are used to manage TRXs

NOTE


Radio link management procedures

Radio link management procedures consist of the following:




Issue 01 (2008-06-10)










Dedicated Channel Management Procedures

The dedicated channel management procedures consist of the following:











1-43
























Issue 01 (2008-06-10)

OM Information ModelThe OM information model consists of the following:l Management objects



SITE


TRX0 TRX1 TRXm

BTS TRX

Channel 0

Channel 1

Chanel7

…

…

…

l Addressing of management objectsNetwork management messages are addressed through the classes and instances of themanagement objects. Each object instance in the BTS has a complete L2 connectiondescription. The first established connection is assigned a semi-permanent or permanentdefault TEI. The subsequent connections are assigned the TEIs provided during theestablishment of TEI procedures. Object instances can also use L3 addresses. The mixeduse of L2 addressing and L3 addressing enables one site to have one or multiple physicallinks.

l Management object stateA management object can be in three states, the administrative state, operational state, andavailability state. For details, see Table 1-9, Table 1-10, and Table 1-11. The availablestate further describes the operational state, and only the BSC controls the administrativestate.


Status Description






1-45


Status Description




Status Description








Basic Procedures

All procedures are based on formatted OM messages. Most formatted OM messages initiatedby the BSC or the BTS require the peer L3 to respond with formatted OM messages. This pairof formatted OM messages or a formatted OM message that does not require a response is calleda basic procedure.


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 certainbasic procedure is not complete, the system does not start the subsequent basic procedures. Whenthere is no response (ACK or NACK) in the previous basic procedure before L3 timeout, no




Issue 01 (2008-06-10)

subsequent basic procedure is sent to this object instance. The default value for L3 timeout is10 seconds.












l Other procedures

1.6 Um InterfaceThe Um interface lies between an MS and the BTS. It is used for the interworking between theMS and the fixed part of the GSM system. The links on the Um interface are radio links. TheUm interface transmits the information about radio resource management, mobilitymanagement, and connection management.

1.6.1 Physical Layer on the Um InterfaceThe physical layer on the Um interface defines the radio access capabilities of the GSM andprovides basic radio channels for information transmission at higher layers.

1.6.2 LAPD Layer on the Um InterfaceThe LAPD Layer on the Um interface is a data link layer. It uses the LAPDm protocol, anddefines various data transmission structures for controlling data transmission.

1.6.3 Layer 3 Entity on the Um InterfaceThe L3 entity on the Um interface consists of many functional program blocks.

1.6.1 Physical Layer on the Um InterfaceThe physical layer on the Um interface defines the radio access capabilities of the GSM andprovides basic radio channels for information transmission at higher layers.

The physical layer is the bottom layer on the Um interface. It provides physical links fortransmitting bit streams. It also provides higher layers with various logical channels, includingtraffic 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 resourcemanagement sublayer (RR) of L3, and other functional units.



1-47

Figure 1-12 Interfaces of L1 on the Um interface

Radio resourcemanagement (3)

Data link layer

MPH primitive PH primitive

Physical layer

TCH

Other functional units

L1 provides the following services:l Access capability

L1 provides a series of limited logical channels for transmission service. Logical channelsare multiplexed onto physical channels. Each TRX has eight physical channels. Throughdata configuration, logical channels are mapped to physical channels.

l Bit error detectionL1 provides error protection transmission, including error detection and correction.

l CipheringBased on a selected ciphering algorithm, the BSS ciphers the bit sequence.

1.6.2 LAPD Layer on the Um InterfaceThe LAPD Layer on the Um interface is a data link layer. It uses the LAPDm protocol, anddefines various data transmission structures for controlling data transmission.

L2 provides reliable dedicated data links between an MS and the BTS. It uses the LAPDmprotocol that evolves from the LAPD protocol. The LAPDm layer receives the services fromthe physical layer and provides services for L3 through the SAP of L2. An SAP is identified byan 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.

FunctionLAPDm 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, andDCCH.

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 isidentified by a data link connection identifier (DLCI).

l Allowing frame type identification

l Allowing L3 message units to be transparently transmitted between L3 entities

l Performing sequence control to maintain the order of the frames transmitted through a DLC

l Detecting format errors and operation errors on data links




Issue 01 (2008-06-10)


l Establishing a contention resolution on a data link after an access request is detected on theRACH

Operation TypeL2 transmits L3 information in unacknowledged and acknowledged modes. One Dm channelcan be in both modes at the same time.

l Unacknowledged modeIn 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 theRACH.

l Acknowledged modeIn acknowledged mode, L3 information is transferred in numbered Information (I) frames.L2 acknowledges the I frames. It performs error correction by resending unacknowledgedframes. When L2 fails to correct errors, it informs the management layer of the correctionfailure. Flow control procedures are also defined. The acknowledged mode is applicableto the DCCH.

Information Transfer ModeInformation is transferred in different modes on different channels.

l Information transfer on the BCCH: The BCCH transfers the broadcast messages from theBTS to the MS. Only the acknowledged mode can be used on the BCCH.

l Information transfer on the PCH+AGCH: These channels transfer messages from the BTSto the MS. Only the unacknowledged mode is applicable to the PCH+AGCH.

l Information transfer on the DCCH: Either the acknowledged or the unacknowledged modecan be used. The transfer mode is determined by L3.

Data Link ReleaseL2 release is initiated by L3. The data links in frame mode are released in the following modes:

l Normal releaseThe BTS and the MS exchange DISC frames and UA frames or DM frames.

l Local releaseNo frame is exchanged. Generally used in abnormal cases.

1.6.3 Layer 3 Entity on the Um InterfaceThe L3 entity on the Um interface consists of many functional program blocks.

OverviewThe L3 entity on the Um interface consists of many functional program blocks. These programblocks transfer message units between all L3 entities and between L3 and its adjacent layers.

L3 performs the following functions:



1-49

l Establishing, operating, and releasing dedicated radio channels (RR)

l Performing location update, authentication, and TMSI reallocation (MM)

l Establishing, maintaining, and terminating circuit-switched calls (CC)

l Supporting supplementary services (SS)

l Supporting short message services (SMS)

L3 uses L3 signaling protocols between the MS and the network. Here the functions of differententities 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 adjacentsublayers in L3 are described in primitives and parameters. The three sublayers in L3 performinformation exchange between peer entities.

Structure and FunctionsL3 consists of three sublayers. The CM sub-layer (the highest sub-layer) consists of threefunctional entities: Call Control (CC), Short Message Service (SMS), and SupplementaryService (SS).

In total, L3 on the Um interface has five functional entities. They perform the followingfunctions:

l Radio Resource Management (RR)Establishing, maintaining, and releasing physical channels and logical channels, as well asperforming cross-cell connection upon the request from the CM sublayer

l Mobility Management (MM)Performing MS-specific functions and notifying the network when an MS is activated anddeactivated, or when the location area of an MS changes. It is also responsible for thesecurity of activated radio channels.

l Call Control (CC)Performing all necessary functions to establish or release CS connections

l Supplementary Service (SS)Performing all necessary functions to support GSM supplementary services

l 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 ofmessages, for example, multiplexing and splitting. These functions are defined in the RadioResource Management and Mobility Management. They route messages according to theprotocol 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 entitiesand the messages of the MM entity to the RR service access point (RR-SAP), andmultiplexes the messages in case of concurrent transactions. The routing function of theRR distributes the to-be-sent messages according to their PD and the actual channelconfiguration.

l The messages provided at different service access points of layer 2 are split by the RRrouting function according to the PD. If a message belongs to the RR sublayer, this messageis transmitted to the RR entity based on the TI. The other messages are sent to the MMsublayer through the RR-SAP. If a message belongs to the MM sublayer, the message is




Issue 01 (2008-06-10)

transmitted to the MM entity based on the TI. The other messages are sent to the CMsublayer 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

AGC

H+P

CH

CC

MNCC-SAP

SS

MNSS-SAP

SMS

MNSMS-SAP

Mobile networkservice

MMREG -SAP

MMCC-SAPMMSS-SAP

MMSMS-SAP

MM CC SS SMSMM

RR-SAP

RR

PDRR

SAPI 0 SAPI 3

RAC

CH

SDC

CH

SAC

CH

FAC

CH

BCC

H

SDC

CH

SAC

CH

RR

Layer 3signaling

l The RR sublayer at the bottom receives the services from L2 through various service accesspoints (that is, various types of channels) of L2, and provides services to the MM sublayerthrough RR-SAP.

l The MM sublayer provides services to different entities through different SAPs: to the CCthrough MMCC-SAP, to the SS through MMSS-SAP, to the SMS through MMSMS-SAP,and to the high layer through MMREG-SAP.

l The three independent entities (CC, SS, and SMS) of the CM sublayer provide services tohigher layers through MNCC-SAP, MNSS-SAP, and MNSMS-SAP respectively.

Service Feature

L3 on the MS side provides the following services:



1-51

l Registration services, that is, IMSI attach and detach

l Call control services, including normal establishment of MS originating calls, emergencyestablishment of MS originating calls, call hold, call termination, and support for call-related supplementary services

l Support for call independent supplementary services

l Support for short messages service

L3 on the network side provides the following services:

l Call control services, including call establishment, call hold, call termination, and supportfor call-related supplementary services

l Support for call independent supplementary services

l Support for short messages service

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 theMM through RR-SAP. They are used to set up control channel connections and trafficchannel connection, indicate ciphering mode, release control channel connections, andtransmit control data.

Figure 1-14 Services provided by the RR sublayer

MS side Network sideMobile

managementsublayer

Radio resourcemanagement sublayer

RR-primitive

Protocol of the peer layer ofthe RR sublayer

SAPRR

l For the services provided by the MM, see Figure 1-15. These services are used to managethe three entities (CC, SS, and SMS) of the CM sublayer.




Issue 01 (2008-06-10)

Figure 1-15 Services provided by the MM sublayer

CC SMSSS

MS side

Mobilemanagement

sublayer

CC SMSSS

Network side

Mobilemanagement

sublayer

Protocol of the peer layerof the MM sublayer

1.7 Gb InterfaceThis describes the Gb interface. The Gb interface lies between the BSS and the SGCN. It is astandard interface.

1.7.1 Protocol Stack on the Gb InterfaceThe protocol stack on the Gb interface consists of the physical layer, NS layer, and BSSGP layer.

1.7.2 FR/IPThis describes FR/IP. The physical layer on the Gb interface supports the FR or IP connectionmode.

1.7.3 NSThis describes NS. The NS is present at both sides of the Gb interface. The functions of NS atthe two sides are symmetrical.

1.7.4 BSSGPThis describes BSSGP. The BSSGP is present at both sides of the Gb interface. The functionsof BSSGP at the two sides are asymmetrical.

1.7.1 Protocol Stack on the Gb InterfaceThe 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.



1-53

Figure 1-16 Protocol stack on the Gb interface

NS

FR/IP

BSSGP

SGSN

Gb interface

BSC LLC

BSSGP

NS

FR/IP

GMM/SM

NS: Network Service BSSGP: Base Station Subsystem GPRS Protocol

LLC: Logical Link Control 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 layercan be connected in point-to-point mode, or through the frame relay network, or throughthe IP network. The physical layer provides communication services for NS.

l The Network Server (NS) layer is responsible for configuring and managing the NSVC orNSVL, for selecting routes for uplink data, for providing data transmission at the user plane,and for providing communication services for BSSGP.

l The BSSGP layer is responsible for transmitting the uplink/downlink signaling and data atthe 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/IPThis describes FR/IP. The physical layer on the Gb interface supports the FR or IP connectionmode.

FR/IP provides transmission paths for the upper layer.

l When physical connection uses FR, FR detects network status at the physical layer. Whennetwork status changes, FR reports the status and service condition of the network to theNS layer.

l 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 NSThis describes NS. The NS is present at both sides of the Gb interface. The functions of NS atthe two sides are symmetrical.

The difference in using the FR and IP protocol on the Gb interface lies in NS.




Issue 01 (2008-06-10)

l In Gb Over FR mode, the NS manages the NSVC and transmits the NS Service DigitalUnit (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 logicallyusable.

– The purpose of the Alive procedure is to test whether the NSVC is physically usable.

l In Gb Over IP mode, NS manages IP paths and transmits NS SDUs. IP path managementconsists 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 NSSDU. NS provides reliable transmission paths for the upper-layer protocol.

l Load balancing between NSVCs or IP pathsWhen NS SDU is transmitted at NS, NS select one or more NSVCs (or IP paths) from theNSVCs (or IP paths) that can transmit services to transmit user datagrams. In this way, theload at NS is evenly shared on all unblocked NSVCs (or IP paths) under the same NSE.

l Network congestion indicationWhen NS detects that congestion on the bottom links occurs or dispears, NS notifies theupper layer through a congestion indication message.

l NS status indicationWhen NS finds that faults on the bottom links occur or are rectified, transmission capacitychanges. NS notifies the upper layer of specific faults or fault recovery.

1.7.4 BSSGPThis describes BSSGP. The BSSGP is present at both sides of the Gb interface. The functionsof BSSGP at the two sides are asymmetrical.

The 3GPP 48018 protocol describes the service model of the BSSGP module, as shown in Figure1-17.



1-55

Figure 1-17 Service model of BSSGP

GSM 03.64 BSSGP

Service model in an SGSN

LLC

BSSGP

Network service

NM

NM

GMM

GMM

BSSGPRLC/MAC

RELAY

Network service

GSM 08.16

NM

NM

GMM

GMM

Service model in a BSS

GSM 08.16

RL

The functions of BSSGP on the BSS side are divided into Relay, GMM, and NM. BSSGPexchanges PDU datagrams with RLC/MAC in Relay mode, and then transmits datagrams to thepeer 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.l Flow control management

Because the transmission rate on the Gb interface is greater than the transmission rate onthe Um interface, flow control is required for the Gb interface. Flow control is categorizedinto two types, that is, cell flow control and MS flow control.

l LLC_DISCARDWhen the expired datagrams on the BSS side are discarded, this message is used to notifythe 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 BSSanalyzes the message based on paging areas, sends a paging message to related cells, andthen delivers the paging message to the Um interface.

l Suspending and resuming PS servicesIf an MS of class B needs to use CS services when the MS operate PS services, the MSuses this function to pause ongoing PS services. After CS services are over, the BSS informsthe SGSN to resume the previously pasused PS services.

l Notification and update of radio capabilityThe BSS performs this function to obtain parameters related to radio capability from theSGSN.

The BSSGP protocol has the following functions:l Sending signaling information and user data

l Performing flow control for downlink data




Issue 01 (2008-06-10)

l Blocking and unblocking the BVC

l Configuring and managing the BVC dynamically

l Detecting errors of interface messages

BSSGP has the following basic procedures:l Procedure of transmitting uplink and downlink data

l Paging procedure

l Notification procedure of radio access capability

l Request and response procedure of radio access capability

l Radio status procedure

l Procedure of suspending and resuming

l FLUSH_LL (Logic Link) procedure

l Flow control procedure

l Procedure of blocking and unblocking the PTP BVC

l Procedure of resetting the BVC

l Tracing procedure



1-57

2 BSS Signaling Tracing

About This Chapter

This describes the BSS signaling tracing, which consists of the signaling tracing on the Uminterface, Abis interface, A interface, Pb interface, Gb interface, and BSC-CBC interface, andsingle user signaling tracing.

2.1 Tracing CS MessagesThis describes how to trace the CS messages such as the messages on the A interface, Abisinterface, Pb interface, Um interface, BSC-CBC interface, and user messages.

2.2 Tracing PS MessagesThis describes how to trace messages on the Gb interface and Um interface.

HUAWEI BSC6000 Base Station SubsystemBSS Signaling Analysis Guide 2 BSS Signaling Tracing


2-1

2.1 Tracing CS MessagesThis describes how to trace the CS messages such as the messages on the A interface, Abisinterface, Pb interface, Um interface, BSC-CBC interface, and user messages.

2.1.1 Tracing the Messages on the A InterfaceThis describes how to trace the BSSAP, MTP2, MTP3, and SCCP messages on the A interface.

2.1.2 Tracing the Messages on the Abis InterfaceThis describes how to trace the RSL, OML, ESL, LAPD messages on the Abis interface.

2.1.3 Tracing the Messages on the Pb InterfaceWhen the PCU is in external mode, you can trace the messages on the Pb interface on theBSC6000 Local Maintenance Terminal. This describes how to trace the application messagesand LAPD messages on the Pb interface.

2.1.4 Tracing CS Domain Messages on the Um InterfaceThis 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 MessagesThis describes how to trace signaling messages on the A/Abis/Um interface on the LMT. Usingthe IMSI, IMEI, TMSI, MSISDN, or channel to specify a user to be traced

2.1.6 Tracing Messages on the BSC-CBC InterfaceThis describes how to trace signaling messages of the interfaces between the BSC and CBCthrough the LMT.

2.1.1 Tracing the Messages on the A InterfaceThis 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 InterfaceThis describes how to trace all signaling messages on the A interface on the LMT. The messagesconsist of DTAP message, BSSMAP message, Paging message, and other messages.

2.1.1.2 Tracing SCCP Messages on the A InterfaceThis describes how to trace the SCCP messages on the A interface based on the DPC, the SCCPuser message, and the MTP3 primal message.

2.1.1.3 Tracing MTP3 Messages on the A InterfaceThis describes how to tracing the MTP3 messages on the A interface based on link number, linkset, 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 InterfaceThis 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 InterfaceThis describes how to trace SCTP messages based on specified subrack, slot, CPU number, andlink number on the LMT. The messages consist of control message, data message, and heartbeatmessage.

2.1.1.6 Tracing M3UA Messages on the A Interface

2 BSS Signaling TracingHUAWEI BSC6000 Base Station Subsystem



Issue 01 (2008-06-10)

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, transferringmessage, SS7 network management message, ASP service maintenance message, ASP statemaintenance 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 messagesconsist of DTAP message, BSSMAP message, Paging message, and other messages.

Prerequisitel The LMT runs normally.

l 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 boxand add them to the Selected Cells box.



2-3

Step 3 Click OK.

----End

Resultl If the operation is successful:

– If the tracing mode is Save on GOMU/GBAM, the LMT does not display the tracedmessages. You can review the output file of the traced message. For details, refer toReviewing Trace Message Files.

– If the tracing mode is Report, a dialog box is displayed, prompting the information ofthe message tracing task, as shown in Figure 2-2.

Figure 2-2 Tracing BSSAP messages on the A interface

l 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 Clear Message: Clear the displayed messages.

l Stop Scroll: Stop scrolling the displayed messages.

l Stop Trace: Stop the current tracing task.

l Restart Trace: Restart the tracing task.

l View Task: View the established tracing task.

l Search: Search for the specified character string in the displayed messages.

l Save Selection: Save the selected messages.




Issue 01 (2008-06-10)

l Save All: Save all the traced messages.

Tracing SCCP Messages on the A InterfaceThis describes how to trace the SCCP messages on the A interface based on the DPC, the SCCPuser message, and the MTP3 primal message.


l The communication between the LMT and the BSC is normal.

l The SCCP link is configured.

ContextFor details of Message Type, refer to Message Types.



ProcedureStep 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



2-5




Figure 2-4 Tracing SCCP messages on the A interface


Postrequisite


Right-click the message to be analyzed. The shortcut menu provides the following options:

l Clear Message: Clear the displayed messages.











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, linkset, and the Destination Signaling Point(DSP). The MTP3 messages consist of SNM message,SLT message, MT message, and L2_CHANGE message.




l 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



2-7




Figure 2-6 Tracing MTP3 messages on the A interface


PostrequisiteYou can double-click a message to view the detailed information.












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.




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



2-9

Step 3 Click OK.

----End




Figure 2-8 Tracing MTP2 messages on the A interface


Postrequisite












Issue 01 (2008-06-10)


Tracing SCTP Messages on the A InterfaceThis describes how to trace SCTP messages based on specified subrack, slot, CPU number, andlink number on the LMT. The messages consist of control message, data message, and heartbeatmessage.

Prerequisitel The LMT runs normally.l The communication between the LMT and the BSC is normal.l An SCTP link is configured.




ProcedureStep 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 SaveFile.

Step 3 Click OK.

----End



2-11




Figure 2-10 Tracing SCTP messages on the A interface


Postrequisite













Issue 01 (2008-06-10)


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, transferringmessage, SS7 network management message, ASP service maintenance message, ASP statemaintenance message, and routing key word message



l An M3UA link is configured.

Context




Procedure

Step 1 On the Trace & Monitor tab page, choose Trace > Trace CS Message > Trace A InterfaceMessage > 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



2-13




Figure 2-12 Tracing M3UA messages on the A interface














Issue 01 (2008-06-10)

2.1.2 Tracing the Messages on the Abis InterfaceThis describes how to trace the RSL, OML, ESL, LAPD messages on the Abis interface.

2.1.2.1 Tracing RSL Messages on the Abis InterfaceThis describes how to trace all the Radio signaling link(RSL) messages on the Abis interface onthe LMT. The messages consist of measurement report, channel request message, pagingmessage, RLM message, and TRXM message.

2.1.2.2 Tracing OML Messages on the Abis InterfaceThis describes how to trace operation and maintenance link(OML) signaling messages on theAbis interface on the LMT. The messages consist of common message and OM message.

2.1.2.3 Tracing ESL Messages on the Abis InterfaceThis describes how to trace all the extend signalling link(ESL) messages on the Abis interfaceon the LMT. The messages consist of common message and OM message.

2.1.2.4 Tracing EML Messages on the Abis InterfaceThis describes how to trace extend maintenance link(EML) messages on the Abis interface basedon site location on the LMT. The messages consist of common message and OM message.

2.1.2.5 Tracing LAPD Messages on the Abis InterfaceThis describes how to trace LAPD messages on the Abis interface on the LMT. The LAPDmessages consist of RSL message, EML message, OML message, and ESL message. TRXtracing 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 onthe LMT. The messages consist of measurement report, channel request message, pagingmessage, RLM message, and TRXM message.


l The communication between the BSC and the BTS is normal.

Context

Tracing messages based on TRXs or cells (a maximum of 16 cells)



CAUTIONAfter the BTS connected to the Abis interface is moved manually, close the message trace ofthis type and restart the message trace function.




2-15

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







Issue 01 (2008-06-10)

Figure 2-14 Tracing RSL messages on the Abis interface


Postrequisite











Tracing OML Messages on the Abis Interface

This describes how to trace operation and maintenance link(OML) signaling messages on theAbis interface on the LMT. The messages consist of common message and OM message.





2-17

ContextTracing the OML messages at Abis interface based on sites (a maximum of 16 sites)




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 andadd them to the Selected Cells box.

Step 3 Click OK.

----End







Issue 01 (2008-06-10)

Figure 2-16 Tracing OML messages on the Abis interface


Postrequisite











Tracing ESL Messages on the Abis Interface

This describes how to trace all the extend signalling link(ESL) messages on the Abis interfaceon the LMT. The messages consist of common message and OM message.





2-19

ContextTracing the ESL messages on the Abis interface based on sites (a maximum of 16 sites)




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 andadd them to the Selected Cells box.

Step 3 Click OK.

----End







Issue 01 (2008-06-10)

Figure 2-18 Tracing ESL messages on the Abis interface


Postrequisite











Tracing EML Messages on the Abis Interface

This describes how to trace extend maintenance link(EML) messages on the Abis interface basedon site location on the LMT. The messages consist of common message and OM message.





2-21




Procedure

Step 1 On the Trace & Monitor tab page, choose Trace > Trace CS Message > Trace Abis InterfaceMessage > 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







Issue 01 (2008-06-10)

Figure 2-20 Trace EML Message on the Abis Interface dialog box











Tracing LAPD Messages on the Abis InterfaceThis describes how to trace LAPD messages on the Abis interface on the LMT. The LAPDmessages consist of RSL message, EML message, OML message, and ESL message. TRXtracing and site tracing are supported.




2-23





ProcedureStep 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







Issue 01 (2008-06-10)

Figure 2-22 Tracing LAPD messages on the Abis interface











2.1.3 Tracing the Messages on the Pb InterfaceWhen the PCU is in external mode, you can trace the messages on the Pb interface on theBSC6000 Local Maintenance Terminal. This describes how to trace the application messagesand LAPD messages on the Pb interface.

2.1.3.1 Tracing Application Messages on the Pb InterfaceThis describes how to trace application messages on the Pb interface on the LMT. The messagesconsist of paging message, confusion message, PCIC message, and other messages.

2.1.3.2 Tracing LAPD Messages on the Pb InterfaceThis describes how to trace the layer 2 messages on the Pb interface through the LMT. You cantrace the LAPD messages on the Pb interface based on the specified link.



2-25

Tracing Application Messages on the Pb InterfaceThis describes how to trace application messages on the Pb interface on the LMT. The messagesconsist of paging message, confusion message, PCIC message, and other messages.



l The communication between the BSC and the PCU is normal.

l The external PCU is configured.

ContextThe application messages on the Pb interface can be traced. A maximum of 16 cells aresupported.




ProcedureStep 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 Cellsbox and add them to the Selected Cells box.

Step 3 Click OK.

----End




Issue 01 (2008-06-10)




Figure 2-24 Tracing application messages on the Pb interface


Postrequisite











2-27


Tracing LAPD Messages on the Pb InterfaceThis describes how to trace the layer 2 messages on the Pb interface through the LMT. You cantrace the LAPD messages on the Pb interface based on the specified link.



l The external PCU is configured.

ContextFor details of Tracing Mode, refer to Tracing Modes.


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.




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






2-29

Figure 2-26 Tracing LAPD messages on the Pb interface


Postrequisite










2.1.4 Tracing CS Domain Messages on the Um InterfaceThis 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.





Issue 01 (2008-06-10)


ContextWhen the messages are traced based on cells, a maximum of 16 cells are supported.



Procedure

Step 1 On the Trace & Monitor tab page, choose Trace > Trace Message on the Um Interface. Adialog 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, TracingMode, and Color.

NOTE

When the Filter Condition is set to TRX or Cell, the execution interfaces are different. In this topic, theinstance 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.

Step 3 Click OK.

----End





2-31


Figure 2-28 Tracing messages on the Um interface


Postrequisite










2.1.5 Tracing User MessagesThis describes how to trace signaling messages on the A/Abis/Um interface on the LMT. Usingthe IMSI, IMEI, TMSI, MSISDN, or channel to specify a user to be traced





Issue 01 (2008-06-10)



l Tracing BSSAP Messages on the A Interface is successful.



Procedure

Step 1 On the Trace & Monitor tab page, choose Trace > Trace User Message. A dialog box isdisplayed, 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, orChannel.



2-33

NOTE

l If you trace the user messages through MSISDN (you are advised to trace the calling ID through thecalled ID):

l If you trace the calling party, the MSISDN is the called ID, that is, the ID that the MS calls. Forexample, if the MS calls 12345, then the MSISDN is 12345.

l If you trace the called party, the MSISDN is the calling ID. The MS must be enabled with callerID display. If 54331 is displayed on the MS, specify the MSISDN with 54321; if 8654321 isdisplayed on the MS, specify the MSISDN with 8654321.

l If you trace the user messages through TMSI or IMSI, you must determine the reassignment strategyon the MSC side:

l If TMSI is carried, you can trace the MS through the TMSI.

l If IMSI is carried, you can trace the MS through the IMSI.

l If you trace the user messages through IMEI, you must determine whether the IMEI is available to theMSC.

Step 3 Click OK.

----End




Figure 2-30 Tracing user messages





Issue 01 (2008-06-10)










2.1.6 Tracing Messages on the BSC-CBC InterfaceThis describes how to trace signaling messages of the interfaces between the BSC and CBCthrough the LMT.



l The communication between the BSC and the CBC is normal.



Procedure

Step 1 On the Trace & Monitor tab page, choose Trace > Trace Message on the BSC-CBCInterface. A dialog box is displayed, as shown in Figure 2-31.



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







Issue 01 (2008-06-10)

Figure 2-32 Tracing Messages on the BSC-CBC Interface











2.2 Tracing PS MessagesThis describes how to trace messages on the Gb interface and Um interface.

ContextDuring PS message tracing, five tracing tasks with different location information can beperformed simultaneously.

2.2.1 Tracing the Messages on the Gb InterfaceThis describes how to trace the PTP messages and SIG messages on the Gb interface.



2-37

2.2.2 Tracing PS Domain Messages on the Um InterfaceThis describes how to trace the PS domain messages on the Um interface based on the specifiedTRX or cell on the LMT when the PCU is installed inside the BSC. The messages consist ofDUMMY message, system message, null paging message, and data block message.

2.2.1 Tracing the Messages on the Gb InterfaceThis describes how to trace the PTP messages and SIG messages on the Gb interface.

2.2.1.1 Tracing SIG Messages on the Gb InterfaceThis describes how to trace SIG signaling messages on the Gb interface based on NSEI on theLMT when the PCU is installed inside the BSC.

2.2.1.2 Tracing PTP Messages on the Gb InterfaceThis describes how to trace the PTP signaling messages on the Gb interface based on cell orNSEI+BVCI on the LMT when the PCU is installed inside the BSC.

Tracing SIG Messages on the Gb InterfaceThis describes how to trace SIG signaling messages on the Gb interface based on NSEI on theLMT when the PCU is installed inside the BSC.


l The communication between the BSC and the SGSN is normal.

l The NSE and the association between BVCs and cells are already configured.



Procedure

Step 1 On the Trace & Monitor tab page, choose Trace > Trace PS Message > Trace Gb InterfaceMessage > SIG Message. A dialog box is displayed, as shown in Figure 2-33.




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






2-39

Figure 2-34 Tracing SIG messages on the Gb interface











Tracing PTP Messages on the Gb InterfaceThis describes how to trace the PTP signaling messages on the Gb interface based on cell orNSEI+BVCI on the LMT when the PCU is installed inside the BSC.






Issue 01 (2008-06-10)

l The NSE and the association between BVCs and cells are already configured.



Procedure

Step 1 On the Trace & Monitor tab page, choose Trace > Trace PS Message > Trace Gb InterfaceMessage > 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






2-41

Figure 2-36 Tracing PTP messages on the Gb interface











2.2.2 Tracing PS Domain Messages on the Um InterfaceThis describes how to trace the PS domain messages on the Um interface based on the specifiedTRX or cell on the LMT when the PCU is installed inside the BSC. The messages consist ofDUMMY message, system message, null paging message, and data block message.





Issue 01 (2008-06-10)




Context




Procedure

Step 1 On the Trace & Monitor tab page, choose Trace > Trace PS Message > Trace Um InterfaceMessage. 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






2-43

Figure 2-38 Trace PS Message on the Um Interface dialog box














Issue 01 (2008-06-10)

3 BSS System Information

About This Chapter

System information (SI) refers to the major radio network parameters on the Um interface suchas the network identification parameters, cell selection parameters, system control parameters,and network functional parameters.

3.1 BSS System Information TypeThe BSS system information consists of System Information Type 1, System Information Type2, System Information Type 2bis, System Information Type 2ter, System Information Type2quater, 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 InformationThis describes the internal BSC signaling procedure of the system information.

HUAWEI BSC6000 Base Station SubsystemBSS Signaling Analysis Guide 3 BSS System Information


3-1

3.1 BSS System Information TypeThe BSS system information consists of System Information Type 1, System Information Type2, System Information Type 2bis, System Information Type 2ter, System Information Type2quater, 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 1This describes the functions and contents of System Information Type 1.

3.1.2 System Information Types 2, 2bis, 2ter, and 2quaterThis topic describes the functions and contents of System Information Types 2, 2bis, 2ter, and2quater.



3.1.5 System Information Types 5, 5bis, and 5terThis describes the functions and contents of System Information Types 5, 5bis, and 5ter.



3.1.8 System Information Type 8This describe the functions and contents of System Information Type 8.



FunctionsSystem 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 cellallocation (CA).

ContentsTable 3-1 lists the contents of System Information Type 1.

3 BSS System InformationHUAWEI BSC6000 Base Station Subsystem



Issue 01 (2008-06-10)

Table 3-1 Contents of System Information Type 1

Type Contents

SYS INFO 1 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 configurationof cell frequencies is subject to the Table 3-2. The BSC selects a format of cell channeldescription 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

Cell Channel Description IEI octet 1

Bit Bit 0 0 Bit Bit Bit Bitoctet 2

128 127 Spare Spare 124 123 122 121

Bit Bit Bit Bit Bit Bit Bit Bitoctet 3

120 119 118 117 116 115 114 113

… … … … … … … … …

Bit Bit Bit Bit Bit Bit Bit Bitoctet 17

8 7 6 5 4 3 2 1

Table 3-3 Format of cell channel description

Bit 128 Bit 127 Bit 124 Bit 123 Bit 122 FormatNotation

0 0 X X X bit map 0

1 0 0 X X 1024 range

1 0 1 0 0 512 range

1 0 1 0 1 256 range



3-3

Bit 128 Bit 127 Bit 124 Bit 123 Bit 122 FormatNotation

1 0 1 1 0 128 range

1 0 1 1 1 variable bitmap

Different formats of cell channel description correspond to different numbers of availablecell frequencies. Assume that the number of available frequencies for a cell is n (except forduplicate and invalid frequencies). ARFCN(i) (i=1,…,n) represents the Absolute RadioFrequency Channel Number. The numbers of available frequencies for different formatsof cell channel description are as follows:– Bit map 0

The bit map 0 format is used for GSM 900 frequencies. The number of availablefrequencies is 64 if 1 ≤ARFCN(i) ≤ 124.

– 1024 rangeIf the 1024 range format is used, the number of available frequencies for a cell is equalto or smaller than 16. For a GSM 900 cell, 1 ≤ ARFCN (i) ≤ 124. For a GSM 1800cell, 512 ≤ ARFCN (i) ≤ 885.

– 512 rangeIf the 512 range format is used, the number of available frequencies for a cell is equalto or smaller than 18. The interval between any two frequencies must be less than 512.

– 256 rangeIf the 256 range format is used, the number of available frequencies for a cell is equalto 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 beconfigured together.

– 128 rangeIf the 128 range format is used, the number of available frequencies for a cell is equalto 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 beconfigured together.

– Variable bit mapIf the variable bit map format is used, the number of available frequencies for a cell isequal to or smaller than 64. The interval between any two frequencies must be 1–111.For example, in variable bit map format, you can configure 64 frequencies numberedfrom 512 to 575 with an increment of 1. However, you cannot configure 64 frequenciesnumbered 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 ofchannel request messages that can be resent before a MS receives an immediate




Issue 01 (2008-06-10)

assignment message. Therefore, the number of channel request messages that an MScan 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_integerNumber of slots to spread transmission (Tx-integer) defines the number of timeslotsbetween two consecutive transmissions of channel request messages.

– Cell Bar AccessCell Bar Access (CBA) determines whether an MS can gain access to a cell. It has onlyone bit. Value 0 of this bit means that the MS can access the cell, and value 1 of this bitmeans the MS cannot access the cell. This parameter does not affect the handover accessof the MS.

– ACAccess Control Class N (AC CN) defines the access class for an MS. Each class isrepresented by a bit. N = 0, 1, … 9, 11, …, 15, totally 16 bits. If the AC CN bit is 1, theaccess 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 11–15 have a higher access priority than the MSsof classes 0–9. The MSs of classes 11-15 have the same priority. So do the MSs ofclasses 0–9.

– RECall reestablishment allowed (RE) determines whether call reestablishment is allowedwhen call drops occur. The parameter has one bit. Value 0 means that callreestablishment is allowed in the cell. Value 1 means that call reestablishment is notallowed in the cell.

– ECEmergency call allowed (EC) determines whether emergency calls are allowed whenthere is no SIM or the access is barred. The parameter has one bit. Value 0 means thatemergency calls are allowed in the cell to all MSs. Value 1 means that emergency callsare not allowed in the cell except for the MSs that belong to classes 11–15.

NOTE

A random value, which belongs to {S, S+1,....S+T-1}, is used as the time interval between twoconsecutive transmissions of channel request messages sent by an MS. The units of timeslotintervals are TDMA frames. "S" is subject to the configuration of common channels. "T" is Tx-integer.

Table 3-4 lists the relation between "S" and "T".

Table 3-4 Relation between "S" and "T"

Tx-Integer Non CombinedCCCH Combined CCCH

3, 8, 14, 50 55 41

4, 9, 16 76 52

5, 10, 20 109 58

6, 11, 25 163 86



3-5

Tx-Integer Non CombinedCCCH Combined CCCH

7, 12, 32 217 115

When satellite transmission is used, Huawei recommends that Max retrans be set to 4 and Tx-integer be set to 32 to reduce the delay caused by satellite transmission.

l SI 1 Rest OctetsThe SI 1 Rest Octets information element has eight bits. It contains indication informationabout the PCS1900 and the DCS1800 and spare bits.

3.1.2 System Information Types 2, 2bis, 2ter, and 2quaterThis topic describes the functions and contents of System Information Types 2, 2bis, 2ter, and2quater.

Functionsl 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 inidle mode.

– A PHASE1 MS in GSM900 recognizes only the neighbor cell frequencies described inSystem Information Type 2 and ignores that described in System Information Types2bis and 2ter.

l System Information Type 2bis is sent optionally on the BCCH. It provides informationabout 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 BA1list. Therefore, System Information Type 2bis describes the rest of the frequencies that areon the same frequency band.

l System Information Type 2ter is sent on the BCCH. It provides information about theextension of the BCCH allocation in the neighbor cells (part of BA1). Only the dual-bandMSs read this message. The GSM900 MSs and the GSM1800 MSs ignore this messagebecause of band difference.

l System Information Type 2quater provides information about the BCCH allocation in the3G neighbor cells under the condition that the inter-system handover is supported and the3G neighbor cells are configured. It is used for the reselection of 3G cells.

ContentsTable 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 Contents

SYS INFO 2 Neighbor Cell Desc

NCC permitted




Issue 01 (2008-06-10)

Type Contents

RACH Control Para

SYS INFO 2 BIS Neighbor Cell Desc

RACH Control Para

SYS INFO 2TER Neighbor Cell Desc. (Extended)

SYS INFO 2QUATER 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 numbersof the BCCH carriers in the neighbor cells of the current cell. Currently, Huawei supportsa 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 ChannelDescription information element. For details, refer to the cell channel description in 3.1.1System 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 SystemInformation Types 2bis and 5bis. If the EXT-IND bit is set to 0, System InformationTypes 2 and 5 carry the complete BA. If the EXT-IND bit is set to 1, System InformationTypes 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 onebit and is used by the MS to discriminate the changes in the BA1 or the BA2. If theneighbor cell relation and the BA2 are modified during the conversation, the BA-INDbit in System Information Type 5 should be 1, indicating that the MS should decode theneighbor cell frequencies again.

l NCC PermittedThe NCC Permitted information element is sent in System Information Types 2 and 6. Ithas eight bits and provides all the NCCs required by MSs. If bit N is 0 (0 ≤ N ≤ 7), theMS does not measure the power level of the cell where the NCC is N, which means thatthe MS is not handed over to the network where the NCC is N. The NCC Permittedinformation element is mainly used for handovers and cell reselection.

l RACH Control ParaFor details about the RACH Control Para information element, refer to 3.1.1 SystemInformation Type 1.

l Neighbor Cell Desc. (Extended)The Neighbor Cell Desc. (Extended) information element is sent in System InformationTypes 2ter and 5ter. Except for bit 5 (BA-IND) and bits 6 and 7 (Multiband_Reporting) ofoctet 2, this information element is coded as the Cell Channel Description informationelement. For details, refer to 3.1.1 System Information Type 1.

l Multiband_ReportingThe Multiband Reporting information element is sent in System Information Types 2terand 5ter. It has two bits and is used to request the dual-band MS to report information aboutneighbor cells of multiple bands. For details, refer to Table 3-6.



3-7

Table 3-6 Multiband reporting

Multiband Reporting (2bits)

Meaning

0 The MS reports six cells where the signal strength is thestrongest, irrespective of the band used.

1 The MS reports a neighbor cell that is on a differentband. It reports in the other five positions the neighborcells that are on the same band.

10 The MS reports two neighbor cells that are on a differentband. It reports in the other four positions the neighborcells that are on the same band.

11 The MS reports three neighbor cells that are on adifferent band. It reports in the other three positions theneighbor cells that are on the same band.

l 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


FunctionsSystem Information Type 3 describes the location area identification, cell identity, RACHcontrol, and parameters of cell selection. They are mandatory and sent on the BCCH.



Type Contents

SYS INFO 3 Cell Identity

LAI

Cell Option (BCCH)

Cell Selection Para

RACH Control Para




Issue 01 (2008-06-10)

Type Contents

SI 3 Rest Octets


l CGI

The Cell Global Identification (CGI) consists of the Location Area Identification (LAI) andthe Cell Identity (CI). The LAI consists of the Mobile Country Code (MCC), the MobileNetwork 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 toaccess the network of the cell and whether the current location area has changed or not. Ifthe location area has changed, the MS initiates a location update procedure.

– The MCC is unique worldwide. It consists of three decimal numerals. For example, theMCC of China is 460.

– The MNC is unique nationwide. It consists of two decimal numerals. For example, theMNC 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 andthe CI have two octets. The CI ranges from 0X0001 to 0XFFFE. 0X0000 and 0XFFFFare reserved.

l 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 parameterhas one bit. If the bit is 0, the MSC is released in 1998 or earlier. If it is 1, the MSC isreleased in 1999 or later.

– ATT

The Attach-Detach Allowed (ATT) parameter indicates whether the MS is allowed toinitiate an IMSI attach and detach procedure. The ATT has one bit. If it is 0, theprocedure is not allowed. If it is 1, the procedure is allowed.

– CCCH-CONF

The CCCH-CONF parameter determines the combination mode of the CCCH. TheCCCH-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 CCCHMessage Blocks inOne BCCHMultiframe

Meaning

000 9 One basic physical channel usedfor CCCH, not shared withSDCCHs



3-9

CCCH-CONF(Three Bits)

Number of CCCHMessage Blocks inOne BCCHMultiframe

Meaning

001 3 One basic physical channel usedfor CCCH, shared with SDCCHs

010 18 Two basic physical channelsused for CCCH, not shared withSDCCHs

100 27 Three basic physical channelsused for CCCH, not shared withSDCCHs

110 36 Four basic physical channelsused for CCCH, not shared withSDCCHs

Others - Reserved

– BS_AG_BLKS_RES

The BS_AG_BLKS_RES parameter indicates the proportion of AGCH message blocksin 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 determinethe proportions of AGCHs and PCHs on the CCCH. You can modify theBS_AG_BLKS_RES to balance the loading of AGCHs and PCHs.

– BS-PA-MFRAMSThe BS-PA-MFRAMS parameter indicates the number of multiframes contained in theperiod of a paging subchannel. It actually determines the number of paging subchannelscontained 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 subchannelrespectively.

– T3212The 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 0indicates that periodic location update is not performed.

l Cell Selection ParaThe Cell Selection Para affect the activities of an MS after it is switched on. Theseparameters include the following:– Cell Reselection Hysteresis

An MS can perform cell reselection only if the difference between the signal level ofthe neighbor cell (in a different location area) and the C2 of the local cell is greater thanthe value of Cell Reselection Hysteresis. The parameter has three bits. The value rangeis 0-7, representing 0-14 dB respectively.

– MS_TXPWR_MAX_CCH




Issue 01 (2008-06-10)

The MS_TXPWR_MAX_CCH parameter indicates the transmit power the MS may usebefore it receives the power control command. The parameter has five bits, ranging from0 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 forthe MS to access the system. It has six bits. The value range is 0-63, representing thesignal level of -110 dBm to -47 dBm respectively.

– ACS

The ACS parameter indicates whether the MS uses C2 during cell reselection. It hasonly one bit. In System Information Type 3, this parameter is meaningless. In SystemInformation Type 4, value 0 of the bit indicates that the SI4 REST of System InformationType 4 is used to calculate the parameters related to C2. Other values indicate that theREST of System Information Types 7 and 8 are used to calculate the parameters relatedto C2.

– NECI

The NECI parameter indicates whether the current cell supports half rate services ornot. It has only one bit. Value 0 of the bit indicates that the current cell does not supporthalf rate services. Value 1 of the bit indicates that the current cell supports half rateservices.

l RACH Control Para

For details, refer to 3.1.1 System Information Type 1.

l 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 parameterand whether the parameter used to calculate C2 exists or not. It has only one bit. Value0 of the bit indicates that the MS uses C1 as the cell reselection parameter. Value 1 ofthe bit indicates that the MS uses C2 that is derived from the system information as thecell reselection parameter.

– CBQ

The Cell Bar Qualify (CBQ) parameter has only one bit. Along withCELL_BAR_ACCESS, it indicates the priority of a cell. For details, refer to Table3-9.

Table 3-9 Parameters affecting cell priority in cell selection

CBQ CBA Priority of CellSelection

Status of CellReselection

0 0 Normal Normal

0 1 Barred Barred

1 0 Low Normal

1 1 Low Normal

– CRO



3-11

The CELL_RESELECT_OFFSET (CRO) parameter applies an offset to C2. It has sixbits. The range of the signal level is 0–126 dB. Along with TO and PT, the CRO is usedto regulate C2 manually.

– TOThe value range of the TEMPORARY_OFFSET (TO) parameter is 0–7. Each levelrepresents 10 dB. For example, 0 refers to 0 dB, 1 refers to 10 dB, 6 refers to 60 dB,and 7 refers to infinity.

– PTThe value range of the PENALTY_TIME (PT) parameter is 0–31. Each level represents20 seconds. For example, 0 refers to 20 s and 30 refers to 620 s. 31 is reserved to indicatethat CRO is subtracted from C2 and that TO is ignored.

– 2TerIThe 2TerI parameter indicates whether System Information Type 2ter can be obtainedor not.

– ECSCThe Early Classmark Sending Control (ECSC) parameter indicates whether the ECSCis allowed or not.

– GPRSThe GPRS parameter indicates whether the GPRS is supported or not.

– SI2quaterIThe SI2quaterI parameter indicates whether System Information Type 2quater can beobtained or not.


FunctionsSystem Information Type 4 provides information about the location area identification, RACHcontrol, cell selection parameters, and CBCH.

l Information about location area identification, RACH control, cell selection parameters ismandatory, it is sent on the BCCH.

l Information about CBCH is optional. It describes the configurations of the CBCH and therelated frequency information and is used when the system supports cell broadcast.



Type Contents

SYS INFO 4 LAI

Cell Selection Para

RACH Control Para




Issue 01 (2008-06-10)

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.

l Cell Selection Para.For details, refer to 3.1.3 System Information Type 3.

l RACH Control Para.For details, refer to 3.1.2 System Information Types 2, 2bis, 2ter, and 2quater.

l CBCH Channel Description and CBCH Mobile Allocation (CBCH MA)Both CBCH Channel Description and CBCH MA are optional. If the system supports cellbroadcast, CBCH Channel Description indicates the configuration of the CBCH. If theCBCH is in frequency hopping mode, CBCH MA is mandatory.

l SI4 Rest Oct.If the cell selection parameter ACS is set to No, the SI4 Rest Oct. is used to calculate thecell 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 5terThis describes the functions and contents of System Information Types 5, 5bis, and 5ter.



3-13

Functionsl 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 SystemInformation Type 2, the MS can read the frequency information described in SystemInformation Type 5 when it is in the conversation state and report the information aboutthe neighbor cells in the measurement report. Such information is used for handovers. APHASE1 MS in GSM900 recognizes only the neighbor cell frequencies described inSystem Information Type 5 and ignores the neighbor cell frequencies described in SystemInformation Types 5bis and 5ter.

l 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 InformationType 5 does not describe all the frequencies in the BA1 list. Therefore, System InformationType 5bis describes the rest of the frequencies in the BA2 that are on the same frequencyband.

l 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-bandMSs. 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 Contents

SYS INFO 5 Neighbor Cell Desc

SYS INFO 5 BIS Neighbor Cell Desc

SYS INFO 5TER 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.

l Neighbor Cell Desc. (Extended)

For details, refer to 3.1.2 System Information Types 2, 2bis, 2ter, and 2quater.


FunctionsSystem Information Type 6 provides information about the location area identification, cellidentity, and other parameters of cell functions. These information is mandatory and is sent onthe SACCH.




Issue 01 (2008-06-10)

Contents

Table 3-12 lists the contents of System Information Type 6.


Type Contents

SYS INFO 6 LAI

Cell Identity

Cell Option (SACCH)

NCC Permitted


l Cell Global Identification (CGI)For details, refer to 3.1.3 System Information Type 3.

l Cell OptionFor details, refer to 3.1.3 System Information Type 3.

l NCC PermittedFor 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 reselectionparameters.

Contents

Table 3-13 lists the contents of System Information Type 7.


Type Contents

SYS INFO 7 SI 7 Rest Octets


l SI 7 Rest Octets contains the cell selection and reselection parameters used by the MS. Itmay also contain the Power Offset parameter used by the DCS1800 Class 3 MS.



3-15

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.


FunctionsSystem Information Type 8 is mandatory and is sent on the BCCH. It provides information aboutcell reselection parameters.



Type Contents



l The SI 8 Rest Octets information element contains the cell reselection parameters used bythe MS. It may also contain the Power Offset parameter used by the DCS1800 Class 3 MS.

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


FunctionsSystem Information Type 13 is sent on the BCCH by the network. It provides information aboutparameters related to GPRS services.



Type Contents


The SI 13 Rest Octets information element has the following parameters:




Issue 01 (2008-06-10)

l BCCH_CHANGE_MARKThe BCCH_CHANGE_MARK parameter has three bits. It changes according to themessages sent on the BCCH.

l SI_CHANGE_FIELDThe SI parameter is binary and indicates that the last bit of the BCCH_CHANGE_MARKparameter has changed. It has four bits and ranges from 0 to 15.

l SI13_CHANGE_MARKThe SI13_CHANGE_MARK parameter ranges from 0 to 3.

l RACThe RAC parameter is binary and indicates the routing area code. It has eight bits.

l SPGC_CCCH_SUPThe SPGC_CCCH_SUP parameter indicates whether the CCCH supports theSPLIT_PG_CYCLE parameter. Value 0 indicates that the CCCH does not supportSPLIT_PG_CYCLE. Value 1 indicates that the CCCH supports SPLIT_PG_CYCLE.

l PRIORITY_ACCESS_THRThe 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 and010 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.

l NETWORK_CONTROL_ORDERThe NETWORK_CONTROL_ORDER parameter has two bits. Value 00 indicates that thecell controls cell reselection and no measurement reports are sent. Value 01 indicates thatthe cell controls cell reselection and the MS sends the measurement reports. Value 10indicates that the network controls cell reselection and the MS sends the measurementreports. Value 11 is reserved.

l PSI1_REPEAT_PERIODThe PSI1_REPEAT_PERIOD parameter indicates the retransmit period of the PSI1. It hasfour bits. Value 0000 indicates that the retransmit period is one multiframe. Value 0001indicates that the retransmit period is two multiframes. Value 0010 indicates that theretransmit period is three multiframes. By analogy, value 1110 indicates that the retransmitperiod is 15 multiframes and value 1111 indicates that the retransmit period is 16multiframes.

l System Information Type 13 also includes parameters such as the GPRS Mobile Allocation,GPRS Cell Options, GPRS Power Control, Parameters struct, and PBCCH Descriptionstruct.

3.2 Internal BSC Signaling Procedure of the SystemInformation

This describes the internal BSC signaling procedure of the system information.

System Information Type 1You can obtain the Cell Frequency in System Information Type 1 in the Set Cell Attributesdialog box.



3-17

Table 3-16 describes the mapping between the RACH control parameters in System InformationType 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 thecorresponding parameters on the BSC6000 Local Maintenance Terminal

RACH Control Parameters inSystem Information Type 1

Parameters on the BSC6000 LocalMaintenance Terminal

Max Retrans MS MAX Retrans

Tx_interger Tx_interger

Cell Bar Access Cell_Bar_ Access

AC Common Access Control Class and SpecialAccess Control Class

RE Call Reestablishment Forbidden

EC EC allowed

To configure the parameters listed in the table on the BSC6000 Local MaintenanceTerminal, 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 CallDisable.

l In the dialog box shown in Figure 3-1, click Idle Mode. Set Tx-integer (RACH Timeslotthat equals to a TDMA frame, 4.615ms) and Cell_Bar_Access.

l In the dialog box shown in Figure 3-1, set Call Reestablishment Forbidden.




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 Type1 are automatically regulated according to the current flow control system.

System Information Types 2, 2bis, 2ter, and 2quaterl 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 theNCC Permitted field in Idle Mode.

– The RACH Control Parameters in System Information Types 2 and 2bis are the sameas that in System Information Type 1. For details, refer to Table 3-16.

l The information in System Information Type 2quater is obtained from the UTRAN SystemMessage, UTRAN FDD Cell BA1, and UTRAN TDD Cell BA1.



3-19


l In the dialog box shown in Figure 3-1, click Idle Mode, select Advanced, and then set theneighbor cell frequency in 2G BA1 Table.

l In the dialog box shown in Figure 3-1, click Idle Mode. Then set NCC Permitted.

l In the dialog box shown in Figure 3-1, click Call Control, and then click Advanced. Thenset the UTRAN system message in UTRAN System Message.

l In the dialog box shown in Figure 3-1, click Idle Mode, and then click Advanced. Thenset the UTRAN neighbor cell frequency in UTRAN FDD Cell BA1.

l In the dialog box shown in Figure 3-1, click Idle Mode, and then click Advanced. Thenset the UTRAN neighbor cell frequency in UTRAN TDD Cell BA1.

System Information Type 3The 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 thecorresponding parameters on the BSC6000 Local Maintenance Terminal.

Table 3-17 Control channel parameters in System Information Type 3 and the correspondingparameters on the BSC6000 Local Maintenance Terminal

Control Channel Parameters inSystem Information Type 3


ATT ATT

CCCH-CONF CCCH Conf

BS_AG_BLKS_RES BS_AG_BLKS_RES

BS-PA-MFRAMS BS-PA-MFRARMS

T3212 Period of Periodic Location Update (6 minutes)


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 correspondingparameters on the BSC6000 Local Maintenance Terminal.

Table 3-18 Cell option parameters in System Information Type 3 and the correspondingparameters on the BSC6000 Local Maintenance Terminal

Cell option parameters in SystemInformation Type 3


PWRC PWRC




Issue 01 (2008-06-10)

Cell option parameters in SystemInformation Type 3


DTX UL DTX

Radio Link Timeout Radio Link Timeout


l In the dialog box shown in Figure 3-1, click Other Attributes, and then clickAdvanced. On the Public Channel Control tab page, set PWRC.

l In the dialog box shown in Figure 3-1, set UL DTX.

l In the dialog box shown in Figure 3-1, click Call Control. Set Radio Link Timeout(SACCH period (480ms)).

Table 3-19 lists the cell option parameters in System Information Type 3 and the correspondingparameters on the BSC6000 Local Maintenance Terminal.

Table 3-19 Cell selection parameters in System Information Type 3 and the correspondingparameters on the BSC6000 Local Maintenance Terminal

Cell Selection Parameters in SystemInformation Type 3


Cell Reselection Hysteresis CRH

MS_TXPWR_MAX_CCH MS_TXPWR_MAX_CCH

RXLEV_ACCESS_MIN RXLEV_ACCESS_MIN

ACS PI

NECI Support Half Rate


l In the dialog box shown in Figure 3-1, click Idle Mode. Set CRH and ACS.

l In the dialog box shown in Figure 3-1, click Other Attributes, select Advanced andCommon Channel Control, and then set MS_TXPWR_MAX_CCH and Half ratesupported.

l 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 sameas that in System Information Type 1. For details, refer to Table 3-16.

System Information Type 4The Location Area Identification in System Information Type 4 is obtained from the Set CellAttributes dialog box.



3-21

For the Cell Selection Parameters, see Table 3-19. The RACH Control Parameters informationelement in System Information Type 4 is the same as that in System Information Type 1. Fordetails, see Table 3-16.

Table 3-20 lists the Rest Oct parameters in System Information Type 4 and the correspondingparameters on the BSC6000 Local Maintenance Terminal.

Table 3-20 Rest Oct parameters in System Information Type 4 and the corresponding parameterson the BSC6000 Local Maintenance Terminal

Rest Oct Parameters in SystemInformation Type 4


PI PI

CBQ Cell Bar Quality Cell_Bar_Qualify

CRO CRO (2dB)

TOTO

TO, TEMPORARY_OFFSET

PT PT (s)


l In the dialog box shown in Figure 3-1, click Idle Mode. Set PI, CBQ, and CRO (2 dB).

l In the dialog box shown in Figure 3-1, click Idle Mode, and then click Advanced. On theIdle Parameter tab page, set TO and PT.

Other System Informationl 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 CellBA1.To configure the parameters listed in the table on the BSC6000 Local MaintenanceTerminal, 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.l 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 inSystem Information Type 3. For details, see Table 3-18. The procedure for configuringNCC Permitted is the same as that for configuring NCC Permitted in System InformationType 2.




Issue 01 (2008-06-10)

l The Rest Oct in System Information Type 7 is the same as that in System Information Type4. For details, see Table 3-20.

l The Rest Oct in System Information Type 8 is the same as that in System Information Type4. For details, see Table 3-20.

l System Information Type 13 is not processed in the BSC and is directly forwarded to theBTS.



3-23

4 Immediate Assignment

About This Chapter

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 ProcedureThis 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 handlingsuggestions.

HUAWEI BSC6000 Base Station SubsystemBSS Signaling Analysis Guide 4 Immediate Assignment


4-1

4.1 Immediate Assignment ProcedureThis describes the immediate assignment procedure.

The purpose of immediate assignment is to establish a Radio Resource (RR) connection betweenan MS and the network on the Um interface. The immediate assignment procedure is initiatedby the MS. Figure 4-1 shows the immediate assignment procedure.

Figure 4-1 Immediate assignment procedure

Channel Request(1)

RACH

Channel Required(2)

Channel Activation(3)

MS BTS BSC

Channel Activation Acknowledge(4)

Immediate Assignment Command(5)

AGCH

Start T3101SABM(6)

main DCCH

UA(7)

main DCCHEstablish Indication(8)

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 Referenceparameters. It has eight bits. Bits 3 to 6 indicate the access cause, and bits 5 to 2 carry theidentifier. 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 Delayparameters. The Request Reference information element contains the random accessreference value and the absolute frame number of the received access burst. The AccessDelay is the delay of the access burst.

3. Upon receiving the Channel Required message, the BSC assigns a signaling channel andsends the BTS a Channel Activation message to activate the resources. The Channel

4 Immediate AssignmentHUAWEI BSC6000 Base Station Subsystem



Issue 01 (2008-06-10)

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, theBTS turns on the power amplifier on the specified channel to receive information in theuplink direction and sends the BSC a Channel Activation Acknowledge message. Themessage contains the absolute frame number so that the BSC can determine the StartingTime parameter.

5. 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 AssignmentExtend message so that the channel efficiency is enhanced. The Immediate AssignmentExtend message contains the assignment information about two MSs. The ImmediateAssignment Command message has the following information elements:l Dedicated mode or TBF

The Dedicated mode or TBF information element requests the MS to decode the rest ofthe message to an Immediate Assignment message or to allocate a Temporary BlockFlow.

l Page ModeThe Paging Mode information element controls the action of the MSs in a paging group.

l Channel DescriptionThe Channel Description information element describes the Channel Type, TDMAoffset, timeslot, and absolute RF channel number of an assigned channel and thecorresponding SACCH.

l Request ReferenceThe Request Reference information element contains the random access reference valueand the absolute frame number of the received access burst. The Access Delay is thedelay of the access burst.

l Time AdvanceThis Time Advance information element provides the initial timing advance value.

If the BSC has no available channels, it sends the MS an Immediate Assignment Rejectmessage 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, theMS is not permitted to access the network. In addition, the MS returns to the idle modeand waits on the paging channel. Before timer T3122 expires, the MS is not permittedto initiate new access attempts except emergency calls in the same cell.

l If the Immediate Assignment Reject message is received for the first time, the MS startstimer T3126. Timer T3126 starts when the number of Channel Request messages sentby the MS reaches the maximum value. When timer T3126 expires, the immediateassignment 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 toestablish 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 pointis the point at which the data link layer provides services to layer 3. SAPI 0 supports thetransfer of signaling, and SAPI 3 supports the transfer of short messages. In the GSMnetwork, an SABM frame carries the layer 3 service request message, which contains the



4-3

identity of the MS and indicates which service the MS is requesting. The layer 3 servicerequest messages are categorized into CM service requests, location update requests, IMSIdetach, and paging responses. All these messages contain the IMSI of the MS, detailedaccess cause, and MS classmarks.

NOTE

The main DCCH is the primary signaling channel and is generally the SDCCH, FACCH, andSACCH.

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 datalink layer. It confirms the SABM frame.When the Channel Request messages sent by two MSs have the same contents, the twoMSs may be assigned the same dedicated channel. Upon receiving the SABM frame, theBTS sends the MS a UA frame that contains the same information as the received SABMframe. 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 theSABM 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 inmulti-frame mode and contains parameters Link Identifier and L3 Information. The LinkIdentifier parameter identifies the signaling channel type and the message priority of SAPIand SAPI 0. L3 Information is a complete layer 3 message.

4.2 Internal BSC Signaling Procedure (ImmediateAssignment)

This describes the internal BSC signaling procedure of immediate assignment.

l Upon receiving the Channel Required message from the BTS, the BSC assigns a signalingchannel according to the specified channel type and channel algorithm.

l During random access, upon receiving the Establish Indication message from the BTS, theBSC sends the MSC a CM Service Request message that carries the target CGI based onthe MCC, MNC, LAC, and CI parameters in the Set Cell Attributes dialog box.

4.3 Abnormal Cases and Handling Suggestions (ImmediateAssignment)

This describes the abnormal cases of immediate assignment, probable causes, and handlingsuggestions.

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.




Issue 01 (2008-06-10)

4.3.1 Failure to Receive an Establish Indication Message AfterChannel 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 anEstablish 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 ChannelRequest message for many times and thus the BSS assigns and activates multiple signalingchannels.

2. Even when the BSS is functional, the MS may send several Channel Request messagesduring one RR connection attempt. The BSS activates multiple signaling channels, but theMS uses only one of them. The BSC cannot receive the Establish Indication messages fromthe MS through other channels and therefore releases the channels after timer T3101expires. If the number of slots for spread transmission (Tx-integer) is set properly, thereason may be that the BTS receives the uplink signals correctly but the MS cannot receivethe downlink signals. Meanwhile, as indicated in the signaling tracing on the Um interfaceon the MS side, the BSC does not receive a response message from the BTS after sendinga Channel Request message.

3. The Tx-integer and the CCCH are not set correctly. The settings of the Tx-integer and theCCCH affect the interval at which an MS resends the Channel Request messages.

Handling Suggestionsl For reason 1, ensure that the MS is functional. Make another attempt by using another MS.

l For reason 2, check that the receive level and receive quality on the uplink and downlinkare normal. If the MS is near the BTS, but the receive level is low and the receive qualityis poor, check that the antenna system, MS antenna, and MS battery are functional.

l For reason 3, check that the Tx-integer and the CCCH are set correctly.

4.3.2 BSC Sending an Immediate Assignment Reject Message (CaseStudy)


DescriptionUpon receiving the Channel Required message, the BSC sends the MS an Immediate AssignmentReject message.

AnalysisThe probable causes are as follows:



4-5

1. The BSC finds no suitable signaling channel, that is, a SDCCH or a TCH, to assign to theMS. This is because that the channels are busy or blocked.

2. Upon receiving a Channel Activation message, the BTS sends the BSC many ChannelActivation Negative Acknowledge messages.

Handling Suggestionsl 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 tothe BTS, modify the access threshold, and enable the directed retry.

l For reason 2, check whether the channel states on the BSC and the BTS are the same. Ifnot, you can infer that the transmission on the Abis interface is unstable. Check also theBTS boards.




Issue 01 (2008-06-10)

5 Classmark Update

About This Chapter

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.

5.1 Classmark Update ProcedureThis describes the classmark update procedure.

HUAWEI BSC6000 Base Station SubsystemBSS Signaling Analysis Guide 5 Classmark Update


5-1

5.1 Classmark Update ProcedureThis describes the classmark update procedure.

Figure 5-1 shows the classmark update procedure.

Figure 5-1 Classmark update procedure

System Information Type3

SDCCHComplete Layer 3 Inforamtion

MS BSS MSC

main DCCH

main DCCH

SDCCH

Classmark Change(1)

SDCCHClassmark Update(2)

Classmark Request(3)Classmark Enquiry(4)

Classmark Change(5)

Classmark Update(6)

UA

SABM


1. Upon receiving the Classmark Change message, the BSS sends the MSC a ClassmarkUpdate message. The Classmark Update message carries the classmark 2 and classmark 3information elements.

NOTEThe Classmark Update message is bi-directional.

2. When an MM connection is established between the MS and the MSC, the MSC initiatesa classmark update procedure by sending the BSS a Classmark Request message on anSCCP.

3. Upon receiving the Classmark Request message, the BSS:l Sends the MSC a Classmark Update message

l Sends the MS a Classmark Enquiry message

l Takes no action

4. Upon receiving the Classmark Enquiry message, the MS sends the BSS a ClassmarkChange message. The Classmark Change message has the same contents as the ClassmarkChange message described in 1.

5 Classmark UpdateHUAWEI BSC6000 Base Station Subsystem



Issue 01 (2008-06-10)

NOTE

If the Early Classmark Sending Control (ECSC) is allowed in System Information Type 3, an MS, forexample, a dual-band MS or a vehicle mounted MS, can automatically initiate a classmark updateprocedure. 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 classmark3 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.l 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.l Steps (3)-(6) in Figure 5-1 show the classmark update procedure initiated by the MSC.

HUAWEI BSC6000 Base Station SubsystemBSS Signaling Analysis Guide 5 Classmark Update


5-3

6 Location Update

About This Chapter

In the GSM system, MS location information is stored in the HLR, the VLR, and the MS. Whenthe MS location information is changed, a location update procedure is initiated to maintainconsistency among the previous three network elements.

6.1 Location Update ProcedureThe 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.

HUAWEI BSC6000 Base Station SubsystemBSS Signaling Analysis Guide 6 Location Update


6-1

6.1 Location Update ProcedureThe 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 ProcedureThis describes the periodic location update procedure and its functions.

6.1.2 IMSI Attach ProcedureThe IMSI attach procedure is the complement of the IMSI detach procedure. It is used to indicatethat the IMSI is active in the network.

6.1.3 Generic Location Update ProcedureThe generic location update procedure mainly consists of the following: network requestingadditional MS capability information, network requesting for identification, and authentication.

6.1.1 Periodic Location Update ProcedureThis describes the periodic location update procedure and its functions.

Periodic Location Update ProcedureThe 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 BTS MSCBSC

RACH

Immediate Assignment Procedure

ChannelRequest(1)

Establish Indication(Location Update Request)(2) CR(Complete

Layer3 Information)

CC(3)LocationUpdationg Accepted(4)

SDCCH

SDCCH

LocationUpdationg Rejected(5)

SDCCH

TMSIReallocation Complete(6)

Clear Command(7)

Clear Complete(7)

NOTE

If the location update request is rejected, the MSC returns a Location Updating Reject message.

6 Location UpdateHUAWEI BSC6000 Base Station Subsystem



Issue 01 (2008-06-10)


1. The Immediate Assignment Procedure is initiated. The BTS sends the BSC an EstablishIndication message, containing the Location Updating Request message.

2. The BSC establishes an SCCP connection on the A interface and sends the MSC a CompleteLayer3 Information message, containing the CGI of the current cell.

3. The MSC responds to the BSC with a Connection Confirm message.4. The MSC responds to the MS with a Location Updating Accepted message, indicating that

the location update is successful.5. If the network reject this location update, it sends a Location Updating Rejected message

to the MS.6. 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.7. 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 theRACH over the Um interface. The cause value carried in this message is location update.

Functions of Periodic Location UpdatePeriodic location update is used to periodically notify the network of the MS availability. Thelocation update type information element in the Location Updating Request message indicatesperiodic update.

The periodic location update procedure is controlled by timer T3212 in the MS. If the timer isnot started, it is started each time the MS enters the Normal Service or Attempting to Updatestate of the MM Idle state. When the MS leaves the MM Idle state, timer T3212 continues runninguntil it expires. The MM Idle state indicates that the MS is not activated, and does not processany call. For example, in the mobile originated or terminated call procedure, the MS leaves theMM Idle state.

Timer T3212 is stopped (and is reset to 0) when:

l A Location Updating Accept or Location Updating Reject message is received.

l An Authentication Reject message is received.

l The first MM message such as the Location Updating Accepted or the CM Service Acceptmessage is received, or ciphering mode setting is complete when the MM connection is setup, except when the most recent service state is Limited Service.

l The MS has responded to paging and has received the first correct layer 3 message exceptthe RR message.

l Timer T3212 expires.

l The MS is deactivated, that is, the MS is powered off or the SIM is removed.

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 thenext start.

l If the MS is in other states than MM Idle, the location update procedure is delayed untilthe MS enters the MM Idle state.



6-3

l If the MS is in the No Cell Available, Limited Service, PLMN Search, or PLMN Search-Normal Service state, the location update procedure is delayed until the MS leaves theservice state.

l If the system information indicates that periodic location update shall not be used, theprocedure is not started. The timeout value of timer T3212 is carried by the Control ChannelDescription 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 servingcell or the broadcast of the timeout value of timer T3212, the MS restarts the timer with the valuet 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 ProcedureThe IMSI attach procedure is the complement of the IMSI detach procedure. It is used to indicatethat the IMSI is active in the network.

The System Information Type 3 message carries an ATT flag that indicates whether the attachand detach procedures are required to be used.

If the IMSI attach and detach procedures are required by the network, the MS will trigger theIMSI attach procedure during IMSI activation. When the MS activates the IMSI within thenetwork coverage area or moves into the coverage area, the IMSI attach procedure is triggeredonly when the Update Status is Updated and the stored LAI is the same as that broadcast on theBCCH 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 updatetype information element in the Location Updating Request message must in this case indicateIMSI attach.

6.1.3 Generic Location Update ProcedureThe generic location update procedure mainly consists of the following: network requestingadditional MS capability information, network requesting for identification, and authentication.

The generic location update procedure is complicated. It contains the following: networkrequesting 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 alsocontains the location update reject. To limit the location update attempts, an attempt counter isrequired.

Network Requesting Additional MS Capability Information

The network may initiate a classmark interrogation procedure to obtain the MS capabilityinformation such as the encryption capability and the short message transmission and receptioncapability.




Issue 01 (2008-06-10)

Network Requesting for IdentificationThe network may initiate an identification request procedure if it cannot get the IMSI from theTMSI and LAI or it requires the IMEI.

AuthenticationThe authentication procedure may be initiated by the network upon receipt of the LocationUpdating Request message from the MS.

Ciphering Mode SettingThe ciphering mode setting procedure may be initiated by the network if a new TMSI has to beallocated.

Location Update RejectIf the location update is not accepted, the network sends a Location Updating Reject messageto the MS. The MS receiving a Location Updating Reject message stops timer T3210, stores thereject cause, starts timer T3240, enters state Location Updating Rejected, and awaits the releaseof the RR connection triggered by the network. It deletes the Equivalent PLMNs list when thereject cause is not #12, #14, or #15.

Upon the release of the RR connection, the MS takes the following actions depending on thestored reject cause:

l # 2 (IMSI Unknown in HLR)

l # 3 (Illegal MS)

l # 6 (Illegal ME)

If the reject value is #2, #3, or #6, the MS sets the update state to Roaming Not Allowed, deletesany TMSI, stored LAI, and ciphering key sequence number, and considers the SIM as invaliduntil it is switched off or the SIM is removed.

l # 11 (PLMN not Allowed)

l # 12 (Location Area not Allowed)

l # 13 (Roaming not Allowed in This Location Area)

l # 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 keysequence number stored in the SIM, resets the attempt counter, and sets the update state toRoaming Not Allowed. The MS stores the LAI and the PLMN ID in a suitable forbidden list.

l If the reject value is #11, the PLMN ID should be stored in the Forbidden PLMN List.

l If the reject value is #12, the LAI should be stored in the list of Forbidden Location Areasfor Regional Provision of Service.

l If the reject value is #13, the LAI should be stored in the list of Forbidden Location Areasfor Roaming. The MS performs a PLMN selection instead of a cell selection when it returnsto the MM Idle state.

l If the reject value is #15, the LAI should be stored in the list of Forbidden Location Areasfor Roaming. The MS searches for a suitable cell in another location area of the samePLMN.



6-5

Other reject values are considered as abnormal cases.

Release of the RR Connection After Location UpdateWhen the location update procedure is complete, the MS (except when it has a follow-onapplication request and has received the proceed indication from the network) sets timer T3240and 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 allowa mobile-initiated MM connection.

Any release of the RR connection is initiated by the network. If the RR connection is not releasedwhen timer T3240 expires, the MS terminates the RR connection. Then the MS enters the MMIdle state.

When the MS enters the Normal Service or Attempting to Update state, either timer T3212 ortimer T3211 is restarted.

Attempt CounterWhen a location update fails, an attempt counter is required. The counter counts the number ofconsecutive unsuccessful location update attempts and increases by 1 when a location updatefails.

The attempt counter is reset when:

l The MS is switched on.

l A SIM is inserted.

l A location update is complete.

l A location update with the cause value 11 (PLMN not Allowed), 12 (Location Area notAllowed), 13 (Roaming not Allowed in This Location Area), or 15 (No Suitable Cells inLocation Area) is complete.

l The service state changes from Attempting to Update.

l The MS enters a new location area.

l Timer T3212 expires.

l The location update is triggered by the CM sublayer requests.

The attempt counter is used to decide whether a location update needs to be initiated after timerT3211 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 BSCsends the MSC a Location Updating Request message that carries the target CGI based on theMCC, 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 selectingIdle Mode in the Set Cell Attributes dialog box. The periodic location update time is delivered to the MSthrough the System Information Type 3 message.




Issue 01 (2008-06-10)

6.3 Abnormal Cases and Handling Suggestions (LocationUpdate)

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 controlThe location update procedure is not started. The MS stays in the current serving cell andstarts the normal cell reselection procedure. The MS starts the location update procedureas soon as it gains access or at cell change.

l Receiving an Immediate Assignment Reject message during random access (in A/Gb modeonly)The location update procedure is not started. The MS stays in the selected serving cell andstarts 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.

l Random access failure (in A/Gb mode only)Timer T3213 is started when random access fails. When it expires, the procedure isattempted again if still necessary. If two successive random access attempts fail, the locationupdate procedure attempt is terminated.

l RR connection failureThe location update procedure is terminated.

l T3212 expiryThe location update and the RR connection are terminated.

l RR release before the normal end of procedureThe location update procedure is terminated.

l RR connection establishment failure (in Iu mode only)The location update procedure is terminated.



6-7

Handling SuggestionsBased on the cause values carried by the Location Updating Rejected message, you can alsorefer to the following suggestions:

l If the reject value is #2, #3, #6, #11, #12, or #13, check that the subscription informationin the HLR and the subscriber data in the VLR are correct.

l If the reject value is #15, check that the CGI and LAC are consistent on the MSC and BSCsides.

6.3.2 Location Update Failure on the Network Side (Case Study)This describes the fault, probable causes, and handling suggestions.

DescriptionLocation update fails, and the network sends a Location Updating Reject message.


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

– If an RR connection fails when a common procedure does not exist, the location updateprocedure for the MS is terminated.

l Location update not accepted by the networkIf the Location Updating Request message is received with a protocol error, the networkreturns 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 messagewith 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.

Handling SuggestionsIf the cause value is #17, refer to the following suggestions:

1. Check that CGI and LAC are correct on the MSC and BSC. Check that both the LAC andthe CI are decimal or hexadecimal.

2. Check that the MSC, VLR, and HLR are functional with normal communications.




Issue 01 (2008-06-10)

7 Authentication

About This Chapter

The purpose of authentication is to permit the network to check whether the identity providedby the MS is acceptable and to prevent the private information on the legal subscribers frombeing stolen.

7.1 Authentication PrinciplesThe authentication procedure is always initiated and controlled by the network.

7.2 Authentication ProcedureThis describes the authentication procedure.

7.3 Authentication RejectThis describes the authentication reject procedure.

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.

HUAWEI BSC6000 Base Station SubsystemBSS Signaling Analysis Guide 7 Authentication


7-1

7.1 Authentication PrinciplesThe authentication procedure is always initiated and controlled by the network.

The network initiates the authentication procedure in the following cases:

l The MS applies to change the subscriber information in the VLR or the HLR.

l Service access is initiated. For example, when the MS originates a call, is called, activated,or deactivated, or the supplementary service is initiated.

l The MS accesses the network for the first time after the MSC/VLR restarts.

l The ciphering key Kc on the network does not match that on the MS.

The authentication has two purposes:

l To permit the network to check whether the identity provided by the MS is acceptable

l 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. Whenregistering in a GSM network, each subscriber is assigned a Mobile Station International ISDNNumber (MSISDN) and an International Mobile Subscriber Identity (IMSI). The IMSI is writteninto the SIM through a SIM writer. The SIM writer also generates an authentication parameterKi, which is stored in the SIM and the authentication center as well. The IMSI and Ki arepermanent information.

A pseudo-random number generator is used in the authentication center to generate anunpredictable pseudo random number RAND. In the authentication center, the RAND and Kigenerate a signed response (SRES) through algorithm A3 and a ciphering key Kc throughalgorithm 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 atone time. The HLR automatically stores them. The HLR can store ten groups of AuthenticationTriplet. Upon request, the HLR sends five groups of Authentication Triplet to the MSC/VLR atone time. The MSC/VLR uses the Authentication Triplet one by one. When only two groups areleft, the MSC/VLR requests the HLR for the Authentication Triplet again.

7.2 Authentication ProcedureThis describes the authentication procedure.

Figure 7-1 shows the authentication procedure.

7 AuthenticationHUAWEI BSC6000 Base Station Subsystem



Issue 01 (2008-06-10)

Figure 7-1 Authentication procedure

MS BTS MSC

SDCCH

BSC

Authentication Request(1)

Start T3260

StopT3260

SDCCH

Authentication Response(2)


1. The network initiates an authentication procedure by sending an Authentication Requestmessage to the MS and starts timer T3260. The Authentication Request message carries a128-bit RAND that is used to calculate the response parameters. It also carries the CipheringKey Sequence Number (CKSN) assigned to the ciphering key.

2. Upon receiving the Authentication Request message, the MS calculates the SRES requiredby the Authentication Response message and the new ciphering key Kc. The SRES iscalculated based on the RAND and Ki through algorithm A3. After writing the newciphering key Kc and the CKSN in the SIM, the MS sends the network an AuthenticationResponse message.Upon receiving the Authentication Response message, the network stops timer T3260 andcompares the stored SRES with the SRES in the Authentication Response message. If theSRESs are the same, the authentication procedure is complete, and the successiveprocedures, for example, the ciphering procedure, start.

7.3 Authentication RejectThis describes the authentication reject procedure.

If authentication fails, that is, if the response is not valid, the network may distinguish betweenthe 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.l 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.



7-3

Figure 7-2 Unsuccessful authentication procedure

MS BTS MSC

SDCCH

BSC


SDCCH

Authentication Response(2)

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 DetachInitiated 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 T3220expiry. If not possible, for example, during IMSI detachment at MS power-down, the RRsublayer on the MS side is aborted.

l If the Authentication Reject message is received in any other state, the MS terminates anyMM connection establishment or call re-establishment procedure, stops all the timersT3210 or T3230, releases all the MM connections, starts timer T3240, and enters the WaitFor Network Command state, expecting the release of the RR connection. If the RRconnection 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 specialprocessing.

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.




Issue 01 (2008-06-10)

7.5.1 Authentication Failure Caused by RR Connection Failure(Case Study)


DescriptionThe authentication procedure fails, and the network releases all the MM connections.

AnalysisUpon detecting an RR connection failure before an Authentication Response message isreceived, the network releases all the MM connections (if any) and terminates any ongoing MM-specific procedure.

Handling SuggestionsCheck that the quality of radio signals on the Um interface is proper.

7.5.2 Authentication Failure Caused by Timer T3260 Expiry (CaseStudy)


DescriptionThe authentication procedure fails.

AnalysisIf timer T3260 expires before an Authentication Response message is received, the networkreleases the RR connection and all the MM connections, terminates the authentication procedureand all the ongoing MM connections (if any), and starts the RR connection release procedure.

Handling SuggestionsCheck that the length of timer T3260 is proper.

7.5.3 Authentication Failure Caused by SIM Unregistered (CaseStudy)


DescriptionThe network directly responds to the MS with an Authentication Reject message.

AnalysisIf the SIM of an MS is not registered in the network, the network returns an AuthenticationReject message to the MS.



7-5

Handling SuggestionsRegister the SIM correctly.




Issue 01 (2008-06-10)

8 Ciphering

About This Chapter

Ciphering is used to secure the information exchange between an MS and a BTS. The informationconsists of the signaling information and the subscriber information. The subscriber informationconsists of the subscriber data and the subscriber voice.

8.1 Ciphering ProcedureThis describes the ciphering procedure.

8.2 Ciphering Mode ChangeThis describe the ciphering mode change procedure.

8.3 Internal BSC Signaling Procedure (Ciphering)This describes the internal BSC signaling procedure of ciphering.

8.4 Abnormal Cases and Handling Suggestions (Ciphering)This describes the abnormal cases of ciphering, probable causes, and handling suggestions.

HUAWEI BSC6000 Base Station SubsystemBSS Signaling Analysis Guide 8 Ciphering


8-1

8.1 Ciphering ProcedureThis describes the ciphering procedure.

Whether ciphering is used is determined by the radio resource management entity. The cipheringprocedure is initiated by the network and is performed in the BTS. To cipher the user data, youmust enter the corresponding parameters in the ciphering program. The ciphering key Kc isgenerated 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 MSC

SDCCH

BSC

Ciphering Mode Command(1)Encryption

Mode Command(2)

SDCCH

Ciphering Mode Command(3)

Ciphering Mode Complete(4)

Ciphering Mode Complete(5)


1. The MSC sends the BSC a Ciphering Mode Command message. The Ciphering ModeCommand message carries the required ciphering algorithms including A5/0, the cipheringkey Kc, and whether the Ciphering Mode Complete message sent by the MS must carrythe IMEI.

2. According to the ciphering algorithm in the Ciphering Mode Command message, theciphering 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.

3. The BTS sends the Ciphering Mode Command message to notify the MS of the cipheringalgorithm.

4. Upon receiving the Ciphering Mode Command message, the MS starts sending theciphering mode and then responds the BSC with a Cipher Mode Complete message.

5. Upon receiving the Ciphering Mode Complete message from the MS, the BSC notifies theMSC of the ciphering completion.

The description of ciphering is as follows:l A5 ciphering algorithm

As specified in the GSM protocol, there are eight ciphering algorithms, A5/0–A5/7, inwhich A5/0 indicates Not Ciphered. The ciphering mode setting procedure is initiated bythe network. The required ciphering algorithm is specified in the Ciphering Informationelement of the Ciphering Mode Command message.

8 CipheringHUAWEI BSC6000 Base Station Subsystem



Issue 01 (2008-06-10)

l Ciphering algorithm selectionWhen an MS initiates a call, it sends a CM Service Request message that carries classmark2 and classmark 3, which contains the ciphering algorithm supported by the MS. The MSCsends a Ciphering Mode Command message based on the ciphering data configurations.According to the ciphering algorithm in the Ciphering Mode Command message, theciphering algorithm allowed by the BSC, and the ciphering algorithm in the CM ServiceRequest message, the BSC determines the algorithm to be used. In a reverse order, the BSCselects an applicable algorithm from the intersection of the early-mentioned threealgorithms. The priority of the algorithms is A5/7 > A5/6 > A5/5 > A5/4 > A5/4 > A5/3 >A5/2 > A5/1 > A5/0.

NOTEWhen the ECSC is set to 1, classmark 3 is carried in the CM Service Request message. When theECSC is set to 0, classmark 3 can only be carried in the CM Service Request message throughclassmark change or update. Therefore, set the ECSC to 1 when ciphering is used.

l Ciphering during handoverThe Handover Request message carries an Ciphering Information element. The CipheringInformation element specifies the required ciphering algorithm and the ciphering key. Ifone of the two A interfaces of the two BSSs is in PHASE I, because of the defects in theETSI GSM PHASE I protocol (no ciphering mode setting information unit is included inthe Handover Command message), the two BSSs interoperate only when they use the sameciphering algorithm such as A5/0 or A5/2. Otherwise, special processing (modifying theinter-BSC handover command) is required in the target MSC or the target BSC (or theserving MSC or the serving BSC).During the interconnection on the A interface in ciphering mode, to avoid unsuccessfulhandovers, you must know whether additional data configuration is required on the BSCsand MSCs from different manufacturers.

8.2 Ciphering Mode ChangeThis describe the ciphering mode change procedure.

The BTS performs and manages ciphering. The BSC does no processing. When the cipheringmode changes, the MSC sends a Ciphering Mode Change command and the BTS changes theciphering mode.

The ciphering mode change procedure is as follows:

1. The BTS performs the sending configuration in old mode and the receiving configurationin new mode.

2. The MS is configured in a completely new mode, including transmission and reception.3. 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 checksthe classmarks of the MS and the settings of the Ciphering Algorithm in the Set CellAttributes dialog box.



8-3

2. According to the ciphering algorithm in the Ciphering Mode Command message, theciphering algorithm allowed by the BSC, and the ciphering algorithm in the CM ServiceRequest message, the BSC determines the algorithm to be used.

3. In a reverse order, the BSC selects an applicable algorithm from the intersection of theearly-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 inthe Cipher Mode Command message that is sent to the BTS.

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 ModeReject Message (Case Study)


DescriptionThe BSS sends the MSC a Cipher Mode Reject message.


1. The BSS does not support the ciphering algorithm specified in the Ciphering ModeCommand message. It sends the MSC a Cipher Mode Reject message with the cause valueCiphering Algorithm Not Supported.

2. If the BSS has initiated ciphering before the MSC requires changing the cipheringalgorithm, the BSS sends the MSC a Cipher Mode Reject message.

Handling Suggestionsl For reason 1, check that the BSS supports the ciphering algorithm specified in the Ciphering

Mode Command message.l For reason 2, check that the BSS has initiated ciphering.

8.4.2 Ciphering Failure Caused by MS Doing No Processing (CaseStudy)


DescriptionUpon receiving the Ciphering Mode Command message, the MS does no processing.

8 CipheringHUAWEI BSC6000 Base Station Subsystem



Issue 01 (2008-06-10)

AnalysisThe Ciphering Mode Command message is considered as valid when:

l It carries an Algorithm Identifier and is received by the MS in No Ciphering mode.

l It carries No Algorithm Identifier and is received by the MS in No Ciphering mode.

l 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. Forexample, if the MS in Ciphering mode receives the Ciphering Mode Command message, theMS sends an RR Status message with the cause value Protocol Error and does not take any otheractions.

Handling SuggestionsConfirm the mode which the MS is in and check that the contents in the Ciphering ModeCommand message are correct.



8-5

9 TMSI Reallocation

About This Chapter

The TMSI reallocation takes place in ciphering mode. It is generally related to another procedure,such as location update or call establishment.

9.1 TMSI Reallocation ProcedureThis describes the TMSI reallocation procedure.

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

HUAWEI BSC6000 Base Station SubsystemBSS Signaling Analysis Guide 9 TMSI Reallocation


9-1

9.1 TMSI Reallocation ProcedureThis describes the TMSI reallocation procedure.

The purpose of the TMSI reallocation procedure is to provide identity confidentiality, that is, toprotect a user from being identified and located by an intruder. Generally, the TMSI reallocationis performed at each change of a location area. It can be initiated at any time by the network ifan RR connection exists between the network and an MS. Figure 9-1 shows the TMSIreallocation procedure.

Figure 9-1 TMSI reallocation procedure

MS BTS MSC

SDCCH

BSC

TMSIReallocation Command(1)

Start T3250

StopT3250

SDCCH

TMSIReallocation Complete(2)


1. The network initiates the TMSI reallocation procedure by sending a TMSI ReallocationCommand message to the MS and starts timer T3250. The TMSI Reallocation Commandmessage carries a TMSI and LAI newly allocated by the network or an LAI and the IMSIif the used TMSI is deleted. Usually, the TMSI Reallocation Command message is sent tothe MS using an RR connection in ciphering mode.

2. Upon receiving the TMSI Reallocation Command message, the MS stores the LAI in theSIM. If the received identity is the IMSI of the relevant MS, the MS deletes any TMSI. Ifthe received identity is a TMSI, the MS stores the TMSI in the SIM. In both cases, the MSsends a TMSI Reallocation Complete message to the network.

3. 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 issent to the MS, the network considers the old TMSI as deleted.

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

9 TMSI ReallocationHUAWEI BSC6000 Base Station Subsystem



Issue 01 (2008-06-10)

9.3 Abnormal Cases and Handling Suggestions (TMSIReallocation)

This describes the abnormal cases of TMSI reallocation, probable causes, and handlingsuggestions.

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 theNetwork Side (Case Study)


DescriptionThe TMSI is reallocated due to RR connection failure on the network side.

AnalysisIf the RR connection fails before the network receives the TMSI Reallocation Completemessage, all MM connections are released and both the old and the new TMSIs are consideredas 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, theTMSI reallocation is restarted.

l 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 oldTMSI.

Handling SuggestionsNo handling is required.

9.3.2 TMSI Reallocation Caused by T3250 Expiry (Case Study)This describes the fault, probable causes, and handling suggestions.

DescriptionThe network releases the RR connection.

AnalysisThe TMSI reallocation is supervised by the timer T3250 in the network. At the first expiry oftimer T3250, the network releases the RR connection. In this case, the network suspends the

HUAWEI BSC6000 Base Station SubsystemBSS Signaling Analysis Guide 9 TMSI Reallocation


9-3

reallocation procedure, releases all MM connections, and follows the rules for RR connectionfailure.

Handling SuggestionsNo handling is required on the BSC side.

9 TMSI ReallocationHUAWEI BSC6000 Base Station Subsystem



Issue 01 (2008-06-10)

10 Speech Channel Assignment

About This Chapter

The speech channel assignment is the procedure for assigning TCHs to the MS according to theservice requests.

10.1 Speech Channel Assignment ProcedureThis describes the speech channel assignment procedure.

10.2 Channel Mode Modification ProcedureThis 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 handlingsuggestions.

HUAWEI BSC6000 Base Station SubsystemBSS Signaling Analysis Guide 10 Speech Channel Assignment


10-1

10.1 Speech Channel Assignment ProcedureThis describes the speech channel assignment procedure.

Figure 10-1 shows the speech channel assignment procedure.

Figure 10-1 Speech channel assignment procedure


Channel ActivationAcknowledge(3)

MS BTS MSC

Assignment Command(4)

Start T10

SABM(5)

main DCCH

UA(6)

FACCH Establishment Indication(7)

BSC

AssignmentRequest(1)

Start T3107

FACCH

AssignmentComplete(8)

FACCHStop T3107


Stop T10


1. Based on the service request, the MSC requests radio resources from the BSS through SCCPconnection, 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 / dataindicator" 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 relatedphysical channels. The remaining bytes indicate speech versions 1–5.

l The Priority parameter indicates different priority levels and whether queuing and pre-emption are performed.

10 Speech Channel AssignmentHUAWEI BSC6000 Base Station Subsystem



Issue 01 (2008-06-10)

l The Circuit Identity Code parameter is used for the physical connection between theBSC and the MSC.

l The Downlink DTX Flag parameter indicates whether discontinuous transmission isallowed.

2. For details about the Channel Activation message, refer to 4 Immediate Assignment.3. For details about the Channel Activation Acknowledge message, refer to 4 Immediate

Assignment.4. Upon receiving the Channel Activation Acknowledge message, the BSC sends the MS an

Assignment Command message on the SDCCH and starts timer T3107. The AssignmentCommand message carries the Channel Description, Power Command, and Channel Mode.For details about these parameters, refer to the Immediate Assignment Procedure.

5. Upon receiving the Assignment Command message from the BTS, the MS adjusts thesignaling to the TCH and sends the SABM frame on the FACCH. The SABM frame is thefirst frame during the setup of multi-frame verification mode and does not carry layer 3messages.

6. Upon receiving the SABM frame, the BTS responds to the MS with a UA frame on theFACCH. The UA frame does not carry layer 3 messages.

7. Then the BTS sends the BSC an Establishment Indication message. The EstablishmentIndication message does not carry layer 3 messages. The system responds with a UAAcknowledgement frame.

8. Upon receiving the UA frame, the MS sends an Assignment Complete message on theFACCH to notify the BSC of the channel assignment completion. Upon receiving themessage, the BSC stops timer T3107.

9. The BSC sends an Assignment Complete message to the MSC. Upon receiving themessage, the MSC stops timer T10.The Assignment Complete message carries the Chosen Channel, Circuit Pool, and Speechversion parameters. The meanings of the parameters are as follows:l Chosen Channel

Inidicates the type of the assigned channell Circuit Pool

Indicates the circuit pool informationl Speech Version

Indicates the speech coding algorithm

10.2 Channel Mode Modification ProcedureThis describes the channel mode modification procedure.

Figure 10-2 shows the channel mode modification procedure.



10-3

Figure 10-2 Channel mode modification procedure

MS BTS MSCBSC


Start T10

main DCCH

Mode Modify(2)

Mode ModifyAcknowledge(3)

ChannelMode Modify(4)

Channel ModeModify Acknowledge(5)

main DCCHAssignment

Commplete(6)

StopT10


1. For details about the Assignment Request message, refer to 10.1 Speech ChannelAssignment Procedure.

2. Upon receiving the Assignment Request message, the BSC sends the BTS a Mode Modifymessage. The Mode Modify message carries the Channel Mode parameter.

3. If the channel mode is changed, the BTS sends the BSC a Mode Modify Acknowledgemessage to the BSC. If the channel mode cannot be changed, the BTS sends the BSC aMode Modify Negative Acknowledge message.

4. Upon receiving the Mode Modify Acknowlege message, the BSC sends the MS a ChannelMode Modify message. The Channel Mode Modify message carries the information on thechannel to be changed and the mode of channel after change.

5. If the channel mode is changed, the MS sends the BSC a Channel Mode ModifyAcknowledge message. If the MS does not support the specified mode, it stays in theoriginal mode. The Channel Mode Modify Acknowledge message carries the modeinformation.

6. For details about the Assignment Complete message, refer to 10.1 Speech ChannelAssignment Procedure.

10.3 Internal BSC Signaling Procedure (Speech ChannelAssignment)

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 channeltype. In the Set Cell Attributes dialog box, choose Other Attributes > Advanced >




Issue 01 (2008-06-10)

Other Parameters. Check whether the Data Service Allowed is enabled. If not, the BSCresponds with an Assignment Failure message.

2. When different transmission types are used on the A interface, the contents of theAssignment Request message sent by the MSC are different and the BSC handles indifferent 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 theexistence of CIC. It also checks whether the circuit pool of the configured CIC, thechannel type in the Assignment Request message, and the support capability of the boardcollide. If they collide, the BSC responds with an Assignment Failure message.

l When IP transmission is used on the A interface, the Assignment Request message sentby the MSC contains the following information elements: Transport Layer Address andSpeech SDP Information list. Based on the Assignment Request message, the BSCchecks whether the IP address of the A interface, the port number, and the supportcapability of the board meet the requirements. If not, the BSC responds with anAssignment Failure message.

NOTE

Transport Layer Address carries the IP address and port number of the A interface. Speech SDPInformation 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 messagewith the A Interface Tag and sends the message to the MSC. You can choose BSCProperty > Basic Data to display the A Interface Tag.

10.4 Abnormal Cases and Handling Suggestions (SpeechChannel Assignment)

This describes the abnormal cases of speech channel assignment, probable causes, and handlingsuggestions.

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)This describes the fault, probable causes, and handling suggestions.

DescriptionUpon receiving the Assignment Request message, the BSC responds with an Assignment Failuremessage.




10-5

1. Radio Interface Message FailureThe MS fails to access the speech channel. It sends an Assignment Failure message on thesignaling channel. Due to the particularity of the transmission on the Um interface, thiscase happens the most frequently and cannot be solved.

2. Equipment FailureThe BSC hardware is faulty.

3. No Radio Resource AvailableThe BSC has no appropriate speech channels for assignment. The possible reason is thatall the speech channels are busy or that the speech channels are blocked.

4. Requested Terrestrial Resource Unavailable5. Requested Transcoding/Rate Adaption Unavailable6. Terrestrial Resource Already Allocated7. Invalid Message Contents8. Radio Interface Failure Reversion To Old Channel9. Requested Speech Version Unavailable10. Timer T3107 expiry

Handling SuggestionsThe respective handling suggestions are as follows:

l For reason 1, check the access-related parameters of the antenna system, BTS boards, andBSC data configuration.

l For reason 2, check the following:– Communication between modules and subracks in the BSC

– Communication on the A interface, for example, the cable connections betweenGEIUAs and subracks

l For reason 3, add TRXs to the BTS, modify the access threshold, and enable the directedretry.

l For reason 4, check that the A interface data configurations on the MSC and BSC sides arecorrect and consistent.

l For reason 5, check the transmission on the A interface.

l For reason 6, check whether the configurations of A interface terrestrial circuits on the BSCand MSC sides are consistent. If not, reset the terrestrial circuits through the BSC6000Local Maintenance Terminal.

l For reason 7, check that the message complies with the protocols.

l For reason 8, check the signal quality on the Um interface, for example, the receive signallevel on the Um interface.

l For reason 9, check that the BSC supports the requested speech version.

l For reason 10, check that the length of timer T3107 is proper.

10.4.2 BSC Receiving a Connection Failure Indication Message(Case Study)





Issue 01 (2008-06-10)

Description

During the assignment procedure, the BSC receives a Connection Failure Indication message.


l Radio link failure

l Hardware failure

Handling Suggestions

The handling suggestions are as follows:

l Check the resources on the Um interface.

l Check the following items:

– Communication between subracks

– Communication on the A interface, for example, the cable connections betweenGEIUBs and subracks

10.4.3 BSC Receiving an Error Indication Message (Case Study)This describes the fault, probable causes, and handling suggestions.

Description

During the assignment procedure, the BSC receives an Error Indication message.

Analysis


l Inconformity with protocols

l Link layer failure

l Timer T200 expiry

l MS failure in receiving a UA frame



l Check that the contents of the frames at the data link layer are correct.

l Check the status of the data link layer.

l Check that the settings of timer T200 are correct.

l Check that the contents of the SABM frame are correct.



10-7

11 Mobile Originated Call

About This Chapter

Mobile originated call refers to a call procedure in which an MS calls another MS or a fixedphone.

11.1 Mobile Originated Call Establishment ProcedureIn terms of the assignment type, the mobile originated call establishment procedure iscategorized into the early assignment procedure, late assignment procedure, and very earlyassignment procedure. The MSC determines the early assignment procedure and the lateassignment procedure. The BSS determines the very early assignment procedure based on theradio 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, andhandling suggestions.

HUAWEI BSC6000 Base Station SubsystemBSS Signaling Analysis Guide 11 Mobile Originated Call


11-1

11.1 Mobile Originated Call Establishment ProcedureIn terms of the assignment type, the mobile originated call establishment procedure iscategorized into the early assignment procedure, late assignment procedure, and very earlyassignment procedure. The MSC determines the early assignment procedure and the lateassignment procedure. The BSS determines the very early assignment procedure based on theradio resources.

11.1.1 Early Assignment ProcedureThis describes the early assignment procedure, namely the mobile originated call establishmentwithout OACSU procedure.

11.1.2 Late Assignment ProcedureThis describes the late assignment procedure, namely the mobile originated call establishmentwith OACSU procedure.

11.1.3 Very Early Assignment ProcedureThis describes the very early assignment procedure, namely the Mobile Originated CallEstablishment with OACSU procedure.

11.1.1 Early Assignment ProcedureThis describes the early assignment procedure, namely the mobile originated call establishmentwithout OACSU procedure.

Figure 11-1 shows the early assignment procedure.

11 Mobile Originated CallHUAWEI BSC6000 Base Station Subsystem



Issue 01 (2008-06-10)

Figure 11-1 Early assignment procedure

MS BTS MSC

Setup(5)

BSC

FACCH

SDCCH


Establish Indication(CM Service Request)(1)

CC(3)

CR(L3:CMService Request)(2)

CM Service Accepted(4)

Call Proceeding(6)SDCCH

TCH Assignment Procedure

FACCH

Alerting(7)

FACCH

Connect(8)

Connect Acknowledge(9)SDCCH

Talking(10)

Release Procedure


1. The BTS sends the BSC an Establishment Indication message. The EstablishmentIndication 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.

2. The BSC establishes an SCCP link connection on the A interface and sends the MSC a CMService Request message.

3. The MSC sends the BSC a Connect Confirm message.4. The MSC sends the MS a CM Service Accepted message on the SDCCH on the Um

interface.



11-3

5. The calling MS sends a Setup message on the SDCCH. The Setup message carries all theinformation required on the network side for processing the call, including the number ofthe called MS.

6. The MSC sends the calling MS a Call Proceeding message on the SDCCH on the Uminterface. The Call Proceeding message indicates that a call is being processed and themobile originated call processing procedure is initiated.

7. The MSC sends the MS an Alerting message on the FACCH on the Um interface. Thenthe calling MS hears a ringing tone.

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

9. The calling MS responds to the MSC with a Connect Acknowledge message on theFACCH.

10. The calling and the called MSs enter the session state.

11.1.2 Late Assignment ProcedureThis describes the late assignment procedure, namely the mobile originated call establishmentwith OACSU procedure.

Figure 11-2 shows the late assignment procedure.




Issue 01 (2008-06-10)

Figure 11-2 Late assignment procedure

MS BTS MSC

Setup(5)

BSC

SDCCH

SDCCH



CC(3)



Call Proceeding(6)SDCCH


SDCCHAlerting(7)

FACCH

Connect(8)

Connect Acknowledge(9)SDCCH

Talking(10)

Release Procedure

For details of each message shown in Figure 11-2, refer to 11.1.1 Early AssignmentProcedure.

1. The difference between Figure 11-2 and the flowchart in 11.1.1 Early AssignmentProcedure is that the assignment procedure of the former takes place after the Alertingmessage is sent.

2. The late assignment saves the seizure time of speech channels.3. 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 makecalls.In actual application, the early assignment procedure is used instead of the late assignmentprocedure.



11-5

11.1.3 Very Early Assignment ProcedureThis describes the very early assignment procedure, namely the Mobile Originated CallEstablishment with OACSU procedure.

Figure 11-3 shows the very early assignment procedure.

Figure 11-3 Very early assignment procedure

MS BTS MSC

Setup(5)

BSC

FACCH

FACCH

Immediate Assignment TCH Procedure


CC(3)



Call Proceeding(6)FACCH

TCH Mode Modify

FACCHAlerting(7)

FACCH

Connect(8)

Connect Acknowledge(9)FACCH

Talking(10)

Release Procedure

For details of each message shown in Figure 11-3, refer to 11.1.1 Early AssignmentProcedure.

1. The difference between the very early assignment procedure and the 11.1.1 EarlyAssignment Procedure is that in the former, the TCH is assigned as a signaling channelduring the immediate assignment procedure. Therefore, no TCH needs to be assignedduring the assignment procedure, and the assigned TCH is adjusted to a speech channelthrough the Mode Modify message.




Issue 01 (2008-06-10)

2. During the immediate assignment procedure, if no idle SDCCHs but TCHs are availableand TCH immediate assignment is allowed in the BSC data configuration, the very earlyassignment procedure will take place.

11.2 Internal BSC Signaling Procedure (Mobile OriginatedCall)

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 signalingchannel according to the channel type and channel assignment algorithm in the ChannelRequired message. The TCH Immediate Assignment Allowed in the Set CellAttributes dialog box may be involved in the channel assignment.

2. During random access, on receiving the Establish Indication message from the BTS, theBSC sends the MSC a CM Service Request message that carries the target CGI based onthe MCC, MNC, LAC, and CI parameters in the Set Cell Attributes dialog box.

3. On receiving the Assignment Request message from the MSC, the BSC checks the channeltype. In the Set Cell Attributes dialog box, choose Other Attributes > Advanced >Other Parameters. Check whether Data Service Allowed is supported.

4. If the data service is not supported, an Assignment Failure message is returned. Based onthe CIC in the Assignment Request message, the BSC checks the E1 timeslots on the Ainterface and confirms the existence of CIC. It also checks whether the circuit pool of theconfigured CIC, the channel type in the Assignment Request message, and the capacity ofthe GDPUC collide. If they collide, the BSC responds to the MSC with an AssignmentFailure message.

5. On receiving the Assignment Complete message from the MS, the BSC fills the messagewith the A Interface Tag and sends the message to the MSC. You can choose BSCProperty > Basic Data to display the A Interface Tag.

11.3 Abnormal Cases and Handling Suggestions (MobileOriginated Call)

This describes the abnormal cases of mobile originated call establishment, probable causes, andhandling 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 (CaseStudy)This describes the fault, probable causes, and handling suggestions.

11.3.5 Abnormal Cases Caused by MS Hangup (Case Study)



11-7


11.3.6 Abnormal Cases Caused by MSC Sending a Clear Command Message or a DisconnectMessage (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)This describes the fault, probable causes, and handling suggestions.

DescriptionWhen late assignment is enabled, the called MS cannot hear the calling MS.

AnalysisTCH assignment fails.

Handling SuggestionsDisable the late assignment.

11.3.2 MSC Releasing the Call After Sending a CM Service RejectMessage (Case Study)


DescriptionAfter sending a CM Service Reject message, the MSC sends a Clear Command message torelease the call.


l The MSC cannot find the subscriber information and considers that the subscriber is illegal.

l Authentication or encryption fails.

l The MSC does not support the applied service in the CM Service Request message.

l The MSC does not have sufficient resources to perform access.

Handling SuggestionsThe handling suggestions are as follows:

l The MS makes a subscription under the MSC.

l Check the subscriber information.

l Hand over the MS to a cell under another MSC.




Issue 01 (2008-06-10)

l Wait for the MSC to release the resources, or expand the MSC transmission capability onthe 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 withthe cause value User Busy. The onhook by the calling MS or a Clear Command message sentby 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 anAssignment Request Message (Case Study)


Description

The MSC does not send an Assignment Request message. It sends a Disconnect message to clearthe call.

Analysis

The A interface may be faulty.


Check the following:

l The state of the A interface circuit on the MSC side

l The consistency of the A interface data on the MSC and the BSC, especially the circuitpool data

11.3.5 Abnormal Cases Caused by MS Hangup (Case Study)This describes the fault, probable causes, and handling suggestions.

Description

The call establishment procedure is terminated.



11-9

Analysisl The MS hangs up.

l The calling or the called MS hangs up during a procedure, which causes abnormality in thesubsequent procedures. For example, after the BSC receives an Assignment Requestmessage from the MSC, the MS suddenly hangs up. In that case, the call establishmentprocedure may be terminated before the BSC responds to the MSC with an AssignmentComplete message or an Assignment Failure message. As a result, the procedure is neithera successful assignment procedure (The BSC sends an Assignment Complete message.)nor an unsuccessful assignment procedure (The BSC sends an Assignment Failuremessage.).


No handling is required.

11.3.6 Abnormal Cases Caused by MSC Sending a Clear CommandMessage 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 CallControl. Otherwise, the cause value may be Protocol Error or Equipment Failure.

l The time difference between the previous message and the Clear Command message or theDisconnect message

Check whether the abnormal procedure is triggered by timeout.

Handling Suggestionsl – 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 relatedprotocols.

– If the cause value in the Clear Command message is Equipment Failure, check therelated BSC hardware:

– Inter-subrack communication (connection on the Ater interface, if the Ater interfaceexists)

– A interface board on the BSC side

l Based on different messages and different time differences, check that the settings of therelated timers are correct.




Issue 01 (2008-06-10)

11.3.7 LAPD Reporting an Error Indication Message During CallEstablishment (Case Study)


DescriptionThe LAPD reports an Error Indication message during call establishment.


l Inconformity with protocols

l LAPD link failure

l Timer T200 expiry

l MS failure in receiving a UA frame


l Check that the contents of the frames at the data link layer are correct.

l Check the status of the data link layer.

l Check that the settings of timer T200 are correct.

l Check that the contents of the SABM frame are correct.



11-11

12 Mobile Terminated Call

About This Chapter

Mobile terminated call refers to a call procedure in which an MS is called by another MS or afixed phone.

12.1 Mobile Terminated Call Establishment ProcedureThis describes the mobile terminated call establishment procedure. For details, refer to GSMRec. 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, andhandling suggestions.

HUAWEI BSC6000 Base Station SubsystemBSS Signaling Analysis Guide 12 Mobile Terminated Call


12-1

12.1 Mobile Terminated Call Establishment ProcedureThis describes the mobile terminated call establishment procedure. For details, refer to GSMRec. 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 MSC

Setup(9)

BSC

PCH


Paging(1)


Alerting(11)

Call Confirmmed(10)

FACCH

Talking(14)

Release Procedure

Paging Command(2)Paging Request(3)

Channel Request(4)

Establish Indication(Paging Response)(5)

RACH

CR(CL31)(6)

CC(7)

CM Service Accepted(8)SDCCH

SDCCH

SDCCH

Connect(12)

FACCH ConnectAcknowledge(13)

FACCH


1. When the paged MS is in the service area of the MSC, the MSC sends the BSC a Pagingmessage, which carries a list of paging cells (optional), TMSI, and IMSI.

12 Mobile Terminated CallHUAWEI BSC6000 Base Station Subsystem



Issue 01 (2008-06-10)

NOTEThe Paging message can be sent to the BSC from the MSC directly. Alternatively, it can be sent tothe SGSN first, and then to the PCU over the Gb interface, and finally to the BSC over the Pb interface.

2. The BSC sends the BTS a Paging Command message that carries the number of theoccupied timeslot and the number of the paging sub-channel.

3. Upon receiving the Paging Command message from the BSC, the BTS sends the pagedMS a Paging Request message on the paging sub-channel. The Paging Request messagecarries the IMSI or TMSI of the paged MS.

4. After decoding the Paging message, if the MS finds itself the paged MS, it sends the BTSa Channel Request message to trigger an Initial Channel Assignment procedure.

5. For details about other messages, refer to 11.1 Mobile Originated Call EstablishmentProcedure.

12.2 Internal BSC Signaling Procedure (Mobile TerminatedCall)

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 inthe BM subrack that is configured with SS7. Based on the CGI in the Paging message, theservice module checks the information on the paged cell. If the paged cell is in the BMsubrack where the service module is located, the service module directly sends the Pagingmessage to the cell. If the paged cell is in another BM subrack, the service module forwardsthe Paging message to the service module in that BM subrack.

2. The service module in the BM subrack first checks whether the Allow eMLPP is set toYes in Call Control of > Set Cell Attributes. Then the service module determines thepaging packet based on the BS_AG_BLKS_RES, CCCH_CONF, andBS_PA_MFRAMES in Idle Mode of > Set Cell Attributes. After that, it sends the Pagingmessage to the BTS.

12.3 Abnormal Cases and Handling Suggestions (MobileTerminated Call)

This describes the abnormal cases of mobile terminated call establishment, probable causes, andhandling 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

12.3.1 No Paging Command on the A Interface (Case Study)This describes the fault, probable causes, and handling suggestions.

Description

The MSC does not send a Paging message to the BSC, as indicated in the signaling tracing onthe 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. Poweroff 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 thesubscriber data in the VLR. The subscriber data includes the the active state, registeredlocation area, and registered cells. Then, the MSC determines whether to and how to senda Paging message.

If the state of the MS changes, for example, the MS is switched off or moves to anotherlocation area, but it has not registered in the network and thus the subscriber data in theVLR is not updated, the paging fails.

In this case, the MS needs to originate a location update procedure to ensure that thesubscriber 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 locationupdate within the period specified by the MSC, so the location update period on the BSCside must be shorter than that on the MSC side.

l 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 tounsuccessful transmission of the Paging message. For example, if the target BSC isincorrectly selected, the Paging message may be sent to a wrong BSC.

12.3.2 No Paging Command on the Abis Interface (Case Study)This describes the fault, probable causes, and handling suggestions.

Description

Upon receiving the Paging message from the MSC, the BSC does not send a Paging Commandmessage to the BTS, as indicated in the message tracing on the Abis interface.

Analysis

The fault lies in the BSC side.




Issue 01 (2008-06-10)

Handling Suggestionsl Check whether the flow control procedure is triggered.

– Check whether the PCH or AGCH is overloaded due to a sharp increase in shortmessages or a burst of access requests.You can verify the change by comparing the values of the counters ImmediateAssignment Requests and MSC Paging Requests (Circuit Service) before and afterthe problem occurs.

– Choose BSC Property > Flow Control Data. Check that the flow control parametersare consistent with those described in the Version Matching Guide.

l Check the data correctness.– 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 datais correct. Incorrect parameter configuration of location areas and cells on the MSC sidemay lead to unsuccessful transmission of the Paging message. For example, if the targetBSC is incorrectly configured, the Paging message is sent to a wrong BSC.

– Check that the paging-related parameters on the BSC side are configured correctly.Choose Set Cell Attributes > Idle Mode. Check that the parametersBS_AG_BLKS_RES, CCCH_CONF, and BS_PA_MFRAMES are set correctly.

l Check the communications between the subracks in the BSC.If the BSC has multiple subracks, on receiving the Paging message from the MSC, the BSCstarts paging based on the location area and cell information in the Paging message. ThePaging Command message sent from the BSC to the BTS may be forwarded betweensubracks. If the communication between the subracks is abnormal, the Paging Commandmessage may not be forwarded, and no Paging Command message is sent on the Abisinterface.By viewing the BSC alarms, check that the communications between the subracks arenormal.

12.3.3 No Paging Response on the Abis Interface (Case Study)This describes the fault, probable causes, and handling suggestions.

DescriptionAfter sending the BTS a Paging Command message, the BSC does not receive an EstablishmentIndication (Paging Response) message, as indicated in the message tracing on the Abis interface.

AnalysisThe fault may be caused by faulty data configuration or poor radio signal coverage.

Handling Suggestionsl 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 AssignmentRequests and MSC Paging Requests (Circuit Service) before and after the problemoccurs.



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.

l To check whether the problem lies in the BTS, make test calls in the following locations:

– Other cells under the same BTS

– Other sites of the same site type

– Other sites of a different site type

– Sites from other manufacturers

l Check the data configurations.

– Check that the paging-related parameters on the BSC side are configured correctly.

– Choose Set Cell Attributes > Idle Mode. Check that the parametersBS_AG_BLKS_RES, CCCH_CONF, BS_PA_MFRAMES, and Tx-integer areset correctly.

– Choose Set Cell Attributes > Call Control. Check that the parameters such as theMS MAX Retrans are set correctly.

– Check that the values of the Location Update Period on the BSC and the MSC are setcorrectly.

– Choose Set Cell Attributes > Call Control. Check that the parameters such as thePeriod of Periodic Location Update (6 minutes) are set correctly.

– The location update period on the BSC side must be shorter than that on the MSCside. For details, refer to 6.1 Location Update Procedure.

l Check the radio signal coverage.

Poor radio signal coverage may lead to the existence of dead zones where an MS cannotreceive the Paging Request message. Thus, the MS cannot be paged.

12.3.4 No Paging Response on the A Interface (Case Study)This describes the fault, probable causes, and handling suggestions.

Description

Upon receiving the Establishment Indication (Paging Response) message from the BTS, theBSC does not send any message to the MSC, as indicated in the message tracing on the Abisinterface 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.




Issue 01 (2008-06-10)

13 BSC Release

About This Chapter

BSC release consists of the normal release procedure and the local release procedure.

13.1 Normal Release ProcedureThis describes the normal release procedure.

13.2 Local Release ProcedureThis describes the local release procedure.

HUAWEI BSC6000 Base Station SubsystemBSS Signaling Analysis Guide 13 BSC Release


13-1

13.1 Normal Release ProcedureThis describes the normal release procedure.

The normal release procedure can be originated by the MS or the MSC. Upon onhook, the callingMS sends a Disconnect message to the MSC. Then, the corresponding MSC sends the Disconnectmessage to the called MS.

After the access of the MS, the BSC initiates the release procedure upon service requests, forexample, MS onhook. Figure 13-1 shows the BSC normal release procedure.

13 BSC ReleaseHUAWEI BSC6000 Base Station Subsystem



Issue 01 (2008-06-10)

Figure 13-1 Normal release procedure

MS BTS MSC

Release Complete(3)

BSC

Disconnect(1)

FACCH

Start T3109

Stop T3109

Start T305

Release(2)FACCH

Start T308

Stop T305

Stop T308

FACCH

Clear Command(4)Channel Release(5)

FACCH

Deactivate SACCH(8)DISC(6)

FACCH

UA(7)FACCH

Release Indication(9)

Start T3111

Stop T3111

RF Channel Release(10)Clear Complete(11)

RF Channel ReleaseAcknowledge(12)

RLSD(13)

RLC(14)


1. Upon onhook, the calling MS sends a Disconnect message to the MSC and starts timerT305. The Disconnect message carries the cause for disconnection.

2. The MSC sends the calling MS a Release message and at the same time sends the calledMS a Disconnect message. The network starts timer T308.



13-3

3. Upon receiving the Release message, the calling MS stops timer T305, releases the MMconnection, and sends the MSC a Release Complete message.

4. Upon receiving the Release Complete message, the MSC stops timer T308, releases theMM connection, and sends the BSC a Clear Command message. The Clear Commandmessage notifies the BSC of releasing the resources on the A interface and the Um interface.

5. The BSC sends a Channel Release message and starts timer T3109. The Channel Releasemessage carries the RR cause filed and notifies the MS and the BTS of releasing the logicchannels on the Um interface.

6. Upon receiving the Channel Release message, the MS disconnects the uplink signaling linkand sends the BTS a DISC frame, indicating that the logic channels are released.

7. The BTS sends the MS a UA frame. Upon receiving the UA frame, the MS returns to theCCCH and enters the idle state.

8. The BSC sends the BTS a Deactivate SACCH message, deactivates the associated signalingchannels, and releases the downlink associated signaling links.

9. Upon receiving the DISC frame from the MS, the BTS sends the BSC a Release Indicationmessage, indicating that the MS has released the logic channels on the Um interface. Atthe same time, the BSC stops timer T3109, and starts timer T3111.

10. Upon timer T3111 expiry, the BSC sends the BTS an RF Channel Release message. TimerT3111 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 theRF 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 sendsthe BSC a Clear Command message to request the release of the SCCP signaling link. TheClear Command message carries the clear causes such as the Handover Successful or CallControl. If the release is caused by radio interface message failures, radio link failures, orequipment failures, the BSC sends a Clear Request message to the system. Then, the MSCdelivers the Clear Command message.

13.2 Local Release ProcedureThis describes the local release procedure.

The local release procedure is initiated by the BSC, as shown in Figure 13-2.

13 BSC ReleaseHUAWEI BSC6000 Base Station Subsystem



Issue 01 (2008-06-10)

Figure 13-2 Local release procedure

Deactivate SACCH (1)

Release Request (2)

RF Channel Release(4)

RF Channel Release Acknowledge (5)

BTS BSC

Release Confirm (3)


1. The BSC sends the BTS a Deactivate SACCH message to deactivate the associatedsignaling channels.

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

3. Upon receiving the Release Request message with the cause value Local End Release, theBTS responds to the BSC with a Release Confirm message. If the Release Request messagecarries other cause values, the BTS sends a DISC frame to the MS. Only after receivingthe UA frame or DM frame from the MS, the BTS sends the Release Confirm message tothe BSC.

4. The BSC sends an RF Channel Release message to the BTS.5. The BTS sends an RF Channel Release Acknowledge message to the BSC.



13-5

14 Handover

About This Chapter

Handover is one of the basic functions of the GSM. It enables calls to be set up in better cellsand reduces call drops. Handover also lowers cross interference. The handover procedureinvolves handover triggering, handover preparation, handover decision, and handover execution.

14.1 Handover ProceduresThe handover procedures are categorized into the intra-BSC handover procedure, inter-BSChandover 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.

HUAWEI BSC6000 Base Station SubsystemBSS Signaling Analysis Guide 14 Handover


14-1

14.1 Handover ProceduresThe handover procedures are categorized into the intra-BSC handover procedure, inter-BSChandover procedure, inter-MSC handover procedure, and inter-RAT handover procedure.

14.1.1 Intra-BSC Handover ProcedureThis describes the intra-BSC handover procedure.14.1.2 Inter-BSC Handover ProcedureThis describes the inter-BSC handover procedure.14.1.3 Inter-MSC Handover ProcedureThis describes the inter-MSC handover procedure.14.1.4 Inter-RAT Handover ProcedureThis describes the inter-RAT handover procedure.

14.1.1 Intra-BSC Handover ProcedureThis describes the intra-BSC handover procedure.

Figure 14-1 shows the intra-BSC handover procedure.

Figure 14-1 Intra-BSC handover procedure

MS BTS2 BTS1BSC


EstablishIndication(11)

SACCH

MS MSC

MeasurementReport(1)Measurement

Result(2)

HandoverCommand(6)


FACCHStart T3103

HandoverAccess(7)

FACCH

Start T3124

HandoverAccess

FACCHHandover Detect(8)

PHY INFO(9)

FACCH

Stop T3124

SABM(10)

FACCH

UA(12)

FACCH HandoverComplete(13)

FACCH

Stop T3103Handover

Perfomed(14)

ChannelModify

Prepare(5)

14 HandoverHUAWEI BSC6000 Base Station Subsystem



Issue 01 (2008-06-10)


1. The MS sends BTS1 a measurement report on an SACCH on the Um interface.

2. BTS 1 forwards the measurement report to the BSC.

3. Based on the measurement report, the BSC determines whether to hand over the MS toanother cell. If a handover is required, the BSC sends BTS 2 a Channel Activation message.

4. Upon receiving the Channel Activation message, if the channel type is correct, BTS 2 turnson the power amplifier on the specified channel to receive information on the uplink, andsends a Channel Activation Acknowledge message to the BSC.

5. After receiving a Channel Activation Acknowledge message from BTS 2, if the targetchannel uses a different payload type (PT) from the originating channel, the BSC sends theMSC a Channel Modify Prepare message, notifying the MSC that the PT of the current callis changed.

6. The BSC sends a Handover Command message to BTS 1 and BTS 1 forwards the messageto the MS on the FACCH. BTS 1 starts timer T3103. The Handover Command messagehas all the information to be transferred on the new channel and the data required foraccessing the MS. It also indicates whether the handover is synchronous or asynchronous.

7. Upon receiving the Handover Command message, the MS attempts the access and sendsBTS 2 a Handover Access message on the FACCH.

8. After receiving the Handover Access message from the MS, BTS 2 sends a Handover Detectmessage to the BSC.

9. Whether a PHY INFO message is sent depends on the handover type.

l Asynchronous handover

After the channels of BTS 2 are activated, BTS 2 waits for the access of the MS on adedicated channel until timer T3103 expires. Upon detecting the Handover Accessmessage from the MS, BTS 2 sends the BSC a Handover Detect message and at thesame time to the MS a PHY INFO message on an FACCH. The PHY INFO messagecarries the new TA calculated by BTS 2. Upon receiving the PHY INFO message, theMS sends BTS 2 an SABM frame.

l Synchronous handover

BTS 2 does not send the PHY INFO message. Upon sending the Handover Accessmessage, 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 firsttime. It stops timer T3124 upon receiving the PHY INFO message, and sends BTS 2an SABM frame on an FACCH.

l 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 messageto 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 linkestablishment.

13. The MS sends BTS 2 a Handover Complete message on the FACCH. BTS 2 forwards themessage to notify the BSC of the handover success. The Handover Complete messagecarries only the handover complete indication. The MS does not return to the old channel



14-3

after sending this message. If the MS does not receive the PHY INFO message or the UAframe 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 aHandover Performed message to notify the MSC of the handover completion. TheHandover Performed message carries the handover type. At the same time, the BSC sendsan RF Channel Release message to notify BTS 1 of channel release. The target cell forwardsto the BSC the Handover Complete message it receives from the MS. Upon receiving theHandover Complete message, the BSC sends an RF Channel Release message to notifyBTS 1 of channel release. Upon receiving the RF Channel Release message, BTS 1 sendsan RF Channel Release Acknowledge message. The message indicates that the radiochannel is released and ready for reallocation.

14.1.2 Inter-BSC Handover ProcedureThis describes the inter-BSC handover procedure.

Figure 14-2 shows the inter-BSC handover procedure.




Issue 01 (2008-06-10)

Figure 14-2 Inter-BSC handover procedure

MS BTS1 MSCBSC1 BSC2 BTS2

MeasurementReport from MS(1) Handover

Required(2)SACCH

FACCH

MS

HandoverRequest(3) Channel

Activation(4)Start T7 Channel Activation

Acknowledge(5)Handover RequestAcknowledge(6)Handover

Command(7)

Stop T7

HandoverCommand(8)

Start T8

HandoverCommand(9)

HandoverAccess(9)

StartT3124

HandoverAccess(10)

FACCH

HandoverDetect(11)Handover

Detect(12)PHY

INFO(13)

FACCH

SABM(14)

FACCH

StopT3124


UA(16)

FACCH

FACCH

HandoverComplete(17)Handover

Complete(18)HandoverComplete(19)Clear

Command(20)

Stop T8

ClearComplete(21)

The difference between the inter-BSC handover procedure and the intra-BSC handoverprocedure lies in the signaling procedures on the A interface. Only the different signalingprocedures are described as follows:

1. When an MS needs to be handed over to a cell controlled by BSC 2, BSC 1 sends the MSCa 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.

2. Upon receiving the Handover Required message, if the MSC finds that the location area ofthe target cell is under the MSC, it sends BSC 2 a Handover Request message. TheHandover Request message carries the information, transmission mode, MS classmark, andrequired channel classmark of the serving and the target cells. Upon receiving the HandoverRequest message, BSC 2 sends the MSC an SCCP Connection Confirm message, indicating



14-5

that its connection to the MSC is established. The A interface messages are sent throughthis SCCP connection.

3. BSC 2 activates a new channel and sends a Handover Request Acknowledge message tonotify the MSC that the channel is now available. The Handover Request Acknowledgemessage carries the information on the allocated handover resources and the handovercommand indicating that the BSC is ready.

4. Upon receiving the Handover Request Acknowledge message, the MSC sends BSC 1 aHandover Command message. Then BSC 1 stops timer T7. BSC 1 sends the MS a HandoverCommand message and starts timer T8, requesting the MS to access the new channel. TheHandover Command message carries the CI, channel type, and handover reference.

5. Upon receiving the Handover Complete message from BSC 2, the MSC sends BSC 1 aClear Command message, which carries the clearing cause (for example, handoverclearing). 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.

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 updateprocedure after a call is complete.

14.1.3 Inter-MSC Handover ProcedureThis describes the inter-MSC handover procedure.

Figure 14-3 shows the inter-MSC handover procedure.




Issue 01 (2008-06-10)

Figure 14-3 Inter-MSC handover procedure

MS BTS1 MSC1BSC1 MSC2 BSC2

MeasurementReport

from MS(1) HandoverRequired(2)

SACCH

FACCH

BTS2

PerformHandover(3) Channel

Activation(5)Channel

ActivationAcknowledge(6)

Handover RequestAcknowledge(7)

HandoverCommand(12)

HandoverAccess(13)

FACCHHandoverDetect(14)Handover

Detect(15) PHYINFO(16)

FACCH

SABM(18)

FACCHEstablish

Indication(19)

UA(20)

FACCH

FACCH

HandoverComplete(21)Handover

Complete(22)HandoverComplete(23)Send

End Signal(24)

ClearComplete(26)

MS

HandoverRequest(4)

RadioChannel Ack(8)

IAM(9)

ACM(10)HandoverCommand(11)

PHYINFO(17)

FACCH

ClearCommand(25)

For the inter-MSC handover procedure, refer to 14.1.1 Intra-BSC Handover Procedure and14.1.2 Inter-BSC Handover Procedure.

The messages on the E interface are as follows:

1. Perform Handover: MAP layer message. It contains the CGI of the serving cell and thetarget cell and the required channel type. It informs MSC 2 that a handover will be initiated.

2. Radio Channel Acknowledge: MAP layer message. It carries the information about the newchannel in the target cell and the handover number.

3. IAM: initial address message. It is a TUP/ISUP message.4. ACM: address complete message. It is a TUP/ISUP message.5. Send End Signal: MAP layer message. It indicates the end of transmission.

14.1.4 Inter-RAT Handover ProcedureThis describes the inter-RAT handover procedure.



14-7

Figure 14-4 and Figure 14-5 show the inter-RAT handover procedure.

Figure 14-4 GSM-to-UMTS handover procedure

MS BSS RNCMSC

Handover Required(1)

FACCH

MS

Inter System to UTRANHandover Command(2)

Start T3121 Handover toUTRAN Complete(4)

HandoverCommand(3)

HandoverComplete(5)

Stop T3121

Clear Command(6)

Clear Complete(7)

FACCH

The GSM-to-UMTS handover procedure is as follows:

1. The BSS sends a Handover Required message to the MSC.2. Upon receiving the Handover Required message, the MSC sends the BSS an Inter System

To UTRAN Handover Command message and starts timer T3121.3. Upon receiving the Inter System To UTRAN Handover Command message, the BSS sends

the MS a Handover Command message on an FACCH.4. After the connection is successfully established, the MS sends the RNC a Handover to

UTRAN Complete message on a UTRAN channel.5. The RNC forwards the Handover Complete message to the MSC.6. Upon receiving the Handover Complete message, the MSC stops timer T3121 and initiates

a channel release procedure.




Issue 01 (2008-06-10)

Figure 14-5 UMTS-to-GSM handover procedure

MS BSS RNCMSC MS

HandoverCommand(4)

FACCH

HandoverRequest(1)

FACCH

HandoverAccess(7)

FACCH

Handover Detect(6)

Handover RequestAcknowledge(2) Handover Request

Acbowledge(3)HandoverAccess(5)

HandoverComplete(8) Handover

Complete(9)

For the UMTS-to-GSM handover procedure, refer to the GSM-to-UMTS handover procedurementioned 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 candidatecell from the candidate cell list based on the priority in a descending order. If the candidatecell is internal BSC, the BSC notifies the candidate cell of initiating an intra-BSC handoverprocedure, and the candidate cell will be the target cell.

2. The BSC assigns a proper channel and notifies the BTS2 that serves the target cell to activatethe channel.

3. If IP transmission is used on the A interface and if the target channel uses a different payloadtype (PT) from the originating channel, the BSC sends a Channel Modify Prepare messageto the MSC, notifying the MSC of the PT change in the current call.



14-9

4. The BSC notifies the originating cell to send a Handover Command message to the MS,and starts timer T3103.

5. After receiving the Handover Detect message, BTS 2 continues to wait for theEstablishment Indication message and the Handover Complete message.

6. After BTS 2 receives the Handover Complete message, BSC 2 stops timer T3103 andconsiders that the call is set up in the target cell.

7. BSC 1 notifies BTS 1 of initiating a local release procedure. At the same time, it sends aHandover Performed message to notify the MSC of the handover completion. If IPtransmission 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 thesoftware 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 candidatecell from the candidate cell list based on the priority in a descending order. If the candidatecell is an external 2G cell, the outgoing BSC handover procedure is triggered. For theserving cell, the external cell is the target cell, and the BSC where the target cell is locatedis the target BSC, namely BSC 2.

2. Upon handover initiation, BTS 1 sends the MSC a Handover Required message and startstimer T7 to wait for a Handover Command message.

3. Upon receiving the Handover Request message from the MSC, the target BSC allocatesand activates channels according to the target cell identity in the message. After channelactivation, BTS 2 sends the MSC a Handover Request Acknowledge message that carriesthe Handover Command message.

4. BTS1 forwards to the MS the Handover Command message that BSC 1 receives from theMSC and at the same time starts timer T8 to wait for the handover completion.

l If the Clear Command message with the cause value Handover Success is receivedbefore timer T8 expires, BSC 1 considers that the handover is successful.

l If the MS returns to the old channel before timer T8 expires, BSC 1 stops T8 and sendsthe MSC a Handover Failure message.

l If timer T8 expires, BSC 1 considers that the call drops and sends the MSC a ClearRequest message.

5. BTS 2 forwards the Handover Detect message to the MSC and continues to wait for theEstablishment Indication message and the Handover Complete message.

6. Upon receiving the Handover Complete message, BTS 2 sends a Handover Completemessage to notify the MSC of handover completion.

7. Upon receiving the Clear Command message, BTS 1 releases the radio resources that thecall 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 describedin 14.2.2 Internal BSC Signaling Procedure (Inter-BSC Handover).




Issue 01 (2008-06-10)

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 inter-BSC handover. The differences are as follows:

l Obtaining the UTRAN neighbor cell information and the UTRAN system parameters fromthe Idle Mode, Handover Data, and Other Attributes

l 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)This describes the fault, probable causes, and handling suggestions.

Description

No channels are available in the target cell.

Analysis


l During an inter-cell handover, no TCHs are available in the target cell.

l During a cross-cell handover, no SDCCHs are available in the target cell.

l During an intra-cell handover due to bad quality, no TCHs are available in the cell.



14-11



l Check whether the target cell is congested. If yes, add TRXs to the target cell.

l Choose Set Cell Attributes > Channel Management > Advanced > Huawei ChannelAllocation Algorithm II and Radio Channel Management and Control. Check that theTCH Traffic Busy Threshold parameter is set to a proper value.

l Choose Set Cell Attributes > Channel Management. Check that the Advanced ChannelType 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 Failuremessage from the MS upon T8 expiry.

Analysis

The probable causes are analyzed as follows:

1. If the old BSS does not receive a Clear Command message from the MSC or a HandoverFailure message from the MS upon T8 expiry, it releases the dedicated channels.

2. The BSC sends the MSC a Clear Request message with the cause value Radio InterfaceMessage Failure.

3. Before a Clear Command message is received, the terrestrial resources on the old BSS sideremain allocated.

4. On receiving the Clear Command message, the old BSS changes the state of the terrestrialresources to idle and sends a Clear Complete message to the MSC.

5. The MSC releases the SCCP connection to the old BSS and thus terminates the connectionwith the BSS.


在 In the Set Cell Attributes dialog box, choose Other Attributes > Advanced > CellTimer. Check that the length of T8 is set properly.

14.3.3 MS Returning to the Old Channel After Inter-Cell HandoverFailure (Case Study)


Description

The MS returns to the old channel after inter-cell handover failure.




Issue 01 (2008-06-10)

AnalysisThe probable cause can be either of the following: first, poor signal quality or low receive levelon the Um interface; second, wrong data configurations of the external cells.

Handling SuggestionsCheck the signal quality and receive level on the Um interface. Check that the data configurationsof the external cells are correct.

14.3.4 BSC Receiving a Connection Failure Indication Message(Case Study)


DescriptionCalls drop.


l Radio link failure

l Hardware faults

Handling Suggestionsl Check the resources on the Um interface.

l Check the antenna system and the power amplifier.

14.3.5 Forced Handover Failure (Case Study)This describes the fault, probable causes, and handling suggestions.

DescriptionForced handover fails.


l No neighbor cell

l Incorrect configuration of the neighbor cell

l No resources in the neighbor cell

l Bad radio conditions in the neighbor cell

Handling SuggestionsCheck the neighbor cell for its data configuration and radio signal quality, for example, thequality of receive level.



14-13

14.3.6 Handover Failure Caused by CIC Malfunction (Case Study)This describes the fault, probable causes, and handling suggestions.

DescriptionHandover fails. The cause value of the Handover Failure message is Requested TerrestrialResource Unavailable.

AnalysisIf the CIC in the Handover Request message received by the target BSC is labeled BLOCK, thetarget BSC responds to the MSC with a Handover Failure message with the cause valueRequested Terrestrial Resource Unavailable.

Handling SuggestionsCheck the state of the CIC.

14.3.7 Handover Failure Caused by MS Access Failure (Case Study)This describes the fault, probable causes, and handling suggestions.

DescriptionThe MS cannot be handed over.

AnalysisThe probable causes are as follows:l The system does not trigger the handover.

l The configurations of the neighbor cell are faulty.

Handling SuggestionsThe handling suggestions are as follows:l Check whether the handover trigger conditions are met.

l Check whether there is a neighbor cell list in the measurement report.

l Check whether the neighbor cell has available channels.

l Check whether the data of the neighbor cell is incorrect, for example, whether there isinconsistency in CGI.




Issue 01 (2008-06-10)

15 Call Re-Establishment

About This Chapter

The call re-establishment procedure allows an MS to resume a connection after a radio linkfailure. It may take place in a new cell or a new location area.

15.1 Call Re-Establishment ProcedureThis 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 handlingsuggestions.

HUAWEI BSC6000 Base Station SubsystemBSS Signaling Analysis Guide 15 Call Re-Establishment


15-1

15.1 Call Re-Establishment ProcedureThis describes the call re-establishment procedure.

Figure 15-1 shows the call re-establishment procedure.

Figure 15-1 Call re-establishment procedure

ChannelRequest(5)

Clear Request(2)

Cipher ModeComplete(11)

Cipher ModeCommand(10)


Status Enquiry(14)

Status(15)

CM Re-establishmentRequest(7)

CC(8)CM Service Accepted (9)

MS BTS MSCBSC

Connection FailureIndication(radio link failure)(1)

RACHEstablish Indication(CM

Reestablishment Request)(6)

Clear Command(3)


FACCH

StartT3230

StopT3230

StartT322

FACCHStopT322


1. After a radio link failure is detected, the BTS sends the BSC a Connection Failure Indicationmessage, which contains the cause value for radio link failure.

2. The BSC sends the MSC a Clear Request message, which contains the cause for theabnormal release.

3. On receiving the Clear Request message, the MSC sends the BSC a Clear Commandmessage, requesting the release of radio resources.

4. The BSC initiates a release procedure, releases the channel resources on the Um interface,and returns a Clear Complete message to the MSC.

15 Call Re-EstablishmentHUAWEI BSC6000 Base Station Subsystem



Issue 01 (2008-06-10)

5. The MS sends the BTS a Channel Request message (cause value: Call re-establishment)and initiates an Immediate Assignment Procedure (Seizing Signaling Channel).

6. The BTS initiates a call re-establishment procedure by sending the BSC a CM Re-establishment 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 MMsublayer state Wait For Reestablish. The CM Re-Establishment Request message containsthe IMSI (or TMSI), classmark 2, and Ciphering Key Sequence Number (CKSN).

7. The BSC establishes an SCCP link connection on the A interface and sends the MSC a CMService Request message.

8. The MSC sends the BSC a Connect Confirm message.9. The MSC sends the MS a CM Service Accepted message on the SDCCH on the Um

interface.10. The MSC initiates the ciphering mode setting procedure by sending a Cipher Mode

Command message. For details, refer to Ciphering Procedure. Once the cipheringprocedure is complete or the CM Service Accepted message is received, the MS stops timerT3230 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 MobileOriginated 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. Steps 1 through 4 shown in Figure 15-1 describe the radio resource release procedure,which is the same as the normal release procedure.

2. Steps 5 through 9 shown in Figure 15-1 describe the immediate assignment procedure,namely, the signaling channel seizure procedure.

3. Steps 10 and 11 shown in Figure 15-1 describe the ciphering procedure.4. Steps 12 and 13 shown in Figure 15-1 describe the assignment procedure.5. Initiation of the call re-establishment procedure

l If a cell is required to support call re-establishment, Call ReestablishmentForbidden in Set Cell Attributes must not be selected, and the cell cannot be in barredstate.

l Upon detection of a link failure, the MS sends a Channel Request message with thecause value Call Re-Establishment in the selected cell. The previous channel resourcesare released by the BSC after the timer on the BTS side expires.

l Upon detection of a link failure, the BTS sends the BSC a Connection Failure messagewith the cause value Radio Link Failure. Then the BSC releases the corresponding radioresources and waits for the call re-establishment request from the MS.

6. Mode of the MS in the call re-establishment procedureThe MS cannot return to idle mode during a call re-establishment procedure. Therefore, ifthe cell selected for call re-establishment is not the location area, the MS cannot performlocation update until the call re-establishment procedure is complete.



15-3

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

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)This describes the fault, probable causes, and handling suggestions.

DescriptionAfter the MSC receives a CM Re-Establishment Request message, if the RR sublayer sends anindication that the ciphering mode setting procedure is complete, or if a CM Service Acceptmessage is received, you can infer that the MS accepts the services. The MS re-enters the MMsublayer state MM Connection Active.

If the re-establishment request from the MS does not correspond to its current call state, thenetwork returns the MS a CM Service Reject message.

AnalysisIf the network cannot process the re-establishment request, it sends a CM Service Reject messagewith one of the following cause values:

l IMSI Unknown in VLR

l Illegal MS

l Network Failure

l Congestion

l Service Option not Supported

l Service Option Temporarily out of Order

Upon receiving the CM Service Reject message, the MS releases the MM connection and therelevant RR connection.




Issue 01 (2008-06-10)



l If the cause value is IMSI Unknown In VLR, check that the location update procedure isperformed successfully to ensure that the IMSI is loaded to the VLR. In addition, checkthat the IMSI exists in the HLR.

l If the cause value is Illegal MS, check that the MS can access the network and can performlocation update. If not, replace the MS with a new one that can access the network.

l If cause value is Network Failure, modify the configuration that corresponds to call re-establishment on the network side.

l If the cause value is Congestion, configure more channels.

l If the cause value is Service Option Not Supported, modify the configuration thatcorresponds to call re-establishment on the network side.

l If the cause value is Service Option Temporarily Out Of Order, modify the configurationthat corresponds to call re-establishment on the network side, for example, the CM servicerelated functions.

l If the previously mentioned measures do not work, analyze the values of the correspondinginformation elements to find out in which network element the fault takes place. Thenperform detailed analysis in the located network element.

15.3.2 Call Re-Establishment Not Allowed or Re-EstablishmentFailure (Case Study)


Description

When an MM connection is established, the MM layer sends an indication to the CC layer. Ifthe 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 orclearing period, the CC layer releases the MM connection.

l If re-establishment is unsuccessful, the MM connection is released, and a release indicationis sent to the CC layer.


Check whether the Call Reestablishment Forbidden parameter of the cell where the re-establishment procedure is initiated is set correctly and whether the cell is barred.

15.3.3 Call Re-Establishment Failure Caused by RR ConnectionFailure (Case Study)




15-5

DescriptionUpon detection of a random access failure or an RR connection failure, the MS stops timerT3230, 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 procedureand releases all active MM connections.

AnalysisThe probable causes are as follows:l Signal quality on the Um interface is poor.

l Channels on the Um interface are congested.

l The network side has no response.


l If the transmission quality on the Um interface is poor, use a test MS to measure the uplinkand downlink receive quality and the power level. Improve the transmit and receive qualityand reduce the interference.

l If the channels are congested, register and observe the relevant traffic statistics to determinethe severity level of congestion. Expand the system capacity if the congestion rate is high.

l If the problem lies in the network, make adjustments on the network side to locate thephases in which serious response delay occurs.




Issue 01 (2008-06-10)

16 Directed Retry

About This Chapter

Directed retry is a special type of handover. When no radio resource is available for allocationin a serving cell during channel assignment, the BSS hands over the channel request from theserving cell to a neighbor cell.

16.1 Directed Retry ProceduresThis describes directed retry procedures. The directed retry procedures are categorized into theintra-BSC directed retry procedure, inter-BSC directed retry procedure, and inter-MSC directedretry procedure.

16.2 Internal BSC Signaling Procedures (Directed Retry)This describes internal BSC signaling procedures (directed retry). The internal BSC signalingprocedures are categorized into the intra-BSC directed retry procedure, inter-BSC directed retryprocedure, and inter-MSC directed retry procedure.

16.3 Abnormal Cases and Handling Suggestions (Directed Retry)This describes the abnormal directed retry cases.

HUAWEI BSC6000 Base Station SubsystemBSS Signaling Analysis Guide 16 Directed Retry


16-1

16.1 Directed Retry ProceduresThis describes directed retry procedures. The directed retry procedures are categorized into theintra-BSC directed retry procedure, inter-BSC directed retry procedure, and inter-MSC directedretry procedure.

16.1.1 Intra-BSC Directed Retry ProcedureThis describes the intra-BSC directed retry procedure.

16.1.2 Inter-BSC Directed Retry ProcedureThis describes the inter-BSC directed retry procedure.

16.1.3 Inter-MSC Directed Retry ProcedureThis describes the inter-MSC directed retry procedure.

16.1.1 Intra-BSC Directed Retry ProcedureThis describes the intra-BSC directed retry procedure.

Figure 16-1 shows the intra-BSC directed retry procedure.

16 Directed RetryHUAWEI BSC6000 Base Station Subsystem



Issue 01 (2008-06-10)

Figure 16-1 Intra-BSC directed retry procedure


Handover Command(17) Handover

Access(18)HandoverDetect(19)

PHY INFO(20)

SABM(22)EstablishIndication(23)

UA(24)HandoverComplete(25)


ChannelRequest(1) Channel

Required(2)Channel

Activation(3)ImmediateAssignment

Command(5)

UA(7)

SABM(6)

Establish Indication(CM ServiceRequest)(8)

CR(Complete L3 Information)(9)

CC(10)


MS BTS1 MSCBSC BTS2 MS


StartT3103

FACCH

RACH

AGCH

SDCCH

CM ServiceAccepted(11)

SDCCH

Setup(12)SDCCH Call Proceeding(13)

SDCCH FACCH

PHY INFO(21)

FACCH

FACCH

FACCH

StopT3103

ChannelActivation(15)


1. The MS sends the BTS a Channel Request message on the RACH.2. The BTS sends the BSC a Channel Required message.



16-3

3. Upon receiving the Channel Required message, the BSC assigns a signaling channel andsends the BTS a Channel Activation message.

4. Upon receiving the Channel Activation message, if the channel type is correct, the BTSturns on the power amplifier on the specified channel to receive information on the uplink,and sends a Channel Activation Acknowledge message to the BSC.

5. Upon receiving the Channel Activation Acknowledge message, the BSC sends anImmediate Assignment Command message on the AGCH to notify the MS of channelaccess.

6. After the MS successfully accesses the channel, the MSC sends the BSC an AssignmentRequest message requesting for TCH radio resources. If a terrestrial circuit is requiredbetween the MSC and the BSC, the Assignment Request message contains informationrelated to the terrestrial circuit. If no qualified TCH is available in the serving cell, the BSCattempts to hand over the MS to a neighbor cell that provides voice services. If the targetcell and the serving cell are controlled by the same BSC, the directed retry is an intra-BSCdirected retry.


1. Steps 1 through 8 in the procedure shown in Figure 16-1 are the random access andimmediate assignment procedures, in which the BSS assigns a signaling channel to the MS.

2. Steps 14 through 24 in the procedure shown in Figure 16-1 are TCH directed retryprocedure, in which the BSS assigns a speech channel to the MS.

16.1.2 Inter-BSC Directed Retry ProcedureThis describes the inter-BSC directed retry procedure.

Figure 16-2 shows the inter-BSC directed retry procedure.




Issue 01 (2008-06-10)

Figure 16-2 Inter-BSC directed retry procedure

AssignmentRequest(14)Handover

Required(15)Handover

Request(16)


HandoverRequest

Acknowledge(19)HandoverCommand(20)

HandoverCommand(21)

HandoverComplete(31)Clear

Command(32)

ChannelRequest(1) Channel

Required(2)Channel

Activation(3)

ImmediateAssignment

Command(5)

SABM(6)EstablishIndication

(CM ServiceRequest)(8)

CM ServiceAccepted(11)

Setup(12)Call

Proceeding(13)

MS BTS1 MSCBSC1 BSC2 BTS2

RACH

AGCH

MS

Start T10

Start T8


SDCCH

UA(7)CR (Complete

Layer3Information)(9)

CC(10)

SDCCH

SDCCH

SDCCH

SDCCH

HandoverAccess(22)

FACCHPHY

INFO(25)

FACCH

SABM(27)

FACCHUA(29)

FACCH

FACCH

HandoverComplete(30)

PHYINFO(26)

FACCHEstablish

Indication(28)

Stop T10

Stop T8

ClearComplete(33)

HandoverDetect(23)Handover

Detect(24)

ChannelActivationACK(4)



16-5

The inter-BSC directed retry procedure differs from the intra-BSC directed retry procedure inA-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 aHandover Required message requesting the MS to initiate an outgoing inter-BSC handover.

NOTE

Direct retry is a special type of handover.

2. Upon receiving the Handover Required message, the MSC sends BSC2 a Handover Requestmessage.

3. BSC2 activates a new channel and sends a Handover Request Acknowledge message tonotify the MSC that the channel is now available.

4. Upon receiving the Handover Request Acknowledge message, the MSC sends BSC1 aHandover Command message. BSC1 forwards the Handover Command message on a TCHto notify the MS of channel access.

5. Upon receiving the Handover Complete message from BSC2, the MSC sends BSC1 a ClearCommand message. BSC1 initiates a local release procedure and sends the MSC a ClearComplete message.

For details about other signaling messages, refer to 16.1.1 Intra-BSC Directed RetryProcedure.

16.1.3 Inter-MSC Directed Retry ProcedureThis describes the inter-MSC directed retry procedure.

Figure 16-3 shows the inter-MSC directed retry procedure.




Issue 01 (2008-06-10)

Figure 16-3 Inter-MSC directed retry procedure

AssignmentRequest(1)Handover

Required(2) PerformHandover(3) Handover

Request(4)


ChannelActivation

Acknowledge(6)HandoverRequest

Acknowledge(7)Radio ChannelAcknowledge(8)

IAM(9)

ACM(10)Handover Command(11)

HandoverDetect(17)

Send EndSignal(23)

Clear Command(24)

HandoverAccess(13)Handover

Detect(14)

PHY INFO(15)

SABM(18)EstablishIndication(19）

UA(20）HandoverComplete(21)

MS BTS1 MSC1BSC1 MSC2 BSC2

Start T10

FACCH

SDCCH

FACCH

PHY INFO(16)

FACCH

FACCH

FACCH

BTS2 MS

Start T8

FACCHStop T10

HandoverComplete(22)

Stop T8

ClearComplete(25)

HandCommand(12)

For details about the inter-MSC directed retry procedure, refer to 16.1.2 Inter-BSC DirectedRetry Procedure.

16.2 Internal BSC Signaling Procedures (Directed Retry)This describes internal BSC signaling procedures (directed retry). The internal BSC signalingprocedures are categorized into the intra-BSC directed retry procedure, inter-BSC directed retryprocedure, 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-7

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 retryprocedure is triggered if the cell where the call is originated has no available TCHs or AssignmentCell Load Judge is enabled, and the Directed Retry Allowed in the Cell Attributes window isselected.

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 acandidate cell from the candidate cell list based on the priority in a descending order. If thecandidate cell is under the same BSC as the serving cell, the BSC notifies the candidatecell of initiating an intra-BSC directed retry procedure, and the candidate cell will be thetarget cell.

2. A channel in the target cell is assigned and the BTS2 that serves the target cell is notifiedto activate the channel.

3. After BTS2 activates the channel, the BSC notifies the MS to send a Handover Commandmessage to BTS1. Meanwhile, BSC2 starts timer T3103 to wait for the Handover Completemessage.

4. On receiving the Handover Detect message, BTS2 continues to wait for the EstablishmentIndication message and the Handover Complete message.

5. On receiving the Handover Complete message, BSC2 stops timer T3103 and considers thatthe call is set up in the target cell.

6. The BSC sends an Assignment Complete message to notify the MSC that assignment isover. The Assignment Complete message carries the information about a new cell. At thesame time, BSC1 notifies BTS1 to initiate a local release procedure.

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 retryprocedure is triggered if the cell where the call is originated has no available TCHs or AssignmentCell Load Judge is enabled, and the Directed Retry Allowed in the Cell Attributes window isselected. If the target cell of the directed retry is an external cell, the inter-BSC directed retryprocedure 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. Atthe same time, the BSC initiates a forced handover procedure. The forced handover procedureis described as follows:

1. If the BSC considers that the call meets the handover trigger conditions, it selects acandidate cell from the candidate cell list based on the priority in a descending order. If the




Issue 01 (2008-06-10)

candidate cell is an external cell, the outgoing BSC directed retry procedure, namely theinter-BSC handover procedure is triggered.

2. Upon the initiation of the inter-BSC handover procedure, BTS1 sends the MSC a HandoverRequired message and starts timer T7 to wait for a Handover Command message from theMSC.

3. On receiving the Handover Request message from the MSC, BSC2 allocates and activatesa channel according to the target cell ID in the message. After channel activation, BTS2sends the MSC a Handover Request Acknowledge message that carries the HandoverCommand message.

4. BTS1 forwards to the MS the Handover Command message that BSC1 receives from theMSC and at the same time starts timer T8 to wait for the handover completion.l 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 issuccessful.

l If the MS returns to the old channel before timer T8 expires, BSC1 stops timer T8 andsends the MSC a Handover Failure message.

l If timer T8 expires, BSC1 considers that the call drops and sends the MSC a ClearRequest message.

5. BTS2 forwards the Handover Detect message to the MSC and continues to wait for theEstablishment Indication message and the Handover Complete message.

6. On receiving the Handover Complete message, BTS2 stops timer T3103B2 and sends aHandover Complete message to notify the MSC of handover completion.

7. On receiving the Clear Command message, BTS1 releases the radio resources that the calloccupies and returns the MSC a Clear Complete message.

16.2.3 Internal BSC Signaling Procedure (Inter-MSC DirectedRetry)

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 theinter-BSC directed retry.

16.3 Abnormal Cases and Handling Suggestions (DirectedRetry)

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 inthe Target Cell (Case Study)




16-9

DescriptionWhen no channel is available in the target cell, BSC2 sends BSC1 a handover failure message,and BSC1 sends the MSC an Assignment Failure message.

AnalysisNo TCH is available in the target cell.

Handling SuggestionsCheck 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)


DescriptionWhen channel activation in the target cell fails, BSC2 sends the MSC an Assignment Failuremessage.

AnalysisThe desired channel in the target cell fails to be activated due to TRX failure.

Handling SuggestionsLocate the channel number in the Channel Activation Negative Acknowledge message, andcheck whether the corresponding TRX is faulty. If the TRX is faulty, replace it.




Issue 01 (2008-06-10)

17 BSC Re-Assignment

About This Chapter

This describes BSC re-assignment. BSC re-assignment refers to a TCH assignment procedureinitiated by the BSC after the BSC receives an Assignment Failure message from the MS on theSDCCH. BSC re-assignment raises the success rate of assignments on the Um interface.

17.1 BSC Re-Assignment ProcedureThis 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 handlingsuggestions.

HUAWEI BSC6000 Base Station SubsystemBSS Signaling Analysis Guide 17 BSC Re-Assignment


17-1

17.1 BSC Re-Assignment ProcedureThis describes the BSC re-assignment procedure.

Figure 17-1 shows the BSC re-assignment procedure.

Figure 17-1 BSC re-assignment procedure

Assignment Failure


AssignmentCommand

Channel ActivationAcknowldge(2)

Assignment Command(3)

UA(5)

Assignment Complete(7)

SABM(4)


MS BTS MSCBSC

SDCCH

SDCCH

SDCCH

FACCH

Start T3107

……

……

Stop T3107

Start T3107

FACCH

FACCH

Stop T3107


1. After the BSC receives the Assignment Failure message from the MS, the BSS stops timerT3107. After a series of BSC internal processing, the BSC sends the BTS a ChannelActivate message and waits for a Channel Activation Acknowledge message from the BTS.

2. Upon receiving the Channel Activation Acknowledge message from the BTS, the BSCperforms internal processing.

3. The BSC sends the MS an Assignment Command message on the SDCCH that is notreleased, and waits for an Establish Indication message from the MS.

17 BSC Re-AssignmentHUAWEI BSC6000 Base Station Subsystem



Issue 01 (2008-06-10)

4. The MS sends the BTS an SABM frame on the main DCCH specified in the AssignmentCommand message.

5. The BTS sends the MS a UA frame on the main DCCH.6. The BTS sends the BSC an Establishment Indication message.7. Upon accessing the speech channel, the MS sends the BSC an Assignment Complete

message on the main DCCH.8. 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 thesession state.

17.2 Internal BSC Signaling Procedure (BSC Re-Assignment)

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 timerT3107 expires, the BSC receives an Assignment Failure message from the BTS.

1. Based on the Assignment Request message, the BSC selects an appropriate TRX, activatesa channel, and sends the BTS an Assignment Command message. The AssignmentCommand message carries the information about the new channel and informs the MS toaccess the new channel.

2. The BSC records the information on the first assignment, such as the channel assignmentrequirements, voice version supported by the MSC, TRX number, band attributes, MSmaximum and minimum power, call type, handover type, indexes of neighbor cells,requirements for downlink DTX, classmark 2, classmark 3, and cell number.

3. Based on the circuit pool number in the first assignment, the BSC obtains the circuitcapability and attaches the channel type parameter in the Channel Assignment Commandmessage.

4. Based on the channel priority in the Assignment Request message from the MSC, the BSCfills the channel priority in the Assignment Command message.

5. Based on the cell type in the first assignment, the BSC fills cell type in the AssignmentCommand message.

6. After all relevant requirements are specified, the BSC assigns a channel as required. Thesubsequent procedure is the same as that of the first assignment.

17.3 Abnormal Cases and Handling Suggestions (BSC Re-Assignment)

This describes the abnormal cases of BSC re-assignment, probable causes, and handlingsuggestions.

17.3.1 BSC Failure to Initiate a Re-Assignment Procedure (Case Study)This describes the fault, probable causes, and handling suggestions.

HUAWEI BSC6000 Base Station SubsystemBSS Signaling Analysis Guide 17 BSC Re-Assignment


17-3

17.3.1 BSC Failure to Initiate a Re-Assignment Procedure (CaseStudy)


DescriptionAfter sending an Assignment Command message, the BSC does not initiate a re-assignmentprocedure even though re-assignment is enabled.

AnalysisThe BSC starts timer T3107. If timer T3107 expires, the BSC does not initiate a re-assignmentprocedure.

Upon receiving a Connect Failure message from the BTS, the BSC does not initiate a re-assignment procedure. When timer T3107 expires or a Connect Failure message is received, theBSC releases related resources.

NOTE

For details, refer to GSM Rec. 0858 and 0808.

Handling SuggestionsIf the BSC receives a Connect Failure message from the BTS, the transmission quality on theA interface should be improved. To improve the transmission quality on the Um interface andto reduce interference, perform a drive test to check the signaling level on the downlink anduplink channels.

17 BSC Re-AssignmentHUAWEI BSC6000 Base Station Subsystem



Issue 01 (2008-06-10)

18 Queuing and Preemption

About This Chapter

This describes queuing and pre-emption.

18.1 Queuing ProcedureThis describes the queuing procedure.

18.2 Preemption ProcedureThis 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 handlingsuggestions.

HUAWEI BSC6000 Base Station SubsystemBSS Signaling Analysis Guide 18 Queuing and Preemption


18-1

18.1 Queuing ProcedureThis describes the queuing procedure.

If no TCHs are available and queuing is allowed, the assignment requests are placed in a waitingqueue. When the TCHs are available, they are assigned in the queuing sequence. Figure 18-1shows the queuing procedure.

Figure 18-1 Queuing procedure


Setup

Queuing Indication

AssignmentComplete

MS BTS MSCBSC

SDCCH


Call ProceedingSDCCH

TCH Assignment Procedure(2)

Release Procedure

Start T11

StopT11

Start Tqho

StopTqho

TALKING


1. The MSC sends the BSC an Assignment Request message and finds that no speech channelis available. If queuing is allowed, the assignment request is placed in a queue, and timerT11 is started.

18 Queuing and PreemptionHUAWEI BSC6000 Base Station Subsystem



Issue 01 (2008-06-10)

2. When a speech channel is assigned, the queuing procedure is complete, and timer T11stops.

18.2 Preemption ProcedureThis describes the preemption procedure.

Preemption refers to handing over an MS with a lower priority to another speech channel or cellso that an MS with a higher priority acquires the speech channel resources. Figure 18-2 showsthe preemption procedure.

Figure 18-2 Preemption procedure

AssignmentRequest

Preemption Start (1)Release Procedure or

Handover Procedure(2)

AssignmentComplete

LowPriority MS

HighPriority MS BSCBTS


Start T11

StopT11

MSC

Talking

Start Tqho

StopTqho

TALKING

Release Procedure


1. The MSC sends the BSC an Assignment Request message and finds that no speech channelis available. If pre-emption is allowed and the priority of the subscriber is higher than thepriority of the subscriber that occupies the speech channel, the preemption procedure isinitiated.

2. The subscriber with a lower priority is handed over to another speech channel or cell.

3. The subscriber with a higher priority seizes the speech channel and the pre-emptionprocedure is complete.



18-3

18.3 Internal BSC Signaling Procedure (Queuing andPreemption)

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 determineswhether queuing is allowed. Only assignment requests and inter-cell handover requests canbe queued.

Upon receiving an Assignment Request message, the BSC searches for an availablechannel. If no channel is available, the BSC sends the MSC a Queuing Indication messageand starts timer T11. The duration of the timer is configurable.

The BSC places the Assignment Request message in a queue and starts the message whenappropriate. Upon assigning a TCH, the BSC stops timer T11 and sends the MSC anAssignment 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-emptionprocedure.

Among all occupied TCHs, the BSC searches for a TCH that has comparatively lowerpriority and that meets the pre-emption requirements. If no such TCHs are available, thequeuing procedure is triggered.

The BSC checks whether eMLPP is enabled. If eMLPP is enabled in the current cell, thepreempted call with a lower priority is forced to perform an outgoing cell handover. Thecall with a higher priority preempts the released TCH.

If eMLPP is not enabled, the call with a lower priority is directly released, and the callwith a higher priority preempts the TCH.

18.4 Abnormal Cases and Handling Suggestions (Queuingand Preemption)

This describes the abnormal cases of queuing and preemption, probable causes, and handlingsuggestions.

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)This describes the fault, probable causes, and handling suggestions.

Description

The BSC sends the MSC a Clear Request message.

18 Queuing and PreemptionHUAWEI BSC6000 Base Station Subsystem



Issue 01 (2008-06-10)

Analysisl 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 messagewith the cause No Radio Resource Available.

l After TCH allocation fails, the BSC sends the MSC an Assignment Failure message. Then,the MSC stops timer Tqho.

Handling SuggestionsCheck whether there is an allocable TCH inside the BSC.



18-5

19 Short Messages

About This Chapter

For an idle MS, short messages are transferred on the SDCCH. For a busy MS, however, shortmessages are transferred on the SACCH. The short message procedure comprises twofundamental procedures: mobile originating short message transfer procedure and mobileterminating short message transfer procedure.

19.1 Short Message ProceduresThe short message transfer procedure comprises the short message sending and receivingprocedures 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.

HUAWEI BSC6000 Base Station SubsystemBSS Signaling Analysis Guide 19 Short Messages


19-1

19.1 Short Message ProceduresThe short message transfer procedure comprises the short message sending and receivingprocedures initiated by an idle or a busy MS.

19.1.1 Short Message Sending Procedure of an Idle MSThis describes the short message sending procedure initiated by an idle MS.19.1.2 Short Message Receiving Procedure of an Idle MSThis describes the short message receiving procedure initiated by an idle MS.19.1.3 Short Message Sending Procedure of a Busy MSThis describes the short message sending procedure initiated by a busy MS.19.1.4 Short Message Receiving Procedure of a Busy MSThis describes the short message receiving procedure initiated by a busy MS.

19.1.1 Short Message Sending Procedure of an Idle MSThis 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

Authentication Request

Authentication Response

Ciphering Mode Command

Ciphering Mode Complete

CP DATA(5)

CP Acknowledge(6)

CP Acknowledge(8)

CP DATA(7)

CM Service Accepted (1)

SABM (SAPI 3)(2)

UA(4)

Establish Indication(SAPI)(3)

MS BTS MSCBSC


SDCCH

Release Procedure

SDCCH

SDCCH

SDCCH

SDCCH

SDCCH

SDCCH

SDCCH

SDCCH

SDCCH

SDCCH

19 Short MessagesHUAWEI BSC6000 Base Station Subsystem



Issue 01 (2008-06-10)

The short message sending procedure initiated by an idle MS is described as follows:

1. The MS sends an SABM frame again, notifying the network side that a user needs toestablish the SMS.

2. The BSC provides a transparent-transmission channel for short message exchange betweenthe MS and the MSC.

In this procedure, the MSC, if possible, sends the BSC an Access Request message for channelallocation. The time for sending the Access Request message is the same as that for an ordinarycall. The BSC provides the SMS either by allocating a new channel or by using the originalSDCCH.

The protocol on point-to-point SMS covers four layers, which are the connection managementlayer (CM), relay layer (RL), transport layer (TL), and application layer (AL). Both the CPDATA message and the CP Acknowledge message shown in Figure 19-1 are transferred at theCM 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.


1. Steps 1 through 4 in the procedure are the random access and immediate assignmentprocedures, in which the BSS assigns a signaling channel to the MS.

2. Steps 5 through 8 are the short message sending procedure.

19.1.2 Short Message Receiving Procedure of an Idle MSThis 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.



19-3

Figure 19-2 Short message receiving procedure of an idle MS

MS BTS MSC

CR(CompleteLayer3 Information(3)

BSC

Paging(1)

PCH

SABM(SAPI 3)(11)

UA(12)

Paging Command(2)Paging Request

Immediate Assignment Prcedure

CC(4)


SDCCHAuthentication Response(6)

SDCCH Cipherding Mode Commnd(7)

SDCCHCipherding Mode Complete(8)

SDCCH CP DATA(9)Establis Request(SAPI 3)(10)

SDCCH

SDCCHEstablish

Confirm(SAPI 3)(13)

CP DATA(14)SDCCH

CP Acknowledge(15)

SDCCH CP DATA(16)SDCCH

SDCCH

CP Acknowledge(17)

Release Procedure


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 andreturns a Paging Response message.

l 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 anEstablishment Request message, requesting for connection establishment. If the BSC




Issue 01 (2008-06-10)

receives an Establishment Confirm message from the MS, the channel for SMS isestablished. The BSC transfers short messages on the transparent channel until theprocedure is complete.

19.1.3 Short Message Sending Procedure of a Busy MSThis 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

CM Service Request(1)

SABM (SAPI 3)(3)

UA(5)

Establish Indication(4)

CP DATA(6)

CP Acknowledge(7)

CP DATA(8)

MS BTS MSCBSC

FACCH

ACTIVE CALL

FACCH

ACTIVE CALL


FACCH

FACCH

SACCH

SACCH

SACCH

SACCH

CP Acknowledge(9)

The short message sending procedure initiated by a busy MS is described as follows:

1. The MS sends the MSC a CM Service Request message on the FACCH. If the MSCresponds with a CM Service Accepted message, a link at the CC layer is established.

2. 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 MSThis 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-5

Figure 19-4 Short message receiving procedure of a busy MS

EstablishRequest(SAPI 3)(2)

CP DATA(6)

CP Acknowledge(9)

CP Acknowledge(7)

CP DATA(8)

SABM (SAPI 3)(3)

UA(4)

CP DATA(1)

MS BTS MSCBSC

ACTIVE CALL

SACCH

FACCH

FACCH

EstablishConfirm (SAPI 3)(5)

SACCH

SACCH

SACCH

ACTIVE CALL

The short message receiving procedure initiated by a busy MS is described as follows:

1. Upon receiving a CP DATA message from the MSC, the BSC establishes a link forreceiving short messages at the RR layer.

2. 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. Based on the classmark reported by the MS, the BSC records whether the MS supportsSMS.

2. Upon receiving short messages from the MS, the BSC checks the Short message uplinkdisabled parameter by choosing Cell Attributes > Call Control > Advanced > CallControl. If the parameter is set to Yes, short messages cannot be sent.

3. Upon receiving short messages from the MSC, the BSC checks the Short message uplinkdisabled parameter by choosing Cell Attributes > Call Control > Advanced > CallControl. If the parameter is set to Yes, short messages cannot be sent.




Issue 01 (2008-06-10)

19.3 Abnormal Cases and Handling Suggestions (ShortMessages)

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 (CaseStudy)This describes the fault, probable causes, and handling suggestions.

19.3.1 Short Message Sending Failure Caused by DisabledAuthentication and Ciphering (Case Study)


DescriptionSome MSs fail to send short messages because the authentication and ciphering function isdisabled.

AnalysisThe short message procedure specified in the GSM protocols involves the authentication andciphering procedure. For some MSs, short message sending fails if no authentication andciphering procedure is involved in the short message procedure.

Handling SuggestionsInitiates an authentication and ciphering procedure on the MSC side.



19-7

20 Cell Broadcast Messages

About This Chapter

The short message service cell broadcast (SMSCB) is similar to the paging station broadcastservice. The operators broadcast messages to the subscribers in the specified areas. Thesubscribers that subscribe to the service receive the messages broadcast by the operators.

20.1 Cell Broadcast Message ProceduresThe cell broadcast procedure comprises the CBC-BSC message procedure and the BSC-BTSmessage 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 handlingsuggestions.

HUAWEI BSC6000 Base Station SubsystemBSS Signaling Analysis Guide 20 Cell Broadcast Messages


20-1

20.1 Cell Broadcast Message ProceduresThe cell broadcast procedure comprises the CBC-BSC message procedure and the BSC-BTSmessage procedure.

20.1.1 CBS-BSC Message ProcedureThis describes the CBC-BSC message procedure.

20.1.2 BSC-BTS Message ProcedureThis describes the BSC-BTS message procedure.

20.1.1 CBS-BSC Message ProcedureThis 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

Write Replace Request(1)

CBC BSC

Report Response(2)


1. The BSC receives a Write Replace Request message sent by the CBC.l If the message is new, the BSC saves the message in the message library.

l If the message is sent for replacing the existing message, the BSC deletes the existingmessage and saves the new message in the message library.

2. The BSC sends the CBC a response message.l If the parameters in the Write Replace Request message are legal, the BSC sends the

CBC a Report Response message.l If the parameters in the Write Replace Request message are illegal, the BSC sends the

CBC a Reject Response message.

Deleting an Existing Message

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

20 Cell Broadcast MessagesHUAWEI BSC6000 Base Station Subsystem



Issue 01 (2008-06-10)

Figure 20-2 Procedure for deleting an existing message

Kill Request(1)

Report Response(2)

CBC BSC


1. The CBC sends a Kill Request message to the BSC.

2. The BSC sends a response message to the CBC.

l If the parameters in the Kill Request message are legal, the BSC deletes the existingmessage and sends a Report Response message to the CBC.

l If the parameters in the Kill Request message are illegal, the BSC sends a RejectResponse 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

Status CBCH Query Request(1)

Status CBCH Query Response(2)

CBC BSC


1. The CBC sends the BSC a Status CBCH Query Request message.

2. The BSC sends the CBC a response message.

l If the parameters in the Status CBCH Query Request message are legal, the BSC sendsthe CBC a Status CBCH Query Response message.

l If the parameters in the Status CBCH Query Request message are illegal, the BSC sendsthe CBC a Reject Response message.



20-3

Querying the Message StatusFigure 20-4 shows the procedure for querying the message status.

Figure 20-4 Procedure for querying the message status

Status Message Query Request(1)

Status Message Query Response(2)

CBC BSC


1. The CBC sends the BSC a Status Message Query Request message.2. The BSC sends the CBC a response message.

l If the parameters in the Status Message Query Request message are legal, the BSC sendsthe CBC a Status Message Query Response message.

l If the parameters in the Status Message Query Request message are illegal, the BSCsends the CBC a Reject Response message.

Resetting a CellFigure 20-5 shows the procedure for resetting a cell.

Figure 20-5 Procedure for resetting a cell

Reset Request(1)

Restart Indication Response(2)

CBC BSC


1. The CBC sends a Reset Request message to the the BSC.2. 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 theCBC a Restart Indication Response message.




Issue 01 (2008-06-10)

l If the CBCH of the specified cell is abnormal (for example, a cell is faulty or notinstalled, or the CBCH is blocked), the BSC sends the CBC a Failure IndicationResponse message.

Setting the DRXFigure 20-6 shows the procedure for setting the discontinuous reception (DRX).

Figure 20-6 Procedure for setting the DRX

Set DRX Request(1)

Set DRX Response(2)

CBC BSC


1. The CBC sends the BSC a Set DRX Request message.2. 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 DRXResponse message to the CBC.

l If the parameters in the Set DRX Request message are illegal, the BSC sends a RejectResponse message to the CBC.

20.1.2 BSC-BTS Message ProcedureThis describes the BSC-BTS message procedure.

WW

The BSC sends the Cell Broadcast Services (CBS) information to the BTS through an SMSBroadcast Command message and specifies the channels to be used by the BTS, as shown inFigure 20-7.



20-5

Figure 20-7 BSC sending an SMS broadcast command message

SMS Broadcast CommandSMS 1(1)

BSC BTS MS

SMS 2(2)

CBCH

CBCH

……

SMS n(3)

CBCH

The BTS reports the load status of the CBCH to the BSC through a CBCH Loading Indicationmessage 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

CBCH LoadingIndication(1)

BSC BTS

20.2 Internal BSC Signaling Procedure (Cell BroadcastMessages)

This describes the internal BSC signaling procedure of the SMSCB.

The internal BSC signaling procedure for cell broadcast messages is described as follows:

1. The cell broadcast function can operate only on the CPUP in the basic frame.

2. When the BSC6000 cell broadcast system operates, the CPU3 obtains the IP address of theCBC from the database and then establishes the communication with the CBC.

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

4. The CPU3 obtains the contents of short messages to be broadcast from the CBC and writesthe contents in the message library. The contents include the number of retransmissionsand the interval of retransmissions.

5. The GXPUM receives the messages sent from the CBC to the BSC, and the CPU3 processesthe messages.

6. After the broadcast message sending timer expires, the CPU3 checks every cell formessages to be broadcast.




Issue 01 (2008-06-10)

l If there are messages to be broadcast, the CPU3 sends the messages to the correspondingGXPUM, and the GEHUB forwards the messages to the corresponding BTS.

l 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

GXPUM

GSCU

GEHUB

GSCU

GEHUB

GMPS

GEPS

20.3 Abnormal Cases and Handling Suggestions (CellBroadcast Messages)

This describes the abnormal cases of cell broadcast messages, probable causes, and handlingsuggestions.

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)This describes the fault, probable causes, and handling suggestions.

DescriptionThe MS fails to receive call broadcast messages.


1. The cell broadcast receive switch of the MS is not turned on and the corresponding channelnumbers are not set.

2. The setting of the IP address in the GXPUM and that in the CBC are different.



20-7

3. The communication between the GXPUM and the CBC is disrupted. If any alarm isgenerated, refer to 102 Disrupted Connection with the CBC

Handling SuggestionsLocate the problem through the message tracing function and the site maintenance function andhandle it as follows:

1. Check whether SMS Broadcast Command messages exist on the Abis interface of therelevant cell.

2. Send a system message in the cell through the site maintenance function and check whetherthe IE CBCH DESP message in System Information Type 4 is correct through interfacetracing.

20.3.2 Cell Not Configured with CBCH (Case Study)This describes the fault, probable causes, and handling suggestions.

Descriptionl The cell is abnormal.

l The CBC cannot perform any operation or the operation fails.

l Cell broadcast messages cannot be sent.

l The MS does not receive any cell broadcast message.

AnalysisThe cause value of the failed signaling is Specified Cell Not Found. The problem lies in that theCBCH of the cell is not configured.

Handling SuggestionsEnsure that the CBCH of a cell is configured. If the CBCH of a cell is not configured, add theCBCH through the BSC6000 Local Maintenance Terminal.




Issue 01 (2008-06-10)

21 GPRS

About This Chapter

This describes the procedure related to PS services, the internal processing procedure, theexceptional procedure, and the handling suggestions.

21.1 GPRS ProcedureThis describes the GPRS procedure. The GPRS procedure consists of TBF related procedure,PDP context related procedure, circuit paging procedure, packet paging procedure, andprocedure of suspending and resuming GPRS services.

21.2 Internal BSC Signaling ProceduresThis describes the internal BSC signaling procedures of the circuit paging and packet paginginitiated 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.

HUAWEI BSC6000 Base Station SubsystemBSS Signaling Analysis Guide 21 GPRS


21-1

21.1 GPRS ProcedureThis describes the GPRS procedure. The GPRS procedure consists of TBF related procedure,PDP context related procedure, circuit paging procedure, packet paging procedure, andprocedure 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 ProcedureThis 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 ProcedureThis describes the downlink TBF release procedure.

21.1.8 GPRS Attach ProcedureThis describes the GPRS attach procedure.

21.1.9 GPRS Detach ProcedureThis describes the GPRS detach procedure.

21.1.10 Routing Area Update ProcedureThis describes the routing area update procedure.

21.1.11 PDP Context Activation ProcedureThis describes the PDP context activation procedure.

21.1.12 PDP Context Deactivation ProcedureThis describes the PDP context deactivation procedure.

21.1.13 PDP Context Modification ProcedureThis describes the PDP context modification procedure.

21.1.14 Circuit Paging ProcedureThis describes the circuit paging procedure that is initiated through the SGSN.

21.1.15 Packet Paging ProcedureThis describes the packet paging procedure.

21.1.16 GPRS Suspension and Resumption ProcedureThis describes the GPRS suspension and resumption procedure.

21 GPRSHUAWEI BSC6000 Base Station Subsystem



Issue 01 (2008-06-10)

21.1.1 Uplink TBF Establishment Procedure (CCCH Phase OneAccess)

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)

Channel request(1) CHAN_REQ(2)

IMM_ASS_CMD(3)Immediate

assignment(4)

RLC data block(with TLLI)(5)

Packet UplinkAck/Nack (with TLLI)(6)

RLC data block(without TLLI)(8)

Packet UplinkAck/Nack (without TLLI)(9)


BTSMS BSC PCU

......



1. The MS sends a packet channel request from the RACH of the CCCH and the BSC sendsthe request to the PCU.

2. The PCU sends on the AGCH an Immediate assignment message to the MS through theBSC. The packet uplink immediate assignment message contains an assigned uplinkchannel and also the TFI and USF of the TBF.

3. The BSS sets the USF on the assigned uplink packet channel, and then the MS sends theuplink RLC data block. After the BSS receives the data block that contains the TLLI of theMS, the BSS responds with Packet Uplink ACK/NACK message that contains the TLLIto solve conflicts.

4. After conflicts are solved, the uplink RLC data block sent by the MS does not contain theTLLI. Each time when the BSS receives 32 RLC data blocks or S1 in the received uplinkRLC data blocks is 1, the Packet Uplink Ack/Nack message is displayed to acknowledgethe received uplink RLC data blocks.



21-3

21.1.2 Uplink TBF Establishment Procedure (CCCH Phase TwoAccess)

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)

Channel request(1)CHAN_REQ(2)

IMM_ASS_CMD(3)Immediateassignment(4)

Packet ResourceRequest(with TLLI)(5)

Packet UplinkAssignment(with TLLI)(6)



Packet Uplink Ack/Nack(without TLLI)(9)


BSCBTSMS PCU

......

The differences between the uplink TBF establishment procedure (CCCH phase one access) andthe uplink TBF establishment procedure (CCCH phase two access) are as follows:

1. The BSS assigns an uplink data block in the packet uplink immediate assignment message.2. The MS sends on the assigned uplink data block a packet resource request message that

contains the TLLI.3. 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 inwhich the MS sends the packet resource request message to solve conflicts.

4. The BSS set the USF on the assigned uplink packet channel, and then the MS sends theuplink RLC data block that does not contain the TLLI.

5. The following procedures are the same as the procedures listed in CCCH phase one access.

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




Issue 01 (2008-06-10)

Figure 21-3 Uplink TBF establishment procedure (PACCH access)

RLC data block(1)

RLC data block(2)

RLC data block(S/P=1)(3)

Packet DownlinkAck/Nack (with ChannelRequest Description)(4)

Packet UplinkAssignment(with TLLI)(5)

RLC data block(6)

BSCBTSMS PCU

......


1. During the transmission of the downlink TBF, if the MS needs to send uplink data, theChannel Request Description is added to the Packet Downlink Ack/Nack message. TheBSS sends on the PACCH of the downlink TBF the packet uplink assignment message thatis marked by the TLLI of the MS.

2. Establishing the transmission channel of the uplink TBF during the transmission of thedownlink TBF does not have conflicts. The BSS set the USF on the assigned uplink packetchannel, and then the MS sends the uplink RLC data block that does not contain the TLLI.

21.1.4 Uplink TBF Release ProcedureThis describes the uplink TBF release procedure.

Figure 21-4 shows the uplink TBF release procedure.



21-5

Figure 21-4 Uplink TBF release procedure

BTSMS BSC PCU

RLC datablock(CV=0)(1)

Packet UplinkAck/Nack(FAI=1)(2)

Packet ControlAck(AB or NB)(3)


1. The MS sets the Countdown Value (CV) to 0 in the last uplink RLC data block. After theBSS 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.

2. The MS receives the Packet Uplink ACK/NACK message and then sends the PacketControl ACK message to release the uplink TBF.

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




Issue 01 (2008-06-10)

Figure 21-5 Downlink TBF establishment procedure (CCCH).

Packet Control Ack(AB)(4)

Packet DownlinkAssignment(6)

RLC data block(7)

RLC data block(S/P=1)(8)

Packet DownlinkAck/Nack(9)

RLC data block(10)

Packet Power Control/Timing Advance(5)

BTSMS BSC PCU

......

IMM ASS CMD(1)Immediate

Assignment(2)

Packet PollingRequest(with TFI)(3)


1. The PCU receives the downlink PDU from the SGSN and then delivers a downlinkimmediate assignment message on the CCCH through the BSC. The message contains adownlink packet channel and the start time of the TFI and the TBF.

2. When the downlink TBF starts, the BSS sends on the PACCH of the downlink TBF thePacket Polling Request message that is marked by the TFI. The MS responds with a packetcontrol acknowledgment message of the ACCESS BURST type. The BSS extracts the timeadvance from AB, notifies the MS through the Packet Power Control/Timing Advancemessage, and sends the packet downlink assignment message to allocate multiple channelsto the MS.

3. If the channels that are allocated to the MS in the immediate assignment message does notmeet the multislot capability of the MS, the PCU actively initiates the reassignmentprocedure.

4. The BSS cuts the downlink PDU into downlink RLC data blocks and sends these blocksto the MS through the allocated downlink packet channel. Each time the BSS sends 20downlink RLC data blocks, the BSS sets the RRBP in downlink RLC data blocks. The MSsends a Packet Downlink Ack/Nack message to acknowledge the downlink RLC datablocks.



21-7

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 TBFestablishment on the uplink PACCH and the downlink TBF establishment on the downlinkPACCH.

Downlink TBF Establishment Procedure on the Uplink PACCHFigure 21-6 shows the downlink TBF establishment procedure on the uplink PACCH.

Figure 21-6 Downlink TBF establishment procedure on the uplink PACCH

RLC data block(6)

RLC data block(7)

RLC data block(3)

Packet Downlink Assignment(Uplink TFI, S/P=1)(4)

Packet ControlAcknowledgement

(AB or NB)(5)

RLC data block(1)

RLC data block(2)

PCUBSCBTSMS...


1. During the uplink TBF transmission, the PCU receives the downlink LLC PDU from theSGSN and directly sends on the PACCH of the uplink TBF the packet downlink assignmentmessage that is marked with the TFI of the uplink TBF. The RRBP is set in the message.

2. The MS responds with a packet control acknowledgment message at a position specifiedby the RRBP. Whether the type of the packet control acknowledgment message is AB orNB is determined by SI13.

3. The BSS receives the packet control acknowledgment message, notifying that the downlinkTBF is successfully established and the downlink RLC data block can be sent.

Downlink TBF Establishment Procedure on the Downlink PACCHAfter the downlink TBF is normally released, the MS continues to monitor the packet channelof 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.




Issue 01 (2008-06-10)

Figure 21-7 Downlink TBF establishment procedure on the downlink PACCH

RLC data block(1)

RLC data block(2)

RLC data block(FBI=1, S/P=1)(3)

Packet DownlinkAck/Nack(FAI=1)(4)

RLC data block(8)

Packet DownlinkAssignment(withDownlink TFI)(5)

RLC data block(7)

Packet ControlAcknowledgement

(AB or NB)(6)

BSCBTSMS PCU

Start T3193Start T3192

Stop T3193

Stop T3192

...


1. After the downlink TBF is normally released, the PCU receives the downlink PDU fromthe SGSN before timer T3193 expires. The BSS sends on the PACCH of the originaldownlink TBF the packet downlink assignment message that is marked by the TFI of theoriginal 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 timerT3192 for the MS.

2. The MS responds with a packet control acknowledgment message at a position specifiedby the RRBP. Whether the type of the packet control acknowledgment message is AB orNB is determined by SI13.

3. The BSS receives the packet control acknowledgment message, notifying that the downlinkTBF is successfully established and the downlink RLC data block can be sent.

4. If timer T3193 has expired when the downlink PCU arrives, the BSS establishes thedownlink TBF on the CCCH. For the detailed procedure, see 21.1.5 Downlink TBFEstablishment Procedure (CCCH).

21.1.7 Downlink TBF Release ProcedureThis describes the downlink TBF release procedure.

Figure 21-8 shows the downlink TBF release procedure.



21-9

Figure 21-8 Downlink TBF release procedure

MS BSC PCUBTS

RLC Data Block(FBI=1,S/P=1)(1)

Packet DownlinkAck/Nack(FAI=1)(2)


1. The BSS set the Final Block Indicator (FBI) to 1 in the last downlink RLC data block. Ifthe MS has collected all the downlink RLC data blocks, the Packet Downlink Ack/Nackmessage with FAI as 1 is sent. Otherwise, the Packet Downlink Ack/Nack with FAI as 0is sent to ask the BSS to resend unreceived data blocks.

2. The downlink TBF is complete after the BSS receives the Packet Downlink Ack/Nackmessage in which FAI is set to 1.

21.1.8 GPRS Attach ProcedureThis describes the GPRS attach procedure.

GPRS Attach Function

After the MS completes the GPRS attach procedure, the MS is in the READY status and theMM context of the MS is established between the MS and the SGSN. Hereafter, the MS activatesthe 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 beachieved through the combined RA/LA update procedure.

l If the network operation mode is II or III, or the MS is not attached to the GPRS, IMSIattach 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 theMS 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 theIMSI detached status before performing GPRS attach.

A pure GPRS attach procedure is simple. Figure 21-9 shows the GPRS attach procedure bytaking the combination of GPRS/IMSI attach as an example.




Issue 01 (2008-06-10)

Figure 21-9 Combined GPRS/IMSI attach procedure

CancelLocationAck(17)

CancelLocation(16)

UpdateLocation(15)

UpdateLocationAck(20)

InsertSubscriberData(18)

InsertSubscriber

Data Ack(19)

InsertSubscriberData(11)


CancelLocation(9)

IdentityResponse(5)

IdentificationResponse(3)

IdentificationRequest(2)

Attach Request(1)

IMEI Check(7)

IdentityRequest(4)

Authentication(6)

UpdateLocation(8)

Location UpdateRequest(14)

Location UpdateAccept(21)

Update LocationAck(13)

InsertSubscriber

Data Ack(12)

MS BSS SGSN(new) SGSN(old) GGSN HLREIR MSC/VLR(old)MSC/VLR(new)

AttachComplete(23)

AttachAccept(22)

TMSIReallocation

Complete(24)


1. If the identity of an MS is P-TMSI and moreover the SGSN where the MS resides haschanged after the MS detaches GPRS, the new SGSN requests the IMSI of the MS fromthe old SGSN.

2. The new SGSN sends an Identification Request message to the old SGSN and requires theresponse from the old SGSN. If the old SGSN does not successfully respond, the new SGSNasks the MS to report its IMSI.

3. After the SGSN sends the Identity Request message to the MS, the SGSN requires theresponse from the MS.l If the MML context of the MS is not available on the network, this process is mandatory.

l In other cases, this process is optional.

4. Authentication and IMEI identity check are optional.



21-11

5. the SGSN where the MS resides has changed after detaching GPRS or the MS is attachedfor the first time, the SGSN needs to notify the HL of the location update of the MS. TheHLR needs to send the data subscribed by the MS to the SGSN.

6. 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 Gsinterface, the SGSN needs to initiate location update towards the MSC/VLR (new) so thatassociation between the SGSN and the MSC/VLR is maintained. Steps 15 through 20 referto inter-MSC location update.

7. If P-TMSI/TMSI has changed, the MS checks whether it has receives the TMSI.8. If TMSI has changed, the SGSN checks with the VLR whether the MS receives the new

TMSI.

21.1.9 GPRS Detach ProcedureThis describes the GPRS detach procedure.

GPRS Detach FunctionThrough the GPRS detach procedure, an MS disconnects the GPRS/GSM network. After theMS is detached from the GPRS network, the MS enters the MM IDLE state.

Detach types consist of:

l IMSI detach

l GPRS detach

l Combined IMSI/GPRS detachNOTE

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

l Implicit detach means that detach is caused by the expiration of a ready timer, or anirrecoverable 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 isavailable.

l The MS that is attached to the GPRS can initiate IMSI detach through the SGSN andbesides. In addition, the MS can detach the IMSI when detaching from the GPRS network.

l The MS that is not attached to the GPRS can detach the IMSI by using the same detachprocedure as the GSM IMSI detach procedure.

The GPRS detach procedure is generally initiated by the MS. The network can also initiate theGPRS detach procedure.

GPRS Detach ProcedureThe following part illustrates the detach procedure initiated by different NEs.

l MS initiating detachFigure 21-10 shows the detach procedure initiated by the MS.




Issue 01 (2008-06-10)

Figure 21-10 MS initiating the GPRS detach procedure

IMSI DetachIndication(4)

Delete PDP ContextResponse(3)

DetachRequest(1) Delete PDP Context

Request(2)

DetachAccept(6)

MS BSS GGSNSGSN MSC/VLR

GPRS DetachIndication(5)


1. The MS sends a Detach Request message to the SGSN. The message contains thedetach type and disconnection.

2. For GPRS detach, after the SGSN receives the Detach Request message, the SGSNsends a Delete PDP Context Request to the GGSN. The GGSN responds to the SGSNwith a Delete PDP Context Response message.

3. For IMSI detach, the SGSN sends an IMSI Detach Indication message to the MSC/VLR.

4. For GPRS detach, the SGSN sends a GPRS Detach Indication message to the MSC/VLR.

5. The SGSN sends detach acknowledgment to the MS.

l SGSN initiating detach

Figure 21-11 shows the detach procedure initiated by the SGSN.

Figure 21-11 SGSN initiating the GPRS detach procedure

Delete PDPContext

Response(3)

DetachRequest(1) Delete PDP

ContextRequest(2)

Detach Accept(5)

MS BSS GGSNSGSN MSC/VLR





21-13

1. The SGSN sends a Detach Request message to the MS. The message contains thedetach type.

2. The SGSN sends a Delete PDP Context Request message to the GGSN. Then, theGGSN responds to the SGSN with a Delete PDP Context Response message.

3. The SGSN sends a GPRS Detach Indication message to the MSC/VLR.4. The MS sends a Detach Accept message to the SGSN.

l HLR initiating detach procedureTo fulfill the demand of the telecom operator, the HLR can request the deletion of MM andPDP context of a user from the SGSN. Figure 21-12 shows the detach procedure initiatedby the HLR.

Figure 21-12 HLR initiating the GPRS detach procedure

HLRMS BSS GGSNSGSN MSC/VLR

Delete PDPContext Request(3)

CancelLocation(1)


DetachRequest(2)

Cancel LocationAck(7)


DetachAccept(6)


1. The HLR sends a Cancel Location message to the SGSN. The message contains theIMSI and the cancellation type.

2. After receiving the Cancel Location message, the SGSN sends the MS a DetachRequest message that contains the detach type.

3. The SGSN sends a Delete PDP Context Request message to the GGSN. The GGSNresponds to the SGSN with a Delete PDP Context Response message.

4. The SGSN sends a GPRS Detach Indication message to the MSC/VLR.5. The MS sends a Detach Accept message to the SGSN.6. The SGSN sends a Cancel Location Ack message to the HLR.

21.1.10 Routing Area Update ProcedureThis describes the routing area update procedure.

When an MS in the GPRS attach state enters a new routing area, or the timer of periodic routingarea update for the MS expires, the MS initiates the routing area update procedure. The SGSNchecks whether the message requesting the routing area update carries the identification of theold 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 updateprocedure is always initiated within the SGSN.




Issue 01 (2008-06-10)

Intra-SGSN Routing Area UpdateFigure 21-13 shows the intra-SGSN routing area update procedure.

Figure 21-13 Intra-SGSN routing area update procedure

Routing Area UpdateRequest(1)

Routing Area UpdateAccept(3)

Security Functions(2)

MS BSS SGSN

Routing Area UpdateComplete(4)


1. The MS sends a Routing Area Update Request message to the SGSN. The message containsthe original RAI, original P-TMSI signature, and update type. The BSS adds the CGI ofRAN and LAC to the message.

2. Starting the security functions is optional.3. 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. Thismessage contains the signature of P-TMSI and P-TMSI.

4. If a new P-TMSI is assigned, the MS displays a Routing Area Update Complete message.This message contains P-TMSI.

NOTE

If the routing area update procedure is unsuccessful and the number of failures exceeds the maximumallowed times, or the SGSN displays a Routing Area Update Reject message, then the MS enters the IDLEstate.

Inter-SGSN Routing Area UpdateFigure 21-14 shows the inter-SGSN routing area update procedure.



21-15

Figure 21-14 Inter-SGSN routing area update procedure

Update PDP ContextRequest(7)

Update PDP ContextResponse(8)

UpdateLocation(9)

Update LocationAck(14)

Routeing AreaUpdate

Accept(15)

CancelLocation(10)


Insert SubscriberData Ack(13)

Insert SubscriberData(12)

Routeing AreaUpdate

Complete(16)

MS BSS new SGSN HLRGGSNold SGSN

SGSN ContextResponse(3)Security

Functions(4)

Routeing AreaUpdate Request(1) SGSN Context

Request(2)

Forward Packets(6)

SGSN ContextAcknowledge(5)


1. The MS sends a Routing Area Update Request message to a new SGSN. The messagecontains the original RAI, original P-TMSI signature, and update type. The BSS adds theCGI of RAN and LAC to the message.

2. The new SGSN sends a SGSN Context Request message to the old SGSN so that the MMcontext and PDP context of the MS are obtained. This message contains the original RAI,TLLI, original P-TMSI signature, and new SGSN address.

3. Perform the encryption function, optional.

4. 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 SGSNlabels information such as the MSC/VLR associated information in the MS context asinvalid. If the previous authentication does not pass, the new SGSN should reject the routingarea update request initiated by the MS, and the old SGSN operates as before.

5. After receiving the SGSN Context Acknowledge message from the new SGSN, the oldSGSN forwards the related N-PDU to the new SGSN within a certain period.




Issue 01 (2008-06-10)

6. The new SGSN sends an Update PDP Context Request message to the GGSN. This messagecontains the new SGSN address, TID, and negotiated QoS. The GGSN responds to the newSGSN with an Update PDP Context Response message that contains TID.

7. The new SGSN sends an Update Location message to the HLR. This message contains theSGSN numbering, SGSN address, and IMSI.

8. The HLR sends a Cancel Location message to the old SGSN. This message contains theTMSI and the cancellation type. The old SGSN deletes corresponding MM and PDPcontexts and then responds to the HLR with a Cancel Location Ack message that containsthe IMSI.

9. The HLR sends an Insert Subscriber Data to the new SGSN. This message contains IMSIand GPRS subscription data. The new SGSN creates a corresponding MM context and thenresponds to the HLR with an Insert Subscriber Data Ack message that contains IMSI.

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 messageto 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 containsP-TMSI and LLC.

21.1.11 PDP Context Activation ProcedureThis describes the PDP context activation procedure.

The PDP context activation procedure is classified into two types: MS-requested PDP contextactivation procedure and network-requested PDP context activation procedure.

MS-Requested PDP Context Activation ProcedureFigure 21-15 shows the MS-requested PDP context activation procedure.

Figure 21-15 MS-requested PDP context activation procedure

GGSN

Activate PDP ContextAccept(5)

Create PDP ContextResponse(4)

Create PDP ContextRequest(3)

Activate PDP ContextRequest(1)

SGSNMS



1. The MS sends an Activate PDP Context Request (NSAPI, TI, PDP Type, APN, QosRequested, PDP Configuration Options) message to the SGSN.

2. Security functions may be executed.



21-17

3. The SGSN tries to derive the GGSN address by using the APN selection criteria based onthe activation type, PDP address, and APN provided by the MS, and then checks whetherthe 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.l 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 ContextRequest (PDP Type, PDP Address, APN, Qos Negotiated, Selection Mode, PDPConfiguration 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, QosNegotiated, Charging Id, Cause) message to the SGSN.

l If the negotiated QoS is not met, the GGSN sends a reject message to the SGSN. TheQoS profiles are configured by the GGSN operator.

5. After receiving the Create PDP Context message from the GGSN, the SGSN inserts theNSAPI, GGSN address, and dynamic PDP address into the PDP context, selects RadioPriority based on Qos Negotiated, and then returns an Activate PDP Context Accept (PDPType, 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 theMS, and to start charging.

Network-Requested PDP Context Activation ProcedureFigure 21-16 shows the network-requested PDP context activation procedure.

Figure 21-16 Network-requested PDP context activation procedure

MS SGSN GGSN

PDU NotificationRequest(4)

HLR

PDP PDU(1)Send Routeing Info

for GPRS(2)

Send Routeing Infofor GPRS Ack(3)

Request PDPContext

Activation(6) PDP ContextActivation

procedure(7)

PDU NotificationResponse(5)


1. After receiving a PDP PDU from the external PDN, the GGSN stores the PDP PDU andsends a Send Routeing Info for GPRS (IMSI) message to the HLR.




Issue 01 (2008-06-10)

2. If the HLR determines that the request can be served, it returns a Send Routeing Info forGPRS Ack (IMSI, SGSN Address, Mobile Station Not Reachable Reason) message to theGGSN. If the HLR determines that the request cannot be served (for example, IMSIunknown in HLR), the HLR shall send a Send Routeing Info for GPRS Ack (IMSI, MAPError Cause) message.

3. After receiving the Send Routeing Info for GPRS Ack message from the HLR, the GGSNsends a PDU Notification Request (IMSI, PDP Type, PDP Address) message to the SGSNindicated by the HLR. Then the SGSN returns a PDU Notification Response message tothe GGSN.

4. The SGSN sends a Request PDP Context Activation (TI, PDP Type, and PDP Address)message to the MS.

5. The subsequent procedure is the same as the MS-requested PDP context activationprocedure. For details, refer to the MS-requested PDP context activation procedure.

21.1.12 PDP Context Deactivation ProcedureThis describes the PDP context deactivation procedure.

The procedure of PDP context deactivation can be initiated by different network elements:

l The procedure of PDP context deactivation initiated by the MS

l The procedure of PDP context deactivation initiated by the SGSN

l The procedure of PDP context deactivation initiated by the GGSN

Procedure of the PDP Context Deactivation Initiated by the MSFigure 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

GGSN

Deactivate PDPContext Accept(5)


Delete PDP ContextRequest(3)

Deactivate PDP ContextRequest(1)

SGSNMS



1. The MS sends a Deactivate PDP Context Request (TI) message to the SGSN.2. Security functions may be executed.3. 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 PDPaddress, and returns a Delete PDP Context Response (TID) message to the SGSN.



21-19

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

GGSN

Delete PDP ContextRequest(1)

SGSN


Deactivate PDPContext Accept(4)

Deactivate PDPContext Request(3)

MS


1. The SGSN sends a Delete PDP Context Request (TID) message to the GGSN. Afterreceiving this message, the GGSN removes the PDP context, releases the dynamic PDPaddress, and sends a Delete PDP Context Response (TID) message to the SGSN.

2. The SGSN sends a Deactivate PDP Context Request message (TI) to the MS.3. The MS removes the PDP context, and then returns a Deactivate PDP Context Accept

message to the SGSN.

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

GGSN

Delete PDP Context Request(1)

SGSN

Delete PDP Context Response(4)

Deactivate PDP Context Accept(3)

Deactivate PDP Context Request(2)

MS


1. The GGSN sends a Delete PDP Context Request (TID) message to the SGSN.




Issue 01 (2008-06-10)

2. The SGSN sends a Deactivate PDP Context Request (TI) message to the MS. Afterreceiving this message, the MS removes the PDP context, and then returns a DeactivatePDP Context Accept message to the SGSN.

3. The SGSN returns a Delete PDP Context Response (TID) message to the GGSN. Afterreceiving this message, the GGSN releases the dynamic PDP address and the correspondingPDP context.

21.1.13 PDP Context Modification ProcedureThis describes the PDP context modification procedure.

The SGSN can initiate the PDP context modification to modify the parameters in the PDPcontext, such as QoS Negotiated and Radio Priority. Figure 21-20 shows the modificationprocedure.

Figure 21-20 Procedure of the PDP context modification initiated by the SGSN

Modify PDP ContextAccept(4)

Update PDP ContextResponse(2)

Update PDP ContextRequest(1)

Modify PDP ContextRequest(3)

SGSN GGSNMS


1. The SGSN sends a Update PDP Context Request (TID, QoS Negotiated) message to theGGSN.

2. 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.l 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 PDPContext Response (TID, QoS Negotiated, Radio Priority) message to the SGSN. If theQoS Negotiated cannot be met, the GGSN rejects the request.

3. After receiving the Update PDP Context Response message from the GGSN, the SGSNsends a Modify PDP Context Request (TID, QoS Negotiated, Radio Priority) message tothe MS.

4. After receiving the Modify PDP Context Request message from the SGSN, the MSresponds as follows: If the MS accepts the new QoS Negotiated and TI, it returns a ModifyPDP Context Accept message to the SGSN. If the MS does not accept the new QoSNegotiated and TI, it deactivates the PDP context, with the reject cause of QoS not accepted.

21.1.14 Circuit Paging ProcedureThis describes the circuit paging procedure that is initiated through the SGSN.



21-21

If an MS is attached to both the GPRS network and the GSM network and besides networkoperation mode I is used, the MSC/VLR initiates the circuit paging procedure through the SGSN.

l If an MS is in the STANDBY status, paging is performed in routing areas.

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

Paging Response(4) SCCP ConnectionRequest (Paging

Response)(5)

Page(1)

Paging Request(3)

Paging Request(2)

MS BSS SGSN MSC/VLR

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. Channelrequirement indicates which types of CS channels of the MS need to be requested in theresponse message. VLR TMSI and channel requirement are optional parameters. Priorityis a parameter determining the priority of circuit switched paging. The SGSN maps priorityto QoS.

2. 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 inthe READY status, or a routing area of an MS in the STANDBY status.

3. The BSS interprets the received paging request message as the radio paging requestmessage of each cell. If the BSS assigns dedicated radio resources to the MS to be pagedin 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 appropriatepaging channels The message contains VLR TMSI/IMSI and channel requirement.

4. On receiving the paging request message of CS services, the MS responds to the messageif the request is accepted. Later, the MS adheres to the process of CS paging response. Thisprocess contains random access, immediate assignment, and paging response.

5. After the BSS receives the paging response message, the BSS sends the message to theMSC. Then, the MSC stops the paging response timer.

21.1.15 Packet Paging ProcedureThis describes the packet paging procedure.




Issue 01 (2008-06-10)

When the network side wants to send downlink data to an MS, the SGSN initiates packet pagingto locate the MS. Figure 21-22 shows the procedure of packet paging.

Figure 21-22 Procedure of packet paging

MS BSC PCU SGSN

PS paging ReqPDU(1)Page Req(2)

Paging Req(3)

Channel Request(4)Channel Req(5)

IMM_ASS CMD(6)ImmediateAssigment(7)

RLC Data block(TLLI,CV=0)(8)

UL PDU(9)Packet Uplink

Ack/Nack(FAI=1)(10)DL PDU(11)

Packet DL Assigment(Uplink TFI,S/P=1)(12)

Packet Control Ack(ABor NB)(13)

Packet Control Ack(ABor NB)(14)

RLC Data Block(15)

BTS

RLC Data Block(16)

...


1. The SGSN sends the PS paging Req PDU to the PCU through the Gb interface. The PCUtransforms the PDU into a Packet Paging Request message and then sends the message onthe 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 establishmentprocedure, sends the paging response packet to the PCU in data format over the Uminterface. The PCU then forwards the packet to the SGSN.

3. After receiving the paging response message, the SGSN processes the message and startstransmitting downlink data, thus initiating the downlink TBF establishment procedure.

21.1.16 GPRS Suspension and Resumption ProcedureThis describes the GPRS suspension and resumption procedure.

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



21-23

Figure 21-23 GPRS suspension and resumption procedure

SUSPEND(5)Suspend PDU(6)

DL PDU(1)RLC data block(2)

GPRSsuspension(4)

SuspendAck/Nack(7)

SUSPEND ACK(8)

RESUME(9)Resume PDU(10)

ResumeAck/Nack(11)

RESUME ACK(12)ChannelRelease (R)

(13) DL PDU(14)

DL PDU(15)Routing Area

UpdatingProcedure(16)

SGSNPCUBSCBTSMS

...

Dedicated ModeEntered(3)

MSC/VLR


1. The MS in the packet transfer mode enters the dedicated mode. The MS sends an RRSuspend (TLLI, RAI) message to the PCU through the BSC, indicating that the ongoingPS service is to be suspended and the services in dedicated mode are to be started. The PCUmay terminate any ongoing GPRS traffic for this TLLI.

2. The PCU sends a Suspend (TLLI, RAI) message to the SGSN, notifying the SGSN that theongoing PS service is to be suspended. The SGSN stops transmitting PDU to the MS, savesthe current PS service state, and returns a Suspend Ack message to the PCU.

3. After receiving the Suspend Ack message, the PCU notifies the BSC to start dedicatedservice, and saves the TLLI and RAI of the MS so that the MS can request the SGSN toresume the GPRS when it no longer works in dedicated mode. The MS starts the dedicatedservice.

4. Upon detection of the completion of dedicated service, the BSC gets ready to release theCS service channel, and notifies the PCU of the current location of the MS. If the PCU canrequest the SGSN to resume the GPRS, it sends a Resume (TLLI, RAI) message to theSGSN, requesting the SGSN to resume the PS service, and reports the current MS locationto the SGSN.

5. The SGSN returns a Resume Ack message to the PCU to confirm the resumption, and startsto send PDUs.




Issue 01 (2008-06-10)

6. The PCU notifies the BSC to resume the PS service. The BSC releases the resources beingoccupied in dedicated mode, and sends a Channel Release (Resume) message to the MS tonotify the MS whether to resume the PS service. The Resume message indicates whetherthe request from the BSS for the SGSN to resume the GPRS of the MS is successful, thatis, whether the BSS has received the Resume Ack message before sending the ChannelRelease message.

NOTE

If the MS does not receive the Channel Release (Resume) message before ending the dedicated mode, orif the Channel Release (Resume) message indicates that the BSS fails to request the SGSN to resume theGPRS, the MS sends a routing area updating request message to the SGSN to resume the GPRS. TheSGSN 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 ProceduresThis describes the internal BSC signaling procedures of the circuit paging and packet paginginitiated by the packet domain in the case of built-in PCU.

Circuit Paging ProcedureThe circuit paging can be initiated by the packet domain only when the Network OperationMode is set to Network Operation Mode I.

The VLR sends the CS paging message to the SGSN through the Gs interface. The SGSN thensends 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. The BSC obtains the list of target paging cells in the NSE according to the BVCI and pagingarea.

2. If the paged MS has a PS connection, the BSC sends the paging message on the PACCHof the cell where the MS camps.

3. If the paged MS does not have a PS connection, the paging message is sent as follows:l If the target cell is configured with the PCCCH, the paging message is sent on the PPCH.

l In other cases, the paging message is sent on the PCH.

Packet Paging ProcedureThe PS paging message sent from the SGSN to the BSC contains the IMSI, BVCI, and pagingarea. The BSC processes the PS paging as follows:

1. The BSC obtains the list of target paging cells in the NSE according to the BVCI and pagingarea.

2. If the paged MS has a PS connection, the BSC sends the paging message on the PACCHof the cell where the MS camps.

3. 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.l 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 issent on the PCH.



21-25

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 andobserving signaling on the Pb interface, and how to locate failure by checking the failureinformation.

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 andobserving signaling on the Pb interface, and how to locate failure by checking the failureinformation.

The PCU cell startup procedure shows the signaling procedure between the PCU and BSC onthe Pb interface when a GPRS cell starts up. You can check whether the initialization of theGPRS cell is normal by tracing and observing the signaling on the Pb interface, and know thecell-related information by checking the message explanation information in the signaling. Youcan 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 thePCU starts the cell.




Issue 01 (2008-06-10)

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. The PCU initializes the cell. It sends a PCU_BSC_CELL_RESET message to the BSCthrough the Pb interface.

2. After receiving a BSC_PCU_CELL_RESET_ACK message from the BSC, the PCU sendsa PCU_BSC_CELL_CONFIG_REQ message to the BSC. The cell configuration obtainingprocedure is started.

3. The BSC sends a BSC_PCU_CELL_INFO and a BSC_PCU_CHAN_INFO message tothe PCU. The PCU returns a PCU_BSC_CELL_INFO_CNF and aPCU_BSC_CELL_INFO_CNF message. The BSC sends cell information and channel



21-27

information messages to the PCU in succession. Each message is sent after the BSC receivesthe acknowledgement of the previous message from the PCU.

4. After all the cell configuration messages and channel configuration messages are sent, andthe acknowledgement of the last message is received, the BSC sends aBSC_PCU_CELL_CONFIG_ACK message to the PCU. The cell configuration obtainingprocedure is complete.

5. The PCU sends a PCU_BSC_PDCH_REQ message to the BSC through the Pb interfaceto request fixed channels. The PCU receives a BSC_PCU_PDCH_REQ_ACK messagefrom the BSC. The PCU requests multiple channels simultaneously.

The above is a normal cell startup procedure. Usually, a abnormal procedure refers to a procedurethat is unable to complete or appears with a NACK message. The problem can be located byanalyzing 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 cellfails. Initialize the local cell after other cells are initialized.

– Timeout when waiting for the acknowledgement message of the BSC configurationobtaining: the initialization of the local cell fails. Initialize the local cell after other cellsare initialized.

– Timeout when waiting for the acknowledgement message in other steps: continue withthe rest steps until the initialization is complete.

l A NACK message is received.

The BSC may return a BSC_PCU_CELL_CONFIG_NACK message after receiving aPCU_BSC_CELL_CONFIG_REQ message from the PCU. The proboble causes are asfollows:

– 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 cellinitialization is no longer performed. For the cause that the BSC is resetting the cell orother 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 aPCU_BSC_PDCH_REQ message from the PCU. The PCU continue with the rest stepsuntil the initialization completes. The cause value of the NACK message can beanalyzed by checking the detail information of the corresponding message.

21.3.2 GPRS Service Access Not Allowed (Case Study)This describes the fault, probable causes, and handling suggestions.

Description

If an external PCU is used, GPRS services in a cell cannot operate. After the GPRS performancemeasurement result is analyzed, it is found that the the number of packet immediate assignmentrequests in a cell is more than 10 and the number of successful packet immediate assignmentsis 0.




Issue 01 (2008-06-10)

AnalysisOn 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 thatthe PCU can obtain cell-related attributes again. After the PCU performs the cell reset procedureon the Pb interface, the PCU needs to request the PDCH from the BSC. The BSC can assign thePDCH to the PCU after the BTS approves the assignment. If the uplink frequency scanning isstarted on the PDCH when the BTS handles the message sent by the BSC for setting PDCHattributes, the BTS regards that it is unsuitable to set the channel to PDCH and displays theNACK message. As a result, the PCU fails to obtain the PDCH and cannot provide GPRSservices.

Till now, the main flow of cell resetting is complete. A packet system message of the cell canstill be normally sent. Therefore, traffic measurement of the BSC indicates there is a packetaccess request. In the PCU, however, the number of successful packet accesses is 0. After theBTS is reset, channels are reselected to scan frequencies. If the system selects the frequencyscanning of TRXs without the PDCH, this problem does not occur temporarily.

Conclusion

The BTS has unreasonable requirement balance between the GPRS services and the frequencyscanning 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.

Handling SuggestionsDo not register cell frequency scanning traffic measurement on the TRX that is configured withthe PDCH, if not required. In later BSC versions, some improvements have been made and thislimitation does not exist.



21-29

HUAWEI BSC6000 Base Station Subsystem BSS Signaling Analysis Guide A Message Interpretation

Issue 01 (2008-06-10) Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd A-1

A 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 Reference

Assignment Request Assignment Request

Assignment Complete Assignment Complete

Assignment Failure Assignment Failure

Handover Request Handover Request

Handover Request Acknowledge Handover Request Acknowledge

Handover Required Handover Required

Handover Required Reject Handover Required Reject

Handover Command Handover Command

Handover Complete Handover Complete

Handover Failure Handover Failure

Handover Performed Handover Performed

Paging Paging

Clear Request Clear Request

A Message Interpretation HUAWEI BSC6000 Base Station Subsystem


A-2 Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd Issue 01 (2008-06-10)


Clear Command Clear Command

Classmark Request Classmark Request

Classmark Update Classmark Update

Cipher Mode Command Cipher Mode Command

Cipher Mode Complete Cipher Mode Complete

Cipher Mode Reject Cipher Mode Reject

Complete Layer 3 Information 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 Reference Direction Type Length

Message Type 1.2.1 MSC-BSS M 1

Channel Type 1.2.2 MSC-BSS M 5–10

Layer 3 Header Information 1.2.3 MSC-BSS O (3) 4

Priority 1.2.4 MSC-BSS O 3

Circuit Identity Code 1.2.5 MSC-BSS O (1) 3

Downlink DTX Flag 1.2.6 MSC-BSS O (2) 2

Interference Band To Be Used 1.2.7 MSC-BSS O 2

Classmark Information 2 1.2.8 MSC-BSS O (4) 4–5

Group Call Reference 1.2.9 MSC-BSS O (5) 3–8

Talker Flag 1.2.10 MSC-BSS O (6) 1

Configuration Evolution Indication

1.2.42 MSC-BSS O (7) 2

LSA Access Control Suppression

1.2.11 MSC-BSS O (8) 2




Service Handover 1.2.38 MSC-BSS O (9) 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


Message Type 1.2.1 BSS-MSC M 1

RR Cause 1.2.12 BSS-MSC O 2

Circuit Identity Code 1.2.5 BSS-MSC O (4) 3

Cell Identifier 1.2.13 BSS-MSC O (1) 3–10

Chosen Channel 1.2.14 BSS-MSC O (3) 2

Chosen Encryption Algorithm 1.2.15 BSS-MSC O (5) 2

Circuit Pool 1.2.16 BSS-MSC O (2) 2





Speech Version (Chosen) 1.2.17 BSS-MSC O (6) 2

LSA Identifier 1.2.18 BSS-MSC O (7) 5


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 A-interface 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



Cause 1.2.19 BSS-MSC M 3–4



Circuit Pool List 1.2.20 BSS-MSC O (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 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



Channel Type 1.2.2 MSC-BSS M 5–10

Encryption Information 1.2.21 MSC-BSS M (1) 3-n

Classmark Information 1 Or Classmark Information 2

1.2.22 1.2.8

MSC-BSS MSC-BSS

M# M (6)

2 4–5

Cell Identifier (Serving) 1.2.13 MSC-BSS M (20) 5–10

Priority 1.2.4 MSC-BSS O 3

Circuit Identity Code 1.2.5 MSC-BSS O (7) 3

Downlink DTX Flag 1.2.6 MSC-BSS O (3) 2

Cell Identifier (Target) 1.2.13 MSC-BSS M (17) 3–10

Interference Band To Be Used 1.2.7 MSC-BSS O 2

Cause 1.2.19 MSC-BSS O (9) 3–4

Classmark Information 3 1.2.23 MSC-BSS O (4) 3–14

Current Channel type 1 1.2.24 MSC-BSS O (8) 2





Speech Version (Used) 1.2.17 MSC-BSS O (10) 2

Group Call Reference 1.2.9 MSC-BSS O (5) 3–8

Talker Flag 1.2.10 MSC-BSS O (11) 1

Configuration Evolution Indication 1.2.27 MSC-BSS O (12) 2

Chosen Encryption Algorithm (Serving) 1.2.15 MSC-BSS O (2) 2

Old BSS to New BSS Information 1.2.26 MSC-BSS O(13) 2–n

LSA Information 1.2.25 MSC-BSS O(14) 3+4n

LSA Access Control Suppression 1.2.11 MSC-BSS O (15) 2

Service Handover 1.2.38 MSC-BSS O (21) 3

IMSI 1.2.39 MSC-BSC O (16) 3–10

Source RNC to Target RNC Transparent Information (UMTS)

1.2.40 MSC-BSS O (18) n–m

Source RNC to Target RNC Transparent Information (cdma2000)

1.2.41 MSC-BSS O (19) n–m


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.



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.


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




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


Message Type 12.1 BSS-MSC M 1

Layer 3 Information 1.2.3 BSS-MSC M (1) 11–n





Circuit Identity Code 1.2.5 BSS-MSC O (3) 3



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.



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




Response Request 1.2.28 BSS-MSC O 1

Cell Identifier List (Preferred)

1.2.29 BSS-MSC M 2n+3 to 7n+3


Current Channel Type 1 1.2.24 BSS-MSC O (2) 2

Speech Version (Used) 1.2.17 BSS-MSC O (3) 2

Queuing Indicator 1.2.30 BSS-MSC O 2

Old BSS to New BSS Information 1.2.26 BSS-MSC O 2–n

Source RNC to target RNC transparent information (UMTS)

1.2.40 BSS-MSC O (5) 3–m

Source RNC to target RNC transparent information (cdma2000)

1.2.41 BSS-MSC O (6) n–m


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.


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

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



Cause 1.2.19 MSC-BSS M 3–4


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



Layer 3 Information 1.2.31 MSC-BSS M (1) 11–n

Cell Identifier 1.2.13 MSC-BSS O 3–10

The Layer 3 Information carries a Handover Command message on the radio interface.



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




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







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.


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




Cell Identifier 1.2.13 BSS-MSC M 3–10






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.



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



IMSI 1.2.32 MSC-BSS M 3–10

TMSI 1.2.33 MSC-BSS O (1) 6

Cell Identifier List 1.2.29 MSC-BSS M 3 to 3+7n

Channel Needed 1.2.34 MSC-BSS O (2) 2

eMLPP Priority 1.2.35 MSC-BSS O (3) 2


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





Radio interface message failure




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



Layer 3 Header Information 1.2.3 MSC-BSS O (1) 4

Cause 1.2.19 MSC-BSS M 3–4

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.


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





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


Message Type 1.2.1 Both M 1

Classmark Information Type 2 1.2.8 Both M 4–5

Classmark Information Type 3 1.2.23 Both O (1) 3–14

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



Layer 3 Header Information

1.2.3 MSC-BSS O (1) 4

Encryption Information 1.2.21 MSC-BSS M 3–n

Cipher Response Mode 1.2.36 MSC-BSS O 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.




Table A-19 IEs of the Cipher Mode Complete message



Layer 3 Message Contents 1.2.37 BSS-MSC O 2–n


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





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



Cell Identifier 1.2.13 BSS-MSC M 3–10

Layer 3 Information 1.2.31 BSS-MSC M 3–n


LSA Identifier List 1.2.38 BSS-MSC O (2) 3+3n




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 Element Name

0000 0001 Circuit Identity Code

0000 0010 Reserved

0000 0011 Resource Available

0000 0100 Cause

0000 0101 Cell Identifier

0000 0110 Priority

0000 0111 Layer 3 Header Information

0000 1000 IMSI

0000 1001 TMSI

0000 1010 Encryption Information

0000 1011 Channel Type

0000 1100 Periodicity

0000 1101 Extended Resource Indicator

0000 1110 Number Of MSs

0000 1111 Reserved





0001 0000 Reserved

0001 0001 Reserved

0001 0010 Classmark Information Type 2


0001 0100 Interference Band To Be Used

0001 0101 RR Cause

0001 0110 Reserved

0001 0111 Layer 3 Information

0001 1000 DLCI

0001 1001 Downlink DTX Flag

0001 1010 Cell Identifier List

0001 1011 Response Request

0001 1100 Resource Indication Method


0001 1110 Circuit Identity Code List

0001 1111 Diagnostic

0010 0000 Layer 3 Message Contents

0010 0001 Chosen Channel

0010 0010 Total Resource Accessible

0010 0011 Cipher Response Mode

0010 0100 Channel Needed

0010 0101 Trace Type

0010 0110 Trigger id

0010 0111 Trace Reference

0010 1000 Transaction id

0010 1001 Mobile Identity

0010 1010 OMC Id

0010 1011 Forward Indicator

0010 1100 Chosen Encryption Algorithm

0010 1101 Circuit Pool

0010 1110 Circuit Pool List




0010 1111 Time Indication

0011 0000 Resource Situation

0011 0001 Current Channel type 1

0011 0010 Queuing Indicator

0100 0000 Speech Version

0011 0011 Assignment Requirement

0011 0101 Talker Flag

0011 0110 Connection Release Requested

0011 0111 Group Call Reference

0011 1000 eMLPP Priority

0011 1001 Configuration Evolution Indication

0011 1010 Old BSS to New BSS Information

0011 1011 LSA Identifier

0011 1100 LSA Identifier List

0011 1101 LSA Information

0011 1110 LCS QoS

0011 1111 LSA access control suppression

0100 0011 LCS Priority

0100 0100 Location Type

0100 0101 Location Estimate

0100 0110 Positioning Data

0100 0111 LCS Cause

0100 1000 LCS Client Type

0100 1001 APDU

0100 1010 Network Element Identity

0100 1011 GPS Assistance Data

0100 1100 Deciphering Keys

0100 1101 Return Error Request

0100 1110 Return Error Cause

0100 1111 Segmentation




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.

8 7 6 5 4 3 2 1

0 0 0 0 0 0 0 0 Reserved

Assignment messages

0 0 0 0 0 0 0 1 Assignment Request

0 0 0 0 0 0 1 0 Assignment Complete

0 0 0 0 0 0 1 1 Assignment Failure

Handover messages

0 0 0 1 0 0 0 0 Handover Request

0 0 0 1 0 0 0 1 Handover Required

0 0 0 1 0 0 1 0 Handover Request Acknowledge

0 0 0 1 0 0 1 1 Handover Command

0 0 0 1 0 1 0 0 Handover Complete

0 0 0 1 0 1 0 1 Handover Succeeded

0 0 0 1 0 1 1 0 Handover Failure

0 0 0 1 0 1 1 1 Handover Performed

0 0 0 1 1 0 0 0 Handover Candidate Enquire

0 0 0 1 1 0 0 1 Handover Candidate Response

0 0 0 1 1 0 1 0 Handover Required Reject

0 0 0 1 1 0 1 1 Handover Detect

Release messages

0 0 1 0 0 0 0 0 Clear Command

0 0 1 0 0 0 0 1 Clear Complete

0 0 1 0 0 0 1 0 Clear Request

0 0 1 0 0 0 1 1 Reserved

0 0 1 0 0 1 0 0 Reserved

0 0 1 0 0 1 0 1 Sapi “n” Reject

0 0 1 0 0 1 1 0 Confusion



8 7 6 5 4 3 2 1

Other connection related messages

0 0 1 0 1 0 0 0 Suspend

0 0 1 0 1 0 0 1 Resume

0 0 1 0 1 0 1 0 Connection Oriented Information

0 0 1 0 1 0 1 1 Perform Location Request

0 0 1 0 1 1 0 0 LSA Information

0 0 1 0 1 1 0 1 Perform Location Response

0 0 1 0 1 1 1 0 Perform Location Abort

General messages

0 0 1 1 0 0 0 0 Reset

0 0 1 1 0 0 0 1 Reset Acknowledge

0 0 1 1 0 0 1 0 Overload

0 0 1 1 0 0 1 1 Reserved

0 0 1 1 0 1 0 0 Reset Circuit

0 0 1 1 0 1 0 1 Reset Circuit Acknowledge

0 0 1 1 0 1 1 0 MSC Invoke Trace

0 0 1 1 0 1 1 1 BSS Invoke Trace

0 0 1 1 1 0 1 0 Connectionless Information

Terrestrial resource messages

0 1 0 0 0 0 0 0 Block

0 1 0 0 0 0 0 1 Blocking Acknowledge

0 1 0 0 0 0 1 0 Unblock

0 1 0 0 0 0 1 1 Unblocking Acknowledge

0 1 0 0 0 1 0 0 Circuit Group Block

0 1 0 0 0 1 0 1 Circuit Group Blocking Acknowledge

0 1 0 0 0 1 1 0 Circuit Group Unblock

0 1 0 0 0 1 1 1 Circuit Group Unblocking Acknowledge

0 1 0 0 1 0 0 0 Unequipped Circuit

0 1 0 0 1 1 1 0 Change Circuit

0 1 0 0 1 1 1 1 Change Circuit Acknowledge




8 7 6 5 4 3 2 1

Radio resource messages

0 1 0 1 0 0 0 0 Resource Request

0 1 0 1 0 0 0 1 Resource Indication

0 1 0 1 0 0 1 0 Paging

0 1 0 1 0 0 1 1 Cipher Mode Command

0 1 0 1 0 1 0 0 Classmark Update

0 1 0 1 0 1 0 1 Cipher Mode Complete

0 1 0 1 0 1 1 0 Queuing Indication

0 1 0 1 0 1 1 1 Complete Layer 3 Information

0 1 0 1 1 0 0 0 Classmark Request

0 1 0 1 1 0 0 1 Cipher Mode Reject

0 1 0 1 1 0 1 0 Load Indication

VGCS/VBS

0 0 0 0 0 1 0 0 VGCS/VBS Setup

0 0 0 0 0 1 0 1 VGCS/VBS Setup Ack

0 0 0 0 0 1 1 0 VGCS/VBS Setup Refuse

0 0 0 0 0 1 1 1 VGCS/VBS Assignment Request

0 0 0 1 1 1 0 0 VGCS/VBS Assignment Result

0 0 0 1 1 1 0 1 VGCS/VBS Assignment Failure

0 0 0 1 1 1 1 0 VGCS/VBS Queuing Indication

0 0 0 1 1 1 1 1 Uplink Request

0 0 1 0 0 1 1 1 Uplink Request Acknowledge

0 1 0 0 1 0 0 1 Uplink Request Confirmation

0 1 0 0 1 0 1 0 Uplink Release Indication

0 1 0 0 1 0 1 1 Uplink Reject Command

0 1 0 0 1 1 0 0 Uplink Release Command

0 1 0 0 1 1 0 1 Uplink Seized Command

Channel Type This element contains all of the information that the BSS requires to determine the required radio resources.



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

Element identifier Octet 1

Length Octet 2

Spare Speech/data indicator Octet 3

Channel rate and type Octet 4

Permitted speech version indication / data rate + transparency indicator

Octet 5 or octet 5 with extension*

* 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 Speech 0010 Data 0011 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 Full rate TCH channel Bm 0000 1001 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




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 SDCCH or Full rate TCH channel Bm or Half rate TCH channel Lm 0000 0001 SDCCH 0000 0010 SDCCH or Full rate TCH channel Bm 0000 0011 SDCCH or Half rate TCH channel Lm 0000 1000 Full rate TCH channel Bm 0000 1001 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. 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 7 6 5 4 3 2 1

ext permitted speech version identifier Octet 5

ext permitted speech version identifier Octet 5a

ext permitted speech version identifier Octet 5b

ext permitted speech version identifier Octet 5c

ext permitted speech version identifier Octet 5d

0 permitted speech version identifier Octet 5e

Bit 8 indicates extension of octet 5.

0 no extension, that is, value "0" indicates that this octet is the last octet.

1 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




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 5a–5e 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 7–1 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 7 6 5 4 3 2 1

ext T/NT Rate Octet 5

ext spare allowed radio interface rates Octet 5a

Bit 8 indicates extension of octet 5.

0 no extension, that is, value "0" indicates that this octet is the last octet.

1 extension, that is, value "1" indicates that at least one additional octet is included.

Bit 7:

0 Transparent service



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


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: Spare








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 7 6 5 4 3 2 1

ext T/NT Rate Octet 5

ext spare allowed radio interface rates 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 Transparent service

1 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 48.0 / 43.5 kbit/s (4x12 kbit/s or 3x14.5 kbit/s) 01 0011 36.0 / 29.0 kbit/s (3x12 kbit/s or 2x14.5 kbit/s) 01 0010 24.0 / 24.0 (4x6 kbit/s or 2x12 kbit/s) 01 0001 18.0 / 14.5 kbit/s (3x6 kbit/s or 1x14.5 kbit/s) 01 0000 12.0 / 12.0 kbit/s (2x6 kbit/s or 1x12 kbit/s) All other values are reserved.

For transparent service, bits 6–1 indicate requested user rate on the air interface.

65 4321

01 1111 64 kbit/s, bit transparent 01 1110 56 kbit/s, bit transparent 01 1101 56 kbit/s 01 1100 48 kbit/s 01 1011 38.4 kbit/s 01 1010 28.8 kbit/s 01 1001 19.2 kbit/s 01 1000 14.4 kbit/s 01 0000 9.6 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.



Bit 4: 0 14.5/14.4 kbit/s (TCH/F14.4) not allowed

1 14.5/14.4 kbit/s (TCH/F14.4) allowed

Bit 3: Spare

Bit 2: 0 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: 0 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.


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


Length Octet 2

Protocol discriminator Octet 3

Transaction identifier Octet 4

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


Length Octet 2

Priority Octet 3

Octet 2 is a binary indication of the length of the rest of the element.




Octet 3 is coded as follows:

8 7 6 5 4 3 2 1

spare pci priority level qa pvi Octet 1

Bit 8 is spare, set to 0

pci = Preemption Capability indicator (see note)

0 this allocation request shall not preempt an existing connection.

1 this allocation request may preempt an existing connection.

priority level:

6 5 4 3

0 0 0 0 spare

0 0 0 1 priority level 1 = highest priority

0 0 1 0 priority level 2 = second highest priority

1 1 1 0 priority level 14 = lowest priority

1 1 1 1 priority not used

qa = queuing allowed indicator

0 queuing not allowed

1 queuing allowed

pvi = Preemption Vulnerability indicator (see note)

0 this connection shall not be preempted by another allocation request.

1 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

Element identifier octet 1



8 7 6 5 4 3 2 1

a b c d e f g h octet 2

i j k X X X X X 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


CIC (least significant bits) Octet 2

CIC (most significant bits) Octet 3

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


Downlink DTX flag Octet 2

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


Band to be used Octet 2




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


Length Octet 2

Classmark Octet 3 - 5

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


8 7 6 5 4 3 2 1


Length Octet 2

Descriptive group or broadcast call reference Octet 3 - 8

Octet 2 is a binary indication of the length of the remainder of the element in octets.

Octets 3–8 are coded in the same way as octets 2–6 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





This IE is included if LSA access control function shall be suppressed in the BSS.


8 7 6 5 4 3 2 1


spare EM Octet 2

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


RR cause Octet 2

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


Length Octet 2

Spare Cell identification discriminator Octet 3

Cell identification Octet 4–n

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 4–n. The "Cell identification discriminator" is coded as follows:

0000 The whole Cell Global Identification, CGI, is used to identify the cell.

0001 Location Area Code, LAC, and Cell Identity, CI, is used to identify the cell.

0010 Cell Identity, CI, is used to identify the cell.




0011 No cell is associated with the transaction.


The coding of octets 4–n 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

MCC dig 2 MCC dig 1 Octet 4

1 1 1 1 MCC dig 3 Octet 5

MNC dig 2 MNC dig 1 Octet 6

LAC Octet 7

LAC cont. Octet 8

CI value Octet 9

CI value cont Octet 10

Octets 4–8 are coded as shown in GSM Rec. 04.08, Table ‘Location Area Identification information element’.

Octets 9–10 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


MNC dig 3 MCC dig 3 Octet 5


LAC Octet 7

LAC cont. Octet 8

CI value Octet 9


Octets 4–8 are coded as shown in GSM Rec. 04.08, Table ‘Location Area Identification information element’.



Octets 9–10 are coded as shown in GSM Rec. 04.08, Table ‘Cell Identity information element’.


8 7 6 5 4 3 2 1

LAC Octet 4

LAC cont. Octet 5

CI value Octet 6

CI value cont. Octet 7


8 7 6 5 4 3 2 1

CI value Octet 4

CI value cont. Octet 5

Octets 4–5 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.


8 7 6 5 4 3 2 1


Channel mode Channel Octet 2

The channel mode field is coded as follows:

Bit 8765

0000 no channel mode indication

1001 speech (full rate or half rate)

1110 data, 14.5 kbit/s radio interface rate







1000 signaling only


The channel field is coded as follows:

Bit 4321

0000 None (Note *)

0001 SDCCH

1000 1 Full rate TCH

1001 1 Half rate TCH

1010 2 Full Rate TCHs








*: 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.


8 7 6 5 4 3 2 1


Algorithm identifier Octet 2

The algorithm identifier caters for the possible future introduction of different user-data encryption algorithms. It is coded as follows:

0000 0001 No encryption used

0000 0010 GSM user data encryption version 1(A5/1).

0000 0011 GSM A5/2

0000 0100 GSM A5/3

0000 0101 GSM A5/4

0000 0110 GSM A5/5



0000 0111 GSM A5/6

0000 1000 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.


8 7 6 5 4 3 2 1


Circuit pool number Octet 2

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 Pool Supported Channels and Speech Coding Algorithms

0000 0001 Circuit pool number 1

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)


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)


FR speech version 2 FR data (12, 6, 3.6 kbit/s) HR speech version 1 HR data (6, 3.6 kbit/s)






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)


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)


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)




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)


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)




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)





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)


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)


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)


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)


FR speech version 3 HR speech version 3


FR speech version 3 FR data (12, 6, 3.6 kbit/s) HR speech version 3


FR speech version 1 FR speech version 2 FR speech version 3 FR data (12, 6, 3.6 kbit/s) HR speech version 3


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






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)


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)


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)


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)


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)





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.


8 7 6 5 4 3 2 1


spare Circuit pool number Octet 2

Bits 7–1 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


Length Octet 2

LSA ID Octet 3

LSA ID cont. Octet 4

LSA ID cont. Octet 5

Octets 3–5 are coded as specified in GSM Rec. 03.03, ‘Identification of Localized Service Area’. Bit 8 of octet 3 is the MSB.




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


Length Octet 2

0/1 ext Cause Value Octet 3

(Octet 4)

The length indicator is a binary representation of the length of the following element.

Cause Value:

Class (000): Normal event


Class (010): Resource unavailable

Class (011): Service or option not available

Class (100): Service or option not implemented

Class (101): invalid message (for example, parameter out of range)

Class (110): protocol error

Class (111): 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 Value

7 6 5 4 3 2 1

Cause Number

0 0 0 0 0 0 0 Radio interface message failure

0 0 0 0 0 0 1 Radio interface failure

0 0 0 0 0 1 0 Uplink quality

0 0 0 0 0 1 1 Uplink strength

0 0 0 0 1 0 0 Downlink quality



Cause Value

Class Value

7 6 5 4 3 2 1

Cause Number

0 0 0 0 1 0 1 Downlink strength

0 0 0 0 1 1 0 Distance

0 0 0 0 1 1 1 O&M intervention

0 0 0 1 0 0 0 Response to MSC invocation

0 0 0 1 0 0 1 Call control

0 0 0 1 0 1 0 Radio interface failure, reversion to old channel

0 0 0 1 0 1 1 Handover successful

0 0 0 1 1 0 0 Better Cell

0 0 0 1 1 0 1 Directed Retry

0 0 0 1 1 1 0 Joined group call channel

0 0 0 1 1 1 1 Traffic

0 0 1 0 0 0 0 }

: : : : : : : } Reserved for international use

0 0 1 0 1 1 1 }

0 0 1 1 0 0 0 }

: : : : : : : } Reserved for national use

0 0 1 1 1 1 1 }

0 1 0 0 0 0 0 Equipment failure

0 1 0 0 0 0 1 No radio resource available

0 1 0 0 0 1 0 Requested terrestrial resource unavailable

0 1 0 0 0 1 1 CCCH overload

0 1 0 0 1 0 0 Processor overload

0 1 0 0 1 0 1 BSS not equipped

0 1 0 0 1 1 0 MS not equipped

0 1 0 0 1 1 1 Invalid cell

0 1 0 1 0 0 0 Traffic Load

0 1 0 1 0 0 1 Preemption

0 1 0 1 0 1 0 }




Cause Value

Class Value

7 6 5 4 3 2 1

Cause Number

: : : : : : : } Reserved for national use

0 1 0 1 1 1 1 }

0 1 1 0 0 0 0 Requested transcoding/rate adaption unavailable

0 1 1 0 0 0 1 Circuit pool mismatch

0 1 1 0 0 1 0 Switch circuit pool

0 1 1 0 0 1 1 Requested speech version unavailable

0 1 1 0 1 0 0 LSA not allowed

0 1 1 0 1 0 1 }

0 1 1 : : : : } Reserved for international use

0 1 1 1 1 1 1 }

1 0 0 0 0 0 0 Ciphering algorithm not supported

1 0 0 0 0 0 1 }


1 0 0 0 1 1 1 }

1 0 0 1 0 0 0 }

1 0 0 : : : : } Reserved for national use

1 0 0 1 1 1 1 }

1 0 1 0 0 0 0 Terrestrial circuit already allocated

1 0 1 0 0 0 1 Invalid message contents

1 0 1 0 0 1 0 Information element or field missing

1 0 1 0 0 1 1 Incorrect value

1 0 1 0 1 0 0 Unknown Message type

1 0 1 0 1 0 1 Unknown IE

1 0 1 0 1 1 0 }

1 0 1 0 1 1 1 } Reserved for international use

1 0 1 1 0 0 0 }

1 0 1 : : : : }Reserved for national use

1 0 1 1 1 1 1 }



Cause Value

Class Value

7 6 5 4 3 2 1

Cause Number

1 1 0 0 0 0 0 Protocol Error between BSS and MSC

1 1 0 0 0 0 1 VGCS/VBS call non existent

1 1 0 0 0 1 0 }


1 1 0 0 1 1 1 }

1 1 0 1 0 0 0 }


1 1 0 1 1 1 1 }

1 1 1 0 0 0 0 }


1 1 1 0 1 1 1 }

1 1 1 1 0 0 0 }


1 1 1 1 1 1 1 }

Circuit Pool List

This element defines a list of BSS preferred circuit pools in order of preference.


8 7 6 5 4 3 2 1


Length Octet 2

Circuit pool number (1st preferred) Octet 3

:

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.




It is a variable length element.


8 7 6 5 4 3 2 1


Length Octet 2

Permitted algorithms Octet 3

Key Octet 4-n

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 No encryption

2 GSM A5/1

3 GSM A5/2

4 GSM A5/3

5 GSM A5/4

6 GSM A5/5

7 GSM A5/6

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




8 7 6 5 4 3 2 1


Classmark Octet 2



The classmark octet 2 is coded in the same way as the equivalent octet in the classmark 1 element of GSM Rec. 04.08.




8 7 6 5 4 3 2 1


Length Octet 2

Classmark Octet 3-14

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.


8 7 6 5 4 3 2 1


Channel mode Channel Octet 2

The channel mode field is coded as follows:

Bit 8765

0000 signaling only

0001 speech (full rate or half rate)





1111 is 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:




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 1111 7 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


Length Octet 2

spare LSA only Octet 3

LSA identification and attributes 1 Octet 4-7

:

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 7 6 5 4 3 2 1

spare act pref priority Octet x+1

LSA ID Octet x+2

LSA ID cont. Octet x+3




Where x = 3 + 4(i-1)

Bits 1 to 4 of octet (x+1) define the priority of the LSA identification.

Bit 4321

0000 priority 1 = lowest priority

0001 priority 2 = second lowest priority

: : : :

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


Length Octet 2

Old BSS to New BSS information elements Octet 3-n

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.




Field Element Reference Length

Extra information 3.2.3.1 3

Current Channel Type 2 3.2.3.2 4

Target cell radio information 3.2.3.3 3

GPRS Suspend information 3.2.3.4 19

MultiRate configuration information 3.2.3.5 3-8


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


spare 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 Modification is allowed and maximum number of TCH/F is 1





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


Cell Identifier List

This element uniquely identifies cells and is of variable length containing the following fields:



8 7 6 5 4 3 2 1


Length Octet 2

spare Cell identification discriminator Octet 3

Cell identification 1 Octet 4-4+m

:

Cell identification n 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 The whole Cell Global Identification, CGI, is used to identify the cells.

0001 Location Area Code, LAC, and Cell Identify, CI, is used to identify the cells.

0010 Cell Identity, CI, is used to identify the cells.

0011 No cell is associated with the transaction.

0100 Location Area Identification, LAI, is used to identify all cells within a Location Area.

0101 Location Area Code, LAC, is used to identify all cells within a location area.

0110 All cells on the BSS are identified.


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


8 7 6 5 4 3 2 1


1 1 1 1 MCC dig 3 Octet 5





8 7 6 5 4 3 2 1

LAC Octet 7

LAC cont. Octet 8

CI value Octet 9


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


8 7 6 5 4 3 2 1

MCC dig 2 MCC dig 1 Octet x+1

MNC dig 3 MCC dig 3 Octet x+2

MNC dig 2 MNC dig 1 Octet x+3

LAC Octet x+4

LAC cont. Octet x+5

CI value Octet x+6

CI value cont Octet x+7

Where x = 3 + 7(i-1).



Coding of i-th Cell Identification for Cell identification discriminator = 0001

8 7 6 5 4 3 2 1

LAC Octet x+1

LAC cont. Octet x+2

CI value Octet x+3

CI value cont. Octet x+4



Where x = 3 + 4(i-1)




8 7 6 5 4 3 2 1

CI value Octet x+1


Where x = 3 + 2(i-1)




8 7 6 5 4 3 2 1


1 1 1 1 MCC dig 3 Octet x+2


LAC Octet x+4

LAC cont. Octet x+5

CI value Octet x+6


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


8 7 6 5 4 3 2 1


MNC dig 3 MCC dig 3 Octet x+2


LAC Octet x+4




8 7 6 5 4 3 2 1

LAC cont. Octet x+5

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


8 7 6 5 4 3 2 1

LAC Octet x+1

LAC cont. Octet x+2

Where x = 3 + 2(i-1)


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


spare qri spare Octet 2

Octet 2 is coded as follows:

qri = queuing recommendation indicator

0 it is recommended not to allow queuing.

1 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


Length Octet 2



8 7 6 5 4 3 2 1

Layer 3 information Octet 3-n

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


Length Octet 2

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

Octet 3-n

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


Length Octet 2

TMSI Octet 3-n

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.


8 7 6 5 4 3 2 1


spare Channel Octet 2




The Channel field is coded as follows:

Bit 2 1

0 0 Any channel

0 1 SDCCH

1 0 TCH/F (Full rate)

1 1 TCH/H or TCH/F (Dual rate)

eMLPP Priority

This IE contains the eMLPP priority of the call.


8 7 6 5 4 3 2 1


spare 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


Cipher response mode Octet 2

Octet 2 is coded as:-

Bits 8,7,6,5,4,3,2 - Spare

Bit 1 = 0 - IMEISV must not be included by the Mobile Station

Bit 1 = 1 - 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


Length Octet 2



8 7 6 5 4 3 2 1

Layer 3 message contents Octet 3-n

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


Length Octet 2

spare EP Octet 3

LSA identification 1 Octet 4-6

: :

LSA identification 2 to 3+3n

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 7 6 5 4 3 2 1

LSA ID Octet x+1



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.





8 7 6 5 4 3 2 1


Length Octet 2

Service Handover information Octet 3

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:

3 2 1

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

0 0 1 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.

0 1 0 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


Length Octet 2

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

Octet 3–n




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


Length Octet 2

Source RNC to target RNC information container Octet 3–n

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


Length Octet 2

Source RNC to target RNC information container Octet 3–n

The Source RNC to Target RNC Information container structure and encoding is defined in relevant RANAP specification TS 25.413, excluding RANAP tag.


This IE indicates whether subsequent assignment requests are expected and the limitation for these subsequent assignments.

8 7 6 5 4 3 2 1


spare 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 Modification is allowed and maximum number of TCH/F is 1.








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:


Channel Required 2.1.1

Paging Command 2.1.2

Channel Activation 2.1.3

Channel Activation Acknowledge 2.1.4

Channel Activation Negative Acknowledge 2.1.5

Immediate Assign Command 2.1.6

Connection Failure Indication 2.1.7

Error Indication 2.1.8

Encryption Command 2.1.9

Handover Detection 2.1.10

Mode Modify 2.1.11

Mode Modify Acknowledge 2.1.12

Mode Modify Negative Acknowledge 2.1.13

Establish Indication 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 Reference Presence Format Length

Message discriminator 2.2.1 M V 1




Message type 2.2.2 M V 1

Channel number 2.2.3 M TV 2

Request Reference 2.2.4 M TV 4

Access Delay 2.2.5 M TV 2

Physical Context 2.2.6 O (1) TLV >=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.





Paging Group 2.2.7 M TV 2

MS Identity 2.2.8 M TLV 2-10

Channel Needed 2.2.9 O (1) TV 2

eMLPP Priority 2.2.10 O (2) TV 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.









Activation Type 2.2.11 M TV 2

Channel Mode 2.2.12 M TLV 8-9

Channel Identification 2.2.13 O (7) TLV 8

Encryption information 2.2.14 O (1) TLV >=3

Handover Reference 2.2.15 C (2) TV 2

BS Power 2.2.16 O (3) TV 2

MS Power 2.2.17 O (3) TV 2

Timing Advance 2.2.18 C (3) (4) TV 2

BS Power Parameters 2.2.20 O (5) TLV >=2

MS Power Parameters 2.2.19 O (5) TLV >=2

Physical Context 2.2.6 O (6) TLV >=2

SACCH Information 2.2.21 O (8) TLV >=3

UIC 2.2.22 O (9) TLV 3

Main channel reference 2.2.23 O (10) TV 2

MultiRate configuration 2.2.24 O (11) TLV >=4

MultiRate Control 2.2.25 O (12) TV 2

Supported Code Types 2.2.26 O (12) TLV >=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



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.





Frame number 2.2.27 M TV 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.





Cause 2.2.28 M TLV >=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.




Immediate Assign Command This message is sent from the BSC to the BTS to request the transmission of an Immediate Assignment message.





Full Imm. Assign Info 2.2.29 M TLV 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.






Error Indication This message is sent from the BTS to the BSC to indicate an abnormal case for a radio-link layer connection.





Link Identifier 2.2.30 M TV 2

RLM Cause 2.2.31 M TLV 2-4



Encryption Command This message is sent from the BSC to the BTS to start ciphering mode operation.





Encryption information 2.2.14 M TLV >=3


L3 Info (CIPH MOD CMD) 2.2.32 M TLV 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.





Access Delay 2.2.5 O (1) TV 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.





Channel Mode 2.2.12 M TLV 8-9

Encryption information 2.2.14 O (1) TLV >=3





Main channel reference 2.2.23 O (2) TV 2

MultiRate configuration 2.2.24 O (3) TLV >=3

Multirate Control 2.2.25 O (4) TV 2

Supported Code Types 2.2.26 O (4) TLV >=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.





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.








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.






L3 Information 2.2.32 O (1) TLV 3–23

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 Non-Transparent messages and also between Radio Link Layer Management, Dedicated Channel Management, Common Channel Management, and TRX Management messages.

8 7 6 5 4 3 2 1

G7 G6 G5 G4 G3 G2 G1 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 Reserved

0 0 0 0 0 0 1 Radio Link Layer Management messages

0 0 0 0 1 0 0 Dedicated Channel Management messages

0 0 0 0 1 1 0 Common Channel Management messages

0 0 0 1 0 0 0 TRX Management messages

0 0 1 0 0 0 0 Location Services messages

All other values are reserved for future use




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.

8 7 6 5 4 3 2 1 Message

0 0 0 0 - - - - Radio Link Layer Management messages

0 0 0 1 Data Request

0 0 1 0 Data Indication

0 0 1 1 Error Indication

0 1 0 0 Establish Request

0 1 0 1 Establish Confirm

0 1 1 0 Establish Indication

0 1 1 1 Release Request

1 0 0 0 Release Confirm

1 0 0 1 Release Indication

1 0 1 0 Unit Data Request

1 0 1 1 Unit Data Indication

0 0 0 1 - - - - Common Channel Management/TRX Management messages

0 0 0 1 BCCH Information

0 0 1 0 CCCH Load Indication

0 0 1 1 Channel Required

0 1 0 0 Delete Indication

0 1 0 1 Paging Command

0 1 1 0 Immediate Assign Command

0 1 1 1 SMS Broadcast Request

1 0 0 1 RF Resource Indication



8 7 6 5 4 3 2 1 Message

1 0 1 0 SACCH Filling

1 0 1 1 Overload

1 1 0 0 Error Report

1 1 0 1 SMS Broadcast Command

1 1 1 0 CBCH Load Indication

1 1 1 1 Notification Command

0 0 1 - - - - - Dedicated Channel Management messages

0 0 0 0 1 Channel Activation

0 0 0 1 0 Channel Activation Acknowledge

0 0 0 1 1 Channel Activation Negative ACK

0 0 1 0 0 Connection Failure

0 0 1 0 1 Deactivate SACCH

0 0 1 1 0 Encryption Command

0 0 1 1 1 Handover Detection

0 1 0 0 0 Measurement Result

0 1 0 0 1 Mode Modify Request

0 1 0 1 0 Mode Modify Acknowledge

0 1 0 1 1 Mode Modify Negative Acknowledge

0 1 1 0 0 Physical Context Request

0 1 1 0 1 Physical Context Confirm

0 1 1 1 0 RF Channel Release

0 1 1 1 1 MS Power Control

1 0 0 0 0 BS Power Control

1 0 0 0 1 Preprocess Configure

1 0 0 1 0 Preprocessed Measurement Result

1 0 0 1 1 RF Channel Release Acknowledge

1 0 1 0 0 SACCH INFO Modify

1 0 1 0 1 Talker Detection

1 0 1 1 0 Listener Detection

1 0 1 1 1 Remote Code Configuration Report

1 1 0 0 0 Round Trip Delay Report




8 7 6 5 4 3 2 1 Message

1 1 0 0 1 Pre-Handover Notification

1 1 0 1 0 Multirate Code Modification Reqest

1 1 0 1 1 Multirate Code MOD Acknowledge

1 1 1 0 0 Multirate Code MOD Negative Acknowledge

1 1 1 0 1 Multirate Code MOD Performed

1 1 1 1 0 TFO Report

1 1 1 1 1 TFO Modification Request

0 1 - - - - - - Location Service messages

0 0 0 0 0 1 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 Bm + ACCH's

0 0 0 1 T Lm + ACCH's

0 0 1 T T SDCCH/4 + ACCH

0 1 T T T SDCCH/8 + ACCH

1 0 0 0 0 BCCH

1 0 0 0 1 Uplink CCCH (RACH)

1 0 0 1 0 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.



Request Reference This element carries the Request Reference parameters used for contention resolution on RACH.

8 7 6 5 4 3 2 1

Element identifier 1

RA 2

T1' T3 (high) 3

T3 (low) T2 4

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


Access Delay 2

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


Length 2

Physical 3

Context

Information N




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


Paging Group 2

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


Length 2

3

:

MS Identity

N

The MS Identity field (octets 3–N) is coded as specified for the Mobile Identity IE of GSM Rec. 04.08, octets 3–N.

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


Reserved for future use Channel 2

The Channel Field (bits 1–2 of octet 2) indicates the further combination of channel that is needed. It is coded as follows:

Value Channel Needed

0 0 Any Channel



0 1 SDCCH

1 0 TCH/F (Full rate)

1 1 TCH/F or TCH/H (Dual rate)

eMLPP Priority This IE contains the eMLPP priority of the call.


8 7 6 5 4 3 2 1


spare 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


R Reserved A3 A2 A1 2

The R bit indicates whether the procedure is an initial activation or a reactivation.

R

0 - Initial activation

1 - 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 - Activation related to intra-cell channel change

0 - related to immediate assignment procedure

1 - related to normal assignment procedure

0 1 - Activation related to inter-cell channel change (handover)

0 - related to asynchronous handover procedure

1 - related to synchronous handover procedure




1 0 - Activation related to secondary channels

0 - related to additional assignment procedure

1 - 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


Length 2

Reserved for future use DTXd DTXu 3

Speech or data indicator 4

Channel rate and type 5

Speech coding algor./data rate + transp ind 6

The DTX bits of octet 3 indicate whether DTX is applied:

1 DTX is applied

0 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 Speech

0000 0010 Data

0000 0011 Signaling


The "Channel rate and type" field (octet 5) is coded as follows:

0000 0001 SDCCH

0000 1000 Full rate TCH channel Bm

0000 1001 Half rate TCH channel Lm

0000 1010 Full rate TCH channel bi-directional Bm, Multislot configuration

0001 1010 Full rate TCH channel uni-directional downlink Bm, Multislot configuration



0001 1000 Full rate TCH channel Bm Group call channel

0001 1001 Half rate TCH channel Lm Group call channel

0010 1000 Full rate TCH channel Bm Broadcast call channel

0010 1001 Half rate TCH channel Lm Broadcast call channel


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 GSM speech coding algorithm version 1




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 7 6 5 4 3 2 1

ext T/NT Rate octet 6

Bit 8: Reserved for extension

Bit 7: 0 Transparent service

1 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




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)


Channel Identification This IE describes some aspects of a channel together with its SACCH.

8 7 6 5 4 3 2 1


Length 2

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


Length 2

Algorithm identifier 3

Key 4

n

The Algorithm Identifier field (octet 3) indicates the relevant ciphering algorithm. It is coded as:

0000 0000 Reserved

0000 0001 No encryption shall be used.



0000 0010 GSM encryption algorithm version 1 (A5/1)

0000 0011 GSM A5/2

0000 0100 GSM A5/3

0000 0101 GSM A5/4

0000 0110 GSM A5/5

0000 0111 GSM A5/6

0000 1000 GSM A5/7

All other values are reserved

The Key field (octets 4–n) 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


Handover reference 2

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


Reserved Power Level 2

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 Power level

0 0 0 0 0 Pn

0 0 0 0 1 Pn - 2 dB

0 0 0 1 0 Pn - 4 dB

0 1 1 1 0 Pn - 28 dB

0 1 1 1 1 Pn - 30 dB





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


Reserved Power Level 2

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


Reserved Timing Advance 2

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


Length 2

MS Power Control Parameters

3 N

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



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


Length 2

3

:

BS Power Control Parameters

N

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, RX-QUAL-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


Length 2

Number of messages 3

Type of 1st message 4

Length of 1st message 5

1st message : j

Type of n'th message l

Length of n'th message l+1

N

n'th message




The Length field (octet 2) indicates in binary the total remaining length of the element (octets 3–N).

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 n’th msg), a length field (Length of n’th message), and a message field (n’th message).

The "Type of n’th msg" field indicates the type of System Information, or an Extended Measurement Order message that follows in the "n’th message" field. It is coded as follows:

Value Message

0 0 0 0 0 1 0 1 SYSTEM INFORMATION 5

0 0 0 0 0 1 1 0 SYSTEM INFORMATION 6

0 0 0 0 1 1 0 1 SYSTEM INFORMATION 5bis

0 0 0 0 1 1 1 0 SYSTEM INFORMATION 5ter

0 1 0 0 0 1 1 1 EXTENDED MEASUREMENT ORDER


The "Length of n’th SI message" field indicates in binary the length of the "n’th message" field that follows.

The "n’th 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


Length 2

UIC information 3

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




8 7 6 5 4 3 2 1

Reserved for future use TN 2

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


Length 2

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

3–n

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


Spare PRE RAE TFO 3

The TFO field (bit 1 of octet 3) indicates if TFO is enabled or not. It is coded as follows:

Value TFO

0 Tandem Free Operation is enabled

1 Tandem Free Operation is disabled

The RAE field (bits 2–3, 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




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 PRE

0 Handover is not expected, respectively has failed

1 Handover is expected soon

Supported Code Types This element indicates the code types supported by the BSS or the remote BSS.


8 7 6 5 4 3 2 1


Length 2

Sys-ID 3

ext Code List 4–n

Preferred Code Type n+1

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 6–7: 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 5–6) should be coded as follows:

8 7 6 5 4 3 2 1

Spare TFO_VER MACS 5

SCS 6



If both FR AMR and HR AMR are supported, the octets 5–6 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 1–2 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.








The Preferred Code Field (bits 1–8, 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.




8 7 6 5 4 3 2 1


T1' T3 (high) 2

T3 (low) T2 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


Length 2

E Cause Value 3

Cause Extension 3a

4

Diagnostic(s) if any

N

The Length field indicates in binary the remaining length of the element (octets 3–N).

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 5–7 of octet 3) and a value within the class (bits 1–4 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 (010): Resource unavailable

Class (011): Service or option not available

Class (100): Service or option not implemented



Class (101): Invalid message (e.g. parameter out of range)

Class (110): Protocol error

Class (111): Interworking

CAUSE VALUES:

Class Value Cause Diagnostics

0 0 0 - - - - Normal Event

0 0 0 0 0 0 0 radio interface failure Channel Number

0 0 0 0 0 0 1 radio link failure Channel Number

0 0 0 0 0 1 0 handover access failure Channel Number

0 0 0 0 0 1 1 talker access failure Channel Number

0 0 0 0 1 0 0 reserved for international use



0 0 0 0 1 1 1 O&M intervention


0 0 0 1 : : :

0 0 0 1 1 1 0

0 0 0 1 1 1 1 normal event, unspecified

0 0 1 - - - - Normal Event


0 0 1 0 : : :

0 0 1 0 1 1 1

0 0 1 1 0 0 0 reserved for national use

0 0 1 1 : : :

0 0 1 1 1 1 1

0 1 0 - - - - Resource unavailable

0 1 0 0 0 0 0 equipment failure

0 1 0 0 0 0 1 radio resource not available Channel Number

0 1 0 0 0 1 0 terrestrial channel failure Channel Number

0 1 0 0 0 1 1 CCCH overload Channel Number

0 1 0 0 1 0 0 ACCH overload Channel Number





0 1 0 0 1 0 1 processor overload


0 1 0 0 1 1 1 BTS not equipped

0 1 0 1 0 0 0 remote transcoder failure Channel Number

0 1 0 1 0 0 1 notification overflow Channel Number






0 1 0 1 1 1 1 resource not available, unspecified

0 1 1 - - - - Service or Option Not Available

0 1 1 0 0 0 0 requested transcoding/rate adaption not available

Channel Number


0 1 1 : : : :

0 1 1 1 1 1 0

0 1 1 1 1 1 1 service or option not available, unspecified

1 0 0 - - - - Service or Option Not Implemented

1 0 0 0 0 0 0 encryption algorithm not implemented Channel Number


1 0 0 0 : : :

1 0 0 0 1 1 1


1 0 0 1 : : :

1 0 0 1 1 1 0

1 0 0 1 1 1 1 service or option not implemented, unspecified

1 0 1 - - - - Invalid Message

1 0 1 0 0 0 0 radio channel already activated/allocated Channel Number


1 0 1 0 : : :




1 0 1 0 1 1 1


1 0 1 1 : : :

1 0 1 1 1 1 0

1 0 1 1 1 1 1 invalid message, unspecified

1 1 0 - - - - Protocol Error

1 1 0 0 0 0 0 message discriminator error Message Discrim

1 1 0 0 0 0 1 message type error Message Type

1 1 0 0 0 1 0 message sequence error Message Type

1 1 0 0 0 1 1 general information element error

1 1 0 0 1 0 0 mandatory information element error Element Identif

1 1 0 0 1 0 1 optional information element error Element Identif

1 1 0 0 1 1 0 information element non-existent Element Identif

1 1 0 0 1 1 1 information element length error Element Identif

1 1 0 1 0 0 0 invalid information element contents Inform. Element







1 1 0 1 1 1 1 protocol error, unspecified

1 1 1 - - - - Interworking


1 1 1 0 : : :

1 1 1 0 1 1 1


1 1 1 1 : : :

1 1 1 1 1 1 0

1 1 1 1 1 1 1 interworking, unspecified




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


Length Indicator 2

Full Immediate 3

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


C2 C1 NA priority SAPI 2

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 C1

0 0 main signaling channel (FACCH or SDCCH)

0 1 SACCH


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:

0 0 normal priority

0 1 high priority

1 0 low priority

All other values for SAPI 0 and all values for other SAPIs are reserved for future use.



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


Length 2

E Cause Value 3

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:

8 7 6 5 4 3 2 1

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


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





8 7 6 5 4 3 2 1

Length 2

Indicator 3

Link Layer Service Data Unit 4

(i.e. a layer 3 message

as defined in GSM Rec. 04.08) n

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 4–n 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

HUAWEI BSC6000 Base Station Subsystem BSS Signaling Analysis Guide

B Differences Between Phase 1, Phase 2, Phase 2+, and R99

Issue 01 (2008-06-10) Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd B-1


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.


HUAWEI BSC6000 Base Station SubsystemBSS Signaling Analysis Guide

B-2 Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd Issue 01 (2008-06-10)

Table B-1 Differences between messages at Phase 1, Phase 2, Phase 2+, and R99

Message Phase 1 Phase 2 Phase 2+ R99

Assignment Request

Supporting the Assignment Request message

Layer 3 header information becomes optional IE

Deleting Radio Channel Identity (optional IE)

Adding Classmark Information 2 (optional IE)

Adding Group Call Reference (optional IE)

Adding Talker Flag (optional IE)

Adding LSA Access Control Suppression (optional IE)

Adding Configuration Evolution Indication (optional IE)

Adding Service Handover (optional IE)

Assignment Complete

Supporting the Assignment Complete message


Adding Chosen Channel (optional IE)

Adding Chosen Encryption Algorithm (optional IE)

Adding Circuit Identity Code (optional IE)

Adding Circuit Pool (optional IE)

Adding Speech Version (Chosen) (optional IE)

Adding LSA Identifier (optional IE)

Adding Cell Identifier (optional IE)

Assignment Failure

Supporting the Assignment Failure message

Basically consistent, Adjusting the cause values


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





Blocking Acknowledge

Supporting the Blocking Acknowledge message




Unblock Supporting the Unblock message (from BSC to MSC)

Supporting the Unblock message (from BSC to MSC)


Supporting the Unblock message

Unblocking Acknowledge

Supporting the Unblocking Acknowledge message




Handover Request

Supporting the Handover Request message

Deleting Radio channel identity optional IE)

Adding Cause (optional IE)

Adding Classmark Information 3 (optional IE)

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)

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)





Handover Required

Supporting the Handover Required message

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)


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 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 Circuit Identity Code (optional IE)

Adding LSA Identifier (optional IE)

Adding Layer 3 Information (mandatory IE)

Handover Command

Supporting the Handover Command message

Modifying the encoding of Layer 3 Information

Adding Cell Identifier (optional IE)

Adding Layer 3 Information (mandatory IE)

Handover Complete

Supporting the Handover Complete message




Handover Succeeded

Not supporting the Handover Succeeded message

Not supporting the Handover Succeeded message

Adding the Handover Succeeded message

Supporting the Handover Succeeded message





Handover Candidate Enquire

Supporting the Handover Candidate Enquire message

Changing the property of Cell Identifier from optional IE to mandatory IE



Handover Candidate Response

Supporting the Handover Candidate Response message




Handover Failure

Supporting the Handover Failure message





Resource Request

Supporting the Resource Request message


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





Clear Request

Supporting the Clear Request message




Clear Command

Supporting the Clear Command message

Changing the property of Layer 3 Header Information from Mandatory IE to optional IE



Clear Complete

Supporting the Clear Complete message




Reset Supporting the Reset message

Supporting the Reset message



Reset Acknowledge

Supporting the Reset Acknowledge message




Handover Performed

Supporting the Handover Performed message

Changing the property of Cell Identifier from Optional IE to mandatory IE





Adding LSA Identifier

Supporting the Handover Performed message

Overload Supporting the Overload message

Supporting the Overload message

Supporting the Overload message

Trace Invocation

Supporting the Trace Invocation message

Changing the Trace Invocation message to two messages:

MSC Invoke Trace

BSS Invoke Trace

Changing the Trace Invocation message to two messages:

MSC Invoke Trace

BSS Invoke Trace

Supporting the Trace Invocation message





MSC Invoke Trace

Not supporting the MSC Invoke Trace message

Adding the MSC Invoke Trace message

Supporting the MSC Invoke Trace message

Supporting the MSC Invoke Trace message

BSS Invoke Trace

Not supporting the BSS Invoke Trace message

Adding the BSS Invoke Trace message

Supporting the BSS Invoke Trace message

Supporting the BSS Invoke Trace message

Classmark Update

Supporting the Classmark Update message (from BSC to MSC)


Changing Classmark Information Type 2 (optional IE)

Adding Classmark Information Type 3 (optional IE)

Supporting the Classmark Update message

Supporting the Classmark Update message

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)




Complete Layer 3 Information

Supporting the Complete Layer 3 Information message


Adding LSA Identifier List (optional IE)

Adding APDU (optional IE)

Supporting the Complete Layer 3 Information message

Queuing Indication

Supporting the Queuing Indication message








SAPI "n" Reject

Supporting the SAPI "n" Reject message




SAPI "n" Clear Command

Supporting the SAPI "n" Clear Command message

Not supporting the SAPI "n" Clear Command message



SAPI "n" Clear Complete

Supporting the SAPI "n" Clear Complete message

Not supporting the SAPI "n" Clear Complete message



Handover Required Reject

Supporting the Handover Required Reject message




Reset Circuit Supporting the Reset Circuit message

Supporting the Reset Circuit message



Reset Circuit Acknowledge

Supporting the Reset Circuit Acknowledge message




Handover Detect

Supporting the Handover Detect message




Circuit Group Block

Not supporting the Circuit Group Block message

Adding the Circuit Group Block message (from BSC to MSC)

Supporting the bi-directional Circuit Group Block message

Supporting the Circuit Group Block message

Circuit Group Blocking Acknowledge

Not supporting the Circuit Group Blocking Acknowledge message

Adding the Circuit Group Blocking Acknowledge message (from MSC to BSC)

Supporting the bi-directional Circuit Group Blocking Acknowledge message

Supporting the Circuit Group Blocking Acknowledge message





Circuit Group Unblock

Not supporting the Circuit Group Unblock message

Adding the Circuit Group Unblock message (from BSC to MSC)

Supporting the bi-directional Circuit Group Unblock message

Supporting the Circuit Group Unblock message

Circuit Group Unblocking Acknowledge

Not supporting the Circuit Group Unblocking Acknowledge message

Adding the Circuit Group Unblocking Acknowledge message (from MSC to BSC)

Supporting the bi-directional Circuit Group Unblocking Acknowledge message

Supporting the Circuit Group Unblocking Acknowledge message

Confusion Not supporting the Confusion message

Adding the Confusion message

Supporting the Confusion message

Supporting the Confusion message

Classmark Request

Not supporting the Classmark Request message

Adding the Classmark Request message

Supporting the Classmark Request message

Supporting the Classmark Request message

Unequipped Circuit

Not supporting the Unequipped Circuit message

Adding the Unequipped Circuit message

Supporting the Unequipped Circuit message

Supporting the Unequipped Circuit message

Cipher Mode Reject

Not supporting the Cipher Mode Reject message

Adding the Cipher Mode Reject message

Supporting the Cipher Mode Reject message

Supporting the Cipher Mode Reject message

Load Indication

Not supporting the Load Indication message

Not supporting the Load Indication message

Adding the Load Indication message

Supporting the Load Indication message

VGCS.CBS Setup

Not supporting the VGCS.CBS Setup message

Not supporting the VGCS.CBS Setup message

Adding the VGCS.CBS Setup message

Supporting the VGCS.CBS Setup message

VGVS/VBS Setup ACK

Not supporting the VGVS/VBS Setup ACK message

Not supporting the VGVS/VBS Setup ACK message

Adding the VGVS/VBS Setup ACK message

Supporting the VGVS/VBS Setup ACK message





VGCS/VBS Assignment Request

Not supporting the VGCS/VBS Assignment Request message

Not supporting the VGCS/VBS Assignment Request message

Adding the VGCS/VBS Assignment Request message

Supporting the VGCS/VBS Assignment Request message

VGCS/VBS Assignment Result

Not supporting the VGCS/VBS Assignment Result message

Not supporting the VGCS/VBS Assignment Result message

Adding the VGCS/VBS Assignment Result message

Supporting the VGCS/VBS Assignment Result message

VGCS/VBS Assignment Failure

Not supporting the VGCS/VBS Assignment Failure message

Not supporting the VGCS/VBS Assignment Failure message

Adding the VGCS/VBS Assignment Failure message

Supporting the VGCS/VBS Assignment Failure message

VGCS/VBS Assignment Indication

Not supporting the VGCS/VBS Assignment Indication message

Not supporting the VGCS/VBS Assignment Indication message

Adding the VGCS/VBS Assignment Indication message

Supporting the VGCS/VBS Assignment Indication message

Uplink Request

Not supporting the Uplink Request message

Not supporting the Uplink Request message

Adding the Uplink Request message

Supporting the Uplink Request message

Uplink Request Acknowledge

Not supporting the Uplink Request Acknowledge message

Not supporting the Uplink Request Acknowledge message

Adding the Uplink Request Acknowledge message

Supporting the Uplink Request Acknowledge message

Uplink Request Confirmation

Not supporting the Uplink Request Confirmation message

Not supporting the Uplink Request Confirmation message

Adding the Uplink Request Confirmation message

Adding the Uplink Request Confirmation message

Uplink Release Indication

Not supporting the Uplink Release Indication message

Not supporting the Uplink Release Indication message

Adding the Uplink Release Indication message

Supporting the Uplink Release Indication message





Uplink Reject Command

Not supporting the Uplink Reject Command message

Not supporting the Uplink Reject Command message

Adding the Uplink Reject Command message

Supporting the Uplink Reject Command message

Uplink Release Command

Not supporting the Uplink Release Command message

Not supporting the Uplink Release Command message

Adding the Uplink Release Command message

Supporting the Uplink Release Command message

Uplink Seized Command

Not supporting the Uplink Seized Command message

Not supporting the Uplink Seized Command message

Adding the Uplink Seized Command message

Supporting the Uplink Seized Command message

Suspend Not supporting the Suspend message

Not supporting the Suspend message

Adding the Suspend message

Supporting the Suspend message

Resume Not supporting the Resume message

Not supporting the Resume message

Adding the Resume message

Supporting the Resume message

Change Circuit

Not supporting the Change Circuit message

Not supporting the Change Circuit message

Adding the Change Circuit message

Supporting the Change Circuit message

Change Circuit Acknowledge

Not supporting the Change Circuit Acknowledge message

Not supporting the Change Circuit Acknowledge message

Adding the Change Circuit Acknowledge message

Supporting the Change Circuit Acknowledge message

LSA Information

Not supporting the LSA Information message

Not supporting the LSA Information message

Adding the LSA Information message

Supporting the LSA Information message

Location Information Command

Not supporting the Location Information Command message

Not supporting the Location Information Command message

Adding the Location Information Command message

Supporting the Location Information Command message





Location Information Report

Not supporting the Location Information Report message

Not supporting the Location Information Report message

Adding the Location Information Report message

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 Phase 1 Phase 2 Phase 2+ R99

Circuit Identity Code

Supporting the Circuit Identity Code IE


Adding the support for 1544 kbit/s


Radio Channel Identity

Supporting the Radio Channel Identity IE

Deleting the Radio Channel Identity IE



Resource Available

Supporting the Resource Available IE




Cause Supporting the Cause 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

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

Supporting the Cause IE





Cell Identifier Supporting the Cell Identifier IE

Supporting the Cell Identifier IE

Adding the support for PCS1900

Supporting inter-RAT handover Adding four types of Cell Identifiers

Priority Supporting the Priority IE

Adding the PCI field Supporting the Priority IE Supporting the IE


Supporting the Layer 3 Header Information IE




IMSI Supporting the IMSI IE

Supporting the IMSI IE Supporting the IMSI IE Supporting the IMSI IE

TMSI Supporting the TMSI IE

Supporting the TMSI IE Supporting the TMSI IE Supporting the TMSI IE

Encryption Information

Supporting the Encryption Information IE (No Encryption and GSM A5/1)

Supporting the Encryption Information IE (No Encryption, GSM A5/1, A5/2, A5/3, A5/4, A5/5, A5/6 and A5/7)

Supporting the Encryption Information IE (No Encryption, GSM A5/1, A5/2, A5/3, A5/4, A5/5, A5/6 and A5/7)

Supporting the Encryption Information IE

Channel Type Supporting the Channel Type IE

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 multislot configuration

Supporting multiple speech versions, such as EFR, AMR

Increasing the data rate

Adding two types of data rates for non-transparent service Adding two types of data rates for transparent service

Periodicity Supporting the Periodicity IE

Supporting the Periodicity IE



Extended Resource Indicator

Not supporting the Extended Resource Indicator IE

Adding the Extended Resource Indicator IE

Adding the SM field Supporting the Extended Resource Indicator IE

Number of MSs Supporting the Number of MSs IE

Supporting the Number of MSs IE







Current Radio Environment

Supporting the Current Radio Environment IE

Deleting the Current Radio Environment IE



Environment of BS "n"

Supporting the Environment of BS "n" IE

Deleting the Environment of BS "n" IE




Supporting the Classmark Information Type 2 IE

Modifying the coding of CLASSMARK 2




Not supporting the Classmark Information Type 3 IE

Adding the Classmark Information Type 3 IE



Interference Band to Be Used

Supporting the Interference Band to Be Used IE




RR Cause Supporting the RR Cause IE

Supporting the RR Cause IE



Trace Number Supporting the Trace Number IE

Deleting the Trace Number IE



Layer 3 Information

Supporting the Layer 3 Information IE




DLCI Supporting the DLCI IE

Supporting the DLCI IE Supporting the DLCI IE Supporting the DLCI IE

Downlink DTX Flag

Supporting the Downlink DTX Flag IE




Cell Identifier List

Supporting the Cell Identifier List IE

Supporting the Cell Identifier List IE

Adding the support for PCS1900

Supporting inter-RAT handover

Adding 3 types of Cell Identification

Response Request

Supporting the Response Request IE








Resource Indication Method

Supporting the Resource Indication Method IE









Circuit Identity Code List

Not supporting the Circuit Identity Code List IE

Adding the Circuit Identity Code List IE

Supporting the Circuit Identity Code List IE

Supporting the Circuit Identity Code List IE

Diagnostic Not supporting the Diagnostic IE

Adding the Diagnostic IE

Supporting the Diagnostic IE

Supporting the Diagnostic IE

Layer 3 Message Contents

Not supporting the IE

Adding Supporting the IE Supporting the IE

Chosen Channel Not supporting the Layer 3 Message Contents IE

Adding the Layer 3 Message Contents IE

Adding the channel mode field

Adding the support for multiple channels

Supporting the Layer 3 Message Contents IE

Total Resource Accessible

Not supporting the Total Resource Accessible IE

Adding the Total Resource Accessible IE

Supporting the Total Resource Accessible IE

Supporting the Total Resource Accessible IE

Cipher Response Mode

Not supporting the Cipher Response Mode IE

Adding the Cipher Response Mode IE

Supporting the Cipher Response Mode IE

Supporting the Cipher Response Mode IE

Channel Needed Not supporting the Channel Needed IE

Adding the Channel Needed IE

Changing the coding of this IE

Supporting full-rate or half-rate service

Supporting the Channel Needed IE

Trace Type Not supporting the Trace Type IE

Adding the Trace Type IE

Supporting the Trace Type IE

Supporting the Trace Type IE

Trigger Id Not supporting the Trigger Id IE

Adding the Trigger Id IE Supporting the Trigger Id IE

Supporting the Trigger Id IE

Trace Reference Not supporting the Trace Reference IE

Adding the Trace Reference IE

Supporting the Trace Reference IE

Supporting the Trace Reference IE





Transaction Id Not supporting the Transaction Id IE

Adding the Transaction Id IE

Supporting the Transaction Id IE

Supporting the Transaction Id IE

Mobile Identity Not supporting the Mobile Identity IE

Adding the Mobile Identity IE

Supporting the Mobile Identity IE

Supporting the Mobile Identity IE

OMC Id Not supporting the OMC Id IE

Adding the OMC Id IE Supporting the OMC Id IE

Supporting the OMC Id IE

Forward Indicator

Not supporting the Forward Indicator IE

Adding the Forward Indicator IE

Supporting the Forward Indicator IE

Supporting the Forward Indicator IE

Chosen Encryption Algorithm

Not supporting the Chosen Encryption Algorithm IE

Adding the Chosen Encryption Algorithm IE

Supporting the Chosen Encryption Algorithm IE

Supporting the Chosen Encryption Algorithm IE

Circuit Pool Not supporting the Circuit Pool IE

Not supporting the Circuit Pool IE

Adding the Circuit Pool IE

Adding several types of circuit pools for the EDGE and HSCSD services

Circuit Pool List

Not supporting the Circuit Pool List IE

Not supporting the Circuit Pool List IE

Adding the Circuit Pool List IE

Supporting the Circuit Pool List IE

Time Indication Not supporting the Time Indication IE

Not supporting the Time Indication IE

Adding the Time Indication IE

Supporting the Time Indication IE

Resource Situation

Not supporting the Resource Situation IE

Not supporting the Resource Situation IE

Adding the Resource Situation IE

Supporting the Resource Situation IE

Current Channel Type 1

Not supporting the Current Channel Type 1 IE

Not supporting the Current Channel Type 1 IE

Adding the Current Channel Type 1 IE

Supporting the Current Channel Type 1 IE

Queuing Indicator

Not supporting the Queuing Indicator IE

Not supporting the Queuing Indicator IE

Adding the Queuing Indicator IE

Supporting the Queuing Indicator IE

Speech Version Not supporting the Speech Version IE

Not supporting the Speech Version IE

Adding the Speech Version IE

Supporting the Speech Version IE

Assignment Requirement

Not supporting the Assignment Requirement IE

Not supporting the Assignment Requirement IE

Adding the Assignment Requirement IE

Supporting the Assignment Requirement IE





Talker Flag Not supporting the Talker Flag IE

Not supporting the Talker Flag IE

Adding the Talker Flag IE Supporting the Talker Flag IE

Connection Release Requested

Not supporting the Connection Release Requested IE

Not supporting the Connection Release Requested IE

Adding the Connection Release Requested IE

Supporting the Connection Release Requested IE

Group Call Reference

Not supporting the Group Call Reference IE

Not supporting the Group Call Reference IE

Adding the Group Call Reference IE

Supporting the Group Call Reference IE

EMLPP Priority

Not supporting the EMLPP Priority IE

Not supporting the EMLPP Priority IE

Adding the EMLPP Priority IE

Supporting the EMLPP Priority IE


Not supporting the Configuration Evolution Indication IE

Not supporting the Configuration Evolution Indication IE

Adding the Configuration Evolution Indication IE

Supporting the Configuration Evolution Indication IE

Old BSS to New BSS Information

Not supporting the Old BSS to New BSS Information IE

Not supporting the Old BSS to New BSS Information IE

Adding the Old BSS to New BSS Information IE

Supporting the Old BSS to New BSS Information IE

LSA Identifier Not supporting the LSA Identifier IE

Not supporting the LSA Identifier IE

Adding the LSA Identifier IE

Supporting the LSA Identifier IE

LSA Identifier List

Not supporting the LSA Identifier List IE

Not supporting the LSA Identifier List IE

Adding the LSA Identifier List IE

Supporting the LSA Identifier List IE

LSA Information

Not supporting the LSA Information IE

Not supporting the LSA Information IE

Adding the LSA Information IE

Supporting the LSA Information IE

LCS QoS Not supporting the LCS QoS IE

Not supporting the LCS QoS IE

Adding the LCS QoS IE Supporting the LCS QoS IE


Not supporting the LSA Access Control Suppression IE

Not supporting the LSA Access Control Suppression IE

Adding the LSA Access Control Suppression IE

Supporting the LSA Access Control Suppression IE

LCS Priority Not supporting the LCS Priority IE

Not supporting the LCS Priority IE

Adding the LCS Priority IE

Supporting the LCS Priority IE





Location Type Not supporting the Location Type IE

Not supporting the Location Type IE

Adding the Location Type IE

Supporting the Location Type IE

Location Estimate

Not supporting the Location Estimate IE

Not supporting the Location Estimate IE

Adding the Location Estimate IE

Supporting the Location Estimate IE

Positioning Data

Not supporting the Positioning Data IE

Not supporting the Positioning Data IE

Adding the Positioning Data IE

Supporting the Positioning Data IE

LCS Cause Not supporting the LCS Cause IE

Not supporting the LCS Cause IE

Adding the LCS Cause IE Supporting the LCS Cause IE

LCS Client Type

Not supporting the LCS Client Type IE

Not supporting the LCS Client Type IE

Adding the LCS Client Type IE

Supporting the LCS Client Type IE

APDU Not supporting the APDU IE

Not supporting the APDU IE

Adding the APDU IE Supporting the APDU IE

Network Element Identity

Not supporting the Network Element Identity IE

Not supporting the Network Element Identity IE

Adding the Network Element Identity IE

Supporting the Network Element Identity IE

GPS Assistance Data

Not supporting the GPS Assistance Data IE

Not supporting the GPS Assistance Data IE

Adding the GPS Assistance Data IE

Supporting the GPS Assistance Data IE

Deciphering Keys

Not supporting the Deciphering Keys IE

Not supporting the Deciphering Keys IE

Adding the Deciphering Keys IE

Supporting the Deciphering Keys IE

Return Error Request

Not supporting the Return Error Request IE

Not supporting the Return Error Request IE

Adding the Return Error Request IE

Supporting the Return Error Request IE

Return Error Cause

Not supporting the Return Error Cause IE

Not supporting the Return Error Cause IE

Adding the Return Error Cause IE

Supporting the Return Error Cause IE

Segmentation Not supporting the Segmentation IE

Not supporting the Segmentation IE

Adding the Segmentation IE

Supporting the Segmentation IE

Service Handover

Not supporting the Service Handover IE



Adding the Service Handover IE






Not supporting the Source RNC to Target RNC Transparent Information (UMTS) IE



Adding the Source RNC to Target RNC Transparent Information (UMTS) IE

Source RNC to Target RNC Transparent Information (cdma2000)

Not supporting the Source RNC to Target RNC Transparent Information (cdma2000) IE



Adding the Source RNC to Target RNC Transparent Information (cdma2000) IE

Dual Transfer Mode Information

Not supporting the Dual Transfer Mode Information IE



Adding the Dual Transfer Mode Information IE

Inter RAT Handover Info

Not supporting the Inter RAT Handover Info IE



Adding the Inter RAT Handover Info IE

Cdma2000 Capability Information

Not supporting the Cdma2000 Capability Information IE



Adding the Cdma2000 Capability Information IE

HUAWEI BSC6000 Base Station Subsystem BSS Signaling Analysis Guide C Reference for GSM Protocols

Issue 01 (2008-06-10) Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd C-1

C Reference for GSM Protocols

C.1 Reference for GSM Protocols Number Short Title

01 series: GSM system description

01.00 Working Procedures for SMG

01.01 GSM Release 1999 Specifications

01.02 General Description of a GSM Public Land Mobile Network (PLMN)

01.04 Abbreviations and Acronyms

01.31 Fraud Information Gathering System (FIGS); Service requirements - Stage 0

01.33 Lawful Interception requirements for GSM

01.48 ISDN-based DECT/GSM interworking; Feasibility Study

01.56 GSM Cordless Telephony System (CTS) (Phase 1); CTS Authentication and Key Generation Algorithms Requirements

01.60 GPRS requirements

01.61 General Packet Radio Service (GPRS)

02 series: GSM services

02.01 Principles of Telecommunication Services Supported by a GSM Public Land Mobile Network(PLMN)

02.02 Bearer Services (BS) Supported by a GSM Public Land Mobile Network (PLMN)

02.03 Teleservices Supported by a GSM Public Land Mobile Network (PLMN)

02.04 General on Supplementary Services

02.06 Types of Mobile Stations (MS)

02.07 Mobile Station (MS) Features

02.08 European digital cellular telecommunication system (Phase 2); Quality of service.

C Reference for GSM Protocols HUAWEI BSC6000 Base Station Subsystem


C-2 Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd Issue 01 (2008-06-10)

Number Short Title

02.09 Security aspects

02.11 Service Accessibility

02.16 International Mobile Station Equipment Identities (IMEI)

02.17 Subscriber Identity Modules, Functional Characteristics

02.19 Subscriber Identity Module Application Programming Interface (SIM API); Service description-Stage 1

02.22 Stage 1 for Personalization of GSM ME

02.24 Description of Charge Advice Information (CAI)

02.30 Man-machine Interface (MMI) of the Mobile Station (MS)

02.31 Fraud Information Gathering System (FIGS) Service description - Stage 1

02.32 Immediate Service Termination (IST); Service description - Stage 1

02.33 Lawful intercept Stage 1

02.34 High Speed Circuit Switched Data (HSCSD) - Stage 1

02.40 Procedures for Call Progress Indications

02.41 Operator Determined Barring

02.42 Network Identity and Time zone (NITZ); Service Description, Stage 1

02.43 Support of Localized Service Area (SoLSA); Service description; Stage 1

02.48 Security mechanisms for the SIM Application Tool kit; Stage 1

02.53 Tandem Free Operation (TFO); Service description; Stage 1

02.56 GSM Cordless Telephony System (CTS), Phase 1; Service description; Stage 1

02.60 General Packet Radio Service Stage 1 Description

02.63 Packet Data on Signaling channels Service (PDS) - Stage 1

02.66 Support of Mobile Number Portability (MNP); Service description; Stage 1

02.67 Enhanced Multi-Level Precedence and Pre-emption Service (eMLPP) - Stage 1

02.68 Voice Group Call Service (VGCS); Stage 1(ASCI spec)

02.69 Voice Broadcast Service (VBS); Stage 1(ASCI spec)

02.71 Location Services (LCS) - Stage 1

02.72 Call Deflection Service description, Stage 1

02.76 Noise Suppression for the AMR

02.78 Customized Applications for Mobile network Enhanced Logic (CAMEL); Service definition (Stage 1)

02.79 Support of Optimal Routeing (SOR); Service definition(Stage 1)



Number Short Title

02.81 Line Identification Supplementary Services - Stage 1

02.82 Call Forwarding (CF) Supplementary Services - Stage 1

02.83 Call Waiting (CW) and Call Hold (HOLD) Supplementary Services - Stage 1

02.84 MultiParty (MPTY) Supplementary Services - Stage 1

02.85 Closed User Group (CUG) Supplementary Services -Stage 1

02.86 Advice of Charge (AoC) Supplementary Services – Stage 1

02.87 User-to-User Signaling (UUS) Service Description, Stage 1

02.88 Call Barring (CB) Supplementary Services - Stage 1

02.90 Stage 1 Decision of Unstructured Supplementary Service Data (USSD)

02.91 Explicit Call Transfer (ECT)

02.93 Completion of Calls to Busy Subscriber (CCBS) Service Description - Stage 1

02.94 Follow Me Service description - Stage 1

02.95 Digital cellular telecommunications system (Phase 2+); Support of Private Numbering Plan (SPNP); Service description, Stage 1

02.96 Name Identification Supplementary Services; Stage 1

02.97 Multiple Subscriber Profile (MSP) Service description, Stage 1

03 services: GSM network

03.01 Network Functions

03.02 Network Architecture

03.03 Numbering, Addressing and Identification

03.04 Signaling requirements relating to routeing of calls to mobile subscribers

03.05 Technical Performance Objectives

03.07 Restoration Procedures

03.08 Organization of Subscriber Data

03.09 Handover Procedures

03.10 Public Land Mobile Network (PLMN) Connection Types

03.11 Technical Realization of Supplementary Services -General Aspects

03.12 Location Registration Procedures

03.13 Discontinuous Reception (DRX) in the GSM System

03.14 Support of Dual Tone Multi-Frequency Signaling(DTMF) through the GSM System

03.15 Technical Realization of Operator Determined Barring




Number Short Title

03.16 Subscriber Data Management

03.18 Basic Call Handling

03.19 GSM API for SIM toolkit stage 2

03.20 Security-related Network Functions

03.22 Functions related to Mobile Station (MS) in idle mode

03.26 Multiband operation of GSM/DCS 1800 by a single operator

03.30 Radio Network Planning Aspects

03.31 Fraud Information Gathering System (FIGS); Service description - Stage 2

03.32 Universal Geographical Area Description (GAD)

03.33 Lawful Interception - stage 2

03.34 High Speed Circuit Switched Data (HSCSD); Stage 2

03.35 Immediate Service Termination (IST); Stage 2

03.38 Alphabets and Language Specific Information for GSM

03.39 Digital Cellular Telecommunications System (Phase 2)Interface Protocols for the Connection of Short Message, Service Centers (SMSCs) to Short Message Entities (SMEs)

03.40 Technical Realization of the Short Message Service(SMS) Point-to-Point (PP)

03.41 Technical Realization of Short Message Service Cell Broadcast (SMSCB)

03.42 SMS Compression

03.43 Support of Videotext

03.44 Support of Teletext in a Public Land Mobile Network (PLMN)

03.45 Technical realization of facsimile Group 3 service- transparent

03.46 Technical realization of facsimile group 3 service - non-transparent

03.47 Example Protocol Stacks for Interconnecting Service Centre(s) (SC) and Mobile Services Switching Centre(s) (MSC)

03.48 Tool Kit Security Stage 2

03.49 Example Protocol Stacks for Interconnecting Cell Broadcast Centre (CBC) and Base Station Controller (BSC)

03.50 Transmission Planning Aspects of the Speech Service in the GSM Public Land Mobile Network (PLMN) System

03.52 Lower layers of the GSM Cordless Telephony System (CTS) radio interface - Stage 2

03.53 Tandem Free Operation (TFO); Service description, Stage 2

03.54 Description for the use of a Shared Inter Working Function (SIWF) in a GSM PLMN; Stage 2



Number Short Title

03.56 GSM Cordless Telephony System (CTS), Phase 1; CTS Architecture Description; Stage 2

03.57 Mobile Station Application Execution Environment (MExE); Functional description; Stage 2

03.58 Characterization, test methods and quality assessment for handsfree Mobile Stations (MSs)

03.60 General Packet Radio Service (GPRS) Service description; Stage 2

03.63 PDS Stage 2

03.64 Overall description of the GPRS radio interface; Stage 2

03.66 Support of GSM Mobile Number Portability (MNP);Stage 2

03.67 Enhanced Multi-Level Precedence and Preemption Service (EMLPP); Stage 2

03.68 Voice Group Call Service (VGCS) - Stage 2

03.69 Voice Broadcast service (VBS) - Stage 2

03.70 Routeing of calls to/from Public Data Network (PDN)

03.71 Location Services (LCS) Stage 2

03.72 Call Deflection stage 2

03.73 Support of Localized Service Area (SoLSA); Stage 2

03.78 CAMEL Phase 2; Stage 2

03.79 Support of Optimal Routeing

03.81 Line Identification Supplementary Services; Stage 2

03.82 Call Forwarding (CF) Supplementary Services; Stage 2

03.83 Call Waiting (CW) and Call Hold (HOLD) Supplementary Services; Stage 2

03.84 Multi Party (MPTY) Supplementary Services; Stage 2

03.85 Closed user Group (CUG) Supplementary Services; Stage 2

03.86 Advice of Charge (AoC) Supplementary Services; Stage 2

03.87 User-to-user signaling (UUS); Stage 2

03.88 Call Barring (CB) supplementary services - Stage 2

03.90 Unstructured Supplementary Service Data (USSD)

03.91 Explicit Call Transfer (ECT) Supplementary Service; Stage 2

03.93 Technical realization of Completion of Calls to Busy Subscriber (CCBS); Stage 2


03.97 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




Number Short Title

04.02 GSM Public Land Mobile Network (PLMN) Access Reference Configuration

04.03 Mobile Station - Base Station System (MS - BSS) Interface Channel Structures and Access Capabilities

04.04 Layer 1 - General Requirements

04.05 Data Link (DL) Layer General Aspects

04.06 Mobile Station - Base Stations System (MS - BSS) Interface Data Link (DL) Layer Specification

04.07 Mobile Radio Interface Signaling Layer 3 – General Aspects

04.08 Mobile Radio Interface - Layer 3 Specification

04.10 Mobile Radio Interface Layer 3 – Supplementary Services Specification - General Aspects

04.11 Point-to-Point (PP) Short Message Service (SMS) Support on Mobile Radio Interface

04.12 Short Message Service Cell Broadcast (SMSCB) Support on the Mobile Radio Interface

04.13 Performance Requirements on Mobile Radio Interface

04.14 Individual equipment type requirements and interworking; Special conformance testing functions

04.18 Mobile Radio Interface Layer 3 specification; Radio Resource Control Protocol

04.21 Rate Adaption on the Mobile Station - Base Station System (MS-BSS) Interface

04.22 Radio Link Protocol for Data and Telematic Services on the MS-BSS Interface

04.30 Location Services (LCS); Mobile radio interface layer 3 supplementary services specification; Mobile Originating Location Request (MO-LR)

04.31 Location Services (LCS); Mobile Station (MS) - Serving Mobile Location Centre (SMLC); Radio Resource LCS Protocol (RRLP)

04.33 Lawful intercept Stage 3

04.35 Location Services (LCS); Broadcast Network Assistance for Enhanced Observed Time Difference (E-OTD) and Global Positioning System (GPS) Positioning Methods

04.53 Inband Tandem Free Operation of Speech codecs, Service Description, stage 3

04.56 GSM Cordless Telephony System (CTS), (Phase 1) CTS Radio Interface Layer 3 Specification

04.57 GSM Cordless Telephony System (CTS), (Phase 1) CTS supervising system Layer 3 Specification

04.60 General Packet Radio Service (GPRS); Mobile Station (MS) - Base Station System (BSS) interface; Radio Link Control/ Medium Access Control (RLC/MAC) protocol

04.63 Packet Data on Signaling channels Service (PDS) Service Description, Stage 3

04.64 Mobile Station - Serving GPRS Support Node (MS-SGSN) Logical Link Control (LLC) Layer Specification

04.65 Mobile Station (MS) - Serving GPRS Support Node (SGSN); Subnetwork Dependent Convergence Protocol (SNDCP)

04.67 Enhanced Multi-Level Precedence and Pre-emption service (eMLPP) - Stage 3



Number Short Title

04.68 Group Call Control (GCC) Protocol

04.69 Broadcast Call Control (BCC) Protocol - Stage 3

04.71 Location Services (LCS) Stage 3

04.72 Call Deflection (CD) Supplementary Service; Stage 3

04.80 Mobile Radio Interface Layer 3 – Supplementary Services Specification Formats and Coding

04.81 Line Identification Supplementary Services - Stage 3

04.82 Call Forwarding (CF) Supplementary Services - Stage 3

04.83 Call Waiting (CW) and Call Hold (HOLD) Supplementary Services - Stage 3

04.84 Multi Party (MPTY) Supplementary Services - Stage 3

04.85 Closed User Group (CUG) Supplementary Services - Stage 3

04.86 Advice of Charge (AoC) Supplementary Services - Stage 3

04.87 User-to-User Signaling (UUS) Supplementary Service Stage 3

04.88 Call Barring (CB) Supplementary Services - Stage 3

04.90 Unstructured Supplementary Service Data (USSD)

04.91 Explicit Call Transfer (ECT) Supplementary Service -Stage 3

04.93 Completion of Calls to Busy Subscriber (CCBS); Stage 3


05 series: physical layer on the radio path (L1 context on the Um interface)

05.01 Physical Layer on the Radio Path (General Description)

05.02 Multiplexing and Multiple Access on the Radio Path

05.03 Channel Coding

05.04 Modulation

05.05 Radio Transmission and Reception

05.08 Radio Subsystem Link Control

05.09 Link Adaptation

05.10 Radio Subsystem Synchronization

05.22 Radio Link management in hierarchical networks

05.50 Background for RF Requirements

05.56 CTS-FP Radio Sub-system

06 series: Speech Codec Specifications

06.01 Full Rate Speech Processing Functions




Number Short Title

06.02 Half Rate Speech Processing Functions

06.06 Half Rate Speech - Part 7: ANSI-C Code for GSM Half Rate Speech Codec

06.07 Half Rate Speech - Part 8: Test Sequence for GSM Half Rate Speech Codec

06.08 Half Rate Speech; Performance Characterization of the GSM half rate speech codec

06.10 Full Rate Speech Transcoding

06.11 Substitution and Muting of Lost Frames for Full Rate Speech Channels

06.12 Comfort Noise Aspects for Full Rate Speech Traffic Channels

06.20 Half Rate Speech Transcoding

06.21 Substitution and Muting of Lost Frames for Half Rate Speech Traffic Channels

06.22 Comfort Noise Aspects for Half Rate Speech Traffic Channels

06.31 Discontinuous Transmission (DTX) for Full Rate Speech Traffic Channels

06.32 Voice Activity Detection (VAD)

06.41 Discontinuous Transmission (DTX) for Half Rate Speech Traffic Channels

06.42 Voice Activity Detection (VAD) for Half Rate Speech Traffic Channels

06.51 Enhanced full rate speech processing functions: General description

06.53 ANSI-C code for the enhanced full rate speech codec

06.54 Test sequences for the GSM Enhanced Full Rate (EFR)

06.55 Performance characterization of the GSM EFR Speech Codec

06.60 Enhanced full rate speech transcoding

06.61 Substitution and muting of lost frames for enhanced full rate speech traffic channels

06.62 Comfort noise aspects for Enhanced Full Rate (EFR) speech traffic channels

06.71 Adaptive Multi-Rate speech processing functions; General description

06.73 ANSI-C code for the GSM Adaptive Multi Rate (AMR) speech codec

06.74 Test sequences for the GSM Adaptive Multi Rate (AMR) speech codec

06.75 AMR performance characterization

06.76 ANSI-C code of the selected AMR-NS algorithm

06.77 Minimum Performance Requirements for Noise Suppresser Application to the AMR Speech Encoder

06.78 Results of the AMR noise suppression selection phase

06.81 Discontinuous Transmission (DTX) for enhanced full rate speech traffic channels

06.82 Voice Activity Detection (VAD) for enhanced full rate speech traffic channels



Number Short Title

06.85 Subjective tests on the interoperability of the HR/FR/EFR speech codecs; single, tandem and tandem free operation

06.90 Adaptive Multi-Rate speech transcoding

06.91 Substitution and muting of lost frames for AMR speech traffic channels

06.92 Comfort noise aspects for Adaptive Multi-Rate speech traffic channels

06.93 Discontinuous Transmission (DTX) for Adaptive Multi-Rate speech traffic channels

06.94 Voice Activity Detector (VAD) for Adaptive Multi Rate(AMR) speech traffic channels

07 series: Terminal Adaptation Functions of Mobile Station

07.01 General on Terminal Adaptation Functions (TAF) for Mobile Stations (MS)

07.02 Terminal Adaptation Functions (TAF) for Services Using Asynchronous Bearer Capabilities

07.03 Terminal Adaptation Functions (TAF) for Services Using Synchronous Bearer Capabilities

07.05 Use of Data Terminal Equipment - Data Circuit Terminating Equipment (DTE-DCE) Interface for Short Message Services (SMS) and Cell Broadcast Services(CBS)

07.07 AT Command set for GSM Mobile Equipment

07.08 GSM Application Programming Interface

07.10 Terminal Equipment to Mobile Station (TE-MS) multiplexer protocol

07.60 General Packet Radio Service (GPRS); Mobile Station(MS) supporting GPRS

08 series: BTS-MSC interfaces (the A and Abis interfaces)

08.01 General Aspects on the BSS-MSC Interface

08.02 Base Station System - Mobile Services Switching Centre(BSS-MSC) Interface - Interface Principles

08.04 Base Station System - Mobile Services Switching Centre (BSS-MSC) Interface Layer 1 Specification

08.06 Signaling Transport Mechanism Specification for the Base Station System - Mobile Services Switching Centre (BSS-MSC) Interface

08.08 Mobile Switching Centre - Base Station system (MSC-BSS) Interface Layer 3 Specification

08.14 General Packet Radio Service (GPRS); Base Station System (BSS) - Serving GPRS Support Node (SGSN) interface; Gb Interface Layer 1

08.16 General Packet Radio Service (GPRS); Base Station System (BSS) - Serving GPRS Support Node (SGSN) Interface; Network Service

08.18 General Packet Radio Service (GPRS); Base Station System (BSS) - Serving GPRS Support Node (SGSN); BSS GPRS Protocol

08.20 Rate Adaptation on the BSS-MSC Interface




Number Short Title

08.31 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)

08.51 Base Station Controller - Base Transceiver Station (BSC-BTS) Interface General Aspects

08.52 Base Station Controller - Base Transceiver Station (BSC-BTS) Interface - Interface Principles

08.54 Base Station Controller - Base Transceiver Station (BSC-BTS) Interface Layer 1 Structure of Physical Circuits

08.56 Base Station Controller - Base Transceiver Station (BSC-BTS) Interface Layer 2 Specification

08.58 Base Station Controller - Base Transceiver Station (BCS-BTS) Interface Layer 3 Specification

08.59 BSC-BTS O&M Signaling Transport

08.60 Inband Control of Remote Transcoders and Rate Adaptors

08.61 Inband Control of Remote Transcoder and Rate Adaptors;(Half Rate)

08.62 Inband Tandem Free Operation (TFO) of Speech Codecs; Service Description; Stage 3

08.71 Location services (LCS) SMLC-BSS interface L3

09 series: Network interworking

09.01 General Network Interworking scenarios

09.02 Mobile Application Part ( MAP) Specification

09.03 Signaling Requirements on Interworking between the Integrated Services Digital Network (ISDN), or Public Switched Telephone Network (PSTN) and the Public Land Mobile Network (PLMN)

09.04 Interworking between the Public Land Mobile Network and the CSPDN

09.05 Interworking between PLMN and PAD access

09.06 Interworking between PLMN and a Packet Switched Public Data Network/Integrated Services digital, Network (PSPDN/ISDN) for Support of Packet Switched Data Transmission Services

09.07 General Requirements on Interworking between the Public Land Mobile Network (PLMN) and the Integrated Services Digital Network (ISDN) or Public Switched Telephone Network (PSTN)

09.08 Application of the Base Station System Application Part (BSSAP) on the E-Interface

09.09 Detailed Signaling Interworking within the PLMN, with the PSTN/ISDN

09.10 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)

09.11 Signaling Interworking for Supplementary Services

09.12 Application of ISUP Version 2 for the ISDN-PLMN (GSM) signaling

09.13 Signaling interworking between ISDN supplementary services Application Service Element (ASE) and Mobile Application Part (MAP) protocols



Number Short Title

09.14 Application of ISUP Version 3 for the ISDN-PLMN Signaling

09.16 General Packet Radio Service (GPRS); Serving GPRS Support Node (SGSN) - Visitors Location Register (VLR); Gs interface network service specification

09.18 General Packet Radio Service (GPRS); Serving GPRS Support Node (SGSN) - Visitors Location Register(VLR); Gs interface layer 3 specification

09.31 Location Services (LCS); Base Station System Application Part LCS Extension (BSSAP-LE)

09.60 General Packet Radio Service (GPRS); GPRS Tunneling Protocol (GPT) across the Gn and Gp Interface

09.61 General Packet Radio Service (GPRS); Interworking between the Public Land Mobile Network (PLMN) supporting GPRS and Packet

09.78 CAMEL Application Part phase 2 (stage 3)

09.90 Interworking between Phase 1 Infrastructure and Phase 2 Mobile Stations (MS)

09.91 Interworking Aspects of the SIM/ME Interface Between Phase 1 and Phase 2

09.94 Recommended Infrastructure Measures to Overcome Specific Phase 1 Mobile Stations Faults

10 series

10.00 Digital Cellular Telecommunication System Feature Description

10.43 Support of Localized Service Area (SoLSA); Work Item Status

10.56 Project scheduling and open issues: GSM Cordless Telephony System CTS, Phase 1

10.57 Project scheduling and open issues: Mobile Station Execution Environment (MExE)

10.59 Project scheduling and open issues for EDGE

10.78 Project scheduling and open issues: CAMEL

11 series: specifications of equipments and models

11.10-1 Conformance Specification

11.10-2 Mobile Station (MS) Conformance Specification, Part 2 – ICS

11.10-3 Mobile Station (MS) Conformance Specification, Part 3 – Abstract Test suites

11.10-4 SIM Application Toolkit conformance Specification

11.11 Specification of the Subscriber Identity Module - Mobile Equipment (SIM-ME) Interface

11.14 Phase 2+ SIM Application Tool kit

11.17 SIM test specification

11.18 Specification of the 1.8 Volt Subscriber Identity Module - Mobile Equipment (SIM - ME) Interface

11.19 CTS SIM Fixed Part

11.21 GSM Radio Aspects Base Station System Equipment Specification




Number Short Title

11.23 GSM Signaling Aspects Base Station System equipment Specification

11.24 GSM transcoding and rate adaptation: Base station

11.26 GSM Repeater Equipment Specification

11.30 Mobile Services Switching Centre

11.31 Home Location Register specification

11.32 Visitor Location Register specification

12 series: O&M

12.00 Objectives and structure of GSM Public Land Mobile Network (PLMN) management

12.01 Common Aspects of Public Land Mobile Network (PLMN) Management

12.02 Subscriber, Mobile Equipment (ME) and Services Data Administration

12.03 Security Management

12.04 Performance Management and Measurements for a GSM Public Land Mobile Network (PLMN)

12.05 Subscriber Related Call and Event Data

12.06 Network Configuration Management and Administration

12.07 Operations and performance management

12.08 Subscriber and Equipment trace

12.11 Fault management of the Base Station System (BSS)

12.15 General Packet Radio Service (GPRS); GPRS Charging

12.20 Base Station System (BSS) Management Information

12.21 Network Management (NM) Procedures and Messages on the Abis Interface

12.22 Interworking of GSM Network Management (NM) Procedures and Messages at the Base Station Controller (BSC)

12.30 ETSI Object Identifier Tree; Mobile Domain O&M

12.71 Location Services (LCS); Location services management

13 series: Attachment requirements for GSM

13.01 Attachment requirements for Global System for Mobile communications (GSM) mobile stations; Access

13.02 Attachment requirements for mobile stations in the DCS 1800 band and additional GSM 900 band Access

13.11 Terminal essential requirements (RTTE)

13.21 BSS Radio aspects requirements (RTTE)



Number Short Title

13.34 Attachment requirements for Global System for Mobile communications (GSM); High Speed Circuit Switched Data (HSCSD) Multislot Mobile Stations Access

13.55 Attachment requirements for Cordless Telephony System Fixed Part (CTS-FP) Access

13.56 Cordless Telephony System Mobile Stations (CTS-MS) Access

13.60 Attachment requirements for Global System for Mobile communications (GSM); General Packet Radio Service (GPRS); Mobile stations Access

13.67 Attachment requirements for Global System for Mobile communications (GSM); Railways Band(R-GSM); Mobile Stations; Access

13.68 Attachment requirements for Global System for Mobile communications (GSM); Advanced Speech Call Items (GSM-ASCI) Mobile Stations; Access

HUAWEI BSC6000 Base Station Subsystem BSS Signaling Analysis Guide D Timers

Issue 01 (2008-06-10) Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd D-1

D Timers

D.1 Timers of Radio Resource Management D.1.1 Timers on the MS Side

Timer Function Timer Length

T3120 This timer is started when the MS sends a Channel Request message to the network.

The value of timer T3120 is set to a random value according to relevant rules. The maximum value of this timer is 5 seconds.

T3122 This timer is used during the random access. The MS starts timer T3122 after the receipt of an Immediate Assignment Reject message.

The value of timer T3122 is given by the network in the Immediate Assignment Reject message.

T3124 During the asynchronous handover, the MS starts repeating the Handover Access message and starts timer T3124.

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.

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.

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.

D.1.2 Timers on the Network Side Timer Function Timer Length

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

The value of timer T3101 must be greater than the maximum time for a L2 establishment attempt.

T3103 This timer is started when the BSC sends a Handover Command message to the MS. This timer is stopped when the BSC receives the

The value of timer T3103 > the maximum transmission time of the Handover Command message + the value of timer T3124 + the

D Timers HUAWEI BSC6000 Base Station Subsystem


D-2 Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd Issue 01 (2008-06-10)

Timer Function Timer Length Handover Complete message for an intra-BSC handover or the Channel Release message for an inter-BSC handover.

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

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

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.

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

The value of timer T3109 must be greater than the value of RADIO_LINK_TIMEOUT multiplied by 0.480 second.

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

The value of timer T3111 is equal to the value of timer T3110.

T3113 This timer is started when the MSC sends a Paging Request message and is stopped when the MSC receives the Paging Response message.

The value of timer T3113 must be greater than the value of timer T3120 plus the value of timer T3101.

T10 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

7 seconds



Timer Function Timer Length from the MSC.

D.2 Timers of Mobility Management D.2.1 Timers on the MS Side


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

20 seconds

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.

15 seconds

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.





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

4 seconds

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

5 seconds

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

15 seconds

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

10 seconds


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

5 seconds

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

5 seconds

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

5 seconds



D.3 Timers of Circuit-Switched Call Control D.3.1 Timers on the MS Side


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

30 seconds

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

30 seconds

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

30 seconds

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

30 seconds

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

30 seconds

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

30 seconds


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

The minimum value of timer T301 is 180 seconds.

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

The value of timer T303 is set by the network operator.

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

30 seconds

T306 This timer is started when the MSC sends a Disconnect message that contains progress indicator #8. This timer

30 seconds




Timer Function Timer Length 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.

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.


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


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


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

30 seconds

D.4 Timers on the A Interface D.4.1 Timers on the MSC Side


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

25 seconds

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

60 seconds




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

35 seconds

D.4.2 Timers on the BSC Side Timer Function Timer Length

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

25 seconds

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


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

30 seconds

Documents

BSS Signaling Analysis