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

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 Network Architecture 167 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 resolution, for the arbitration between multiple mobile stations, 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 Broadband Wireless Mobile: 3G and Beyond168 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, Network Architecture 169 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 Broadband Wireless Mobile: 3G and Beyond170 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 Network Architecture 171 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-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, Broadband Wireless Mobile: 3G and Beyond172 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. Network Architecture 173 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 Broadband Wireless Mobile: 3G and Beyond174 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 Network Architecture 175 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. Broadband Wireless Mobile: 3G and Beyond176 Figure 3.11 The separation of user-plane and control-plane in UTRAN. [...]... transport stratum and the radio network layer or radio stratum (see Figure 3.13(b)) This division is consistent with the aforementioned separation of UTRAN architecture into the radio network layer and the transport network layer (see section 3.4.1) The transport stratum depends on the architecture of the transport network, while the radio stratum depends on the architecture of the radio access network (e.g... this interface is based on the W-CDMA technology This technology is used mainly as a radio multiplexing technology, which deals with the way the radio resources are divided and allocated to several mobile users However, W-CDMA also specifies some aspects related to the radio transmission technology In particular, the radio transmission technology should be based on spread spectrum techniques This is in... control-plane messages could be different from the transport stratum used to transport user-plane data In other words, the transport technology could be different between the user-plane and the control-plane In the following two subsections we discuss the protocol architecture of the transport stratum as used in the control and user planes This discussion will be part of the discussion of the overall protocol... illustrates the protocol architecture employed across the Iu-cs interface In the vertical direction, we distinguish the control plane and the user plane These planes include the protocol stacks used to transfer network control messages (i.e signalling) and user data respectively In the horizontal direction, we distinguish the radio stratum and the transport stratum The transport stratum is typically based on... Part (RANAP) However, the user-plane protocols are different in Iu-cs and Iu-ps The Iu interface has been specified so as to satisfy the following requirements: † The Iu must support all service capabilities offered to UMTS users, including: – – – – dedicated circuits, especially for voice; best-effort packet services (e.g Internet/IP); real-time multimedia services requiring a higher degree of QoS (CS/PS... traffic is transported by using protocols and transport channels that are different and independent from the corresponding protocols and channels used to transport the user-plane traffic For instance, when the transport technology is based on ATM, different virtual circuits could be used for control and user plane traffic As we have already discussed, the separation of control and user plane is applied in the... technology is modified, corresponding modifications will be required in the core network to cope with the change of parameters and change of parameter semantics If, on the other hand, the addressing information contains only a generic user identifier, the core network is made independent of the RAN In this case, the same core network can be connected to several RANs, each one possibly based on different RAN... and radio access network As indicated in Figure 3.13(a), the radio access network is typically connected to the core Broadband Wireless Mobile: 3G and Beyond 180 Figure 3.13 Typical physical implementation of Iu (b) The model of Iu functional strata network through a transport network In general, the latter can be based on ATM, IP or any other technology Having this in mind, we can logically divide...Network Architecture 177 It is evident that the control-plane and user-plane transmissions pass through different and separate protocol stacks in each UTRAN node In addition, in the UTRAN transport networks, which are typically based on ATM technology, there are different ATM virtual circuits for the control and user plane traffic Usually, the virtual circuits carrying control plane... assigned a Radio Network Temporary Identity (RNTI) to be used as UE identity on the common transport channels In UTRAN-CONNECTED mode the UE is always in one of the four following RRC states: CELL_DCH, CELL_FACH, CELL_PCH and URA_PCH The RRC state of the UE depends on the UE level of activity on the radio interface and on the requested quality of service Typically, in the CELL_DCH state dedicated downlink . 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. Terrestrial Radio Access Network As discussed before, the UMTS Terrestrial Radio Access Network (UTRAN) [14] is one of the several possible radio access networks