Adapter Implementation between Wimax Specic Layers and Network/Application Layers

Tuomas Nissil , Jyrki Huusko, Ilkka Harjula, and Marcos Katz a Technical Research Centre of Finland (VTT) Oulu, FIN-90570 Email: Tuomas.Nissila@vtt. Telephone: +358405028168, Fax: +358207222320

Abstract
Several recent studies show that future high data rate broadband wireless access (BWA) technologies require the use of adaptive and co-operative techniques to more efciently utilise the resources in link and system level. In this paper we propose an adapter module to be utilised in the data link layer (DLL) and optionally in the application layer to serve different adaptive triggering routines among the networks. The adapter is used to retrieve the necessary information from hardware (HW) to aid different adaptation processes in system. The adapter is also used to trigger the preferred control and management actions in the media access control (MAC) and physical (PHY) level of the related HW. The usability and performance limits of the designed and implemented adapter solutions were measured with relevant performance evaluations and the derived results validate the feasibility of the proposed adapter solution.

1. Introduction
Several recent studies show that future BWA technologies will exploit different adaptive and co-operative techniques [1, 2, 3]. Reference [3] studies different adaptive techniques to achieve the requested quality of service (QoS) demands of future technologies. Reference [2] emphasizes the use of co-operative techniques to allow a more efcient utilisation of system resources. Reference [1] is one example of a recent project studying the utilisation of BWA technology to serve applications in stringent environmental conditions. One example application scenario is scalable video transmission, which is highly dependent of certain CSI and link performance information [4]. In addition to adaptive applications, the resource control, access control, and other environment aware adaptive processes re-

quire certain CSI and network state information, too. The problem is that, currently, the WiMAX technology is relatively new and does not support those adaptive features over the L2 layer. Advocating these concepts, this paper describes the implementation of an adapter module that serves different adaptive processes, including those motivating examples, among the future BWA network. The adapter gathers and derives the necessary input information to aid in decisions of adaptation. The adapter is also used to trigger the preferred actions of the HW. In this paper we propose an adapter module to be utilised in the DLL and optionally in the application layer. A network device driver is used to serve the former DLL solution of the adapter. An SNMP client module is used to serve the latter application layer solution of the adapter, as SNMP is planned for standardized use in many future BWA technologies. The adapter solutions are further suggested to be utilised by following the cross-layer and convergence layer contexts. Section 2 gives a high level description of the proposed adapter implementation. Section 3 examines two optional adapter solutions dealing with different environments. Section 4 presents the evaluations for the adapter solutions, and Section 5 concludes this paper.

2. System Model
This section gives a high level view of the adapter architecture. In Figure 1, the adapter and its co-operative modules are presented. The adapter is intended to operate in different systems and environments. In access service network gateway (ASN-GW) and network control system (NCS) there is need to interface the related HW indirectly, horizontally, through the SNMP agent, using the SNMP protocol. The SNMP agent is implemented by HW manufacturer providing the necessary SNMP operations for control and management. In customer premises equipment

The 2007 International Conference on Next Generation Mobile Applications, Services and Technologies (NGMAST 2007) 0-7695-2878-3/07 $25.00 2007

(CPE), subscriber station (SS) and base station (BS) there can be a reasonable vertical HW access present, depending on the openness of the HW. Thus, there is motivation for a network driver to be included in the adapter solution to utilize the direct, vertical, HW access in DLL.

AI

Figure 2. Cross-layer design. the preferred control and management actions of the related HW. The cross-layer signaling between user application space and kernel-space is implemented using the device specic input-output control (IOCTL) commands. The cross-layer signaling between different kernel-space modules is implemented using the public kernel symbols.

HWI

3.2. Convergence Layer Requirements

Figure 1. Adapter architecture. The convergence layer, presented in Figure 3, utilises a triggering mechanism to manage the preferred network interface selection and handovers. Triggering mechanism, similar kind as in reference [5], is based on the CSI, link QoS, application QoS and network state information gathered through the vertical and horizontal signaling channels over the network and the protocol stack, using the crosslayer context.

3. Adapter Implementation for Various Environments

This section describes some further requirements for the adapter and its implementation for various environments. First cross-layer, convergence layer and HW requirements are overviewed. Then, the designed and implemented adapter solutions are presented.

3.1. Cross-Layer Requirements

Cross-layer context, depicted in Figure 2, allows direct communication links between non-neighbor layers of the protocol stack, which leads to efciency and power saves in system, when designed carefully [2]. Following the cross-layer context the co-operation can be more efciently utilised between non-neighbor layers, which is a valuable aid for future BWA technologies [2, 3]. One example application scenario utilising cross-layer context can be tracked from reference [4]. The adapter shall implement a cross-layer signaling mechanism to serve different cross-layer interactions in the protocol stack. The adapter is designed to retrieve and deliver the requested channel state information (CSI) from the interested HW to different adaptation routines using the cross-layer approach. The adapter is also used to trigger

Figure 3. Convergence layer utilizing different HW technologies and cross-layer context. The adapter retrieves and delivers the requested CSI and link performance information for convergence layer triggering purposes. The adapter also provides a reasonable crosslayer signaling mechanisms for convergence layer to aid the convergence layer triggering functions. The adapter is further used to trigger the preferred control and management actions of the related HW.

The 2007 International Conference on Next Generation Mobile Applications, Services and Technologies (NGMAST 2007) 0-7695-2878-3/07 $25.00 2007

3.3. Hardware Requirements

The utilised HW sets the low level requirements for the adapter implementation. When the necessary HW access is available, the preferred control and management action triggering of the HW can be made directly in DLL. When a relevant HW access is not available, there is need for horizontal signaling to full the demands. The horizontal interactions of worldwide interoperability for microwave access (WiMAX) HW can be made in standardized way via the SNMP protocol [6]. From the adapter point of view, there are two optional ways to interact with the related HW. One way is vertically by the network device driver. Another way is horizontally via the SNMP protocol, with a convenient SNMP client implementation. Referring to [6] and [7], a WiMAX Forum certied equipment shall support at least the last option of those two. Thus, there is a motivation to implement an adapter solution that relies on the SNMP, but also allows the CSI retrieval directly from HW when a relevant HW access is available in DLL. In SS and CPE systems there are both SNMP client and network driver to serve the demands. In ASN-GW and NCS systems there is only the SNMP client to allow the horizontal interactions with the related HW.

mented with UNIX socket, serves the interactions with the adaptive processes.

3.5. Adapter for SS and CPE systems

The adapter in SS and CPE includes two separate modules. One module is an SNMP client operating in Linux user-space and the other module is a network device driver operating in Linux kernel-space. Figure 5 represents the adapter solution for SS and CPE systems. SNMP client term is used here to substitute for SNMP manager, which is used in pure SNMP manager/agent paradigm. Client is more convenient to use here, as it is widely used in programming terminology.

3.4. Adapter for ASN-GW and NCS systems

This section overviews the adapter solution for ASNGW and NCS systems. The architecture of the adapter is presented in Figure 4.

IOCTL

IO CT

v de t_ ne

ice

Figure 5. Adapter solution for SS and CPE systems.

I UN

So

e ck

Figure 4. Adapter architecture in ASN-GW and NCS systems.

The SNMP client and network device driver modules communicate with each other via certain device specic IOCTL commands, using the cross-layer approach. The adapter serves both Linux kernel-space and user-space modules and provides data transfer between the internet protocol (IP) layer and the network device driver via the net device interface. The SNMP client is implemented by using the NetSNMP C application programming interface (API) [9]. The example solution for loop-back network device driver [11] is used as a base for the kernel-space adapter implementation. The example solution includes the basic functionalities for each network device driver. The additional implementations are made to allow the use of a driver for CSI servicing purposes and for cross-layer signaling.

The adapter solution, operating in ASN-GW and NCS systems, has two different interfaces. The SNMP interface is for horizontal control and management action triggering of the SNMP agent, hosting the related HW. The control and management actions include also the CSI retrieval for different adaptation purposes. The adapter interface, imple-

The 2007 International Conference on Next Generation Mobile Applications, Services and Technologies (NGMAST 2007) 0-7695-2878-3/07 $25.00 2007

HWI

4. System Evaluation
The adapter solutions were evaluated in laboratory, under line-of-sight (LOS) condition, assuming that the utilised WiMAX link was relatively static. The evaluations were made with system clock, which may lead some light error in the measurements. An error margin of 10% is required for reliable adapter evaluations, system clock providing reasonable resolution for measurements.

4.1. Evaluation System

Figure 6 shows the evaluation system environment of the adapter solutions. The system consists of one BS and one SS (WiMAX 16d), a Windows server with network management software (NMS), and Linux laptop computer. The BS and Windows server are connected into a local Willab network. The SS utilises the wireless WiMAX 16d link provided by the BS. The laptop computer is connected to the SS or the core service network (CSN), depending on the performed evaluation activity. Figure 7. Evaluation system modules of SS and CPE adapter solution.

Figure 8. Evaluation system modules of ASNGW and NCS adapter solution.

4.3. Evaluation activities

The evaluations of the adapter implementation consist of performance evaluations of different adapter interfaces. We describe both the SNMP interface evaluations using the available WiMAX 16d or Ethernet link and the evaluation actions for the different kind interfaces for an adaptive process. The latency of an SNMP request consists of the link delay and the request processing time. Figure 6. Evaluation system. 4.3.1: Evaluations for SNMP interface As seen in Figure 6, the evaluation environment supports both implemented adapter solutions. The wireless WiMAX 16d link is used when evaluating the adapter solution for SS and CPE systems. The Ethernet link is used to evaluate the adapter solution for ASN-GW and NCS systems. The performance of the SNMP interface was evaluated measuring the round-trip delay experienced by an SNMP GET request. The convention to use different amount of sequential requests with variable amount of OIDs were used in the evaluation. From the gathered results, presented in Tables 1 and 2, an approximation of maximum SNMP servicing rate can be derived. For the used evaluation congurations, the SNMP request servicing rate is 1/53 ms when using WiMAX link and 1/6 ms when using Ethernet link. That leads to approximately 18 requests/second and 156 requests/second, respectively. As the SNMP request processing can be assumed to take similar time regardless of the utilised link, the delay of

4.2. Evaluation system modules

Figures 7 and 8 describe the evaluation system modules of the adapter solutions on the SS and ASN-GW sides, respectively. The additional user-space and kernel-space modules were implemented to get the necessary support for evaluation activities.

The 2007 International Conference on Next Generation Mobile Applications, Services and Technologies (NGMAST 2007) 0-7695-2878-3/07 $25.00 2007

quests utilising the Ethernet link, as described in Figure 9. Table 1. Round-trip delay of SNMP request via WiMAX 16d link in milliseconds.

OIDs in request Request amount 1 10 20 50 100 200 500 1000 Average roundtrip delay

1 49 498 980 2480 4940 9900 24929 51276 51

10 49 500 1000 2488 4950 9960 24990 51328 51

20 50 500 1001 2500 4960 9987 26309 51349 51 53

50 50 500 1008 2971 4988 9990 26317 51449 52

100 61 601 1201 3910 5981 11981 30010 61489 61

200 TO TO TO TO TO TO TO TO TO

Figure 9. Evaluation set: UNIX socket - SNMP.

The achieved evaluation result was 15 ms. That leads to servicing rate of 66 requests per a second. 4.3.3: SNMP request evaluations using kernel symbol interface This section presents the evaluation activity to measure the performance of the SNMP GET requests using the kernel symbol interface and wireless WiMAX 16d link, as described in Figure 10. The performance is evaluated by measuring the round-trip delay for SNMP request experienced by the kernel-space module.

Table 2. Round-trip delay of SNMP request via Ethernet link in milliseconds.

OIDs in request Request amount 1 10 20 50 100 200 500 1000 Average roundtrip delay

1 30 39 55 88 163 304 742 1458 2

10 31 40 70 145 268 513 1243 2454 3

20 32 57 95 211 397 771 1925 5230 5 6

50 40 100 178 407 817 1613 3998 8052 8

100 44 157 318 766 1524 3033 7574 15145 15

200 TO TO TO TO TO TO TO TO TO

Figure 10. Evaluation set: Kernel symbol IOCTL - SNMP. The resulting round-trip delay for the kernel symbol interface was 62 ms. For the used evaluation system, the SNMP servicing rate is 1/62 ms when using the dened kernel symbol and WiMAX link. That leads to servicing rate of approximately 16 requests per a second. 4.3.4: SNMP request evaluations using IOCTL interface This section denes the evaluation activity to measure the performance of the SNMP requests using the IOCTL interface and wireless WiMAX 16d link, as described in Figure 11. The performance is evaluated by measuring the round-trip delay for SNMP request experienced by the userspace independent module. The resulting round-trip delay for IOCTL interface was 83 ms. The SNMP servicing rate is 1/83 ms when using the dened IOCTL interface and WiMAX 16d link. That leads to servicing rate of 12 requests per a second.

WiMAX 16d link is seen to be notably higher than the delay of Ethernet link. Seemingly, the delay of WiMAX and Ethernet links are around 49 ms and 2 ms respectively, suggesting that the SNMP request processing time is 4 ms in average. These evaluation results provide the background for the adapter performance analysis. Next, the evaluations of other adapter interfaces are overviewed. The evaluations were made following the conventions used in SNMP interface evaluations here. 4.3.2: SNMP request evaluations using UNIX socket interface This section presents the evaluation activity to measure the feasibility of the adapter solution for ASN-GW and NCS systems. The performance of an UNIX socket interface is evaluated by measuring the round-trip delay for SNMP re-

The 2007 International Conference on Next Generation Mobile Applications, Services and Technologies (NGMAST 2007) 0-7695-2878-3/07 $25.00 2007

[3] S.G. Glisic, Advanced Wireless Networks, 4G Technologies, John Wiley & Sons Ltd., West Sussex, England, 2006. [4] Jyrki Huusko, Janne Vehkaper , et al., Cross-layer ara chitecture for Scalable Video Transmission in Wireless Network, Elsevier Signal Processing: Image Communication, 22th April 2007, pp. 317-330. Figure 11. Evaluation set: IOCTL - IOCTL SNMP. [5] Jukka M kel and Kostas Pentikousis, Trigger Mana a agement Mechanisms, Proceedings of 2nd International Symposium on Wireless Pervasive Computing, San Juan, Puerto Rico, February 2007. [6] IEEE Computer Society and the IEEE Microwave Theory and Techniques Society, IEEE 802.16f Standard for Local and Metropolitan Area Networks - Part 16: Air Interface for Fixed Broadband Wireless Access Systems, Amendment 1, Management Information Base, IEEE Press, 2005. [7] Redline Communications on behalf of the WiMAX Forum, WiMAX Forum Certication of Broadband Wireless Systems, WiMAX Forum, 2005. [8] S. Mo, Assessing the worldwide potential for WiMAX, Journal article on Telecommunications, Horizon House, Norwood, MA 02062, USA, January, 2006, Vol. 40, N. 1, pp. 17-19. [9] Net-SNMP, Net-SNMP Web site, URL: http://netsnmp.sourceforge.net/, Read 9.5.2007. [10] K. Wehrle, F. P hlke, et al., The Linux Networking a Architecture: Design and Implementation of Network Protocols in the Linux Kernel, Prentice Hall, New Jersey, USA, 2005. [11] A. Rubini, J. Corbet, and G. Kroah-Hartman, Linux Device Drivers, 3rd. Edition, OReilly & Associates, Inc., USA, 2005.

5. Conclusion
This paper proposed an adapter implementation for control and management action triggering to serve different adaptation routines in future BWA technologies. The two optional approaches were considered, namely the network device driver in DLL, and SNMP client in the application layer. The network device driver enables the necessary HW interactions directly in DLL. The SNMP client communicates horizontally with the SNMP agent of the HW. The usability and performance limits of the designed and implemented adapter solutions were measured with relevant performance evaluations. The derived evaluation results show that both implemented adapter solutions can readily be used for their planned use. The main principal starting point and guideline for the further development work is that the adapter solutions principally ground a base to congure, control and manage different kind HW, in two optional ways. The target HW in this initiative was a WiMAX HW, but the same principles are applicable for any other HW.

Acknowledgment
The authors would like to thank EU IST-FP6 WEIRD project for partially funding this research work.

References
[1] E. Guainella, E.Borcoci, et al., Extending WiMAX to Novel and Stringent Wireless Scenarios: An Introduction to the WEIRD Project, Conference on Broadband Europe, Geneva, Switzerland, 11-14th November 2006. 6 p. [2] F.H. Fitzek and M.D. Katz, Cooperation in Wireless Networks: Principles and Applications, Springer, Dordrecht, The Netherlands, 2006.

The 2007 International Conference on Next Generation Mobile Applications, Services and Technologies (NGMAST 2007) 0-7695-2878-3/07 $25.00 2007