A Development Environment for OSA-Based Applications over the Interworked WLAN and Cellular Networks

Transcription

1 Wireless Personal Communications (2007) 40: DOI: /s y C Springer 2006 A Development Environment for OSA-Based Applications over the Interworked WLAN and Cellular Networks CHUNG-MING HUANG 1, TZ-HENG HSU 2 and CHIH-WEN CHAO 1 1 Department of Computer Science and Information Engineering, National Cheng Kung University, Tainan, Taiwan, R.O.C. 2 Department of Computer Science and Information Engineering, Southern Taiwan University of Technology, Tainan, Taiwan, R.O.C. hsuth@mail.stut.edu.tw Abstract. In this paper, we propose an OSA-based development environment for interworking WLAN and 3G cellular networks. The main goal of our work is to establish and create an environment that can serve as a demonstration of a working network for OSA-based application developers while featuring mobile services over the interworked LAN and 3G cellular networks. The proposed simulating environment has (i) a location update scheme that is used to obtain mobile users locations and status information over the interworked WLAN and cellular networks, (ii) an instant message gateway (IMG) simulator that is developed to send and receive generic messages over the interworked WLAN and cellular networks, and (iii) a mapping of Parlay APIs onto SIP signaling messages for multiparty call applications over the interworked WLAN and cellular networks. An illustrated OSA-based application that utilizes the corresponding system functions and modules is developed and verified using the proposed simulating environment. Keywords: Open Service architecture (OSA), instant message service, Parlay APIs, interworking WLAN and 3G cellular network, location update 1. Introduction 3G cellular networks are expected to be capable of supporting a wide range of services by adopting standard specifications that are proposed by IETF, international, or industry organizations. With the coming presence of the 3G cellular network and the increased popularity of multimedia services, the need for open services has become more and more urgent. As a result, the 3rd Generation Partnership Project (3GPP) has defined the Open Service Architecture (OSA) specification for building various kinds of services on the top of 3G cellular networks. The specified OSA/Parlay APIs have been designed to simplify and speed up service creation and deployment for 3G cellular networks while at the same time preserving the network s integrity. Currently, telecom operators provide various telecommunication services. With the rapid technical development and providing abundant services in data communication, including voice service, telecom operators themselves can no longer provide sufficient service contents to meet subscribers requirements for various services. With the success of wireless networks, telecom operators are highly intending to integrate existing WLAN data services, e.g., voice and multimedia services, to their telecom networks [1]. The main goal of interworking WLAN and cellular networks is to provide a way for telecom operators to integrate both telecom services and WLAN data services into one network architecture.

2 246 C.-M. Huang et al. 3G cellular networks will be toward to IP-based networks and will, hopefully, to be integrated with WLAN data networks [2, 3]. In such a heterogeneous networking environment, the integration issues of control and transmission protocols will be a critical problem [4 6]. A typical interoperability issue is location services. For example, a user may want to query location information of his friends or family members over the interworked WLAN and 3G cellular networks. In order to design and evaluate possible services over interworked WLAN and 3G cellular networks, a new simulating environment should be provided for helping service providers to develop OSA/Parlay-based applications over the interworked WLAN and 3G cellular networks. In this paper, a new simulating environment which can allow developers to design, test and evaluate applications over the interworked WLAN and cellular networks is proposed. The aim of our work is to explore the service platform and its applications development in interworked WLAN and 3G cellular networks. Using OSA/Parlay APIs, operators and 3rd party service providers can conveniently create their services. However, telecommunication and data communication are different stories. How to develop applications that can use OSA/Parlay Service Capability Features (SCFs) in an interworked WLAN and 3G cellular networks environment becomes a key issue in such a heterogeneous networking environment. Although various network simulators are in place currently, simulation of a service platform over the interworked WLAN and cellular networks remains to be a challenge. In this paper, we identify fundamental issues for the simulating of OSA-based applications over the interworked WLAN and cellular networks, and propose new schemes that address them. First, we exploit a location update scheme that is used to obtain mobile users locations and status information over the interworked WLAN and cellular networks. Second, an instant message gateway (IMG) simulator is developed to send and receive generic messages over the interworked WLAN and cellular networks. Third, a mapping of OSA/Parlay APIs onto SIP signaling messages for multiparty call applications over the interworked WLAN and cellular networks is implemented. Based on the proposed schemes, OSA-based application developers can test and validate their applications over the interworked WLAN and cellular network using the proposed simulating environment. The proposed simulating environment allows developers to be able to simulate network actions, e.g., location update, instant message delivery, and SIP signaling messages, of the interworked WLAN and cellular networks. Through the procedures of developing applications that use OSA/Parlay services, e.g., location service, instant message service, and presence service, we can find the integration problems of developing telecom service and data communication service in the interworked WLAN and cellular networks. As a result, our experience can provide telecom application developers and service providers some guidance to create their services in future interworked WLAN and 3G cellular networks more effectively. The remaining part of this paper is organized as follows: Section 2 introduces related works for interworking WLAN and cellular networks. Section 3 describes the proposed simulating architecture for interworking WLAN and cellular networks. Sesion 4 introduced a new location update scheme to obtain mobile users locations and status information over the interworked WLAN and cellular networks. Sesion 5 depicts an instant message gateway (IMG) simulator that can send and receive generic messages over the interworked WLAN and cellular networks. Sesion 6 presents a mapping of Parlay APIs onto SIP signaling messages and a multiparty call application over the interworked WLAN and cellular networks. Section 7 gives a simple OSA-based application that is developed using the proposed simulating environment. Section 8 has the conclusion remarks.

3 A Development Environment for OSA-Based Applications over the Interworked WLAN Related Works Developing OSA-based applications over the interworked WLAN and cellular networks is not trivial because of the characteristics of the WLAN and cellular networks. In this section, we give a brief survey of the Open Service Architecture (OSA) and the approaches for interworking WLAN and cellular networks OPEN SERVICE ARCHITECTURE (OSA) Today s telecommunications are encountering new challenges because the provided services nowadays cannot satisfy customers needs. The solution to the vision of open programmable networks for telecommunications is to develop the OSA/Parlay interface. The main advantage of using the OSA/Parlay interfaces is that it provides a simplified network model, i.e. the service providers can develop new services even though they don t know how the underlying network works. The introduction of the OSA/Parlay interface will result in rapid service development. The OSA/Parlay architecture comprises a network part and an application part [7]. The network part, which is often referred to as an OSA/Parlay gateway, is utilized to access network s functionality. The application part, which can be hosted outside the network operator s domain, is the place running telecommunication services. 3G applications can communicate with the OSA/Parlay gateway with OSA/Parlay APIs (Application Programming Interfaces). The purpose of OSA/Parlay APIs is to acquire different areas of functionalities of a telecommunication network and make them available to programmers with standardized interfaces [8, 9]. Using the APIs, an application can request the OSA/Parlay gateway to notify it when some network-related events occur. The service logic can also instruct the network to perform specific tasks. A service provider, which is different from a network operator, can also host application services. OSA/Parlay is now a part of ETSI and 3GPP standards. The OSA/Parlay APIs have been divided into several Service Capability Features (SCFs) according to their functionalities. The SCFs include Mobility SCF, Call Control SCF, User Interaction SCF, and several others. An OSA/Parlay gateway may implement the network part of one or more SCFs I NTERWORKING A RCHITECTURE FOR WLAN AND 3G CELLULAR NETWORK A 3G cellular data network, such as Universal Mobile Telecommunication System (UMTS) or General Packet Radio Service (GPRS), provides wide area coverage but only support low data rates. However, the low data rates are not sufficient for many data intensive applications. A Wireless Local Area Network (WLAN) supports higher speed data, but covers only small areas. A WLAN network will provide wireless data coverage by means of the hot spot deployment. A cellular-wlan interworking architecture can combine their benefits [1]. A cellular-wlan interworking architecture integrating wide-area cellular data service and high bandwidth WLAN networking service in hotspot locations is gaining significant popularity. In the interworking architecture, a mobile terminal has the ability to access high bandwidth services at the WLAN coverage, while access cellular network services at other places. Mobile operators must provide a seamless user experience between WLAN and cellular networks. Such an interworking architecture combines the benefits of WLAN

4 248 C.-M. Huang et al. and cellular technologies. Two general interworking solutions specified by the European Telecommunications Standardization Institute (ETSI) are (1) the tight coupling and (2) the loose coupling approach. Tight Coupling is an approach integrating the WLAN into a 3G network. A WLAN network can connect to the 3G core network and act like radio access network. The data over a WLAN will pass through the 3G core network before arriving the external Public Data Networks (PDNs). The benefit of this approach is the reuse of the 3G infrastructure, such as bill systems, subscriber databases, and other core network resources. However, this approach will be highly specific to the 3G technology used and difficult to analyse, define and standardize. A WLAN is deployed as an access network complementary to the 3G network in the loose coupling approach. The WLAN makes use of the subscriber s database in the 3G core network but has no data interface to the 3G core network. It means that the data over WLAN will reach the external PDNs directly instead of passing through the 3G core network using the loose coupling solution. The benefit of this approach is avoiding any impact on the Serving GPRS Support Node (SGSN) and Gateway GPRS Support Node (GGSN) nodes. Moreover, the loose coupling approach allows many different network operators to be able to operate in the same market. 3. System Architecture Figure 1 depicts the abstract system architecture of the service platform simulating environment. In the proposed simulating environment, developers can use OSA/Parlay APIs to develop and evaluate OSA-based applications. The OSA-based applications invoke the services provided by the OSA/Parlay gateway. The interworking part of WLAN and cellular networks is simulated in the proposed environment. Some extensions should be made to achieve interworking WLAN and cellular networks. Extensions can be conveniently integrated by making Interworked WLAN and 3G Cellular Network Simulating Environment OSA/ PARLAY Gateway Simulator HSS HLR VLR WAG AP UE Status Server Instant Message Gateway SIP Server/ Proxy Protocol Protocol Parlay Framework SCF to FW OSA/PARLAY API Mobility SCF Other SCFs SCF to Application OSA/PARLAY API OSA-based Applications Figure 1. The abstract system architecture of the service platform simulating environment.

5 A Development Environment for OSA-Based Applications over the Interworked WLAN 249 use of highly reusable components in the simulating environment. The proposed simulating environment consists of the following major components: (1) User Equipment (UE), (2) Wireless Access Point (AP), (3) Base Station (BS), (4) Wireless Access Gateway (WAG), (5) Mobile-Switching Center (MSC), (6) Home Subscriber Server (HSS)/Home Location Register (HLR), (7) Visited Location Register (VLR), (8) status server, (9) Instant Message Gateway (IMG), and (10) SIP server/proxy. A UE can be a standard handset or mobile device that is equipped with a WLAN card and a GPRS/UMTS card. WLAN and GPRS/UMTS dual-mode mobile devices are now available. By communicating with a WLAN Access Point (AP), the UE can access Internet services through a gateway named WLAN Access Gateway (WAG). In the proposed simulating environment, we assume that the UE can monitor the broadcast-controlled channel and initiate a location update when the UE moves into another base station (BS) or access point (AP). A WLAN Access Gateway (WAG) in the WLAN plays the role as the MSC in the cellular network. A UE sends an update request as well as either the International Mobile Subscriber Identity (IMSI) or the Temporary Mobile Subscriber Identity (TMSI) to the new VLR via the new MSC in the cellular network. The new VLR then allocates and sends a Mobile Station Roaming Number (MSRN) to the HLR that keeps the most current location. The location and status servers provide services to the underlying telecommunication networks. The simulating environment of interworking WLAN and cellular networks can provide users and BTS locations while an OSA/Parley application is running. In the proposed simulating environment, an instant message gateway (IMG) serves as a key to send messages between the WLAN network and the cellular network. The IMG has the ability to send messages to an instant message server (ICQ, MSN server) and provides the interface to communicate between application servers and instant message servers. To be compatible with SIP-based services, a mapping of Parlay APIs onto SIP signaling messages for supporting OSA-based applications over the interworked WLAN and cellular networks is provided in the proposed simulating environment. The OSA-based application services provided by the proposed simulating environment can be classified into four OSA/Parlay service capability features (SCFs): (i) mobility SCF, (ii) terminal SCF, (iii) presence and availability management SCF, and (iv) generic messaging SCF. For each SCF, various applications can be developed using the proposed simulating environment for evaluating and testing OSA/Parlay-based applications over the interworked WLAN and cellular networks. These supported OSA/Parlay SCFs are as follows. Mobility SCF The mobility SCF allows applications to obtain the geographical location and the status of fixed, mobile and IP based telephony users [10, 11, 12, 13]. The User Location service (UL) provides a general geographic location service. UL is supplemented by User Location Camel service (ULC) to provide information about network-related information. Emergency calls for location service is supplemented by User Location Emergency service (ULE). Terminal SCF The Terminal Capabilities SCF enables the application to retrieve the terminal capabilities of the specified terminal. The OSA-based application can request notifications when the capability of the user s terminal is changed. The getterminalcapabilities() method is used by an application to get the capability of a user s terminal. The returned result specifies the latest available capability of the user s terminal. The information is returned as CC/PP headers as that are specified in W3C and adopted in the WAP UAProf specification. It

6 250 C.-M. Huang et al. contains terminal attributes and values in the RDF format. Presence and Availability Management SCF Presence and Availability Management SCF describes different contexts of an entity s existence. The concept of presence has been used in many application areas, such as Instant Messaging [14, 15]. Starting from a simple notion of online/offline status, it can be expanded to include other context information around the status such as disposition (out to lunch, away from the computer, etc.) and activity status (on the phone, idle, etc.). For example, an instant messaging client on a desktop computer can register its status when a user logs in; a mobile phone may do an explicit registration on a WAP server for instant messaging; the phone s presence for voice calls, on the other hand, may be inferred implicitly by querying the cellular network for the mobile device. The presence of an identity, on the other hand, may be computed using presence information from one or more devices owned by the identity. Generic Messaging SCF Generic Messaging Service interface (GMS) is used by applications to send, store and receive messages. GMS has voice mail and electronic mail as the messaging mechanism. The messaging service interface can be used by both. A messaging system is assumed to have the following entities: Mailboxes, Folders, and Messages. A mailbox is the application s main entry point to the messaging system. A mailbox has at least inbox and outbox folders. These folders may have sub-folders. Messages are stored in folders. The integration issues of user mobility in the interworked WLAN and 3G cellular networks give challenges for the proposed simulating environment. One critical issue is how to obtain mobile users locations and status information over the interworked WLAN and cellular networks environment [16]. A user may want to query location information of his friends or family members over the interworked WLAN and 3G cellular networks. In order to provide location service, a new simulating environment should be designed for helping developer to query locations of mobile users over the interworked WLAN and cellular networks. In Section 4, a new location update scheme is proposed to obtain mobile users locations and status information over the interworked WLAN and cellular networks. Another critical issue is how to send and receive generic messages over the interworked WLAN and cellular networks. SMS message and instant message services are incompatible in the real environment. In Session 5, an instant message gateway (IMG) simulator is developed to solve this problem. The IMG has the ability to translate instant messages for mobile users over the interworked WLAN and cellular networks and provides the interfaces to communicate between application servers and instant message servers. Additionally, SIP (Session Initiation Protocol) is a signaling protocol that are wildly used for multimedia control in the IP networks. For OSA-based applications developers, it is hard to send SIP signaling messages to multimedia applications in WLAN using Parlay APIs. Therefore, how to map Parlay APIs onto SIP signaling control messages over the interworked WLAN and cellular networks becomes an important issue. In Session 6, a mapping of Parlay APIs onto SIP signaling messages is implemented to solve the problem. An OSA/Parlay application is not part of the proposed simulating environment. However, the developer can use the proposed simulating environment to develop OSA/Parlay applications. In order to help the developers to develop OSA/Parlay applications, we use Ericsson Mobile Positioning Center Emulator (MPC Emulator) as the auxiliary tool to cooperate with our proposed simulating environment [17, 18]. For validating the proposed simulating envi-

7 A Development Environment for OSA-Based Applications over the Interworked WLAN 251 ronment, a simple application is developed and introduced in Section Location and Status Tracking over the Interworked WLAN and Cellular Networks According to the OSA/Parlay specification, location and status services have been defined for cellular networks [7]. Mobile Application Part (MAP) is a protocol that allows the implementation of GSM signaling infrastructure. The GSM network entities, such as MSC, VLR, and HLR, can communicate with each other using MAP. MAP can be used to manage presence and location information for a subscriber. Customised Applications for Mobile network Enhanced Logic (CAMEL) is a message protocol that extends traditional Intelligent Networks (IN) services into GSM mobile networks. CAMEL enables network operators to provide operator-specific services even when a subscriber is roaming outside the Home Public Land Mobile Network (HPLMN). CAMEL Application Part (CAP) is a realtime protocol used to support the information flows between CAMEL functional elements. Such location and status services over the interworked WLAN and cellular networks environment are not discussed. How to obtain mobile users locations and status information over the interworked WLAN and cellular networks environment is still an open question. In the proposed simulating environment, we try to solve this problem by proposing a new location update scheme over the interworked WLAN and cellular networks environment. In the proposed scheme, the mobile users locations and status information can be obtained. Consequently, the OSA-based application developers can request location and status services, which are either in WLAN or in the cellular network. In the proposed scheme, the basic location unit is defined as the coverage of a Location Area (LA) or an Access Point (AP). In order to get the user location information in the interworked WLAN and cellular networks, the WLAN Access Gateway (WAG) in a WLAN acts as the MSC in a cellular network. The MSC in a cellular network uses the Integrated Services Digital Network (ISDN) number as the unique identifier for identifying the location where the UE resides. The WLAN Access Gateway (WAG) is given a set of special sequence numbers, which are used to distinguish them with the ISDN numbers of MSCs in the cellular network. For example, we take numbers from to as the MSC identities in the cellular network and the numbers greater than as the WAG s ISDN numbers in the WLAN network. Hence, if the number that one gets is , one can identify that the user is in a WLAN network. The registration message flow of location update over the interworked WLAN and cellular networks within the simulating environment can be explained in three different situations that are explained as follows. Case 1 Inter-LA movement of an MS moving within the cellular network Figure 2 depicts the corresponding registration message flow of GSM location update for Case MS sends a location update request message to the MSC through the BTS. This message includes (i) address of the previously visited LA, (ii) address of the previously visited MSC, and (iii) address of the previously visited VLR. 2. MSC forwards the location update request to the VLR using a Transaction Capabilities Application Part (TCAP) message, MAP UPDATE LOCATION AREA. The TCAP message provides the capability to exchange information between applications using noncircuitrelated signaling. This message includes (i) Address of the MSC, (ii) TMSI of the MS,

8 252 C.-M. Huang et al. (iii) previous Location Area Identification (LAI), (iv) Target LAI, and (v) other related information lists used in the GSM standard. 3. VLR notices that the previous LA and the target LA are connected to the same MSC. It updates the LAI field of the VLR record, and then responses to the MSC with an acknowledgment. 4. MSC sends an acknowledgment to the MS. Case 2 Inter-MSC movement of an MS moving from cellular network to WLAN network Figure 3 depicts the corresponding registration message flow of GSM location update for Case MS sends a location update request message to WAG through AP. 2. WAG forwards the location update request to VLR using the TCAP message MAP UPDATE LOCATION AREA. 3. VLR notices that the previous MSC and the target WAG are connected to the same VLR. The VLR updates LAI and MSC fields of the VLR record, and obtains the HLR address of the MS from MS s IMSI. The VLR sends the MAP UPDATE LOCATION message to HLR. The message includes (i) IMSI of the MS, (ii) address of the target HLR 3 VLR1 VLR2 MSC WAG LA1 MS LA2 Figure 2. The registration message flow of GSM location update for Case 1. 4 HLR VLR1 3 5 VLR2 MSC 2 WAG 1 6 LA1 MS LA2 Figure 3. The registration message flow of GSM location update for Case 2.

9 A Development Environment for OSA-Based Applications over the Interworked WLAN 253 WAG, (iii) address of the target VLR, and (iv) other related information listed in the GSM standard. 4. HLR can identify the MS s record using the received IMSI. The MSC number field of the record is updated. An acknowledgment is sent to the VLR. 5. VLR sends an acknowledgment to WAG. 6. WAG sends an acknowledgment to MS. Case 3 Inter-VLR movement of an MS moving from cellular network to WLAN network Figure 4 depicts the corresponding registration message flow of GSM location update for Case The location update request is sent from MS to VLR. 2. Since the MS moves from VLR1 to VLR2, the target VLR does not have a VLR record of the MS and the IMSI of the MS is not known. The target VLR obtains the address of the previous VLR from the MAP UPDATE LOCATION AREA message. It sends the message MAP SEND IDENTIFICATION to the previous VLR. Details concerning this message can be found in the GSM standard. Basically, the message provides TMSI of the MS that is used by the previous VLR to retrieve the corresponding IMSI in the database. 3. The IMSI is then sent back to the target VLR as an acknowledgment. 4. VLR2 creates a VLR record for the MS and sends a registration message to update the location information in HLR. 5. HLR updates the record of the MS. An acknowledgment is sent back to VLR2. 6. VLR2 generates a new TMSI and sends it to the MS. 7. HLR informs the previous VLR to delete the out-of-date record of the MS. 8. An acknowledgment is sent from VLR1 to HLR. Once the application server receives a request from a user, it can make a request to the OSA/Parlay gateway via OSA/Parlay APIs. The OSA/Parlay gateway can fetch the information from the underlying interworked WLAN and cellular networks environment. In the proposed 7 HLR 5 VLR VLR2 MSC WAG LA1 MS LA2 Figure 4. The registration message flow of GSM location update for Case 3.

10 254 C.-M. Huang et al. simulating environment, the OSA/Parlay gateway can communicate with the status server and the HLR. The status server is responsible for managing the user status information which indicates that a user is reachable, non-reachable, or busy. HLR and VLR are responsible for managing the user location information. 5. Instant Message Between WLAN and Cellular Networks Sending message is the simplest way to communicate with others. For example, users can use Short Message Service (SMS) in the cellular network and can use instant messaging, e.g., MSN, ICQ, in the WLAN network. However, the above two message services are incompatible in the real environment. In the proposed simulating environment, we try to solve the problem by developing an instant message gateway (IMG) simulator. Thus, we expect a message can be sent and received over the interworked WLAN and cellular networks. A mobile station in the cellular network can send a message to MTs in the WLAN network through the IMG in the form of SMS, and then the MT in the WLAN network can receive the message in the form of an instant message which is translated by the IMG. In the proposed simulating environment, an instant message gateway (IMG) serves as a key to send messages between the WLAN network and the cellular network. The IMG has the ability to send messages to an instant message server (ICQ, MSN server) and provides the interfaces to communicate between application servers and instant message servers. Figure 5 shows how the IMG works. The Instant Message Server (IMS) is a server set up on Internet. It is responsible for managing presence information and forwarding messages between its IM clients. It keeps the user presence information in its presence table. The Instant Message Gateway (IMG) acts as an application on the application server. An MT can request its service by sending an SMS to the specific service number. For sending an instant message, the IMG also acts as an IM client. The following steps describe the procedure that MT 0955 sends a message to IM client abc and then IM client abc replies. 1. MT 0955 sends a message to IMG using an SMS. 2. The IMG creates an entry in its communication table. The IMG forwards this message to the IMS. Figure 5. The abstract work flow of the instant message gateway.

11 A Development Environment for OSA-Based Applications over the Interworked WLAN The IMS checks the presence information of the user abc in its presence table and then forwards this message to IM client abc. 4. IM client abc sends a reply message to the IMS with an instant message. 5. The IMS checks the presence information of the IMG robot and then forwards this message to the IMG. 6. The IMG finds out the subscriber communicating with IM client abc. The IMG forwards this message to that subscriber with an SMS. 6. Mapping Parlay APIs onto SIP Signaling Messages SIP (Session Initiation Protocol) is a signaling protocol for session control of multimedia communications in an IP network. SIP provides functions for establishing, modifying, and terminating multimedia sessions. SIP is wildly used for multimedia control in the IP networks. This section introduces a mapping of Parlay APIs onto SIP signaling messages and an illustrated multiparty call application using the mapping over the interworked WLAN and cellular networks. The multiparty call application is an application that provides multiparty call service for SIP end users. A user can request the application to initiate a call from a web page by entering Application OSA/Parlay Gateway SIP Network IpAppLogic IpMultiPartyCallControlManager IpMultyParyCall IpCallLeg A IpCallLeg B Party A Party B createcall() new() createcallleg() eventreportreq() new() routereq() eventreportres() INVITE 200 OK createcallleg() eventreportreq() new() routereq() eventreportres() attachmediareq() attachmediareq() eventreportres() detachmediareq() ACK BYE 200 OK INVITE 200 OK ACK media stream Figure 6. The message flow diagram of the multiparty call application.

12 256 C.-M. Huang et al. the SIP address of the user who wants to join this multiparty call. Once all the callees answer the call, the multiparty call session can be started. During the call session, each callee can hang up to leave the call. The call will be terminated when there are less than two callees attached to the call. Parlay APIs offer several kinds of call control interfaces. The Generic Call Control service provides the basic call control functions between two parties. The Multiparty Call Control service enhances the Generic Call Control service with capabilities of call leg management so that more than two parties can be attached to one call. We use the Multiparty Call Control interfaces to develop the application because the Generic Call Control is limited to two party calls. As for the Multimedia Call Control service and the Conference Call Control service, their functionalities exceed what we need. Taking the Multiparty Call Control service for example. Parlay defines the following interfaces for it: (1) IpMultiPartyCallControlManager: it is the multiparty call control manager that provides management functions. IpMultiPartyCallControlManager is utilized to control all active calls in the call processing system. (2) IpMultiPartyCall: it is a call representing a relation between several parties. An IpMultiPartyCall object can attach more than two parties. (3) IpCallLeg: it is the call leg interface representing the logical call leg associating a call with an address, in which a call leg is a logical connection between two addressable call endpoints. The Mapping is implemented at the gateway side according to previous researches [19 21]. The gateway implements the Parlay interfaces and maps them onto the corresponding SIP actions. On the other hand, it receives SIP messages and maps them onto the Parlay event report functions. In order to communicate with the underlying SIP network, the gateway also plays the role of a SIP user agent. Figure 6 depicts the message flow diagram of the multiparty call application. Figure 6 also depicts the mapping between Parlay APIs and SIP signaling messages. For simplification, Figure 7. The abstract system architecture of the FriendFinder application.

13 A Development Environment for OSA-Based Applications over the Interworked WLAN 257 we assume that it is a two party call and the application side interfaces of Call Control are condensed into one IppAppLogic interface in Figure 6. When the application receives a multiparty call request from a user, it creates a multiparty call object in the gateway. The application then creates a call leg and routes it for each callee. The routereq() method is mapped onto a SIP INVITE message to invite the callee. Once the callee accepts the invitation, it will send back the SIP 200 OK message. This SIP 200 OK message is then mapped onto an eventreportres() method with an ANSWER event to report the event. After the successful routing of all the created legs, the remaining thing that the application has to do is to attach the legs to a call. The attachmedia() method is mapped onto a SIP ACK message which is sent by the gateway to the callee. Meanwhile, the callees that attached to the multiparty call can start to communicate with each other. If one callee among the multiparty call wishes to leave this call, it can send a SIP BYE message to the gateway. After that, the gateway will inform the application by an eventreportres() method with a TERMINATING RELEASE event. Finally, the application invokes detachmediareq() to detach the call leg from its call. 7. Case Study To illustrate the usage of the proposed OSA-based service platform simulating environment, an application called FriendFinder is developed using the OSA/Parlay APIs. FriendFinder is an application that offers specific location information regarding the location of friends or family members. FriendFinder can deliver user s location and status information via an SMS Web Server Application OSA/Parlay Gateway CellularNetwork Web Interface IpAppLogic IpUserLocation IpUserStatus Status Serve HLR VLR locationrequest statusreportreq MAP AnyTimeInterrogationReq MAP AnyTimeInterrogationRes statusreportres extendedlocationreportreq MAP AnyTimeInterrogationReq querylaireq querylaires MAP AnyTimeInterrogationRes extendedlocationreportres locationresponse Figure 8. The message flow for querying locations via the web interface.

14 258 C.-M. Huang et al. or a WAP gateway. Moreover, map information can also be sent to the requester using the Multimedia Messaging Service (MMS). Once the location of a friend or a family member is located, users can sent SMS or instant messages to chat with each other via the instant message gateway (IMG). Figure 7 depicts the abstract system architecture of the FriendFinder application over the interworked WLAN and cellular networks. FriendFinder provides two operation scenarios for mobile users to query the locations of friends or family members: web browsing and SMS messages. The interfaces at the OSA/Parlay application side, including IpAppUserLocation, IpAppUserStatus, and IpAppUI, are simplified to one IpAppLogic interface. Message flows for retrieving user s location and status information via web browsing and SMS messages over the interworked WLAN and cellular networks are depicted as follows Q UERY LOCATION VIA WEB BROWSING This scenario shows how a user in a WLAN can query locations of friends or family members via web browsing. A web service is implemented to handle the request from the user and the result from the FriendFinder application. Figure 8 depicts the message flow diagram for querying location via the web interface over the interworked WLAN and cellular networks. In Figure 8, a user can use the browser to make a request of querying the location of a specific friend. The web server forwards this request to the FriendFinder application. After receiving the request, the FriendFinder application invokes the statusreportreq method on the OSA/Parlay gateway to retrieve the user status of a friend. The statusreportreq method invocation is mapped onto a Mobile Application Part (MAP) protocol dialogue. The Mobile Application Part (MAP) protocol is a signaling protocol for cellular networks [22]. After retrieving the user status, the FriendFinder application invokes the extendedlocaionreportreq method on the OSA/Parlay gateway to query the location of his friend. Since the HLR does not store the Location Area Identification (LAI) information of the Mobile Terminal, the HLR requests the corresponding VLR to get the LAI information. After the FriendFinder application receives the result, it forwards the result to the web server. Then, the web server makes a response to the requested mobile user in the form of a graphic with geographic information Q UERY LOCATION VIA SMS MESSAGES This scenario shows how a user in the cellular network can query locations of friends or family members via SMS messages. A user in the cellular network can send SMS messages to trigger the notification of the FriendFinder application. The result can be sent back to the user via SMS or MMS. Figure 9 depicts the sequence diagram for querying locations via the SMS interface over the interworked WLAN and cellular networks. In Figure 9, the FriendFinder application registers its call back interface to enable system notifications in the cellular network. The FriendFinder application registers its interest in certain SMS events. When a user sends an SMS message to a specific service number, the FriendFinder application will be notified. Meanwhile, the reporteventnotification method on the OSA/Parlay gateway will be triggered. With the data stored in the reporteventnotification method, the FriendFinder application can get the information about the request for querying location of a specific user. The FriendFinder application invokes statusreportreq and extendedlocationreportreq methods to retrieve the user status and user location of the

15 A Development Environment for OSA-Based Applications over the Interworked WLAN 259 Application OSA/Parlay Gateway Cellular Network IpAppLogic IpUIManager IpUserLocatin IpUserStatus IpUI StatusServer HLR VLR MSC MT enablenotification MAP AnyTiemModification reporteventnotification statusreportreq CAP InitialDPSMS InsertSubscriberData MO SMS Attempt MAP AnyTimeInterrogationReq statusreportres extendedlocationreportreq extendedlocationreportres creatui sendinforeq MAP AnyTimeInterrogationRes MAP AnyTimeInterrogationReq MAP AnyTimeInterrogationRes new querylaireq querylaires sendinfores MAP SendRoutingInfoForSMreq MAP SendRoutingInfoForSM conf MAP MTForwardShortMessage MAP MTForwardSMConf Send SMS Figure 9. The message flow diagram for querying location via SMS messages. user who is being queried. After receiving the result, the FriendFinder application sends the result to the mobile user who queries friend s location information via SMS messages. Using the User Interaction interface (IpUI) of the OSA/Parlay APIs, the sendinforeq method on the OSA/Parlay gateway is mapped onto the MAP SendRoutinginfoForSM message to obtain the serving MSC from HLR. Then, the MAP MTForwardShortMessage message is sent to the serving MSC for forwarding SMS messages. Finally, the mobile user receives an SMS message with his friend s status and location information. The above two scenarios illustrate how the OSA interfaces, including User Location, User status, and User Interaction, can be called to create an application. The illustrated case study shows the procedures of mapping OSA/Parlay APIs to the MAP or CAP protocol in order to communicate with the WLAN and cellular network components. Figure 10 shows a snapshot of querying location via SMS messages in the proposed environment using Ericsson Mobile Positioning Center Emulator (MPC Emulator). The MT receives an MMS message with the location query result of a specific friend. Figure 11 shows a snapshot of querying location via web browsing in the proposed environment. A user uses the web browser to make a request of querying the location of a specific friend.

16 260 C.-M. Huang et al. Figure 10. An illustrated snapshot of querying location via SMS messages. 8. Conclusion Figure 11. An illustrated snapshot of querying location via web browsing. In this paper, we have proposed an OSA-based service platform simulating environment for the interworked WLAN and 3G cellular networks. In the proposed simulating environment, an UE can access Internet services through a gateway named WLAN Access Gateway (WAG). A

17 A Development Environment for OSA-Based Applications over the Interworked WLAN 261 WLAN Access Gateway (WAG) in WLAN plays the role as the MSC in the cellular network. A UE sends an update request with the data field of International Mobile Subscriber Identity (IMSI) or Temporary Mobile Subscriber Identity (TMSI) to the new VLR via the new MSC in the cellular network. The new VLR then allocates and sends a Mobile Station Roaming Number (MSRN) to the HLR that keeps the current location information. The main goal of our work is to establish and create an environment that can serve as a demonstration of a working network for OSA-based application developers while featuring mobile services over the interworked LAN and 3G cellular networks. The proposed simulating environment has (i) a location update scheme that is used to obtain mobile users locations and status information over the interworked WLAN and cellular networks, (ii) an instant message gateway (IMG) simulator that is developed to send and receive generic messages over the interworked WLAN and cellular networks, and (iii) a mapping of Parlay APIs onto SIP signaling messages for multiparty call applications over the interworked WLAN and cellular networks. The corresponding system functions and modules are verified by developing an illustrated OSA-based application in the proposed simulating environment. Acknowledgement This research is partially supported by Computer Communication Lab oratory (CCL) under the grant No. T , Industrial Technology Research Institute (ITRI), Republic of China (Taiwan), and the National Science Council of the Republic of China (Taiwan) under the grant No. NSC E References 1. A. Salkintzis, C. Fors, and R. Pazhyannur, WLAN-GPRS Integration for Next-Generation Mobile Data Networks, IEEE Wireless Communications, Vol. 9, No. 5, pp , October J. Ala-Laurila, J. Mikkonen, and J. Rinnemaa, Wireless LAN Access Network Architecture for Mobile Operators, IEEE Communications Magazine, Vol. 39, No. 11, pp , November H. Honkasalo, K. Pehkonen, M. Niemi, and A. Leino, WCDMA and WLAN for 3G and Beyond, IEEE Wireless Communications, Vol. 9, No. 2, pp , April M. Jaseemuddin, An Architecture for Integrating UMTS and WLAN Networks, Proceedings of IEEE Symposium of Computer and Communication (ISCC2003), pp , June D. Findlay, H. Flygare, R. Hancock, T. Haslestad, E. Hepworth, D. Higgins, and S. McCann, 3G Interworking with Wireless LANs, Proceedings of the 3rd International Conference on 3G Mobile Communication Technologies, pp , May A. Salkintzis, Interworking Between WLANs and Third-Generation Cellular Data Networks, Proceedings of the Vehicular Technology Conference, pp , April M. Yates and I. Boyd, The Parlay Network API Specification, BT Technology Journal, Vol. 18, NO. 2, pp , April A. Moerdijk and L. Klostermann, Opening the Networks with Parlay/OSA: Standards and Aspects Behind the APIs, IEEE Network, Vol. 17, NO. 3, pp , May S. Beddus, C. Bruce, and S. Davis, Opening up Networks with JAIN Parlay, IEEE Communications Magazine, Vol. 38, No. 4, pp , April E.P. Group, Open Service Access (OSA); Application Programming Interface (API); Part 6: Mobility SCF; ETSIES V1.2.1, ETSI/The Parlay Group, The 3rd Generation Partnership Project (3GPP), Application Programming Interface (API) Mapping for OSA; Part 6: User Location User Status Service Mapping to MAP; 3GPP TR V6.0.0, The 3rd Generation Partnership Project (3GPP), 2004.

18 262 C.-M. Huang et al. 12. The 3rd Generation Partnership Project (3GPP), Location Management Procedures; 3G TS V3.3.0, The 3rd Generation Partnership Project (3GPP), The 3rd Generation Partnership Project (3GPP), Feasibility Study on 3GPP System to Wireless Local Area Network (WLAN) Interworking; 3GPP TR V6.2.0, The 3rd Generation Partnership Project (3GPP), C. Faure, Presence Service in 3G Networks, Proceedings of the 3rd International Conference on 3G Mobile Communication Technologies, pp , May M. Day, J. Rosenberg, and H. Sugano, RFC 2778: A Model for Presence and Instant Messaging, IETF, V. Varma, S. Ramesh, K. Wong, M. Barton, G. Hayward, and J. Friedhoffer, Mobility Management in Integrated UMTS/WLAN Networks, Proceedings of IEEE International Conference on Communications (ICC 03), pp , May M. Klos, J. Domaszewicz, and M. Roj, Implementing OSA/Parlay Mobility SCF with Ericsson Mobile Center Emulator, Krajowe Sympozjum Telekomunikacji, 2003, J.D.M. Roj, Simple Service Developed with Ericsson OSA/Parlay Simulator, Proceedings of the Mobile Open Society through Wireless Telecommunications International Conference, 2002, publications-papers.htm. 19. R.H. Glitho and A. Poulin, A High Level Service Creation Environment for Parlay in A SIP Environment, Proceedings of IEEE International Conference on Communications (ICC 2002), Vol. 4, pp , April R. Pailer, J. Stadler, and I. Miladinovic, Using PARLAY APIs over A SIP System in A Distributed Service Platform for Carrier Grade Multimedia Services, Wireless Networks, Vol. 9, No. 4, pp , July R.H. Glitho and K. Sylla, Developing Applications for Internet telephony: A Case Study on the Use of Parlay Call Control APIs in SIP Networks, IEEE Network, Vol. 18, No. 3, pp , May The 3rd Generation Partnership Project (3GPP), Mobile Application Part (MAP) Specification; 3GPP TS V6.8.0, The 3rd Generation Partnership Project (3GPP), Chung-Ming Huang received the B.S. degree in Electrical Engineering from National Taiwan University on 1984/6, and the M.S. and Ph.D. degrees in Computer and Information Science from The Ohio State University on 1987/12 and 1991/6 respectively. He is currently a professor in Department of Computer Science and Information Engineering, National Cheng Kung University, Taiwan, R.O.C. He is the director of The Promotion Center for Network Applications and Services, Innovative Communication Education Project, Ministry of Education, Taiwan, R.O.C. His research interests include broadband Internet and applications, wireless and mobile network protocols, ubiquitous computing and communications, and multimedia streaming.

19 A Development Environment for OSA-Based Applications over the Interworked WLAN 263 Tz-Heng Hsu received the B.S. degree from Department of Computer Science and Information Engineering, Feng Chia University on 1996/6, and the M.S. degree and Ph.D from Department of Computer Science and Information Engineering, National Cheng Kung University on 1998/7 and 2005/7, Taiwan, R.O.C. He is currently a assistant professor in Department of Computer Science and Information Engineering, Southern Taiwan University of Technology. His research interests are wireless and mobile network protocols, applications over interworked WLAN and cellular networks and communications, and multimedia streaming. Chih-Wen Chao received the B.S. degree from Department of Engineering Science, National Cheng Kung University on 2003/6, and the M.S. degree from Department of Computer Science and Information Engineering, National Cheng Kung University on 2005/7, Taiwan, R.O.C. His research interests are OSA-based applications and distributed multimedia systems.