Surrey’s Next Generation Wireless Network Testbed M.Georgiades, N.Akhtar, M.Ghader, Z.Li, S.Gultchev, R.Tafazolli Centre for Communications Systems Research University of Surrey Guildford GU2 7XH, England, United Kingdom {m.georgiades, n.akhtar, m.ghader, zhaojun.li, s.gultchev, r.tafazolli}@surrey.ac.uk
Contact details of the first author: Michael Georgiades Centre for Communications Systems Research, University of Surrey, Guildford GU2 7XH, England, United Kingdom. Tel: +44 (0)1483 683424 Fax: +44 (0) 1483 686011 Email:
[email protected] Abstract This paper gives an overview of the research work that has been carried out in recent years in the Wireless Network Testbed (WNT) at the University of Surrey. The CCSR Wireless Network Testbed (WNT) provides a flexible, re-configurable wireless network platform, capable of supporting an extensive range of networking and service provisioning scenarios. Here we describe some of the research that has been carried in the following technical areas: mobility management, context transfer protocol, cross-layer signalling, reconfiguration network management, service discovery and service routing, and personal area networks. Keywords Wireless Network Testbed, Mobility Management, IP.
Surrey’s Next Generation Wireless Network Testbed M.Georgiades, N.Akhtar, M.Ghader, Z.Li, S.Gultchev, R.Tafazolli Centre for Communications Systems Research University of Surrey Guildford GU2 7XH, England, United Kingdom {m.georgiades, n.akhtar, m.ghader, zhaojun.li, s.gultchev, r.tafazolli}@surrey.ac.uk
Abstract-This paper gives an overview of the research work that has been carried out in recent years in the Wireless Network Testbed (WNT) at the University of Surrey. The CCSR Wireless Network Testbed (WNT) provides a flexible, re-configurable wireless network platform, capable of supporting an extensive range of networking and service provisioning scenarios. Here we describe some of the research that has been carried in the following technical areas: mobility management, context transfer protocol, cross-layer signalling, reconfiguration network management, service discovery and service routing, and personal area networks.
The network consists, mainly of Cisco networking equipment, connecting Sun, Windows and Linux workstations, along with an IEEE802.11b-based Wireless LAN access segment. The complete network diagram is shown in the Figure 1. Network Network Core Management Centre
Wireless Access Points
Wireless Clients
CCSR Internet
Keywords - Wireless Network Testbed, Mobility Management, IP.
IP Network
I. INTRODUCTION The CCSR Wireless Network Testbed (WNT) provides a flexible, re-configurable wireless network platform, capable of supporting an extensive range of networking and service provisioning scenarios. The testbed can also be used to set up protocol stack functionalities in a flexible manner in order to support adaptive quality of service for multi-media communications in mobile environments. The testbed itself contains almost all the essential constituents of the Mobile Wireless Internet. The Wireless Network Testbed can be configured to support both IPv4/IPv6. The WNT offers the capabilities to undertake research in every area of mobile communication including (but not limited to): • Mobility support for IP networks • Service Discovery, Location and Routing in MANETs/PANs • Terminal and network reconfigurability • Quality of Service • Network and data security • Multicast support
Access Pool
LAN Workgroup Access
PC & Sun Workstations
Figure 1: Wireless Network Testbed diagram
II. RESEARCH IN THE WNT A. Mobility Management The following protocols have been installed and configured in the WNT for research in the area of mobility management. • Session Initiation Protocol (SIP): Used in the testbed for initiating and setting up multi-media sessions between clients. Different implementations of SIP servers such as Partysip [1], SIP Express Router are available. SIP-based applications such as Linphone are used. •
The Dynamic Host Configuration Protocol (DHCP): Allocation of IP addresses to mobile hosts. Both static and dynamic allocation is supported.
•
Mobile IP: Supports macromobility.
•
Cellular IP (CIP): and Hierarchical Mobile IP (HMIP): Micromobility Support.
Table 1: Results from Mobility Experiments Handover Delay (sec) HA2 HA3 HA4 HA5 27.3 31.2 28.6 30.3 8.9 12.3 9.5 11.2 0.54 0.53 0.55 0.54 15.7 40.8 19.9 7.2
In [2], an end system mobility solution was proposed for an all-IP network infrastructure based on the interworking of SIP with other mobility-related protocols to guarantee transparent mobility to end systems. The following mobility management interworking solutions have been implemented and the wireless testbed:
Protocols Used SIP/DHCP(DAA) SIP/DHCP(SAA) SIP/CIP SIP/MIP/CIP
•
SIP/DHCP: In the SIP/DHCP solution, the mobile host is dynamically allocated a new IP address by a DHCP server when a handoff takes place and the media session is maintained by sending a SIP reINVITE message to the correspondent host.
•
SIP/Cellular IP: In this scheme, the MH keeps using the same IP address even after handoff as Host Specific Routing is used. Once the network layer handoff is complete any ongoing sessions are resumed by sending a re-INVITE message to the corresponding hosts. For Cellular IP the open source of [3] was used.
•
SIP/Mobile IP/Cellular IP: In this solution Mobile IP is used to provide network macromobility and Cellular IP for network micromobility. SIP is used for providing session macromobility as in the previous two cases. Similarly to the SIP/Cellular scheme, the mobile host maintains its home address. For Mobile IP the open source of [4] was used.
This section presents the research undertaken to develop a context transfer solution to support seamless and secure multimedia services over all-IP infrastructures. In this work, two context transfer schemes have been proposed: (1) Context transfer extension to mobility management protocols, (2) A standalone context transfer module. The first solution was designed to act as an adhesive between the context transfer candidate service and mobility management exchanges by using the latter to forward state information related to the service. For the implementation of this Cellular IP was enhanced with a context transfer mechanism to carry the desired AAA state information (See Figure 3). FreeRADIUS [5] was used as the AAA server. The results have shown that the authentication component of the handoff delay is reduced by approximately a factor of twenty.
Correspo ndin g
S IP Server
HA
HA1 28.2 10.4 0.55 29.7
HA6 29.2 10.5 0.55 37.7
B. Context Transfer
AAA
Mobile-IP HA
IPv4/IPv6 backbon e Context PGW /FA Transfer
NGW/FA
AAA QoS IPsec Header C ompression Multicast Group No.
Hosts Home Network
All IP Backbone
MH
R2
R1
WLAN
Handoff
ha ndover
Mobil e Host
Figure 2: Mobility Test Setup The handoff performance of these schemes has been evaluated by measuring the handoff delay in each case. The test setup for the experiments is shown in Figure 2. The Routers R1 and R2 acted as CIP gateways and MIP Foreign Agents. Table 1 shows some of the results obtained during the tests with the different mobility management schemes mentioned above. For further details, please see [2].
Figure 3: Test Setup for Context Transfer Additional results demonstrate the effect of AAA Context Transfer on multimedia services and also the impact on the performance of a TCP communication. The second scheme is a standalone context transfer module which has been designed to reside at an access router and to provide a message framework for the interworking between itself, the mobility management protocol and the context transfer candidate service protocol. Figure 4 demonstrates how the proposed context transfer solutions improve the overall handoff performance and hence can aid in realizing seamless and secure mobility management in IP-based
infrastructures. More details on context transfer can be found in [6].
CT Disabled
CIP
end-host and sends them across for display. Compared with the original Mobile IP, the significant decrease in handoff latency in the proposed scheme can be observed from Figure 5. As a consequence, the solution has been proven to reduce packet loss and improve the overall data throughput. D. Reconfiguration Network Management
EAP/T LS CT Enabled
MIP 0
1
2
3
4
5
6
7
Handof f Delay (seconds)
Figure 4: Context Transfer Results C. Cross-layer Signalling Design
RTP Packet Sequence Number
Set up signalling interface between mobility management at network layer (MIP) and application layer signalling protocol (SIP) enables the information exchanging regarding handoffs to enhance the real-time IP multimedia application performance. A few changes have been made to the implementations of MIP client and SIP UA in order to support signalling between SIP and MIP on the mobile hosts. Figure 2 depicts the experimental environment for real-time multimedia service performance evaluation over the proposed mobility management scheme. It consists of a HA, two FAs, a CH and a MH. The Mobile IP FA and MH functionality is provided by Dynamics [4], which is a Linux-based Mobile IPv4 implementation. The SIP proxy is co-located with the MIP FA. The Partysip software [1] provides this functionality.
The RMA Demonstrator implements a software reconfiguration architecture called Reconfiguration Management Architecture that represents a generic approach for controlling and managing the reconfiguration in software radio. The RMA represents a distributed architecture of two parts - terminal and network; that are needed for fulfilling the requirements of the software reconfiguration from network, user, operator, software provider, and manufacture and regulator perspectives. The RMA terminal part contains and their functionality are described and the mechanisms of the network resident Configuration Control Part (CCP) as well as the terminal resident Radio Module and Configuration Management Parts (RMC & RMP) are explained (see Figure 6). Network Interfaces Software Configuration Manager
Policies
0
1
2
3
4
5
6
Configuration Manager
Protocol GSM { Encode(); Decode(); };
Figure 6: Reconfiguration Management Architecture
8
For running SIP-based real-time multimedia, a videophone application is installed in both MH and CH. This application is a modified version of Linphone [1]. It captures real-time images from webcams at either
Terminal Internal Interfaces
Policies
Time (sec)
Figure 5: Handoff with Mobile IP and proposed solution
Software Tag_File
Software
MIP
7
Configuration Manager
Rules
SIP/MIP
Security
Network Interfaces
2300 2250 2200 2150 2100 2050 2000 1950 1900 1850 1800
Terminal-Network Interfaces Internal control, management and data Interfaces Reconfiguration Interfaces
The ‘Configuration Control Part’(CCP) is located within the (reconfiguration support) network, it executes those reconfiguration related tasks that affect the network or air interface and therefore require the approval of the ‘responsible authority’. The Configuration Management Part (CMP) performs tasks including the procurement of configuration software, handling of configuration rules, generation and compilation of tag-files, implementation of new configurations and finally reconfiguration related signalling. The Radio Module Part (RMP) hosts the actual radio platform which ideally it should be implemented as general processing platform capable to implement any radio configuration required.
protocols, provided by some industrial consortium and forums, or standardisation bodies, including UPnP [7], Bluetooth SDP [8], IETF SLP [9], SUN Jini [10] and Salutation [11]. Some problems are identified for using these protocols in wireless networks, such as mobility, heterogeneity, context awareness, and combination of local and remote discovery: •
Streaming Server H261 ∼15kbps
MPEG1 ∼900kbps
Mobile Terminal WaveLAN Connections ∼11Mbps
IP Network
3rd party provider
MServer
•
•
Figure 7: RMA Demonstrator
E. Service Discovery and Service Routing The services and resources in wireless networks must be discovered on a spontaneous basis. For this reason there are a number of service discovery
•
Applications
Security
Using, as example, a client program based on Java, where the execution environment allows the download, configuration and execution of new modules, whenever a new or specific (software-) module is needed. The demonstrator (See Figure 7) includes the implementation of the signalling and messaging procedures as well as of a graphical user interface to demonstrate the run time reconfiguration of the video codecs. Furthermore, a streaming server capable to handle H261 and MPEG media streams as well as the procedures for download and reconfiguration signalling between terminal and MServer were implemented. The demonstrator shows this procedure, it downloads first the MPEG1 codec and runs a streaming video from the local intranet. Then the whole procedure is repeated to replace the component (MPEG1 codec) with another, the H261 codec, and again a video stream is feed to the terminal, but this time from a remote site. In this way as using different locations, the demonstrator shows not only the functionality of the RSS but also the robustness and performance of the system as a whole as well as the innovativeness of the design of video codecs (system components).
Mobility: the mobility of nodes, whether client or server, implies necessity for mobility awareness of the services and clients. Even this can be handled at the lower layers of the network, (Network, etc.) but the service mobility is the issue that should be handled by the service management system. Heterogeneity: participation of different link technologies and network protocols, as well as service discovery protocols, results to the need for supporting a service discovery and provision platform, to support these kinds of heterogeneity. Context awareness: the context of the user, network and environment, affects the user service requirement, as the service should be adapted to the context state. Local and remote discovery: most of the existing protocols support discovery of the services within the local network. When the user is in need of discovering remote services in other remote sites, the service discovery system must be able to support remote discovery, as well as local one. Services
Service Management Layer Service Selection & Adaptation
Mobility
Context Discovery
Service Discovery
Naming services
The radio implementations on the RMP will be controlled by the CMP, the RMA only requires a clearly defined interface between RMP and CMP to install the reconfiguration software on the (processing) platform. The RMA only defines the interface between CMP and RMP but does not define the architecture of the RMP.
Transport
Figure 8: Service management platform For this reason, a service discovery and management system is proposed, which acts as a service platform for wireless networks. This service platform should manage and take care of the issues raised earlier. Figure 8 depicts the proposed architecture. This architecture is under implementation and integration in the Wireless Network Testbed. The framework of the system is derived from the Salutation platform, which is enhanced by definition of context discovery, mobility management, and service selection and adaptation
modules. At the transport layer, some existing discovery protocols, such as UPnP, SLP and Bluetooth SDP can be used for communication with the already equipped devices. For the remote discovery, some other P2P protocols such as JXTA [12] can be used.
F. Personal Area Network One of the research topics in wireless network testbed is the formation of Personal Area Networks and interconnection of such networks by using the infrastructure networks, such as Internet, 3G, etc. The PAN in wireless network testbed is setup by using ad hoc connectivity protocols, such as Bluetooth (802.15.3), WLAN (802.11b, ad hoc mode). For providing interconnectivity with the infrastructure, we use a dual port mobile router, which can be realised by using a router enabled node, which routes the packets between the PAN and the infrastructure network. This has been illustrated in Figure 9. BT PANU BT PANU
WLAN Bluetooth WLAN AP
BT NAP BT PANU
DHCP Server
Figure 9: A PAN connected to the infrastructure The research issues in this scenario are as follow: • Naming and addressing: how the nodes within the PAN should be named and addressed • Routing: how the routes must be established between the PAN and infrastructure. • Service discovery: how the services must be locally discovered and advertised remotely, (as addressed in the previous section) IV. CONCLUSIONS This paper gave an overview of the research work that has been carried out on a number of technical areas at the Wireless Network Testbed (WNT) at the University of Surrey. These areas included mobility management, context transfer protocol, cross-layer signalling, reconfiguration network management, service discovery and service routing, and personal area networks all of which have been briefly described, including a number of implementation results, to give
an overview of the research that has been carried out as well as to give a feel of the capacity of WNT for future and innovative research. Research in these and other related fields is ongoing and the WNT is expanding depending on the requirements for new software or hardware components. More up-to-date published results from the WNT can be found at [13]. REFERENCES [1] http://www.gnu.org/software/osip/osip.html [2] N. Akhtar, M. Georgiades, C. Politis, R. Tafazolli, "SIP-based End System Mobility Solution for AllIP Infrastructures", IST Mobile & Wireless Communications Summit 2003, 15-18th June 2003, Aveiro, Portugal. [3] http://www.comet.columbia.edu/cellularip/ [4] http://www.cs.hut.fi/Research/Dynamics/ [5] http://www.freeradius.org/ [6] C. Politis, T. Diagiuklas, N.Akhtar, M. Georgiades, R. Tafazolli, "Mobility Management and AAA Support Characterisation for Providing Seamless Multimedia Services over IP-based Infrastructures", IEEE Wireless Communications Magazine, August 2004. [7] UPnP Forum, “Universal Plug and Play Device Architecture”, June 2000. http://www.upnp.org/download/UPnPDA10_2000 0613.htm [8] Bluetooth, “Bluetooth Specification”, v1.2, https://www.bluetooth.org/spec/ [9] E. Guttman, C. Perkins, J. Veizades and M. Day, “Service Location Protocol, Version 2”, RFC 2608, http://www.ietf.org/rfc/rfc2608.txt?number=2608 [10] Sun Microsystems, “Jini Specifications”, v2.0, http://wwws.sun.com/software/jini/specs/index.html [11] Salutation Consortium, “Salutation Architecture Specification”, v2.0c, http://www.salutation.org [12] Project JXTA. http://www.jxta.org/ [13] http://www.ee.surrey.ac.uk/CCSR/Mobile/Publicati ons/
