Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Umts call-flows

Umts call-flows

  • Login to see the comments

Umts call-flows

  1. 1. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 20051 Module 01 UE-UTRAN Signalling Protocols Version 0.0.1 (07/02/2005) Author: Alexander Seifarth (a.seifarth@techcom.de)
  2. 2. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 20052 1. Network Architecture
  3. 3. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 20053 1. Network Architecture 1.1. Top Level Network Architecture
  4. 4. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 20054 1.1. Top Level Network Architecture UE UTRAN (UMTS Terrestrial Radio Access Network) UTRAN (UMTS Terrestrial Radio Access Network) CN (Core Network) CN (Core Network) Uu Iu Access Protocols Access Protocols Non Access Protocols intra-UTRAN protocols intra-CN protocols
  5. 5. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 20055 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 (User 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 non- access signalling protocols. These non-access protocols are exchanged between UE and CN directly. UTRAN must transparently pass 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.
  6. 6. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 20056 1. Network Architecture 1.2. Network Elements and Interfaces
  7. 7. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 20057 1.2. Network Elements and Interfaces Node B UE RNC Node B Iub Iub RNC Iur Iub Node B RNS RNS BSC BTS BSS Uu MSC/VLR Server#1 SGSN #1 SGSN #L MSC/VLR Server#N . . . . . . CS MGW #1 CS MGW #K Iu-CS Iu-PS Iu-PS A Gb CS-CN PS-CN
  8. 8. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 20058 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 pass transparently through the Node B. Between RNC and Node B there is the Iub interface. Its task is to transfer data (user 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 user 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.
  9. 9. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 20059 1.2. Network Elements and Interfaces Serving RNC Drift RNC SGSN MSC Server CS-MGW Node B Node B Node B UE Drift RNC • relay between Iur and Iub • splitting/combining function [optional] • local admission control Serving RNC • radio management (handover decision, channel de/allocation • NAS message relay • Iu management • backward error correction • splitting/combination function • local and global admission control Iur IubIubIub Iu-PSIu-CS
  10. 10. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200510 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.
  11. 11. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200511 1. Network Architecture 1.3. UTRAN/UE Main Functional Protocols Overview
  12. 12. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200512 1.3. UTRAN/UE Main Functional Protocols UE Node B RNC RNC MSC/VLR Server SGSN Iu-CS Iu-PS Uu Iub IubUu Iur RRCRRC RNSAPRNSAP RANAPRANAP RANAPRANAP Iu-CS ALCAPALCAP NBAPNBAP ALCAPALCAP ALCAPALCAP WCDMAWCDMA CS-MGW
  13. 13. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200513 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 real- time 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.
  14. 14. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200514 RNC RNS 1.3. UTRAN/UE Main Functional Protocols UE MSC/VLR Server SGSN MMMM CCCC SSSS SMSSMS GMMGMM SMSM SMSSMS PS dataPS data CS dataCS data CS-MGW NAS Signalling Relay
  15. 15. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200515 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-CP (Short Message Control Protocol), SM-RP (Short Message Relay Protocol), SM-TL (Short Message Transfer Layer) and SM-AL (Short Message Application Layer).
  16. 16. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200516 1. Network Architecture 1.4. UTRAN Protocol Stacks on Iux Interfaces
  17. 17. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200517 1.4. Protocol Stacks on Iux Interfaces – Iu-CS Serving RNC MSC/VLR Server CS-MGW Iu-CS (control plane) Iu-CS (user + transport network control plane) RANAPRANAP ALCAPALCAPSCCPSCCP MTP3BMTP3B SAALSAAL SAALSAAL SAALSAAL ATMATM AAL2AAL2AAL2AAL2. . . . . . PVC PVC PVC PVC PVC MMMM CCCC SSSS SMSSMS Iu UP Iu UP Iu UP Iu UP . . . Iu UP Iu UP Iu UP Iu UP . . . CS call data User PlaneTransport Network Control Plane Control Plane
  18. 18. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200518 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 user data is carried over the Iu UP (Iu User Plane) protocol from RNC to CS-MGW and vice versa. The Iu UP protocol supports 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 SCCP (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.
  19. 19. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200519 1.4. Protocol Stacks on Iux Interfaces – Iu-PS Serving RNC SGSNIu-PS (control plane, user plane) RANAPRANAP SCCPSCCP MTP3BMTP3B SAALSAAL SAALSAAL SAALSAAL ATMATM AAL5AAL5AAL5AAL5. . . . . . PVC PVC PVC PVC PVC GMMGMM SMSM SMSSMS PS call data (PDP Contexts) User PlaneControl Plane IPIP UDPUDP GTP-UGTP-U . . .
  20. 20. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200520 1.4. Protocol Stacks on Iux Interfaces – Iu-PS On Iu-PS user data consists of PDP context packets. PDP context data is transferred over the GTP-U (GPRS Tunnelling Protocol – User 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.
  21. 21. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200521 1.4. Protocol Stacks on Iux Interfaces – Iub RNCNode BUE Uu Iub NBAPNBAP ALCAPALCAP TrCH FP TrCH FP TrCH FP TrCH FP TrCH FP TrCH FP SAALSAAL ATMATM PVC SAALSAAL PVC ... ALCAPALCAP... SAALSAAL PVC SAALSAAL PVC ... AAL2AAL2 PVC AAL2AAL2 PVC ... ... ... Control Plane Transport Network Control Plane User Plane Transport Channel Data
  22. 22. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200522 1.4. Protocol Stacks on Iux Interfaces – Iub On the Iub interface data (user 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.
  23. 23. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200523 1.4. Protocol Stacks on Iux Interfaces – Iur Drift RNCNode BUE Uu Iub RNSAPRNSAP TrCH FP TrCH FP TrCH FP TrCH FP TrCH FP TrCH FP SAALSAAL ATMATM PVC SAALSAAL PVC ALCAPALCAP SAALSAAL PVC ... AAL2AAL2 PVC AAL2AAL2 PVC ... ... ... Control Plane Transport Network Control Plane User Plane Transport Channel Data Serving RNCIur SCCPSCCP MTP3BMTP3B
  24. 24. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200524 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.
  25. 25. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200525 2. Radio Protocol Architecture and Channels
  26. 26. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200526 2. Radio Protocol Architecture and Channels 2.1. Radio Protocol Architecture
  27. 27. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200527 2.1. Radio Protocol Architecture WCDMA Physical Layer (FDD)WCDMA Physical Layer (FDD) #1 #2 #n Medium Access Control (MAC)Medium Access Control (MAC) Transport Channels (TrCH) Physical Channels (PhCH)#1 #k RF #1 #x #y #z RLCRLC RLCRLC... RLCRLC RLCRLC... #y2 RLCRLC BMCBMCPDCPPDCP #1 #x #y #z#y2 RRCRRC ... MMMM GMMGMM SMSM CCCC SSSS SMSSMS NAS Protocols CS App CS App PS PDP Ctx. PS PDP Ctx. CB SMS App CB SMS App #y1 RLCRLC #y1 Logical Channels (LogCH) Radio Bearer (RB) ... ... RAB RAB
  28. 28. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200528 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 user applications all radio bearers of a single application are combined in a radio access bearer (RAB).
  29. 29. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200529 2. Radio Protocol Architecture and Channels 2.2. Logical Channel Types and their Usage
  30. 30. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200530 2.2. Logical Channel Types and their Usage UE Identification in UTRAN Serving RNC Node BUE Uu Iub No UE IdentificationNo UE Identification Layer 1 IdentificationLayer 1 Identification Layer 2 IdentificationLayer 2 Identification Layer 3 IdentificationLayer 3 Identification Case UE Identification in RNC Some information (System Information, CB SMS) does not require a UE identification. UE must have a dedicated physical resource. This resource uniquely identifies the UE for the time the resource is assigned to it. UE uses common resources and identifies itself with a special MAC header identifier (c-RNTI, u-RNTI, dsch- RNTI) on that resource. 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.
  31. 31. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200531 2.2. Logical Channel Types and their Usage BCCHBCCH PCCHPCCH CCCHCCCH DCCHDCCH DTCHDTCH CTCHCTCH Logical Channel Types Control Channels Traffic Channels Broadcast Control Channel [dl, ptm] System Information broadcast; downlink channel; no UE specific information Paging Control Channel [dl, ptm] Point-to-multipoint paging procedure (Paging Type 1) UE identification by RRC message itself Common Control Channel [ul+dl, ptp] Point-to-point RRC signalling on common resource when no MAC identifier available Dedicated Control Channel [ul+dl, ptp] Point-to-point RRC signalling on common or dedic. resource with MAC identifier available (on common resource) Dedicated Traffic Channel [ul|dl|ul+dl, ptp] Point-to-point data (CS data, CS speech, PS data) on common or dedicated resource (requires MAC-ID on common resource). Common Traffic Channel [dl (currently), ptm] Used for cell broadcast SMS. Thus no UE-ID. ptm: point-to-multipoint ptp: point-to-point dl: downlink ul: uplink
  32. 32. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200532 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.
  33. 33. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200533 2. Radio Protocol Architecture and Channels 2.3. Transport Channel Types and their Usage
  34. 34. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200534 2.3. Transport Channel Types and their Usage Node B UE UE WCDMA FDD cell dedicated physical channels common physical channel Dedicated TrCHDedicated TrCH UE Dedicated TrCHDedicated TrCH Dedicated TrCHDedicated TrCH Common TrCHCommon TrCH Common TrCHCommon TrCH Common TrCH • 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] 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
  35. 35. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200535 2.3. Transport Channel Types and their Usage 1 BCHBCH PCHPCH RACHRACH FACHFACH Transport Channel Types Common Channels Broadcast Channel [dl, 1/cell] Carries BCCH. Paging Channel [dl, ≦16/cell] Carries PCCH. Random Access Channel [ul, ≦16/cell] Can carry CCCH, DCCH and DTCH. Minimum SF is 32 and maximum transmission time is 10|20 ms. Forward Access Channel [dl, ≦16/cell] Can carry CCCH, DCCH, DTCH, BCCH and CTCH. Minimum SF is 4. dl: downlink ul: uplink DSCHDSCH CPCHCPCH HS-DSCHHS-DSCH Downlink Shared Channel [dl, ≦?/cell] Common Packet Channel [ul, ≦64/cell] High Speed DSCH [dl, ≦16/cell] 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.
  36. 36. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200536 2.3. Transport Channel Types and their Usage 2 DCHDCH Transport Channel Types Dedicated Channels Dedicated Channel [ul|dl] One DCH can carry one or more DCCH or one DCH can carry one or more DTCH.
  37. 37. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200537 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. • CPCH (Common Packet Channel): The CPCH is working like the RACH, but is used for DCCH and DTCH only. Compared to the RACH the CPCH allows higher bit rates and longer transmission periods – thus a higher throughput can be achieved on CPCH.
  38. 38. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200538 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.
  39. 39. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200539 2. Radio Protocol Architecture and Channels 2.4. Physical Channels and their Usage
  40. 40. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200540 2.4. Physical Channels and their Usage 1 P-SCHP-SCH S-SCHS-SCH P-CPICHP-CPICH Physical Channel Types Synchronisation Channels Primary Synchr. Channel [dl, 1/cell] Transmits Primary Synchr. Code (PSC) to detect cell. Secondary Synchr. Channel [dl, 1/cell] Transmits a Secondary Synchr. Code sequence to identify scrambling code group and radio frame start. Primary Common Pilot CH [dl, 1/cell] Transmits a pre-defined symbol sequence (all –1) with the primary dl scrambling code of the cell. dl: downlink ul: uplink S-CPICHS-CPICH P-CCPCHP-CCPCH Secondary CPICH [dl, 0...15/cell] Primary Common Control Physical Channel [dl, 1/cell] Transmits a pre-defined symbol sequence with one the 15 possible secondary scrambling codes of cell. Carries BCH with BCCH. Always scrambled by primary dl scrambling code of the cell. Measurement Reference Channels System Information Broadcast
  41. 41. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200541 2.4. Physical Channels and their Usage 2 S-CCPCHS-CCPCH PICHPICH PRACHPRACH Physical Channel Types PhCH for FACH and PCH Secondary Common Control Physical Channel [dl, ≦ 16/cell] Carries either 1) FACH only, 2) PCH only or 3) FACH + PCH multiplexed. Paging Indicator Channel [dl, ≦ 16/cell] Contains paging indicators for discontinuous reception (DRX) in association with a PCH. Physical Random Access Channel [ul, ≦ 16/cell] Consists of a preamble part to perform open loop power control and a data part transferring RACH data. dl: downlink ul: uplink AICHAICH Acquisition Indicator Channel [dl, ≦ 16/cell] Associated with a single PRACH. Carries the preamble responses (acquisition indications). PhCH for RACH
  42. 42. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200542 2.4. Physical Channels and their Usage 3 DPCHDPCH DPCCHDPCCH PDSCHPDSCH Physical Channel Types PhCH for DCH Dedicated Physical Channel [dl, dynamical allocation] Carries one or several DCH of a single UE and physical layer information (TPC, pilot bits, TFCI). Data rate ≦1860 kpbs (SF=4). [Physical channel bit rate] Dedicated Physical Ctrl CH [ul, dynamical allocation] [ 1/UE] Carries physical layer information from a single UE to Node B (TPC, pilot bits, TFCI, FBI). SF=256 fix. 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] dl: downlink ul: uplink DPCHDPCH Dedicated Physical Channel [dl, dynamical allocation] A PSDCH must be used by together with DPCH by a UE. The DPCH contains physical layer control bits. PhCH for DSCH DPDCHDPDCH Dedicated Physical Data CH [ul, dynamical allocation] [≦6/UE] Carries one or several DCH of a single UE to Node B. Data rate ≦ 960 kpbs (SF=4). [Physical channel bit rate]
  43. 43. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200543 2.4. Physical Channels and their Usage 4 PCPCHPCPCH AP-AICHAP-AICH CSICHCSICH Physical Channel Types PhCH for CPCH Physical Common Packet Channel [ul] Carries CPCH with DCCH/DTCH of several UE multiplexed by time (asynchronous) and CPCH access preambles, collision detection preambles and power control preambles. Data rate ≦960 kpbs (SF=4) for max. 80 ms. Access Preamble Acquisition Indicator CH [dl] Gives positive or negative acquisition indications to CPCH access preambles for CPCH access preambles. CPCH Status Indicator CH [dl] Gives status indications about availability/non- availability of CPCH resources. dl: downlink ul: uplink CD/CA-ICHCD/CA-ICH Collision Detection/ Channel Assignment Indicator Channel [dl] Gives collision indications or channel assignment indications (code alloc.) for CPCH collision preambles. DPCHDPCH Dedicated Physical CH [dl] Carries physical layer control bits (TPC) used for closed loop power control of PCPCH.
  44. 44. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200544 2.4. Physical Channels and their Usage 5 HS-PDSCHHS-PDSCH HS-SCCHHS-SCCH Physical Channel Types PhCH for HS-DSCH 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-DSCH related Shared Control Channel [dl, ≦4 per HS-DSCH] On this channel the physical layer assigns a UE the HS-PDSCH for the next transmission period. dl: downlink ul: uplink HS-DPCCHHS-DPCCH Dedicated Physical CH [ul, 1 per UE on HS-DSCH] Transmits quality indicator (C/I) and acknowledgements for received data on HS-PDSCH from UE to Node B.
  45. 45. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200545 2. Radio Protocol Architecture and Channels 2.5. Radio Bearers (RB) and Radio Access Bearers (RAB)
  46. 46. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200546 2.5. RB and RAB - Architecture RB 1 R R C RB 2 RB 3 RB 4 R R C A M R RB 5 RB 6 RB 7 RB 8 Rate control Iu UP UE Serving RNC RAB subflow 1 RAB subflow 2 RAB subflow 3 MSC Server CS-MGW Iu UP AMR A B C A B C SGSN PDP Ctx. 1 RB 9 PDP Context 1 RAB (CS) RAB (PS) RAB (PS) PDP Ctx. 2 PDP Context 2
  47. 47. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200547 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 user data applications (CS calls, PDP contexts). But user 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.
  48. 48. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200548 2.5. RB and RAB – RRC Radio Bearer Usage RRCRRC MACMAC PHYPHY MMMM GMMGMM SMSM CCCC SSSS SMSSMS NAS Protocols high priority signalling transfer low priority signalling transfer RB 0 RLC (UL:TM; DL:UM) CCCH RB 1 RLC (UL/DL:UM) DCCH 1 RB 2 RLC (UL/DL:AM) DCCH 2 RB 3 RLC (UL/DL:AM) DCCH 3 RB 4 RLC (UL/DL:AM) DCCH 4 UL-TrCHDL-TrCH
  49. 49. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200549 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).
  50. 50. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200550 2. Radio Protocol Architecture and Channels 2.6. Channel Configuration Scenario
  51. 51. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200551 DL 2.6. Channel Configuration Scenario RB 1 UM DCCH 1 RB 2 AM DCCH 2 RB 3 AM DCCH 3 RB 4 AM DCCH 4 RB 5 TM DTCH 1 RB 6 TM DTCH 2 RB 7 TM DTCH 3 RB 8 TM DCCH 5 RB 9 UM|AM DTCH 5 PDCP RLC RRCRRC MM, GMM, CC, SS, SM, SMSMM, GMM, CC, SS, SM, SMS AMR codecAMR codec PDP Ctx.PDP Ctx. MAC DCH #31 DCH #0 DCH #1 DCH #2 DCH #3 DCH #4 A B C frame header PHY UE with one variable rate AMR CS call, 1 PDP context (active data transfer) DPCH DPCCH DPDCH UL
  52. 52. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200552 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.
  53. 53. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 20051 Module 02 Radio Layer 2 Protocols MAC, RLC, PDCP Version 0.0.1 (10/02/2005) Author: Alexander Seifarth (a.seifarth@techcom.de)
  54. 54. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 20052 1. Transport Channel Configuration
  55. 55. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 20053 1. Transport Channel Configuration 1.1. Transport Formats (TF) and Transport Format Sets (TFS)
  56. 56. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 20054 1.1. TF and TFS – Transport Blocks and Format MACMAC PHYPHY TrCH x Transport Block TB #0 Transport Block TB #1 Transport Block TB #N-1 . . . Transport Block Set TBS Transport Block Set TBS Transport Block Set TBS Transport Block Set TBS time Transmit Time Interval TTI Transmit Time Interval TTI Transport Format (TF) channel coding algorithm CRC size rate matching attribute TTI TB size (no. of bits) TBS size (no. of TB in TBS)
  57. 57. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 20055 1.1. TF and TFS – Transport Format Sets channel coding algorithm CRC size rate matching attribute TTI TFI 0 TB size #0 TBS size #0 TFI 1 TB size #1 TBS size #1 TFI K-1 TB size #K-1 TBS size #K-1 . . . Transport Format Set (TFS) | 1.1.1.1.9 ul-AddReconfTransChInfoList | | 1.1.1.1.9.1 uL-AddReconfTransChInformation | |-----0-- |1.1.1.1.9.1.1 ul-TransportChannelType |dch | |***b5*** |1.1.1.1.9.1.2 transportChannelIdentity |32 | | 1.1.1.1.9.1.3 transportFormatSet | | 1.1.1.1.9.1.3.1 dedicatedTransChTFS | | 1.1.1.1.9.1.3.1.1 tti | | 1.1.1.1.9.1.3.1.1.1 tti40 | | 1.1.1.1.9.1.3.1.1.1.1 dedicatedDynamicTF-Info | | 1.1.1.1.9.1.3.1.1.1.1.1 rlc-Size | | 1.1.1.1.9.1.3.1.1.1.1.1.1 octetModeType1 | |***b5*** |1.1.1.1.9.1.3.1.1.1.1.1.1.1 sizeType1 |16 | | 1.1.1.1.9.1.3.1.1.1.1.2 numberOfTbSizeList | | 1.1.1.1.9.1.3.1.1.1.1.2.1 numberOfTransportBlocks | | |1.1.1.1.9.1.3.1.1.1.1.2.1.1 zero |0 | | 1.1.1.1.9.1.3.1.1.1.1.3 logicalChannelList | | |1.1.1.1.9.1.3.1.1.1.1.3.1 allSizes |0 |
  58. 58. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 20056 1.1. TF and TFS – Transport Format Sets | 1.1.1.1.9.1.3.1.1.1.2 dedicatedDynamicTF-Info | | 1.1.1.1.9.1.3.1.1.1.2.1 rlc-Size | | 1.1.1.1.9.1.3.1.1.1.2.1.1 octetModeType1 | |10000--- |1.1.1.1.9.1.3.1.1.1.2.1.1.1 sizeType1 |16 | | 1.1.1.1.9.1.3.1.1.1.2.2 numberOfTbSizeList | | 1.1.1.1.9.1.3.1.1.1.2.2.1 numberOfTransportBlocks | | |1.1.1.1.9.1.3.1.1.1.2.2.1.1 one |0 | | 1.1.1.1.9.1.3.1.1.1.2.3 logicalChannelList | | |1.1.1.1.9.1.3.1.1.1.2.3.1 allSizes |0 | | 1.1.1.1.9.1.3.1.2 semistaticTF-Information | | 1.1.1.1.9.1.3.1.2.1 channelCodingType | |1------- |1.1.1.1.9.1.3.1.2.1.1 convolutional |third | |***b8*** |1.1.1.1.9.1.3.1.2.2 rateMatchingAttribute |185 | |-011---- |1.1.1.1.9.1.3.1.2.3 crc-Size |crc16 |
  59. 59. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 20057 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.
  60. 60. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 20058 1. Transport Channel Configuration 1.2. Transport Format Combinations TFC
  61. 61. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 20059 TFS (TrCH 1) 1.2. Transport Format Combinations TFC MACMAC PHYPHY TrCH 1 TrCH 2 TFI 0 TFI 1 TFI 2 TFI 0 TFI 1 TFS (TrCH 2) 0 kbps 8 kbps 0 kbps 16 kbps 32 kbps TrCH 1 TrCH 2TFCI Total TrCH Bit Rate TFI 0 TFI 1 TFI 0 TFI 2 TFI 0TFI 0 TFI 1 TFI 0 TFI 1 TFI 2 TFI 1TFI 1 0 1 2 3 blocked blocked 16 kbps 32 kbps 0 kbps 8 kbps 40 kbps 24 kbps
  62. 62. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200510 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 admission control, because in the end effect each TFC is associated with a certain required transmission power.
  63. 63. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200511 2. Medium Access Control MAC
  64. 64. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200512 2. Medium Access Control MAC 2.1. MAC Entities
  65. 65. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200513 2.1. MAC Entities MAC-b NBAP MAC-c/sh MAC-d MAC-b MAC-c/sh MAC-d NBAP MAC-d MAC-hs MAC-hsHS-DSCH DCH RACH, FACH, DSCH, CPCH,PCH BCH UE RNCNode B
  66. 66. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200514 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.
  67. 67. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200515 2. Medium Access Control MAC 2.2. MAC – PDU, LogCH Identification, UE Identification on Layer 2
  68. 68. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200516 2.2. MAC-PDU, UE/LogCH Identification MAC-dMAC-d DCH #N PHYPHY DCH case: DxCH #0 DxCH #1 DxCH #K-1 . . . TB #0 (MAC-PDU #0) TB #1 (MAC-PDU #1) TB #L-1 (MAC-PDU #L-1) . . . Transport Block Set TBS MAC Header MAC-SDU = LogCH Data (RLC PDU) MAC - PDU DxCH – number (if K>1) x = T(raffic) | C(ontrol)
  69. 69. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200517 2.2. MAC-PDU, UE/LogCH Identification MAC-c/shMAC-c/sh RACH | FACH | DSCH | CPCH PHYPHY Common TrCH (RACH, FACH, DSCH, CPCH) case: CCCH BCCH| CTCH DxCH #K-1 . . . TB #0 (MAC-PDU #0) TB #1 (MAC-PDU #1) TB #L-1 (MAC-PDU #L-1) . . . Transport Block Set TBS MAC Header MAC-SDU = LogCH Data (RLC PDU) MAC - PDU DxCH – number (if K>1) x = T(raffic) | C(ontrol) DxCH #0 UE-identifier (for DxCH only) LogCH Type from MAC-d
  70. 70. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200518 2.2. MAC-PDU, UE/LogCH Identification Common TrCH (HS-DSCH) case: MAC-dMAC-d HS-DSCH PHYPHY DxCH #0 DxCH #1 DxCH #K-1 . . . MAC-hsMAC-hs MAC-d Flow DxCH – number (if K>1) LogCH Type MAC Header MAC-SDU = LogCH Data (RLC PDU) MAC-d - PDU MAC-d PDU #0 MAC-d PDU #M-1 . . .MAC-hs Header MAC-hs PDU
  71. 71. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200519 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 CPCH 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 MAC- d 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 user 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.
  72. 72. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200520 2.2. MAC-PDU, UE/LogCH Identification • MAC-PDU (non HS-DSCH) TCTF UE-ID Type UE-ID C/T MAC Header RLC PDU (LogCH Data) • MAC-d PDU (for HS-DSCH) C/T MAC Header RLC PDU (LogCH Data) MAC SDU MAC SDU • MAC PDU (HS-DSCH) MAC-hs Header MAC Header MAC-hs SDUs MAC-d PDU #0 MAC-d PDU #1 MAC-d PDU #N-1 . . . Version Flag Queue ID Seq.No. TSN Size Index Id. #0 No. MAC-d PDUs #0 Flag #0 Size Index Id. #Y No. MAC-d PDUs #Y Flag #Y. . .
  73. 73. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200521 2.2. MAC-PDU, UE/LogCH Identification UE U-RNTI (32 bit)U-RNTI (32 bit) MAC header UE identifier C-RNTI (16 bit)C-RNTI (16 bit) DSCH-RNTI (16 bit)DSCH-RNTI (16 bit) RNC MAC PDU -- (no MAC UE ID)-- (no MAC UE ID) • UE uses CCCH/PCCH/BCCH/CTCH or DCH/HS-DSCH • UE uses DCCH/DTCH on RACH/FACH in a new cell • UE uses DCCH/DTCH on RACH/FACH/ CPCH (not after cell change) • UE uses DCCH/DTCH on DSCH = S-RNC-ID + S-RNTI
  74. 74. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200522 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 re- transmission. • 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.
  75. 75. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200523 2.2. MAC-PDU, UE/LogCH Identification | 2.2 FP: Transport Block | |0011---- |2.2.1 MAC: C/T Field |Logical Channel 4 | | |2.2.2 MAC: Target Channel Type |DCCH (Dedicated Control Channel) | | |2.2.3 MAC: RLC Mode |Acknowledge Mode | |----0--- |2.2.4 RLC: Data/Control |Control PDU | |-----000 |2.2.5 RLC: PDU Type |STATUS | | |2.2.6 RLC: Acknowledgement Super Field | |0010---- |2.2.6.1 RLC: SUFI Type |Acknowledgement | |**b12*** |2.2.6.2 RLC: Last Sequence Number |2 | | |2.2.7 RLC: Padding | |**b124** |2.2.7.1 RLC: Padding |'000000000000000000000000000000000'B | | | |'000000000000000000000000000000000'B | | | |'000000000000000000000000000000000'B | | | |'0000000000000000000000000'B | • Example: MAC-PDU (Transport Block) DCCH on DCH
  76. 76. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200524 2.2. MAC-PDU, UE/LogCH Identification | 2 FP: Transport Block | |01------ | 2.1 MAC: Target Channel Type Field |DTCH/DCCH (Dedicated Traffic/Cont... | |--01---- | 2.2 MAC: UE-ID Type |C-RNTI (Cell Radio Network Tempor... | |**b16*** | 2.3 MAC: UE-ID |0 | |----0010 | 2.4 MAC: C/T Field |Logical Channel 3 | | | 2.5 MAC: RLC Mode |Acknowledge Mode | |1------- | 2.6 RLC: Data/Control |Acknowledged mode data PDU | |**b12*** | 2.7 RLC: Sequence Number |1 | |-----1-- | 2.8 RLC: Polling Bit |Request a status report | |------01 | 2.9 RLC: Header extension type |Octet contains LI and E bit | |0001010- | 2.10 RLC: Length Indicator |10 | |-------1 | 2.11 RLC: Extension Bit |The next field is LI and E bit | |1111111- | 2.12 RLC: Length Indicator |Rest is padding | |-------0 | 2.13 RLC: Extension Bit |The next field is data | |**B10*** | 2.14 RLC: Last Data Segment |94 02 08 00 18 00 11 88 10 00 | |***B4*** | 2.15 RLC: Padding |00 00 00 00 | • Example: MAC-PDU (Transport Block) DCCH on FACH
  77. 77. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200525 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.
  78. 78. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200526 2. Medium Access Control MAC 2.3. RACH Access Control
  79. 79. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200527 2.3. RACH Access Control – Basic Procedure 1(3) UE RNCNode B Uu Iub MAC PHY PHY MAC Acess.Request[PHY] R=random (0≤R<1) IF (R ≤ P) TRUE Wait 10 ms FALSE START P = Persistence Value (SIB 7) M = Preamble Cycle Counter (UE counter) AccessPreamblePHY:PRACH AccessPreamblePHY:PRACH AccessPreamblePHY:PRACH . . . 1st Preamble Cycle Case: No acquisition indication 1) maximum no. of preambles 2) maximum power on PRACH NoAck.Indication[PHY] M= 1
  80. 80. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200528 2.3. RACH Access Control – Basic Procedure 2(3) UE RNCNode B Uu Iub MAC PHY PHY MAC Acess.Request[PHY] AccessPreamblePHY:PRACH AccessPreamblePHY:PRACH AI = -1PHY:AICH 2nd Preamble Cycle Case: Negative acquisition indication NAck.Indication[PHY] R=random (0≤R<1) IF (R ≤ P) TRUE Wait 10 ms FALSE M:=M+1 Wait 10 ms
  81. 81. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200529 2.3. RACH Access Control – Basic Procedure 3(3) UE RNCNode B Uu Iub MAC PHY PHY MAC Acess.Request[PHY] AccessPreamblePHY:PRACH AI = +1PHY:AICH 3rd Preamble Cycle Case: Positive acquisition indication Ack.Indication[PHY] R=random (0≤R<1) IF (R ≤ P) TRUE Wait 10 ms FALSE M:=M+1 NBO1=random {0 ≤ NBO1min ≤ NBO1 ≤ NBO1max } Wait TBO1 (= NBO1 x 10 ms) Wait 10 ms NBO1min = minimum value for backoff timer 1 (SIB) NBO1max = maximum value for backoff timer 1 (SIB) Data.Request[PHY] RACH DataPHY:PRACH RACH DATARACH-FP
  82. 82. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200530 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.
  83. 83. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200531 3. Radio Link Control (RLC) Protocol
  84. 84. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200532 3. Radio Link Control (RLC) Protocol 3.1. RLC Modes of Operation
  85. 85. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200533 3.1. RLC Modes of Operation Transparent Mode TM Transparent Mode TM Unacknowledged Mode UM Unacknowledged Mode UM Acknowledged Mode AM Acknowledged Mode AM RLC ModesRLC Modes • no sequence number check • no acknowledgements • no retransmission • segmentation/reassembly may be used or not used • no RLC overhead • sequence number check • no acknowledgements • no retransmission • segmentation/reassembly is done in RLC • sequence number and length indicators included in RLC frame • 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 RLC SDU (Data) cipher unit MAC Header RLC SDU (Data) cipher unit RLC Seq. No. Length Indicators MAC Header RLC SDU (Data or Ctrl) cipher unit RLC Seq. No. Length Indicators
  86. 86. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200534 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 assigning 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.
  87. 87. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200535 3.1. RLC Modes of Operation PCCH BCCH CCCH-UL DCCH DTCH CTCH TM TM TM CCCH-DL UM TM UM AM TM UM AM UM RLC ModesLogCH Type
  88. 88. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200536 3. Radio Link Control (RLC) Protocol 3.2. Segmentation/Reassembly Function
  89. 89. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200537 3.2. Segmentation/Reassembly Function MACMAC RLCRLC Layer 3 (RRC, applic.)Layer 3 (RRC, applic.) PHYPHY RLC SDU #0 RLC SDU #1 #0.0 #0.1 #1.0 #1.1 padding RLC header RLC header RLC header RLC PDU #0 RLC PDU #1 RLC PDU #2 MAC header #0.0 RLC header Transport Block Set MAC header #0.1 RLC header #1.0 MAC header #1.1 RLC header padding
  90. 90. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200538 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.
  91. 91. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200539 3. Radio Link Control (RLC) Protocol 3.3. RLC Transparent Mode Procedures
  92. 92. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200540 3.3. RLC Transparent Mode Procedures UE RNC TMD PDURLC RLC SDU segments TMD PDURLC RLC SDU segments . . . IF all segments of a SDU received reassembly TMD PDURLC RLC SDU segments TMD PDURLC RLC SDU segments . . . IF all segments of a SDU received reassembly
  93. 93. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200541 3.3. RLC Transparent Mode Procedures | 2 FP: Transport Block | |00------ |2.1 MAC: Target Channel Type Field |CCCH (Common Control Channel) | | |2.2 MAC: RLC Mode |Transparent Mode | |**b166** |2.3 RLC: Whole Data |'001000010000011101000000001000011'B | | | |'010000000100110001000000001000000'B | | | |'111110100110110000000000000000000'B | | | |'000000000000000000000000000000000'B | | | |'000000000000000000000000000000000'B | | | |'0'B | segmented SDU data RLC Transparent Mode DATA
  94. 94. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200542 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.
  95. 95. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200543 3. Radio Link Control (RLC) Protocol 3.4. Unacknowledged Mode Procedures
  96. 96. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200544 3.4. Unacknowledged Mode Procedures UE RNC UMD PDURLC Sequence No. = 2, Length Indicators, RLC SDU segments UMD PDURLC Sequence No. = 8, Length Indicators, RLC SDU segments . . . IF all segments of a SDU received reassembly UMD PDURLC Sequence No. = 43, Length Indicators, RLC SDU segments UMD PDURLC Sequence No. = 47, Length Indicators, RLC SDU segments . . . IF all segments of a SDU received reassembly
  97. 97. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200545 3.4. Unacknowledged Mode Procedures | 2 FP: Transport Block | |01000000 |2.1 MAC: Target Channel Type Field |CCCH (Common Control Channel) | | |2.2 MAC: RLC Mode |Unacknowledge Mode | |0101010- |2.3 RLC: Sequence Number |42 | |-------1 |2.4 RLC: Extension Bit |The next field is LI and E bit | |1111100- |2.5 RLC: Length Indicator |Start with new SDU | |-------0 |2.6 RLC: Extension Bit |The next field is data | |**B18*** |2.7 RLC: First Data Segment |30 f7 36 c0 00 04 24 c4 02 00 18... | | 3 FP: Transport Block | |01000000 |3.1 MAC: Target Channel Type Field |CCCH (Common Control Channel) | | |3.2 MAC: RLC Mode |Unacknowledge Mode | |0101011- |3.3 RLC: Sequence Number |43 | |-------0 |3.4 RLC: Extension Bit |The next field is data | |**B19*** |3.5 RLC: Data Segment |49 d3 e2 84 f8 ea 30 00 14 61 67... | | 2 FP: Transport Block | |01000000 |2.1 MAC: Target Channel Type Field |CCCH (Common Control Channel) | | |2.2 MAC: RLC Mode |Unacknowledge Mode | |0101100- |2.3 RLC: Sequence Number |44 | |-------0 |2.4 RLC: Extension Bit |The next field is data | |**B19*** |2.5 RLC: Data Segment |92 13 e5 a9 40 00 52 8a 13 a7 cd... | | 3 FP: Transport Block | |01000000 |3.1 MAC: Target Channel Type Field |CCCH (Common Control Channel) | | |3.2 MAC: RLC Mode |Unacknowledge Mode | |0101101- |3.3 RLC: Sequence Number |45 | |-------0 |3.4 RLC: Extension Bit |The next field is data | |**B19*** |3.5 RLC: Data Segment |d3 e8 84 fa 6a 90 00 15 08 00 06... |
  98. 98. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200546 3.4. Unacknowledged Mode Procedures | 2 FP: Transport Block | |01000000 |2.1 MAC: Target Channel Type Field |CCCH (Common Control Channel) | | |2.2 MAC: RLC Mode |Unacknowledge Mode | |0101110- |2.3 RLC: Sequence Number |46 | |-------0 |2.4 RLC: Extension Bit |The next field is data | |**B19*** |2.5 RLC: Data Segment |04 80 11 dc 32 00 01 04 13 f7 eb... | | 3 FP: Transport Block | |01000000 |3.1 MAC: Target Channel Type Field |CCCH (Common Control Channel) | | |3.2 MAC: RLC Mode |Unacknowledge Mode | |0101111- |3.3 RLC: Sequence Number |47 | |-------1 |3.4 RLC: Extension Bit |The next field is LI and E bit | |0001110- |3.5 RLC: Length Indicator |14 | |-------1 |3.6 RLC: Extension Bit |The next field is LI and E bit | |1111111- |3.7 RLC: Length Indicator |Rest is padding | |-------0 |3.8 RLC: Extension Bit |The next field is data | |**B14*** |3.9 RLC: Last Data Segment |ba dd fc 80 64 53 ca 08 00 40 8c... | |***B3*** |3.10 RLC: Padding |00 00 00 |
  99. 99. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200547 3.4. Unacknowledged Mode Procedures Sequence Number E • UMD PDU (7-bit Length Indicators) LI0 E LIN-1 E=0 . . . segmented RLC SDU padding Sequence Number E • UMD PDU (15-bit Length Indicators) LI0 (low part) E LIN-1 E=0 . . . segmented RLC SDU padding LI0 (high part) LIN-1 (high part)
  100. 100. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200548 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.
  101. 101. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200549 3. Radio Link Control (RLC) Protocol 3.5. Acknowledged Mode Procedures
  102. 102. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200550 3.5. Acknowledged Mode Procedures UE RNC RESET PDURLC Reset Sequence Number, Hyper Frame Number uplink (HFNI) RESET ACK PDURLC Reset Reset Sequence Number, Hyper Frame Number downlink (HFNI) RESET PDURLC Reset Sequence Number, Hyper Frame Number downlink (HFNI) RESET ACK PDURLC Reset Sequence Number, Hyper Frame Number uplink (HFNI)
  103. 103. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200551 3.5. Acknowledged Mode Procedures UE RNC AMD PDURLC Sequence No. = 12, Poll Bit P, Length Indicators, RLC SDU segments AMD PDURLC . . . Data Transfer with Solitary STATUS PDU Sequence No. = 18, Poll Bit P, Length Indicators, RLC SDU segments STATUS PDURLC Acknowledgement super fields (SUFI): ACK, BITMAP, LIST, RLIST AMD PDURLC Sequence No. = 12, Poll Bit P, Length Indicators, RLC SDU segments AMD PDURLC . . . Sequence No. = 18, Poll Bit P, Length Indicators, RLC SDU segments STATUS PDURLC Acknowledgement super fields (SUFI): ACK, BITMAP, LIST, RLIST
  104. 104. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200552 3.5. Acknowledged Mode Procedures UE RNC AMD PDURLC Sequence No. = 12, Poll Bit P, Length Indicators, RLC SDU segments AMD PDURLC . . . Data Transfer with Piggybacked STATUS PDU Sequence No. = 18, Poll Bit P, Length Indicators, RLC SDU segments AMD PDURLC Sequence No. = 34, Poll Bit P, Length Indicators, RLC SDU Segments, Piggybacked STATUS PDU = {Acknowledgement super fields (SUFI): ACK, BITMAP, LIST, RLIST} AMD PDURLC Sequence No. = 12, Poll Bit P, Length Indicators, RLC SDU segments AMD PDURLC . . . Sequence No. = 28, Poll Bit P, Length Indicators, RLC SDU segments AMD PDURLC Sequence No. = 39, Poll Bit P, Length Indicators, RLC SDU Segments, Piggybacked STATUS PDU = {Acknowledgement super fields (SUFI): ACK, BITMAP, LIST, RLIST}
  105. 105. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200553 3.5. Acknowledged Mode Procedures Move Receiving Window ProcedureUE RNC STATUS PDURLC Move Receiving Window (MRW) super field: SN1,...SNK STATUS PDURLC Move Receiving Window Ack (MRWACK) super field STATUS PDURLC Move Receiving Window (MRW) super field: SN1,...SNK STATUS PDURLC Move Receiving Window Ack (MRWACK) super field
  106. 106. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200554 3.5. Acknowledged Mode Procedures Windowsize ConfigurationUE RNC STATUS PDURLC Window (WINDOW) super field: window size STATUS PDURLC Window (WINDOW) super field: window size
  107. 107. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200555 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.
  108. 108. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200556 3.5. Acknowledged Mode Procedures | 2.2 FP: Transport Block | |0010---- |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 | |----1--- |2.2.4 RLC: Data/Control |Acknowledged mode data PDU | |**b12*** |2.2.5 RLC: Sequence Number |2 | |-1------ |2.2.6 RLC: Polling Bit |Request a status report | |--01---- |2.2.7 RLC: Header extension type |Octet contains LI and E bit | |***b7*** |2.2.8 RLC: Length Indicator |9 | |---1---- |2.2.9 RLC: Extension Bit |The next field is LI and E bit | |***b7*** |2.2.10 RLC: Length Indicator |Rest is padding | |---0---- |2.2.11 RLC: Extension Bit |The next field is data | |**b72*** |2.2.12 RLC: Last Data Segment |df d9 4c ed 0d 21 31 f1 10 | |**b40*** |2.2.13 RLC: Padding |00 00 00 00 00 | | 2.2 FP: Transport Block | |0010---- |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 | |----0--- |2.2.4 RLC: Data/Control |Control PDU | |-----000 |2.2.5 RLC: PDU Type |STATUS | | |2.2.6 RLC: Acknowledgement Super Field | |0010---- |2.2.6.1 RLC: SUFI Type |Acknowledgement | |**b12*** |2.2.6.2 RLC: Last Sequence Number |3 | | |2.2.7 RLC: Padding | |**b124** |2.2.7.1 RLC: Padding |'000000000000000000000000000000000'B | | | |'000000000000000000000000000000000'B | | | |'000000000000000000000000000000000'B | | | |'0000000000000000000000000'B |
  109. 109. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200557 3.5. Acknowledged Mode Procedures Sequence Number (high part) D/C (1) • AMD PDU (7-bit Length Indicators) LI0 E LIN-1 E=0 . . . segmented RLC SDU Padding| piggybacked STATUS PDU • AMD PDU (15-bit Length Indicators) LI0 (low part) E LIN-1 E=0 . . . segmented RLC SDU padding LI0 (high part) LIN-1 (high part) HEPSeq.Number (low part) Sequence Number (high part) D/C (1) HEPSeq.Number (low part)
  110. 110. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200558 3.5. Acknowledged Mode Procedures D/C (0) • RESET/RESET ACK PDU HFNI HFNI padding padding PDU TYPE 0 0 1 / 0 1 0 RSN reserved HFNI D/C (0) • STATUS PDU PDU TYPE 0 0 0 SUFI #1 SUFI #1 . . . SUFI #N padding Note: In case of a piggybacked STATUS PDU the D/C bit is reserved.
  111. 111. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200559 3.5. Acknowledged Mode Procedures Super Fields (SUFI) 0 0 0 0 NO_MORE 0 0 1 0 ACK LSN high LSN low 0 0 0 1 WINDOW WSN high WSN low 0 0 1 1 LIST LENGTH SN1 high SN1 low L1 . . . SNLENGTH high SNLENGTH low LLENGTH 0 1 0 0 BITMAP LENGTH FSN high FSN low BITMAP . . . BITMAP Padding 0 1 0 1 RLIST LENGTH FSN high FSN low CW1 . . . CWLENGTH padding 0 1 1 0 MRW LENGTH SN1 high SN1 low . . . SNLENGTH high SNLENGTH low NLENGTH SN2 high SN2 high 0 1 1 1 MRW_ACK SNACK low NLENGTH SNACK high Padding
  112. 112. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200560 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.
  113. 113. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 20051 Module 03 Radio Resource Control Signalling (RRC) Version 0.0.1 (21/03/2005) Author: Alexander Seifarth (a.seifarth@techcom.de)
  114. 114. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 20052 1. System Information
  115. 115. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 20053 1. System Information 1.1. System Information Blocks and Segmentation
  116. 116. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 20054 1.1. System Information Blocks and Segments UE RNC SystemInformation (SI)[BCH:BCCH] RRC 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 } first segment subsequent segment subsequent segment last segment System Information Block (SIB): . . .
  117. 117. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 20055 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.
  118. 118. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 20056 1. System Information 1.2. Master and Scheduling Information Blocks
  119. 119. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 20057 1.1. Master and Scheduling Information Blocks UE RNC MasterInformationBlock (MIB)[BCH:BCCH] RRC MIB value tag, supported 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 } MasterInformationBlock (MIB)[BCH:BCCH] RRC 80 ms MIB value tag, supported 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 } MasterInformationBlock (MIB)[BCH:BCCH] RRC 80 ms MIB value tag, supported 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 } Master Information Block (MIB)
  120. 120. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 20058 1.1. Master and Scheduling Information Blocks UE RNC SchedulingInformationBlock1/2[BCH:BCCH] RRC references to other system information blocks = { SIB Type, value tag, scheduling } [BCH:BCCH] RRC repetition rate given in MIB references to other system information blocks = { SIB Type, value tag, scheduling } [BCH:BCCH] RRC Scheduling Information Block (SchIB1/2) SchedulingInformationBlock1/2 repetition rate given in MIB references to other system information blocks = { SIB Type, value tag, scheduling } SchedulingInformationBlock1/2
  121. 121. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 20059 1.1. Master and Scheduling Information Blocks | |masterInfoBlock (= masterInfoBlock) | | |sib_description | | |1 sib_choice | | |1.1 masterInfoBlock | |-001---- |1.1.1 mib-ValueTag |2 | | |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 | |***b4*** |1.1.2.1.1.1.1 digit |2 | |--0110-- |1.1.2.1.1.1.2 digit |6 | |***b4*** |1.1.2.1.1.1.3 digit |2 | | |1.1.2.1.1.2 mnc | |---0000- |1.1.2.1.1.2.1 digit |0 | |***b4*** |1.1.2.1.1.2.2 digit |9 | | |1.1.3 sibSb-ReferenceList | | |1.1.3.1 schedulingInformationSIBSb | | |1.1.3.1.1 sibSb-Type | |***b8*** |1.1.3.1.1.1 sysInfoType1 |44 | | |1.1.3.1.2 scheduling | | |1.1.3.1.2.1 scheduling | | |1.1.3.1.2.1.1 segCount |1 | | |1.1.3.1.2.1.2 sib-Pos | |***b6*** |1.1.3.1.2.1.2.1 rep128 |6 | | |1.1.3.2 schedulingInformationSIBSb | | |1.1.3.2.1 sibSb-Type | |------01 |1.1.3.2.1.1 sysInfoType2 |2 | ... Master Information Block MIB
  122. 122. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200510 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.
  123. 123. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200511 1. System Information 1.3. System Information Blocks (SIB)
  124. 124. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200512 1.3. System Information Blocks (SIB) UE RNC SIBx[BCH:BCCH] RRC SIBx data [BCH:BCCH] RRC repetition rate given in MIB SIBx data [BCH:BCCH] RRC SIBx repetition rate given in MIB SIBx data SIBx General System Information Transmission
  125. 125. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200513 1.3. System Information Blocks (SIB) UE RNC SIB1[BCH:BCCH] RRC 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 SIB2[BCH:BCCH] RRC URA-ID list = URA#1,.., URA#<maxURA> SIB3[BCH:BCCH] RRC SIB4 indicator = true|false, cell identity, cell selection and re-selection info, cell access restriction SIB4[BCH:BCCH] RRC cell identity, cell selection and re-selection info, cell access restriction
  126. 126. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200514 1.3. System Information Blocks (SIB) UE RNC SIB5[BCH:BCCH] RRC SIB6 indicator = true|false, PICH power offset, AICH power offset, secondary CCPCH system info, primary CCPCH info = Tx diversity indicator, PRACH system information list, CBS DRX level 1 information SIB6[BCH:BCCH] RRC PICH power offset, AICH power offset, secondary CCPCH system info, CBS DRX level 1 information, primary CCPCH info = Tx diversity indicator, PRACH system information list SIB7[BCH:BCCH] RRC UL interference, dynamic persistence level for PRACH in SIB5/6, expiration time factor SIB8[BCH:BCCH] RRC CPCH parameters (UE access parameters), CSICH power offset, CPCH set info (code and resource info) SIB9[BCH:BCCH] RRC CPCH persistence levels
  127. 127. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200515 1.3. System Information Blocks (SIB) UE RNC SIB10[BCH:BCCH] RRC DRAC (dynamic resource allocation) system information SIB11[BCH:BCCH] RRC 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} SIB12[BCH:BCCH] RRC 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} SIB13|SIB13.1|SIB13.2|SIB13.3|SIB13.4[BCH:BCCH] RRC ANSI-41 CN information
  128. 128. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200516 1.3. System Information Blocks (SIB) UE RNC SIB14[BCH:BCCH] RRC 3.84 Mcps TDD mode system information SIB15|SIB15.1|SIB15.2|SIB15.3|SIB15.4|SIB15.5[BCH:BCCH] RRC system information for UE positioning SIB16[BCH:BCCH] RRC pre-defined RB/TrCH/PhCH configuration for inter-system handover to UTRAN SIB17[BCH:BCCH] RRC 3.84 Mcps TDD|1.28 Mcps TDD mode system information SIB18[BCH:BCCH] RRC PLMN identities for neighbour cells for idle|connected mode UE
  129. 129. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200517 1.3. System Information Blocks (SIB) | |sibType1 (= sibType1) | | |sib_description | | |1 sib_choice | | |1.1 sibType1 | |**b16*** |1.1.1 cn-CommonGSM-MAP-NAS-SysInfo |00 18 | | |1.1.2 cn-DomainSysInfoList | | |1.1.2.1 cN-DomainSysInfo | |0------- |1.1.2.1.1 cn-DomainIdentity |cs-domain | | |1.1.2.1.2 cn-Type | |**b16*** |1.1.2.1.2.1 gsm-MAP |01 01 | |-----01- |1.1.2.1.3 cn-DRX-CycleLengthCoeff |7 | | |1.1.2.2 cN-DomainSysInfo | |-------1 |1.1.2.2.1 cn-DomainIdentity |ps-domain | | |1.1.2.2.2 cn-Type | |**b16*** |1.1.2.2.2.1 gsm-MAP |08 01 | |----01-- |1.1.2.2.3 cn-DRX-CycleLengthCoeff |7 | | |1.1.3 ue-ConnTimersAndConstants | |----1010 |1.1.3.1 t-301 |ms2000 | |010----- |1.1.3.2 n-301 |2 | |---1100- |1.1.3.3 t-302 |ms4000 | ... |--001--- |1.1.3.22 t-317 |s10 | | |1.1.4 ue-IdleTimersAndConstants | |***b4*** |1.1.4.1 t-300 |ms1000 | |-011---- |1.1.4.2 n-300 |3 | |----1010 |1.1.4.3 t-312 |10 | |000----- |1.1.4.4 n-312 |s1 | System Information Block SIB1
  130. 130. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200518 2. RRC Connection Handling 2.1. RRC States
  131. 131. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200519 2.1. RRC States CELL_DCHCELL_DCH CELL_FACHCELL_FACH URA_PCHURA_PCH CELL_PCHCELL_PCH UTRA IDLEUTRA IDLE
  132. 132. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200520 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 CPCH 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.
  133. 133. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200521 2.1. RRC States – Cell Reselection in CELL_FACH UE RNC TMD Cell Update[RACH:CCCH] RLC/RRC U-RNTI, STARTCS, STARTPS, cell update cause = cell re-selection , measured results on RACH, … CELL_FACH automatic cell reselection UMD Cell Update Confirm[FACH:CCCH] RLC/RRC 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 . . .
  134. 134. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200522 2.1. RRC States – Cell Reselection in CELL_PCH UE RNC TMD Cell Update[RACH:CCCH] RLC/RRC U-RNTI, STARTCS, STARTPS, cell update cause = cell re-selection , measured results on RACH, … CELL_PCH automatic cell reselection UMD Cell Update Confirm[FACH:CCCH] RLC/RRC 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 . . . CELL_FACH
  135. 135. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200523 2.1. RRC States –URA Reselection in URA_PCH UE RNC TMD URA Update[RACH:CCCH] RLC/RRC U-RNTI, STARTCS, STARTPS, URA update cause = URA re-selection URA_PCH automatic cell reselection UMD URA Update Confirm[FACH:CCCH] RLC/RRC 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 . . . CELL_FACH (new cell is not part of old URA) false URA_PCH true
  136. 136. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200524 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.
  137. 137. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200525 2. RRC Connection Handling 2.2. RRC Connection Establishment
  138. 138. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200526 2.2. RRC Connection Estab. - CELL_FACH UE RNC TMD RRC Connection Request[RACH:CCCH] RLC/RRC pre-defined configuration status indicator = true|false, Initial UE ID, establishment cause, measured result on RACH UTRA IDLE NAS Trigger UMD RRC Connection Setup[FACH:CCCH] RLC/RRC 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 CELL_FACH UTRA IDLE CELL_FACH • TMSI + LAI • PTMSI + RAI • IMSI • IMEI • 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 AMD RRC Connection Setup Complete[RACH:DCCH] RLC/RRC STARTCS, STARTPS, UE radio access capability, inter-RAT UE radio access capability STATUS[RACH:DCCH] RLC/- Acknowledgement
  139. 139. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200527 2.2. RRC Connection Est. – CELL_FACH +--------+--------------------+------------+------------+------------+-------------------------------------+ |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 | RRC Connection Establishment CELL_FACH (short trace)
  140. 140. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200528 2.2. RRC Connection Est. – CELL_FACH |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 | RRC Connection Request
  141. 141. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200529 2.2. RRC Connection Est. – CELL_FACH |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 | RRC Connection Setup 1( )
  142. 142. Alexander SeifarthCONFIDENTIAL - DRAFTJune 1, 200530 2.2. RRC Connection Est. – CELL_FACH | |1.1.1.1.7 capabilityUpdateRequirement | |1------- |1.1.1.1.7.1 ue-RadioCapabilityFDDUpdateRequ.. |1 | |-0------ |1.1.1.1.7.2 ue-RadioCapabilityTDDUpdateRequ.. |0 | | |1.1.1.1.7.3 systemSpecificCapUpdateReqList | | |1.1.1.1.7.3.1 systemSpecificCapUpdateReq |gsm | | |1.1.1.1.8 srb-InformationSetupList | | |1.1.1.1.8.1 sRB-InformationSetup | |00000--- |1.1.1.1.8.1.1 rb-Identity |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 |0 | |***b4*** |1.1.1.1.8.1.3.2.1.1.2 logicalChannelIdentity |2 | ... | |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 |0 | |***b4*** |1.1.1.1.8.1.3.2.2.1.2 logicalChannelIdentity |2 | RRC Connection Setup 2( )

×