Sunteți pe pagina 1din 49

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

3

Architecture V2.0.8 (2004-06)

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

4

Architecture V2.0.8 (2004-06)

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

5

Architecture V2.0.8 (2004-06)

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

6

Architecture V2.0.8 (2004-06)

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

7

Architecture V2.0.8 (2004-06)

[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

8

Architecture V2.0.8 (2004-06)

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,

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.

,7.

If the decoder specifies such mode set, the encoder MUST abide by the request and MUST

PoC Architecture

9

Architecture V2.0.8 (2004-06)

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

10

Architecture V2.0.8 (2004-06)

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

11

Architecture V2.0.8 (2004-06)

4

Architecture

The PoC functional architecture is outlined in Figure 1.

UE

OTAP

IMS Core

architecture is outlined in Figure 1. UE OTAP IMS Core ACCESS NETWOR K Io Remote PoC

ACCESS NETWORK

Io

Remote PoC Networks
Remote PoC Networks
Remote PoC Networks

Remote PoC Networks

Remote PoC Networks
Remote PoC Networks
Remote PoC Networks

Ips

Presence

Server

Ipl Im GLMS Ik Is If
Ipl
Im
GLMS
Ik
Is
If

It

PoC Server

Itn

Server Ipl Im GLMS Ik Is If It PoC Server Itn In It: Floor Control and
Server Ipl Im GLMS Ik Is If It PoC Server Itn In It: Floor Control and

In

Server Ipl Im GLMS Ik Is If It PoC Server Itn In It: Floor Control and

It: Floor Control and media Itn: Floor Control and media Is: PoC Client to Proxies Session Signaling If: Proxy to PoC Server Session Signaling In: Proxy to Proxy Session Signaling Im: Group Mgmt to PoC Client Ik:Group Mgmt to PoC Server

Bold box identifies PoC functional entities

Remote PoC Network contains the same network elements and reference points as 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

12

Architecture V2.0.8 (2004-06)

- 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

13

Architecture V2.0.8 (2004-06)

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.

Participating Controlling POC POC 1:1 1:1 Function A Function Participating 1:1 POC Function B
Participating
Controlling
POC
POC
1:1
1:1
Function A
Function
Participating
1:1
POC
Function B
Participating Controlling POC POC 1:1 1:1 Function A Function Participating 1:1 POC Function B UE A

UE A

UE B

1:1
1:1

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

14

Architecture V2.0.8 (2004-06)

Network A Controlling 1:1 Participating 1:1 UE A POC POC Function A Function Participating UE
Network A
Controlling
1:1
Participating
1:1
UE A
POC
POC
Function A
Function
Participating
UE B
1:1
POC
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

Network A participating in the PoC Group Session. UE Bj (j=1

participating in the PoC Group Session .The grey underground areas identify a particular administrative domain.

is one of the PoC enabled UE in Network B

is one of the PoC enabled UE in

N)

M)

PoC Architecture

15

Architecture V2.0.8 (2004-06)

1:N Network X Controlling POC Function 1:M Network A Participating POC Function A UE Ai
1:N Network X Controlling POC Function 1:M Network A Participating POC Function A UE Ai
1:N Network X Controlling POC Function 1:M Network A Participating POC Function A UE Ai
1:N Network X Controlling POC Function 1:M Network A Participating POC Function A UE Ai
1:N Network X Controlling POC Function 1:M Network A Participating POC Function A UE Ai

1:N

1:N Network X Controlling POC Function 1:M Network A Participating POC Function A UE Ai Network

Network X

Controlling

POC

Function

1:N Network X Controlling POC Function 1:M Network A Participating POC Function A UE Ai Network
1:N Network X Controlling POC Function 1:M Network A Participating POC Function A UE Ai Network

1:M

1:N Network X Controlling POC Function 1:M Network A Participating POC Function A UE Ai Network
1:N Network X Controlling POC Function 1:M Network A Participating POC Function A UE Ai Network
1:N Network X Controlling POC Function 1:M Network A Participating POC Function A UE Ai Network
1:N Network X Controlling POC Function 1:M Network A Participating POC Function A UE Ai Network
1:N Network X Controlling POC Function 1:M Network A Participating POC Function A UE Ai Network
1:N Network X Controlling POC Function 1:M Network A Participating POC Function A UE Ai Network

Network A

Participating

POC

Function A

POC Function A

UE Ai

Network A Participating POC Function A UE Ai
Network A Participating POC Function A UE Ai Network B Participating POC UE Bj    
Network A Participating POC Function A UE Ai Network B Participating POC UE Bj    

Network B

Participating

POC

UE Bj

         
         
   
         
         
     
       

Function B

1:1

1:1

1:1

1:1

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

16

Architecture V2.0.8 (2004-06)

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 procedures defined in [2] to support the PoC features defined in [1].

PoC Architecture

This communication includes the SIP

17

Architecture V2.0.8 (2004-06)

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

18

Architecture V2.0.8 (2004-06)

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

19

Architecture V2.0.8 (2004-06)

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

20

Architecture V2.0.8 (2004-06)

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

21

Architecture V2.0.8 (2004-06)

- 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

22

Architecture V2.0.8 (2004-06)

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

23

Architecture V2.0.8 (2004-06)

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

24

Architecture V2.0.8 (2004-06)

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

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

25

Architecture V2.0.8 (2004-06)

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

26

Architecture V2.0.8 (2004-06)

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

27

Architecture V2.0.8 (2004-06)

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 UE B PoCS B PoCS A 1. REFER 2.
Controlling /
Participating
Participating
UE A
UE B
PoCS 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

28

Architecture V2.0.8 (2004-06)

Controlling / Participating Participating UE A UE B PoCS B PoCS A 1. REFER 2.
Controlling /
Participating
Participating
UE A
UE B
PoCS B
PoCS A
1. REFER
2. 202 ACCEPTED
3. INVITE
4. INVITE
6. 180 Ringing
5.180 Ringing
Floor granted
8. 200 OK
Floor taken
7. 200 OK
Floor taken
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

29

Architecture V2.0.8 (2004-06)

Controlling / Participating Participating UE A UE B PoCS B PoCS A 1. REFER 2.
Controlling /
Participating
Participating
UE A
UE B
PoCS 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 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 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.

8 The Controlling PoC Server A sends a SIP ACK request to the Participating PoC Server 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.

11 UE A sends the SIP 200 OK (NOTIFY) response to the Controlling PoC Server A.

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

30

Architecture V2.0.8 (2004-06)

Controlling /

Participating

PoCS A

Participating

PoCS B

UE A
UE A
UE B
UE B
Floor taken Media
Floor taken
Media

1. INVITE

2. INVITE 3. 200 OK (INVITE)

B Floor taken Media 1. INVITE 2. INVITE 3. 200 OK (INVITE) 4. 200 OK (INVITE)

4. 200 OK (INVITE)

1. INVITE 2. INVITE 3. 200 OK (INVITE) 4. 200 OK (INVITE) Floor granted Floor taken
1. INVITE 2. INVITE 3. 200 OK (INVITE) 4. 200 OK (INVITE) Floor granted Floor taken

Floor granted

INVITE 3. 200 OK (INVITE) 4. 200 OK (INVITE) Floor granted Floor taken Media Media 6.

Floor taken

200 OK (INVITE) 4. 200 OK (INVITE) Floor granted Floor taken Media Media 6. NOTIFY 5.

Media

(INVITE) 4. 200 OK (INVITE) Floor granted Floor taken Media Media 6. NOTIFY 5. ACK 7

Media

4. 200 OK (INVITE) Floor granted Floor taken Media Media 6. NOTIFY 5. ACK 7 200

6.

NOTIFY

OK (INVITE) Floor granted Floor taken Media Media 6. NOTIFY 5. ACK 7 200 OK (NOTIFY)

5. ACK

Floor granted Floor taken Media Media 6. NOTIFY 5. ACK 7 200 OK (NOTIFY) Figure 8:

7 200 OK (NOTIFY)

Floor taken Media Media 6. NOTIFY 5. ACK 7 200 OK (NOTIFY) Figure 8: No Early
Floor taken Media Media 6. NOTIFY 5. ACK 7 200 OK (NOTIFY) Figure 8: No Early

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 between the UE A and the Participating PoC Server A.

2 Controlling PoC Server A sends a SIP INVITE request to the Participating PoC Server B.

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.

5 The Controlling PoC Server A sends a SIP ACK request to the Participating PoC Server B.

6 The Controlling PoC Server A sends UE A a SIP NOTIFY request 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.

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

31

Architecture V2.0.8 (2004-06)

Controlling / Participating Participating UE A UE B PoCS B PoCS A 1.INVITE 2. INVITE
Controlling /
Participating
Participating
UE A
UE B
PoCS B
PoCS A
1.INVITE
2. INVITE
5. 202 ACCEPTED
3.183
4. INVITE
6. 200 OK
Floor granted
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

32

Architecture V2.0.8 (2004-06)

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 / Participating Participating UE A UE B PoCS B PoCS A 1. INVITE 2.
Controlling /
Participating
Participating
UE A
UE B
PoCS B
PoCS A
1.
INVITE
2. INVITE
3. INVITE
6. 180 Ringing
5. 180 Ringing
4.
180 Ringing
9.
200 OK
Floor granted
8. 200 OK
Floor taken
7.
200 OK
Floor taken
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

33

Architecture V2.0.8 (2004-06)

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

34

Architecture V2.0.8 (2004-06)

Participating Controlling Participating Participating UE A UE B1 UE B2 PoCS A PoCS PoCS B1
Participating
Controlling
Participating
Participating
UE A
UE B1
UE B2
PoCS A
PoCS
PoCS B1
PoCS B2
1.
INVITE
2.
INVITE
3. INVITE
4.INVITE
5.
INVITE
6. 183
7.
INVITE
9. 202 Accepted
Floor granted
Media
8. 202 Accepted
Floor granted
Media
11. 200 OK
10.
200 OK
12. ACK
13.
ACK
Floor taken
Floor taken
15. NOTIFY
14. NOTIFY
Media
Media
16.
200 OK
17.
200 OK
19. 180 Ringing
18.
180 Ringing
20.
200 OK
21. 200 OK
22. ACK
23.
ACK
25. NOTIFY
24.
NOTIFY
Floor taken
26. 200 OK
27. 200 OK
Floor taken
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 B 1 ’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 B 2 ’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 B 1 . (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

35 Architecture V2.0.8 (2004-06) Participating Controlling Participating Participating UE A UE B1 UE B2 PoCS
35
Architecture V2.0.8 (2004-06)
Participating
Controlling
Participating
Participating
UE A
UE B1
UE B2
PoCS A
PoCS
PoCS B1
PoCS B2
1. INVITE
2.
INVITE
3. INVITE
4. 183
5. INVITE
7. 202 Accepted
Floor granted
Media
6. 202 Accepted
Floor granted
Media
9. 200 OK
10. ACK
8. 200 OK
11. ACK
Floor taken
Floor taken
13. NOTIFY
12. NOTIFY
Media
Media
14. 200 OK
15.
200 OK
16. INVITE
17.INVITE
18. 200 OK
19. 200 OK
21.
NOTIFY
20. NOTIFY
Floor taken
23.
200 OK
22. 200 OK
Floor taken
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 B 1 ’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 B 2 ’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 B 1 . (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

36

Architecture V2.0.8 (2004-06)

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
Participating
Controlling
UE A
PoCS A
PoCS
1.
INVITE
2. INVITE
4.200 OK
3. 200 OK
Floor granted /
Floor taken
Media
Floor granted /
Floor taken
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

37

Architecture V2.0.8 (2004-06)

Local Local PoCS A PoCS B UE A UE B MESSAGE MESSAGE 200 OK 200
Local
Local
PoCS A
PoCS B
UE A
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
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

38

Architecture V2.0.8 (2004-06)

UE A

RLS

UE B Presence Server

UE A

UE A

UE B

1.SUBSCRIBE

UE A RLS UE B Presence Server UE A UE B 1.SUBSCRIBE 2.200 OK 3.SUBSCRIBE 4.200

2.200 OK

UE A RLS UE B Presence Server UE A UE B 1.SUBSCRIBE 2.200 OK 3.SUBSCRIBE 4.200

3.SUBSCRIBE

B Presence Server UE A UE B 1.SUBSCRIBE 2.200 OK 3.SUBSCRIBE 4.200 OK 5.NOTIFY 6.200 OK

4.200

OK

Server UE A UE B 1.SUBSCRIBE 2.200 OK 3.SUBSCRIBE 4.200 OK 5.NOTIFY 6.200 OK 7.NOTIFY 8.200

5.NOTIFY

UE A UE B 1.SUBSCRIBE 2.200 OK 3.SUBSCRIBE 4.200 OK 5.NOTIFY 6.200 OK 7.NOTIFY 8.200 OK

6.200 OK

7.NOTIFY

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
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

8.200 OK

9.PUBLISH

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
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

10.200 OK

11.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:
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:

12.200 OK

13.NOTIFY

8.200 OK 9.PUBLISH 10.200 OK 11.NOTIFY 12.200 OK 13.NOTIFY 14.200 OK Figure 16: Subscription to Presence
8.200 OK 9.PUBLISH 10.200 OK 11.NOTIFY 12.200 OK 13.NOTIFY 14.200 OK Figure 16: Subscription to Presence

14.200 OK

9.PUBLISH 10.200 OK 11.NOTIFY 12.200 OK 13.NOTIFY 14.200 OK Figure 16: Subscription to Presence Information 1.

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

different network) it sends a SUBSCRIBE on behalf of UE A for the presence information of UE B to UE B’s home network.

a

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

39

Architecture V2.0.8 (2004-06)

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

40

Architecture V2.0.8 (2004-06)

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

41

Architecture V2.0.8 (2004-06)

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.

to the target IMS core as shown in the Figure 17 below. Operator A IMS Core
Operator A IMS Core INVITE ( SIP URI) sip: Jason.Japple@operatorB.net
Operator A
IMS Core
INVITE ( SIP URI)
sip: Jason.Japple@operatorB.net
IMS Core INVITE ( SIP URI) sip: Jason.Japple@operatorB.net Operator B sip: Jason.Japple@operatorB.net INVITE (…SIP

Operator B

sip: Jason.Japple@operatorB.net
sip: Jason.Japple@operatorB.net

INVITE (…SIP URI

)

IMS Core

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

42

Architecture V2.0.8 (2004-06)

Operator A Operator B (Target Operator)
Operator A Operator B (Target Operator)
Operator A Operator B (Target Operator)
Operator A Operator B (Target Operator)
Operator A Operator B (Target Operator)
Operator A Operator B (Target Operator)
Operator A Operator B (Target Operator)

Operator A

Operator A
Operator A
Operator A

Operator B

(Target Operator)
(Target Operator)

(Target Operator)

Operator A Operator B (Target Operator)
Operator A Operator B (Target Operator)
Operator A Operator B (Target Operator)
Operator A Operator B (Target Operator)
Operator A Operator B (Target Operator)
Operator A Operator B (Target Operator)
Operator A Operator B (Target Operator)
Operator A Operator B (Target Operator)
Operator A Operator B (Target Operator)
Operator A Operator B (Target Operator)
Operator A Operator B (Target Operator)
Operator A Operator B (Target Operator)
3 DNS QUERY DNS/ENUM 5 DNS/ENUM DNS QUERY DNS QUERY Response 4 2 DNS QUERY
3 DNS QUERY
DNS/ENUM
5
DNS/ENUM
DNS QUERY
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

43

Architecture V2.0.8 (2004-06)

Operator A Operator C (Target Network)
Operator A Operator C (Target Network)
Operator A Operator C (Target Network)
Operator A Operator C (Target Network)

Operator A

Operator A
Operator A
Operator A

Operator C

(Target Network)
(Target Network)
(Target Network)

(Target Network)

Operator A Operator C (Target Network)
Operator A Operator C (Target Network)
NP DNS/ENUM 4 5 DNS/ENUM
NP
DNS/ENUM
4
5
DNS/ENUM

IMS Core

DNS QUERY Response DNS QUERY 3 6 Operator B
DNS QUERY Response
DNS QUERY
3
6
Operator B
DNS/ENUM 7 DNS QUERY Response 2
DNS/ENUM
7
DNS QUERY Response
2
DNS QUERY 1 IMS Core 8 Sip: INVITE (…SIP URL: UserB@operatorB.net) sip: INVITE (…MSISDN…)
DNS QUERY
1 IMS Core
8
Sip: INVITE
(…SIP URL: UserB@operatorB.net)
sip: INVITE (…MSISDN…)

(Recipient Operator)

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 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 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.

Step 8: 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.

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

44

Architecture V2.0.8 (2004-06)

The architecture for Alternative 2 is shown below. Operator A Operator B (Target Operator) NP
The architecture for Alternative 2 is shown below.
Operator A
Operator B
(Target Operator)
NP
SRI_MO_SMS (…MSISDN…)
HLR
3a
DNS/E.164 Translator
3b
SRI_MO_SMS (…IMSI…)
3
DNS
3c
4