Flow-Control for Multi-Access Systems - CiteSeerX

FLOW-CONTROL FOR MULTI-ACCESS SYSTEMS1 Ralf Tönjes, Thorsten Lohmar, Marc Vorwerk, Ralf Keller Ericsson Research, Corporate Unit, Ericsson Eurolab Deutschland, Ericsson Allee 1, D-52134 Herzogenrath, Germany, Ralf.Toenjes @eed.ericsson.se

Abstrac t - Future wireless communication systems will be characterised by an integration of different access technologies. Such systems will feature a user-friendly coordination of the complementary access technologies to access personalized services in a seamless manner via the currently most suitable access. Efficient resource management will provide cost effective bandwidth. These systems need a flow-control functionality to select always the best suitable access system for a certain traffic flow in different environments. This paper lists requirements and describes a flow control functionality that controls the forwarding of individual traffic flows over different access systems in a multi-access scenario. In addition, examples are presented and discussed how this advanced multimedia flow-control can be embedded both in a co-operative and in an integrated multi-access system architecture, providing thereby guidelines for standardization and future products. Keywords – Multi-Access, Flow Control, Hybrid Networks, Network Architecture, Multimedia Services.

not only via one but also via several radio-access systems at the same time. Each access system may provide different application services. There can be simultaneous connections via different access systems, or connections via only one access system at a time. Future wireless communication systems beyond 3G will be characterized by an integration of different access technologies such as cellular, WLAN, short-range radio, digital broadcast and fixed access technologies [1]. Such future systems need a flow-control functionality that can be configured for the users preferences. It has the task to coordinate the complementary access technologies to provide cost effective bandwidth for accessing personalized services in a seamless manner via the currently most suitable access form in different environments. This paper is structured as following: The next section lists requirements. The provision of multi media flow control in a cooperative system is described in section 3. Section 4 discusses the approach for integrated systems. Section 5 contains the final conclusions.

I. INTRODUCTION The demand for access to mobile multimedia services at any time and anywhere has driven the development of 3G mobile communication systems. 3G systems are labelled as mobile multimedia as they enable many kinds of services and clearly dominate future network evolution activities on all levels building on two key technologies: the Internet and digital mobile communication systems. The success of mobile communication in the future will depend on the availability of attractive services for end users. Only if mobile systems can provide data services for the mass market at attractive prices then the success of mobile data will be comparable to the success of mobile voice. Existing and emerging multimedia services exhibit a variety of requirements in terms of asymmetry, interactivity, real-time and communication type like unicast, multicast, and broadcast. A single system can hardly ever serve all the different user needs in an optimal way, but a combined and coordinated system can. This leads to the envisioned scenario, wherein a mobile user is able to communicate best

II. REQUIREMENTS An efficient flow routing is needed to support simultaneous transmission via several Radio Access Networks (RANs) and to provide a certain quality of service. The flow routing is the entity in the network that is responsible for directing the user’s traffic via different RANs. The selection and combination of different RANs will depend on different parameters, such as user preferences (e.g. minimal costs), terminal capabilities (e.g. display resolution), system capabilities (e.g. bandwidth, delay), the traffic and link status (e.g. network load), the application preferences and capabilities (e.g. min./max. /preferred bandwidth), and operator preferences (e.g. network utilization). The general architecture is depicted in the following figure. A mobile terminal uses two services (Service 1 and Service 2) simultaneously. The application flows are routed via two different Access Systems (Access System 1 and Access System 2) to the mobile terminal. An application flow is

1

This work has been partially supported by a grant from the German Ministry for Research and Education (BMB+F) within the project “Communication and Mobility by Cellular Advanced Radio (COMCAR)” and by the European Commission within the IST project “Dynamic Radio for IP-Services in Vehicular Environments (DRiVE)”.

0-7803-7589-0/02/$17.00 ©2002 IEEE

PIMRC 2002

identified in the network by source and destination address, source and destination port, and protocol ID. Two network domains are depicted in the following figure, Home Network and Tunnelling Network. A home network is a network having a network prefix matching the mobile terminal's home address [9][15]. According to the standard IP’s routing mechanism, all packets destined to the mobile terminal are routed to the home network. The tunnelling network is responsible of forwarding the packets to the actual point of presence of the mobile terminal.

Access System 1

IP IP

IP

IP

Backbone Network

Mobile Mobile Terminal Terminal Receiver Control

Access System 2

Tunnelling Network

IP

IP

Service 1

Flow Router

Service 2

IP IP

Home Network RCFR: Receiver -Controlled Flow Routing

Fig. 1: The concept of "Receiver Controlled Flow Routing" Since two access systems are available in our example, the mobile terminal shall be enabled to influence (i.e. receiver control) the decision of forwarding flows via access systems. The mobile terminal has full information about access system availability, but no information about the network topology. An additional node in the infrastructure, the flow router, is responsible of forwarding the individual flows via different access systems. This leads to the suggested approach of Receiver Controlled Flow Routing (RCFR). In the following sections, two different approaches to implement this mechanism of receiver controlled flow routing are presented. To compare both system realisations, we first formulate requirements for the system: •

Transparent to servers: In order to maintain fast rerouting effect, the servers shall not be involved in the process. The forwarding decision is taken between the access network and the mobile terminal. To meet this requirement, the mobile’s IP address shall not change.

•

Usage of available systems: All available systems shall be used. If an access system does not provide the requested capacity, another access system shall be used. If one available access system is able to provide all requested resources, all traffic is routed via this one for efficiency reasons.

•

Receiver Controlled: Since only the receiver has the full information about available and usable access systems, the host shall influence the routing decision. It provides all relevant information to identify the flow to the RCFR node.

Further requirements are: •

The multi-access system has to provide roaming, personal/terminal mobility, ensure transport level continuity of services.

•

The cooperation of multiple access systems requires a Common Coordination Control (CCC) functionality, which, amongst other tasks, announces the available access systems to the mobile terminal.

•

The first approach describes the realisation of flow forwarding in cooperative systems. Here the used access networks are not necessarily maintained and controlled by the same network operator. In this approach, the functionality of the RCFR is associated with the binding update of Hierarchical Mobile IP [13]. In the second approach, we describe the realisation using integrated systems. Here, the RCFR node is collocated with the GGSN (GPRS Gateway Support Node) of a 3G network [14][15][16]. III. CO-OPERATIVE SYSTEMS

Cooperative systems combine and coordinate different access systems, while keeping them (almost) unchanged. The objective is to combine those access systems that have been optimised for the required specific services. Examples for hybrid systems are MEMO [2] combining DAB and GSM, SABINA [3] combining DVB and GSM, and the interactive DVB [4] system with back channel. The generic DRiVE [6] system architecture combines any access system that is capable of transporting IP, e.g. UMTS, GSM, DAB, DVB, and WLAN. DRiVE has introduced an overlay design for the network architecture [7], consisting of two parts: a backbone, and individual radio access systems. This approach has been driven by two main goals: firstly, to leave the radio access systems unaltered as far as possible, and secondly, to provide a framework for co-operation between accesses by the backbone. A representative co-operative network is given schematically in Figure 2, which shows a mobile terminal communicating with a correspondent node (e.g. service provider) via different access systems attached to the generic IPv6 backbone. The user is able to communicate with corresponding nodes through multiple access networks simultaneously. The backbone part is access system independent, providing inter-system mobility and AAA subscriber management services for roaming. The flow router forwards traffic to the various access networks. Technically, the flow router employs Hierarchical Mobile IPv6 (HMIPv6) with extensions to allow more elaborate traffic distribution [13].

UMTS

Service Provider

Traffic Mgmt .

Backbone Traffic GPRS Mgmt . Mobile Mobile Terminal Terminal Receiver Control

Home Agent Flow Router

Traffic DVB-T Mgmt .

Internet MAP AAA

DAB

Traffic Mgmt .

WLAN Traffic Mgmt .

Fig. 2: A Co-operative Network Architecture Hierarchical Mobile IP (HMIPv6) [12] proposes the use of a Mobility Anchor Point (MAP), which is located in the domain visited by the mobile terminal. A mobile terminal obtains a Regional Care of Address (RCoA) from the visited network, which is registered at the correspondent node (CN). Thus traffic destined to the mobile terminal is directed to the MAP, which forwards it to the mobile terminals current Care of Address. If a mobile terminal performs a handover, it registers its new local CoA at the MAP. Because CNs are unaffected, HMIP reduces the amount of (and time for!) binding update messages send for handover. Flow routing allows to route flows over different access systems in a multi-access scenario. The co-operative network architecture implements MAP in the flow router. A single HMIPv6 extended flow router will be responsible for a group of access networks, generally covering a particular geographic area. Optionally a flow can be identified based on the source/destination addresses, transport protocol number, source/destination port numbers quintuplet, or based on the IPv6 flow label combined with the CN’s source address. No matter what kind of RCFR is defined or has been configured in the flow routing enabled MAP of HMIP for particular user traffic, the following scenario describes user traffic forwarding mandated by the co-operative system. Traffic destined to the Mobile Terminal will be transmitted via the Home Agent (HA) (using IPv6 encapsulation) or directly from Correspondent Node (CN) (routing optimisation) to the RCoA. At the MAP the datagrams will be processed in two different ways depending on whether they are transmitted via the HA (decapsulation) or via the CN (Routing Header processing). In either way the MAP will obtain the final destination address, i.e. the mobile home address of the mobile terminal. At this point a look up in the cache entry together with the specified RCFR will elucidate the next destination path for each datagram, i.e. the Local CoA within the access system. The MAP will encapsulate the original datagram with a new IPv6 header and tunnel [14] it over the access system. Ultimately, the mobile terminal will receive the packet and process the datagram according to the MIPv6 specification. By

extending the co-operative network with the HMIPv6 functionality, mobility management is improved in several aspects. For instance, binding update signalling from the mobile terminal to the correspondent node and vice versa is reduced remarkably. Furthermore, the number of signalling associated with the inter- and intra-MAP movement, passing over different access system, is also reduced. As a consequence, security overhead is minimized, which implicitly leads to an increased throughput of best effort services of real time applications. In a scenario of location dependent availability of access systems the hybrid system should announce which radio services are available. A useful generic means to provide this information is via the CCC. The CCC can provide information on available radio access systems, service capabilities, used frequency range, and traffic characteristics. Within the DRiVE architecture, a logical channel is used to implement CCC functionality. IV. INTEGRATED IMT-2000 SYSTEM One key characteristic of integrated system approach is to include system enhancements that automatically select and optimise the link for the specific traffic demand. In this approach the RCFR flow router is integrated in the GGSN. The CCC functionality could be included in the radio resource management, thereby enhancing existing system functionality. This section describes the communication between the mobile terminal and the flow router as developed in COMCAR [5]. The receiver control functionality [17] in the terminal has the task to manage and schedule Internet access in a highly dynamic multi-radio environment with simultaneous usage of several radio systems such as GPRS, DVB-T, UMTS, and WLAN while moving between areas with different access coverage. Every mobile application running on such a terminal which needs access to the Internet has to register at the receiver control functionality at first in order to request resources from it. Essential parameters that have to be sent to the receiver control are the minimum bit rate and a set of increasing bit rate thresholds up to the maximum. These values define when the receiver control will inform an application either that it cannot guarantee the lower values anymore or that it can offer more bandwidth to an application than the next announced upper threshold. The receiver control functionality calculates continuously an optimum sharing of the current bandwidth among the registered applications under consideration of their delivered parameters and the time of their registration. i) satsys := ∑ sat (MA i

(1)

This leads to an overall satisfaction (sat) of the whole system, which is made up of the weighted satisfaction of each registered mobile application. After every optimisation, the receiver control informs the applications about this new value over the provided interfaces. On the other hand the receiver control establishes dynamically the routes for the numerous data flows generated by different mobile applications. The key of the whole concept is to steer remotely the flow router located at the entrance points of the radio access networks, to control the negotiated bit rates for each flow and to instruct the flow router as to which data packet is to be sent through which radio system. These constraints and routes are updated within every optimisation step. To control the application flows, the source / destination IP addresses and the associated ports are needed. These values are also provided during the registration process. The flow router receives the requests from the receiver control entity, which in turn influences the routing of the flow router. There are several methods for setting, deleting, and changing network rules remotely. This is done by marking the IP packets, adjusting routing tables, creating tunnels, and shaping the traffic per registered flow if necessary, see Figure 3. •

Classification: The packets are classified to identify the flows of different sessions.

•

Routing: The packets of the individual flows are routed to the selected access system. The new destination address is the CoA that was assigned to the mobile terminal in the corresponding access system

•

Encapsulation: because the original destination address is located in the home network, the packets are tunnelled to the CoA in the access system.

•

Traffic shaping: To ensure that the flows comply with the assigned data rate, a rate control based on class based queuing is employed.

Fig. 3: Traffic Control mechanisms in the RCFR A prototype was implemented on a Linux platform using the traffic control mechanisms of the Linux Kernel 2.4 and JAVA for configuring the flow router. For performance measurements UDP packets were generated with Iperf [18].

Datagrams with sizes from 200 up to 1470 bytes were send for verification using 1500 Byte MTU fragmentation. Every IP-packet of a session flow gets an additional IP-header for the selected tunnel of 20 bytes before it gets queued and controlled. The chosen data rates to transmit over the RCFR were increased from 10 up to 1280 kbit/s.

Fig. 4: Efficiency of the Traffic Control in the RCFR The results for some effective data-rates depending on the average packet size are shown in Figure 4. It could be shown that the RCFR prototype performs in that way that it maintains the characteristic behaviour for this kind of traffic. V. CONCLUSION Existing and emerging multimedia services exhibit a variety of requirements in terms of asymmetry, interactivity, realtime and communication type like unicast, multicast, and broadcast. In this paper we have presented flow-control requirements for multi-access systems, which supports endusers in fully utilizing the capabilities of multi-access systems. The inclusion of flow control functionality in cooperative and integrated multi-access systems has been discussed. The advantages of this intelligent resource management are manifold: •

Fair distribution of bandwidth among concurrent clients and applications.

•

Transparent Internet access via multiple radio systems.

•

Transparent Internet access in spite of dramatically changing requirements from the applications.

•

Protracted bandwidth measurements are not needed any longer, because of existing knowledge about the current situation in the receiver control functionality. This allows for faster adaptation of the mobile applications to the changing radio conditions

Moreover, details of our prototypical implementation of flow-control have been revealed. Overall, we are currently running tests of our prototypical implementation whereby different end-user application services are used on top. Some of these end-user application services make use of the offered interfaces. One goal of these tests is to further optimise the sharing of available bandwidth among registered applications. The utilization of several available accesses in end-user terminals is not yet commo nplace, however, our work on receiver controlled flow routing is seen as an essential step forward to further enhance the always best connected experience of end users.

[8]

[9] [10]

[11]

[12]

AKNOWLEDGEMENTS This work has been partially supported by a grant from the German Minis try for Research and Education (BMB+F) within the project “Communication and Mobility by Cellular Advanced Radio (COMCAR)” and by the European Commission within the IST project “Dynamic Radio for IPServices in Vehicular Environments (DRiVE)”. Partners in COMCAR are Ericsson, DaimlerChrysler, T-Systems Nova, and Sony. The DRiVE consortium consists of Ericsson (coordinator) BBC, Bertelsmann, Bosch, DaimlerChrysler, Nokia, Steria, Teracom, VCON, and Vodafone as well as Rheinisch-Westfälische Technische Hochschule RWTH Aachen, Universität Bonn, Heinrich-Hertz-Institut Berlin and the University of Surrey. The authors acknowledge the contributions of their colleagues in the COMCAR and DRiVE consortium.

[13] [14] [15]

[16]

[17]

[18]

REFERENCES [1]

[2]

[3] [4]

[5] [6] [7]

R. Keller et al.: “Convergence of Cellular and Broadcast Networks from a Multi-Radio Perspective. IEEE Personal Communications”, 8(2): 51-56, 2001 Klingenberg, W., Neutel, A.: MEMO – A Hybrid DAB/GSM Communication System for Mobile Interactive Multimedia Services. In: Proceedings of ECMAST ’98, Berlin 1998. Lecture Notes in Computer Science Vol. 1425. Springer Verlag, Berlin Heidelberg New York (1998) SABINA (System for Asymmetric Broadband Internet Access). Project page under http://www.teracom.se/ U. Reimers: Digital Video Broadcasting, IEEE Communications Magazine, Special Issue on Wireless, Video (Invited Paper), Vol. 36 (1998), No.6, S. 104110 COMCAR project page: http://www.comcar.de/ DRiVE project page: http://www.ist-drive.org/ T. Paila et al.: "Flexible Network Architecture for Future Hybrid W ireless Systems", Mobile Summit 2001; Barcelona; 10.-12. September 2001

S: Acharya, M. Franklin, S. Zdonik “Balancing push and pull for data broadcast”, in proceedings of ACM SIGMOD ’97, May 1997, Tucson, AZ RFC3220, “IP Mobility Support for IPv4.”, C. Perkins, Ed.. January 2002. C. Castelluccia, HMIPv6, ACM SIGMOBILE Mobile Computing and Communications Review, Volume 4, Issue 1, January 2000 D. Johnson, C. Perkins, “Mobility Support in IPv6”, Internet Draft , IETF mobileip working group, July 2001 (work in progress) H. Soliman, C. Castelluccia, K. El-Malki, “Hierarchical MIPv6 mobility management”, Internet Draft , IETF mobileip working group, July 2001 (work in progress). H. Soliman: “Per-Flow movement in MIPv6”, , IETF, Nov. 2001. 3GPP TS 23.060: "General Packet Radio Service (GPRS); Service Description Stage 2". 3GPP TS 29.060: "General Packet Radio Service (GPRS); GPRS Tunnelling Protocol (GTP) across the Gn and Gp Interface". 3GPP TS 29.061: "Interworking between the Public Land Mobile Network (PLMN) supporting Packet Based services and Packet Data Networks (PDN)". S. Blödt: Entwicklung und Implementierung einer dienstgütebasierten Ressourcenverwaltung und Wegewahlstrategie in einer heterogenen Mobilfunkumgebung, Diploma Thesis (ITM University Karlsruhe / Ericsson Eurolab Deutschland) - November 2001. Iperf project page: http://dast.nlanr.net/Projects/Iperf/