U MTS

UE UTRA N SGSN GGSN IP Serv er UE

CHAPTER 3

A pplic ation Lay er

SIP

End-to-End Serv ice

SIP

SIP

Quality of Service
The 3
rd

Trans port Lay er

UDP IP

UDP IP

UDP IP

Sy s tem Lay er

UMTS Bearer Serv ic e

External Bearer Serv ice

Generation system is envisioned as a service driven wireless communication

system. The UMTS infrastructure introduces a wide variety of packet data service ranging from real-time services, as voice over IP, to services with no real-time requirement such as e-mail, web browsing, etc. However, since wireless networks are bandwidth-constrained and operate in error-prone environments, mechanisms need to be put in place in order to manage the availability of these services efficiently. With Quality of Service (QoS) UMTS provides facilities, adequate bandwidth and quality for the end-user and their applications, contributing to fulfil the end-to-end services requirements. From the service perspective, the system architecture proposed by 3GPP is logically divided into layers and bearer services as shown in Figure 3.1. At the first level, the application level, end-to-end service allows communication among a range of networks and terminal equipment. This service uses the bearer services of the underlying networks, UMTS Bearer Service (UMTS BS) and External Bearer Service. The UMTS bearer service contains mechanisms to allocate QoS over UMTS/3G networks consisting of a UTRAN and UMTS CN [27]. Since the UMTS network is typically attached to external network(s), the end-user QoS requirements must be handled at the interface to other networks, too [28]. The IP external bearer service in turn consists of the necessary extension of the UMTS BS to do this. Chapter 2 presented some aspects of the UMTS protocol architecture at the network layer level. However, in this chapter the UMTS Bearer Service is studied in more detail illustrating the QoS mechanisms required in each level and the services. Additional features concerning end-to-end services will also be explained. 21

Netw ork Lay ers

R adio Lay er

Radio A c c es s Bearer

CN Bearer

Trans port R adio Bearer Lay er U TR A F D D /TD D

Iu Bearer Phy s ic al

Bac k bone

Figure 3.1 End-to-end QoS architecture

3.1 UMTS BEARER SERVICE

The UMTS Bearer Service (BS) consists of the Radio Access bearer (RAB) service and the Core Network bearer service (CN BS) [29] according to the functional architecture introduced/described in the previous chapter. Both services reflect the optimised way to set-up and support the Bearer Service over UMTS using the aforementioned control and data protocols. The Radio Access Bearer service (RAB) provides confidential transport of signalling and user data between UE and SGSN with the QoS adequate to the negotiated UMTS BS. This service is based on the characteristics of the radio interface and is maintained for a moving UE. The RAB itself consist of a Radio Bearer Service and and Iu-bearer service. The Radio Link Control layer (RLC) between RNC and UE supports the Radio bearer service for both user and control planes providing radio interface transport and error protection. The Iu bearer provides transport services between RNC and SGSN. The Core Network Bearer Service provides transport services within the UMTS core network.

22

On the start of a packet-switched user application, a Bearer Service connection (PDP context with specific Radio Access Bearer and Radio Bearer) needs to be established to enable transfer of data. However, before a RNC can control any requested bearer, it needs to create a signalling connection between the UE and the CN. This connection transfers the higher layer information between entities in the Non Access Stratum. Between the UE and the UTRAN, RNC uses the Radio Resource Control (RRC) connection services in creation the Signalling Radio Bearer (SBR), and through the Iu interface a signalling bearer is then created. In this section the functions and procedures required to establish the signalling and bearer connections are described in detail as defined by 3GPP [30].

Once the RRC connection has been established, the UE sends the message RRC Initial
direct transfer to RNC which in turn maps it in the SGSN into a RANAP message (RAN

application part). After that, Authentication is performed and the Bearer Service setup is triggered.

3.1.2 UMTS Bearer Service Management

In the Packet Switched sub-system domain the UMTS bearer service is realised by a packet data protocol (PDP) context. A PDP context describes the quality of the UMTS bearer service (BS) offered to the user for a specific application on a specific NSAPI (Network Service Access Point Identifier). It also contains routing information that is used to transfer the PDP PDUs between the UE and the GGSN. Consequently, every context establishes an association between the UE and CN with a negotiated set of QoS attributes.

3.1.1 Signalling Connection Management

On power on, the UE establishes at most one radio control connection in order to access the UTRAN [21]. The set-up procedure, as shown in Figure 3.2, is always initiated by the UE with the RRC Connection Request message. Upon receiving this message, the RNC transmits a RRC Connection Set-up message to the UE and then the UE changes its RRC state from IDLE to CONNECTED. Finally the UE confirms the RRC connection establishment by sending the RRC Connection Set-up complete message indicating its capabilities. With the Radio Resource Control (RRC) connection one or more Signalling
Radio Bearers (SRBs) are created to transmit RRC signalling.
UE N ode B 1 . R R C C o n n e c t io n R e q u e s t RRC { C C C H ( o n R A C H ) : R R C C o n n e c t io n R e q u e st } 2 . R R C C o n n e c t io n S e t u p RRC { C C C H (o n F A C H ) : R R C C o n n e c t io n S e t u p } RRC RRC RNC

Those contexts are managed by the high-level Session Management (SM) entity and its activity depends on the lower level entities PMM (PS mobility management) and RRC (radio resource control). The SM, located in the UE and GGSN, as a logical entity has two main states, INACTIVE and ACTIVE. In the INACTIVE state, the packet data transfer is not possible whereas in the ACTIVE state it is possible and also valid routing information is present and defined. The Session set-up starts with the UE sending an Activate PDP Context Request message to the SGSN indicating the NSAPI, the PDP Address if static, the Access Point Name and the QoS requested. This request is carried in the RRC payload through UTRAN and to the CN in a RANAP message. Upon receiving the message, the SGSN validates it, according to the subscription records. Subsequently, the SGSN starts the Radio Access Bearer allocation by sending a RAB Assignment Request message over the Iu interface. When the RNC receives the message, the Radio Resource Management Admission Control algorithm checks if the Radio Bearer (RB) for this transaction can be established with the requested

3 . R R C C o n n e c t io n S e t u p C o m p le t e RRC { D C C H (o n D C H ) : R R C C o n n e c t io n S e t u p C o m p le t e } N ode B RRC

QoS parameters. If so, the RB is established with the given parameters. Depending on the bit rate associated with the service the radio bearers may be set-up on RACH/FACH
RNC

UE

(Random access channel/forward access channel) or DCH (dedicated channel). As soon as the UE is able to receive data from the new RB it acknowledges this by sending the Radio

Figure 3.2 - RRC Connection

23

24

bearer set-up complete message to the RNC, which in turn maps it to the CN with a RAB assignment response message. After that the SGSN informs the GGSN about the

3.2 UMTS PROCEDURES

In addition to the establishment of the UMTS bearer service within the PDP context activation procedure, UMTS also supports others QoS management functions in order to control the established bearers. Two main QoS management groups can be differentiated, Mobility Management and Radio Resource Management [26, 30].

downgraded QoS attributes with the Create PDP context request message. Finally, once the RAB is established, the CN confirms the packet session establishment with the Activate PDP context accept message. The procedure is shown in Figure 3.3 [30].
UE N ode B RN C SGSN GGSN

1 . D ir e c t T ra n sfe r: A c tiv a te P D P C o n te x t R e q u e s t
SM

SM

RAB RB
3 . R a d io L ink S e tup N BAP 4 . R e s p o ns e

2 . R A B A s s ignm e nt R e q ue s t RAN AP N BAP RAN AP

3.2.1 Mobility Management

Unlike fixed networks, a mobile network such as the UMTS network requires a set of functions and procedures to manage the subscriber location and mobility together with its identities and security aspects. Those aspects affect the UMTS bearer service and therefore need to be considered in this approach. In order to track the UE, the cells (i.e. NodeBs) in the UMTS service area are partitioned into several groups as shown in Figure 3.4.
LA
RA
URA
Cell
GTP GTP 1 0 . R e s p o ns e

N BAP

N BAP

5 . A L C A P Iub D a ta T ra ns p o rt B e a re r S e tup RRC 6 . R a d io B e a re r S e tup {D C C H : R a d io B e a re r S e tup } RRC 7 . R a d io B e a re r S e tup C o m p le te RRC

RRC 8 . R A B A s s ignm e nt R e s p o ns e RAN AP RAN AP 9 . C re a te P D P C o nte xt R e q ue s t G TP GTP

Cell

URA
Cell Cell Cell

Cell Cell

Cell Cell Cell

Cell

1 1 . D ir e c t T r a n s f e r : A c tiva te P D P C o nte xt SM SM

RA
UE N ode B RN C SGSN GGSN

Cell

URA
Cell Cell Cell Cell

URA
Cell

Cell

Figure 3.3 - PDP Context Activation

Cell

Cell

Cell

Cell

This procedure can also be initiated by the GGSN, through a Network Initiated PDP
Context Activation procedure. On Mobile Terminated sessions, when GGSN receives a
Figure 3.4 - MM logical entities

PDP PDU it checks if a PDP context is established for that PDP address. If no PDP context has been established, the GGSN triggers a PDP Context Activation message by paging the UE to determine if it is reachable. Once a primary PDP context has been established for a given PDP address, a secondary PDP context can be activated. Such context uses the same PDP address and other information associated with the already active PDP context, but may have a different QoS profile. 25

In the CS domain one or more cells under control of a VLR (Visitor Location Register) are mapped into a Local Area (LA) in which a mobile will be registered. Similarly, in the PS domain, the location registration is based on Routing Areas (RA). However, a RA is typically a subset of an LA and cannot belong to two or more LAs. The VLR tracks the LA of an UE whereas the RA is controlled by the SGSN. In addition to this, the cells in an RA

26

are further partitioned into UTRAN Registration Areas (URAs). The URA and the cell of a UE are tracked by the UTRAN. This four-level logical hierarchy acts as a map for RNC and SGSN to control the location of the UE with the Mobility Management procedures.

PMM-IDLE. The UE is attached to the GPRS CN and therefore, both UE and SGSN have established MM contexts. However, a signalling connection (RRC) is not established between both and the UE location is known only by the CN (with accuracy of RA). In this state, the UE is able to receive system information (SGSN paging) and cell broadcast messages. The transition to the PMM-CONNECTED state occurs when the service request procedure is executed to establish the PS signalling connection between UE and SGSN.

3.2.1.1 CN Mobility Management: RA level

The MM protocol state machine in both SGSN and UE perform the mobility management activities for the UE on a RA level. For the UMTS PS service domain, the states in the machine are PMM-DETACHED, PMM-IDLE and PMM-CONNECTED. The MM states are stored in the MM context maintained by the UE and SGSN. Figure 3.5 illustrates the MM state diagrammes and the transitions among them triggered by the specific Location Management procedure(s). Details of the Location Management procedures are presented further on in this section.
MS MM States
PMM DE TACHED

PMM-CONNECTED. PDUs can only be delivered in this state as the PS signalling connection (RRC connection) is established depending on the type of traffic to be transmitted. The SGSN tracks the UE with accuracy of the RA level and the serving RNC is responsible for cell-level tracking. The serving RNC relocation procedure is executed in this state.

3.2.1.2 UTRAN Mobility Management: Cell & URA level

The UTRAN tracking is triggered by the establishment of the RRC connection. This
3G -SGSN MM States
PMM DE TACHE D

connection creates specific Signalling Radio Bearers (SRBs) and traffic dependent Radio Bearers. In the CONNECTED mode, the UE can have different states depending on the

PS Detach PS Attach PS Signalling Connection Release PS Signalling Connection Establish

D etach, PS Attach Reject, R AU Reject

PS Detach PS Attach

Detach, PS Attach Reject, RAU Reject

type of connection it has to the UTRAN as well as the velocity of the UE as illustrates Figure 3.6.
Connected Mode Cell DCH Idle Mode Cell FACH URA PCH
Figure 3.6 - UE RRC States in connected mode

PM M -IDLE SM-AC T IVE or INACT IVE

PM M CONNECTED SM-ACT IVE or INACT IVE

PM M -IDLE SM-ACT IVE or INACT IVE

PS Signalling Connection Release PS Signalling Connection Establish

PM M CONNECTED SM-ACT IVE or INACT IVE

Serving RNC relocation

Cell PCH

Figure 3.5 -PMM States

The MM states are as follows:

PMM-DETACHED. The UE is not known, as it is not attached to the core network, therefore it is not reachable by the network. In this state the MS performs an attach procedure. As the attach procedure establishes the MM context and the PS signalling, it trigger the change to PMM-CONNECTED mode. In this state the SM state is always INACTIVE.

When the connection is established, the state moves from the IDLE state to Cell DCH or Cell FACH connected mode where the UE location is known with accuracy of a cell by the UTRAN.

27

28

In the CELL DCH state the UTRAN has allocated dedicated resources for the connection, a Dedicated Packet Data Channel (DPDCH) and Dedicated Packet Control Channel (DPCCH). Depending on the radio connection, different RRC procedures are executed in this state. For services with high QoS class handovers are performed whereas they may not be completed for the lower QoS class. The UE processes measurement control information received from the RNC. In this state the UE is known by its serving RNC on a cell or active set level.

3.2.1.3 PMM Procedures

The Mobility Management procedures emphasizing PS-based services (PMM) can be grouped into Attach, Location Management and Service Request. Detailed explanation is given in TS 23.060 [30] and TS 24.008 [26]. Security [31] and System Interchange are not discussed here, as they are not relevant for the current investigation.
A. ATTACH

In the CELL FACH state no dedicated physical channel is allocated for the UE, but RACH (Random access channel) and FACH (Forward access channel) common channels are used instead for transmitting both signalling and user data. In this state the UE performs cell reselection. After a Cell Update message is sent, so that the RNC knows the UEs location on a cell level. Once the UE is in the Cell DCH or Cell FACH state but no data is transferred, the UE state will change to Cell PCH or URA PCH state after the inactivity timers expire. Cell and URA PCH states are very similar. However in the URA PCH, the UE execute URA updates, avoiding periodical Cell updates after each cell reselection. If the UE mobility is high its state also changes to URA PCH.

The UE performs a GPRS Attach to the SGSN in order to obtain access to the GPRS services. With the Packet IMSI Attach the valid routing information for the packet switched connection is created in every node involving the packet switched connections, which causes MM context to be established at the UE and the SGSN. During an attach, the UE is authenticated and the HLR is updated with its location information. The main procedures executed during the UMTS GPRS Attach are illustrated in Figure 3.7. The UE first requests a GPRS Attach procedure. As the UE is unknown to the SGSN, the SGSN requests its Identity (IMSI). Upon receipt of UEs identity the Authentication and Equipment check procedures are executed. Then, the SGSN sends an Update Location message to the HLR providing the subscribers IMSI and the new SGSN address. The HLR sends the GPRS Subscription Data in an Insert Subscriber Data message to the SGSN. After that, the new SGSN validates the UE's presence in the RA. If all checks are successful the SGSN constructs an MM context for the MS and returns an Insert
Subscriber Data Ack (IMSI) message to the HLR. Finally, the HLR acknowledges the

In the Cell PCH state, the UEs location is still known on a cell level to the SRNC, but it can be reached only via the paging channel (PCH) and listens to the system information on the broadcast channel. If the UE performs a cell reselection, it moves automatically to the Cell FACH state to execute the Cell Update procedure, after which it re-enters the Cell PCH if no other activity is triggered.

Update Location message to the SGSN after cancelling the old MM context and insertion of a new one are finished. The SGSN sends an Attach Accept to the MS and includes a new P-TMSI (Temporary Mobile Subscriber Identity).

In URA PCH state, the location of the UE is known only at the URA level and hence in order to obtain the cell level location accuracy the UE is paged by the UTRAN/RNC (Iur) on a BCH (Broadcast channel). If the UE performs a cell reselection, the UE checks if the new cell belongs to the same URA. Only if the URA has change, the UE will enter the Cell FACH and execute the Cell procedure.

29

30

UE 1. P S A ttach R eq RRC

RNC

SGSN

HLR

B.

LOCATION MANAGEMENT

Tracking of the UEs location is managed based on the four-levels network structure shown
RRC 2 . I n it ia l U E M e ss a g e RANAP RANAP PM M

in Figure 3.4. Location Update/Management procedures are triggered either because the UE detects a change on its location or because the UE is executing a periodic report to the network [32]. Periodic reports are controlled by timers maintained in both UE and SGSN or
PM M M AP M AP 4 . S e n d A u th I n fo 4. A ck M AP

PM M PM M

3 . I d e n tit y R e q u e st 3 . I d e n t ity R e sp o n se

RNC. Consequently when a timer expires, the UE performs the respective periodic update.
MAP

A PS attached UE, when crossing a cell boundary, performs update procedures for RA, URA and Cell depending on its PMM and RRC states as stated earlier. The procedures considered in this study are the following ones.

PM M PM M

5 . A u t h e n tic a t io n R e q u e s t 5 . A u t h e n tic a t io n R e sp o n s e

PM M PM M 6 . C heck IM E I MAP 6. Ack M AP MAP M AP

C.

CELL/URA UPDATE

Whenever a mobile terminal crosses a cell boundary, a cell update is triggered if the mobile is not engaged in any active data session or call. In addition, if the mobile is also crossing

7 . S e c u rit y M o d e C o m m a n d RRC
R R C /R A N A P

RANAP

SRNC boundaries, the cell update request message triggers SRNC relocation as shown in
7 . S e c u r it y M o d e C o m p le t e
R R C /R A N A P

RRC

RANAP MAP 8 . U p d a t e L o c a tio n M AP M AP MAP 1 0 . U p d a t e L o c a t io n A c k MAP M AP

Figure 3.8. However, a mobile in URA_PCH RRC state, performs URA updates to track the location of the mobile when the mobile crosses an URA boundary. Both update flows are the same except that URA update and URA Update Confirm are the messages exchanged.
UE 1 . C e ll U p d a te RRC { C C C H : C e ll U p d a te } RRC A llo c a te C -R N T I SRNC

9 . I n se rt S u b sc r ib e r D a ta MAP 9. A ck M AP

PM M

11. A ttach A ccept

PM M

PM M UE

1 2 . A t t a c h C o m p le te

PM M SGSN HLR
RRC 2 . C e ll U p d a te C o n firm { D C C H : C e ll U p d a te C o n firm }

RNC

RRC

Figure 3.7 Attach Procedure

UE

SRN C

Figure 3.8 - Cell Update Procedure

31

32

D.

SRNC RELOCATION

Figure 3.10 illustrates the Inter-SGSN relocation. As we can see the flow is similar to the additional messages exchanged between the old and new SGSN. After the Inter-SGSN SRNC relocation the UE performs the RA update.
UE
Source RNC Target RNC Old SGSN New SGSN

When a mobile terminal crosses a RNC boundary, in other words crosses cells that belong to different RNCs, a Serving RNC relocation procedure is triggered. If the new SRNC is connected to the same SGSN as the old SRNC, an Intra-SGSN SRNC relocation is performed otherwise an Inter-SGSN SRNC procedure followed by an RA update is undertaken. Both types of SRNC procedures are combined with a handover procedure if the UE is in Cell DCH RRC state. Figure 3.9 illustrates the Intra-SGSN SRN procedure; steps 5-8 and 13 are only present when the UE in Cell DCH requires handover.
UE N ode B S ou rce N o de B T arg et RNC S ou rce RNC T a rg et
1. D ecision to in itia te S R N S relocation 2 . Up lin k S ig n allin g T r an sfer In d ication

GGSN

1. Decision to perform SRNS relocation

2. Relocation Required

RANAP

RANAP
3. Forward Relocation Request

GTP
SG SN

GTP RANAP

RANAP

4. Relocation Request Establishment of Radio Access Bearers 4. Relocation Request Acknowledge

RANAP
RNSA P

RANAP GTP
5. Forward Relocation Rsp

RN SAP RA N AP

3 . R elocation R equ ired 4. R elocation R eq u est RA NA P

GTP

RA NA P RA NA P

6. Relocation Command

RANAP
7. Forwarding of data

RANAP RNSAP RNSAP RANAP

9. Relocation Detect

5. R a dio L in k S etu p R eq u est N BAP N BA P 6 . R ad io L in k S etup R esp on se N BA P N BA P

RNSAP RNSAP

8. Relocation Commit
7. A L C A P Iu b D ata T r an sp ort B ear er S etup 8. D ow n lin k a n d up lin k syn ch r on isa tion N BA P N BA P 9 . R elocation R eq u est A ck RA N AP RA NA P RA N AP RN SAP 10 . R eloca tion C om m a n d RA NA P 11 . R eloca tion C om m it RNSAP 1 2 . R elocation D etect RA NA P 1 3. R a dio Lin k F a ilu re In dication NBA P 1 4. R N T I R eallocation RRC 15 . R N T I R ealloca tion C om p lete RRC RRC RRC 1 6. R elocation C om p lete RA NA P RA N AP 1 7 . Iu R elease C om m an d RAN A P RA NA P NBAP RA N AP

RANAP
11. Update PDP Context Request

RRC RRC

10. RAN Mobility Information 10. Confirm

RRC RRC

GTP
11. Response

GTP GTP

GTP
12. Relocation Complete

RANAP

RANAP GTP

12. Forward Relocation Complete

GTP GTP
13. Iu Release Command 12. Ack

GTP

RANAP
13. Complete

RANAP RANAP
Target RNC Old SGSN New SGSN

UE

N ode B S ou rce

N ode B T arget

RN C S ou rce

RNC T a rg et

SG S N

RANAP UE
Source RNC

GGSN

Figure 3.9 - Intra-SGSN SRNC relocation

Figure 3.10 - Inter SGSN SRNC relocation procedure

33

34

E.

BRANCH ADDITION

F.

ROUTING AREA UPDATE (RA)

If a mobile is in an active session with an active dedicated RRC Connection (Cell DCH) and crosses cell boundaries, the mobile needs to add a new radio link to its active set. This triggers a branch addition procedure for all sessions that the mobile is engaged in. Figure 3.11 shows the message sequence chart detailing the branch addition procedure.
UE N ode B RNC
D ecisio n to setup n ew R L NBAP S tart R X 2 . R ad io L in k Se tup R esp o n se NBAP 3 . A L C A P Iub B earer Se tup NBAP 1 . R ad io L in k S etu p R eq u est

When a UE moves to a cell which belongs to a new Routing Area, the UE changes its state to PMM-IDLE and a Routing area update is triggered as illustrated in Figure 3.12. Additionally, if the new RA belongs to a new SGSN (inter-SGSN), a GTP context
transfer message and PDP context modification are required.
MS Node B
1-3: RRC Connection Establishment RRC 4: Routeing Area Update Request
RRC/RANAP

RNC

SGSN

NBAP

RANAP

5: Security Mode Command RANAP RANAP RRC RRC 6: Security Mode Command 7: Security Mode Complete RRC RRC 8: Sec Mode Compl RANAP RANAP RANAP RANAP

D C H -F P

4 . D o w nlink Synch ro nisatio n

D C H -F P

RRC
5 . U p link S ynch ro nisa tio n D C H -F P S tart T X 6 . A ctive S et U p d ate RRC { D C C H : A ctive S et U p d ate} 7 . A ctiv e S et U p d a te C o m p lete RRC {D C C H : A ctiv e S et U p d ate C o m p lete} RRC D C H -F P

9: Routeing Area Update Accept

RRC/RANAP

RRC

10: Routeing Area Update Complete

RRC/RANAP

11-12: RRC Connection Release

RRC

MS

Node B

RNC

SGSN

Figure 3.12 - RA Update procedure

UE

N ode B

RNC

Figure 3.11 - Branch addition Procedure

35

36

G.

SERVICE REQUEST

3.2.2 Radio Resource Control & Management

Since the RRC layer handles the major part of the control signalling between the UE and UTRAN by controlling and managing the RBs, it has numerous functions to perform in addition to the signalling establishment mentioned above.

The UE uses the Service Request procedure in order to establish a secure connection with the SGSN and transfer signalling messages (Activate PDP Context Request) or user data through an active PDP context. The UE sends a Service Request message to the SGSN. Then, after performing the security functions, the UE triggers the resource reservation to assign RAB or the PDP Context Activation procedure depending on whether there is an active PDP context or not. Figure 3.13 shows the messages flow for the case where there is an active PDP context.
UE RNC SGSN HLR GGSN

3.2.2.1 Radio Resource Management

Radio Resource Management (RRM) is a collection of procedures UTRAN uses for management of the air interface resources. These procedures handle, for instance, power control, different types of handovers, system load and admission control. Power control is needed to keep the interference level at a minimum in the air interface and to provide the required QoS whereas handovers are needed in cellular systems to handle mobility of users. In addition, in third generation networks, other RRM algorithms such as admission control, load control and packet scheduling, are required to guarantee the QoS and to maximize the system throughput with a mix of different bit rates, service and quality requirements. A more detailed description can be found in [17].

1. RRC Connection Request 1. RRC Connection Setup 2. Service Request 3. Security Functions 4. Service Accept 4. RAB Assignment Request 5. RB Setup 6. RB Setup Complete 6. RAB Assignment Response 7. SGSN-Initiated PDP Context Modification 8. Uplink PDU

3.2.2.2 Radio Resource Control Functions

In addition to managing radio resources, UTRAN control functionality takes care of establishment and maintenance of the radio link between UE and UTRAN.
A.
RNC SGSN HLR GGSN

SYSTEM INFORMATION BROADCASTING & PAGING

UE

System information is used to maintain both the radio connections and also to control the overall operation of the UTRAN. The RNC broadcasts to the UE to assist the UTRAN controlling functions, such as measurements criteria, paging, assistance date for positioning purposes etc. This system information can be received by the UE both in idle and all connected states. Figure 3.14 shows as an example the broadcast of paging information depending on the UE RRC mode (RRC Idle mode, RRC URA or Cell PCH mode and Cell FACH or DCH RRC state).

Figure 3.13 - Service Request procedure (active PDP context)

If the session is initiated by the network (NI PDP Activation) or the SGSN receives a downlink packet for an UE in PMM-IDLE, the Service request is triggered by the paging request procedure.

37

38

UE NODE B
A) UE is in IDLE mode

RNC

RNC
1. Paging RANAP

MSC

For Case C:

An RRC Connection exists and the UE is in Cell_DCH or Cell_FACH state, i.e. DCCH
RANAP

exists. In this case, the RNC sends an RRC Paging Type 2 message on the DCCH.
B. INITIAL ACCESS AND SIGNALLING CONNECTION MANAGEMENT

2. PCCH: Paging Type I RRC RRC

When the UE enters the idle mode by turning on its power, it attempts to make contact with
B) UE is in URA connected mode or in Cell_PCH RRC state 2. Paging Request RNSAP 3. PCCH: Paging Type I RRC 3. PCCH: Paging Type I RRC RRC RRC RNSAP RANAP 1. Paging RANAP

the UTRAN. The UE looks for a suitable cell in the UTRAN and chooses the cell to provide available services, and tunes to its control channel. This process is known as camping on a cell. Then the UE obtains the necessary information (by means of broadcasting) to capture the NodeB controlled by the corresponding RNC. Once obtained, the UE can establish the signalling connection, as explained before. Timers are used to control the time allowed for a UE to execute a RRC connection reestablishment in case of a radio link failure.

C) UE is in cell connected mode with existing DCCH RRC 2. DCCH: Paging Type 2

RANAP

1. Paging RANAP

3.3 UMTS QOS CLASSES

The UMTS Bearer Services are categorized into four traffic classes: conversational, streaming, interactive and background as defined in TS 23.107 [27]. The main

RRC

UE

NODE B

RNC

RNC

MSC

Figure 3.14 - Paging Procedure

distinguishing factor between them is the delay sensitiveness attribute as it is most directly The first message is common for all three cases where the SGSN CN entity sends a RANAP Paging message to the RNCs serving the UEs Routing Area.

related to the connection quality. Nonetheless other factors such as the guaranteed bit rate (bandwidth) and nature of traffic (symmetric/asymmetric) among others have been defined in order to enable more enhanced service differentiation for UMTS bearers. Conversational and Streaming classes are intended mainly to carry real-time traffic flows as both preserve time relation between information elements within the stream. However, the conversational class has stricter and lower delay requirements, which are defined by the human perception of video and audio conversations. On the other hand, Interactive class and Background are principally used by traditional Internet applications such as WWW, Email, Telnet, FTP and Network News. Due to the looser delay requirements, compared to conversational and streaming classes, reduced bit error rates are achieved through channel coding and retransmission. The main difference between interactive and background class is the traffic priority in the scheduler, which assigns the transmission resources.

For Case A:

The UE is in idle mode, and the RNC broadcasts an RRC Paging Type 1 message on an appropriate paging occasion on the PCCH.

For Case B:

An RRC connection exists and the UE is in URA_PCH or CELL_PCH RRC state. A URA may be controlled by different RNCs and the UE might be camping on a cell controlled by a different RNC so the RNC sends a RNSAP Paging Request to the concerned RNCs. The corresponding RNCs then broadcast an RRC Paging Type 1 message as in Case A but only for cells belonging to the URA if the UE is in URA_PCH state, or only in the known cell if the UE is in CELL_PCH state

39

40

Table 3.1 presents the QoS profile parameters for each class.
Table 3.1 - Traffic classes QoS Attributes
Traffic class Maximum bit rate (kbps) Guaranteed bit rate (kbps) Max. SDU size (octets) Residual BER SDU error ratio Transfer delay max value (ms)
-2 -2 -3 -3

Rate (AMR) codec, which supports eight source rates ranging form 4.75 kbps to 12.2 kbps [35]. Those bit rates are controlled by the radio access network making an optimum use of

Conversational < 2 048 < 2 048

Streaming

Interactive

Background

the battery power, bandwidth available and also provides adaptation to changing radio channel conditions through adapting source and channel codec rates for voice. To facilitate interoperability with existing cellular networks, some of the modes are compatible with 2G

< 2 048 overhead

1 500 or 1 502 5*10 , 10 , 5*10 , 10 , 10 , 10 10 , 7*10 , 10 , -4 -5 10 , 10 100

-2 -3 -3 -1 -2 -4 -6 -3

networks. For instance, the 12.2 kbps stream corresponds to the GSM EFR (Enhanced full
4*10 , 10 , 6*10 10 , 10 , 10
-3 -4 -6 -3 -5 -8

rate) codec.

10 , 10 , 7*10 , -3 -4 -5 10 , 10 , 10 250

3.3.1.2 PS Speech Services

A voice service transmitted over the Packet Switch domain, commonly known as Voice over IP, is feasible since UMTS Release 6 provides full Call Control PS capability by using the IETF defined text based protocol, Session Initiation Protocol (SIP). The control of the call relates to inviting and synchronising the various entities involved in the session [36, 37]. It also enables the participants to describe and share information about the characteristics of the terminal equipment and the speech capabilities using the Session Description Protocol (SDP). SIP call control signalling over the GPRS network is carried through a PDP context established for this purpose. As the speech path requires a separate PDP context to the SIP signalling, a user establishes a secondary PDP context to carry voice data once the call setup is finished. In this approach the speech service is carried like packet switched data from the terminal through the network to the Media Gateway (MGW).

By being able to differentiate traffic flows in the network, four application-related service classes can be defined within UMTS accordingly. In this section some services with different traffic characteristics relevant to the current investigation are highlighted. Their performance requirements established in the earlier UMTS specifications are also presented based on the Rel99 3GPP 25.853 [33] and 22.105 [34] standards.

3.3.1 Conversational Class Applications

UMTS most common service using the conversational QoS class is the speech service. The speech service in UMTS can be transmitted using the circuit or packet switched domain depending on the UMTS specification stage it refers to. Earlier UMTS specifications (R99) implemented the speech services using the CS domain, however later versions provide full PS call control capabilities required for voice quality support. As both approaches are relevant to this investigation, a brief call/session control description for both is given in this section.

3.3.2 Streaming Class Applications

This application class is one of the newcomers in data communications, raising a number of new requirements in both telecommunication and data communication systems. Multimedia streaming is a technology that allows compressed live or pre-recorded video and audio content to be delivered to the user in real-time. With streaming, the transfer of data is processed by the user terminal as a steady and continuous stream, being mainly unidirectional. The main characteristic is that the time relations (variation) between information entities (i.e. samples, packets) within a flow must be preserved, although it does not have any requirements on low transfer delay.

3.3.1.1 CS Speech Service

Voice service in earlier UMTS specifications use the CS domain inherited from GSM, however the Call Control (CC) is enhanced to encompass the new radio resource control protocol RRC and UTRAN based mobility as defined in [24.008][26]. A users speech is digitally sampled by the mobile equipment and then coded for transmission. The speech coding used in terminals and the UTRAN is the Adaptive Multi-

41

42

3.3.3 Interactive Class Applications

Interactive traffic is one of the classical data communication modes that at an overall level are characterized by the request response pattern of the end-user. At the message destination there is an entity expecting the message (response) within a certain time. Round trip delay time is therefore one of the key attributes. Another characteristic is that the content of the packets shall be transparently transferred.

0 to 150 ms:

preferred range

<30ms, user does not notice any delay <100ms, user does not notice delay if echo cancellation is provided and there are no distortions on the link 150 to 400 ms: > 400 ms: acceptable range (but with increasing degradation) unacceptable range

The human ear is highly intolerant of short-term delay variation (jitter) it is therefore

3.3.4 Background Class Applications

Data traffic generated by applications such as server-to-server e-mail, SMS and downloading of database data can be delivered in the background since such applications do not require immediate action. Background traffic is one of the classical data communication schemes supporting non-real time services without any special requirement on delay. The scheme is thus delivery time insensitive. Another characteristic is that the content of the packets must be transparently transferred.

paramount that delay variation is maintained as low as possible. A lower limit of 1 ms is suggested as a target. The human ear, on the other hand, is tolerant to certain amount of speech signal distortion and therefore requirements for information loss are less tight. It has been suggested in studies that acceptable performance is typically obtained with frame erasure rates (FER) of up to 3 %. A connection for a conversation normally requires the allocation of symmetrical communication resources, with the average holding time of a call being in the region of 2 minutes.

3.3.5 QoS Performance Requirements for end user applications

This section outlines the expected QoS requirements of typical end user application, set as initial UMTS requirements by 3GPP in specification 22.105 Release 99 [34]. These requirements represent end-to-end performance summarising the major groups of applications in terms of QoS requirement.

3.3.5.2 Interactive Services Requirements

Different data application services are examined such as web browsing and e-mail application services. Although there may be some exceptions, a prime requirement for any data transfer application is to guarantee essentially zero loss of information. At the same time, delay variation is not applicable. The different applications therefore tend to distinguish themselves on the basis of the delay that can be tolerated by the end-user from

3.3.5.1 Conversational/ Real Time Services Requirements

Audio transfer delay requirements depend on the level of interactivity of the end users. To preclude difficulties related to the dynamics of voice communications, ITU-T Recommendation G.114 recommends the following general limits for one-way transmission time:

the time the source content is requested until it is presented to the user. A. WEB BROWSING This category refers to retrieving and viewing the HTML component of a Web page and other components such as images or audio/video clips. From the user point of view, the main performance factor is how fast a page appears after it has been requested. A value of 2-4 seconds per page is proposed, however improvement on these figures to a target figure of 0.5 seconds would be desirable.

43

44

B. E-mail E-mail is generally a store and forward service, which in principle can tolerate delays of several minutes or even hours. However, it is important to differentiate between communications between the user and the local e-mail server and server-to-server transfer. When the user communicates with the local mail server, there is an expectation that the mail will be transferred quite rapidly, although not necessarily instantaneously. Consistent with the research findings on delay tolerance for Web-browsing, a requirement of 2-4 seconds is proposed.

3.3.5.3 Streaming Service Requirements

The resulting overall requirements for this communication scheme is to support streaming real time services having unidirectional data flows with continuous utilisation. The delay requirements are relaxed, as there is no conversational element involved (one-way communication), even more so than for interactive services.

3.3.5.4 Background Service Requirements

In principle, according to the above mention service characteristics, the only requirement for applications in this category is that information should be delivered to the user essentially error free. However, there is some delay constraint, since data is effectively useless if it is received too late for any practical purpose. A. SMS OR OTHER LOW PRIORITY TRANSACTION SERVICES 30 seconds is proposed as an acceptable delivery delay value for the SMS case. B. E-MAIL (SERVER-TO-SERVER) This category is included for completeness, since as mentioned earlier, the prime interest in email is in the access time. There is a wide spread in user expectation, with a median value of several hours.

45