Interface Protocol and Signaling Flow

7/30/2019 Interface Protocol and Signaling Flow

http://slidepdf.com/reader/full/interface-protocol-and-signaling-flow 1/49

WR_BT06_E1_0

Interface Protocol and Signaling Flow

ZTE CORPORATIONZTE Plaza, Keji Road South,Hi-Tech Industrial Park,Nanshan District, Shenzhen,P. R. China518057 Tel: (86) 755 26771900 800-9830-9830Fax: (86) 755 26772236URL: http://support.zte.com.cnE-mail: [email protected]

http://support.zte.com.cn/


mailto:[email protected]

mailto:[email protected]




LEGAL INFORMATION

Copyright © 2006 ZTE CORPORATION.

The contents of this document are protected by copyright laws and international treaties. Any

reproduction or distribution of this document or any portion of this document, in any form by anymeans, without the prior written consent of ZTE CORPORATION is prohibited. Additionally, thecontents of this document are protected by contractual confidentiality obligations.

All company, brand and product names are trade or service marks, or registered trade or servicemarks, of ZTE CORPORATION or of their respective owners.

This document is provided “as is”, and all express, implied, or statutory warranties, representationsor conditions are disclaimed, including without limitation any implied warranty of merchantability,fitness for a particular purpose, title or non-infringement. ZTE CORPORATION and its licensors shallnot be liable for damages resulting from the use of or reliance on the information contained herein.

ZTE CORPORATION or its licensors may have current or pending intellectual property rights orapplications covering the subject matter of this document. Except as expressly provided in anywritten license between ZTE CORPORATION and its licensee, the user of this document shall notacquire any license to the subject matter herein.

The contents of this document and all policies of ZTE CORPORATION, including without limitationpolicies related to support or training are subject to change without notice.



ZTE CORPORATION

Values Your Comments & Suggestions!Your opinion is of great value and will help us improve the quality of our productdocumentation and offer better services to our customers.

Please fax to: (86) 755-26772236; or mail to Documentation R&D Department,

ZTE CORPORATION, ZTE Plaza, A Wing, Keji Road South, Hi-Tech Industrial Park,Shenzhen, P. R. China 518057.

Thank you for your cooperation!

DocumentName

ZXWN HLR Home Location Register Operation Manual

Product

Version

V3.00Document

Revision Number

R1.0

Equipment Installation Date

Yourevaluation of thisdocumentation

Presentation:

(Introductions, Procedures, Illustrations, Completeness, Level of Detail,Organization, Appearance)

Good Fair Average Poor Bad N/A

Accessibility:

(Contents, Index, Headings, Numbering, Glossary)


Intelligibility:

(Language, Vocabulary, Readability & Clarity, Technical Accuracy, Content)


Yoursuggestionsforimprovementof this

documentation

Please check the suggestions which you feel can improve thisdocumentation:

Improve the overview/introduction Make it more concise/brief

Improve the Contents Add more step-by-stepprocedures/tutorials

Improve the organization Add more troubleshooting information

Include more figures Make it less technical

Add more examples Add more/better quick reference aids

Add more detail Improve the index

Other suggestions __________________________________________________________________________

__________________________________________________________________________

__________________________________________________________________________

__________________________________________________________________________

__________________________________________________________________________

# Please feel free to write any comments on an attached sheet.

If you wish to be contacted regarding your comments, please complete the following:

Name Company

Postcode Address



TelephoneE-

mail



Contents

Chapter 1..................................................................1

WCDMA UTRAN System Archetecture..........................1

UTRAN Architecture..........................................................1

Explanation Related to RNS...............................................2

UTRAN Common Protocol model.........................................2

Chapter 2..................................................................5

WCDMA Interface Hierarchy.......................................5

Control Plane and User Plane.............................................5

Access Layer and Non-access Layer....................................6

Chapter 3..................................................................7

Interface and Protocol...............................................7

Protocol Overview............................................................7

RRC Connection Setup...........................................................7

Network Registration Process..................................................9

Connection Release Process..................................................11

Protocol Related to Interface Uu.......................................13

Uu Interface protocol architecture..........................................13

Status of RRC Protocol.........................................................19

Some Explanations..............................................................20

Protocol related to Interface Iu.........................................21

IU interface architecture.......................................................21

Protocol Structure of Iu Interface...........................................22

Some Explanations..............................................................25

RANAP Process....................................................................27

Protocol related to Interface Iur........................................29



Function and Structure of Interface Iur...................................30

DCH Frame Protocol of Interface Iur.......................................30

RNSAP Process....................................................................30

Protocol Related to Interface Iub......................................32

Node B Logic Model..............................................................33

NBAP Process......................................................................34

Cell Setup Process..........................................................38

CS Call Origination Flow (RRC Setup on CCH).....................39

CS Call Origination Flow (RRC Setup on DCH)....................40

CS Call Termination Flow.................................................41

Release Flow in CS Domain CN Originates..........................42

Release Flow in CS Domain UE Originates..........................43



C h a p t e r 1

WCDMA UTRAN SystemArchetecture

Highlights:

WCDMA UTRAN system structure

Hierarchy with UTRAN protocol common model

UTRAN ArchitectureFigure 1 shows the overall architecture of WCDMA UTRAN (UMTS

Terrestrial Radio Access Network) system of 3GPP R4.

F I G U R E 1 O V E RAL L UTRAN A RCHI T E CT URE

RNS

RNC

RNS

RNC

Core Network

Node B Node B Node B Node B

Iu Iu

Iur

Iub IubIub Iub

TRAN

The interface between CN and UTRAN is Interface Iu.

Inside UTRAN, the interface between RNC and Node B is

Interface Iub.

Confidential and Proprietary Information of ZTE CORPORATION 1



Inside UTRAN, the interface between RNCs is Interface Iur.

In addition, the interface between UTRAN and UE is InterfaceUu.

Explanation Related to RNSRNS (Radio Network Subsystem): The general name for oneRNC and all Nodes B it manages.

SRNC (Serving RNC): The RNS connecting with CN is calledSRNS and the RNC of RNS is called SRNC.

DRNC (Drift RNC): In the case of soft handover of WCDMA, UEcan use several RNSs. Figure 2 shows the relation of SRNS and

DRNS.

F I G U R E 2 SRNS A ND DRNS

SRNS

Core Network

Iu

DRNSIur

UE

Cells

Several links can exist inside one UE at the same time. The userdata to access DRNS is sent to SRNS from DRNS via InterfaceIur. DRNC won’t process the data but transmit it betweenInterface Iub and Interface Iur transparently. One UE can accessone or several DRNSs.

CRNC (Control RNC): When UE access one RNS, the RNC of theRNS is called CRNC. Therefore, in Figure 2, both SRNC andDRNC are CRNC. CRNC manages the resources of the whole cell.SRNC schedules data on user DCH and CRNC schedules data on

CCH.

For Source RNC (S-RNC) and Target RNC (T-RNC), refer to

Chapter of Interface Iu.

UTRAN Common ProtocolmodelFigure 3 shows the general protocol model for UTRAN Interfaces,




Chapter 1 Interface and Protocol

and described in detail in the following subclauses. The structureis based on the principle that the layers and planes are logically

independent of each other. Therefore, as and when required, thestandardisation body can easily alter protocol stacks and planes

to fit future requirements.

F I G U R E 3 UTRAN C O M M O N PRO T O CO L MO DE L

ApplicationProtocol

DataStream(s)

ALCAP(s)

Transport

NetworkLayer

Physical Layer

SignallingBearer(s)

Transport

User

Network

Plane

Control Plane User Plane

Transport

User

Network

Plane

Transport Network

Control Plane

RadioNetwork

Layer

SignallingBearer(s)

DataBearer(s)

Horizontal, The Protocol Structure consists of two main layers,Radio Network Layer, and Transport Network Layer. All UTRANrelated issues are visible only in the Radio Network Layer, andthe Transport Network Layer represents standard transporttechnology that is selected to be used for UTRAN, but without

any UTRAN specific requirements.

Vertical, UTRAn falls into the following 4 planes: control plane ,user plane , TNL control plane , TNL user plane.

Control plane：

The Control Plane Includes the Application Protocol, i.e.RANAP, RNSAP or NBAP, and the Signalling Bearer for

transporting the Application Protocol messages.Among other things, the Application Protocol is used forsetting up bearers for (i.e. Radio Access Bearer or RadioLink) in the Radio Network Layer. In the three planestructure the bearer parameters in the Application Protocolare not directly tied to the User Plane technology, but arerather general bearer parameters.

The Signalling Bearer for the Application Protocol may ormay not be of the same type as the Signalling Protocol forthe ALCAP. The Signalling Bearer is always set up by O&Mactions.

User plane：




WR_BT06_E1_0 Interface Protocol and Signaling Flow

The User Plane Includes the Data Stream(s) and the DataBearer(s) for the Data Stream(s). The Data Stream(s) is/arecharacterised by one or more frame protocols specified forthat interface.

TNL control plane：

The Transport Network Control Plane does not include any

Radio Network Layer information, and is completely in theTransport Layer. It includes the ALCAP protocol(s) that is/are

needed to set up the transport bearers (Data Bearer) for theUser Plane. It also includes the appropriate Signalling

Bearer(s) needed for the ALCAP protocol(s).

The Transport Network Control Plane is a plane that acts

between the Control Plane and the User Plane. Theintroduction of Transport Network Control Plane makes it

possible for the Application Protocol in the Radio Network

Control Plane to be completely independent of thetechnology selected for Data Bearer in the User Plane.

When Transport Network Control Plane is used, the transport

bearers for the Data Bearer in the User Plane are set up inthe following fashion. First there is a signalling transaction by

the Application Protocol in the Control Plane, which triggersthe set up of the Data Bearer by the ALCAP protocol that isspecific for the User Plane technology.

The independence of Control Plane and User Plane assumes

that ALCAP signalling transaction takes place. It should benoted that ALCAP might not be used for all types Data

Bearers. If there is no ALCAP signalling transaction, theTransport Network Control Plane is not needed at all. This isthe case when pre-configured Data Bearers are used.

It should also be noted that the ALCAP protocol(s) in the

Transport Network Control Plane is/are not used for settingup the Signalling Bearer for the Application Protocol or for

the ALCAP during real time operation.

The Signalling Bearer for the ALCAP may or may not be of

the same type as the Signalling Bearer for the ApplicationProtocol. The Signalling Bearer for ALCAP is always set up by

O&M actions.

TNL user plane

The Data Bearer(s) in the User Plane, and the SignallingBearer(s) for Application Protocol, belong also to TransportNetwork User Plane. As described in the previous subclause,the Data Bearers in Transport Network User Plane aredirectly controlled by Transport Network Control Plane duringreal time operation, but the control actions required for

setting up the Signalling Bearer(s) for Application Protocolare considered O&M actions.

4 Confidential and Proprietary Information of ZTE CORPORATION



C h a p t e r 2

WCDMA InterfaceHierarchy

Highlights:

Grasp the concepts of UTRAN control plane and user plane

Know about the protocols of UTRAN control plane

Grasp the concepts of access layer and non-access layer

Control Plane and User PlanePurpose of the control plane:

Control the radio access bearer and the connection between UEand the network;

Transmit messages of non-access layer transparently.

Purpose of user plane:

Transmit the user data via the access network.

In UTRAN, each interface of RNL has user plane and control

plane.

The control plane protocols of each interface on RNL include:

Interface Iu: RANAP

Interface Iur: RANSAP

Interface Iub: NBAP

Interface :Uu: RRC protocol

The user plane data and control plane data of all RNL belong toTNL user plane. TNL control plane protocol is ALCAP, belonging

to SAAL (Signalling AAL) of ATM.




Access Layer and Non-

access Layer The concepts of access layer and non-access layer are related tothe communication of UE and CN. The access layer bears theupper layer services via the SAP (Service Access Point), asshown in Figure 4.

F I G U R E 4 A CCE S S L AY E R AN D NO N - ACCE S S L AY E R

UTRAN UE CN

Access Stratum

Non-Access Stratum

Radio(Uu)

Iu

Radioproto-cols(1)

Radioproto-cols(1)

Iuprotocols

(2)

Iuprotocols

(2)

Example for non-access layer:

In AMR voice telephone (the calling party), there are several UE-CN signaling, which are the control plane signaling of non-accesslayer. These signaling are encapsulated in RRC protocol first andthen transmitted to RNC transparently. RNC decodes thesesignaling out of RRC messages, encapsulates into RANAP, andthen transmits to CN transparently via RANAP.

UERNC CM Service Request

RNCUE Authentication Request

UERNC Authentication Response

RNCUE CM Service Accept

UERNC SETUP

RNCUE Call Processing

RNCUE Alerting

RNCUE Connect

UERNC Connect Acknowledge




C h a p t e r 3

Interface and Protocol

Highlights

Grasp the types of protocols at UTRAN radio side

Grasp hierarchy of the protocols

Grasp the status of RRC protocol

Protocol OverviewBesides the process that UE searches for the net, UE registrationfall into 3 phases:

RRC connection setup

Network registration

Connection release

RRC Connection Setup

Figure 5 shows the flow of RRC connection setup.




F I G U R E 5 RRC C O NNE CT I O N SE T UP

5. Downlink Synchronisation

UE Node B

Serving RNS Serving

RNC

DCH-FPDCH-FP

Allocate RNTI

Select L1 and L2

parameters

RRCRRC1. CCCH : RRC Connection Request

NBAP NBAP3. Radio Link Setup Response

NBAP NBAP

2. Radio Link Setup Request

RRCRRC7. CCCH : RRC Connection Setup

Start RX

Start TX

4. ALCAP Iub Data Transport Bearer Setup

RRCRRC8. DCCH : RRC Connection Setup Complete

DCH-FPDCH-FP6. Uplink Synchronisation

Detailed descriptions:

At the beginning, UE does not have dedicated channel resources,so it sends the message of RRC connection setup on CCCH(RACH).

RNC allocates RNTI and available resources to UE, decides toallocate DCH to UE, and inform Node B to allocate DCH to UEwith NBAP message of “Radio Link Setup Request”.

Node B allocates resources to UE, starts to receive, and returns

“Radio Link Setup Response” to RNC.

At this time, there are no resources of the transmission networkon Interface Iub, so ALCAP of SRNC sends the message of ERQ(Establish Request). This message contains AAL2 binding ID.

This ID can help Node B to bind the data transmission bearer onInterface Iub and DCH, and sends the message of ECF (Establish

Confirm) back to RNC.

Node B and SRNC perform the frame synchronization via “Downlink Synchronization” and “Uplink. Synchronization” inDCH frame protocol, and then to perform the DL transmission.

Although DCH resources on Interface Iub are ready, UE does notknow it. Therefore, SRNC sends the message of “RRCConnection Setup” to UE on CCCH (FACH), and informs UE of related parameters.

According to related parameters in “RRC Connection Setup”, UE

configures the physical layer. Node B sets up DCH successfully





and sends the message of “RRC Connection Setup Complete” back to SRNC on DCH.

Network Registration Process

Figure 6 shows the flow of UE registration for CS domain.





F I G U R E 6 UE LO CAT I O N UP DAT E


After RRC connection sets up, UE establishes DCH. UE needs tochange information with CN (this is signaling interaction of non-

access layer and readers of non-access layer signaling can refer





to [3]), that is, to initiate the Location Update. This message isencapsulated in the RRC message of Initial Direct Transfer,

which is sent to RNC by UE.

RRC of RNC receives the message of Initial Direct Transfer,

decodes the high-layer messages from it, and sends to RANAPentity. RANAP entity will encapsulate the message of “LocationUpdate” into Initial UE Message and sends it to CN through SCCPentity. At this time, there is no signaling connection between

RNC and CN, so the message of “Initial UE Message” of RANAP isencapsulated into SCCP connection setup massage (CR) and

sent to CN.

SCCP entity of CN receives the SCCP connection setup request.It returns SCCP connection setup message (CC) to RNC andsends the RANAP massage contained in CR messages to RANAP

entity. RANAP entity decodes the message of “Location Update”

of NAS layer and sends it to the related modules on NAS layerfor processing.

After receiving the message of “Location Update” from UE, CN

initiates the authentication. The signalling during theauthentication process is transmitted transparently. RNC and

Node B only transfer between UE and CN, but do not processmessages. Messages of “Authentication Request” and

“Authentication Response” are NAS messages, too. They areencapsulated into the message of “Direct Transfer” of RANAPand RRC.

After the authentication check on UE is passed, CN initiates the

security mode process. It is to encrypt and protect the data andsignaling of the air interface. Messages of security mode are nottransmitted transparently and it needs RNC processing.

After the authentication check is passed and the security mode

is initiated, CN sends the message of “Location Update Accept” to UE, informing that UE registration succeeds. This message is

transmitted transparently.

Connection Release Process

Figure 7 shows the connection release process.





F I G U R E 7 RRC C O NNE CT I O N R E L E AS E


After Location Update completes, CN initiates Iu release process.

SRNC sends the message of RRC connection release to RRC.

UE sends the message of RRC connection release back to RNC.

RNC informs Node B to delete RL and after deleting RL, Node Breplies to RNC.

RNC informs CN that returns Iu release completes via RANAP.

CN initiates to release SCCP link and RNC returns the messageof SCCP release confirmation.

RNC initiates to release the transmission resources on InterfaceIub.





Protocol Related to Interface

UuUu Interface protocol architecture

Figure 8 shows the architecture of Uu Interface protocol.

F I G U R E 8 S T RUCT URE O F RRC PR O T O C O L

L3

Logical

Channels

Transport

Channels

C-plane signalling U-plane information

PHY

L2/MAC

L1

RLC

DC NtGC

L2/RLC

MAC

RLCRLC

RLCRLC

RLCRLC

RLC

Duplication avoidance

UuS boundary

BMCL2/BMC

control

PDCPPDCP L2/PDCP

DC NtGC

Radio

Bearers

RRC

The Uu interface is layered into three protocol layers:

the physical layer (L1);

the data link layer (L2);

network layer (L3).

Layer 2 is split into following sublayers: Medium Access Control(MAC), Radio Link Control (RLC), Packet Data Convergence

Protocol (PDCP) and Broadcast/Multicast Control (BMC). Layer 3and RLC are divided into Control (C-) and User (U-) planes.





PDCP and BMC exist in the U-plane only.

In the C-plane, Layer 3 is partitioned into sublayers where thelowest sublayer, denoted as Radio Resource Control (RRC),

interfaces with layer 2 and terminates in the UTRAN. The next

sublayer provides 'Duplication avoidance' functionality. Itterminates in the CN but is part of the Access Stratum; itprovides the Access Stratum Services to higher layers. Thehigher layer signalling such as Mobility Management (MM) andCall Control (CC) is assumed to belong to the non-accessstratum..

The functions of RLC:

The RLC sublayer provides ARQ functionality closely coupled withthe radio transmission technique used. There is no difference

between RLC instances in C and U planes.The UTRAN can berequested by the CN to prevent all loss of data (i.e.

independently of the handovers on the radio interface), as longas the Iu connection point is not modified. This is a basicrequirement to be fulfilled by the UTRAN retransmissionfunctionality as provided by the RLC sublayer.However, in caseof the Iu connection point is changed (e.g. SRNS relocation,streamlining), the prevention of the loss of data may not be

guaranteed autonomously by the UTRAN but relies on'Duplication avoidance' functions in the CN.There are primarily

two kinds of signalling messages transported over the radiointerface - RRC generated signalling messages and NAS

messages generated in the higher layers. On establishment of the signalling connection between the peer RRC entities three or

four UM/AM signalling radio bearers may be set up. Two of thesebearers are set up for transport of RRC generated signallingmessages - one for transferring messages through anunacknowledged mode RLC entity and the other for transferring

messages through an acknowledged mode RLC entity.

The functions of MAC include:

Mapping between logical channels and transportchannels. The MAC is responsible for mapping of logical

channel(s) onto the appropriate transport channel(s).

Selection of appropriate Transport Format for eachTransport Channel depending on instantaneous sourcerate. Given the Transport Format Combination Set assigned

by RRC, MAC selects the appropriate transport format withinan assigned transport format set for each active transportchannel depending on source rate. The control of transportformats ensures efficient use of transport channels.

Priority handling between data flows of one UE. Whenselecting between the Transport Format Combinations in the

given Transport Format Combination Set, priorities of thedata flows to be mapped onto the corresponding TransportChannels can be taken into account. Priorities are e.g. given

by attributes of Radio Bearer services and RLC buffer status.





The priority handling is achieved by selecting a TransportFormat Combination for which high priority data is mapped

onto L1 with a "high bit rate" Transport Format, at the sametime letting lower priority data be mapped with a "low bit

rate" (could be zero bit rate) Transport Format. Transportformat selection may also take into account transmit power

indication from Layer 1.

Priority handling between UEs by means of dynamic

scheduling. In order to utilise the spectrum resourcesefficiently for bursty transfer, a dynamic scheduling function

may be applied. MAC realises priority handling on commonand shared transport channels. Note that for dedicatedtransport channels, the equivalent of the dynamic schedulingfunction is implicitly included as part of the reconfigurationfunction of the RRC sublayer.

Identification of UEs on common transport channels.When a particular UE is addressed on a common downlinkchannel, or when a UE is using the RACH, there is a need forinband identification of the UE. Since the MAC layer handlesthe access to, and multiplexing onto, the transport channels,the identification functionality is naturally also placed in MAC.

Multiplexing/demultiplexing of upper layer PDUs

into/from transport blocks delivered to/from thephysical layer on common transport channels. MACshould support service multiplexing for common transportchannels, since the physical layer does not supportmultiplexing of these channels.

Multiplexing/demultiplexing of upper layer PDUsinto/from transport block sets delivered to/from thephysical layer on dedicated transport channels. TheMAC allows service multiplexing for dedicated transportchannels. This function can be utilised when several upperlayer services (e.g. RLC instances) can be mapped efficientlyon the same transport channel. In this case the identification

of multiplexing is contained in the MAC protocol controlinformation.

Traffic volume measurement. Measurement of trafficvolume on logical channels and reporting to RRC. Based on

the reported traffic volume information, RRC performstransport channel switching decisions.

Transport Channel type switching. Execution of theswitching between common and dedicated transportchannels based on a switching decision derived by RRC.

Ciphering. This function prevents unauthorised acquisition

of data. Ciphering is performed in the MAC layer fortransparent RLC mode.

Access Service Class selection for RACH and CPCHtransmission. The RACH resources (i.e. access slots and

preamble signatures) and CPCH resources (i.e. access slots

and preamble signatures) may be divided between different





Access Service Classes in order to provide different prioritiesof RACH and CPCH usage. In addition it is possible for morethan one ASC or for all ASCs to be assigned to the sameaccess slot/signature space. Each access service class will

also have a set of back-off parameters associated with it,some or all of which may be broadcast by the network. TheMAC function applies the appropriate back-off and indicates

to the PHY layer the RACH and CPCH partition associated toa given MAC PDU transfer.

The functions of PDCP include:

Header compression and decompression. Headercompression and decompression of IP data streams (e.g.,TCP/IP and RTP/UDP/IP headers) at the transmitting andreceiving entity, respectively. The header compression

method is specific to the particular network layer, transportlayer or upper layer protocol combinations e.g. TCP/IP andRTP/UDP/IP.

Transfer of user data. Transmission of user data meansthat PDCP receives PDCP SDU from the NAS and forwards itto the RLC layer and vice versa.

Support for lossless SRNS relocation. Maintenance of PDCP sequence numbers for radio bearers that areconfigured to support lossless SRNS relocation.

The functions of BMC include:

Storage of Cell Broadcast Messages.

The BMC stores the Cell Broadcast messages received overthe CBC-RNC interface for scheduled transmission.

Traffic volume monitoring and radio resource requestfor CBS.At the UTRAN side, the BMC calculates the requiredtransmission rate for Cell Broadcast Service based on the

messages received over the CBC-RNC interface, and requestsfor appropriate CTCH/FACH resources from RRC.

Scheduling of BMC messages.

The BMC receives scheduling information together with eachCell Broadcast message over the CBC-RNC-interface. Basedon this scheduling information, at the UTRAN side, BMC

generates schedule messages and schedules BMC messagesequences accordingly. At the UE side, BMC evaluates the

schedule messages and indicates scheduling parameters toRRC, which are used by RRC to configure the lower layers forCBS discontinuous reception.

Transmission of BMC messages to UE.

This function transmits the BMC messages (Scheduling andCell Broadcast messages) according to schedule.

Delivery of Cell Broadcast messages to upper layer





(NAS).This functions delivers the received Cell Broadcast messages

to upper layer (NAS) in the UE. Only non-corrupted CellBroadcast messages are delivered.

The functions of RRC include:

The Radio Resource Control (RRC) layer handles the controlplane signalling of Layer 3 between the UEs and UTRAN. The

RRC performs the following functions:

Broadcast of information provided by the non-accessstratum (Core Network). The RRC layer performs systeminformation broadcasting from the network to all UEs. Thesystem information is normally repeated on a regular basis.The RRC layer performs the scheduling, segmentation and

repetition. This function supports broadcast of higher layer(above RRC) information. This information may be cell

specific or not. As an example RRC may broadcast CoreNetwork location service area information related to somespecific cells.

Broadcast of information related to the access

stratum. The RRC layer performs system informationbroadcasting from the network to all UEs. The system

information is normally repeated on a regular basis. The RRClayer performs the scheduling, segmentation and repetition.This function supports broadcast of typically cell-specificinformation.

Establishment, re-establishment, maintenance andrelease of an RRC connection between the UE and

UTRAN. The establishment of an RRC connection is initiatedby a request from higher layers at the UE side to establishthe first Signalling Connection for the UE. The establishmentof an RRC connection includes an optional cell re-selection,an admission control, and a layer 2 signalling linkestablishment. The release of an RRC connection can beinitiated by a request from higher layers to release the lastSignalling Connection for the UE or by the RRC layer itself in

case of RRC connection failure. In case of connection loss,the UE requests re-establishment of the RRC connection. In

case of RRC connection failure, RRC releases resourcesassociated with the RRC connection.

Establishment, reconfiguration and release of RadioBearers. The RRC layer can, on request from higher layers,

perform the establishment, reconfiguration and release of Radio Bearers in the user plane. A number of Radio Bearers

can be established to an UE at the same time. Atestablishment and reconfiguration, the RRC layer performsadmission control and selects parameters describing theRadio Bearer processing in layer 2 and layer 1, based oninformation from higher layers.

Assignment, reconfiguration and release of radio





resources for the RRC connection. The RRC layer handlesthe assignment of radio resources (e.g. codes, CPCHchannels) needed for the RRC connection including needsfrom both the control and user plane. The RRC layer may

reconfigure radio resources during an established RRCconnection. This function includes coordination of the radioresource allocation between multiple radio bearers related to

the same RRC connection. RRC controls the radio resourcesin the uplink and downlink such that UE and UTRAN cancommunicate using unbalanced radio resources (asymmetricuplink and downlink). RRC signals to the UE to indicateresource allocations for purposes of handover to GSM orother radio systems.

RRC connection mobility functions. The RRC layerperforms evaluation, decision and execution related to RRCconnection mobility during an established RRC connection,

such as handover, preparation of handover to GSM or othersystems, cell re-selection and cell/paging area updateprocedures, based on e.g. measurements done by the UE.

Paging/notification. The RRC layer can broadcast paginginformation from the network to selected UEs. Higher layerson the network side can request paging and notification. TheRRC layer can also initiate paging during an established RRCconnection.

Routing of higher layer PDUs. This function performs at

the UE side routing of higher layer PDUs to the correct higherlayer entity, at the UTRAN side to the correct RANAP entity.

Control of requested QoS. This function shall ensure thatthe QoS requested for the Radio Bearers can be met. This

includes the allocation of a sufficient number of radioresources.

UE measurement reporting and control of thereporting. The measurements performed by the UE are

controlled by the RRC layer, in terms of what to measure,when to measure and how to report, including both UMTS air

interface and other systems. The RRC layer also performsthe reporting of the measurements from the UE to thenetwork.

Outer loop power control. The RRC layer controls settingof the target of the closed loop power control.

Control of ciphering. The RRC layer provides proceduresfor setting of ciphering (on/off) between the UE and UTRAN.

Arbitration of radio resources on uplink DCH. Thisfunction controls the allocation of radio resources on uplinkDCH on a fast basis, using a broadcast channel to sendcontrol information to all involved users.This function isimplemented in the CRNC.

Initial cell selection and re-selection in idle mode.Selection of the most suitable cell based on idle mode

measurements and cell selection criteria.





Integrity protection. This function adds a MessageAuthentication Code (MAC-I) to those RRC messages that are

considered sensitive and/or contain sensitive information.

Initial Configuration for CBS

This function performs the initial configuration of the BMCsublayer.

Allocation of radio resources for CBSThis function allocates radio resources for CBS based ontraffic volume requirements indicated by BMC. The radioresource allocation set by RRC (i.e. the schedule for mappingof CTCH onto FACH/S-CCPCH) is indicated to BMC to enablegeneration of schedule messages. The resource allocation forCBS shall be broadcast as system information.

Configuration for CBS discontinuous receptionThis function configures the lower layers (L1, L2) of the UE

when it shall listen to the resources allocated for CBS basedon scheduling information received from BMC.

Status of RRC Protocol

In WCDMA, all statuses of UE are scheduled by RRC protocol.

One UE has several RRC statuses, such as, Idle and DCH. Figure9 shows the status and status conversion (containing GSM

status).

F I G U R E 9 RRC ST AT US AND ST AT US CO NV E RS I O N

Establish RRC

Connection

Release RRC

Connection

UTRA RRC Connected Mode

UTRA:Inter-RATHandover

GSM:Handover

Establish RRC

Connection

Release RRC

Connection

URA_PCH CELL_PCHGSM

Connected

Mode

Establish RR Connection

Release RR Connection

Idle Mode

Camping on a UTRAN cell1 Camping on a GSM / GPRS cell1

GPRS Packet Idle Mode1

GPRS

Packet

Transfer

Mode

Initiation of emporarylock flow

Release of emporary

lock flow

Cell reselection

CELL_DCH

out of service

inservice

CELL_FACH

out of service

inservice

out of service

inservice

UE status is defined by the channel that UE uses.

CELL_DCH status indicates that UE occupies the dedicated

physical channel.





CELL_FACH status indicates that UE does not use any dedicatedchannel but uses the common channel when the traffic is small.UL uses RACH and DL uses FACH. In this status, UE can initiatecell reselection process and UTRAN can determine which cell UE

locates in.CELL_PCH status indicates that UE only intercepts PCH and BCH.In this status, UE can reselect the cell. During the reselection, itconverts into CELL_FACH status, the cell update initiates, and itreturns to CELL_PCH status. The network can determine the cellwhich the UE locates in.

URA_PCH status is similar to CELL_PCH status. The network canonly determine the URA cell which the UE locates in.

The introduction of CELL_PCH status and URA_PCH status is to

keep UE always in online status in order not to waster radioresources.

Some Explanations

In CELL_PCH, URA_PCH or Idle status, UE can intercept PCH andBCH, and can receive the message of Paging. In CELL_DCH orCELL_FACH status, UE cannot intercept PCH and BCH. PagingType 2 is introduced to page UE in these two statuses.

Usually, the permanent ID information of UE (such as, IMSI) willnot be saved in RNC. When UE is making a call, CN informs RNCof the IMSI of the UE with the message of Command ID of

RANAP. When CN requires RNC to page a specific UE, RNC will judge which RRC status the IMSI to page is in, to decide thepaging type (Paging Type 1 or Paging Type 2).





Protocol related to Interface

IuIU interface architecture

Core Network (CN)UTRAN

Node B

Node B

Node B

Node B

RNC

Iu Interface

“Iu-BC”

“Iu-CS”

BC

Domain

CS

Domain

PS

Domain

“Iu-PS”

RNC

The Iu interface is specified at the boundary between the CoreNetwork and UTRAN. Figure depicts the logical division of the Iu

interface. From the Iu perspective, the UTRAN access point is anRNC. The Iu interface towards the PS-domain of the core

network is called Iu-PS, and the Iu interface towards the CS-domain is called Iu-CS. The differences between Iu-CS and Iu-PS are treated elsewhere in the present document. The Iuinterface to the Broadcast domain is called Iu-BC.

There shall not be more than one Iu interface (Iu-PS) towardsthe PS-domain from any one RNC. Each RNC shall not have

more than one Iu interface (Iu-CS) towards its default CN nodewithin the CS domain, but may also have further Iu interfaces(Iu-CS) towards other CN nodes within the CS domain. (See [6]for definition of Default CN node.) These further Iu interfaces(Iu-CS) shall only be used as a result of intra-MSC inter-systemhandover or SRNS relocation, in the case the anchor CN nodedirectly connects to the target RNC. There shall not be morethan one Iu interface (Iu-BC) from an RNC towards the

Broadcast domain.

In the separated core network architecture, this means thatthere shall be separate signalling and user data connectionstowards the PS and CS domains – this applies in both transport

and radio network layers.





In the combined architecture, there shall be separateconnections in the user plane towards the PS and CS domains(in both transport and radio network layers). In the controlplane, there shall be separate SCCP connections to the two

logical domains.In either architecture, there can be several RNCs within UTRANand so UTRAN may have several Iu access points towards theCore Network. As a minimum, each Iu access point (in UTRAN orCN) shall independently fulfil the requirements of the relevant Iuspecifications

Protocol Structure of Iu Interface

Figure 10 shows the structure of Interface Iu-CS protocol and

Figure 11 shows the structure of Interface Iu-PS protocol.

F I G U R E 10 ST RUCT URE O F I U -CS PRO T O CO L

Q.2150.1

Q.2630.1

RANAP Iu UP Protocol

Layer

Transport

Network Layer

Physical Layer

Transport

User

Network

Plane


Transport

User

Network

Plane

Transport Network

Control Plane

Radio

Network

Layer

ATM

SSCOP

AAL5

SSCOP

SSCF-NNI

AAL2AAL5

MTP3bMTP3b

SCCP

SSCF-NNI





F I G U R E 11 ST RUCT URE O F I NT E RF ACE IU -PS P RO T O CO L

SSCF-NNI

SSCOP

AAL5

IP

SCTP

SCCP

SSCF-NNI

MTP3-B

M3UA

RANAPIu UP Protocol

Layer

Transport

Network

Layer

Physical Layer

Transport

User

Network

Plane


Transport

User

Network

PlaneTransport Network

Control Plane

Radio

Network Layer

ATM

AAL5

IP

UDP

GTP-U

Physical Layer

ATM

RANAP: user plane application protocol. It provides thesignalling service between UTRAN and CN that is required to

fulfil the RANAP functions. RANAP protocol has the followingfunctions:

Relocating serving RNC. This function enables to change theserving RNC 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 forsetting up, modifying and releasing RABs.

Queuing the setup of RAB. The purpose of this function is toallow placing some requested RABs into a queue, and

indicate the peer entity about the queuing.

Requesting RAB release. While the overall RAB managementis 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 Iuconnection.

Requesting the release of all Iu connection resources. Whilethe Iu release is managed from the CN, the RNC has thecapability to request the release of all Iu connectionresources from the corresponding Iu connection.





SRNS context forwarding function. This function isresponsible for transferring SRNS context from the RNC tothe CN for intersystem change 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 Iuinterface.

Sending the UE Common ID (permanent NAS UE identity) tothe RNC. This function makes the RNC aware of the UE'sCommon ID.

Paging the user. This function provides the CN for capabilityto 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 (see [8]).

This function has two sub-classes:

1. Transport of the initial NAS signalling message from the UEto CN. This function transfers transparently the NAS

information. As a consequence also the Iu signallingconnection is set up.

2. 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 messagesdifferently.

Controlling the security mode in the UTRAN. This functionis used to send the security keys (ciphering and integrityprotection) to the UTRAN, and setting the operation mode

for security functions.

Controlling location reporting. This function allows the CNto operate the mode in which the UTRAN reports thelocation of the UE.

Location reporting. This function is used for transferringthe actual location information from RNC to the CN.

Data volume reporting function. This function isresponsible for reporting unsuccessfully transmitted DL

data volume over UTRAN for specific RABs.

Reporting general error situations. This function allows

reporting of general error situations, for which functionspecific error messages have not been defined.

Location related data. This function allows the CN toeither retrieve from the RNC deciphering keys (to beforwarded to the UE) for the broadcasted assistance data,or request the RNC to deliver dedicated assistance data

to the UE.





SCCP: The SCCP is used to support signalling messagesbetween the CNs and the RNC. One user function of the SCCP,called Radio Access Network Application Part (RANAP), is

defined. The RANAP uses one signalling connection per active UEand CN for the transfer of layer 3 messages. RANAP may useSSN, SPC and/or GT and any combination of them as addressingschemes for the SCCP. Which of the available addressing

scheme to use for the SCCP is an operator matter. A new SCCPconnection is established when information related to the

communication between a UE and the network has to beexchanged between RNC and CN, and no SCCP connection existsbetween the CN and the RNC involved, for the concerned UE.

MTP3B: provides message routing, discrimination and

distribution (for point-to-point link only), signaling linkmanagement load sharing and changeover/back between link

within one link-set. The need for multiple link-sets is precluded.

SAAL-NNI: SAAL-NNI [1] consists of the following sub-layers: -

SSCF [3], - SSCOP [2] and – AAL5 [6]. The SSCF maps therequirements of the layer above to the requirements of SSCOP.

Also SAAL connection management, link status and remoteprocessor status mechanisms are provided. SSCOP providesmechanisms for the establishment and release of connectionsand the reliable exchange of signalling information between

signalling entities. Adapts the upper layer protocol to therequirements of the Lower ATM cells.

IUUP: user plane protocol.

GTP-U: GTP-U is used as the user data bearer towards the PSdomain.RANAP Signalling is used to establish, modify and

release the GTP-U tunnels towards the PS domain.

AAL2: AAL2 is used as the user data bearer towards the CS

domain.Q.2630.2 is used as the protocol for dynamically setup

AAL-2 connections over Iu towards the CS domain. Q.2630.2adds new optional capabilities to Q.2630.1.

Some Explanations

SRNS Relocation

One case:





UE crosses 2 RNSs during the move, as shown in Figure 12.

F I G U R E 12 SRNS R E L O CAT I O N ( I )

One UE can use 2 RNSs at the same time. The data can be sent

on two RLs. In addition, the data that UE sends to DRNC is sentto SRNC via Interface Iur, and SRNC will combine them and

send to CN.

If UE continues to move, the RL deterioration of UE on SRNS

cannot be used again, which will cause the following case.

F I G U R E 13 SRNS RE L O CAT I O N ( I I )

UE and SRNC have no direct contact, but all data still pass SRNCand reach CN via Interface Iur. It will cause the waste of resources. Therefore, SRNS relocation should be initiated, which

can move Interface Iu from SRNC to DRNC. In the course of





SRNC relocation, SRNC (Serving RNC) is also called Source RNCand DRNC is also called Target RNC. Figure 14 shows the result

after the relocation completes.

F I G U R E 14 SRNS R E L O CAT I O N ( I I I )

SRNS relocation is the process to move Interface Iu from SourceRNC to Target RNC.

RANAP ProcessTABL E 1 CL AS S 1

ElementaryProcedure

InitiatingMessage

SuccessfulOutcome

UnsuccessfulOutcome

Response

message

Response message

Iu Release IU RELEASE

COMMAND

IU RELEASE

COMPLETE

Relocation

Preparation

RELOCATIO

NREQUIRED

RELOCATION

COMMAND

RELOCATION

PREPARATIONFAILURE

RelocationResourceAllocation

RELOCATION REQUEST

RELOCATIONREQUESTACKNOWLEDGE

RELOCATIONFAILURE

Relocation

Cancel

RELOCATIO

N CANCEL

RELOCATION

CANCELACKNOWLEDGE

SRNSContextTransfer

SRNSCONTEXTREQUEST

SRNS CONTEXTRESPONSE





Elementar

yProcedure

Initiating

Message

SuccessfulOutcome

UnsuccessfulOutcome

Responsemessage

Response message

SecurityModeControl

SECURITYMODECOMMAND

SECURITY MODECOMPLETE

SECURITY MODEREJECT

DataVolume

Report

DATAVOLUME

REPORTREQUEST

DATA VOLUMEREPORT

Reset RESET RESETACKNOWLEDGE

ResetResource

RESETRESOURCE

RESET RESOURCEACKNOWLEDGE

LocationrelatedData

LOCATIONRELATEDDATAREQUEST

LOCATIONRELATED DATARESPONSE

LOCATIONRELATED DATAFAILURE

TABL E 2 CL AS S 2

Elementary Procedure Message

RAB Modification Request RAB MODIFY REQUEST

RAB Release Request RAB RELEASE REQUEST

Iu Release Request IU RELEASE REQUEST

Relocation Detect RELOCATION DETECT

Relocation Complete RELOCATION COMPLETE

SRNS Data Forwarding Initiation SRNS DATA FORWARDCOMMAND

SRNS Context Forwarding fromSource RNC to CN

FORWARD SRNS CONTEXT

SRNS Context Forwarding to TargetRNC from CN

FORWARD SRNS CONTEXT

Paging PAGING

Common ID COMMON ID

CN Invoke Trace CN INVOKE TRACE

CN Deactivate Trace CN DEACTIVATE TRACE

Location Reporting Control LOCATION REPORTINGCONTROL

Location Report LOCATION REPORT

Initial UE Message INITIAL UE MESSAGE

Direct Transfer DIRECT TRANSFER

Overload Control OVERLOAD

Error Indication ERROR INDICATION






TABL E 3 CL AS S 3

ElementaryProcedure

InitiatingMessage

Response Message

RAB Assignment RAB ASSIGNMENTREQUEST

RAB ASSIGNMENTRESPONSE x N (N>=1)

Protocol related to Interface

Iur The highest layer protocol of Interface Iur control plane isRANSAP. Figure 15 shows the structure of Interface Iur protocol.

F I G U R E 15 ST RUCT URE O F I NT E RF ACE IU R PRO T O CO L

SSCF-NNI

SSCOP

MTP3-B

AAL5

IP

SCTP

SCCP

AAL5

SSCF-NNI

STC (Q.2150.1)

RNSAP Iur DataStream(s)

TransportNetwork

Layer

Physical Layer

TransportUser

NetworkPlane


TransportUser

NetworkPlane

Transport NetworkControl Plane

Radio

Network

Layer

ATM

ALCAP(Q.2630.1)

AAL2

SSCF-NNI

SSCOP

MTP3-B

IP

SCTPSSCF-NNI

M3UA M3UA

The protocol structure of Interface Iur control plane (includingRNL and TNL) is same as that of Interface Iu control plane.





Function and Structure of InterfaceIur

Interface Iur is to transmit data when UE performs the softhandover between adjacent RNCs.

3GPP prescribes that Interface Iur is a logic entity. That is,

Interface Iur and Interface Iu can either share one channel forthe transmission or connect via independent physical interface.

DCH Frame Protocol of Interface Iur

As shown in Figure,when UE crosses RNSs, DRNC can forwardDCH data to SRNC via Interface Iur. DRNC does not process DCH

data but directly send DCH data at Interface Iub to Interface Iur.DCH frames of Interface Iur and Interface Iub keep consistent,

to greatly reduce DCH data processing by DRNC.

RNSAP Process

TABL E 4 CL AS S 1 EL E M E NT ARY PRO CE DURE S

Elementar

yProcedure

InitiatingMessage

Successful

Outcome

Unsuccessful

OutcomeResponsemessage

Responsemessage

Radio LinkSetup

RADIO LINKSETUPREQUEST

RADIO LINKSETUPRESPONSE

RADIO LINKSETUP FAILURE

Radio LinkAddition

RADIO LINKADDITION

REQUEST

RADIO LINKADDITION

RESPONSE

RADIO LINKADDITION

FAILURE

Radio LinkDeletion

RADIO LINKDELETIONREQUEST

RADIO LINKDELETIONRESPONSE

Synchronised RadioLinkReconfigurationPreparation

RADIO LINKRECONFIGURATION PREPARE

RADIO LINKRECONFIGURATION READY

RADIO LINKRECONFIGURATION FAILURE

Unsynchronised Radio

LinkReconfigura

tion

RADIO LINKRECONFIGURA

TIONREQUEST

RADIO LINKRECONFIGURAT

ION RESPONSE

RADIO LINKRECONFIGURATIO

N FAILURE





ElementaryProcedure

InitiatingMessage

SuccessfulOutcome

UnsuccessfulOutcome

Responsemessage

Responsemessage

PhysicalChannel

Reconfiguration

PHYSICALCHANNEL

RECONFIGURATION

REQUEST

PHYSICALCHANNEL

RECONFIGURATION COMMAND

PHYSICALCHANNEL

RECONFIGURATION FAILURE

DedicatedMeasurement Initiation

DEDICATEDMEASUREMENT INITIATIONREQUEST

DEDICATEDMEASUREMENTINITIATIONRESPONSE

DEDICATEDMEASUREMENTINITIATIONFAILURE

CommonTransportChannelResourcesInitialisation

COMMONTRANSPORTCHANNELRESOURCESREQUEST

COMMONTRANSPORTCHANNELRESOURCESRESPONSE

COMMONTRANSPORTCHANNELRESOURCESFAILURE

CommonMeasurement Initiation

COMMONMEASUREMENT INITIATIONREQUEST

COMMONMEASUREMENTINITIATIONRESPONSE

COMMONMEASUREMENTINITIATIONFAILURE

Information

ExchangeInitiation

INFORMATION

EXCHANGEINITIATION

REQUEST

INFORMATION

EXCHANGEINITIATION

RESPONSE

INFORMATION

EXCHANGEINITIATION

FAILURE

TABL E 5 CL AS S 2 EL E M E NT ARY PRO CE DURE S

Elementary Procedure Initiating Message

Uplink Signalling Transfer UPLINK SIGNALLING TRANSFERINDICATION

Downlink Signalling Transfer DOWNLINK SIGNALLING TRANSFERREQUEST

Relocation Commit RELOCATION COMMIT

Paging PAGING REQUEST

Synchronised Radio Link

Reconfiguration Commit

RADIO LINK RECONFIGURATION

COMMIT

Synchronised Radio LinkReconfiguration Cancellation

RADIO LINK RECONFIGURATIONCANCEL

Radio Link Failure RADIO LINK FAILURE INDICATION

Radio Link Restoration RADIO LINK RESTORE INDICATION

Dedicated MeasurementReporting

DEDICATED MEASUREMENT REPORT

Dedicated MeasurementTermination

DEDICATED MEASUREMENTTERMINATION REQUEST





Elementary Procedure Initiating Message

Dedicated MeasurementFailure

DEDICATED MEASUREMENT FAILUREINDICATION

Downlink Power Control[FDD] DL POWER CONTROL REQUEST

Compressed Mode Command[FDD]

COMPRESSED MODE COMMAND

Common Transport ChannelResources Release

COMMON TRANSPORT CHANNELRESOURCES RELEASE REQUEST


Downlink Power TimeslotControl [TDD]

DL POWER TIMESLOT CONTROLREQUEST

Radio Link Pre-emption RADIO LINK PREEMPTION REQUIRED

INDICATION

Radio Link Congestion RADIO LINK CONGESTIONINDICATION

Common MeasurementReporting

COMMON MEASUREMENT REPORT

Common Measurement

Termination

COMMON MEASUREMENT

TERMINATION REQUEST

Common Measurement

Failure

COMMON MEASUREMENT FAILURE

INDICATION

Information Reporting INFORMATION REPORT

Information Exchange

Termination

INFORMATION EXCHANGE

TERMINATION REQUEST

Information ExchangeFailure

INFORMATION EXCHANGE FAILUREINDICATION

Protocol Related to InterfaceIubThe high layer protocol of Interface Iub control plane is NBAP.

The user plane consists of several frame protocols. Figure 16 shows the structure of protocols.





F I G U R E 16 ST RUCT URE O F I NT E RF ACE IU B PRO T O CO L

Node B

Application Part

(NBAP)

AAL Type 2

ALCAP

Transport

Layer

Physical Layer

Radio

Network

Layer

Radio Network

Control Plane

Transport

Network Control Plane

ATM

AAL Type 5

User Plane

SSCF-UNI

SSCOP

AAL Type 5

SSCF-UNI

SSCOP

Q.2630.1

Q.2150.2

NBAP includes Node B logic O&M and dedicated NBAP.

Node B Logic Model

F I G U R E 17 N O DE B LO G I C MO DE L

. .. . ..

Node B

...Cell Cell Cell Cell CellCell

Node B Communication Contexts,

with attributes

Common Transport Channels,

with attributes

Node BControl

Port

IubRACHDataport

IubFACHDataport

IubPCHDataport

Controlling RNC

IubFDD

CPCHDataport

Traffic termination point

CommunicationControl

Port

IubTDD USCH

Dataport

IubDCHDataport

IubDSCHDataport

IubFDD TFCI2

Dataport

Traffic termination point

CommunicationControl

Port

IubTDD USCH

Dataport

IubDCHDataport

IubDSCHDataport

IubFDD TFCI2

DataPort

Node B logic model consists of cell, common transmissionchannel/port, Node B communication context, and the

corresponding DSCH/DCH. Node B controls NCP and thecommunication controls port CCP, etc.

Node B communication context and the corresponding

DSCH/DCH port are related to dedicated user services.





Node B communication context is corresponding to CRNCcommunication context.

Node B communication context is identifies by Node B

Communication Text ID, containing necessary information to

communicate with UE. It is established when RL is setup anddeleted when RL is deleted.

There is only one NCP link on one Node B. RNC sends all Node B

common control signaling from NCP. NCP link must be setupbefore operating, maintaining, and controlling Node B.

There can be several CCP links on one Node B. RNC sends allNode B dedicated control signaling from CCP link. Usually, one

cell inside Node B can be configured with one CCP (it is just aroutine, not certain.)

NBAP ProcessTABL E 6 CL AS S 1

Elemen

taryProced

ure

Message

SuccessfulOutcome

UnsuccessfulOutcome

Responsemessage

Responsemessage

CellSetup

CELL SETUPREQUEST

CELL SETUPRESPONSE

CELL SETUPFAILURE

Cell

Reconfiguration

CELL

RECONFIGURATION REQUEST

CELL

RECONFIGURATION RESPONSE

CELL


CellDeletion

CELL DELETIONREQUEST

CELL DELETIONRESPONSE

CommonTransportChannelSetup

COMMONTRANSPORTCHANNEL SETUPREQUEST

COMMONTRANSPORTCHANNEL SETUPRESPONSE

COMMONTRANSPORTCHANNEL SETUPFAILURE

Commo

nTranspo

rtChannel

Reconfiguration

COMMON

TRANSPORTCHANNEL

RECONFIGURATION REQUEST

COMMON

TRANSPORTCHANNEL

RECONFIGURATION RESPONSE

COMMON

TRANSPORTCHANNEL


Common

Transport

ChannelDeletion

COMMONTRANSPORT

CHANNELDELETION

REQUEST

COMMONTRANSPORT

CHANNELDELETION

RESPONSE





Elemen

taryProced

ure

Message

SuccessfulOutcome

UnsuccessfulOutcome

Responsemessage

Responsemessage

PhysicalShared

ChannelReconfig

ure[TDD]

PHYSICALSHARED

CHANNELRECONFIGURATI

ON REQUEST

PHYSICALSHARED


ON RESPONSE

PHYSICALSHARED


ON FAILURE

Audit AUDIT REQUEST AUDITRESPONSE

AUDIT FAILURE

BlockResource

BLOCKRESOURCEREQUEST

BLOCKRESOURCERESPONSE

BLOCKRESOURCEFAILURE

RadioLinkSetup

RADIO LINKSETUP REQUEST

RADIO LINKSETUPRESPONSE

RADIO LINKSETUP FAILURE

SystemInforma

tionUpdate

SYSTEMINFORMATION

UPDATE REQUEST

SYSTEMINFORMATION

UPDATERESPONSE

SYSTEMINFORMATION

UPDATE FAILURE

CommonMeasurementInitiatio

n

COMMONMEASUREMENTINITIATIONREQUEST

COMMONMEASUREMENTINITIATIONRESPONSE

COMMONMEASUREMENTINITIATIONFAILURE

RadioLinkAddition

RADIO LINKADDITIONREQUEST

RADIO LINKADDITIONRESPONSE

RADIO LINKADDITIONFAILURE

Radio

LinkDeletion

RADIO LINK

DELETIONREQUEST

RADIO LINK

DELETIONRESPONSE

Synchronised

RadioLink

Reconfig

urationPreparation

RADIO LINKRECONFIGURATI

ON PREPARE


ON READY


ON FAILURE

UnsynchronisedRadioLinkReconfiguration

RADIO LINKRECONFIGURATION REQUEST

RADIO LINKRECONFIGURATION RESPONSE

RADIO LINKRECONFIGURATION FAILURE





Elementary

Procedure

Message

SuccessfulOutcome

UnsuccessfulOutcome

Responsemessage

Responsemessage

DedicatedMeasurementInitiation

DEDICATEDMEASUREMENTINITIATIONREQUEST

DEDICATEDMEASUREMENTINITIATIONRESPONSE

DEDICATEDMEASUREMENTINITIATIONFAILURE

Reset RESET REQUEST RESET

RESPONSE

CellSynchronisationInitiatio

n[3.84Mcps TDD]

CELLSYNCHRONISATION INITIATIONREQUEST

CELLSYNCHRONISATION INITIATIONRESPONSE

CELLSYNCHRONISATION INITIATIONFAILURE

CellSynchronisationReconfiguration[3.84McpsTDD]

CELLSYNCHRONISATIONRECONFIGURATION REQUEST

CELLSYNCHRONISATIONRECONFIGURATION RESPONSE

CELLSYNCHRONISATIONRECONFIGURATION FAILURE

Cell

SynchronisationAdjustm

ent[3.84Mc

ps TDD]

CELL

SYNCHRONISATION ADJUSTMENTREQUEST

CELL

SYNCHRONISATION ADJUSTMENTRESPONSE

CELL

SYNCHRONISATION ADJUSTMENTFAILURE

Informa

tionExchang

eInitiatio

n

INFORMATION

EXCHANGEINITIATION

REQUEST

INFORMATION

EXCHANGEINITIATION

RESPONSE

INFORMATION

EXCHANGEINITIATION

FAILURE

TABL E 7 CL AS S 2


Resource Status Indication RESOURCE STATUS INDICATION

Audit Required AUDIT REQUIRED INDICATION

Common MeasurementReporting

COMMON MEASUREMENT REPORT

Common MeasurementTermination

COMMON MEASUREMENTTERMINATION REQUEST






Common MeasurementFailure

COMMON MEASUREMENT FAILUREINDICATION

Synchronised Radio LinkReconfiguration Commit

RADIO LINK RECONFIGURATIONCOMMIT

Synchronised Radio LinkReconfiguration Cancellation

RADIO LINK RECONFIGURATIONCANCEL

Radio Link Failure RADIO LINK FAILURE INDICATION

Radio Link Restoration RADIO LINK RESTORE INDICATION

Dedicated Measurement

Reporting

DEDICATED MEASUREMENT REPORT

Dedicated MeasurementTermination

DEDICATED MEASUREMENTTERMINATION REQUEST

Dedicated MeasurementFailure

DEDICATED MEASUREMENT FAILUREINDICATION

Downlink Power Control

[FDD]

DL POWER CONTROL REQUEST

Compressed Mode Command

[FDD]

COMPRESSED MODE COMMAND

Unblock Resource UNBLOCK RESOURCE INDICATION


Downlink Power Timeslot

Control [TDD]

DL POWER TIMESLOT CONTROL

REQUEST

Radio Link Pre-emption RADIO LINK PREEMPTION REQUIREDINDICATION

Cell SynchronisationReporting [3.84Mcps TDD]

CELL SYNCHRONISATION REPORT

Cell SynchronisationTermination [3.84Mcps TDD]

CELL SYNCHRONISATIONTERMINATION REQUEST

Cell Synchronisation Failure

[3.84Mcps TDD]

CELL SYNCHRONISATION FAILURE

INDICATION

Information Reporting INFORMATION REPORT

Information ExchangeTermination

INFORMATION EXCHANGETERMINATION REQUEST

Information ExchangeFailure

INFORMATION EXCHANGE FAILUREINDICATION





Cell Setup Process

F I G U R E 18 CELL SETUP PROCESS

RNC Node B

NBAP. Cell setup request

NCP,CCP and ALCAP set up

Reset process

NBAP and cell setup response

NBAP and SCCPCH setup request

NBAP and SCCPCH setup response

ALCAP: ERQ(FACH)

ALCAP :ECF

ALCAP:ERQ(PCH)

ALCAP:ECF

NBAP: RACH setup request

NBAP: RACH setup response

ALCAP:ERQ( RACH)

ALCAP: ECF

NBAP: System information update request NBAP: System information update response

Node B

startup

process

Cell setup

process

FP synchronization process

PCCPCH





CS Call Origination Flow

(RRC Setup on CCH)F I G U R E 19 C AL L ORI G I NAT I O N F L O W (RRC SE T UP O N CCH)

RRC connection req. （RACH –CCCH）

RL setup req

RL setup resp.

ALCAP EST. req

ALCAP EST. cfn

RRC connection setup( FACH –CCCH)

RRC connection setup comp.(RACH—DCCH)

INITIAL DT(CM service req)( DCCH)

DT(setup)

DT(call proceeding)

DT(Authentication req)

DT(Authentication resp)

Initial UE message

RAB assig nment req

RB setup

RB setup comp RAB assignment resp

DT(alerting)

DT(connect)

DT(connect ack)

UE NodeB RNC MSC

DT(CM service accept)

DCH_FP:Uplink SYNC

DCH_FP:Downlink SYNC





CS Call Origination Flow

(RRC Setup on DCH)F I G U R E 20 CS C AL L O RI G I NAT I O N FL O W (RRC SE T UP O N DCH)

RRC connection req.

RL setup req

RL setup resp.

ALCAP EST. req

ALCAP EST. cfn


RRC connection setup comp.

INITIAL DT(CM service req)

DT(setup)

DT(call proceeding)



Initial UE message

RAB assignment reqRL reconfig pre

RL reconfig ready

ALCAP EST. req

ALCAP EST. cfn

RL reconfig commit

RB setup


DT(alerting)

DT(connect)

DT(connect ack)

UE NodeB RNC MSC

ALCAP EST. req

ALCAP EST. cfn

DT(CM service accept)

DCH_FP:Uplink SYNC

CH_FP:Downlink SYNC





CS Call Termination Flow

F I G U R E 21 CS CA L L T E RM I NAT I O N FL O W (RRC SE T UP O N DCH)

RRC connection req.

RL setup req

RL setup resp.

ALCAP EST. req

ALCAP EST. cfn


INITIAL DT(Paging resp)

DT(setup)

DT(call confirmed)



Initial UE message

RAB assignment reqRL reconfig pre

RL reconfig ready

ALCAP EST. req

ALCAP EST. cfn

RL reconfig commit

RB setup


DT(alerting)

DT(connect)

DT(connect ack)

Paging type1 paging

UE B NodeB RNC MSC

ALCAP EST. req

ALCAP EST. cfn

DCH_FP：UL SYNC

DCH_FP：DL SYNC

RRC connection setup comp.





Release Flow in CS Domain

CN OriginatesF I G U R E 22 R E L E AS E FL O W I N CS D O M AI N CN I NI T I AT E S

DT release

DT Release com

RRC connection release

RRC connection release com

IU release command

IU release com

RL delete

RL delete res

ALCAP REL. re

ALCAP REL. cfn

UE NodeB RNC MSC

ALCAP EST. re

ALCAP EST. cfn

DT disconnection





Release Flow in CS Domain

UE OriginatesF I G U R E 23 R E L E AS E FL O W I N CS D O M AI N UE I NI T I AT E S

DT re ease

DT Release com

RRC connection release

RRC connection release com

IU release command

IU re ease comp

RL delete

RL delete resp

ALCAP REL. req

ALCAP REL. c n

UE NodeB RNC MSC

ALCAP EST. req

ALCAP EST . c n

DT sconnect on

Documents

Interface Protocol and Signaling Flow