336 Mobile Messaging Technologies and Services † Presence and Instant Messaging Protocol (PRIM) † SIP for Instant Messaging and Presence Leveraging Extensions (SIMPLE) SIMPLE is an IMPS protocol based on the Session Initiation Protocol (SIP) [RFC-3261] and is particularly well suited for UMTS phase 2. SIMPLE defines a mechanism for subscribing to a service which manages subscriber status changes over a SIP network. The Wireless Village Initiative was recently set up by several manufacturers to consider the support of IMPS in the mobile environment. The prime objective of this initiative is to develop an industry standard to guarantee interoperability between various IMPS services that could be deployed in the near future. The IMPS model, proposed by the Wireless Village, includes four primary features: † Presence: this feature manages information such as device availability (e.g. mobile device has been switched on/off, voice call under progress), user status (e.g. available, not avail- able, having a meeting), user location, mobile device capabilities, personal status/moods (e.g. happy, angry), etc. To ensure confidentiality, presence information is provided according to user instructions only. † Immediate Messaging: this feature allows the exchange of messages delivered instanta- neously to the recipient(s). This means that, upon sending by the originator, the message is perceived as being immediately delivered to the message recipient(s). Compared with traditional messaging services, instant messaging allows the establishment of interactive messaging sessions between users. These sessions are usually displayed using a threaded conversational interface, also known as chat. † Groups: this feature allows users to create and manage their own groups. The manager of a group can invite other users to chat with the group members. Network operators can create general interest groups. † Shared Content: this feature provides users with storage zones where pictures, audio and other multimedia contents can be posted and retrieved. These contents can be shared among several users during group messaging sessions. The general architecture of the Wireless Village initiative solutions is depicted in Figure 7.1. In the architecture shown in the figure, the Wireless Village server is a central element. This server manages the following services: presence, instant messaging, groups and content sharing. Two types of Wireless Village clients can communicate with the server: the Wireless Village embedded client and the Wireless Village Command Line Interface (CLI) client. The Wireless Village embedded client is a dedicated application embedded in a mobile device. This client communicates with the server over the Client Server Protocol (CSP). On the other hand, the Wireless Village CLI client uses text messages (e.g. SMS) to communicate with the server using the Command Line Protocol (CLP). A CLI client is usually a legacy mobile device. Two Wireless Village servers, located in the same provider domain or in two distinct provider domains, can communicate with the Server-Server Protocol (SSP). A Wireless Village server may also be connected to a proprietary IMPS system via a proprietary gateway. In this configuration, the gateway transcodes SSP instructions into instructions supported by the proprietary system, and vice versa. The Server-Mobile Core Network Protocol (SMCNP) allows the server to obtain presence information and service capabilities from the mobile core network. In addition, the SMCNP can also be used for authentication and authorization of users, clients and servers. 337 Other Mobile Messaging Services Figure 7.1 General Wireless Village architecture Wireless Village technical specifications can be downloaded from http://www.wireless- village.org. 7.2 Mobile Email Email is the de facto messaging service on the Internet. However, due to the bandwidth limitations of mobile systems and the fact that mobile devices are seldom permanently connected to the network, Email is not widely used in the mobile telecommunications domain. Nevertheless, several manufacturers have designed Email clients for mobile devices using standard Internet messaging protocols such as the Post Office Protocol-3 (POP3), defined in [RFC-1939] and the Interactive Mail Access Protocol (IMAP), defined in [RFC- 1730]. These solutions have the advantage of allowing mobile subscribers to communicate seamlessly with remote Internet users (using the same message formats and server access protocols). However, these solutions have proven to be very impractical to use without a minimum adaptation to the constraints of mobile devices and networks. The major barriers to the success of these solutions are the ‘pull’ model for retrieving messages which requires frequent accesses to the Email server and the fact that server access protocols are not resource efficient. In order to offer an Email service adapted to the requirements of mobile subscribers, the company Research in Motion (RIM) designed a set of extensions for the existing Email service. This extended Email service, offered to subscribers under the denomination ‘Black- berry service’, bypasses Email inadequacies to the mobile domain by enabling: † a ‘push’ model for message retrieval † a compression of messages † an encryption of messages. Two main configurations are available for the Blackberry service. The first configuration 338 Mobile Messaging Technologies and Services Figure 7.2 The Blackberry service configuration limits the impact on existing Email architectures by integrating a ‘desktop’ Blackberry application (the Blackberry desktop redirector) in the user’s personal computer used for accessing Email messages. When the user is on the move, the desktop application intercepts incoming messages, compresses them, encrypts them and pushes them to the Blackberry device via a mobile network. The other way round, the user can compose a new message with the Blackberry device. The message is compressed and encrypted by the device and sent via the mobile network to the desktop application. The desktop application receives the message (by polling the Email server), decompresses and decrypts it and sends it normally to the message recipients as if the message had been sent out directly by the user from his/her personal computer. A more sophisticated configuration of the Blackberry service consists of installing an extension to the Email server itself (the Blackberry enterprise server). Basically, in the second configuration, the user’s personal computer does not have to be left running when the user is on the move. With this configuration, messaging functions performed by the desktop application in the first configuration are performed here by the server extension. In addition, this configuration also allows the synchronization of calendaring and scheduling data between shared corporate databases and remote Blackberry devices. The enterprise configuration of the Blackberry service is depicted in Figure 7.2. The Blackberry service is already available in North America and is currently being deployed in other countries in Europe (United Kingdom and France). The service fulfils particularly well the needs of itinerant professional users, who avoid using laptop computers while on the move (because of long dial-up time for accessing Email servers, etc.). The Multimedia Messaging Service (MMS), described in the previous chapter, targets the mass market by supporting a messaging service, similar to the Email service, with small handsets. On the other hand, the Blackberry service targets the professional market with devices 339 Other Mobile Messaging Services designed as Personal Digital Assistants. More information can be obtained on the Blackberry service from Research in Motion (RIM) at http://www.rim.com and Blackberry service at http://www.blackberry.net. 7.3 IMS Messaging Chapter 1 introduced the two phases for UMTS. The second phase of UMTS is built on the IP-based Multimedia Service (IMS) based on the Session Initiation Protocol (SIP) for session/ call management. The 3GPP recently initiated work on messaging services based on a combination of IMS service capabilities (e.g. presence) and already defined messaging services (SMS, EMS and MMS). The scope of this work initially consists of identifying (in the release 6 timeframe) the requirements for messaging services in the IMS environment. These requirements will be detailed in the technical report [3GPP-22.940]. Appendices A TP-PID Values for Telematic Interworking For enabling SMS interworking with various telematic devices, the set of protocol identifiers (TP-Protocol-Identifier) listed in Table 1 can be used. Table 1 Protocol identifiers for telematic interworking TP-PID value (hex) Description 0x20 Type of telematic device is defined by the message destination or originator address. 0x21 Telex (or teletex reduced to telex format) 0x22 Group 3 telefax 0x23 Group 4 telefax 0x24 Voice telephone (i.e. conversion to speech) 0x25 European Radio Messaging System (ERMES) 0x26 National paging system (type known to the service centre) 0x27 Videotext such as T.100 or T101 0x28 Teletex, carrier unspecified 0x29 Teletex, in PSPDN 0x2A Teletex, in CSPDN 0x2B Teletex, in analogue PSTN 0x2C Teletex, in digital ISDN 0x2D Universal Computer Interface (UCI) 0x2E…0x2F Reserved (2 values) 0x30 Message handling facility (type known to the service centre) 0x31 Public X.400-based message handling system 0x32 Internet electronic mail 0x33…0x37 Reserved (5 values) 0x38…0x3E SC specific use (7 values) 0x3F GSM or UMTS