Radio Frequency Convergence Protocol for 4G Networks

Transcription

1 Radio Frequency Convergence Protocol for 4G Networks ROSLI SALLEH, XICHUN LI, LINA YANG, ZHIYUAN Li Faculty of Computer Science and Information Technology University of Malay, 50603, Kuala Lumpur, MALAYSIA Abstract - CDMA Develop Group (CDG) has issued WLAN-CDMA convergence architecture for 4G Networks, which complement each other to provide ubiquitous highs-peed wireless internet connectivity to mobile users. In the merging networks, WLANs frequency is much wider than cellular network, the internet characteristics in frequency utilization that relates to request amounts to one fourth of its reply. This paper considers the disparity of both frequency and utilization, we combine the disparity frequency through developing a new protocol so that wireless mobile internet can be supply as same quality as fixed internet by 4G wireless mobile networks. Keywords: 4G Networks, Radio Frequency Convergence 1 INTRODUCTION The exponential growth of the Internet and the proliferation of cellular mobile systems and WLAN systems throughout both home and business applications generated both competition and cooperation among the different systems [1, 2]. In the near future, multimedia applications which are mainly achieved by wired and fixed internet users will be achieved by mobile internet users as well. To achieve this kind of advance level of mobile wireless multimedia services require the development of the internet, cellular communication network and WLAN network to be integrated to provide these emerging services [3]. Academic researchers and service providers have both thought ways to integrate the WLAN systems with mobile cellular systems and fixed Internet. The desire was to gain the increased data rates provided by WLAN working together with the mobility provided by cellular systems. This research effort focused on frequency combination and TCP/IP suite protocol enhancement to improve performance for data transmission. 4G wireless mobile internet networks will integrate current existing cellular networks and WLAN networks with fixed internet network [4, 5]. CDMA Develop Group (CDG) has issued the convergence architecture [4]. Capacity and data rates of both of WLAN and cellular system are dependent on many factors. One most important factor is frequency. In which WLAN frequency is much wider than CDMA2000 network integrating the WLAN- CDMA2000 network, therefore will cause conflict. In addition, when a mobile node comes into overlapping area by both of WLAN and CDMA2000, the mobile node will be landed over to WLAN. In this case, WLAN is busy and CDMA2000 network resource is wasted. In order to solve this problem, according to the internet characteristics in frequency utilization that relates to request amounts to one fourth of the reply [6], we propose to combine cellular network for uplink traffic services and b Wi-Fi network for downlink traffic service so that TCP/IP suite can work on both two networks simultaneously. Thus, frequency resources are efficient utilization, and we call the protocol is Radio Frequency Combination protocol (RFCP). The majority of the protocol is to distribute data into both frequencies of the two networks for transmission. By the way, we have chosen ns2 Java version (Java Network Simulator) to develop our system based on CDMA2000 1x-EVDO and Wireless LAN integrated networks [7]. Therefore, this paper is organized as following: section 1 is introduction and section 2 is literature review. The protocol design is in section 3, we describe the implementation and testing in section 4, and finally, section 5 is summarization and conclusions. 2 LITERATURE REVIEW This research is based on integrating of WLAN- CDMA2000 networks. Therefore, this section provides a basic theoretical background in 3G wireless cellular networks and the wireless LAN family of technologies that are required to understand. IEEE b and g are operating in 2.4GHz frequency band. They can support a maximum data rate of 11Mb/s and 54Mb/s respectively. Another ISBN: ISSN:

2 IDC IDC IDC 8th WSEAS Int. Conf. on MULTIMEDIA SYSTEMS and SIGNAL PROCESSING (MUSP '08), Hangzhou, China, April 6-8, 2008 standard i.e. IEEE a can offer a maximum data rate of 54Mb/s operating in 5GHz frequency band. For local area coverage, these technologies can achieve a higher data rate at a very low cost and therefore are now widely implemented in hotels, restaurants, shopping malls, homes etc. On the other hand, for a wide area coverage, the CDMA2000 network is widely implemented but with moderate data rate. For example, CDMA2000 1xEV-DO Release A can provide only up to 3.1Mb/s in downlink and 1.8Mb/s in uplink. These two networks are incompatible but allowing these networks to complement each other is an added advantage. Possible solution that we have proposed is to optimize the network usage by allowing mobile devices full access to both networks simultaneously. Issues in convergence these two networks have been addressed by the CDMA Development Group (CDG) [4]. Following the convergence architecture, in this research, the targeted network environment (Figure1) is an infrastructure-based wireless network within WLAN and CDMA2000 cell overlapping areas to allow mobile nodes to connect to multiple neighboring base stations and access points simultaneously. HA AP WLAN Internet Laptop PDSN BS CN rates over the WLAN-CDMA2000 integrated system. This research considers the frequency disparity of CDMA Mbs channels and WLAN 11Mbs channels. We combine the two frequencies so that mobile node can send requests through CDMA2000 channels and get reply through WLAN channels. The two motivations above drive us to propose a new protocol to deal with. The new protocol design is presenting as following. 3 PROTOCOL DESIGN From Lucent research, it is found that the internet characteristics in bandwidth utilization that relates to request amounts to one fourth of the reply [8]. WLAN bandwidth is much higher than cellular network. For the CDG proposal on CDMA-WLAN convergence network, at overlapping coverage area, users will be able to access the internet through the WLAN network for a higher data rate which is the case when the mobile node is fully handoff to WLAN network. In this case, under the overlapping coverage area, WLAN network will be very busy while the CDMA network resources not in used. On the other hand, if we let the mobile node to access the internet through the CDMA network only, the data rate served to the user will be very low. For these reasons, we thought that access integrations are an added advantage to the current CDMA-WLAN convergence architecture issued by CDMA Development Group (CDG) [4]. Therefore, we have proposed what we called Radio Frequency Combination Protocol (RFCP). The protocol overview is presenting as following Figure2. Cellular Figure1: Targeted Network Environment Since currently existing TCP/IP suite protocols can work on one network independently, it is limited working on two or more networks for cooperation. For example, in the WLAN-CDMA2000 integrated system, TCP/IP suite protocol can work on WLAN or CDMA2000 network, but it can not work on WLAN and CDMA2000 networks. Therefore, the first phase of our research is motivated by the need to have TCP/IP suite protocol capable of working on the integrated CDMA2000 and WLAN systems. Seamless services and applications via different access networks and technologies that maximize the use of available spectrum will be the driving forces for future developments. Therefore, the second phase of this research is motivated by the desire to improve data Figure2: RFC Protocol Overview The radio frequency combination protocol (RFCP) is implemented in between MAC layer and TCP/IP layer. An illustrative example of the functionality of RFCP consisting of RFC (Radio Frequency Combination) and RFCA (Radio frequency combination Agent) components is presented in Figure1 above. Packets received from higher layer are aggregated to ISBN: ISSN:

3 RFC. The RFC is defined to response for generating, sending out and receiving RFCP messages and subsequently using received updates to update the relevant routing tables in our simulation model. The RFCA is a component which holds information about direct link interfaces of one node and interfaces of other nodes associated with the RFCP. The RFC protocol design is based on WLAN frame structure [8]. The following items are related specifically to our RFCP: i. Type/Subtype field: Type/Subtype fields will be used to indicate that this frame is a RFCP frame. The type field will be set to the previously reserved value (11), and the subtype ( ) will be used to indicate any of the accepted data frames. ii. Duration/ID field: Immediately following the Frame Control field in the IEEE MAC header is the Duration/ID field. The Duration/ID field is also 16 bits in length. The contents of this field that relates to our research are as follows: 1) In control type frames of subtype Power Save (PS)-Poll, the Duration/ID field carries the association identity (AID) of the station that transmitted the frame in the 14 least significant bits (lsb), with the 2 most significant bits (msb) both set to 1. The value of the AID is in the range ) In all other frames, the Duration/ID field contains a duration value as defined for each frame type. For frames transmitted during the contention-free period (CFP), the duration field is set to Whenever the contents of the Duration/ID field are less than 32768, the duration value is used to update the network allocation vector (NAV). Therefore, Duration/ID is set to the size of the total aggregate frame body, rather than to any sort of individual packet sizes during contention period (CP), and is set to the specified value of for all CFP transmissions. iii. Frame Check Sequence (FCS): FCS will be computed over the entire aggregate header. 4 SIMULATION, IMPLEMENTATION AND TESTING After the RFC protocol design, the next step was to look at some of the code of JNS to get a basic idea about how the program was implemented. This was followed by setting up internetwork in JNS and visualizing them with JVS to see whether it was being set up correctly. Therefore, this section will proceed by presenting the simulation design, implementation of our proposal design and the tests that were carried out. 4.1 Simulation design As the simulation environment, we select ns2 Java version network simulator. The Java Network simulator (JNS) is chosen due to its flexibility and extensive model library sets. Furthermore, the JNS allows developers of networking protocols to simulate their protocols in a controlled environment. JNS then produces a trace file (same format as NAM trace files) which can be viewed in a network animator such as Javis [7]. Decisions about what to simulate for this system would be quite ambitious. Initially, the aim is to simulate a stand-alone version using the RFC protocol algorithm to update routing tables and, once this is established to be working correctly, RFCPMessage will be sent from one node to another. After this basic simulation has been accomplished, it can be extended to include request messages with responses and triggered updates. This simulation would also be expected to be able to cope with links in the internetwork. The requirement for this system simulation is to be able to send RFCPMessage within the convergence architecture after the routing table updated by the generated updates. It is therefore necessary to be able to distinguish mobile nodes for the RFCPMessage. Since these updates are variable, different routes can be used to send the RFCPMessages to different neighbors according to the RFC strategies. Therefore, this simulation scenario is shown in Figure3 as black array: Figure3: Simulation Scenario Model The simulation above requirements revealed the need for five main classes. The first and the most important class would be the class responsible for generating updates, sending them out, receiving updates and updating routing tables. This class is called the RFC class. Another important class is the class which holds all the information about the links in the network, i.e. the RFCA class. The other three classes are also ISBN: ISSN:

4 required to represent routes, routing tables and the update messages that get sent out; the Route, RoutingTable and RFCPMessage classes, respectively. 4.2 Implementation Our implementation consists of the classes as presented in Table1. The RFC class is core class which will be implemented in the essential algorithm associated with our proposed RFCP in our research. The relationships between the Simulator class and the element package of JNS and the classes associated with RFCP are illustrated in Figure4. Figure4: Main Implementation Classes Overview The first step for the simulation is to update the element of the network by the Simulator class. The Simulator class is a main class in the JNS, it contains main loop which can update the elements of the network. The RFCA class is the first class which runs in the simulation. During the RFCA class implementation, the network information is generated in the RFCA object, its neighbor link information is updated and a reference to the RFCA object will be getting from the Simulator class. Meanwhile, the RFCA class requests to have its own commands scheduled here to have them executed at a specific time. Every Command object contain the simulator time. The Command object is then scheduled by placing it in the simulator event queue. After then, the core RFC class is going to be run. In this stage, the RFC object generates updates for the RoutingTable. After the RoutingTable is updated, the new route is generated. When this implementation is finished, the new route information is transmitted to through the RFC object shown. The RFCA class updates its neighbor link information once received the new route, then the RFCPMessage send to its correct destination through the RFCA object. In order to make the system works, we need to make sure that it is capable of performing these tasks as following: Store network information. This is to complete by the RFCA object. During the implementation in this stage, the RFCA object is to store the network information, which is to be used to select a route and add the route into the RFCPMessage. The RFCPMessage. This object is to contain route information. Selecting a route for the RFCPMessage. This is to be completed by the RoutingTable object. All of possible routes are included in to the object, and the suitable route for the RFCPMessage is to be selected. Adding the route for the RFCPMessage. This is to be completed by the Route object. Once the suitable route established, the route is to be added into the RFCPMessage. Updating the routing table. This is to be completed by the RFC object. Main Class Description Name Simulator The main JNS class Contains instances of element Will call the first RFCA class Initialize the internal network structure and implementations RFCA Contains instances of element, such as Node, Interface and Link The RFCA class holds all information of the network, which used to send messages out Updating its neighbor link information Getting a reference from the JNS simulator class RFCPMessage Contains Route Contains interface from and interface to Two kind of the RFCPMessages: Request and Response RoutingTable Contains all of possible routes in each node Route Supplied to RFCPMessage class Supplied to RoutingTable class RFC Generating RFCPMessage Generating its updates Sending messages Receiving messages Table1: Implementation Classes ISBN: ISSN:

5 4.3 Testing The RFC Protocol testing is to verify the original designed expectation. The original designed idea is to create a new protocol to update the CDMA2000-WLAN convergence network routing table so that data message can be sent through CDMA2000 network and reply through WLAN network. Therefore, two main testing needs to be done in order to proof our concept as follows: To verify the proposed protocol whether works on the convergence network properly The routing table whether updated or not. If all of the expectation of the original designed idea can get from the system correctly, the system output file should show this information. Figure5: Testing Network Model In order to do this testing, it is necessary to configure Java Network Simulator environment. Simple network of four nodes is established within the JNS. Our testing is based on the simple network design as shown Figure5 above. The Nodes replace for the CDMA2000 network traffic and the Nodes replace for WLAN network traffic within the CDMA2000-WLAN convergence architecture. We have systematically tested each class that we have added in what is called a bottom-up testing methodology. The results show that each class is working as expected. These tests and their results will not be shown through visualizor. Only after that, we can proceed with the real test, i.e. testing the updating of routing table. There are three items that need to be verified through out this testing as follows: Integrating Test for the RFCP and JNS This test is to verify the interoperation after the integration of the RFCP and JNS. A simple network with four nodes has been established for this test (see Figure5). The RFCA class is the first class for executing in the JNS. We have added RFCA as a variable into the JNS simulator. After the execution of the RFCA class, the network information in the RFCA object is to be generated, the node neighbor links information is to be updated by calling the update method of the RFCA class and get a reference to the RFCA object of the simulator. In order to generate network information as designed, we have assigned IP address to each node interface. The IP address for Node0 interface is , for Node1 interface is There are three interfaces for Node2, which are , and , respectively. Node3 interface is All the subnet masks are set to If the system is working as expected, the routing table for each node should be generated after the simulation test. This test has been done and the routing table has been generated, the routing table for Node1 has shown as follows: Routing Table for Node1 Destination Neighbor OutgoingIfaceAddress Default route Node N/A N/A From this test we can verify that the network information has been stored by the RFCA class after setting up the four nodes simple network in JNS. The output shows the initialized routing tables for all nodes, followed by lists of node interface IP addresses with the IP addresses of the interfaces that they are directly attached to. After this there is a list of node names together with the IP addresses associated with each of them The RFCP Packets Test This test is to verify that whether the RFC protocol packet can be delivered properly between two mobile nodes. The Figure6 and Figure7 follows have shown the testing results. We have proposed the new protocol for radio frequency combination of CDMA2000-WLAN convergence architecture through adding new fields into the RFCPPacket. It is therefore necessary to test this new fields functionality. We defined the RFC protocol packet as vector. The packet will be aggregated between two nodes. One node is for source of the packet, and the other is for destination. If the RFCPPackets work well on this new protocol, the packets should send from Nodes and then from Nodes In Figure 6, the RFCPPakcet transmitted from Node0 to Node2 and finally arrived in Node3. The Node0 is the mobile node, the Node2 is packet data switch node, and the Node3 is corresponding node. Three of these nodes together work on the CDMA2000 ISBN: ISSN:

6 network under the convergence architecture of CDMA2000-WLAN. In Figure7, the RFCPPakcet transmitted from Node3 to Node2 and finally arrived in Node1. The Node1 is the packet data interworking function, the Node2 is packet data switch node, and the Node3 is corresponding node. Three of these nodes together work on the WLAN network under the convergence architecture of CDMA2000-WLAN. From Figure6 and Figure7, this test has verified that the RFCPPackets are successfully transmitted on the convergence architecture of CDMA2000-WLAN. Figure6: Packet Up from Right Figure7: Packet Down from Left The RFC Protocol Test This test is to verify the RFC protocol and the RoutingTable. This test is still based on the four nodes simple network established in Figure5. The RFCP packets are to send from Node0 to Node2 and Node3, finally, it arrives in Node1. The RFC object generates updates, and then updates the RoutingTable. We have designed two kinds of RFCP packets shown in section 3. The one is request of the RFCP packet, and the other is the response. If the routing table has been updated successfully, the request of the RFCP packet should be send out from Node0 to Node2 and Node3, and the response of the RFCP packet should be reply from Node3 to Node2 and Node1. We have mentioned in above that Node0, Node2 and Node3 is working on the CDMA2000 network under the convergence architecture of CDMA2000- WLAN, and the Node3, Node2 and Node1 is working on the WLAN network under the convergence architecture of the CDMA2000-WLAN. Once the RFCP request packets send out from the Nodes and response from Nodes 3-2-1, this can certify that the mobile node sends the RFCP request packets through the CDMA2000 network and get reply through WLAN network. This test has been done and the routing table has been generated. After the Node3 routing table has been updated successfully, the routing information for the Node3 has presented as follows: Destination nextnod OutgoingIfaceAddress Default route Node Node Node Node N/A N/A From this test we can verify that the routing table has been updated successfully. The generated routing table for Node3 shows that the default route for Node3 is Its first destination is Node2 in which Node2 interface is And the Node2 s nextnod interface is Its second destination is Node1 with interface Thus, the packets transmitted from nodes The Testing Results Analysis Our RFC protocol is evaluated based upon throughput. The CDMA2000 network and WLAN are differing in frequency. We have combined the two network frequencies through creating the RFC protocol in order to get higher data rates. Throughput can be used to evaluate performance of the frequency combination as a main metric. In communication networks, throughput is the amount of digital data per time unit that is delivered over a physical or logical link, or that is passing through a certain network node. For example, it may be the amount of data that is delivered to a CDMA2000 network mobile node or a WLAN network mobile node, or between the two mobile nodes. The throughput is usually measured in bits per second (bits/s or bps), occasionally in data packets per second. Relative to our research and the WLAN data link layer, throughput is defined as the total number of bits sent to the higher layer from the data link layer. The ISBN: ISSN:

7 data packets received at the physical layer are sent to the higher layer if they are destined. We measured this value in terms of bits per second. Throughput represents an average rate of traffic flow where higher values are better. Throughput is very important aspect that can determine the quality of service of wireless network for our new protocol. During the proposed protocol was simulating, we connect data of throughput and available bandwidth, and then we generated the comparison for the throughput and available bandwidth which has been presented in Figure8 follows. If the proposed protocol is working well on the radio frequency of convergence architecture of CDMA2000-WLAN, we are to get the relationship of the throughput and available bandwidth. From the Figure8, it clearly has shown the differences between the convergence architecture of CDMA2000-WLAN and CDMA2000 network. Once TCP/IP working on the different networks, the network can supply different throughput. The throughput is much higher when TCP/IP working on the convergence architecture of CDMA2000-WLAN then the CDMA2000 network. Further more, the throughput increases when the available bandwidth increases under the convergence architecture of CDMA2000-WLAN, and the available bandwidth of WLAN much wider then CDMA2000 network. Therefore, the proposed RFC protocol working with TCP/IP suite protocol on the convergence architecture of CDMA2000-WLAN always has a higher throughput then TCP/IP working on CDMA2000 network. Throughput (bps) TCP/IP Working on Networks Avaliable Bandwidth (Mbs) TCP/IP Working on Both Networks TCP/IP Working on CDMA2000 Network Figure8: Throughput vs Available Bandwidth 5 CONCLUSION AND FUTURE WORK In this paper, The RFC protocol has been defined to response for generating, sending out and receiving RFCP messages and subsequently using received updates to update the relevant routing tables. We have presented the rationale and design overview of the simulation-based experiments employed to evaluate our new RFC protocol. We used JNS standard models and modified them to support our RFC protocol. The simulation results have been evaluated through throughput and data session delay parameters. We have defined both of the parameters and measured them in our simulation system. The results have shown that the throughput is increased when TCP/IP working on the integrated network. Furthermore, TCP/IP working on the integrated network can increase data rates more promptly then it working on CDMA2000 network. The above protocol does not consider issues such as congestion relief, re-negotiated QoS, or the movement pattern of the mobile node. In future, there is a need to develop a new detection algorithm that can support the broad level of network integration promised by the 4G wireless system. REFERENCES [1]. S. Y. Hui and K. H. Yeung, Challenges in the migration to 4G mobile systems. IEEE Communications, vol. 41, No. 12, Dec [2]. P. Vidales, R. Chakravorty, and C. Policroniades. PROTON: A Policy-based Solution for Future 4G devices. In Proceedings of 5th International Workshop on Policies for Distributed Systems and Networks (IEEE POLICY 2004), New York, United States, June [3]. 3GPP2, CDMA2000 WLAN Interworking, S.R0087-Av1.0, Mar [4]. Jatinder Pal Singh, Tansu Alpcan, Xiaoqing Zhu, Towards Heterogeneous Network Convergence: Policies and Middleware Architecture for Efficient Flow Assignment, Rate Allocation and Rate Control for Multimedia Applications, MNCNA 07, Port Beach- CA, USA, November 26, [5]. Yu Zheng, Dake He, Weichi Yu and Xiaohu Tang, Trusted Computing-Based Security Architecture For 4G Mobile Networks, Proceedings of the Sixth International Conference on Parallel and Distributed Computing, Applications and Technologies (PDCAT 05) IEEE,2005. [6]. Lucent technologies, Wireless Network Systems- 3G Engineering Guidelines. June [7]. [8]. IEEE : IEEE Std (1999): "Standard for Information Technology -Telecommunications and information exchange between systems - Local and Metropolitan Area networks - Specific requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications". ISBN: ISSN: