using unstructured service supplementary data ... - MediaTeam Oulu

The 12th International Symposium on Wireless Personal Multimedia Communications (WPMC 2009)

USING UNSTRUCTURED SERVICE SUPPLEMENTARY DATA SIGNALING FOR MOBILE PEER-TO-PEER INVOCATIONS Otso Kassinen University of Oulu Oulu, Finland

Timo Koskela University of Oulu Oulu, Finland

Mika Ylianttila University of Oulu Oulu, Finland

device typically acts as a client and contacts a server that has a well-known public location, mobile P2P This paper proposes a method for initiating IP-based networking requires some special technique that peer-to-peer (P2P) communication sessions in cases enables listening for incoming requests on the device. where the target of the initial communication 3) There is a lack of fixed-fee data plans. Thus, attempt is a mobile device. Mobile P2P networking keeping a P2P application (or any kind of IP poses certain problems: a battery-powered device may connection) always on may cause worries to the user not always keep its network interfaces on for IP who is afraid of surprisingly high data bills. communications due to battery life issues, and mobile In this paper, we propose a solution that alleviates hosts are typically also behind a NAT that hinders those problems. Every GSM or UMTS phone is incoming connections. Our proposed solution to these connected to a base station, which enables “pushing” problems is Network-Assisted P2P Invocation (NAPI). call initiations and SMS messages towards the phone. It takes advantage of an established feature of the Thus, instead of having an IP-based connection GSM and 3G cellular networks: the Unstructured always active, the existing cellular channel could be Service Supplementary Data (USSD) signaling used for P2P invocations. This would save resources protocol. The USSD protocol, which operates over the of the mobile devices, because the devices would be “always-active” channel to the base station, would be available targets for session requests even when they used for requesting the initiation of an IP (TCP, UDP) have no IP-enabled data connection active. connection at the mobile target peer; the thus formed Our solution takes advantage of the Unstructured IP-based connection can then be used for any Service Supplementary Data (USSD) protocol, an application-specific P2P communications. After the existing feature of the widely deployed GSM [2] and initiation, USSD is not used in actual communication. UMTS (3G) [3] cellular networks. In our proposed solution, USSD is used for sending signals which I. INTRODUCTION indicate to the mobile device that it should open its The popularity of mobile peer-to-peer (P2P) IP-based connection and launch the desired networking, relying on the Internet Protocol (IP) application. This IP-based connection, the generic support of the modern wireless access networks, has communication path of the Internet world, is then increased in recent years. It is not uncommon to have, used for application-specific communication. We call for example, a file-sharing application or a P2P- this signaling technique Network-Assisted P2P oriented voice over IP (VoIP) client in the user’s Invocation (NAPI). It needs to be emphasized that personal mobile device. However, there are at least after the initiation, USSD is not used in the actual the following obstacles to mobile P2P networking. communication. 1) A mobile device has a limited battery capacity, NAPI seems promising for launching P2P activities which restricts its abilities to listen to and fulfill such as VoIP, games, video calls, instant messaging, incoming requests. As an extreme example, if the or joining a user group’s private P2P overlay network. device acts as a peer in an active DHT-based overlay II. OVERVIEW OF USSD network, its battery life is just a few hours [1]. Even the simple activity of having a UDP socket open for The USSD protocol is supported by every GSM or listening requires keeping a network interface, such UMTS phone. The USSD version in GSM Phase 1 as WLAN or UMTS, active. This consumes the specifications does not have the “push” mode that battery at a faster rate than staying offline (see enables network-initiated USSD connections; only section III B), especially in WLAN but also in UMTS. mobile-device-initiated connections are possible in In addition to the networking-related energy Phase 1, as pointed out in [4] and [5]. Fortunately, consumption, the running IP-listening applications the USSD version in GSM Phase 2, which enables the also consume CPU cycles and memory. pushing of messages from the network-side (operator) 2) A mobile device practically never has a public IP to the handset, is broadly deployed, as the Phase 2 of address and is typically placed behind a Network GSM has been taken into use already in the 1990s. Address Translation (NAT) or firewall. As opposed to The USSD protocol has no store-and-forward client-server communications, where the mobile support; the connections are always session-oriented. ABSTRACT

The 12th International Symposium on Wireless Personal Multimedia Communications (WPMC 2009) The typical user interface to USSD services is either through dialing commands using the phone’s numeric keys, or with a menu-based browser. USSD is being used for different information services, even for mobile banking in some countries. Examples of simple existing USSD-based services include topping up a prepaid account, and the requesting of a voice call-back when roaming abroad. Among other things, USSD has also been proposed for facilitating push-to-talk management [6] and for indicating service charging information to the mobile user [7]; these two example services rely on the ability to push USSD messages to the mobile device. USSD carries messages of up to 182 characters in length (7-bit characters: 160 bytes). As an additional plus, the load caused by USSD on the operator’s networking resources is very light. USSD operates in the same SDCCH signaling channel as SMS does. USSD is better than SMS for implementing NAPI, because 1) USSD is session-based: the radio channel is reserved until the end of the USSD session which yields shorter delays (in addition, SMS could cause unwanted storing of NAPI messages in the message center when the target device is offline); and 2) roaming with USSD is free of charge (even the nonroaming use of USSD is often free, unlike SMS). USSD applications can reside on different cellularnetwork elements – for example the Home Location Register – which can be senders or receivers of USSD messages [2]. The operation logic of a service can be provided by operators’ Intelligent Network (IN) nodes.

channel. This protocol is used for carrying different pieces of information needed for the initiation of the IP-supporting connection and the application usage. We do not want to specify here the final bit-by-bit format of the NAPI protocol, but in Fig. 1 we define an example message format that shows the kinds of information that the NAPI messages should contain. There are “magic” bits to indicate that the message is NAPI-related, a message type field, the unique application ID, and optional application-specific data.

Figure 1: Example NAPI message format (request or response).

The ID of the application to use is indicated, because the receiving side must know which application to launch in addition to activating the IPsupporting network interface. The middleware knows what applications (in other words, what IDs) are locally installed. IDs can be assigned to applications by e.g. developers. Which network interface from the multiple choices (WLAN, UMTS, etc.) is activated, is decided based on the receiving user’s settings. Messages are marked as requests (type field: binary 0) or responses (type field: non-zero, contains a response code). With the response code, the receiver’s middleware indicates acceptance, rejection, or error to the initiator. Errors can occur if, for example, the requested application is not installed or if the IPenabled connection is unavailable. If acceptance is III. THE PROPOSED TECHNICAL SOLUTION received, the initiator knows that the requested action (IP activation etc.) is in progress on the remote A. Harnessing USSD for Mobile Peer-to-Peer Invocations side, and he only needs to wait for the session a few An essential property of NAPI is that the USSD seconds. In addition, the finishing of the remote connection is not restricted to initiating only one kind action could be indicated with another response. of narrowly-specified service session. Instead, NAPI The optional application-specific field can contain is used as a generic tool for requesting the beginning parameters that are read by the target application in of different kinds of IP-based activities that will order to initiate the communication. This could utilize TCP or UDP. This generic nature of NAPI sets include, for example, the initiator’s IP address and it apart from the existing USSD-based push-to- port, or his application-user ID, such as a Session mobile techniques in the literature, such as [6, 7]. Initiation Protocol (SIP) Uniform Resource Identifier There are at least two main components needed for (URI), or game- or VoIP-system username, to contact NAPI: 1) some entity (a mobile device or operator- by the target device after the application is launched. side equipment) capable of issuing the correct type of An example of application-specific data is a case USSD signals; and 2) a middleware in the mobile where NAPI is used to ask the target device to target device that detects incoming USSD-based become a member in an online P2P community (that NAPI messages and invokes the mobile applications is implemented as a P2P overlay network) when some that should be launched as a result of NAPI messages. community-activity is about to start. The applicationApplications may or may not need to be modified for specific part of the NAPI request could contain the enabling NAPI, depending on their details. In any identifier of the community overlay, possibly along case, the middleware frees the users from keying with the IP address of the overlay’s bootstrap peer. USSD command strings or navigating USSD menus. For many applications, it is also possible that any NAPI obviously requires an agreed-upon messaging additional parameters are not needed; then only the format (protocol) to be used on top of the USSD application ID is enough. For example, if the initiator

The 12th International Symposium on Wireless Personal Multimedia Communications (WPMC 2009) only wants the target to come online in Skype, it is enough that the “launch Skype now” NAPI request is sent. The desired action occurs: the remote user comes online for the IP-based activity, and the initiator can manually start a VoIP call, for instance. In the cases where only plain application-launch is enough, application developers do not need to add NAPI support to the application. This is beneficial, because users can use NAPI without dependency to the developers’ actions. Modification of applications by developers would be needed if an application needs specifically to interact with the NAPI middleware. In addition to actual P2P communications, NAPI can be used in hybrid cases, such as requesting the starting of a target’s mobile Web server. Again, NAPI saves the resources of the mobile device that waits for incoming connections, as the device does not need to keep its IP-enabled connection active all the time. B. Estimated Mobile Energy Savings with NAPI Energy savings of NAPI can be approximated based on our measurements, where a Nokia N95 device staying in the idle state (no IP listening) saves about 6mW or 72mW when compared to IP listening in UMTS or WLAN (IEEE 802.11b/g), respectively. These amounts of power can be saved, as the device waits for P2P invocations without an active Internet connection. For UMTS, the saving is relatively small, but for WLAN it is more substantial. As WLAN is often free but UMTS incurs a cost, some users may strongly prefer WLAN; thus, it is meaningful to say that NAPI saves 72mW (WLAN power), when UMTS listening is not an approvable option for the user. The sleep-mode power consumptions of two IEEE 802.11b cards in [8] are 45mW and 60mW. Even with 45mW, NAPI saves 162J of energy per hour. Moreover, according to [9] the reception of an SMS message consumes less than 0.01J of energy. Since USSD utilizes the same signaling channel as SMS, and the lengths of USSD and SMS messages are similar, it can be concluded that USSD-receiving is similarly energy-efficient. However, the energy consumption of USSD itself (a few messages per session) is only a negligible factor; the real energy savings come from the fact that IP-related listening does not need to be on when waiting for connections.

addressed initial contact (IAIC). In CAIC, the initiator knows the target’s Mobile Station International Subscriber Directory Number (MSISDN) and uses it to refer to the target. Two subtypes of CAIC can be identified: 1) the initiator itself uses USSD for issuing the NAPI request to the correct MSISDN; or 2) the initiator sends a request (containing the target MSISDN) to an aiding server, which is probably maintained by the operator and issues the actual USSD-based requests. The subtype (1) of CAIC of course requires the initiator to be a GSM/UMTS supporting mobile device. The subtype (2) of CAIC works also with non-mobile initiators, if the application in question supports the usage of MSISDN as the target identity. This would probably require impractically large modifications to the P2P application logic in many cases. CAIC is clearly simpler to implement than IAIC. IAIC requires much more complex infrastructure. IAIC would be needed for the initiation of connections towards the mobile device over USSD in cases, where the initiator is a non-mobile device (e.g. PC) that has no GSM or UMTS support. IAIC is also needed for mobile initiator devices, if the initiator is only able to use its IP-based connectivity, or does not have the middleware for issuing NAPI messages, or does not know the target’s MSISDN, or is currently using a non-NAPI-aware P2P application. In IAIC, the initiator identifies the target node by using an address that makes sense for IP-based applications. This target address could be, for instance, a SIP URI or similar application username. Thus, IAIC obviously requires some mediator-entity that maps the Internet-originated address to the correct MSISDN and translates (transparently) the communication request into a USSD-based signal. This is similar to CAIC subtype (2), but here the initiator does not know the target MSISDN or even know that NAPI is used. The mediator-entity could be the mobile operator. The operator would maintain a database of mappings. The mapping could be maintained, for NAPI usage, by the operator’s facilities (for example, a modified SIP server) even when nodes are offline from e.g. SIP. The basic operation of NAPI is illustrated in Fig. 2.

C. Addressing of the Target Device by the Initiator It is justified to ask: Does the connection-initiating remote party need to know about the special technique, or does NAPI work in a transparent manner? How does the initiator’s application refer to a particular target peer? We identify two basic categories of techniques for addressing the target mobile peer in NAPI: cellularaddressed initial contact (CAIC) and Internet-

Figure 2: Basic operation of NAPI.

The 12th International Symposium on Wireless Personal Multimedia Communications (WPMC 2009) In practice, both CAIC and IAIC need transparent inter-operator collaboration, for example through common databases, in order to enable functionalities such as the querying of MSISDNs to enable NAPI signaling towards mobile nodes of different operators.

initiators’ identities could be enforced by the operator. Thus, security-aware target devices could specify the list of trusted MSISDNs, which could not be spoofed. Another security scheme could be a password that must be included in the NAPI message. Reliable authentication could also be done with public key D. Aid for NAT Traversal infrastructure (PKI) based schemes over USSD. This NAPI opens certain possibilities for NAT traversal in could involve bidirectional communication between the target to the initiator. The request would be mobile P2P communications. For example, a prerequisite for using the Traversal signed with the initiator’s private key; the target Using Relay NAT (TURN) data-relaying system is a accepts to start its IP-supporting network interface mechanism that allows the communication initiator and launch the desired application only after to indicate its relayed-transport-address (i.e. the verifying the signature. This would also work in IAIC, initiator’s “public address” at the relay server) to the with the initiator being a PC device, for example. It should be taken into account that a cellular data target device. The address could be indicated in a NAPI message. With that information, the target’s connection (GPRS, UMTS, etc.) typically has a application would know to start communication to monetary cost. There can be rules for NAPI the initiator’s relayed address. In this way, NAPI instructing to trigger, for example, only a free-ofsatisfies the initiator’s need to have its relayed IP- charge WLAN connection, based on user preferences. As a cellular-dependent system, NAPI should be address propagated to the target nodes. Like the initiator, also the target is probably aware of roaming users. While USSD roaming itself behind a NAT. Here NAPI also provides benefits, by should be free of charge, the invoked P2P removing the difficulty of taking an initial P2P communication over an IP-based data connection can contact towards a target behind a NAT, because the be very costly in the network of a foreign country. The cellular-network based contact is not hindered by user should be able to specify rules such as ignoring NAT. In a way, NAPI provides a rough equivalent of all NAPI connection attempts if roaming. Another concern for the mobile user is the listening to a well-known port behind a NAT, which is not possible with, for example, basic TURN (of course, remaining battery capacity. If the battery is low and the real application traffic will flow through UDP or the user wants to save the remaining charge, the user TCP connections as soon as IP-based NAT traversal may want to ignore connection attempts. The system such as TURN has been initiated with NAPI signals). could observe the battery state, and that information Furthermore, let us consider that the Simple could be used as input for a reject-connections rule. Traversal of UDP through NATs (STUN) protocol IV. BUSINESS POTENTIAL allows a device to determine its NAT-allocated IP address and port for use with communication The provision of mobile data and voice services is a initiation with remote hosts. For the benefit of the business controlled by operators that need paying target node, NAPI could provide similar functionality customers. If NAPI is implemented in a form that at the time of a contact attempt, to facilitate and requires operator support, a viable business incentive speed up the application’s connection establishment. is needed for the co-operation of the operators. The operator would notice that a NAPI message is Existing USSD-based services are often charged by being sent towards the target through the cellular content access or usage duration, but USSD usage network. Thus, the operator could add to the message can also be free of charge, depending on the the IP address and port that will be allocated for the operator’s billing rules and the services consumed. target in the (operator-provided) NAT. This service The NAPI service could be 1) provided free of implies that the operator integrates its NAT system charge, if the operator’s business goal is to increase with NAPI and guarantees that the address-port pair IP-based traffic and thus indirectly to increase their embedded in the NAPI message will actually be revenue from data billing. Or, 2) operators can charge allocated for the target, when the target – probably in for the NAPI service, in order to get direct revenue. a few seconds after the NAPI request – comes online. As seen in the Internet of the present day, people E. Security and Privacy Privacy of the users must be honored. Users must be able to specify rules that restrict the incoming NAPI connections. For example, contact attempts could be accepted only from trusted initiators, and other attempts would be ignored. At least in CAIC,

generally are reluctant to pay for content (with some exceptions), but they are willing to pay a moderate fee for connectivity. Thus, it is interesting to note that the proposed USSD-based solution is just a form of connectivity: the mobile user obtains the ability to be contacted for P2P communications (including even mobile server like usages). Users could be interested

The 12th International Symposium on Wireless Personal Multimedia Communications (WPMC 2009) in NAPI as an operator-provided connectivity service. Moreover, for many kinds of services, people have the tendency to prefer flat-rate charging over usagebased charging [10], even in cases where flat-rate charging does not bring an actual monetary benefit. Based on the charging model studies, flat-rate charging seems to be the most appropriate for NAPI. Another point speaking in favor of flat-rate is the fact that if the paying user is the target of connection attempts, he cannot directly control the number of incoming NAPI-based connections; under such conditions, usage-based billing would seem irrational. Intuitively, the NAPI flat-rate fee should be quite modest, because NAPI is just an enabler for more specific services that might not appear immediately to the users (possible slow start for customer adoption); it would be infeasible to charge heavily for NAPI. Conceivably NAPI could also be bundled in a broader service package of the operator. It is also an interesting question, which of the following should be true: 1) the user who made himself contactable with NAPI, pays; or 2) the user who initiates contacts to others with NAPI, pays. We assume that the alternative (1), especially when combined with flat-rate billing, is more viable, because the initiating device could be a non-mobile device (such as a PC) with no flexible cellular-based billing mechanism; the target is always mobile. However, when deciding who pays, we should ask: Is the NAPI-initiated connection beneficial for both users? On one hand, the user may be willing to pay for NAPI as an “availability enhancer” (for incoming VoIP calls etc.). On the other hand, for a NAPIcontactable user that only provides content or services for the initiators, paying for just “being a servant of others” does not sound appealing. From the viewpoint of operators, USSD is an established, lightweight technology, and using it for only P2P connection initiations is a minor burden to the network if we compare it to the continuous provision of voice call data streams, for example. In order to apply NAPI, the middleware component needs to be installed in the mobile device. Different ways to achieve this are at least: pre-installation by device manufacturer, pre-installation by operator, provision as part of a NAPI-supporting application, or separate manual installation. The availability of the middleware in a large number of users’ phones is essential for NAPI-based P2P invocations to work, thus it is not only a technical question but it must also be taken into account in a NAPI business plan. V. DISCUSSION AND FUTURE WORK With NAPI, mobile devices (having a GSM or UMTS capability) can attain a similar level of being “callable” in a P2P manner for IP-based application

activities as fixed-line computers already have. Possible NAPI use cases include P2P-oriented context information retrieval, file push or file retrieval, access to mobile servers, instant messaging invitation, and invitation to join a P2P user community or DHT overlay network for online group collaboration. The wide deployment of USSD makes it a viable choice for implementing NAPI signaling towards mobile devices. In order to evaluate properly the feasibility of NAPI, a prototype implementation is needed. This may require a prototyping environment where the developers have access to operator-side equipment for realizing certain parts of the service. Business studies are needed to evaluate end-users’ response to the service, and whether they are willing to pay for cellular-assisted P2P listening functionality. VI. ACKNOWLEDGEMENT This work has been financially supported by the Finnish Funding Agency for Technology and Innovation (TEKES) and the ITEA2 program. REFERENCES [1] I. Kelenyi and J. K. Nurminen, “Energy aspects of peer cooperation – Measurements with a mobile DHT system,” in

Proceedings of the IEEE International Conference on Communications, Cognitive and Cooperative Wireless Networks Workshop, 2008, pp. 164−168. [2] European Telecommunications Standards Institute, “Digital cellular telecommunications system (Phase 2+); Unstructured Supplementary Service Data (USSD) - Stage 2 (GSM 03.90 version 7.0.0),” 1999. [3] European Telecommunications Standards Institute, “Digital cellular telecommunications system (Phase 2+); Universal Mobile Telecommunications System (UMTS); Unstructured Supplementary Service Data (USSD); Stage 2 (3GPP TS 23.090 version 7.0.0),” 2007. [4] Nokia Networks, “Method for improving the performance of USSD transfer in a cellular communications system,” US patent 6834196, 2004. [5] Ericsson corporation, “Unstructured Supplementary Service Data from a home location register to an external node,” US patent 5752188, 1998. [6] Ericsson corporation, “USSD-facilitated call setup for push to talk over cellular (PoC) services,” US patent 7289816, 2007. [7] Ericsson corporation, “Indication of charging information using the USSD mechanism,” US patent 6496689, 2002. [8] E. Shih, P. Bahl, and M. J. Sinclair, “Wake on wireless: An event driven energy saving strategy for battery operated devices,” in Proceedings of the 8th Annual International Conference on Mobile Computing and Networking, 2002, pp. 160−171. [9] L. Zhong, B. Wei, and M. J. Sinclair, “SMERT: Energy-efficient design of a multimedia messaging system for mobile devices,” in Proceedings of the 43rd ACM/IEEE Design Automation Conference, 2006, pp. 586−591. [10] H. Mitomo and T. Otsuka, “Consumers’ preference for flat rates: A case of media access fees,” in Proceedings of the

International Telecommunications Society 17th Biennial Conference, 2008, 11 pp.