Radio Access Network Protocols and Signalling Analysis Inc Iu Intfce

Chapter 1 UTRAN Interface Protocols and Functions ................................. 1.1 Overview ................................................................................................ 1.2 Uu Interface ............................................................................................ 1.2.
1 Uu Protocol Structure..................................................................... 1.2.2 RRC Functions ............................................................................... 1.2.3 L2 Functions .................................................................................. 1.2.4 L1 Functions .................................................................................. 1.3 Iub Interface ........................................................................................... 1.3.1 Iub Protocol Structure .................................................................... 1.3.2 NBAP Functions ............................................................................. 1.3.3 NBAP Procedures .......................................................................... 1.3.4 Iub FP for Common Transport Channel Data Transfer .................. 1.3.5 Iub FP for Dedicated Transport Channel Data Transfer ................ 1.4 Iur Interface ............................................................................................ 1.4.1 Iur Protocol Structure ..................................................................... 1.4.2 RNSAP Functions .......................................................................... 1.4.3 RNSAP Procedures ....................................................................... 1.4.4 Iur FP for Transport Channel Data Transfer .................................. 1.5 Iu Interface ............................................................................................. 1.5.1 Iu Protocol Structure ...................................................................... 1.5.2 RANAP Functions .......................................................................... 1.5.3 RANAP Procedures ....................................................................... 1.5.4 Iu UP Functions ............................................................................. 1.5.5 GTP-U Functions ........................................................................... 1.5.6 SABP Functions ............................................................................. Chapter 2 Transport Network Layer Procedure Analysis ............................ 2.1 Overview ................................................................................................ 2.2 SAAL ...................................................................................................... 2.2.1 Overview ........................................................................................ 2.2.2 SSCOP .......................................................................................... 2.2.3 SSCF ............................................................................................. 2.2.4 CPCS ............................................................................................. 2.2.5 SAR................................................................................................ 2.2.6 LM .................................................................................................. 2.2.7 SSCOP Message ........................................................................... 2.3 MTP3-B .................................................................................................. 2.3.1 Overview ........................................................................................ 2.3.2 Function ......................................................................................... 2.3.3 Message Structure .........................................................................
1-1 1-1 1-2 1-2 1-4 1-5 1-6 1-6 1-6 1-7 1-9 1-10 1-14 1-18 1-18 1-19 1-20 1-22 1-23 1-23 1-25 1-27 1-29 1-34 1-34 2-1 2-1 2-1 2-1 2-2 2-7 2-8 2-9 2-9 2-10 2-11 2-11 2-12 2-14
2.3.4 Changeover, Changeback, and Management Prohibit .................. 2.3.5 Signalling Network Management and Signalling Link Status ......... 2.3.6 Signalling Network Management and Signalling Route Status ...... 2.3.7 MTP3-B Upper User Message ....................................................... 2.3.8 MTP3-B Test Message .................................................................. 2.3.9 MTP3-B Management Message .................................................... 2.4 ALCAP .................................................................................................... 2.4.1 Overview ........................................................................................ 2.4.2 Function ......................................................................................... 2.4.3 Message Structure ......................................................................... 2.4.4 Establishment Request Message .................................................. 2.5 SCCP ..................................................................................................... 2.5.1 Overview ........................................................................................ 2.5.2 Function ......................................................................................... 2.5.3 Message Structure ......................................................................... 2.5.4 Connection Request Message ....................................................... Chapter 3 Cell Related Procedure Analysis .................................................. 3.1 Overview ................................................................................................ 3.2 Procedures Involved in Cell Setup ......................................................... 3.2.1 Resource Status Indication ............................................................ 3.2.2 Resource Audit .............................................................................. 3.2.3 Cell Setup ...................................................................................... 3.2.4 Common Transport Channel Setup ............................................... 3.2.5 Iub Interface User Plane Setup ...................................................... 3.2.6 System Information Update ........................................................... 3.2.7 Common Measurement Initiation ................................................... 3.2.8 Cell Reconfiguration ....................................................................... 3.2.9 Cell Deletion ................................................................................... 3.2.10 Resource Status Indication Message .......................................... 3.2.11 Audit Response Message ............................................................ 3.2.12 Cell Setup Request Message ...................................................... 3.2.13 Common Transport Channel Setup Request Message ............... 3.2.14 System Information Update Request Message ........................... 3.3 A Cell Setup Example ............................................................................ Chapter 4 System Information Procedure Analysis ..................................... 4.1 Overview ................................................................................................ 4.1.1 System Information Structure ........................................................ 4.1.2 System Information Monitoring Mechanism ................................... 4.1.3 Functions of System Information ...................................................
2-19 2-20 2-23 2-24 2-25 2-26 2-27 2-27 2-28 2-30 2-30 2-31 2-31 2-32 2-33 2-34 3-1 3-1 3-1 3-1 3-2 3-3 3-4 3-4 3-5 3-5 3-6 3-7 3-8 3-12 3-16 3-20 3-26 3-28 4-1 4-1 4-1 4-2 4-2
4.2 System Information Broadcast and Update ............................................ 4.2.1 System Information Broadcast ....................................................... 4.2.2 System Information Update ........................................................... 4.2.3 System Information Message ........................................................ 4.3 System Information Modification Notification ......................................... 4.3.1 Notification by a Value Tag ............................................................ 4.3.2 Notification by a Timer ................................................................... 4.3.3 Paging Type 1 Message ................................................................ Chapter 5 Call Setup and Release Procedure Analysis ............................... 5.1 Overview ................................................................................................ 5.2 Paging .................................................................................................... 5.2.1 Overview ........................................................................................ 5.2.2 Paging for UE in Idle Mode or in PCH State .................................. 5.2.3 Paging for UE in CELL_DCH or CELL_FACH State ...................... 5.2.4 Paging Type 1 Message ................................................................ 5.2.5 Paging Type 2 Message ................................................................ 5.3 RRC Connection Setup .......................................................................... 5.3.1 Overview ........................................................................................ 5.3.2 RRC Connection Setup on DCH .................................................... 5.3.3 RRC Connection Setup on CCH .................................................... 5.3.4 RRC Connection Reject ................................................................. 5.3.5 RRC Connection Request Message .............................................. 5.3.6 RRC Connection Setup Message .................................................. 5.3.7 RRC Connection Reject Message ................................................. 5.3.8 Radio Link Setup Request Message .............................................. 5.4 Direct Transfer ........................................................................................ 5.4.1 Overview ........................................................................................ 5.4.2 Initial Direct Transfer ...................................................................... 5.4.3 Uplink Direct Transfer .................................................................... 5.4.4 Downlink Direct Transfer ................................................................ 5.4.5 Initial Direct Transfer Message ...................................................... 5.4.6 Uplink Direct Transfer Message ..................................................... 5.4.7 Downlink Direct Transfer Message ................................................ 5.5 UE Capability Information Enquiry and Update ...................................... 5.5.1 UE Capability Enquiry .................................................................... 5.5.2 UE Capability Information Update .................................................. 5.6 RAB Setup .............................................................................................. 5.6.1 Overview ........................................................................................ 5.6.2 DCH-DCH ...................................................................................... 5.6.3 CCH-DCH ......................................................................................
4-3 4-3 4-4 4-4 4-7 4-7 4-8 4-8 5-1 5-1 5-1 5-1 5-2 5-3 5-3 5-4 5-5 5-5 5-6 5-7 5-7 5-8 5-11 5-14 5-14 5-18 5-18 5-18 5-19 5-20 5-21 5-23 5-24 5-25 5-26 5-26 5-27 5-27 5-27 5-31
5.6.4 CCH-CCH ...................................................................................... 5.6.5 RAB Assignment Request Message .............................................. 5.6.6 RAB Assignment Response Message ........................................... 5.6.7 Radio Bearer Setup Message ........................................................ 5.7 Call Release ........................................................................................... 5.7.1 Overview ........................................................................................ 5.7.2 Iu Signalling Connection Release .................................................. 5.7.3 RAB Release ................................................................................. 5.7.4 Combined CS Domain Iu and RAB Release .................................. 5.7.5 RRC Connection Release .............................................................. Chapter 6 Mobility Management Procedure Analysis .................................. 6.1 Overview ................................................................................................ 6.2 Forward handover .................................................................................. 6.2.1 Overview ........................................................................................ 6.2.2 Cell Update .................................................................................... 6.2.3 URA Update ................................................................................... 6.2.4 Cell Update Message..................................................................... 6.2.5 URA Update Message ................................................................... 6.3 Soft Handover ........................................................................................ 6.3.1 Overview ........................................................................................ 6.3.2 Radio Link Addition ........................................................................ 6.3.3 Radio Link Deletion ........................................................................ 6.3.4 Radio Link Addition and Deletion ................................................... 6.3.5 Radio Link Setup Request Message .............................................. 6.3.6 Active Set Update Message ........................................................... 6.4 Hard Handover ....................................................................................... 6.4.1 Overview ........................................................................................ 6.4.2 Compressed Mode ......................................................................... 6.4.3 Iur Interface Hard Handover .......................................................... 6.4.4 Combined Hard Handover ............................................................. 6.4.5 Radio Link Setup Request Message .............................................. 6.4.6 Physical Channel Reconfiguration Message ................................. 6.5 Inter-RAT Handover ............................................................................... 6.5.1 Overview ........................................................................................ 6.5.2 UMTS to GSM Handover ............................................................... 6.5.3 GSM to UMTS Handover ............................................................... 6.5.4 GSM/GPRS to UMTS Cell Reselection ......................................... 6.5.5 UMTS to GSM/GPRS Cell Reselection ......................................... 6.5.6 Handover from UTRAN Command Message................................. 6.5.7 Handover to UTRAN Command Message .....................................
5-32 5-33 5-36 5-38 5-43 5-43 5-43 5-45 5-47 5-49 6-1 6-1 6-1 6-1 6-1 6-3 6-4 6-7 6-8 6-8 6-9 6-10 6-12 6-13 6-13 6-15 6-15 6-16 6-17 6-19 6-22 6-22 6-24 6-24 6-25 6-27 6-29 6-29 6-32 6-33
6.6 Relocation .............................................................................................. 6.6.1 Overview ........................................................................................ 6.6.2 Static Relocation ............................................................................ 6.6.3 Relocation with Hard Handover ..................................................... 6.6.4 Relocation with Forward Handover ................................................ 6.6.5 Relocation Required Message ....................................................... 6.6.6 Relocation Request Message ........................................................ 6.6.7 Relocation Command Message ..................................................... 6.6.8 UTRAN Mobility Information Message ........................................... 6.6.9 Uplink Signalling Transfer Indication Message .............................. Chapter 7 Dynamic Resource Control Procedure Analysis ........................ 7.1 Overview ................................................................................................ 7.2 RAB Modification .................................................................................... 7.2.1 Overview ........................................................................................ 7.2.2 RAB Modification (DCH-DCH) ....................................................... 7.2.3 RAB Assignment Request Message .............................................. 7.2.4 Radio Bearer Reconfiguration Message ........................................ 7.3 Dynamic Channel Reconfiguration ......................................................... 7.3.1 Overview ........................................................................................ 7.3.2 Radio Bearer Reconfiguration ........................................................ 7.3.3 Radio Bearer Reconfiguration Message ........................................ Appendix A Tracing Tools .............................................................................. A.1 About Tracing Tools ............................................................................... A.1.1 RNC Tracing Tool .......................................................................... A.1.2 NodeB Tracing Tool ....................................................................... Appendix B A Typical Call Procedure ........................................................... B.1 Overview ................................................................................................ B.2 Calling Procedure .................................................................................. B.3 Called procedure.................................................................................... Appendix C Acronyms and Abbreviations .................................................... Index .................................................................................................................
6-35 6-35 6-36 6-39 6-41 6-42 6-44 6-46 6-49 6-51 7-1 7-1 7-1 7-1 7-1 7-3 7-3 7-6 7-6 7-7 7-8 A-1 A-1 A-1 A-1 B-1 B-1 B-1 B-4 C-1
HUAWEI
HUAWEI UMTS Radio Access Network Protocols and Signalling Analysis
Huawei Technologies Proprietary
HUAWEI UMTS Radio Access Network Protocols and Signalling Analysis

Manual Version Product Version BOM T2-030223-20050120-C-1.23 BSC6800V100R002 NodeB V100R003 31026523
Huawei Technologies Co., Ltd. provides customers with comprehensive technical support and service. Please feel free to contact our local office or company headquarters.
Huawei Technologies Co., Ltd.

Address: Administration Building, Huawei Technologies Co., Ltd., Bantian, Longgang District, Shenzhen, P. R. China Postal Code: 518129 Website: http://www.huawei.com Email: support@huawei.com
Copyright 2005 Huawei Technologies Co., Ltd.
All Rights Reserved

No part of this manual may be reproduced or transmitted in any form or by any means without prior written consent of Huawei Technologies Co., Ltd.
Trademarks
, HUAWEI, C&C08, EAST8000, HONET,
, ViewPoint, INtess, ETS, DMC,
TELLIN, InfoLink, Netkey, Quidway, SYNLOCK, Radium, M900/M1800, TELESIGHT, Quidview, Musa, Airbridge, Tellwin, Inmedia, VRP, DOPRA, iTELLIN, HUAWEI OptiX, C&C08 iNET, NETENGINE, OptiX, iSite, U-SYS, iMUSE, OpenEye, Lansway, SmartAX, infoX, and TopEng are trademarks of Huawei Technologies Co., Ltd. All other trademarks and trade names mentioned in this manual are the property of their respective holders.
Notice
The information in this manual is subject to change without notice. Every effort has been made in the preparation of this manual to ensure accuracy of the contents, but all statements, information, and recommendations in this manual do not constitute the warranty of any kind, express or implied.
Summary of Updates
This section provides an update history of this manual and introduces the updates of contents.
Update History
This manual is updated for a major product version to maintain consistency with system hardware or software versions and to incorporate customer suggestions. Manual Version T2-030223-20041001-C-1.22 T2-030223-20050120-C-1.23 Notes Initial commercial release Second commercial release
Updates of Contents
Updates between manual versions are cumulative. Therefore, the latest manual version contains all updates made to previous versions.
Updates Made between Versions 1.23 and 1.22

Version 1.23 uses a new template. It optimizes the expression and figures of the document.
About This Manual

Release Notes
This manual applies to BSC6800 V100R002 and NodeB V100R003.
Organization
The manual analyzes protocols and signalling of UMTS Terrestrial Radio Access Network (UTRAN). There are 7 chapters and 3 appendixes in the manual. Chapter 1 UTRAN Interface Protocols and Functions profiles the interfaces, functions and the corresponding protocols of UTRAN. The user planes of Iub/Iur/Iu interfaces are described in this chapter. Chapter 2 Transport Network Layer Procedure Analysis analyzes the signalling procedures and describes the functions of entities in the transport network layer. Chapter 3 Cell Related Procedure Analysis analyzes the cell-related procedures, such as cell setup and common channel setup, and illustrates a cell setup procedure. Chapter 4 System Information Procedure Analysis analyzes the system information procedures. Chapter 5 Call Setup and Release Procedure Analysis mainly analyzes the procedures of RRC connection setup and release as well as RAB setup and release. Chapter 6 Mobility Management Procedure Analysis analyzes the procedures of forward handover, soft handover, hard handover, Inter-RAT handover and SRNS relocation. Chapter 7 Dynamic Resource Control Procedure Analysis analyzes the procedures of RAB modification and dynamic channel reconfiguration. Appendix A Tracing Tools Appendix B A Typical Call Procedure Appendix C Acronyms and Abbreviations
Intended Audience
The manual is intended for the following readers: Technical marketing specialists Operation and maintenance personnel
Conventions
The manual uses the following conventions:
I. General conventions
Convention Arial Arial Narrow Boldface Courier New Description Normal paragraphs are in Arial. Warnings, Cautions, Notes and Tips are in Arial Narrow. Headings are in Boldface. Terminal Display is in Courier New.
II. Symbols
Eye-catching symbols are also used in the manual to highlight the points worthy of special attention during the operation. They are defined as follows:
Caution, Warning, Danger: Means reader be extremely careful during the operation. Note, Comment, Tip, Knowhow, Thought: Means a complementary description.
Protocols and Signalling Analysis HUAWEI UMTS Radio Access Network
Table of Contents
Table of Contents
Chapter 1 UTRAN Interface Protocols and Functions............................................................... 1-1 1.1 Overview ............................................................................................................................ 1-1 1.2 Uu Interface ....................................................................................................................... 1-2 1.2.1 Uu Protocol Structure.............................................................................................. 1-2 1.2.2 RRC Functions ........................................................................................................ 1-4 1.2.3 L2 Functions............................................................................................................ 1-5 1.2.4 L1 Functions............................................................................................................ 1-6 1.3 Iub Interface ....................................................................................................................... 1-6 1.3.1 Iub Protocol Structure ............................................................................................. 1-6 1.3.2 NBAP Functions ...................................................................................................... 1-7 1.3.3 NBAP Procedures ................................................................................................... 1-9 1.3.4 Iub FP for Common Transport Channel Data Transfer......................................... 1-10 1.3.5 Iub FP for Dedicated Transport Channel Data Transfer ....................................... 1-14 1.4 Iur Interface...................................................................................................................... 1-18 1.4.1 Iur Protocol Structure ............................................................................................ 1-18 1.4.2 RNSAP Functions ................................................................................................. 1-19 1.4.3 RNSAP Procedures .............................................................................................. 1-20 1.4.4 Iur FP for Transport Channel Data Transfer ......................................................... 1-22 1.5 Iu Interface ....................................................................................................................... 1-23 1.5.1 Iu Protocol Structure ............................................................................................. 1-23 1.5.2 RANAP Functions ................................................................................................. 1-25 1.5.3 RANAP Procedures .............................................................................................. 1-27 1.5.4 Iu UP Functions..................................................................................................... 1-29 1.5.5 GTP-U Functions .................................................................................................. 1-34 1.5.6 SABP Functions .................................................................................................... 1-34 Chapter 2 Transport Network Layer Procedure Analysis ......................................................... 2-1 2.1 Overview ............................................................................................................................ 2-1 2.2 SAAL.................................................................................................................................. 2-1 2.2.1 Overview ................................................................................................................. 2-1 2.2.2 SSCOP.................................................................................................................... 2-2 2.2.3 SSCF....................................................................................................................... 2-7 2.2.4 CPCS ...................................................................................................................... 2-8 2.2.5 SAR ......................................................................................................................... 2-9 2.2.6 LM ........................................................................................................................... 2-9 2.2.7 SSCOP Message .................................................................................................. 2-10 2.3 MTP3-B............................................................................................................................ 2-11 2.3.1 Overview ............................................................................................................... 2-11
Huawei Technologies Proprietary i
Table of Contents
2.3.2 Function................................................................................................................. 2-12 2.3.3 Message Structure ................................................................................................ 2-14 2.3.4 Changeover, Changeback, and Management Prohibit......................................... 2-19 2.3.5 Signalling Network Management and Signalling Link Status................................ 2-20 2.3.6 Signalling Network Management and Signalling Route Status............................. 2-23 2.3.7 MTP3-B Upper User Message .............................................................................. 2-24 2.3.8 MTP3-B Test Message ......................................................................................... 2-25 2.3.9 MTP3-B Management Message ........................................................................... 2-26 2.4 ALCAP ............................................................................................................................. 2-27 2.4.1 Overview ............................................................................................................... 2-27 2.4.2 Function................................................................................................................. 2-28 2.4.3 Message Structure ................................................................................................ 2-30 2.4.4 Establishment Request Message.......................................................................... 2-30 2.5 SCCP ............................................................................................................................... 2-31 2.5.1 Overview ............................................................................................................... 2-31 2.5.2 Function................................................................................................................. 2-32 2.5.3 Message Structure ................................................................................................ 2-33 2.5.4 Connection Request Message .............................................................................. 2-34 Chapter 3 Cell Related Procedure Analysis ............................................................................... 3-1 3.1 Overview ............................................................................................................................ 3-1 3.2 Procedures Involved in Cell Setup..................................................................................... 3-1 3.2.1 Resource Status Indication ..................................................................................... 3-1 3.2.2 Resource Audit........................................................................................................ 3-2 3.2.3 Cell Setup................................................................................................................ 3-3 3.2.4 Common Transport Channel Setup ........................................................................ 3-4 3.2.5 Iub Interface User Plane Setup ............................................................................... 3-4 3.2.6 System Information Update..................................................................................... 3-5 3.2.7 Common Measurement Initiation ............................................................................ 3-5 3.2.8 Cell Reconfiguration................................................................................................ 3-6 3.2.9 Cell Deletion ............................................................................................................ 3-7 3.2.10 Resource Status Indication Message ................................................................... 3-7 3.2.11 Audit Response Message ................................................................................... 3-12 3.2.12 Cell Setup Request Message.............................................................................. 3-16 3.2.13 Common Transport Channel Setup Request Message ...................................... 3-20 3.2.14 System Information Update Request Message .................................................. 3-26 3.3 A Cell Setup Example...................................................................................................... 3-28 Chapter 4 System Information Procedure Analysis .................................................................. 4-1 4.1 Overview ............................................................................................................................ 4-1 4.1.1 System Information Structure.................................................................................. 4-1 4.1.2 System Information Monitoring Mechanism............................................................ 4-2 4.1.3 Functions of System Information............................................................................. 4-2
Huawei Technologies Proprietary ii
Table of Contents
4.2 System Information Broadcast and Update....................................................................... 4-3 4.2.1 System Information Broadcast ................................................................................ 4-3 4.2.2 System Information Update..................................................................................... 4-4 4.2.3 System Information Message.................................................................................. 4-4 4.3 System Information Modification Notification..................................................................... 4-7 4.3.1 Notification by a Value Tag ..................................................................................... 4-7 4.3.2 Notification by a Timer ............................................................................................ 4-8 4.3.3 Paging Type 1 Message ......................................................................................... 4-8 Chapter 5 Call Setup and Release Procedure Analysis ............................................................ 5-1 5.1 Overview ............................................................................................................................ 5-1 5.2 Paging................................................................................................................................ 5-1 5.2.1 Overview ................................................................................................................. 5-1 5.2.2 Paging for UE in Idle Mode or in PCH State ........................................................... 5-2 5.2.3 Paging for UE in CELL_DCH or CELL_FACH State............................................... 5-3 5.2.4 Paging Type 1 Message ......................................................................................... 5-3 5.2.5 Paging Type 2 Message ......................................................................................... 5-4 5.3 RRC Connection Setup ..................................................................................................... 5-5 5.3.1 Overview ................................................................................................................. 5-5 5.3.2 RRC Connection Setup on DCH ............................................................................. 5-6 5.3.3 RRC Connection Setup on CCH ............................................................................. 5-7 5.3.4 RRC Connection Reject .......................................................................................... 5-7 5.3.5 RRC Connection Request Message ....................................................................... 5-8 5.3.6 RRC Connection Setup Message ......................................................................... 5-11 5.3.7 RRC Connection Reject Message ........................................................................ 5-14 5.3.8 Radio Link Setup Request Message..................................................................... 5-14 5.4 Direct Transfer ................................................................................................................. 5-18 5.4.1 Overview ............................................................................................................... 5-18 5.4.2 Initial Direct Transfer ............................................................................................. 5-18 5.4.3 Uplink Direct Transfer ........................................................................................... 5-19 5.4.4 Downlink Direct Transfer....................................................................................... 5-20 5.4.5 Initial Direct Transfer Message ............................................................................. 5-21 5.4.6 Uplink Direct Transfer Message............................................................................ 5-23 5.4.7 Downlink Direct Transfer Message ....................................................................... 5-24 5.5 UE Capability Information Enquiry and Update ............................................................... 5-25 5.5.1 UE Capability Enquiry ........................................................................................... 5-26 5.5.2 UE Capability Information Update......................................................................... 5-26 5.6 RAB Setup ....................................................................................................................... 5-27 5.6.1 Overview ............................................................................................................... 5-27 5.6.2 DCH-DCH.............................................................................................................. 5-27 5.6.3 CCH-DCH.............................................................................................................. 5-31 5.6.4 CCH-CCH.............................................................................................................. 5-32 5.6.5 RAB Assignment Request Message ..................................................................... 5-33
Huawei Technologies Proprietary iii
Table of Contents
5.6.6 RAB Assignment Response Message .................................................................. 5-36 5.6.7 Radio Bearer Setup Message ............................................................................... 5-38 5.7 Call Release..................................................................................................................... 5-43 5.7.1 Overview ............................................................................................................... 5-43 5.7.2 Iu Signalling Connection Release ......................................................................... 5-43 5.7.3 RAB Release......................................................................................................... 5-45 5.7.4 Combined CS Domain Iu and RAB Release......................................................... 5-47 5.7.5 RRC Connection Release ..................................................................................... 5-49 Chapter 6 Mobility Management Procedure Analysis ............................................................... 6-1 6.1 Overview ............................................................................................................................ 6-1 6.2 Forward handover.............................................................................................................. 6-1 6.2.1 Overview ................................................................................................................. 6-1 6.2.2 Cell Update.............................................................................................................. 6-1 6.2.3 URA Update ............................................................................................................ 6-3 6.2.4 Cell Update Message.............................................................................................. 6-4 6.2.5 URA Update Message ............................................................................................ 6-7 6.3 Soft Handover .................................................................................................................... 6-8 6.3.1 Overview ................................................................................................................. 6-8 6.3.2 Radio Link Addition ................................................................................................. 6-9 6.3.3 Radio Link Deletion ............................................................................................... 6-10 6.3.4 Radio Link Addition and Deletion .......................................................................... 6-12 6.3.5 Radio Link Setup Request Message..................................................................... 6-13 6.3.6 Active Set Update Message.................................................................................. 6-13 6.4 Hard Handover................................................................................................................. 6-15 6.4.1 Overview ............................................................................................................... 6-15 6.4.2 Compressed Mode................................................................................................ 6-16 6.4.3 Iur Interface Hard Handover.................................................................................. 6-17 6.4.4 Combined Hard Handover .................................................................................... 6-19 6.4.5 Radio Link Setup Request Message..................................................................... 6-22 6.4.6 Physical Channel Reconfiguration Message ........................................................ 6-22 6.5 Inter-RAT Handover......................................................................................................... 6-24 6.5.1 Overview ............................................................................................................... 6-24 6.5.2 UMTS to GSM Handover ...................................................................................... 6-25 6.5.3 GSM to UMTS Handover ...................................................................................... 6-27 6.5.4 GSM/GPRS to UMTS Cell Reselection ................................................................ 6-29 6.5.5 UMTS to GSM/GPRS Cell Reselection ................................................................ 6-29 6.5.6 Handover from UTRAN Command Message........................................................ 6-32 6.5.7 Handover to UTRAN Command Message............................................................ 6-33 6.6 Relocation ........................................................................................................................ 6-35 6.6.1 Overview ............................................................................................................... 6-35 6.6.2 Static Relocation ................................................................................................... 6-36 6.6.3 Relocation with Hard Handover ............................................................................ 6-39
Huawei Technologies Proprietary iv
Table of Contents
6.6.4 Relocation with Forward Handover ....................................................................... 6-41 6.6.5 Relocation Required Message .............................................................................. 6-42 6.6.6 Relocation Request Message ............................................................................... 6-44 6.6.7 Relocation Command Message ............................................................................ 6-46 6.6.8 UTRAN Mobility Information Message.................................................................. 6-49 6.6.9 Uplink Signalling Transfer Indication Message ..................................................... 6-51 Chapter 7 Dynamic Resource Control Procedure Analysis...................................................... 7-1 7.1 Overview ............................................................................................................................ 7-1 7.2 RAB Modification ............................................................................................................... 7-1 7.2.1 Overview ................................................................................................................. 7-1 7.2.2 RAB Modification (DCH-DCH) ................................................................................ 7-1 7.2.3 RAB Assignment Request Message ....................................................................... 7-3 7.2.4 Radio Bearer Reconfiguration Message ................................................................. 7-3 7.3 Dynamic Channel Reconfiguration .................................................................................... 7-6 7.3.1 Overview ................................................................................................................. 7-6 7.3.2 Radio Bearer Reconfiguration................................................................................. 7-7 7.3.3 Radio Bearer Reconfiguration Message ................................................................. 7-8 Appendix A Tracing Tools............................................................................................................A-1 A.1 About Tracing Tools ..........................................................................................................A-1 A.1.1 RNC Tracing Tool ...................................................................................................A-1 A.1.2 NodeB Tracing Tool................................................................................................A-1 Appendix B A Typical Call Procedure .........................................................................................B-1 B.1 Overview............................................................................................................................B-1 B.2 Calling Procedure ..............................................................................................................B-1 B.3 Called procedure ...............................................................................................................B-4 Appendix C Acronyms and Abbreviations .................................................................................C-1 Index ................................................................................................................................................ i-1
Huawei Technologies Proprietary v
Chapter 1 UTRAN Interface Protocols and Functions

1.1 Overview
Figure 1-1 UTRAN interfaces As shown in Figure 1-1, UTRAN interfaces in the UMTS system include Iub, Iur, Iu and Uu interfaces. See Table 1-1 for the description of the interfaces. Table 1-1 UTRAN interfaces Interface Uu Iub Iur Iu Description Logical interface between UTRAN and UE Logical interface between RNC and NodeB Logical interface between RNCs Logical interface between RNC and CN
Huawei Technologies Proprietary 1-1
Iub, Iur, Iu and Uu interfaces are standard interfaces and can be used to connect different network elements (NEs) from different providers. Iub, Iur and Iu interfaces are also called UTRAN terrestrial interfaces. According to the type of CN entity connected to RNC, the Iu interface can be classified as Iu-CS interface, Iu-PS interface and Iu-BC interface. The Iu-CS interface is used to connect RNC and MSC. The Iu-PS interface is used to connect RNC and SGSN. The Iu-BC interface is used to connect RNC and CBC.
1.2 Uu Interface
1.2.1 Uu Protocol Structure
Uu interface is the interface between User Equipment (UE) and UMTS Terrestrial Radio Access Network (UTRAN) and it is the most important interface in the UMTS system. As shown in Figure 1-2, the Uu interface includes three protocol layers, physical layer (L1), data link layer (L2) and network layer (L3). L1 provides the radio physical channels for the transmission of the traffic from upper layers. The functions of L1 are implemented by NodeB. L2 includes four sublayers, Medium Access Control (MAC), Radio Link Control (RLC), Broadcast/Multicast Control (BMC) and Packet Data Convergence Protocol (PDCP). The functions of L2 are implemented by RNC. L3 includes the Radio Resource Control (RRC) sublayer in the access stratum, the Mobility Management (MM) and Call Control (CC) in the non-access stratum (NAS). The RRC functions of L3 are implemented by RNC, and the MM and CC functions of L3 are implemented by CN.

DC
GC
Nt
Duplication avoidance GC C-plane signalling Nt DC UuS boundary U-plane information
RRC co ntr co ntr co co ntr ntr
control
L3
Radio Bearers PDCP PDCP
L2/PDCP
BMC
L2/BMC
RLC RLC
RLC
RLC RLC RLC RLC
RLC
L2/RLC
Logical Channels MAC
L2/MAC
Transport Channels
PHY
L1
Figure 1-2 Uu interface protocol stack The technical specifications of Uu interface are shown in Figure 1-3.
GC
Nt
DC
Duplication avoidance GC C-plane signalling Nt DC U-plane information control TS25.331 TS25.323 UuS boundary
L3 L2/PDCP L2/BMC
control
control
control
control
TS25.324
RLC RLC
RLC
RLC RLC TS25.322 RLC
RLC
L2/RLC
Logical Channels TS25.321
L2/MAC
Transport Channels
TS25.211~TS25.215
L1
Figure 1-3 Uu interface technical specifications
1.2.2 RRC Functions

The RRC performs the functions listed below: Broadcast of information related to the non-access stratum (Core Network) Broadcast of information related to the access stratum Establishment, maintenance and release of an RRC connection between the UE and UTRAN Establishment, reconfiguration and release of Radio Bearers Assignment, reconfiguration and release of radio resources for the RRC connection RRC connection mobility functions Route selection for the Protocol Data Unit (PDU) of upper layers Control of requested QoS UE measurement reporting and control of the reporting Outer loop power control Control of ciphering Paging
Initial cell selection and cell re-selection Arbitration of radio resources on uplink DCH RRC message integrity protection CBS control
1.2.3 L2 Functions
L2 includes four sublayers, Medium Access Control (MAC), Radio Link Control (RLC), Broadcast/Multicast Control (BMC) and Packet Data Convergence Protocol (PDCP).
I. MAC
The functions of MAC include: Mapping between logical channels and transport channels Selection of appropriate transport format for each transport channel Priority handling between data flows of one UE Priority handling between UEs by means of dynamic scheduling Priority handling between data flows of several UEs on FACH Identification of UEs on common transport channels Multiplexing/demultiplexing of upper layer PDUs into/from transport blocks delivered to/from the physical layer on common transport channels Traffic volume measurement Transport channel type switching Ciphering for transparent mode RLC Access Service Class selection
II. RLC
The functions of RLC include: Segmentation, reassembly, concatenation, padding and transfer of user data Flow control Error correction, in-sequence delivery of upper layer PDUs and duplicate detection Sequence numbers check Protocol error detection and recovery Ciphering Suspend/resume function
III. PDCP
The functions of PDCP include: Header compression and decompression of IP data streams at the transmit and receive entities respectively
Transfer of user data Forwarding of PDCP-SDUs from NAS to RLC, and multiplexing of different RBs to the same RLC entity
IV. BMC
The functions of BMC include: Storage of cell broadcast messages Traffic volume monitoring and radio resource request for CBS Scheduling of BMC messages Transmission of BMC messages to UE Delivery of cell broadcast messages to upper layer (NAS)
1.2.4 L1 Functions
The functions of L1 (physical layer) mainly includes: Provision for higher layers with measurements and indications (such as FER, SIR, interference power, and transmission power) Macro-diversity distribution/combination and soft handover execution Frequency and time (chip, bit, slot, frame) synchronization Closed-loop power control RF processing Multiplexing of transport channels and demultiplexing of coded composite transport channels Mapping of coded composite transport channels onto physical channels Modulation/demodulation and spreading/despreading of physical channels The detailed functions and relevant specifications of L1 are involved with the basic principles of WCMDA. They are out of the range of this manual. Refer to relevant protocols and documents for details.
1.3 Iub Interface

1.3.1 Iub Protocol Structure
Iub interface is the interface between RNC and NodeB. The protocol stack of Iub interface is illustrated in Figure 1-4.
Radio Network Layer
Radio Network Control Plane Node B Application Part (NBAP) Transport Network Control Plane ALCAP Q.2630.1 Q.2150.2 SSCF-UNI SSCOP AAL Type 5 SSCF-UNI SSCOP AAL Type 5 ATM Physical Layer
User Plane FACH FP RACH FP DCH FP PCH FP
Transport Layer
AAL Type 2
Figure 1-4 Iub interface protocol stack The technical specifications of Iub interface are shown in Figure 1-5.
Radio Network Layer
Radio Network Control Plane

NBAP
User Plane
Dedicated Channels Common Channels
TS 25.433 Transport Network Control Plane

Transport Signaling
TS 25.427
TS 25.435
Transport Layer
NBAP Transport
TS 25.426
(Dedicated Channel Transport) Dedicated Channel Transport Common Channel Transport
TS 25.432
(Common Channel Transport)
TS 25.434
TS 25.426
TS 25.434
TS 25.431 Physical Layer
Figure 1-5 Iub interface technical specifications
1.3.2 NBAP Functions

NodeB Application Part (NBAP) is the signalling protocol of the control plane of the radio network layer on the Iub interface, which provides the following functions:
Cell Configuration Management This function gives the controlling RNC (CRNC) the possibility to manage the cell configuration information in a NodeB. Common Transport Channel Management This function gives the CRNC the possibility to manage the configuration of common transport channels in a NodeB. System Information Management This function gives the CRNC the ability to manage the scheduling of System Information to be broadcast in a cell. Resource Event Management This function gives the NodeB the ability to inform the CRNC about the status of NodeB resources. Configuration Alignment This function gives the CRNC and the NodeB the possibility to verify and enforce that both nodes have the same information on the configuration of the radio resources. Measurements on Common Resources This function allows the NodeB to initiate measurements in the NodeB. The function also allows the NodeB to report the result of the measurements. Radio Link Management This function allows the CRNC to manage radio links using dedicated resources in a NodeB. Radio Link Supervision This function allows the CRNC to report failures and restorations of a radio link. Compressed Mode Control This function allows the CRNC to control the usage of compressed mode in a NodeB. Measurements on Dedicated Resources This function allows the CRNC to initiate measurements in the NodeB. The function also allows the NodeB to report the result of the measurements. DL Power Drifting Correction This function allows the CRNC to adjust the DL power level of one or more radio links in order to avoid DL power drifting between radio links. Reporting of General Error Situations This function allows reporting of general error situations.
1.3.3 NBAP Procedures

NBAP procedures are divided into common procedures and dedicated procedures. NBAP common procedures are procedures that request initiation of a UE context for a specific UE in NodeB or are not related to a specific UE. NBAP common procedures also incorporate logical O&M procedures. NBAP dedicated procedures are procedures that are related to a specific UE context in NodeB. This UE context is identified by a UE context identity. The two types of procedures may be carried on separate signalling links.
I. NBAP Common Procedures

The NBAP functions and corresponding NBAP elementary procedures (EPs) are shown in the Table 1-2. Table 1-2 NBAP functions and corresponding elementary procedures Function Cell Configuration Management Elementary procedure Cell Setup Cell Reconfiguration Cell Deletion Common Transport Channel Setup Common Transport Channel Reconfiguration Common Transport Channel Deletion System Information Update Block Resource Unblock Resource Resource Status Indication Audit Required Audit Reset Measurements on Common Resources Common Measurement Initiation Common Measurement Reporting Common Measurement Termination Common Measurement Failure Radio Link Setup
Common Transport Channel Management
System Information Management Resource Event Management
Configuration Alignment
Radio Link Management.
II. NBAP Dedicated Procedures

The NBAP functions and corresponding NBAP dedicated procedures are shown in Table 1-3.
Table 1-3 NBAP functions and corresponding dedicated procedures Function Radio Link Management. Dedicated procedure Radio Link Addition Radio Link Deletion Unsynchronized Radio Link Reconfiguration Synchronized Radio Link Reconfiguration Preparation Synchronized Radio Link Reconfiguration Commit Synchronized Radio Link Reconfiguration Cancellation Radio Link Pre-emption Radio Link Supervision. Compressed Mode Control Radio Link Failure Radio Link Restoration Radio Link Setup Radio Link Addition Compressed Mode Command Unsynchronized Radio Link Reconfiguration Synchronized Radio Link Reconfiguration Preparation Synchronized Radio Link Reconfiguration Commit Synchronized Radio Link Reconfiguration Cancellation Dedicated Measurement Initiation Dedicated Measurement Reporting Dedicated Measurement Termination Dedicated Measurement Failure Downlink Power Control Error Indication
Measurements on Dedicated Resources
DL Power Drifting Correction Reporting of General Error Situations
1.3.4 Iub FP for Common Transport Channel Data Transfer

Iub frame protocol (FP) for common transport channel data transfer is the protocol of the user plane of the radio network layer on the Iub interface, which provides the following services: Transport of Transport Block Set (TBS) between the NodeB and the CRNC for common transport channels (including RACH, FACH, and PCH) Support of transport channel synchronization mechanism Support of Node Synchronization mechanism
I. RACH Data Transfer

RACH Data Transfer procedure is to transfer RACH Data Frame from NodeB to CRNC, as shown in Figure 1-6.
NodeB
RACH Data Frame
CRNC
Figure 1-6 RACH data transfer procedure
II. FACH Data Transfer

FACH Data Transfer procedure is to transfer FACH Data Frame from CRNC to NodeB, as shown in Figure 1-7.
NodeB
FACH Data Frame
CRNC
Figure 1-7 FACH data transfer procedure
III. PCH Data Transfer

PCH Data Transfer procedure is to transfer PCH Data Frame from CRNC to NodeB, as shown in Figure 1-8.
NodeB
PCH Data Frame
CRNC
Figure 1-8 PCH data transfer procedure
IV. Node Synchronization

Node synchronization is to obtain the round trip delay (RTD) of transmission over the Iub interface. In the Node Synchronization procedure, the RNC sends a DL Node Synchronization control frame to the NodeB containing the parameter T1. Upon reception of the frame, the NodeB shall respond with a UL Node Synchronization control frame, indicating T2 and T3, as well as T1 that was indicated in the initiating DL Node Synchronization control frame, as shown in Figure 1-9.
NodeB CRNC
DL Node Synchronization UL Node Synchronization
Figure 1-9 Node synchronisation procedure
Parameters T1, T2, and T3 are defined as follows: T1: RNC specific frame number (RFN) that indicates the time when the RNC sends the DL Node Synchronization control frame through the service access point (SAP) to the transport network layer. T2: NodeB specific frame number (BFN) that indicates the time when the NodeB receives the correspondent DL Node Synchronization control frame through the SAP from the transport network layer. T3: NodeB specific frame number (BFN) that indicates the time when the NodeB sends the UL Node Synchronization control frame through the SAP to the transport network layer.
V. DL Transport Channels Synchronization

DL transport channel synchronization procedure is used to synchronize the transport channel after the transport channel has been set up or used to maintain the synchronization of the transport channel when there is no DL data frame. In the DL transport channel synchronization procedure, the CRNC sends a DL Synchronization control frame to the NodeB. This message indicates the target Connection Frame Number (CFN). Upon reception of the frame, the NodeB shall immediately respond with a UL Synchronization control frame indicating the Time of Arrival (ToA) for the DL Synchronization frame and the CFN indicated in the received message, as shown in Figure 1-10.
NodeB
DL Synchronization UL Synchronization
CRNC
Figure 1-10 FACH and PCH transport channels synchronization procedure
VI. DL Timing Adjustment

Timing Adjustment procedure is used for a NodeB to indicate the CRNC the incorrect ToA of downlink data to the NodeB. Timing adjustment procedure is initiated by the NodeB if a DL frame arrives outside of the defined arrival window. If the DL frame has arrived before the ToAWS or after the ToAWE, the NodeB will include the ToA and the target CFN in the Timing Adjustment control frame, as shown in Figure 1-11.
NodeB
Timing Adjustment
CRNC
.
Figure 1-11 FACH and PCH Timing Adjustment procedure
The arrival window and the ToA are defined as follows:

Time of Arrival Window Endpoint (ToAWE): ToAWE represents the time point
by which the DL data shall arrive at the NodeB from Iub. ToAWE is defined as the amount of milliseconds before the last time point from which a timely DL transmission for the identified CFN would still be possible taking into account the NodeB internal delays. ToAWE is set via control plane. If data does not arrive before ToAWE, a Timing Adjustment control frame shall be sent by NodeB.
Time of Arrival Window Startpoint (ToAWS): ToAWS represents the time after
which the DL data shall arrive at the NodeB from Iub. ToAWS is defined as the amount of milliseconds from ToAWE. ToAWS is set via control plane. If data arrives before ToAWS, a Timing Adjustment control frame shall be sent by NodeB.
Time of Arrival (ToA): ToA is the time difference between the end point of the DL
arrival window (ToAWE) and the actual arrival time of DL frame for a specific CFN. A positive ToA means that the frame is received before ToAWE. A negative ToA means that the frame is received after ToAWE.
1.3.5 Iub FP for Dedicated Transport Channel Data Transfer

Iub FP for dedicated transport channel data transfer is the radio network user plane of Iub interface which provides the following services: Transport of TBS between Serving RNC (SRNC) and NodeB Transport of outer loop power control information between SRNC and NodeB Support of transport channel synchronization mechanism Support of Node Synchronization mechanism Transfer of radio interface parameters from SRNC to NodeB
I. Uplink Data Transfer
NodeB
UL Data Frame
SRNC
Figure 1-12 Uplink data transfer procedure
Uplink Data Transfer procedure is to transfer UL Data Frame from NodeB to SRNC, as shown in Figure 1-12. Two modes can be used for the UL transmission: normal mode and silent mode. The SRNC selects the mode when setting up the transport bearer and notifies the NodeB with the relevant control plane procedure. In normal mode, the NodeB shall always send an UL Data Frame to the RNC for all the DCHs in a set of coordinated DCHs regardless of the number of Transport Blocks of the DCHs. In silent mode and in case only one transport channel is transported on a transport bearer, the NodeB shall not send an UL Data Frame to the RNC when it has received a TFI indicating number of TB equal to 0 for the transport channel during a TTI. In silent mode and in case of coordinated DCHs, when the NodeB receives a TFI indicating number of TB equal to 0 for all the DCHs in a set of coordinated DCHs, the NodeB shall not send an UL data frame to the RNC for this set of coordinated DCHs.
II. Downlink Data Transfer
NodeB
DL Data Frame
SRNC
Figure 1-13 Downlink data transfer procedure
Downlink Data Transfer procedure is to transfer DL Data Frame from SRNC to NodeB, as shown in Figure 1-13. The NodeB shall consider a transport bearer synchronized only after it has received at least one data frame on this transport bearer before the latest time of arrival (LTOA). The NodeB shall consider the DL user plane for a certain RL synchronized if all transport bearers established for carrying DL DCH data frames for this RL are synchronized. Only when the DL user plane is considered synchronized, the NodeB shall transmit the data on the DL DPDCH. When the DL user plane is considered synchronized and the NodeB does not receive a valid DL Data Frame in a TTI, it assumes that there is no data to be transmitted in that TTI for this transport channel, and shall act as one of the following cases: If the NodeB is aware of a TFI value corresponding to zero bits for this transport channel, this TFI is assumed. When combining the TFIs of the different transport channels, a valid TFCI might result and in this case data shall be transmitted on Uu. If the NodeB is not aware of a TFI value corresponding to zero bits for this transport channel or if combining the TFI corresponding to zero bits with other TFIs, results in an unknown TFI combination, the handling will be different. In the former case, at each radio frame, the NodeB shall build the TFCI value of each CCTrCH, according to the TFI of the DCH data frames multiplexed on this CCTrCH. In the latter case, the NodeB shall transmit only the DPCCH without TFCI bits.
III. Outer Loop Power Control Information Transfer

Outer loop power control information transfer procedure is to transfer Outer Loop PC control frame from SRNC to NodeB, as shown in Figure 1-14. The Outer Loop PC control frame can be sent via any of the transport bearers dedicated to one UE.
Based, for example, on the CRC Indicator (CRCI) values and on the quality estimate in the UL frames, the SRNC modifies the SIR target used by the UL Inner Loop Power Control by including the absolute value of the new SIR target in the Outer Loop PC control frame sent to the NodeB's. Upon reception of the Outer Loop PC control frame, the NodeB shall immediately update the SIR target used for the inner loop power control with the specified value.
NodeB
Outer Loop PC
SRNC
Figure 1-14 Outer loop power control information transfer procedure
IV. Radio Interface Parameter Update

Radio interface parameter update procedure is used to update radio interface parameters which are applicable to all RLs for the concerning UE. Both synchronized and unsynchronized parameter updates are also supported. The procedure is realized by a transmission of Radio Interface Parameter Update control frame from SRNC to the NodeB, as shown in Figure 1-15.
NodeB
SRNC
Radio Interface Parameter Update
Figure 1-15 Radio interface parameter update procedure
V. Node Synchronization
Node synchronization procedure is to obtain the round trip delay (RTD) of transmission over the Iub interface. In the Node Synchronization procedure, the SRNC sends a DL Node Synchronization control frame to the NodeB containing the parameter T1. Upon reception of the frame, the NodeB shall respond with a UL Node Synchronization control frame, indicating T2
and T3, as well as T1 that was indicated in the initiating DL Node Synchronization control frame, as shown in Figure 1-16.
NodeB SRNC
DL Node Synchronization UL Node Synchronization
Figure 1-16 Node synchronization procedure
Parameters T1, T2, and T3 are defined as: T1: RNC specific frame number (RFN) that indicates the time when RNC sends the DL Node Synchronization control frame through the SAP to the transport network layer. T2: NodeB specific frame number (BFN) that indicates the time when the NodeB receives the correspondent DL Node Synchronization control frame through the SAP from the transport network layer. T3: NodeB specific frame number (BFN) that indicates the time when the NodeB sends the UL Node Synchronization control frame through the SAP to the transport network layer.
VI. DL Transport Channel Sychronization

DL transport channel synchronization procedure is used to achieve or restore the synchronization of the DCH data stream in DL direction, and as a keep-alive procedure in order to maintain activity on the Iur/Iub transport bearer. In the DL transport channel synchronization procedure, the CRNC sends a DL Synchronization control frame to the NodeB. This message indicates the target Connection Frame Number (CFN). Upon reception of the frame, the NodeB shall immediately respond with a UL Synchronization control frame indicating the Time of Arrival (ToA) for the DL Synchronization frame and the CFN indicated in the received message, as shown in Figure 1-17. The UL Synchronization control frame shall always be sent, even if the DL Synchronization control frame is received by the NodeB within the arrival window.
NodeB
DL Synchronization UL Synchronization
SRNC
Figure 1-17 DCH synchronization procedure
VII. DL Timing Adjustment

Timing adjustment procedure is used to keep the synchronization of the DCH data stream in DL direction. The timing adjustment procedure is initiated by the NodeB if a DL frame arrives outside of the defined arrival window. If the DL frame has arrived before the ToAWS or after the ToAWE, NodeB will include the ToA and the target CFN in the Timing Adjustment control frame, as shown in Figure 1-18.
NodeB
Timing Adjustment
SRNC
Figure 1-18 Timing adjustment procedure
1.4 Iur Interface

1.4.1 Iur Protocol Structure
Iur interface is the interface between RNCs. The protocol stack of Iur interface is illustrated in Figure 1-19.
Radio Network Layer
Control Plane RNSAP Transport Network Control Plane ALCAP(Q.2630.1) STC (Q.2150.1) MTP3-B SSCF-NNI SSCOP AAL5 ATM Physical Layer
User Plane Iur Data Stream(s) Transport Network User Plane
Transport Network User Plane Transport Network Layer
SCCP MTP3-B SSCF-NNI SSCOP AAL5
AAL2
Figure 1-19 Iur interface protocol stack
The technical specifications of the Iur interface are shown in Figure 1-20.
User Plane
Dedicated Channels Common Channels
Radio Network Layer
Radio Network Control Plane

RNSAP
TS 25.423 Transport Network Control Plane
TS 25.427
TS 25.425
Transport Signaling
Transport Layer
Signalling Transport
TS 25.426
(Dedicated Channel Transport) Dedicated Channel Transport Common Channel Transport
TS 25.424
(Common Channel Transport) Physical LayerTS 25.421
TS 25.422
TS 25.426
TS 25.424
Figure 1-20 Iur interface technical specifications
1.4.2 RNSAP Functions

Radio Network Subsystem Application Part (RNSAP) is the signalling protocol of the control plane of the radio network layer on Iur interface, which provides the following functions:
Radio Link Management This function allows the Serving RNC (SRNC) to manage radio links using dedicated resources in a Drift RNS (DRNS). Physical Channel Reconfiguration This function allows the Drift RNC (DRNC) to reallocate the physical channel resources for a radio link. Radio Link Supervision This function allows the DRNC to report failures and restorations of a radio link. Compressed Mode Control This function allows the SRNC to control the usage of compressed mode within a DRNS. Measurements on Dedicated Resources This function allows the SRNC to initiate measurements on dedicated resources in the DRNS. The function also allows the DRNC to report the result of the measurements. DL Power Drifting Correction This function allows the SRNC to adjust the DL power level of one or more Radio Links in order to avoid DL power drifting between the radio links. CCCH Signalling Transfer This function allows the SRNC and DRNC to pass information between the UE and the SRNC on a CCCH controlled by the DRNS. Paging This function allows the SRNC to page a UE in a URA or a cell in the DRNS. Relocation Execution This function allows the SRNC to finalize a relocation previously prepared via other interfaces. Reporting of General Error Situations This function allows reporting of general error situations, for which function specific error messages have not been defined.
1.4.3 RNSAP Procedures

RNSAP procedures can be classified into class 1 and class2. The procedures of class 1 have response messages including successful or unsuccessful outcome, as shown in Table 1-4. The procedures of class 2 have no response message. The message is always assumed successful, as shown in Table 1-5.
Table 1-4 RNSAP class 1 elementary procedures Elementary procedure Initiating message Response message Successful outcome Unsuccessful outcome
Radio Link Setup Radio Link Addition Radio Link Deletion Synchronised Radio Link Reconfiguratio n Preparation Unsynchronise d Radio Link Reconfiguratio n Physical Channel Reconfiguratio n Dedicated Measurement Initiation Common Transport Channel Resources Initialisation
RADIO LINK SETUP REQUEST RADIO LINK ADDITION REQUEST RADIO LINK DELETION REQUEST RADIO LINK RECONFIGURATIO N PREPARE RADIO LINK RECONFIGURATIO N REQUEST PHYSICAL CHANNEL RECONFIGURATIO N REQUEST DEDICATED MEASUREMENT INITIATION REQUEST COMMON TRANSPORT CHANNEL RESOURCES REQUEST
RADIO LINK SETUP RESPONSE RADIO LINK ADDITION RESPONSE RADIO LINK DELETION RESPONSE RADIO LINK RECONFIGURATIO N READY RADIO LINK RECONFIGURATIO N RESPONSE PHYSICAL CHANNEL RECONFIGURATIO N COMMAND DEDICATED MEASUREMENT INITIATION RESPONSE COMMON TRANSPORT CHANNEL RESOURCES RESPONSE
RADIO LINK SETUP FAILURE RADIO LINK ADDITION FAILURE
RADIO LINK RECONFIGURATIO N FAILURE RADIO LINK RECONFIGURATIO N FAILURE PHYSICAL CHANNEL RECONFIGURATIO N FAILURE DEDICATED MEASUREMENT INITIATION FAILURE COMMON TRANSPORT CHANNEL RESOURCES FAILURE
Table 1-5 RNSAP class 2 elementary procedures Elementary procedure Initiating message
Uplink Signalling Transfer Downlink Signalling Transfer Relocation Commit Paging
UPLINK SIGNALLING TRANSFER INDICATION DOWNLINK SIGNALLING TRANSFER REQUEST RELOCATION COMMIT PAGING REQUEST
Elementary procedure
Initiating message
Synchronised Radio Link Reconfiguration Commit Synchronised Radio Link Reconfiguration Cancellation Radio Link Failure Radio Link Restoration Dedicated Measurement Reporting Dedicated Measurement Termination Dedicated Measurement Failure Downlink Power Control Compressed Mode Command Common Transport Channel Resources Release Error Indication Radio Link Pre-emption
RADIO LINK RECONFIGURATION COMMIT RADIO LINK RECONFIGURATION CANCEL RADIO LINK FAILURE INDICATION RADIO LINK RESTORE INDICATION DEDICATED MEASUREMENT REPORT DEDICATED MEASUREMENT TERMINATION REQUEST DEDICATED MEASUREMENT FAILURE INDICATION DL POWER CONTROL REQUEST COMPRESSED MODE COMMAND COMMON TRANSPORT CHANNEL RESOURCES RELEASE REQUEST ERROR INDICATION RADIO LINK PREEMPTION REQUIRED INDICATION
1.4.4 Iur FP for Transport Channel Data Transfer

Iur frame protocol (FP) is the protocol of the user plane of the radio network layer on the Iur interface. It includes Iur FP for common transport channel data transfer and Iur FP for dedicated transport channel data transfer. Iur FP for common transport channel data transfer and Iub FP for common transport channel data transfer are both specified in 3GPP TS25.425 protocol. For details, refer to section 1.3.4 Iub FP for Common Transport Channel Data Transfer. Iur FP for dedicated transport channel data transfer and Iub FP for dedicated transport channel data transfer are both specified in 3GPP TS25.427 protocol. For details, refer to section 1.3.5 Iub FP for Dedicated Transport Channel Data Transfer.
1.5 Iu Interface
1.5.1 Iu Protocol Structure
Iu interface is the interface between UTRAN and CN. The Iu interface between UTRAN and CS domain of CN is called Iu-CS. The protocol stack is shown in Figure 1-21. The Iu interface between UTRAN and PS domain of CN is called Iu-PS. The protocol stack is shown in Figure 1-22. The Iu interface between UTRAN and BC domain of CN is called Iu-BC. The protocol stack is shown in Figure 1-23.
Radio Network Layer
Control Plane RANAP Transport Network Control Plane Q.2630.1 Q.2150.1 MTP3-B SSCF-NNI SSCOP AAL5 ATM Physical Layer
User Plane Iu UP Protocol Layer Transport Network User Plane
SCCP MTP3-B SSCF-NNI SSCOP AAL5
AAL2
Figure 1-21 Iu-CS interface protocol stack
Radio Network Layer
Control Plane RANAP Transport Network Control Plane
User Plane Iu UP Protocol Layer Transport Network User Plane
SCCP MTP3-B SSCF-NNI SSCOP AAL5 ATM Physical Layer GTP-U UDP IP AAL5 ATM Physical Layer
Figure 1-22 Iu-PS interface protocol stack
Radio Network Layer
SA Broadcast Plane SABP Protocol Layer
Transport Network Layer
Transport Network User Plane
TCP IP AAL5
ATM Physical Layer
Figure 1-23 Iu-BC interface protocol stack
The technical specifications of Iu interface are shown in Figure 1-24.

Radio Network Layer Control Plane User Plane 25.415 SA Broadcast Plane 25.419
25.413
Transport Network Layer
Transport Network Control Plane
25.412
25.414
25.411
Figure 1-24 Iu interface technical specifications
1.5.2 RANAP Functions

Radio Access Network Application Part (RANAP) is the signalling protocol of the control plane of the radio network layer on the Iu interface, which provides the following functions: Relocating SRNC This function enables to change the SRNC functionality as well as the related Iu resources (RAB(s) and Signalling connection) from one RNC to another. Overall RAB management This function is responsible for setting up, modifying and releasing RABs. Queuing the setup of RAB The purpose of this function is to allow placing some requested RABs into a queue, and indicate the peer entity about the queuing. Requesting RAB release While the overall RAB management is a function of the CN, the RNC has the capability to request the release of RAB. Release of all Iu connection resources
This function is used to explicitly release all resources related to one Iu connection. Requesting the release of all Iu connection resources While the Iu release is managed from the CN, the RNC has the capability to request the release of all Iu connection resources from the corresponding Iu connection. SRNS context forwarding function This function is responsible for transferring SRNS context from the RNC to the CN for intersystem forward handover in case of packet forwarding. Controlling overload in the Iu interface This function allows adjusting the load in the Iu interface. Resetting the Iu This function is used for resetting an Iu interface. Sending the UE Common ID (permanent NAS UE identity) to the RNC This function makes the RNC aware of the UE's Common ID. Paging the user This function provides the CN for capability to page the UE. Controlling the tracing of the UE activity This function allows setting the trace mode for a given UE. This function also allows the deactivation of a previously established trace. Transport of NAS information between UE and CN This function has two sub-classes: Sub-class1: Transport of the initial NAS signalling message from the UE to CN. This function transfers transparently the NAS information. After transmission, the Iu signalling connection is set up. Sub-class2: Transport of NAS signalling messages between UE and CN, This function transfers transparently the NAS signalling messages on the existing Iu signalling connection. It also includes a specific service to handle signalling messages differently. Controlling the security mode in the UTRAN This function is used to send the security keys (ciphering and integrity protection) to the UTRAN, and setting the operation mode for security functions. Controlling location reporting This function allows the CN to operate the mode in which the UTRAN reports the location of the UE. Location reporting
This function is used for transferring the actual location information from RNC to the CN. Data volume reporting function This function is responsible for reporting unsuccessfully transmitted DL data volume over UTRAN for specific RABs. Reporting general error situations
1.5.3 RANAP Procedures

RANAP procedures can be classified as class 1, class 2 and class 3. The procedures of class 1 have response messages including successful or unsuccessful outcome, as shown in Table 1-6. The procedures of class 2 have no response message. The message is always considered successful, as shown in Table 1-7. The procedures of class 3 may have one or several response messages reporting both successful and unsuccessful outcomes of the requests as well as temporary status information about the requests, as shown in Table 1-8. This type of procedures only terminates through response(s) or EP timer expiry.
Table 1-6 NANAP class 1 elementary procedures Elementary procedure Initiating message Response message Successful outcome Unsuccessful outcome
Iu Release Relocation Preparation Relocation Resource Allocation Relocation Cancel SRNS Context Transfer Security Mode Control
IU RELEASE COMMAND RELOCATION REQUIRED RELOCATION REQUEST RELOCATION CANCEL SRNS CONTEXT REQUEST SECURITY MODE COMMAND
IU RELEASE COMPLETE RELOCATION COMMAND RELOCATION REQUEST ACKNOWLEDGE RELOCATION CANCEL ACKNOWLEDGE SRNS CONTEXT RESPONSE SECURITY MODE COMPLETE SECURITY MODE REJECT RELOCATION PREPARATION FAILURE RELOCATION FAILURE
Elementary procedure
Initiating message
Response message Successful outcome Unsuccessful outcome
Data Volume Report
DATA VOLUME REPORT REQUEST RESET RESET RESOURCE
DATA VOLUME REPORT
Reset Reset Resource
RESET ACKNOWLEDGE RESET RESOURCE ACKNOWLEDGE
Table 1-7 NANAP class 2 elementary procedures Elementary procedure Message
RAB Release Request Iu Release Request Relocation Detect Relocation Complete SRNS Data Forwarding Initiation SRNS Context Forwarding from Source RNC to CN SRNS Context Forwarding to Target RNC from CN Paging Common ID CN Invoke Trace CN Deactivate Trace Location Reporting Control Location Report Initial UE Message Direct Transfer Overload Control Error Indication
RAB RELEASE REQUEST IU RELEASE REQUEST RELOCATION DETECT RELOCATION COMPLETE SRNS DATA FORWARD COMMAND FORWARD SRNS CONTEXT FORWARD SRNS CONTEXT PAGING COMMON ID CN INVOKE TRACE CN DEACTIVATE TRACE LOCATION REPORTING CONTROL LOCATION REPORT INITIAL UE MESSAGE DIRECT TRANSFER OVERLOAD ERROR INDICATION
Table 1-8 NANAP class 3 elementary procedures Elementary procedure Initiating message Response message
RAB Assignment
RAB ASSIGNMENT REQUEST
RAB ASSIGNMENT RESPONSE x N (N>=1)
1.5.4 Iu UP Functions
Iu UP is located in the user plane of the radio network layer on the Iu interface and used to convey user data associated to Radio Access Bearers (RABs). One Iu UP protocol instance is associated to one RAB only. Iu UP protocol instances exist at Iu access point i.e. at CN and UTRAN. Whenever a RAB requires transfer of user data in the Iu UP, an Iu UP protocol instance exists at each Iu interface access points. These Iu UP protocol instances are established, relocated and released together with the associated RAB procedures. The Iu UP includes two modes of operation: Transparent Mode (TrM) and Support Mode for predefined SDU size (SMpSDU). Transparent mode (TrM) The transparent mode is intended for those RABs that do not require any particular feature from the Iu UP protocol other than transfer of user data. Figure 1-25 illustrates the transparent mode of Iu UP protocol layer.
UTRAN Iu RNL-SAP CN Non Access Stratum Access Stratum Radio Interface Protocols
Iu UP layer (transparent mode)
Iu UP layer (transparent mode)
TNL-SAP
TNL-SAP
Figure 1-25 Transparent mode of Iu UP
In this mode, the Iu UP protocol instance does not perform any Iu UP protocol information exchange with its peer over the Iu interface. The Iu UP protocol layer is used for PDUs transfer between upper layers and transport network layer. For instance, Iu UP of Iu-PS adopts transparent mode. Support mode
The support modes are intended for those RABs that require particular features from the Iu UP protocol in addition to transfer of user data. When operating in a support mode, the peer Iu UP protocol instances exchange Iu UP frames. Figure 1-26 illustrates the support mode of Iu UP protocol layer.
Iu RNL-SAP CN Non Access Stratum Access Stratum Iu UP layer (support mode) Radio Interface Protocols Support Mode Functions Transfer of Iu UP protocol frames Iu UP layer (support mode) Support Mode Functions
UTRAN
TNL-SAP
TNL-SAP
Figure 1-26 Support mode of Iu UP
The only support mode which has been defined is the support mode for predefined SDU size (SMpSDU). For instance, the transfer of AMR speech PDUs would utilize SMpSDU.
I. User Data Transfer

User data transfer procedure is to transfer Iu UP frames between the two Iu UP protocol layers on the Iu interface. Since an Iu UP instance is associated to an RAB and an RAB only, the user data being transferred only relate to the associated RAB. As shown in Figure 1-27, the transfer of user data procedure is invoked whenever user data for that particular RAB needs to be sent across the Iu interface. In SRNC, the upper layers may deliver frame quality classification information together with the RFCI.
RNC/ CN Transfer of User Data

(RFCI, payload)
CN/ RNC
Figure 1-27 Transfers of user data
II. Initialization Procedure

Initialization procedure is to configure both termination points of the Iu UP with the RFCIs and associated RAB Sub Flows SDU sizes necessary during the transfer of user data phase. This procedure is mandatory for RABs using the support mode for predefined SDU size. The RNC sends initialization frame to the CN, indicating the RFCIs and their corresponding RAB sub-flow SDU size, as shown in Figure 1-28. If the CN receives the initialization frame and accepts the parameters, it will respond with an Initialization ACK frame. Otherwise, it will respond with an Initialization NACK frame.
RNC
*
Initialisation ((RFCI, SDU sizes ) Initialisation ACK Transfer Of User Data m

)
CN/other
* it can repeated n times
Figure 1-28 Initialization of Iu UP for m RFCIs
III. Iu Rate Control

Iu rate control procedure is to signal to the peer Iu UP protocol layer the permitted rate(s) over Iu in the reverse direction of the sent rate control frame.
The Iu rate control procedure is invoked whenever the SRNC/CN decides that the set of downlink/uplink permitted rates over Iu shall be modified, as shown in Figure 1-29. The permitted rate is given as RFCI indicators.
RNC/CN CN/RNC
Rate Control (RFCI indicators, [Downlink send intervals*]) * Optional
Figure 1-29 Rate control
IV. Time Alignment Procedure

Time alignment procedure is to minimize the buffer delay in RNC by controlling the transmission timing in the peer Iu UP protocol layer entity. The time alignment procedure is invoked whenever the SRNC detects the reception of Iu UP PDU at an inappropriate timing that leads to an unnecessary buffer delay as shown in Figure 1-30. The Iu UP protocol layer entity in SRNC indicates the peer entity the necessary amount of the delay or advance adjustment in the number of 500 s steps. A supervision timer TTA is started after sending the Iu UP time alignment frame. This timer supervises the reception of the time alignment acknowledgement frame. The requested Iu UP protocol layer entity in the peer node adjusts the transmission timing by the amount as indicated by SRNC. If the time alignment frame is correctly formatted and treated by the receiving Iu UP protocol layer and the time alignment is treated correctly by the upper layers, this latter sends a time alignment acknowledgement frame. Upon reception of a time alignment acknowledgement frame, the Iu UP protocol layer in the SRNC stops the supervision timer TTA. If the CN cannot handle the time alignment frame, it will send an NACK frame to the RNC, indicating the causes. The RNC will decide whether to send again the time alignment frame or not according to the causes and meanwhile stop the timer TTA.
RNC
User data with bad timing Time Alignment ACK User data with adjusted timing
CN
Figure 1-30 Time alignment
V. Error Event
Error event procedure is to handle the error reporting. Over the Iu UP protocol the error reports are made with Error event frames as shown in in Figure 1-31,The Error event procedure in the Iu UP can be triggered by: An error detected by the Iu UP functions A request by the upper layers When an Error event is reported by an Error event frame the following information shall be included: A cause value Error distance (0: if Iu UP function detected; 1: if requested by upper layers).
RNC/ CN or other
Error event (Cause value, Error distance)
CN or other/ RNC
Figure 1-31 Error event
VI. Frame Quality Classification

Frame quality classification (FQC) is used to classify the Iu UP frames depending on whether errors have occurred in the frame or not.
The FQC information is exchanged between RNC and CN through user data transfer procedure, as shown in Figure 1-32.
RNC/CN Transfer of User Data , (FQC RFCI, payload )

Transfer of User Data , ( FQC RFCI,payload )
CN/RNC
Figure 1-32 Transfers of user data with FQC information
1.5.5 GTP-U Functions

GPRS Tunnel Protocol User Plane (GTP-U) is to transfer Iu-PS user data through tunnel protocol. In addition, it also includes the user plane auxiliary signalling such as error indication of data transferring, handshaking message and supported extension head list.
1.5.6 SABP Functions

Service Area Broadcast Protocol (SABP) is the protocol of the radio network layer on the Iu-BC interface, which provides the following functions: Message Handling This function is to broadcast new messages, amend existing broadcasted messages, and stop the broadcasting of specific messages. Load Handling This function is responsible for determining the loading of the broadcast channels at any particular point in time. Reset This function permits the CBC to end broadcasting in one or more service areas. Error Handling This function allows the reporting of general error situations, for which function specific error messages have not been defined.
Chapter 2 Transport Network Layer Procedure Analysis

2.1 Overview
In UTRAN, the transport network layer adopts a message adaptation and transfer mechanism to provide transport service for the radio network layer. In this way, the radio network layer can evolve without too much consideration for the transport technology. The transport network layer includes the following logical entities: Signalling ATM Adaptation Layer (SAAL) Message Transfer Part (Broadband) (MTP3-B) Access Link Control Application Part (ALCAP) Signalling Connection and Control Part (SCCP) In this chapter, we will discuss the architecture and function of each entity.
2.2 SAAL
2.2.1 Overview
The SAAL converts various formats of signalling messages from the upper layer into a format suitable for transmission in an AMT network.
NBAP SAAL SSCS SSCF AT UNI SSCF AT NNI STC MTP3-B
SSCOP CP
LM
CPCS SAR
Figure 2-1 SAAL structure
2-1
The structure of SAAL in BSC6800 is illustrated in Figure 2-1. The SAAL comprises the following parts: Service Specific Convergence Sublayer (SSCS) The SSCS includes Service Specific Coordination Function (SSCF) and Service Specific Connection Oriented Protocol (SSCOP). Common Part (CP) The CP adopts AAL adaptation layer 5 (AAL5). It comprises Common Part Convergence Sublayer (CPCS) as well as Segmentation and Reassembly (SAR). Layer Management (LM)
Note: For details about SSCF, refer to ITU-T Q.2140. For details about SSCOP, refer to ITU-T Q.2110. For details about LM, refer to ITU-T Q.2144.
2.2.2 SSCOP
I. Overview
The SSCOP transmits information and control information between two peer entities.
II. Function
The SSCOP performs the following functions. Sequence Integrity. This function preserves the order of SSCOP Service Data Units (SDUs) that were submitted for transfer by SSCOP. Error Correction by Selective Retransmission. Through a sequencing mechanism, the receiving SSCOP entity can detect missing SSCOP SDUs. This function corrects sequence errors through retransmission. Flow Control. This function allows an SSCOP receiver to control the rate at which the peer SSCOP transmitter entity may send information. Error Reporting to Layer Management. This function indicates to layer management errors which have occurred. Keep Alive. This function verifies that the two peer SSCOP entities participating in a connection are remaining in a link connection established state even in the case of a prolonged absence of data transfer. Local Data Retrieval. This function allows the local SSCOP user to retrieve in-sequence SDUs which have not yet been released by the SSCOP entity.
2-2
Connection Control. This function performs the establishment, release, and resynchronization of an SSCOP connection. It also allows the transmission of variable length user-to-user information without a guarantee of delivery. Transfer of User-Data. This function is used for the conveyance of user data between users of the SSCOP. SSCOP supports both assured and unassured data transfer. Protocol Error Detection and Recovery. This function detects and recovers from errors in the operation of the protocol. Status Reporting. This function allows the transmitter and receiver peer entities to exchange status information. SSCOP Protocol Data Units (PDUs) are the message units transmitted between SSCOP peer layers for connection setup and release and for reliable message transmission. They include the following basic PDUs. BGN PDU (Begin), used to set up connection between two peer SSCOP entities. It requests the peer SSCOP to clear data in the transmitter and receiver buffers, to perform initialization of state variables and receiving/sending counters. BGAK PDU (Begin Acknowledge), used to acknowledge the connection request from the peer end. BGREJ PDU (Begin Reject), used to reject the connection request from the peer SSCOP entity. END PDU (End), used to release the connection between the two ends in communication. ENDAK PDU (End Acknowledge), used to acknowledge the release action. RS PDU (Resynchronization), used to resynchronize the buffers and data transfer state variables. RSAK PDU (Resynchronization Acknowledge), used to acknowledge the resynchronization request originated from the peer entity. ER PDU (Error Recovery), used to recover errors in connection action. ERAK PDU (Error Recovery Acknowledge), used to acknowledge the recovery request. SD PDU (Sequenced Data), used to send user service data to the peer entity after SSCOP connection has been set up. POLL PDU (Status Request), used to request status information of the peer SSCOP after SSCOP connection setup. STAT PDU (Solicited Status Response), used as the response for POLL PDU. It is used to notify which SD PDUs have been received and which have not. It is also used to update the location of sending window so as to control the sending sequence No. of the max. SD PDU. The STAT PDU also includes the sending SN of the POLL PDU(N(PS)), which is used as the response to the POLL PDU. USTAT PDU (Unsolicited Status Response). It is sent by the receiving end to inform the peer end resending the lost SD PDUs when the receiving end detects loss of SD PDUs after comparing the receiving SN of SD PDU. The USTAT PDU
2-3
also contains data for updating sending window of the peer end, but contains no N(PS) segment. Unnumbered Data (UD). UD are transmitted between peer SSCOP users. The in-progress connection oriented sequencing will not be affected, no counter or status between the two entities will be altered, and no data will be retransmitted if they get lost. Management Data (MD). Unnumbered MD is transmitted between two SSCOP management entities. Similar to UD PDUs, no reliable receiving of the peer end is guaranteed.
III. SSCOP Operation State

SSCOP operation states reflect the states of the SSCOP in information exchanges with its user and peer respectively. It includes the following basic states: State 1 - Idle, the initial state of SSCOP. Each SSCOP entity turns to idle state after initialization and connection release. State 2 - Outgoing Connection Pending, the state when the local SSCOP entity has sent connection setup request and has not received acknowledgement from the peer end. State 3 - Incoming Connection Pending, the state when the local SSCOP has received a connection setup request from the peer end and is waiting for the response from the local end user. State 4 - Outgoing Disconnection Pending, the state after the local SSCOP entity requests to release the connection with the peer end and before the local end receives the connection release acknowledgement message. State 5 - Outgoing Resynchronization Pending, the state when the local end is waiting for the acknowledgement from the peer end for its connection resynchronization request. State 6 - Incoming Resynchronization Pending, the state when the local end has received the resynchronization request from the peer end and is waiting for the response from its user. State 7 - Outgoing Recovery Pending, the state when the local end has sent request to the peer end for connection recovery and is waiting for recovery acknowledgement. State 8 - Recovery Response Pending, the state when the SSCOP entity has recovered the connection and notified the user and is waiting for response from the user. State 9 - Incoming Recovery Pending, the state when the SSCOP entity has received the connection recovery request from the peer end and is waiting for response from its user. State 10 - Data Transfer Ready: the state when the connection setup, resynchronization or error recovery program has been successfully accomplished and the two SSCOP entities are ready for reliable data transmission.
2-4
IV. SSCOP Connection Setup

The procedure of SSCOP connection setup is as follows: 1) To set up connection between two peer SSCOP entities, the SSCF sends to SSCOP A an AA-ESTABLISH.req primitive, as is shown in Figure 2-2. The primitive includes the BR and SSCOP-UU parameters used by the SSCOP entity to generate a BGN message. 2) 3) 4) 5) 6) SSCOP A sends the BGN message to SSCOP B, where it is decoded, processed and mapped to an AA-ESTABLISH.ind signal. SSCOP B sends the AA-ESTABLISH.ind signal to the SSCF of the receiving entity. The SSCF responds to SSCOP A with AA-ESTABLISH.rsp primitive. The AA-ESTABLISH.rsp primitive also includes the SSCOP-UU and BR parameters. SSCOP B sends a BGAK message to SSCOP A, where the BGAK message is decoded, processed. SSCOP A sends AA-ESTABLISH.con to the SSCF of the originating entity. Now connection is set up between the two SAAL entities.
SSCOP A SSCOP B
AA-ESTABLISH.req
PDU BGN AA-ESTABLISH.ind.
AA-ESTABLISH.con.
PDU BGAK
AA-ESTABLISH.rsp.
Figure 2-2 SSCOP connection setup
V. SSCOP Connection Release

The procedure of SSCOP connection release is as follows: 1) 2) 3) 4) After SSCOP A receives AA-RELEASE.request, it sends END PDU to SSCOP B, as shown in Figure 2-3. SSCOP B sends AA-RELEASE.indication to the user. After the connection is released, SSCOP B sends ENDAK PDU to SSCOP A. SSCOP A sends AA-RELEASE.confirm to the SSCF to release the connection.
2-5

SSCOP A AA-RELEASE.request END

SSCOP B
AA-RELEASE.indication
AA-RELEASE. confirm ENDAK
Figure 2-3 SSCOP connection release
VI. SSCOP Data Transmission and Error Recovery

In this section, we will introduce the SSCOP data transmission and error recovery mechanism through an example as shown in Figure 2-4. 1) SSCOP A sends 4 SD PDUs to SSCOP B, with their N(S) numbered from 0 to 3. Only PDU1 and PDU2 properly reach SSCOP B. SSCOP B delivers PDU1 and PDU2 to the user. 2) SSCOP A then sends a POLL PDU, which contains a N(S)=5 representing the N(S) value of the next new SD PDU (the SD PDU to be transferred the next time). The POLL PDU also contains a N(PS)=1, the sequence No. of the POLL PDU. 3) SSCOP B uses a STAT PDU as the response to the POLL PDU. The N(R) in the STAT PDU is coded 3 for acknowledging PDU1 and PDU2 and for indicating its expectation of the next PDU, that is, PDU3. The N (PS) segment in the STAT PDU is the same as that in the corresponding POLL PDU. The list element in the STAT PDU is set as (3, 5), which tells the SSCOP A: To resend PDU3 and PDU4; To release PDU1 and PDU2 from the buffer; To preserve PDU3 and PDU4, because there is still no sufficient information about the results of PDU3 and PDU4.
Note: The odd element (the value is 3 in this example) represents a PDU within a certain loss interval, while the even element represents the first PDU in the next sequence properly received.
2-6

Action Tx 1 (0) 2 (0) 3 (0) 4 (0) 5 (1) 6 (1) 7 (1)

Rx Delivered
POLL(5,1)
1 2 X X
X X
5}) N(MR), {3, STAT(3, 1,
Free 1, 2
X X 7
Figure 2-4 SSCOP data transmission
2.2.3 SSCF
I. Overview
As shown in Figure 2-1, the SSCF functions as the adaptation layer of the SSCOP and upper layer applications. The upper layer applications include NBAP, MTP3-B and Signalling Transport Converter (STC). The MTP3-B is used for network-to-network interface (NNI), which has higher link quality. The SAAL is required to support link quality check and to help the MTP3-B to perform link switchover. However, the NBAP is used for User-to-Network Interface (UNI), which has poorer link quality and greater delay. Therefore, the SSCF is divided into SSCF-NNI and SSCF-UNI to cater to different upper layer applications. SSCF-NNI is used for adapting the SSCOP and the upper layer MTP3-B. It maps primitives from the MTP3-B to SSCOP signals as required, or reversely. The SSCF-NNI acts as a medium for signal transferring between SSCOP and MTP3-B. The SSCF does not send PDUs to the peer SSCF of the receiver. It transfers the information through SSCOP PDUs. Besides primitive mapping, the SSCF-NNI also implements local data retrieval, link state maintenance, and link quality check. It reports link information to the LM. SSCF-UNI is used for adapting the SSCOP and the upper layer NBAP or STC. It implements error-free sequential data transmission by the SSCOP. Similar to the SSCF-NNI, the SSCF-UNI maps primitives from the NBAP/STC to SSCOP signals as required. It differs from SSCF-NNI in that it does not implement link alignment and data retrieval functions. The SSCF-UNI accomplishes primitive mapping, SAAL link setup and release, and data transmission acknowledgement.
II. Function
The SSCF performs the following functions. Primitive mapping
2-7
The SSCF maps primitives from the MTP3-B to SSCOP signals as required, or reversely. Local data retrieval In the case of link failure, the SSCF retrieves unsent data from the link before link switchover, and then sends the data to another link for transmission. Flow control The SSCF reports to the user the congestion level (or no congestion) to prevent the loss of cells. It also adjusts certain PDUs to the lower layer to prevent congestion at the peer end. Link state maintenance According to primitives received from the MTP3-B and SSCOP, the SSCF maintains information about link states, such as Out Of Service and In Service. Using the information, it can provide primitives/signals to the MTP3-B and SSCOP for link management. Reporting to LM The SCCF sends Management AAL (MAAL) primitives to the LM. For example, the SSCF reports link fault to the LM when a link gets faulty. It monitors errors with the help of the LM. Link alignment
2.2.4 CPCS
CPCS-PDU payload
PAD 0~47bytes
UUI 8 bits
CPI 8 bits
LI 16 bits
CRC 32bits
CPCS-PDU tail
Figure 2-5 CPCS-PDU format As shown in Figure 2-5, the CPCS-PDU includes three parts, CPCS-PDU payload, PAD and CPCS-PDU tail. The length of CPCS-PDU payload is variable within 165535 bytes. The bytes filled in PAD make the length of CPCS-PDU the integer times of 48 bytes. The length of CPCS-PDU tail is 8 bytes, including the following parts: User-to-User Indication (UUI), used for the transparent transmission of information between CPCS users. CPCS Part Indication (CPI), used to make the length of CPCS-PDU tail as 8 bytes. Length Indication (LI), used to indicate the length of CPCS-PDU payload.
2-8
Cyclic Redundancy Check (CRC), used to check the content of CPCS-PDU, including CPCS-PDU payload, PAD, UUI, CPI and LI.
2.2.5 SAR
The Segment and Reassemble (SAR) sublayer in the AAL5 segments the CPCS-PDU into 48-byte SAR-PDU without any overheads. The reassembly function is performed during SDU receiving.
2.2.6 LM
I. Overview
The LM interacts directly with SAAL sublayers to accomplish Operation Administration and Maintenance (OAM) functions. No interactions are defined between CPCS and SAR, because both CPCS and SAR are hardware dependent. The SSCS LM is responsible for the following tasks: The SSCS LM determines whether a link shall exit or enter service status. The SSCS LM conducts multiple measurements periodically. For example, it counts each links service life, fault frequency, congestion frequency, and so on. The LM can be in any of the following states: Out Of Service Alignment Proving Aligned Ready In Service
II. Function
The LM provides three algorithms for error monitoring. These algorithms can detect burst errors lasting more than 400 ms. Algorithm 1 applies to heavy load. If the data volume to be sent is too large, the receiving end does not have enough time to process them so that data in the buffer cannot be released on time and the sending queue keeps increasing. When the sending queue is increased to a certain value, links will be released. Algorithm 2 applies to medium load. Algorithm 2 monitors the number of data retransmissions. Within a certain period, if the number of data retransmissions exceeds the threshold, the link quality must be very poor. When the transmission delay cannot be tolerated by the system, links will be released. Algorithm 3 applies to light load. The number of STAT PDUs lost is the difference between the number of POLL PDUs sent and the number of STAT PDUs received. If this value exceeds a certain value within a certain period, it means the link quality is very poor and links will be released.
2-9
2.2.7 SSCOP Message

I. Message Parameters
Parameters N(S) Comments VT(S) is mapped to N(S) whenever a new SD or POLL PDU is generated. Information field The information field of an SD, MD, or UD PDU is mapped from the Message unit parameter of an AA-DATA, MAA-UNITDATA, or AA-UNITDATA request, respectively. It is mapped to a Message unit parameter of an AA-DATA, MAA-UNITDATA, or AA-UNITDATA indication, respectively. N(PS) VT(PS) (after VT(PS) has been incremented) is mapped to N(PS) whenever a POLL PDU is generated. The receiver of a POLL PDU maps the received POLL.N(PS) into the field STAT.N(PS). In addition, to facilitate error recovery procedures, the current value of VT(PS) is mapped into N(PS) and stored in the transmitter buffer with the corresponding SD PDU whenever a SD PDU is sent. N(R) VR(R) is mapped to N(R) whenever a STAT or USTAT PDU is generated. N(MR) VR(MR) is mapped to N(MR) whenever a STAT, USTAT, RS, RSAK, ER, ERAK, BGN, or BGAK PDU is generated. This is the basis for credit granting by the receiver. SSCOP-UU The SSCOP-UU in a BGN, BGAK, BGREJ, END or RS PDU is mapped to and from the SSCOP-UU parameter of the corresponding SSCOP signal. Source (S) bit In an END PDU this bit conveys whether the originator of the release was the SSCOP or the SSCOP user. When the transmission of an END PDU is stimulated by the user, this bit is set to 0. When the transmission of an END PDU is stimulated by the SSCOP, this bit is set to 1. N(SQ) This field carries the connection sequence value. VT(SQ) is mapped to N(SQ) whenever a new BGN, RS, or ER PDU is transmitted. This field is used by the receiver together with VR(SQ) to identify retransmitted BGN, RS, and ER PDUs PDU Type field PDU type
2-10
II. Example
2.3 MTP3-B
2.3.1 Overview
Based on Message Transfer Part Layer 3 (MTP3), the MTP3-B is the protocol specification aiming at ATM features. It performs message exchange through the services provided by SAAL. The MTP3-B module performs MTP3-B protocol functions, including signalling message handling and signalling network management, as shown in Figure 2-6. Signalling message handling part This part guarantees the signalling message generated at the user part of a signalling point (SP) can be transmitted to the corresponding user part of the
2-11
destination specified by the related field in message signalling unit (MSU). There are only two user parts at Iu/Iur interface, that is, SCCP and STC. Functionally the function of this part may be further subdivided into message discrimination, message routing and message distribution. Signalling network management part This part performs re-networking for a signalling network in case of failure. With the increase of signalling network traffic and signalling link load, the signalling network might be congested. Therefore, this part also performs congestion control function. The signalling network management function can be classified as signalling traffic management, signalling link management and signalling route management.
Figure 2-6 MTP3-B protocol structure
2.3.2 Function
I. Message Discrimination
Message Discrimination is to identify the destination of a signalling message by analyzing the destination signalling point code (DPC) in the signalling message routing label. When a signalling message arrives at Layer 3 (MTP3-B) from Layer 2 (SAAL), this function first processes it and determines its next destination. If the local SP is the destination, the message will be handed over to the message distribution function for subsequent handling. If the local SP is not the destination and is capable of transferring, the message routing function will be enabled. If the local SP does not
2-12
have the transferring capability, the signalling network management function will be informed to handle the message as an illegal one.
II. Message Distribution

Message Distribution is to distribute the signalling message to the corresponding user part of the local SP. As the MTP3-B of the SP has to serve multiple user parts, it is required to decide to which user part the signalling message will be distributed by analyzing the service indicator (SI) in the service information octet (SIO) of the signalling message. When the SI field equals 0000 or 0001 (i.e., the message to be distributed is a signalling network management message or a maintenance and test message), the codes of the herder, H0 and H1, will be analyzed so as to specify by which signalling network management part the message is to be handled.
III. Message Routing

Message Routing is to select a proper route for the message according to the header information. It processes the message as follows: For the message sent from the upper layer, the message routing function finds an available route, if any, to send it. For the message sent from another SP, it will be sent out if the SP receiving it has the signalling transfer function and the Destination Signalling Point (DSP) of this message exists in the DSP table of this SP. For the message that does not belong to a SP, it will be discarded if this SP has the signalling transfer function but the DSP of this message does not exist in the DSP table of this SP.
IV. Signalling Traffic Management

Signalling Traffic Management is to transfer signalling traffic over signalling links or routes or temporarily reduce traffic in case of congestion. Signalling traffic management covers the following procedures: If a signalling link gets unavailable (for example, faulty, disconnected or inhibited), the traffic over the signalling link will be changed over to another one or more links. When the link becomes available (reconnected or uninhibited), the traffic will be changed back to this link. If a signalling route gets unavailable, the traffic over this route will be changed over to the substitute route by means of forcible rerouting. When the route becomes available, the traffics will be changed back to this route by the controlled rerouting program. If a signalling route is restricted, the traffic over this route will be changed over to the substitute route by the controlled rerouting program.
2-13
To limit the traffic of signalling sources in case of congestion, the signalling traffic flow control program is used.
V. Signalling Route Management

Signalling route management is to ensure reliable interchange of signalling route availability information among SPs.
VI. Signalling Link Management

Signalling link management is to stop using an unavailable or unreliable link and repeatedly restart it to make it available. Besides, it also provides the link test function to periodically test links for confirmation of the usability of these links.
2.3.3 Message Structure

The structure of MTP3-B is the same as that of MTP3. Service Information Octet (SIO) and Service Information Field (SIF) are also included in Its MSU.
I. Service Information Octet (SIO)

SIO comprises Service Indicator (SI) and Sub-Service Field (SSF), as shown in Figure 2-7. The length of SIO is eight bits, among which SI and SSF occupy four bits respectively.
2-14
Figure 2-7 SIO format and codes Service Indicator (SI) SI is used to indicate to which specified user part a transmitted message belongs. In the MTP of the signalling network, the signalling message handling function distributes the message to the specified user part according to the indication of SI. The code of SI is illustrated in Figure 2-7. The capacity of SI can be used to indicate 16 different user parts. The figure only shows several of them. Sub-Service Field (SSF) It is made up of 4 bits, of which the higher two bits act as the network indicator, and the lower two bits, coded 00, are reserved presently. The network indicator serves to distinguish the network attribute of the transmitted message, that is, to distinguish between an international signalling network message and a national signalling network message, as shown in Figure 2-7.
II. Signalling Information Field (SIF)

SIF includes two parts, addressing label and signalling message, as shown in Figure 2-8. Label
2-15
Label includes the necessary information needed to send the message to its destination. The length of standard routing label is 32 bits, it locates in the beginning of the SIF. Label includes Destination Point Code (DPC), Originating Signalling Point Code (OPC) and Signalling Link Selection Code (SLS). DPC is digital address, which is the code used to identify each signalling point uniquely in the SS7. When the DPC of the message represents the accepting signalling point, the message is sent to the corresponding user part that the service indicator of the SIO indicates (for instance, the SCCP). SLS is used to: - Guarantee the message order. Any two messages with the same SLS reach their destination in the same order they are sent. - Allow all the available links to share the traffic load equally. If a user part sends messages periodically, and distributes the SLS in a cyclic way, then all the service levels at the destination shall be the same.
SIF SIO First bit transmitted
Signaling message
SL S
OP C
DP C
Figure 2-8 SIF format Signalling message The signalling message part is also called service information part. This part can be further divided into several sub-fields. These sub-fields can be mandatory or optional. The length of them can be fixed or flexible to meet the demands of various functions or expansion. Therefore, this part applies to different user messages and enables transmitting different user messages in the common channel. The most important signalling message of MTP layer is the signalling network management message. In the following, we will focus on it.
III. Format of Signalling Network Management Message

Signalling network management messages, originating from Level 3 (peer or local end), mainly apply to signalling traffic management, signalling link management and signalling route management. A signalling network management message is identified, in a signalling network, by the SI of the SIO in the signal message unit, where SI equals 0000. This message is composed of n x 8 (n0) bits. It may contain one or more signalling or indicator codes, yet with a total length of integer number of octets.
2-16
Being one of MSUs, the signalling information of signalling network management messages is transmitted in the SIF, with the structure illustrated in Figure 2-9.
Management information
H1
H0
SLC
OPC
DPC First bit transmitted
8n ( n = 0)
24/14
24/14
Figure 2-9 General format of a signalling network management message Label Composed of DPC, OPC and SLC, as stated before Heading code The heading code is made up of two 4-digit bits: H0 and H1. H0 identifies the management message group, and H1 determines the messages in a message group. H0 and H1 occupy 4 bits respectively. They can represent 265 kinds of messages, that is, there are 16 message groups and each of them has 16 types of messages. Table 2-1 Description of heading code H0 H0 0000 0001 0010 0011 0100 0101 0110 0111 1001 1010 10111111 Reserved Changeover and changeback messages (CHM) Emergency changeover message (ECM) Transfer controlled and signalling route set congestion messages (FCM) Transfer-prohibited-allowed-restricted messages (TFM) Signalling-route-set-test messages (RSM) Management inhibit messages (MIM) Traffic restart allowed message (TRM) Spare User part flow control messages (UFC) Spare Description
2-17
The signalling network management message and its heading code allocation are described in Table 2-2 in details. Table 2-2 Network management messages of the third function level of SS7 Message H1 Group H0 0000 CHM ECM FCM TFM RSM MIM TRM DLM 0001 0010 0011 0100 0101 0110 0111 1000 1001 UFC 1010 1011 1100 1101 1110 1111 (UPU) ECO ECA RCT TFP RST LIN (TRA) RSR LUN LIA LUA LID LFU LLT (LRT) TFC TFR TFA XCO XCA CBD CBA 0000 0001 0010 0011 0100 0101 0110 0111 1000 10 10 10 11 11 11 11 01 10 11 00 01 10 11
CBA: Changeback-acknowledgement signal CBD: Changeback-declaration signal XCA: Extended Changeover Acknowledgement XCO: Extended Changeover Order ECA: Emergency-changeover-acknowledgement signal ECO: Emergency-changeover-order signal RCT: Signalling-route-set-congestion-test signal RSR: Signalling-route-set-test signal for restricted destination (national option),
2-18
RST: Signalling-route-set-test signal for prohibited destination TFR: Transfer-restricted signal (national option) TFA: Transfer-allowed signal TFC: Transfer-controlled signal TRA: Traffic-restart-allowed signal TFP: Transfer-prohibited signal LID: Link inhibit denied signal LFU: Link forced uninhibit signal LIN: Link inhibit signal LIA: Link inhibit acknowledgement signal LUA: Link uninhibit acknowledgement signal LUN: Link uninhibit signal LLT: Link local inhibit test signal LRT: Link remote inhibit test signal UPU: User Part Unavailable signal
2.3.4 Changeover, Changeback, and Management Prohibit

I. Changeover
Changeover refers to the signalling traffic management process which shifts the signalling traffic from a signalling link, when it turns from normal operation into unavailable (such as signalling link fault, blocking or out of service), to one or more alternative signalling links.
II. Changeback
Generally, signalling traffic in the signalling network are carried on normal signalling links, while alternative signalling links only take over the signalling traffic from the signalling links that are "temporarily" faulty. Therefore, signalling traffic must be changed back to normal signalling links once the temporarily faulty links are available again.
III. Management Prohibit

Management prohibit is a signalling traffic management function, which is used to maintain and test the signalling network. Signalling link prohibit can be started by the management function of the signalling link terminal. During the inhibited period, any link status of the second function level does not change. However, the signalling link is marked as inhibited, and the signalling traffic on the inhibited link is stopped temporarily. You can carry out tests periodically.
2-19
If necessary, the inhibited link can be un-inhibited by the MML command or signalling route control function.
2.3.5 Signalling Network Management and Signalling Link Status

MTP3-B usually regards a signalling link as either available or unavailable. A signalling link can transmit signalling traffic only when it is available. There are the following three causes for a signalling link to become unavailable: Signalling link faulty Signalling link inhibited Signalling link not working In the signalling network, the status of a signalling link may change as a result of the following: Signalling link faulty Signalling link restored Signalling link disconnected Signalling link connected Signalling link inhibited or uninhibited If a signalling link is identified as "Faulty", "Disconnected", or "Inhibited", it will become unavailable. If the signalling link is identified as "Restored", "Connected or "Uninhibited", it will again become available.
I. Signalling Link Faulty

In any of the following cases, the signalling link is deemed faulty and becomes unavailable: The SAAL gives the fault indication Out of Service. A request from the management system indicates this link is faulty. A changeover command from the peer end requests to change over the signalling traffic to another signalling link.
II. Signalling Link Restored

The process to remove the fault of a signalling link and make the signalling link ready for transmitting signalling traffic is referred to as signalling link restoration. When the fault is removed and initial alignment is successfully completed at both ends of the faulty signalling link, the signalling link becomes available again.
III. Signalling Link Disconnected

The process to stop traffic of a signalling link set or a signalling link is defined as signalling link disconnection. Signalling link may be disconnected upon the request of the operation and maintenance system or by the signalling link management function as well.
2-20
IV. Signalling Link Connected

The process to make the signalling link ready for signalling traffic transmission is defined as signalling link connection. When a disconnected signalling link has its signalling data link or signalling terminal connected again and the initial alignment is completed successfully, the once disconnected signalling link is regarded as being connected. Table 2-3 shows general processes of signalling network management upon change of signalling link status. Table 2-3 Signalling network management processes upon change of signalling link status Signalling network management Signalling link status Signalling traffic management Starts the changeover procedure (or emergency changeover procedure when necessary) to shift the signalling traffic Faulty (becomes unavailable) on the unavailable signalling link to one or more alternative signalling links. The process above mentioned includes specifying the alternative signalling link, recovering the messages sent yet not acknowledged. The changeback process, when necessary, is Restored activated to shift the signalling traffic from the one or more alternative signalling
2-21
Signalling link management
Signalling route management
When a signalling link is faulty, the signalling link management function will, according to the status of the signalling link set, connect another signalling link in the signalling link set, and then prepare for the restoration of the faulty signalling link and its signalling transmission The signalling route function is disabled if the signalling link fault does not result in any change of signalling route set status. Otherwise, the transfer-prohibited process or transfer-restricted process has to be started.
If another signalling link in the same link set is connected during the signalling link fault, then the stop process is used to change the
The signalling route function is disabled if the signalling link fault does not result in any change of signalling route set status. Otherwise, the
Signalling network management Signalling link status Signalling traffic management links back to the link that recovers to be available. It includes the process to specify the signalling traffic that can be changed back to and to maintain the correct message sequence. Signalling link management signalling link set status back to that before the fault occurs, and to disconnect the operating link connected during the signalling link fault, regarding it unable to transmit signalling. Normally, when a signalling link is to be disconnected, the signalling traffic has Disconnected already been transferred. If it is not yet transferred, the signalling traffic changeover process shall be executed. When one signalling link is disconnected, if the number of signalling links operating in the link set is less than the necessary number, another link will be connected. When the signalling link is connected, if the number of The same procedure Connected as that after a signalling link is restored connected signalling links in the link set is greater than the necessary number, another link will be disconnected. If a signalling route set The same procedure Inhibited as that after a signalling link is faulty None becomes unavailable or restricted, due to link inhibit, it cannot perform the transfer-prohibited
2-22
Signalling route management transfer-allowed process has to be started.
The same procedure as that after a signalling link is faulty
The same procedure as that after a signalling link is restored
Signalling network management Signalling link status Signalling traffic management Signalling link management Signalling route management process on the STP which can select routes for relevant messages. When a signalling The same procedure Uninhibited as that after a signalling link is restored None route set becomes available again due to link uninhibit, the transfer-allowed process will be employed.
2.3.6 Signalling Network Management and Signalling Route Status

For the signalling traffic to a destination, the signalling route may be in one of these two states: available, unavailable. When a transfer-prohibited message is received, indicating that the signalling traffic to a destination can no longer be transmitted via the STP sending out relevant messages, the signalling route will become unavailable. When a transfer-allowed message is received, indicating that the signalling traffic to a destination can be transmitted via the STP sending out the transfer-allowed message, the signalling route will again become available. Table 2-4 shows the processes of signalling network management upon change of signalling route status.
2-23
Table 2-4 Signalling network management processes upon change of signalling route status Signalling route status Signalling network management Signalling traffic management The forcible rerouting process is performed so that the signalling traffic to a Unavailable destination is changed over from the link set which includes the unavailable route to the alternative route connecting another STP. The controlled rerouting process is performed so that the signalling traffic to a destination is changed back Available from the signalling link set which includes the alternative signalling route to the signalling link set which includes the recovered route. The transfer-allowed process will be started, informing one or more adjacent signalling points that this STP can transmit messages again. Meanwhile, the route set test process or the route set congestion test process will be stopped. Signalling route management When a signalling route becomes unavailable, the transfer-prohibited process will be started, informing one or more adjacent signalling points that this STP can no longer transmit messages. Meanwhile, the route set test process or the route set congestion test process will be started accordingly.
2.3.7 MTP3-B Upper User Message

I. Message Structure
Refer to section 2.3.3 Message Structure.
2-24
II. Example
2.3.8 MTP3-B Test Message

2-25
II. Example
2.3.9 MTP3-B Management Message

2-26
II. Example
2.4 ALCAP
2.4.1 Overview
Q. AAL2 ALCAP SAAL STC MTP3-B STC
SAAL UNI
MTP3-B
Figure 2-10 ALCAP structure in the BSC6800 system Access Link Control Application Part (ALCAP) is also called Q.AAL2 protocol. It is the protocol of the control plane of the transport network layer on the Iub, Iur, and Iu-CS interfaces. The signalling bearers are of SAAL UNI type and MTP3-B type.
2-27
As shown in Figure 2-10, the ALCAP consists of a Q.AAL2 protocol processing layer and two STC adaptation layers. The former performs all protocol functions while the latter adapts primitives and shields bottom-layer (SAAL and MTP3-B) differences. The basic function of ALCAP is to establish and release AAL2 connection between two SPs. Besides, it maintains and manages such resources as micro channel. The ALCAP of BSC6800 complies with ITU-T Q.2630.1.
2.4.2 Function
I. AAL2 Connection Establishment and Release
The establishment and release of an AAL2 connection is initiated by the ALCAP at the RNC side (RNC ALCAP for short hereinafter), as shown in Figure 2-11.
Figure 2-11 AAL2 connection establishment and release procedure The procedure to establish an AAL2 connection is as follows: 1) 2) 3) The RNC ALCAP sends an ESTABLISH REQUEST message to the ALCAP at the peer end (peer RNC for short hereinafter). The peer ALCAP sends an ESTABLISH INDICATION primitive to the service layer after resource allocation and starts the wait timer. After receiving an ESTABLISH response from the service layer before the time expires, it sends an ESTABLISH confirm to the RNC ALCAP. The release procedure is similar to the establishment procedure.
II. AAL2 Path Block and Unblock

To prevent a new connection from being established over an AAL2 path, the O&M system can initiates a path block procedure. When a path is blocked, the originating end is in a locally blocked state and the peer end is in a remotely blocked state. If the peer end also initiates a block procedure, both ends of the path are in a locally blocked state. The test connection can be set up over the path in a blocked state.
2-28
The blocked AAL2 path may be unblocked through an unblock procedure. The unblock procedure can be initiated by local end or remote end. The procedure of blocking and unblocking a path is shown in Figure 2-12.
O&M RNC ALCAP ALCAP
BLOCK REQUEST BLOCK REQUEST BLOCK CONFIRM BLOCK CONFIRM UNBLOCK REQUEST UNBLOCK REQUEST UNBLOCK CONFIRM UNBLOCK CONFIRM
Figure 2-12 AAL2 path block and unblock procedure The procedure to block a path is as follows: 1) 2) 3) 4) The RNC O&M system initiates a BLOCK REQUEST to the RNC ALCAP. The RNC ALCAP sends a BLOCK REQUEST to the peer ALCAP. After analyzing the message, the peer ALCAP sets the path in blocked status, generates a BLOCK CONFIRM message, and sends it to the RNC ALCAP. The RNC ALCAP sends the message to the O&M system. The unblock procedure is similar to the block procedure.
III. AAL2 Connection/Path Reset

The reset procedure can help to release AAL2 connection or AAL2 PATH in confused state. This procedure can reset an AAL2 connection, an AAL2 PATH, or all AAL2 PATHs between two SPs. The reset procedure is shown in Figure 2-13.
O&M RNC ALCAP ALCAP Service
RESET REQUEST RESET REQUEST RELEASE INDICATION RESET CONFIRM RESET CONFIRM
Figure 2-13 AAL2 connection/path reset procedure The reset procedure is as follows:
2-29
1) 2) 3)
The RNC O&M system initiates a RESET REQUEST to the RNC ALCAP. The RNC ALCAP sends a RESET REQUEST to the peer ALCAP. After analyzing the message, the peer ALCAP sends a RESET CONFIRM message to the RNC ALCAP. If there is any connection in the micro channel or path, the connection will be released and a RELEASE INDICATION will be reported to the service layer.
4)
The RNC ALCAP sends the message to the O&M system.

The length of an ALCAP message is variable and the message header is 6 bytes long fixedly. The parameters in the message are classified as mandatory parameters and optional parameters. The parameters can also be divided into fixed-length parameters and variable-length parameters. The first byte of the variable-length field in a variable-length parameter indicates the length of the field. The structure is shown in Figure 2-14.
Signaling related ID Message ID Message compatability field Message length ID of parameter A Compatability field for parameter A Length of parameter A Field a in parameter A Field b in parameter A Length of field c in parameter A Field c in parameter A Parameter B M
Figure 2-14 ALCAP message structure
2.4.4 Establishment Request Message

2-30
II. Example
2.5 SCCP
2.5.1 Overview
Signalling Connection Control Part (SCCP) is used to enhance the functions of Message Transfer Part (MTP). The addressing function of MTP can only be used to transmit messages to nodes, providing only connectionless message transfer. The SCCP is able to provide the addressing function to identify each SCCP user in a node using DPC and subsystem number (SSN). The SCCP in the BSC6800 system complies with ITU-T Q711-716.
2-31
2.5.2 Function
The SCCP performs network service, routing and management functions.
I. Network Service Function

The SCCP provides three classes of protocols: Class 0: Basic connectionless class Class 1: In-sequence delivery connectionless class Class 2: Basic connection-oriented class Class-0 and class-1 protocols are used in connectionless services, while class-2 protocol is used in connection-oriented services. Connectionless services Connectionless services are implemented in the case that the user directly transmits data information in the signalling network by means of SCCP and MTP routing functions without prior establishment of signalling connections, featuring flexibility and simpleness and applicable to the transmission of small quantities of data. Among them, class-0 service does not ensure the messages can be transmitted in sequence but class-1 service is able to do that depending on the cooperation of the signalling link selection code (SLS) and MTP. Connectionless services implement user data transmission using Unit Data (UDT) and Enhanced Unit Data (XUDT) messages. The UDT message cannot be segmented and reassembled and it can transmit up to 255 octets. The XUDT message can be segmented and reassembled and it can transmit up to 2k octets. Connection-oriented services Connection-oriented services are implemented only after the user establishes signalling connections (virtual connections) between the OSP and DSP by answer mode before transmitting signalling messages. In this way, the data can be transmitted via the established signalling connections instead of the routes selected via the SCCP routing function. Upon the completion of the data transmission, the user can release the connections with the primitive N_DISCONNECT_REQ. Connection-oriented services are applicable to the transmission of large quantities of data. The reason is that the DSP is confirmed to be able to receive data prior to data transmission to avoid invalid transmission of large quantities of data. Furthermore, the pre-established connections make the SCCP routing function unnecessary to the subsequent transmissions, thus effectively reducing the batch transmission delay. The implementation procedure of connection-oriented services includes connection establishment, data transmission and connection release. Capable of setting up coupling connections, the BSC6800 system provides the local reference function of freezing the local node to prevent disordered connections when releasing the local connection reference source.
2-32
II. Routing Function

The routing function of the BSC6800 system is to implement the addressing for SCCP address information, more universal than the DPC routing function. The SCCP address information covers: DPC DPC+SSN Where, DPC is the one adopted by MTP while SSN is used to identify different SCCP users (for example, ISUP, MAP, TCAP, and so on) in a node so as to compensate for shortage of MTP users and broaden the addressing scope, thus to be applicable for new services in the future. The routing function of the BSC6800 system can obtain DPC+SSN or DPC by translation as required. Upon receiving a message from the MTP, the SCCP route control part analyzes the called address. If this node is the destination of this message, the SCCP will distribute the message to the destination user. Otherwise, the SCCP will translate the address of the message to form a new route flag and potential new called address and then send them to the MTP. Upon receiving a message from the connection-oriented control part or the connectionless control part, the SCCP performs route analysis and then sends it to the MTP part, the connection-oriented control part or the connectionless control part for processing.
III. Management Function

The SCCP management function implements network maintenance by rerouting or adjusting traffic volume in case of network fault or congestion. This function is realized via the transmission of the SCCP management messages (by class-0 UDT) and primitives. The SCCP management includes SP management, subsystem management, harmonization between active/standby subsystems, broadcast of status information, and status test of faulty subsystem.

If the SI of an MSU equals 0011, it means the message is an SCCP message. The content of the SCCP message is located in the SIF of the MSU, as shown in Figure 2-15. The route flag of SCCP includes DPC, OPC and SLS.
2-33
Figure 2-15 SCCP message structure
2.5.4 Connection Request Message

2-34
II. Example
2-35
Chapter 3 Cell Related Procedure Analysis

3.1 Overview
Successful cell setup is prerequisite to normal communication of the WCDMA system. The BSC6800 can implement cell setup in two ways: Cell setup via O&M system This procedure is directly initiated by an RNC and involves such procedures as cell setup, common transport channel setup, Iub interface data transport bearer setup, system information update, common measurement initiation, and so on. Cell setup triggered by resource audit response from NodeB The RNC initiates a resource audit procedure towards a NodeB. The NodeB sends an audit response to the RNC. Then, the RNC initiates a cell setup procedure. The steps thereafter are similar to those involved in the cell setup through the O&M system. This chapter introduces the procedures involved in cell setup and a cell setup example.
3.2 Procedures Involved in Cell Setup

3.2.1 Resource Status Indication
NodeB CRNC
RESOURCE STATUS INDICATION
Figure 3-1 Resource status indication procedure The NodeB uses a resource status indication to report its physical resources to the RNC. In the following cases, the NodeB triggers the resource status indication procedure: When a local cell is added to the NodeB, that is, it becomes existent When a local cell is deleted form the NodeB, that is, it becomes nonexistent. When a local cell changes in its capability at the NodeB
When a cell changes in its capability and/or its resource operational state at the NodeB When common physical channels and/or common transport channels change in their capabilities at the NodeB When a communication control port changes in its resource operational state at the NodeB When a local cell group changes its resource capability at the NodeB The NodeB initiates a RESOURCE STATUS INDICATION message to the CRNC in each of the above cases, as shown in Figure 3-1. This message may contain the trigger cause and the associated logical resource information.
3.2.2 Resource Audit

The resource audit procedure is executed by the CRNC to audit the configuration and status of the logical resources in the NodeB. A complete audit of a NodeB is performed by one or more audit procedures and each procedure carries an audit sequence number. The audit may cause the CRNC to know the logical resources of the NodeB and re-synchronize its resources with those of the NodeB. The procedure is initiated with an AUDIT REQUEST message sent from the CRNC to the NodeB, as shown in Figure 3-2. If the [Start of Audit Sequence] information element (IE) in the AUDIT REQUEST message is set to start of audit sequence, a new audit sequence is started, any ongoing audit sequence shall be aborted, and the NodeB shall provide (part of the) audit information. If the [Start of Audit Sequence] IE is set to not start of audit sequence, the NodeB shall provide (part of) the remaining audit information not already provided during this audit sequence.
NodeB CRNC
AUDIT REQUEST
AUDIT
RESPONSE
Figure 3-2 Resource audit procedure The NodeB responds to the resource audit request of the RNC by an AUDIT RESPONSE message. The AUDIT RESPONSE message includes information about physical common channel of logical cell, CCP, local cell, and local group cell. Where, the local cell and the local cell group information are the abstraction of the NodeBs
physical resources. In this way, the RNC can distribute the logical resources of the cell according to the abstract data. If the AUDIT RESPONSE message completes the audit sequence, the NodeB shall set the [End of Audit Sequence Indicator] IE in the AUDIT RESPONSE message to End of Audit Sequence. If not all audit information is provided in the AUDIT RESPONSE message, the NodeB shall set the [End of Audit Sequence Indicator] IE in the AUDIT RESPONSE message to Not End of Audit Sequence.
3.2.3 Cell Setup

NodeB CRNC
CELL SETUP REQUEST
CELL SETUP RESPONSE
Figure 3-3 Cell setup procedure After receiving the AUDIT RESPONSE message from the NodeB, the CRNC sends a CELL SETUP REQUEST message to the NodeB if the conditions of cell setup are satisfied. The NodeB shall set up a new cell according to the parameters included in that message, as shown in Figure 3-3. If the CELL SETUP REQUEST message includes one or more [Secondary CPICH Information] IEs, the NodeB shall configure and activate the Secondary CPICHs (SCPICHs) in the cell according to received configuration data. The [Maximum Transmission Power] IE value shall be stored in the NodeB and at any time, the total maximum output power in the cell shall not be greater than this value. If the CELL SETUP REQUEST message includes one or more [Closed Loop Timing Adjustment Mode] IEs, the value(s) shall be stored in the NodeB and applied when closed loop feed-back mode diversity is used on DPCH. When the cell is successfully configured, the NodeB shall store the [Configuration Generation ID] IE value and send a CELL SETUP RESPONSE message as a response. When the cell is successfully configured, there shall be CPICH(s), Primary SCH (PSCH), Secondary SCH (SSCH), Primary CCPCH (PCCPCH) and BCH. The cell and the channels are set to Enabled state. When the cell is not successfully configured, the CELL SETUP FAILURE message shall be sent to the CRNC.
3.2.4 Common Transport Channel Setup

The common transport channel setup procedure is used for establishing the following channels: Secondary CCPCH (SCCPCH), FACH, PCH, PICH, PRACH, RACH, and AICH.
NodeB CRNC
COMMON TRANSPORT CHANNEL SETUP REQUEST COMMON TRANSPORT CHANNEL SETUP RESPONSE
Figure 3-4 Common transport channel setup procedure The procedure is initiated with a COMMON TRANSPORT CHANNEL SETUP REQUEST message sent from the CRNC to the NodeB. One message can configure only one of the following combinations: One SCCPCH, and FACHs, PCH and PICH related to that SCCPCH One PRACH, one RACH and one AICH related to that PRACH If successfully setting up the common transport channel, the NodeB responds with a COMMON TRANSPORT CHANNEL SETUP RESPONSE message to the CRNC. If failing to set up the common transport channel, the NodeB responds with a COMMON TRANSPORT CHANNEL SETUP FAILURE message.
Note: The transport channel synchronization procedure in user plane follows the successful establishment of downlink common transport channel. After the PCH is established successfully, the node synchronization procedure in user plane might follow.
3.2.5 Iub Interface User Plane Setup

The CRNC sends an ALCAP message Q.AAL2 ESTABLISH REQUEST to the NodeB, requesting for Iub interface user plane establishment. After a successful establishment, the NodeB responds with an ALCAP message Q.AAL2 ESTABLISH CONFIRM to the CRNC, indicating the Iub interface user plane is established.
3.2.6 System Information Update

NodeB CRNC
SYSTEM INFORMATION UPDATE REQUEST SYSTEM INFORMATION UPDATE RESPONSE
Figure 3-5 System information update procedure After all common transport channels are set up, the CRNC sends a SYSTEM INFORMATION UPDATE REQUEST message to the NodeB, as shown in Figure 3-5. That message includes the system information broadcast in segments on the BCCH and the scheduling information of each segment. If the NodeB successfully updates the system information on the broadcast channel according to the parameters in the SYSTEM INFORMATION UPDATE REQUEST message, it responds to the CRNC with a SYSTEM INFORMATION UPDATE RESPONSE message. Otherwise, the NodeB responds with a SYSTEM INFORMATION UPDATE FAILURE message.
3.2.7 Common Measurement Initiation

NodeB CRNC
COMMON
MEASUREMENT REQUEST MEASUREMENT RESPONSE
INITIATION
COMMON
INITIATION
Figure 3-6 Common measurement initiation procedure The procedure is initiated with a COMMON MEASUREMENT INITIATION REQUEST message sent from the CRNC to the NodeB using the NodeB control port, as shown in Figure 3-6. That message includes the measurement object type (such as cell and RACH), common measurement type (such as Tx carrier power and Rx total wide band power), and report characteristics (such as On-Demand report, periodic report, and event report). Upon receipt of the message, the NodeB initiates the requested measurement according to the parameters in the request.
If the NodeB is able to initiate the measurement requested by the CRNC, it responds with a COMMON MEASUREMENT INITIATION RESPONSE message sent over the NodeB control port. If the initiation fails, it responds with a COMMON MEASUREMENT INITIATION FAILURE message.
3.2.8 Cell Reconfiguration

The cell reconfiguration procedure is used for an RNC to reconfigure a cell in a NodeB when the cell parameters need to be modified, as illustrated in Figure 3-7.
NodeB CRNC
CELL RECONFIGURATION REQUEST
CELL
RECONFIGURATION RESPONSE
Figure 3-7 Cell reconfiguration procedure The CRNC sends a CELL RECONFIGURATION REQUEST message to the NodeB. Upon reception, the NodeB reconfigures the cell according to the parameter included in the message. If the CELL RECONFIGURATION REQUEST message includes the [Primary SCH Information] IE, the NodeB reconfigures Primary SCH power in the cell according to the [Primary SCH Power] IE value. If the CELL RECONFIGURATION REQUEST message includes the [Secondary SCH Information] IE, the NodeB reconfigures Secondary SCH power in the cell according to the [Secondary SCH Power] IE value. If the CELL RECONFIGURATION REQUEST message includes the [Primary CPICH Information] IE, the NodeB reconfigures Primary CPICH power in the cell according to the [Primary CPICH Power] IE value. The NodeB adjusts all the transmitted power levels relative to the Primary CPICH power according to the new value. If the CELL RECONFIGURATION REQUEST message includes one or more [Secondary CPICH Information] IEs, the NodeB reconfigures the power for each Secondary CPICH in the cell according to their [Secondary CPICH Power] IE value. If the CELL RECONFIGURATION REQUEST message includes the [Primary CCPCH Information] IE, the NodeB reconfigures BCH power in the cell according to the [BCH Power] IE value.
If the CELL RECONFIGURATION REQUEST message includes the [Maximum Transmission Power] IE, the value shall be stored in the NodeB and, at any time, the total maximum output power in the cell shall not be greater than this value. If reconfiguring the cell successfully, the NodeB stores the new [Configuration Generation ID] IE value and sends a CELL RECONFIGURATION RESPONSE message as a response. If failing to reconfigure the cell, the NodeB sends a CELL RECONFIGURATION FAILURE message. If the CELL RECONFIGURATION REQUEST message includes the [Synchronization Configuration] IE, the NodeB reconfigures the indicated parameters in the cell according to the IE value. When the parameters in the [Synchronization Configuration] IE affect the thresholds applied to a radio link set, the NodeB immediately starts the new thresholds.
3.2.9 Cell Deletion

The cell deletion procedure is used to delete a cell from a NodeB, as illustrated in Figure 3-8.
NodeB CRNC
CELL DELETION REQUEST
CELL DELETION RESPONSE
Figure 3-8 Cell deletion procedure 1) The CRNC sends a CELL DELETION REQUEST message to the NodeB. Upon reception, the NodeB deletes the cell and any remaining common and dedicated channels within the cell. The states of the deleted cell and common channels shall be set to Not Existing. The NodeB deletes all radio links and all NodeB communication contexts within the cell. The NodeB also initiates releasing of the corresponding transport bearers in the user plane. 2) After deleting the cell, the NodeB returns a CELL DELETION RESPONSE message as a response.
3.2.10 Resource Status Indication Message

IE/Group name Message Discriminator Message Type Transaction ID Indication Type CHOICE Indication Type >No Failure >>Local Cell Information >>>Local Cell ID >>>Add/Delete Indicator >>>DL or Global Capacity Credit >>>UL Capacity Credit >>>Common Channels Capacity Consumption Law >>>Dedicated Channels Capacity Consumption Law >>>Maximum DL Power Capability >>>Minimum Spreading Factor >>>Minimum DL Power Capability >>>Local Cell Group ID >>Local Cell Group Information >>>Local Cell Group ID >>>DL or Global Capacity Credit M M O C-add C-add C-add C-add M M C-add O C-add M M M M M Presence Semantics description
IE/Group name >>>UL Capacity Credit >>>Common Channels Capacity Consumption Law >>>Dedicated Channels Capacity Consumption Law >Service Impacting >>Local Cell Information >>>Local Cell ID >>>DL or Global Capacity Credit >>>UL Capacity Credit >>>Common Channels Capacity Consumption Law >>>Dedicated Channels Capacity Consumption Law >>>Maximum DL Power Capability >>>Minimum Spreading Factor >>>Minimum DL Power Capability >>Local Cell Group Information >>>Local Cell Group ID >>>DL or Global Capacity Credit >>>UL Capacity Credit >>>Common Channels Capacity Consumption Law >>>Dedicated Channels Capacity Consumption Law >>Communication Control O M O O O O O O O M O O O M O M
Presence
Semantics description
IE/Group name Port Information >>>Communication Control Port ID >>>Resource Operational State >>>Availability Status >>Cell Information >>>C-ID >>>Resource Operational State >>>Availability Status >>>Primary SCH Information >>>Secondary SCH Information >>>Primary CPICH Information >>>Secondary CPICH Information >>>>Secondary CPICH Individual Information >>>Primary CCPCH Information >>>BCH Information >>>Secondary CCPCH Information >>>>Secondary CCPCH Individual Information >>>PCH Information >>>PICH Information >>>FACH Information >>>>FACH Individual Information >>>PRACH Information M O O M O O M M O O O O O M M M
Presence
IE/Group name >>>>PRACH Individual Information >>>RACH Information >>>>RACH Individual Information >>>AICH Information >>>>AICH Individual Information >>>PCPCH Information >>>>PCPCH Individual Information >>>CPCH Information >>>>CPCH Individual Information >>>AP-AICH Information >>>>AP-AICH Individual Information >>>CD/CA-ICH Information >>>>CD/CA-ICH Individual Information >>>SCH Information Cause O O M M M M M M M
Presence
II. Example
3.2.11 Audit Response Message

IE/Group name Message Discriminator Message Type Transaction ID End Of Audit Sequence Indicator Cell Information >C-ID >Configuration Generation ID >Resource Operational State >Availability Status >Local Cell ID >Primary SCH Information >Secondary SCH Information >Primary CPICH Information >Secondary CPICH Information >>Secondary CPICH Individual Information >Primary CCPCH Information >BCH Information >Secondary CCPCH Information >>Secondary CCPCH Individual Information >PCH Information >PICH Information >FACH Information >>FACH Individual Information >PRACH Information >>PRACH Individual Information M M O O M O O M M M M M M O O O M M M M
Presence
IE/Group name >RACH Information >>RACH Individual Information >AICH Information >>AICH Individual Information >PCPCH Information >>PCPCH Individual Information >CPCH Information >>CPCH Individual Information >AP-AICH Information >>AP-AICH Individual Information >CD/CA-ICH Information >>CD/CA-ICH Individual Information >SCH Information Communication Control Port Information >Communication Control Port ID >Resource Operational State >Availability Status Local Cell Information >Local Cell ID >DL or Global Capacity Credit >UL Capacity Credit >Common Channels Capacity Consumption Law >Dedicated Channels Capacity Consumption Law M M M O M M M M O M M M M M M
Presence
IE/Group name >Maximum DL Power Capability >Minimum Spreading Factor >Minimum DL Power Capability >Local Cell Group ID Local Cell Group Information >Local Cell Group ID >DL or Global Capacity Credit >UL Capacity Credit >Common Channels Capacity Consumption Law >Dedicated Channels Capacity Consumption Law Criticality Diagnostics O M M M O M O O O O
Presence
II. Example
3.2.12 Cell Setup Request Message

IE/Group name Message Discriminator Message Type Transaction ID Local Cell ID C-ID Configuration Generation ID T_Cell UARFCN UARFCN Maximum Transmission Power Presence M M M M M M M M M M Cell ID Offset of T_cell against BFN Maximum transmission power Closed Loop Timing Adjustment Mode Primary Scrambling Code M Primary scrambling code of cell Synchronization Configuration >N_INSYNC_IND >N_OUTSYNC_IND >T_RLFAILURE DL TPC pattern 01 count Primary SCH Information >Common Physical Channel ID >Primary SCH Power >TSTD Indicator Secondary SCH Information >Common Physical Channel ID M M M M M M M M O Semantics description
IE/Group name >Secondary SCH power >TSTD Indicator Primary CPICH Information >Common Physical Channel ID >Primary CPICH power >Transmit Diversity Indicator Secondary CPICH Information >Common Physical Channel ID >DL Scrambling code >FDD DL Channelisation Code Number >Secondary CPICH Power >Transmit Diversity Indicator Primary CCPCH Information >Common Physical Channel ID >BCH Information >>Common Transport Channel ID >>BCH Power >STTD Indicator Limited power increase information >Power_Raise_Limit >DL_power_averaging_window_siz e
Presence M M M M M M M M
M M
M M M
PCPICH transmission power
M M
II. Example
3.2.13 Common Transport Channel Setup Request Message

IE/Group name Message Discriminator Message Type Transaction ID C-ID Configuration Generation ID CHOICE common physical channel to be configured >Secondary CCPCH Situation when the SCCPCH established >>Secondary CCPCH >>>Common Physical Channel ID >>>FDD SCCPCH Offset >>>DL Scrambling Code >>>FDD DL Channelisation Code Number >>>TFCS >>>Secondary CCPCH Slot Format >>>TFCI Presence C SlotFormat >>>Multiplexing Position >>>Power Offset Information >>>>PO1 >>>>PO3 >>>STTD Indicator M M M M Power offset TFCI bit power offset Preamble bit power offset M M M M C-PCH M SCCPCH timing offset Presence M M M M M M Cell ID Semantics description
IE/Group name >>>FACH Parameters >>>>Common Transport Channel ID >>>>Transport Format Set >>>>ToAWS >>>>ToAWE >>>>Max FACH Power >>>PCH Parameters >>>>Common Transport Channel ID >>>>Transport Format Set >>>>ToAWS >>>>ToAWE >>>>PCH Power >>>>PICH Parameters >>>>>Common Physical Channel ID >>>>>FDD DL Channelisation Code Number >>>>>PICH Power >>>>>PICH Mode >>>>>STTD Indicator >PRACH
Presence
M M M M
M M M M
. .
M M M
. Situation when PRACH established
>>PRACH >>>Common Physical Channel ID >>>Scrambling Code Number >>>TFCS M M M

IE/Group name >>>Preamble Signatures >>>Allowed Slot Format Information >>>>RACH Slot Format >>>RACH Sub Channel Numbers >>>Puncture Limit >>>Preamble Threshold >>>RACH Parameters >>>>Common Transport Channel ID >>>>Transport Format Set >>AICH Parameters >>>Common Physical Channel ID >>>AICH Transmission Timing >>>FDD DL Channelisation Code Number >>>AICH Power >>>STTD Indicator >PCPCHes
Presence M
M M M M M
M M M
M M
Situation when PCPCH established
>>CPCH Parameters >>>Common Transport Channel ID >>>Transport Format Set >>>AP Preamble Scrambling Code >>>CD Preamble Scrambling Code >>>TFCS >>>CD Signatures M M M M M O
IE/Group name >>>CD Sub Channel Numbers >>>Puncture Limit >>>CPCH UL DPCCH Slot Format >>>UL SIR >>>Initial DL transmission Power >>>Maximum DL Power >>>Minimum DL Power >>>PO2 >>>PO3 >>>FDD TPC DL Step Size >>>N_Start_Message >>>N_EOT >>>Channel Assignment Indication >>>CPCH Allowed Total Rate >>>PCPCH Channel Information >>>>Common Physical Channel ID >>>>CPCH Scrambling Code Number >>>>DL Scrambling Code >>>>FDD DL Channelisation Code Number >>>>PCP Length >>>>UCSM Information >>>>>Min UL Channelisation Code Length >>>>>NF_max >>>>>Channel Request
Presence
M M M M M M M M M M M M M
M M
M M
M C-NCA M
IE/Group name Parameters >>>>>>AP Preamble Signature >>>>>AP Sub Channel Number >>>VCAM Mapping Information >>>>Min UL Channelisation Code Length >>>>NF_max >>>>Max Number of PCPCHes >>>>SF Request Parameters >>>>>AP Preamble Signature >>>>>AP Sub Channel Number >>>AP-AICH Parameters >>>>Common Physical Channel ID >>>>FDD DL Channelisation Code Number >>>>AP-AICH Power >>>>CSICH Power >>>>STTD Indicator >>>CD/CA-ICH Parameters >>>>Common Physical Channel ID >>>>FDD DL Channelisation Code Number >>>>CD/CA-ICH Power >>>>STTD Indicator
Presence
M O C-CA M
M M
M O
M M
M M M
M M
M M
II. Example
3.2.14 System Information Update Request Message

IE/Group name Message Discriminator Message Type Transaction ID C-ID BCCH Modification Time MIB/SB/SIB Information >IB Type >IB OC ID >CHOICE IB DeletionIndicator >>NoDeletion >>>SIB Originator >>>IB SG REP >>>Segment Information >>>>IB SG POS >>>>Segment type O C CRNCOriginati on >>>>IB SG DATA C CRNCOriginati on >>Deletion C-SIB O M M M M M M M
O
Presence
II. Example
3.3 A Cell Setup Example

This section describes an example of cell setup triggered by the resource status indication procedure, as illustrated in Figure 3-9. In this example, two SCCPCHs and one PRACH are set up in the cell. One SCCPCH bears two FACHs and the other SCCPCH bears two FACHs and one PCH. The PRACH bears one RACH.
Node B
1.NCP:RESOURCE STATUS INDICATION 2. NCP: AUDIT REQUEST 3.NCP: AUDIT RESPONSE 4.NCP: CELL SETUP REQUEST 5.NCP: CELL SETUP RESPONSE
RNC
6.NCP: COMMON TRANSPORT CHANNEL SETUP REQUEST 7.NCP: COMMON TRANSPORT CHANNEL SETUP RESPONSE 8.ALCAP:QAAL2 ESTABLISH REQUEST 9.ALCAP:QAAL2 ESTABLISH CONFIRM 10.NCP: COMMON TRANSPORT CHANNEL SETUP REQUEST 11.NCP: COMMON TRANSPORT CHANNEL SETUP RESPONSE 12.ALCAP:QAAL2 ESTABLISH REQUEST 13.ALCAP:QAAL2 ESTABLISH CONFIRM 14.ALCAP:QAAL2 ESTABLISH REQUEST 15.ALCAP:QAAL2 ESTABLISH CONFIRM 16.ALCAP:QAAL2 ESTABLISH REQUEST 17.ALCAP:QAAL2 ESTABLISH CONFIRM 18.NCP:COMMON TRANSPORT CHANNEL SETUP REQUEST 19.NCP:COMMON TRANSPORT CHANNEL SETUP RESPONSE 20. ALCAP: QAAL2 ESTABLISH REQUEST 21. ALCAP: QAAL2 ESTABLISH CONFIRM 22. ALCAP: QAAL2 ESTABLISH REQUEST 23. ALCAP: QAAL2 ESTABLISH CONFIRM
NodeB
RNC
24. NCP: SYSTEM INFORMATION UPDATE REQUEST 25 NCP: SYSTEM INFORMATION UPDATE RESPONSE
26. NCP: COMM ON M EASUREM ENT INITIATION REQUEST 27. NCP: COMM ON M EASUREM ENT INITIATION RESPONSE 28. NCP: COMM ON M EASUREM ENT INITIATION REQUEST 29. NCP: COMM ON M EASUREM ENT INITIATION RESPONSE 30. NCP: COMM ON M EASUREM ENT INITIATION REQUEST 31. NCP: COMM ON M EASUREM ENT INITIATION RESPONSE 32. NCP: M EASUREM ENT REPORT 33. NCP: M EASUREM ENT REPORT 34. NCP: M EASUREM ENT REPORT
Figure 3-9 Cell setup procedure Each step is explained as follows: 1) The NodeB sends a RESOURCE STATUS INDICATION message to the CRNC. The message may contain the trigger cause and the associated logical resource information. 2) 3) The CRNC sends an AUDIT REQUEST message to the NodeB to initiate the resource audit procedure. The CRNC performs an audit of the configuration and status of the logical resources in the NodeB. It may also re-synchronize its resources with those of the NodeB. After the audit, the NodeB returns an AUDIT RESPONSE message to the CRNC. 4) 5) The CRNC sends a CELL SETUP REQUEST message to the NodeB to initiate a cell setup procedure. The NodeB reserves the necessary resources and configures a new cell according to the parameters in the CELL SETUP REQUEST message. After the
cell setup, the NodeB returns a CELL SETUP RESPONSE message to the CRNC, confirming that the cell is successfully set up. 6) 7) 8) The CRNC sends a COMMON TRANSPORT CHANNEL SETUP REQUEST message to the NodeB, requesting the NodeB to set up a PRACH. The NodeB returns a COMMON TRANSPORT CHANNEL SETUP RESPONSE message, confirming that the common transport channel is successfully set up. The CRNC sends a QAAL2 ESTABLISH REQUEST message to the NodeB using the ALCAP protocol to initiate an Iub interface data transport bearer establishment procedure. The message contains an AAL2 binding identity to bind the Iub interface data transport bearer to the RACH. 9) The NodeB returns a QAAL2 ESTABLISH CONFIRM message to the CRNC as a response. 10) The CRNC sends a COMMON TRANSPORT CHANNEL SETUP REQUEST message to the NodeB, requesting the NodeB to set up an SCCPCH. Here, the SCCPCH bears two FACHs and one PCH. 11) The NodeB returns a COMMON TRANSPORT CHANNEL SETUP RESPONSE message, confirming that the common transport channel is successfully set up. 12) 14) 16) The CRNC sends a QAAL2 ESTABLISH REQUEST message to the NodeB to initiate an Iub interface data transport bearer establishment procedure. This procedure is implemented three times to set up three Iub interface data transport bearers. Each QAAL2 ESTABLISH REQUEST message contains an AAL2 binding identity to bind the corresponding Iub interface data transport bearer to the two FACHs and one PCH. 13) 15) 17) The NodeB returns a QAAL2 ESTABLISH CONFIRM message to the CRNC as a response. Corresponding to the three QAAL2 ESTABLISH REQUEST messages, the NodeB returns three QAAL2 ESTABLISH CONFIRM messages to the CRNC. 18) The CRNC sends a COMMON TRANSPORT CHANNEL SEUTP REQUEST message to the NodeB, requesting the NodeB to set up an SCCPCH. This SCCPCH bears two FACHs. 19) The NodeB returns a COMMON TRANSPORT CHANNEL SETUP RESPONSE message, confirming the successful setup of the common transport channel. 20) 22) The CRNC sends an ALCAP message QAAL2 ESTABLISH REQUEST to the NodeB to initiate an Iub interface data transport bearer establishment procedure. This procedure is implemented two times to set up two Iub interface data transport bearers. Each QAAL2 ESTABLISH REQUEST message contains an AAL2 binding identity to bind the corresponding Iub interface data transport bearer to the two FACHs. 21) 23) The NodeB returns a QAAL2 ESTABLISH CONFIRM message to the CRNC as a response. Corresponding to the two QAAL2 ESTABLISH REQUEST messages, the NodeB returns two QAAL2 ESTABLISH CONFIRM messages to the CRNC.
24) The CRNC sends a SYSTEM INFORMATION UPDATE REQUEST message to the NodeB. 25) The NodeB returns a SYSTEM INFORMATION UPDATE RESPONSE message, confirming the successful update of the system information. 26) 28) 30) The RNC sends a COMMON MEASUREMENT INITIATION REQUEST message to the NodeB. The message is sent three times, requesting for three types of common measurements: Tx carrier power measurement in the form of periodic report, RTWP measurement in the form of periodic report and Tx carrier power measurement in the form of event-E report. 27) 29) 31) Corresponding to the three COMMON MEASUREMENT INITIATION REQUEST messages, the NodeB returns three COMMON MEASUREMENT INITIATION RESPONSE messages, confirming the successful initiation of the common measurement. 32) According to the RNC request, the NodeB periodically sends the Tx carrier power MEASUREMENT REPORT. 33) According to the RNC request, the NodeB periodically sends the RTWP MEASUREMENT REPORT. 34) According the RNC request, the NodeB sends the Tx carrier power MEASUREMENT REPORT only when the event E occurs. So far, the setup of the cell has completed and the UEs can access the network.
Chapter 4 System Information Procedure Analysis

4.1 Overview
System information is broadcasted to the UEs within a cell or the whole PLMN. Its purpose is to provide the UE with the common information of the access stratum and the non-access stratum. In this way, it helps the UE to know the network configuration before initiating a call, thus to choose a proper way to initiate the call. Information of the non-access stratum includes carrier information, CN domain information, and so on. Information of the access stratum includes URA information, cell information, channel information, cell selection/re-selection information, and so on.
4.1.1 System Information Structure

System information includes Master Information Block (MIB), Scheduling Block (SB) and System Information Block (SIB).
SIB
SIB MIB SB SIB
SIB
Figure 4-1 System information structure The three types of system information blocks are organized as a tree as shown in Figure 4-1. Their features and main contents are as follows: The MIB bears scheduling information of a certain number of SIBs or SBs in a cell. A MIB can also contain the PLMN Type (GSM and/or ANSI-41) supported by the cell and the PLMN ID. MIBs are regularly broadcast on a BCH on fixed occasions. Because the BCH is mapped to the PCCPCH, the UEs within the cell can read the content of MIB to know if it is necessary to update or store the system information.
The SB bears scheduling information of other SIBs. The SB is applied when the scheduling resources of the MIB are insufficient. The SIB bears the actual system information, including 18 types of SIBs. The scheduling information of SIB is carried by MIB or SB.
4.1.2 System Information Monitoring Mechanism

A SIB groups together system information elements of the same nature. Dynamic parameters (i.e., system parameters changing frequently) and static parameters (i.e., system parameters less or never changing) are carried by different SIBs. For a SIB containing dynamic parameters (SIB7, SIB8, SIB9, SIB14, and SIB17), the scheduling occasion information is described in the scheduling information included in MIB or SB. The UE regularly reads the SIB on each occasion. A SIB containing static parameters (SIB1SIB6, SIB10SIB3, SIB15, SIB16, and SIB18) is identified by a value tag. A value tag is included in MIB or SB as a part of the scheduling information. The UE checks whether the value tag for a SIB is different from that for the SIB the UE last reads. If so, the UE shall re-read the SIB. Therefore, the UE can know by monitoring the MIB whether a SIB containing static parameters is updated.
4.1.3 Functions of System Information

All SIB types are described as follows: SIB1: includes NAS system information (such as CN information) as well as UE Timers and constants in idle mode and in connected mode. The scope is PLMN. SIB2: includes URA information. SIB3: includes cell selection and re-selection parameters. SIB4: includes cell selection and re-selection parameters of UE in connected mode. SIB5: includes the configuration parameters of cell common physical channel. SIB6: includes the configuration parameters of cell common physical channel and shared physical channel when UE is in connected mode. SIB7: includes rapidly changed parameters (UL interference and dynamic persistence level). SIB8: includes static CPCH information of cell. Only used in FDD. SIB9: includes CPCH information of cell. Only used in FDD. SIB10: includes UE DCH information controlled by DRAC process. Only used in FDD. SIB11: includes measurement control information of cell. SIB12: includes UE measurement control information in connected mode. SIB13: includes ANSI-41 relevant information.
SIB14: includes UL outer loop control parameters of common and dedicated physical channels. Only used in TDD. SIB15: includes information on UE-based or UE-assisted positioning method SIB 16: includes parameters of radio bearer, transport channel and physical channel. These parameters are stored in UE (either in idle mode or in connected mode). It is used when UE is switched to UTRAN. The scope is PLMN. SIB17: includes the rapidly changed parameters used to configure the shared physical channel in connected mode. Only used in TDD. SIB18: includes PLMN identity of neighbor cell.
4.2 System Information Broadcast and Update

4.2.1 System Information Broadcast
The signalling flow of system information broadcast is illustrated in Figure 4-2.
UE
SYSTEM INFORMATION
UTRAN
Figure 4-2 System information broadcast procedure UTRAN sends a SYSTEM INFORMATION message to the UE. The message contains the scheduling information, area scope, system information contents, and so on. The RRC layer in UTRAN performs segmentation and concatenation of encoded system information blocks. If the encoded system information block is larger than the size of a SYSTEM INFORMATION message, it will be segmented and transmitted in several messages. If the encoded system information block is smaller than a SYSTEM INFORMATION message, UTRAN may concatenate several system information blocks, or the first segment or the last segment into the same message. The UE shall read SYSTEM INFORMATION messages broadcast on a BCH transport channel in idle mode and in states CELL_PCH, CELL_FACH and URA_PCH. In idle mode and connected mode different combinations of SIBs are valid. The UE shall acquire the needed system information blocks. The UE may store SIBs for different cells and different PLMNs for later use when the UE returns to these cells or PLMNs.
4.2.2 System Information Update

This section describes a complete system information update signalling procedure, as illustrated in Figure 4-3.
UE NodeB
NBAP NBAP 3. BCCH: SYSTEM INFORMATION RRC 4. BCCH: SYSTEM INFORMATION RRC 1.SYSTEM INFORMATION UPDATE REQUEST 2.SYSTEM INFORMATION UPDATE RESPONSE
CRNC
NBAP NBAP
RRC
RRC
RRC
5. BCCH: SYSTEM INFORMATION
RRC
Figure 4-3 System information update procedure Each step is explained as follows: 1) 2) 3) The RNC sends a NBAP SYSTEM INFORMATION UPDATE REQUEST message to the associated NodeB, requesting for system information broadcast. The NodeB returns a NBAP SYSTEM INFORMATION UPDATE RESPONSE message to the RNC, confirming the system information broadcast. 4) 5) The NodeB sends SYSTEM INFORMATION messages on the air interface.
4.2.3 System Information Message

IE/Group name Message type SFNprime CHOICE Segment combination >Combination 1 >Combination 2 >>First Segment >Combination 3 >>Subsequent Segment MP MP OP CV-channel MP Presence Semantics description
IE/Group name >Combination 4 >>Last segment >Combination 5 >>Last segment >>First Segment >Combination 6 >>Last Segment >>Complete list >>>Complete >Combination 7 >>Last Segment >>Complete list >>>Complete >>First Segment >Combination 8 >>Complete list >>>Complete >Combination 9 >>Complete list >>>Complete >>First Segment >Combination 10 >>>Complete SIB of size 215 to 226 >Combination 11 >>Last segment of size 215 to 222 MP MP MP MP MP MP MP MP MP MP MP MP MP MP MP MP MP
Presence
II. Example
4.3 System Information Modification Notification

There are two ways of notifying a UE of system information modification: by a value tag and by a timer.
4.3.1 Notification by a Value Tag

For SIBs using value tags, UTRAN should notify the new value tag for the MIB to the UE. To notify a UE in idle mode, CELL_PCH state or URA_PCH state, UTRAN sends a PAGING TYPE 1 message on the PCCH on all paging occasions in the cell to transmit the new MIB value tag. To notify a UE in CELL_FACH state, UTRAN sends a SYSTEM INFORMATION CHANGE INDICATION message on the BCCH to transmit the new MIB value tag. Upon reception of the PAGING TYPE 1 message or SYSTEM INFORMATION CHANGE INDICATION message from UTRAN, the UE shall read the changed system information according to the new MIB value tag.
UE
PAGING TYPE 1
UTRAN
Figure 4-4 System information modification procedure (in idle mode, CELL_PCH state, or URA_PCH state)
UE
SYSTEM INFORMATION CHANGE INDICATION
UTRAN
Figure 4-5 System information modification procedure (in CELL_FACH state)
4.3.2 Notification by a Timer

Other types of SIBs have timers respectively. When the timer expires, the UE shall consider the stored system information content invalid, start the timer, and re-acquire new SIB information. The UE may postpone reading the SIB until the content is needed.
4.3.3 Paging Type 1 Message

Refer to section 5.2.4 Paging Type 1 Message.
Chapter 5 Call Setup and Release Procedure Analysis

5.1 Overview
After a UE detects a cell and reads the system information of the cell, it can obtain the configured parameters of the system and thus can access the network. There are two types of call setup procedures. One is implemented when the UE acts as a caller and the other when the UE acts as a callee. The difference between the two procedures is that different parties initiate the call setup request. Whether the UE is a caller or callee, the call setup and release procedure include the following steps: 1) 2) 3) 4) 5) 6) RRC connection setup between UE and UTRAN Signalling connection setup between UE and CN through direct transfer messages UE capacity information query and update RAB setup RAB release and Iu signalling connection release RRC connection release
5.2 Paging
5.2.1 Overview
Paging includes CN originated paging and UTRAN originated paging. The CN originated paging procedure is used to establish a signalling connection. It is divided into co-ordination paging and non co-ordination paging. The CN indicates in the RANAP paging message whether the RNC shall perform the UTRAN co-ordination paging. In the case of co-ordination paging, the RNC shall check whether the UE has other CN domain signalling connections besides the paging domain connection. If so and the UE is in CELL_DCH or CELL_FACH state, the paging message shall be transmitted on the already connected DCCH on the radio interface. If so and the UE is in CELL_FACH or URA_PCH state, the paging message shall be transmitted on the PCCH on the radio interface. If no, the paging message shall be transmitted on the PCCH. In the case of non co-ordination paging, the RNC need not check whether the UE has other CN domain signalling connections besides the paging domain
connection but directly transmit the paging message on the PCCH in the CN specified paging area. The UTRAN may initiate paging for a UE in CELL_PCH or URA_PCH state to trigger a cell update procedure to enable the transition to CELL_FACH state. In addition, the UTRAN may initiate paging for a UE to trigger reading of updated system information. For a UE in idle mode or in CELL_PCH or URA_PCH state, the RNC initiates the paging procedure by transmitting a PAGING TYPE 1 message on the PCCH. For a UE in CELL_FACH or CELL_DCH state, the RNC initiates the paging procedure by transmitting a PAGING TYPE 2 message on the DCCH.
5.2.2 Paging for UE in Idle Mode or in PCH State

The UTRAN usually pages a UE in idle mode or in CELL_PCH or URA_PCH state by transmitting a PAGING TYPE 1 message on the PCCH. Such paging procedure generally occurs on the following occasions: When the upper layer in the network initiates paging to set up a call or a signalling connection; When the UTRAN initiates paging for a UE in CELL_PCH or URA_PCH state to trigger a cell update procedure to enable the transition to CELL_FACH state; When the UTRAN initiates paging for a UE to trigger reading of updated system information. In this case, the value tag of the MIB is included in the [BCCH modification info] IE in the PAGING TYPE 1 message. Figure 5-1 illustrates the paging procedure.
UE
PAGING TYPE 1
UTRAN
Figure 5-1 Paging for UE in idle mode or in PCH state The UTRAN initiates the paging procedure by transmitting a PAGING TYPE 1 message on an appropriate paging occasion on the PCCH. The UTRAN may repeat the transmission of a PAGING TYPE 1 message to a UE on several paging occasions to increase the probability of proper reception of a page. The UE in idle mode and in PCH state receive the paging information from the network layer on appropriate paging occasions.
5.2.3 Paging for UE in CELL_DCH or CELL_FACH State

The UTRAN usually pages a UE in CELL_DCH or CELL_FACH state by transmitting a PAGING TYPE 2 message on the DCCH. Figure 5-2 illustrates the signalling procedure.
UE
PAGING TYPE 2
UTRAN
Figure 5-2 Paging for UE in CELL_DCH or CELL_FACH state
The UTRAN initiates the paging procedure by transmitting a PAGING TYPE 2 message on the DCCH. Such paging procedure is also called dedicated paging procedure. The UE receives and reads the PAGING TYPE 2 message and forwards the [Paging cause] IE and the [Paging record type identifier] IE to the NAS. The paging procedure ends. This procedure shall not affect the state of any other ongoing RRC procedure at the UE. If the UE receives a PAGING TYPE 2 message which contains a protocol error, the UE shall discard that paging message and transmit an RRC STATUS message on the uplink DCCH using AM RLC.

IE/Group name Presence Semantics description
Message Type
UE information elements
MP
Paging record list >Paging record

Other information elements
OP MP
BCCH modification info
OP
II. Example

Message Type
MP
RRC transaction identifier Integrity check info Paging cause

CN information elements
MP CH MP
CN domain identity Paging Record Type Identifier
MP MP
II. Example
5.3 RRC Connection Setup

5.3.1 Overview
A UE in idle mode shall initiate an RRC connection setup procedure when the NAS of the UE requests the establishment of a signalling connection. After receiving an RRC CONNECTION REQUEST message from the UE, the RNC shall determine according to a specific algorithm whether to accept or reject the RRC connection request. If accepting the request, the RNC shall then determine whether to set up the RRC connection on a dedicated channel (DCH) or a common channel (CCH). On different channels, the RRC connection setup procedures are different.
Note:
RRC connection setup is always initiated by the UE and RRC connection release by the RNC. Each UE has at most one RRC connection.
5.3.2 RRC Connection Setup on DCH

The RNC shall allocate dedicated radio resources to the UE and set up a radio link and an Iub interface ALCAP user plane transport bearer for the radio link when an RRC connection is set up on a dedicated channel. Figure 5-3 illustrates the RRC connection setup signalling procedure on a dedicated channel.
UE
1.CCCH : RRC CONNECTION REQUEST RRC
NodeB
RNC
RRC
2.Allocate parameters such asRNTIL1 L2 3. RADIO LINK SETUP REQUEST NBAP 4. RADIO LINK SETUP RESPONSE NBAP NBAP NBAP
5.ALCAP Setup and synchronization

6. CCCH : RRC CONNECTION SETUP RRC 7. DCCH: RRC CONNECTION SETUP COMPLETE RRC RRC RRC
Figure 5-3 RRC connection setup procedure (on DCH)
Each step is explained as follows: 1) 2) The UE sends an RRC CONNECTION REQUEST message on the uplink CCCH, requesting for the establishment of an RRC connection. The RNC determines, according to the cause in the RRC connection request and the system resource status, to set up the RRC connection on a dedicated channel and allocates the RNTI, radio resources and other resources (L1 and L2 resources). 3) The RNC sends a RADIO LINK SETUP REQUEST message to the NodeB, requesting the NodeB to allocate the specific radio link resources required for an RRC connection. 4) The NodeB responds with a RADIO LINK SETUP RESPONSE message to the RNC after successfully preparing the resources.
5) 6)
The RNC sets up the Iub interface user plane transport bearer using ALCAP and performs the NodeB synchronization procedure. The RNC sends an RRC CONNECTION SETUP message to the UE on the downlink CCCH. The message contains the information about the dedicated channel allocated by the RNC.
7)
The UE sends an RRC CONNECTION SETUP COMPLETE message on the just established uplink DCCH after confirming that the RRC connection is successfully set up. The RRC connection setup procedure ends.
5.3.3 RRC Connection Setup on CCH

Since the UE uses the common resources already established in a cell when the RRC connection is set up on a common channel, the UE need only map its logical channel onto a common channel in the cell rather than set up a radio link and a user plane data transport bearer. Other procedures are similar to those used for RRC connection setup on a dedicated channel. Figure 5-4 illustrates the RRC connection setup signalling procedure on a common channel.
UE
C 1. CCH : RRC CONNECTION REQUEST RRC RRC
NodeB
RNC
2.Allocate parameters such as RNTIL1 L2 3.Map the logical channels used by UE to the common channels
4.CCCH: :RRC CONNECTION SETUP RRC 5. DCCH: RRC CONNECTION SETUP COMPLETE RRC RRC RRC
Figure 5-4 RRC connection setup procedure (on CCH)
5.3.4 RRC Connection Reject

If the RNC judges that the RRC connection request cannot be set up (for instance, due to insufficient resources), it directly sends an RRC CONNECTION REJECT message to the UE, and indicates the reject reason in the message.
UE
RNC
CCCH:RRC CONNECTION REQUEST
CCCH:RRC CONNECTION REJECT
Figure 5-5 RRC connection reject procedure
5.3.5 RRC Connection Request Message

Message Type
MP
Initial UE identity
MP
Initial UE identity , such as IMSI(P-TMSI), LAI,RAI
Establishment cause
MP
RRC establishment cause, including: Originating Conversational Call, Originating Streaming Call, Originating Interactive Call, Originating Background Call, Originating Subscribed traffic Call, Terminating Conversational Call, Terminating Streaming Call, Terminating Interactive Call, Terminating Background Call, Emergency Call, Inter-RAT cell re-selection, Inter-RAT cell change order,
IE/Group name
Presence
Registration, Detach, Originating High Priority Signalling, Originating Low Priority Signalling, Call re-establishment, Terminating High Priority Signalling, Terminating Low Priority Signalling, Terminating cause unknown Protocol error indicator
Measurement information elements
MD
Measured results on RACH
OP
II. Example
5.3.6 RRC Connection Setup Message

Message Type
MP
Initial UE identity
MP
Initial UE identity, such as IMSI(P-TMSI), LAI and RAI
RRC transaction identifier Activation time
MP MD Activation time defines the exact starting time point of the operation caused by the message. The range is 0255 (CFN)
New U-RNTI New C-RNTI RRC State Indicator
MP OP MP
RRC state indicator: CELL_DCH, CELL_FACH, CELL_PCH, URA_PCH
UTRAN DRX cycle length coefficient Capability update requirement

RB information elements
MP
MD
Signalling RB information to setup list >Signalling RB information to setup
MP
MP
SRB information, including SRB identity, RB mapping information and so on
TrCH information elements Uplink transport channels
UL Transport channel information common for all transport channels
OP
Including the messages like TFC message and so on
IE/Group name
Presence
Added or Reconfigured TrCH information list >Added or Reconfigured UL TrCH information

Downlink transport channels
MP
MP
DL Transport channel information common for all transport channels Added or Reconfigured TrCH information list >Added or Reconfigured DL TrCH information
PhyCH information elements
OP
MP
MP
Frequency info
Uplink radio resources
MD
Maximum allowed UL TX power CHOICE channel requirement >Uplink DPCH info >CPCH SET Info
Downlink radio resources
MD OP
Downlink information common for all radio links Downlink information per radio link list >Downlink information for each radio link
OP
OP
MP
II. Example
5.3.7 RRC Connection Reject Message

Message Type
MP
RRC transaction identifier Initial UE identity Rejection cause
MP MP MP
RRC Rejection cause, including congestion or unspecified
Wait time
MP
Indicate the time that the UE needs to wait to re-send the RRC connection request
Redirection info
OP
Indicate the UE initiates the connection request in other frequencies or systems.
II. Example
None
5.3.8 Radio Link Setup Request Message

Message Discriminator Message Type CRNC Communication Context ID Transaction ID

UL DPCH information
M M M
>UL Scrambling Code
UL scrambling code of UE
IE/Group name
Presence
>Min UL Channelisation Code length >Max Number of UL DPDCHs
C CodeLen
>puncture Limit >TFCS >UL DPCCH Slot Format > UL SIR Target >Diversity mode >SSDT cell ID Length >S Field Length
DL DPCH information
M M M M M O C-FBI
>TFCS >DL DPCH Slot Format >TFCI signalling mode >TFCI presence >Multiplexing Position >PDSCH RL ID >PDSCH code mapping
>Power offset information
M M M C-SlotFormat M C-DSCH C-DSCH
>>PO1 >>PO2 >>PO3 >FDD TPC DL Step Size >Limited Power Increase >Inner Loop DL PC Status
M M M M M M
IE/Group name
Presence
DCH Information DSCH Information

TFCI2 bearer information
M O
>ToAWS >ToAWE
RL information
M M
>RL ID >C-ID >First RLS Indicator >Frame Offset >Chip Offset >Propagation Delay >Diversity Control Field
M M M M M O C NotFirstRL
>DL Code Information >Initial DL transmission Power >Maximum DL power >Minimum DL power >SSDT Cell Identity >Transmit Diversity Indicator
M M M M O C Diversity mode
Transmission Gap Pattern Sequence Information Active Pattern Sequence Information
II. Example
5.4 Direct Transfer

5.4.1 Overview
Direct transfer messages are used to exchange between UE and CN the NAS information such as authentication, service request, and connection setup information. Such messages are transparently transported in the RNC, and therefore called direct transfer messages. The RRC connection is only a signalling connection between the UE and the RNC. A signalling connection shall also be set up between the UE and the CN to transport direct transfer messages. The RNC shall set up the signalling connection to the CN on the SCCP when it receives the first direct transfer message, that is, INITIAL DIRECT TRANSFER message. When the signalling connection is successfully set up, a message from the UE to the CN shall be sent in this way: The UE sends an UPLINK DIRECT TRANSFER message to the RNC and the RNC converts the message to a DIRECT TRANSFER message and forwards it to the CN. A message from the CN to the UE shall be sent in this way: The CN sends a DIRECT TRANSFER message to the RNC and the RNC converts the message to a DOWNLINK DIRECT TRANSFER message and forwards it to the UE.
5.4.2 Initial Direct Transfer

The initial direct transfer procedure is used to establish a signalling connection. It is also used to carry initial NAS information from UE to CN. The NAS information is not interpreted in the RNC and is transferred to the CN directly.
Note:
Before initial direct transfer, the UE in CELL_PCH or URA_PCH state shall perform a cell update procedure using the cause "uplink data transmission" to transit to the CELL_FACH state. When the cell update procedure completes successfully, the UE shall continue with the initial direct transfer procedure.
Figure 5-6 illustrates the initial direct transfer signalling procedure.
UE
1. INITIAL DIRECT TRANSFER RRC
SRNC
RRC
CN
2.INITIAL UE MESSAGE RANAP RANAP 3.CONNECITON CONFIRMSUCCESS SCCP 4.CONNECTION REFUSEFAILURE SCCP SCCP SCCP
Figure 5-6 Initial direct transfer procedure
Each step is explained as follows: 1) After the RRC connection is set up, the UE sends an INITIAL DIRECT TRANSFER message to the RNC. The message shall contain the initial NAS information and CN domain identity the UE wants to send to the CN. 2) After receiving the INITIAL DIRECT TRANSFER message from the UE, the RNC sends an INITIAL UE MESSAGE to the CN on the Iu interface as a Connection Request (CR) for SCCP connection establishment. The message shall contain the message the UE sends to the CN. 3) The CN shall return a CONNECTION CONFIRM message to the RNC if it determines to accept the connection request and the SCCP connection is successfully set up. Upon reception of the message, the RNC confirms that the connection is successfully set up. 4) The CN shall return a CONNECTION REFUSE message to the RNC if it determines to refuse the connection request and the SCCP connection setup fails. Upon reception of the message, the RNC confirms that the connection setup fails and initiates an RRC release procedure. The initial direct transfer procedure ends. For the NAS information contained in INITIAL DIRECT TRANSFER and INITIAL UE MESSAGE, the CN shall send the acceptance or reject information to the UE by the downlink transfer procedure.
5.4.3 Uplink Direct Transfer

The UE shall initiate an uplink direct transfer procedure when it need send NAS information to the CN on an already existing signalling connection.
Note:
Before uplink direct transfer, the UE in CELL_PCH or URA_PCH state shall perform a cell update procedure using the cause "uplink data transmission" to transit to the CELL_FACH state. When the cell update procedure completes successfully, the UE shall continue with the uplink direct transfer procedure.
Figure 5-7 illustrates the uplink direct transfer signalling procedure.
UE
1. UPLINK DIRECT TRANSFER RRC
SRNC
RRC
CN
2.DIRECT TRANSFER RANAP RANAP
Figure 5-7 Uplink direct transfer procedure
Each step is explained as follows: 1) The UE sends an UPLINK DIRECT TRANSFER message to the RNC to initiate an uplink direct transfer procedure. The message shall contain the NAS information and CN domain identity. 2) On reception of the UPLINK DIRECT TRANSFER message, the RNC shall send a DIRECT TRANSFER message on the Iu interface to the CN according to the CN domain identity so as to route the NAS information to the CN.
Note:
If the UPLINK DIRECT TRANSFER message includes the [Measured results on RACH] IE, it indicates the message carries a measurement report. The UTRAN shall resolve the corresponding content for radio resource control, and send the rest of the message to the CN.
5.4.4 Downlink Direct Transfer

The CN shall initiate a downlink direct transfer procedure when it need send NAS information to the UE on an already existing signalling connection.
Figure 5-8 illustrates the downlink direct transfer signalling procedure.

UE SRNC
1.DIRECT TRANSFER RANAP RANAP
CN
2. DOWNLINK DIRECT TRANSFER RRC RRC
Figure 5-8 Downlink direct transfer procedure
Each step is explained as follows: 1) 2) The CN sends a DIRECT TRANSFER message to the RNC to initiate a downlink direct transfer procedure. The message shall contain the NAS information. The UTRAN sends a DOWNLINK DIRECT TRANSFER message on the downlink DCCH using AM RLC. The message shall contain the NAS information and CN domain identity the CN wants to send to the US. The UE receives and reads the NAS information contained in the DOWNLINK DIRECT TRANSFER message. If the UE receives a DOWNLINK DIRECT TRANSFER message which contains a protocol error, the UE shall transmit an RRC STATUS message on the uplink DCCH using AM RLC. The downlink direct transfer procedure ends.
5.4.5 Initial Direct Transfer Message

Message Type
MP
Integrity check info

CH
CN domain identity Intra Domain NAS Node Selector NAS message

Measurement information
MP MP MP
IE/Group name elements
Presence
OP
II. Example
5.4.6 Uplink Direct Transfer Message

Message Type
MP
Integrity check info

CH
IE/Group name
Presence
CN domain identity NAS message

Measurement information elements
MP MP
OP
II. Example
5.4.7 Downlink Direct Transfer Message

Message Type
MP
RRC transaction identifier Integrity check info
MP CH
IE/Group name CN information elements
Presence
CN Domain Identity NAS message
MP MP
II. Example
5.5 UE Capability Information Enquiry and Update

UE capability information includes the information about security capability, location capability, measurement capability, physical channel capability, transport channel capability, and so on. UEs have different capabilities due to different manufacturers and specifications. Therefore, a UE shall transmit the UE capability information to the UTRAN after an RRC connection setup. Thus, the network can perform configuration for the UE according to the supported capability parameters. The UE capability information can be transmitted in the following three ways: When the RRC connection is successfully set up, the UE capability information is transmitted to the RNC through an RRC CONNECTION SETUP COMPLETE message.
When the RRC connection is successfully set up, the RNC sends a UE CAPABILITY ENQUIRY message to the UE if it finds the capability information does not exist. The UE returns a UE CAPABILITY INFORMATION message containing the UE capability information. When the UE capability information changes during the RRC connection setup procedure, the UE transmits the updated UE capability information to the RNC through a UE CAPABILITY INFORMATION message.
5.5.1 UE Capability Enquiry

The UTRAN may request the UE to initiate a UE capability enquiry procedure by transmitting a UE CAPABILITY ENQUIRY message to the UE, as illustrated in Figure 5-9.
UE
UE CAPABILITY ENQUIRY
UTRAN
Figure 5-9 UE capability enquiry procedure
The UE capability enquiry procedure is initiated by the UTRAN by transmitting a UE CAPABILITY ENQUIRY message on the downlink DCCH using AM RLC.
5.5.2 UE Capability Information Update

When the UTRAN initiates a UE capability enquiry procedure or when the UE capability information changes during the RRC connection setup procedure, the UE shall initiate a UE capability information update procedure. This procedure sends the UTRAN the radio network related capability information the UE can support, as illustrated in Figure 5-10.
Figure 5-10 UE capability information update procedure

1) 2)
The UE sends a UE CAPABILITY INFORMATION message on the uplink DCCH using AM or UM RLC. The message shall contain the UE capability information. The UTRAN reads the UE capability information and returns a UE CAPABILITY INFORMATION CONFIRM message on the downlink DCCH using AM or UM RLC. The UE capability information update procedure ends.
5.6 RAB Setup

5.6.1 Overview
Radio access bearer (RAB) is a user plane bearer. It is used to convey the service information like speech, data and multimedia information between UE and CN. The RAB setup procedure shall only be implemented after the signalling connection is successfully set up between the UE and the CN. This procedure is initiated by the CN and implemented by the UTRAN. The RAB setup procedure is as follows: 1) 2) 3) The CN initiates an RAB ASSIGNMENT REQUEST message. The RNC configures the relevant radio network parameters according to the QoS parameter in the RAB ASSIGNMENT REQUEST message. The RNC informs the setup result to the CN through the RAB ASSIGNMENT RESPONSE message.
Note:
The RAB ASSIGNMENT REQUEST message is initiated by the CN. Each UE can have one or more RABs.
The RAB setup procedure can adopt the following three modes according to the RRC connection status before and after the RAB setup: DCH-DCH: The RRC connection is on a DCH before the RAB setup and also on a DCH after the RAB setup. CCH-DCH: The RRC connection is on a CCH before the RAB setup and on a DCH after the RAB setup. CCH-CCH: The RRC connection is on a CCH before the RAB setup and also on a CCH after the RAB setup.
5.6.2 DCH-DCH
When the RRC connection of the UE is on a DCH, the assigned RAB can only be set up on the DCH. The RAB setup procedure can be implemented through the following two ways according to the radio link reconfiguration situation:
Synchronous radio link reconfiguration Asynchronous radio link reconfiguration The difference is that in the former the NodeB and UE cannot invoke the reconfiguration parameters immediately after they receive the configuration messages from the SRNC while in the latter they can.
I. Synchronous Radio Link Reconfiguration

In this case, the SRNC, NodeB and UE shall synchronously perform radio link reconfiguration. The synchronization procedure is given below: The NodeB shall not invoke the reconfiguration parameters immediately after it receives a RADIO LINK RECONFIGURATION PREPARE message but prepare for the radio resources required. Then it shall wait till it receives a RADIO LINK RECONFIGURATION COMMIT message from the SRNC and obtains the synchronization time specified by the SRNC in the message. The UE shall also not invoke the reconfiguration parameters immediately after it receives a RADIO BEARER SETUP message but obtain the synchronization time specified by the SRNC in the message. The NodeB and UE shall invoke the reconfiguration parameters at the synchronization time specified by the SRNC. Figure 5-11 illustrates the DCH-DCH RAB setup procedure in the case of synchronous radio link reconfiguration.
UE NodeB SRNC
1. RAB ASSIGNMENT REQUEST RANAP 2.ALCAP setup 3. RADIO LINK RECONFIGURATION PREPARE (Synchronised) NBAP NBAP 4. RADIO LINK RECONFIGURATION READY (Synchronised) NBAP NBAP RANAP
CN
5.ALCAP Setup and synchronization 6. RADIO BEARER SETUP RRC RRC 7. RADIO LINK RECONFIGURATION COMMIT (Synchronised) NBAP
NBAP RRC
8. RADIO BEARER SETUP COMPLETE RRC 9. RAB ASSIGNMENT RESPONSE RANAP RANAP
Figure 5-11 RAB setup procedure (DCH-DCH, synchronous)
Each step is explained as follows:

1) 2)
The CN sends an RAB ASSIGNMENT REQUEST message to the UTRAN to initiate an RAB setup procedure. Upon reception of the RAB ASSIGNMENT REQUEST message, the SRNC shall map the QoS parameter for the RAB to the AAL2 link characteristic parameter and radio resource characteristic parameter. The ALCAP on the Iu interface shall initiate an Iu interface user plane transport bearer setup procedure according to the AAL2 link characteristic parameter (as for PS domain, the ALCAP step does not exist).
3)
The SRNC sends a RADIO LINK RECONFIGURATION PREPARE message to the controlled NodeB, requesting the NodeB to prepare for adding one or more DCHs to the existing radio link for bearing the RAB.
4)
The NodeB allocates the corresponding resources and returns a RADIO LINK RECONFIGURATION READY message to the SRNC it belongs to, informing it that the radio link reconfiguration is ready.
5)
The ALCAP on the Iub interface at the SRNC initiates an Iub interface user plane transport bearer setup procedure. The NodeB and the SRNC perform synchronization by exchanging the uplink & downlink synchronization frames in the DCH frame protocol.
6) 7) 8) 9)
The SRNC sends an RRC message RADIO BEARER SETUP to the UE. The SRNC sends a RADIO LINK RECONFIGURATION COMMIT message to the controlled NodeB. After performing radio bearer setup, the UE sends a RADIO BEARER SETUP COMPLETE message to the SRNC. Upon reception of the RADIO BEARER SETUP COMPLETE message, the SRNC sends an RAB ASSIGNMENT RESPONSE message to the CN. The RAB setup procedure ends.
II. Asynchronous Radio Link Reconfiguration

In this case, the SRNC, NodeB and UE need not synchronously perform radio link reconfiguration. The NodeB and UE shall invoke the reconfiguration parameters immediately after they receive the configuration messages from the SRNC. Figure 5-12 illustrates the DCH-DCH RAB setup procedure in the case of asynchronous radio link reconfiguration.

CN
1. RAB ASSIGNMENT REQUEST RANAP RANAP
UE
NodeB
SRNC
2.ALCAP setup 3. RADIO LINK RECONFIGURATION REQUEST NBAP 4. RADIO LINK RECONFIGURATION RESPONSE NBAP NBAP
NBAP
5.ALCAP Setup and synchronization
6. RADIO BEARER SETUP RRC 7. RADIO BEARER SETUP COMPLETE RRC RRC 8. RAB ASSIGNMENT RESPONSE RANAP RANAP RRC
Figure 5-12 RAB setup procedure (DCH-DCH, asynchronous)
Each step is explained as follows: 1) 2) The CN sends a RANAP message RAB ASSIGNMENT REQUEST to the SRNC to initiate an RAB setup procedure. Upon reception of the RAB ASSIGNMENT REQUEST message, the SRNC shall map the QoS parameter for the RAB to the AAL2 link characteristic parameter and radio resource characteristic parameter. The ALCAP on the Iu interface shall initiate an Iu interface user plane transport bearer setup procedure according to the AAL2 link characteristic parameter (as for PS domain, the ALCAP step does not exist). 3) The SRNC sends an NBAP message RADIO LINK RECONFIGURATION REQUEST to the controlled NodeB, requesting the NodeB to reconfigure the DCH in the existing radio link. 4) Upon reception of the RADIO LINK RECONFIGURATION REQUEST message, the NodeB allocates the corresponding resources and returns a RADIO LINK RECONFIGURATION RESPONSE message to the SRNC it belongs to, informing the SRNC that it finishes radio link reconfiguration. 5) The ALCAP on the Iub interface at the SRNC initiates an Iub interface user plane transport bearer setup procedure. The NodeB and the SRNC perform synchronization by exchanging the uplink & downlink synchronization frames in the DCH frame protocol. 6) The SRNC sends an RRC message RADIO BEARER SETUP to the UE.
7) 8)
After performing radio bearer setup, the UE sends a RADIO BEARER SETUP COMPLETE message to the SRNC Upon reception of the RADIO BEARER SETUP COMPLETE message, the SRNC sends an RAB ASSIGNMENT RESPONSE message to the CN. The RAB setup procedure ends.
5.6.3 CCH-DCH
When the RRC connection is on a CCH, the RNC can set up the assigned RAB on a DCH according to the QoS parameter in the RAB ASSIGNMENT REQUEST message. The RRC connection status shall transit from the CCH to the DCH state. Figure 5-13 illustrates the CCH-DCH RAB setup procedure.
UE NodeB SRNC
1. RABASSIGNMENT REQUEST RANAP RANAP
CN
2. ALCAP setup 3. NBAP 4. NBAP RADIO LINK SETUP RESPONSE NBAP RADIO LINK SETUP REQUEST NBAP
5.ALCAP Setup and synchronization 6. RADIO BEARER SETUP RRC 7. RADIO BEARER SETUP COMPLETE RRC RRC 8. RAB ASSIGNMENT RESPONSE RANAP RANAP RRC
Figure 5-13 RAB setup procedure (CCH-DCH)
Each step is explained as follows: 1) 2) The CN sends a RANAP message RAB ASSIGNMENT REQUEST to the SRNC to initiate an RAB setup procedure. Upon reception of the RAB ASSIGNMENT REQUEST message, the SRNC shall map the QoS parameter for the RAB to the AAL2 link characteristic parameter and radio resource characteristic parameter. The ALCAP on the Iu interface shall initiate an Iu interface user plane transport bearer setup procedure according to the AAL2 link characteristic parameter (as for PS domain, the ALCAP step does not exist).
3)
The SRNC initiates an Iub interface radio link setup procedure by sending a RADIO LINK SETUP REQUEST message to the controlled NodeB, requesting the NodeB to allocate the specific radio link resources for the RRC connection.
4) 5) 6) 7) 8)
After preparing the resources, the NodeB returns a RADIO LINK SETUP RESPONSE message to the RNC. The RNC sets up an Iub interface user plane transport bearer using ALCAP and performs the NodeB synchronization procedure. The SRNC sends an RRC message RADIO BEARER SETUP to the UE. After performing radio bearer setup, the UE sends a RADIO BEARER SETUP COMPLETE message to the SRNC. Upon reception of the RADIO BEARER SETUP COMPLETE message, the SRNC sends an RAB ASSIGNMENT RESPONSE message to the CN. The RAB setup procedure ends.
5.6.4 CCH-CCH
When the RRC connection is on a CCH, the RNC can set up the assigned RAB on a CCH according to the QoS parameter in the RAB ASSIGNMENT REQUEST message. Figure 5-14 illustrates the CCH-CCH RAB setup procedure.
UE NodeB SRNC
1. RAB ASSIGNMENT REQUEST
CN
RANAP
RANAP
2. ALCAP setup 3. RADIO BEARER SETUP RRC 4. RADIO BEARER SETUP COMPLETE RRC 5. RAB ASSIGNMENT RESPONSE RANAP RANAP RRC
RRC
Figure 5-14 RAB setup procedure (CCH-CCH)
Each step is explained as follows: 1) 2) The CN sends a RANAP message RAB ASSIGNMENT REQUEST to the UTRAN to initiate an RAB setup procedure. Upon reception of the RAB ASSIGNMENT REQUEST message, the SRNC shall map the QoS parameter for the RAB to the AAL2 link characteristic parameter and radio resource characteristic parameter. The ALCAP on the Iu interface shall initiate an Iu interface user plane transport bearer setup procedure according to
the AAL2 link characteristic parameter (as for PS domain, the ALCAP step does not exist). 3) 4) 5) The SRNC sends an RRC message RADIO BEARER SETUP to the UE. After performing radio bearer setup, the UE sends a RADIO BEARER SETUP COMPLETE message to the SRNC. Upon reception of the RADIO BEARER SETUP COMPLETE message, the SRNC sends an RAB ASSIGNMENT RESPONSE message to the CN. The RAB setup procedure ends.
5.6.5 RAB Assignment Request Message

Message Type
RABs To Be Setup Or Modified List
M C ifNoOtherGroup
>RABs To Be Setup Or Modified Item IEs >>First Setup Or Modify Item
M M C-ifModifandNAS InfoProvided
>>>RAB ID >>>NAS Synchronisation Indicator
>>>RAB Parameters
CifSetuporNewVal ues
>>>User Plane Information
CifSetuporNewVal ues
>>>>User Plane Mode >>>>UP Mode Versions

>>>Transport Layer Information
M M C- ifNot OnlyNSI M M
>>>>Transport Layer Address >>>>Iu Transport Association
IE/Group name
Presence
>>>Service Handover
>>Second Setup Or Modify Item
O M C ifPSandSetup C ifPSandSetup
>>> PDP Type Information >>>Data Volume Reporting Indication >>>DL GTP-PDU Sequence Number
CifAvailPSandSetu p
>>>UL GTP-PDU Sequence Number
CifAvailPSandSetu p
>>>DL N-PDU Sequence Number
CifAvailPSandSetu p
>>>UL N-PDU Sequence Number
CifAvailPSandSetu p
RABs To Be Released List
C ifNoOtherGroup
>RABs To Be Released Item IEs
>>RAB ID >>Cause
M M
Release cause
II. Example
5.6.6 RAB Assignment Response Message

Message Type
RABs Setup Or Modified LIST
M
CifNoOtherGroup
>RABs Setup Or Modified Item IEs
>>RAB ID >>Transport Layer Address >>Iu Transport Association

>>DL Data Volumes >>>Data Volume List
M C - ifPS C - ifPS C ifModReqPS
>>>>Unsuccessfully Transmitted DL Data Volume >>>>Data Volume Reference

RABs Released List
O C ifNoOtherGroup
>RABs Released Item IEs
>>RAB ID
>>DL Data Volumes >>>Data Volume List
M C ifReqPS
>>>>Unsuccessfully Transmitted DL Data Volume >>>>Data Volume Reference >>DL GTP-PDU Sequence Number >>UL GTP-PDU Sequence Number
RABs Queued List
O C-ifAvailUiPS C-ifAvailUiPS C ifNoOtherGroup
IE/Group name
Presence
>RABs Queued Item IEs
>>RAB ID
RABs Failed To Setup Or Modify List >RABs Failed To Setup Or Modify Item IEs
M C ifNoOtherGroup
>>RAB ID >>Cause
RABs Failed To Release List
M M C ifNoOtherGroup
>RABs Failed To Release Item IEs
>>RAB ID >>Cause Criticality Diagnostics
M M O
II. Example
5.6.7 Radio Bearer Setup Message

Message Type
MP
IE/Group name
Presence
RRC transaction identifier Integrity check info Integrity protection mode info Ciphering mode info Activation time New U-RNTI New C-RNTI RRC State Indicator UTRAN DRX cycle length coefficient
MP CH OP OP MD OP OP MP MD
CN Information info
UTRAN mobility information elements
OP
URA identity
RB information elements
OP
Signalling RB information to setup list >Signalling RB information to setup RAB information to setup list >RAB information for setup RB information to be affected list >RB information to be affected Downlink counter synchronisation info >RB with PDCP information list >>RB with PDCP information
TrCH information elements
OP MP OP MP OP MP OP OP MP
IE/Group name
Presence
Uplink transport channels
UL Transport channel information common for all transport channels Deleted TrCH information list >Deleted UL TrCH information Added or Reconfigured TrCH information list >Added or Reconfigured UL TrCH information CHOICE mode >FDD >>CPCH set ID >>Added or Reconfigured TrCH information for DRAC list >>>DRAC static information >TDD
Downlink transport channels
OP
OP MP OP
MP
OP
OP OP
MP
DL Transport channel information common for all transport channels Deleted TrCH information list >Deleted DL TrCH information Added or Reconfigured TrCH information list >Added or Reconfigured DL TrCH information
PhyCH information elements
OP
OP MP OP
MP
Frequency info
Uplink radio resources
MD
IE/Group name
Presence
Maximum allowed UL TX power CHOICE channel requirement >Uplink DPCH info >CPCH SET Info
Downlink radio resources
MD OP
CHOICE mode >FDD >>Downlink PDSCH information >TDD Downlink information common for all radio links Downlink information per radio link list >Downlink information for each radio link
MP
OP
OP
OP MP
II. Example
5.7 Call Release

5.7.1 Overview
There are two types of call release procedures. One is implemented when the UE initiates an upper layer call release request and the other when the CN initiates an upper layer call release request. The resource release procedures in the two cases are both initiated by the CN. For a UE, the RRC connection might correspond to several RABs (such as for Video Phone (VP) service and Web Browse service at the same time); both CS domain and PS domain might correspond to one Iu signalling connection respectively. The service release is described as follows:
I. CS Domain Service Release

If the CS domain has only one RAB, the CN initiates an IU RELEASE COMMAND message. After the RNC receives the message, it automatically releases the Iu signalling connection and the RAB. Refer to section 5.7.4 Combined CS Domain Iu and RAB for details. After the service release completes, the SRNC checks whether the RRC connection still has corresponding Iu signalling connection (in the PS domain). If no, it initiates the RRC connection release procedure. If the CS domain has several RABs, the CN initiates the RAB release procedure only for the RABs to be released. It does not release the Iu signalling connection. Refer to section 5.7.3 RAB Release for details.
II. PS Domain Service Release

If the PS domain has only one RAB, the CN first initiates the RAB release procedure to this RAB. Then it sends an IU RELEASE COMMAND message to release the Iu signalling connection on the Iu-PS interface. Refer to section 5.7.3 RAB Release and section 5.7.2 Iu Signalling Connection Release for details. After the service release completes, the SRNC checks whether the RRC connection still has corresponding Iu signalling connection (in the CS domain). If no, it initiates the RRC connection release procedure. If the PS domain has several RABs, the CN initiates the RAB release procedure only for the RABs to be released. It does not release the Iu signalling connection. Refer to section 5.7.3 RAB Release for details.
5.7.2 Iu Signalling Connection Release

I. Iu Signalling Connection Release Request
The Iu signalling connection release request procedure is used by the UTRAN to request the CN to initiate an Iu signalling connection release procedure. Generally, the
CN initiates the Iu signalling connection release procedure. The UTRAN may also request the CN to initiate the release procedure. Figure 5-15 illustrates the Iu signalling connection release request procedure. RNC
IU RELEASE REQUEST
CN
Figure 5-15 Iu signalling connection release request procedure
The SRNC sends an IU RELEASE REQUEST message to the CN domain to initiate an Iu interface release request procedure. The message shall contain the cause for the Iu connection release request. The CN determines how to respond to the Iu release request. For example, the CN may initiate an Iu release procedure if it determines to release the Iu connection.
II. Iu Signalling Connection Release

The Iu signalling connection release procedure is used by the CN to release an Iu connection. All the related UTRAN resources shall be released. Figure 5-16 illustrates the Iu signalling connection release procedure.
RNC
1.IU RELEASE COMMAND 2.IU RELEASE COMPLETE
CN
Figure 5-16 Iu signalling connection release procedure
1)
The CN sends an IU RELEASE COMMAND to the UTRAN to initiate a signalling connection release procedure. The message shall contain the cause for the signalling connection release, such as "Successful Relocation", "Normal Release", "Release due to UTRAN Generated Reason", "Relocation Cancelled", and "No Remaining RAB". After sending the message, the CN shall no more send any connection-oriented RANAP message on that connection.
2)
Upon reception of the IU RELEASE COMMAND message, the RNC shall clear the related resources in the UTRAN. The RNC returns an IU RELEASE
COMPLETE message to the CN. The Iu signalling connection release procedure ends.
5.7.3 RAB Release

The RAB release procedure is also initiated by the CN and implemented by the UTRAN. The RAB release procedure also adopts the following three modes: DCH-DCH: The RRC connection is on a DCH before the RAB release and also on a DCH after the RAB release. CCH-CCH: The RRC connection is on a CCH before the RAB release and also on a CCH after the RAB release. DCH-CCH: The RRC connection is on a DCH before the RAB release and on a CCH after the RAB release. This section describes only the DCH-DCH RAB release procedure. The other two procedures can be deduced by analogy. Similar to the RAB setup procedure, the DCH-DCH RAB release procedure on the radio interface can also be implemented through the following two ways: Synchronous radio link reconfiguration Asynchronous radio link reconfiguration This section describes only the RAB release procedure in the former case. The RAB release procedure in the latter case can be deduced by analogy according to the asynchronous Iub interface radio link reconfiguration procedure. Figure 5-17 illustrates the DCH-DCH RAB release procedure in the former case.
UE
NodeB Serving RNS
Serving RNC
RANAP
CN
1 RAB ASSIGNMENT REQUEST RANAP [Release]
NBAP
2RADIO LINK RECONFIGURATION PRPARE NBAP [DCH Deletion]
3.RADIO LINK RECONFIGURATION READY NBAP NBAP RRC 4:RADIO BEARER RELEASE RRC
5.RADIO LINK RECONFIGURATION COMMIT NBAP NBAP
Apply new transport format set DCCH 6.DCCH : RADIO BEARER RELEASE COMPLETE
RRC
RRC
7.ALCAP Iub Data Transport Bearer Release
8. ALCAP Iu Data TransportBearer Release not required towards PS domain RANAP 9. RAB ASSIGNMENT RESPONSE RANAP
Figure 5-17 RAB release procedure (DCH-DCH, synchronous)
Each step is explained as follows: 1) The CN sends an RAB ASSIGNMENT REQUEST [Release] message to initiate an RAB release procedure. The message shall indicate the ID of the RAB to be released. 2) The SRNC sends a RADIO LINK RECONFIGURATION PREPARE message to the NodeB, requesting the NodeB to prepare for releasing the DCH bearing the RAB. 3) 4) 5) 6) 7) The NodeB returns a RADIO LINK RECONFIGURATION READY message to the SRNC, informing it that the release is ready. The SRNC sends a RADIO BEARER RELEASE message to the UE to initiate the bearer release procedure. The SRNC sends a RADIO LINK RECONFIGURATION COMMIT message to the NodeB. The SRNC receives a RADIO BEARER RELEASE COMPLETE message from the UE. The SRNC initiates an Iub interface user plane transport bearer release procedure using ALCAP.
8)
If it is an AAL2 bearer, the SRNC uses an ALCAP AAL2 release message to initiate the Iu interface data transport bearer release from the CN (this step is not required towards PS domain).
9)
The SRNC sends a RANAP message RAB ASSIGNMENT RESPONSE to the CN. The RAB release procedure ends.
Note:
In the case of user plane abnormity at RNC, the RNCAP shall send an RAB RELEASE REQUEST message to the CN, requesting the CN to release the affected RAB, as illustrated in Figure 5-18.
RNC
RAB RELEASE REQUEST
CN
Figure 5-18 RAB release request procedure
5.7.4 Combined CS Domain Iu and RAB Release

If the CS domain has only one RAB, the MSC sends an IU RELEASE COMMAND message to the RNC during the service release. When the RNC receives this message, it will release the Iu signalling connection on the Iu-CS interface and RAB. Figure 5-19 shows the combined CS domain Iu and RAB release procedure (DCH-DCH).

NodeB Serving RNS

Serving RNC
RANAP 1 IU RELEASE COMMAND
UE
CN
RANAP
2 RADIO LINK RECONFIGURATION PRPARE NBAP NBAP [DCH Deletion] 3.RADIO LINK RECONFIGURATION READY NBAP NBAP RRC 4:RADIO BEARER RELEASE RRC
5.RADIO LINK RECONFIGURATION COMMIT NBAP NBAP
Apply new transport format set DCCH 6.DCCH : RADIO BEARER RELEASE COMPLETE
RRC
RRC
7.ALCAP Iub Data Transport Bearer Release
8. ALCAP Iu Data TransportBearer Release
9. IU RELEASE COMPLETE RANAP
RANAP
Figure 5-19 Combined CS domain Iu and RAB release procedure (DCH-DCH)
1) 2)
The CN sends an IU RELEASE COMMAND message to the SRNC. The SRNC sends a RADIO LINK RECONFIGURATION PREPARE message to the NodeB, requesting the NodeB to prepare for the release of DCH that bears the RAB.
3) 4) 5) 6) 7) 8) 9)
The NodeB sends a RADIO LINK RECONFIGURATION READY message to the SRNC, informing the SRNC that the release is ready. The SRNC sends a RADIO BEARER RELEASE message to the UE, starting the bearer release procedure. The SRNC sends a RADIO LINK RECONFIGURATION COMMIT message to the NodeB. The SRNC receives the RADIO BEARER RELEASE COMPLETE message from the UE. The SRNC releases the data transfer bearer on the Iub interface through ALCAP. If it is an AAL2 bearer, the SRNC uses an AAL2 release message to start the release of the data transfer bearer on the Iu interface through ALCAP. The SRNC sends an IU RELEASE COMPLETE message to the CN.
5.7.5 RRC Connection Release

I. Overview
After the RAB release, the SRNC shall check whether the same RRC bears other RABs. If no, the SRNC shall release that RRC connection. The RRC connection release procedure is used to release the RRC connection including all radio bearers between the UE and the UTRAN. By doing so, all established signalling connections will be released. The RRC connection release procedure has two kinds according to the RRC status, RRC release on a DCH and RRC release on a CCH. Only when the UE is in CELL_DCH or CELL_FACH state, can RRC connection release be implemented. If the RRC connection is in CELL_PCH or URA_PCH state, the UTRAN shall initiate a paging procedure to enable the UE transition to CELL_FACH state before the release. The RNC shall send an RRC CONNECTION RELEASE message on the downlink DCCH or CCCH using UM RLC. The UTRAN sends RRC CONNECTION RELEASE message on a DCCH if available. Otherwise, the UTRAN sends the message on a CCCH.
II. RRC Connection Release on DCH

Figure 5-20 illustrates the signalling procedure for RRC connection release on a DCH.
UE NodeB
1.RRC CONNECTION RELEASE
SRNC
RRC
RRC
2.RRC CONNECTION RELEASE COMPLETE RRC 3. RADIO LINK DELETION REQUEST NBAP 4. RADIO LINK DELETION RESPONSE NBAP NBAP NBAP RRC
5.ALCAP Release
Figure 5-20 RRC connection release procedure (on DCH)
Each step is explained as follows:
1)
The SRNC sends an RRC CONNECTION RELEASE message to the UE on the DCCH. It may transmit this message several times to increase the probability of proper reception of the message by the UE
2) 3) 4) 5)
The UE returns an RRC CONNECTION RELEASE COMPLETE message to the SRNC. The SRNC sends a RADIO LINK DELETION REQUEST message to the NodeB, requesting to delete the radio link resources in the NodeB. After releasing the resources, the NodeB returns a RADIO LINK DELETION RESPONSE message to the SRNC. The SRNC initiates an Iub interface user plane transport bearer release procedure using ALCAP. The RRC connection release procedure ends.
III. RRC Connection Release on CCH

Figure 5-21 illustrates the signalling procedure for RRC connection release on a CCH.
UE
NodeB
RRC CONNECTION RELEASE
SRNC
RRC
RRC
Figure 5-21 RRC connection release procedure (on CCH)
The SRNC sends an RRC CONNECTION RELEASE message to the UE on a CCCH to initiate an RRC connection release procedure. The UE shall release the resources. In the case of RRC connection release on a CCH, the RRC CONNECTION RELEASE COMPLETE is not required. The UTRAN shall release only the UE resources rather than the NodeB resources and data transport bearer, for the UE uses only the common resources in the cell.
Note:
The UTRAN may transmit several RRC CONNECTION RELEASE messages to increase the probability of proper reception of the message by the UE. The RRC message sequence numbers (RRC SN) for these messages are the same. The number and interval of retransmissions are controlled by the network.
Chapter 6 Mobility Management Procedure Analysis

6.1 Overview
Terminal mobility is an important feature of mobile communications. The UMTS includes the following mobility management: Forward handover (cell update and URA update) Soft handover Hard handover, Inter-RAT handover Relocation
6.2 Forward handover

6.2.1 Overview
Forward handover includes cell update and URA update. It is used to update UE information of the UTRAN side after the UE location changes. In addition, forward handover is also used for RRC connection monitoring, RRC connection status transition, error reporting, and information transmission. Both cell update and URA update are initiated by UE.
6.2.2 Cell Update

The cell update procedure is possible for UEs in the connected mode (URA_PCH, CELL_PCH, CELL_FACH and CELL_DCH). The UE shall initiate the cell update procedure in the following cases: Cell reselection Re-entering service area Periodical cell update Radio link failure Paging response Uplink data transmission RLC unrecoverable error Figure 6-1 illustrates a basic cell update procedure.
UE 1.CELL UPDATE 2.CELL UPDATE CONFIRM
UTRAN
Figure 6-1 Basic cell update procedure Each step is explained as follows: 1) 2) The UE sends a CELL UPDATE message to the RNC to initiate a cell update procedure. The message shall contain the cell update cause, U-RNTI and so on. The RNC returns a CELL UPDATE CONFIRM message to the UE. The message may contain the transport channel IEs, physical channel IEs, radio bearer (RB) IEs, U-RNTI and so on. Upon reception of the CELL UPDATE CONFIRM message, the UE shall invoke IEs in the message and performs corresponding status transition. Depending on the different IEs included in the CELL UPDATE CONFIRM message, the UE may return different messages or no message to the RNC. The messages the UE may return are given below: RADIO BEARER RELEASE COMPLETE RADIO BEARER RECONFIGURATION COMPLETE TRANSPORT CHANNEL RECONFIGURATION COMPLETE PHYSICAL CHANNEL RECONFIGURATION COMPLETE UTRAN MOBILITY INFORMATION CONFIRM The cell update procedure ends. Figure 6-2 describes a cell update instance in which the UE returns a PHYSICAL CHANNEL RECONFIGURATION COMPLETE message on the radio interface.
UE
RRC 2.CELL UPDATE CONFIRM RRC 3.PHYSICAL CHANNEL RECONFIGURATION COMPLETE RRC RRC RRC
NodeB
1.CELL UPDATE
RNC
RRC
Figure 6-2 A cell update instance
The CELL UPDATE CONFIRM message contains the C-RNTI and U-RNTI the network allocates to the UE. After invoking the new parameters, the UE sends a PHYSICAL CHANNEL RECONFIGURATION COMPLETE message to the RNC. The cell update procedure ends.
6.2.3 URA Update

For the UE in URA_PCH state, the URA update procedure is actually a procedure the UE initiates to update the URA information of the network side. The UE shall initiate the URA update procedure in the following cases: URA reselection Periodic URA update Figure 6-3 illustrates the basic URA update procedure.
UE URA UPDATE URA UPDATE CONFIRM UTRAN
Figure 6-3 Basic URA update procedure Each step is explained as follows: 1) 2) The UE sends a URA UPDATE message to the RNC to initiate a URA update procedure. The message shall contain the URA update cause, U-RNTI and so on. The RNC returns a URA UPDATE CONFIRM message to the UE. The message may contain the new C-RNTI, U-RNTI, ciphering mode information, integrity protection mode information, and so on. Upon reception of the URA UPDATE CONFIRM message, the UE shall invoke IEs in the message and send a PHYSICAL CHANNEL RECONGURITION COMPLETE message or no message to the RNC depending on the different IEs included in the URA UPDATE CONFIRM message. Figure 6-4 describes a URA update instance in which a PHYSICAL CHANNEL RECONGURITION COMPLETE message is sent.
UE
RRC
NodeB
1.URA UPDATE
RNC
RRC
2.URA UPDATE CONFIRM RRC 3.PHYSICAL CHANNEL RECONFIGURATION COMPLETE RRC RRC RRC
Figure 6-4 A URA update instance The URA UPDATE CONFIRM message contains RRC Transaction Identity and RRC State Indicator. In addition, it might contain the CN IEs, integrity protection mode information, ciphering mode information, new C-RNTI and U-RNTI. After invoking the new parameters, the UE sends a PHYSICAL CHANNEL RECONFIGURATION COMPLETE message to the RNC. The URA update procedure ends.
6.2.4 Cell Update Message

IE/Group name Message Type UE information elements U-RNTI RRC transaction identifier Integrity check info START list >CN domain identity >START AM_RLC error indication(RB2 or RB3) AM_RLC error indication(RB>3) Cell update cause MP MP Includes: cell reselection, periodical cell update, uplink
Presence MP MP CV-Failure CH MP MP MP MP
IE/Group name
Presence
Semantics description data transmission, paging response, re-entered service area, radio link failure, RLC unrecoverable error
Failure cause RB timer indicator Measurement information elements Measured results on RACH
OP MP
OP
II. Example
6.2.5 URA Update Message

IE/Group name Message Type UE information elements U-RNTI RRC transaction identifier Integrity check info URA update cause MP CV- ProtErr CH MP Presence MP Semantics description Includes: change of URA, periodic URA update, re-entered service area Protocol error indicator Other information elements Protocol error information CV-ProtErr MD
II. Example
6.3 Soft Handover

6.3.1 Overview
When there are intra-frequency neighboring cells in the UMTS system, a UE can communicate with the network through multiple radio links. The multiple radio links are combined on a macro-diversity basis by selection ratio or maximum ratio to optimize the communication QoS. By soft handover, the UE can be smoothly handed over to another cell without affecting the previous communication. Soft handover only applies to FDD mode. Soft handover has the following three kinds according to the resource usage situation: Radio link addition Radio link deletion Radio link addition and deletion A soft handover generally includes the following steps:
1)
The UE measures the intra-frequency neighboring cells according to the measurement control information from the RNC. The measurement results are reported to the RNC after processing.
2) 3) 4) 5)
The RNC compares the measurement results with the thresholds to determine the cells to be added or deleted. The RNC requests the NodeB to prepare if it determines to add a cell. The RNC requests the UE to add and/or delete cells through an ACTIVE SET UPDATE procedure. After the UE successfully performs the active set update where a cell is deleted, the RNC shall request the NodeB to release the corresponding RL resources.
6.3.2 Radio Link Addition

This section describes the soft handover procedure [radio link addition] implemented by the NodeB under the control of DRNC, as illustrated in Figure 6-5.
UE NodeB DRNS DRNC SRNC
Decision to setup new RL 1. RADIO LINK SETUP REQUEST RNSAP 2. RADIO LINK SETUP REQUEST NBAP Start RX description NBAP 3. RADIO LINK SETUP RESPONSE NBAP 4.ALCAP Iub Bearer setup 5. RADIO LINK SETUP RESPONSE RNSAP 6.ALCAP Iur Bearer setup Start TX description 7. ACTIVE SET UPDATE RRC [RADIO LINK ADDITION] 8. ACTIVE SET UPDATE COMPLETE RRC RRC RNSAP NBAP RNSAP
RRC
Figure 6-5 Soft handover procedure [radio link addition] Each step is explained as follows: 1) According to the resource usage situation, the SRNC decides to set up a radio link in a new cell of the DRNC. It sends an RNSAP message RADIO LINK
SETUP REQUEST to the DRNC, requesting for radio resources. If this is the first radio link between the DRNC and the UE, a signalling connection shall also be established on the Iur interface for bearing the RNSAP signalling associated with the UE. 2) After confirming that the resources requested by the SRNC are available, the DRNC sends an NBAP message RADIO LINK SETUP REQUEST to the target NodeB. The NodeB starts uplink reception. 3) After successfully allocating the resources requested by the SRNC, the NodeB sends an NBAP message RADIO LINK SETUP RESPONSE to the DRNC, reporting the allocation result. 4) 5) 6) 7) The DRNC initiates an Iub interface transport bearer setup procedure using ALCAP. The DRNC sends an RNSAP message RADIO LINK SETUP RESPONSE to the SRNC. The SRNC initiates an Iur interface transport bearer setup procedure using ALCAP. The SRNC transmits an ACTIVE SET UPDATE [RADIO LINK ADDITION] message to the UE on the DCCH. The message shall contain the information about the radio link to be added. 8) The UE adds the corresponding radio link information to the active set and returns an RRC message ACTIVE SET UPDATE COMPLETE message to the SRNC. The soft handover procedure [radio link addition] ends.
6.3.3 Radio Link Deletion

This section describes the soft handover procedure [radio link deletion] implemented by the NodeB under the control of DRNC, as illustrated in Figure 6-6.
UE
NodeB DRNS
DRNC
SRNC
Decision to delete old RL 1. ACTIVE SET UPDATE RRC RADIO LINK DELETION RRC 2. ACTIVE SET UPDATE COMPLETE RRC RNSAP 4. RADIO LINK DELETION REQUEST NBAP Stop RX and TX 5. RADIO LINK DELETION RESPONSE NBAP NBAP 6.ALCAP Iub Bearer release 7. RADIO LINK DELETION RESPONSE RNSAP 8.ALCAP Iur Bearer release RNSAP NBAP 3. RADIO LINK DELETION REQUEST RNSAP RRC
Figure 6-6 Soft handover procedure [radio link deletion] Each step is explained as follows: 1) According to the resource usage situation, the SRNC decides to delete a radio link from the DRNC. It transmits an RRC message ACTIVE SET UPDATE [RADIO LINK DELETION] to the UE on the DCCH. The message shall contain the information about the radio link to be deleted. 2) The UE stops downlink reception on the radio link and deletes that radio link. Then it sends an RRC message ACTIVE SET UPDATE COMPLETE to the SRNC. 3) After confirming that the deleted radio link is in the DRNC, the SRNC sends an RNSAP message RADIO LINK DELETION REQUEST to the DRNC, requesting the DRNC to release the allocated radio resources. 4) 5) The DRNC sends an NBAP message RADIO LINK DELETION REQUEST to the NodeB, requesting the NodeB to release the allocated radio resources. After successfully releasing the radio resources, the NodeB returns an NBAP message RADIO LINK DELETION RESPONSE to the DRNC, reporting the release result. 6) 7) The DRNC initiates an Iub interface data transport bearer release procedure using ALCAP. The DRNC sends an RNSAP message RADIO LINK DELETION RESPONSE to the SRNC.
8)
The SRNC initiates an Iur interface data transport bearer release procedure using ALCAP. The soft handover procedure [radio link deletion] ends.
6.3.4 Radio Link Addition and Deletion

The soft handover procedure [radio link addition and deletion] is implemented when the number of radio links of the UE reaches the maximum number of macro-diversity tributaries allowed. This section describes the soft handover procedure [radio link addition and deletion] implemented by the NodeB under the control of DRNC, as illustrated in Figure 6-7.
UE NodeB DRNS NodeB SRNS DRNC SRNC
Decision to setup new RL and release old RL
1. RADIO LINK SETUP REQUEST
RNSAP
2. RADIO LINK SETUP REQUEST
RNSAP
NBAP Start RX description

3. RADIO LINK SETUP RESPONSE
NBAP
NBAP
NBAP
4. ALCAP Iub Data Transport Bearer Setup

5.RADIO LINK SETUP RESPONSE
RNSAP 6.ALCAP 7. ACTIVE SET UPDATE RRC

[Radio Link Addition & Deletion]
RNSAP Iur Bearer Setup RRC
RRC
8. ACTIVE SET UPDATE COMPLETE RRC 9.RADIO LINK DELETION REQUEST NBAP Stop RX and TX 10.RADIO LINK DELETION RESPONSE NBAP NBAP
NBAP
11. ALCAP Iub Data Transport Bearer Release
Figure 6-7 Soft handover procedure [radio link addition and deletion] Each step is explained as follows: 1)6) These steps are the same as those of the soft handover procedure [radio link addition], as shown in Figure 6-5. Through these steps, a radio link is added to the NodeB under control of DRNC.
7) The SRNC transmits an RRC message ACTIVE SET UPDATE [RADIO LINK ADDITION & DELETION] message to the UE on the DCCH. The message shall contain the information about the radio links to be added and deleted. 8) After successfully adding and deleting the corresponding radio links, the UE sends an RRC message ACTIVE SET UPDATE COMPLETE to the NodeB. 9)11) These steps are similar to steps 3)7) of the soft handover procedure [radio link deletion], as shown in Figure 6-6. The difference is that the radio link is deleted from the NodeB under the control of SRNC in this case. Therefore, there is no radio link deletion through the Iur interface.

Refer to section 5.3.8 Radio Link Setup Request Message for details.
6.3.6 Active Set Update Message

IE/Group name Message Type UE information elements RRC transaction identifier Integrity check info Integrity protection mode info Ciphering mode info Activation time New U-RNTI CN information elements CN Information info RB information elements Downlink counter synchronisation info >RB with PDCP information list >>RB with PDCP information OP MP OP OP MP CH OP OP MD OP Presence MP Semantics description
IE/Group name Phy CH information elements Uplink radio resources Maximum allowed UL TX power Downlink radio resources Radio link addition information >Radio link addition information Radio link removal information >Radio link removal information TX Diversity Mode SSDT information
Presence
MD
OP MP OP MP MD OP
II. Example
6.4 Hard Handover

6.4.1 Overview
The hard handover procedure is a procedure in which the UE stops communication with the previous cell before it accesses a new cell. Hard handover has two types, intra-frequency hard handover and inter-frequency hard handover, according to the variation of working frequencies before and after the hard handover. Since the hard handovers performance is worse than the soft handovers, the hard handover procedure is adopted only when the soft handover procedure cannot be implemented. Relocation shall be triggered along with hard handover between different RNCs. Such relocation is generally called relocation with hard handover. The hard handover procedure may be performed by one of the following five procedures on the Uu interface: PHYSICAL CHANNEL RECONFIGURATION TRANSPORT CHANNEL RECONFIGURATION RADIO BEARER SETUP RADIO BEARER RELEASE RADIO BEARER RECONFIGURATION The following will introduce the compressed mode and then the hard handover on the Iur interface and the CN combined hard handover to demonstrate the hard handover procedures.
6.4.2 Compressed Mode

The UE may directly implement hard handover without performing measurements for the target cell, as is not allowed in the soft handover procedure. Such hard handover has great possibility of failure, and therefore shall be applied in only emergency circumstances. In more cases of hard handover, the UE shall perform measurements for the target cell. The UE is generally configured with one decoder and cannot simultaneously decode the signals at two frequencies. In order that the UE can perform inter-frequency and inter-RAT measurements, the compressed mode is introduced to the UMTS system. Figure 6-8 illustrates the principle of compressed mode.
One frame (10 ms)
Idle period available for inter-frequency measurements
Figure 6-8 Principle of compressed mode The fundamental principle of compressed mode is given below: When in compressed mode, the UE transmits a radio frame compressed in time instead of a full radio frame so that the decoder can switch to another frequency or mode to perform inter-frequency and inter-RAT measurements during the transmission gap. The transmission time reduction can be achieved by puncturing or by SF/2. Puncturing is a method in which bits of a coded radio frame on a radio channel are regularly stopped to create a transmission gap. SF/2 is a method in which the spreading factor is halved to increase the transmission rate of data bits. That is, this method is used to transmit the bits originally transmitted in one radio frame in a shorter period so as to create a transmission gap. When the UE performs inter-frequency hard handover measurements, the NodeB shall also be in the compressed mode to ensure that the UE can receive messages from the RNC. Whether to use the compressed mode is determined by the RNC.
6.4.3 Iur Interface Hard Handover

Figure 6-9 illustrates the hard handover signalling procedure implemented on the Iur interface by the UE in CELL_DCH state.

NodeB Source NodeB Target RNC Source

RNC target
1. RADIO LINK SETUP REQUEST RNSAP 2. RADIO LINK SETUP REQUEST NBAP 3. RADIO LINK SETUP RESPONSE NBAP NBAP NBAP RNSAP
UE
SRNC
4. ALCAP
Iub Data Transport Bearer Setup 5. RADIO LINK SETUP RESPONSE RNSAP RNSAP
6. ALCAP Iur Data Transport Bearer Setup 7. PHYSICALl CHANNEL RECONFIGURATION RRC 8. RADIO LINK FAILURE INDICATION NBAP NBAP 9. RADIO LINK FAILURE INDICATION RNSAP 10. PHYSICAL CHANNEL RECONFIGURATION COMPLETE RRC 11. RADIO LINK DELETION REQUEST RNSAP 12. RADIO LINK DELETION REQUEST NBAP 13. RADIO LINK DELETION RESPONSE NBAP NBAP NBAP RNSAP RRC RNSAP RRC
14. ALCAP
Iub Data Transport Bearer Release 15. RADIO LINK DELETION RESPONSE RNSAP RNSAP
16. ALCAP
Iur Data Transport Bearer Release
Figure 6-9 Hard handover on Iur interface (UE in CELL_DCH state) Each step is explained as follows: 1) 2) 3) 4) The SRNC sends a RADIO LINK SETUP REQUEST message to the target RNC on the Iur interface. The target RNC allocates the RNTI and radio resources and sends a RADIO LINK SETUP REQUEST message to the target NodeB on the Iub interface. The target NodeB allocates the resources, starts physical layer reception, and returns a RADIO LINK SETUP RESPONSE message to the target RNC. The target RNC initiates an Iub interface data transport bearer setup procedure using ALCAP.
5) 6) 7) 8)
The target RNC sends a RADIO LINK SETUP RESPONSE message to the SRNC on the Iur interface. The SRNC initiates an Iur interface data transport bearer setup procedure using ALCAP. The SRNC sends a PHYSICAL CHANNEL RECONFIGURATION message to the UE on the Uu interface. The UE disconnects from the previous radio link and access the network on the new radio link. The NodeB detects the radio link failure and sends a RADIO LINK FALURE INDICATION message to the CRNC on the Iub interface.
9)
The source RNC sends a RADIO LINK FAILURE INDICATION message to the SRNC on the Iur interface.
10) After the setup of a radio connection to the target RNC and allocation of the necessary radio resources, the UE sends a PHYSICAL CHANNEL RECONFIGURATION COMPLETE message to the SRNC on the Uu interface. 11) The SRNC sends a RADIO LINK DELETION REQUEST message to the source RNC on the Iur interface. 12) The source RNC sends a RADIO LINK DELETION REQUEST message to the source NodeB on the Iub interface. 13) After successfully releasing the radio resources, the source NodeB returns a RADIO LINK DELETION RESPONSE message. 14) The source RNC initiates an Iub interface data transport bearer release procedure using ALCAP. 15) After successful release, the source RNC sends a RADIO LINK DELETION RESPONSE message to the SRNC. 16) The SRNC initiates an Iur interface data transport bearer release procedure using ALCAP. The hard handover procedure on the Iur interface ends.
6.4.4 Combined Hard Handover

The UE in CELL_DCH state has simultaneously connections to two CN domains, CS domain and PS domain. It can implement combined hard handover via the CN domains between different RNCs, accompanied by an SRNC relocation signalling procedure, as illustrated in Figure 6-10.
UE
NodeB Source
NodeB Target
RNC Source
RANAP RANAP
RNC Target
MSC
SGSN
1. RELOCATION REQUIRED 2. RELOCATION REQUIRED
RANAP
RANAP RANAP
RANAP
3. RELOCATION REQUEST 4. RELOCATION REQUEST
RANAP
RANAP
5. ALCAP Iu Data Transport Bearer Setup NBAP NBAP 6. RADIO LINK SETUP REQUEST 7. RADIO LINK SETUP RESPONSE NBAP NBAP
8. ALCAP Iub Data Transport Bearer Setup 9. RELOCATION REQUEST ACKNOWLEDGE RANAP 10. RELOCATION REQUEST ACKNOWLEDGE
RANAP
RANAP
RANAP
RANAP
11. RELOCATION COMMAND
RANAP
RANAP 13. PHYSICAL CHANNEL RECONFIGURATION
12. RELOCATION COMMAND
RANAP
RRC
RRC 14. RADIO LINK RESTORE INDICAITON NBAP RANAP 15. RELOCATION DETECT RANAP 16. RELOCATION DETECT RANAP
NBAP
NBAP
17. RADIO LINK FAILURE INDICATION
RANAP NBAP
RRC
18. PHYSICAL CHANNEL RECONFIGURATION COMPLETE
RRC 19. RELOCATION COMPLETE RANAP 20. RELOCATION COMPLETE RANAP
RANAP
RANAP
RANAP
21. IU RELEASE COMMAND
RANAP
RANAP
22. IU RELEASE COMMAND
RANAP
23. ALCAP IU DATA TRANSPORT BEARER RELEASE RANAP 24. IU RELEASE COMPLETE RANAP
RANAP
25. IU RELEASE COMPLETE
RANAP
Figure 6-10 Combined hard handover (through CN domain) Each step is explained as follows:
1)2) The source RNC decides to perform relocation with hard handover. The combined hard handover procedure starts. The source RNC sends two RELOCATION REQUIRED messages respectively to two CN nodes. Upon reception of the RELOCATION REQUIRED message, the two CN nodes respectively make preparation for the handover procedure. 3)4) After successful preparation, the two CN nodes respectively send a RELOCATION REQUEST message to the target RNC, requesting the target RNC to allocate resources. The target RNC configures the necessary resources for the radio links to be set up during the hard handover procedure. 5) The target RNC and the MSC set up a new Iu interface transport bearer for the RAB associated with that MSC. 6) The target RNC allocates the RNTI and radio resources to the RRC connection and radio links and sends a RADIO LINK SETUP REQUEST message to the target NodeB. 7) The target NodeB allocates the resources, starts physical layer reception, and sends a RADIO LINK SETUP RESPONSE message to the target RNC. 8) The target RNC initiates an Iub interface data transport bearer setup procedure using ALCAP. 9)10) After successful preparation, the target RNC sends two RELOCATION REQUEST ACKNOWLEDGE messages respectively to the two CN nodes. 11)12) After successful preparations for SRNC relocation, the two CN nodes respectively send a RELOCATION COMMAND message to the source RNC. 13) The source RNC sends a PHYSICAL CHANNEL RECONFIGURATION message to the UE, informing it of the new physical channel parameters. 14)16) The target NodeB detects the radio link synchronization on the air interface and sends a RADIO LINK RESTORE INDICATION message to the target RNC, triggering the target RNC to send RELOCATION DETECT messages respectively to the MSC and the SGSN. 17) When the UE is handed from the previous radio link over to the new one, the NodeB detects the asynchronization of the previous radio link and sends a RADIO LINK FAILURE INDICATION message to the target RNC. 18)20) After successfully physical channel reconfiguration, the UE sends a PHYSICAL CHANNEL RECONFIGURATION COMPLETE message to the target RNC, triggering the target RNC to send RELOCATION COMPLETE messages respectively to the MSC and the SGSN. 21)22) The MSC and the SGSN respectively send an IU RELEASE COMMAND message to the source RNC to initiate an Iu connection release procedure. 23)25) Upon reception of the IU RELEASE COMMAND messages from the two CN nodes, the source RNC returns two IU RELEASE COMPLETE messages respectively
to the CN nodes and releases all UTRAN resources associated with the RRC connection.

Refer to section 5.3.8 Radio Link Setup Request Message for details.
6.4.6 Physical Channel Reconfiguration Message

IE/Group name Message Type UE information elements RRC transaction identifier Integrity check info Integrity protection mode info Ciphering mode info Activation time New U-RNTI New C-RNTI RRC State Indicator UTRAN DRX cycle length coefficient CN information elements CN Information info UTRAN mobility information elements URA identity RB information elements Downlink counter synchronisation info >RB with PDCP information list >>RB with PDCP information PhyCH information elements
Presence MP
OP
OP
OP OP MP
IE/Group name Frequency info Uplink radio resources Maximum allowed UL TX power CHOICE channel requirement >Uplink DPCH info >CPCH SET Info >CPCH set ID Downlink radio resources CHOICE mode >FDD >>Downlink PDSCH information >TDD Downlink information common for all radio links Downlink information per radio link list >Downlink information for each radio link
Presence MD
MD OP
MP
OP
OP
OP MP
II. Example
6.5 Inter-RAT Handover

6.5.1 Overview
Inter-RAT handover is a handover between UMTS and GSM/GPRS systems and can be divided into: 1) UMTS to GSM handover This procedure is to hand the UE in CELL_DCH state that sets up a CS service in the UMTS system over to the GSM system. 2) GSM to UMTS handover This procedure is to hand the UE in connected mode that sets up a CS service in the GSM system over to the UMTS system. 3) 4) GSM/GPRS to UMTS cell reselection UMTS to GSM/GPRS cell reselection
Note: This manual only introduces the related signalling procedures in UTRAN. The signalling procedures in CN and GSM/BSS are not included. This section describes equipment in the format of ABC/abc to distinguish equipment that may exist in UMTS, GSM and GPRS systems. For example, GSM/MSC denotes the MSC in GSM.
6.5.2 UMTS to GSM Handover

This section describes the basic UMTS to GSM handover procedure, as illustrated in Figure 6-11.
Note: The signalling procedures between the UMTS/CN and the GSM/MSC and between the GSM/MSC and the GSM/BSC are outside the scope of this manual and are only schematically mentioned here.

UE NodeB
SRNC
CN
GSM/MSC
GSM/BSC
1. RELOCATION REQUIRED RANAP RANAP 2. PREPARE HANDOVER MAP/E MAP/E 3. HANDOVER REQUEST BSSMAP BSSMAP
BSSMAP 5. PREPARE HANDOVER MAP/E RESPONSE MAP/E
4. HANDOVER REQUEST ACK
BSSMAP
6. RELOCATION COMMAND RANAP 7.DCCH : HANDOVER FROM UTRAN COMMAND RRC [Hard Handover] 8. HANDOVER DETECT RRC RANAP
BSSMAP
BSSMAP
9. HANDOVER COMPLETE RR 10. HANDOVER COMPLETE BSSMAP BSSMAP RR
11. SEND END SIGNAL MAP/E REQUEST MAP/E
12. IU RELEASE COMMAND RANAP RANAP
13. IU RELEASE COMPLETE RANAP RANAP
14. SEND END SIGNAL MAP/E RESPONSE MAP/E
Figure 6-11 UMTS to GSM handover procedure Each step is explained as follows: 1) The SRNC decides to perform inter-RAT handover to the GSM system and sends a RELOCATION REQUIRED message to the CN on the Iu interface. 2) The CN sends a MAP message PREPARE HANDOVER to the GSM/MSC. 3)4) These two steps indicate the signalling procedures in GSM schematically. 5) The GSM/MSC and the GSM/BSS perform the initialization procedure and return a MAP/E message PREPARE HANDOVER RESPONSE to the CN.
6) The CN sends a RANAP message RELOCATION COMMAND to the SRNC as a response to the RELOCATION REQUIRED message. 7) The SRNC sends a HANDOVER FROM UTRAN COMMAND message to the UE on the existing RRC connection, commanding the UE to perform inter-RAT handover. 8) This step indicates a signalling procedure in GSM schematically. 9)10) The UE accesses the network via the GSM/BSS and sends a HANDOVER COMPLETE message. 11) The GSM/MSC detects the UE in the GSM coverage area and sends a MAP/E message SEND END SIGNAL REQUEST to the CN. 12) The CN sends an IU RELEASE COMMAND message to initiate a release procedure for the SRNC allocated resources. 13) The UMTS releases the bearer resources and returns an IU RELEASE COMPLETE message to the CN on the Iu interface. 14) Upon completion of the call, the CN sends a MAP/E message SEND END SIGNAL RESPONSE to the GSM/MSC.
6.5.3 GSM to UMTS Handover

This section describes the basic GSM to UMTS handover procedure, as illustrated in Figure 6-12
Note: The signalling procedures between the CN and the GSM/MSC and between the GSM/MSC and the GSM/BSC are outside the scope of this manual and are only schematically mentioned here.
UE
NodeB
RNC Target
CN
MSC
BSC
1. HANDOVER REQUIRED BSSMAP 2. PREPARE HANDOVER MAP/E MAP/E BSSMAP
3. RELOCATION REQUEST RANAP RANAP
RANAP
4. RELOCATION REQUEST ACK RANAP 5. PREPARE HANDOVER RESPONSE MAP/E MAP/E
6. HANDOVER COMMAND BSSMAP BSSMAP
7. HANDOVER COMMAND RR 8. RELOCATION DETECT RANAP RANAP RR
9. DCCH HANDOVER TO UTRAN COMPLETE : RRC
RRC
10. RELOCATION COMPLETE RANAP RANAP 11. SEND END SIGNAL REQUEST MAP/E 12. CLEAR COMMAND BSSMAP BSSMAP
MAP/E
13. CLEAR COMPLETE BSSMAP 14. SEND END SIGNAL MAP/E RESPONSE MAP/E BSSMAP
Figure 6-12 GSM to UMTS handover procedure Each step is explained as follows: 1) 2) 3) 4) 5) The GSM/BSC sends a HANDOVER REQUIRED message to the GSM/MSC. The GSM/MSC sends a MAP/E message PREPARE HANDOVER to the CN. The CN sends a RELOCATION REQUEST message to the target RNC on the Iu interface. The target RNC returns a RELOCATION REQUEST ACKNOWLEDGE message to the CN. The CN sends a MAP/E message PREPARE HANDOVER RESPONSE to the GSM/MSC.
6) 7) 8) 9)
The GSM/MSC sends a HANDOVER COMMAND message to the GSM/BSC. The GSM/BSC sends a HANDOVER COMMAND message to the UE, commanding the UE to access the network via the target RNC in UMTS. The target RNC detects the UE and sends a RELOCATION DETECT message to the CN node. The UE sets up an RRC connection to the target RNC. After allocating the necessary radio resources, the UE sends a HANDOVER TO UTRAN COMPLETE message to the target RNC.
10) The target RNC sends a RANAP message RELOCATION COMPLETE to the CN. 11) The CN sends a MAP/E message SEND END SIGNAL REQUEST to the GSM/MSC. 12) The GSM/MSC sends a CLEAR COMMAND message to the GSM/BSC. 13) The GSM/BSC returns a CLEAR COMPLETE message to the GSM/MSC. 14) The GSM/MSC sends a MAP/E message SEND END SIGNAL RESPONSE to the CN.
6.5.4 GSM/GPRS to UMTS Cell Reselection

The GSM/GPRS to UMTS cell reselection procedure is given below: 1) The UE camps on a GSM/GPRS cell. It obtains the information (such as downlink frequency and primary scramble) about adjacent UMTS cells and the cell reselection parameters from the system information broadcast in the cell. Depending on the information and parameters, the UE determines whether to reselect a UMTS cell. 2) The UE reselects a UMTS cell, reads the system information, and registers in the UMTS system. This procedure is the same as the location update procedure and is not detailed in this section.
6.5.5 UMTS to GSM/GPRS Cell Reselection

I. Overview
UMTS to GSM/GPRS cell reselection includes the following modes: UMTS to GSM/GPRS cell reselection implemented by the UE in idle mode in the UMTS system UMTS to GPRS cell reselection initiated by the UE in CELL_FACH, CELL_PCH or URA_PCH state that sets up a PS service in the UMTS system UMTS to GPRS cell reselection initiated by the network side for the UE in CELL_DCH or CELL_FACH state that sets up a PS service in the UMTS system
II. Cell Reselection when UE in Idle Mode

1) The UE camps on a UMTS cell and obtains the information about adjacent GSM/GPRS cells and cell reselection parameters from the system information broadcast in the cell. Depending on the information and parameters, the UE determines whether to reselect a GSM/GPRS cell. 2) The UE selects a GSM/GPRS cell, reads the system information, and initiates a registration procedure. This procedure is the same as the registration procedure in GSM/GPRS and is not detailed in this section.
III. Cell Reselection when UE in CELL_FACH, CELL_PCH or URA_PCH State

The UE in CELL_FACH, CELL_PCH or URA_PCH state that sets up a PS service in the UMTS system can initiate a UMTS to GPRS cell reselection signalling procedure, as illustrated in Figure 6-13.
Serving RNC
UE
CN
1. Cell Reselection triggered
3. RANAP
IU RELEASE COMPLETE RANAP
Figure 6-13 UMTS to GPRS cell reselection procedure (initiated by UE) 1) 2) The UE selects a GPRS cell, reads the system information of the cell, and initiates a UE-GPRS signalling connection setup procedure. After necessary CN-GPRS preparation such as UE context retrieval, the CN sends an IU RELEASE COMMAND message to the SRNC to initiate an Iu connection release procedure. 3) After successful release, the SRNC returns an IU RELEASE COMPLETE message to the CN. The UMTS to GPRS cell reselection procedure initiated by the UE ends.
IV. Cell Reselection when UE in CELL_DCH or CELL_FACH state

When the UE in CELL_DCH or CELL_FACH state that sets up a PS service in the UMTS system detects the signal of a GPRS cell and reports an inter-RAT
measurement report, the network side can initiate a UMTS to GPRS cell reselection signalling procedure, as illustrated in Figure 6-14.
Note: The UMTS to GPRS cell reselection procedure initiated by the network side can be implemented only when the RNC can generate GSM messages.
UE
Serving RNC
CN
1. CELL CHANGE ORDER FROM UTRAN RRC RRC
3. RANAP
IU RELEASE COMPLETE RANAP
Figure 6-14 UMTS to GPRS cell reselection procedure (initiated by network side) Each step is explained as follows: 1) The SRNC decides to perform handover to a GPRS cell based on the measurement results from the UE and sends a CELL CHANGE ORDER FROM UTRAN message to the UE. Upon reception of the message, the UE performs a UE-GPRS connection setup procedure. 2) After necessary CN-GPRS preparation such as UE context retrieval, the CN sends an IU RELEASE COMMAND message to the SRNC to initiate an RRC connection release procedure on the Iu interface. 3) After successfully releasing all resources reserved for the UE, the SRNC returns an IU RELEASE COMPLETE message to the CN. The UMTS to GPRS cell reselection procedure initiated by the network side ends.
6.5.6 Handover from UTRAN Command Message

IE/Group name Presence Semantics description Message Type UE information elements RRC transaction identifier Integrity check info Activation time RB information elements RAB information list >RAB info Other information elements CHOICE System type >GSM >>Frequency band >>GSM message >>>Single GSM message >>>GSM message List >cdma2000 >>cdma2000MessageList >>>MSG_TYPE(s) >>>cdma2000Messagepayload(s) MP MP MP MP MP MP MP OP MP MP CH MD MP
II. Example
None
6.5.7 Handover to UTRAN Command Message

IE/Group name Presence Semantics description New U-RNTI Ciphering algorithm CHOICE specification mode >Complete specification RB information elements >>Signalling RB information to setup list >>>Signalling RB information to setup >>RAB information to setup list >>>RAB information for setup Uplink transport channels >>UL Transport channel information common for all transport channels >>Added or Reconfigured TrCH information >>>Added or Reconfigured UL TrCH information Downlink transport channels >>DL Transport channel information common for all transport channels >>Added or Reconfigured TrCH information >>>Added or Reconfigured DL TrCH information Uplink radio resources >>Uplink DPCH info MP MP MP MP MP MP MP MP MP OP MP MP OP MP
IE/Group name
Presence
>>CHOICE mode >>>FDD >>>>CPCH SET Info Downlink radio resources >>>>Downlink PDSCH information >>>TDD >>Downlink information common for all radio links >>Downlink information per radio link >>>Downlink information for each radio link >Preconfiguration >>CHOICE Preconfiguration mode >>>Predefined configuration >>>Default configuration >>>>Default configuration mode >>>>Default configuration identity >>RAB info >>Uplink DPCH info Downlink radio resources >>Downlink information common for all radio links >>Downlink information per radio link >>>Downlink information for each radio link >>CHOICE mode >>>FDD
MP
OP
OP
MP
MP MP
MP MP MP MP OP MP MP
MP MP
MP
IE/Group name
Presence
>>>TDD >>>>Primary CCPCH Tx Power Frequency info Maximum allowed UL TX power MP MP MP
II. Example
None
6.6 Relocation
6.6.1 Overview
The RNC relocation procedure is a procedure in which the SRNC of the UE changes from one RNC to another. According to whether the connection between UE and DRNC is set up during the relocation procedure, RNC relocations can be classified as UE NOT INVOLVED relocation and UE INVOLVED relocation. According to the triggering causes, RNC relocations can also be divided into the following four kinds: Static relocation: A relocation procedure occurring after a radio link is added to the DRNC. The UE has set up a radio link in the DRNC and established a connection to the DRNC before the static relocation procedure; therefore, this relocation is a kind of UE NOT INVOLVED relocation. Relocation with hard handover: A relocation procedure occurring with inter-RNC hard handover. The UE removes the connection with the SRNC and establishes a connection to the DRNC during the relocation with hard handover; therefore, this relocation is a kind of UE INVOLVED relocation. Relocation with forward handover: A relocation procedure occurring when the UE with RRC connection to the SRNC enters into a DRNC cell and initiates a forward handover (cell update or URA update) procedure. The UE has entered into the DRNC and sent a CELL UPDATE or URA UPDATE message before the relocation with forward handover; therefore, this relocation is a kind of UE NOT INVOLVED relocation. Inter-RAT handover: The UE removes the connection with the SRNC and establishes a connection to the GSM system during the inter-RAT handover procedure; therefore, inter-RAT handover is a kind of UE INVOLVED relocation.
This section describes the former three kinds of relocation procedures. Refer to section 6.5 procedure. Inter-RAT Handover for the details about the inter-RAT handover
6.6.2 Static Relocation

When the UE has a radio link connection only to the DRNC, the Iur interface transport resources between the SRNC and the DRNC shall be occupied. The static relocation procedure is implemented in this case. Through the relocation procedure, the Iur interface connection and the Iu interface connection between the SRNC and the CN are released and an Iu interface connection is set up between the DRNC and the CN. After relocation, the original DRNC becomes the SRNC, as illustrated in Static relocation.
CN SRNC DRNC CN
Orig. SRNC
SRNC
NodeB
CELL CELL
NodeB
CELL CELL
NodeB
CELL CELL
NodeB
CELL CELL
UE
UE
Figure 6-15 Static relocation
Note: If the UE has connections to two CN domains in the UMTS system before the relocation procedure, the two must be relocated together.
Figure 6-16 illustrates the static relocation signalling procedure.
UE
SRNC
DRNC
1. RELOCATION REQUIRED
MSC
SGSN
RANAP 2. RELOCATION REQUIRED RANAP RANAP 3. RELOCATION REQUEST RANAP 4. RELOCATION REQUEST RANAP 5.ALCAP SETUP 6. RELOCATION REQUEST ACKNOWLEDGE RANAP RANAP 8. RELOCATION COMMAND RANAP 9. RELOCATION COMMAND RANAP 10. RELOCATION COMMIT RNSAP RNSAP 11. RELOCATION DETECT RANAP 12. RELOCATION DETECT RANAP 13.UTRAN MOBILITY INFORMATION RRC 14.UTRAN MOBILITY INFORMATION CONFIRM RRC RRC 15. RELOCATION COMPLETE RANAP 16. RELOCATION COMPLETE RANAP 17. IU RELEASE COMMAND RANAP 18. IU RELEASE COMMAND RANAP 19.ALCAP 20. IU RELEASE COMPLETE RANAP 21. IU RELEASE COMPLETE RANAP RANAP release RANAP RANAP RRC RANAP RANAP 7. RELOCATION REQUEST ACKNOWLEDGE RANAP RANAP
RANAP
RANAP
RANAP
RANAP
RANAP
RANAP RANAP
RANAP
Figure 6-16 Static relocation procedure Each step is explained as follows: 1) 2) 3) 4) 5) 6) The SRNC sends a RELOCATION REQUIRED message to the SGSN (in PS domain). The SRNC sends a RELOCATION REQUIRED message to the MSC (in CS domain). The SGSN sends a RELOCATION REQUEST message to the DRNC, requesting the DRNC to make resource preparation for the relocation. The MSC sends a RELOCATION REQUEST message to the DRNC, requesting the DRNC to make resource preparation for the relocation. The DRNC initiates an Iu interface user plane bearer setup procedure using ALCAP. The DRNC sends a RELOCATION REQUEST ACKNOWLEDGE message to the SGSN, informing it that the resource is ready.
7) 8) 9)
The DRNC sends a RELOCATION REQUEST ACKNOWLEDGE message to the MSC, informing it that the resource is ready. The SGSN sends a RELOCATION COMMAND message to the SRNC, informing it that the relocation can start. The MSC sends a RELOCATION COMMAND message to the SRNC, informing it that the relocation can start.
10) The SRNC sends a RELOCATION COMMIT message to the DRNC on the Iur interface. If an RAB supporting lossless relocation exists, the message shall contain the PDCP and GTP-U sequence numbers required for data transfer. Then the SRNC starts data transfer. After receiving the RELOCATION COMMIT message, the DRNC becomes the SRNC. 11) The DRNC sends a RELOCATION DETECT message to the SGSN, informing the SGSN that it detects the relocation triggering. 12) The DRNC sends a RELOCATION DETECT message to the MSC, informing the MSC that it detects the relocation triggering. 13) The DRNC sends a UTRAN MOBILITY INFORMATION message to the UE. The message shall contain the new U-RNTI and so on. 14) The UE returns a UTRAN MOBILITY INFORMATION CONFIRM message to the DRNC. 15) The DRNC sends a RELOCATION COMPLETE message to the SGSN, informing it that the relocation ends successfully. 16) The DRNC sends a RELOCATION COMPLETE message to the MSC, informing it that the relocation ends successfully. 17) The SGSN sends an IU RELEASE COMMAND message to the original SRNC, requesting it to release the Iu connection with the PS domain. 18) The MSC sends an IU RELEASE COMMAND message to the original SRNC, requesting it to release the Iu connection with the CS domain. 19) The original SRNC initiates an Iu interface user plane bearer release procedure using ALCAP. 20) After successful release, the SRNC returns an IU RELEASE COMPLETE message to the MSC. 21) The SRNC returns an IU RELEASE COMPLETE message to the SGSN. The static relocation procedure ends. Note: When the UE has Iu connections with both CS and PS domains, the relocation messages for the two domains are not transmitted in order of precedence order. Take the RELOCATION REQUIRED message for example. The SRNC may either first send the RELOCATION REQUIRED message to the MSC or first send the RELOCATION REQUIRED message to the SGSN. The same applies below.
6.6.3 Relocation with Hard Handover

The relocation with hard handover is a procedure in which the UE performs hard handover to the target RNC and the Iu interface changes. Figure 6-17 illustrates the signalling procedure of relocation with hard handover.
UE SRNC TRNC
1. RELOCATION REQUIRED RANAP 2. RELOCATION REQUIRED RANAP RANAP 4. RELOCATION REQUEST RANAP 5.ALCAP setup 6. RELOCATION REQUEST ACKNOWLEDGE RANAP RANAP 8. RELOCATION COMMAND RANAP 9. RELOCATION COMMAND RANAP 10*. FORWARD SRNS CONTEXT RANAP 11*. FORWARD SRNS CONTEXT 12. PHYSICAL CHANNEL RECONFIGURATION RRC 13. PHYSICAL CHANNEL RECONFIGURATION COMPLETE RANAP RANAP RANAP RANAP RANAP 7. RELOCATION REQUEST ACKNOWLEDGE RANAP RANAP RANAP RANAP 3. RELOCATION REQUEST RANAP
MSC
SGSN
RANAP
RRC RRC
RRC 14. RELOCATION COMPLETE RANAP 15. RELOCATION COMPLETE RANAP RANAP RANAP RANAP
16. IU RELEASE COMMAND RANAP 17. IU RELEASE COMMAND RANAP 18.ALCAP release 19. IU RELEASE COMPLETE RANAP 20. IU RELEASE COMPLETE RANAP RANAP RANAP RANAP
Figure 6-17 Procedure of relocation with hard handover Each step is explained as follows: 1) 2) 3) 4) 5) The SRNC sends a RELOCATION REQUIRED message to the SGSN. The SRNC sends a RELOCATION REQUIRED message to the MSC. The SGSN sends a RELOCATION REQUEST message to the DRNC, requesting the DRNC to make resource preparation for the relocation. The MSC sends a RELOCATION REQUEST message to the DRNC, requesting the DRNC to make resource preparation for the relocation. The DRNC initiates an Iu interface user plane bearer setup procedure using ALCAP.
6)
The DRNC sends a RELOCATION REQUEST ACKNOWLEDGE message to the SGSN, informing it that the resource is ready. The message shall contain the reconfiguration information, indicating a procedure to implement the relocation. This procedure may be the radio bearer setup, radio bearer release, radio bearer reconfiguration, transport channel reconfiguration, or physical channel reconfiguration procedure.
7)
The DRNC sends a RELOCATION REQUEST ACKNOWLEDGE message to the MSC, informing it that the resource is ready. The message shall contain the reconfiguration information, indicating a procedure to implement the relocation. This procedure may be the radio bearer setup, radio bearer release, radio bearer reconfiguration, transport channel reconfiguration, or physical channel reconfiguration procedure.
8) 9)
The SGSN sends a RELOCATION COMMAND message to the SRNC, informing it that the relocation can start. The MSC sends a RELOCATION COMMAND message to the SRNC, informing it that the relocation can start.
10) (Optional) If an RAB supporting lossless relocation exists, the SRNC shall send a FORWARD SRNS CONTEXT message to the SGSN, requesting the SGSN to send the PDCP and GTP-U sequence numbers required for context transfer to the target RNC. Then the system goes to the next step. Otherwise, the system goes to step 12). 11) (Optional) If the SGSN receives a FORWARD SRNS CONTEXT message from the SRNC, it shall forward the message to the target RNC. The message shall contain the PDCP and GTP-U sequence numbers required for context transfer. 12) The SRNC sends a PHYSICAL CHANNEL RECONFIGURATION message to the UE, informing it of the new physical channel parameters. The specific message type sent at this step is determined by the target RNC during resource preparation and sent to the SRNC through steps 6), 7), 8) and 9). 13) After successfully accessing the target RNC, the UE sends a PHYSICAL CHANNEL RECONFIGURATION COMPLETE message to the target RNC. The handover procedure succeeds and the target RNC becomes the new SRNC of the UE. 14) The target RNC sends a RELOCATION COMPLETE message to the SGSN, informing it that the relocation ends successfully. 15) The target RNC sends a RELOCATION COMPLETE message to the MSC, informing it that the relocation ends successfully. 16) The SGSN sends an IU RELEASE COMMAND message to the original SRNC, requesting it to release the Iu connection with the PS domain. 17) The MSC sends an IU RELEASE COMMAND message to the original SRNC, requesting it to release the Iu connection with the CS domain. 18) The original SRNC initiates an Iu interface (including Iu-CS interface and Iu-PS interface) user plane bearer release procedure using ALCAP.
19) The original SRNC returns an IU RELEASE COMPLETE message to the SGSN, indicating that the IU release completes. 20) The original SRNC returns an IU RELEASE COMPLETE message to the MSC, indicating that the IU release completes.
6.6.4 Relocation with Forward Handover

Relocation may occur when the UE performs forward handover between different RNCs. Such relocation is called relocation with forward handover. This section describes the signalling procedure of relocation with forward handover. Figure 6-18 takes the relocation with cell update as an example.
UE SRNC
1.CELL UPDATE RRC RRC 2.UPLINK SIGNALLING TRANSFER INDICATION RNSAP RNSAP 3. RELOCATION REQUIRED RANAP RANAP 5. RELOCATION REQUEST ACKNOWLEDGE RANAP 6. RELOCATION COMMAND RANAP 7.RELOCATION COMMIT RNSAP RNSAP 8.RELOCATION DETECT RANAP 9.CELL UPDATE CONFIRM RRC 10.PHYSICAL CHANNEL RECONFIGURATION COMPLETE RRC RRC 11.RELOCATION COMPLETE RANAP 12.IU RELEASE COMMAND RANAP 13.IU RELEASE COMPLETE RANAP RANAP RANAP RANAP RRC RANAP RANAP RANAP RANAP 4. RELOCATION REQUEST RANAP
DRNC
SGSN
Figure 6-18 Procedure of relocation with cell update Each step is explained as follows: 1) 2) The UE sends a CELL UPDATE message to the DRNC. The message shall contain the S-RNTI, SRNC ID and so on. The DRNC gets the SRNC ID of the UE from the URNTI IE in the CELL UPDATE message. Then the DRNC sends an UPLINK SIGNALING TRANSFER INDICATION message to the SRNC, informing it that the UE requests for cell update. 3) 4) The SRNC sends a RELOCATION REQUIRED message to the SGSN. The SGSN sends a RELOCATION REQUEST message to the DRNC, requesting the DRNC to make resource preparation for the relocation.
5) 6) 7)
The DRNC returns a RELOCATION REQUEST ACKNOWLEDGE message to the SGSN, informing it that the resource is ready. The SGSN sends a RELOCATION COMMAND message to the SRNC, informing it that the relocation can start. The SRNC sends a RELOCATION COMMIT message to the DRNC on the Iur interface. If an RAB supporting lossless relocation exists, the message shall contain the PDCP and GTP-U sequence numbers required for data transfer. Then the SRNC starts data transfer.
8) 9)
The DRNC sends a RELOCATION DETECT message to the SGSN, informing the SGSN that it detects the relocation triggering. The DRNC sends a CELL UPDATE CONFIRM message to the UE. The message may contain the transport channel IE, physical channel IE, radio bearer IE, U-RNTI, and so on.
10) The UE sends a PHYSICAL CHANNEL RECONFIGURATION COMPLETE message to the DRNC. 11) The DRNC sends a RELOCATION COMPLETE message to the SGSN, informing it that the relocation ends successfully. The DRNC becomes the SRNC. 12) The SGSN sends an IU RELEASE COMMAND message to the original SRNC, requesting it to release the Iu connection with the PS domain. 13) After successfully releasing the Iu connection with the PS domain, the original SRNC returns an IU RELEASE COMPLETE message to the SGSN, indicating that the release completes. The relocation procedure with cell update ends.
6.6.5 Relocation Required Message

IE/Group name Message Type Relocation Type Cause Source ID Target ID MS Classmark 2 M M M M M C ifGSMtarget MS Classmark 3 C ifGSMtarget Source RNC To Target RNC C Presence Semantics description
IE/Group name Transparent Container Old BSS To New BSS Information
Presence ifUMTStarget C ifGSMtarget
II. Example
6.6.6 Relocation Request Message

IE/Group name
Presence
Message Type Permanent NAS UE Identity Cause CN Domain Indicator Source RNC To Target RNC Transparent Container RABs To Be Setup List >RABs To Be Setup Item IEs >>RAB ID >>NAS Synchronisation Indicator
M C ifAvail M M M
M C ifNASInfoProvid ed
>>RAB Parameters >>Data Volume Reporting Indication >> PDP Type Information >>User Plane Information >>>User Plane Mode >>>UP Mode Versions >>Transport Layer Address >>Iu Transport Association >>Service Handover Integrity Protection Information Encryption Information Iu Signalling Connection Identifier
M C ifPS
C ifPS M M M M M O C ifAvail O M
II. Example
6.6.7 Relocation Command Message

I. Messaage Structure
IE/Group name Presence IE type and reference
IE/Group name
Presence
IE type and reference
Message Type Target RNC To Source RNC Transparent Container
M CifRecdFromRelocT arget
L3 Information
CifRecdFromRelocT arget
RABs To Be Released List >RABs To Be Released Item IEs >>RAB ID RABs Subject To Data Forwarding List >RABs Subject To Data Forwarding Item IEs >>RAB ID >>Transport Layer Address >>Iu Transport Association Criticality Diagnostics
M C - ifPS
M M M O
II. Example
6.6.8 UTRAN Mobility Information Message

IE/Group name Message Type UE Information Elements Integrity check info RRC transaction identifier Integrity protection mode info Ciphering mode info New U-RNTI New C-RNTI UE Timers and constants in connected mode CN Information Elements CN Information info UTRAN Information Elements URA identity RB Information elements Downlink counter synchronisation info >RB with PDCP information list >>RB with PDCP information OP MP OP OP OP CH MP OP OP OP OP OP Presence MP Semantics description
II. Example
6.6.9 Uplink Signalling Transfer Indication Message

IE/Group name Message Type Transaction ID UC-Id SAI Cell GAI C-RNTI S-RNTI D-RNTI Propagation Delay STTD Support Indicator Closed Loop Mode1 Support Indicator Closed Loop Mode2 Support Indicator L3 Information CN PS Domain Identifier CN CS Domain Identifier URA Information M O O O M M M M M O M M O M M M Presence Semantics description
II. Example
Chapter 7 Dynamic Resource Control Procedure Analysis

7.1 Overview
Dynamic resource control is the process to control the radio resources through such means as the channel reconfiguration, radio bearer (RB) reconfiguration and so on. In this way, it can achieve appropriate allocation and efficient utilization of the resources. In this chapter, we will describe the dynamic resource control process through examples, including: RAB modification Dynamic channel reconfiguration
7.2 RAB Modification

7.2.1 Overview
When the service parameters change, the RAB modification procedure shall be initiated by the CN to reconfigure the RAB to adapt to the QoS change. This procedure is initiated by the CN and implemented by the UTRAN. Corresponding to the RAB setup and release procedures, RAB modification has the following four kinds according to the RRC connection status before and after the RAB modification: DCH-DCH: The RRC connection is in CELL_DCH state before the RAB modification and also in CELL_DCH state after the RAB modification. CCH-CCH: The RRC connection is in CELL_FACH state before the RAB modification and also in CELL_FACH state after the RAB modification. CCH-DCH: The RRC connection is in CELL_FACH state before the RAB modification and in CELL_DCH state after the RAB modification. DCH-CCH: The RRC connection is in CELL_DCH state before the RAB modification and in CELL_FACH state after the RAB modification. This section describes only the DCH-DCH RAB modification procedure. Other kinds of procedures can be deduced by analogy.
7.2.2 RAB Modification (DCH-DCH)

Similar to the RAB setup procedure, the DCH-DCH RAB modification procedure can also be implemented through the following two ways:
Synchronous radio link reconfiguration Asynchronous radio link reconfiguration This section describes only the DCH-DCH RAB modification procedure in the case of synchronous radio link reconfiguration as shown in Figure 7-1.
UE NodeB Serving RNS Serving RNC
RANAP 1. RAB ASSIGNMENT REQUEST [Modify]
CN
RANAP
2. Select L1, L2 and Data Iu Transport Bearer parameters e.g. for Radio Bearer reconfiguration.)
3. ALCAP Iu Data Transport Bearer Modify 4.RADIO LINK RECONFIGURATION PREPARE NBAP 5.RADIO LINK RECONFIGURATION READY NBAP NBAP
NBAP
ALCAP
Iub Data Transport Bearer Modify
RRC
6.DCCH: RADIO BEARER RECONFIGURATION 7.RADIO LINK ECONFIGURATION COMMIT
RRC NBAP
NBAP
Actualizing Radio Bearer modification (e.g. Apply new transport format set) 8 .DCCH: RADIO BEARER RECONFIGURATION COMPLETE
RRC
RRC 9. RAB ASSIGNMENT RESPONSE RANAP
RANAP
Figure 7-1 RAB modification procedure (DCH-DCH, synchronous) Each step is explained as follows: 1) The CN sends an RAB ASSIGNMENT REQUEST [Modify] message to initiate an RAB modification procedure. The message shall indicate the RAB ID, modified RAB information, user plane information, transport network layer information, and so on. 2) 3) 4) 5) The SRNC selects the parameters to be modified and the corresponding reconfiguration procedures. The SRNC modifies the channel characteristics of the Iu interface data transport bearer using ALCAP if the Iu interface user plane is over AAL2. The SRNC sends a RADIO LINK RECONFIGURATION PREPARE message to the NodeB on the Iub interface to initiate a radio link reconfiguration procedure. The NodeB returns a RADIO LINK RECONFIGURATION READY message to the SRNC on the Iub interface.
6)
After the Iu interface transport control plane and the Iub radio link are successfully modified, the SRNC sends a RADIO BEARER RECONFIGURATION message to the UE on the DCCH. The message shall contain the RAB information, RAB ID, and so on.
7)
The SRNC sends a RADIO LINK RECONFIGURATION COMMIT message to the NodeB. The message shall contain the CFN IE. When the next CFN indicated by the IE is received, the NodeB shall use the prepared new configuration.
8) 9)
The UE returns a RADIO BEARER SETUP COMPLETE message to the SRNC. The SRNC sends a RANAP message RADIO BEARER ASSIGNMENT RESPONSE to the CN, confirming that the RAB modification procedure succeeds. The RAB modification procedure ends.
7.2.3 RAB Assignment Request Message

Refer to section 5.6.5 RAB Assignment Request Message.
7.2.4 Radio Bearer Reconfiguration Message

IE/Group name Message Type UE Information elements RRC transaction identifier Integrity check info Integrity protection mode info Ciphering mode info Activation time New U-RNTI New C-RNTI RRC State Indicator UTRAN DRX cycle length coefficient CN information elements CN Information info UTRAN mobility information
Presence MP
OP
IE/Group name elements URA identity RB information elements RAB information to reconfigure list >RAB information to reconfigure RB information to reconfigure list >RB information to reconfigure RB information to be affected list >RB information to be affected TrCH information elements Uplink transport channels UL Transport channel information common for all transport channels Deleted TrCH information list
Presence
OP
OP MP MP MP OP MP
OP
OP
>Deleted UL TrCH information Added or Reconfigured TrCH information list >Added or Reconfigured UL TrCH information CHOICE mode >FDD >>CPCH set ID >>Added or Reconfigured TrCH information for DRAC list >>>DRAC static information >TDD
MP OP
MP
OP
OP OP
MP
IE/Group name Downlink transport channels DL Transport channel information common for all transport channels Deleted TrCH information list
Presence
OP
OP
>Deleted DL TrCH information Added or Reconfigured TrCH information list >Added or Reconfigured DL TrCH information PhyCH information elements Frequency info Uplink radio resources Maximum allowed UL TX power CHOICE channel requirement >Uplink DPCH info >CPCH SET Info Downlink radio resources CHOICE mode >FDD >>Downlink PDSCH information >TDD Downlink information common for all radio links Downlink information per radio link list >Downlink information for each radio link
MP OP
MP
MD MD OP MP OP OP
MP
MP
II. Example
7.3 Dynamic Channel Reconfiguration

7.3.1 Overview
When the UE initiates a service request, the RNC shall allocate an appropriate channel bandwidth as per the requested QoS. The RNC keeps monitoring the traffic measurement, downlink code transmit power, and so on during the service process. When there is a change in the rate of service origin or the quality of air interface, the RNC adjusts the channel bandwidth to satisfy the new requirement of the service origin. This procedure is called dynamic channel reconfiguration. The RNC informs the UE of the new radio link parameters through this.
7.3.2 Radio Bearer Reconfiguration

The radio bearer reconfiguration procedure is used to reconfigure a radio bearer. This section describes the dynamic channel reconfiguration procedure, as illustrated in Figure 7-2, with radio bearer reconfiguration as an example. The RRC connection of the UE is in CELL_FACH state before the radio bearer reconfiguration and in CELL_DCH state after the radio bearer reconfiguration.
UE NodeB
1. RADIO LINK SETUP REQUEST NBAP 2. RADIO LINK SETUP RESPONSE NBAP NBAP NBAP
CRNC
3. ALCAP
RRC
Data Transport Bearer setup
4.RADIO BEARER RECONFIGURATION RRC 5. RADIO BEARER RECONFIGURATION COMPLETE 6. RADIO LINK RESTORE NBAP NBAP
RRC
RRC
Figure 7-2 Radio bearer reconfiguration procedure (CCH-DCH) Each step is explained as follows: 1) 2) 3) The CRNC sends a RADIO LINK SETUP REQUEST message to the NodeB to which the target cell belongs. The NodeB returns a RADIO LINK SETUP RESPONSE message to the CRNC. The CRNC sets up an Iub interface transport bearer between the CRNC and the NodeB using ALCAP and implements synchronization using Frame Protocol (FP). 4) The CRNC sends a RADIO BEARER RECONFIGURATION message to the UE on the downlink DCCH. The message shall contain the target cell information and the target RRC connection status of the UE.
5)
After successfully handed over to the target cell, the UE sends a RADIO BEARER RECONFIGURATION COMPLETE message to the CRNC on the DCCH.
6)
After detecting the uplink synchronization of the new radio link, the NodeB sends a RADIO LINK RESTORE INDICATION message to the CRNC. The message shall contain the information about the radio link detected as synchronized. The radio bearer reconfiguration procedure ends.
7.3.3 Radio Bearer Reconfiguration Message

Refer to section 7.2.4 Radio Bearer Reconfiguration Message.
Appendix A Tracing Tools
Appendix A Tracing Tools

A.1 About Tracing Tools
You can browse the signalling procedures and the content of each message described in this manual through the message tracing tools integrated in LMTs of Huawei RNC and NodeB.
A.1.1 RNC Tracing Tool

Refer to HUAWEI BSC6800 WCDMA Radio Network Controller Operation Manual Routine Operation for the details of how to use the tracing tool.
A.1.2 NodeB Tracing Tool

Refer to WCDMA NodeB Operation Manual Routine Operation for the details of how to use the tracing tool.
Huawei Technologies Proprietary A-1
Appendix B A Typical Call Procedure

B.1 Overview
This appendix illustrates a typical call procedure in UTRAN through a calling procedure and a called procedure.
B.2 Calling Procedure

Calling procedure is a procedure in which a UE calls another subscriber for example, a PSTN subscriber. Figure B-1 illustrates a specific calling procedure, which generally consists of the following steps: 1) RRC connection setup
To make a call, the UE initiates an RRC connection setup procedure to set up a signalling connection to the RNC. For details, see section 5.3 RRC Connection Setup. 2) Signalling connection setup
The RNC sets up a signalling connection to the CN. For details, see section 5.4 Direct Transfer. 3) RAB setup
The CN responds to the service request from the UE and requests the RNC to set up the corresponding RAB. After successful RAB setup, the called party answers the call and the two parties start the communication. For details, see section 5.6 RAB Setup. 4) Signalling connection release
Upon completion of the call, the signalling connection between the RNC and the CN shall be released. For details, see section 5.7 Call Release. 5) RAB release
The RAB shall be released. For details, see section 5.7 Call Release. 6) RRC connection release
The RRC connection between the UE and the RNC shall be released if the RRC connection bears no other RABs. For details, see section 5.7 Call Release.
Huawei Technologies Proprietary B-1

UE
RRC

SRNC
RRC NBAP
NodeB SRNS
CCCH : RRC CONNECTION REQUEST RADIO LINK SETUP REQUEST NBAP Start RX RADIO LINK SETUP RESPONSE NBAP ALCAP
CN
NBAP
Iub Data Transport Bearer Setup
Start TX CCCH : RRC CONNECTION SETUP RRC RRC RRC DCCH : RRC CONNECTION SETUP COMPLETE DCCH :INITAL DIRECT TRANSFER RRC RRC RRC RANAP RANAP RRC RRC RRC DCCH DOWNLINK DIRECT TRANSFER DCCH : UPLINK DIRECT TRANSFER RRC RRC RANAP RANAP RRC RRC DOWNLINK DIRECT TRANSFER DCCH DCCH UPLINK DIRECT TRANSFER RRC RRC RAB ASSIGNMENT REQUEST RANAP ALCAP RADIO LINK RECONFIGURATION PREPARE NBAP NBAP RADIO LINK RECONFIGURATION READY NBAP NBAP (Establishment) RANAP DIRECT TRANSFER (Setup) DIRECT TRANSFER (Call Proceeding) RANAP RANAP INNTIAL UE MESSAGE (CM Service Request) DIRECT TRANSFER (CM Service Accept) RANAP RANAP
Iur Data Transport Bearer Setup
UE
NodeB SRNS
ALCAP
SRNC
CN
RRC
DCCH : RADIO BEARER SETUP
RRC RADIO LINK RECONFIGURATION NBAP NBAP COMMIT
Apply new transport format set RRC DCCH : RADIO BEARER SETUP COMPLETE RRC RANAP RAB ASSIGNMENT RESPONSE RANAP (Establish) DIRECT TRANSFER (Alerting) DIRECT TRANSFER (Connect) RANAP
RANAP RRC DCCH DOWNLINK DIRECT TRANSFER RRC RANAP RRC RRC DCCHDOWNLINK DIRECT TRANSFER DCCH: UPLINK DIRECT TRANSFER RRC RRC RANAP RRC DCCH: UPLINK DIRECT TRANSFER RRC RANAP RANAP RRC RRC DCCH: DOWNLINK DIRECT TRANSFER DCCH: UPLINK DIRECT TRANSFER RRC RRC RANAP RANAP
RANAP
DIRECT TRANSFER (Connect Acknowledge) DIRECT TRANSFER (Disconnect) DIRECT TRANSFER ( Release)
RANAP
RANAP RANAP
DIRECT TRANSFER (Release Complete) IU RELEASE COMMANDE
RANAP RANAP
ALCAP Iu Data Transport Bearer Release IU RELEASE COMPLETE
RANAP RRC RRC DCCH : RRC CONNECTION RELEASE DCCH : RRC CONNECTION RELEASE NBAP COMPLETE RRC RRC NBAP
RANAP
RADIO LINK DELETION
RADIO LINK DELETION COMPLETE NBAP NBAP ALCAP Iub Data Transport Bearer Release
Figure B-1 Calling procedure
B.3 Called procedure

Called procedure is a procedure in which the network side pages a UE and the UE responds to the paging. Upon reception of a paging message, the UE shall initiate an RRC connection setup procedure. The called procedure generally consists of the following steps: 1) Paging
The network side pages the UE. For details, see section 5.2 Paging. 2) RRC connection setup
The UE answers the call, initiating an RRC connection setup procedure to the RNC. For details, see section 5.3 RRC Connection Setup. 3) Signalling connection setup and direct transfer
The RNC sets up a signalling connection to the CN. For details, see section 5.4 Direct Transfer. 4) RAB setup
The CN requests the RNC to set up the corresponding RAB. After successful RAB setup, the UE exchanges signalling messages with the CN and starts the communication with the caller. For details, see section 5.6 RAB Setup. 5) Signalling connection release
Upon completion of the call, the signalling connection between the RNC and the CN shall be released. For details, see section 5.7 Call Release. 6) RAB release
The RAB shall be released. For details, see section 5.7 Call Release. 7) RRC release
The RRC connection between the UE and the RNC shall be released if the RRC bears no other RABs. For details, see section 5.7 Call Release. Figure B-2 illustrates a specific called procedure.
UE
NodeB SRNS
SRNC
PAGING
CN
RANAP
RANAP PAGING TYPE 1 RRC RRC CCCH: RRC CONNECTION REQUEST RRC RRC RADIO LINK SETUP REQUEST NBAP NBAP
Start RX NBAP ALCAP RADIO LINK SETUP RESPONSE NBAP
Start TX RRC RRC RRC CCCH : RRC CONNECTION SETUP DCCH : RRC CONNECTION SETUP COMPLETE DCCH : INITAL DIRECT TRANSFER RRC RRC RRC INITIAL UE MESSAGE RANAP (Paging Response) RANAP RRC RRC RRC DCCH: DOWNLINK DIRECT TRANSFER : DCCH : UPLINK DIRECT TRANSFER RRC RRC RANAP DIRECT TRANSFER (Call Confirm) RANAP DIRECT TRANSFER (Set Up) RANAP RANAP
RAB ASSIGNRMENT REQUEST RANAP RANAP (Establishment) ALCAP Iu Data Transport Bearer Setup
RAKIO LINK RECONFIGURATION NBAP NBAP PREPARE RADIO LINK RECONFIGURATION NBAP READY NBAP
UE
NodeB SRNS
ALCAP
SRNC
Iub Data Transport Bearer Setup RRC NBAP
CN
RRC
DCCH : RADIO BEARER SETUP RADIO LINK RECONFIGURATION NBAP COMMIT Apply new transport format set DCCH : RADIO BEARER SETUP COMPLETE
RRC
RRC RAB ASSIGNMENT RESPONSE RANAP (Establishment) RRC RANAP DIRECT TRANSFER ( Alerting) DIRECT TRANSFER (Connect) DIRECT TRANSFER (Connect Acknowledge) RRC RANAP DIRECT TRANSFER (Disconnect) RANAP RANAP RANAP
RRC
UPLINK DIRECT TRANSFER DCCH
RRC
UPLINK DIRECT TRANSFER DCCH
RRC RANAP RANAP RANAP RANAP
RRC
DOWNLINK DIRECT TRANSFER DCCH
RRC RRC
DOWNLINK DIRECT TRANSFER DCCH DCCHUPLINK DIRECT TRANSFER
RRC RRC RANAP RANAP DIRECT TRANSFER (Release) DIRECT TRANSFER (ReleaseComplete) RANAP RANAP
RRC
DOWNLINK DIRECT TRANSFER DCCH
RRC RANAP IU RELEASE COMMAND RANAP
ALCAP
Iu Data Transport Bearer Release IU RELEASE COMPLETE
RANAP RRC RRC RRC CONNECTION RELEASE DCCH RRC CONNECTION RELEASE COMPLETE DCCH NBAP RADIO LINK DELETION RRC RRC NBAP
RANAP
RADIO LINK DELETION COMPLETE NBAP NBAP ALCAP Iub Data Transport Bearer Release
Figure B-2 Called procedure
Appendix C
Acronyms and Abbreviations
Appendix C Acronyms and Abbreviations

A AAL AAL2 AAL5 AICH ALCAP AMR ATM B BCCH BCH BFN BMC BSC BSC6800 BSS C CA-ICH CBC CBS CC CCCH CCH CCTrcH Channel assignment indication channel Cell Broadcast Center Cell Broadcast Service Call Control Common Control Channel Common transport channel Coded Composite Transport Channel Broadcast Control CHannel Broadcast Channel NodeB Frame Number Counter Broadcast/Multicast Control protocol Base Station Controller Huawei RNC Model Base Station Subsystem ATM Adaptation Layer ATM Adaptation Layer type 2 ATM Adaptation Layer Type 5 Acquisition Indicator Channel Access Link Control Application Part Adaptive Multi-Rate Asynchronous Transfer Mode
Huawei Technologies Proprietary C-1
Appendix C
CFN CN CPCH CPCS CPICH CRC CRNC C-RNTI CS CSICH D DCCH DCH DPC DPCCH DPCH DPDCH DRNC DRNS DRX DSCH F FACH FDD FER G GPRS
Connection Frame Number Core Network Common Packet Channel Common Part Convergence Sublayer Common Pilot Channel Cyclic Redundancy Check Controlling RNC Cell Radio Network Temporary Identifier Circuit-Switched CPCH status indication channel
Dedicated Control CHannel Dedicated CHannel Destination (Signaling)Point Code Dedicated Physical Control Channel Dedicated Physical Channel Dedicated Physical Data Channel Drift RNC Drift RNS Discontinuous Reception Downlink Shared Channel
Forward Access Channel Frequency Division Duplex Frame Error Rate
General Packet Radio Service
Appendix C
GSM GTP-U I IE IMSI IP ISUP
Global System for Mobile Communications User plane part of GPRS tunneling protocol
Information Element International Mobile Station Identity Internet Protocol Integrated Services Digital Network User Part/ISDN User Part
ITU-T
International Telecommunication Union - Telecommunication Standardization Sector
IU IUR L LAI M MAC MIB MM MS MSC MSU MTP MTP3 N NAS NBAP NNI NodeB
Iu Interface Iur Interface
Location Area Identity
Medium Access Control Master Information Block Mobility Management Mobile Station Mobile Switching Center Message Signalling Unit Message Transfer Part Message Transfer Part Layer 3
Non-Access Stratum NodeB Application Part Network Node Interface (Network-to-Network) WCDMA Base Station
Appendix C
O OAM OPC P PCCH PCCPCH PCH PCP PCPCH PCPICH PDCP PDP PDSCH PICH PLMN PRACH PS PSCH PSTN Q QoS R RAB RACH RANAP RB RFN Radio Access Bearer Random Access CHannel Radio Access Network Application Part Radio Bearer RNC Frame Number counter Quality of Service Paging Channel (logical Channel) Primary Common Control Physical Channel Paging Channel Power Control Preamble Physical Common Packet Channel Primary Common Pilot Channel Packet Data Convergence Protocol Packet Data Protocol Physical Downlink Shared Channel Paging Indicator Channel Public Land Mobile Network Packet Random Access Channel Packet Switched Physical shared channel Public Switched Telephone Network Operation Administration and Maintenance Originating Point Code
Appendix C
RNC RNS RNSAP RNTI RRC RTWP S SAAL SABP SAR SCCP SCCPCH SCH SCPICH SDU SGSN SI SIB SIF SIO SIR SLS SRB SRNC SRNS SS7 SSCF
Radio Network Controller Radio Network Subsystem Radio Network Subsystem Application Part Radio Network Temporary Identity Radio Resource Control Received Total Wide band Power
Signaling ATM Adaptation Layer Service Area Broadcast Protocol Segmentation And Reassembly Signaling Connection and Control Part Secondary Common Control Physical Channel Synchronization CHannel Secondary Common Pilot Channel Service Data Unit Serving GPRS Support Node Service Indicator System Information Block Signaling Information Field Service Information Octet Signal-Interference Ratio Signaling Link Selection Signalling radio bearer Serving RNC Serving RNS Signaling System Number 7 Service Specific Coordination Function
Appendix C
SSCH SSCOP SSCS SSN STC STTD T TB TBS TDD TFC TFCI TFI ToA ToAWE ToAWS TPC TTI U UE UMTS
Secondary Synchronization CHannel Service Specific Connection Oriented Protocol Service Specific Convergence Sublayer Sub-System Number Signaling Transport Converter Space Time Transmit Diversity
Transport Block Transport Block Set Time Division Duplex Transport Format Combination Transmit Format Combined Indicator Transport Format Indicator Time of Arrival Time of Arrival Window Endpoint Time of Arrival Window Startpoint Transmit Power Control Transmission Time Interval
User Equipment Universal mobile telecommunication services/Universal Mobile Telecommunications System
UNI UP URA U-RNTI UTRAN UU
Logical User-Network Interface User Plane UTRAN Registration Area UTRAN Radio Network Temporary Identifier UMTS Terrestrial Radio Access Network Uu Interface
Appendix C
VW VP WCDMA Video Phone Wideband CDMA
Index
Index
A
active set update message, 6-13 ALCAP, 2-27 audit response message, 3-12
D
DCH-DCH, 5-27 direct transfer message, 5-18 disconnection of signaling link, 2-20 DL timing adjustment, 1-13 DL transport channel synchronization, 1-12 downlink data transfer, 1-15 downlink direct transfer, 5-20 downlink direct transfer message, 5-24 downlink timing adjustment, 1-18 downlink transport channel sychronization, 1-17 dynamic channel reconfiguration, 7-6 dynamic resource control procedure analysis, 7-1
B
blocking of AAL2 path, 2-28 BMC, 1-6
C
call example, B-1 call release, 5-43 call setup and release procedure analysis, 5-1 CCH-CCH, 5-32 CCH-DCH, 5-31 cell deletion procedure, 3-7 cell reconfiguration procedure, 3-6 cell related procedure analysis, 3-1 cell setup procedure, 3-3 cell setup request message, 3-16 cell update, 6-1 cell update message, 6-4 changback, 2-19 changeover, 2-19 class 1 elementary procedure, 1-21, 1-27 class 2 elementary procedure, 1-21, 1-28 class 3 elementary procedure, 1-29 combined hard handover, 6-19 combined release, 5-47 common measurement initiation procedure, 3-5 common transport Channel setup procedure, 3-4 common transport channel setup request, 3-20 compressed mode, 6-16 connection request message, 2-34 CPCS, 2-8 CS domain service release, 5-43
E
error event, 1-33 establish request message, 2-30 establishment of AAL2 connection, 2-28 example of cell setup procedure, 3-28
F
FACH data transfer, 1-11 forward handover, 6-1 frame quality classification, 1-33 function of Iu UP, 1-29 function of NBAP, 1-7 function of RANAP, 1-25 function of RNSAP, 1-19 function of SABP, 1-34 function of system information, 4-2
G
GSM/GPRS->WCDMA cell reselection, 6-29 GSM->WCDMA inter-RAT handover, 6-27 GTP-U, 1-34
i-1
Index cell update, 6-4 common transport channel setup request, 3-20 connection request, 2-34 downlink direct transfer, 5-24 establish request, 2-30 handover from UTRAN command, 6-32 handover to UTRAN command, 6-33 initial direct transfer, 5-21 MTP3-B management, 2-26 MTP3-B test, 2-25 MTP3-B upper user, 2-24 paging type 1, 5-3 paging type 2, 5-4 physical channel reconfiguration, 6-22 RAB assignment request, 5-33 RAB assignment response, 5-36 radio bearer reconfiguration, 7-3 radio bearer setup, 5-38 radio link setup request, 5-14 relocation command, 6-46 relocation request, 6-44 resource status indication, 3-7 RRC connection reject, 5-14 RRC connection request, 5-8 RRC connection setup, 5-11 SSCOP, 2-10 system information, 4-4 system information update request, 3-26 uplink direct transfer, 5-23 uplink signaling transfer indication, 6-51 URA update, 6-7 UTRAN mobility information, 6-49 message discrimination, 2-12 message distribution, 2-13 message routing, 2-13 message structure, 2-14, 2-30, 2-33 mobility management procedure analysis, 6-1 modification by a timer, 4-8 modification by a value tag, 4-7 MTP3-B, 2-11 MTP3-B management message, 2-26 MTP3-B test message, 2-25
H
handover from UTRAN command message, 6-32 handover to UTRAN command message, 6-33 hard handover, 6-15 heading code, 2-17
I
initial direct transfer, 5-18 initial direct transfer message, 5-21 initialisation procedure, 1-31 Inter-RAT handover, 6-24 Iu interface, 1-23 Iu interface specification, 1-25 Iu protocol architecture, 1-23 Iu rate control, 1-31 Iu signaling connection release, 5-43 Iub FP common transport channel data transfer, 1-10 dedicated transport channel data transfer, 1-14 Iub interface, 1-6 Iub interface specification, 1-7 Iub interface user plane setup, 3-4 Iub protocol structure, 1-6 Iur FP transport channel data transfer, 1-22 Iur interface, 1-18 Iur interface hard handover, 6-17 Iur interface specification, 1-19 Iur protocol structure, 1-18
L
L1 function, 1-6 L2 function, 1-5 LM, 2-9
M
MAC, 1-5 management prohibit, 2-19 message active set update, 6-13 audit response, 3-12 cell setup request, 3-16 i-2
Protocols and Signalling Analysis HUAWEI UMTS Radio Access Network MTP3-B upper user message, 2-24
Index system information broadcast and update, 4-3 system information modification, 4-7 UE capability information, 5-25 procedure Involved in cell setup, 3-1 Protocol stack of Iub interface, 1-7 protocol stack of Iu-BC interface, 1-24 protocol stack of Iu-CS interface, 1-23 protocol stack of Iu-PS interface, 1-24 protocol stack of Iur interface, 1-19 protocol structure of MTP3-B, 2-12 PS domain service release, 5-43
N
NBAP common procedure, 1-9 NBAP dedicated procedure, 1-9 NBAP procedure, 1-9 Node synchronization, 1-12, 1-16 NodeB tracing tool, A-1
O
originating call procedure, B-1 outer loop power control transfer, 1-15
R
RAB assignment request message, 5-33 RAB assignment response message, 5-36 RAB modification, 7-1 RAB modification (DCH-DCH), 7-1 RAB release, 5-45 RAB setup, 5-27 RACH data transfer, 1-11 radio bearer reconfiguration message, 7-3 radio bearer setup message, 5-38 radio interface parameter update, 1-16 radio link addition, 6-9 radio link addition and deletion, 6-12 radio link deletion, 6-10 radio link setup request message, 5-14 RANAP procedure, 1-27 release of AAL2 connection, 2-28 relocation, 6-35 relocation command message, 6-46 relocation request message, 6-44 relocation with forward handover, 6-41 relocation with hard handover, 6-39 reset, 2-29 resource audit procedure, 3-2 resource status indication message, 3-7 resource status indication procedure, 3-1 RLC, 1-5 RNC tracing tool, A-1 RNSAP procedure, 1-20 RRC connection reject, 5-7
P
paging, 5-1 UE in CELL_DCH state, 5-3 UE in CELL_FACH state, 5-3 UE in idle mode, 5-2 UE in PCH state, 5-2 paging type 1 message, 5-3 paging type 2 message, 5-4 PCH data transfer, 1-11 PDCP, 1-5 physical channel reconfiguration message, 6-22 procedure ALCAP, 2-27 call release, 5-43 cell setup, 3-1 direct transfer message, 5-18 dynamic channel reconfiguration, 7-6 forward handover, 6-1 hard handover, 6-15 inter-RAT handover, 6-24 MTP3-B, 2-11 paging, 5-1 RAB modification, 7-1 RAB setup, 5-27 relocation, 6-35 RRC connection setup, 5-5 SAAL, 2-1 SCCP, 2-31 soft handover, 6-8
i-3
Protocols and Signalling Analysis HUAWEI UMTS Radio Access Network RRC connection reject message, 5-14 RRC connection release, 5-49 on CCH, 5-50 on DCH, 5-49 RRC connection request message, 5-8 RRC connection setup, 5-5 on common channel, 5-7 on dedicated channel, 5-6 RRC connection setup message, 5-11 RRC function, 1-4 system information modification, 4-7
Index
system information monitoring mechanism, 4-2 system information procedure analysis, 4-1 system information structure, 4-1 system information update, 3-5, 4-4 system information update request message, 3-26
T
terminated call procedure, B-4 time alignment procedure, 1-32 ToA, 1-13 ToAWE, 1-13 ToAWS, 1-13 tool NodeB message tracing, A-1 RNC message tracing, A-1 transport network layer procedure analysis, 2-1
S
SAAL, 2-1 SAAL Structure, 2-1 SAR, 2-9 SCCP, 2-31 service indicator (SI), 2-15 service information octet(SIO), 2-14 signaling connection release, 5-44 signaling connection release request, 5-43 signaling information field (SIF), 2-15 signaling link connecting, 2-21 signaling link fault, 2-20 signaling link management, 2-14 signaling link restoration, 2-20 signaling network management message, 2-16 signaling route management, 2-14 signaling traffic management, 2-13 soft handover, 6-8 SSCF, 2-7 SSCOP, 2-2 SSCOP connection release, 2-5 SSCOP connection setup, 2-5 SSCOP data transmission, 2-6 SSCOP error recovery, 2-6 SSCOP message, 2-10 SSCOP operation state, 2-4 static relocation, 6-36 synchronized radio link reconfiguration, 5-28 system information broadcast, 4-3 system information broadcast and update, 4-3 system information message, 4-4
U
UE capability enquiry, 5-26 UE capability information, 5-25 UE capability information update, 5-26 unblocking of AAL2 path, 2-28 unsynchronized radio link reconfiguration, 5-29 uplink data transfer, 1-14 uplink direct transfer, 5-19 uplink direct transfer message, 5-23 uplink signaling transfer indication message, 6-51 URA update, 6-3 URA update message, 6-7 user data transfer, 1-30 UTRAN interface function, 1-1 UTRAN interface protocol, 1-1 UTRAN interface protocol and function, 1-1 UTRAN interfaces, 1-1 UTRAN mobility information message, 6-49 Uu interface, 1-2
W
WCDMA->GSM inter-RAT handover, 6-25 WCDMA->GSM/GPRS cell reselection, 6-29
i-4

Radio Access Network Protocols and Signalling Analysis Inc Iu Intfce

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Radio Access Network Protocols and Signalling Analysis Inc Iu Intfce

Uploaded by

Copyright:

Available Formats

HUAWEI UMTS Radio Access Network Protocols and Signalling Analysis

Huawei Technologies Proprietary

HUAWEI UMTS Radio Access Network Protocols and Signalling Analysis

Huawei Technologies Co., Ltd.

Huawei Technologies Proprietary

Copyright 2005 Huawei Technologies Co., Ltd.

All Rights Reserved

, HUAWEI, C&C08, EAST8000, HONET,

, ViewPoint, INtess, ETS, DMC,

Huawei Technologies Proprietary

Updates Made between Versions 1.23 and 1.22

Huawei Technologies Proprietary

About This Manual

Huawei Technologies Proprietary

Protocols and Signalling Analysis HUAWEI UMTS Radio Access Network

Protocols and Signalling Analysis HUAWEI UMTS Radio Access Network

Protocols and Signalling Analysis HUAWEI UMTS Radio Access Network

Protocols and Signalling Analysis HUAWEI UMTS Radio Access Network

Protocols and Signalling Analysis HUAWEI UMTS Radio Access Network

Huawei Technologies Proprietary v

Protocols and Signalling Analysis HUAWEI UMTS Radio Access Network

Chapter 1 UTRAN Interface Protocols and Functions

Chapter 1 UTRAN Interface Protocols and Functions

Huawei Technologies Proprietary 1-1

Protocols and Signalling Analysis HUAWEI UMTS Radio Access Network

Chapter 1 UTRAN Interface Protocols and Functions

Huawei Technologies Proprietary 1-2

Protocols and Signalling Analysis HUAWEI UMTS Radio Access Network

Chapter 1 UTRAN Interface Protocols and Functions

Duplication avoidance GC C-plane signalling Nt DC UuS boundary U-plane information

RRC co ntr co ntr co co ntr ntr

RLC RLC RLC RLC

Logical Channels MAC

Huawei Technologies Proprietary 1-3

Protocols and Signalling Analysis HUAWEI UMTS Radio Access Network

Chapter 1 UTRAN Interface Protocols and Functions

RLC RLC TS25.322 RLC

Logical Channels TS25.321

Figure 1-3 Uu interface technical specifications

1.2.2 RRC Functions

Protocols and Signalling Analysis HUAWEI UMTS Radio Access Network

Chapter 1 UTRAN Interface Protocols and Functions

Protocols and Signalling Analysis HUAWEI UMTS Radio Access Network

Chapter 1 UTRAN Interface Protocols and Functions

1.3 Iub Interface

Huawei Technologies Proprietary 1-6

Protocols and Signalling Analysis HUAWEI UMTS Radio Access Network

Chapter 1 UTRAN Interface Protocols and Functions

Radio Network Layer

User Plane FACH FP RACH FP DCH FP PCH FP

Radio Network Layer

Radio Network Control Plane

TS 25.433 Transport Network Control Plane

(Common Channel Transport)

TS 25.431 Physical Layer

Figure 1-5 Iub interface technical specifications

1.3.2 NBAP Functions

Protocols and Signalling Analysis HUAWEI UMTS Radio Access Network

Chapter 1 UTRAN Interface Protocols and Functions

Huawei Technologies Proprietary 1-8

Protocols and Signalling Analysis HUAWEI UMTS Radio Access Network

Chapter 1 UTRAN Interface Protocols and Functions

1.3.3 NBAP Procedures

I. NBAP Common Procedures