Data Communication Protocols

Data Communication Protocols
UTRA Data Communication Protocols Description September 18 Raul Bruzzone

Contents Introduction Review of Data Communication Concepts
Protocol Architecture Overview Layer 1: Services and Functions Medium Access Control Sub-layer: Services and Functions Radio Link Control Sub-layer: Services and Functions Radio Resource Control Layer: Services and Functions Conclusions References September 18 Raul Bruzzone

Introduction September 18 Raul Bruzzone

UTRA Data Communication Protocols
The set of rules that different machines of a Communication System must follow in order to transport data is called a Protocol. This presentation introduces the Protocols that have been designed for the radio-dependent part of UMTS, called UMTS Radio Access Network (UTRA). These protocols cover the three lower layers of the OSI/ISO model. Their functionality is distributed in the User Equipment (UE) and Fixed Radio Network. September 18 L2_1

Review of DATA COMMUNICATION Concepts
September 18 Raul Bruzzone

Data Communication Service Concept
A Service represents a set of functions offered to a User by a Provider : Service User Provider Access Points In a data communication service, several entities are always present: Two or more Service Users If there are only 2 users, the service is called “Point-to-Point”. If one users sends the same message to several users, it is called “Point-to-Multi-point”. If several users are able to send messages to other set of users, it is called “Multi-point to Multi-Point”. One Service Provider It is a physical or logical entity that transport the message. Example Service users may be the MAC layers of UE and UTRAN. The Service Provider is Layer 1 (the Physical Layer). September 18 L2_2

Layering Concept When the Data Communication process requires a relatively complex processing, the total activity is split in several parts called Layers. N-Service User N-Service User Layer N+1 N- Service Access Points N-Service Entity N-Service Entity Layer N (N-1) - Service Access Points Data communication processes are quite complex, involving several functions that are applied on the data transmitted and received. In order to make the software development a manageable task, the complex process is divided in several stages, called “layers”. Division in layers also facilitates the revision of the standard: if a layer must be changed or enhanced, the other layers remain unchanged. (N-1) - Service Provider September 18 L2_2

Data Communication Protocols
Service Entities located in the same layer communicate between them following a set of rules called Protocol. N-Service User N-Service User Layer N+1 N-Layer Protocol N-Service Entity N-Service Entity Layer N Layers of the same hierarchy exchange data following a standardised set of rules. This set of rules is called a “protocol”. (N-1) - Service Provider September 18 L2_2

Confirmed Data Communication Service
A Data Communication Service involves two participants: The User asking for the service: The Requesting User The User that is informed about the service request: The Accepting User A Confirmed Service is one that involves a Handshake between the Requesting User and the Accepting User. Professional data communication normally implies reliability. This requirement is accomplished by means of an acknowledged communication method, in which the recipient sends back a confirmation message to the sender. This is the so-called Confirmed Service. September 18 L2_2

Service Primitives A Confirmed Service requires the exchange of several messages between the participating entities. Each message is called a Service Primitive. The following slides will show how these Primitives are exchanged. Messages exchanged between consecutive layers receive the name of “Primitives”. A data communication protocol involves several primitives. As an example, we will examine in the following slides the exchange of primitives required for a Confirmed Data Communication Service. September 18 L2_2

Confirmed Service Scenario
SAP SAP Requesting User Accepting User Requesting User Accepting User Service Provider This slide shows from 2 different perspectives, a Confirmed Service data communication between a Requesting User and an Accepting User. At the left of the slide, a block diagram is depicted. At the right, a flow diagram is shown. In this diagram, primitives will be represented by arrows. The time flow goes from top to down. The next slides show the different phases of this service. September 18 L2_2

1. Service Request SAP SAP Service Provider Requesting User Accepting
In the first phase, the Requesting User sends a service.REQUEST primitive to the Service Provider entity. September 18 L2_2

2. Service Indication SAP SAP Service Provider Requesting User
Accepting User service.REQUEST Requesting User Accepting User service.INDICATION Service Provider In a second stage, the Service Provider entity transmit the information through its own medium (e.g. if the Service Provider is the UTRA layer 1, the medium are the radio electromagnetic waves). Once the data are received at the other side of the Service Provider link, a primitive is issued to the Accepting User: service.INDICATION September 18 L2_2

3. Service Response SAP SAP Service Provider Requesting User Accepting
service.REQUEST Requesting User Accepting User service.INDICATION service.RESPONSE Service Provider In a Confirmed Service, the data communication is not finished when the Accepting User receives the information: it is required that it sends a message to the Requesting User acknowledging the reception. In order to do that, the Accepting User issues to the Service Provider the following primitive: service. RESPONSE This primitive contains a confirmation message that flows in the reverse direction of the original data. September 18 L2_2

4. Service Confirmation SAP SAP Service Provider Requesting User
Accepting User service.REQUEST Requesting User Accepting User service.INDICATION service.RESPONSE Service Provider The Service Provider transports in its medium the confirmation to the originating entity. It then issues to the Requesting User the following primitive: service.RESPONSE When the Requesting User receives this primitive, it can confirm that the original message has reached the intended Accepting User. It is interesting to observe that the Confirmed Service requires that the Service Provider have a bi-directional data communication capacity. For example, this kind of message is not possible in normal broadcast radio. service.CONFIRMATION September 18 L2_2

Data Transfer by Encapsulation (I)
Consider that a Service Provider is asked to transfer some data to the Remote Service User. User-data are termed a Service Data Unit (SDU). The Service Provider adds a small header to the user-data. This header is called Protocol Control Information (PCI). It identifies the data to be transferred. The resulting object is called a Protocol Data Unit. PCI SDU When data communication involves the co-operative effort of several layers at each communication end, the data to be transmitted are fragmented in sets that also contain some service information. This service information allows the automatic entities that implement each layer, to decide the type of processing that the data will follow. This process is called “Encapsulation”. The following slides shows the different stages of an Encapsulation process, as standardised by the International Standards Organisation (ISO). PDU PDU September 18 L2_2

Data Transfer by Encapsulation (II)
Next, the (N-1) Service Provider must be invoked. To do this, the Interface Control Information (ICI) is attached to the Protocol Data Unit (PDU). The ICI identifies the Service Primitive to be invoked from the (N-1)-Layer Service. The resulting object is called an Interface Data Unit (IDU). PDU PDU ICI IDU IDU September 18 L2_2

Data Transfer by Encapsulation (III)
The (N-1) Service Provider receives the Interface Data Unit (IDU) and breaks it apart into the ICI and the (N-1) SDU. It then invokes the desired primitive, based on the ICI. IDU IDU ICI PDU ICI PDU September 18 L2_2

Data Transfer by Encapsulation (IV)
At the other end, the process is performed in the reverse order. September 18 L2_2

Service Types Services are classified in two classes:
Connection-oriented Services Connectionless Services Examples of these services are: Connection-oriented Services: Speech Communication Connectionless Services: Packet Data Communication UTRAN provides both types of services September 18 L2_2

Connection-oriented Services
A service of this kind goes through three distinct phases: Connection Establishment Data Transfer Connection Release September 18 L2_2

Connection-oriented Services Phase 1: Establishment
In this phase, the users negotiate the conditions in which the service will be provided. Typical conditions to negotiate include: Data rate Target Bit Error Rate Maximum Admissible Delay If the negotiation is succesful, a Connection is established. The Connection remains available until a Release is requested (or a failure occurs). Typically, all Layers provide a connection establishment service, using the verb Connect. September 18 L2_2

Connection-oriented Services Phase 2: Data Transfer
During this stage, the users exchange data. Third Generation Mobile Systems allow, during this phase, to change the conditions under which data are transferred. This is required in order to maintain a Multi-media Communication, where the requirements in terms of data type and speed may change during the Call. September 18 L2_2

Connection-oriented Services Phase 3: Connection Release (I)
In this phase, the Data Transfer comes to an end. Layers provides 3 types of Connection Release Services: RELEASE ABORT P-ABORT September 18 L2_2

Connection-oriented Services Phase 3: Connection Release (II)
The RELEASE service provides a graceful degradation of the connection. Any service primitives queued for delivery are drained prior to the binding being destroyed. This is a confirmed service. The ABORT service provides for a user-initiated immediate release of the connection. Service primitives queued for delivery may or may not be drained prior to the binding being destroyed. This is an unconfirmed service. The P-ABORT (provider-service abort) is a provider-initiated service that also results in an immediate release of the connection. This is usually triggered by an underlying failure. September 18 L2_2

Connectionless Services
This service has only one phase: Data Transfer Resources (radio channels, etc.) are only allocated by the network for a certain amount of data. If more data needs to be transferred, a new connectionless service needs to take place. Connectionless services are also known as Packet Communication services. Some second generation mobile networks provide these kinds of services: Global Packet Radio Service (GPRS) in GSM. CDPD in the US standard. September 18 L2_2

Protocol Architecture Overview
September 18 Raul Bruzzone

UTRA Architecture Non-Access Stratum Access Stratum UE UTRAN
GC Nt DC GC Nt DC Access Stratum UE UTRAN Core Network Radio Iu This figure shows the three basic components of UTRA: UE UTRAN Core Network All components are also classified according to its radio dependance: Entities that depend of the Radio Interface (Access Stratum) Entities that do not depend of the Radio Interface (Non-Access Stratum) This last classification will allow several kinds of Core Networks (MSN, N-ISDN, B-ISDN) to support UTRA. Of course, not all UMTS service might be supported by all core networks. (Uu) September 18 L2_1

Service Access Points GC: General Control Nt: Notification
DC Nt GC GC: General Control Nt: Notification DC: Dedicated Control The Access Stratum offers its services to the Non-Access Stratum by means of three Service Access Points. September 18 L2_1

Transport Channels The Services provided by Layer 1 to Layer 2 are called Transport Channels. The part of layer 2 that directly interfaces with Layer 1 is called Medium Access Control (MAC) sub-layer. Transport Channels are the services provided by Layer 1 to Layer 2. Layer 2 comprises two sub-layers: Medium Access Control (MAC) Radio Link Control (RLC) MAC is the lower part of layer 2. L2/MAC MAC Transport Channels PHY L1 September 18 L2_1

Logical Channels Logical Channels C-plane signalling
U-plane information RLC RLC L2/RLC RLC RLC RLC RLC RLC RLC Logical Two type of data are classified: 1. Data that the users are willing to transmit 2. Data introduced by the network, for control purposes (signalling data) Entities in charge of transmitting User Data are included in the “User Plane”. Entities in charge of transmitting or receiving the signalling data are included in the “Control Plane”. Channels MAC L2/MAC Transport Channels PHY L1 September 18 L2_1

Logical Channels The upper part of layer 2, that directly interfaces with the Medium Access Control (MAC) sub-layer, is called Radio Link Control (RLC) sub-layer. The Services provided by the Medium Access Control (MAC) sub-layer to the Radio Link Control sub-layers are called Logic Channels. September 18 L2_1

RLC Instances in UTRAN UTRAN UEs C-plane signalling
U-plane information L2/RLC In the case of the fixed part of the network, several instances of the RLC entity co-exist. Each instance is dedicated to one UE. Logical Channels MAC L2/MAC Transport Channels PHY L1 September 18 Raul Bruzzone

Layer 3: Radio Resource Control (RRC)
C-plane signalling U-plane information GC Nt DC RRC L3 RLC RLC L2/RLC RLC RLC RLC RLC RLC RLC Logical Layer 3 has only components in the Control Plane. The corresponding entity is called Radio Resource Control (RRC). RRC directly interfaces with the Non-Access Stratum layers. Channels MAC L2/MAC Transport Channels PHY L1 September 18 L2_1

Configuration Control Connections
GC Nt DC RRC L3 control control control RLC RLC L2/RLC RLC RLC RLC RLC RLC RLC Logical An important function of RRC is to set up the configuration of lower layers (RLC, MAC, PHY). This function is possible through special local connections between RRC and these layers. These special connections are in red in this slide. Channels MAC L2/MAC Transport Channels PHY L1 September 18 L2_1

UTRAN Radio Interface Protocol Architecture
C-plane signalling U-plane information GC Nt DC RRC L3 control control control RLC RLC L2/RLC RLC RLC RLC RLC RLC RLC Logical This slide the complete Protocol Architecture. Channels MAC L2/MAC Transport Channels PHY L1 September 18 L2_1

Layer 1: Functions and Services
This section presents Layer 1 very shortly, just reviewing the services that this layer provides to the MAC layer. A more detailed description of Layer 1 is presented in other block of this Course. September 18 Raul Bruzzone

A review of Physical Layer Functions (I)
Macro-diversity distribution/combining and soft handover execution Error detection on transport channels and indication to higher layers FEC encoding/decoding and interleaving/de-interleaving of transport channels Multiplexing of transport channels and demultiplexing of coded composite transport channels Rate matching Mapping of coded composite transport channels on physical channels This slide, and the following one, revisit the list of functions performed by the physical layer. These functions are transparent to layers 2 and 3. September 18 L2_1

A review of Physical Layer Functions (II)
Power weighting and combining of physical channels Modulation and spreading/demodulation and despreading of physical channels Frequency and time (chip, bit, slot, frame) synchronization Measurements and indication to higher layers (e.g. FER, SIR, interference power, transmit power, etc.) Closed-loop power control RF processing September 18 L2_1

Transport Channels The Services provided by Layer 1 to Layer 2 are called Transport Channels. As was previously mentioned, Layer 1 provides services to the upper layers under the form of Transport Channels. The following slides present the Transport Channels in detail. L2/MAC MAC Transport Channels PHY L1 September 18 L2_1

Transport Channel Types
Transport Channel identification may be based on: The Physical Channel used for data transport. In this case, the Physical Channel properties are used for identification: Carrier Frequency and Spreading Code (FDD) Carrier Frequency, Spreading Code and Time Slot (TDD) This class of channels is called Dedicated Channels. In-band identification. This class of channels is called Common Channels. September 18 L2_1

Transport Channels Common Transport Channels
Dedicated Transport Channels Random Access Channel (RACH) Dedicated Channels (DCH) ODMA Random Access Channel (ORACH) Fast Uplink Signalling Channel (FAUSCH) Forward Access Channel (FACH) Downlink Shared Channels (DSCH) ODMA Dedicated Channel (ODCH) Downlink Shared Control Channel (DSCCH) Uplink Shared Channel (USCH) In order to perform all the required communication functions, UTRA has a rich set of Common and Dedicated Channels. This chart gives the complete picture. In the following slides, a brief description of each class of Transport Channels is included. Broadcast Channel (BCH) Synchronisation Channel (SCH) Paging Channel (PCH) September 18 L2_1

Random Access Channel (RACH)
Used by the UE for initial access to the fixed network. Used to upload small amounts of non-real-time data. Only available in the Uplink. Contention based. September 18 L2_1

ODMA Random Access Channel (ORACH)
Used by UEs for relaying data. Contention based September 18 L2_1

Forward Access Channel (FACH)
Used by the BS to transmit small amounts of data. Available only in the Downlink. No closed-loop power control. September 18 L2_1

Downlink Shared Channel (DSCH)
Shared by several UEs. It carries dedicated data or control information. September 18 L2_1

Downlink Shared Control Channel
It is always associated with a Downlink Shared Channel (DSCH). It provides information on resources allocation for the associated DSCH. September 18 L2_1

Uplink Shared Channel (USCH)
Uplink channel shared by several UEs. It carries dedicated user or signalling data. Only available in TDD mode. September 18 L2_1

Broadcast Channel Used by the Base Station to distribute general information to all the UEs camping in its cell. September 18 L2_1

Synchronisation Channel
Used by the Base Station to distribute synchronisation information to all the UEs camping in its cell. Only available in TDD mode. September 18 L2_1

Paging Channel (PCH) Used by the Base Station to inform a specific UE about a network-originated call. Transmitted on an intermitent basis, in order to facilitate Sleeping Mode at the UEs. September 18 L2_1

Dedicated Channel Used to communicate data between UTRAN and a specific UE. Available in both uplink and downlink. September 18 L2_1

Fast Uplink Signalling Channel (FAUSCH)
Uplink channel used to allocate dedicated channels. Operates in conjunction with the Forward Access Channel (FACH). September 18 L2_1

ODMA Dedicated Channel
Assigned to a specific UE for relaying purpose. September 18 L2_1

Medium Access Control (MAC) Sub-layer: Functions and Services
This section presents Layer 1 very shortly, just reviewing the services that this layer provides to the MAC layer. A more detailed description of Layer 1 is presented in other block of this Course. September 18 Raul Bruzzone

Inside MAC MAC is, in fact, a set of several independent entities.
Six types of entities have been identified. The functions implemented by each entity are different in the UE than from UTRAN. MAC configuration is performed by the Radio Resource Control (RRC) layer (Layer 3). MAC MAC-b MAC-p MAC-c MAC-d MAC-sh MAC-sy September 18 L2_3

MAC Entities (I) MAC-b identifies the MAC entity that handles the Broadcast Channel (BCH). There is one MAC-b entity in each UE and one MAC-b in the UTRAN for each cell. MAC-p identifies the MAC entity that handles the Paging Channel (PCH). There is one MAC-p entity in each UE and one MAC-p in the UTRAN for each cell. MAC-c identifies the MAC entity that handles the Forward Access Channel (FACH) and the Random Access Channel (RACH). There is one MAC-c entity in each UE and one in the UTRAN for each cell. MAC MAC-b MAC-p MAC-c MAC-d MAC-sh MAC-sy September 18 L2_3

MAC Entities (II) MAC-d denotes the MAC entity that is responsible for handling of Dedicated Logical Channels and Dedicated Transport Channels (DCH) allocated to a UE. There is one MAC-d entity in the UE and one MAC-d entity in the UTRAN for each UE. MAC-sh denotes the MAC entity that handles Downlink Shared Channels (DSCH) for both FDD and TDD and Uplink Shared Channels (USCH) for TDD . There is one MAC-sh entity in each UE that is using a DSCH and a USCH for TDD operation and one MAC-sh entity in the UTRAN for each cell that contains a DSCH and a USCH for TDD operation. MAC-sy identifies the MAC entity used in TDD operation to handle the information received on the Synchronisation Channel SCH. MAC MAC-b MAC-p MAC-c MAC-d MAC-sh MAC-sy September 18 L2_3

Connectivity of Broadcast, Paging and Synchronisation Channels
UE Radio Link Control (RLC) MAC Control BCCH PCCH SCCH Medium Access Control (MAC) MAC-b MAC-p MAC-sy MAC-b, MAC-p and MAC-sy represents SCH, BCH and PCH control entities, which are cell-specific MAC entities in the UTRAN. In the UE side there is one SCH, BCH and PCH control entity per UE. The SCH control entity handles synchronisation channels for the TDD mode. The MAC Control SAP is used to transfer Control information to each MAC entity. UTRAN BCH PCH SCH Layer 1 September 18 L2_3

Connectivity of FACH, RACH, USCH and Dedicated Channels
UE Radio Link Control (RLC) CCCH MAC Control DCCH DTCH DTCH Medium Access Control (MAC) TDD only MAC-d MAC-c MAC-sh The figure illustrates the connectivity of MAC entities. The figure shows a MAC-d servicing the needs of several DTCH mapping them to a number of DCH. A MAC-sh controls access to a common transport channel. It is noted that because the MAC-sh provides additional capacity then it communicates only with the MAC-d rather than the DTCH directly. The MAC-c, which interfaces with the FACH and RACH common signalling channels, is connected with the MAC-d for transfer of data and RNTI. The MAC Control SAP is used to transfer Control information to each MAC entity. In the TDD implementation the MAC-sh transfers data from the DSCH to the MAC-d and from the MAC-d to the USCH under control of the FACH. UTRAN FACH RACH USCH DSCH DCH DCH Layer 1 ( TDD only ) September 18 L2_3

Inside MAC-c UE UTRAN CCCH MAC-c RACH FACH MAC Control September 18
to MAC –d to MAC – sh (2) add/read c-RNTI C/D MUX UL: TF selection This slide shows the inner structure of the MAC-c entity. It includes the following elements: The C/D MUX box represents the insertion and detection of the field in the MAC header, that indicates whether a common or dedicated logical channel is used. The c-RNTI field in the MAC header is used to distinguish between UEs. In the uplink, the possibility of transport format selection exists. RNTI means Radio Network Temporary Identity. Selection of Access Service Classes ( ASC ) for RACH, details on definition of ASC and the relation to the RACH retransmission algorithm are ffs. Inner descriptions of the other MAC entities may be found in the UMTS standard documents. See reference. ASC Selection (1) UTRAN RACH FACH September 18 L2_3

MAC Layer - UTRAN side Serving Controlling RNC RNC MAC-d MAC-c MAC-sh
DTCH DTCH CCCH MAC Control DCCH TDD only MAC-d MAC-c MAC-sh This figure illustrates the connectivity between the MAC entities from the UTRAN side. It is similar to the UE case with the exception that there will be one MAC-d for each UE and each UE (MAC-d) that is associated with a particular cell may be associated with that cell’s MAC-sh. MAC-c and Mac-sh are located in the controlling RNC while MAC-d is located in the serving RNC.The MAC Control SAP is used to transfer Control information to each MAC entity belongs to one UE. FACH RACH USCH DSCH DCH DCH TDD only September 18 L2_3

MAC DATA Protocol Data Unit (PDU)
MAC header MAC SDU C/D UE-Id C/T MAC SDU The MAC Service Data Unit (SDU) contains the data originated at the upper layer. MAC PDU consists of an optional MAC header and a MAC Service Data Unit (MAC SDU). Both the MAC header and the MAC SDU are of variable size. The content and the size of the MAC header depends on the type of the logical channel, and in some cases none of the parameters in the MAC header are needed. The size of the MAC-SDU depends on the size of the RLC-PDU, which is defined during the set-up procedure. September 18 L2_3

MAC DATA Protocol Data Unit (PDU): C/D Field
UE-Id C/T MAC SDU The C/D field is a single-bit flag that provides identification of the logical channel class on FACH and RACH transport channels, i.e. whether it carries CCCH or dedicated logical channel information. The C/D field is a single-bit flag that provides identification of the logical channel class on FACH and RACH transport channels, i.e. whether it carries CCCH or dedicated logical channel information. C/D field Designation 1 CCCH DCCH or DTCH September 18 L2_3

MAC DATA Protocol Data Unit (PDU): UE-Id Field
C/T MAC SDU The UE-Id field provides an identifier of the UE . September 18 L2_3

MAC DATA Protocol Data Unit (PDU): UE-Id Field
C/T MAC SDU The C/T field provides identification of the logical channel instance when multiple logical channels are carried on the same transport channel. C/T field Designation The C/T field is used also to provide identification of the logical channel type on dedicated transport channels and on FACH and RACH when used for user data transmission. The size of the C/T field may be variable. (e.g. 4 bits ) 0000 Logical channel 1 0001 Logical channel 2 ... ... 1111 Logical channel 16 September 18 L2_3

MAC Sub-layer Functions (I)
Mapping between logical channels and transport channels. Selection of appropriate Transport Format for each Transport Channel depending on instantaneous source rate Priority handling between data flows of one UE Priority handling between UEs by means of dynamic scheduling Priority handling between data flows of several users on the the DSCH and FACH Scheduling of broadcast, paging and notification messages Identification of UEs on common transport channels September 18 L2_3

MAC Sub-layer Functions (II)
Multiplexing/demultiplexing of higher layer PDUs into/from transport blocks delivered to/from the physical layer on common transport channels Multiplexing/demultiplexing of higher layer PDUs into/from transport block sets delivered to/from the physical layer on dedicated transport channels Traffic volume monitoring Monitoring the links of the assigned resources Routing of higher layer signalling Maintenance of a MAC signalling connection between peer MAC entities Dynamic Transport Channel type switching September 18 L2_3

MAC Sub-layer Functions (III)
The following potential functions are regarded as further study items: Constrained execution of open loop power control algorithms Processing of messages received at common control channels Successive Transmission on RACH Ciphering Access Service Class selection for RACH transmission. September 18 L2_3

Logical Channels Structure
Common Channels Dedicated Channels Synchronisation Control Channel (SCCH) Dedicated Traffic Channels (DTCH) Broadcast Control Channel (BCCH) ODMA Dedicated Traffic Channels (ODTCH) Paging Control Channel (PCCH) Dedicated Control Channels (DCCH) Common Traffic Channels (CTCH) Logical are the services offered by MAC to upper layers. Common Control Channel (CCCH) ODMA Dedicated Control Channel (ODCCH) ODMA Common Control Channel (ODCCH) September 18 L2_1

Logical channels mapped onto transport channels (seen from the UE side)
SCCH- BCCH- PCCH- DCCH- CCCH- DTCH- SAP SAP SAP SAP SAP SAP Logical Channels Transport SCH These slides on mapping are given only for reference, because at the time of writing (May, 1999) there is not yet an agreement. BCH PCH FAUSCH RACH FACH USCH DSCH DCH Channels (TDD only) (TDD only) MAC SAPs September 18 L2_1

Logical channels mapped onto transport channels (seen from the UTRAN side)
SCCH- BCCH- PCCH- DCCH- CCCH- DTCH- SAP SAP SAP SAP SAP SAP Logical Channels Transport SCH BCH PCH FAUSCH RACH FACH USCH DSCH DCH Channels (TDD only) (TDD only) MAC SAPs September 18 L2_1

Logical channels mapped onto transport channels (seen from the UE side, Relay only)
ODCCH- OCCCH- ODTCH- Logical SAP SAP SAP Channels Transport Channels ORACH ODCH MAC SAPs September 18 L2_1

Radio Link Control (RLC) Sub-layer: Functions and Services
This section presents Layer 1 very shortly, just reviewing the services that this layer provides to the MAC layer. A more detailed description of Layer 1 is presented in other block of this Course. Base Station User Equipment September 18 Raul Bruzzone

General Concepts on Link Control
Segmentation and Re-assembly Error Detection and Correction Flow Control Before describing the Radio Link Control Sub-layer, some general concepts that are applicable to most Link Control Protocol will be presented. September 18 L2_1

Segmentation and Re-assembly
The maximum length of frames is usually limited by: The Optimum transmission length required by Lower Layers (e.g. MAC) The Size of available Buffers When the length of a message exceeds the maximum allowable size of the frame, the message must be segmented and sent over several frames. This process is called Segmentation. Conversely, the message must be re-assembled at the other end. This process is called Re-assembly. September 18 L2_1

Direction of Transmission
Segmentation Upper Layer Message 1 Segmentation 1 1 The following parts are identified in each Segment: Header Contents Trailer Fill Bits (if the Contents is not full) The “More” Bit allows the receiver to assess if the segment is the last part of the message, or not. More Bit 1 This Frame is not the last of the Message Direction of Transmission This Frame is the last of the Message September 18 L2_1

Re-assembly Re-assembly 1 1 1 Upper Layer Message September 18 L2_1
Re-assembly Upper Layer Message Fill bits are usually “1”. September 18 L2_1

Error Detection and Correction
The Link Layer improves the transmission quality by detecting frames with errors, and asking for repetition. Error Detection is implemented by means of a sequence of redundancy bits. This sequence is called Frame Check Sequence (FCS). Error Detection serves two purposes: To provide information on the likelihood of errors in a frame To monitor the quality of the link, triggering alarms when it exceeds a specific threshold. September 18 L2_1

Error Detection and Correction
Error Detection and Correction is based on retransmission of frames that are received with errors. Frames receive a cyclic number, which enables the recipient to: To detect possible repetitions and/or losses of frames To acknowledge specific frames. The acknowledgement is done by the receiver by means of transmitting to the sender, the number of the next expected frame: N(R). September 18 L2_1

Error Detection and Correction Repetition Rules
Repetition is triggered by the sender in two cases: When it does not receive an ACK after a certain amount of time. When it receives an ACK for a frame which is not the last one sent. September 18 L2_1

Error Detection and Correction Timers
The repetition process is based on two timers located at the Sender: Supervision Timer: measures the time between successive checks of ACKs Expiry Timer: measures the maximum allowable time to receive the ACK of a specific message September 18 L2_1

Flow Control Flow Control procedures allow a Recipient Entity to send back to the Transmitting Entity a message asking to reduced (or even stop) data delivery: Data Flow Flow Control Feedback This control mechanism avoids that a local overload could produce the colapse of the whole system. September 18 L2_1

C-plane signalling U-plane information GC Nt DC RRC L3 control control control RLC RLC L2/RLC RLC RLC RLC RLC RLC RLC Logical This block will be dedicated to the analysis of the Radio Link Control (RLC) sub-layer, which is the upper part of Layer 2. As a reminder, this first slide shows the RLC position in the context of the whole UTRAN Radio Interface Protocol. Channels MAC L2/MAC Transport Channels PHY L1 September 18 L2_1

Data Transfer Modes provided by RLC
RLC is able to transmit higher layer Protocol Data Units (PDUs) according to three kinds of data communication services: Transmission without adding any protocol information, although including (if required) segmentation/re-assembly functionality. This mode is called Transparent Data Transfer. Transmission without guaranteeing delivery to the peer entity (i.e. no notification to the sender in case of bad reception). This mode is called Un-acknowledged Data Transfer. Transmission ensuring delivery to the peer entity: In case RLC is unable to deliver the data correctly, the user of RLC at the transmitting side is notified. This mode is called Acknowledged Data Transfer. September 18 L2_1

Un-acknowledged Data Transfer Mode
The unacknowledged data transfer mode has the following characteristics: Detection of erroneous data: The RLC sub-layer delivers only those SDUs to the receiving higher layer that are free of transmission errors by using a sequence-number check function. Unique delivery: The RLC sub-layer delivers each Service Data Unit (SDU) only once to the receiving upper layer, using duplication detection function. Immediate delivery: The receiving RLC sub-layer entity delivers a Service Data Unit (SDU) to the higher layer receiving entity as soon as it arrives at the receiver. September 18 L2_1

Acknowledged Data Transfer Mode
The acknowledged data transfer mode has the following characteristics: Error-free delivery: it is ensured by means of retransmission. The receiving RLC entity delivers only error-free Service Data Units (SDUs) to the higher layer. Unique delivery: RLC delivers each SDU only once to the receiving upper layer, using a duplication detection function. In-sequence delivery: RLC ensures in-order delivery of SDUs, i.e., RLC delivers SDUs to the receiving higher layer entity in the same order as the transmitting higher layer entity submits them to its RLC sub-layer. Out-of-sequence delivery: Alternatively to in-sequence delivery, it is also possible to instruct the receiving RLC entity to deliver SDUs to its higher layer in different order than submitted to RLC sub-layer at the transmitting side. September 18 L2_1

Other Services provided by RLC to Upper Layers
RLC connection establishment/release. This service performs establishment/release of RLC connections. QoS setting. The retransmission protocol is configurable by layer 3 to provide different levels of QoS. This can be controlled. Notification of unrecoverable errors. RLC notifies the upper layer of errors which cannot be resolved by RLC itself by normal exception handling procedures. e.g. by adjusting the maximum number of retransmissions according to delay requirements In my understanding, QoS in this case should be associated with the admissible delay for data communication. September 18 L2_1

RLC Sub-layer Architecture
The RLC sub-layer is implemented by means of several independent entities: Transparent Mode (Tr) Entities Un-acknowledged Mode (UM) Entities Acknowledged Mode (AM) Entities September 18 L2_1

Transmitting and receiving entities for Transparent Modes exist at both sides of the Radio Interface: UE UTRAN Layer Higher Radio Interface Transm. Receiv. Transm. Receiv. Tr-Entity Tr-Entity Tr-Entity Tr-Entity RLC MAC September 18 L2_4

Transmitting and receiving entities for Un-acknowledged Mode (UM) exist at both sides of the Radio Interface: UE UTRAN Layer Higher Radio Interface Transm. Receiv. Transm. Receiv. UM-Entity UM-Entity UM-Entity UM-Entity RLC MAC September 18 L2_4

There is one combined transmitting and receiving entity for the acknowledged mode service: UE UTRAN Layer Higher Radio Interface AM-Entity AM-Entity RLC MAC September 18 L2_4

The complete RLC architecture is: UE UTRAN Radio Interface Layer Higher Transm. Transm. AM-Entity Receiv. Receiv. Transm. Transm. Transm. AM-Entity Receiv. Receiv. Tr-Entity UM-Entity UM-Entity Tr-Entity Tr-Entity UM-Entity UM-Entity UM-Entity Tr-Entity RLC MAC September 18 L2_4

Transparent-Mode Entities
Transm. Entity Transmission buffer Segmentation Tr-SAP BCCH/PCCH/ CCCH/DTCH Receiver Re-assembly Radio Interface Receiving This slide shows the block diagram of one Transparent Mode Entity. In the following slides, the operation of this entity is described. September 18 L2_4

Transparent-Mode Entity Operation
The transmitting Tr-entity receives SDUs from the higher layers through the Tr-SAP. Radio Interface SDU Tr-SAP September 18 L2_4

The transmitting Tr-entity receives SDUs from the higher layers through the Tr-SAP. RLC segments the SDUs into appropriate RLC PDUs without adding any overhead. Radio Interface SDU Tr-SAP Transm. Entity Segmentation The RLC sub-layer may be requested by the upper layers about do not make segmentation. The reason may be that (for a certain type of data) more efficient segmentation is done at the upper layers. Moreover, if the size of the SDU is sufficiently small, no segmentation is required. September 18 L2_4

The transmitting Tr-entity receives SDUs from the higher layers through the Tr-SAP. RLC segments the SDUs into appropriate RLC PDUs without adding any overhead. The PDU is stored in a Transmission Buffer, waiting for available radio transmission capacity. Radio Interface SDU Tr-SAP Transm. Entity Segmentation Transmission buffer September 18 L2_4

The transmitting Tr-entity receives SDUs from the higher layers through the Tr-SAP. RLC segments the SDUs into appropriate RLC PDUs without adding any overhead. The PDU is stored in a Transmission Buffer, waiting for available radio transmission capacity. RLC delivers the RLC PDUs to MAC through either a BCCH, PCCH or a DTCH. Radio Interface SDU Tr-SAP Transm. Entity Segmentation Transmission buffer September 18 L2_4

The transmitting Tr-entity receives SDUs from the higher layers through the Tr-SAP. RLC segments the SDUs into appropriate RLC PDUs without adding any overhead. The PDU is stored in a Transmission Buffer, waiting for available radio transmission capacity. RLC delivers the RLC PDUs to MAC through either a BCCH, PCCH or a DTCH. MAC transmits the data to its peer entity located at the other side of the Radio Interface. Radio Interface SDU Tr-SAP Transm. Entity Segmentation Transmission buffer BCCH/PCCH/ BCCH/PCCH/ BCCH/PCCH/ CCCH/DTCH CCCH/DTCH CCCH/DTCH September 18 L2_4

The transmitting Tr-entity receives SDUs from the higher layers through the Tr-SAP. RLC segments the SDUs into appropriate RLC PDUs without adding any overhead. The PDU is stored in a Transmission Buffer, waiting for available radio transmission capacity. RLC delivers the RLC PDUs to MAC through either a BCCH, PCCH or a DTCH. MAC transmits the data to its peer entity located at the other side of the Radio Interface. The Receiving entity receives PDUs through from one of the logical channels from the MAC sub-layer. The information is stored in a Buffer. Radio Interface SDU Tr-SAP Transm. Entity Receiving Entity Segmentation Transmission Receiver buffer buffer BCCH/PCCH/ BCCH/PCCH/ BCCH/PCCH/ CCCH/DTCH CCCH/DTCH CCCH/DTCH September 18 L2_4

The transmitting Tr-entity receives SDUs from the higher layers through the Tr-SAP. RLC segments the SDUs into appropriate RLC PDUs without adding any overhead. The PDU is stored in a Transmission Buffer, waiting for available radio transmission capacity. RLC delivers the RLC PDUs to MAC through either a BCCH, PCCH or a DTCH. MAC transmits the data to its peer entity located at the other side of the Radio Interface. The Receiving entity receives PDUs through from one of the logical channels from the MAC sub-layer. The information is stored in a Buffer. RLC reassembles the PDUs into RLC SDUs. Radio Interface SDU Tr-SAP Transm. Entity Receiving Entity Segmentation Re-assembly Transmission Receiver buffer buffer BCCH/PCCH/ BCCH/PCCH/ BCCH/PCCH/ CCCH/DTCH CCCH/DTCH CCCH/DTCH September 18 L2_4

The transmitting Tr-entity receives SDUs from the higher layers through the Tr-SAP. RLC segments the SDUs into appropriate RLC PDUs without adding any overhead. The PDU is stored in a Transmission Buffer, waiting for available radio transmission capacity. RLC delivers the RLC PDUs to MAC through either a BCCH, PCCH or a DTCH. MAC transmits the data to its peer entity located at the other side of the Radio Interface. The Receiving entity receives PDUs through from one of the logical channels from the MAC sub-layer. The information is stored in a Buffer. RLC reassembles the PDUs into RLC SDUs. The receiving entity transfers the SDUs to the higher layers through the Tr-SAP. Radio Interface SDU SDU Tr-SAP Tr-SAP Transm. Entity Receiving Entity Receiving Entity Segmentation Re-assembly Transmission Receiver buffer buffer BCCH/PCCH/ BCCH/PCCH/ BCCH/PCCH/ CCCH/DTCH CCCH/DTCH CCCH/DTCH September 18 L2_4

Un-acknowledged Mode Entity
Radio Interface Tr-SAP Tr-SAP Transm. Entity Receiving Entity Segmentation Concatenation RLC Header Addition Remove RLC Header Re-assembly Transmission Receiver buffer buffer This slide shows the block diagram of one Un-acknowledged Mode Entity. As may be seen, its structure is quite similar to the Transparent Mode Entity. However, some complementary processes take place: Concatenation RLC Header addition and removal. Concatenation refers to the addition of stamps to the PDUs (segments of the SDU) in such a way that the peer entity should be able to reconstruct the original SDU. The RLC Header is a set of additional information where this concatenation information is loaded for further transmission. BCCH/PCCH/ BCCH/PCCH/ CCCH/DTCH CCCH/DTCH September 18 L2_4

Acknowledged Mode Entity
Transmission buffer Segmentation Concatenation Add RLC Header Retransmission buffer & management MUX Set fields in RLC Header (e.g. set poll bits) RLC Control Unit Received acknowledgements Acknowledgements DCCH/ DTCH AM-SAP AM-Entity Demux/Routing Receiver buffer & Remove RLC Header & Re-assembly Transmitting Side Receiving Side September 18 L2_4

Acknowledged Mode Entity Acknowledgement Communication Path
Transmitting Side Receiving Side Transmitting Side Receiving Side AM-SAP Segmentation Concatenation RLC Header Retransm. buffer management MUX Remove RLC Header & Re-assembly Transmission Acknowledgement buffer Receiver buffer Retransmission management If the transmission has successfully received, the Receiving Entity sends back and Acknowledgement Message. This message contains the identity of the received message. The acknowledgement is received at the original Transmitting Entity. Its effect is to delete the original message from the Retransmission Buffer. It is important to underline that the Transmitting Entity waits until a certain time before considering that (due to unavailability of ACK) the transmission has failed. Set fields in RLC Header (e.g. set poll bits) Set fields in RLC Header (e.g. set poll bits) Demux/Routing Demux/Routing DCCH/ DCCH/ DCCH/ DTCH DTCH DTCH September 18 L2_4

Acknowledged Mode Entity Acknowledgement Communication Path
Transmitting Side Receiving Side Transmitting Side Receiving Side AM-SAP Segmentation Concatenation RLC Header Retransm. buffer management MUX Remove RLC Header & Re-assembly Transmission buffer Receiver buffer Retransmission management In the case that no ACK has been received after a certain time, the Transmitting Entity re-sends the original PDU. This re-send process is governed by a counter, that limits the quantity of retransmissions. If the communication still remains unsuccesfull, a notification is sent to the upper layers. Set fields in RLC Header (e.g. set poll bits) Set fields in RLC Header (e.g. set poll bits) Demux/Routing Demux/Routing DCCH/ DCCH/ DCCH/ DTCH DTCH DTCH Retransmission September 18 L2_4

RLC Services: Comparative Table
Transparent Mode Segmentation / Re-assembly Transfer of User Data Un-acknowledged Mode Segmentation / Re-assembly Concatenation Transfer of User Data Acknowledged Mode Segmentation / Re-assembly Concatenation Transfer of User Data Error correction In-sequence delivery Duplicate detection Flow Control Error detection and recovery QoS setting Notific. of unrecov. errors Multicast delivery September 18 L2_4

Radio Resource Control (RRC) Layer: Functions and Services
This section presents the Radio Resource Control Layer. September 18 Raul Bruzzone

C-plane signalling U-plane information GC Nt DC RRC L3 control control control RLC RLC L2/RLC RLC RLC RLC RLC RLC RLC Logical The Radio Resource Control (RRC) layer corresponds to Layer 3 in the OSI/ISO data communications structure. It only exists in the Control Plane. RRC is directly in contact with the Non-Access Stratum. Channels MAC L2/MAC Transport Channels PHY L1 September 18 L2_1

Radio Resource Control (RRC) Services
RRC Services are classified in three classes: Information Broadcast (General Control Service) Paging and Notification Broadcast (Notification Service) Establishment/release of a connection and transfer of messages using this connection (Dedicated Control Service) Each class of service has its specific Service Access Point. September 18 L2_6

RRC Functions (I) Broadcast of information provided by the non-access stratum (Core Network) Broadcast of information related to the access stratum Broadcast of ODMA relay node neighbour information Establishment, maintenance and release of an RRC connection between the UE and UTRAN Collating ODMA neighbour list and gradient information Maintenance of number of ODMA relay node neighbours. Establishment, maintenance and release of a route between ODMA relay nodes Broadcast of information provided by the non-access stratum (Core Network). The RRC layer performs system information broadcasting from the network to all UEs. The system information is normally repeated on a regular basis. This function supports broadcast of higher layer (above RRC) information. This information may be cell specific or not. As an example RRC may broadcast Core Network location service area information related to some specific cells. Broadcast of information related to the access stratum. The RRC layer performs system information broadcasting from the network to all Ues This function supports broadcast of typically cell-specific information. Broadcast of ODMA relay node neighbour information. The RRC layer performs probe information broadcasting to allow ODMA routing information to be collected. Establishment, maintenance and release of an RRC connection between the UE and UTRAN. The establishment of an RRC connection is initiated by a request from higher layers at the UE side to establish the first Signalling Connection for the UE. The establishment of an RRC connection includes an optional cell re-selection, an admission control, and a layer 2 signalling link establishment. The release of an RRC connection can be initiated by a request from higher layers to release the last Signalling Connection for the UE or by the RRC layer itself in case of RRC connection failure. The RRC layer detects loss of RRC connection and releases resources assigned for the RRC connection in case of connection failure. Collating ODMA neighbour list and gradient information. The ODMA relay node neighbour lists and their respective gradient information will be maintaining by the RRC. Maintenance of number of ODMA relay node neighbours. The RRC will adjust the broadcast powers used for probing messages to maintain the desired number of neighbours. Establishment, maintenance and release of a route between ODMA relay nodes. The establishment of an ODMA route and RRC connection based upon the routing algorithm. September 18 L2_1

RRC Functions (II) Interworking between the Gateway ODMA relay node and the UTRAN Establishment, reconfiguration and release of Radio Access Bearers Assignment, reconfiguration and release of radio resources for the RRC connection RRC connection mobility functions Paging/notification Routing of higher layer PDUs Interworking between the Gateway ODMA relay node and the UTRAN. The RRC layer will control the interworking with the standard TDD or FDD communication link between the Gateway ODMA relay node and the UTRAN. Establishment, reconfiguration and release of Radio Access Bearers. The RRC layer can, on request from higher layers, perform the establishment, reconfiguration and release of radio access bearers in the user plane. A number of radio access bearers can be established to an UE at the same time. At establishment and reconfiguration, the RRC layer performs admission control and selects parameters describing the radio access bearer processing in layer 2 and layer 1, based on information from higher layers. Assignment, reconfiguration and release of radio resources for the RRC connection. The RRC layer handles the assignment of radio resources (e.g. codes) needed for the RRC connection including needs from both the control and user plane. The RRC layer may reconfigure radio resources during an established RRC connection. This function includes co-ordination of the radio resource allocation between multiple radio bearers related to the same RRC connection. RRC controls the radio resources in the uplink and downlink such that UE and UTRAN can communicate using unbalanced radio resources (asymmetric uplink and downlink). RRC signals to the UE to indicate resource allocations for purposes of handover to GSM or other radio systems. RRC connection mobility functions. The RRC layer performs evaluation, decision and execution related to RRC connection mobility during an established RRC connection, such as handover, preparation of handover to GSM or other systems, cell re-selection and cell/paging area update procedures, based on e.g. measurements done by the UE. Paging/notification. The RRC layer can broadcast paging information from the network to selected UEs. Paging and notification can be requested by higher layers on the network side. The RRC layer can also initiate paging during an established RRC connection. Routing of higher layer PDUs. This function performs at the UE side routing of higher layer PDUs to the correct higher layer entity, at the UTRAN side to the correct RANAP entity. September 18 L2_1

RRC Functions (III) Control of requested QoS
UE measurement reporting and control of the reporting Outer loop power control Control of ciphering Slow Dynamic Channel Allocation Contention resolution Arbitration of radio resources on uplink DCH Initial cell selection and re-selection in idle mode Control of requested QoS. This function shall ensure that the QoS requested for the radio access bearers can be met. This includes the allocation of a sufficient number of radio resources. The exact requirements on RRC to support this function are ffs. UE measurement reporting and control of the reporting. The measurements performed by the UE are controlled by the RRC layer, in terms of what to measure, when to measure and how to report, including both UMTS air interface and other systems. The RRC layer also performs the reporting of the measurements from the UE to the network. Outer loop power control. The RRC layer controls setting of the target of the closed loop power control. Control of ciphering. The RRC layer provides procedures for setting of ciphering (on/off) between the UE and UTRAN. Slow DCA. Allocation of preferred radio resources based on long-term decision criteria. It is applicable only in TDD mode. Contention resolution. The RRC handles reallocations and releases of radio resources in case of collisions indicated by lower layers in TDD mode. Applicability of contention resolution in FDD mode is ffs. Arbitration of radio resources on uplink DCH. This function controls the allocation of radio resources on uplink DCH on a fast basis, using a broadcast channel to send control information to all involved users. [Note: This function is implemented in the CRNC. Details are ffs.] Initial cell selection and re-selection in idle mode. Selection of the most suitable cell based on idle mode measurements and cell selection criteria. September 18 L2_1

Model of RRC (UE side) ... ... ... ... ... ... Non Access Stratum
BCFE: Broadcast Control Functional Entity DCFE: Dedicated Control Functional Entity PNFE: Paging and Notification Control Functional Entity RFE: Routing Functional Entity TME: Traffic Multiplexing Entity GC-SAP GC-SAP ... GC-SAP ... DC-SAP ... Nt-SAP Nt-SAP Nt-SAP DC-SAP DC-SAP RFE RFE RFE RRC BCFE PNFE DCFE TME This slide shows the RRC architecture corresponding to a UE. The architecture for the UTRAN side is basically the same. In the following slides, the components of RRC will be briefly described. Tr-SAP UM SAP AM SAP RLC-ctrl RLC MAC MAC MAC-ctrl UTRAN L1 L1-ctrl September 18 L2_6

Model of RRC (UE side) Routing Function Entity (RFE)
Non Access Stratum Routing of higher layer messages to different Man Machine/Communication Management (MM/CM) entities is handled by the Routing Function Entities (RFE). ... ... ... GC-SAP GC-SAP ... GC-SAP ... DC-SAP ... Nt-SAP Nt-SAP Nt-SAP DC-SAP DC-SAP RFE RFE RFE RRC BCFE PNFE DCFE TME Tr-SAP UM SAP AM SAP RLC-ctrl RLC MAC MAC MAC-ctrl L1 L1-ctrl September 18 L2_6

Model of RRC (UE side) Broadcast Control Function Entity (BCFE)
Non Access Stratum ... ... ... GC-SAP GC-SAP ... GC-SAP ... DC-SAP ... Nt-SAP Nt-SAP Nt-SAP DC-SAP DC-SAP Broadcast functions are handled in the Broadcast Control Function Entity (BCFE). RFE RFE RFE RRC BCFE PNFE DCFE TME Tr-SAP UM SAP AM SAP RLC-ctrl RLC MAC MAC MAC-ctrl L1 L1-ctrl September 18 L2_6

Non Access Stratum BCFE offers RRC services by the GC-SAP ... ... ... GC-SAP GC-SAP ... GC-SAP ... DC-SAP ... Nt-SAP Nt-SAP Nt-SAP DC-SAP DC-SAP Broadcast functions are handled in the Broadcast Control Function Entity (BCFE). RFE RFE RFE RRC BCFE PNFE DCFE TME Tr-SAP UM SAP AM SAP RLC-ctrl RLC MAC MAC MAC-ctrl L1 L1-ctrl September 18 L2_6

Non Access Stratum BCFE offers RRC services by the GC-SAP ... ... ... GC-SAP GC-SAP ... GC-SAP ... DC-SAP ... Nt-SAP Nt-SAP Nt-SAP DC-SAP DC-SAP Broadcast functions are handled in the Broadcast Control Function Entity (BCFE). RFE RFE RFE RRC BCFE PNFE DCFE TME BCFE uses the lower layer services provided by Tr-SAP. Tr-SAP UM SAP AM SAP RLC-ctrl RLC MAC MAC MAC-ctrl L1 L1-ctrl September 18 L2_6

Model of RRC (UE side) Paging and Notification Control Function Entity (PNFE)
Non Access Stratum ... ... ... GC-SAP GC-SAP ... GC-SAP ... DC-SAP ... Nt-SAP Nt-SAP Nt-SAP DC-SAP DC-SAP Paging of idle mode UE(s) is controlled by the paging and notification control function entity (PNFE) RFE RFE RFE RRC BCFE PNFE DCFE TME Tr-SAP UM SAP AM SAP RLC-ctrl RLC MAC MAC MAC-ctrl L1 L1-ctrl September 18 L2_6

Non Access Stratum PNFE offers RRC services by the Nt-SAP ... ... ... GC-SAP GC-SAP ... GC-SAP ... DC-SAP ... Nt-SAP Nt-SAP Nt-SAP DC-SAP DC-SAP Paging of idle mode UE(s) is controlled by the paging and notification control function entity (PNFE) RFE RFE RFE RRC BCFE PNFE DCFE TME Tr-SAP UM SAP AM SAP RLC-ctrl RLC MAC MAC MAC-ctrl L1 L1-ctrl September 18 L2_6

Non Access Stratum PNFE offers RRC services by the Nt-SAP ... ... ... GC-SAP GC-SAP ... GC-SAP ... DC-SAP ... Nt-SAP Nt-SAP Nt-SAP DC-SAP DC-SAP Paging of idle mode UE(s) is controlled by the paging and notification control function entity (PNFE) RFE RFE RFE RRC BCFE PNFE DCFE TME BCFE uses the lower layer services provided by Tr-SAP. Tr-SAP UM SAP AM SAP RLC-ctrl RLC MAC MAC MAC-ctrl L1 L1-ctrl September 18 L2_6

Model of RRC (UE side) Dedicated Control Function Entity (DCFE)
Non Access Stratum ... ... ... GC-SAP GC-SAP ... GC-SAP ... DC-SAP ... Nt-SAP Nt-SAP Nt-SAP DC-SAP DC-SAP The Dedicated Control Function Entity (DCFE) handles all functions specific to one UE RFE RFE RFE RRC BCFE PNFE DCFE TME Tr-SAP UM SAP AM SAP RLC-ctrl RLC MAC MAC MAC-ctrl L1 L1-ctrl September 18 L2_6

Non Access Stratum DCFE offers RRC services by the DC-SAP ... ... ... GC-SAP GC-SAP ... GC-SAP ... DC-SAP ... Nt-SAP Nt-SAP Nt-SAP DC-SAP DC-SAP The Dedicated Control Function Entity (DCFE) handles all functions specific to one UE RFE RFE RFE RRC BCFE PNFE DCFE TME Tr-SAP UM SAP AM SAP RLC-ctrl RLC MAC MAC MAC-ctrl L1 L1-ctrl September 18 L2_6

Non Access Stratum DCFE offers RRC services by the DC-SAP. ... ... ... GC-SAP GC-SAP ... GC-SAP ... DC-SAP ... Nt-SAP Nt-SAP Nt-SAP DC-SAP DC-SAP The Dedicated Control Function Entity (DCFE) handles all functions specific to one UE. RFE RFE RFE RRC BCFE PNFE DCFE TME DCFE can use lower layer services of UM, AM and Tr-SAP depending on the message to be sent and on the current UE service state. Tr-SAP UM SAP AM SAP RLC-ctrl RLC MAC MAC MAC-ctrl L1 L1-ctrl September 18 L2_6

Conclusions September 18 Raul Bruzzone

UTRA Architecture Non-Access Stratum Access Stratum UE UTRAN
GC Nt DC GC Nt DC Access Stratum UE UTRAN Core Network Radio Iu In this presentation, we have reviewed the protocols corresponding to the the Access Stratum part of a UMTS network. (Uu) September 18 L2_1

C-plane signalling U-plane information GC Nt DC RRC L3 control control control RLC RLC L2/RLC RLC RLC RLC RLC RLC RLC Logical The UTRAN protocol stack comprises three layers, and two data communication planes. The three layers are: Layer 1 (also known as the Physical Layer) Layer 2, which comprises two sub-layers: MAC LRLC Layer 3, which has only one component: RRC The two planes are: The Control Plane The User Plane Channels MAC L2/MAC Transport Channels PHY L1 September 18 L2_1

Layer 1 The Services provided by Layer 1 to Layer 2 are called Transport Channels. Layer 1 provides to layer 2 a set of services called Transport Channels. L2/MAC MAC Transport Channels PHY L1 September 18 L2_1

Layer 2: Medium Access Control (MAC)
MAC-b (Broadcast Channel) MAC-p (Paging Channel) MAC-c (Forward Access, Random Access Channels) MAC-d (Dedicated Channels) MAC-sh (Shared Channels) MAC-sy (Synchronization Channels) We studied the MAC sub-layer, identifying its six internal entities. MAC MAC-b MAC-p MAC-c MAC-d MAC-sh MAC-sy September 18 L2_3

Connectivity of Broadcast, Paging and Synchronisation Channels
UE Radio Link Control (RLC) MAC Control BCCH PCCH SCCH Medium Access Control (MAC) MAC-b MAC-p MAC-sy We studied the interactions between the different MAC entities. UTRAN BCH PCH SCH Layer 1 September 18 L2_3

Layer 2: RLC Segmentation
Upper Layer Message 1 Segmentation 1 1 We presented the way in which RLC processes data (Segmentation/Re-assembly). More Bit 1 This Frame is not the last of the Message Direction of Transmission This Frame is the last of the Message September 18 L2_1

Layer 2: Transparent-Mode Operation
Transm. Entity Transmission buffer Segmentation Tr-SAP BCCH/PCCH/ CCCH/DTCH Receiver Re-assembly Radio Interface Receiving We discovered how RLC implements Transparent Mode. September 18 L2_4

Layer 3: Model of RRC (UE side)
Non Access Stratum ... ... ... BCFE: Broadcast Control Functional Entity DCFE: Dedicated Control Functional Entity PNFE: Paging and Notification Control Functional Entity RFE: Routing Functional Entity TME: Traffic Multiplexing Entity GC-SAP GC-SAP ... GC-SAP ... DC-SAP ... Nt-SAP Nt-SAP Nt-SAP DC-SAP DC-SAP RFE RFE RFE RRC BCFE PNFE DCFE TME Finally, we studied the services, functions and internal structure of Layer 3 Radio Resource Control (RRC). Tr-SAP UM SAP AM SAP RLC-ctrl RLC MAC MAC MAC-ctrl UTRAN L1 L1-ctrl September 18 L2_6

References September 18 Raul Bruzzone

Mobile Radio Data Communication Protocols
References L2_1 TS RAN S2.01, Radio Interface Protocol Architecture, V0.2.0 3GPP. April, 1999 L2_2 The Open Book. A Practical Perspective on OSI. Marshall T. Rose Prentice Hall L2_3 TS RAN S2.21, MAC Protocol Specification, V0.1.0 L2_4 TS RAN S2.22, RLC Protocol Specification V0.1.0 L2_5 The GSM System for Mobile Communications Michel Mouly, Marie-Bernadette Pautet L2_6 TS RAN 2.31, RRC Protocol Specification, V0.1.0 September 18 Raul Bruzzone

Opportunity Driven Multiple Access
coming next … ODMA Opportunity Driven Multiple Access Raul Bruzzone

Data Communication Protocols

Similar presentations

Presentation on theme: "Data Communication Protocols"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Data Communication Protocols

Similar presentations

Presentation on theme: "Data Communication Protocols"— Presentation transcript:

Similar presentations

About project

Feedback