Umts Call Flows 3k3j1b

Module 01 UE-UTRAN Signalling Protocols

Version 0.0.1 (07/02/2005) Author: Alexander Seifarth ([email protected])

1

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

1. Network Architecture

2

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

1. Network Architecture 1.1. Top Level Network Architecture

3

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

1.1. Top Level Network Architecture

Uu

UTRAN UTRAN

Iu

(UMTS (UMTSTerrestrial Terrestrial Radio RadioAccess Access Network) Network)

CN CN (Core (CoreNetwork) Network)

UE

Non Access Protocols Access Protocols

Access Protocols

intra-CN protocols

intra-UTRAN protocols

4

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

1.1. Top Level Network Architecture UMTS inherits its top level network architecture from second generation mobile communication networks. Any UMTS network can be divided into three major network subsystems: • UE ( Equipment): The UE is built from Mobile Equipment (ME) providing all required hard- and software to gain access to the network and a UMTS Subscriber Identity Module (USIM). In other words the UE is a 3G enabled cell phone. • UTRAN (UMTS Terrestrial Radio Access Network): The major change of UMTS compared to second generation systems like GSM is the radio access technology. Instead of the classical GSM BSS (Base Station Subsystem) using TDMA/FDMA radio access there is now UTRAN utilizing CDMA (Code Division Multiple Access). UTRAN currently comes in three different flavours – FDD mode, TDD mode and low chip rate TDD mode. (This script focuses on FDD mode). • CN (Core Network): The core network is the same for GSM and UMTS. It is responsible to provide telecommunication services like mobility handling, circuit switched call services, packet switched data services and messaging service. The CN can be split into domains – the CS domain and the packet switched domain. Several signalling protocols provide the communication facilities between these subsystems. To establish the basic communication links (access links) between UE-UTRAN and UTRAN-CN there are access signalling protocols between these subsystems. On the other hand for telecom services there are protocols between UE and CN for mobility management, CS call management, PDP context management, SMS, etc. These protocols belong to the so called nonaccess signalling protocols. These non-access protocols are exchanged between UE and CN directly. UTRAN must transparently signalling messages from non-access signalling protocols from UE to CN and vice versa. Obviously there are also protocols inside UTRAN and inside CN. These are labelled intra-UTRAN or intra-CN protocols respectively.

5

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

1. Network Architecture 1.2. Network Elements and Interfaces

6

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

1.2. Network Elements and Interfaces Node B

RNC

Iub

MSC/VLR Server#1

Iu-CS

CS MGW #1 Iub Uu

...

Node B MSC/VLR Server#N

Iur

RNS

UE Node B

Iub

CS MGW #K

RNC

CS-CN

RNS BTS

BSC

BSS 7

June 1, 2005

CONFIDENTIAL - DRAFT

SGSN #1

Iu-PS

...

A Iu-PS Gb

SGSN #L

PS-CN Alexander Seifarth

1.2. Network Elements and Interfaces UTRAN is composed of two different network elements: • RNC (Radio Network Controller): The RNC is responsible for all radio management tasks inside of UTRAN. This includes channel allocation/modification/removal, handover procedures, security functions, etc. • Node B: The Node B serves one or more cells. The tasks of the Node B is to terminated the physical layer (WCDMA FDD) and convert it to the transport protocol on the Iub interface towards RNC. In other words the Node B is a relay point. Anything above the radio physical layer must transparently through the Node B. Between RNC and Node B there is the Iub interface. Its task is to transfer data ( data, signalling) between UE and RNC. Furthermore there is an optional interface Iur between two RNC. The Iur interface is related to soft handover procedures. This interface is similar to the Iub interface used for transparent transfer of data between UE and the so called serving RNC. For the connection between UTRAN and CN there is the Iu interface defined. It comes in two different versions – Iu-CS for the connectivity between RNC and MSC (MSC server, CS Media Gateway MGW) and Iu-PS for RNC-SGSN communication. The Iu interfaces shall transfer data (CS speech calls, CS data calls, PDP context data), non-access signalling to and from the UE and access signalling between RNC and MSC/SGSN. Iu, Iub and Iur interfaces are currently based on ATM as transport layer technology, but also IP may be used. The IP based UTRAN is already specified. In parallel to UTRAN the classical GSM BSS may still be used together with UTRAN. Thus the core network still provides connectivity for A and Gb interface. Note that in future releases also the GSM BSS may be based on Iu interfaces rather than the old second generation protocols.

8

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

1.2. Network Elements and Interfaces MSC Server

CS-MGW SGSN Iu-PS

Iu-CS

Serving RNC

Serving RNC

• radio management (handover decision, channel de/allocation • NAS message relay • Iu management • backward error correction • splitting/combination function • local and global ission control

Drift RNC Iur

Iub Node B

Iub

Iub

Node B

Node B

Drift RNC • relay between Iur and Iub • splitting/combining function [optional] • local ission control

UE 9

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

1.2. Network Elements and Interfaces A UE can be in one of two states: • IDLE: A UE in IDLE mode has no connectivity to UTRAN, in other words there is no signalling relation with an RNC and of course no radio resources are allocated for the UE. • CONNECTED: A CONNECTED mode UE has a signalling relation with an RNC which performs all radio management tasks for this UE. This special RNC is called the serving RNC (S-RNC) for the UE. A single UE has in CONNECTED mode exactly one serving RNC, in IDLE mode there is no serving RNC for the UE. During soft handover procedures it can happen, that a UE is connected with a cell that does not belong to the serving RNC’s area. The RNC managing this cell is called a drift RNC (D-RNC). A D-RNC must have an Iur interface to the serving RNC of the UE. The drift RNC must not perform radio management procedures for the UE, this is task of the serving RNC. The drift RNC provides functionality to relay data between serving RNC and UE. In other words the drift RNC is a Iub/Iur relay. In some RNC equipment also functionality to combine and split data streams to/from a UE during soft handover can be provided.

10

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

1. Network Architecture 1.3. UTRAN/UE Main Functional Protocols Overview

11

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

1.3. UTRAN/UE Main Functional Protocols WCDMA WCDMA UE

Node B

NBAP NBAP ALCAP ALCAP

Uu

Uu

RANAP RANAP

Iub

RRC RRC

RNC

ALCAP ALCAP

MSC/VLR Server Iu-CS

CS-MGW Iu-CS

Iub

Iur

ALCAP ALCAP RNSAP RNSAP

RNC

12

June 1, 2005

CONFIDENTIAL - DRAFT

RANAP RANAP

SGSN Iu-PS

Alexander Seifarth

1.3. UTRAN/UE Main Functional Protocols There are some main functional protocols within UTRAN that implement the UMTS specific operations. These protocols are: • RRC (Radio Resource Control): The RRC protocol is exchanged between UE and serving RNC. It provides functions for radio channel management, handover, security functions, measurements, etc. • RANAP (Radio Access Network Application Part): RANAP is the main protocol on the Iu interfaces. MSC server and SGSN use RANAP signalling messages to allocated radio access bearers and to handle relocation of the serving RNC. • NBAP (Node B Application Part): NBAP is the control protocol on the Iub interface. It allows the RNC to command the Node B to allocate or delete channels on the air interface, to transport Node B measurements to the RNC. Although there is a detailed specification of NBAP, most of all available UTRAN equipment implements a propriety version of NBAP. • RNSAP (Radio Access Network Application Part): RNSAP is used on Iur interface, thus it is an open protocol. The RNSAP protocol extends the NBAP protocol, so that a serving RNC can allocate radio resources on cells owned by a drift RNC. Some other functions of RNSAP concern the relocation of the serving RNC function and packet data forwarding from old to new RNC over Iur. The mentioned protocols RRC, NBAP, RANAP, RNSAP are UTRAN specific protocols. On Iub, Iur and Iu-CS interfaces realtime data streams will be transported. Thus before such a real-time data stream can be transferred, an appropriate transmission bearer must be allocated on the transport network, this requires another protocol: • ALCAP (Access Link Control Application Part): The term ALCAP is a generic “placeholder” for a transport network specific control protocol to allocate transport bearers for delay sensitive data. In case of ATM-AAL2 transport network the ACLAP is the ITU-T protocol Q.2630 (AAL type 2 signalling protocol). If IP/UDP is used instead, the ALCAP is not defined, because in IP/UDP there is no resource allocation defined.

13

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

1.3. UTRAN/UE Main Functional Protocols NAS Signalling Relay

MM MM

CC CC

SS SS

MSC/VLR Server

SMS SMS

RNC

UE

CS-MGW

CS CSdata data

RNS GMM GMM

14

June 1, 2005

SM SM

CONFIDENTIAL - DRAFT

SMS SMS

PS PSdata data

SGSN

Alexander Seifarth

1.3. UTRAN/UE Main Functional Protocols The non-access signalling protocols between UE and MSC server/SGSN are the direct transfer application part (DTAP) protocols known from GSM/GPRS. For the CS services there are: • MM (Mobility Management): This protocols provides location area update, authentication, IMSI detach procedures and some others (e.g. identity request, MM information). • CC (Call Control): Here we find mobile originated and mobile terminated call setup, local and remote call release, as well as call related supplementary services, mid-call modification and DTMF interaction. • SS (Supplementary Services): This protocol allows to trigger non-call related supplementary services like USSD, management of call forwarding and call barring, etc. For PS core network the following protocols are used: • GMM (GPRS Mobility Management): This protocol defines GPRS attach, GPRS detach, routing area update, authentication, service request and some other procedures (e.g. identity request, GMM information). • SM (Session Management): The SM protocol provides the functionality for PDP context activation, PDP context deactivation and PDP context modification. For PS and CS core network domain the short messaging service is possible. The protocols for SMS are identical for both domains: • SMS (Short Message Service): The SMS protocol suite consists of SM- (Short Message Control Protocol), SM-RP (Short Message Relay Protocol), SM-TL (Short Message Transfer Layer) and SM-AL (Short Message Application Layer).

15

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

1. Network Architecture 1.4. UTRAN Protocol Stacks on Iux Interfaces

16

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

1.4. Protocol Stacks on Iux Interfaces – Iu-CS Serving RNC

MSC/VLR Server

Iu-CS (control plane)

CS-MGW

Iu-CS ( + transport network control plane)

Control Plane MM MM

CC CC

SS SS

SMS SMS

Transport Network Control Plane

RANAP RANAP

Plane CS call data Iu Iu . . . UP UP

Iu Iu UP UP

Iu Iu . . . UP UP

Iu Iu UP UP

ALCAP ALCAP

SC SC MTP3B MTP3B SAAL SAAL

SAAL SAAL

PVC

PVC

...

SAAL SAAL

AAL2 AAL2

PVC

PVC

...

AAL2 AAL2 PVC

ATM ATM 17

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

1.4. Protocol Stacks on Iux Interfaces – Iu-CS On the Iu-CS interface the main functionality is to transfer CS call (speech, video, data) between RNC and CS media gateway (CS-MGW). CS data is carried over the Iu UP (Iu Plane) protocol from RNC to CS-MGW and vice versa. The Iu UP protocol s codecs with multiple data rate modes like the AMR codec. Each application has its own Iu UP instance which is carried as AAL2 call inside a AAL2 virtual channel. To allocate AAL2 calls inside a AAL2 virtual channel the establishment procedure of the ALCAP protocol (Q.2630) must be used. In the same way when the application terminates, the associated AAL2 call must be released by ALCAP’s release procedure. Thus the ALCAP protocol is required between RNC and CS-MGW. The UMTS specific higher layer control of radio access bearers the AAL2 call belongs to the RANAP protocol is used. RANAP uses the SC (Signalling Connection Control Part) for virtual signalling connection between RNC and MSC server to identify a single UE. For signalling message transfer MTP3B (Message Transfer Part level 3 Broadband) is used. This is commonly known as broadband or high speed SS7. MTP3B provides routing facilities between RNC, MSC server and CS-MGW. The transmission is done on one or more high speed SS7 signalling links. Such high speed links are provided via SAAL (Signalling ATM Adaptation Layer) protocol instances. Each SAAL represents one ATM virtual channels together with retransmission functionality to increase transmission reliability. The non-access signalling protocol for the circuit switched side (MM, CC, SS, SMS) are carried over RANAP.

18

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

1.4. Protocol Stacks on Iux Interfaces – Iu-PS Serving RNC

SGSN

Iu-PS (control plane, plane)

Control Plane

Plane

SM SM

PS call data (PDP Contexts)

GMM GMM

SMS SMS

...

RANAP RANAP

GTP-U GTP-U

SC SC

UDP UDP

MTP3B MTP3B

IP IP

SAAL SAAL

SAAL SAAL

PVC

PVC

...

SAAL SAAL

AAL5 AAL5

PVC

PVC

...

AAL5 AAL5 PVC

ATM ATM 19

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

1.4. Protocol Stacks on Iux Interfaces – Iu-PS On Iu-PS data consists of PDP context packets. PDP context data is transferred over the GTP-U (GPRS Tunnelling Protocol – plane). GTP-U provides so called GTP-U tunnels which are used to identify subscriber and PDP context and to route PDP context data correspondingly. The GTP-U protocol uses IP/UDP as transport layer. The IP layer routes between RNC and SGSN. In an ATM environment IP is transmitted over one or more AAL5 virtual channels. The control stack is similar to Iu-CS. The RANAP protocol is used between SGSN and RNC to allocate radio access bearer services for PDP contexts. There is no ALCAP on Iu-PS because AAL2 is not used here. Obviously the non-access signalling protocols on Iu-PS are different to Iu-CS. Between RNC and SGSN we can find GMM, SM and SMS on RANAP.

20

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

1.4. Protocol Stacks on Iux Interfaces – Iub UE

Node B

Uu

Iub

Control Plane Transport Network Control Plane

RNC

Plane Transport Channel Data

TrCH TrCH TrCH TrCH FP FP ... FP FP

NBAP NBAP

TrCH TrCH ... FP FP

ALCAP ALCAP ... ALCAP ALCAP SAAL SAAL PVC

...

SAAL SAAL

SAAL SAAL

PVC

PVC

...

SAAL SAAL

AAL2 AAL2

PVC

PVC

AAL2 AAL2 ...

PVC

ATM ATM 21

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

1.4. Protocol Stacks on Iux Interfaces – Iub On the Iub interface data ( data and signalling) to and from the UE must be transported transparently. This UE-RNC is data is transferred in form of so called transport channels TrCH. Each transport channel is carried over Iub in a Frame Protocol (FP). Each such frame protocol FP uses a single AAL2 call inside a AAL2 virtual channel as transport resource. To allocate a AAL2 call for a frame protocol instance, again the ALCAP protocol is required. The ALCAP is carried over a single SAAL ATM virtual channel. Dependent on the RNC/Node B vendor also one or several ALCAP instances might be used on Iub. The main protocol on Iub, the NBAP protocol, may also be split into several parts. Again this depends on the equipment vendor. Thus one or more SAAL ATM virtual channels are required to transfer NBAP messages over the Iub interface.

22

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

1.4. Protocol Stacks on Iux Interfaces – Iur UE Uu

Node B Iub

Control Plane RNSAP RNSAP

Transport Network Control Plane

SC SC

Iur

Drift RNC

Serving RNC

Plane Transport Channel Data

TrCH TrCH TrCH TrCH FP FP ... FP FP

ALCAP ALCAP

TrCH TrCH ... FP FP

MTP3B MTP3B SAAL SAAL SAAL SAAL PVC

PVC

...

SAAL SAAL

AAL2 AAL2

PVC

PVC

AAL2 AAL2 ...

PVC

ATM ATM 23

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

1.4. Protocol Stacks on Iux Interfaces – Iur The Iur interface is comparable to Iub with two differences. First instead of NBAP the RNSAP protocol is used. The second difference is that RNSAP and ALCAP use broadband SS7 for transfer and routing of signalling messages between serving RNC and drift RNC.

24

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

2. Radio Protocol Architecture and Channels

25

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

2. Radio Protocol Architecture and Channels 2.1. Radio Protocol Architecture

26

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

2.1. Radio Protocol Architecture NAS Protocols MM MM GMM GMM SM SM

CC CC

RRC RRC ... #1

CS CS App App

SS SS SMS SMS

... RAB

PS PS PDP PDPCtx. Ctx.

RAB

CB CB SMS SMS App App

Radio Bearer (RB) #x

#y1

... RLC RLC ... RLC RLC

RLC RLC

#y

#z

PD PD

BMC BMC

#y2

RLC RLC

RLC RLC ... RLC RLC

Logical Channels (LogCH) #1

#x

#y1

#y2

#y

#z

Medium MediumAccess AccessControl Control(MAC) (MAC) Transport Channels (TrCH)

#1

#2

WCDMA WCDMAPhysical PhysicalLayer Layer(FDD) (FDD)

#1

27

June 1, 2005

#n

Physical Channels (PhCH) CONFIDENTIAL - DRAFT

#k

RF Alexander Seifarth

2.1. Radio Protocol Architecture The UMTS radio protocol architecture as it is implemented in the UE has the following protocols: • WCDMA Physical Layer: The physical layer offers bit transport services in form of so called transport channel TrCH. To transmit TrCH data over the air the physical layer has access to physical channels PhCH. A PhCH represents the physical resource and is identified by frequency, scrambling code and channelization code (plus some additional parameters for certain channels). • Medium Access Control (MAC): MAC protocol has the task to include or check UE identifiers on transport channels that are shared between several UE (common transport channels). The transport services are offered to higher layers in form of logical channels LogCH. Thus the MAC also has to multiplex and demultiplex logical channels onto or from transport channels. • Radio Link Control (RLC): To each logical channel there is one RLC instance. The RLC belongs to a single radio bearer (RB) which represents the transmission resource for a layer 3 application (codec, RRC protocol, PDP context). The RLC protocol offers reliability in form of sequence numbering and backward error correction. Typically one RLC belongs to one logical channel, but for acknowledged mode one RLC instance can also utilize two logical channels. • Packet Data Convergence Protocol (PDPC): This protocol is applicable for radio bearers belonging to PDP contexts only. The protocol performs IP header compression and optionally also IP datagram numbering. • Broadcast Multicast Control (BMC): This protocol exists only for cell broadcast SMS radio bearer. This protocol contains the scheduling messages and the basic CB SMS frames. • Radio Resource Control (RRC): The main signalling protocol for radio resource management. For a single application one or more radio bearers have to be allocated. For applications all radio bearers of a single application are combined in a radio access bearer (RAB).

28

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

2. Radio Protocol Architecture and Channels 2.2. Logical Channel Types and their Usage

29

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

2.2. Logical Channel Types and their Usage UE Identification in UTRAN UE

Case No NoUE UEIdentification Identification

Uu

Node B

Iub

Serving RNC

UE Identification in RNC Some information (System Information, CB SMS) does not require a UE identification.

Layer Layer11Identification Identification

UE must have a dedicated physical resource. This resource uniquely identifies the UE for the time the resource is assigned to it.

Layer Layer22Identification Identification

UE uses common resources and identifies itself with a special MAC header identifier (c-RNTI, u-RNTI, dschRNTI) on that resource.

Layer Layer33Identification Identification

30

June 1, 2005

UE has no dedicated resource and no assigned MAC header identifier, but uses common resources (RRC signalling only). The RRC message must contain a UE identifier as layer 3 parameter. CONFIDENTIAL - DRAFT

Alexander Seifarth

2.2. Logical Channel Types and their Usage Logical Channel Types

ptm: ptp: dl: ul:

Control Channels

point-to-multipoint point-to-point downlink uplink

BCCH BCCH

Broadcast Control Channel [dl, ptm]

System Information broadcast; downlink channel; no UE specific information

PCCH PCCH

Paging Control Channel [dl, ptm]

Point-to-multipoint paging procedure (Paging Type 1) UE identification by RRC message itself

CCCH CCCH

Common Control Channel [ul+dl, ptp]

Point-to-point RRC signalling on common resource when no MAC identifier available

DCCH DCCH

Dedicated Control Channel [ul+dl, ptp]

Point-to-point RRC signalling on common or dedic. resource with MAC identifier available (on common resource)

Traffic Channels

31

June 1, 2005

DTCH DTCH

Dedicated Traffic Channel [ul|dl|ul+dl, ptp]

CTCH CTCH

Common Traffic Channel [dl (currently), ptm]

Point-to-point data (CS data, CS speech, PS data) on common or dedicated resource (requires MAC-ID on common resource). Used for cell broadcast SMS. Thus no UE-ID.

CONFIDENTIAL - DRAFT

Alexander Seifarth

2.2. Logical Channel Types and their Usage For FDD mode the following logical channel types are defined: • BCCH (Broadcast Control Channel): The BCCH carries the cell’s system information, which are RRC messages (System Information Blocks, Master Information Block). The BCCH is not associated with a radio bearer. • PCCH (Paging Control Channel): The PCCH carries RRC messages ‘Paging Type 1’. This message type is used to page a UE or to indicate system information changes. Like the BCCH there is no radio bearer associated with the PCCH. • CCCH (Common Control Channel): The CCCH is a bi-directional RRC signalling channel where layer 3 identification is required. The UE uses CCCH signalling at the beginning of communication when no DCCH is available. Only radio bearer RB 0 is attached to CCCH. RB 0 is configured via system information, because it works as a start up point. • DCCH (Dedicated Control Channel): The normal bi-directional RRC signalling and also rate control signalling is exchanged on a DCCH. Every DCCH is associated with its own radio bearer which must be configured via explicit RRC signalling from RNC to UE. On DCCH only layer 1 or layer 2 identification is allowed. • DTCH (Dedicated Traffic Channel): CS call data (speech, video, data) as well as PDP context data is carried over DTCH. Like for DCCH also on DTCH layer 1 or layer 2 identification is required, layer 3 identification is not possible. • CTCH (Common Traffic Channel): This channel type is currently used for cell broadcast SMS (CB SMS) only. It should be obvious that any DTCH or CTCH requires an associated radio bearer. Such radio bearers are granted via RRC procedure from the RNC to the UE.

32

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

2. Radio Protocol Architecture and Channels 2.3. Transport Channel Types and their Usage

33

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

2.3. Transport Channel Types and their Usage Node B

Dedicated TrCH • mapped onto dedicated physical resources • only one UE can use the physical resource • automatically provides Layer 1 identification for the UE assigned to the channel • used with DCCH and DTCH

Common TrCH

WCDMA FDD cell common physical channel

dedicated physical channels

• mapped onto shared physical resources • multiple UE can be assigned to same physical resource • requires Layer 2 identification for DCCH, DTCH • requires Layer 3 identification for CCCH, PCCH [opt]

Common CommonTrCH TrCH

UE

Dedicated DedicatedTrCH TrCH Dedicated DedicatedTrCH TrCH

UE 34

Common CommonTrCH TrCH

Dedicated DedicatedTrCH TrCH June 1, 2005

CONFIDENTIAL - DRAFT

UE

Alexander Seifarth

2.3. Transport Channel Types and their Usage 1 Transport Channel Types

dl: ul:

downlink uplink

Common Channels BCH BCH

Broadcast Channel [dl, 1/cell]

Carries BCCH.

PCH PCH

Paging Channel [dl, ≦16/cell]

Carries PCCH.

RACH RACH

Random Access Channel [ul, ≦16/cell]

Can carry CCCH, DCCH and DTCH. Minimum SF is 32 and maximum transmission time is 10|20 ms.

FACH FACH

Forward Access Channel [dl, ≦16/cell]

DSCH DSCH

Downlink Shared Channel [dl, ≦?/cell]

CH CH

Common Packet Channel [ul, ≦64/cell]

HS-DSCH HS-DSCH 35

June 1, 2005

High Speed DSCH [dl, ≦16/cell]

Can carry CCCH, DCCH, DTCH, BCCH and CTCH. Minimum SF is 4. Carries DCCH and DTCH. A DSCH is always used together with one or more DCH. Carries DCCH and DTCH. Minimum SF is 4 and maximum transmission time is 80 ms. Carries DCCH and DTCH. Can switch between QPSK and 16QAM on physical channel.

CONFIDENTIAL - DRAFT

Alexander Seifarth

2.3. Transport Channel Types and their Usage 2 Transport Channel Types Dedicated Channels DCH DCH

36

June 1, 2005

Dedicated Channel [ul|dl]

One DCH can carry one or more DCCH or one DCH can carry one or more DTCH.

CONFIDENTIAL - DRAFT

Alexander Seifarth

2.3. Transport Channel Types and their Usage A single transport channel has a certain characteristics that describes how bits are transmitted over the air interfaces. This concerns bit rate, delay and reliability. A special characteristics is whether the associated physical channel used for transport channel data transmission is dedicated to a single UE or must be shared between several UE. This means that we have two groups of transport channels – dedicated TrCH and common TrCH. Common transport channels are created during cell setup or O&M triggered cell reconfiguration. In UMTS FDD mode we have the following common transport channels: • BCH (Broadcast Channel): There is exactly one BCH per cell and it is used to carry BCCH. The format of a BCH is fixed by specification so that any UE camping on a cell can read the BCH. • PCH (Paging Channel): A PCH carries PCCH. A cell may have up to 16 PCH by specification. A UE selects a PCH depending on subscriber identity. • RACH (Random Access Channel): The random access channel is used to carry CCCH, DCCH, DTCH in the uplink. In case of CCCH any UE in the cell can freely access the RACH, for DCCH/DTCH a UE has to get permission from the RNC to do so. Especially it is so that for DCCH/DTCH on RACH the UE needs a temporary identifier (C-RNTI) for layer 2 identification. • FACH (Forward Access Channel): The FACH is the downlink response channel to the RACH. It is used to carry CCCH, DCCH, DTCH, CTCH and BCCH. For DCCH/DTCH on FACH the already mentioned C-RNTI is required. Note that there is no fixed timing relationship between transmission on RACH and reception on FACH. Rather a UE that uses RACH/FACH the FACH must be monitored permanently. • CH (Common Packet Channel): The CH is working like the RACH, but is used for DCCH and DTCH only. Compared to the RACH the CH allows higher bit rates and longer transmission periods – thus a higher throughput can be achieved on CH.

37

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

2.3. Transport Channel Types and their Usage • DSCH (Downlink Shared Channel): The downlink shared channel shall be used for packet data in the downlink. The channel allows multiplexing of DCCH/DTCH of several UE using time and code multiplexing mechanisms. This shall increase resource usage efficiency. • HS-DSCH (High Speed Downlink Shared Channel): This channel is one of the new features in UMTS Release 5. The HS-DSCH has the same function like the normal DSCH. DCCH/DTCH of several UE shall be multiplexed – again time and code multiplexing is used. The special thing is, that the physical resource allocation and the multiplexing is handled at the Node B, not at the RNC. Furthermore the associated physical channel allows switch between QPSK and 16QAM. In contrast to this the dedicated transport channels which are assigned to a single UE will be created and deleted during normal operation using NBAP/RNSAP- and RRC-procedures. There is only one dedicated transport channel type defined: • DCH (Dedicated Channel): The dedicated channel carries either several (or one) DCCH or several (or one) DTCH. Obviously several logical channels on a DCH belong to the same UE. Thus the DCH is the only case where layer 1 identification is in use. A UE can have several DCH simultaneously. A single DCH is either uplink or downlink.

38

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

2. Radio Protocol Architecture and Channels 2.4. Physical Channels and their Usage

39

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

2.4. Physical Channels and their Usage 1 Physical Channel Types

dl: ul:

downlink uplink

Synchronisation Channels P-SCH P-SCH

Primary Synchr. Channel [dl, 1/cell]

S-SCH S-SCH

Secondary Synchr. Channel Transmits a Secondary Synchr. Code sequence to identify scrambling code group and radio frame start. [dl, 1/cell]

Transmits Primary Synchr. Code (PSC) to detect cell.

Measurement Reference Channels P-ICH P-ICH

Primary Common Pilot CH [dl, 1/cell]

S-ICH S-ICH

Secondary ICH [dl, 0...15/cell]

Transmits a pre-defined symbol sequence (all –1) with the primary dl scrambling code of the cell. Transmits a pre-defined symbol sequence with one the 15 possible secondary scrambling codes of cell.

System Information Broadcast P-CCH P-CCH 40

June 1, 2005

Primary Common Control Physical Channel [dl, 1/cell]

Carries BCH with BCCH. Always scrambled by primary dl scrambling code of the cell.

CONFIDENTIAL - DRAFT

Alexander Seifarth

2.4. Physical Channels and their Usage 2 Physical Channel Types

dl: ul:

downlink uplink

PhCH for FACH and PCH S-CCH S-CCH

Secondary Common Control Physical Channel [dl, ≦ 16/cell]

PICH PICH

Paging Indicator Channel [dl, ≦ 16/cell]

Carries either 1) FACH only, 2) PCH only or 3) FACH + PCH multiplexed. Contains paging indicators for discontinuous reception (DRX) in association with a PCH.

PhCH for RACH PRACH PRACH AICH AICH

41

June 1, 2005

Physical Random Access Channel [ul, ≦ 16/cell] Acquisition Indicator Channel [dl, ≦ 16/cell]

Consists of a preamble part to perform open loop power control and a data part transferring RACH data. Associated with a single PRACH. Carries the preamble responses (acquisition indications).

CONFIDENTIAL - DRAFT

Alexander Seifarth

2.4. Physical Channels and their Usage 3 Physical Channel Types

dl: ul:

downlink uplink

PhCH for DCH DPCH DPCH

Dedicated Physical Channel Carries one or several DCH of a single UE and [dl, dynamical allocation] physical layer information (TPC, pilot bits, TFCI). Data rate ≦1860 kpbs (SF=4). [Physical channel bit rate]

DPCCH DPCCH

Dedicated Physical Ctrl CH [ul, dynamical allocation] [ 1/UE]

DPDCH DPDCH

Dedicated Physical Data CH Carries one or several DCH of a single UE to Node B. [ul, dynamical allocation] Data rate ≦ 960 kpbs (SF=4). [Physical channel bit rate] [≦6/UE]

Carries physical layer information from a single UE to Node B (TPC, pilot bits, TFCI, FBI). SF=256 fix.

PhCH for DSCH PDSCH PDSCH DPCH DPCH 42

June 1, 2005

Physical Downlink Shared Channel [dl, dynamical allocation of codes]

Carries a DSCH with DCCH/DTCH of several UE multiplexed by time and channelization codes. Data rate ≦ 1920 kbps (SF=4).[Physical channel bit rate]

Dedicated Physical Channel A PSDCH must be used by together with DPCH by a [dl, dynamical allocation]

UE. The DPCH contains physical layer control bits.

CONFIDENTIAL - DRAFT

Alexander Seifarth

2.4. Physical Channels and their Usage 4 Physical Channel Types

dl: ul:

downlink uplink

PhCH for CH PCH PCH

Physical Common Packet Channel [ul]

Carries CH with DCCH/DTCH of several UE multiplexed by time (asynchronous) and CH access preambles, collision detection preambles and power control preambles. Data rate ≦960 kpbs (SF=4) for max. 80 ms.

AP-AICH AP-AICH

Access Preamble Acquisition Indicator CH [dl]

Gives positive or negative acquisition indications to CH access preambles for CH access preambles.

Collision Detection/ CD/CA-ICH CD/CA-ICH Channel Assignment Indicator Channel [dl]

43

June 1, 2005

Gives collision indications or channel assignment indications (code alloc.) for CH collision preambles.

CSICH CSICH

CH Status Indicator CH [dl]

Gives status indications about availability/nonavailability of CH resources.

DPCH DPCH

Dedicated Physical CH [dl]

Carries physical layer control bits (TPC) used for closed loop power control of PCH.

CONFIDENTIAL - DRAFT

Alexander Seifarth

2.4. Physical Channels and their Usage 5 Physical Channel Types

dl: ul:

downlink uplink

PhCH for HS-DSCH HS-PDSCH HS-PDSCH

High Speed Physical Downlink Shared Channel [dl, ≦ 15/cell]

Carries a HS-DSCH with DCCH/DTCH of several UE. Fixed spreading factor 16. Up to 15 HS-PDSCH may be used in parallel. Can switch between QPSK and 16QAM. Single HS-PDSCHData rate =960 kpbs (16QAM) and

=480 kbps (QPSK).

HS-SCCH HS-SCCH

HS-DSCH related Shared Control Channel [dl, ≦4 per HS-DSCH]

HS-DPCCH HS-DPCCH

Transmits quality indicator (C/I) and Dedicated Physical CH [ul, 1 per UE on HS-DSCH] acknowledgements for received data on HS-PDSCH

On this channel the physical layer assigns a UE the HS-PDSCH for the next transmission period.

from UE to Node B.

44

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

2. Radio Protocol Architecture and Channels 2.5. Radio Bearers (RB) and Radio Access Bearers (RAB)

45

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

2.5. RB and RAB - Architecture UE

RB 1 RB 2

R R C A M R

Serving RNC

RB 3 RB 4 RB 5

A B C

RB 6 RB 7 RB 8

MSC Server CS-MGW

R R C Rate control

Iu UP

RAB (CS) RAB subflow 1 RAB subflow 2 RAB subflow 3

RAB (PS)

PDP Ctx. 1

RB 9

PDP Ctx. 2

AMR A B C Iu UP

PDP Context 1 PDP Context 2

RAB (PS) SGSN

46

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

2.5. RB and RAB - Architecture Transmission resources for telecommunication services in UMTS are handled on several levels – each network subsystem is responsible for its own resources. This allows to handle transmission resources on different time scales. As shown in the section about the radio protocol architecture within UTRAN each application uses one or more so called Radio Bearers (RB). Radio bearers are used for signalling (RRC protocol messages, rate control signalling) as well as for data applications (CS calls, PDP contexts). But data applications have to be terminated by the core network. Thus for each active application the core network establishes one so called Radio Access Bearer (RAB). A RAB can be considered as a virtual transmission resource between UE and CN. Depending on the application a single RAB can utilize one or more radio bearers. For PDP contexts it is even possible to have a RAB without radio bearer. Note that a PDP context can be active with and also without radio access bearer. The SGSN removes or reallocates the RAB by timer supervision. Whereas the radio bearers are removed and reallocated by the RNC also by timer supervision.

47

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

2.5. RB and RAB – RRC Radio Bearer Usage NAS Protocols MM MM GMM GMM SM SM

CC CC

high priority signalling transfer

SS SS SMS SMS low priority signalling transfer

RRC RRC RB 0 RLC

RB 1 RLC

RB 2

RB 3

RLC

RLC

RB 4 RLC

(UL:TM; DL:UM)

(UL/DL:UM)

(UL/DL:AM)

(UL/DL:AM)

(UL/DL:AM)

CCCH

DCCH 1

DCCH 2

DCCH 3

DCCH 4

MAC MAC

DL-TrCH

UL-TrCH PHY PHY

48

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

2.5. RB and RAB – RRC Radio Bearer Usage The RRC protocol has to use radio bearers for the transmission of its signalling messages. The very first radio bearer RB 0 is special, because it is configured via system information (BCCH) and acts as a start up item for signalling. RB 0 is always mapped to CCCH and is thus found on RACH and FACH. For normal signalling (DCCH) there are RB 1, RB 2, RB 3 and RB 4. RB 1 and RB 2 are used for radio management procedures only, whereas RB 3 and RB 4 are to be used for non-access signalling (CN procedures). The difference between RB 1 and RB 2 is the mode of the associated RLC protocol instance. RB 1 is always running with unacknowledged mode, RB 2 always uses acknowledged mode. RB 3 and RB 4 have to use acknowledged mode, their difference is the priority. RB 3 is for high priority CN signalling (MM, GMM, SM, CC, SS). In contrast to that RB 4 is for low priority signalling (SMS).

49

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

2. Radio Protocol Architecture and Channels 2.6. Channel Configuration Scenario

50

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

2.6. Channel Configuration Scenario UE with one variable rate AMR CS call, 1 PDP context (active data transfer) MM, MM,GMM, GMM,CC, CC,SS, SS,SM, SM,SMS SMS

RRC RRC RB 1

RB 2

RB 3

PDP PDPCtx. Ctx.

AMR AMRcodec codec

RB 4

A

B

C

RB 5

RB 6

RB 7

frame header

RB 8

RB 9 PD

RLC

UM

AM

AM

AM

TM

TM

TM

TM

UM|AM

DCCH 1

DCCH 2

DCCH 3

DCCH 4

DTCH 1

DTCH 2

DTCH 3

DCCH 5

DTCH 5

DCH #0

DCH #1

DCH #2

DCH #3

DCH #4

MAC DCH #31 PHY DL 51

June 1, 2005

DPCH

DPCCH

CONFIDENTIAL - DRAFT

DPDCH

UL Alexander Seifarth

2.6. Channel Configuration Scenario The scenario shown here presents the configuration of a UE in UTRA connected mode with two services running: • one AMR speech call with variable bit rate, • one PDP context with active data transfer. The UE uses several radio bearers RB1, …, RB4 for RRC signalling. Obviously these radio bearers are DCCH. For the AMR codec also four radio bearers are required. RB 5, …, RB 7 carry the encoded speech data in form of the codec’s A, B and C bits. Every 20 ms the codec produces one set of A, B and C bits. Together with the codec frame header which are mapped to RB 8 they form the AMR codec frame. The frame header is essential for rate control of AMR codecs. For the PDP context there is at most one radio bearer RB 9 required. RB 5, 6, 7 and 9 are mapped to DTCH, whereas the radio bearer RB 8 for the AMR codec frame header is DCCH. All RRC signalling radio bearers RB 1, …, RB 4 are multiplexed onto the same DCH (UL-DCH + DL-DCH). RB 5, 6, 7 and 8 belong to the codec but require different reliability settings. Thus they are mapped each to their own DCH (UL/DL). The same is true for the PDP context’s radio bearer RB 9, it also gets its own DCH. On the physical layer all DCH can be multiplexed to a single DPDCH in the uplink and a DPCH in the downlink. If the data rate exceeds the capacity of single DPDCH or DPCH, several physical channels might be used in parallel.

52

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

Module 02 Radio Layer 2 Protocols MAC, RLC, PD Version 0.0.1 (10/02/2005) Author: Alexander Seifarth ([email protected])

1

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

1. Transport Channel Configuration

2

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

1. Transport Channel Configuration 1.1. Transport Formats (TF) and Transport Format Sets (TFS)

3

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

1.1. TF and TFS – Transport Blocks and Format TrCH x

MAC MAC

PHY PHY Transport Block Set TBS

Transport Block Set TBS Transmit Time Interval TTI

Transport Block TB #0 Transport Block TB #1

... Transport Block TB #N-1

Transport Block Set TBS

Transmit Time Interval TTI

Transport Format (TF) channel coding algorithm CRC size rate matching attribute

Transport Block Set TBS

TTI TB size (no. of bits) TBS size (no. of TB in TBS)

time 4

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

1.1. TF and TFS – Transport Format Sets Transport Format Set (TFS) channel coding algorithm

TB size #0

TB size #1

TBS size #0

TBS size #1

TFI 0

TFI 1

CRC size rate matching attribute TTI

| | |-----0-|***b5*** | | | | | | | |***b5*** | | | | | 5

June 1, 2005

1.1.1.1.9 1.1.1.1.9.1 |1.1.1.1.9.1.1 |1.1.1.1.9.1.2 1.1.1.1.9.1.3 1.1.1.1.9.1.3.1 1.1.1.1.9.1.3.1.1 1.1.1.1.9.1.3.1.1.1 1.1.1.1.9.1.3.1.1.1.1 1.1.1.1.9.1.3.1.1.1.1.1 1.1.1.1.9.1.3.1.1.1.1.1.1 |1.1.1.1.9.1.3.1.1.1.1.1.1.1 1.1.1.1.9.1.3.1.1.1.1.2 1.1.1.1.9.1.3.1.1.1.1.2.1 |1.1.1.1.9.1.3.1.1.1.1.2.1.1 1.1.1.1.9.1.3.1.1.1.1.3 |1.1.1.1.9.1.3.1.1.1.1.3.1

TB size #K-1

...

ul-AddReconfTransChInfoList uL-AddReconfTransChInformation ul-TransportChannelType transportChannelIdentity transportFormatSet dedicatedTransChTFS tti tti40 dedicatedDynamicTF-Info rlc-Size octetModeType1 sizeType1 numberOfTbSizeList numberOfTransportBlocks zero logicalChannelList allSizes CONFIDENTIAL - DRAFT

TBS size #K-1

TFI K-1

|dch |32

|16 |0 |0

| | | | | | | | | | | | | | | | |

Alexander Seifarth

1.1. TF and TFS – Transport Format Sets | | | |10000--| | | | | | | |1------|***b8*** |-011----

6

June 1, 2005

1.1.1.1.9.1.3.1.1.1.2 1.1.1.1.9.1.3.1.1.1.2.1 1.1.1.1.9.1.3.1.1.1.2.1.1 |1.1.1.1.9.1.3.1.1.1.2.1.1.1 1.1.1.1.9.1.3.1.1.1.2.2 1.1.1.1.9.1.3.1.1.1.2.2.1 |1.1.1.1.9.1.3.1.1.1.2.2.1.1 1.1.1.1.9.1.3.1.1.1.2.3 |1.1.1.1.9.1.3.1.1.1.2.3.1 1.1.1.1.9.1.3.1.2 1.1.1.1.9.1.3.1.2.1 |1.1.1.1.9.1.3.1.2.1.1 |1.1.1.1.9.1.3.1.2.2 |1.1.1.1.9.1.3.1.2.3

dedicatedDynamicTF-Info rlc-Size octetModeType1 sizeType1 numberOfTbSizeList numberOfTransportBlocks one logicalChannelList allSizes semistaticTF-Information channelCodingType convolutional rateMatchingAttribute crc-Size

CONFIDENTIAL - DRAFT

|16 |0 |0 |third |185 |crc16

| | | | | | | | | | | | | |

Alexander Seifarth

1.1. TF and TFS – Transport Format Sets Each transport channel has to be configured with a set of transport characteristics that control the data transmission within the channel. Data transmission within a transport channel is organized in so called transport blocks (TB). A single transport block TB contains data from one logical channel. Zero, one or more of these transport blocks (also from different logical channels) are assembled in a single transport block set (TBS). One TBS has to be transmitted every transmission time interval (TTI), which can be 10 ms, 20 ms, 40 ms or 80 ms. The configuration of a single transport channel has to configure the TTI, TB size (bits or octets) and TBS size (in number of transport blocks). Every transport block TB gets in the physical layer its own cyclic redundancy check (CRC). The size of the CRC (CRC Size) which can be 0 bits, 8 bits, 12 bits, 16 bits or 24 bits, is a transport channel configuration parameter too. The transport blocks together with their CRC are channel coded with either a ½ convolutional coding, 1/3 convolutional coding or a 1/3 turbo coding. The type of channel coding is also part of the TrCH configuration parameter. A problem of code division multiple access using OVSF channelization code tree is that the number of bits after channel coding must be adapted to the physical layer frame size. This task is performed by the rate matching function. When too many bits are coming from the channel encoder a puncturing algorithm will be used to reduce the number of bits, when too less bits are available some bits will be repeated. The rate matching algorithm is configured with a single rate matching attribute. These parameters: TB size, TBS size, TTI, CRC size, Channel Coding and Rate Matching Attribute form a so called transport format (TF). A single TBS is transmitted with exactly one TF. Several transport formats TF can be configured in parallel for a single transport channel. All TF of a TrCH are called transport format set (TFS). The physical layer’s architecture requires that all TF of a TFS have the same settings for TTI, CRC size, Channel Coding and Rate Matching Attribute. Whenever a new TrCH shall be created it is the RNC that allocates a TFS for it. The TFS is sent to Node B via NBAP signalling. The UE gets the TFS either via System Information (BCCH) or via explicit RRC signalling on a CCCH or DCCH. 7

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

1. Transport Channel Configuration 1.2. Transport Format Combinations TFC

8

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

1.2. Transport Format Combinations TFC MAC MAC

TFS (TrCH 1)

TFI 0

0 kbps

TFI 1

8 kbps

TrCH 1

TFS (TrCH 2) TrCH 2

PHY PHY

9

June 1, 2005

TFI 0

0 kbps

TFI 1

16 kbps

TFI 2

32 kbps

TFCI

TrCH 1

TrCH 2

Total TrCH Bit Rate

0

TFI 0

TFI 1

16 kbps

1

TFI 0

TFI 2

32 kbps

2

TFI 0

TFI 0

0 kbps

3

TFI 1

TFI 0

8 kbps

blocked

TFI 1

TFI 2

40 kbps

blocked

TFI 1

TFI 1

24 kbps

CONFIDENTIAL - DRAFT

Alexander Seifarth

1.2. Transport Format Combinations TFC A UE can use several transport channels simultaneously. Each transport channel has its own set of transport formats assigned. This means at every time instant every transport channel transmits a TBS using a certain transport format. A set of one transport format for every configured transport channel is a transport format configuration (TFC). Which transport format combinations TFC are permitted is indicated by the RNC to the UE. One major function that uses TFC restrictions is the ission control, because in the end effect each TFC is associated with a certain required transmission power.

10

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

2. Medium Access Control MAC

11

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

2. Medium Access Control MAC 2.1. MAC Entities

12

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

2.1. MAC Entities Node B

UE

NBAP

13

MAC-b

BCH

MAC-c/sh

RACH, FACH, DSCH, CH,PCH

MAC-hs

HS-DSCH

MAC-d

DCH

June 1, 2005

RNC NBAP

MAC-b MAC-c/sh

MAC-hs

MAC-d MAC-d

CONFIDENTIAL - DRAFT

Alexander Seifarth

2.1. MAC Entities The MAC protocol is split into several entities: • MAC-b: This entity is responsible for broadcasting the system information downlink. The system information is assembled by the RNC at sent via NBAP messages to the Node B. From here the MAC-b sends this information periodically in the cell. • MAC-c/sh: MAC-c/sh has to manage all common transport and shared logical channels. For DCCH/DTCH on common transport channels this includes identification of the UE with help of special UE identifiers contained in the MAC header. • MAC-d: For DCH as well as DCCH/DTCH the MAC-d entities are responsible. MAC-b and MAC-c/sh are created once per cell, whereas MAC-d is available inside the UE and the serving RNC for each UE. For high speed downlink packet access a new MAC entity is introduced: • MAC-hs: This entity manages the high speed downlink shared channel HS-DSCH. It is implemented in the Node B and gets its data input from MAC-d (serving RNC) directly or indirectly via MAC-c/sh (drift RNC). MAC-hs is especially responsible to perform the scheduling of downlink packet data.

14

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

2. Medium Access Control MAC 2.2. MAC – PDU, LogCH Identification, UE Identification on Layer 2

15

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

2.2. MAC-PDU, UE/LogCH Identification x = T(raffic) | C(ontrol)

DCH case: DxCH #0

DxCH #1

...

DxCH #K-1

Transport Block Set TBS TB #0 (MAC-PDU #0)

MAC-d MAC-d

TB #1 (MAC-PDU #1)

... TB #L-1 (MAC-PDU #L-1)

DCH #N

MAC - PDU MAC Header

PHY PHY

16

June 1, 2005

MAC-SDU = LogCH Data (RLC PDU)

DxCH – number (if K>1)

CONFIDENTIAL - DRAFT

Alexander Seifarth

2.2. MAC-PDU, UE/LogCH Identification Common TrCH (RACH, FACH, DSCH, CH) case: CCCH

BCCH| CTCH

DxCH DxCH #0 #K-1 from MAC-d

Transport Block Set TBS

...

TB #0 (MAC-PDU #0)

MAC-c/sh MAC-c/sh RACH | FACH | DSCH | CH

TB #1 (MAC-PDU #1)

... TB #L-1 (MAC-PDU #L-1)

MAC - PDU MAC Header

PHY PHY

17

June 1, 2005

x = T(raffic) | C(ontrol)

MAC-SDU = LogCH Data (RLC PDU)

LogCH Type DxCH – number (if K>1) UE-identifier (for DxCH only) CONFIDENTIAL - DRAFT

Alexander Seifarth

2.2. MAC-PDU, UE/LogCH Identification Common TrCH (HS-DSCH) case: DxCH #0

DxCH #1

...

DxCH #K-1

MAC-d MAC-d MAC-d - PDU MAC Header

MAC-d Flow

LogCH Type DxCH – number (if K>1)

MAC-hs MAC-hs HS-DSCH

MAC-SDU = LogCH Data (RLC PDU)

MAC-hs PDU MAC-hs Header

MAC-d PDU #0

...

MAC-d PDU #M-1

PHY PHY 18

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

2.2. MAC-PDU, UE/LogCH Identification Two major functions are provided by MAC protocol: • explicit UE identification on common transport channels, • multiplexing of logical channels onto/from transport channels. On a DCH the MAC frame provides in its header the DCCH or DTCH logical channel number if more than one logical channel is multiplexed onto the DCH. On common transport channels like RACH, FACH, DSCH, FACH or CH the MAC header indicates the type of logical channel that the transport block carries, the UE identity if the logical channel is DCCH or DTCH and if more than one logical channel of the same UE and of the same type is contained the logical channel number. For high speed downlink packet access a single UE can get one or more so called MAC-d flows on Iub interface. Each MACd flow corresponds to a so called re-ordering queue. The MAC-d PDU indicates to which logical channel (DTCH) the data belongs to. On the air interface the MAC-hs entity assembles several MAC-d PDU of the same and bundles them in a MAC-hs PDU. In the MAC-hs PDU the re-ordering queue identity and a sequence number (for retransmission purposes) is contained. Furthermore size indicators for the contained MAC-d PDU are implemented into the MAC-hs PDU.

19

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

2.2. MAC-PDU, UE/LogCH Identification • MAC-PDU (non HS-DSCH) MAC Header

TCTF

MAC SDU

UE-ID Type

C/T

UE-ID

RLC PDU (LogCH Data)

• MAC-d PDU (for HS-DSCH) MAC Header

MAC SDU

C/T

RLC PDU (LogCH Data)

• MAC PDU (HS-DSCH) MAC Header

MAC-hs Header

Version Queue Seq.No. Flag ID TSN

20

June 1, 2005

MAC-hs SDUs

MAC-d PDU #0

Size Index Id. #0

MAC-d PDU #1

No. MAC-d PDUs #0

Flag #0

CONFIDENTIAL - DRAFT

...

...

Size Index Id. #Y

MAC-d PDU #N-1

No. MAC-d PDUs #Y

Flag #Y

Alexander Seifarth

2.2. MAC-PDU, UE/LogCH Identification MAC PDU UE

RNC

MAC header UE identifier ----(no (noMAC MACUE UEID) ID)

• UE uses CCCH/PCCH/BCCH/CTCH or DCH/HS-DSCH

U-RNTI U-RNTI(32 (32bit) bit)

• UE uses DCCH/DTCH on RACH/FACH in a new cell

= S-RNC-ID + S-RNTI

21

C-RNTI C-RNTI(16 (16bit) bit)

• UE uses DCCH/DTCH on RACH/FACH/ CH (not after cell change)

DSCH-RNTI DSCH-RNTI(16 (16bit) bit)

• UE uses DCCH/DTCH on DSCH

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

2.2. MAC-PDU, UE/LogCH Identification • TCTF (Target Channel Type Field): Indicates logical channel type that is carried in the MAC header. • UE-ID/UE-ID type: Identifies a UE on common transport channels for DCCH or DTCH. The UE-ID can be u-rnti (umts – radio network temporary identifier), c-rnti (cell-rnti) or dsch-rnti. These identifiers must be allocated for a UE via RRC signalling before their use. • C/T (Channel of Type): If several logical channels of the same type are multiplexed onto the same transport channel, this field is used to distinguish and therefore demultiplex them. The following information elements are used in HS-DSCH frames only: • Version Flag: Currently always set to zero. May be used to allow MAC-hs extensions in future. • Queue ID: Indicates which re-ordering queue inside the UE the data belongs to. This enables independent buffer management for data of different applications. • TSN (Transmission Sequence Number): Sequence number for re-ordering purposes in case of disordering or retransmission. • SID (Size Index Identifier): Identifies the size of a number of consecutive MAC-d PDU (see next field). The SID is dynamically configured via higher layer signalling and is independent for each re-ordering queue. • Number of MAC-d PDU: Indicates the number of consecutive MAC-d PDU with the same SID. • Flag: If 0 then another SID fields follows, if 1 then the MAC-d PDU part starts after the flag.

22

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

2.2. MAC-PDU, UE/LogCH Identification • Example: MAC-PDU (Transport Block) Æ DCCH on DCH | |0011---| | |----0--|-----000 | |0010---|**b12*** | |**b124** | | |

23

June 1, 2005

2.2 FP: Transport Block |2.2.1 MAC: C/T Field |2.2.2 MAC: Target Channel Type |2.2.3 MAC: RLC Mode |2.2.4 RLC: Data/Control |2.2.5 RLC: PDU Type |2.2.6 RLC: Acknowledgement Super Field |2.2.6.1 RLC: SUFI Type |2.2.6.2 RLC: Last Sequence Number |2.2.7 RLC: Padding |2.2.7.1 RLC: Padding | | |

|Logical Channel 4 |DCCH (Dedicated Control Channel) |Acknowledge Mode |Control PDU |STATUS |Acknowledgement |2 |'000000000000000000000000000000000'B |'000000000000000000000000000000000'B |'000000000000000000000000000000000'B |'0000000000000000000000000'B

CONFIDENTIAL - DRAFT

| | | | | | | | | | | | | |

Alexander Seifarth

2.2. MAC-PDU, UE/LogCH Identification • Example: MAC-PDU (Transport Block) Æ DCCH on FACH | |01-----|--01---|**b16*** |----0010 | |1------|**b12*** |-----1-|------01 |0001010|-------1 |1111111|-------0 |**B10*** |***B4***

24

June 1, 2005

2 FP: Transport Block | 2.1 MAC: Target Channel Type Field | 2.2 MAC: UE-ID Type | 2.3 MAC: UE-ID | 2.4 MAC: C/T Field | 2.5 MAC: RLC Mode | 2.6 RLC: Data/Control | 2.7 RLC: Sequence Number | 2.8 RLC: Polling Bit | 2.9 RLC: Header extension type | 2.10 RLC: Length Indicator | 2.11 RLC: Extension Bit | 2.12 RLC: Length Indicator | 2.13 RLC: Extension Bit | 2.14 RLC: Last Data Segment | 2.15 RLC: Padding

CONFIDENTIAL - DRAFT

|DTCH/DCCH (Dedicated Traffic/Cont... |C-RNTI (Cell Radio Network Tempor... |0 |Logical Channel 3 |Acknowledge Mode |Acknowledged mode data PDU |1 |Request a status report |Octet contains LI and E bit |10 |The next field is LI and E bit |Rest is padding |The next field is data |94 02 08 00 18 00 11 88 10 00 |00 00 00 00

| | | | | | | | | | | | | | | |

Alexander Seifarth

2.2. MAC-PDU, UE/LogCH Identification The two examples show a trace made on Iub interface. They contain MAC PDU on non-high speed channels. The first example shows a transport block on DCH. There is no UE-ID because a DCH is already identifying a UE uniquely. Also there is no TCTF, because on a DCH there can be either DCCH or DTCH but not mixed. The second example shows a transport block on FACH. The TCTF indicates that DCCH is transported, thus a UE-ID is required to assign the dedicated data to a UE. In this case the c-rnti is used.

25

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

2. Medium Access Control MAC 2.3. RACH Access Control

26

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

2.3. RACH Access Control – Basic Procedure 1(3) Uu

Iub

UE

Node B PHY

MAC START

PHY

RNC

MAC

P = Persistence Value (SIB 7) M = Preamble Cycle Counter (UE counter)

M= 1 Wait 10 ms R=random (0≤R<1) IF (R ≤ P) TRUE

FALSE 1st Preamble Cycle

[PHY] .Request

PHY:PRACH

AccessPreamble

PHY:PRACH

AccessPreamble

... [PHY] NoAck.Indication

27

June 1, 2005

PHY:PRACH

Case: No acquisition indication 1) maximum no. of preambles 2) maximum power on PRACH

AccessPreamble

CONFIDENTIAL - DRAFT

Alexander Seifarth

2.3. RACH Access Control – Basic Procedure 2(3) Uu

Iub

UE

Node B PHY

MAC

PHY

RNC

MAC

Wait 10 ms M:=M+1 Wait 10 ms R=random (0≤R<1) IF (R ≤ P) FALSE

TRUE

2nd Preamble Cycle

[PHY] .Request

PHY:PRACH

AccessPreamble

PHY:PRACH

AccessPreamble

PHY:AICH [PHY]

28

Case: Negative acquisition indication

AI = -1

NAck.Indication

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

2.3. RACH Access Control – Basic Procedure 3(3) Uu

Iub

UE

Node B PHY

MAC

PHY

RNC

MAC

NBO1min = minimum value for backoff timer 1 (SIB) NBO1max = maximum value for backoff timer 1 (SIB)

Wait 10 ms NBO1=random {0 ≤ NBO1min ≤ NBO1 ≤ NBO1max} Wait TBO1 (= NBO1 x 10 ms) M:=M+1

Wait 10 ms

R=random (0≤R<1) IF (R ≤ P) FALSE

TRUE

3rd Preamble Cycle

[PHY] .Request

PHY:PRACH

[PHY]

Ack.Indication

PHY:AICH

[PHY]

Data.Request

PHY:PRACH

29

June 1, 2005

AccessPreamble AI = +1 RACH Data CONFIDENTIAL - DRAFT

Case: Positive acquisition indication

RACH-FP

RACH DATA Alexander Seifarth

2.3. RACH Access Control – Basic Procedure The MAC layer is in control of the PRACH preamble cycles. This means the MAC layer has to trigger PRACH preamble cycles and to handle negative outcomes of this procedure. Whenever a data transmission on RACH shall be done the MAC layer will first of all generate a random number R and compare it against a so called persistence value P. The persistence value P is coming from system information SIB 7, a block generated by the Node B itself. If the number R is bigger than P (R>P) then the MAC layer will wait 10 ms and generate a new random number. If R is less or equal to P then the physical layer can start a random number. By decreasing P the Node B can reduce the number of UE that will simultaneously access the RACH. When a preamble cycle ends without an indication from the Node B, then the MAC layer will wait another 10 ms and restart the preamble cycle (of course with random number and persistence check first) again. When a preamble cycle ends with a negative indication from the Node B, then again the MAC layer has to wait 10 ms. But afterwards the backoff 1 timer (T_BO1) is started with a time N_BO1 x 10 ms. N_BO1 is a random number that lies within the range N_BO1min and N_BO1max. These limits are BCCH parameters. When T_BO1 has its time out, then another preamble cycle including persistence check is done. Both negative cases (no indication, negative indication) will be aborted when the maximum number of preambles (BCCH parameter) is exceeded. In case the preamble cycle is positive, then the RACH data will be transmitted.

30

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

3. Radio Link Control (RLC) Protocol

31

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

3. Radio Link Control (RLC) Protocol 3.1. RLC Modes of Operation

32

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

3.1. RLC Modes of Operation RLC RLCModes Modes Transparent TransparentMode Mode TM TM • no sequence number check • no acknowledgements • no retransmission • segmentation/reassembly may be used or not used • no RLC overhead

MAC Header

RLC SDU (Data)

33

June 1, 2005

cipher unit

Unacknowledged UnacknowledgedMode Mode UM UM • sequence number check • no acknowledgements • no retransmission • segmentation/reassembly is done in RLC • sequence number and length indicators included in RLC frame

Acknowledged AcknowledgedMode Mode AM AM • sequence number check • acknowledgements • retransmission • segmentation/reassembly is done in RLC • sequence number and length indicators included in RLC frame + RLC control messages required

MAC Header

MAC Header

RLC Seq. No.

RLC Seq. No.

Length Indicators

Length Indicators

RLC SDU (Data)

cipher unit

CONFIDENTIAL - DRAFT

RLC SDU (Data or Ctrl)

cipher unit

Alexander Seifarth

3.1. RLC Modes of Operation The RLC protocol is used to enhance the reliability of a single radio bearer. Thus there is one instance of RLC protocol per radio bearer available. Each RLC instance can be set in one of three modes independent of each other: • Transparent Mode (TM): In transparent mode there is no additional reliability provided by the RLC protocol instance. Only segmentation and reassembly functions might be used. There is no RLC overhead included in this mode. Ciphering is done over the whole RLC SDU. • Unacknowledged Mode (UM): In unacknowledged mode there is at least a sequence number check provided by RLC. This is used to ensure correct reassembly. Thus there are sequence numbers and length indicators for reassembly control n the RLC frame. Ciphering is done over the whole RLC PDU except the sequence number. • Acknowledged Mode (AM): In acknowledged mode the RLC protocol instance provides acknowledgements and retransmission functionality. The RLC PDU contains now sequence number, length indicators for reassembly control and RLC status messages for retransmission control. Ciphering is done over the whole RLC PDU except the sequence number. Which mode is used is configured by the RNC during radio bearer setup procedure. Thus the UE is told via RRC signalling which RLC mode to use on a radio bearer. It is possible to combine TM and UM on the same radio bearer. This can be done by asg uplink and downlink different modes. It is not possible to combine AM with another mode, because for acknowledgements always uplink and downlink direction must be used simultaneously in AM.

34

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

3.1. RLC Modes of Operation LogCH Type

RLC Modes

BCCH

TM

PCCH

TM

CCCH-UL

TM

CCCH-DL DCCH

TM

UM

AM

DTCH

TM

UM

AM

CTCH

35

UM

June 1, 2005

UM

CONFIDENTIAL - DRAFT

Alexander Seifarth

3. Radio Link Control (RLC) Protocol 3.2. Segmentation/Reassembly Function

36

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

3.2. Segmentation/Reassembly Function Layer Layer33(RRC, (RRC,applic.) applic.) RLC SDU #0

RLC SDU #1

RLC RLC RLC header

MAC MAC

PHY PHY

37

June 1, 2005

#0.0

RLC header

RLC PDU #0

#0.1 #1.0

RLC header

RLC PDU #1

#1.1

padding

RLC PDU #2

Transport Block Set MAC header

RLC header

MAC header

RLC header

#0.1

#1.0

MAC header

RLC header

#1.1

padding

CONFIDENTIAL - DRAFT

#0.0

Alexander Seifarth

3.2. Segmentation/Reassembly Function Next to the enhanced reliability functions provided by RLC there is another task done by this protocol – segmentation and reassembly. The RLC protocol instances have to segment higher layer data so that a transport block of an appropriate size corresponding to the available transport formats can be formatted. The RLC protocol can perform segmentation together with concatenation (several RLC SDU or segments of an RLC SDU in one RLC PDU) and padding. The RLC protocol has been designed for maximum resource efficiency. In unacknowledged and acknowledged mode the RLC protocol includes length indicators in its PDU to indicate the end of an higher layer frame (RLC SDU). Sometimes the length indicators can also carry special control meaning. In transparent mode such length indicators are not used. Rather the RLC protocol reassembles everything that comes in the same transport blocks. This might not be exactly the inverse of the segmentation process in transparent mode. Therefore segmentation and reassembly is usually switched off when transparent mode is used. The higher layers have then to send frame of correct size to match the transport block sizes.

38

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

3. Radio Link Control (RLC) Protocol 3.3. RLC Transparent Mode Procedures

39

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

3.3. RLC Transparent Mode Procedures UE

RNC

RLC TMD PDU

. . .

RLC SDU segments

RLC TMD PDU RLC SDU segments

IF all segments of a SDU received Æ reassembly

RLC TMD PDU

. . .

RLC SDU segments

RLC TMD PDU RLC SDU segments IF all segments of a SDU received Æ reassembly

40

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

3.3. RLC Transparent Mode Procedures | |00-----| |**b166** | | | | |

2 FP: Transport Block |2.1 MAC: Target Channel Type Field |2.2 MAC: RLC Mode |2.3 RLC: Whole Data | | | | |

|CCCH (Common Control Channel) |Transparent Mode |'001000010000011101000000001000011'B |'010000000100110001000000001000000'B |'111110100110110000000000000000000'B |'000000000000000000000000000000000'B |'000000000000000000000000000000000'B |'0'B

| | | | | | | | |

RLC Transparent Mode DATA

segmented SDU data

41

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

3.3. RLC Transparent Mode Procedures In transparent mode there is only the data transfer procedure defined. It is implemented via the TMD PDU (Transparent Mode Data). The TMD PDU contains nothing else data from higher layers, no RLC control information is to be found.

42

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

3. Radio Link Control (RLC) Protocol 3.4. Unacknowledged Mode Procedures

43

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

3.4. Unacknowledged Mode Procedures UE

RNC

RLC UMD PDU Sequence No. = 2, Length Indicators, RLC SDU segments

RLC UMD PDU Sequence No. = 8, Length Indicators, RLC SDU segments

RLC UMD PDU Sequence No. = 43, Length Indicators, RLC SDU segments

RLC UMD PDU

. . . IF all segments of a SDU received Æ reassembly

. . .

Sequence No. = 47, Length Indicators, RLC SDU segments IF all segments of a SDU received Æ reassembly

44

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

3.4. Unacknowledged Mode Procedures | |01000000 | |0101010|-------1 |1111100|-------0 |**B18*** | |01000000 | |0101011|-------0 |**B19***

2 FP: Transport Block |2.1 MAC: Target Channel Type Field |2.2 MAC: RLC Mode |2.3 RLC: Sequence Number |2.4 RLC: Extension Bit |2.5 RLC: Length Indicator |2.6 RLC: Extension Bit |2.7 RLC: First Data Segment 3 FP: Transport Block |3.1 MAC: Target Channel Type Field |3.2 MAC: RLC Mode |3.3 RLC: Sequence Number |3.4 RLC: Extension Bit |3.5 RLC: Data Segment

| |01000000 | |0101100|-------0 |**B19*** | |01000000 | |0101101|-------0 |**B19***

2 FP: Transport Block |2.1 MAC: Target Channel Type Field |2.2 MAC: RLC Mode |2.3 RLC: Sequence Number |2.4 RLC: Extension Bit |2.5 RLC: Data Segment 3 FP: Transport Block |3.1 MAC: Target Channel Type Field |3.2 MAC: RLC Mode |3.3 RLC: Sequence Number |3.4 RLC: Extension Bit |3.5 RLC: Data Segment

45

June 1, 2005

|CCCH (Common Control Channel) |Unacknowledge Mode |42 |The next field is LI and E bit |Start with new SDU |The next field is data |30 f7 36 c0 00 04 24 c4 02 00 18... |CCCH (Common Control Channel) |Unacknowledge Mode |43 |The next field is data |49 d3 e2 84 f8 ea 30 00 14 61 67... |CCCH (Common Control Channel) |Unacknowledge Mode |44 |The next field is data |92 13 e5 a9 40 00 52 8a 13 a7 cd... |CCCH (Common Control Channel) |Unacknowledge Mode |45 |The next field is data |d3 e8 84 fa 6a 90 00 15 08 00 06...

CONFIDENTIAL - DRAFT

| | | | | | | | | | | | | | | | | | | | | | | | | |

Alexander Seifarth

3.4. Unacknowledged Mode Procedures | |01000000 | |0101110|-------0 |**B19*** | |01000000 | |0101111|-------1 |0001110|-------1 |1111111|-------0 |**B14*** |***B3***

46

June 1, 2005

2 FP: Transport Block |2.1 MAC: Target Channel Type Field |2.2 MAC: RLC Mode |2.3 RLC: Sequence Number |2.4 RLC: Extension Bit |2.5 RLC: Data Segment 3 FP: Transport Block |3.1 MAC: Target Channel Type Field |3.2 MAC: RLC Mode |3.3 RLC: Sequence Number |3.4 RLC: Extension Bit |3.5 RLC: Length Indicator |3.6 RLC: Extension Bit |3.7 RLC: Length Indicator |3.8 RLC: Extension Bit |3.9 RLC: Last Data Segment |3.10 RLC: Padding

|CCCH (Common Control Channel) |Unacknowledge Mode |46 |The next field is data |04 80 11 dc 32 00 01 04 13 f7 eb... |CCCH (Common Control Channel) |Unacknowledge Mode |47 |The next field is LI and E bit |14 |The next field is LI and E bit |Rest is padding |The next field is data |ba dd fc 80 64 53 ca 08 00 40 8c... |00 00 00

CONFIDENTIAL - DRAFT

| | | | | | | | | | | | | | | | |

Alexander Seifarth

3.4. Unacknowledged Mode Procedures • UMD PDU (7-bit Length Indicators) Sequence Number

E

LI0

E

• UMD PDU (15-bit Length Indicators) Sequence Number LI0 (high part)

...

LIN-1

E

LI0 (low part)

E

...

E=0

LIN-1 (high part) LIN-1

E=0

segmented RLC SDU segmented RLC SDU padding padding 47

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

3.4. Unacknowledged Mode Procedures In unacknowledged mode there is also only one frame defined, the UMD PDU (Unacknowledged Mode Data PDU). It is used to carry RLC SDU or segments of RLC SDU between UE and RNC. To enable faithful segmentation and reassembly, length indicators are used to point to the end of the last segment of a RLC SDU. This means a length indicator is to be found whenever a UMD PDU contains the last (or the only one) segment of a RLC SDU. In some situations special length indicators will be included that have control meaning (e.g. reset of reassembly etc.). Length indicators can be either 7 bit long or 15 bit long. It depends on the largest UMD PDU (transport block size – MAC header size) in the associated transport channel. If the maximum UMD PDU size is less or equal 125 bytes, then 7 bit length indicators shall be used, otherwise 15 bit length indicators have to be included in the UMD PDU. For detection of lost RLC PDU there is a 7 bit long sequence number included in every UMD PDU. If an UMD PDU is lost, then all RLC SDU with segments in this UMD PDU are discarded by the receiver.

48

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

3. Radio Link Control (RLC) Protocol 3.5. Acknowledged Mode Procedures

49

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

3.5. Acknowledged Mode Procedures UE

Reset

RNC

RLC RESET PDU Reset Sequence Number, Hyper Frame Number uplink (HFNI)

RLC RESET ACK PDU Reset Sequence Number, Hyper Frame Number downlink (HFNI)

RLC RESET PDU Reset Sequence Number, Hyper Frame Number downlink (HFNI)

RLC RESET ACK PDU Reset Sequence Number, Hyper Frame Number uplink (HFNI)

50

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

3.5. Acknowledged Mode Procedures UE

Data Transfer with Solitary STATUS PDU

RLC AMD PDU Sequence No. = 12, Poll Bit P, Length Indicators, RLC SDU segments

RLC AMD PDU

RNC

. . .

Sequence No. = 18, Poll Bit P, Length Indicators, RLC SDU segments

RLC STATUS PDU Acknowledgement super fields (SUFI): ACK, BITMAP, LIST, RLIST

RLC AMD PDU Sequence No. = 12, Poll Bit P, Length Indicators, RLC SDU segments

RLC AMD PDU

. . .

Sequence No. = 18, Poll Bit P, Length Indicators, RLC SDU segments

RLC STATUS PDU Acknowledgement super fields (SUFI): ACK, BITMAP, LIST, RLIST

51

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

3.5. Acknowledged Mode Procedures UE

Data Transfer with Piggybacked STATUS PDU

RNC

RLC AMD PDU

. . .

Sequence No. = 12, Poll Bit P, Length Indicators, RLC SDU segments

RLC AMD PDU Sequence No. = 18, Poll Bit P, Length Indicators, RLC SDU segments

RLC AMD PDU Sequence No. = 34, Poll Bit P, Length Indicators, RLC SDU Segments, Piggybacked STATUS PDU = {Acknowledgement super fields (SUFI): ACK, BITMAP, LIST, RLIST}

RLC AMD PDU

. . .

Sequence No. = 12, Poll Bit P, Length Indicators, RLC SDU segments

RLC AMD PDU Sequence No. = 28, Poll Bit P, Length Indicators, RLC SDU segments

RLC AMD PDU Sequence No. = 39, Poll Bit P, Length Indicators, RLC SDU Segments, Piggybacked STATUS PDU = {Acknowledgement super fields (SUFI): ACK, BITMAP, LIST, RLIST} 52

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

3.5. Acknowledged Mode Procedures UE

Move Receiving Window Procedure

RNC

RLC STATUS PDU Move Receiving Window (MRW) super field: SN1,...SNK

RLC STATUS PDU Move Receiving Window Ack (MRWACK) super field

RLC STATUS PDU Move Receiving Window (MRW) super field: SN1,...SNK

RLC STATUS PDU Move Receiving Window Ack (MRWACK) super field

53

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

3.5. Acknowledged Mode Procedures UE

Windowsize Configuration

RNC

RLC STATUS PDU Window (WINDOW) super field: window size

RLC STATUS PDU Window (WINDOW) super field: window size

54

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

3.5. Acknowledged Mode Procedures In acknowledged mode there some more procedures defined. In detail we have • Reset: The Reset procedure is used to recover after errors in acknowledged mode. A new HFNI (Hyper Frame Number Indicator) for ciphering can be allocated at Reset procedure. The RESET PDU and RESET ACK PDU are defined for this procedure. • Data Transfer with solitary STATUS PDU: For data transfer the AMD (Acknowledged Mode Data) PDU is defined. It carries a 12 bit long sequence number. A single AMD or a series of AMD PDU can be acknowledged by a stand-alone acknowledgement in form of a STATUS PDU. • Data Transfer with piggybacked STATUS PDU: Very often AMD PDU are exchanged in both directions. In this case it is possible to include STATUS PDU in AMD PDU for acknowledgements. This simply is more efficient with respect to bandwidth usage. • Move Receiving Window: In some situations an AMD PDU is transmitted and retransmitted correctly. This situation can be determined by thresholds (maximum number of retransmissions) or timers (maximum time for data transmission). Either an error is the result or both sides agree to skip the problematic AMD PDU. For skipping (discarding) the Move Receiving Window procedure is used. In a STATUS PDU the command to move the receiving window with the sequence numbers of the AMD PDU to be discarded are indicated. An acknowledgement completes the procedure. • Window Size: The RLC protocol uses acknowledgements that acknowledges several AMD PDU with one message. The maximum number of AMD PDU that can be sent without acknowledgement is indicated in the window size procedure. A STATUS PDU contains a window size field in which the limit is indicated.

55

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

3.5. Acknowledged Mode Procedures | |0010---| | |----1--|**b12*** |-1-----|--01---|***b7*** |---1---|***b7*** |---0---|**b72*** |**b40***

2.2 FP: Transport Block |2.2.1 MAC: C/T Field |2.2.2 MAC: Target Channel Type |2.2.3 MAC: RLC Mode |2.2.4 RLC: Data/Control |2.2.5 RLC: Sequence Number |2.2.6 RLC: Polling Bit |2.2.7 RLC: Header extension type |2.2.8 RLC: Length Indicator |2.2.9 RLC: Extension Bit |2.2.10 RLC: Length Indicator |2.2.11 RLC: Extension Bit |2.2.12 RLC: Last Data Segment |2.2.13 RLC: Padding

| |0010---| | |----0--|-----000 | |0010---|**b12*** | |**b124** | | |

2.2 FP: Transport Block |2.2.1 MAC: C/T Field |Logical Channel 3 |2.2.2 MAC: Target Channel Type |DCCH (Dedicated Control Channel) |2.2.3 MAC: RLC Mode |Acknowledge Mode |2.2.4 RLC: Data/Control |Control PDU |2.2.5 RLC: PDU Type |STATUS |2.2.6 RLC: Acknowledgement Super Field |2.2.6.1 RLC: SUFI Type |Acknowledgement |2.2.6.2 RLC: Last Sequence Number |3 |2.2.7 RLC: Padding |2.2.7.1 RLC: Padding |'000000000000000000000000000000000'B | |'000000000000000000000000000000000'B | |'000000000000000000000000000000000'B | |'0000000000000000000000000'B

56

June 1, 2005

|Logical Channel 3 |DCCH (Dedicated Control Channel) |Acknowledge Mode |Acknowledged mode data PDU |2 |Request a status report |Octet contains LI and E bit |9 |The next field is LI and E bit |Rest is padding |The next field is data |df d9 4c ed 0d 21 31 f1 10 |00 00 00 00 00

CONFIDENTIAL - DRAFT

| | | | | | | | | | | | | | | | | | | | | | | | | | | |

Alexander Seifarth

3.5. Acknowledged Mode Procedures • AMD PDU (7-bit Length Indicators) D/C (1)

Sequence Number (high part)

Seq.Number (low part)

P

LI0

HE

• AMD PDU (15-bit Length Indicators) D/C (1)

Seq.Number (low part)

E

P

HE

LI0 (high part)

...

LIN-1

Sequence Number (high part)

LI0 (low part)

E

...

E=0

LIN-1 (high part) LIN-1

segmented RLC SDU

E=0

segmented RLC SDU

Padding| piggybacked STATUS PDU

padding 57

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

3.5. Acknowledged Mode Procedures • RESET/RESET ACK PDU D/C (0)

PDU TYPE 001/010

RSN

• STATUS PDU D/C (0)

reserved

HFNI

SUFI #1

SUFI #1

...

HFNI HFNI

PDU TYPE 000

SUFI #N

padding

padding padding

58

June 1, 2005

Note:

CONFIDENTIAL - DRAFT

In case of a piggybacked STATUS PDU the D/C bit is reserved.

Alexander Seifarth

3.5. Acknowledged Mode Procedures Super Fields (SUFI) NO_MORE LIST

0 0 0 0

MRW

0 0 1 1 LENGTH

WINDOW

0 0 0 1 WSN high

SN1 high SN1 low

SN1 L1

...

WSN low

0 1 1 0 LENGTH SN1

0 0 1 0

LSN

SNLENGTH high

LSN low RLIST

0 1 0 1 LENGTH

0 1 0 0 LENGTH FSN high FSN low

BITMAP

BITMAP

Padding

...

FSN low

CW1

CWLENGTH

padding

59

June 1, 2005

CONFIDENTIAL - DRAFT

high

SN2 high

...

SNLENGTH SNLENGTH

BITMAP

FSN high

...

LLENGTH

low

SN2

low

SNLENGTH high ACK

high

low

high

NLENGTH

MRW_ACK

0 1 1 1

NLENGTH

SNACK high SNACK

low

Padding

Alexander Seifarth

3.5. Acknowledged Mode Procedures AMD PDU have a similar format like UMD PDU. The sequence of length indicators is used to control reassembly. Each length indicator points to the end of the last segment of a RLC SDU. Furthermore some special length indicator values are reserved (e.g. whether a STATUS PDU is carried within the AMD PDU or not, etc.). Again there are 7 bit long length indicators and 15 bit long length indicators. If the maximum AMD PDU size is less or equal to 126 octets then 7 bit long length indicators shall be used, otherwise 15 bit length indicators are chosen. The sequence number of AMD PDU is 12 bit long to enable bigger window size for acknowledgements. The poll bit P is used to request immediate acknowledgement for a AMD PDU. STATUS PDU contain one or more so called super fields SUFI. Each SUFI carries special acknowledged mode control meaning for acknowledgements, window size negotiation, moving receiving window. The following SUFI types are known: • No More: Indicates end of the STATUS PDU. • ACK: A simple acknowledgement. Indicates the next expected AMD PDU sequence number (LSN: last sequence number). • LIST: Indicates gaps of the reception of AMD PDU. Each gap is indicated by its start sequence number (SN: start number) and its length (L:length). Up to 15 gaps can be indicated in a single LIST super field. • BITMAP: Indicates positive or negative acknowledgement for a series of consecutive AMD PDU with a bitmap. The first bit of the bitmap stands for AMD PDU with sequence number FSN (FSN: first sequence number). The second bit of the bitmap is for FSN+1, and so on. When the bit is ‘0’ the associated AMD PDU is negatively acknowledged. • MRW/MRW_ACK: Used to move the receiving window. Inside the MRW field each AMD PDU to be discarded is indicated by its sequence number SN. • RLIST: A relative list used to indicate gaps in the reception. The method to specify the gap is different to LIST super field. In a RLIST special code words CW are used to calculate gap start and length. 60

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

Module 03 Radio Resource Control Signalling (RRC) Version 0.0.1 (21/03/2005) Author: Alexander Seifarth ([email protected])

1

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

1. System Information

2

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

1. System Information 1.1. System Information Blocks and Segmentation

3

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

1.1. System Information Blocks and Segments UE

RNC

[BCH:BCCH] RRC SystemInformation (SI) SFNPrime (INTEGER 0…4094 step 2), Segment Combination = CHOICE { Combination 1: no data | Combination 2: first segment | Combination 3: subsequence segment | Combination 4: last segment | Combination 5: last segment, first segment | Combination 6: last segment, complete list = {complete block#0, …, complete block#N} | Combination 7: last segment, complete list = {complete block#0, …, complete block#N}, first segment | Combination 8: complete list = {complete block#0, …, complete block#N} | Combination 9: complete list = {complete block#0, …, complete block#N}, first segment | Combination10: complete SIB of size 215…226 | Combination11: last segment of size 215…226 }

System Information Block (SIB):

4

June 1, 2005

first subsequent segment segment

CONFIDENTIAL - DRAFT

...

subsequent last segment segment

Alexander Seifarth

1.1. System Information Blocks and Segments Signalling on the BCCH is done by means of the RRC System Information. On the BCH that carries the BCCH there is only RLC transparent mode used. Thus the RRC protocol must provide its own sequence numbering and segmentation functionality. For segmentation of System Information Blocks (SIB) the RRC protocol defines the System Information (SI) message. In each SI message one or more segments of a SIB or several SIB can be contained. Several combinations allow to indicate first, last and subsequent segments, or to bundle several complete blocks in one SI message. Additionally to the SIB segments the SI message also indicates the cell time via the System Frame Number (0..4095). The SFN is translated into the SFN prime via th following rule. In each frame with even SFN (SFN mod 2 = 0) it holds SFN prime = SFN. In radio frames with odd SFN (SFN mod 2 = 1) we have SFN prime = SFN-1. In other words the SFN prime is increased with every second radio frame by 2.

5

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

1. System Information 1.2. Master and Scheduling Information Blocks

6

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

1.1. Master and Scheduling Information Blocks UE

Master Information Block (MIB)

RNC

[BCH:BCCH] RRC MasterInformationBlock (MIB) MIB value tag, ed PLMN types = GSM-MAP|ANSI-41|GSM-MAP+ANSI-41, PLMN identity = MCC + MNC, ANSI-41-CN information, references to other system information blocks = { SIB Type, value tag, scheduling } 80 ms

[BCH:BCCH] RRC MasterInformationBlock (MIB) MIB value tag, ed PLMN types = GSM-MAP|ANSI-41|GSM-MAP+ANSI-41, PLMN identity = MCC + MNC, ANSI-41-CN information, references to other system information blocks = { SIB Type, value tag, scheduling } 80 ms

[BCH:BCCH] RRC MasterInformationBlock (MIB) MIB value tag, ed PLMN types = GSM-MAP|ANSI-41|GSM-MAP+ANSI-41, PLMN identity = MCC + MNC, ANSI-41-CN information, references to other system information blocks = { SIB Type, value tag, scheduling }

7

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

1.1. Master and Scheduling Information Blocks UE

Scheduling Information Block (SchIB1/2)

RNC

[BCH:BCCH] RRC SchedulingInformationBlock1/2 references to other system information blocks = { SIB Type, value tag, scheduling } repetition rate given in MIB

[BCH:BCCH] RRC SchedulingInformationBlock1/2 references to other system information blocks = { SIB Type, value tag, scheduling } repetition rate given in MIB

[BCH:BCCH] RRC SchedulingInformationBlock1/2 references to other system information blocks = { SIB Type, value tag, scheduling }

8

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

1.1. Master and Scheduling Information Blocks Master Information Block MIB | | | | |-001---| | | | |***b4*** |--0110-|***b4*** | |---0000|***b4*** | | | |***b8*** | | | | |***b6*** | | |------01 ... 9

June 1, 2005

|masterInfoBlock (= masterInfoBlock) |sib_description |1 sib_choice |1.1 masterInfoBlock |1.1.1 mib-ValueTag |1.1.2 plmn-Type |1.1.2.1 gsm-MAP |1.1.2.1.1 plmn-Identity |1.1.2.1.1.1 mcc |1.1.2.1.1.1.1 digit |1.1.2.1.1.1.2 digit |1.1.2.1.1.1.3 digit |1.1.2.1.1.2 mnc |1.1.2.1.1.2.1 digit |1.1.2.1.1.2.2 digit |1.1.3 sibSb-ReferenceList |1.1.3.1 schedulingInformationSIBSb |1.1.3.1.1 sibSb-Type |1.1.3.1.1.1 sysInfoType1 |1.1.3.1.2 scheduling |1.1.3.1.2.1 scheduling |1.1.3.1.2.1.1 segCount |1.1.3.1.2.1.2 sib-Pos |1.1.3.1.2.1.2.1 rep128 |1.1.3.2 schedulingInformationSIBSb |1.1.3.2.1 sibSb-Type |1.1.3.2.1.1 sysInfoType2 CONFIDENTIAL - DRAFT

|2

|2 |6 |2 |0 |9

|44

|1 |6

|2

| | | | | | | | | | | | | | | | | | | | | | | | | | |

Alexander Seifarth

1.1. Master and Scheduling Information Blocks The individual system information blocks in the RRC protocol divide the information into groups. Two blocks have special meaning: the master information block and the scheduling information blocks. In the master information block MIB the PLMN type (GSM-MAP or ANSI-41) is indicated. For GSM-MAP the PLMN identity (MCC + MNC) is broadcasted also in the MIB. Then for every further system information block the MIB indicates scheduling information and a value tag (except SIB 7). The value tag indicates changes of the associated SIB by incremented value. The master information block always starts at radio frames with SFN mod 8 = 0.

10

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

1. System Information 1.3. System Information Blocks (SIB)

11

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

1.3. System Information Blocks (SIB) UE

General System Information Transmission

RNC

[BCH:BCCH] RRC SIBx SIBx data repetition rate given in MIB

[BCH:BCCH] RRC SIBx SIBx data repetition rate given in MIB

[BCH:BCCH] RRC SIBx SIBx data

12

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

1.3. System Information Blocks (SIB) UE

RNC

[BCH:BCCH] RRC SIB1 CN common GSM-MAP NAS info = LAC, CS domain system info = {periodic LAU timer T3212, ATT flag}, PS domain system info = {RAC, Network Mode of Operation NMO}, UE timers and constants in idle mode, UE timers and constants in connected mode

[BCH:BCCH] RRC SIB2 URA-ID list = URA#1,.., URA#<maxURA>

[BCH:BCCH] RRC SIB3 SIB4 indicator = true|false, cell identity, cell selection and re-selection info, cell access restriction

[BCH:BCCH] RRC SIB4 cell identity, cell selection and re-selection info, cell access restriction

13

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

1.3. System Information Blocks (SIB) UE

RNC

[BCH:BCCH] RRC SIB5 SIB6 indicator = true|false, PICH power offset, AICH power offset, secondary CCH system info, primary CCH info = Tx diversity indicator, PRACH system information list, CBS DRX level 1 information

[BCH:BCCH] RRC SIB6 PICH power offset, AICH power offset, secondary CCH system info, CBS DRX level 1 information, primary CCH info = Tx diversity indicator, PRACH system information list

[BCH:BCCH] RRC SIB7 UL interference, dynamic persistence level for PRACH in SIB5/6, expiration time factor

[BCH:BCCH] RRC SIB8 CH parameters (UE access parameters), CSICH power offset, CH set info (code and resource info)

[BCH:BCCH] RRC SIB9 CH persistence levels 14

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

1.3. System Information Blocks (SIB) UE

RNC

[BCH:BCCH] RRC SIB10 DRAC (dynamic resource allocation) system information

[BCH:BCCH] RRC SIB11 SIB12 indicator = true|false, FACH measurement occasion info = {measurement cycle length info, IF/IRAT measurement indicators} measurement control system information = {HCS indicator, cell selection/re-selection quantity, neighbour cell list SF/IF/IRAT, traffic volume measurements}

[BCH:BCCH] RRC SIB12 FACH measurement occasion info = {measurement cycle length info, IF/IRAT measurement indicators} measurement control system information = {HCS indicator, cell selection/re-selection quantity, neighbour cell list SF/IF/IRAT, traffic volume measurements}

[BCH:BCCH] RRC SIB13|SIB13.1|SIB13.2|SIB13.3|SIB13.4 ANSI-41 CN information

15

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

1.3. System Information Blocks (SIB) UE

RNC

[BCH:BCCH] RRC SIB14 3.84 Ms TDD mode system information

[BCH:BCCH] RRC SIB15|SIB15.1|SIB15.2|SIB15.3|SIB15.4|SIB15.5 system information for UE positioning

[BCH:BCCH] RRC SIB16 pre-defined RB/TrCH/PhCH configuration for inter-system handover to UTRAN

[BCH:BCCH] RRC SIB17 3.84 Ms TDD|1.28 Ms TDD mode system information

[BCH:BCCH] RRC SIB18 PLMN identities for neighbour cells for idle|connected mode UE

16

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

1.3. System Information Blocks (SIB) System Information Block SIB1 | | | | |**b16*** | | |0------| |**b16*** |-----01| |-------1 | |**b16*** |----01-| |----1010 |010----|---1100... |--001--| |***b4*** |-011---|----1010 |000----17

June 1, 2005

|sibType1 (= sibType1) |sib_description |1 sib_choice |1.1 sibType1 |1.1.1 cn-CommonGSM-MAP-NAS-SysInfo |1.1.2 cn-DomainSysInfoList |1.1.2.1 cN-DomainSysInfo |1.1.2.1.1 cn-DomainIdentity |1.1.2.1.2 cn-Type |1.1.2.1.2.1 gsm-MAP |1.1.2.1.3 cn-DRX-CycleLengthCoeff |1.1.2.2 cN-DomainSysInfo |1.1.2.2.1 cn-DomainIdentity |1.1.2.2.2 cn-Type |1.1.2.2.2.1 gsm-MAP |1.1.2.2.3 cn-DRX-CycleLengthCoeff |1.1.3 ue-ConnTimersAndConstants |1.1.3.1 t-301 |1.1.3.2 n-301 |1.1.3.3 t-302 |1.1.3.22 t-317 |1.1.4 ue-IdleTimersAndConstants |1.1.4.1 t-300 |1.1.4.2 n-300 |1.1.4.3 t-312 |1.1.4.4 n-312 CONFIDENTIAL - DRAFT

|00 18

|cs-domain |01 01 |7 |ps-domain |08 01 |7 |ms2000 |2 |ms4000 |s10 |ms1000 |3 |10 |s1

| | | | | | | | | | | | | | | | | | | | | | | | | |

Alexander Seifarth

2. RRC Connection Handling 2.1. RRC States

18

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

2.1. RRC States URA_PCH URA_PCH

CELL_PCH CELL_PCH

CELL_DCH CELL_DCH

CELL_FACH CELL_FACH

UTRA UTRAIDLE IDLE 19

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

2.1. RRC States To manage radio resources of a UE in UMTS a state system with respect to the RRC protocol is introduced. In general a UE has two main states – UTRA Idle and UTRA Connected. The difference between idle and connected is that in connected mode there is a serving RNC for the UE, whereas in idle mode there is no serving RNC. Note that a connected mode UE can have radio resources allocated or not. In idle mode a UE cannot have radio resources. To make a more detailed specification of a connected mode UE there are four sub-states defined for connected mode: • CELL_DCH: In this state the UE uses DCH for signalling and might use additional DCH or DSCH for applications. The UE is subject to soft and hard handover procedures in this state. • CELL_FACH: In this state the UE listens to FACH for RRC signalling and uses RACH on the uplink side. Also CH might be in use. Mobility is handled in this state via cell reselection, handover procedures like in CELL_DCH state are not used. • CELL_PCH: Here the UE has currently no radio resources allocated. Thus the UE waits for incoming paging messages on the PCH. The UE executes cell reselection, the RNC knows the current serving cell of the UE. • URA_PCH: This state is similar to CELL_PCH, only this time the RNC knows the current URA (UTRAN Registration Area) of the UE and not the cell. In CELL_FACH, CELL_PCH and URA_PCH the UE performs automatic cell reselection. Thus the RNC has to be updated whenever the area of interest (cell for CELL_FACH and CELL_PCH, URA for URA_PCH) changes.

20

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

2.1. RRC States – Cell Reselection in CELL_FACH UE

RNC

CELL_FACH automatic cell reselection

[RACH:CCCH] RLC/RRC

TMD Cell Update

U-RNTI, STARTCS, STARTPS, cell update cause = cell re-selection , measured results on RACH, …

[FACH:CCCH] RLC/RRC

UMD Cell Update Confirm

U-RNTI, new U-RNTI, new C-RNTI, new DSCH-RNTI, new H-RNTI, RRC state indicator = state_X, CN info, RB to reconfigure or delete, TrCH-UL to add/reconfigure/delete, TrCH-DL to add/reconfigure/ delete, uplink/downlink physical resources State_X

...

21

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

2.1. RRC States – Cell Reselection in CELL_PCH UE

RNC

CELL_PCH automatic cell reselection CELL_FACH

[RACH:CCCH] RLC/RRC

TMD Cell Update

U-RNTI, STARTCS, STARTPS, cell update cause = cell re-selection , measured results on RACH, …

[FACH:CCCH] RLC/RRC

UMD Cell Update Confirm

U-RNTI, new U-RNTI, new C-RNTI, new DSCH-RNTI, new H-RNTI, RRC state indicator = state_X, CN info, RB to reconfigure or delete, TrCH-UL to add/reconfigure/delete, TrCH-DL to add/reconfigure/ delete, uplink/downlink physical resources State_X

...

22

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

2.1. RRC States –URA Reselection in URA_PCH UE

RNC

URA_PCH automatic cell reselection (new cell is not part of old URA) false

URA_PCH

true CELL_FACH

[RACH:CCCH] RLC/RRC

TMD URA Update

U-RNTI, STARTCS, STARTPS, URA update cause = URA re-selection

[FACH:CCCH] RLC/RRC

UMD URA Update Confirm

U-RNTI, new U-RNTI, new C-RNTI, new DSCH-RNTI, new H-RNTI, RRC state indicator = state_X, CN info, RB to reconfigure or delete, TrCH-UL to add/reconfigure/delete, TrCH-DL to add/reconfigure/ delete, uplink/downlink physical resources State_X

...

23

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

2.1. Mobility Handling in CELL_FACH, CELL_PCH and URA_PCH When a UE reselects a cell in CELL_FACH state, it has to perform a CELL UPDATE procedure afterwards in the new cell. The CELL UPDATE message contains the current UE identifier (U-RNTI), so that the RNC can identify the UE. The message is sent on RACH via CCCH. Thus the associated response CELL UPDATE CONFIRM is returned to the UE on the FACH, also CCCH. In this message the UE is assigned a new state or again CELL_FACH. A similar procedure is done when a UE reselects a cell in CELL_PCH state. The only difference to the update procedure in CELL_FACH is, that after the cell reselection the UE enters automatically CELL_FACH state and then sends CELL UPDATE to the RNC. With the CELL UPDATE CONFIRM the UE is sent to a new state or back to CELL_PCH. In case the UE reselects a cell in URA_PCH state then another procedure is done. First of all the UE checks whether the new cell still belongs to the old URA. If this is true no update procedure will be performed. Otherwise the UE enters CELL_FACH state and sends URA UPDATE on RACH. The response CELL UPDATE CONFIRM on the FACH contains again a new state for the UE. If this state is set to URA_PCH, then the UE goes back to URA_PCH state and enters the master URA (URA #0 in SIB2) of the new cell.

24

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

2. RRC Connection Handling 2.2. RRC Connection Establishment

25

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

2.2. RRC Connection Estab. - CELL_FACH UE

RNC

UTRA IDLE Æ CELL_FACH

UTRA IDLE NAS Trigger

[RACH:CCCH] RLC/RRC

TMD RRC Connection Request

pre-defined configuration status indicator = true|false, Initial UE ID, establishment cause, measured result on RACH

• • • •

• • • • • •

TMSI + LAI PTMSI + RAI IMSI IMEI

[FACH:CCCH] RLC/RRC

orig./term. conversational call orig./term. streaming call orig./term. interactive call orig./term. background call originating subscribed traffic call emergency call

• • • • • • •

inter-RAT cell re-selection inter-RAT cell change order registration detach orig./term. high/low priority signalling call re-establishment terminating – cause unknown

UMD RRC Connection Setup

Initial UE ID, new U-RNTI, new C-RNTI, RRC state indicator = CELL_FACH, capability update requirement, signalling radio bearer to setup, TrCH to add/reconfigure

[RACH:DCCH] RLC/RRC

AMD RRC Connection Setup Complete

STARTCS, STARTPS, UE radio access capability, inter-RAT UE radio access capability

[RACH:DCCH] RLC/-

STATUS

Acknowledgement CELL_FACH 26

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

2.2. RRC Connection Est. – CELL_FACH RRC Connection Establishment Æ CELL_FACH (short trace) +--------+--------------------+------------+------------+------------+-------------------------------------+ |No |Long Time |2. Prot |2. MSG |3. Prot |3. MSG | +--------+--------------------+------------+------------+------------+-------------------------------------+ |68 |17:25:34,045,725 |RLC/MAC |FP DATA RACH| | | |69 |17:25:34,045,725 |RLC reasm. |TM DATA RACH|RRC_CCCH_UL |rrcConnectionRequest | |70 |17:25:34,130,812 |RLC/MAC |FP DATA FACH| | | |71 |17:25:34,140,807 |RLC/MAC |FP DATA FACH| | | |72 |17:25:34,150,775 |RLC/MAC |FP DATA FACH| | | |73 |17:25:34,150,775 |RLC reasm. |UM DATA FACH|RRC_CCCH_DL |rrcConnectionSetup | |74 |17:25:34,414,754 |RLC/MAC |FP DATA RACH| | | |75 |17:25:34,513,729 |RLC/MAC |FP DATA RACH| | | |76 |17:25:34,513,729 |RLC reasm. |AM DATA RACH|RRC_DCCH_UL |rrcConnectionSetupComplete |

27

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

2.2. RRC Connection Est. – CELL_FACH RRC Connection Request |TS 25.331 CCCH-UL (2002-09) (RRC_CCCH_UL) rrcConnectionRequest (= rrcConnectionRequest) | |uL-CCCH-Message | |1 message | |1.1 rrcConnectionRequest | |1.1.1 initialUE-Identity | |1.1.1.1 tmsi-and-LAI |***B4*** |1.1.1.1.1 tmsi |'00000111010000000010000110011110'B | |1.1.1.1.2 lai | |1.1.1.1.2.1 plmn-Identity | |1.1.1.1.2.1.1 mcc |0010---|1.1.1.1.2.1.1.1 digit |2 |----0110 |1.1.1.1.2.1.1.2 digit |6 |0010---|1.1.1.1.2.1.1.3 digit |2 | |1.1.1.1.2.1.2 mnc |***b4*** |1.1.1.1.2.1.2.1 digit |0 |-0010--|1.1.1.1.2.1.2.2 digit |2 |**b16*** |1.1.1.1.2.2 lac |'0000011111010010'B |***b5*** |1.1.2 establishmentCause |registration |--0----|1.1.3 protocolErrorIndicator |noError

28

June 1, 2005

CONFIDENTIAL - DRAFT

| | | | | | | | | | | | | | | | | | |

Alexander Seifarth

2.2. RRC Connection Est. – CELL_FACH RRC Connection Setup 1( ) |TS 25.331 CCCH-DL (2002-09) (RRC_CCCH_DL) rrcConnectionSetup (= rrcConnectionSetup) | |dL-CCCH-Message | |1 message | |1.1 rrcConnectionSetup | |1.1.1 r3 | |1.1.1.1 rrcConnectionSetup-r3 | |1.1.1.1.1 initialUE-Identity | |1.1.1.1.1.1 tmsi-and-LAI |**b32*** |1.1.1.1.1.1.1 tmsi |'00000111010000000010000110011110'B | |1.1.1.1.1.1.2 lai | |1.1.1.1.1.1.2.1 plmn-Identity | |1.1.1.1.1.1.2.1.1 mcc |---0010|1.1.1.1.1.1.2.1.1.1 digit |2 |***b4*** |1.1.1.1.1.1.2.1.1.2 digit |6 |---0010|1.1.1.1.1.1.2.1.1.3 digit |2 | |1.1.1.1.1.1.2.1.2 mnc |0000---|1.1.1.1.1.1.2.1.2.1 digit |0 |----0010 |1.1.1.1.1.1.2.1.2.2 digit |2 |***B2*** |1.1.1.1.1.1.2.2 lac |'0000011111010010'B |00-----|1.1.1.1.2 rrc-TransactionIdentifier |0 | |1.1.1.1.3 new-U-RNTI |**b12*** |1.1.1.1.3.1 srnc-Identity |'010111110000'B |**b20*** |1.1.1.1.3.2 s-RNTI |'00001011101011110111'B |**b16*** |1.1.1.1.4 new-c-RNTI |'0000000000000000'B |--01---|1.1.1.1.5 rrc-StateIndicator |cell-FACH |----000|1.1.1.1.6 utran-DRX-CycleLengthCoeff |3 29

June 1, 2005

CONFIDENTIAL - DRAFT

| | | | | | | | | | | | | | | | | | | | | | | | | |

Alexander Seifarth

2.2. RRC Connection Est. – CELL_FACH RRC Connection Setup 2( ) | |1------|-0-----| | | | |00000--... | ... | | |***b4*** ... | | |***b4***

30

June 1, 2005

|1.1.1.1.7 capabilityUpdateRequirement |1.1.1.1.7.1 ue-RadioCapabilityFDDUpdateRequ.. |1.1.1.1.7.2 ue-RadioCapabilityTDDUpdateRequ.. |1.1.1.1.7.3 systemSpecificCapUpdateReqList |1.1.1.1.7.3.1 systemSpecificCapUpdateReq |1.1.1.1.8 srb-InformationSetupList |1.1.1.1.8.1 sRB-InformationSetup |1.1.1.1.8.1.1 rb-Identity

| | | | | | | |

|1 |0 |gsm

|1

|1.1.1.1.8.1.3.2 rB-MappingOption |1.1.1.1.8.1.3.2.1.1.1 ul-TransportChannelType |1.1.1.1.8.1.3.2.1.1.1.1 rach |1.1.1.1.8.1.3.2.1.1.2 logicalChannelIdentity |1.1.1.1.8.1.3.2.2.1.1 dl-TransportChannelType |1.1.1.1.8.1.3.2.2.1.1.1 fach |1.1.1.1.8.1.3.2.2.1.2 logicalChannelIdentity

CONFIDENTIAL - DRAFT

|

|0 |2

| | |

|0 |2

| | |

Alexander Seifarth

2.2. RRC Connection Est. – CELL_FACH RRC Connection Setup 3( ) ... | | | |***b4*** ... | | |----0010 | |-00010-| |***b5*** ... | |--00011| |00001--...

31

June 1, 2005

|1.1.1.1.8.2.3.2 rB-MappingOption |1.1.1.1.8.2.3.2.1.1.1 ul-TransportChannelType |1.1.1.1.8.2.3.2.1.1.1.1 rach |1.1.1.1.8.2.3.2.1.1.2 logicalChannelIdentity |1.1.1.1.8.2.3.2.2.1.1 dl-TransportChannelType |1.1.1.1.8.2.3.2.2.1.1.1 fach |1.1.1.1.8.2.3.2.2.1.2 logicalChannelIdentity |1.1.1.1.8.3 sRB-InformationSetup |1.1.1.1.8.3.1 rb-Identity |1.1.1.1.8.3.2 rlc-InfoChoice |1.1.1.1.8.3.2.1 same-as-RB |1.1.1.1.8.4 sRB-InformationSetup |1.1.1.1.8.4.1 rb-Identity |1.1.1.1.8.4.2 rlc-InfoChoice |1.1.1.1.8.4.2.1 same-as-RB

CONFIDENTIAL - DRAFT

|0 |3

|0 |3 |3

| | | | | | | | | |

|2

|4 |2

| | | |

Alexander Seifarth

2.2. RRC Connection Est. – CELL_FACH RRC Connection Setup Complete |TS 25.331 DCCH-UL (2002-09) (RRC_DCCH_UL) rrcConnectionSetupComplete (= rrcConnectionSetupComplete) | |uL-DCCH-Message | |1 message | |1.1 rrcConnectionSetupComplete |-00----|1.1.1 rrc-TransactionIdentifier |0 | |1.1.2 startList | |1.1.2.1 sTARTSingle |-----0-|1.1.2.1.1 cn-DomainIdentity |cs-domain |**b20*** |1.1.2.1.2 start-Value |'00000000000000000100'B | |1.1.2.2 sTARTSingle |--1----|1.1.2.2.1 cn-DomainIdentity |ps-domain |**b20*** |1.1.2.2.2 start-Value |'00000000000000001010'B | |1.1.3 ue-RadioAccessCapability | |1.1.3.1 accessStratumReleaseIndicator |r99 | |1.1.3.2 pd-Capability |0------|1.1.3.2.1 losslessSRNS-Relocation |0 | |1.1.3.2.2 ForRfc2507 | |1.1.3.2.2.1 noted |0 | |1.1.3.3 rlc-Capability |--010--|1.1.3.3.1 totalRLC-AM-BufferSize |kb50 |-----0-|1.1.3.3.2 maximumRLC-WindowSize |mws2047 |***b3*** |1.1.3.3.3 maximumAM-EntityNumber |am6 | |1.1.3.4 transportChannelCapability | |1.1.3.4.1 dl-TransChCapability |-0101--|1.1.3.4.1.1 maxNoBitsReceived |b6400 |***b4*** |1.1.3.4.1.2 maxConvCodeBitsReceived |b640 ... 32

June 1, 2005

CONFIDENTIAL - DRAFT

| | | | | | | | | | | | | | | | | | | | | | | | | |

Alexander Seifarth

2.2. RRC Connection Est. – CELL_FACH When a UE wants to leave idle mode and enter connected mode it has to start the RRC Connection Establishment procedure. During this procedure the UE is sent either to CELL_FACH state or CELL_DCH state. The decision which of the two states is chosen is done by the RNC. The first flow shows the transition to state CELL_FACH. The procedure is done in the following way:

33

1.

The UE sends RRC CONNECTION REQUEST on the RACH (CCCH) to the RNC. Inside the message the UE indicates its identity in the parameter ‚Initial UE ID‘. Furthermore a cause for the request is indicated via the ‚Establishment Cause‘ information element.

2.

When the RNC has made the decision about the state (here CELL_FACH) then it sends RRC CONNECTION SETUP to the UE on FACH (CCCH). As reference to the RRC CONNECTION REQUEST the ‚Initial UE ID‘ is repeated in this message. The ‚RRC State Indicator‘ tells the UE to enter CELL_FACH state. To use DCCH/DTCH on RACH and FACH the UE needs a c-rnti, which is also indicated in this message. As sign for the connected mode the UE also gets a u-rnti.

3.

To confirm the connected mode the UE returns now RRC CONNECTION SETUP COMPLETE. This message is sent on RACH because the UE is in state CELL_FACH now. The logical channel is DCCH, thus the MAC header for the transport blocks of this message contains the c-rnti for identification of the UE.

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

2.2. RRC Connection Establishment UE

UTRA IDLE Æ CELL_DCH

RNC

UTRA IDLE NAS Trigger

[RACH:CCCH] RLC/RRC

TMD RRC Connection Request

pre-defined configuration status indicator = true|false, Initial UE ID, establishment cause, measured result on RACH

[FACH:CCCH] RLC/RRC

UMD RRC Connection Setup

Initial UE ID, new U-RNTI, RRC state indicator = CELL_DCH, capability update requirement, signalling radio bearer to setup, TrCH to add/reconfigure (signalling DCH), uplink and downlink physical resources DPCH and DPDCH/DPCCH synchronisation

[DCH:DCCH] RLC/RRC

AMD RRC Connection Setup Complete

STARTCS, STARTPS, UE radio access capability, inter-RAT UE radio access capability

[DCH:DCCH] RLC/-

STATUS

Acknowledgement CELL_DCH

34

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

2.2. RRC Connection Establishment When the UE enters CELL_DCH instead of CELL_FACH the basic flow of messages is the same. The first difference is to be seen in the RRC CONNECTION SETUP message. The ‚RRC State Indicator‘ is now set to CELL_DCH and thus there is no c-rnti to be allocated for the UE. Rather the physical layer will identify the UE in CELL_DCH state, the MAC layer will not perform layer 2 identification. Of course the RRC CONNECTION SETUP COMPLETE message will now be sent on DCH (DCCH) instead of RACH.

35

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

2. RRC Connection Handling 2.3. RRC Connection Release

36

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

2.3. RRC Connection Release UE

CELL_DCH Æ UTRA IDLE

RNC

CELL_DCH

[DCH:DCCH] RLC/RRC

UMD RRC Connection Release

N308, release cause • • • • • • •

[DCH:DCCH] RLC/RRC N308

... [DCH:DCCH] RLC/RRC

normal event unspecified pre-emptive release congestion re-establishment reject inactivity directed signalling connection re-establishment

UMD RRC Connection Release Complete UMD RRC Connection Release Complete

UTRA IDLE

37

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

2.3. RRC Connection Release UE

CELL_FACH with DCCH Æ UTRA IDLE

RNC

CELL_FACH

[FACH:DCCH] RLC/RRC

UMD RRC Connection Release

release cause

[RACH:DCCH] RLC/RRC

AMD RRC Connection Release Complete

[FACH:DCCH] RLC/-

STATUS

Acknowledgement UTRA IDLE

UE

CELL_FACH without DCCH Æ UTRA IDLE

RNC

CELL_FACH

[FACH:CCCH] RLC/RRC

UMD RRC Connection Release

U-RNTI, release cause UTRA IDLE 38

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

2.3. RRC Connection Release UE

URA_PCH/CELL_PCH Æ UTRA IDLE

RNC

CELL_PCH or URA_PCH

[PCH:PCCH] RLC/RRC

TMD Paging Type 1

U-RNTI, release indicator = release UTRA IDLE

39

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

2.3. RRC Connection Release To release a UE from connected mode and send it to idle the RRC Connection Release procedure is defined. Depending on the configuration of the UE the procedure has a different appearance. When the UE is in state CELL_DCH then the RNC has to send the RRC CONNECTION RELEASE procedure to the UE via the signalling DCH. Inside the message a cause value indicates the reason for the release. A counter value N308 tells the UE how often to repeat the RRC CONNECTION RELEASE COMPLETE message on the uplink DCH to confirm the procedure. After this the UE is in idle mode and the RNC can release all dedicated resources allocated to this UE. When the UE is in state CELL_FACH with allocated DCCH then the RNC also sends RRC CONNECTION RELEASE to release the UE. This time there is no counter value N308. Thus the UE sends exactly one RRC CONNECTION RELEASE COMPLETE message on RACH, then it enters idle mode. If the UE is in state CELL_FACH but has currently no DCCH (happens after paging in state CELL_PCH or URA_PCH or after cell reselection) then only the RRC CONNECTION RELEASE message is sent. No completion message follows afterwards, instead the UE enters directly idle mode (see paging procedures for more information about this). In UMTS Release 5 a new procedure is introduced. When a UE is in state CELL_PCH or URA_PCH it is possible to page it with a PAGING TYPE 1 message that contains a release indicator. If this indicator is set to release, then the UE enters directly idle mode without any further action (NOTE: There is a small inconsistency with the RRC state diagram.)

40

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

3. Iu Signalling Connection Handling

41

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

3. Iu Signalling Connection Handling 3.1. Iu Signalling Connections - General

42

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

3.1. Iu Signalling Connections - General

UE

n CS o i t c onne C g nallin g i S Iu

RRC Connection

Serving RNC

S-RNTI S-RNTI

43

June 1, 2005

radio radiomgt. mgt. data data

Iu S i

gnall ing

Conn ectio n

PS

MSC Server CS-MGW

SGSN

CS-Iu CS-IuSign.Connection Sign.Connection PS-Iu PS-IuSign.Connection Sign.Connection

CONFIDENTIAL - DRAFT

Alexander Seifarth

3.1. Iu Signalling Connections - General CS Mobility Management States CMM_Detached CMM_Detached

CMM_Idle CMM_Idle

CMM_Connected CMM_Connected

PS Mobility Management States PMM_Detached PMM_Detached

PMM_Idle PMM_Idle

44

June 1, 2005

PMM_Connected PMM_Connected

CONFIDENTIAL - DRAFT

Alexander Seifarth

3.1. Iu Signalling Connections - General The RRC Connection provides signalling facilities between UE and RNC for radio management tasks. Of course the main reason to start signalling is to get services from the core network. In other words the UE also needs signalling transfer capabilities to and from the core network. In UMTS (like in GSM) the UE has no direct link to the CN, thus the UTRAN has to manage signalling connection towards the CN for the UE. These connections are called Iu signalling connections. They are implemented by the SC protocol on Iu interface. The RANAP protocol is running in Iu signalling connections. A connected mode UE can have none, one or two Iu signalling connections. At most one Iu signalling connection can be set up for a UE to the MSC server and at most one Iu signalling connection can be established to SGSN for a UE. An idle mode UE cannot have any Iu signalling connection. The reason for the last fact is that it is the serving RNC that has to manage Iu signalling connections. Within the core network entities MSC server and SGSN a mobility management state (PMM = Packet Mobility Management, CMM = Circuit Mobility Management) is maintained for each UE. PMM and CMM states are relatively equal defined. Both consist of three possible states: • P/CMM_DETACHED: A UE in state P/CMM_DETACHED is currently not ed for services in the core network entity. • P/CMM_CONNECTED: In this state the UE is ed for services in the CN entity and an Iu signalling connection for this UE exists in the moment. Thus the CN can immediately start signalling towards UE by sending a message within the appropriate Iu signalling connection. This means that CN triggered paging is not required in this state. • P/CMM_IDLE: In this state the UE is ed for services in the CN entity, but there is currently no Iu signalling connection for this UE. Thus before a signalling procedure can be started with the UE the CN must page the UE. This paging is for the UE the trigger to establish an Iu signalling connection (P/CMM_CONNECTED) state.

45

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

3. Iu Signalling Connection Handling 3.2. Establishment and Signalling Transfer

46

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

3.2. Establishment and Signalling Transfer Iu Signalling Connection Establishment UE

RNC

SGSN MSC Server

CELL_DCH CELL_FACH

[DCCH] RLC/RRC

AMD Initial Direct Transfer

CN domain ID, intra domain NAS node selector, establishment cause, NAS message, START, measured results on RACH

[DCCH] RLC/--

RANAP Initial UE Message CN domain ID, NAS message, LAI, RAC, …

STATUS

acknowledgement

47

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

3.2. Establishment and Signalling Transfer Uplink NAS Signalling Transfer UE

SGSN

RNC

MSC Server

CELL_DCH CELL_FACH

[DCCH] RLC/RRC

AMD Uplink Direct Transfer

RANAP Direct Transfer

CN domain ID, NAS message, measured results on RACH

CN domain ID, NAS message, LAI, RAC

Downlink NAS Signalling Transfer UE

SGSN

RNC

MSC Server

CELL_DCH CELL_FACH

[DCCH] RLC/RRC

AMD Downlink Direct Transfer

CN domain ID, NAS message, SAPI

CN domain ID, NAS message

48

June 1, 2005

RANAP Direct Transfer

CONFIDENTIAL - DRAFT

Alexander Seifarth

3.2. Establishment and Signalling Transfer The establishment of Iu signalling connection is triggered by the UE via the INITIAL DIRECT TRANSFER message. This message indicates which core network domain the connection shall be set up to and a message for this core network is contained. On the Iu interface the serving RNC issues the RANAP message INITIAL UE MESSAGE is sent to the indicated core network domain. Once the Iu signalling connection exists, the UE and the core network can freely exchange NAS signalling with each other. The serving RNC acts as relay point for the NAS signalling messages. In case of uplink NAS signalling the UE packs the NAS message in a UPLINK DIRECT TRANSFER message, the RNC relays the message via RANAP DIRECT TRANSFER to the core network. For downlink NAS messages the CN has to encapsulate the NAS PDU in a RANAP DIRECT TRANSFER message. The RNC translates this into the DOWNLINK DIRECT TRANSFER message. The ‚SAPI‘ parameter in the DIRECT TRANSFER message gives the priority of the NAS message.

49

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

3. Iu Signalling Connection Handling 3.3. Iu Signalling Connection Release

50

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

3.3. Iu Signalling Connection Release UE

SGSN

RNC

MSC Server RANAP Iu Release Command release cause

RANAP IF (last Iu signalling connection to be released)

Iu Release Complete

…

RRC Connection Release Procedure ELSE IF (no radio bearer for releasing CN allocated)

[DCCH] RLC/RRC

AMD Signalling Connection Release

CN domain ID ELSE IF (radio bearer for releasing CN allocated)

[DCCH] RLC/RRC

AMD Radio Bearer Release

…, signalling connection release indication = CN domain ID, …

[DCCH] RLC/RRC

AMD Radio Bearer Release Complete

… 51

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

3.3. Iu Signalling Connection Release UE

[DCCH] RLC/RRC

SGSN

RNC

MSC Server

AMD Signalling Conn. Release Indic.

CN domain ID

RANAP

Iu Release Request

RANAP Iu Release Command release cause = UTRAN generated reason

RANAP

Iu Release Complete

Handling like in normal Iu signalling connection release case

52

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

3.3. Iu Signalling Connection Release The release of Iu signalling connections is managed by the core network via the RANAP Iu Release procedure. The core network releases an Iu signalling connection via RANAP message IU RELEASE COMMAND. The serving RNC will respond with IU RELEASE COMPLETE. Depending on the current UE configuration there are three basic procedures possible on the radio interface: • RRC Connection Release procedure is triggered (UE is sent to IDLE state), • UE is informed about Iu signalling connection release via SIGNALLING CONNECTION RELEASE procedure, • radio bearers are released via RADIO BEARER RELEASE procedure. Of course none of these procedures is triggered when the UE is no longer in this RNC area. In some situations the RNC can request the release of the Iu signalling connection from the CN via the RANAP procedure IU RELEASE REQUEST. The reason for this message might be an RNC internal trigger or the UE has requested the release by SIGNALLING CONNECTION RELEASE MESSAGE.

53

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

4. Security Mode Control

54

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

4. Security Mode Control 4.1. Ciphering and Integrity Protection

55

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

4.1. Ciphering and Integrity Protection Integrity Protection

Transmitter

Receiver

COUNT-I

COUNT-I

DIRECTION IK

DIRECTION

FRESH

IK

f9 f9(UIA) (UIA)

FRESH

f9 f9(UIA) (UIA) XMAC-I

RRC Message

MAC-I

RRC Message

MAC-I

COUNT-I

RRC(28 HFN RRC HFN bit) 56

June 1, 2005

(28 bit)

CONFIDENTIAL - DRAFT

RRC SN

(4)

Alexander Seifarth

4.1. Ciphering and Integrity Protection DCCH RRC messages can be protected against change of information or message injection by an integrity protection mechanism. Therefore an algorithm f9 (UIA: UMTS Integrity Algorithm) must be available in UE and RNC. For each DCCH RRC message this algorithm calculates a message authentication code (MAC-I: Message Authentication Code – Integrity). This MAC-I is included in the message itself. At the receiver side the MAC-I is calculated again and cross-checked with the transmitted one. The algorithm UIA (f9) takes several additional values as input: • IK (Integrity Key): A UE specific key that is derived from authentication (automatic key agreement). • DIRECTION: Discriminates between uplink and downlink direction. • FRESH: An offset value that is allocated for uplink by UE and for downlink by RNC. The UL/DL-FRESH values are exchanged at set up of signalling radio bearers (RRC CONNECTION SETUP and RRC CONNECTION SETUP COMPLETE). • COUNT-I: This value is increased with every message that is transmitted. For initialisation of COUNT-I a START value is negotiated at radio bearer set up time.

57

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

4.1. Ciphering and Integrity Protection Ciphering

Transmitter

Receiver

COUNT-C

COUNT-C

DIRECTION BEARER

CK

DIRECTION

LENGTH

BEARER

f8 f8(UEA) (UEA)

XOR

COUNT-C for RLC TM on DCH COUNT-C for RLC UM COUNT-C for RLC AM 58

June 1, 2005

f8 f8(UIA) (UIA)

CK

Keystream Block

Keystream Block Plaintext Block

LENGTH

Ciphertext Block

XOR

MAC-d RRC HFN HFN (24 bit)(28 bit) RRC HFN RLC HFN (25 bit) RLC HFN CONFIDENTIAL - DRAFT

(20 bit)

CFN

(28 bit)RLC

SN

RLC SN

Plaintext Block

(4 bit) (7 bit)

(12 bit)

Alexander Seifarth

4.1. Ciphering and Integrity Protection Like in GSM also UMTS allows an encryption with a classical stream cipher algorithm. The algorithm for production of the stream cipher sequence is called UEA (UMTS Encryption Algorithm) or f8. This algorithm uses several values as input: • CK (Cipher Key): A UE specific key that is coming from authentication (automatic key agreement). • BEARER: The radio bearer identity. • DIRECTION: Distinguishes between uplink and downlink direction. • LENGTH: Length of the cipher sequence to be produced. • COUNT-C: Strictly increasing value for each radio frame (RLC transparent mode) or RLC frame (RLC unacknowledged or acknowledged mode). COUNT-C is initialised with the START values that are exchanged at radio bearer set up time.

59

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

4. Security Mode Control 4.2. Security Mode Activation

60

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

4.2. Security Mode Activation UE

SGSN

RNC

MSC Server RANAP Security Mode Command

[DCCH] RLC/RRC

AMD Security Mode Command.

integrity protection info, ciphering info, …

CN domain ID, security capability, inter-RAT security capability, ciphering mode info = {start/modify, selected UEA-no., RB activation time, DPCH activation time} integrity mode info = {start/modify, selected UIA-no., DL-FRESH, …}

[DCCH] RLC/--

STATUS

acknowledgement

[DCCH] RLC/RRC

AMD Security Mode Complete

integrity check info = {MAC-I, RRC SN for RB2}, uplink integrity protection activation info ={RRC SN for RB1-RB4}, RB ciphering activation time info = {RB-ID, RLC SN}

[DCCH] RLC/--

STATUS

acknowledgement

RANAP

Security Mode Complete

…

61

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

4.2. Security Mode Activation |TS 25.331 DCCH-DL (2002-09) (RRC_DCCH_DL) securityModeCommand (= securityModeCommand) | |1 integrityCheckInfo |**b32*** |1.1 messageAuthenticationCode |'10110100100001111011101010000100'B |-0001--|1.2 rrc-MessageSequenceNumber |1 | |2 message | |2.1 securityModeCommand | |2.1.1 r3 | |2.1.1.1 securityModeCommand-r3 |***b2*** |2.1.1.1.1 rrc-TransactionIdentifier |0 | |2.1.1.1.2 securityCapability |**b16*** |2.1.1.1.2.1 cipheringAlgorithmCap |uea1 | | |uea0 |**b16*** |2.1.1.1.2.2 integrityProtectionAlgorithmCap |uia1 | |2.1.1.1.3 integrityProtectionModeInfo | |2.1.1.1.3.1 integrityProtectionModeCommand | |2.1.1.1.3.1.1 startIntegrityProtection |**b32*** |2.1.1.1.3.1.1.1 integrityProtInitNumber |'01000000110110110000111010010001'B | |2.1.1.1.3.2 integrityProtectionAlgorithm |uia1 |---0---|2.1.1.1.4 cn-DomainIdentity |cs-domain

| | | | | | | | | | | | | | | | | | |

|TS 25.331 DCCH-UL (2002-09) (RRC_DCCH_UL) securityModeComplete (= securityModeComplete) | |1 integrityCheckInfo |**b32*** |1.1 messageAuthenticationCode |'11101010011001010000010001001011'B |-0001--|1.2 rrc-MessageSequenceNumber |1 | |2 message | |2.1 securityModeComplete |-----00|2.1.1 rrc-TransactionIdentifier |0 | |2.1.2 ul-IntegProtActivationInfo | |2.1.2.1 rrc-MessageSequenceNumberList |0000---|2.1.2.1.1 rRC-MessageSequenceNumber |0 |----0000 |2.1.2.1.2 rRC-MessageSequenceNumber |0 |0000---|2.1.2.1.3 rRC-MessageSequenceNumber |0 |----0000 |2.1.2.1.4 rRC-MessageSequenceNumber |0 |0000---|2.1.2.1.5 rRC-MessageSequenceNumber |0

| | | | | | | | | | | | | |

62

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

4.2. Security Mode Activation Security functions are activated by the core network via the RANAP procedure Security Mode Control. This procedure is triggered with the message SECURITY MODE COMMAND. In this message the CN provides IK and CK to the RNC as well as a list of permitted UIA and UEA. The serving RNC has to select an UIA and an UEA that is ed by UE and RNC and is permitted by the CN. Then the security functions are activated by the RRC message SECURITY MODE COMMAND. In it one can find the selected algorithms. When the UE is able to activate the requested algorithms it returns SECURITY MODE COMPLETE. The same message but from RANAP protocol is also returned to the core network.

63

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

5. Paging

64

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

5. Paging 5.1. UTRAN Paging Types

65

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

5.1. UTRAN Paging Types UTRAN Paging Paging Originator CN CNoriginated originated UTRAN UTRANoriginated originated

Request for Iu signalling connection

Request for UE to enter CELL_FACH and perform Cell Update procedure

Paging Type

66

June 1, 2005

Paging PagingType Type11

PCCH on PCH; may be used to page up to 8 UE

Paging PagingType Type22

DCCH on DCH or FACH

CONFIDENTIAL - DRAFT

Alexander Seifarth

5.1. UTRAN Paging Types Paging in UMTS can come from two different types of source – the paging originator: • CN originated paging: The CN triggers paging whenever a downlink signalling message shall be sent, but currently there is no Iu signalling connection for this UE at the CN domain of interest available (P/CMM_DETACHED state). Thus CN originated paging is a request for an Iu signalling connection. • UTRAN originated paging: The serving RNC has to trigger a paging whenever the UE is in state CELL_PCH or URA_PCH and a downlink message shall be sent to the UE. This paging shall force the UE to enter state CELL_FACH and perform a Cell Update procedure. A problem for UTRAN is the question on which channel to send the paging message. The RRC protocol provides two options: • Paging Type 1: The RRC message PAGING TYPE 1 is always sent on the PCH. Thus it can be used for UE in state Idle, CELL_PCH or URA_PCH. The PAGING TYPE 1 message can be used to page up to 8 UE in one single message. Furthermore the PAGING TYPE 1 message can also be used to indicate change of BCCH (BCCH Modification) or to release a UE from state CELL_PCH or URA_PCH to idle. • Paging Type 2: The message PAGING TYPE 2 is sent on either DCH or FACH. Thus it is the choice for UE in state CELL_DCH or CELL_FACH. Note that PAGING TYPE 2 is a dedicated control channel (DCCH) message, thus only one UE can be paged with such a message.

67

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

5. Paging 5.2. CN originated paging

68

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

5.2. CN originated paging UE

SGSN

RNC

MSC Server RANAP Paging

[P/DCCH] RLC/RRC

TMD/AMD Paging Type 1|2

Type 1: Paging Record ={…, CN UE ID or U-RNTI + CN domain ID} Type 2: CN domain ID

CN domain ID, UE identifier, paging area, paging cause

IF (UE idle)

[CCCH] RLC/RRC

TMD RRC Connection Request

[CCCH] RLC/RRC

UMD RRC Connection Setup

[DCCH] RLC/RRC

AMD RRC Connection Setup Complete

... [DCCH] RLC/RRC

AMD Initial Direct Transfer

CN domain ID, …, NAS-Message = RR:Paging Response|GMM:Service Request

[DCCH] RLC/--

69

June 1, 2005

RANAP

Initial UE Message

NAS-Message

STATUS

CONFIDENTIAL - DRAFT

Alexander Seifarth

5.2. CN originated paging CN Triggered Paging |TS 25.331 PCCH (2002-03) (RRC_PCCH) pagingType1 (= pagingType1) | |pCCH-Message | |1 message | |1.1 pagingType1 | |1.1.1 pagingRecordList | |1.1.1.1 pagingRecord | |1.1.1.1.1 cn-Identity |110----|1.1.1.1.1.1 pagingCause |---0---|1.1.1.1.1.2 cn-DomainIdentity | |1.1.1.1.1.3 cn-pagedUE-Identity |**b32*** |1.1.1.1.1.3.1 tmsi-GSM-MAP

|'10110110000000000000000000100001'B

| | | | | | | | | | |

|3 |237

| | | | | | |

|terminatingCauseUnknown |cs-domain

BCCH Modification Indication |TS 25.331 PCCH (2002-03) (RRC_PCCH) pagingType1 (= pagingType1) | |pCCH-Message | |1 message | |1.1 pagingType1 | |1.1.1 bcch-ModificationInfo |-----010 |1.1.1.1 mib-ValueTag |***b9*** |1.1.1.2 bcch-ModificationTime

70

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

5.2. CN originated paging CN originated paging is obviously triggered by the core network. MSC server or SGSN send the RANAP message PAGING to the RNC (or to several RNC). Inside the message the UE is identified (IMSI, TMSI/PTMSI) and the paging area (LAI/RAI) is indicated. The RNC determines the state of the UE by checking the IMSI. Then either PAGING TYPE 1 or PAGING TYPE 2 is sent on an appropriate downlink signalling transport channel. If the UE is in idle state, then it first of all performs a RRC connection setup procedure. If the UE is already in connected mode, it can skip this part. Then the UE has to trigger the Iu signalling connection to the requesting core network using the INITIAL DIRECT TRANSFER message.

71

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

5. Paging 5.3. UTRAN originated paging

72

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

5.3. UTRAN originated paging UE

RNC

CELL_PCH URA_PCH

[PCCH] RLC/RRC

TMD Paging Type 1

Type 1: Paging Record ={…, U-RNTI, RRC connection release indication=No Release|Release Cause} IF (RRC connection release indication = NoRelease)

[CCCH] RLC/RRC

TMD Cell Update

U-RNTI, cell update cause = paging response, …

[CCCH] RLC/RRC

UMD Cell Update Confirm

U-RNTI, new U-RNTI, new C-RNTI, RRC state indicator, RB info, TrCH info, PhCH info, …

[CCCH] RLC/RRC

OR

UMD RRC Connection Release

U-RNTI, new U-RNTI, new C-RNTI, RRC state indicator, RB info, TrCH info, PhCH info, … IF (RRC connection release indication = ReleaseCause

UE enters UTRA IDLE mode 73

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

5.3. UTRAN originated paging In case the paging is originated by the serving RNC there is no ‚CN Domain‘ information element inside the PAGING TYPE 1 message. The UE will enter state CELL_FACH on reception of an UTRAN originated paging. Then the UE will send a CELL UPDATE message on RACH (CCCH). Inside it will identify itself with the u-rnti and the parameter ‚cell update cause‘ is set to „paging response“. The RNC has now two options. Either it sends the CELL UPDATE CONFIRM message on FACH to the UE and indicates with this a new state and radio configuration to the UE. Or the RNC sends RRC CONNECTION RELEASE, so that the UE immediately enters idle mode. Since UMTS Release 5 the PAGING TYPE 1 message can contain a release indicator. If this is set to „release“, the UE will not perform the CELL UPDATE, instead it silently enters idle mode without any further interaction with the RNC.

74

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

6. Radio Resource Management

75

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

6. Radio Resource Management 6.1. Radio Bearer and Radio Access Bearer Setup

76

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

6.1 RB and RAB Setup UE

RNC

SGSN MSC Server RANAP RAB Assignment Request RAB to setup or Modify, RAB to release

[DCCH] RLC/RRC

UMD/AMD Radio Bearer Setup

…, RRC state indicator, signalling radio bearer, radio access bearers Æ radio bearers ( data) transport channel to add/delete, physical channel configuration

[DCCH] RLC/RRC

AMD Radio Bearer Setup Complete

…

RANAP RAB Assignment Response successful RAB setup, failed RAB setup

77

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

6.1 RB and RAB Setup +--------+----------------+--------------------+------------+------------+------------+--------------------------+ |No |Long Time |From |2. Prot |2. MSG |3. Prot |3. MSG | +--------+----------------+--------------------+------------+------------+------------+--------------------------+ |97 |12:01:15,470,365|NB #2 (DCH #1 DL) |RLC/MAC |FP DATA DCH | | | |98 |12:01:15,510,323|NB #2 (DCH #1 DL) |RLC/MAC |FP DATA DCH | | | |99 |12:01:15,550,476|NB #2 (DCH #1 DL) |RLC/MAC |FP DATA DCH | | | |100 |12:01:15,590,240|NB #2 (DCH #1 DL) |RLC/MAC |FP DATA DCH | | | |101 |12:01:15,630,489|NB #2 (DCH #1 DL) |RLC/MAC |FP DATA DCH | | | |102 |12:01:15,670,155|NB #2 (DCH #1 DL) |RLC/MAC |FP DATA DCH | | | |103 |12:01:15,710,405|NB #2 (DCH #1 DL) |RLC/MAC |FP DATA DCH | | | |104 |12:01:15,750,364|NB #2 (DCH #1 DL) |RLC/MAC |FP DATA DCH | | | |105 |12:01:15,750,364|NB #2 (DCH #1 DL) |RLC reasm. |AM DATA DCH |RRC_DCCH_DL |radioBearerSetup | |106 |12:01:15,967,569|NB #2 (DCH #1 UL) |RLC/MAC |FP DATA DCH | | | |109 |12:01:17,327,602|NB #2 (DCH #1 UL) |RLC/MAC |FP DATA DCH | | | |110 |12:01:17,327,602|NB #2 (DCH #1 UL) |RLC reasm. |AM DATA DCH |RRC_DCCH_UL |radioBearerSetupComplete |

78

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

6.1 RB and RAB Setup The radio bearers for RRC signalling are usually set up via RRC CONNECTION SETUP. Radio bearers for data (especially DTCH/CTCH, but not exclusively) cannot be created with this operation. The general radio bearer establishment is provided by the RADIO BEARER SETUP procedure implemented by RRC protocol. This operation can be used to create any kind of radio bearer. When radio bearers for applications like calls or PDP context shall be created, then the RADIO BEARER SETUP is part of the radio access bearer establishment triggered by core network. This is done via the RANAP message RAB ASSIGNMENT REQUEST. This message is used for set up, modification and release of radio access bearers. When a RAB is created or modified, then the serving RNC calculates how many radio bearers with which settings are required and creates these radio bearers with the RADIO BEARER SETUP procedure. In it the UE also gets an indication about the radio access bearers created. When the new radio bearers are allocated by the UE it will respond with RADIO BEARER SETUP COMPLETE, this will in the end effect also trigger the RAB ASSIGNMENT RESPONSE message of RANAP back to the core network. This RANAP message contains parameters that indicate success or failure of the procedure.

79

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

6. Radio Resource Management 6.2. Radio Bearer and Radio Access Bearer Release

80

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

6.2. RB and RAB Release UE

[DCCH] RLC/RRC

RNC

UMD/AMD Radio Bearer Release

…, RRC state indicator, radio access bearers to reconfigure list transport channel to add/delete, physical channel configuration

[DCCH] RLC/RRC

AMD Radio Bearer Release Complete

…

[DCCH] RLC/RRC

SGSN MSC Server RANAP RAB Assignment Request RAB to setup or Modify, RAB to release

RANAP RAB Assignment Response successful RAB setup, failed RAB setup

UMD/AMD Radio Bearer Release

RANAP Iu Release Command

…, RRC state indicator, signalling connection release indication = ps|cs radio access bearers to reconfigure list transport channel to add/delete, physical channel configuration

[DCCH] RLC/RRC

AMD Radio Bearer Release Complete

…

81

June 1, 2005

RANAP Iu Release Complete RAB released

CONFIDENTIAL - DRAFT

Alexander Seifarth

6.2. RB and RAB Release To release radio bearers the RADIO BEARER RELEASE procedure is provided by RRC protocol. It can be used to release individual radio bearers or complete radio access bearers with all associated radio bearers and the procedure can also trigger RRC state changes. The RNC can in principle release a radio bearer at any time without involution of the core network. If this is really done, depends on the traffic class of the radio access bearer. Because of delay problems when a radio bearer is to be reestablished, such a Radio Access Bearer independent Radio Bearer management is not done for conversational or streaming traffic classes. Only background and interactive traffic class radio access bearers allow such a radio bearer management without involution of CN. Of course radio bearers have to be released whenever the radio access bearer of the service is terminated. A radio access bearer can be released in two ways. Either the CN uses again the RANAP procedure RAB ASSIGNMENT REQUEST with a RAB release indication or the CN releases the Iu signalling connection with IU RELEASE COMMAND. In the latter case all RAB for this UE of to the releasing core network have to be terminated. The RNC can upon one of these two procedures release the associated radio bearers with RADIO BEARER RELEASE, the UE has to respond with RADIO BEARER RELEASE COMPLETE. Of course there is another final way to release all radio bearers. When the UE is sent to idle state by the RRC message RRC CONNECTION RELEASE automatically all radio bearers will be terminated. This option is used after the IU RELEASE COMMAND when no Iu signalling connection is left at the end of the procedure.

82

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

6. Radio Resource Management 6.3. Reconfiguration Operations

83

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

6.3. Reconfiguration Operations UE

[DCCH] RLC/RRC

RNC UMD/AMD

Radio Bearer Reconfiguration

New U-RNTI, new C-RNTI, new DSCH-RNTI, new H-RNTI, RRC state indicator, RB to reconfigure, transport channels to add/delete/modify, physical channel configuration

[DCCH] RLC/RRC

AMD Radio Bearer Reconfiguration Complete

…

[DCCH] RLC/RRC

UMD/AMD

Transport Channel Reconfiguration

New U-RNTI, new C-RNTI, new DSCH-RNTI, new H-RNTI, RRC state indicator, transport channels to add/delete/modify, physical channel configuration

[DCCH] RLC/RRC

AMD Transport Channel Reconfiguration Complete

…

[DCCH] RLC/RRC

UMD/AMD

Physical Channel Reconfiguration

New U-RNTI, new C-RNTI, new DSCH-RNTI, new H-RNTI, RRC state indicator, physical channel configuration

[DCCH] RLC/RRC

AMD Physical Channel Reconfiguration Complete

… 84

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

6.3. Reconfiguration Operations Three main operations are provided in the RRC protocol to modify the current radio configuration of a UE. There are • RADIO BEARER RECONFIGURATION: This allows to modify physical channels (frequency, channelization codes, scrambling codes), transport channels (transport format sets, transport format combination sets, type of transport channels) and radio bearers itself. • TRANSPORT CHANNEL RECONFIGURATION: This procedure allows to modify transport channels and physical channels. Radio bearers are not affected by this procedure. • PHYSICAL CHANNEL RECONFIGURATION: This allows to modify physical channels only. Depending on what shall be modified the serving RNC has to select one of these procedures. If only transport format combinations shall be allowed or blocked there is another procedure – the TRANSPORT FORMAT COMBINATION CONTROL operation. This is not really a reconfiguration, because the channels and radio bearers are not modified by it. The reconfiguration operations can be used to implement hard handover procedures on the same frequency or to other frequency (inter-frequency handover). They cannot be used for soft handover (see active set update procedure) or to perform inter-system (inter-RAT) handover (see HANDOVER FROM UTRAN COMMAND).

85

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

6. Radio Resource Management 6.4. Inter-System Change Operations

86

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

6.4. Inter-System Change Operations Handover From UTRAN UE [DCCH] RLC/RRC

Core Network

other RAT (e.g. GSM BSS)

Source RNC

AMD/UMD UE Capability Enquiry

capability update requirement

[DCCH] RLC/RRC

AMD

UE Capability Information

UE radio access capability, other RAT capabilities

[DCCH] RLC/RRC

AMD/UMD UE Capability Information Confirm

…

other system’s handover message [DCCH] RLC/RRC

AMD

Handover From UTRAN Command

RAB to handover list, other RAT system information Æ other system’s handover message, …

[DCCH] RLC/--

STATUS

SUFI: Acknowledgement

other system’s handover completion 87

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

6.4. Inter-System Change Operations To change from UMTS WCDMA FDD mode to another radio access technology (RAT) there are inter-system (inter-RAT) procedures defined. Before a UE can go to another RAT it might be necessary to retrieve the UE’s capabilities with respect to this RAT. If these RAT capabilities are not available yet at the serving RNC a capability enquiry procedure has to be performed. During this procedure the RNC request the updated capabilities with UE CAPABILITY ENQUIRY from the UE, which will respond with a UE CAPABILITY INFO message back to the RNC. This message contains the UE capabilities as requested before by the UE CAPABILITY ENQUIRY message. The RNC confirms reception of the parameters by sending UE CAPABILITY INFO CONFIRM. When the handover to the other RAT shall be started typically a so called S-RNS Relocation procedure (not shown here) is started. During this relocation the new RAT radio network controller (whatever this might be) sends an appropriate handover command over the core network to the serving RNC. This will take it and pack it into a HANDOVER FROM UTRAN COMMAND, which is sent to the UE. The UE now changes the radio access system and completes the handover procedure in the new radio subsystem.

88

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

6.4. Inter-System Change Operations Handover To UTRAN UE RRC

Core Network

other RAT (e.g. GSM BSS)

Target RNC

Signalling transfer “Inter-RAT Handover Info”

Inter-RAT Handover Info

UE radio access capabilities, pre-defined configuration status information

RRC Handover To UTRAN Command

Signalling transfer “Handover To UTRAN Command”

new U-RNTI, ciphering algorithm, signalling radio bearer to setup, RAB and radio bearer to setup, transport channels to add, physical channel configuration

[DCCH] RLC/RRC

AMD

Handover To UTRAN Complete

…

[DCCH] RLC/--

STATUS

SUFI: Acknowledgement

89

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

6.4. Inter-System Change Operations A handover to UTRAN is of course triggered by the other RAT that is used by the UE in the moment. Before a handover to UTRAN is started usually the new RNC (target RNC) has to get the UE capabilities with respect to WCDMA FDD mode. Therefore the other RAT requests the UE WCDMA capabilities and forwards it over the CN to the target RNC. This is embedded in a S-RNC relocation procedure, but this time the RNC is the destination of the procedure, not the source. When the target RNC has the UE capabilities it will prepare all resources for it and then create a HANDOVER TO UTRAN COMMAND. This command is sent over the core network to the radio controller of the other RAT. From here the message finds its way to the UE. How this is done depends on the other RAT. Now the UE switches to the WCDMA FDD cell and completes the handover with the message HANDOVER TO UTRAN COMPLETE.

90

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

6.4. Inter-System Change Operations Network Ordered Cell Change To Other RAT UE [DCCH] RLC/RRC

Source RNC

other RAT (e.g. GSM BSS)

AMD

Cell Change Order From UTRAN

target cell description, …

[DCCH] RLC/--

STATUS

SUFI: Acknowledgement

update procedures corresponding to new system

91

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

6.4. Inter-System Change Operations There is a second possibility to change from UTRAN to another radio access technology. This option is especially designed for UMTS (CELL_FACH) to GSM (Packet Transfer Mode). Here we use a network ordered cell change to switch away from UMTS to another RAT. The RNC give the CELL CHANGE ORDER FROM UTRAN command to the UE. In this message the new cell of the other RAT is indicated. The UE now performs a forced cell reselection to the new cell. All cell reselection criteria for automatic cell reselection are ignored at the UE. The remaining part of the procedure consists possibly of an update procedure in the new RAT. This is out of scope of UTRAN.

92

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

6. Radio Resource Management 6.5. Active Set Management (Soft Handover)

93

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

6.5. Active Set Management (Soft Handover) UE

[DCCH] RLC/RRC

RNC

AMD/UMD

Active Set Update

Radio link addition info Æ {primary ICH info = primary DL scrambling code, cell identity, downlink DPCH info, …} Radio link removal info Æ {primary ICH info = primary DL scrambling code}

[DCCH] RLC/RRC

94

June 1, 2005

AMD Active Set Update Complete

CONFIDENTIAL - DRAFT

Alexander Seifarth

6.5. Active Set Management (Soft Handover) Soft handover consists of operations to add, delete and replace cells from the so called active set. The procedure that provides this functionality is the ACTIVE SET UPDATE. In an ACTIVE SET UPDATE message the serving RNC indicates the cells that are to be added to the active set and the cells that must be removed from it. Whenever the UE receives such an ACTIVE SET UPDATE it immediately performs the requested operations and returns the ACTIVE SET UPDATE COMPLETE message.

95

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

7. UE Measurements

96

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

7. Measurements 7.1. Measurement Types and Reporting

97

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

7.1. Measurement Types and Reporting 1) Intra Frequency Measurements 2) Inter Frequency Measurements 3) Inter RAT Measurements

WCDMA physical layer TrCH #0

...

5) Quality Measurements 6) UE Internal Measurements

TrCH #N

7) Positioning Measurements 4) Traffic Volume Measurements

RLC/MAC ... RRC

RRC Periodical Measurements

98

June 1, 2005

RRC

Measurement Control | SIB 3/4+11/12

RNC

Measurement Report

- Filtering - Reporting criteria evaluation

CONFIDENTIAL - DRAFT

Alexander Seifarth

7.1. Measurement Types and Reporting UE Measurements in UTRAN are divided into seven categories as shown on the slide. Every measurement in a UE has to be created before it starts. Therefore a MEASUREMENT CONTROL message is provided. Additionally SIB 3/4 and SIB 11/12 can create measurements. Reporting of measurements can be done either periodically or by event trigger. Which reporting mode for a created measurement is to chosen is indicated in the associated MEASUREMENT CONTROL message. When a trigger for a report is fulfilled then the UE sends MEASUREMENT REPORT uplink to the RNC which contains the measured results (filtered by UE) and the indication of the event that triggered the report (only for even triggered reporting).

99

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

7. Measurements 7.2. Measurement Control and Report Procedure

100

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

7.2. Measurement Control and Report Procedure UE

[DCCH] RLC/RRC

RNC

AMD

Measurement Control

measurement identity, measurement control command = setup, release, modify, measurement type, measurement reporting mode Æ {RLC mode = AMD|UMD, trigger = periodical|event}, …

[DCCH] RLC/--

STATUS

[DCCH] RLC/RRC

AMD/UMD

Measurement Report

measurement identity, measurement control command = setup, release, modify, measurement type, measurement reporting mode Æ {RLC mode = AMD|UMD, trigger = periodical|event}, …

[DCCH] RLC/--

101

June 1, 2005

STATUS

CONFIDENTIAL - DRAFT

Alexander Seifarth

7.2. Measurement Control and Report Procedure Measurement Control 1(4) |TS 25.331 DCCH-DL (2002-03) (RRC_DCCH_DL) measurementControl (= measurementControl) |dL-DCCH-Message | |1 integrityCheckInfo |**b32*** |1.1 messageAuthenticationCode |'11101001001100000100101100101000'B |-0011--|1.2 rrc-MessageSequenceNumber |3 | |2 message | |2.1 measurementControl | |2.1.1 r3 | |2.1.1.1 measurementControl-r3 |***b2*** |2.1.1.1.1 rrc-TransactionIdentifier |2 |-1000--|2.1.1.1.2 measurementIdentity |9 | |2.1.1.1.3 measurementCommand | |2.1.1.1.3.1 setup | |2.1.1.1.3.1.1 intraFrequencyMeasurement | |2.1.1.1.3.1.1.1 intraFreqCellInfoList | |2.1.1.1.3.1.1.1.1 removedIntraFreqCellList | |2.1.1.1.3.1.1.1.1.1 removeAllIntraFreqCells |0 | |2.1.1.1.3.1.1.1.2 newIntraFreqCellList | |2.1.1.1.3.1.1.1.2.1 newIntraFreqCell |--00000|2.1.1.1.3.1.1.1.2.1.1 intraFreqCellID |0 | |2.1.1.1.3.1.1.1.2.1.2 cellInfo |-000000|2.1.1.1.3.1.1.1.2.1.2.1 cellIndividualOffset |-20 | |2.1.1.1.3.1.1.1.2.1.2.2 modeSpecificInfo | |2.1.1.1.3.1.1.1.2.1.2.2.1 fdd | |2.1.1.1.3.1.1.1.2.1.2.2.1.1 primaryICH-Info |***b9*** |2.1.1.1.3.1.1.1.2.1.2.2.1.1.1 primaryScramb.. |3 |***b6*** |2.1.1.1.3.1.1.1.2.1.2.2.1.2 primaryICH-TX.. |30 |-1-----|2.1.1.1.3.1.1.1.2.1.2.2.1.3 readSFN-Indicator |1 |--0----|2.1.1.1.3.1.1.1.2.1.2.2.1.4 tx-DiversityInd.. |0

102

June 1, 2005

CONFIDENTIAL - DRAFT

| | | | | | | | | | | | | | | | | | | | | | | | | | | | |

Alexander Seifarth

7.2. Measurement Control and Report Procedure Measurement Control 2(4) | |***b5*** | |***b6*** | | | |***b9*** |***b6*** |---1---|----0--| |***b5*** | |***b6*** | | | |***b9*** |***b6*** |-----1-|------0| | | | |-00----| | |----00-|------0|-------1 103

June 1, 2005

|2.1.1.1.3.1.1.1.2.2 newIntraFreqCell |2.1.1.1.3.1.1.1.2.2.1 intraFreqCellID |2.1.1.1.3.1.1.1.2.2.2 cellInfo |2.1.1.1.3.1.1.1.2.2.2.1 cellIndividualOffset |2.1.1.1.3.1.1.1.2.2.2.2 modeSpecificInfo |2.1.1.1.3.1.1.1.2.2.2.2.1 fdd |2.1.1.1.3.1.1.1.2.2.2.2.1.1 primaryICH-Info |2.1.1.1.3.1.1.1.2.2.2.2.1.1.1 primaryScramb.. |2.1.1.1.3.1.1.1.2.2.2.2.1.2 primaryICH-TX.. |2.1.1.1.3.1.1.1.2.2.2.2.1.3 readSFN-Indicator |2.1.1.1.3.1.1.1.2.2.2.2.1.4 tx-DiversityInd.. |2.1.1.1.3.1.1.1.2.3 newIntraFreqCell |2.1.1.1.3.1.1.1.2.3.1 intraFreqCellID |2.1.1.1.3.1.1.1.2.3.2 cellInfo |2.1.1.1.3.1.1.1.2.3.2.1 cellIndividualOffset |2.1.1.1.3.1.1.1.2.3.2.2 modeSpecificInfo |2.1.1.1.3.1.1.1.2.3.2.2.1 fdd |2.1.1.1.3.1.1.1.2.3.2.2.1.1 primaryICH-Info |2.1.1.1.3.1.1.1.2.3.2.2.1.1.1 primaryScramb.. |2.1.1.1.3.1.1.1.2.3.2.2.1.2 primaryICH-TX.. |2.1.1.1.3.1.1.1.2.3.2.2.1.3 readSFN-Indicator |2.1.1.1.3.1.1.1.2.3.2.2.1.4 tx-DiversityInd.. |2.1.1.1.3.1.1.2 intraFreqMeasQuantity |2.1.1.1.3.1.1.2.1 filterCoefficient |2.1.1.1.3.1.1.2.2 modeSpecificInfo |2.1.1.1.3.1.1.2.2.1 fdd |2.1.1.1.3.1.1.2.2.1.1 intraFreqMeasQuantity.. |2.1.1.1.3.1.1.3 intraFreqReportingQuantity |2.1.1.1.3.1.1.3.1 activeSetReportingQuantities |2.1.1.1.3.1.1.3.1.1 sfn-SFN-OTD-Type |2.1.1.1.3.1.1.3.1.2 cellIdentity-reportingI.. |2.1.1.1.3.1.1.3.1.3 cellSynchronisationInfo.. CONFIDENTIAL - DRAFT

|1 |-20

|5 |30 |1 |0 |2 |-18

|1 |30 |1 |0 |fc0

|ich-Ec-N0

|noReport |0 |1

| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |

Alexander Seifarth

7.2. Measurement Control and Report Procedure Measurement Control 3(4) | | |-1-----|--0----|---0---| |----00-|------0|-------1 | | |-1-----|--0----|---0---| | | | | | |001----|---00011 |00000--|-----010 |111----|---011-|***b4*** |--0000-| |--100---

104

June 1, 2005

|2.1.1.1.3.1.1.3.1.4 modeSpecificInfo |2.1.1.1.3.1.1.3.1.4.1 fdd |2.1.1.1.3.1.1.3.1.4.1.1 ich-Ec-N0-reporti.. |2.1.1.1.3.1.1.3.1.4.1.2 ich-RS-reportin.. |2.1.1.1.3.1.1.3.1.4.1.3 pathloss-reportingI.. |2.1.1.1.3.1.1.3.2 monitoredSetReportingQuantities |2.1.1.1.3.1.1.3.2.1 sfn-SFN-OTD-Type |2.1.1.1.3.1.1.3.2.2 cellIdentity-reportingI.. |2.1.1.1.3.1.1.3.2.3 cellSynchronisationInfo.. |2.1.1.1.3.1.1.3.2.4 modeSpecificInfo |2.1.1.1.3.1.1.3.2.4.1 fdd |2.1.1.1.3.1.1.3.2.4.1.1 ich-Ec-N0-reporti.. |2.1.1.1.3.1.1.3.2.4.1.2 ich-RS-reportin.. |2.1.1.1.3.1.1.3.2.4.1.3 pathloss-reportingI.. |2.1.1.1.3.1.1.4 reportCriteria |2.1.1.1.3.1.1.4.1 intraFreqReportingCriteria |2.1.1.1.3.1.1.4.1.1 eventCriteriaList |2.1.1.1.3.1.1.4.1.1.1 intraFreqEventCriteria |2.1.1.1.3.1.1.4.1.1.1.1 event |2.1.1.1.3.1.1.4.1.1.1.1.1 e1a |2.1.1.1.3.1.1.4.1.1.1.1.1.1 triggeringCondi.. |2.1.1.1.3.1.1.4.1.1.1.1.1.2 reportingRange |2.1.1.1.3.1.1.4.1.1.1.1.1.3 w |2.1.1.1.3.1.1.4.1.1.1.1.1.4 reportDeactivat.. |2.1.1.1.3.1.1.4.1.1.1.1.1.5 reportingAmount |2.1.1.1.3.1.1.4.1.1.1.1.1.6 reportingInterval |2.1.1.1.3.1.1.4.1.1.1.2 hysteresis |2.1.1.1.3.1.1.4.1.1.1.3 timeToTrigger |2.1.1.1.3.1.1.4.1.1.1.4 reportingCellStatus |2.1.1.1.3.1.1.4.1.1.1.4.1 allActiveplusMoni..

CONFIDENTIAL - DRAFT

|1 |0 |0 |noReport |0 |1

|1 |0 |0

|monitoredSetCellsOnly |3 |0 |t2 |ra-Infinity |ri1 |0 |ttt0 |viactCellsPlus5

| | | | | | | | | | | | | | | | | | | | | | | | | | | | | |

Alexander Seifarth

7.2. Measurement Control and Report Procedure Measurement Control 4(4) | | | |---00--|***b5*** |--00000|***b4*** |---0000| |---010-| | | |---011-|***b3*** |-000---|----0000 |0000---| |100----| |---0---|----1---

105

June 1, 2005

|2.1.1.1.3.1.1.4.1.1.2 intraFreqEventCriteria |2.1.1.1.3.1.1.4.1.1.2.1 event |2.1.1.1.3.1.1.4.1.1.2.1.1 e1b |2.1.1.1.3.1.1.4.1.1.2.1.1.1 triggeringCondi.. |2.1.1.1.3.1.1.4.1.1.2.1.1.2 reportingRange |2.1.1.1.3.1.1.4.1.1.2.1.1.3 w |2.1.1.1.3.1.1.4.1.1.2.2 hysteresis |2.1.1.1.3.1.1.4.1.1.2.3 timeToTrigger |2.1.1.1.3.1.1.4.1.1.2.4 reportingCellStatus |2.1.1.1.3.1.1.4.1.1.2.4.1 withinActiveSet |2.1.1.1.3.1.1.4.1.1.3 intraFreqEventCriteria |2.1.1.1.3.1.1.4.1.1.3.1 event |2.1.1.1.3.1.1.4.1.1.3.1.1 e1c |2.1.1.1.3.1.1.4.1.1.3.1.1.1 replacementActi.. |2.1.1.1.3.1.1.4.1.1.3.1.1.2 reportingAmount |2.1.1.1.3.1.1.4.1.1.3.1.1.3 reportingInterval |2.1.1.1.3.1.1.4.1.1.3.2 hysteresis |2.1.1.1.3.1.1.4.1.1.3.3 timeToTrigger |2.1.1.1.3.1.1.4.1.1.3.4 reportingCellStatus |2.1.1.1.3.1.1.4.1.1.3.4.1 allActiveplusMoni.. |2.1.1.1.4 measurementReportingMode |2.1.1.1.4.1 measurementReportTransferMode |2.1.1.1.4.2 periodicalOrEventTrigger

CONFIDENTIAL - DRAFT

|activeSetCellsOnly |3 |0 |0 |ttt0 |e3

|t3 |ra1 |noPeriodicalreporting |0 |ttt0 |viactCellsPlus5 |acknowledgedModeRLC |eventTrigger

| | | | | | | | | | | | | | | | | | | | | | |

Alexander Seifarth

7.2. Measurement Control and Report Procedure Measurement Report 1(2) |TS 25.331 DCCH-UL (2002-03) (RRC_DCCH_UL) measurementReport (= measurementReport) | |uL-DCCH-Message | | |1 integrityCheckInfo | |**b32*** |1.1 messageAuthenticationCode |'11111000011011110101100100001111'B| |-0100--|1.2 rrc-MessageSequenceNumber |4 | | |2 message | | |2.1 measurementReport | |***b4*** |2.1.1 measurementIdentity |14 | | |2.1.2 measuredResults | | |2.1.2.1 intraFreqMeasuredResultsList | | |2.1.2.1.1 cellMeasuredResults | | |2.1.2.1.1.1 cellSynchronisationInfo | | |2.1.2.1.1.1.1 modeSpecificInfo | | |2.1.2.1.1.1.1.1 fdd | | |2.1.2.1.1.1.1.1.1 countC-SFN-Frame-difference | |0000---|2.1.2.1.1.1.1.1.1.1 countC-SFN-High |0 | |***b8*** |2.1.2.1.1.1.1.1.1.2 off |6 | |**b16*** |2.1.2.1.1.1.1.1.2 tm |16896 | | |2.1.2.1.1.2 modeSpecificInfo | | |2.1.2.1.1.2.1 fdd | | |2.1.2.1.1.2.1.1 primaryICH-Info | |***b9*** |2.1.2.1.1.2.1.1.1 primaryScramblingCode |3 | |-100101|2.1.2.1.1.2.1.2 ich-Ec-N0 |37 |

106

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

7.2. Measurement Control and Report Procedure Measurement Report 2(2) | | | | | |----0000 |00000110 |***B2*** | | | |***b9*** |***b6*** | | |***b4*** | | | |***b9***

107

June 1, 2005

|2.1.2.1.2 cellMeasuredResults |2.1.2.1.2.1 cellSynchronisationInfo |2.1.2.1.2.1.1 modeSpecificInfo |2.1.2.1.2.1.1.1 fdd |2.1.2.1.2.1.1.1.1 countC-SFN-Frame-difference |2.1.2.1.2.1.1.1.1.1 countC-SFN-High |2.1.2.1.2.1.1.1.1.2 off |2.1.2.1.2.1.1.1.2 tm |2.1.2.1.2.2 modeSpecificInfo |2.1.2.1.2.2.1 fdd |2.1.2.1.2.2.1.1 primaryICH-Info |2.1.2.1.2.2.1.1.1 primaryScramblingCode |2.1.2.1.2.2.1.2 ich-Ec-N0 |2.1.3 eventResults |2.1.3.1 intraFreqEventResults |2.1.3.1.1 eventID |2.1.3.1.2 cellMeasurementEventResults |2.1.3.1.2.1 fdd |2.1.3.1.2.1.1 primaryICH-Info |2.1.3.1.2.1.1.1 primaryScramblingCode

CONFIDENTIAL - DRAFT

|0 |6 |17372

|1 |15

|e1a

|3

| | | | | | | | | | | | | | | | | | | |

Alexander Seifarth

Module 04 Complete Sequences – Use Cases (Layer 3 signalling) Version 0.0.1 (02/05/2005) Author: Alexander Seifarth ([email protected])

1

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

1. CS Mobility Management

2

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

1. CS Mobility Management 1.1. Location Area Update

• • • •

3

UE is UTRA idle; UE is PS detached; performs cell reselection no services follow after update

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

1.1. Location Area Update (1) UE

RNC

MSC Server

UTRA_Idle cell reselection New LAI ?

false

true

[CCCH] RRC

RRC Connection Request

Initial UE ID = IMSI|TMSI+LAI, Est.Cause = registration

[CCCH] RRC

RRC Connection Setup

U-RNTI, C-RNTI, signalling radio bearer RB1..RB4, TrCH configuration, PhCH configuration, radio access capability update requirement

[DCCH] RRC

RRC Connection Setup Complete

UE radio access capabilities CELL_DCH|CELL_FACH

[DCCH] RRC

Initial Direct Transfer

RANAP Initial UE Message

CN domain = cs, NAS-PDU = MM-message: Location Updating Request CN domain = cs, LAI, SAI, RNC-ID, NAS-PDU = Location Updating Request 4

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

1.1. Location Area Update (2) UE

[DCCH] RRC

RNC

Downlink Direct Transfer

CN domain = cs, NAS-PDU = MM-message: Authentication Request

[DCCH] RRC

Uplink Direct Transfer

CN domain = cs, NAS-PDU = MM-message: Authentication Response

[DCCH] RRC

Security Mode Command

selected UIA, selected UEA, ciphering activation time, …

[DCCH] RRC

Security Mode Complete

…

[DCCH] RRC

Downlink Direct Transfer

Uplink Direct Transfer

CN domain = cs, NAS-PDU = MM-message: TMSI Reallocation Compl.

5

June 1, 2005

RANAP Direct Transfer SAPI=0, NAS-PDU = Authentication Req.

RANAP Direct Transfer LAI, SAI, NAS-PDU = Authentication Resp.

RANAP Security Mode Command permitted UIA, IK, permitted UEA, CK, …

RANAP Security Mode Command selected UIA, selected UEA

CN domain = cs, NAS-PDU = MM-message: Location Updating Accept

[DCCH] RRC

MSC Server

CONFIDENTIAL - DRAFT

RANAP Direct Transfer SAPI=0, NAS-PDU = Location Updating Accept

RANAP Direct Transfer LAI, SAI, NAS-PDU = TMSI Realloc. Compl.

Alexander Seifarth

1.1. Location Area Update (3) UE

RNC

MSC Server RANAP Iu Release Command

[DCCH] RRC

RRC Connection Release

cause = normal event, N308 (only for CELL_DCH)

[DCCH] RRC

cause = normal event

RANAP Iu Release Complete

RRC Connection Release Complete

UTRA_Idle

6

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

1. CS Mobility Management 1.2. IMSI Detach (UE Power Off)

• UE is UTRA idle; • UE is PS detached; • switches UE off

7

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

1.2. IMSI Detach (UE Power Off) (1) UE

RNC [BCCH] RRC

UTRA_Idle

MSC Server

SIB 1

…, ATT, …

Power Off () ATT=true

false

Power Off

true

[CCCH] RRC

RRC Connection Request

Initial UE ID = IMSI|TMSI+LAI, Est.Cause = detach

[CCCH] RRC

RRC Connection Setup

U-RNTI, C-RNTI, signalling radio bearer RB1..RB4, TrCH configuration, PhCH configuration, radio access capability update requirement

[DCCH] RRC

RRC Connection Setup Complete

UE radio access capabilities CELL_DCH|CELL_FACH

[DCCH] RRC

Initial Direct Transfer

CN domain = cs, NAS-PDU = MM-message: IMSI Detach Indication

8

June 1, 2005

CONFIDENTIAL - DRAFT

RANAP Initial UE Message CN domain = cs, LAI, SAI, RNC-ID, NAS-PDU = IMSI Detach Indication

Alexander Seifarth

1.2. IMSI Detach (UE Power Off) (2) UE

[DCCH] RRC

RNC

RRC Connection Release

MSC Server SC

Connection Refused

Cause = normal event | unspecified, N308 (only CELL_DCH)

[DCCH] RRC

RRC Connection Release Complete

UTRA_Idle Power Off

9

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

2. CS Call Services

10

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

2. CS Call Services 2.1. Mobile Originating Call (MOC)

• • • •

11

UE is UTRA idle; no PS services running, no other CS services except the MOC no handovers during call call release by remote party

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

2.1. Mobile Originating Call (MOC) (1) UE

RNC

MSC Server

UTRA_Idle call request ()

[CCCH] RRC

RRC Connection Request

Initial UE ID = IMSI|TMSI+LAI, Est.Cause = originating conversational call

[CCCH] RRC

RRC Connection Setup

U-RNTI, C-RNTI, signalling radio bearer RB1..RB4, TrCH configuration, PhCH configuration, radio access capability update requirement

[DCCH] RRC

RRC Connection Setup Complete

UE radio access capabilities CELL_DCH|CELL_FACH

[DCCH] RRC

Initial Direct Transfer

CN domain = cs, NAS-PDU = MM-message: CM Service Request

12

June 1, 2005

CONFIDENTIAL - DRAFT

RANAP Initial UE Message CN domain = cs, LAI, SAI, RNC-ID, NAS-PDU = CM Service Request

Alexander Seifarth

2.1. Mobile Originating Call (MOC) (2) UE

[DCCH] RRC

RNC

Downlink Direct Transfer

CN domain = cs, NAS-PDU = MM-message: Authentication Request

[DCCH] RRC

Uplink Direct Transfer

CN domain = cs, NAS-PDU = MM-message: Authentication Response

[DCCH] RRC

Security Mode Command

selected UIA, selected UEA, ciphering activation time, …

[DCCH] RRC

Security Mode Complete

…

[DCCH] RRC

Uplink Direct Transfer

June 1, 2005

SAPI=0, NAS-PDU = Authentication Req.

RANAP Direct Transfer LAI, SAI, NAS-PDU = Authentication Resp.

RANAP Security Mode Command permitted UIA, IK, permitted UEA, CK, …

RANAP Security Mode Command

RANAP Direct Transfer LAI, SAI, NAS-PDU = Setup

Downlink Direct Transfer

CN domain = cs, NAS-PDU = CC-message: Call Proceeding 13

RANAP Direct Transfer

selected UIA, selected UEA

CN domain = cs, NAS-PDU = CC-message: Setup

[DCCH] RRC

MSC Server

CONFIDENTIAL - DRAFT

RANAP Direct Transfer SAPI=0, NAS-PDU = Call Proceeding

Alexander Seifarth

2.1. Mobile Originating Call (MOC) (3) UE

[DCCH] RRC

RNC

RANAP RAB Assignment Request

Radio Bearer Setup

RRC state = CELL_DCH, RAB to setupÆ radio bearer to setup, signalling radio bearer, transport channels to add, physical channel

[DCCH] RRC

Radio Bearer Setup Complete

CELL_DCH

[DCCH] RRC

Downlink Direct Transfer

Downlink Direct Transfer

CN domain = cs, NAS-PDU = CC-message: Connect

[DCCH] RRC

RABSetupOrModifyItemÆRAB Parameter

RANAP RAB Assignment Response successful setup

CN domain = cs, NAS-PDU = CC-message: Alerting

[DCCH] RRC

MSC Server

Uplink Direct Transfer

CN domain = cs, NAS-PDU = CC-message: Connect Ackn.

RANAP Direct Transfer SAPI=0, NAS-PDU = Alerting

RANAP Direct Transfer SAPI=0, NAS-PDU = Connect

RANAP Direct Transfer LAI, SAI, NAS-PDU = Connect Ackn.

call active 14

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

2.1. Mobile Originating Call (MOC) (4) UE

[DCCH] RRC

RNC

Downlink Direct Transfer

CN domain = cs, NAS-PDU = CC-message: Disconnect

[DCCH] RRC

Uplink Direct Transfer

CN domain = cs, NAS-PDU = CC-message: Release

[DCCH] RRC

Downlink Direct Transfer

CN domain = cs, NAS-PDU = CC-message: Release Complete

[DCCH] RRC

RRC Connection Release

cause = normal event

[DCCH] RRC

MSC Server

RANAP Direct Transfer SAPI=0, NAS-PDU = Disconnect

RANAP Direct Transfer LAI, SAI, NAS-PDU = Release

RANAP Direct Transfer SAPI=0, NAS-PDU = Release Complete

RANAP Iu Release Command cause = normal event

RANAP Iu Release Complete RRC Connection Release Complete

released RAB

UTRA_Idle

15

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

2. CS Call Services 2.2. Mobile Terminating Call (MTC)

• UE is UTRA idle; • no other services running; • call release by local party

16

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

2.2. Mobile Terminating Call (MTC) (1) UE

RNC RANAP

UTRA_Idle

[PCCH] RRC

MSC Server

Paging Type 1

Paging

CN domain = cs, LAI, IMSI, TMSI, cause

UE-ID = TMSI|IMSI, cause = terminating conversation call|terminating cause unknown

[CCCH] RRC

RRC Connection Request

Initial UE ID = IMSI|TMSI+LAI, Est.Cause = terminating conversational call|terminating cause unknown

[CCCH] RRC

RRC Connection Setup

U-RNTI, C-RNTI, signalling radio bearer RB1..RB4, TrCH configuration, PhCH configuration, radio access capability update requirement

[DCCH] RRC

RRC Connection Setup Complete

UE radio access capabilities CELL_DCH|CELL_FACH

[DCCH] RRC

Initial Direct Transfer

CN domain = cs, NAS-PDU = MM-message: Paging Response

17

June 1, 2005

CONFIDENTIAL - DRAFT

RANAP Initial UE Message CN domain = cs, LAI, SAI, RNC-ID, NAS-PDU = Paging Response

Alexander Seifarth

2.2. Mobile Terminating Call (MTC) (2) UE

[DCCH] RRC

RNC

Downlink Direct Transfer

CN domain = cs, NAS-PDU = MM-message: Authentication Request

[DCCH] RRC

Uplink Direct Transfer

CN domain = cs, NAS-PDU = MM-message: Authentication Response

[DCCH] RRC

Security Mode Command

selected UIA, selected UEA, ciphering activation time, …

[DCCH] RRC

Security Mode Complete

…

[DCCH] RRC

RANAP Direct Transfer SAPI=0, NAS-PDU = Authentication Req.

RANAP Direct Transfer LAI, SAI, NAS-PDU = Authentication Resp.

RANAP Security Mode Command permitted UIA, IK, permitted UEA, CK, …

RANAP Security Mode Command selected UIA, selected UEA

Downlink Direct Transfer

CN domain = cs, NAS-PDU = CC-message: Setup

[DCCH] RRC

MSC Server

Uplink Direct Transfer

CN domain = cs, NAS-PDU = CC-message: Call Confirmed

RANAP Direct Transfer SAPI=0, NAS-PDU = Setup

RANAP Direct Transfer LAI, SAI, NAS-PDU = Call Confirmed

18

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

2.2. Mobile Terminating Call (MTC) (3) UE

[DCCH] RRC

RNC

RANAP RAB Assignment Request

Radio Bearer Setup

RRC state = CELL_DCH, RAB to setupÆ radio bearer to setup, signalling radio bearer, transport channels to add, physical channel

[DCCH] RRC

Radio Bearer Setup Complete

CELL_DCH

[DCCH] RRC

Uplink Direct Transfer

Uplink Direct Transfer

CN domain = cs, NAS-PDU = CC-message: Connect

[DCCH] RRC

RABSetupOrModifyItemÆRAB Parameter

RANAP RAB Assignment Response successful setup

CN domain = cs, NAS-PDU = CC-message: Alerting

[DCCH] RRC

MSC Server

Downlink Direct Transfer

CN domain = cs, NAS-PDU = CC-message: Connect Ackn.

RANAP Direct Transfer LAI, SAI, NAS-PDU = Alerting

RANAP Direct Transfer LAI, SAI, NAS-PDU = Connect

RANAP Direct Transfer SAPI=0, NAS-PDU = Connect Ackn.

call active 19

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

2.2. Mobile Terminating Call (MTC) (4) UE

[DCCH] RRC

RNC

Uplink Direct Transfer

CN domain = cs, NAS-PDU = CC-message: Disconnect

[DCCH] RRC

Downlink Direct Transfer

CN domain = cs, NAS-PDU = CC-message: Release

[DCCH] RRC

Uplink Direct Transfer

CN domain = cs, NAS-PDU = CC-message: Release Complete

[DCCH] RRC

RRC Connection Release

cause = normal event

[DCCH] RRC

MSC Server

RANAP Direct Transfer LAI, SAI, NAS-PDU = Disconnect

RANAP Direct Transfer SAPI=0, NAS-PDU = Release

RANAP Direct Transfer LAI, SAI, NAS-PDU = Release Complete

RANAP Iu Release Command cause = normal event

RANAP Iu Release Complete RRC Connection Release Complete

released RAB

UTRA_Idle

20

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

3. PS Mobility Management

21

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

3. PS Mobility Management 3.1. PS (GPRS) Attach

• UE is UTRA idle; • UE is PS detached; • no CS services running

22

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

3.1. PS (GPRS) Attach (1) UE RNC

SGSN

UTRA_Idle GPRS activation ()

[CCCH] RRC

RRC Connection Request

Initial UE ID = IMSI|TMSI+LAI, Est.Cause = registration

[CCCH] RRC

RRC Connection Setup

U-RNTI, C-RNTI, signalling radio bearer RB1..RB4, TrCH configuration, PhCH configuration, radio access capability update requirement

[DCCH] RRC

RRC Connection Setup Complete

UE radio access capabilities CELL_DCH|CELL_FACH

[DCCH] RRC

Initial Direct Transfer

CN domain = ps, NAS-PDU = GMM-message: Attach Request

23

June 1, 2005

CONFIDENTIAL - DRAFT

RANAP Initial UE Message CN domain = ps, RAI, SAI, RNC-ID, NAS-PDU = Attach Request

Alexander Seifarth

3.1. PS (GPRS) Attach (2) UE SGSN

RNC [DCCH] RRC

Downlink Direct Transfer

CN domain = ps, NAS-PDU = GMM-message: Authentication And Ciphering Request

[DCCH] RRC

Uplink Direct Transfer

CN domain = ps, NAS-PDU = GMM-message: Authentication And Ciphering Response

[DCCH] RRC

Security Mode Command

selected UIA, selected UEA, ciphering activation time, …

[DCCH] RRC

Security Mode Complete

…

[DCCH] RRC

June 1, 2005

SAPI=0, NAS-PDU = Authentication And Ciphering Request

RANAP Direct Transfer RAI, SAI, NAS-PDU = Authentication And Ciphering Response

RANAP Security Mode Command permitted UIA, IK, permitted UEA, CK, …

RANAP Security Mode Command selected UIA, selected UEA

Downlink Direct Transfer

CN domain = ps, NAS-PDU = GMM-message: Attach Accept

24

RANAP Direct Transfer

CONFIDENTIAL - DRAFT

RANAP Direct Transfer SAPI=0, NAS-PDU = Attach Accept

Alexander Seifarth

3.1. PS (GPRS) Attach (3) UE SGSN

RNC [DCCH] RRC

Uplink Direct Transfer

CN domain = ps, NAS-PDU = GMM-message: Attach Complete

[DCCH] RRC

RRC Connection Release

cause = normal event

[DCCH] RRC

RANAP Direct Transfer RAI, SAI, NAS-PDU = Attach Complete

RANAP Iu Release Command cause = normal event

RANAP Iu Release Complete RRC Connection Release Complete

UTRA_Idle

25

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

3. PS Mobility Management 3.2. Routing Area Update (IDLE mode update)

• UE is UTRA idle; • UE is PS attached; • performs cell reselection

26

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

3.2. Routing Area Update (IDLE) (1) UE

RNC SGSN

UTRA_Idle cell reselection New RAI ?

false

true

[CCCH] RRC

RRC Connection Request

Initial UE ID = IMSI|PTMSI+RAI|TMSI+LAI, Est.Cause = registration

[CCCH] RRC

RRC Connection Setup

U-RNTI, C-RNTI, signalling radio bearer RB1..RB4, TrCH configuration, PhCH configuration, radio access capability update requirement

[DCCH] RRC

RRC Connection Setup Complete

UE radio access capabilities CELL_FACH|CELL_DCH

[DCCH] RRC

Initial Direct Transfer

CN domain = ps, NAS-PDU = GMM-message: Routing Area Update Request 27

June 1, 2005

CONFIDENTIAL - DRAFT

RANAP Initial UE Message CN domain = ps, RAI, SAI, RNC-ID, NAS-PDU = Routing Area Update Request

Alexander Seifarth

3.2. Routing Area Update (IDLE) (2) UE SGSN

RNC [DCCH] RRC

Downlink Direct Transfer

CN domain = ps, NAS-PDU = GMM-message: Authentication And Ciphering Request

[DCCH] RRC

Uplink Direct Transfer

CN domain = ps, NAS-PDU = GMM-message: Authentication And Ciphering Response

[DCCH] RRC

Security Mode Command

selected UIA, selected UEA, ciphering activation time, …

[DCCH] RRC

Security Mode Complete

…

[DCCH] RRC

June 1, 2005

SAPI=0, NAS-PDU = Authentication And Ciphering Request

RANAP Direct Transfer RAI, SAI, NAS-PDU = Authentication And Ciphering Response

RANAP Security Mode Command permitted UIA, IK, permitted UEA, CK, …

RANAP Security Mode Command selected UIA, selected UEA

Downlink Direct Transfer

CN domain = ps, NAS-PDU = GMM-message: Routing Area Update Accept

28

RANAP Direct Transfer

CONFIDENTIAL - DRAFT

RANAP Direct Transfer SAPI=0, NAS-PDU = Routing Area Update Accept

Alexander Seifarth

3.2. Routing Area Update (IDLE) (3) UE SGSN

RNC [DCCH] RRC

Uplink Direct Transfer

CN domain = ps, NAS-PDU = GMM-message: Routing Area Update Complete

RANAP Direct Transfer RAI, SAI, NAS-PDU = Routing Area Update Complete

RANAP

[DCCH] RRC

RRC Connection Release

cause = normal event

[DCCH] RRC

Iu Release Command

cause = normal event

RANAP Iu Release Complete RRC Connection Release Complete

UTRA_Idle

29

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

3. PS Mobility Management 3.3. Routing Area Update (Connected mode update)

• UE is UTRA connected for CS services; • UE is PS attached without Iu signalling connection, (PMM_IDLE); • UE performs cell reselection

30

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

3.3. Routing Area Update (Connected) (1) UE

RNC SGSN

UTRA_Connected CELL_FACH|CELL_DCH

[DCCH] RRC

UTRAN Mobility Information

…, new RAI, …

[DCCH] RRC

UTRAN Mobility Information Confirm

…

[DCCH] RRC

Initial Direct Transfer

CN domain = ps, NAS-PDU = GMM-message: Routing Area Update Request

[DCCH] RRC

Downlink Direct Transfer

CN domain = ps, NAS-PDU = GMM-message: Authentication And Ciphering Request

[DCCH] RRC

Uplink Direct Transfer

CN domain = ps, NAS-PDU = GMM-message: Authentication And Ciphering Response 31

June 1, 2005

CONFIDENTIAL - DRAFT

RANAP Initial UE Message CN domain = ps, RAI, SAI, RNC-ID, NAS-PDU = Routing Area Update Request

RANAP Direct Transfer SAPI=0, NAS-PDU = Authentication And Ciphering Request

RANAP Direct Transfer RAI, SAI, NAS-PDU = Authentication And Ciphering Response

Alexander Seifarth

3.3. Routing Area Update (Connected) (2) UE SGSN

RNC [DCCH] RRC

Security Mode Command

selected UIA, selected UEA, ciphering activation time, …

[DCCH] RRC

Security Mode Complete

…

[DCCH] RRC

permitted UIA, IK, permitted UEA, CK, …

RANAP Security Mode Command selected UIA, selected UEA

Downlink Direct Transfer

CN domain = ps, NAS-PDU = GMM-message: Routing Area Update Accept

[DCCH] RRC

RANAP Security Mode Command

Uplink Direct Transfer

CN domain = ps, NAS-PDU = GMM-message: Routing Area Update Complete

RANAP Direct Transfer SAPI=0, NAS-PDU = Routing Area Update Accept

RANAP Direct Transfer RAI, SAI, NAS-PDU = Routing Area Update Complete

UTRA_Connected

32

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

3. PS Mobility Management 3.4. PS (GPRS) Detach (no UE power off)

• UE is UTRA Idle • UE is PMM_Idle • GPRS is to be deactivated by

33

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

3.4. PS (GPRS) Detach (no UE power off) (1) UE RNC

SGSN

UTRA_Idle GPRS deactivation ()

[CCCH] RRC

RRC Connection Request

Initial UE ID = IMSI|TMSI+LAI, Est.Cause = detach

[CCCH] RRC

RRC Connection Setup

U-RNTI, C-RNTI, signalling radio bearer RB1..RB4, TrCH configuration, PhCH configuration, radio access capability update requirement

[DCCH] RRC

RRC Connection Setup Complete

UE radio access capabilities CELL_DCH|CELL_FACH

[DCCH] RRC

Initial Direct Transfer

CN domain = ps, NAS-PDU = GMM-message: Detach Request

34

June 1, 2005

CONFIDENTIAL - DRAFT

RANAP Initial UE Message CN domain = ps, RAI, SAI, RNC-ID, NAS-PDU = Detach Request

Alexander Seifarth

3.4. PS (GPRS) Detach (no UE power off) (2) UE SGSN

RNC [DCCH] RRC

Downlink Direct Transfer

CN domain = ps, NAS-PDU = GMM-message: Authentication And Ciphering Request

[DCCH] RRC

Uplink Direct Transfer

CN domain = ps, NAS-PDU = GMM-message: Authentication And Ciphering Response

[DCCH] RRC

Security Mode Command

selected UIA, selected UEA, ciphering activation time, …

[DCCH] RRC

Security Mode Complete

…

[DCCH] RRC

June 1, 2005

SAPI=0, NAS-PDU = Authentication And Ciphering Request

RANAP Direct Transfer RAI, SAI, NAS-PDU = Authentication And Ciphering Response

RANAP Security Mode Command permitted UIA, IK, permitted UEA, CK, …

RANAP Security Mode Command selected UIA, selected UEA

Downlink Direct Transfer

CN domain = ps, NAS-PDU = GMM-message: Detach Accept

35

RANAP Direct Transfer

CONFIDENTIAL - DRAFT

RANAP Direct Transfer SAPI=0, NAS-PDU = Detach Accept

Alexander Seifarth

3.4. PS (GPRS) Detach (no UE power off) (3) UE SGSN

RNC [DCCH] RRC

RRC Connection Release

cause = normal event

[DCCH] RRC

RANAP Iu Release Command cause = normal event

RANAP Iu Release Complete RRC Connection Release Complete

UTRA_Idle

36

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

4. PDP Context Management

37

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

4. PDP Context Management 4.1. PDP Context Activation

• UE is UTRA idle, • UE is PMM_Idle (already ed for GPRS) • or application activate PDP context

38

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

4.1. PDP Context Activation (1) UE RNC

SGSN

UTRA_Idle PDP Context request ()

[CCCH] RRC

RRC Connection Request

Initial UE ID = IMSI|TMSI+LAI, Est.Cause = originating <xxx> call

[CCCH] RRC

RRC Connection Setup

U-RNTI, C-RNTI, signalling radio bearer RB1..RB4, TrCH configuration, PhCH configuration, radio access capability update requirement

[DCCH] RRC

RRC Connection Setup Complete

UE radio access capabilities CELL_DCH|CELL_FACH

[DCCH] RRC

Initial Direct Transfer

CN domain = ps, NAS-PDU = GMM-message: Service Request (service type = signalling)

39

June 1, 2005

CONFIDENTIAL - DRAFT

RANAP Initial UE Message CN domain = ps, RAI, SAI, RNC-ID, NAS-PDU = Service Request

Alexander Seifarth

4.1. PDP Context Activation (2) UE SGSN

RNC [DCCH] RRC

Downlink Direct Transfer

CN domain = ps, NAS-PDU = GMM-message: Authentication And Ciphering Request

[DCCH] RRC

Uplink Direct Transfer

CN domain = ps, NAS-PDU = GMM-message: Authentication And Ciphering Response

[DCCH] RRC

Security Mode Command

selected UIA, selected UEA, ciphering activation time, …

[DCCH] RRC

Security Mode Complete

…

[DCCH] RRC

June 1, 2005

SAPI=0, NAS-PDU = Authentication And Ciphering Request

RANAP Direct Transfer RAI, SAI, NAS-PDU = Authentication And Ciphering Response

RANAP Security Mode Command permitted UIA, IK, permitted UEA, CK, …

RANAP Security Mode Command selected UIA, selected UEA

Uplink Direct Transfer

CN domain = ps, NAS-PDU = SM-message: Activate PDP Context Request

40

RANAP Direct Transfer

CONFIDENTIAL - DRAFT

RANAP Direct Transfer RAI, SAI, NAS-PDU = Activate PDP Context Request

Alexander Seifarth

4.1. PDP Context Activation (3) UE

RNC SGSN

[DCCH] RRC

RANAP RAB Assignment Request

Radio Bearer Setup

RRC state = CELL_DCH/FACH, RAB to setupÆ radio bearer to setup, signalling radio bearer, transport channels to add, physical channel

[DCCH] RRC

Radio Bearer Setup Complete

RANAP RAB Assignment Response successful setup

CELL_DCH|CELL_FACH

[DCCH] RRC

RABSetupOrModifyItemÆRAB Parameter

Downlink Direct Transfer

CN domain = ps, NAS-PDU = SM-message: Activate PDP Context Accept

RANAP Direct Transfer SAPI=0, NAS-PDU = Activate PDP Context Accept

Packet PDU Transmission

41

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

4. PDP Context Management 4.2. Service Data for uplink traffic

• UE is UTRA idle and PMM_Idle, • PDP context is active • uplink packet data shall be sent

42

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

4.2. Service Data for uplink traffic (1) UE RNC

SGSN

UTRA_Idle uplink PDP PDU

[CCCH] RRC

RRC Connection Request

Initial UE ID = IMSI|TMSI+LAI, Est.Cause = high priority signalling

[CCCH] RRC

RRC Connection Setup

U-RNTI, C-RNTI, signalling radio bearer RB1..RB4, TrCH configuration, PhCH configuration, radio access capability update requirement

[DCCH] RRC

RRC Connection Setup Complete

UE radio access capabilities CELL_DCH|CELL_FACH

[DCCH] RRC

Initial Direct Transfer

CN domain = ps, NAS-PDU = GMM-message: Service Request (service type = data)

43

June 1, 2005

CONFIDENTIAL - DRAFT

RANAP Initial UE Message CN domain = ps, RAI, SAI, RNC-ID, NAS-PDU = Service Request

Alexander Seifarth

4.2. Service Data for uplink traffic (2) UE SGSN

RNC [DCCH] RRC

Security Mode Command

selected UIA, selected UEA, ciphering activation time, …

[DCCH] RRC

Security Mode Complete

…

[DCCH] RRC

permitted UIA, IK, permitted UEA, CK, …

RANAP Security Mode Command selected UIA, selected UEA

RANAP RAB Assignment Request

Radio Bearer Setup

RRC state = CELL_DCH/FACH, RAB to setupÆ radio bearer to setup, signalling radio bearer, transport channels to add, physical channel

[DCCH] RRC

RANAP Security Mode Command

Radio Bearer Setup Complete

RABSetupOrModifyItemÆRAB Parameter

RANAP RAB Assignment Response successful setup

CELL_DCH|CELL_FACH

Packet PDU Transmission

44

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

4. PDP Context Management 4.3. Service Data for downlink traffic

• UE is UTRA idle and PMM_Idle, • PDP context is active • downlink packet data shall be sent

45

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

4.3. Service Data for downlink traffic (1) UE SGSN

RNC RANAP

UTRA_Idle

[PCCH] RRC

Paging Type 1

Paging

CN domain = ps, RAI, IMSI, PTMSI, cause

UE-ID = TMSI|IMSI, cause = terminating cause unknown

[CCCH] RRC

RRC Connection Request

Initial UE ID = IMSI|TMSI+LAI, Est.Cause = terminating cause unkn.

[CCCH] RRC

RRC Connection Setup

U-RNTI, C-RNTI, signalling radio bearer RB1..RB4, TrCH configuration, PhCH configuration, radio access capability update requirement

[DCCH] RRC

RRC Connection Setup Complete

UE radio access capabilities CELL_DCH|CELL_FACH

[DCCH] RRC

Initial Direct Transfer

CN domain = ps, NAS-PDU = GMM-message: Service Request (service type = paging response)

46

June 1, 2005

CONFIDENTIAL - DRAFT

RANAP Initial UE Message CN domain = ps, RAI, SAI, RNC-ID, NAS-PDU = Service Request

Alexander Seifarth

4.3. Service Data for downlink traffic (2) UE SGSN

RNC [DCCH] RRC

Security Mode Command

selected UIA, selected UEA, ciphering activation time, …

[DCCH] RRC

Security Mode Complete

…

[DCCH] RRC

permitted UIA, IK, permitted UEA, CK, …

RANAP Security Mode Command selected UIA, selected UEA

RANAP RAB Assignment Request

Radio Bearer Setup

RRC state = CELL_DCH/FACH, RAB to setupÆ radio bearer to setup, signalling radio bearer, transport channels to add, physical channel

[DCCH] RRC

RANAP Security Mode Command

Radio Bearer Setup Complete

RABSetupOrModifyItemÆRAB Parameter

RANAP RAB Assignment Response successful setup

CELL_DCH|CELL_FACH

Packet PDU Transmission

47

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

4. PDP Context Management 4.4. PDP Context Deactivation by UE

• UE is UTRA connected and PMM_Connected, • PDP context is active and will be deactivated, • ohter PS services are still active

48

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

4.4. PDP Context Deactivation (1) UE SGSN

RNC UTRA_Connected PMM_Connected

[DCCH] RRC

Uplink Direct Transfer

CN domain = ps, NAS-PDU = SM-message: Deactivate PDP Context Request

[DCCH] RRC

Radio Bearer Release

RRC state = XXX, RAB to reconfigure, RB to release, TrCH to reconf.

[DCCH] RRC

Radio Bearer Release Complete

RANAP Direct Transfer RAI, SAI, NAS-PDU = Deact. PDP Context Request

RANAP RAB Assignment Request RABReleaseItemÆRAB ID

RANAP RAB Assignment Response RAB data volume

[DCCH] RRC

Downlink Direct Transfer

CN domain = ps, NAS-PDU = SM-message: Deactivate PDP Context Accept

RANAP Direct Transfer SAPI=0, NAS-PDU = Deact.PDP Context Accept

UTRA_XXX 49

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

5. Radio Management Procedures

50

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

5. Radio Management Procedures 5.1. Soft Handover

• UE is UTRA connected in state CELL_DCH, • soft handover including cell 1, cell 2, cell 3

51

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

5.1. Soft Handover (1 – add radio link) UE RNC

Active Set CELL_DCH

cell 1

[DCCH] RRC

Measurement Control

intra-frequency cell list for cell 1, reporting criteriaÆ events 1A, 1B, 1C

[DCCH] RRC

Measurement Report

trigger event = 1A for cell 2, measured results

[DCCH] RRC

Active Set Update

cell addition info Æ downlink code information for cell 2

[DCCH] RRC

Active Set Update Complete

Active Set CELL_DCH

cell 1, cell 2

[DCCH] RRC

Measurement Control

intra-frequency cell list for cell 1/2, reporting criteriaÆ events 1A, 1B, 1C

52

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

5.1. Soft Handover (2 – replacement) UE RNC [DCCH] RRC

Measurement Report

trigger event = 1C for cell 3/1, measured results

[DCCH] RRC

Active Set Update

cell addition info Æ downlink code information for cell 3 cell removal info Æ radio link id cell 1

[DCCH] RRC

Active Set Update Complete

Active Set CELL_DCH

cell 3, cell 2

[DCCH] RRC

Measurement Control

intra-frequency cell list for cell 3/2, removal of cell 1’s neighbour cell list, reporting criteriaÆ events 1A, 1B, 1C

53

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

5.1. Soft Handover (3 – radio link deletion) UE RNC [DCCH] RRC

Measurement Report

trigger event = 1B for cell 2, measured results

[DCCH] RRC

Active Set Update

cell removal info Æ radio link id cell 2

[DCCH] RRC

Active Set Update Complete

Active Set CELL_DCH

cell 3

[DCCH] RRC

Measurement Control

removal of cell 2’s neighbour cell list, reporting criteriaÆ events 1A, 1B, 1C

54

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

5. Radio Management Procedures 5.2. Packet Radio Bearer Management

• UE is UTRA connected and PMM_Connected, • PDP context is active and RAB exists for it

55

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

5.2. Packet Radio Bearer Management (1) UE SGSN

RNC CELL_DCH|CELL_FACH

Packet PDU Transmission RB Inactivity Timer

[DCCH] RRC

Radio Bearer Release

RRC state = CELL_PCH/URA_PCH, radio bearer identitiy to release

[DCCH] RRC

Expiry of all Inactivity Timers

Radio Bearer Release Complete

CELL_PCH|URA_PCH

uplink PDP PDU

[CCCH] RRC

Cell Update

U-RNTI, cause = uplink data transmission

[CCCH] RRC

Cell Update Confirm

U-RNTI, RRC state = CELL_DCH/FACG, radio bearer to set up 56

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

5.2. Packet Radio Bearer Management (2) UE SGSN

RNC [DCCH] RRC

Radio Bearer Setup Complete

CELL_DCH|CELL_FACH

Packet PDU Transmission RB Inactivity Timer

[DCCH] RRC

Radio Bearer Release

RRC state = CELL_PCH/URA_PCH, radio bearer identitiy to release

[DCCH] RRC

Expiry of all Inactivity Timers

Radio Bearer Release Complete

CELL_PCH|URA_PCH

57

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth

5.2. Packet Radio Bearer Management (3) UE SGSN

RNC

Packet PDU Transmission

Paging Type 1

[PCCH] RRC U-RNTI

[CCCH] RRC

Cell Update

U-RNTI, cause = paging response

Cell Update Confirm

[CCCH] RRC

U-RNTI, RRC state = CELL_DCH/FACG, radio bearer to set up

[DCCH] RRC

Radio Bearer Setup Complete

CELL_DCH|CELL_FACH

Packet PDU Transmission Packet PDU Transmission RB Inactivity Timer

58

June 1, 2005

CONFIDENTIAL - DRAFT

Alexander Seifarth