Tài liệu Điện thoại di động băng thông rộng không dây P5 pptx

BSSGP basically provides: † unreliable transport of LLC data units between the PCU and the SGSN and † flow control in the downlink direction.. The radio access network provides and manag

value is 500 octets, then IP datagrams of 1500 octets will be segmented into three SNDCP data units Each one will be transmitted separately and reassembled by the receiving SNDCP layer

A PDP Context essentially represents a virtual connection between an MS and an external PDN The PDP Context multiplexing is a function that:

† routes each data unit received on a particular PDP Context to the appropriate upper layer and

† routes each data unit arrived from an upper layer to the appropriate PDP Context For example, assume a situation where the MS has set up two PDP Contexts, both with type

IP but with different IP addresses One PDP Context could be linked to a remote PDN A and the other could be linked to a remote PDN B In this case, there are two different logical interfaces at the bottom of the IP layer, one for each PDP Context The SNDCP layer is the entity that multiplexes data to and from these two logical interfaces

The Logical Link Control (LLC) protocol runs also between the MS and the SGSN, and it

is specified in 3GPP TS 04.64 LLC basically provides data link services, as specified in the Open System Interconnection (OSI) seven-layer model In particular, LLC provides one or more (up to 16) separate logical links (LLs) between the MS and the SGSN, which are distinguished into user-LLs (used to carry user data) and control-LLs (used to carry signal-ling)

There can be up to four user-LLs, while there are basically three control-LLs: one for exchanging GPRS Mobility Management (GMM) and Session Management (SM) signalling, another to support the Short Message Service (SMS) and a third to support Location Services (LCS) (see 3GPP TS 03.71) The user-LLs are established dynamically, in the context of the PDP Context Activation procedure [57], and their properties are negotiated between the MS and the SGSN during the establishment phase Negotiated properties typically include:

† the data transfer mode (acknowledged versus unacknowledged);

† the maximum length of transmission units;

† timer values;

† flow control parameters, etc

On the other hand, the control-LLs have pre-defined properties and they are automatically set up right after the MS registers to the GPRS network It should be noted that each user-LL carries data for one or more PDP Contexts, all sharing the same QoS

Control LLs operate only in unacknowledged mode, which basically provides an unreliable transport service On the other hand, user-LLs operate either in unacknowledged mode or in acknowledged mode, depending on the reliability requirements The latter mode provides reliable data transport by:

† detecting and re-transmitting erroneous data units;

† maintaining the sequential order of data units, and

† providing flow control

Another service provided by the LLC layer is ciphering This service can be provided in both acknowledged and unacknowledged mode of operation and, therefore, all LLs can be secured and protected from eavesdropping

The Radio Link Control (RLC) and Medium Access Control (MAC) protocols run between

the MS and the PCU, and they are specified in 3GPP TS 04.60 The RLC provides the procedures for unacknowledged or acknowledged operation over the radio interface It also provides segmentation and reassembly of LLC data units into fixed-size RLC/MAC blocks In RLC acknowledged mode of operation, RLC also provides the error correction procedures enabling the selective retransmission of unsuccessfully delivered RLC/MAC blocks Additionally, in this mode of operation, the RLC layer preserves the order of higher layer data units provided to it Note that, while LLC provides transport services between the

MS and the SGSN, the RLC provides similar transport services between the MS and the PCU The MAC layer implements the procedures that enable multiple mobile stations to share a common radio resource, which may consist of several physical channels In particular, in the uplink direction (MS to network), the MAC layer provides the procedures, including conten-tion resoluconten-tion, for the arbitraconten-tion between multiple mobile staconten-tions, which simultaneously attempt to access the shared transmission medium In the downlink direction (network to MS), the MAC layer provides the procedures for queuing and scheduling of access attempts More details are provided below

The MAC function in the network maintains a list of active MSs, which are mobile stations with pending uplink transmissions These MSs have previously requested permission to content for uplink resources and the network has responded positively to their request Each active MS is associated with a set of committed QoS attributes, such as delay, through-put, etc These QoS attributes were negotiated when the MS requested uplink resources The main function of the MAC layer in the network is to implement a scheduling function (in the uplink direction), which successively assigns the common uplink resource to active MSs in a way that guarantees that each MS receives its committed QoS A similar scheduling function is also implemented in the downlink direction

From the above, it is obvious that, every cell supporting PS services in Gb mode features a central authority, which:

† arbitrates the access to common uplink resources (by providing an uplink scheduling function) and

† administers the transmission on the downlink resources (by providing a downlink sche-duling function)

These scheduling functions are part of the functions required to guarantee the provisioning

of QoS on the radio interface, and are implementation dependent

The Base Station Subsystem GPRS Protocol (BSSGP) runs across the Gb interface, and it

is specified in 3GPP TS 08.18 BSSGP basically provides:

† unreliable transport of LLC data units between the PCU and the SGSN and

† flow control in the downlink direction

The flow control aims to prevent the flooding of buffers in the PCU and to conform the transmission rate on Gb (from SGSN to PCU) to the transmission rate on the radio interface (from PCU to MS) Flow control in the uplink direction is not provided because it is assumed that uplink resources on Gb are suitably dimensioned, and are significantly greater than the corresponding uplink resources on the radio interface BSSGP provides unreliable transport because the reliability of the underlying frame relay network is considered sufficient enough

to meet the required reliability level on Gb

BSSGP provides also addressing services, which are used to identify a given MS in uplink

and downlink directions, and a particular cell In the downlink direction, each BSSGP data unit typically carries an LLC data unit, the identity of the target MS, a set of radio-related parameters (identifying the radio capabilities of the target MS) and a set of QoS attributes needed by the MAC downlink scheduling function The identity of the target cell is specified

by means of a BSSGP Virtual Channel Identifier (BVCI), which eventually maps to a frame relay virtual channel In the uplink direction, each BSSGP data unit typically carries an LLC data unit, the identity of the source MS, the identity of the source cell and a corresponding set

of QoS attributes The mobility management function in the SGSN uses the source cell identity to identify the cell wherein the source MS is located

As shown in Figure 3.6a, the GPRS Tunneling Protocol (GTP) runs between the SGSN and the GGSN In general, however, GTP also runs between two SGSNs GTP provides an unreliable transport function (usually runs on top of UDP) and a set of signalling functions primarily used for tunnel management and mobility management The transport service of GTP is used to carry user-originated IP datagrams (or any other supported packet unit) into GTP tunnels GTP tunnels are necessary between the SGSN and the GGSN for routing purposes [58] They are also necessary for correlating user-originated IP datagrams to PDP Contexts By means of this correlation, a GGSN knows how to treat an IP datagram received from an SGSN, for example to which external PDN to forward this datagram, and an SGSN knows how to treat an IP datagram received from a GGSN (or another SGSN), for example what QoS mechanisms to apply to this datagram, to which cell to forward this datagram, etc

3.4 UMTS Terrestrial Radio Access Network

As discussed before, the UMTS Terrestrial Radio Access Network (UTRAN) [14] is one of the several possible radio access networks (RANs) that could be used in a UMTS network The main purpose of UTRAN is to facilitate the communication between the user equipment and the core network The radio access network provides and manages the wireless resources required for the signalling and user data transmission between the user equipment and the core network As we have already seen in the functional UMTS model, a radio access network is part of the Access Stratum and, therefore, it offers the means for the user to access the services provides by the core network This section describes the fundamental architec-ture of UTRAN, as well as the most significant UTRAN functions

3.4.1 UTRAN Architecture

As illustrated in Figure 3.7, UTRAN is composed of a collection of Radio Network Subsys-tems (RNS), each one connected to the core network through the so-called Iu reference point

An RNS is responsible for managing the radio resources allocated to a number of cells and for the transmission/reception in these cells Every RNS consists of one Radio Network Control-ler (RNC) and one or more Node-Bs As shown in Figure 3.7, the reference point connecting two RNCs is referred to as Iur, while the reference point connecting an RNC with a Node-B is referred to as Iub Each Node-B is controlled by only one RNC and it supports the physical wireless interface with the mobile terminal, i.e the Uu interface As explained in Chapter 2, the Uu interface is based on W-CDMA technology and it supports either Frequency Division Duplex (FDD) mode or Time Division Duplex (TDD) mode

Each RNC is assigned a pool of radio resources (for example frequencies, CDMA codes,

etc.) and is responsible for managing those radio resources and allocating them to the mobile users on a demand basis Each UE connected to UTRAN is served by a specific RNC, which

is called the Serving RNC (SRNC) The SRNS controls the signalling connection between the UE and the UTRAN and it also controls the Iu signalling connection for this UE Formally, the signalling connection between the UE and the UTRAN is called the RRC connection, because the signalling protocol between the UE and the SRNC and the RRC protocol [28]

The RNC that controls a specific set of UTRAN access points, i.e one or more Node-Bs, serves as the Controlling RNC (CRNC) for these Node-Bs There is only one CRNC for any Node-B and that CRNC has the overall control of the logical resources of that Node-B In general, an RRC connection originates at the UE, passes transparently through a Node-B and its CRNC and terminates at the SRNC The SRNC and the CRNC may or may not be implemented in the same RNC node Figure 3.8(a) shows a situation where the CRNC of the illustrated Node-B and the SRNC of the UE correspond to the same RNC node On the contrary, Figure 3.8(b) shows another situation where the CRNC of the illustrated Node-B and the SRNC of the UE correspond to different RNC nodes

It is clear that the role of controlling RNC makes sense only in connection with a specific Node-B, while the role of Serving RNC makes sense only in connection with a specific UE In Figure 3.8(b) the CRNC of Node-B serves as a Drift RNC (DRNC) with respect to the UE In general, a DRNC is the role an RNC can take with respect to a specific RRC connection

Figure 3.7 Network schematic diagram

between a UE and UTRAN An RNC that supports the SRNC with radio resources when the connection between the UTRAN and the UE need to use cell(s) controlled by this RNC, is referred to as DRNC

In this chapter, the UTRAN Iu, Iub and Iur interfaces are collectively referred to as Ix interfaces Below, we describe the general architectural aspects of the Ix interfaces The architectural aspects of the Uu interface are presented in Chapter 2

3.4.1.1 Architecture of UTRAN Ix interfaces

Functionally, the architecture of UTRAN Ix interfaces is decomposed into two layers, the Radio-Network Layer (RNL) and the Transport-Network Layer (TNL) This is illustrated in Figure 3.9 The Radio-Network layer is associated with UTRAN-specific signalling and user-data protocols used between UTRAN nodes, while the Transport-Network layer is associated with the transport mechanisms used to transport information (either signalling or user data) between UTRAN nodes Ideally, these two layers are completely independent and, therefore, the UTRAN-specific protocols can be implemented over several transport mechanisms For instance, one operator may choose to use ATM technology in the Transport-Network layer, while another one may choose IP technology The UTRAN Radio-Network layer has been specified to be independent of the underlying transport mechanisms and thus any transport mechanism can be used in UTRAN, as long as it satisfies the data transmission requirements (e.g delay, throughput, etc) In first UMTS releases, the UTRAN Network-Transport layer is

Figure 3.8 The roles of SRNC and CRNC/DRNC

based on ATM technology, while in later UMTS releases it evolves to also support IP-based transport [29]

One of the key features of UTRAN is that the transport-network layer in the control-plane

is independent (or logically separated) from the transport-network layer in the user-plane This means that the transport mechanisms used to transport signalling are generally different and separate from the transport mechanisms used to transport user data The signalling and data transport mechanisms used across the various interfaces, i.e across Iub, Iur and Iu, will

be discussed later on, when these interfaces are discussed in more detail

As already mentioned above, another key feature of UTRAN is that the radio-network layer and the transport-network layer are fully separated and independent This effectively means that the control- and user-plane functions in UTRAN are fully separated from the underlying transport functions Therefore, the transport functions and the UTRAN-specific control- and user-plane functions can evolve independently

3.4.1.2 Protocol model of Ix interfaces

Figure 3.10 illustrates the general model used to describe the protocol architecture of UTRAN

Ix interfaces This model is composed of a number of horizontal and vertical layers These layers are logically independent from each other and this accounts for a highly modular and expandable architecture Indeed, each module or layer can be replaced or evolve indepen-dently from the rest of the modules and, therefore, future requirements can be addressed be updating only the correct module(s), rather than updating the entire protocol architecture

In the horizontal direction, there is the radio-network layer and the transport-network layer

As already explained, the former entails the UTRAN-specific signalling and user data proto-cols, while the latter entails the underlying transport protocols that transport the UTRAN-specific protocol data units All UTRAN-UTRAN-specific issues are handled only by the radio network layer The transport network layer is based on standard transport technology, such

as ATM and IP

In the vertical direction there are two main planes: the control plane and the user plane,

Figure 3.9 The concept of transport-network and radio-network layers

both extending across the radio-network layer and the transport-network layer The control plane contains a UTRAN Signalling Protocol (RANAP, RNSAP, or NBAP, which will be addressed later) and an associated transport mechanism for the transport of the signalling messages between the UTRAN nodes As discussed later, the UTRAN Signalling Protocols are used for setting up data transports (or data bearers) in the radio network layer

The User plane contains a UTRAN protocol that deal with user-specific data and an associated transport mechanism for the transport of the user-specific data between UTRAN nodes Typical UTRAN protocols that deal with user-specific data (or data streams) include the Medium Access Control (MAC) protocol and Radio Link Control (RLC) protocol As illustrated in Figure 3.10, both Signalling Transport(s) and Data Transport(s) are defined in the Transport Network User Plane because, from the transport network point of view, they both transport protocol units that pass transparently through the transport network In other words, the transport network treats these protocol units as data units that need to be trans-ferred without any interpretation On the other hand, the protocols defined in the Transport Network Control Plane, are Transport-Signalling protocols (generally referred to as ALCAP protocols) that generate signalling messages for controlling the transport network These messages are interpreted by the transport network and are mainly used to dynamically set

up and release virtual channels within the transport network (of course, when the transport network supports virtual circuits) As an example, when a new conversational call needs to be established and the transport network in based on ATM, a new virtual circuit, for example an AAL2 VC, would need to be established between the Node-B and its CRNC This AAL2 VC

is created and controlled by means of the transport-signalling protocol

It should be noted that the Signalling Transport for the UTRAN Signalling Protocol(s) may

or may not be of the same type as the Signalling Transport(s) for the ALCAP

Figure 3.10 General protocol model of UTRAN interfaces

The specific details of the protocol architecture that apply to each UTRAN interface will be discussed later on, when each UTRAN interface is discussed

3.4.2 UTRAN Functions

Below we summarise some of the most important functions provided by UTRAN All these functions are provides by means of several elementary procedures employed in the UTRAN

Ix and Uu interfaces Some of these elementary procedures will be discussed later

3.4.2.1 Information broadcasting

In every cell, UTRAN broadcasts information needed by the mobiles to perform specific tasks, or used to collect specific system information about the network For example, the broadcast information includes the network and the cell identities, information for location registration purposes, specific access rights applicable in a given time, information for trans-mission power control, information regarding the configuration of the transport channels, information for cell selection and cell-reselection, the frequency bands used, etc In addition, physical-layer information is broadcast to aid mobile acquire synchronisation and decode the downlink control channels

3.4.2.2 Security provision

The security mechanisms applied to protect the user data and the signalling information against malicious attacks, are carried out between the mobile and the UTRAN In particular, the UTRAN is responsible for setting up the security mode before any sensitive data is communicated In the context of security both ciphering and integrity protection are provided

3.4.2.3 Mobility management

The main mobility management functionality required for a mobile in CONNECTED mode is provided by the UTRAN For this mobility management the following procedures are provided:

† Radio measurements: The quality of the radio environment provided to a mobile is calculated by means of specific radio measurements, taken on the current and the neigh-boring cells Typical measurements include the signal strength and the estimated bit error rate of the current and the neighboring cells, the estimation of the propagation environ-ment, the received interference level, the Doppler shift, etc

† Handover decision: From the gathered radio measurements the UTRAN estimates the quality of the current radio channel and the quality of the neighboring radio channels Then it compares the overall quality of service provided with the current radio channel with the requested limits and with the estimated quality of service of the neighboring cells Depending on the outcome of this comparison, the UTRAN may activate the handover procedure or the macro-diversity procedureand transfer the communication path to another radio channel in another cell In addition, the UTRAN may activate the handover

procedure to balance the traffic loading between several radio cells In such cases, a mobile

is commanded to move to a neighboring cell, which is less loaded than the current cell and which can also provides accepTable 3.quality of service

† Macro-diversity procedure: Before a mobile is handed over to another radio channel the macro-diversity mode may be activated In this mode, the mobile is assigned an additional radio channel, possibly in another cell, to support the same call Therefore, the information transmitted by the mobile is simultaneously transmitted on two radio channels In addition, the downlink information is transmitted to the mobile by two different radio channels For this macro-diversity technique to work, the UTRAN needs to carry out a macro-diversity combining/splitting function, which combines the two uplink streams into one and splits the downlink stream into two, one for each downlink radio channel

† Handover procedure: This procedure is executed when the current call needs to be switched to another radio channel, which is considered more appropriate The handover procedure is decomposed into several phases First, a handover initiation is executed, which identifies the need for handover to the related elements These elements will need to take some action in order to realise the handover Then, the handover resource allocation takes place wherein the some new resources are allocated and activated to support the call after the handover Subsequently, the handover execution is carried out wherein the mobile is commanded to switch to the new channel When the mobile actually changes channel, the call is switched to the new path, which has already been activated during the handover resource allocation phase Finally, the handover completiontakes place wherein the old resources, which supported the call before the handover, are released It should be noted that, a handover could be hard or soft A soft handover initiates with the activation of the macro-diversity procedure

† Inter-system handover: This procedure enables the handover between radio access networks that support different radio access technologies, e.g between a UTRAN and a GSM BSS

† SRNS relocation: This procedure is typically executed after an inter-RNS soft handover

In such cases, the role of the serving RNS needs to be transferred to another RNS in order

to avoid the inefficient resources utilisation within the UTRAN The SRNS relocation implies that the Iu interface connection point is relocated from one RNS to another

3.4.2.4 Radio resource management

The radio resource management is concerned with the allocation and maintenance of radio communication resources The allocation procedure encompasses:

† the selection of some communication resources from a pool of resources, and

† the signalling procedures to allocate the selected resources to the mobile that requested for them

The maintenance procedure aims to guarantee that the allocated communication resources will provide the requested quality of service This procedure is very important in mobile communications systems where the radio environment is subject to continuous changes and

to interference In a sense, the radio resource management entity maintains a pool of commu-nications resources and receives requests for allocation of new resources or release of already

used resources These requests may originate from the users, who request new calls or release established calls, or from the maintenance process, which modifies the resources allocated to

a user to guarantee accepTable 3.communications quality Some functions related to radio resource management are listed below:

† radio bearer connection setup and release;

† allocation and de-allocation of physical radio channels;

† rf power control and setting;

† radio channel coding control and setting

† In the following two sections we identify two important aspects of the UTRAN:

† The protocol architecture that provides for the separation of the control and the user planes

in UTRAN, and

† the levels of association between the UE and the UTRAN

3.4.3 Control and User Plane Separation in UTRAN

Figure 3.11 illustrates the protocol architecture between the UE and the SRNC This figure hides any details pertaining to Iub and Iur interfaces However, it is implicitly assumed that these interfaces also support separate protocol stacks for the control and the user planes On the UE side, the NAS signalling messages (i.e signalling messages for the CN) is handled by the RRC protocol, whereas the user-data information is handled by the PDCP protocol These protocols, along with the RLC, MAC and the L1 layer are discussed in Chapter 2 On the SRNC side, the NAS signalling messages are relayed from the RRC to the RANAP and subsequently transported to the appropriate CN domain through the Iu signalling transport layer The user data is relayed from the PDCP layer to the GTP-U layer and subsequently to the appropriate CN domain through the Iu data transport layer The details of the Iu signalling transport and Iu data transport, as well as the details of RANAP, will be discussed later on, in the context of the Iu protocol architecture discussion

Figure 3.11 The separation of user-plane and control-plane in UTRAN