USSD Communication Channel As Alternative to XML SOAP in Mobile Unified Communication Applications
Total Page:16
File Type:pdf, Size:1020Kb
Position Papers of the 2013 Federated Conference on Computer Science and Information Systems pp. 45–50 USSD communication channel as alternative to XML SOAP in mobile Unified Communication applications Dariusz Bogusz Grzegorz Siewruk Jarosław Legierski Siemens Enterprise Warsaw University of Technology Orange Labs Communications* Faculty of Electronics and ul. Obrzeżna 7, ul. Mińska 63A Information Technology 02-691 Warsaw, Poland 03-828 Warsaw, Poland ul. Nowowiejska 15/19 Email: [email protected] Email: 00-665 Warsaw, Poland dariusz.bogusz@siemens-enterpr Email:[email protected] ise.com Jan S. Kunicki University of Warmia and Mazury Faculty of Mathematics and Computer Science Słoneczna 54 Street 10-710 Olsztyn Email: [email protected] Abstract—Traditional mobile Unified Communications • communication enabled business processes (UC) clients use data channel over GSM/UMTS network for CEBP – multimedia communication built into communication with UC services broker and providers. UC the enterprise business applications via API or signaling traffic characteristics require a large number of the short data connection sessions and can cause overload of the the available plugins. mobile network. The reason is a ratio of the overhead data to • social media integration – possibility to the useful signaling information. communicate via Web 2.0 portals in the Cloud This paper presents an analysis of the mobile UC architec- via API or federation tures and a possible use of Unstructured Supplementary Ser- Architecture of a typical UC system is presented in Fig. 1. vice Data (USSD) channel for UC application in the mobile do- main. The usage of USSD channel can help to provide more ef- Proliferation of the smart mobile terminals allowed to fective applications for the mobile UC user. offer UC users a dedicated mobile application that signifi- cantly increases functionality of the office communica- I. INTRODUCTION tion systems for the business end users. Integration of the NIFIED Communications is a new trend on the en- UC applications with other systems [1], [2] allows to of- Uterprise market. The basic idea is to handle all co- fer a complete end extensible environment. In the next mmunications of a business user (voice call, video, ins- sections we discuss evolution of the architectural ap- tant messaging, teleconferencing, e-mails, voice mails, proach to the mobile UC, we also suggest a possible opti- web collaboration, mobility and customer contact center mization in this area and present a prototype implementa- etc.) over a single scalable, software-based, unifying co- tion. mmunications platform working with any IT, voice, and application environment. Some of the key features are: II.MOBILE UC APPLICATIONS EVOLUTION • one universal telephone number independent on Mobility of the end users is a very important aspect for a physical device (desk phone, soft phone, home many enterprises. This section presents evolution of the office, mobile), enterprise mobile applications architectures based on the • presence management - including personal and solutions available on the market during the last 20 years. media status, A. Hardware DECT/GSM system • mobility - including virtualization of the com- The first mobile application was announced in 1995 as munication services irrespective of a client (soft- a joint trial development project between TELIASON- phone on PC, browser based client, personal ERA AB; ERICSSON Inc. [6]. Ericsson was to deliver voice based client, mobile smartphone client), c 2013, PTI 45 46 POSITION PAPERS OF THE FEDCSIS. KRAKOW,´ 2013 5,000 dual-mode GSM/DECT handsets, which should gration) client extensively using WiFi or GSM Data chan- operate over both wireless networks. This concept was nel for UC signaling traffic. The payload (voice only) to beneficial to the telecommunications providers due to the mobile client is transmitted over a standard GSM better utilization of RF, and to the customers because of channel. GUI of this client is a simple implementation of better radio coverage and maintaining in-campus mobil- UI for managing Web Services responsible for the ad- ity. vanced UC features. Openscape UC mobile Client has no However such a system requires a specialized terminal built in intelligence, which could allow us to name it an (hardware) capable of using DECT and GSM transmis- agent system. sion (GSM means here GSM900 as well as DCS1800) D.Mobile Connect [7]. Such terminal must be able to maintain two concur- rent communication sessions; one over GSM and the At CEBIT 2006 Siemens presented a prototype, and at other over DECT. Additionally it should be available CEBIT 2007 the commercial product of a different Archi- over one personal number irrespective of the terminal lo- tecture, commercially named HiPath Mobile Connect. cation; via DECT in campus and via GSM outside. Intel- Mobile Connect is a solution based on a dual connectivity ligence is located in the network infrastructure, no intelli- (WiFi and GSM) of the commercially available mobile gence in the terminal. phones [9]. With all these advantages this model requires a special- The main architectural difference is the application ized dual-mode GSM/DECT handset. This in turn in- server called FMC Appliance, located within the enter- creases price of the whole solution and diminishes battery prise’s IP network. It is fully managed by the Enterprise. life. Some vendors tried to use another approach. As the contractual relationships do not go beyond a stan- dard commercial contract between the enterprise and telecommunications provider, such system is commer- cially much easier to deploy. Thus much wider adoption of this model. With a lack of information from the mobile provider, a network implementation of the advanced ser- vices like seamless handover between enterprise WiFi and public GSM is implemented partially as FMC client function. It means that more intelligence is moved to the endpoint. This architecture implements for the first time FMC client as an intelligent agent system interworking with FMC Controller through implementation of its ad- vanced functions. Fig. 1 OpenScape UC system architecture E. OpenScape MObile B. Corporate GSM Openscape OSMO (OpenScape MObile) is a client The idea of corporate GSM has been presented by combining rich UC functionality of OpenScape UC Mo- many vendors. The first fully developed architecture bile Client with SIP client implementation on a smart- named DWOS, was presented by Ericsson[8]. Implemen- phone [15]. Though such functionality is beneficial for tation of the critical functionality is split between the en- the users it poses many challenges to the network. terprise and telecommunications provider core infrastruc- OSMO client maintains two parallel connections: ture [14]. This unfortunately requires many integrations • CTI connection to a UC proxy named OpenScape between the provider and enterprise telecommunication Facade in both organisations and in the infrastructure. The mar- • Payload and SIP Signalling connection to an enterprise ket has not developed any appropriate business model Session Border Controller (SBC) named OpenScape and such solutions have not been widely adopted. SBC This architecture is necessary (despite its complica- C.OpenScape UC Mobile Client tions), because SIP is a standard protocol. Standard voice By the year 2002 the first Unified Communications and video functions are implemented within SIP sig- systems were announced to the market [12]. They nalling accessing the enterprise net via SBC. All non promised many advanced features irrespective of the user standard UC protocols are transmitted via data channel to location, administrative domain, or access network tech- a UC proxy. Such architecture with split of functions re- nology. One of the first UC systems in the market was quires the client on a smartphone to perform as an agent. Openscape UC issued by 2004 [13]. In this paper we User interface of UC mobile client OSMO is presented in cover the mobility aspect of this solution. Openscape UC Fig. 2. mobile Client is mainly CTI (Computer Telephony Inte- DARIUSZ BOGUSZ ET AL.: USSD COMMUNICATION CHANNEL AS ALTERNATIVE TO XML SOAP IN MOBILE UNIFIED COMMUNICATION APPLICATIONS 47 Fig. 2 OpenScape OSMO GUI on iPhone III. MOBILE UC SIGNALING TRAFFIC A. Data traffic from UC mobile application Signalling traffic characteristics of such an agent in mobile domain creates an interesting problem with many practical implications for the mobile provider in the sig- nalling and data path. They are also important from the Fig. 3 TCP packet with user status change enterprise security and availability perspective. Issues re- sulting from integration of those two worlds are planned for further investigation. Here we cover only some as- pects of it. Typical Unified Communication mobile user uses the application installed in his mobile phone to: • Change personal status (available, free, out of the office on holiday, etc.) • Change preferred device (office phone, mobile phone , home phone, etc.) • Read phone log (answered/ not answered calls, connections redirected to another device, etc.) • Read telephone book records (global and personal address books) The most frequently used function focuses on the change of personal status of a user. The end users can change their status using OpenScape Mobile application. Request of the status change is transmitted to Unified Communication server as Web Service call using XML data and SOAP [3] protocol. The connection is estab- lished as data channel via IP network. Using this method Fig. 4 TCP packet with USSD code every status change results in transmission of 4890 bytes in 4 TCP packets (without TCP/IP packet headers). Fig 5 presents typical usage of OSMO application Information of Unified Communication subscriber based on the application logs recorded at a mobile phone. status change can be transmitted using 3-5 digits USSD From the data presented at Fig 5 we notice that the code. Fig. 4 presents USSD communication captured number of communication requests per hour per user using Wireshark in SIGTRAN (SS7 over IP protocol) ranges between 1 and 21. Average value is more than 6 MAP messages.