register 7_Iu Interface User Plane Protocols.pdf

VII. Iu Interface User Plane Protocols

1 UTRAN and UMTS Radio Protocols

Iu Interface User Plane Protocols Module Objectives:

• Iu User Plane Protocol Iu UP for CS Services,

• Iu Interface User Data Transfer for PS Services,

• GTP-U Protocol.


UTRAN and UMTS Radio Protocols 2



1 Iu User Plane Protocol



1.1 Iu User Plane Protocol Modes and Tasks The Iu User Plane (Iu UP) protocol is located on Iu-PS and Iu-CS user plane as the highest layer that transports user data. This protocol is considered to be specific to UTRAN, hence it belongs to the so called radio network layer (RNL). Below the radio network layer is the transport network layer (TNL) which is independent of any UMTS related things. On Iu-CS the TNL is built out of AAL2/ATM and on Iu-PS the TNL is formed by GTP-U/UDP/IP/AAL5/ATM. The task of the Iu UP protocol is to decouple the service related user data transport characteristics from the underlying transport network protocols. This shall enable the easy exchange of the transport network protocols (e.g. all IP network without ATM) without any modification of the services. Only the Iu UP protocol has to be adapted to the new transport network. On Iu-PS there is currently no need for an adaptation of the transport services provided by GTP-U/UDP/IP… to the session service (PDP context). Hence on Iu-PS the Iu UP protocol is more or less switched off, it does not provide frames or functionality. Of course this might change in future. On Iu-CS one of the main applications are speech calls with mobile specific speech codecs (AMR : Adaptive Multi-rate Codec). These codecs require a special media flow characteristics, which is not provided by AAL2/ATM. So on Iu-CS the Iu UP protocol has to enhance the transport network bearer service with additional functionality (sub-flows).



CNRNC

user planetransport

bearerprotocols

user planetransport

bearerprotocols

radioprotocols

radioprotocols

RNL-SAP RNL-SAP

Iu UP Iu UP

TNL-SAPTNL-SAP

TNL SAP = Transport Network Layer Service Access PointRNL SAP = Radio Network Layer Service Access Point

Iu u

ser

plan

epr

otoc

ol.

Menu

UE

figure 1 Meaning and location of Iu UP protocol.



The functionality of the Iu UP protocol is divided into so called User Plane Modes. Currently there are two modes defined : • Transparent Mode: The transparent mode is characterized by no functionality from

the Iu UP protocol. This means there are no frames provided and no functionality can be expected from the protocol. This simply means the protocol is switched off. The Iu-PS user plane utilizes this mode in all current implementations.

• Support Mode for predefined SDU sizes: This is in the moment the only mode that

enables specific Iu UP protocol functionality. The main functionality of this mode is the support of RAB sub-flows and sub-flow combinations. Associated with this the Iu UP protocol can perform a frame quality classification of user data, blocking of certain sub-flow combinations (rate control) and handling of the jitter of user data arrival.

The support mode for predefined SDU sizes works only, when the sizes of the user data frames are predefined, this means for each sub-flow combination all sizes of all sub-flows are exactly known. This is the case for speech codecs. The user plane modes can be further divided into versions. In UMTS Release 1999 only one version (version 1) exists for both modes. In UMTS Release 4 a version 2 is defined for the support mode.



Iu u

ser

plan

epr

otoc

ol m

odes

and

mod

eve

rsio

ns.

Iu User Plane Protocol

Transparent ModeSupport Mode for

predefined SDU sizes

Version 1 Version 1

Version 2(only for UMTS Release 4 and higher)

-Transfer of user data -Transfer of user data-UP Initialization-Rate Control-Time Alignment-Handling of error events-Frame quality classification

used on Iu-PS used on Iu-CS

figure 2 Iu UP operation modes and currently available versions with their functionality.



Which of the two user plane modes and which version of this mode shall be used for a radio access bearer is configured by RANAP. In the RAB Assignment Request message the parameter user plane information that is provided for a RAB setup, contains the user plane mode version and user plane mode.



Con

figur

atio

nof

the

IuU

Ppr

otoc

ol w

ithR

AN

AP

.

RNC MSC|SGSN

RANAP: RAB Assignment Request(Setup: RAB-ID, RAB parameters,

User Plane Information = User Plane Mode +supported UP Mode Version)

RANAP: RAB Assignment Response(Setup Acknowledgement: RAB-ID)

figure 3 Parameters in RAB Assignment procedure affecting the Iu user plane protocol.



1.1.1 Transparent Mode In transparent mode the Iu UP protocol is bypassed, thus the user data is transparently flowing through the Iu UP protocol layer without any processing.



Tra

nspa

rent

IuU

P m

ode.

Iu UP - TrM

TNL SAP

RNL SAP

Iu

Iu UP - TrM

TNL SAP

Rad

io In

terf

ace

Pro

toco

ls

RNC MSC|SGSN

figure 4 Transparent operation mode of Iu UP protocol.



1.1.2 Support Mode for Predefined SDU Sizes In the support mode for predefined SDU sizes the Iu UP protocol enables three categories of functionalities : • Frame Handler Function: The frame handler function performs framing and de-

framing of user data and control messages. Together with that a cyclic redundancy check can be applied to user data.

• Procedure Control Function: The Iu UP protocol in support mode provides

signaling procedures for initialization, rate control, time alignment and error event notification.

• NAS stream specific functions: These functions are special processing features of

user data. In the support mode for predefined SDU sizes version 1 this covers : detection of frame loss, frame quality classification and decision to discard or deliver frames. Additionally frame loss notifications are sent to the data stream consumer (speech codec).



Sup

port

mod

efo

r pr

edef

ined

SD

Usi

zes

ofIu

UP

.

TNL SAP

RNL SAP

Iu

TNL SAP

Rad

io In

terf

ace

Pro

toco

ls

NAS streamspecific functions

ProcedureControl

Functions

Frame HandlerFunction

NAS streamspecific functions

ProcedureControl

Functions

Frame HandlerFunction

RNC MSC|SGSN

figure 5 Functional architecture of Iu UP protocol for support mode.



1.2 Iu UP Support Mode Procedures

1.2.1 User Plane Initialization When a new RAB is established, the RANAP message RAB Assignment Request contains in the user plane information parameter the configuration of the Iu UP protocol. If this parameter indicates the support mode for predefined SDU sizes, there will be an initialization procedure within the user channel (in-band signaling) after the user channel is set up. The initialization is a procedure of the Iu UP protocol in support mode and is triggered by the RNC with the message Initialization. This message contains the number sub-flows that have been defined. The RNC will give an identifier for each established RAB sub-flow combination, which is called RFCI (RAB sub-flow combination identifier). For each sub-flow combination the size (length) of each sub-flow inside must be indicated. The MSC has to check the transmitted configuration and shall acknowledge it with Initialization Acknowledgement.



Initi

alis

atio

n1

(3).

RANAP: RAB Assignment Request

(Setup: RAB-ID, RAB parameters, User Plane Mode : Support Mode for predefined SDU sizes)

RANAP: RAB Assignment Response

(Setup Acknowledgement: RAB-ID)

INITIALISATION( number of defined sub-flows, RFCI for each sub-flow-combination,

length of each sub-flow in each sub-flow-combination,Inter PDU Transmission Interval IPTI for each sub-flow-combination)

INITIALISATION ACK

RNC MSC|SGSN

figure 6 Initialization procedure.



In general the parameter in the Initialization message can be presented in the following way. From the RAB Assignment Request message the Iu UP protocol gets all the information about sub-flows and sub-flow combinations that are applicable to this RAB (RAB parameters). As already mentioned, each sub-flow occurs in each sub-flow combination, but possibly with different sizes. So the Initialization message will contain for each sub-flow combination a RFCI that is used as unique identifier for this combination. The size of each sub-flow in a combination is indicated. Additionally the IPTI (Inter PDU Transmission Interval) which is the mean time between two consecutive user data frames of one sub-flow combination is indicated. This IPTI is typically the size of the SDU for one sub-flow combination divided by the bit rate of this combination.



Initi

alis

atio

n2

(3).

sub-flow-combination 1

sizeof

sub-flow 1

sizeof

sub-flow 2

sizeof

sub-flow 3

sizeof

sub-flow NIPTI

sub-flow-combination 2

sizeof

sub-flow 1

sizeof

sub-flow 2

sizeof

sub-flow 3

sizeof

sub-flow NIPTI

sub-flow-combination X

sizeof

sub-flow 1

sizeof

sub-flow 2

sizeof

sub-flow 3

sizeof

sub-flow NIPTI

. . .

sf1

sf2

sf3

sfN. . .

. . .

. . .

. . .

RFCI=1

RFCI=2

RFCI=X

N sub-flows

figure 7 Sub-flow combination configuration.



1.2.2 Transfer of User Data When the Iu UP protocol for the RAB is configured, user data can be transported using the Iu UP protocol. Therefore the frame of type Transfer Of User Data is provided. This PDU transports the user data as payload and includes the RFCI that indicates according to which sub-flow combination the payload is built.



Tra

nsfe

r of

Use

rD

ata.

Transfer of User Data(RFCI, payload)

Transfer of User Data

(RFCI, payload)

RNC MSC|SGSN

figure 8 Transfer of user data frames in support mode.



1.2.3 Rate Control Procedure The rate control procedure is used by the RNC to indicate to the MSC which sub-flow combinations are currently allowed and which are currently permitted. This is done using the Rate Control frame of Iu UP protocol, in which a bitmap can be found. This bitmap specifies for each defined sub-flow combination whether it is blocked (b´1) or allowed (b´0). With that the serving RNC is able to control the maximum and minimum data rates by enabling and inhibiting certain sub-flow combinations. Usually this functions works together with the control procedures of the AMR (Adaptive Multi-rate Codec). When and how the serving RNC uses this procedure is operator and manufacture specific. Note that in version 2 of the support mode (UMTS Release 4 and higher) also the MSC can send rate control messages.



Rat

eC

ontr

ol.

Rate Control(RFCI indicator bitmap)

0 0 0 1 1 . . . 11 2 3 4 5 X

RFC X : barred

RFC 5 : barredRFC 4 : barredRFC 3 : allowedRFC 2 : allowedRFC 1 : allowed

...

RNC MSC|SGSN

figure 9 Rate control procedure.



1.2.4 Time Alignment Procedure The RNC has to send the downlink data in radio frames that are periodical time slices of 10 ms. So the sending of data in dedicated channels is in fact synchronous. But the MSC sends the data via the Iu bearer based on ATM, so it is possible that the user data arrives at the RNC at irregular intervals (jitter). To compensate this jitter the RNC maintains a jitter buffer. If the jitter becomes too big, the jitter buffer may have a under-run or a over-run. Therefore the RNC can report to late and to early sending to the MSC. This is simply done by the Iu UP protocol message Time Alignment. This message carries a time alignment value which specifies the to late or to early sending in the range of –40 ms to +40 ms in 500 µs steps.



Tim

eA

lignm

ent.

Time Alignment(time alignment)


(RFCI, payload)bad

timing

Time Alignment Acknowledgement


(RFCI, payload)

adjustedtiming

RNC MSC|SGSN

figure 10 Time alignment for user data with too high jitter.



1.2.5 Error Event Procedure If UE or RNC detect an error in the transmitted downlink data, the error event indication procedure is triggered. The Iu UP protocol provides the Error Event message for this. This message contains an error cause (e.g. wrong SDU sizes, undefined RFCI, etc.) and an error distance. The error distance specifies who detected the error. The error distance 0 is a local error detected by the Iu UP protocol in the RNC. If the failure is detected by other protocols in the RNC (e.g. AMR codec) the error distance is set to 1, if the error indication comes from the UE the error distance is set to 2.



Err

orE

vent

.

Error Event(error cause, error distance)

RNC MSC|SGSN

figure 11 Error event indication.



1.3 Frame Quality Classification Function The frame quality classification function is available in the support mode for predefined SDU sizes only. The function consists of the following features : • CRC check : The Iu UP protocol can perform a cyclic redundancy check for the user

data payload on Iu. • frame quality classification : The Iu UP protocol layer can divide the received frames

in categories of frames without errors (good), frames with bit errors (bad) and frames with bit errors resulting from air interface problems (bad due to radio).

• On basis of the RAB configuration, frame quality classification and CRC check the Iu

UP protocol can decide to discard or deliver the frame. The exact behavior and applicability of these features is configured during RAB establishment. The parameter that is responsible for this is the Delivery Of Erroneous SDU element in the RAB parameters. This parameter can be set individually for each defined sub-flow. The Delivery Of Erroneous SDU parameter can have three different values: • YES : The CRC check for payload will be performed by Iu UP protocol, and all three

features are applicable. Frames with and without errors will be delivered to the higher layers (e.g. AMR codec).

• NO : The CRC for payload will be performed by Iu UP protocol, and all three

features are applicable. But only frames without bit errors will be delivered, whenever bit errors are detected (by CRC or frame quality classification) the frame will be discarded.

• NO ERROR DETECTION CONSIDERATION : If this is the value of the parameter,

the Iu UP protocol will not perform the CRC check for payload. Also the frame quality classification is not used, instead each user data frame will be delivered without any error detection consideration.

This parameter must be set for each sub-flow individually. But the Iu UP protocol will treat all sub-flows in a sub-flow combination in the same way. This is done in the



following way. If the Delivery Of Erroneous SDU parameter of at least one sub-flow is NO, all sub-flows are handled in this way. If the Delivery Of Erroneous SDU parameter of at least one sub-flow is YES, but for no sub-flow the Delivery Of Erroneous SDU parameter is NO, all sub-flows are treated like Delivery Of Erroneous SDU parameter is YES. If for all sub-flows the Delivery Of Erroneous SDU parameter is NO ERROR DETECTION CONSIDERATION then all sub-flows are handled according to this.

Radio Access Bearer

Traffic Class Asymetry Max. Bitrate Guaranteed Bitrate

Delivery Order Max. SDU-Size Transfer Delay Priority

SDU Error Ratio

Bit Error Ratio

Delivery of erroneousSDUs

Size of subflow SDUin each combination

Sub-Flow 1SDU Error Ratio

Bit Error Ratio

Delivery of erroneousSDUs

Size of subflow SDUin each combination

Sub-Flow x

. . .

Fra

me

Qua

lity

Cla

ssifi

catio

n fu

nctio

n1-

CR

Cer

ror

prot

ectio

n ac

tivia

tion/

deac

tivat

ion.

.

Delivery Of Erroneous SDU::= ENUMERATED{yes,no,no-error-detection-consideration

}

Payload CRC applicable

Payload CRC not applicable

figure 12 Parameter in RAB Assignment Request to control the frame quality classification.



1.3.1 Downlink User Data Handling The handling of the downlink user data is simple. When the MSC wants to send a downlink user data SDU, it shall evaluate the Delivery Of Erroneous SDU parameter for this sub-flow. If at least for one sub-flow Delivery Of Erroneous SDU = YES or NO, the MSC shall calculate a CRC over the payload and transmit it in the user data frame (Transfer of User Data). The frame quality classification is always set to good, because user data from the MSC has no bit errors by definition. The RNC receives the user data frame and shall evaluate the CRC if it is included. In case bit errors (from Iu interface) are detected, the frame is always discarded, regardless of the value of the Delivery Of Erroneous SDU parameters.



Fra

me

Qua

lity

Cla

ssifi

catio

n fu

nctio

n2

-do

wnl

ink.

Transfer of User Data(RFCI, payload, FQC = good, payload CRC)

FQC ( Frame Quality Classification )[ 0= frame good, 1= frame bad, 2= frame bad due to radio ]

RNC discards the frame whenpayload CRC present and bit

errors are detected with it.

CN

Menu

UE RNC

figure 13 Downlink user data handling.



1.3.2 Handling of Uplink User Data In case of uplink data the Iu UP protocol behavior is a little bit more complex. This is because now we can have errors from the radio interface and errors from the Iu interface. In the RNC the following can is done : • frame quality classification according to the information received from the radio

protocols, • decision to discard or deliver the frame, • calculation of a CRC for the payload if applicable. In the MSC the following can happen : • checking of frame quality classification, • checking of CRC if there is one, • decision to discard or deliver the frame.



Fra

me

Qua

lity

Cla

ssifi

catio

n fu

nctio

n3

-up

link.

TNL SAP

RNL SAP

Iu

TNL SAP

Rad

io In

terf

ace

Pro

toco

ls

Radio framequality classification

Add payload CRCif needed, set FQC

discard frame?

No

check payload CRCif present, check FQC

deliver frame?

Yes

RNC MSC|SGSNdata with FQC

figure 14 Uplink user data frame quality handling.



1.4 Frame Formats

1.4.1 Transfer of User Data (PDU Type 0 and 1) The Iu UP protocol provides two frames (PDU types) for the transport of user data payload. These two frames are • PDU type 0 : PDU type 0 allows a CRC to be transmitted for the payload. • PDU type 1 : In contrast to type 0 there can be no CRC for the payload in a PDU

type 1. Common elements of both frame types are : • PDU type indication : Distinguishes between PDU type 0 (with payload CRC), PDU

type 1 (without payload CRC) and PDU type 14 (control messages of Iu UP protocol).

• Frame Number : This field works as a sequence number for the user data frames. It

is a strictly increasing number. • FQC (frame quality classification) : The FQC classifies the frame quality according

to good (b´00), bad (b´01) and bad due to radio (b´10) frames. • RFCI (RAB sub-flow combination identifier) The payload that is transported by the frame is not required to have length that is an integral multiple of 8 bits. But always the Iu UP protocol pads the missing bits such that the payload is aligned to octet boundaries. For future compatibility the frames contain a so called spare extension. This extension is currently not used and not transmitted. In future versions it might happen that additional parameters are transmitted in this extension.



7 6 5 4 3 2 1 0

PDU Type (0000) Frame Number

FQC RFCI

Header CRCPayload

CRCPayload CRC

Payload

Payload Padding

Spare Extension (0..4 octets)

IuU

ser

Pla

ne p

roto

col f

ram

es: T

rans

fer

Of U

ser

Dat

e (P

DU

Typ

e 0

and

1).

7 6 5 4 3 2 1 0

PDU Type (0001) Frame Number

FQC RFCI

Header CRC spare

Payload

Payload Padding


figure 15 PDU Type 0 and 1 for transfer of user data.



1.4.2 Control Frames (PDU Type 14) For control messages that do not carry user data inside the PDU type 14 is used. This frame format consists of • ACK/NACK : This field indicates whether the control message is a procedure request (b´00), positive acknowledgement (b´01), negative acknowledgement (b´10).

• Sequence Number : The sequence number for PDU type 14 is used as a

transaction identity. An acknowledgement shall use the sequence number of the corresponding request. The sequence numbers of requests shall be increasing numbers.

• Iu UP mode version : This four bit field indicates the version of the used Iu UP

mode. Currently only the value b´0000 (version 1) is used. • Procedure Indicator : The procedure indicator differentiates between Initialization procedure (b´0000), Rate control procedure (b´0001), Time alignment procedure (b´0010), Error event indication (b´0011).

The rest of the frame is used for the parameters that are specific to the procedure.



figure 16 Control frame format of Iu UP protocol (PDU Type 14).

payload CRC

SequenceNumber

7 6 5 4 3 2 1 0

PDU Type (1110) ACK/NACK

Iu UP modeversion

Procedure Indicator

Header CRC payloadCRC

Procedure Data


IuU

ser

Pla

ne p

roto

col f

ram

es: C

ontr

olF

ram

e (P

DU

Typ

e14)

.



1.4.3 Example of Formatted Frame The following contains an example of a formatted Iu UP protocol frame. The PDU type is formed by the highest four bits of the first octet. It has the value H`E = d´14 which indicates a control frame. The next two bits form the ACK/NACK field and is b´00 so this frame constitutes a procedure request. The last two bits of the first octet are the sequence number. In the second octet the higher four bits give the user plane mode version which is b´000, so version 1 of the user plane mode is used here. The lower four bits are the procedure indicator. The value b´0001 together with the ACK/NACK field mean a Rate Control message. In the Iu UP protocol specification TS 25.415 the Rate Control message is defined to have only one parameter – a bitmap of allowed and barred sub-flow combinations. The first element of this parameter is an indicator how many sub-flow combinations are indicated. In the actual case this means 3 sub-flow combinations are defined. Then the last octet contains the bitmap beginning from the highest bit. Bit 8 and 7 of the last octet are 0, so RFCI 1 and RFCI 2 are allowed, whereas RFCI 3 is blocked, because bit 6 is 1.



IuU

ser

Pla

ne p

roto

col f

ram

es: R

ate

Con

trol

exa

mpl

e.

payload CRC

7 6 5 4 3 2 1 0

Header CRCpayload

CRC

1 1 1 0 0 0 1 0

0 0 0 0 0 0 0 1

0 0 0 0 0 0 1 1

0 0 1 0 0 0 0 0

PDU type 14=Control, Procedure request

UP mode version 0, Procedure 1 = rate control

spare, 3 RFCIs defined

RFCI 1and 2 allowed, RFCI 3 barred

figure 17 Example of a formatted rate control frame





2 Iu-PS User Plane – GTP-U



2.1 Iu-PS Protocols for User Data Transfer The Iu-PS user plane is responsible to transport packet data between RNC and SGSN for activated PDP contexts. Thus the data is running from UE to SGSN via RNC and then to the GGSN and vice versa. On the radio interface Uu the packet data is transported in the PDCP (Packet Data Convergence Protocol) which performs packet header information compression and decompression. The lower layers of Uu (RLC, MAC and PHY) form the radio bearer that is temporary used as transport resource for the PDP context. The radio bearer is of course part of the radio access bearer RAB that is currently allocated for the PDP context. Note that the PDP context can exist with and without an associated radio access bearer. It can be de-allocated when no user packet data has to be sent. On the Iu-PS interface the radio access bearer is implemented on the user plane by the protocols : • Iu-UP (Iu user plane protocol) : This protocol is at the moment running in transparent

mode only, so there is no functionality provided by this protocol on Iu-PS. • GTP-U (GPRS Tunneling Protocol – User plane) : The GTP-U layer forms data

transport tunnels between RNC and SGSN for each radio access bearer of all PDP contexts. So this protocol tunnels the user packets between RNC and SGSN.

• UDP/IP : These two standard protocols are denoted as path protocols. UDP

provides an unreliable data transport, but as the ATM network is reliable enough, there should be no problem. The IP layer enables the routing between SGSN and RNC as far as this is necessary.

• AAL5/ATM : The AAL 5 layer provides an unacknowledged transport service for

variable bit rate service, especially for bursty traffic. The AAL 5 virtual channels have to be defined by the operator (semi-permanent virtual channels) and are usually end-to-end between RNC and SGSN.



SGSNRNC

GTP-U GTP-U

RLCRLC

MACMAC

PHYPHY

UDP UDP

IP IP

AAL5 AAL5

ATM ATM

PDCPPDCP

RelayRNL-SAP RNL-SAP

Iu Packet Bearer = GTP-TunnelUu Packet Bearer

= Radio Bearer

RNL-SAP : Radio Network Layer Service Access Point

Iu UP Iu UP

GT

P-U

on

the

pack

etor

ient

ed I

u us

er

pla

ne

Menu

UE

figure 18 Packet oriented data transfer over Iu and Uu.



The complete picture of the Iu-PS interface protocol stack shows, that it consists of control and user plane. No network control plane is defined, thus there is no ALCAP (Access Link Control Application Part) involved on Iu-PS. This is, because the AAL5 virtual channels are pre-configured (semi-permanent) and do not need a dynamical set up. Also there is no sub-channeling within an AAL5 virtual channel, this means, all IP packets are equally, statistically multiplexed onto the virtual channel. The differentiation between the data packets of different PDP contexts is done in the GTP-U protocol layer. Hence it is necessary to configure this protocol when a new radio access bearer is set up for a PDP context. But RAB management is a task of RANAP, so it is a task of RANAP (RANAP-RAB management process) to configure the GTP-U protocol after RAB establishment.



NAS signaling / PS user data

Physical Layer

ATM (NNI)

AAL 5 AAL 5

SAAL

MTP 3 B

SCCP

RANAP Iu User Plane Prot.

control plane networkcontrol plane

user plane

radionetwork

layer

transportnetwork

layer

SGSNRNC

IP

UDP

GTP-U

Rel

atio

nbe

twee

n Iu

-PS

cont

rola

ndus

erp

lane

figure 19 Protocol architecture on Iu-PS.



2.2 Tunnel End Points and Tunnel Configuration The GPRS feature of UMTS is built according to the principle of tunneling. This means network protocol packets for an external data network (e.g. IP or PPP datagrams) must be transported through another network (in our case UMTS network). So the tunnel is nothing else than a transport bearer service. The UMTS packet switched bearer services consist of several transport tunnels. A first bearer service is between UE and RNC (radio bearer), the second between RNC and SGSN and a third is between SGSN and GGSN. In this section only the tunnel between RNC and SGSN is of interest, but most of the statements hold for the SGSN-GGSN tunnel too. Each tunnel is identified by its two endpoints. As the tunnels is a transport service specific to a certain PDP context, the protocols GTP-U, UDP and IP have to deal with the definition of the endpoints. Indeed an endpoint is defined as the pair : • IP address of the endpoint node and • TEID (Tunnel Endpoint Identifier) which is a local reference number for the PDP

context chosen by this endpoint node, the address belongs to. So the TEID is unique only together with the IP address.

These two identifiers will be carried in each user data packet, the TEID is contained in the GTP-U part and the IP address will be contained in the IP header of the data frame that carries the tunneled data. With this it is possible to uniquely identify and process the packet. In this you may miss the UDP port number. In UMTS the UDP source port number of a tunnel can vary during time (ephemeral port numbers for source) and the UDP destination port numbers are pre-defined by the GTP-U protocol (port number 2152). When a tunnel is to be set up, it is necessary to indicate IP address and TEID for both tunnel endpoints. All TEID values except TEID = 0 can be used for tunnels. The TEID = 0 is reserved for control procedures of GTP-U (e.g. error indications, path test).



SGSNRNC

IP/ATMnetwork

ATM

AAL 5

IP

UDP

GTP-U

Tunnel Endpoint Tunnel Endpoint

Iu Tunnel (Iu Packet Bearer)

RNC-IP Addr.

UDP Port No.

SGSN-IP Addr.

UDP Port No.

TEIDRNC TEIDSGSN

(TEIDRNC, TEIDSGSN)

Con

cept

of T

unne

lbea

rer

serv

ice

son

Iu-P

S.

figure 20 Tunnel end points and the relevant protocols.



When a PDP context is active a radio access bearer for this context can exist or not. In other words, when no packet user data must be transported the radio access bearer can be released and in the moment packet data must be sent a new radio access bearer will be set up. The radio access bearer for a packet data bearer is from the point of view of RANAP signaling procedure nothing special. The RANAP message RAB Assignment Request is used to trigger the set up of the radio access bearer and the RNC acknowledges with RAB Assignment Response. In the request and response message two parameters are special for packet data bearers set : • Transport Layer Address : This element contains the IP address of SGSN (request)

or RNC (response). • Iu Transport Layer Association : This parameter transports the TEID of SGSN

(request) or RNC (response) to the other side. With this both sides (e.g. RNC and SGSN) have all information to establish the tunnel as a logical transport resource. Any further action is not necessary.



RNC SGSN

RANAP: RAB Assignment Request(Setup: RAB-ID, RAB parameters,

Transport Layer Address = SGSN-IP address,Iu Transport Association = SGSN-TEID,PDP type = protocol to be tunnelled )

RANAP: RAB Assignment Response(Setup Acknowledgement: RAB-ID,

Transport Layer Address = RNC-IP address,Iu Transport Association = RNC-TEID)

Allo

catio

nof

TE

IDs

and

IPad

dre

sse

s fo

r th

e tu

nne

l usi

ngR

AN

AP

.

figure 21 RAB Assignment parameters for configuration of tunnels.



The UDP port numbers for GTP-U messages are handled in the following way. GTP-U two three types of frames are defined : • GTP-U data frames (G-PDU) :

A G-PDU carries user data inside. The destination port number of a G-PDU is always set to d´2152. The source port number is freely chosen by the originator of the G-PDU (ephemeral source port).

• GTP-U request control frames :

A request control frame is used to trigger a signaling procedure. The destination port is again d´2152, whereas the source port is freely chosen.

• GTP-U response control frames :

A response control frames is the answers to a request control frame. The source port of a response control frame is always d´2152 (e.g. this equals the destination port of the associated request control frame) and the destination frame is the source port number of the associated request control frame.

In other words the GTP-U protocol uses port number d´2152, which must always be used for the destination port number in initial messages (G-PDU or request control frame),but the source port number can be chosen freely in initial messages. In response messages the values from the corresponding initial message are taken and interchanged.



RNC (SGSN) SGSN (RNC)

Source Port : X

Dest. Port : 2152GTP-U request message

Source Port : 2152

Dest. Port : XGTP-U response message

Source Port : X

Dest. Port : 2152GTP-U data frame TEID

UD

Ppo

rt n

umbe

r ut

iliza

tion

for

GT

P-U

cont

rola

ndda

ta m

essa

ges.

figure 22 GTP-U within UDP and the associated UDP port numbers.



2.3 GTP-U Procedures

2.3.1 Packet Data Transfer The main task of the GTP-U protocol is to transport packet user data of a PDP context within the associated tunnel on Iu-PS. The G-PDU (GTP – Protocol Data Unit) is responsible for this. This frame is transported within a UDP/IP datagram that contains the IP address of RNC (downlink) or SGSN (uplink) and the UDP destination port (d´2152) and source port (ephemeral). In the header of the G-PDU the TEID of the receiver endpoint is included. Also a sequence numbering for the packet user data is contained in here. The user data itself will be transported as payload in the G-PDU which is also called T-PDU (Transport PDU).



RNC SGSN

[TEIDRNC, sequence number, T-PDU=user data]

G-PDU (RNC-IP-address, source port: X, destination port: 2152)

[TEIDSGSN, sequence number, T-PDU=user data]

G-PDU (SGSN-IP-address, source port: Y, destination port: 2152)

GT

P-U

user

dat

a tr

ans

port

.

figure 23 G-PDU for packet oriented user data transfer.



2.3.2 Error Indication When SGSN or RNC receive a G-PDU for a TEID that is not active, a error notification shall be sent. Therefore the GTP-U protocol contains the Error Indication procedure. This frame is a request control frame which is sent in TEID=0, that has been reserved for control procedures. The error indication frame itself then contains a parameter TEID1, that contains the inactive TEID the G-PDU was received for. When the remote side receives such an error indication, it shall implicitly release the RAB that is associated with the inactive TEID. The PDP context itself is not affected by this.



RNC SGSN

[TEID=0, TEID1 = inactive PDP context]

Error Indication

[TEID=0, TEID1 = inactive PDP context]

Error Indication

releaseRAB

releaseRAB

!PDP contextnot released

GT

P-U

erro

r in

dica

tion

for

inac

tive

TE

IDs.

figure 24 GTP-U Error indication for inactive PDP contexts.



2.3.3 Path Test Procedure RNC and SGSN periodically test whether their counterpart is still active. This procedure is the path test or echo procedure. The node that starts a path test, will send a GTP-U control frame of type Echo Request with TEID = 0. The remote side has to response with a frame Echo Response.



RNC SGSN

[TEID=0]

Echo Request (RNC-IP-address, source port: X, destination port: 2152)

[TEID=0]

Echo Response (SGSN-IP-address, source port:2152, destination port:X)

[TEID=0]

Echo Request (SGSN-IP-address, source port: Y, destination port: 2152)

[TEID=0]

Echo Response (RNC-IP-address, source port:2152, destination port:Y)

Pat

h a

vaila

bili

tyte

stw

ithG

TP

-U e

cho

proc

edur

e.

figure 25 Echo request for path test procedure.



2.4 GTP-U Frame Format The GTP-U frames are transported in UDP/IP datagrams. The IP protocol can be of version 4 or 6. In any case the IP header carries the source and the destination IP address used for IP routing between RNC and SGSN if it is necessary. The UDP header includes the UDP port numbers as they have been discussed before. The GTP frame follows as data part of the UDP frame. The GTP frame contains the TEID of the destination node.



0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

IP version header length type of service total lengthdatagram identification flags fragment offset

time to live protocol (H´11=UDP) header checksum

source IP address

UDP source port number

destination IP address

options (e.g. time stamps, route records, security info)

IPv4header

UDP destination port numberUDP datagram length UDP checksum

UDPheader

versionPT 0 E S PN GTP message type GTP message lengthTunnel Endpoint Identifier (TEID)

Sequence Number N-PDU number next extension header

extension header length extension header content extension header content=0

GTP message parameters/data

GTPmessage

PT = Protocol Type (1=GTP; 0=GTP´)version = 001 (TS 29.060 V3.x.y)E = extension header field indicatorS = sequence number indicatorPN = N-PDU number indicator

IP/U

DP

/GT

Phe

ader

son

Iu.

figure 26 IP/UDP/GTP frame layout.



The GTP-U frame contains the following elements : • version (3): The version field indicates the differentiates between different GTP

versions. UMTS must use GTP version 2 (b´001) or higher. GTP version 2 is specified in TS 29.060 V3.x.y. GPRS/GSM can use GTP version 1 (b´000) which has been specified in GSM TS 09.60.

• PT (Protocol Type) (1): The protocol type distinguishes between GTP (b´1) and GTP' (b´0) used between GSN and charging gateway function, and thus is a charging data protocol.

• E (Extension Header Flag) (1): This bit indicates whether the octet 12 of the header shall be evaluated (b´1) or not (b´0)

• S (Sequence Number Flag) (1): This bit indicates whether the octets 9 and 10 shall be evaluated (b´1) or not (b´0).

• PN (N-PDU Number Flag) (1): This bit indicates whether the octet 11 shall be evaluated (b´1) or not (b´0).

• Message Type (8): The message type differentiates between the following frame types: G-PDU (H´FF), Echo Request (H´01), Echo Response (H´02), Error Indication (H´1A), Supported Header Extension Indication (H´1F).

• Length (16): These two octets indicate the length of the payload (without GTP header) in bytes.

• TEID (Tunnel Endpoint ID) (32): The tunnel endpoint identifier of the destination. • Sequence Number (16): The sequence number is a strictly increasing label for each

G-PDU. For control message frames the sequence number is used as a transaction identifier (in other words: request and response have the same number). The sequence number is must be present when one of the E, S or PN bits are set. The sequence number shall be used only when the S bit is set.

• N-PDU Number (8): The N-PDU number represents a sequence number for network protocol data units (e.g. IP datagrams for external network). It is used during inter-SGSN routing area updates and inter-system handovers to support loss-less data transmission. This field must be present when one of the bits E, S or PN is set, this field shall be evaluated only when the PN bit is set.

• Next Extension Header Type (8): This field is used to indicate which extension header follows after the standard header. The value H´00 indicates that no extension header follows, H´01 means the PDCP number extension header. This field must be present when one of the bits E, S or PN is set and shall be evaluated only when the E bit is set.

After the header follows then either the payload (no extension header indicated) or an extension header.



8 7 6 5 4 3 2 1version

Message Type

Length

Tunnel Endpoint ID(TEID)

Sequence Number

N-PDU Number

PT 0 E S PN

Next Extension Header Type

1

2

3

4

5

6

7

8

9

10

11

12

Version : 0 0 1 (GTP V2)PT (Protocol Type): 1=GTP, 0=GTP´E (Extension Header) : octet 12 is validS (Sequence Number): octets 9/10 validPN (N-PDU Number): octet 11 valid

Message Type Code Message Type 0 0 0 0 0 0 0 1 Echo Request 0 0 0 0 0 0 1 0 Echo Response 0 0 0 1 1 0 1 0 Error Indication 0 0 0 1 1 1 1 1 Supported Header Extension Indication 1 1 1 1 1 1 1 1 G-PDU

GT

Phe

ader

and

GT

P-U

rel

evan

tmes

sage

type

cod

es.

Next Header Extension Type

Type

0 0 0 0 0 0 0 0 No more extension headers 0 0 0 0 0 0 0 1 PDCP PDU Number extension header.

figure 27 GTP frame format.



The extension headers of GTP are built according to a model consisting of the following elements : • Extension Header Length (8), • Extension Header Content (N*8) : The extension header content represents the

meaning of this header. It must be an integral multiple number of 8 bits. • Next Extension Header Type (8): This field indicates, what comes after this

extension header. When this field is H´00 the payload will follow. The only extension header that is currently defined is the extension header for PDCP PDU numbers. In case of relocations and associated handovers, this header can be used to support loss-less relocation.



8 7 6 5 4 3 2 1

Extension Header Length

Extension Header Content


8 7 6 5 4 3 2 1

PDCP PDU Number


PDCP PDU number extension headerGeneral Extension Header Layout

0 0 0 0 0 0 0 1

GT

Pex

tens

ion

head

er..

figure 28 Extension header layout and PDCP Number extension header.



Documents

register 7_Iu Interface User Plane Protocols.pdf