TERMINAL BRIDGE EXTENSION OVER DISTRIBUTED ARCHITECTURE

Transcription

1 TERMINAL BRIDGE EXTENSION OVER DISTRIBUTED ARCHITECTURE Sami Saalasti, Juha Jääskeläinen and Ari Valtaoja Lappeenranta University of Technology P.O.Box 20, Lappeenranta, Finland {sami.saalasti, juha.jaaskelainen, ABSTRACT The fact that several different wireless networks and mobile devices have become common has lead to the need of convergence; most of the today s wireless technologies are not compatible with each other without any additional software or hardware components. Common Object Request Broker (CORBA) architecture provides middleware solution for several platforms and can be used as a communication layer between mobile devices. Although CORBA makes it possible to run services on different mobile device platforms it cannot provide roaming or handoff between the access points. Alternative approach is to use Wireless CORBA, an enhanced version of CORBA which is more flexible and better suited to handle problem situations typical for wireless communication. The Wireless CORBA can be used with a Terminal Bridge extension module which enables roaming and automatic handoff depending on the varying network link quality. KEYWORDS CORBA, Wireless CORBA, Distributed services 1. INTRODUCTION While wireless networks have become common varying from small Bluetooth networks to large-scale GSM networks, there yet doesn't exist any general model for using these different wireless technologies together. Common Object Request Broker (CORBA) offers a communication middleware solution for several platforms and it can be also used on mobile devices over wireless networks. However, CORBA has been developed to operate only on fixed networks and it presumes that the underlying network medium is reliable, which is not the case in the wireless environment. To overcome these problems Object Management Group (OMG) has developed a new specification, Wireless Access and Terminal Mobility in CORBA [1]. New evolution of CORBA, the Wireless CORBA [2] follows this specification and it has been developed to specially operate on wireless networks. Thus, the Wireless CORBA offers a software middleware solution for communication on several platforms with capability of performing flexible change of network access point. This process is called handoff. When a terminal device moves away from its current access point's range, a handoff to a new access point has to be performed if the connection is wanted to continue. Although the Wireless CORBA makes this handoff process possible it doesn't define how the access points are located. To solve the problem of finding access points, an extension module was developed by the authors to operate with the Wireless CORBA Terminal Bridge. This work was done in Lappeenranta University, Laboratory of Communication

2 Engineering. The Terminal Bridge extension is implemented for Linux operating system and it was used on Intel x86 -architecture. However, Wireless CORBA and the Terminal Bridge extension can be easily cross-compiled for example to be used on Compaq ipaq handheld devices running Linux. When a Wireless CORBA application utilizes the Terminal Bridge extension, network discovery is performed automatically. The module takes also care of selecting the best found transport medium and performs a handoff when the connection weakens or breaks. Currently Bluetooth [3], IEEE Wireless Local Area Network (WLAN) [4] and General Packet Radio Service (GPRS) are supported. This means that if the user moves away from for example Bluetooth's coverage area, connection is switched to WLAN or GPRS and data transfer can continue after the connection is re-established. Wireless CORBA takes care of buffering the data while the handoff is performed. 2. DISTRIBUTED SERVICE ARCHITECTURE Distributed service architecture describes a network environment which offers shared services to network users. Services can be distributed by using different approaches over CORBA or the Wireless CORBA. Both CORBA architectures can support several wireless networking technologies such as Bluetooth, WLAN and GPRS. The idea is to provide access to a shared service from different kinds of mobile networks. These services can be used by devices like PDA-devices, cellular phones etc. This chapter describes both CORBA architectures and a centralized service model which can be utilized with the Terminal Bridge extension. 2.1 CORBA CORBA is OMG's open, vendor-independent architecture that enables creation of distributed applications (Figure 1). Usage of standard protocols allows CORBA-based program from any vendor, on almost any computer, operating system, programming language, and network to interoperate with a CORBA-based program from another vendor [1]. Figure 1. CORBA architecture. The main strength of CORBA is that the network layer is completely hidden from applications so all details related to argument marshalling, connection handling, flow control etc. are taken care by the Object Request Broker (ORB). At the same time however, the underlying network must be reliable because no connection failures are

3 expected. This is also one of CORBA s main weaknesses when it is used in a wireless environment. 2.2 Wireless CORBA Compared to traditional CORBA, the Wireless CORBA has some additional components which enable handoff between different network technologies (Figure 2). Terminal Bridge (TB) and Access Bridge (AB) form a tunnel that is used to carry GIOP packets over onehop wireless link using a special GIOP Tunnelling Protocol. Home Location Agent (HLA) keeps track of terminal s current location. Access Bridges are software components which are located on technology specific network access points. If Terminal Bridge wants to create a connection, it must make sure that specific access point has also Access Bridge running. This Access Bridge detection is discussed further in chapter 3. Wireless CORBA utilizes centralized service model. The main goal for this model is to provide one centralized service which can be accessed through several networks using the Wireless CORBA Access Bridges (Figure 2). Access Bridge forwards traffic from the Terminal Bridge to the server using the available network medium. The GIOP protocol between the bridge components is mapped to the specific network transport protocol (for example Bluetooth). The whole underlying architecture is transparent for applications, so in theory existing CORBA application could be used as they are. In practice however, the situation is more complex. There may be multiple wireless networks available and the Wireless CORBA lacks methods to detect possible new networks if the current connection drops. Also HLA makes the whole architecture quite heavy. The fact that the centralized service model contains only one instance of the given service can be true benefit when considering network resources but if this one centralized service fails, user can't have service of any kind. Home Location Agent Access Bridge Backbone network Service Terminal Bridge Access Bridge Figure 2. Wireless CORBA architecture. wired link wireless link Wireless CORBA is not the only way to distribute services in wireless networks. For example Mobile IP [5] provides the ability to roam from different IP networks to another while still keeping the original identity of the device. This is done with the division of home and visiting networks and location registers. Data is always forwarded to the home address of the device. Services in this environment can use the same IP network as in fixed network also, e.g. CORBA could be run directly in this environment. Still the problem of selecting from the available wireless networks in the case when the current connection

4 drops, exists also in Mobile IP. However, this paper addresses the handoff issue only in Wireless CORBA. Mobile IP and handoff is out of the scope of this paper. 3. WIRELESS CORBA TERMINAL BRIDGE EXTENSION The Wireless CORBA Terminal Bridge extension makes it easier to use CORBA services on wireless networks. This extension automates the handoff process and guards the connection state by monitoring signalling level. If the current connection seems to be too weak, the Terminal Bridge extension selects another available access point and commands Terminal Bridge to perform a handoff. Connection is then switched to the Access Bridge locating on selected access point. Handoff process is illustrated in Figure 3. Because Terminal Bridge must make sure that access point contains also Wireless CORBA Access Bridge, a user-defined access point list is used. This list contains every known access point which has also Access Bridge running. Selection of next access point is handled using priorities. Access points can be given priorities depending on user needs: because Bluetooth has low power consumption [6], it would be ideal to give higher priority to Bluetooth access points if mobile devices battery consumption is the case of worry. Figure 3.Terminal Bridge extension guided handoff process 3.1 Implementation of the Terminal Bridge extension The Terminal Bridge extension structure is based on the idea of abstract factory pattern; factory provides an interface for implementing specific objects depending on the case and need. Seeker takes care of inquiry of devices, Monitor monitors active connection's link strength and Pinger can be used to check the presence of the communication medium. Every part has a specific implementation for Bluetooth, WLAN and GPRS (Figure 4). When the Terminal Bridge extension is initiated it searches all the devices described on a specific access point list using the inquiry function, sorts the access point list using priorities and selects the best found access point. This user-defined access point list contains information about network type, interface's hardware address and the Wireless CORBA Access Bridge's address. For WLAN there is also information about WLAN access point s hardware address. Handoff to the selected access point is then performed

5 using the Terminal Bridge's handoff implementation. If the link level gets too low or the connection breaks, the next access point is selected from the access point list. After the list has been gone through to the last item, it is formed again using an inquiry function. 4. TEST CASES Figure 4. Terminal Bridge extension class diagram The Terminal Bridge extension module was tested with different wireless networks. This extension was used over the underlying Wireless CORBA architecture which was operating over TCP/IP (WLAN and GPRS) and L2CAP (Bluetooth). The task of the extension was to guide the Terminal Bridge to select always the most suitable network depending on signal strength. A simplified illustration of layers involved with test-cases is illustrated in Figure 5. Figure 5. Layers of the testing environment

6 Mobile devices typically contain only one or two wireless interfaces so the test cases were limited to simulate these situations. The tests aimed to measure delays which were taken by network inquiries or access point handoffs. These test delays represent the delays which user faces when service is used in a changing wireless environment. All the test cases were performed in office environment using two desktop computers running Access Bridges and one laptop computer running Terminal Bridge. Tests did not include running any actual CORBA applications. All computers were running Linux operating system; distributions were Red Had Linux [7] and Debian [8]. Bluetooth interfaces were Nokia DTL-1 and 3COM 3CRWB6096 PCMCIA cards. WLAN interfaces were SMC 2632W PCMCIA -cards and WLAN access point was Lucents WP-II E. GPRS interface was Nokia D211 PCMCIA card. 4.1 Case 1: Bluetooth - Bluetooth In the first case a Bluetooth network of two Bluetooth Access Bridges was built for the testing environment Test Network Architecture Access points were placed to positions surrounding the mobile device where the both access points could still be found with inquiry (Figure 6). Network was built to simulate small Bluetooth network where user can move from the one access point's area to another without losing the connectivity. This kind of network can be built with using only Bluetooth access points but because of Bluetooth's short signal range, the access points must be placed in a way that there are no gaps in the network coverage area. Figure 6. Bluetooth Access Bridges in test case 1

7 Testing was performed by moving from the first access point's coverage area to another. Link error was simulated by manually breaking the link or by walking away from the signal range Use case The simulated network can be applied at small public places like cafeterias. When the mobile device enters this area inquiry takes place and searches for all Bluetooth access points defined on the access point list. Because few Bluetooth access points can easily cover the small cafeteria area, user movement should create only handoff situations when link has not broken and handoff can be made straightforward to the next available access point. Problems arise when the operating area is wider. Bluetooth coverage area has to be increased by adding more access points which leads to a situation where inquiry can't find all the surrounding access points at once. This results as continuous need of inquiry when user moves through the network area. The coverage area may also contain gaps which can lead to link failure situation. In this case handoff has to be performed to the next available access point on the access point list and if the list is at the end, inquiry has to be performed again. 4.2 Case2: Bluetooth - WLAN In the second case, testing environment was expanded to cover wider area by using both Bluetooth and WLAN Test Network Architecture Testing was performed using the same method as in the previous case i.e. by moving the mobile terminal from one network's area to another. Because WLAN has much greater coverage area than Bluetooth, this test case was slightly different than the previous: the WLAN network covered also the smaller Bluetooth network area and was almost always available when the user moved away from the Bluetooth network area (Figure 7). WLAN connections between the mobile terminal's Terminal Bridge and the WLAN access point's Access Bridge were made through an external WLAN access point. This architecture was built to simulate roaming network which consists of smaller Bluetooth networks but where is also one WLAN network covering the whole operating area. User can leave and join different Bluetooth network areas without losing the connectivity because there still is WLAN on the background. This type of network architecture allows building larger networks easier than using only Bluetooth.

8 Figure 7. Bluetooth and WLAN Access Bridges in test case Use case Comparing to the plain Bluetooth network the use of WLAN allows building networks which can be applied at bigger public places like airports. When user enters this area inquiry searches all the Bluetooth and WLAN access points. While the user is near a Bluetooth hot-spot, service can be used through Bluetooth which is less battery consuming than using WLAN. If the user starts to move away from this Bluetooth hot-spot handoff is made to WLAN. Because WLAN network covers also the Bluetooth network area, link should not get broken anytime when handoff is made from Bluetooth to WLAN. However, if the user moves away from the Bluetooth coverage area very quickly or operates at the edge of the WLAN coverage area, the link can break and handoff needs to be made to the next available access point. If the access point list is at the end, inquiry has to be performed again which interrupts the using of the service. 4.3 Bluetooth - GPRS Third case simulated a scenario where Bluetooth is used with GPRS. GPRS can cover wide areas using the underlying GSM-network and this can create new opportunities while the network coverage area is not as limited Test Network Architecture The third test case included one Bluetooth and one GPRS access point (Figure 8). The idea was to measure the time which is consumed during the handoff from Bluetooth to GPRS. Testing was performed by moving away from the Bluetooth access point's coverage area. When the signal was weak enough or broken, the connection was changed to GPRS. Because the GPRS connection is considered to be always available the testing was limited to cover only handoffs from Bluetooth to GPRS.

9 Figure 8. Bluetooth and GPRS Access Bridges in test case Use case Bluetooth with GPRS can be applied at situations where the coverage area can't be limited to some building or a specific area. When the user starts to use the service inquiry searches Bluetooth access points and verifies the presence of GPRS. Typical case would be when the user is using Bluetooth for example at a conference situation and then moves away from the Bluetooth hot-spot. The connection is switched from Bluetooth to GPRS and the use of the service can continue. If the user quickly moves away from the Bluetooth area the connection can break but it can be resumed immediately by making the handoff to GPRS. As noted before, GPRS is considered to be always available and there shouldn't be any link-broken situations when the user is operating on the GPRS connection. 5. RESULTS Several values were measured during the testing phase. All the measured delays except handoff function and network inquiry (tests 1 and 2) represent the delay which is taken when the connection is established and the user can start to use the service. All the delays were measured using simple testing application which calculated the delays using Portable Operating System Interface (POSIX) timer functions. Every test case consisted of about 150 measurements; calculated intermediate values from the cases are presented in Table1. Achieved results are described and compared between the test cases in the next chapter. Table1 Test results Test: BT->BT BT<->WLAN BT->GPRS 1 N et w o r k in q uir y Handoff-function Handoff total (normal situation) Handoff total (list is at the end,inquiry needed) Na 5 Handoff total (link broken) Handoff total (link broken,list is at the end, inquiry needed) Na

10 5.1 Network Inquiry Overview Network inquiry (test 1) is a process where available Bluetooth and WLAN devices are searched and the GPRS gateway is located. Bluetooth inquiry searches for Bluetooth devices for a defined period of time which was set to 10 seconds. WLAN inquiry searches access points for through all the 13 WLAN channels using passive scanning which normally takes about 10 seconds. GPRS discovery consists of searching the existence of the GPRS gateway using ICMP echo messages. This takes a few seconds depending of quality of the GPRS connection. In these tests, GPRS is considered to be always on and connection to Internet Service Provider (ISP) is established Test results Inquiry delays comprise the individual inquiry delays taken by each networking technology. Bluetooth inquiry (test1, case BT<->BT) took about 10 seconds comparing to 19 seconds of Bluetooth&WLAN case (test 1, case BT<->WLAN). This difference is explained because the Bluetooth&WLAN inquiry included both Bluetooth and WLAN inquiries. In the Bluetooth&GPRS case (test 1, case BT->GPRS) Bluetooth inquiry included also discovery of the GPRS-gateway which took together about 12 seconds. If Bluetooth inquiry can be presumed to take about 10 seconds, this makes the GPRS gateway discovery delay about 1-2 seconds. 5.2 Handoff function Overview Handoff function delay (test 2) represents the time which is taken when the Terminal Bridge's handoff function has been called and returned. This delay varies greatly between Bluetooth and WLAN handoffs because establishing Bluetooth connection is always more time consuming and takes about 2-3 seconds compared to WLAN where connection is established in a less than a second. While the Bluetooth case included only handoffs from Bluetooth to Bluetooth, the Bluetooth&WLAN case included both: handoff from Bluetooth to WLAN and handoff from WLAN to Bluetooth. Mean delay was then calculated from both these test values. On the Bluetooth&GPRS case handoffs were performed only from Bluetooth to GPRS because GPRS was presumed to be always on Test results The test results show that there was no big difference between the cases Bluetooth and Bluetooth&WLAN. The case Bluetooth (test 2, case BT<->BT) handoff function delay was 2,6 seconds and the case Bluetooth&WLAN's (test 2, case BT<->WLAN) 2,0 seconds. This can be explained because handoff to WLAN is very quick and this lowers the calculated mean delay. Handoff to GPRS (test 2, case BT->GPRS) is understandably the fastest operation because GPRS connection is always on. It took fastest on average 1,0 seconds.

11 5.3 Handoff total time Overview Handoff total time (tests 3, 4, 5 and 6) represent the delay during the whole handoff process. While the handoff function delay (test 2) only represent the delay between calling and returning of the handoff function, the handoff total time measures the delay which is consumed between changing the old access point to a new one. These handoff total time tests are divided into four different situations which can happen when using the Wireless CORBA Terminal Bridge extension module. The situations are: Normal situation (test 3) - the access point list still contains items and link is not broken. Handoff can be done normally to the next access point on the access point list when the link gets weak. This delay includes only the delay of changing the access point to next access point on the list. List is at the end and inquiry is needed (test 4) - the currently used access point is the last item on the access point list and the link is not broken. Inquiry has to be performed before the handoff can be done. Because inquiry creates a new access point list handoff is then performed to the first item on the list. This delay includes the delay of inquiry and delay of changing the access point to the next access point on the access point list. Link broken (test 5) - the access point list still contains items but the link has broken. Handoff must be done to the next access point on the access point list immediately. This delay includes the delay of the broken link detection and the delay of changing the access point to a next access point on the access point list. Link broken, list is at the end, inquiry needed (test 6) - the currently used access point is the last item on the access point list and the link has broken so inquiry has to be performed immediately. Because inquiry creates a new access point list, handoff is then performed to the first item on the access point list. This delay includes the delay of the broken link detection, the delay of inquiry and the delay of changing the access point to the next access point on the access point list Test results Test results for the normal situation (test 3) show quite similar results which can be concluded from the previous handoff function test (test 2). The Bluetooth case's (test 3, case BT<->BT) delay of 3,4 seconds is calculated only from the handoff delays which are made from Bluetooth to Bluetooth but in the Bluetooth&WLAN case both handoffs, from Bluetooth to WLAN and handoff to from WLAN to Bluetooth are included. This lowers the calculated mean delay to 2,7 seconds (test 3, case BT<->WLAN) because handoff to WLAN is much faster to perform. The Bluetooth&GPRS case's handoff from Bluetooth to GPRS was the fastest and it took about 1,9 seconds (test 3, case BT->GPRS). When the list is at the end and inquiry is needed (test 4) results are straight comparable to the test 3 results but include also the inquiry delays. The Bluetooth case (test 4, case BT<- >BT) delay was 13,0 seconds and Bluetooth&WLAN case's (test 4, case BT<->WLAN) delay was 21,3 seconds. This test was not performed on the Bluetooth&GPRS case

12 because GPRS is considered to be always on and thus there is always at least one GPRS connection available on the access point list. If the link breaks and the list is not at the end (test 5) results are slightly different: the Bluetooth case's (test 5, case BT<->BT) delay was 3,3 seconds while Bluetooth&WLAN case's (test 5, case BT<->WLAN) delay was 0,2 seconds. This major difference between the delays can be explained by the following: due to the access point list's priorities, handoffs are always done to the next lower priority access point. On this particular test the Bluetooth&WLAN case handoffs were always made from Bluetooth to WLAN while the Bluetooth case handoffs were always made from Bluetooth to Bluetooth. This caused the difference between delays. On the Bluetooth&GPRS case the delay was 1,7 seconds (test 5, case BT->GPRS) and this delay is the same as handoff on the normal situation. Again, these similar delays can be explained because GPRS is considered to be always on. The last situation happens when the link breaks and the access point list is at the end (test 6). The results show that the handoff delays do not vary essentially compared to the situation when the access point list is at the end and handoff is done normally (test 4). The Bluetooth case (test 6, case BT<->BT) took 14,8 seconds and the Bluetooth&WLAN case took 21,5 seconds (test 6, case BT<->WLAN). This test was not performed on the Bluetooth&GPRS case because the situation when the access point list is at the end and the link breaks can never happen while GPRS is presumed to be always operative. 6. CONCLUSIONS As test results show, inquiry always takes quite a long time to process and it should be avoided as long as possible. Creation of Bluetooth connection always requires a few seconds, while the connection to WLAN is performed in less than a second. This delay can be a problem if the network is based only on Bluetooth access points and the user moves simultaneously from one place to another. When GPRS is used handoff is always performed very quickly because GPRS is already on when the handoff function is called and the connection can be established without any additional delays. The Terminal Bridge extension always tries to change the access point before the link is broken but there can still be a situation where the user moves away from signal range very quickly. However, the test results show that the recovery time in this link-broken situation is on the same level as the delay occurred from the normal handoff. When thinking network usability, plain Bluetooth network is not the best possible choice if the user moves a lot between network areas and wants to stay connected while moving. If this is the case, network should be designed very precisely because one gap in the network coverage area breaks the link. Also, a constant need of running inquiry kills the usability very effectively. Better solution would be to use WLAN in the background and then decide what kind of Bluetooth network can be built. Network design also comes easier when WLAN can cover wider area and possible gaps on Bluetooth network. GPRS creates

13 completely different possibilities to use services on a wider area because network coverage is no more as restricting factor as on WLAN or Bluetooth technologies. The current version of the Wireless CORBA Terminal Bridge extension can't tell anything about the presence or link quality of other found access points. This means that handoff has to be performed blindly to the next access point on the access point list. If this information about access points could be acquired somehow, unnecessary handoffs would be avoided and thus waiting delays for users would be decreased. When considering future development, one solution could be using a background Pinger process which travels through the access point list and checks the presence of the access points. Even though this system could not determine the link qualities it would provide more reliable handoffs by verifying the presence of the access point before the handoff is initiated. REFERENCES [1] Object Management Group [www-pages]. Available at [Referred ] [2] Wireless CORBA [www-pages]. Available [Referred ] [3] Bluetooth Special Interest Group. Bluetooth Specification Version 1.1 Core. [e-document]. Available at [Referred ] [4] IEEE standard. Specification Documentation [e-document]. Available at [Referred ] [5] Mobile IP. Request for Comments: 2002 [e-document]. Available at [Referred ] [6] Power Consumption Estimates for Bluetooth [e-document]. Available at [Referred ] [7] Red Hat Linux. Linux distribution [www-pages]. Available at [Referred ] [8] Debian. Linux distribution [www-pages]. Available at [Referred ]