Tài liệu Các mạng UTMS và công nghệ truy cập vô tuyến P6 pdf

The UMTS Network and Radio Access Technology: Air Interface Techniques for Future Mobile Systems Jonathan P. Castro Copyright © 2001 John Wiley & Sons Ltd Print ISBN 0-471-81375-3 Online ISBN 0-470-84172-9   S ERVICE C OMPONENTS IN UMTS 6.1 B ACKGROUND UMTS services will not only offer mobile services supported by 2nd generation systems such as GSM, but will also expand these services to higher rates and greater flexibility. The services evolving in the GSM platform through its Circuit Switched (CS) and Packet Switched (PS) services will continue in UMTS while new services are introduced. Thus, future UMTS services will have user transmission rates from low bit up to 2 Mbps. Although, high rates will occur primarily within indoor environments, there will be substantial increases in rates throughout all environments when compared to the typical 9.4 kbps. Table 6.1 (an extract from Table 2.1) illustrate this increase. Table 6.1 Range of Transmission Rates High level description Maximal bit rate (kbits/s) Maximal speed (km/h) Cell coverage Rural outdoor 144s 500 Macrocell Suburban outdoor 384 120 Microcell Macrocell Indoor/ 2048 10 Picocell Low range outdoor Microcell Then the question of the transmission range for UTMS services, is no longer just what transmission rates, but what type of services, when and where. It is no longer “commu- nications any where any time”, but “what I want when I want where ever I want”. Practically, the exploitation of wider transmission rates will facilitate the expansion of data traffic. As illustrated Table 6.2 there exists a clear trend for the convergence of IP protocol to wireless, or to what we now call wireless IP. The latter will lead to the Wire- less Internet, where about 200 M Internet and 300 M mobile subscribers will merge into 1 billion Wireless Internet users. Table 6.2 Convergence of Internet Protocol (IP) to Wireless Computer: mobility high speed services Telecommunications: mobility wide services Media: mobility personal services Internet access ISDN services Streaming audio Electronic mail Video telephony Video on demand Real time images Wideband data services Interactive video services Multimedia Location services coupled with application servers TV/radio/data contribution and distribution Non-voice services will make demands not only on manufacturers and operators but also from supporting industries, creating a need for new service enablers. However, 232 The UMTS Network and Radio Access Technology such demand will also introduce new challenges and the need for pragmatic integration of services and devices, as well as new data processing and managing techniques. These demands can be summarized as needs as illustrated in Table 6.3. Table 6.3 Needs for Service Providers and Technology Enablers Needs for service providers Needs for technology enablers Strategy for innovative services Well integrated CS and PS system Economic and spectrum efficiency data pipe Advanced value added platforms (e.g. WAP, IS, location services, unified messaging, etc.) Standard interface to phone display Power efficient handsets Dynamic management control points Effective yet very light device OSs New and flexible billing systems Text  speech Perception of market needs Speech  text Personalization Intelligent voice recognition Addressing all user segments Multi-band terminals exploiting software radio New data processing and management techniques Synchronization Cost efficient terminals and devices Pragmatic user interfaces (e.g. efficient portals) Clearly, the challenges cover all main areas of SW/HW and management technology. In the forthcoming sections we will see how UMTS addresses these needs and outline the main approaches and requirements to meet the challenges. 6.2 T HE UMTS B EARER A RCHITECTURE As illustrated in Figure 6.1 after [1], UMTS proposes a layered bearer service architec- ture, where each bearer service on a specific layer offers its individual services based on lower layers. Thus, the UMTS bearer service architecture serves as an ideal platform for end-to-end services providing key features in preceding layers. @I9ÃUPÃ@I9ÃT@SWD8@ VHUTÃ7@6S@SÃT@SWD8@ U@HU à yphy 7rhrÃTrvpr @rhy 7rhrÃTrvpr S69DPÃ688@TT 7@6S@S ÃT@SWD8@ 8rÃIrx 7rhr ÃTrvpr ShqvÃ7rhr Trvpr DÃ7rhr Trvpr 7hpxir IrÃTrvpr VUS6 A99U99 Trvpr Quvphy 7rhr Trvpr U@ HU VUS6 8IÃD 8I B X U@  Figure 6.1 UMTS bearer service architecture. Service Components in UMTS 233 Because of its layered-bearer service architecture UMTS permits users or applications to negotiate, re-negotiate or change appropriate bearer characteristics to carry their in- formation. Negotiations take place based on application needs, network resource avail- ability, and demands of quality of service (QoS). 6.3 Q UALITY OF S ERVICE IN 3 RD G ENERATION N ETWORKS The main four classes of UMTS traffic differentiated by their delay sensitivity are con- versational, streaming, interactive, and background. Conversational classes have higher delay sensitivity than background classes. The first two classes correspond to real time classes, while the 2nd two to non-real time. Table 6.4 illustrates these classes. Table 6.4 QoS Classes in UMTS Traffic class Conversational Streaming Interactive Background Characteristics and applications Preserve time relation between information entities – low delay (e.g. voice, video- telephony) Preserve also time relation between infor- mation entities (e.g. multi- media) Request re- sponse pattern preserving data integrity. (e.g. Internet or web browsing) Connectionless, generally packet communications preserving data integrity (e.g. ftp, email, etc.) 6.4 M ULTIMEDIA T RANSMISSION – UMTS T RAFFIC C LASSES 6.4.1 Conversational Typical speech over CS bearers, voice over IP (VoIP) and video-telephony represent the conversational class, which in turn represent real-time services. The latter corresponds to symmetric traffic with end-to-end delay thresholds below 399 ms. 6.4.1.1 Enabling Speech The adaptive multi-rate (AMR) techniques will enable the UMTS speech codec. This codec consists of single integrated speech codec with eight source rates controlled by the RAN, i.e: 12.2 (GSM-EFR), 10.2, 7.95, 7.40 (IS-641), 6.70 (PDC-EFR), 5.90, 5.15 and 4.75 kbps. The use of the average required bit rate has impacts on interference lev- els, thereby on capacity, and battery life. Logically, lower rates will favour capacity and battery life duration, but not necessary quality. The AMR coder [4] works with speech frames of 20 ms, i.e. 160 samples at a sampling rate of 8000 sample/s. It may switch its bit rate at every frame through in-band signal- ling or through a dedicated channel. It uses Multi-rate Algebraic Code Excited Linear Prediction Coder (MR-ACELP) as a coding scheme. We extract CELP parameters at each 160 speech samples for error sensitive tests. The latter consist of three error classes (A–C), where class A has the highest sensitivity and requires strong channel coding. The AMR speech codec can tolerate about 1% frame error rate (FER) of class A bits without any deterioration of the speech quality. For classes B and C bits a higher FER can be allowed. The corresponding bit error rate (BER) of class A bits will be about 10 ± . 234 The UMTS Network and Radio Access Technology AMR allows an activity factor of 50% (while parties have a telephone conversation), through a set of basic functions:  background acoustic noise evaluation on the Tx to transmit key parameters to the Rx;  Voice Activity Detector (VAD) on the Tx;  a Silence Descriptor (SID) frame that passes transmission comfort noise informa- tion to the Rx at regular intervals. This noise gets generated on the Rx in the ab- sence of normal speech frames. 6.4.1.2 Enabling Circuit Switched Video Telephony Video telephony has higher BER requirements than speech due to its video compression features; however, it has the same delay sensitivity of speech. Technical specifications in [2] UMTS recommend ITU-T Rec. H.324M for video telephony in CS links, while at present there exists two video telephony options for PS links, i.e. ITU-T Rec. H.323 [5] and IETF SIP [7]. The H.323 has similar characteristics to H.324M. The adapted 1 H.324 includes essential elements such as H.223 for multiplexing, H.245 for control. It also includes H.263 video codec, G.723.1 speech codec, and V.8bis. I may have MPEG-4 video and AMR to better suit UMTS services as illustrated in Figure 6.2. Technical specifications include seven phases for a call, i.e. set-up, speech only, modem learning, initialization, message, end, and clearing. Backward compatibility occurs through level 0 of the H.223 multiplexing, which is the same as H.324. WvqrÃDP rvr SrprvrÃhu qryh WvqrÃpqrp C!%"ÃÃHQ@B# TvyrÃQsvyr C!!" Hyvyrvt qryvyrvt GrryÃ Grryà GrryÃ! TrrpuÃpqrp B&!" Ã6HS 6qvÃDP rvr VrÃqhh hyvphvÃU ! rp TrÃpy VrÃvrshpr C!#$Ãpy TrÃpy TSQG6QH prqr C"!#HÃhrh 9hhÃpy W #ÃG6QHÃrp HqrÃW"# W'W'iv sÃQTUI 8rqvt vrshprÃs vryr rx HqrÃpy W!$r QTUI Xvryr 8vpv Tvpurq IrxÃrt BTHÃVHUT rp Figure 6.2 The ITU Rec. H.324 model. _______ 1 Adapted to wireless from what was originally meant for fixed networks. Service Components in UMTS 235 The H.324 terminal has an operation mode for use over ISDN links. Annex D in the H.324 recommendations defines this mode of operation as H.324/I [3]. H.324/I offers direct inter-operability with the H.320 terminals, H.324 terminals on the GSTN, H.324 terminals operating on ISDN, and voice telephones. For seamless data communications between UMTS and PSTNs, the UMTS call control mechanism takes into account V.8bis messages. These messages get interpreted and converted into UMTS messages and V.8bis, respectively. The latter contains identifica- tion procedures and selection of common modes of operation between data circuit- terminating equipment (DCE) and between data terminal equipment (DTE). Essential V.8bis features include:  flexible communication mode selection by either the calling or answering party;  enabling automatic identification of common operating modes;  enabling automatic selection between multiple terminals sharing common tele- phone channels;  friendly user interface to switch from voice telephony to a modem based communi- cations. 6.4.1.3 Enabling Packet Switched Video Telephony The H.323 ITU-T protocol standard for multimedia (and IP telephony) call control en- ables PS multimedia communications in UMTS. The standard:  employs a peer-to-peer model in which the source terminal and/or GW is the peer of the destination terminal and/or GW,  treats gateways (GW) and terminals alike;  requires GWs and terminals to provide their own call control/processing functions;  provides multiple options for voice, data and video communications;  it may employ a gatekeeper function to provide telephone number-to-IP address translation, zone admission control and other resource management functions. Figure 6.3 illustrates the H.323 architecture, which incorporates a family of standards including H225, H245 and H450. As an international standard for conferencing over packet networks H.323:  acts as a single standard to permit Internet telephony products to inter-operate;  also serves as base for standard interoperability between ISDN- and telephony- based conferencing systems; and  has the flexibility to support different HW/SW and network capabilities. The logical channels in H.323 get multiplexed at the destination port transport address level. The transport address results from the combination of a network address and a port identifying a transport level endpoint, e.g., an IP address and a UDP port. Packets having different payload types go to different transport address, thereby eliminating 236 The UMTS Network and Radio Access Technology usage of separate multiplexing/demultiplexing layer in H.225.0. The H.225 standard uses RTP/RTCP 2 for media stream packetization and synchronization for supporting LANs. This usage depends on the usage of UDP/TCP/IP. BER control takes place at lower layers; thus, incorrect packets do not reach the H.225 level. When both audio and video media act in a conference, they transmit using separate RTP sessions, and RTCP packets get transmitted for each medium using two different UDP port pairs and/or multicast addresses. Thus, it does not exist direct coupling at the RTP level between audio and video sessions, and synchronised playback of a source’s audio and video takes place using timing information carried in the RTCP packets for both sessions. Point-to-point H.323 conference occurs with two TCP connections between the two terminals, i.e. one for call set-up connection and one for conference control and feature exchange. The first connection carries the call set-up messages defined in H.225.0, i.e. the Q.931 channel. After a 1 st TCP connection on a dynamic port, the calling parties establish the second TCP connection to the given port, where the 2 nd connection carries the conference control messages defined in H.245. Thus, the H.245 serves to exchange audio and video features in the master/slave context. WvqrÃDP rvr SrprvrÃhu qryh WvqrÃpqrp C!% ÃÃC!%" C!!$ yhr 6qvÃpqrp B& ÃB&!! B&!"  B&!'ÃB&!( 6qvÃDP rvr VrÃqhh hyvphvÃU ! rp TrÃpy VrÃvrshpr C!#$Ãpy 8hyyÃpy C!!$ÃR("  S6TÃpy C!!$ Qhpxr IrxÃrt !B"BÃBQST TrÃpy SrpÃC"!"Ã6rh Figure 6.3 The ITU Rec. H.323 model. 6.4.1.4 Session Initiation Protocol (SIP) The Session Initiation Protocol (SIP) is another alternative to enable PS video- telephony. Developed in IETF by the MMSIC Multiparty Multimedia Session Control group, SIP is an application layer control signalling protocol for creating/modifying and _______ 2 Real-time transport protocol/real-time transport control protocol. Service Components in UMTS 237 terminating sessions with one or more participants, e.g. Internet multimedia confer- ences, Internet telephone calls and multimedia distribution. Participants in a session can communicate via multicast or via a mesh of unicast relations, or a combination of these. See Figure 6.4. SIP corresponds to:  the overall IETF multimedia data and control architecture currently incorporating protocols such as Resource Reservation Protocol – RFC 2205 (RSVP) for reserving network resources;  the real-time transport protocol (RTP – RFC 1889) for transporting real-time data and providing QoS feedback;  the real-advertising multimedia sessions via multicast and the session description protocol (SDP – RFC 2327) for describing multimedia sessions. WvqrÃDP rvr WvqrÃpqrp C!% C!%" C!%"ÃHivWvqr U8QDQÃqvr 6qvÃpqrp B& ÃB&!! B&!"  B&!'ÃB&!(Ã@AS 6qvÃDP rvr VrÃqhh hyvphvÃU ! rp TrÃpy VrÃvrshpr SU8QÃvhy Qhpxr rx UurÃD@UAÃHyvrqvhÃrvhyÃhrh TDQ T6Q T9Q STWQÃvhy TrpvÃvhy SUQphyhv rprvrÃhuÃqryh SU8QÃrqr rÃvhy SU8QÃrqr SUQphyhv rprvrÃhuÃqryh rÃvhy Figure 6.4 The IETF multimedia model. Nevertheless, it does not depend in any of the above for its functionality and operation. SIP transparently supports name mapping and redirection services, thereby allowing the implementation of ISDN and IN telephony subscriber services, and enabling personal mobility. Technically SIP has the following characteristics  called and calling peers can specify their preference of where they would like calls to be connected;  use of user@domain as call addresses and http look alike messages;  only deals with tracking down users and delivering a call to an endpoint, i.e. it is orthogonal to other signalling protocols;  uses servers for redirection (redirect server), user location tracking (registrar), fork request (proxy server);  it does not have address initiation and termination like H.323, but it is widely ac- cepted; 238 The UMTS Network and Radio Access Technology  simple and easy to implement by IP developers. SIP supports five phases of establishing and terminating multimedia calls:  user location Å determination of the end system for connection;  user capabilities Å determination of the media and media parameters for usage;  user availability Å determination of the willingness of the called party to engage in communications;  call setup Å ringing establishment of call parameters at both called and calling party;  call handling Å including transfer and termination of calls. SIP can also initiate multi-party calls using a multi-point control unit (MCU) or fully meshed interconnection instead of multi-cast. SIP vs. H.323 H.323 SIP Standards body ITU-TSG – 16 IETF MMusic Properties Based on H.320 conferencing and ISDN Q.931 legacy Based on Web principals (Internet friendly) Difficult to extend and update Easily to extend and update No potential beyond telephony Readily extensible beyond telephony Complex, monolithic design Modular simplistic design Standards status H.450.x series provides minimal feature set (pure peer approach) No real end-device feature standard yet Adding mixed peer/stimulus ap- proach (inefficient architecture) Many options for advanced telephony features Slow moving Good velocity Industry acceptance Established now, primarily system level Rapidly growing industry momentum (system level) Few if any H:323 base telephones Growing interest in SIP phones and soft clients End-user primarily driven by Micro- soft (NetMeeting), Intel, etc. Undoubtedly, SIP is poised as the most appropriate protocol to enable PS video teleph- ony in UTMS. At this writing, technical bodies are debating the final outcome. From the author’s point of view, it seems evident that SIP would lead to better results and widespread usage of video telephony. 6.4.1.5 Layer Structure Enabling for Multimedia – MEGACO/H.248 MEdia GAteway COntrol (MEGACO) or H.248 is part of the protocols that will facili- tate the control of video telephony on the PS side. Megaco/248 jointly developed by ITU TG-16 and IETF, covers all gateway applications moving information streams from IP networks to PSTN, ATM and others. These include: PSTN trunking, gateways, Service Components in UMTS 239 ATM interfaces, analog line and telephone interfaces, announcement servers, IP phones, and many others. The Megaco IP phone master/slave approach is entirely compatible with peer-level call control approaches such as SIP and H.323. It acts orthogonal to the last two protocols. Megaco/H.248 allows:  profiles to be defined, i.e. permits application level agreements on gateway organi- zation and behaviour to be made for specific application types, thereby reducing complexity;  allows support of multiple underlying transport types (e.g. ALF reliability layer over UDP, TCP), and both text and binary encoding; the latter enables more appro- priate support for a broader range of application scales (e.g. big vs. small gateways) and more direct support for existing systems. 6.4.1.6 IETF Signalling Transport (SIGTRAN) SIGTRAN develops an essential Simple Control Transmission Protocol (SCTP), which we view as a layer between the SCTP user application and an unreliable end-to-end datagram service such as UDP. Thus, the main function of SCTP amounts to reliable transfer of user datagrams between peer SCTP users. It performs this service within the context of an association between SCTP nodes, where APIs exist at the boundaries. SCTP has connection-oriented characteristics but with broad concept. It provides means for each SCTP endpoint to provide the other during association startup with a list of transport addresses (e.g. address/UDP port combinations) by which that endpoint can be reached and from which it will originate messages. The association carries transfers over all possible source/destination combinations, which may be generated from two end lists. As result SCTP offers the following services:  application-level segmentation;  acknowledged error-free non-duplicated transfer of user data;  sequenced delivery of user datagrams within multiple streams;  enhanced reliability through support of multi-homing at either or both ends of the association;  optional multiplexing of user datagram into SCTP datagrams. 6.4.2 Streaming Streaming implies transmitting information continuously in streams. This technique facilitates Internet browsing by allowing displays even before the completion of infor- mation transfer. It has higher tolerance for jitter to support the large asymmetry of Internet applications. Through buffering, the streaming technique smoothes out packet traffic and offers it as it becomes available. Thus, it can support video on demand as well as web broadcast. While both types of video applications can benefit from the same video compression technologies, they differ in the usage of coding, protocols, etc. Thus, we can offer two types of video applications and address or offer services to more than one type of user depending on the transmission rate or delay sensitivity. 240 The UMTS Network and Radio Access Technology 6.4.3 Interactive Logically, we denote interactive to be the dynamic exchange of information through a man–machine interface or machine-to-machine interconnection. The tempo of the dy- namics will depend on the application or the purpose of the device under interaction. In the context of Internet applications like web browsing, the response time will depend on the type of information requested and the quality of the link as well as protocols in use. Delay sensitive applications will demand faster interaction, e.g. emergency devices, system controls, etc. Other applications such location services, games, passive informa- tion centres, etc., will operate within flexible round trip delays. In the forthcoming sec- tion we cover other applications. 6.4.4 Background While the background class still grows with innovative solutions, it remains as one of the traditional data communications techniques. It serves for e-mail, SMS, database inquiry, and information service platforms. Delay does not have critical consequence in this class, although delays of more than a minute will be highly noticeable. But despite the non-demanding round-trip delays, accuracy becomes critical. Thus, the background users expect error-free communications. For example, control mechanisms measuring performance or monitoring actions will need a reliable accuracy when send- ing or transmitting information. 6.4.5 Sensitivity to IP Transmission Impairments To conclude the UMTS traffic classes, in the following we briefly outline some criteria for different applications in the context of the aforementioned classes.  8rhvhy  9hvpÃDrhpv  8rhvhy  WvprÃhqÃvqr  Ã  WvprÃÃvqrÃh  rqvÃr  Ãrp  ihpxtq  hvv  Ãrp  8hqÃÃpy  rtÃryrÃvrÃthr  Trhvt  Srvr  Drhpvr  Uvry  7hpxtq  Ipvvphy  Trhvt  hqvvqr  rhtvt  Ãrp  Qhtr  qyhqvt  Uhhpv  @prpr  7hpxÃrà  hpv  rtÃrhvyÃqryvr  È  È  $È  9y QhpxrÃG  9ÃÃyrhr  hpxrÃy  Figure 6.5 Sensitivity of applications to delay in IP environments. From the algorithmic representation of delays (x-axis) and linear scale of packet loss estimation (y-axis) in Figure 6.5, we can see the sensitivity of applications to IP im- pairments. Clearly, entries below the vertical axis do not tolerate any type of packet lost; e.g. command/control actions in Telnet or interactive games, on-line-banking, e- commerce, etc. Which means that reliable service transmission will imperatively in- clude both delay control and packet transfer integrity. . Low range outdoor Microcell Then the question of the transmission range for UTMS services, is no longer just what transmission rates, but what type of services,. is poised as the most appropriate protocol to enable PS video teleph- ony in UTMS. At this writing, technical bodies are debating the final outcome. From