Final Implemented QoS architecture for the IST Project VIRTUOUS Demonstrator

Transcription

1 Final Implemented QoS architecture for the IST Project VIRTUOUS Demonstrator Filomena Del Sorbo, Giuseppe Lombardi, Fabio Ventrone Computer Science Department University of Rome La Sapienza, Via F. Buonarroti, Rome, Italy Tel: , reference ABSTRACT The integration of a satellite US network with a terrestrial US one represents one of the most attractive proposals to overcome the coverage limitations of the future 3G cellular mobile networks, together with the possibility of exploiting the intrinsic satellite transmission capabilities. In this scenario, the IST VIRTUOUS project has developed and implemented a suitable demonstrator allowing to test this kind of systems. This paper deals with the QoS relevant software designed and implemented in the VIRTUOUS demonstrator, showing the approach followed and the results expected. I. INTRODUCTION In the age of multimedia communications, the QoS concepts have by now assumed a central role in the development of the future telecommunication systems, considering the necessity of an efficient and fair management of several applications with several distinct features and requirements. These issues gain a particular relevance in the wireless systems where, in spite of all the improvements, the scarcity of transmission resources forces to pay special attention to the QoS management. At this purpose, in the framework of an integrated terrestrial and satellite network (T-US, S- US) designed to provide everywhere and to everyone a set of innovative multimedia services, the IST Project VIRTUOUS has developed a suitable architecture to support many kinds of different sources ( Voice, FTP, Web,.) with the requested QoS profile. This paper aims at describing this QoS supporting architecture, focusing the attention on the procedures adopted to implement the relevant software in the VIRTUOUS Demonstrator. II. VIRTUOUS GENERAL DEMONSTRATOR ARCHITECTURE The VIRTUOUS demonstrator respects the architecture of a classical mobile network, separating the elements into domains: user equipment, radio access network and core network, plus the external ISP domain. Thus, the VIRTUOUS demonstrator comprises a multi-mode mobile station, an integrated S/T-US physical layer testbed, a GPRS access segment, a core network equipment and an external IP network. MOBILE EQUIPMENT TE SIP client FTP client Web browser T - I W U Terminal Tesbed GPRS T-US S-US ACCESS NETWORK GPRS BSS S/T-US tesbed CORE NETWORK HLR 2G/3G SGSN GGSN Fig. no. 1 : VIRTUOUS demonstrator ISP DOMAIN Web As shown in fig. n.1, the demonstrator can run under different testing conditions, thanks to the multi-mode testbed, using the same client and server modules: in this way it is possible to test the performance of the QoS algorithms working under several different conditions. The leftmost and rightmost blocks on the same figure just list a few examples of the available applications that can run during the demonstration. For architectural reasons, as shown later in this paper, it is possible to say that all applications that run on the Internet can also run inside the demonstrator system. SIP FILE servers LAN

2 III. PROPOSED QoS ARCHITECTURE In order to reach the above mentioned goals relevant to the QoS management, a target system architecture has been proposed in VIRTUOUS, as shown in fig. n. 2. User Plane S 1 S 2 S n DLB 1 DLB 2 Segmentation MUX TX DLB n CCH C Config Req (r i,p i ) Data Req ( ) Sched_Alg Control Plane Fig. no. 2 : Radio Access Stratum architecture The figure shows all the Radio Access Stratum (RAS) protocols enhanced through the design of appropriate QoS modules/devices. The RRC layer is in charge of handling the Call Admission Control (CAC) and the dynamic resources management issues; although the RRC layer is actually implemented in the demonstrator, the CAC functionalities have not been designed, since this was not a task of the project. The implemented QoS architecture aims at managing in the best possible way a set of connections already admitted into the network (so the attention is not on the set-up phase); tests and trials with different traffic conditions have been/will be performed. The layer has to insert the data packets belonging to different flows into the relevant queues, also performing the usual traffic shaping/policing through a set of Dual Leaky Buckets (DLBs). Basing on the inputs derived from the scheduling algorithm implemented in VIRTUOUS, the is in charge of performing the segmentation of the IP datagrams in order to adapt their format to the PDU length. The scheduling algorithm selects both the most suitable transport format for transmission (this decision is taken during each Time Transmission Interval, i.e. each 10 msec. in VIRTUOUS) and the packet to be actually transmitted among those stored in the queues. This combined selection is performed through an innovative VIRTUOUS-specific algorithm, which allows to obtain dramatic improvements respect to the 3GPP proposed one. The description of such algorithm, together with a detailed analysis of the target system QoS architecture, can be found in [1]. IV. QoS IMPLEMENTATION IN VIRTUOUS RRC C Measurement Ind ( ) This section will examine the software applications written in order to physically evaluate the performance of the QoS architecture described above and to compare the VIRTUOUS QoS scheduling algorithm with the other available ones. In particular, as already stressed by the simulations, the VIRTUOUS algorithm has to be compared with the 3GPP proposed one [2]. All the attention is focused on the demonstrator part that is in charge of emulating the access section of the integrated S-US T-US target system. The Core Network has been excluded by the QoS experiment, since its task is the validation of the algorithms embedded in the US AS (access stratum) protocols which have to manage the resources in the radio section. In fact, it is clear that the actual transmission bottleneck is often represented by the scarcity of bandwidth in this part of the overall system, so all the investigations are focused on these crucial issue. The software environment designed ad hoc for VIRTUOUS, is able to simulate an US connection with different real data sources and to test the transmission performance through the physical layer emulator. Objectives of the software architecture The software architecture has been projected with three major aims : 1. portability: the system has to be easily installable on different machines in order to reduce the constraints on the physical emulator specs. 2. efficiency: the results of the demonstration have to be reliable in every testing conditions. 3. versatility: all the testing applications should be highly configurable. These three points have been all reached with the current implementation. All the critical sections of the system are written in C language, without using kernel version dependent system calls. This guarantees portability and efficiency. In order to obtain the maximum flexibility of the testing parameters we have decided that each application that runs on the Internet will run on the simulator as a testing application. In this way it is possible to create ad hoc applications generating particular kinds of traffic and it is even possible to test the algorithms using real applications such as Netscape web browsers, FTP clients, RealMedia video streaming and so on. Main architecture The system architecture is made up of 51 blocks, as described in the following diagram:

3 Appl. CS Graphical RunTime Visualizer Appl. SS Internet Appl. CS Sniff ip Put ip SCHED. demux demux SCHED Appl. SS Sniff ip Put ip Internet Fig. no. 3 : system architecture The module is a black box in this context and it represents the physical layer emulator that introduces the channel noise, delays and so on. In fact, in the framework of the project, the radio link is represented by a suitable module, named ROBMOD, that targets at emulating the main features of the radio access section of a real T-US S-US integrated network. Directly connected to the, there are the modules and then the Application s modules. The system architecture is exactly symmetrical and so it is enough to analyze just one side. Starting from the leftmost block we can see the Application Client Side. This is a Linux PC which provides all client applications such as Netscape Browser, RealPlayer, FTP client. All the connection requests to the symmetrical Application (Server Side) start from this machine. All the Internet traffic is separated and redirected to the machine, which hosts the algorithm module. The block is another Linux PC connected to the Application through an Ethernet network and to the module through a serial cable. This module just receives data from 15 queues (TCP sockets) incoming from the AP-CS and schedules it using the QoS parameters prefixed in a configuration file. The scheduled data is then sent to the Physical layer emulator through the serial line. Fig. no. 4 : functional architecture The application portal CS contains the sniffer module which capture all the IP traffic without changing the system user s way of work. All the separated IP packets are then sent trough a set of TCP sockets to the device, where the scheduler can easily merge everything into a single flow of data, which is sent again trough the Physical emulator. On the right side the inverse operation takes place: the data flow is demultiplexed and sent back to the Internet (put IP module). Data flow separation The key-feature of this software is in the data flow separation. The algorithm used guarantees the maximum flexibility on the real application involved in the simulation. The following scheme shows the technique used for this task: The demonstrator will consider the Application Client Side PC as the application layer of the terminal Equipment, while the PC as the lower layers. The algorithm module has been projected in order to simplify the algorithm parameterization or substitution, thus allowing high flexibility to the demonstration test. The functional architecture of the demonstrator is expanded in figure n. 4. Fig. no. 5: data flow separation The raw IP packets arriving from higher layers are all captured from a module, called sniffer, that uses the pcap (packet capture) library of the operating system.

4 At this point the packet separation is made up watching at the operating system user that has generated those packets. This is possible just matching the user s used ports with the sender address of the packet. Each user can generate all kinds of IP traffic, but he will always cross the network using the same channel. In this way it is possible to make two kinds of associations; the first one is between the operating system (OS) users and the opened network ports, and it is easily obtainable querying some OS functions. In fact, for each requested Internet connection, the OS will assign a sender port in order to correctly receive the call answer. The second one is between the OS user and the crossing channel utilized. This association is prefixed and makes easy the task of selecting the appropriate channel (and so QoS request): every application started by a particular OS user will travel through the mapped channel. The global mapping is done by the sniffer module, which calculates the sender port accessing to the packet header, obtains the generating OS user just inverting the first association, and finally chooses the channel using the last association. So, in order to send data through the network with a particular QoS it is enough to generate these data with the relevant OS-user. As previously mentioned, the algorithm module is a separate module, allowing this way the possibility of its fast and efficient substitution in order to perform the comparison of different algorithms and their retuning. The implemented architecture foresees the presence of another module, the so-called graphical visualizer, which is totally independent from the other ones. It has been developed in order to made available a real-time window on the channels performance. The architecture is the standard web client/server: the visualizer acts as a server and waits for a TCP connection on a configurable port. The Visualizer receives a connection request from the module, which will provide real time measurements about channels performance during the demonstration. Once the connection has been established the server just waits for the client to send all the information through the TCP/IP socket. In particular for each time slice the client sends a text string to the server containing the speeds and the queues lengths for each channel involved in the demonstration.. The real time visualizer is able to show four kinds of information about the running simulation: 1. The overall transmission speed 2 For each available channel: The speed The queue length The latency The following picture shows a captured image of the visualizer during the running simulation: Fig. no. 6: screenshot of the Runtime Visualizer Each channel is associated to a column which contains : Latency (horizontal arrow) Speed (speedometer-like circle) Queue length (vertical bar) In particular the latency and queue length indicators have also an overflow signal which trigs on when the values for these parameters are in overload. The downside graph represents the global speed over the network. The graphical visualizer can also store all the simulation logs, which can be further elaborated for statistical purposes. IV. CONCLUSIONS The software architecture designed ad hoc for VIRTUOUS respects all the constraints fixed for the demonstrator. After the successful simulation of the QoS tools conceived to enhance the overall system performance [1], the implementation carried out is expected to confirm the simulation results on a real operational scenario. A set of trials has been created in order to reach the above mentioned goal. In particular, the high versatility of the implemented software will allow comparative considerations, which will be obtained repeating the same tests with different scheduling QoS algorithms. At the same time, the demonstrator architecture for the QoS experiment allows to perform tests with real Internet applications under different load conditions. It will be possible in this way to stress the great advantages of the VIRTUOUS-specific QoS

5 architecture respect to the 3GPP proposed solutions [2] in a much more real scenario than a simply simulated one. REFERENCES [1] F. Delli Priscoli, C. Mannino et alii, Joined Transport Format Selection algorithm for QoS provisions in VIRTUOUS Experiments, IST Mobile Summit 2001, Barcelona. [2] 3GPP TS Protocol Specification. [3] 3GPP TS Protocol Specification.