1565 MotDoc

Architecture V2.0.
8 (2004-06)
Technical Specification
Push-to-talk over Cellular (PoC);

Architecture;
PoC Release 2.0
Comneon, Ericsson, Motorola, Nokia, Siemens

2 Architecture V2.0.8 (2004-06)
Keywords
Push-to-talk over Cellular (PoC), Architecture
Copyright Notification
No part may be reproduced except as authorized by written permission of the contributing companies.
© Comneon.Ericsson, Motorola, Nokia, Siemens

All rights reserved.
PoC Architecture
Contents
Foreword ............................................................................................................................................................5
Introduction ........................................................................................................................................................5
1 Scope ........................................................................................................................................................6
2 References ................................................................................................................................................6
3 Definitions and abbreviations...................................................................................................................7
3.1 Definitions ......................................................................................................................................................... 7
3.2 Abbreviations..................................................................................................................................................... 9
3.3 Requirement vocabulary .................................................................................................................................. 10
4 Architecture............................................................................................................................................11
5 Description of functional entities ...........................................................................................................12
5.1 User Equipment (UE) ...................................................................................................................................... 12
5.2 IMS Core ......................................................................................................................................................... 12
5.3 Group and List Management Function (GLMF).............................................................................................. 12
5.4 PoC Server ....................................................................................................................................................... 13
5.4.1 Controlling PoC Function ......................................................................................................................... 15
5.4.2 Participating PoC Function ........................................................................................................................ 15
5.5 Presence Server................................................................................................................................................ 16
5.6 Over The Air Provisioning (OTAP) Server ..................................................................................................... 16
6 Description of the interfaces ..................................................................................................................16
6.1 Interface Is: UE – IMS Core ............................................................................................................................ 16
6.2 Interface If: IMS Core – PoC Server ............................................................................................................... 17
6.3 Interface It: UE – PoC Server .......................................................................................................................... 17
6.4 Interface Im: UE – GLMS ............................................................................................................................... 17
6.5 Interface Ik: PoC Server – GLMS ................................................................................................................... 17
6.6 Interface Ips: IMS core – Presence Server....................................................................................................... 17
6.7 Interface Ipl: Presence Server – GLMS ........................................................................................................... 17
6.8 Interface Itn: PoC Server – PoC Server .............................................................................................................. 18
6.9 Interface In: IMS Core – IMS Core .................................................................................................................... 18
6.10 Interface Io: POC CLIENT – OTAP SERVER .............................................................................................. 18
7 System concepts .....................................................................................................................................18
7.1 Identification.................................................................................................................................................... 18
7.1.1 Address of record (a.k.a. public user identity) ........................................................................................... 18
7.1.2 Private user identity.................................................................................................................................... 19
7.1.3 Group identities.......................................................................................................................................... 19
7.1.4 Contact list identities.................................................................................................................................. 19
7.2 Addressing ....................................................................................................................................................... 19
7.2.1 IP addresses................................................................................................................................................ 19
7.2.2 Phone numbers – TEL URL....................................................................................................................... 19
7.2.3 SIP URI ...................................................................................................................................................... 20
7.3 Routing principles............................................................................................................................................ 20
7.3.1 Registration ................................................................................................................................................ 20
7.3.2 Session establishment................................................................................................................................. 20
7.3.3 User location .............................................................................................................................................. 20
7.4 Security ............................................................................................................................................................ 20
7.4.1 Threats........................................................................................................................................................ 20
7.4.2 Countermeasures ........................................................................................................................................ 21
7.4.3 Network Security ....................................................................................................................................... 21
7.5 Floor control .................................................................................................................................................... 22
7.6 Codecs ............................................................................................................................................................. 22
7.7 Signaling compression..................................................................................................................................... 22
7.8 User plane adaptation....................................................................................................................................... 23
7.9 Charging .......................................................................................................................................................... 23
PoC Architecture
7.9.1 Charging Models and Mechanisms............................................................................................................ 23

7.9.2 Inter-Operator Charging.............................................................................................................................. 23
7.10 Roaming........................................................................................................................................................... 24
7.11 Presence ........................................................................................................................................................... 24
7.11.1 Resource List Function............................................................................................................................ 24
7.11.2 Presence States ........................................................................................................................................ 25
7.11.3 Watcher Authorization - Access List Management................................................................................. 25
7.12 Do-not-Disturb................................................................................................................................................. 25
8 High level procedures.............................................................................................................................25
8.1 PDP Contexts................................................................................................................................................... 25
8.2 DNS name server discovery............................................................................................................................. 26
8.3 DNS procedures............................................................................................................................................... 26
8.3.1 SIP URI resolution ..................................................................................................................................... 26
8.3.2 HTTP URL resolution................................................................................................................................ 26
8.4 Early Session dialog establishment (Pre-established Session)......................................................................... 26
8.5 Instant Personal Talk (1-1 PoC Session).......................................................................................................... 27
8.5.1 Instant Personal Talk establishment with early session.............................................................................. 27
8.5.2 Instant Personal Talk establishment on-demand ........................................................................................ 30
8.6 Ad-hoc Instant Group Talk .............................................................................................................................. 33
8.7 Instant Group Talk ........................................................................................................................................... 33
8.8 Chat Group Talk .............................................................................................................................................. 35
8.9 Instant Personal Alert....................................................................................................................................... 36
9 High level procedures for presence .......................................................................................................37
Annex A (informative): Known 3GPP/OMA divergence ................................................................................39
A.1 General divergences....................................................................................................................................... 39
A.2 Specific Divergences ..................................................................................................................................... 40
Annex B: E.164 Number Translation (Informative)........................................................................................40
B.1 Addressing Using SIP URI .............................................................................................................................. 41
B.2 Addressing Using Tel URL ............................................................................................................................. 41
B.2.1 Alternative 1: DNS/ENUM Translation..................................................................................................... 41
B.2.2 Alternative 2: DNS/E.164 Translator......................................................................................................... 43
Annex C: IP addressing considerations (Informative)......................................................................................46
Annex D: Change History (Informative).........................................................................................................49
PoC Architecture
Foreword
This Technical Specification has been produced by Ericsson, Siemens, Motorola and Nokia for PoC Release 2.0.
Introduction
This technical specification describes an architecture that fulfils the user requirements described in reference [1].
The basic architecture is described in clause 4.
The functional entities of the architecture are described in clause 5.
The interfaces of the architecture are described in clause 6.
General system concepts, that have architectural implications, are described in clause7.
An overview of the high level procedures, for informational purposes, is described in clause 8.
High level procedures for presence are described in clause 9.
Annex A lists recognized 3GPP/OMA divergences.
Informative Annex B presents options for E.164 number translation.
IP addressing considerations are in Informative Annex C .
Annex D provides the change history of this document.
PoC Architecture
1 Scope
This document describes the functional entities, interfaces, system concepts and high-level procedures of the Push-to-
Talk over Cellular (PoC) service.
The PoC service is characterized by a half duplex form of communication whereby one user will communicate with
other users by pressing a button (or by performing equivalent action) on a PoC enabled User Equipment (UE).
This specification has been updated using following assumption:
• The Release 2.0 architecture will allow for backwards compatibility to Release 1.0.
2 References
The following documents contain provisions, which through reference in this text constitute provisions of the
present document.
• References are either specific (identified by date of publication, edition number, version number, etc.) or
non-specific.
• For a specific reference, subsequent revisions do not apply.
• For a non-specific reference, the latest version applies. In the case of a reference to a PoC document, a
non-specific reference implicitly refers to the latest version of that document in the same Release as the
present document.
[1] Push-to-Talk over Cellular User Requirements; PoC Release 2.0
[2] PoC Signaling Flows - UNI; PoC Release 2.0
[3] PoC User Plane; Transport Protocols; PoC Release 2.0
[4] PoC User Plane; (E)GPRS Specification; PoC Release 2.0
[5] PoC List Management and Do-Not-Disturb; PoC Release 2.0
[6] PoC Signaling Flows – NNI; PoC Release 2.0
[7] PoC Presence; PoC Release 2.0
[8] 3GPP TS 24.008 “Mobile radio interface Layer 3 specification; Core network protocols; Stage 3”
[9] IETF RFC 1332 “The PPP Internet Protocol Control Protocol (IPCP)”
[10] IETF RFC 1877 “PPP Internet Protocol Control Protocol Extensions for Name Server Addresses”
[11] IETF RFC 1889 “RTP: A Transport Protocol for Real-Time Applications”
[12] IETF RFC 2616: "Hypertext Transfer Protocol HTTP/1.1"
[13] IETF RFC 3261: "SIP: Session Initiation Protocol"
[14] IETF RFC 3263: "Session Initiation Protocol (SIP): Locating SIP Servers"
[15] IETF RFC 3320: “Signaling Compression (SigComp)”
[16] IETF RFC 3321: “Signaling Compression (SigComp) - Extended Operations”
[17] IETF RFC 3485: “The Session Initiation Protocol (SIP) and Session Description Protocol (SDP)
Static Dictionary for Signaling Compression (SigComp)”
[18] IETF RFC 3486: “Compressing the Session Initiation Protocol (SIP)”
PoC Architecture
[19] IETF < draft-ietf-sip-callerprefs-10.txt> (expire April 21, 2004): “Caller Preferences for the
Session Initiation Protocol (SIP)”
[20] Void
[21] ITU-T Recommendation E.164: “The international public telecommunication numbering plan”
[22] IETF RFC 2486: “The Network Access identifier”.
[23] IETF RFC 2806 “URLs for Telephone Calls”
[24] Void
[25] 3GPP TS 22.141: "Presence service; Stage 1".
[26] 3GPP TS 23.141: “Presence Service; Architecture and Functional Description”
[27] Common Presence and Instant Messaging (CPIM) Presence Information Data Format, Internet
Draft http://www.ietf.org/internet-drafts/draft-ietf-impp-cpim-pidf-08.txt, May 2003
[28] Session Initiation Protocol (SIP) Extensions for Presence, Internet-Draft

http://www.ietf.org/internet-drafts/draft-ietf-simple-presence-10.txt, July 2003
[29] A SIP Event Package for List Presence, Internet-Draft, http://search.ietf.org/internet-drafts/draft-

ietf-simple-event-list-04.txt, June 2003
[30] 3GPP TS 33.900 Guide to 3G security
[31] 3GPP TS 33.210 3G security; Network Domain Security (NDS); IP network layer security
[32] 3GPP TS 23.228 IP Multimedia Subsystem (IMS); Stage 2; Release 5
[33] 3GPP TS 24.229 Internet Protocol (IP) multimedia call control protocol based on Session
Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3, Release 5
[34] 3GPP TR 24.841 “Presence service based on Session Initiation Protocol (SIP); Functional models,
information flows and protocol details”
[35] Analysis on IPv6 Transition in 3GPP Networks, Internet Draft, http://www.ietf.org/internet-

drafts/draft-ietf-v6ops-3gpp-analysis-08.txt, January 2004
[36] OMA – Enabler Release Definition for Client Provisioning V1.1
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the PoC specifications, the following terms and definitions apply.
Access control: Each PoC user can define rules that describe who is allowed to contact him/her using the PoC service.
The PoC Server implements the access control policy according to these defined rules.
Access list: Each PoC user has two access lists: a user accept list and user reject list. Access lists are used for
controlling whether the PoC server is allowed or not to send talk session requests to the user when requested by other
user.
Ad-hoc instant group talk: A feature providing a user to ad-hoc establishes a PoC session with other PoC users.
Administrative domain: A collection of hosts and routers, and the interconnecting network(s), managed by a single
administrative authority.
Chat group: A persistent group created for chat group talk. Each group member joins the talk session individually.
PoC Architecture
Chat group talk: A feature providing users with the capability to join a pre-defined chat group. The chat group may be
open or restricted.
Chat talk session: A talk session established by a chat group talk.
Contact list: A list available to the end user containing the addresses of other users or groups.
Contact: A contact is an identity of a user, or a group. A contact includes the SIP URI or a TEL URI of the entity, type
of the entity (user or group) and optionally the display name.
Floor control: A control mechanism that arbitrates requests, from the UEs, for the right to speak.
Group Talk: An instant group talk, ad-hoc instant group talk or chat group talk.
Group: Group is predefined set of users together with its attributes. The group is used for easy session establishment
and/or for defining session access policy. Each group is identified by its SIP URI.
Home PoC Network : PoC network of the served PoC user
Instant group: A persistent group created for instant group talk. The users PoC server invites all the other group
members to a talk session.
Instant group talk: A feature providing a user to establish a PoC session with other members in a pre-defined instant
group. The instant group is always a restricted group.
Instant personal Alert: A feature providing a user with the capability to send a callback request to another user.
Instant personal talk: A feature to establish a PoC session with another user.
Instant talk session: A talk session established by instant personal talk, ad-hoc group talk or instant group talk.
Invited user: This is the PoC user who has been invited to a talk session.
Inviting user: This is the PoC user inviting other PoC user(s) to the to a talk session.
maxptime: The maximum amount of media which can be encapsulated in a RTP payload packet, expressed as time in
milliseconds. The time is calculated as the sum of the time the media present in the packet represents. The time should
be a multiple of the frame size. In PoC the allowed values are N*20; where N>0 and N<21.
media capabilities list: In this list, the PoC Server shall store the downlink media capabilities of all UEs that are active
in sessions served by the PoC Server.
media capabilities: A set of parameters that should describe the performance of the PoC user equipment (UE), the
speech coder used and the performance of the radio bearer that carries the PoC service (the quality of service parameters
agreed upon etc).
media parameters: The PoC Server uses the media capabilities list to determine the settings the user equipments
should use in the talk session. The information transmitted from the PoC Server to the UE in order to alter the settings
of the UE, is in this document referred to as media parameters. Media parameters are transmitted by SIP/SDP messages.
mode-set: Restricts the active codec mode set to a subset of all modes. Possible values are a comma separated list of
modes from the set: 0,...,7. If the decoder specifies such mode set, the encoder MUST abide by the request and MUST
NOT use modes outside of the subset. If not present, all codec modes are allowed for the session.
Open group: A group that can be joined by any user.
Participant: A PoC user in talk session.
Presence list: A contact list of type user that a watcher is using to subscribe for presence information of users on the
list.
Presentity : A PoC client that provides PoC presence information.
PoC Access list: Each PoC user has two access lists: a user accept list and user reject list. Access lists are used for
controlling whether the PoC server is allowed or not to send talk session requests, PoC alert and PoC presence
information to the user when requested by another user.
PoC Architecture
ptime: Number of frames per RTP-packet the UE needs to be able to receive the media stream on its downlink. Ptime is
given as the length of time in milliseconds represented by the media that needs to be in a RTP packet.
Remote PoC Network : The Remote PoC network is the network that supports one or more Remote PoC Clients.
Restricted group: A group that can be joined only by predefined user(s).
Session: A session is considered as an exchange of data between associations of participants.
Talk session: This is an established connection between PoC users where the users can communicate one at a time in a
half duplex manner.
talk spurt: A part of the speech signal that starts with a speech onset and ends when the speech coder goes down in
DTX-mode. Hence a talk burst can consists of several talk spurts.
Talk-burst: The media recording, transport and playback that occur from when the user has the floor.
User: A human using the described features through a terminal device.
User accept list: User accept list is a list of items each identified by its SIP URI.
User equipment: User equipment is a hardware device (e.g. phone) with Push-to-Talk software used by users.
User reject list: User reject list is a list of items each identified by its SIP URI.
Watcher: A PoC client that requests presence information for other PoC client.
3.2 Abbreviations
For the purposes of the PoC specifications, the following abbreviations apply:
AMR Adaptive Multi Rate

APP Application-defined RTCP packet
BYE Goodbye RTCP packet
CSRC Contributing Source
DL DownLink
DNS Domain Name System
DTD Document Type Definition
ENUM E.164 Number Mapping
FQDN Fully Qualified Domain Name
FFS For Further Study
GERAN GSM/EDGE Radio Access Network
GGSN Gateway GPRS Support Node
GLMF Group and List Management Function
GLMS Group and List Management Server
HTTP Hypertext Transfer Protocol
ICID IMS Charging Identifier
IMS IP multimedia subsystem
IOI Inter operator identifier
IP Internet Protocol
IPCP Internet Protocol Control Protocol
ISC IMS service control interface
MD5 Message Digest no. 5
MSISDN Mobile Subscriber ISDN
N/A Not Applicable
NAI Network Access Identifier
NAPTR Naming Authority Pointer
NAT Network Address Translation
NP Number Portability
orig-ioi Originating IOI
OTAP Over The Air Provisioning
P-CSCF Proxy-CSCF
PCO Protocol Configuration Options
PoC Architecture
PDP Packet Data Protocol

PoC PTT over Cellular
PoCS PoC Server
PTT Push to Talk
QoS Quality of Service
RFC Request For Comments (IETF specifications)
RLS Resource List Server
RR Receiver Report RTCP packet
RTCP RTP Control Protocol
RTP Real-time Transport Protocol
SDP Session Description Protocol
SIP Session Initiation Protocol
SR Sender Report RTCP packet
SRV DNS resource record for the location of services
SSRC Synchronization Source
term-ioi Terminating IOI
UCS Universal Character Set
UDP User Datagram Protocol
UE User Equipment
UL UpLink
URI Uniform Resource Identifier
URL Uniform Resource Locator
UTF-8 UCS Transformation Format 8
UTRAN Universal Terrestrial Radio Access Network.
XML Extensible Mark-up Language
3.3 Requirement vocabulary

Shall Indicates a mandatory requirement.
Should Indicates a recommendation.
May Indicates an optional requirement.
PoC Architecture
4 Architecture
The PoC functional architecture is outlined in Figure 1.
OTAP
Io
Ips
Presence
Server
ACCESS NETWORK
Ipl
Im
UE
IMS Core
GLMS
Ik
Remote PoC Networks

Is
If PoC Server
It Itn
In
It: Floor Control and media

Itn: Floor Control and media
Is: PoC Client to Proxies Session Signaling
Bold box identifies PoC functional entities
If: Proxy to PoC Server Session Signaling
In: Proxy to Proxy Session Signaling
Im: Group Mgmt to PoC Client Remote PoC Network contains the same network elements and reference points as
Ik:Group Mgmt to PoC Server the home PoC network
Figure 1: PoC architecture

NOTE 1: The access in the PoC architecture includes both the radio access as well as the other nodes required to
gain IP connectivity.
NOTE 2: Dotted line identifies interfaces outside the scope for PoC Release 2 specifications.
PoC shall be based on IMS Core Networks as specified in 3GPP TS 23.228 [32] and TS 24.229 [33].
The present PoC specification is IMS compliant with the following major exceptions regarding to:
- IPv4 is mandatory to support on all interfaces. IPv6 is optional on Itn and In interfaces.
- The IMS-enabled PoC service may be offered through mobile networks different from that specified in 3GPP
release 5. This implies modified interfaces to the network environment for in the areas of charging and QoS
support, and and modifications in the SIP signaling.
PoC Architecture
- HTTP digest is used for authentication instead of IMS-AKA aas specified by 3GPP.
See Annex A for a complete list of IMS exceptions.
In this release of the PoC specification only interfaces between the IMS core and the UE, the IMS core and the PoC and
presence server and between IMS core networks will be specified. Therefore Im, Is, , In, It, If, Ips and Itn are the
interfaces to be specified in this release of the PoC specification.
Nevertheless all core internal interfaces as depicted in the architectural picture above shall be based on IMS. All other
relevant core internal interfaces may be specified in subsequent releases of the PoC specifications.
5 Description of functional entities
5.1 User Equipment (UE)

The UE is the terminal equipment containing the PoC application client software.
5.2 IMS Core

The IMS core includes a number of SIP proxies and SIP registrars according to [32] and [13]. The first point of contact
for UE is one of the proxies in the IMS core that is configured on the UE as the outbound proxy. In the IMS
architecture, the outbound proxy is known as the P-CSCF. The IMS Core performs the following functions:
- Routes the SIP signaling
o between the UE and the PoC Server,
o between UE and Presence server,
o between different IMS Cores;
- Terminates the SIP compression from the terminal;
- Authentication and authorization;
- Maintains the registration state and the SIP session state;
- Reporting to the charging system.
The UE shall send all its SIP messages to the IP address of the outbound proxy after resolving the SIP URI of the
outbound proxy to an IP address.
5.3 Group and List Management Function (GLMF)

PoC users use the Group and List Management Function ( GLMF) to manage groups, contact lists and access lists.
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 and to access PoC Presence information. A user may have one or several contact lists including
identities of other PoC users or PoC Groups. Contact list management includes operations to allow the UE to store,
modify, retrieve and delete the contact lists located in the GLMS.
The end users can define 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.
A PoC access list is used by the end user as a means of controlling who is allowed to initiate instant talk sessions to the
end user and who is allowed to receive PoC presence information for a user. An access list contains end user defined
identities of other PoC end users or groups. The end user may have one blocked identities list and one granted identities
list.
PoC Architecture
The GLMF also manages a separate access list, retrievable by the Presence Server, for controlling who is allowed to
subscribe to basic presence information for a given user.
Note: GLMF can be distributed over multiple servers, so that e.g. access lists for presence information may be stored on
the Presence Server.
5.4 PoC Server

The PoC Server implements functionality needed the PoC Service in the PoC network.
The PoC server may perform a Controlling PoC Function or Participating PoC Function. The Controlling PoC Function
and Participating PoC Function are different roles of the PoC server and and a PoC server may perform both a
Controlling PoC function and a Participating PoC function at the same time.
Figure 2 shows the distribution of the functionality during a 1-1 PoC Session in a single PoC Network. The UE A is the
UE initiating the instant personal talk session. The UE B is the UE invited to the talk session.The grey underground
areas identify a particular administrative domain.
Controlling Participating UE A
POC POC
1:1 1:1
Function Function A
Participating UE B
1:1 POC 1:1
Function B
Figure 2: Relationship between Controlling PoC Function, Participating PoC Functions and the PoC enabled UE
The determination of the PoC Server role (Controlling PoC Function and Participating PoC Function) takes place
during the PoC session setup and lasts for the duration of the whole PoC session. In case of 1-1 PoC Session and Ad-
hoc PoC group session the PoC server of the inviting user shall perform the Controlling PoC Function. In case of the
Chat PoC group and pre-arranged group session the PoC server owning/hosting the group identity shall perform the
Controlling PoC Function.
Figure 3 shows the distribution of the functionality during a 1-1 PoC Session in a multiple network environment. The
UE A is the UE initiating the instant personal talk session. The UE B is the UE invited to the talk session. The grey
underground areas identify a particular administrative domain.
PoC Architecture
Network A
Controlling 1:1 Participating 1:1 UE A
POC POC
Function Function A
Participating UE B
POC 1:1
1:1
Function B
Network B
Figure 3: Relationship between the Controlling PoC function, Participating PoC function and PoC enabled UE
for 1-1 PoC Session
In a PoC session there shall be only one PoC server performing the Controlling PoC Function. There can be one or
more PoC servers performing the Participating PoC Function in the PoC session.
The PoC Server performing the Controlling PoC Function has N number of SIP sessions and media and floor control
communication paths in one PoC session, where N is number of UE participating in the PoC session. The PoC server
performing the PoC Controlling Function will have no direct communication to the PoC enabled UE for PoC session
signaling. The PoC server performing the Controlling PoC Function may have a direct communication path for media
to each UE based local policy in the PoC servers performing the Participating PoC Function. A PoC server performing
the Participating PoC Function has always a direct communication path with a UE and a direct communication path
with the PoC server performing the Controlling PoC Function.
Figure 4 depicts the relation between the Controlling PoC Function, Participating PoC Function and the PoC enabled
UE in multiple network environment for a PoC Group session. UE Ai (i=1..N) is one of the PoC enabled UE in
Network A participating in the PoC Group Session. UE Bj (j=1..M) is one of the PoC enabled UE in Network B
participating in the PoC Group Session .The grey underground areas identify a particular administrative domain.
PoC Architecture
Network X Network A
Participating UE Ai
Controlling
1:N POC 1:1
POC
Function A
Function
Network B
Participating UE Bj
1:M
POC 1:1
Function B
Figure 4: Relationship between the Controlling PoC Function, Participating PoC Function and PoC enabled UE
for PoC Group Session
The Controlling PoC Function can be assigned to a PoC Server in the Home Network of the inviting user or to a PoC
Server in the Home Network of one of the invited users.
5.4.1 Controlling PoC Function

The PoC Server performs the following functions when it fulfills the Controlling PoC Function:
• Provides centralized PoC session handling

• Provides the centralized Media distribution
• Provides the centralized floor control functionality including talker identification
• Provides SIP session handling, such as SIP session origination, termination, etc.
• Provides policy enforcement for participation in group sessions
• Provides the participants information
• Collects and provides centralized media quality information
• Provides centralized charging reports
5.4.2 Participating PoC Function

The PoC Server performs the following functions when it fulfills the Participating PoC Function:
• Provides PoC session handling

• Provides the Media relay function between PoC enabled UE and Controlling PoC server
• Provides the floor control message relay function between PoC enabled UE and Controlling PoC server
• Provides SIP session handling, such as SIP session origination, termination, etc, on behalf of the represented PoC
enabled UE.
• Provides policy enforcement for incoming PoC session (e.g. access control, availability status, etc)
• Provides policy enforcement for outgoing PoC session (e.g. access control, etc)
PoC Architecture
• Collects and provides media quality information

• May provide the participant charging reports.
The Participating PoC Function may be left out as an implementation option from the media path. This option is not
furter discussed in this document.
5.5 Presence Server

Presence is defined by 3GPP TS 23.141 [26] , 3GPP TR 24.841 [34] and related IETF drafts and RFCs [27, 28, 29]. In
general, Presence and PoC are two independent services offered to the UE, with only a minimal interaction as defined
further in sub-clause 7.11.
The presence server has two functional roles Presence function and Resource list function.
Presence server when performing Resource list function provides following functions:
• authorizes the usage of the presence list for subscribing to the multiple presenties
• handles subscriptions to the presence servers of the presentities on the presence list
• sends presence information to the watcher based on the information received from the presence servers
• aggregates the presence information from presence servers into the one presence information notification to the
watcher
• provides rate control for the presence information notifications
Presence server when performing the Presence function provides following functions:
• manages presence information uploaded by the presentity
• authorizes subscription requests from the watchers based on the authorized watcher lists
• sends presence status changes of the presentity to the authorized and subscribed watcher
• provides rate control for the presence information notifications
• authorizes the subscription to the watcher information from the presentity
• provides watcher information notifications to the Resource list function
5.6 Over The Air Provisioning (OTAP) Server

The OTAP Server performs the following functions that are needed in support of the PoC Service:
• Provides all the needed configuration parameters from the service provider network for a PoC Client.
• Sends a WAP-push/SMS containing a binary coded XML to every client UE with default factory and network
settings.
6 Description of the interfaces
6.1 Interface Is: UE – IMS Core

The Is interface supports the communication between the UE and the IMS Core.. This communication includes the SIP
procedures defined in [2] to support the PoC features defined in [1].
PoC Architecture
The protocol for the Is interface is SIP (as defined by [13], other relevant IETF RFCs and necessary additions from
[33]). The SIP signaling across this interface is subject to SIP signaling compression defined in [2]. The Is signaling
shall be transported on both UDP and TCP as specified in [13]. When communicating with PoC 1 terminals, the IMS
core shall fall back to UDP.
NOTE: UA and IMS Core signaling is covered in [2] .
6.2 Interface If: IMS Core – PoC Server

The protocols over If interface support the communication between the IMS core and the PoC Server for session
control. This communication includes the SIP procedures defined in [2] to support the PoC features defined in [1].
The protocol for the If interface is SIP (as defined by [13], other relevant IETF RFCs and necessary additions from
[33]).
6.3 Interface It: UE – PoC Server

The It interface supports:
• media transport
• floor control procedures
• link quality procedures
The protocols for the It interface are RTP and RTCP [11] with details described in [3].
6.4 Interface Im: UE – GLMS

The protocols over Im interface support the communication between the UE and the Group and List Management
Server (GLMS) for the purpose of managing the groups, contact lists and access lists for PoC and Presence. They also
allow management of the Auto Answer Mode and Do-not-Disturb indication. The HTTP/XML protocols shall be used
as defined in [5].
The GLM function can be distributed over different servers which allows for different lists to be stored on different
servers. The group and list management operations are detailed in [5].
6.5 Interface Ik: PoC Server – GLMS

The protocols over Ik interface support the communication between the PoC Server and the GLMS; enabling the PoC
Server to retrieve the groups and access lists managed by the GLMF.
NOTE: The Ik interface is not specified in PoC release 2.0.
6.6 Interface Ips: IMS core – Presence Server

The protocols over Ips interface enable the publishing of the presence status from UE to the Presence Server, the
subscription to presence information delivery from the UE to the Presence Server and the dissemination of the presence
information between the Presence Server and the UE. The protocol for the Ips interface is SIP (as defined by [13], other
relevant IETF RFCs and necessary additions from [33]
6.7 Interface Ipl: Presence Server – GLMS

The Ipl interface enables the downloading of contact lists and access lists for presence from the GLMS to the Presence
Server, if needed.
PoC Architecture
NOTE1: GLMF can be distributed over multiple servers, so that e.g. access lists for presence information may be
stored on the Presence Server.
NOTE 2: The Ipl interface is not specified in the PoC release 2.0
6.8 Interface Itn: PoC Server – PoC Server

The Itn interface supports the user plane communication between the PoC servers.
The Itn interface shall support the following:
• media transport
• floor control procedures
• link quality procedures

The protocols for the Itn interface are RTP and RTCP [11] with details described in [3]
6.9 Interface In: IMS Core – IMS Core

The In interface supports the communication between the SIP/IP Cores. The In interface is based on SIP.
The In interface shall support the following:
• communication and forwarding of SIP signalling messaging between IMS Cores
The protocol for the In interface is SIP (as defined by [13], other relevant IETF RFCs and necessary additions from
[33]).
6.10 Interface Io: POC CLIENT – OTAP SERVER

The Io reference point supports the communication between the PoC Client and the OTAP Server. The Io reference
point shall support
• Transfer of the PoC Client configuration data from the OTAP Server.
OMA provides a general XML-based OTAP framework which shall be used (see [36]) for this interface.
7 System concepts
7.1 Identification
7.1.1 Address of record (a.k.a. public user identity)
The PoC operator shall assign, to each user, an address-of-record (also known as public user identity) in the form of a
SIP URI where the user part of the URI uniquely identifies the user. The host part of the URI uniquely identifies a
domain owned by the operator. The address-of-record shall comply with the specification of a SIP URI in [13].
The address-of-record is used for PoC only or for PoC and other SIP based services.
Examples of address-of-records are:
- sip:joe.doe@operator.net;
- sip:buss2.city@operator.net;
- sip:buss2.city@poc.operator.net.
PoC Architecture
7.1.2 Private user identity

The network operator shall assign to the user a private user identity for authentication purposes. The private user
identity shall be hidden from the other users and cannot be used for addressing.
The private user identity shall take the form of an NAI, and shall have the form username@realm as specified in clause
3 of RFC 2486 [22]. It is configured in the UE.
7.1.3 Group identities

The group identity used on the Is, If and Itn interfaces for group talk, shall be generated by the GLMF and shall comply
with the specification of a SIP URI in [13]. The GLMF shall generate the group identity according to reference [5].
Group identities are globally unique.
7.1.4 Contact list identities

A contact list identity used on the Is and Ips interfaces uses the generic address format defined in [13] and shall be used
to address the contact lists in the GLMS. The GLMF shall generate a SIP URI for each contact list as specified in
reference [5].
7.2 Addressing
7.2.1 IP addresses
Each entity in the PoC system shall be assigned one or more IP addresses belonging to public or private IP realms.
IPv4 is mandatory to support on all interfaces. IPv6 is optional on Itn and In interfaces
7.2.2 Phone numbers – TEL URL

A PoC user may address another user by a phone number.
The UE shall send the phone number to the network in a TEL URL [23].
The phone number may be in the international E.164 [21] format or a local format using a local dialing plan and prefix.
The phone number shall be expressed in the TEL URL as described in [23] with the following clarifications:
- An international E.164 number shall follow the global number scheme with the leading ‘+’.
- A local number shall follow the local number scheme that requires the presence of the phone-context
parameter. The UE shall provide in the phone-context parameter its own MSISDN number preceded by ‘+’, or,
if its own MSISDN is unknown, the domain of the home operator. The private prefix format of the area
specifier shall be used and formed by enclosing the information in double quotation characters. Examples of
the local number formats:
o A local number where the UE provides its own MSISDN number:
tel:2144567890;phone-context=”+12147656734”
o A local number where the UE provides its operator’s domain:
tel:2144567890;phone-context=”operator.com”
- Other local number formats shall not be used.
The method of expressing a phone number in a SIP URI by means of “user=phone” described in [13] shall not be used.
The phone number may be used to identify a user in a contact list, an access list, or a group. In order to unambiguously
identify the user by the user’s phone number the network shall internationalize the number.
PoC Architecture
The phone number may be used to address a user for a PoC session and instant personal alert. This requires that the
network internationalizes the number and resolves the TEL URL to a SIP URI, for instance by using DNS/ENUM or
other local data base. Examples of how TEL URLs may be resolved are illustrated in Annex B: E.164 Number
Translation (Informative).
7.2.3 SIP URI

A PoC user may address another user by a SIP URI.
7.3 Routing principles

7.3.1 Registration
The PoC user shall register itself with the IMS core before using the PoC service.
The UE binds the public user identity and the UE IP address and port at registration with the IMS core. The UE shall
include the media feature tag [19] indicating the PoC service in the Contact header. The IMS core may use this
information for routing.
7.3.2 Session establishment

The INVITE request on the Is interface shall contain the Accept-Contact header [19] with a media feature tag indicating
the PoC service. The IMS core shall be able to identify the request as PoC communication by inspecting the Accept-
Contact header.
The Request-URI of the INVITE shall contain either the pre-configured ad-hoc identity (for instant personal talk and
ad-hoc instant group) or a group identity (for instant group talk or chat group talk). The pre-configured ad-hoc identity
is assigned according to reference [2]
Early session establishment is used for having session available for quick connection establishment with REFER. Early
session establishment’s INVITE does not have any referred party field and can be differentiated from this against other
INVITEs.
The transient group identity used for AdHoc group talk and instant personal talk is generated by the controlling PoC
server and distributed to the UE in the contact header. Participating PoC server needs to have algorithm to translate its
transient group id to the one generated by the controlling PoC server.
From the initiating UE, the public user identity of the inviting user shall be included in the From header. On the
signaling towards the invited user, the From header includes either the public user identity (instant personal talk, ad-hoc
instant group) or the group identity (instant group talk or being added to a chat group).
Editor’s Note: The transient group identity is generated by the Controlling PoC Function, sent to the Participating PoC
Function and then algorithmically regenerated by the Participating PoC Function and sent to the UE. This allows the
Participating PoC Function to support call backs to an Adhoc group.
7.3.3 User location

Users shall use the Address of record or phone number (as described in 7.2.2 and 7.2.3) of other users to address them.
The IMS core is responsible for routing the requests to the users according to the bindings established through
registrations.
7.4 Security
7.4.1 Threats
There are a number of SIP threats identified in [13]. The main problem is that it is simple to steal and use another
user’s identity unless the identity is properly authenticated. The main threats by unauthorized use of an identity are
according to [13]:
PoC Architecture
- Registration Hijacking;
- Impersonating a Server;
- Tearing Down Sessions.
Another threat is fraud where a malicious user steals another user’s identity to talk and let the other user pay for that.
7.4.2 Countermeasures
The best and simplest countermeasure to the threats above is to properly authenticate the SIP requests from a user. The
Digest procedure defined in [13] shall be supported between the UE and IMS core for authenticating the user. The UE
shall include any stored credentials in all relevant SIP requests to avoid unnecessary signaling. With the digest
procedure, the IMS core should challenge the user if a relevant SIP request lacks credentials or the credentials are
invalid. The details for the authentication procedure are defined in [2].
A user shall be authenticated with the GLMS by using the procedures defined in [5].
In the case of HTTP digest, then the same digest password should be used by the UE when communicating with GLMS
or IMS core. The UE should not prompt the user for a digest password if the password is configured in the UE. Any
configured password should be protected, for example, by encryption.
7.4.3 Network Security

An end-user service such as PoC relies on the security mechanisms of the IMS core network to provide a secure
environment in which to provide end-user services. PoC specific security threats include (but are not limited to)
identify theft, DoS attacks, server authentication, confidentiality, media plane security, secure network to network
operating environment, etc. Many of these threats are mitigated using existing IMS security provisions.
For IMS based core networks, inter-network security guidelines are established in chapter 9 of 3GPP TS 33.900 [30].
PoC application servers shall adhere to the trust domains as specified in 3GPP TS 24.229 [33].
The PoC server belongs to the same trusted domain as the IMS. The IMS trusted domain interfaces are protected as
specified in 3GPP TS 33.210 [31]. Major areas of security are confidentiality, integrity, authentication and anti-reply
protection.
Note: There are no explicit requirements placed on the PoC server to achieve compliance with Lawful Interception.
PoC Architecture
7.5 Floor control

Floor control includes the following actions:
- floor request;
The action provides the capability for a participant in a talk session to ask for permission to talk.
- floor release;
The action taken be a granted user to release their permission to talk.
- floor grant;
An action from the network to inform requesting participant that the floor has been granted.
- floor idle indication;

An action from the network to inform participants that the floor is idle.
- floor deny;
An action from the network to inform the requesting participant that the floor request is denied.
- floor taken;
An action from the network to inform all participants that the floor has been granted to the indicated user.
- floor revoke;
The action from the network to remove the permission to talk from a user who has previously been granted
the floor
- talk burst quality feedback.

reports the amount of media received by the PoC server or by the UE.
- RTCP BYE;
indicates that the sending party wants to terminate the ongoing media session in current communication
context, without changing the SIP-session state
The talker arbitration performed through the use of RTCP.
The talker identification distributed through the use of RTCP
The talk burst quality feedback is distributed through the use of RTCP RR and SR
Floor control is described in detail in [3].
7.6 Codecs
PoC has the AMR speech codec as the mandatory speech codec for the GSM, GERAN and UTRAN radio access
networks. The details describing how AMR is used in PoC is found in [4]. The codec rate depends heavily on the radio
cell configuration and the latency for GSM/GERAN/UTRAN.
7.7 Signaling compression

The UE and the IMS core shall compress the SIP signaling according to [15], [16], [17] and [18] to reduce the
transmission delays. Details how this is done are described in [2].
The grouping of messages (compartments) starts at registration and ends at de-registration.
A static SIP dictionary [17] shall be stored locally in the UE and the IMS core. A user specific dictionary [16] may be
uploaded by the UE to the IMS core and stored there as part of the registration procedure. The user specific dictionary is
used to increase the compression rate in particular for the initial SIP messages. The SIP URI shall include the signaling
compression indication as described in [18].
PoC Architecture
7.8 User plane adaptation

The media throughput is affected by the conditions on the radio access link. The talk burst (user plane) bit rate shall be
reduced in case the talk burst bit rate is higher than the available end-to-end bit rate. The available bit rate is indicated
with RTCP. The talk bursts bit rate can be reduced if necessary by re-negotiation with SIP. The Controlling PoC server
is responsible for deciding whether user plane adaptation is done. Either the UE or the Controlling PoC server can
initiate the user plane adaptation SIP messages.
7.9 Charging
7.9.1 Charging Models and Mechanisms
The charging models that should be supported are described in [1]. In general, the models proposed are Flat Rate,
Session based, Granted Talking Time, Talk Burst Size, and Number of Talk Bursts. The PoC architecture shall be able
to support the following charging mechanisms to support these charging models:
- The IMS core network nodes and the PoC Server may be able to report to the charging system upon reception
of various SIP methods since charging relevant information is contained in these messages;
- The PoC Server may be able to report a talk burst end event to the charging system. The message sent to the
charging system for the talk burst should include any relevant SIP and SDP parameters for the ongoing session,
the numbers of bytes sent, the number of packets sent and the duration of the talk burst.
- The PoC Server may be able to report to the charging system the number of packets and bytes a UE has
received in a talk burst. The UE reports these parameters in a receiver report message;
- The delivery of the receiver reports and the talk burst end are not reliable. The PoC Server may be able to report
to the charging system after a timer expiry in case both of these messages are lost.
The receiver report cannot be trusted. In case there is a long-term difference between the number of bytes sent from
PoC server and the information received in the receiver report, this is an indication of fraud.
The bearer charging is also used in parallel. The correlation between the bearer charging and service charging shall be
done in the charging system.
A deployed network may implement all, some or none of the charging models described in this sub-clause.
7.9.2 Inter-Operator Charging

In PoC Release 2, inter-operator charging reconciliation is not specified. The general approach is that all users are
responsible for their own PoC usage charges according to the policies of their own Home local operator – Home
controlled charging. However concerns are raised on how charging is reconciled if a group participant initiates a group
call to a group he/she does not own.
In order to keep the initial charging methods simple, and not require inter-operator reconciliation, the following policies
are assumed for each PoC Service type.
Instant Group Talk and Chat Group Talk
• All Group owners pay for the group talk (group list explosion, media distribution) according to the charging
model of the group owner’s network.
• A Group owner can restrict the group initiation right to himself.
• The Group owner can restrict the ‘add user’ right to himself.
• Each group participant will have to pay for his/her own participation depending on the charging model of his
own home network.
• Different charging models may be applied in different networks for the same PoC session.
PoC Architecture
For example, if a group owner initiates a group call with 2 other members in different operator networks, the group
owner will pay for the group call according to his local charging policy, and the other members will only pay for their
“legs” of the call, according to the charging policy of each individuals operator. In similar fashion, if one of the group
members calls back to that group (assuming they have proper permission), the group owner still pays for the main group
call session (explosion, distribution), with the members (including the initiator) still only being charged for their “legs”
usage.
The GLMS should hold the attributes as to whether or not participants (not the group owner) may
• initiate the group call, and

• add users to an existing group call.
These rights may not be dynamically changed mid-session and be expected to take effect. . .
Instant Personal Talk and Ad-hoc group talk
For Instant Personal Talk and Ad-hoc group talk, the same principles apply as for the group owner of the Instant Group
Talk and Chat Group Talk. In Instant Personal Talk, both parties pay for their participation in the 1-to-1 call according
to the charging policies of their Home network. In Ad-hoc Group Talk, the Session initiator is the group owner, and
there is no need to provide rights to initiate the call for Ad-hoc, and the policies described for Group Talk and Chat
apply.
The user’s profile or operator configuration data should hold the attributes as to whether instant personal talk or Ad-hoc
group talk participants (not the talk initiator) may add users to an existing call. These rights may not be dynamically
changed mid-session and be expected to take effect. By storing this in the user’s profile, the settings will apply to all
instant personal talks or Ad-hoc group calls.
7.10 Roaming
The PoC user may roam in a visited network. GPRS roaming can then be used which means that a home GGSN and the
home IMS core are always used.
7.11 Presence
Presence functionality is defined by 3GPP 23.141 [26], 3GPP TR 24.841 [34] and related IETF drafts and RFCs [27,
28, 29]. The topic is included here to clarify the interactions of Presence and PoC.
As described in reference [26], a UE (presence user agent) publishes its presence state to the Presence Server via the Is
and Ips interfaces. The Presence Server then forwards that presence information to all authorized UE watcher’s that
have subscribed to it, also via Ips and Is.
Since this presence functionality is deployed in an environment of scarce radio resources, it is an implementation option
of the Presence Server as to how often it communicates with presentities to gather presence state information and how
often it sends information to watchers. Presentity status should not be sent to watchers unless it has changed since the
last time it was sent.
7.11.1 Resource List Function

Contact list(s) for PoC of type user, which are managed between the UE and GLMF, might be used as a resource list for
subscribing at once to multiple presentities.in PoC. This allows a UE watcher to use the SIP URI of a contact list to
subscribe to a resource list with a single subscription. The RLF may forward subscriptions to other Presence Servers,
on behalf of the UE for those members of the resource list which are not served by the Resource List Function (RLF) of
Presence Server Resource List Function (RLF) receiving the subscription request. The RLF notifies the UE watcher
whenever presentities in the resource list have updated their presence information. The notification includes all users if
it is triggered by a subscribe otherwise it is a partial notification only including those presentities that have updated their
presence since the last notification.
Additionally a Presence server may use it's own lists which are managed between the UE and Resource List Function in
the Presence server.
The Presence Server shall use the Ipl interface to the GLMS that optionally allows it to obtain information about PoC
contact list membership and access list membership.
PoC Architecture
7.11.2 Presence States

PoC defines two new presence states that the UE and Presence Server shall exchange as part of the normal presence
package.
• PoC Available
• PoC Unavailable
These new states are used to inform the watchers as to the availability of potential PoC call targets. For example, a user
may have a general presence status of “online”, but still be “PoC Unavailable”, if they are busy in a different service
such as a telephone call.
7.11.3 Watcher Authorization - Access List Management

A presentity can authorize and unauthorize watchers by using Access/Reject list(s). Managing of lists is performed
using Im interface.
Access/Reject list(s) for PoC, which are managed between the UE and GLMF, are also used for PoC presence. While
having common PoC and Presence Access/Reject lists is not required, thit vendor specific supported architecture is
preferred, as it provides an integrated user experience. The Presence Server shall use the Ipl interface to the GLMS that
optionally allows it to obtain information about PoC Access/Reject list membership for watcher authorization of a
particular presentity..
NOTE: As the GLM Function can be distributed over multiple servers the Access/Reject lists for presence
information may be stored on the Presence Server.
7.12 Do-not-Disturb
The user can enable the Do-not-Disturb (DnD) feature in the UE. The result is that DnD flag for the user is set in the
network The network or the UE with the enabled DnD will then reject all incoming sessions. The inviting user does
then recognize the response as a busy indication.
The user updates the DnD setting in GLMS. This is described in detail in [5].
NOTE: Do-not-Disturb is not a presence attribute, it is used as a PoC specific equivalent of an incoming session
baring function.
8 High level procedures

The sub-clause gives examples on PoC signaling procedures. Details shall be described in stage 3 documents.
Following guidelines have been used for the signaling flows shown below:
• Flows do not show the IMS Core, do not show all messages - only essential triggers are numbered and
commented.
• Same terminology as in Release 1.0 is still being used.
Note: Call Flows between Controlling and Participating PoC AS should be as close as possible to Call Flows
between Controlling PoC Server and terminating/invited PoC subscriber in Release 1.0 to keep the
Participating PoC AS implementations simple. Nevertheless, no deviations from standards shall be
allowed
8.1 PDP Contexts

A PDP Context with the interactive traffic class with the highest priority should be used for the SIP, DNS and
HTTP/XML signaling. The signaling PDP Context is a PDP Context that shall be activated before the SIP registration.
This PDP Context should be activated at least as long as the SIP registration lasts.
PoC Architecture
In case the radio access network does not support the streaming class or the streaming class usage is subject to local
policy, a PDP Context with the interactive traffic class with the highest priority should be used for media. The same
PDP Context may be used for the media and for signaling. As an alternative an additional PDP Context with the
interactive traffic class and same IP address may be used for the media.
In case the radio access network supports the streaming traffic class and the local policy allows its usage PDP Context
with the streaming traffic class should be used for the media to provide high quality voice. The PDP Context for the
streaming traffic class is an additional PDP Context with the same IP address as the PDP Context for signaling, that is
activated in parallel with the establishment of Instant Personal Talk or Group Talk.
8.2 DNS name server discovery

The UE obtains IP addresses of the DNS name servers as part of the PDP context activation.
The IPv4 addresses for the DNS name servers (primary and secondary) are included in the Protocol Configuration
Options (PCO) [8]. The PCO format uses the IPCP [9] field that is defined in [10].
8.3 DNS procedures

8.3.1 SIP URI resolution
The address of the outbound proxy in the IMS Core is configured into the UE in the form of a SIP URI. The URI should
include the transport protocol and the port number the proxy is listening to and an indication that compression should be
used (comp=sigcomp).
The UE shall resolve the SIP URI of the outbound proxy into an IP address before its registration with the IMS core.
This IP address shall be used by the UE for all SIP initial requests during this registration period. The resolution
procedure shall follow the procedures described in [14].
The Participating PoC server of the inviting PoC user will have to determine based on a DNS query the IP version
supported by the IMS Core of the PoC Server (Participating or Controlling) handling the invited user(s).
In order to locate the IMS Core of a invited PoC user the SIP URI is resolved by the IMS Core of the Controlling PoC
Server following the procedures in [14].
In order to locate the IMS Core of a PoC group the SIP URI is resolved by the IMS Core of the Participating PoC
Server of the inviting PoC User following the procedures in [14].
Note that if the SIP URI of the outbound proxy that is configured in the UE follows the format recommended above
(transport protocol and port number explicitly given), following the procedures in [14], the UE performs an A query. If
the recommended format is not followed, the UE might need to perform NAPTR or/and SRV queries.
Example of the recommended format for the SIP URI configured in the UE pointing to the outbound proxy:
sip:outbound-proxy.my-operator.com:5060;transport=udp;comp=sigcomp
8.3.2 HTTP URL resolution

The UE resolves a HTTP URL according to [12] or to best current practice.
NOTE: The Im request is sent to a proxy identified by a configured address in case a WAP or HTTP proxy is
used. In that case the proxy resolves the HTTP URL according to [12] or to best current practice.
8.4 Early Session dialog establishment (Pre-established

Session)
The early session provides the instant personal talk and AdHoc Instant Group talk for end-user. The early session
enables the UE to establish a transport path with its participating PoC server that can be used for exchanging
RTP/RTCP packets
PoC Architecture
The early session may be used for service negotiation purposes between the end user and the home PoC Server.
The early session is established for service negotiation purposes right after the initial registration, or the UE may request
the early session at any later time point (e.g. when the end-user activates PoC Application from the UE).
8.5 Instant Personal Talk (1-1 PoC Session)

In an Instant Personal Talk, user A establishes a PoC session with user B. Connection setup may be done either with
early session procedure and a SIP REFER request or with a SIP INVITE request.
In Instant Personal Talk cases the PoC server having the role of the Participating PoC server A of takes also the role of
the Controlling PoC server.
8.5.1 Instant Personal Talk establishment with early session

In early session case the UE A and UE B establishes early sessions towards their respective PoC servers. The PoC
Servers may belong to the same or to different operator domains.
Controlling /
Participating Participating
UE A PoCS B UE B
PoCS A
1. REFER
2. 202 Accepted 3. INVITE
4. 200 OK
Floor granted Floor taken Floor taken
Media Media Media

5. ACK
6. NOTIFY
7. 200 OK
Figure 5 : Early session both sides
1. During the connection establishment phase the session is established with using a SIP REFER request between
the UE A and the Participating PoC Server A.
2. A SIP 202 Accepted response is sent immediately by the Participating PoC Server A. to the UE A.
3. Controlling PoC Server A sends a SIP INVITE request to the Participating PoC Server B.
4. A SIP 200 OK response is immediately sent back to the Controlling PoC Server A by the Participating PoC
Server B, as UE B has an established early session and has auto-answer mode set (confirmed indication).
5. The Controlling PoC Server A sends a SIP ACK request to the Participating PoC Server B.
6. The Participating PoC Server A sends UE A a SIP NOTIFY request after the first talk burst to inform it that
UE B has accepted the connection.
7. UE A sends the SIP 200 OK (NOTIFY) response to the Controlling PoC Server A.
If User B does not use auto answer, the Participating PoC Server B sends SIP Invite to the UE B as shown in the
following Figure 6.
PoC Architecture
Controlling /
UE A PoCS B UE B
PoCS A
1. REFER
2. 202 ACCEPTED 3. INVITE 4. INVITE
6. 180 Ringing 5.180 Ringing
8. 200 OK 7. 200 OK
Media Media Media
9. NOTIFY
10. 200 OK
11. ACK 12. ACK
Figure 6: Early Session with Late Media and Manual answer procedure
1 During the connection establishment phase the session is established with using a SIP REFER request
between the UE A and the Participating PoC Server A.
2 A SIP 202 Accepted response is sent immediately by the Participating PoC Server A. to the UE A.
3 Controlling PoC Server A sends a SIP INVITE request to the Participating PoC Server B.
4 Participating PoC Server B forwards the SIP INVITE request to the UE B.
5 A SIP 180 Ringing response is sent by the UE B to the Participating PoC Server B.
6 Participating PoC Server B forwards the SIP 180 Ringing response to the Controlling PoC Server A
7 When UE B answers a SIP 200 OK is immediately sent back to the Participating PoC Server B.
8 The SIP 200 OK response is forwarded to the Controlling PoC Server A by the Participating PoC Server B.
The Controlling PoC Server A is granting the floor to the UE A and notifies the UE B about the taken floor.
Media starts to flow between UE A and UE B.
9 The Participating PoC Server A sends UE A a SIP NOTIFY request after the first talk burst to inform it that
UE B has accepted the connection.
10 UE A sends the SIP 200 OK (NOTIFY) response to the Controlling PoC Server A.
11 The Controlling PoC Server A sends a SIP ACK request to the Participating PoC Server B.
12 PoC Server B forwards the SIP ACK request to the UE B.
The signaling flow for the case where there is no early session established by the UE B, but auto answer is supported is
shown in Figure 7
PoC Architecture
Controlling /
UE A PoCS B UE B
PoCS A
1. REFER
2. 202 3 INVITE
4.183 5.INVITE
Floor granted
6.200 OK
Media 7.200 OK
8.ACK 9.ACK
10. NOTIFY
Floor taken Floor taken
11. 200 OK (NOTIFY)
Media Media
Figure 7: Early Session only on the originating side, auto answer on the terminating side
1 During the connection establishment phase the session is established with using a SIP REFER request
2 A SIP 202 Accepted response is sent immediately by the Participating PoC Server A. to the UE A.
4 Participating PoC Server B recognizes that UE B uses auto answer mode and immediately sends a SIP 183
Session Progress response to Controlling PoC Server A. The Controlling PoC Server A grants UE A the
floor and starts spooling the talk bursts received.
5 Participating PoC Server B forwards the SIP INVITE request to the UE B.
6 A SIP 200 OK is immediately sent back to the Participating PoC Server B.
7 The SIP 200 OK response is forwarded to the Controlling PoC Server A by the Participating PoC Server
B. The Controlling PoC Server A notifies the UE B about the taken floor. Media starts to flow between the
Controlling PoC Server A and UE B.
9 PoC Server B forwards the SIP ACK request to the UE B.
10 The Participating PoC Server A sends UE A a SIP NOTIFY request to inform it that UE B has accepted
the connection.
Figure 8 shows the case in which the UE B in auto answer mode has established an early session but the originating side
is not supporting early media.
PoC Architecture
Controlling /
UE A PoCS B UE B
PoCS A
1. INVITE 2. INVITE
4. 200 OK (INVITE) 3. 200 OK (INVITE)
Media Media Media

6. NOTIFY 5. ACK
7 200 OK (NOTIFY)
Figure 8: No Early Session on the originating side, Early Session on the terminating side and Auto answer
procedure
1 During the connection establishment phase the session is established with using a SIP INVITE request
3 Participating PoC Server B recognizes that UE B uses auto answer mode and immediately sends a SIP 200
OK response to Controlling PoC Server A.
4 A SIP 200 OK response is sent immediately by the Participating PoC Server A. to the UE A. The
Controlling PoC Server A grants UE A the floor. Media starts to flow between the Controlling PoC Server
A and UE B.
6 The Controlling PoC Server A sends UE A a SIP NOTIFY request to inform it that UE B has accepted the
connection.
8.5.2 Instant Personal Talk establishment on-demand

If no early session exist the UE A Figure 9 shows the Instant Personal Talk Establishment flow.
PoC Architecture
Controlling /
UE A PoCS B UE B
PoCS A
1.INVITE 2. INVITE
5. 202 ACCEPTED 3.183 4. INVITE
Floor granted 6. 200 OK
7. 200 OK
Media
8. NOTIFY Floor taken Floor taken

9. 200 OK (NOTIFY) Media
Media
10. ACK 11. ACK
Figure 9 : Early media and auto answer procedure

1. The UE A sends a SIP INVITE request to the Participating PoC Server A including user B’s address in a body
whose type is application/vnd.poc.refer-to. Since the Participating PoC Server A recognizes that this a Instant
personal talk session establishment it takes the role of the Controlling PoC server as well.
2. The Controlling PoC Server sends a SIP INVITE request to the Participating PoC Server B. When the
Participating PoC Server B receives this SIP INVITE request, it performs an authorization decision based on
the Do-not-Disturb and the access list settings in the GMLS. If the invitation is authorized, the Participating
PoC Server B depending on the User B’s auto-answer/manual-answer settings, initiates early media
establishment procedures or late media procedures.
3. If the User B’s auto-answer/manual-answer setting indicates auto-answer the Participating PoC Server B
initiates the early media establishment procedure as shown in Figure 9, by sending a SIP 183 Session Progress
provisional response to the Controlling PoC Server. The Participating PoC Server B should insert in 183 either
a codec out of a list of codecs supported by the target, or the default codec.
4. The Participating PoC Server B also sends an SIP INVITE request to UE B.
5. Upon receiving the SIP 183 Session Progress response the Controlling PoC Server A sends a SIP 202
Accepted response to the UE A. This response, together with the “floor grant” message from the talker
arbitration process, informs user A that user B has not been reached yet, but that the PoC Server is already
prepared to receive media.
6. In parallel, upon receipt of the SIP INVITE request UE B responds with a SIP 200 OK to the Participating PoC
Server B.
7. The SIP 200 OK message is sent from Participating PoC Server B to Controlling PoC Server A.
8. The Controlling PoC Server informs UE A that UE B is connected by sending SIP NOTIFY request.
9. UE A responds with a SIP 200 OK.
PoC Architecture
If the User B’s auto-answer/manual-answer setting indicates manual-answer the Participating PoC Server B initiates the
late media establishment procedures as shown in Figure 10. As a result, SIP messages from UE B are relayed via
Participating PoC Server B and Controlling PoC Server A (and over several SIP dialogs) to UE A. A SIP 200 OK
message from UE B finally results in a SIP 200 OK message received by UE A. This informs UE A that UE B has
accepted the conversation.
Controlling /
UE A PoCS B UE B
PoCS A
1. INVITE 2. INVITE 3. INVITE

6. 180 Ringing 5. 180 Ringing 4. 180 Ringing
9. 200 OK 8. 200 OK 7. 200 OK
Media Media Media
10. ACK 11. ACK 12. ACK
13. NOTIFY
14. 200 OK (NOTIFY)
Figure 10 Late Media and Manual answer procedure

1. The UE A sends a SIP INVITE request to the Participating PoC Server A including user B’s address in a body
whose type is application/vnd.poc.refer-to. Since the Participating PoC Server A recognizes that this a Instant
personal talk session establishment it takes the role of the Controlling PoC server as well.
2. The Controlling PoC Server sends a SIP INVITE request to the Participating PoC Server B. When the
Participating PoC Server B receives this SIP INVITE request, it performs an authorization decision based on
the Do-not-Disturb and the access list settings in the GMLS. If the invitation is authorized, the Participating
PoC Server B depending on the User B’s auto-answer/manual-answer settings initiates the late media
procedures.
3. Participating PoC Server B forwards the SIP INVITE Request to the UE B.
4. The UE B sends immediately a SIP 180 Ringing response to the Participating PoC Server B
5. The Participating PoC Server B forwards the SIP 180 Ringing response to the Controlling PoC Server A.
6. UE A is receiving the SIP 180 Ringing response from the Participating PoC Server A.
7. Upon manual answer of the UE B a SIP 200 OK response is sent to the Participating PoC Server B.
8. Participating PoC Server B is forwarding the SIP 200 OK to the Controlling PoC Server A.
9. UE A receives the SIP 200 OK from the Participating PoC Server A. At this point the Controlling PoC Server
A grants the floor to the UE A and Media starts to flow between UE A and UE B.
In steps 10...12 the SIP 200 OK is acknowledged.
PoC Architecture
13 The Controlling PoC Server informs UE A that UE B is connected by sending SIP NOTIFY request.
14 UE A responds with a SIP 200 OK for the NOTIFY.
Once the session has been established, either user A or user B can terminate it at any time. In case of inactivity, the PoC
Server can also terminate the session (no talk bursts within a configured time period).
8.6 Ad-hoc Instant Group Talk

In an Ad-hoc Instant Group Talk, user A establishes a PoC session with a set of users. The PoC server having the role of
the Participating PoC server A of takes also the role of the Controlling PoC server.
For the early media procedures and the late media procedures are similar to those described in
Figure 9 and Figure 10. The difference is that in an Ad-hoc Instant Group Talk, the application / vnd-poc.refer-to body
of the initial SIP INVITE request from UE A will contain more than one address. Therefore, the Controlling PoC Server
will send more than one SIP INVITE request to more than one terminating Participating PoC Server The UE A will
receive a SIP NOTIFY request for each B party. The setup will be done with auto or manual answering mode depending
on the B party’s auto-answer/manual-answer settings. When using the early media establishment procedures for ad-hoc
groups, the PoC server begins to play the media when the first invited B party accepts.
For the early session case procedures are similar to those described in Figures 5 to 8, . The difference is that the SIP
REFER request from user A will contain more than one address. The Controlling PoC server will send several SIP
INVITEs towards more than one terminating Participating PoC Server. The setup will be done with auto or manual
answering mode depending on the B party’s auto-answer/manual-answer settings.
In Ad-hoc Instant Group Talk the user portion of the Request-URI of the initial INVITE will be set to the pre-
configured ad-hoc string. The Controlling PoC Server will return in the Contact header of the final response for the
INVITE a unique identifier for the Ad-hoc Instant Group Talk.
8.7 Instant Group Talk

In an Instant Group Talk, a member in an existing instant group, invites other members in the same instant group to a
talk session. Existing instant group, in this context, means that a unique identifier has been previously allocated for the
instant group.
In Instant Group Talk cases the PoC server owning the group identity shall be the Controlling PoC server.
Figure 11 shows the high-level signalling procedures when one member initiates the talk session with 3 members in the
group. The member initiating the talk session, and the members invited to the talk session may be connected to different
operators. One of the invited members has the auto-answering mode enabled while the other has the manual-answering
mode enabled. The Controlling PoCS which provides possibility for the early media may be located in a different
administrative domain than the inviting UE A (as shown).
Note: When the Controlling PoCS is in the same admisitrative domain as the inviting UE A, the PoCS A fulfills
both the Participating and the Controlling PoC Function.
PoC Architecture
Participating Controlling Participating Participating

UE A PoCS A PoCS PoCS B1 UE B1 PoCS B2 UE B2
1. INVITE 2. INVITE 3. INVITE 4.INVITE
5. INVITE
6. 183 7. INVITE
9. 202 Accepted 8. 202 Accepted
Floor granted Floor granted
Media Media 11. 200 OK 10. 200 OK
12. ACK 13. ACK
15. NOTIFY 14. NOTIFY Media Media
16. 200 OK 17. 200 OK
19. 180 Ringing 18. 180 Ringing
21. 200 OK 20. 200 OK

22. ACK 23. ACK
25. NOTIFY 24. NOTIFY
26. 200 OK 27. 200 OK
Media Media
Figure 11 Instant Group Talk setup.

• The UE A sends a SIP INVITE towards the address of the Instant Group pointing to Controlling PoC server
via its own Participating PoC Server A. (steps 1 and 2)
• The Controlling PoC server authorizes the member A. If the member A is authorized the instant group PoC
Server initiates an Instant Group Talk session to the other members via Participating PoC Servers (steps 3 and
5)
The member B1’s auto-answer/manual-answer setting indicates auto-answer hence the Participating PoC Server B1
initiates the early media procedures as shown in
• Figure 11, and sends a SIP 183 provisional response to the Controlling PoC server (steps 6, 7, 10 and 11).
The member B2’s auto-answer/manual-answer setting indicates manual-answer hence the Participating PoC Server B2
initiates the late media establishment procedures as shown in
• Figure 11, and answer the SIP INVITE request with a 200 (OK) response to the Controlling PoC Server (steps
4, 20 and 21).
• The 202 (Accepted) response, together with the “floor grant” message from the talker arbitration process,
informs UE A that no members have been reached yet, but the media can be sent. The Controlling PoC server
may buffer media received from the member A until it can be delivered to the member B1. (steps 8 and 9)
• Any provisional responses, for example 180 (Ringing) received from the UE B2 relayed back to the
Controlling PoC Server, depending on the state in the Controlling PoC Server, discarded or sent to the UE A
(steps 18 and 19).
• When UE B1 and B2 finally accept the invitation, the Participating PoC Servers B1 and B2 relay the 200 OK
response to the Controlling PoC server. The Controlling PoC Server informs the UE A that UE B1 and UE B2
are connected by using SIP NOTIFY requests (steps 14, 15, 24 and 25).
Figure 12 shows the high-level signaling procedures when one member initiates the talk session with 3 members in the
group. The member initiating the talk session, and the members invited to the talk session may be connected to different
operators. One of the invited members has the auto-answering mode enabled while the other has an established early
session.
PoC Architecture
Participating Controlling Participating Participating

UE A PoCS A PoCS PoCS B1 UE B1 PoCS B2 UE B2
1. INVITE 2. INVITE
3. INVITE
4. 183 5. INVITE
7. 202 Accepted 6. 202 Accepted
Floor granted Floor granted
Media Media 9. 200 OK 8. 200 OK
10. ACK 11. ACK
13. NOTIFY 12. NOTIFY Media Media
14. 200 OK 15. 200 OK
16. INVITE 17.INVITE
19. 200 OK 18. 200 OK
21. NOTIFY 20. NOTIFY

23. 200 OK 22. 200 OK
Media Media
Figure 12: Instant Group Talk setup with Early Session User on the terminating side
• The UE A sends a SIP INVITE towards the address of the Instant Group pointing to Controlling PoC server
via its own Participating PoC Server A. (steps 1 and 2)
• The Controlling PoC server authorizes the member A. If the member A is authorized the instant group PoC
Server initiates an Instant Group Talk session to the other members via Participating PoC Servers (steps 3 and
16)
The member B1’s auto-answer/manual-answer setting indicates auto-answer hence the Participating PoC Server B1
initiates the early media procedures as shown in
• Figure 12, and sends a SIP 183 provisional response to the Controlling PoC server (steps 4, 5, 8 and 9).
The member B2’s early session is established hence the Participating PoC Server B2 proceeds with the establishment as
shown in
• Figure 12, and answer the SIP INVITE request with a 200 (OK) response to the Controlling PoC Server (steps
17, 18 and 19).
• The 202 (Accepted) response, together with the “floor grant” message from the talker arbitration process,
informs UE A that no members have been reached yet, but the media can be sent. The Controlling PoC server
may buffer media received from the member A until it can be delivered to the member B1. (steps 6 and 7)
• When UE B1 and B2 accept the invitation, the Participating PoC Servers B1 and B2 relay the 200 OK
response to the Controlling PoC server. The Controlling PoC Server informs the UE A that UE B1 and UE B2
are connected by using SIP NOTIFY requests (steps 12, 13, 20 and 21).
8.8 Chat Group Talk

In a Chat Group Talk, a user joins an existing chat group. Existing in this context means that a unique identifier has
been previously allocated for the chat group.
In Chat Group Talk cases the PoC server owning the group identity shall be the Controlling PoC server.
PoC Architecture
Figure 13 shows the high-level signaling procedure when a user joins a chat group. The user joining the chat group is
connected to a different operator than the Chat group PoC Server.
Participating Controlling
UE A PoCS A PoCS
1. INVITE 2. INVITE
4.200 OK 3. 200 OK
Floor granted / Floor granted /

Media Media
Media Media
5. ACK 6. ACK
Figure 13 Joining the Chat Group talk

The User A sends the SIP INVITE request to the address of the Chat group via the Participating PoC Server A. The
Chat group PoC Server authorizes the user A and if the User A is authorized the User A is added to the chat group talk
session.
The SIP 200 (OK) response informs the User A that join was successful. The “floor grant” or “floor taken” message
from the talker arbitration process, informs the user about the status of the floor. The “floor grant” indicates that the
User A may start to talk and the “floor taken” indicates that the floor is taken by another user.
The SIP ACK request is sent by the UE A via the Participating PoC Server A to the Controlling PoC Server owning the
Chat Group.
8.9 Instant Personal Alert

An Instant Personal Alert is a request from user A to user B for user B to establishes an Instant Personal Talk with user
A. Instant Personal Alerts are similar to a call back service in the world of traditional telephony. The User B’s access
list setting may restrict the instant personal alert.
Figure 14 shows the high-level signaling flow when one user sends an instant personal alert to another user. In this case
User B’s IMS home network routes the SIP MESSAGE request to the PoC server of the User B.
PoC Architecture
Local Local
UE A PoCS A PoCS B UE B
MESSAGE MESSAGE
200 OK 200 OK
NOTE: If the policy requires, the Instant Personal Alert may be routed through the PoC Server A (dashed in the figure)
of the originating UE A.
Figure 14 Instant Personal Alert with Access list control
The User A sends the SIP MESSAGE request towards the address of the User B. The User B PoC Server authorizes the
User A using the User B’s reject list settings and if the User A is authorized, the User B PoC Server sends the SIP
MESSAGE request to the User B.
The 200 OK informs the User A that the instant personal alert was successfully delivered to User B.
Figure 15 shows the high-level signaling flow when one user sends an instant personal alert to another user. In this case
User B’s IMS home network routes the SIP MESSAGE request directly to User B.
UE A UE B
MESSAGE
200 OK
Figure 15 Instant Personal Alert
9 High level procedures for presence

An example of the high-level procedures for exchanging presence information between UE’s and Presence Servers(s)
are shown in the following diagram. They follow the recommendations defined in 3GPP 23.141 [26] and related IETF
drafts and RFCs [27, 28, 29]. No changes to these procedures are expected for PoC.
PoC Architecture
UE A UE B
UE A RLS Presence Server UE B
1.SUBSCRIBE
2.200 OK
3.SUBSCRIBE
4.200 OK
5.NOTIFY
6.200 OK
7.NOTIFY
8.200 OK 9.PUBLISH
10.200 OK
11.NOTIFY
12.200 OK
13.NOTIFY
14.200 OK
Figure 16: Subscription to Presence Information

1. The UE A sends a SUBSCRIBE request for a list to the Presence server (via IMS routing) in his/her home
network. The presence server in UE A’s home network decides to handle the request and accepts the
subscription by sending a 200 OK response to UE A.
2. The presence server in UE A’s home network decides to handle the request and accepts the subscription by
sending a SIP 200 OK response to UE A.
3. If the presence server can not retrieve presence information for a certain user internally (as this user belongs to
a different network) it sends a SUBSCRIBE on behalf of UE A for the presence information of UE B to UE
B’s home network.
4. The Presence server in user B’s home network decides to handle the request and sends a SIP 200 OK response.
5. Immediately after the SIP 200 OK final response, the UE B’s presence server sends a SIP NOTIFY request
with the presence status of UE B. This request is forwarded to UE A’s presence server who issued the
subscription.
6. After presence server A has received the presence information of all members of the list (the previous steps
may be repeated as necessary) it assembles a SIP NOTIFY request that contains the aggregated presence
information of all list members and sends it to UE A. If the time to collect the complete presence information
is too long, the presence server may decide to send a NOTIFY with status ‘no data available’ for the
presentities with no status available.
9. Later, UE B updates his presence information by sending a PUBLISH request to his local presence server.
10 The UE B presence server sends the SIP “200 OK” response.
11-14 The change of state triggers a notification to Presence server A
The updated Presence status of user B triggers a NOTIFY with the updated status to UE A. The Presence server only
sends the changed data with the NOTIFY.
PoC Architecture
Annex A (informative): Known 3GPP/OMA divergence

PoC industry specification is based on 3GPP and IETF standards where feasible. In order to overcome limitations of
the existing technology, the PoC specifications contain some deviations from the 3GPP standards. Careful evaluation
of these deviations is required in subsequent releases of Push-to-talk specification. These divergences included in the
industry specification do not imply requirements on the 3GPP/OMA standards but the OMA standards work should
follow and be aligned with the 3GPP IMS specifications as much as possible.
A.1 General divergences

This section captures the known divergences from the 3GPP specification.
• IP version
The PoC Release 2.0 specification supports IPv4. IPv6 is optionally supported on Itn and In interfaces.
• Authentication and integrity protection

The PoC Release 2.0 specification supports HTTP digest in place of the IMS-AKA specified by 3GPP.
• Policy control
The PoC Release 2.0 specification does not provide for the support of the IMS headers related to the policy
control (Go interface).
• CSCF discovery
The PoC Release 2.0 specifications describe the parameters which are required to be configured – this includes
the contact address of the SIP proxy which the terminal will communicate with.
• Provisioning of private user ID

The PoC Release 2.0 specifications describes the parameters which are required to be configured – this includes
the private user identifier. In 3GPP this is located on the ISIM or derived from the USIM.
• Floor control
The PoC Release 2.0 specifications describes floor control. There is no suitable floor control standardized
within the industry.
• Group List Management

The PoC Release 2.0 specifications describes a group list management protocol. The group list management
work in 3GPP is still ongoing.
• PoC header extension

The PoC Release 2.0 specifications describes header extensions for identifying that the signaling is related to
the PoC service.
• Initial-, Re- & De-registration procedures

The PoC Release 2.0 specifications do not use all the 3GPP specified SIP header fields and parameters and
additionally the PoC Release 2.0 specifications use PoC specific header fields and parameters.
• Reject and Error Codes in Sessions

The PoC Release 2.0 specifications have specific usage of reject and error codes.
• Conferencing
The overall POC functionality has similarities with currently ongoing 3GPP Rel6 conferencing work. Further
alignments of these two activities are needed.
• Group Identities
The PoC Release 2.0 specification defines a mechanism for creating group identities. 3GPP has not yet
completed the work on group management including handling of group identities and the Ut reference point.
• Presence
The PoC Release 2.0 specification defines a mechanism for interacting with presence. 3GPP has not yet
completed the work on presence. The overall POC functionality has similarities with currently ongoing 3GPP
Rel6 presence work. Further alignments of these two activities are needed..
PoC Architecture
• Implicit subscription to refer state event

The PoC Release 2.0 specifications establish with SIP INVITE method an implicit subscription which is not
specified in 3GPP nor IETF
• Limited number of features

The PoC Release 2.0 specifications will be focusing on a limited number of features (e.g. no multiple sessions)
• Nomenclature
The PoC Release 2.0 specifications will include only the OMA agreed nomenclature updates (partially as
parentheses after the Release 1.0 names)
• Supress NOTIFY
In Early Session setup the immediate NOTIFY which should be sent just after "202 Accepted" to the inviting
UE, showing "100 Trying” in the body will be suppressed.
• Transport of SIP 183 Session Progress

SIP 183 Session Progress is sent unreliable.
A.2 Specific Divergences

This section captures the known divergences from the stage 3 3GPP specification.
• The PoC Release 2.0 specifications do not provide for the support of indication to the UE when a network
initiated de-registration occurs (whatever the reason is)
• The PoC Release 2.0 specifications do not provide for the support of UE to learn the routing path (as the
Service-route header is not supported).
• The PoC Release 2.0 specifications do not provide for the support of UE to subscribe to registration state event
package.
• The PoC Release 2.0 specifications do not provide for the treatment for a P-Media-Authorization header.
• The PoC Release 2.0 specifications do not provide for the support to pass P-Access-Network-Info header for
informing the network about the used access technology.
• The PoC Release 2.0 specifications do not provide for the support to pass P-Called-Party header for
differentiating the used identity in the terminating side. I.e. what identity was used to reach the called party.
• The PoC Release 2.0 specifications do not provide for the support to pass the P-Visited-Network-ID header for
indicating what network was used in IMS roaming case.
• The PoC Release 2.0 specifications do not provide for the support to request to hide the calling party identity
as the Privacy header is not supported.
• The PoC Release 2.0 specifications do not provide support of some further protocol related headers namely P-
Asserted-Identity, P-Associated-URI, P-Charging-Vector and P-Charging-Function-Addresses.
Annex B: E.164 Number Translation (Informative)

The Request-URI in a SIP request line is used to indicate the user or service to which the request is being routed. There
are many standard ways to use the host name in a SIP URI to route SIP requests. If a TEL URL is used, the IMS core
may need to translate the TEL URL to a SIP URI to forward the request between networks. This Annex will provide
informative options that a network operator could use in the IMS core to achieve the translation of a TEL URL to a SIP
URI when routing requests between PoC servers in two different networks. The options provided in this annex are not
exhaustive; there are other methods that could be used to provide E.164 number translation. The goal of this annex is to
provide clarification of a couple of methods for E.164 number translation, but other methods could be utilized as well.
PoC Architecture
Senders identify recipients using one of two designations:
• SIP URI
• MSISDN in a TEL URL
NOTE: This annex uses the terms MSISDN or E.164 number also when the term dial string (this denotes the
actual string of symbols entered by the user) would be more appropriate. The actual meaning follows
from the context
The operator chooses which of these methods are supported in their network domain. Both the principles and
procedures of addressing using the SIP URI and a MSISDN in a TEL URL are described in the following chapters.
B.1 Addressing Using SIP URI

When a PoC user is addressed using a SIP URI from the originator, the originating UE forms a SIP INVITE with the
SIP URI specified. The SIP URI typically has a form such as sip:Jason.Japple@operatorB.net. When the target is
within another operator’s domain, the SIP INVITE is then forwarded to the target IMS core as shown in the Figure 17
below.
Operator A Operator B
sip: Jason.Japple@operatorB.net
INVITE (…SIP URI...) IMS Core INVITE ( SIP URI) IMS Core
sip: Jason.Japple@operatorB.net
Figure 17 Addressing Using SIP URI
B.2 Addressing Using Tel URL

A PoC user can be addressed using a MSISDN. Two methods are identified to accomplish the E.164 translation to an
operator domain, in order to construct a routable SIP URI to another operators network:
• Alt 1: using DNS/Enum Infrastructure
• Alt 2: Using DNS/E.164 translator
Both alternatives assume that the originator specifies the target using an E.164 number. It is also assumed that the
target is addressed using the subscriber’s registered Public User Identity. The operator shall have open DNS capability
in order to perform the translations described in the following chapters.
B.2.1 Alternative 1: DNS/ENUM Translation

Architecture
The architecture for Alternative 1a is shown below.
PoC Architecture
(Target Operator)
3 DNS QUERY
DNS/ENUM
5
DNS QUERY DNS/ENUM
DNS QUERY Response 4
2
DNS QUERY Response
1 IMS Core 6 IMS Core
Sip: INVITE
(…SIP URL: UserB@operatorB.net)
sip: INVITE (…MSISDN…)
Figure 18 Alternative 1a: Translation Using DNS/ENUM Translation
In Alternative 1a, the architecture includes the IMS core networks, and DNS/ENUM services. Once the originating
IMS Core receives the SIP INVITE with MSISDN, a DNS query is performed. In the end, a DNS response is returned
to the originating IMS Core, and the SIP INVITE towards the target network is created using the OperatorB domain
information in the SIP URL. The procedure and specific translation methods that the translator utilizes are outlined
below.
High Level Flow

Step 1: A SIP Invite with MSISDN arrives at the originating IMS Core.
Step 2: The IMS core sends E.164 number to its own DNS for resolution. The DNS makes an attempt to translate the
MSISDN to a SIP URI. If the query is successful, the DNS returns the target user’s SIP address.
Step 3: If the DNS query is not successful, a DNS query is initiated to the target operator DNS.
Step 4: The target DNS translates the MSISDN to a SIP URI. The DNS returns the target user’s SIP address.
Step 5: The originating network DNS returns the target user’s SIP address.
Step 6: The IMS Core constructs a SIP URI containing the User ID and the appropriate network domain name, and
sends the SIP message to the target network.
Architecture with Number Portability

A variant on the architecture presented previously is provided for the case where a user’s number has been ported. This
architecture is presented below in Figure 19.
PoC Architecture
Operator A Operator C NP
(Target Network)
DNS QUERY Response

DNS QUERY DNS/ENUM
3
4
DNS/ENUM
6
Operator B
(Recipient Operator) 5
7
DNS QUERY DNS/ENUM
DNS QUERY Response
Sip: INVITE
(…SIP URL: UserB@operatorB.net)
Figure 19: Alternative1b: Translation Using DNS/ENUM Translation with Number Portability
In Alternative 1b with number portability, the architecture is identical to the Alternative 1a, with the exception of the
additional “donor” network where the subscriber previously was homed. The procedures are similar to the previous
architecture, with the addition of the number portability steps. The procedure and specific translation methods that the
translator utilizes are outlined below.
High Level Flow

Step 2: The IMS core sends E.164 number to its own DNS for resolution. The DNS makes an attempt to translate the
MSISDN to a SIP URI. If the query is successful, the DNS returns the target user’s fully qualified domain name, and
the IMS core constructs a SIP address.
Step 3: If the DNS query is not successful, a DNS query is initiated to the target operator DNS.
Step 4: The target network DNS detects that the number is ported and queries the DNS in the recipient network.
Step 5: The recipient network DNS translates the MSISDN to a SIP URI. The DNS returns the target user’s SIP
address.
Step 6: The target network DNS returns the target user’s SIP address.
Step 7: The originating network DNS returns the target user’s SIP address.
B.2.2 Alternative 2: DNS/E.164 Translator

If ENUM/DNS infrastructure is not available in the originating network, or if ENUM/DNS translation fails, Alternative
2 is suggested as a means to translate MSISDN to a routable domain name. The architecture and process steps to
accomplish this translation are provided in this chapter.
Architecture
PoC Architecture
The architecture for Alternative 2 is shown below.
(Target Operator)
NP SRI_MO_SMS (…MSISDN…)
HLR
3a
DNS/E.164 Translator
3b SRI_MO_SMS (…IMSI…)
3
DNS
3c
4
ENUM QUERY (…MSISDN…)
ENUM QUERY
(…SIP URI: ‘Registered Public User Id”)
2
Sip: INVITE
(…SIP URI: ‘Registered Public User Id”)
Figure 20: Alternative 2: Translation Using DNS/E.164 Translator
In Alternative 1, the architecture includes a DNS to E.164 translator function. This function can query a number of
subscriber information resources, including Number Portability (NP) database, an HLR (using MAP protocol), and
another operator’s DNS service. Once the serving IMS core receives a SIP INVITE, which includes the target’s
MSISDN, the IMS core will query the DNS/E.164 translator function. The translator will utilize various resources to
eventually construct a valid operator B domain. The procedure and specific translation methods that the translator
utilizes are outlined below.
High Level Flow

Step 2: The IMS Core takes the MSISDN and formats and ENUM query and send it to a local DNS/E.164 translator.
Step 3: The DNS/E.164 translator attempts to identify the operator’s domain. The translator may for example be
configured with the operator’s own subs MSISDN, and could hence do an immediate translation of MSISDN to a SIP
URI. If the translation is found, the SIP URI is returned to the S-CSCF.
If the DNS/E.164 translator does not find the MSISDN in the internal DNS DB, it can query one of the associated
resources for translation information. Examples include:
Step 3a: Ask another DB such as a Number Portability DB.
Step 3b: Issuing a MAP query to the recipient’s HLR. By simulating SMS traffic with MAP query containing the
recipients MSISDN number, the HLR will return an Ack with the IMSI and Operator ID that is used to find the domain
part of the SIP URI in the translator’s internal table. The operator ID is mapped in the local translator using a table
containing all remote domains to which messages can be routed.
Step 3c: Query another operator’s DNS. Finish domain construction to locate the actual interrogating CSCF name in
the other operator’s network.
Step 4: The ENUM QUERY response is returned to the IMS core in a SIP URI.
PoC Architecture
PoC Architecture
Annex C: IP addressing considerations (Informative)

Due to the nature of PoC and the fact that PoC uses SIP, the UE, the IMS Core, and the PoC Server have to be in the
same address space. Thus for example, if private IPv4 addresses are used, the UE, P-CSCF, and the PoC Server have to
have an interface in the same private IP address domain. Hence, NAT cannot be used on the Is and It interfaces.
In the inter-connected PoC network case, the inter-connected operators have to be in the same IP address space. In
practise this means that the inter-connection has to use public IP address space. The public IP addresses can be either
IPv4 or IPv6. This annex concentrates on describing the possible scenarios for the IP address domains.
Figure 21 shows a case where the inter-operator network is using IPv4. The operator internal networks can either use
private or public addresses as the operator internal network can basically be isolated from the inter-connect network.
However, in the case of IPv4, typically public IPv4 addresses cannot be allocated to the UEs due address scarcity and
private IPv4 addresses are used instead. The P-CSCF and the PoC Server have interfaces in the same domain as the UE.
The P-CSCF and the PoC server have also interfaces in the same addressing domain as the S-CSCF. The IMS Core has
an element on the border of the intra-operator address space, and the inter-operator address space. That element can be
either an I-CSCF or the S-CSCF that is multihomed.
Figure 21: Inter-operator connectivity with IPv4 (public IPv4 addresses).

Figure 22shows a case where the inter-operator network is using IPv6. The operator internal network IP version and
address space is independent of the inter-operator network IP version as the operator internal network can basically be
PoC Architecture
isolated from the inter-connect network. The P-CSCF and the PoC Server have interfaces in the same domain as the UE.
The P-CSCF and the PoC server have also interfaces in the same addressing domain as the S-CSCF. The IMS Core has
an element on the border of the intra-operator address space, and the inter-operator address space. That element can be
either an I-CSCF or the S-CSCF that is multihomed.
Figure 22: Inter-operator connectivity with IPv6.

As different vendors' equipment may support IPv6 at different times, some operators may not support IPv6 on the NNI
from the beginning. Hence, the interworking between different kinds of deployment has to be assured by choosing the
IP version, which is available.
Practically, IPv4 will be chosen if IPv6 is not available for either end of the communication, otherwise IPv6 is used.
The decision is done between two peers in a communication.
Figure 23 shows an example of an environment where there are users from different environments participating in a
PoC session. In this case, the controlling PoC Server is dual-stack. The session setup is done between the individual
participating server and the controlling server.
PoC Architecture
Figure 23: Example of multi version environment
PoC Architecture
Annex D: Change History (Informative)
Date Subject/Comment Version

2004-06-08 Approved on Mai 12th, 2004. Confidential and Proprietary marking removed 2.0.8
PoC Architecture

1565 MotDoc

Încărcat de

Informații document

Descriere originală:

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

1565 MotDoc

Încărcat de

Drepturi de autor:

Formate disponibile

Architecture V2.0.

Push-to-talk over Cellular (PoC);

Comneon, Ericsson, Motorola, Nokia, Siemens

© Comneon.Ericsson, Motorola, Nokia, Siemens

7.9.1 Charging Models and Mechanisms............................................................................................................ 23

The basic architecture is described in clause 4.

The functional entities of the architecture are described in clause 5.

The interfaces of the architecture are described in clause 6.

High level procedures for presence are described in clause 9.

Annex A lists recognized 3GPP/OMA divergences.

Informative Annex B presents options for E.164 number translation.

IP addressing considerations are in Informative Annex C .

Annex D provides the change history of this document.

This specification has been updated using following assumption:

• For a specific reference, subsequent revisions do not apply.

[1] Push-to-Talk over Cellular User Requirements; PoC Release 2.0

[2] PoC Signaling Flows - UNI; PoC Release 2.0

[3] PoC User Plane; Transport Protocols; PoC Release 2.0

[4] PoC User Plane; (E)GPRS Specification; PoC Release 2.0

[5] PoC List Management and Do-Not-Disturb; PoC Release 2.0

[6] PoC Signaling Flows – NNI; PoC Release 2.0

[7] PoC Presence; PoC Release 2.0

[12] IETF RFC 2616: "Hypertext Transfer Protocol HTTP/1.1"

[13] IETF RFC 3261: "SIP: Session Initiation Protocol"

[15] IETF RFC 3320: “Signaling Compression (SigComp)”

[16] IETF RFC 3321: “Signaling Compression (SigComp) - Extended Operations”

[22] IETF RFC 2486: “The Network Access identifier”.

[23] IETF RFC 2806 “URLs for Telephone Calls”

[25] 3GPP TS 22.141: "Presence service; Stage 1".

[26] 3GPP TS 23.141: “Presence Service; Architecture and Functional Description”

[28] Session Initiation Protocol (SIP) Extensions for Presence, Internet-Draft

[29] A SIP Event Package for List Presence, Internet-Draft, http://search.ietf.org/internet-drafts/draft-

[30] 3GPP TS 33.900 Guide to 3G security

[32] 3GPP TS 23.228 IP Multimedia Subsystem (IMS); Stage 2; Release 5

[35] Analysis on IPv6 Transition in 3GPP Networks, Internet Draft, http://www.ietf.org/internet-

[36] OMA – Enabler Release Definition for Client Provisioning V1.1

3 Definitions and abbreviations

Chat talk session: A talk session established by a chat group talk.

Home PoC Network : PoC network of the served PoC user

Open group: A group that can be joined by any user.

Participant: A PoC user in talk session.

Presentity : A PoC client that provides PoC presence information.

Restricted group: A group that can be joined only by predefined user(s).

Session: A session is considered as an exchange of data between associations of participants.

User: A human using the described features through a terminal device.

AMR Adaptive Multi Rate

PDP Packet Data Protocol

3.3 Requirement vocabulary

Remote PoC Networks

It: Floor Control and media

Figure 1: PoC architecture

See Annex A for a complete list of IMS exceptions.

5 Description of functional entities

5.1 User Equipment (UE)

5.2 IMS Core

- Routes the SIP signaling

o between the UE and the PoC Server,

o between UE and Presence server,

o between different IMS Cores;

- Terminates the SIP compression from the terminal;

- Authentication and authorization;

- Maintains the registration state and the SIP session state;