idnits 2.17.1 draft-westberg-rmd-cellular-issues-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == There is 1 instance of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 57 has weird spacing: '...P must provi...' == Line 64 has weird spacing: '...rvation funct...' == Line 516 has weird spacing: '... cannot be pe...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 2002) is 7986 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'AhBe99' -- Possible downref: Non-RFC (?) normative reference: ref. 'KeMc00' -- Possible downref: Non-RFC (?) normative reference: ref. 'WeLi99' ** Downref: Normative reference to an Informational RFC: RFC 2998 Summary: 7 errors (**), 0 flaws (~~), 5 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Cellular RAN Resource Issues June 2002 4 Internet Engineering Task Force D. Partain (ed) 5 INTERNET-DRAFT G. Karagiannis 6 Expires December 2002 P. Wallentin 7 L. Westberg 8 Ericsson 9 June 2002 11 Resource Reservation Issues in Cellular Radio Access Networks 12 draft-westberg-rmd-cellular-issues-01.txt 14 Status of this Memo 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC2026. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet- Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Abstract 36 This memo describes resource management issues that are relevant to 37 the use of IP transport in cellular radio access networks (RANs). 38 The document describes the particular characteristics of these kinds 39 of networks, the requirements applicable to a resource reservation 40 scheme in a cellular RAN, and provides a brief analysis of the 41 applicability of existing solutions to this problem space. 43 Table of Contents 45 1 Introduction ................................................. 3 46 2 Terminology .................................................. 4 47 3 Background and motivation .................................... 4 48 3.1 IP transport in radio access networks ...................... 4 49 3.2 Motivation for this memo ................................... 8 50 4 Network characteristics of cellular access networks today .... 9 51 4.1 General aspects of the network structure ................... 9 52 4.2 High cost for transmission ................................. 10 53 4.3 Transportation of radio frames ............................. 11 54 4.4 Mobility aspect of radio frame transport ................... 13 55 5 Requirements on a Resource Reservation Scheme ................ 13 56 5.1 Main requirement on resource reservation scheme ............ 13 57 5.2 IP must provide same service behavior as the transport 58 networks used today ....................................... 14 59 5.3 Efficient network utilization .............................. 14 60 5.4 Handover performance requirements on resource reservation 61 scheme 62 ...................................................... 15 63 5.5 Edge-to-edge reservations, not end-to-end .................. 16 64 5.6 Reservation functionality in edge nodes versus interior 65 routers ................................................... 17 66 5.7 On-demand and dynamic allocation of resources .............. 18 67 5.8 Unicast and not multicast .................................. 18 68 5.9 A single operator in the RAN ............................... 19 69 5.10 Minimal impact on router performance ...................... 19 70 5.11 Scalably Manageable ....................................... 20 71 5.12 Bi-directional reservations ............................... 20 72 5.13 Support for non-RAN specific traffic ...................... 20 73 6 Evaluation of existing strategies ............................ 21 74 6.1 End-to-end per-flow resource reservation protocol .......... 21 75 6.2 Integrated Services over Differentiated Services ........... 23 76 6.3 Statically-assigned trunk reservations based on Differen� 77 tiated Services ........................................... 25 78 6.4 Dynamic trunk reservations with Aggregated RSVP ............ 25 79 7 Conclusion ................................................... 27 80 8 References ................................................... 28 81 9 Acknowledgements ............................................. 29 82 10 Authors' Addresses .......................................... 29 84 1. Introduction 86 The rapidly growing popularity of IP and its flexibility make it a 87 good candidate to be used for transmission in cellular networks. 89 Using IP-based transport on the wired transmission links in the 90 cellular networks gives operators an opportunity to upgrade their 91 transport network to a packet-based one. When compared with a 92 traditional STM-based system, the gain is seen in the statistical 93 aggregation of traffic that can be done. This results in increased 94 transmission efficiency and reduced leasing cost for the operator. 96 A radio access network (RAN) provides the radio access (e.g., GSM, 97 CDMA, or WCDMA) to mobile stations in a cellular network. To 98 accomplish this, radio frames are transported on the wired links 99 between different cellular-specific nodes in the RAN. The majority of 100 the traffic (up to 100%) is delay-sensitive traffic. 102 The cellular user is unaware of the IP-based transport network 103 underneath, and the service must work the same way as the user has 104 come to expect the cellular services to work in an STM-based 105 transport network. In addition to this requirement, the situation is 106 further complicated by the fact that the RAN is large in terms of its 107 geographic size, the number of inter-connected nodes, and the 108 proportion of real-time traffic. 110 To satisfy the above requirements, it is absolutely critical that we 111 have a simple and scalable bandwidth resource management scheme for 112 real-time traffic in this type of network. 114 In order for real-time services to function satisfactorily in an IP- 115 based RAN, we need to ensure that there are adequate transport 116 resources on the links available in the RAN to handle this particular 117 instance of the service (e.g., a phone call). Note that, in rest of 118 this draft, whenever the term "resources" is used, it refers to 119 bandwidth on the links. 121 If the RAN is bandwidth-limited and does not use any mechanism to 122 limit the usage of the network resources, congestion might occur and 123 degrade the network performance. For example, speech quality might 124 degrade due to packet losses. 126 2. Terminology 128 The following terminology is used in this memo: 130 * BSC: Base Station Controller 132 * RNC: Radio Network Controller 134 * MSC: Mobile Services Switching Center 136 * GGSN: Gateway GPRS Support Node 138 * SGSN: Serving GPRS Support Node 140 * GPRS: General Packet Radio Service, the packet-switched access 141 scheme and service provided in GSM. 143 * GSM: Global System for Mobile Communications 145 * UMTS: Universal Mobile Telecommunications System, the third 146 generation (3G) mobile system based on WCDMA and GSM, 147 specified by 3GPP (third generation partnership project). 149 * radio frame: a short data segment coded/decoded and 150 transmitted/received by the radio base station. 151 It originates from a mobile station or the BSC/RNC. 153 * WCDMA: Wideband Code Division Multiple Access, the 154 radio transmission technology used in UMTS 156 3. Background and motivation 158 The context of the issues described in this document is the cellular 159 radio access network (RAN). This section briefly discusses two 160 examples of radio access networks (for GSM - Global System for Mobile 161 Communication - and for WCDMA - Wideband Code Division Multiple 162 Access) and then outlines the motivation for this memo. 164 3.1. IP transport in radio access networks 166 This section introduces the radio access network and its use of IP 167 transport. A radio access network (RAN) provides the radio access 168 (e.g., GSM, CDMA, or WCDMA) to mobile stations for a cellular system. 169 The boundaries for a RAN are the radio transmission and reception 170 access points (terminated by base stations) at one end and, at the 171 other end, the interfaces to the gateways (e.g., MSC and SGSN/GGSN), 172 which in turn provide connections to the fixed public network. 174 The radio access network consists of a number of nodes as shown in 175 the Figure 1 below. 177 IP IP 178 <---> <---> 180 |---------| |---------| |---------| 181 Mobile v | Base | | | | MSC/ | Fixed 182 stations |--| station |-----| BSC/RNC |-----| SGSN/ |--- public 183 ^ | | ^ | | ^ | GGSN | network 184 | |---------| | |---------| | |---------| 185 | | | 186 Wireless Wired Wired 187 interface interface interface 189 Radio access network 190 <-------------------------------> 192 Figure 1: Typical radio access network and its boundaries 194 The base station provides the radio channel coding/decoding and 195 transmission/reception function to and from mobile stations in its 196 coverage area, which is called a cell. 198 The BSC/RNC controls a number of base stations including the radio 199 channels and the connections to mobile stations. For a WCDMA radio 200 access network, the BSC/RNC provides soft handover combining and 201 splitting between streams from different base stations belonging to 202 the same mobile station. Furthermore, the BSC/RNC is also 203 responsible for the allocation of transport resources within the 204 radio access network. The transport is either between the base 205 station and the BSC/RNC, between multiple BSC/RNCs, or between the 206 BSC/RNC and the MSC/SGSN. 208 The MSC provides, among others things, support for circuit-switched 209 services towards mobile stations including mobility management, 210 access control and call control as well as interworking with external 211 circuit-switched networks such as the public switched telephony 212 network (PSTN). The SGSN/GGSN provide, amongst other things, support 213 for packet switched services towards mobile stations, including 214 mobility management, access control and control of packet data 215 protocol contexts. In addition, the GGSN provides interworking with 216 external packet-switched networks such as the public Internet. 218 The radio access network consists of potentially thousands of base 219 stations and a significant number of BSCs/RNCs. The traffic volume, 220 in terms of voice-traffic, generated by these nodes can vary from a 221 few up to fifty voice calls per base station, and up to several 222 thousand simultaneous calls (Erlang) per BSC/RNC site. Therefore, a 223 router in the network has to handle many thousands of simultaneous 224 flows. 226 The transmission between base stations and the BSC/RNC is usually on 227 leased lines, and this part (due to the wide area coverage of the 228 cellular network) is usually extremely expensive when compared to the 229 cost of transmission in the backbone. Due the number of base 230 stations, the cost for these leased lines can be quite significant. 231 Dimensioning using over-provisioning might therefore be prohibitively 232 expensive, and it is unlikely that the network will be dimensioned 233 without using the statistical properties of traffic aggregation 234 (e.g., Erlang trunking). 236 |--------| 237 | Upper |<--------------------------------------------> towards the 238 | layers | MSC/SGSN/GGSN 239 |--------| |---------|--------| 240 | Radio | | Radio | | 241 | Link |<----------------------------------->| Link | | 242 | Layer | | Layer | | 243 |--------| |---------| | 244 | | |Radio | |<- 245 | | |Physical | Frame | 246 | | |Layer | transp.| 247 | | |-------|--------| |---------| layer | 248 | | | | Frame |<-------------->| Frame | | 249 | | | | transp.| | transp. | | 250 |Radio | | Radio |--------| |---------|--------| 251 |Physical| | Phys. | UDP |<-------------->| UDP | UDP | 252 |Layer |<->| Layer |--------| |--------| |---------|--------| 253 | | | | IP |<->| IP |<->| IP | IP | 254 | | | |--------| |--------| |---------|--------| 255 | | | | Link | | Link |<->| Link | Link | 256 | | | | Layer |<->| Layer | | Layer | Layer | 257 | | | |--------| |--------| |---------|--------| 258 | | | |Physical| |Physical| |Physical |Physical| 259 | | | | Layer |<->| Layer |<->| Layer | Layer | 260 |--------| |-------|--------| |--------| |------------------| 261 Mobile Base station Router BSC/RNC 262 Station ^ ^ ^ 263 | | | 264 Wireless Wired Wired 265 interface interface interface 267 Radio access network 268 <-----------------------------------------------------> 270 Figure 2: Example of a protocol stack in the 271 radio access network (simplified) 273 Figure 2 shows a simplified example of protocol layering when using 274 IP transport in the radio access network. 276 The radio physical layer performs radio transmission and reception 277 functions, including soft handover splitting and combining in case of 278 WCDMA. 280 The frame transport layer is used to transmit radio frames between 281 the base station and the BSC/RNC. A radio frame is a short data 282 segment coded/decoded and transmitted/received by the radio base 283 station at a given point in time. The radio frames must be delivered 284 in a timely fashion with limited delay. Otherwise, the frames are 285 discarded by the base station or RNC/BSC. The traffic is therefore 286 very sensitive to delays. 288 The radio link layer performs segmentation/re-assembly, 289 retransmission and multiplexing/scheduling functions as well as radio 290 resource control. The adaptation of user data performed by the radio 291 link layer depends on the type of radio channel and the type of 292 service. In one case, that very small radio frames might be 293 transferred, while in other cases the packets are significantly 294 larger. 296 Introducing IP in the radio access network implies that an IP QoS- 297 capable domain, e.g. a Differentiated Services domain, will have to 298 be introduced and managed in the radio access network. This domain 299 consists of edge and interior nodes, where the edge nodes are the 300 nodes located at the boundary of the domain. All the nodes which are 301 part of this QoS-capable domain and are not edge nodes are defined as 302 interior nodes. 304 An edge node can be defined as an ingress node, or a node that 305 handles the traffic as it enters the QoS-capable domain. 306 Alternatively, an edge node might be an egress node, or a node that 307 handles the traffic as it leaves the QoS-capable domain. In this 308 memo, an edge node (ingress or egress) is denoted as the first hop 309 router that the base station or BSC/RNC is connected to. The first 310 hop router might be a part of the base station or BSC/RNC. 312 Furthermore, the base station and BSC/RNC must be able to handle 313 algorithms used for purposes other than edge node functionality that 314 are many times more complex than the algorithms required for handling 315 the edge node functionality. Therefore, the edge node functionality 316 will only have minimal impact on the complexity of the base station 317 or BSC/RNC. 319 3.2. Motivation for this memo 321 The issues described in this document concern only the cellular radio 322 access network (RAN). 324 The architecture of the RAN and the nature of the transported data 325 mean that the RAN has different characteristics when compared with 326 other IP-based networks. However, those differences, which are the 327 motivation for this memo, are limited to the domain of the RAN and do 328 not extend into the backbone of the IP network. 330 In order for the transport within the RAN to function satisfactorily, 331 even if the transport network is IP-based, we need to ensure that 332 there are adequate resources in the transport network to meet the 333 needs of the data flows between the nodes within the RAN. 335 Based upon the characteristics of the RAN (described in Section 4 336 below), the current strategies for resource management do not meet 337 the requirements for an appropriate resource management strategy 338 within a RAN. This document seeks to initiate a dialog on how to 339 correct that situation. 341 4. Network characteristics of cellular access networks today 343 Cellular RANs today have a unique set of characteristics compared to 344 other kinds of IP networks. These characteristics result in a set of 345 requirements on any resource reservation scheme that might be used in 346 the RAN. 348 4.1. General aspects of the network structure 350 The network structure for cellular radio access networks can be 351 described as having the following characteristics: 353 * Operator relationship 355 The RAN is typically controlled by a single cellular operator 356 with full control over the network. The IP network used to 357 transport radio frames might be leased from another operator 358 or be built by the same cellular operator. This network 359 could be thought of as an "intranet". 361 * Size of network 363 RANs can be very large routed networks. Networks including 364 thousands of nodes are certainly within reason. 366 * Traffic volume 368 The traffic from a large number of radio base stations 369 needs to be supported by the same transport network. Even 370 if a single radio base station generates a modest volume of 371 traffic, the total number of flows for radio frame transport 372 in the radio access network is very large. 374 * Transmission sharing 376 The network between the BSC/RNC and the base stations is 377 built to support transmission sharing between different 378 nodes even if they are geographically distributed. 379 One transmission link (possibly with redundancy) can 380 support more than one base station. In other words, one 381 piece of hardware can serve more than one base station and 382 therefore can support more cells in one location, such as 383 a three sector site. This means that the cells that are 384 located at the same location will have to compete for the 385 same transmission resources. 387 * Unicast transport of radio frames 389 The transport of radio frames in the radio access network is 390 point-to-point transport. Even if the soft handover splitting 391 in the BSC/RNC is multicast of radio frames in some sense, 392 this is handled above the IP layer by the frame transport 393 protocol. For each radio channel in each base station the 394 frame transport protocol needs a separate flow. Therefore, 395 the frame transport protocol requires unicast transmission 396 from the IP layer. 398 4.2. High cost for transmission 400 The transmission between base stations and the BSC/RNC is usually on 401 leased lines, and this part (due to the wide area coverage of the 402 cellular network) is usually extremely expensive when compared to the 403 cost of transmission in the backbone. Due to the number of base 404 stations, the cost for these leased lines can be quite significant. 405 Even if the cost for the leased line decreases over the years, the 406 "last mile" to the base station is likely to be expensive due to the 407 location of the base station. 409 Cellular RANs are built over a very wide geographic area. There are, 410 of course, many different networks that cover a wide geographic area 411 (e.g., across USA, and the world), but the dispersion of nodes over 412 the area in the RAN case is different. Due to the fact that the base 413 stations are positioned based on a radio network perspective, i.e., 414 radio coverage, and not based on a transmission perspective, a large 415 proportion of nodes are distributed throughout rural and urban areas, 416 not close to installed high-capacity transmission hubs. Even worse, 417 the the base stations could be positioned far out in the countryside. 419 The peak bitrate of the multirate radio channels is selected on- 420 demand. To utilize the bandwidth of the expensive transmission links 421 used for radio frame transport efficiently, dimensioning using over- 422 provisioning might therefore be prohibitively expensive, and it is 423 unlikely that the network will be dimensioned for peak allocation. 424 Dynamic allocation and optimization to reduce the cost are therefore 425 a fundamental requirement. Resource reservations make it possible to 426 have high utilization of the network for real-time sensitive traffic 427 as well as avoiding congestion in the network. 429 4.3. Transportation of radio frames 431 The traffic in cellular access networks is dramatically different 432 from the Internet in general. The Internet primarily supports best- 433 effort traffic today, while the traffic on a RAN is (at least today) 434 largely real-time traffic. The network from the base station to the 435 BSC/RNC is the part of the network that has the highest volume of 436 real-time traffic and where delay must be minimized as much as 437 possible. The reasons for the this are: 439 * End-to-end delay for speech traffic consists of delays in the 440 mobile stations, the RAN and in the MSC (see Figure 1 in 441 Section 3.1). The major portion of delay in the RAN is caused 442 by the radio-related functionality (e.g., interleaving and 443 coding in the base station and adaptation in the BSC/RNC). 444 Therefore, the combined delay in all parts (MSC, radio 445 network, and mobile stations) must be minimized as much 446 as possible to give the end user proper speech quality. 448 * Handover is a major issue. For GSM, with typically multiple 449 handovers per call, excessive delay in the control, e.g. 450 radio network control traffic, of the radio network will 451 cause a longer handover interruption period. The majority 452 of handovers are also made within the radio network. 454 * The transport of radio frames is very delay-sensitive. In 455 the direction from the BSC/RNC to the base station, a radio 456 frame is a short segment of data (payload) to be coded and 457 transmitted on a given radio channel by the base station at a 458 given point in time. In the direction from the base station 459 to the BSC/RNC, a radio frame is a short segment of data 460 (payload) that was received and decoded by the base station 461 at a given point in time and potentially needs to be combined 462 in the BSC/RNC with radio frames received by other base 463 stations at the same point in time as this particular frame. 464 Note that the data segment in a radio frame may contain user 465 data but also control signalling information and the same 466 type of synchronized frame transport is needed for almost 467 all kinds of radio channels and is generally not coupled 468 to the type of service. Therefore, even if an end to end 469 application is best effort, the transport of the radio frames 470 originating from this application might be treated as real-time 471 within the radio access network. 473 The real-time traffic on the RANs is today almost exclusively voice 474 (up to 90% with 10% signalling), but the cellular systems are 475 evolving to provide capabilities for other kinds of real-time traffic 476 (e.g., video). Nonetheless, voice continues to be one of the most 477 important sources of revenue in most cellular environments today. The 478 transport resources are today allocated when the call is accepted, 479 and the radio frame transport over an IP network has to provide the 480 same guarantees. If real-time traffic cannot be engineered to work 481 correctly, the primary revenue stream will disappear. 483 Some of the sources, such as video-based services and gaming, will be 484 able to send data at a variable bitrate at higher rates. For radio, 485 the rates of the radio channels are selected on-demand. In reality, 486 the radio network can support a wide range of partitioning of the 487 radio resources among the different radio channels. A rather large 488 portion of the transmission resources between the base station and 489 BSC/RNC will have to be allocated for such services. To be able to 490 utilize the bandwidth used for radio frame transport efficiently, the 491 same flexibility is required in assignment of the transport resources 492 as in the air-interface. Therefore, statically-assigned resources 493 will induce a cost which is too high for the operator. 495 4.4. Mobility aspect of radio frame transport 497 The mobility of the mobile stations imposes strong requirements on 498 managing the transmission resources available in the RAN, 499 Furthermore, this also implies that there are strong requirements on 500 the RAN's internal signaling and not only on transferring of packets 501 sent by the mobile station. 503 Hard handover is one of the issues. For GSM, with typically multiple 504 handovers per call, excessive delay in the control of the radio 505 network will cause a longer handover interruption period. Typically, 506 most of the handovers will be made between base stations controlled 507 by the same BSC and therefore extensive delay between base station 508 and BSC will degrade more than delays in the MSC and SGSN/GGSN 509 network. 511 Moreover, for maximal utilization of radio spectrum in WCDMA (and 512 also in CDMA), fast and frequent (soft) handover operations between 513 radio channels and radio base stations are required. The frequency of 514 handover events is therefore typically higher in WCDMA radio access 515 networks than in GSM and means even higher performance requirements 516 on the transport solution. If the soft handover cannot be performed 517 fast enough, spectrum cannot be utilized efficiently, which will 518 cause degradation of the radio network capacity. At each handover 519 event, resource reservation is needed, and therefore resource 520 reservation needs to be fast and will be used very frequently. 522 The impact of mobility in the radio access network has therefore two 523 major differences compared to the fixed network: 524 (1) High volume of resource reservation events 525 (2) Requirement on short response time for reservations 527 5. Requirements on a Resource Reservation Scheme 529 This section outlines what we believe are the fundamental 530 requirements placed on any resource reservation scheme in a cellular 531 radio access network. Later sections will outline how current schemes 532 match these requirements. 534 5.1. Main requirement on resource reservation scheme 536 One of the primary requirements that real-time applications impose on 537 any resource reservation scheme is the provisioning of good QoS 538 (delay and packet loss) guarantees. This can only be achieved if the 539 network can be utilized while avoiding congestion and without having 540 too high packet losses. The level of utilization depends on network 541 topology, traffic mix, scheduling discipline, delay and packet loss 542 requirements. The utilization is given by network dimensioning but 543 should be as high as possible. 545 The resource reservation scheme must be able to keep the real-time 546 traffic under a certain pre-defined network utilization in order to 547 bound congestion. Otherwise, it is impossible to guarantee percentile 548 bounds on the QOS requirements for real-time traffic. 550 5.2. IP must provide same service behavior as the transport networks 551 used today 553 Today's commercial IP networks are mainly optimized to carry best- 554 effort traffic. As explained above and also discussed in [WeLi99], 555 the transport of radio frames in the radio access network puts real- 556 time requirements on the underlying transport network. All of these 557 characteristics are fulfilled by the connection-oriented transport 558 networks (STM and ATM) used by cellular networks today. By, at a 559 minimum, meeting these same requirements, the IP networks will be 560 capable of providing the same behavior as the transport networks that 561 are currently used by cellular systems while gaining the advantages 562 of IP networking. It should be noted that IP networks will be able to 563 meet these requirements only if the following two constraints are 564 met: 566 (1) that service guarantees are percentiles, see Section 5.1 567 (2) strictly limited to a given operator's IP network, see 568 Section 5.9. 570 5.3. Efficient network utilization 572 Due to the high cost of the leased transmission, we must utilize the 573 network to the highest degree possible, and this must be facilitated 574 by the resource reservation scheme. 576 However, in considering a resource reservation scheme, its impact 577 upon the performance and scalability of the network as a whole must 578 also be taken into account. For example, the performance and 579 scalability impact on the edge and internal routers is a very 580 important consideration. 582 5.4. Handover performance requirements on resource reservation scheme 584 Whatever reservation scheme is used must be highly performant for at 585 least the following reasons: 587 * Handover rates 589 In the GSM case, mobility usually generates an average 590 of one to two handovers per call. For third generation 591 networks (such as WCDMA and cdma2000), where it is 592 necessary to keep radio links to several cells 593 simultaneously (macro-diversity), the handover rate is 594 significantly higher (see for example [KeMc00]). 595 Therefore, the admission control process has to cope 596 with far more admission requests than call setups alone 597 would generate. 599 * Fast reservations 601 Handover can also cause packet losses. If the processing 602 of an admission request causes a delayed handover to the 603 new base station, some packets might be discarded, and 604 the overall speech quality might be degraded 605 significantly. 607 Furthermore, a delay in handover may cause degradation 608 for other users. This is especially true for radio access 609 technologies using macro-diversity, such as WCDMA and CDMA, 610 where a handover delay will cause interference for other 611 users in the same cell. Furthermore, in the worst case 612 scenario, a delay in handover may cause the connection 613 to be dropped if the handover occurred due to bad radio 614 link quality. 616 Therefore, it is critical that an admission control 617 request for handover be carried out very quickly. Since 618 the processing of an admission control request is only 619 one of many tasks performed during handover, the time to 620 perform admission control should be a fraction of the 621 time available for handover. 623 Furthermore, in the situation that the transport network 624 in the RAN is over-utilised it is preferable to keep 625 the reservation on already established flows while new 626 requests might be blocked. Therefore, the handover 627 requests for resource reservation should be treated 628 with a higher priority than the new requests for 629 resource reservation. 631 5.5. Edge-to-edge reservations, not end-to-end 633 Real-time applications require a high level of quality of service 634 (QoS) from the underlying transmission network. This can only be 635 achieved by accomplishing the QoS management on an end-to-end basis 636 (i.e., end user to end user), from application to application, 637 potentially across many domains. 639 However, this does not mean that the resource reservation protocol 640 must be applied end-to-end. The end-to-end QoS management 641 architecture may consist of many interoperable edge-to-edge QoS 642 management architectures where each of them might use a different 643 edge-to-edge resource reservation protocol. In fact, this is far 644 more likely to be the case than that a global signaling structure 645 will be available across all different domains in an end-to-end 646 perspective. This will increase the flexibility and the openness of 647 the transmission network since various access networks that are using 648 the same transmission network and different edge-to-edge QoS 649 management architectures will be able to interoperate. 651 It is critical that the appropriate mechanisms for providing the 652 service guarantees needed in the radio access network be put in place 653 independently of solving the more difficult problem of end-to-end 654 QoS. 656 In our case, the access network is simply an intranet in which we 657 need to solve a local QoS problem. This implies that a general 658 solution which handles the end-to-end QoS problem is unnecessarily 659 complicated for solving the intranet problem in the cellular access 660 network. 662 5.6. Reservation functionality in edge nodes versus interior routers 664 In our network, it is important that the reservation mechanism be as 665 simple as possible to implement in the interior nodes since in most 666 cases there might be more interior routers (<= 10 depending on 667 network structure) in the path than there are edge nodes. 669 Typically, in a RAN there are two edge nodes located in a 670 communication path. Moreover, the average number of interior nodes in 671 a communication path within a RAN depends on the chosen network 672 topology by the RAN operator. As such, the scheme must be optimized 673 for the interior nodes and not for the edge nodes, thus reducing the 674 requirements placed on the functionality of the interior routers. 675 This means that we can have complicated mapping of traffic parameters 676 at the edges and a simplified model in the interior nodes, and that 677 the necessary set of parameters required for setting up reservations 678 shall be based upon their effect on interior nodes and not on edge 679 nodes. 681 The edge routers typically have to perform per-session 682 management/control, and hence complex per flow handling is not a 683 significant burden. 685 However, interior nodes do not need to have per flow 686 responsibilities. We must therefore optimize for simple QoS 687 mechanisms on these interior devices, and use more complex mechanisms 688 in the edge devices. 690 In our case, edge device functionality is implemented in the first 691 hop router that the base station or BSC/RNC is connected to (see 692 Section 3.1). In this way we optimize for simple QoS mechanisms on 693 the interior devices, while the more complex mechanisms are applied 694 on the edge devices, e.g., base station, BSC/RNC. 696 This emphasis on simplicity is due to performance requirements listed 697 above. We need to make sure that we understand the minimal level of 698 functionality required in the reservation scheme in order to 699 guarantee the performance of real-time traffic. 701 5.7. On-demand and dynamic allocation of resources 703 Real-time services require that a portion of network resources is 704 available to them. These resources can be reserved on a static or 705 dynamic basis, or potentially based on some kind of measurement of 706 network load. 708 In the first situation, this may result in an poorly utilized 709 network. This is mainly due to the fact that the network resources 710 are typically reserved for peak real-time traffic values. Mobility 711 in the network makes static configuration even less desirable as the 712 resources will be used even less effectively. 714 If using dynamic allocation, this problem will be avoided since the 715 resources are reserved on demand. However, the load from resource 716 reservation will be much higher than if static allocation of 717 resources is used. If the dynamic allocation of the resources is 718 done on a micro-flow basis, the resulting network load from resource 719 reservation might be quite high. 721 We might use other methods, such as measurement-based admission 722 control, to simplify the reservation protocol, as long as these 723 methods can fulfill the requirements (now or in the future). 725 What is important is that all of these mechanisms can be used for 726 solving part of the network utilization problem, and, as such, any 727 reservation scheme must have the flexibility to provide both on- 728 demand reservations as well as measurement-based admission control. 730 As high bitrate and variable bitrate applications enter the cellular 731 space, the need for on-demand reservations of resources will become 732 even more acute. 734 5.8. Unicast and not multicast 736 The majority of the traffic in the RAN is point-to-point unicast 737 transport of radio frames between the base station and the BSC/RNC. 738 As such, the resource reservation scheme need not to be optimized for 739 multicast. 741 5.9. A single operator in the RAN 743 It is realistic to assume that end-to-end communication in IP 744 networks as well as the end-to-end QoS management architectures will 745 be managed by more than one operator. 747 Furthermore, it also realistic to assume that an edge-to-edge 748 resource reservation protocol can be managed by one single operator. 749 As such, it is reasonable to limit reservation scheme to a single 750 operator domain. This will ensure that each operator can optimize the 751 edge-to-edge QoS management architecture for their needs. Moreover, 752 this limitation (a single operator domain) means that the reservation 753 scheme does not need to handle the issues inherent in a multi- 754 operator domain, thus simplifying the scheme. 756 5.10. Minimal impact on router performance 758 The performance of each network node that is used in an end-to-end 759 communication path has a significant impact on the end-to-end 760 performance of this communication path. Therefore, the end-to-end 761 performance of the communication path can be optimized by optimizing 762 the router performance. It is absolutely critical that the 763 introduction of QoS mechanisms and signaling does not overly impact 764 the performance of the infrastructure. Obviously, you cannot 765 introduce new things that need to be done by networking 766 infrastructure without impacting its performance, but that impact 767 must be minimized to the greatest extent possible. 769 One of the factors that can contribute to this optimization is the 770 minimization of the resource reservation signaling protocol load on 771 each router. When the dynamic allocation of the resources is on a per 772 micro-flow basis, the resource reservation signaling protocol could 773 easily overload a router located in a core network, causing severe 774 router performance degradation. Furthermore, any mechanisms defined 775 must be such that it is reasonable to implement them in hardware 776 which will increase the scalability of the solution. 778 5.11. Scalably Manageable 780 Any strategy for resource management in a RAN must be done in such a 781 way that it is easily manageable in a very large network. This 782 implies as little "laying on of hands" as possible and as much 783 automation as possible. In networks made up of many thousands of 784 routers, changing of even a single parameter in all routers may be 785 prohibitively difficult. Minimizing the involvement of the operator 786 (or the operator's management tools) is therefore an important 787 requirement. 789 5.12. Bi-directional reservations 791 In current RANs, the BSC/RNC is responsible for initiation of 792 reservation of resources in the transport plane. Therefore, via the 793 resource reservation signaling protocol, the BSC/RNC has to support 794 the initiation and management of the resource reservations for both 795 directions, both to and from the base station, simultaneously. In 796 this way a simpler edge-proxy resource reservation functionality will 797 be implemented in the base station, decreasing its complexity. 799 5.13. Support for non-RAN specific traffic 801 Any strategy for resource management used in a cellular RAN must be 802 able to support any type of traffic (RAN-specific or non-RAN 803 specific) in the same way, as long as the traffic belongs to the same 804 traffic class. 806 The RAN-specific traffic is the traffic that is transported through 807 the RAN and is generated or used by specific entities belonging to 808 the same cellular technology as the one used in the RAN. 810 The non-RAN specific traffic is the traffic that is transported 811 through the RAN but is neither generated by nor used by any specific 812 entity belonging to the same cellular technology as the one used in 813 the RAN. 815 6. Evaluation of existing strategies 817 In order to understand whether technology exists today which will 818 allow us to manage the resources in cellular networks, we briefly 819 look at the protocols that currently exist which address parts or all 820 of these requirements. 822 6.1. End-to-end per-flow resource reservation protocol 824 An end-to-end per-flow resource reservation signaling protocol is 825 applied in an end-to-end IP communication path, and it can be used by 826 an application to make known and reserve its QoS requirements to all 827 the network nodes included in this IP communication path. This type 828 of protocol is typically initiated by an application at the beginning 829 of a communication session. A communication session is typically 830 identified by the combination of the IP destination address, 831 transport layer protocol type and the destination port number. The 832 resources reserved by such a protocol for a certain communication 833 session will be used for all packets belonging to that particular 834 session. Therefore, all resource reservation signaling packets will 835 include details of the session to which they belong. 837 The end-to-end per-flow resource reservation signaling protocol most 838 widely used today is the Resource Reservation Protocol (RSVP) (see 839 [RFC2210], [RFC2205]). The main RSVP messages are the PATH and RESV 840 messages. The PATH message is sent by a source that initiates the 841 communication session. It installs states on the nodes along a data 842 path. Furthermore, it describes the capabilities of the source. The 843 RESV message is issued by the receiver of the communication session, 844 and it follows exactly the path that the RSVP PATH message traveled 845 back to the communication session source. On its way back to the 846 source, the RESV message may install QoS states at each hop. These 847 states are associated with the specific QoS resource requirements of 848 the destination. The RSVP reservation states are temporary states 849 (soft states) that have to be updated regularly. This means that PATH 850 and RESV messages will have to be retransmitted periodically. If 851 these states are not refreshed then they will be removed. The RSVP 852 protocol uses additional messages either to provide information about 853 the QoS state or explicitly to delete the QoS states along the 854 communication session path. RSVP uses in total seven types of 855 messages: 857 * PATH and RESV messages 859 * RESV Confirm message 861 * PATH Error and RESV Error messages 863 * PATH Tear and RESV Tear messages 865 An overview of the functionality of the RSVP functionality includes: 867 * End-to-end reservation with aggregation of path 868 characteristics such as fixed delay. 870 * The same type of reservation functionality in all 871 routers. Only policy handling separates the edge of the 872 domain from other routers. 874 * Multicast and unicast reservations with receiver initiated 875 reservations. RSVP makes reservations for both unicast and 876 many-to-many multicast applications, adapting dynamically 877 to changing routes as well as to group membership. 879 * Shared reservations for multiple flows. 881 * Support for policy handling to handle multi-operator 882 situations since more than one operator will be 883 responsible for RSVP's operation. 885 * Flexible object definitions. RSVP can transport and maintain 886 traffic and policy control parameters that are opaque to 887 RSVP. Each RSVP message may contain up to fourteen classes of 888 attribute objects. Furthermore, each class of RSVP objects 889 may contain multiple types to specify further the format 890 of the encapsulated data. Moreover, the signaling load 891 generated by RSVP on the routers is directly proportional 892 to the flows processed simultaneously by these routers. 893 Furthermore, processing of the individual flows in the 894 networking infrastructure may impose a significant processing 895 burden on the machines, thus hurting throughput. These 896 issues make it reasonable to question the scalability and 897 performance in a large cellular radio access network. 899 * support for uni-directional reservations, not bi-directional. 901 In the situation where a mobile moves or the connection moves from 902 one base station to another, it could force the communication path to 903 change its (source/dest) IP address. The change of IP address will 904 require that RSVP establish a new RSVP session through the new path 905 that interconnects the two end points involved in the RSVP session 906 and release the RSVP session on the old path. During this time, the 907 end-to-end data path connection is incomplete (i.e., QoS disruption) 908 and it will negatively affect the user performance. 910 This approach includes much more functionality and complexity than is 911 required in the cellular RAN. Our problem is significantly simpler to 912 solve. The trade-off between performance and functionality is one of 913 the key issues in the RAN. In our case, the majority of the 914 functionality in RSVP is not required. This is true for four 915 reasons: 917 * Unicast reservations are much less complex than multicast. 919 * Edge-to-edge with one operator does not require policy 920 handling in the interior routers. 922 * Path characteristics and flexible traffic parameters and 923 QoS definitions could be solved by network dimensioning 924 and edge functionality. 926 * Per microflow states in intermediate routers cause severe 927 scalability problems. Furthermore, receiver-initiated 928 reservations impose high complexity in the states due to 929 reverse-direction routing of the RESV messages. A scheme 930 based on sender oriented reservation (see e.g., [AhBe99]) 931 decreases the complexity of the per microflow states due 932 to the fact that no reverse-direction routing is 933 required. 935 6.2. Integrated Services over Differentiated Services 937 The IntServ over DiffServ framework addresses the problem of 938 providing end-to-end QoS using the IntServ model over heterogeneous 939 networks. In this scenario, DiffServ is one of these networks 940 providing edge-to-edge QoS. This is similar to the underlying 941 architecture for this draft, where the specific network is the 942 cellular RAN, and where the end-to-end model is unspecified. As such, 943 the problem addressed by IntServ over DiffServ is similar in nature 944 to the problem described here, although the specific requirements 945 (such as network utilization and performance) are different. 947 The IntServ over DiffServ framework discusses two different possible 948 deployment strategies. The first is based on statically allocated 949 resources in the DiffServ domain. In this strategy the Diffserv 950 domain is statically provisioned (see Section 6.3). Furthermore, in 951 this strategy the devices in the Diffserv network region are not RSVP 952 aware. However, it is considered that each edge node in the customer 953 network is consisting of two parts. One part of a node is a standard 954 Intserv that interfaces to the customer's network region and the 955 other part of the same node interfaces to the Diffserv network 956 region. Any edge node in the customer network maintains a table that 957 indicates the capacity provisioned per SLS (Service Level 958 Specification) at each Diffserv service level. This table is used to 959 perform admission control decisions on Intserv flows that cross the 960 Diffserv region. A disadvantage of this approach is that the edge 961 nodes in the customer network will not be aware of the traffic load 962 in the nodes located within the Diffserv domain. Therefore, a 963 congestion situation on a communication path within the Diffserv 964 domain cannot be predicted by any of these edge nodes. Due to the 965 "Efficient network utilization" requirement explained in Section 5.3, 966 the RAN is dimensioned such that it may have performance bottlenecks 967 which are not visible to the edges. More advantages and disadvantages 968 of this approach are discussed in Section 6.3. 970 The second possible strategy is based on dynamically allocated 971 resources in the DiffServ domain. According to [RFC2998], this can be 972 done using RSVP-aware DiffServ routers. However, this approach has 973 most of the drawbacks described in Section 6.1, and per-microflow 974 state information is kept in the intermediate routers. 976 Alternatively, resources in the DiffServ domain can be dynamically 977 allocated using Aggregated RSVP. This will be discussed in Section 978 6.4. 980 Other approaches related to the bandwidth broker concept are still 981 very immature and will not be discussed here. 983 6.3. Statically-assigned trunk reservations based on Differentiated 984 Services 986 A significant problem in deploying an end-to-end per-flow resource 987 reservation signaling scheme is its scalability. This can be solved 988 by aggregating (trunking) several individual reservations into a 989 common reservation trunk. The reservation trunks can be either 990 statically or dynamically configured. When the reservation trunks 991 are statically configured, no signaling protocol is required for 992 performing the reservation of network resources but is likely to be a 993 difficult management problem. However, due to the different mobility 994 requirements (such as handover) and QoS requirements (such as 995 bandwidth) that the multi-bitrate applications impose on the RAN, it 996 will be difficult to configure the trunked reservations statically 997 and utilize the RAN efficiently. 999 6.4. Dynamic trunk reservations with Aggregated RSVP 1001 The reservation trunks can be dynamically configured by using a 1002 signaling protocol that manages various mechanisms for dynamic 1003 creation of an aggregate reservation, classification of the traffic 1004 to which the aggregate reservation applies, determination of the 1005 bandwidth needed to achieve the requirement and recovery of the 1006 bandwidth when the sub-reservations are no longer required. 1008 The first router that handles the aggregated reservations could be 1009 called an Aggregator, while the last router in the transit domain 1010 that handles the reservations could be called a Deaggregator. 1012 The Aggregator and Deaggregator functionality is located in the edge 1013 nodes. In particular, an Aggregator is located in an ingress edge 1014 node, while a Deaggregator is located in an egress edge node, 1015 relative to the traffic source. 1017 The aggregation region consists of a set of aggregation capable 1018 network nodes. The Aggregator can use a policy that can be based on 1019 local configuration and local QoS management architectures to 1020 identify and mark the packets passing into the aggregated region. 1021 For example, the Aggregator may be the base station that aggregates a 1022 set of incoming calls and creates an aggregate reservation across the 1023 edge-to-edge domain up to the Deaggregator. In this situation the 1024 call signaling is used to establish the end-to-end resource 1025 reservations. Based on policy, the Aggregator and Deaggregator will 1026 decide when the Aggregated states will be refreshed or updated. 1028 One example of a protocol that can be used to accomplish QoS dynamic 1029 provisioning via trunk reservations is the RSVP Aggregation signaling 1030 protocol specified in [BaIt00]. 1032 With regards to aggregated RSVP, even if the reservation is based on 1033 aggregated traffic, the number of re-negotiations of the allocated 1034 resources due to mobility (handover) does not decrease and each re- 1035 negotiation of resources has the same performance requirements as the 1036 per-flow reservation procedure. 1038 Note that the aggregated RSVP solution may use a policy to maintain 1039 the amount of bandwidth required on a given aggregate reservation by 1040 taking account of the sum of the underlying end to end reservations, 1041 while endeavoring to change it infrequently. However, such solutions 1042 (policies) are very useful assuming that the cost of the 1043 overprovisioned bandwidth is not significant, since this implies the 1044 need for a certain "slop factor" in bandwidth needs. In a RAN, where 1045 overprovisioning is not preferable due to high costs of transmission 1046 links, a more dynamic QoS provisioning solution is needed. 1048 Furthermore, the aggregated RSVP scheme is receiver initiated and 1049 cannot support bi-directional reservations. 1051 In the aggregated RSVP scheme the resource reservation states stored 1052 in all the RSVP aware Edge and Interior nodes represent aggregated 1053 RSVP sessions (i.e., trunks of RSVP sessions). Therefore, the number 1054 of the resource reservation states in the aggregated RSVP scheme 1055 compared to the (per-flow) RSVP scheme, is decreased. However, in a 1056 Diffserv based RAN the number of the aggregated RSVP sessions depends 1057 on: 1059 * the number of Aggregators/Deaggregators; Considering 1060 that each base station and each BSC/RNC is used as 1061 Aggregator/Deaggregator, the total number of 1062 Aggregators/Deaggregators within the RAN is 1063 significantly high. This is due to the fact 1064 that the number of BSCs/RNCs is significantly 1065 high and the number of base stations in a RAN is 1066 in the range of thousands, see Section 3.1. 1067 * the network topology used; The communication between 1068 RNCs is performed in a meshed way, i.e., all to all 1069 communication. This will imply that many communication 1070 paths will have to be maintained by the RAN 1071 simultaneously. 1072 * the number of Diffserv Code Points (DSCPs) used; More 1073 than one traffic classes will be supported 1074 within the RAN. Therefore, the number of the Diffserv 1075 Code Points (DSCPs) used within the RAN will probably 1076 be higher than one. 1078 Therefore, the number of the aggregated RSVP reservation states 1079 within a Diffserv based RAN will be significantly large. 1081 7. Conclusion 1083 Cellular radio access networks and coming wireless applications 1084 impose different requirements on reservation strategies than typical 1085 Internet conditions. 1087 Firstly, the reservation solution does not need to have the same 1088 level of complexity: 1090 * Edge-to-edge not end-to-end: The IP traffic is generated 1091 in the network and is only transported as far as the 1092 cellular-specific nodes (such as the base station and 1093 BSC/RNC). 1095 * Single operator domain and no inter-domain transport: The 1096 transport is owned and managed by a single operator. 1098 * Only unicast not multicast: The end-to-end payload is 1099 transported between nodes. This transport only requires 1100 a unicast reservation. 1102 Furthermore, a cellular radio access network has much higher 1103 performance requirements on the reservation strategy: 1105 * Efficient usage of the transmission network: The transport 1106 between the BSC/RNC and the base station represents a significant 1107 cost for the cellular operator, and efficient usage of 1108 the transmission network is therefore critical from a cost 1109 point of view. The network should allow dynamic allocation 1110 of resources to allow efficient statistical aggregation 1111 of traffic without causing congestion. 1113 * A wide-area network with significant volume of real-time 1114 traffic: Real-time traffic levels up 100% must be 1115 supported. 1117 * The resource reservation process has to handle a 1118 significantly higher volume of requests, and the process 1119 has to be fast enough to avoid packet losses in the 1120 air-interface during handover. 1122 * The scheme must be optimal for interior nodes and not 1123 for the edge nodes. In this way the necessary set of 1124 parameters required for setting up reservations should be 1125 based upon their effect on interior nodes and not on edge 1126 nodes. This reduces the complexity on the interior routers. 1128 Given these requirements, we believe that appropriate standardization 1129 should take place to create the necessary protocols for edge-to-edge 1130 resource management for a single operator domain. 1132 8. References 1134 [AhBe99] Ahlard, D., Bergkvist, J., Cselenyi, I., "Boomerang 1135 Protocol Specification", Internet draft, Work in progress. 1137 [BaIt00] Baker, F., Iturralde, C. Le Faucher, F., Davie, B., 1138 "Aggregation of RSVP for Ipv4 and Ipv6 Reservations", 1139 IETF RFC 3175, 2001. 1141 [KeMc00] Kempf, J., McCann, P., Roberts, P., " IP Mobility 1142 and the CDMA Radio Access Network: Applicability 1143 Statement for Soft Handoff", Internet draft, Work 1144 in progress. 1146 [RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, A., Jamin, S., 1147 "Resource ReSerVation Protocol (RSVP) -- Version 1 1148 Functional Specification", IETF RFC 2205, 1997. 1150 [RFC2210] Wroclawski, J., "The use of RSVP with IETF Integrated 1151 Services", IETF RFC 2210, 1997. 1153 [WeLi99] Westberg, L., Lindqvist, M., "Realtime Traffic over 1154 Cellular Access Networks", Internet draft, Work in 1155 progress (expired). 1157 [RFC2998] Bernet, Y., Yavatkar, R., Ford, P., baker, F., Zhang, L., 1158 Speer, M., Braden, R., Davie, B., "Felstaine, E., 1159 "Framework for Integrated Services operation over 1160 Diffserv Networks", IETF RFC 2998, 2000. 1162 9. Acknowledgements 1164 Special thanks to Brian Carpenter, Steven Blake, Phil Chimento, 1165 Anders Bergsten, Marc Greis, Hamad el Allali, 1166 Nicola Blefari-Melazzi, Giuseppe Bianchi and Geert Heijenk for 1167 providing useful comments and input. 1169 10. Authors' Addresses 1171 David Partain 1172 Ericsson Radio Systems AB 1173 P.O. Box 1248 1174 SE-581 12 Linkoping 1175 Sweden 1176 EMail: David.Partain@ericsson.com 1178 Georgios Karagiannis 1179 Ericsson EuroLab Netherlands B.V. 1180 Institutenweg 25 1181 P.O.Box 645 1182 7500 AP Enschede 1183 The Netherlands 1184 EMail: Georgios.Karagiannis@eln.ericsson.se 1186 Pontus Wallentin 1187 Ericsson Radio Systems AB 1188 P.O. Box 1248 1189 SE-581 12 Linkoping 1190 Sweden 1191 EMail: Pontus.Wallentin@era.ericsson.se 1193 Lars Westberg 1194 Ericsson Research 1195 Torshamnsgatan 23 1196 SE-164 80 Stockholm 1197 Sweden 1198 EMail: Lars.Westberg@era-t.ericsson.se