Push-to-talk over cellular

From Hill2dot0
(Redirected from PoC)
Jump to: navigation, search

Push-to-talk systems, or just plain walkie-talkie service, has been a part of radio for a very long time. The concept is that with an always-on connection you can immediately contact another user. What is interesting, however, is that the original push-to-talk systems actually had one radio talking directly with another, which results in significant distance limitations due to problems associated with fade. To expand the service area, Motorola created a wired backbone infrastructure to provide the always-on connectivity. The digital version is known as the integrated digital enhanced network (iDEN) with the name being drawn from its use in dispatch radio systems (e.g., taxi and truck dispatch systems). Today, Sprint/Nextel offers the top-of-the-line push-to-talk service, and the cellular providers are scrambling to create a competitive service.

Push-to-talk over cellular (PoC) makes two-way radio service available over the traditional cellular network. PoC provides one-to-one and one-to-many voice communication services to cellular handsets equipped with the push-to-talk option. The PoC solution is based on half-duplex voice over IP technology found in 2.5/3G cellular networks. The PoC solution is part of the IMS communications portfolio and is viewed as part of the overall set of services that will be offered as part of the IMS core.

PoC Architecture

PoC Architecture

Ericsson, Siemens, Motorola, and Nokia along with the Open Mobile Alliance (OMA) have been instrumental in the development of the PoC technical specifications. The current architecture specification is release 2 version 2.0.8. Note that the darker shaded items are defined in the PoC architecture and that the dotted reference points are outside the scope of the current PoC specifications.

Several of the PoC architectural elements are drawn from IMS—the access network, UE, IMS core, and presence server. The group and list management server, the PoC server, and the Im, Is, In, It, If, Ips, and Itn reference points are defined in the PoC technical specifications being created by OMA.

PoC Functional Entities

User equipment, the IMS core, and the presence server function in the PoC architecture as they do in the IMS. In the IMS, presence and PoC are two services offered to the UE.

The group list and management function (GLMF) manages the groups, contact lists, and access lists that are stored on the group list and management server (GLMS) on behalf of the PoC user. PoC groups are defined by the user. The user selects one group from his/her list of groups to start an instant group talk or a group chat session depending on the nature of the group.

The contact list is the user’s address book; it is used to establish instant talk sessions with other PoC users or a PoC group and to access presence information. A user can have one or many contact lists. The contact list management software allows users to store, modify, retrieve, and delete contact lists located on the GLMS.

The user sets up access lists, which determine which other PoC users can talk with this user or get presence information about this user. The access list might contain identities of other PoC users or groups. The user is allowed to have a blocked identities list and a granted identities list.

The PoC server can operate as a controlling PoC function, a participating PoC function, or both at the same time. The choice of function happens at session establishment time. As a general rule of thumb, the inviting user of a one-on-one ad hoc session performs the controlling function and the user that sets up a pre-arranged group session performs the controlling function. Regardless of who is the controlling user, every participant needs the participating PoC function, which is why the PoC server must be able to function as both controlling and participating. It is quite possible in some situations that the controlling function is in network A, user 1/participating function 1 is in network A, and user 2/participating function 2 is in network B. Since this multi-network structure is easily handled in the IMS there is no trouble getting communication between the servers.

The over-the-air provisioning server (OTAP) provides all of the needed configuration parameters from the service provider network for the PoC client. OTAP sends default factory and network settings via a WAP-push/SMS to all client UEs. The settings are coded in XML.

PoC Reference Points

Below we discuss the protocol information for the PoC reference points, or interfaces, and any unique operational characteristics of the interfaces.

  • Is: UE – IMS core interface using SIP procedures over either UDP or TCP
  • If: IMS core – PoC server interface using SIP procedures
  • It: UE – PoC server interface using RTP and RTCP to support media transport, link quality procedures, and floor control procedures (floor control is a mediated function that determines who the current speaker is, in other words, who has the floor)
  • Im: UE – GLMS interface using HTTP/XML to support UE/GLMS communications for the management of groups, contact lists, and access list that may be stored on the GLMS; also managed are the auto answer mode and the do not disturb mode; the GLMS might be distributed over several physical servers, which allows for storage of different types of lists on different servers
  • Ik: PoC server – GLMS interface for list access by the PoC (not in Release 2)
  • Ips: IMS core – Presence server interface using SIP procedures to allow the publishing, subscription, and dissemination of presence information between the server and the UE.
  • Ipl: Presence server – GLMS interface for list access by the presence server (not in Release 2)
  • Itn: PoC server – PoC server interface uses RTP and RTCP to communicate between PoC servers in the same network or in another network; information exchanged includes media transport, floor control procedures, and link quality procedures
  • In: IMS core – IMS core interface using SIP procedures for the CSCF-CSCF communications between IMS cores
  • Io: PoC client – OTAP server interface is a general XML-based framework provided by the open mobile alliance (OMA) for the exchange of client configuration data

Also worthy of note is the fact that IPv4 is mandatory on all PoC interfaces. However, IPv6 is optional on the Itn and In interfaces.

PoC System Concepts

In the PoC terminology, each PoC user is assigned an address of record in the form of a SIP URI. In the IMS terminology this is the public user identity. A typical SIP URI for PoC service would be sip:jane.doe@poc.operator.net. A user may also have a tel URL for an address as long as it conforms to the E.164 numbering standard. Other identities are the private user identity (network access identifier format), group identities (SIP URI format), and contact list identities (SIP URI format).

The PoC specification states that the PoC user must register with the IMS core before using the PoC service. This process binds the UE public identity and the UE IP address and port with the IMS core. Sessions are established via the SIP INVITE command with a media feature tag for the PoC service in the accept-contact header. Early session establishment is used for having a session available for quick establishment using the REFER request.

Floor control is, as the name implies, a mediated function that determines who the current speaker is (i.e., who has the floor). There are several actions under the umbrella of floor control.

  • Floor request: User asks permission to talk
  • Floor release: User releases permission to talk
  • Floor grant: User is given the floor (permission to speak is granted)
  • Floor idle indication: Network informs uses that the floor is not in use
  • Floor deny: User’s permission to talk has been denied
  • Floor taken: Network tells users that floor is in use
  • Floor revoke: Network removes permission to talk from a user
  • Talk burst quality feedback: Amount of media received by PoC server or UE
  • RTCP BYE: Terminate media session but leave SIP session in place

All floor control functions are arbitrated by RTCP and talker identifications are distributed by RTCP.

Several charging models, or all or none, can be used by the PoC service provider. These include flat-rate (self-explanatory), session-based (time in the session), granted talking time (time user actually talked), talk burst size (a measure of bandwidth used based on the information transferred), and number of talk bursts (number of actual messages transmitted, which is like granted talking time except that the talking itself may be several talk bursts). All of these work fairly well in the IMS except for the talk burst related entities, as this information is not always reliably or accurately reported to the charging collection function (CCF). Inter-operator charging is not specified in Release 2.

PoC High Level Procedures

Several talk models are used in the PoC service; instant person talk, ad-hoc instant group talk, instant group talk, chat group talk, and instant personal alert. Some of these can be used with the early session dialog establishment often referred to as a preestablished session.

Instant personal talk is a one-to-one PoC session in which Dave establishes a PoC session with Paul using the early session procedure and the SIP REFER request or the SIP INVITE request. In the early session procedure, Dave and Paul have both established early sessions with their respective PoC servers. When Dave wants to talk to Paul, he pushes the button, and a SIP REFER is sent to his PoC server, which sends an INVITE to Paul’s PoC server. Since Paul has early establishment and auto answer mode set, the session is ready and Dave is granted the floor. The media flows from Dave to Paul and Paul’s PoC server sends the acknowledgment of successful delivery to Dave’s PoC server, and the session is done. If Paul does not have early session establishment in place then his device must be alerted and answered before Dave can be given the floor.

Instant personal talk establishment on demand is basically the same, except that instead of the quick REFER request, the process begins with the SIP INVITE request to the PoC server. The invite process goes from Dave’s PoC server to Paul’s PoC server to Paul’s UE at the other end. At each point there needs to be processing of the session establishment procedures. After the session is established for a while, Dave sends a BYE message and the PoC session ends. There are numerous scenarios that could be played out using early session establishment at one or both ends, auto answer mode being on or off, and the do not disturb mode being on or off.

The ad hoc instant group talk is the same as the personal talk. It can be used in either the early session establishment mode or the establishment on-demand mode. The basic difference is that the controlling PoC server gets a list of PoC users to invite.

The instant group talk is similar to the ad-hoc instant group talk except that the unique identifier for this group has already been assigned. In chat group talk a user joins an existing chat group (i.e., one that already has a unique identity assigned).

The last procedure is the instant personal alert where Dave sends an alert to Paul asking him to establish an instant personal talk with Dave. This procedure is very similar to a call back service in traditional telephony.