Push-to-talk in PDC Packet data network

Transcription

1 Umeå University Department of Computing Science Master Thesis, 20 credits Olof Burman Push-to-talk in PDC Packet data network Internal Supervisor: Pedher Johansson External Supervisor: Håkan Nordmark

2

3 Abstract Push-to-talk is a walkie-talkie type of service over mobile phones. By combining the benefits of a walkie-talkie and a mobile phone it creates a fast, cheap and easy way to communicate with multiple people at once. Push-to-talk services already exist but they only work within their own system. To eliminate this problem and achieve interoperability between operators, terminals and networks a specification, Push-to-talk over Cellular, is being constructed. It is a jointly developed specification by mobile industry leaders, Ericsson, Nokia, Motorola and Siemens. This master thesis studies the specification for PoC and investigates to what extend it can be applied to the Japanese mobile cellular system PDC. A prototype of a push-to-talk system, following the PoC specification, has also been implemented.

4

5 Acknowledgements I would foremost like to thank my supervisors, Pedher Johansson and Håkan Nordmark, for their help during this master thesis. I would also like to thank Roger Sjölin, Tomas Röjmyr and Jan Halvarsson for their involvement in my work. Last but not least I would like to thank the employees at TietoEnator for making this a fun and educational experience.

6

7 Table of contents 1. Introduction Goal Thesis outline PDC PPDC Network overview Push-to-talk over Cellular Standards and Protocols SIP - Session Initiation Protocol RTP Real-time Transport Protocol XML - Extensible Mark-up Language XCAP XML Configuration Access Protocol Architecture Entities PoC Client PoC Server GLMS Group List Management Server Presence Server SIP/IP Core Interfaces Is interface It interface Itn interface Im interface In interface Ik interface If interface Ipl interface Ips interface Igs interface Ie interface Identification and Usage PoC applicability to PDC Implementation of a PoC prototype Hardware and software Limitations Design and implementation The Client The SIP Core The PoC Server Testing Problems encountered... 38

8 5. Conclusions References...43 A Abbreviations 45 B User Guide 47

9 List of figures Figure 1: PDC network overview...14 Figure 2: SIP signaling flow...20 Figure 3: RTP packet...22 Figure 4: SR packet...23 Figure 5: The PoC architecture...26 Figure 6: Instant personal talk signaling flow Figure 7: Implemented parts of the PoC architecture...36 Figure 8: The Client with the user tree opened....37

10

11 1. Introduction As the Internet and mobile telecommunications becomes more and more integrated new ways to communicate appears. Some of them, like WAP and MMS, have already made their way into every day life and others are on the way. One of the new upcoming applications is Push-to-talk (PTT), a walkie-talkie type of service that gives the user the capability to simultaneously communicate with one or more persons. Push-to-talk uses Voice over IP[17] (VoIP), a way of packaging and transmitting voice data over the Internet, or any other packet data network. Since Push-to-talk uses some kind of network to transport the data, unlike a walkie-talkie that sends it directly to the receivers, it has the potential to communicate worldwide. It also minimizes the bandwidth needed by only sending data when someone is talking, which makes it very cost-efficient when used with a packet-switched network like GPRS. Push-to-talk is however not a new concept. It was first introduced by the US operator Nextel on their iden network about ten years ago. Nextel has a proprietary solution that only works in their network. Since then a few other companies have launched their own software Push-to-talk services, one example is the Swedish company Sapio. Their Push-to-talk client comes in the form of a Java application that is installed on the mobile phone. In the last couple of months there has been a tremendous increase in telecommunication companies trying to make their way into the Push-to-talk market. SonyEricsson, Nokia and Motorola are, or soon will be, offering phones with Push-to-talk. To achieve interoperability between operators, terminals and networks, a Push-totalk specification over standard mobile networks, PoC (Push-to-talk over Cellular), is being developed by the mobile industry leaders, Ericsson, Nokia, Motorola and Siemens [8]. PoC is also supported by AT&T Wireless Services, Cingular, Sonim Technologies and SonyEricsson [10]. Since the specification is not frozen there might be some inconsistencies between this report and the final PoC specification. At TietoEnator the PDC (Personal Digital Cellular) system for the Japanese mobile telephone market is developed, verified and maintained. The PDC mobile telephone standard is a variant of the GSM standard and is used in the Japanese mobile telephony network. Among other things it includes a service for sending IP packet based traffic over the radio network, a system called Packet PDC (PPDC) which is the Japanese version of GSM:s GPRS service. As Push-to-talk is becoming a recognised concept in GSM networks, but something similar is missing in the PDC network, TietoEnator wants to examine the Push-to-talk standard and investigate if it could be applied to PDC. 11

12 Chapter 1. Introduction 1.1. Goal The goal of this master thesis is to investigate the Push-to-talk specification for GSM and to which extent it can be applied to the Japanese mobile cellular system PDC. An in-depth study of the Push-to-talk specification and an overview study of the PDC system will be conducted. It will then be concluded to which extent the Push-to-talk specification for GSM can be applied to the PDC network. A prototype of a Push-to-talk system, following the specification, will be implemented. The client will be implemented in Java to ease portability Thesis outline The second chapter gives an introduction to the PDC mobile system. The history of PDC and the techniques it uses are described. The packet switched part (PPDC) of the system is also described. Finally an overview of the system components is given. In the third chapter the Push-to-talk specification for GSM, PoC, is described. It is explained why it is developed and by whom. The standards and protocols on which it is built and its architecture, with all of its components and interfaces, are also described. The chapter is ended with the concluding of to which extent PoC can be applied to the PDC system. The fourth chapter describes the implemented prototype. It is explained which hardware and software that were used and limitation and design decisions that were made. Furthermore the implemented components, test results and problems encountered are described. The fifth chapter concludes the master thesis. 12

13 2. PDC PDC (Personal Digital Cellular or Pacific Digital Cellular) is a second-generation mobile phone system. It was first introduced by NTT DoCoMo in 1991 as a replacement for the earlier analog networks. Even thou it only exists in Japan it accounts for about 10% of the world market for second-generation mobile phone users. PDC is very similar to GSM (Global System for Mobile Communication) and they both use TDMA (Time Division Multiple Access) to share a frequency channel. TDMA divides each channel into individual time slots in order to increase the amount of data that can be carried, or in this case number of users. PDC operates in the 800 and 1500 MHz bands and uses 25 khz channel spacing. PDC supports two operating modes, full-rate and half-rate. In full-rate mode, normally used, it can support three users per frequency channel. If the traffic levels are high it can use half-rate and double the supported users to six per channel, this will of course reduce the sound quality. PDC is the most spectrally efficient TDMA technology in use today. GSM only supports eight users over a 200 khz channel compared to PDC that can support up to six users over a 25 khz channel. Both GSM and PDC, in full-rate, have a digital data transfer rate of 9.6 kbps. PDC in half-rate only offers a transfer rate of 5.6 kbps. Even though it results in a significantly lower sound quality the speech is still understandable [6, 13]. Like other second-generation technologies PDC offers an impressive array of advanced features. It has the usual features like text messaging and caller identification. Furthermore it utilizes its Intelligent Network (IN) capabilities to support features like pre-paid calling, Universal Access Numbers, advanced charging schemes, personal numbers and virtual private networks (VPN). VPNs are limited access groups that allow people working in different locations to communicate through the mobile phone network as though they were using a conventional office phone system [6, 13]. One very important feature in Japan is that of coverage, especially within buildings such as shopping malls, offices and subway stations. PDC has been designed to solve this with a network of micro and pico cells that can be deployed indoors. The base stations for these cells use low power combined with distributed antenna systems and repeaters to ensure the required coverage [6, 13] PPDC PPDC (Packet PDC) or PDC-P (PDC mobile Packet Data Communication System) has been introduced in the PDC system to enable data transmissions. PPDC utilizes a packet switch system instead of the usual circuit switch, which makes it far more efficient when bursty applications such as web browsing are used. PPDC allows a user to use an entire channel at once allowing a data transfer 13

14 Chapter 2. PDC rate on the downlink of 28.8 kbps. The uplink on the other hand only supports the usage of one time slot, lowering the transfer rate to 9.6 kbps. PPDC also charges the user differently. Instead of paying for the connected time the user pays for the amount of data transmitted. This allows a user to be online a long time without it costing a fortune [6, 13]. It is also possible to combine packet data and circuit data on the same frequency [4] Network overview The PDC and PPDC network consist of the components shown in Figure 1 and listed below. Figure 1: PDC network overview 14

15 Chapter 2. PDC MS The Mobile System communicates over the air with a Base Station (BS). The MS can be assigned an IP address and thereby connect to an Application Server (AS) that stores the IP-based content. The MS can access this content by establishing a radio link to a PMSC. The IP address is dynamically assigned by the PMSC and is retained by the MS until it deregisters. BS The Base Station is connected to antennas that transmit and receives information over the air to enable the BS to communicate with MSs in their covered area. The BS separates circuit- and packet-switched calls before forwarding them to the VMSC. VMSC The Visited Mobile Services Switching Center is the main component in the circuit-switched network. It is responsible for the operation and maintenance of the radio network resources. It provides functions for switching, call setup, circuit-switched charging and so on. Each VMSC controls multiple BSs and provides the interface to the HLR and GLR database. It also maintains and updates subscription information about the subscribers currently served, and stores information about the location of the MS. When used with packet-switched communication it controls if the MS is allowed to use packet data. All the packetswitched user data and control signaling data is carried transparently through the VMSC. PMSC - The Packet Mobile services Switching Center is the main component in the PPDC system. It handles the packet data switching functionality between MSs and ASs, and provides IP-based connectivity by assigning dynamic IP addresses to MSs wishing to setup an end-to-end packet data session to an AS. It also routes and forwards incoming and outgoing IP packets within the PMSC s Terminal Registration Area (TRA). The TRA is the geographical area covered by one PMSC. The PMSC provides mobility management functions that allow MSs to keep their communication links while moving. These functions include registration and deregistration, authentication and update of routing information. OSS The Operations Support System is used by the operator to plan, operate and maintain the system. It contains a database of all the parameters the operator has set and the information about the current status of the network. NOC The Network Operational Center is used to configure and manage the PMSCs. The NOC is only needed for the PPDC system. CHSe The Charging Server collects charging data that is generated by the PMSC periodically or after a call is completed. The CHSe only collects charging data for packet-switched connections. HLR The Home Location Register is a database that contains the subscription information for all users. It contains information like supplementary services, 15

16 Chapter 2. PDC authentication parameters, the location of the MS and if the MS is allowed to use packet data communication. GLR The Gateway Location Server is the database that contains subscriptions for subscribers visiting from other mobile networks. GMSC The Gateway Mobile services Switching Center switches all the circuitswitched calls between the PDC network and the Public Switched Telephone Network (PSTN). It is not used by the PPDC. AS The Application Server provides the content that the operators offer. It can include IP-based services from both local and external sources like the Internet. For security reasons a firewall is installed between the AS and the Internet [4]. 16

17 3. Push-to-talk over Cellular On the 25:th of August 2003, a specification for Push-to-talk over Cellular (PoC) was submitted to the Open Mobile Alliance (OMA). It is a jointly developed specification by the mobile industry leaders, Ericsson, Nokia, Motorola and Siemens [8], and supported by AT&T Wireless Services, Cingular, Sonim Technologies and SonyEricsson [10]. The specification outlines a Push-to-talk type of service over standard mobile networks. It defines a half-duplex Voice over IP solution. PoC is primary designed for GSM/GPRS/EGPRS packet switch networks, but can easily be expanded to other networks that use the IP protocol. Therefore, it can also be used in PPDC, UMTS, LAN and Wi-Fi networks. The solution outlined is based on the IP Multimedia Subsystem (IMS), as defined by Third Generation Partnership Project (3GPP), and it is built on established standards like Session Initiation Protocol (SIP), Real Time Protocol (RTP) and Hyper Text Transfer Protocol (HTTP). The main idea behind the standardization of PoC is to attain interoperability between operators and between terminals and networks. However, the specification is still not frozen and work will continue throughout This master thesis is based on Release 1.0 of the PoC Specification. The unfrozen specification has resulted in a minor crack between Nokia and the others. Nokia has chosen a slightly different solution for their first Push-to-talk mobile phones. It is however based on the PoC standard and it will be upgradeable to the standard when it is finished [8]. Another Push-to-talk service that is based on the PoC specification is Ericsson Instant Talk[2]. PoC should not be seen as a cheap alternative to regular phone calls, due to the half-duplex mode, latencies and group functionality. Nor is it a SMS or replacement, since the massage is not stored and forwarded. It should rather be seen as a complement to existing voice and messaging services and is believed to place it self between regular phone calls and SMS [12] Standards and Protocols The Core of the PoC network is IMS (IP Multimedia Subsystem), a standardized architecture for peer-to-peer communication over IP. IMS in its turn is based on SIP (Session Initiation Protocol), see below for further information about SIP. The PoC network also uses some other standardized protocols, for example RTP and HTTP. These protocols have already been used in the Internet and mobile community for quite some time. As a service platform IMS aims at real-time multimedia services that easily integrate with each other and telephone services. By bringing together call control and service provision into a horizontally integrated system IMS enables new combinations of services and service elements. 17

18 Chapter 3. Push-to-talk over Cellular SIP - Session Initiation Protocol Session Initiation Protocol (SIP) was developed in the mid-1990s by the IETF (Internet Engineering Task Force) as a real-time communication protocol for IP voice. Since then it has expanded into video, interactive games, virtual reality and instant-messaging applications. SIP is firmly grounded in the culture of the Internet and has drawn heavily from the experiences of developing protocols such as HTTP. It is a text-based request-response protocol, similar to HTTP and SMTP, for initiating interactive communication sessions between users. SIP was designed to specifically reuse as many existing protocols and protocol design concepts as possible. For example, SIP was modeled after HTTP, using URLs and SDP. Much of the syntax in message headers and many HTTP codes are reused. For example: the error code 404 for an address not found is identical to that used in HTTP. SIP also re-uses the SMTP for address schemes. A SIP address, such as sip:olof@tietoenator.com, has the same structure as an address. SIP even leverages Web architectures, such as DNS, making messaging among SIP users even more extensible. SIP runs on top of several different transport protocols, UDP being one of them [16]. Since SIP was designed for the Internet there where no big concerns regarding bandwidth and latencies. This meant that the size of the messages was not a priority. But when SIP is used in a mobile environment the priorities change. To solve this new problem Signal Compression (SigComp) is used. SigComp can use any compression algorithm to compress ASCII-based protocols, such as SIP, to a fraction of their original size [10]. SIP does not have any way to describe the content and its characteristics. SIP therefore uses SDP (Session Description Protocol) to convey session information. SDP includes description of: media to use (codec, sampling and so on), media destination (IP address and port number), session name and purpose, times the session is active and contact information. SIP invitations used to create sessions carry session descriptions that allow participants to agree on a set of compatible media types [7]. SIP was designed to solve only a few problems and to work with a broad spectrum of existing and future IP telephony protocols. To this end SIP provides four basic functions: SIP allows for the establishment of user location (translating from a user's name to their current network address). SIP provides for feature negotiation so that all of the participants in a session can agree on the features to be supported among them. SIP provides call management - adding, dropping and transferring participants. SIP allows for changing features of a session while it is in progress [15]. To provide these functions SIP sessions utilize up to four major components: SIP User Agents, SIP Registrar Servers, SIP Proxy Servers and SIP Redirect Servers. 18

19 Chapter 3. Push-to-talk over Cellular Together, these systems deliver messages embedded with the SDP protocol defining their content and characteristics to complete a SIP session. Below is a high-level description of each SIP component and the role it plays in this process: User Agents (UA) are the end-user devices, such as cell phones, PCs, PDAs, etc. used to create and manage a SIP session. The User Agent Client initiates the message and the User Agent Server responds to it. Registrar Servers are databases that contain the location of all User Agents within a domain. In SIP messaging, these servers retrieve and send participants IP addresses and other pertinent information to the SIP Proxy Server. Proxy Servers accept session requests made by a UA and query the SIP Registrar Server to obtain the recipient UA s addressing information. It then forwards the session invitation directly to the recipient UA if it is located in the same domain or to a Proxy Server if the UA resides in another domain. It also authenticates and authorizes users for services. Redirect Servers allow SIP Proxy Servers to direct SIP session invitations to external domains. SIP Redirect Servers may reside in the same hardware as SIP Registrar Servers and SIP Proxy Servers [16]. SIP supports a variety of methods, below is a list of the most important: INVITE initiates sessions ACK confirms session establishment, can only be used with INVITE BYE terminates sessions REGISTER binds a permanent address to current location [1] When used for telephony the SIP protocol performs basic call-control tasks such as session set up and tear down, and signaling for call initiation, dial tone and termination. SIP also controls other signaling for features such as hold, caller ID and call transferring. Its functions are similar to the Signaling System 7 protocol in standard telephony and H.323 in IP telephony. The SIP model for telephony puts most of the intelligence for call setup and features on the SIP device or user agent - such as an IP phone or a PC with voice or instant-messaging software. This lets SIP user agents provide more features and operate in more of a peer-topeer fashion. The method is different from traditional telephony where most call processing and control intelligence reside on a centralized phone switch or server. Example The example below describes a normal talk session using SIP. It shows the signaling flow (Figure 2), the contents of the INVITE and a description of the contents in the INVITE. 19

20 Chapter 3. Push-to-talk over Cellular The talk session consists of four user actions: 1. Alice calls Bob using his SIP URI 2. Bob accepts the call. 3. They talk. 4. Bob ends the call. These actions result in the following signaling flow: atlanta.com proxy biloxi.com proxy Alice Bob INVITE INVITE 100 Trying INVITE 100 Trying 180 Ringing 180 Ringing 180 Ringing 200 OK 200 OK 200 OK ACK Media Session BYE 200 OK Figure 2: SIP signaling flow The first signal sent was an INVITE. The INVITE in this example has the following contents: INVITE SIP/2.0 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hg4bk776asdhds Max-Forwards: 70 To: Bob From: Alice Call-ID: CSeq: INVITE Contact: Content-Type: application/sdp Content-Length: 142 (Alice's SDP not shown) 20

21 Chapter 3. Push-to-talk over Cellular The first line of the text-encoded message contains the method name (INVITE). The lines that follow are a list of header fields. This example contains a minimum required set. The header fields are briefly described below: Via contains the address at which Alice is expecting to receive responses to this request. It also contains a branch parameter that identifies this transaction. Max-Forwards limit the number of hops a request can make on the way to its destination. It consists of an integer that is decremented by one at each hop. To contains a display name (Bob) and a SIP or SIPS URI (sip:bob@biloxi.com) towards which the request was originally directed. From also contains a display name (Alice) and a SIP or SIPS URI (sip:alice@atlanta.com) that indicate the originator of the request. This header field also has a tag parameter containing a random string ( ) that was added to the URI by the user equipment. It is used for identification purposes. Call-ID contains a globally unique identifier for this call, generated by the combination of a random string and the user equipments host name or IP address. The combination of the To tag, From tag, and Call-ID completely defines a peer-to-peer SIP relationship between Alice and Bob and is referred to as a dialog. CSeq or Command Sequence contains an integer and a method name. The CSeq number is incremented for each new request within a dialog and is a traditional sequence number. Contact contains a SIP or SIPS URI that represents a direct route to contact Alice, usually composed of a username at a fully qualified domain name (FQDN). While a FQDN is preferred, many end systems do not have registered domain names, so IP addresses are permitted. While the Via header field tells other elements where to send the response, the Contact header field tells other elements where to send future requests. Content-Type contains a description of the message body (not shown). Content-Length contains an octet (byte) count of the message body [7] RTP Real-time Transport Protocol RTP provides end-to-end delivery services for data with real-time characteristics, such as audio, video or simulation data, over multicast or unicast network services. Those services include payload type identification, sequence numbering, time stamping and delivery monitoring. Applications typically run RTP on top of UDP to make use of its multiplexing and checksum services, both protocols contribute parts of the transport protocol functionality. RTP itself does not provide any mechanism to ensure timely delivery or provide other quality-of-service guarantees, but relies on lower-layer services to do so. It does not guarantee delivery or prevent out-of-order delivery, nor does it assume that the underlying 21

22 Chapter 3. Push-to-talk over Cellular network is reliable and delivers packets in sequence. The data transport is augmented by a control protocol (RTCP) to allow monitoring of the data delivery in a manner scalable to large multicast networks, and to provide minimal control and identification functionality. RTP and RTCP are designed to be independent of the underlying transport and network layers. Figure 3, shows the RTP packet contents Figure 3: RTP packet [5] Version (V)(2 bit): Indicating the current version of RTP. The current version of RTP is 2.0. Padding (P)(1 bit): If P is set the packet contains one or more additional padding octets at the end, which are not part of the payload. Padding is needed by some encryption algorithms, which require fixed block sizes, or for carrying several RTP packets in a lower-layer protocol data unit (PDU). Extension (X)(1): If X is set, the fixed header is followed by exactly one header extension. CSRC count (CC)(4): The field indicates the number of CSRC identifiers that follow the fixed headers. This number is more than one if the payload of the RTP packet contains data from several sources. Marker bit (M)(1): If M is set it indicates some significant events, like frame boundaries, to be marked in the packet stream. For example, an RTP marker bit is set if the packet contains a few bits of the previous frame along with the current frame. Payload type (PT)(7): PT indicates the payload type carried by the RTP packet. RTP Audio Video Profile (AVP) contains a default static mapping of payload type codes to payload formats. Additional payload types can be registered with IANA. Sequence number (16): The number increments by one for each RTP data packet sent, with the initial value set to a random value. The receiver can use the sequence number not only to detect packet loss but also to restore the packet sequence. Time stamp (32): The time stamp reflects the sampling instant of the first octet in the RTP data packet. The sampling instant must be derived from a clock that increments monotonically and linearly in time to allow synchronization and jitter 22

23 Chapter 3. Push-to-talk over Cellular calculations at the receiver. The initial value should be random, to prevent known plain text attacks. For example, if the RTP source is using a codec, which is buffering 20 ms of audio data, the RTP time stamp must be incremented by 160 for every packet irrespective of the fact that the packet is transmitted or dropped as silence. SSRC (32): This field identifies the source that is generating the RTP packets for this session. The identifier is chosen randomly so that no two sources within the same RTP session have the same value. CSRC list: The list identifies the contributing sources for the payload contained in this packet. The maximum number of identifiers is limited to 15, as is apparent from the CC field. If there are more than 15 contributing sources, only the first 15 sources are identified [5]. RTCP RTP receivers provide reception quality feedback using RTCP report packets. The report packets can be of sender type or receiver type. The receiver sends SR (sender reports) if it is actively participating in the session, otherwise it will send RR (receiver reports). RTCP also has three other packet types: SDES, BYE and APP. SDES contain a source description, BYE ends the RTP session and APP defines the application [5] V P RC PT = SR = 200 Length SSRC of Sender NTP (MSB) NTP (LSB) RTP Timestamp Sender s packet count Sender s octet count SSRC_1 Fraction lost Cumulative number of packets lost Extended highest seq number received Inter arrival jitter Last SR Delay since last SR SSRC_2... Figure 4: SR packet [5] 23

24 Chapter 3. Push-to-talk over Cellular Version (V)(2): Same as in RTP. Padding (P)(1): Same as in RTP. Reception report count (RC)(5): Indicates the number of reception report blocks it contains. Packet type (PT)(8): SR report packet has a packet type of 200. Length (16): The length of the packet is given in 32 bit words minus one. SSRC: Same as in RTP. NTP Time stamp (64): NTP indicates the wall clock time when this packet is sent. This information is used to measure round-trip propagation delay. RTP Time stamp: Same as in RTP. These time stamps are used for media synchronization. Sender s packet count (32): This field indicates the number of RTP data packets transmitted by the sender from the starting of the session up until this SR packet has been transmitted. Sender s octet count (32): The total number of payload octets sent from the start of the session. Fraction lost: The fraction of RTP packets lost since the previous SR or RR packet is sent. Cumulative number of packets lost (24): The total number of RTP data packets lost from the beginning of the session. Extended highest sequence number received (32): The low 16 bits contain the highest sequence number received in an RTP data packet and the high 16 bits extend that sequence number with the corresponding number of sequence number cycles. Inter-arrival jitter (32): An estimation of the statistical variance of the RTP data packet arrival time measured in time stamp units and expressed as an unsigned integer. Last SR timestamp (32): Contains the middle 32 bits of 64 bits in the NTP time stamp received as part of the most recent RTCP SR packet. Delay since last SR (DLSR) (32): The delay expressed in units of 1 in seconds, between the last SR packet and this RR packet. The RR packet structure is same as that of SR, except that it will not contain the sender related fields (NTP, RTP time stamps, packet and octet count) XML - Extensible Mark-up Language XML is a mark-up language for documents containing structured information. Structured information contains both content (words, pictures, etc.) and some indication of what role that content plays (for example, content in a section heading has a different meaning from content in a footnote). Almost all documents have some structure. A mark-up language is a mechanism to identify structures in a document. The XML specification defines a standard way to add mark-up to documents [6]. 24

25 Chapter 3. Push-to-talk over Cellular XCAP XML Configuration Access Protocol XCAP allows a client to read, write and modify application configuration data, stored in XML format on a server. XCAP maps XML document sub-trees and element attributes to HTTP URIs, so that these components can be directly accessed by HTTP Architecture The PoC architecture is constructed by several small entities, each entity handling a different part of the system. The architecture consists of the following central entities: PoC Client Gives the user access to the PoC service. PoC Server Contains the PoC service. SIP/IP Core Handles sessions, SIP routing, authentication and authorization. GLMS Stores and manages groups and lists. Presence Server Manages presence information. The PoC architecture entities, and the interfaces between them, are shown in Figure 5. They are also described in detail further down in the report. 25

26 Chapter 3. Push-to-talk over Cellular Im GLMS Management/Administration Ie Igs GLMS Ipl PoC Client ACCESS NETWORK Is It SIP / IP Core If Ik Ips PoC Server Presence Server Itn Remote PoC Network In Figure 5: The PoC architecture Entities PoC Client The PoC Client resides on the mobile terminal. It gives the user access to PoC services. The main purpose for the PoC Client is to send and receive messages via the PoC Server. It uses three different interfaces (Im, Is and It) to communicate with the PoC infrastructure. The Im interface is used for list and group management, the Is interface for session and presence handling and the It interface for media transmissions. The PoC Client performs the following functions: PoC session initiation, participation and termination. Generate talk bursts for transmission and reproduce received talk bursts. Registration and authentication with the PoC Infrastructure. Provide access to PoC group lists. 26

27 Chapter 3. Push-to-talk over Cellular Support floor control procedures. Provide access to PoC subscriber for managing PoC group lists. Provide access to presence conditions of the PoC subscriber PoC Server The PoC Server contains the PoC service. The main goal for the PoC Server is to handle sessions and to distribute media from one user to all other users in the talk session. The PoC Server also handles the following functions: Access control Do Not Disturb Floor control Talker identification Participants information Quality feedback Charging reports GLMS Group List Management Server The GLMS is used for storage and management of the groups and lists that are needed for the PoC service. It handles the creation, modification, retrieval and deletion of groups and lists. There are three types of lists: Contact lists stores contact entities in the GLMS. Group lists defines PoC groups. Access lists defines who s allowed to reach a specific user. A contact list is a kind of address book that may be used by PoC users to establish an instant talk session with other PoC users or PoC Groups. A user may have one or several contact lists, containing identities of other PoC users or PoC Groups. A group list is a list of user defined PoC groups. The end user may select one group from the list to initiate an instant group talk session or a chat group talk session depending on the type of the group. 27

28 Chapter 3. Push-to-talk over Cellular An access list is used by the end user as means of controlling who is allowed to initiate instant talk sessions to the end user. An access list contains end user defined identities of other PoC end users or groups. The end user may have one reject list and one accept list Presence Server The Presence Server manages presence information. It is responsible for combining the presence-related information for a certain user from the information it receives from multiple sources into a single presence document. The presence server handles the publication, watching and fetching of Presence Information, it also handles the authorization for watching and fetching. The authorization is done based on authorization rules stored in the Presence Server. A user can have one of the following statuses: Reachable Do Not Disturb Busy Unavailable Offline SIP/IP Core The SIP/IP Core is the first point of contact for the PoC client. It is based on IMS and includes a number of SIP proxies and SIP registrars. The PoC client sends all of its SIP messages to the IP address of the outbound proxy, after resolving the SIP URI of the outbound proxy to an IP address. The SIP/IP Core handles all routing of SIP signaling between the PoC Client and the PoC Server. The SIP/IP Core also performs the following functions that are needed in support of the PoC Service: Discovery and address resolution SIP compression Authentication and authorization of PoC Clients Maintains the registration state Charging information 28

29 Chapter 3. Push-to-talk over Cellular 3.4. Interfaces The entities in the system communicate through a series of interfaces. Most of the interfaces use well-known protocols like SIP and RTP. There are however interfaces that have not been specified yet Is interface The Is interface supports the communication between the PoC Client and the SIP/IP Core. The protocol for the Is interface is SIP (Session Initiation Protocol), transported with UDP. The Is interface supports: Session signaling between the PoC client and the PoC server Discovery and address resolution Authentication and authorization Registration Publishing of presence information Subscribing to presence information Receiving of presence notifications Subscription to modification by the GLMS of lists. Notification of modification by the GLMS of lists It interface The It interface is used for transporting media, floor control and link quality messages between the PoC Client and the PoC Server. It uses RTP and RTCP Itn interface The Itn interface supports the communication between the PoC servers. It supports media transport and floor control procedures. It uses RTP and RTCP Im interface The Im interface is used for the communication between the PoC Client and the GLMS for the purpose of managing the groups, contact lists and access lists. The Im interface uses the XCAP protocol and gives the PoC Client the capability to create, modify, retrieve and delete groups and lists 29

30 Chapter 3. Push-to-talk over Cellular In interface The In interface supports the communication and forwarding of SIP signaling messaging between SIP/IP Cores. The interface is based on SIP Ik interface The Ik interface supports the communication between the PoC Server and the GLMS. It enables the PoC Server to retrieve the groups and access lists from the GLMS. It is not yet specified which protocol it will use If interface The If interface supports the communication between the SIP/IP Core and the PoC Server for session control. The If interface is based on SIP. It supports session signaling, address resolution, charging information and publication, subscription and notification of Presence Information by the Presence Server to the PoC Server Ipl interface The Ipl interface supports the communication between the GLMS and the Presence Server. It enables transference of presence lists, group lists and subscription authorization policies to the Presence Server. It is not yet specified which protocol it will use Ips interface The Ips interface supports the communication between the SIP/IP Core and the Presence Server. It enables uploading of the registration status from the SIP/IP Core to the Presence Server and the distribution of the presence information between the presence server and the PoC Client. Ips is based on SIP Igs interface The Igs interface supports the communication between the GLMS and the SIP/IP Core. It handles subscription and notification of the modification of lists. It is not yet specified which protocol it will use Ie interface The Ie interface is between the GLMS and GLMS Management/Administration entity. This entity can act on behalf of end users and administrators subject to service providers access control policies. Access may be provided via the intranet, internet or corporate networks. The Ie interface provides the capability to create, modify, retrieve and delete groups and lists. It is not yet specified which protocol it will use, but it will most likely be XCAP. 30

31 Chapter 3. Push-to-talk over Cellular 3.5. Identification and Usage Each user shall be assigned a public user identity and a private user identity. The public identifier is in the form of a SIP URI and consists of a user and a host part. The user part uniquely identifies the user while the host part identifies a domain owned by the operator. A SIP URI should look something like this user@operator.com. The private URI has a similar purpose but it is hidden from other users and can not be used for addressing. It shall take the form of a NAI and has the form username@realm. Each group has a group identifier, it is associated with the individual identifiers of all group members. The group identifier is generated by the GLMS and has the form of a SIP URI. The PoC Clients uses the group identifier to address the group, the PoC server then distributes the message to all members of the group. A user can also be addressed by a phone number, TEL URI. The PoC Client sends the TEL URI to the SIP/IP Core that resolves it to a SIP URI. This is done by using a DNS/ENUM or other local database. The PoC Client must register itself with the SIP/IP Core before using the PoC Service. This gives the SIP/IP Core the opportunity to bind the current IP address and port to the public user identity. Once it is registered it can invite, or be invited by, other users to talk sessions. A Talk session can be with one person or a group of persons. The groups can be either predefined or ad-hoc. The talk session will use the media capability of the user with the lowest bandwidth. The establishment phase of the talk session is different depending on how the following alternatives are combined. Early Session Early Media Procedure Late Media Procedure Auto Answer Manuel Answer Both parties have an early session established. The inviter can begin to talk before someone accepts. The inviter has to wait until someone accepts. Calls are automatically accepted. Calls have to be manually accepted. Once the talk session has been initialized the inviter is given the floor, the right to talk, and can send his message to the others. When he is finished he releases the PTT-button and the floor becomes idle so that anyone can take it and send their message to the group. Example (Instant personal talk scenario) This example describes an instant personal talk end-to-end session combining early media establishment with auto answering. The signaling flow in Figure 6 is built on the following scenario: The user at Client 1: 1. Presses the PTT-button. 2. Receives a beeping signal when a media channel is established. 31

32 Chapter 3. Push-to-talk over Cellular 3. The user starts to talk. 4. Releases the PTT-button. 5. Receives a beeping sound that the floor is taken by the other user. 6. Receives speech from the other user. 7. Receives a beeping sound when the floor is idle again. The user at Client 2 (configured for auto answer): 1. Receives a beeping sound in the loud speaker. 2. Listens to the user at Client 1 speech phrase. 3. Receives a beeping sound that the floor is idle. 4. Presses the PTT-button. 5. Receives a beeping sound that that the user can start to speak. 6. The user talks. 7. The user releases the PTT-button. Client 1 SIP/IP Core PoC Server SIP/IP Core Client 2 Figure 6: Instant personal talk signaling flow [3]. 32

33 Chapter 3. Push-to-talk over Cellular 3.6. PoC applicability to PDC The PPDC system enables data transmissions in the PDC system. It utilizes a packet switch system allowing a data transfer rate of 28.8 kbps in downlink and 9.6 kbps in uplink. The Mobile System (MS) is dynamically assigned an IP address that is retained until it deregisters. The MS can connect to an Application Server (AS), which can contain IP-based services from both local and external sources like the Internet. The packet data switching functionality between MSs and ASs is handled by the Packet Mobile services Switching Center (PMSC). It routes and forwards IP packets and provides mobility management functions that allow MSs to keep their communication links while moving. The PoC specification defines a half-duplex Voice over IP solution over standard mobile networks. The Core of the PoC network is IMS (IP Multimedia Subsystem), a standardized architecture for peer-to-peer communication over IP. It uses SIP to handle talk sessions and RTP to transfer the audio. SIP can run on top of several different transport protocols, UDP being one of them. It uses Signal Compression (SigComp) to compress messages to a fraction of their original size. RTP is designed to be independent of the underlying transport and network layers. It typically runs on top of UDP to make use of its multiplexing and checksum services. The audio is encoded by using the AMR (Adaptive Multi Rate) codec, which allows it to encode the audio at different frequencies depending on the bandwidth available. Since the PoC specification can be implemented on any IP network and that the PPDC network is an IP network it is concluded that PoC is completely applicable to the PDC network. The PoC client will run on a MS, a PPDC enabled mobile phone. It will receive an IP-address from the PMSC, enabling it to communicate with an AS where the PoC server, SIP core, Presence server and GLMS is running. The AS is also connected to the Internet making it possible to connect a PDC PoC client with a PoC client on another IP-network. The AS uses an ordinary UNIX platform, so it is not a problem running applications on it. The only possible problem is the low bandwidth of the uplink, 9.6 kbps, which might result in a low sound quality. 33

34 34

35 4. Implementation of a PoC prototype To test the applicability of the PoC specification to the PDC network a prototype was implemented. Due to the size of the PoC specification only the most central parts of the system was implemented. A user guide to the implemented prototype can be found in Appendix B Hardware and software The prototype was implemented in Java (J2SE 1.4.2) under Windows 2000 and Redhat 8.0. It uses two additional packages, JMF [14] (Java Media Framework 2.1.1e) and JAIN SIP[9]. JMF enables audio, video and other time-based media to be added to applications and applets built on Java technology. It can capture, play, stream, and transcode multiple media formats. JAIN SIP is a SIP API that supplies the tools for SIP communication. Java was selected because it was required that the client would be implemented in Java, to ease portability, and that there are programming synergises if all components are implemented in the same programming language. The code was mainly written using the text editor jedit, with the exception of the initial GUI that was written in Borland JBuilder 4 Professional. The prototype was tested on three PCs with Windows XP. This test was mainly performed so that the SIP Core and the PoC Server application could be executed on one machine and two separate PoC clients on separate machines. There is also a PDC test lab at TietoEnator where it was originally planed to test the prototype, this was later cut due to new safety procedures and time deficiency. It is however not a problem that the prototype was not tested in the PDC network. The difference for the prototype would have been the platform, the platform used in the PDC lab is UNIX. Since Java is platform independent this would not have been any problem. There are of course other differences, like the network, but they would not affect the prototype Limitations Because of the size of the PoC specification, and the lack of information in it, some parts where dropped. The GLMS and the network-to-network communication were dropped in an early stage. The reason for this was that they had the least effect on the system and that XML and XCAP could be dropped. It was also decided that a codec that already exists in JMF would be used instead of AMR, which is specified in the PoC standard, and that no compression would be used. These changes will result in a higher bandwidth usage. Both the early session and early media procedure were also dropped. Later on the Presence 35

36 Chapter 4. Implementation of a PoC prototype server was also dropped, which means that it will not be possible to distinguish the presence status of the other users Design and implementation Three separate applications will be implemented in the prototype, the PoC Client, the SIP/IP Core and the PoC Server, shown in Figure 7. Since all of them communicate with one or more of the parts that are not implemented in the prototype it will diverge from the PoC specification as follows: There will be no presence information shown, the status of the other users will always be display as online. The contact list will only exist on the client, due to the absence of the GLMS. The PoC server will contain static group lists instead of receiving them from the GLMS. This means that the clients can not contact users in a new group using the group s address. The sound will use the GSM audio format instead of AMR. Only the late media procedure will be used. There will be no accept list or reject list, everyone will be treated as if they are in the accept list. PoC client SIP / IP Core (IMS) Is (SIP) If (SIP) It (RTP) PoC Server Figure 7: Implemented parts of the PoC architecture. 36