|
|
OMA Specifications related to SIP / SIMPLE
This page provides the list of OMA specifications related to SIP, SIMPLE, GEOPRIV... IETF RFCs and Internet Drafts.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Related OMA's PDF documents are available at:
http://www.openmobilealliance.org/technical/release_program/Presence_simple_v1_0_1.aspx
|
|
|
|
|
|
|
| | |
OMA-ERELD-
Presence_SIMPLE
Approved Version 1.0.1
28 Nov 2006
(12 p.) |
|
|
Enabler Release Definition for OMA Presence SIMPLE |
This document outlines the Enabler Release Definition for OMA Presence SIMPLE and the respective conformance
requirements for clients and servers claiming compliance to it as defined by Open Mobile Alliance across the specification
baseline.
The OMA Presence SIMPLE Enabler is a service that manages the collection and controlled dissemination of presence
information over mobile networks. |
|
|
|
|
|
|
|
|
|
|
| | |
OMA-AD-
Presence_SIMPLE
Approved Version 1.0.1
28 Nov 2006
(20 p.) |
|
|
Presence SIMPLE Architecture |
The scope of this document is to provide an architecture for the OMA presence service Enabler, which includes a general
network-agnostic model, for mobile presence using the
IETF SIMPLE specifications.
The OMA Presence Enabler is a service that manages the collection and controlled dissemination of presence information
over mobile networks. Multiple standards fora are working on presence. This section describes the OMA Presence Service
and how it relates to similar work of other industry/standards fora.
The IETF has defined protocols and formats for presence in its SIMPLE (SIP Instant Messaging and Presence Leveraging
Extentions) activity (see [RFC3856]). The work of OMA and other fora leverages these standards.
3GPP and 3GPP2 have defined an aligned Presence Service framework in
[3GPP TS 23.141] and [3GPP2 X.S0027-001-0].
This framework has a defined presence reference architecture both in "network layer" and "application layer" meaning that
3GPP and 3GPP2 specifications [3GPP TS 24.141] and [3GPP2 X.P0027-003-0] respectively define end-to-end presence
information flows. The term "network layer" refers to the communication that is required between the Presence Service
functional elements (e.g. Presence Server) and various network elements as they are defined in the network architectures of
3GPP and 3GPP2 (e.g. MSC, HLR). The term "application layer" refers to the communication that is required between the
various Presence Service elements (e.g. Presence Server and Presence Source), which includes the "application layer"
functional entities.
Additionally, there are presence services that exist or can be envisaged that do not leverage core network infrastructure as
defined by 3GPP and 3GPP2. However, those presence services are still relevant to the mobile domain and thus supported by
this architecture.
|
|
|
|
|
|
|
|
|
|
|
| | |
OMA-RD-
Presence_SIMPLE
Approved Version 1.0
25 Jul 2006
(62 p.) |
|
|
Presence SIMPLE Requirements |
|
This document contains use-cases and requirements for a Presence Service, taking into considerations the demands of endusers,
service providers, and system implementers.
|
|
|
|
|
|
|
|
|
|
|
| | |
OMA-TS-
Presence_SIMPLE
Approved Version 1.0.1
28 Nov 2006
(90 p.) |
|
|
Presence SIMPLE Specification |
This document defines an application level specification for the OMA SIP/SIMPLE-based Presence Service.
It defines the
presence information semantics for presence information conveyed using the Presence Information Data Format (PIDF) the
Rich Presence Information Data Format (RPID) and geographical information conveyed in a GEOPRIV location object (see
[RFC4119])
specified by the IETF in conjunction with the overall Presence Data Model defined in
[RFC4479].
This specification makes use of the implementations of the SIP protocol in the 3GPP IMS (IP Multimedia Subsystem) and
3GPP2 MMD (Multimedia Domain) for collecting and disseminating presence information between the various Presence
Sources and their watchers as described in the Presence architecture document
([PRESAD]).
In addition to the SIP methods for subscription, publication, and notification of presence state based on
[RFC3265],
[RFC3856] and
[RFC3903],
this specification also addresses:
|
| - |
The content of presence information, based on
[RFC3863],
[RFC4119],
[RFC4479],
[RFC4480] etc.
|
| - |
The partial publication of (only the changed) presence information, based on [PARFORMAT]
|
| - |
Triggers for the generation of notifications when specific events take place
|
| - |
The handling of large presence information content, based on support of
[RFC2387] and
[RFC4483]
|
| - |
The control of the content of the notification sent to a watcher, based on
[RFC4660] and
[RFC4661]
|
| - |
Back-end subscriptions to a presence list, based on
[RFC4662]
|
| - |
Subscription authorization rules for watchers, based on [PRESXDM], and
|
| - |
Presence content rules for watchers, based on [PRESXDM].
|
|
The Presence Services makes use of various data repositories in the network that store information related to presentities and
watchers, specifically:
|
| - |
The Presence XDMS (see [PRESXDM]) for storage of documents related to a presentity, such as subscription
authorization rules and presence content rules for watchers;
|
| - |
The Shared XDMS (see [SharedXDM]) for URL Lists which may be referenced from other documents;
|
| - |
The RLS XDMS (see [RLSXDM]) for storing a watcher's presence list; and
|
| - |
The Content Server (see [PRESAD]) for managing MIME objects.
|
|
|
|
|
|
|
|
|
|
|
|
| | |
OMA-TS-
Presence_SIMPLE_XDM
Approved Version 1.0.1
28 Nov 2006
(19 p.) |
|
|
Presence XDM Specification |
This specification describes the structure of a particular type of XML document used for watcher authorisation in the
Presence service. As stated in [PRESAD] there are two different
"levels" of a watcher authorisation: subscription
authorisation and presence content authorisation. The former defines if a watcher is allowed to subscribe to a presentity's
presence information, and the latter the limitations in presence information that the watcher can get.
This specification provides the XCAP application usage of the Presence Authorisation Rules. It reuses the document structure
described in [PRESAUTH].
The Presence XDMS (see [PRESAD]) is the logical repository for Presence Authorisation Rules documents. The common
protocol specified in [XDMSPEC] is used for access and manipulation of such Presence Authorisation Rules by authorized
principals.
|
|
|
|
|
|
|
|
|
|
|
| | |
OMA-TS-
Presence_SIMPLE_RLS_XDM
Approved Version 1.0.1
28 Nov 2006
(16 p.) |
|
|
Resource List Server (RLS) XDM Specification |
The RLS XDMS is the repository for XML documents that define services which are associated with a list of resources. An
example of such a service document is a Presence List, which is used by a RLS to subscribe, on behalf of
a watcher, to the presence status of a list of presentities.
The protocol used to access and manipulate such documents is based on the XML Configuration Access Protocol (XCAP),
and described in [XDMSPEC].
This specification provides the XCAP application usage for one type of RLS-specific XML document, the Presence List.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Related OMA's PDF documents are available at:
http://www.openmobilealliance.org/technical/release_program/simple_im_v1_0.aspx
|
|
|
|
|
|
|
| | |
OMA-ERELD-SIMPLE-IM
Candidate Version 1.0
16 Aug 2007
(14 p.) |
|
|
Enabler Release Definition for SIMPLE IM |
This document outlines the Enabler Release Definition for SIMPLE IM version 1.0 and the respective conformance
requirements for SIMPLE IM clients and servers implementations claiming compliance to it as defined by Open Mobile
Alliance across the specification baseline.
Instant Messaging (IM) is a set of capabilities allowing exchange of Instant Messaging messages between users in near realtime,
whether using mobile networks or fixed Internet connections. The SIMPLE IM enabler uses the IETF SIP protocol
[RFC3261] with SIMPLE extensions. SIMPLE IM features are described in terms of actions taken by IM Clients and
Servers. The SIMPLE IM enabler relies on common OMA enablers such as Presence [OMA_Pres], XDM [OMA_X1,
OMA_X2], Device Management Services [OMA_DM] to provide complementary features and capabilities.
|
|
|
|
|
|
|
|
|
|
|
| | |
OMA-AD-SIMPLE_IM
Candidate Version 1.0
16 Aug 2007
(41 p.) |
|
|
Instant Messaging using SIMPLE Architecture |
The scope of this SIP/SIMPLE Instant Messaging Architecture Document (AD) is to define the architecture for the IM
service enabler based on the IETF SIP/SIMPLE specifications.
This document fulfils the requirements for functional capabilities of the SIMPLE IM enabler and proposes a functional
architecture to support this service enabler as described in the Instant Messaging Requirements document [IM-RD]. Within
the context of the OMA Service Environment (OSE), this document defines all functional entities within and external to the
SIMPLE IM enabler and all their reference points.
|
|
|
|
|
|
|
|
|
|
|
| | |
OMA-RD-IM
Candidate Version 1.0
16 Aug 2007
(57 p.) |
|
|
Instant Messaging Requirements |
This document describes use cases of Instant Messaging (IM) in mobile and requirements for a wireless IM solution within
OMA.
The overall goal of this requirements document is to investigate IM service in mobile from service provider, technological
and end-users' demands. This document contributes the development of an IM Solution for OMA.
The overall goals of an OMA IM Solution can be stated as:
|
| - |
Low latency (i.e. as close to real time as possible for an IM message exchange)
|
| - |
Optimized and efficient use of available wireless resources
|
| - |
Interoperability & Interworking with other standardized IM solutions
|
| - |
Security
|
| - |
Mobility
|
| - |
Unrestricted by content type
|
|
Although the technical realization is assumed to be based on SIP/SIMPLE technology, this Requirements Document
describes requirements at a high level, in a technology agnostic way.
|
|
|
|
|
|
|
|
|
|
|
| | |
OMA-TS-SIMPLE_IM
Candidate Version 1.0
16 Aug 2007
(188 p.) |
|
|
Instant Messaging using SIMPLE |
Instant Messaging (IM) is a form of 2-way communications that allows users to exchange information with others in an
interactive nature, i.e., users exchange messages in near real time to engage in conversations. This requires low latency in the
delivery of messages. Typically, text messages are exchanged but this enabler supports content types beyond text.
Communication can be in one-to-one or one-to-many configurations, meaning that the messaging can be between two
individuals or within a group where everyone in the group can see what everyone else is sending. There is no need to
maintain any type of floor control since messages are posted to the individual (or group) in the order they are received, and
can be read as needed.
This specification supports three fundamental modes of IM communication: (1) Pager Mode (2) Large Message Mode and
(3) IM Session Mode. The first is appropriate for brief message exchanges such as announcements with acknowledgements.
The second is for brief message exchanges in which the size of the individual message is large (such as when carrying
multimedia content).The last is similar to a conference hosted by a network where individual users join and leave the group
conversation over time.
This specification allows the IM Service to ride atop a SIP/IP Core Network as a SIP application. One example of such a
network is an IP Multimedia Subsystem (IMS) network but any appropriate SIP network may be used. While the underlying
SIP "infrastructure" is responsible for SIP authentication and routing of SIP messages, all IM specific behaviour is
documented in this specification.
Basic messaging capabilities are augmented with advanced features such as Conversation Storage and Searching. During IM
communication, a record of the users incoming and outgoing messages may be stored as part of a conversation. The IM user
is later able to selectively retrieve messages from within conversations as well as manage their storage. The Search feature in
[XDM-Core] allows users to search through the metadata of stored IM content. Further, the Search feature enables users to
explore the user profiles of others in order to find new people with which to communicate.
Together with companion OMA enablers for Presence Service and XML Document Management, this specification supports
IM services built upon presence and group management to provide a more compelling user experience. In addition, user
group lists may be created that operate across Presence and PoC services as well as IM service.
|
|
|
|
|
|
|
|
|
|
|
| | |
OMA-TS-IM_XDM
Candidate Version 1.0
16 Aug 2007
(23 p.) |
|
|
Instant Messaging XDM Specification |
|
This specification provides Application Usages for IM specific XML documents stored at IM XDMS. IM specific
Application Usages include Conversation History metadata and deferred message metadata.
|
|
|
|
|
|
|
|
|
|
|
| | |
OMA-TS-SIMPLE_IM_Charging
Candidate Version 1.0
16 Aug 2007
(56 p.) |
|
|
OMA SIMPLE IM Charging Specification |
This document specifies the use of OMA Charging Enabler to realise the offline and online charging requirements of OMA
SIMPLE IM Enabler. The OMA Charging Enabler defines a set of interfaces that are utilised by the other Enablers to fulfil
their charging requirements. The interfaces are specified in [OMA-AD-Charging-V1_0]. This document defines how, when
and by which entities charging is triggered and which function invokes charging over the OMA Charging Enabler interfaces.
This document also defines the data that will be exchanged during the process.
This document specifies in detail:
|
| - |
The charging models for the OMA SIMPLE IM enabler,
|
| - |
The logical messages and message types used on CH-1 and CH-2 interfaces,
|
| - |
The flow of messages between the Charging Enabler User and the Charging Enabler with regard to the IM Service
and applicable IM scenarios,
|
| - |
Mapping of the IM parameters to the OMA Charging Data Elements
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Related OMA's PDF documents are available at:
http://www.openmobilealliance.org/technical/release_program/xdm_v1_0_1.aspx
|
|
|
|
|
|
|
| | |
OMA-ERELD-XDM
Approved Version 1.0.1
28 Nov 2006
(15 p.) |
|
|
Enabler Release Definition for XML Document Management |
|
This document outlines the Enabler Release Definition for the XML Document Management (XDM) enabler and the
respective conformance requirements for clients and servers implementing claiming compliance to it as defined by Open
Mobile Alliance across the specification baseline.
|
|
|
|
|
|
|
|
|
|
|
| | |
OMA-AD-XDM
Approved Version 1.0
12 Jun 2006
(19 p.) |
|
|
XML Document Management Architecture |
|
This Architecture Document describes the features and architecture of the OMA XML Document Management enabler.
The XML Document Management defines a common mechanism that makes user-specific service-related information
accessible to the service enablers that need them. Such information is expected to be stored in the network where it can be
located, accessed and manipulated (created, changed, deleted, etc.). XDM specifies how such information will be defined in
well-structured XML documents, as well as the common protocol for access and manipulation of such XML documents. The
XML Configuration Access Protocol (XCAP) [XCAP], as defined by IETF, has been chosen as the common XML Document
Management protocol.
|
|
|
|
|
|
|
|
|
|
|
| | |
OMA-RD-XDM
Approved Version 1.0
12 Jun 2006
(50 p.) |
|
|
XML Document Management Requirements |
This document describes use cases and requirements for the management of information (e.g., URI Lists) that are stored as
documents using an extensible and platform-neutral format that could be used by other OMA service enablers. Therefore, the
requirements contained in this document are limited to these aspects (i.e., the storage, management and re-use of such
documents containing information by other applications).
The privacy of personal data, such as, principal identity is protected according to privacy regulations. However, mechanisms
to obtain the permission of principal (e.g., before they are included in lists that are managed by the XDM enabler) are out of
scope.
The XDM enabler provides mechanisms for principals to specify who can access the data they have stored.
In addition, the owner of a XDM enabler deployment has full access to this data (overriding any principal preferences) for
purposes, such as, administration and maintenance. The application of those administrative rights in relation to principal
preferences may be described in legal or contractual policies, and as such is out of scope for this enabler.
The XDM enabler is designed to support other OMA service enablers and applications. It is envisioned that there will be
multiple enabler specifications to satisfy the requirements in this document.
|
|
|
|
|
|
|
|
|
|
|
| | |
OMA-TS-XDM_Core
Approved Version 1.0.1
28 Nov 2006
(47 p.) |
|
|
XML Document Management (XDM) Specification |
Various OMA enablers such as, Presence, Push to Talk Over Cellular (PoC), Instant Messaging (IM), etc. need support for
access to and manipulation of certain information that are needed by these enablers. Such information is expressed as XML
documents and stored in various document repositories in the network where such documents can be located, accessed and
manipulated (created, changed, deleted) by authorised principals.
This specification defines the common protocol for access and manipulation of such XML documents by authorized
principals. This specification reuses the IETF XML Configuration Access Protocol (XCAP).
XCAP defines:
|
| - |
A convention for describing elements and attributes of an XML document as a HTTP resource, i.e., accessible via an
HTTP URI
|
| - |
A technique for using HTTP GET, PUT and DELETE methods for various document manipulation operations (e.g.,
retrieving/adding/deleting elements/attributes, etc.)
|
| - |
The concept and structure of an XCAP Application Usage by which service or enabler specific documents can be
described
|
| - |
A default authorization policy for accessing and manipulating documents
|
|
This specification also defines a technique by which changes to such XML documents can be conveyed to an XCAP Client.
This reuses an IETF-defined SIP event package by which an XDM Client subscribes to changes to all documents that it
owns.
Common, reusable as well as enabler-specific document formats and associated XCAP application usages are described in
separate specifications (e.g., [SharedXDM]
[POCXDM]
[PRESXDM] and
[RLSXDM]) that make use of the XCAP
protocol specified here for their document management.
|
|
|
|
|
|
|
|
|
|
|
| | |
OMA-TS-XDM_Shared
Approved Version 1.0.1
28 Nov 2006
(19 p.) |
|
|
Shared XDM Specification |
This specification, which is a part of the XML Document Management enabler, describes a particular type of list, the URI
List, which is a convenient way for a principal to group together a number of URIs (e.g., as "Friends", "Family" etc.) or other
resources, where such a list is expected to be reused for a number of different services. Such a list is not enabler-specific and
can be re-used wherever a principal has a need to collectively refer to a group of other end users or resources. For example,
the reference to a list of "Friends" can be an entry in a PoC Group member list (see [PoC_XDM] for details), or be included
in a Presence List (see [RLSXDM] for details).
This specification provides the data schema and application usage of a URI List and Group Usage List. It reuses the
document structure "resource-lists" described in IETF [XCAP_List].
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Related OMA's PDF documents are available at:
http://www.openmobilealliance.org/technical/release_program/xdm_v2_0.aspx
|
|
|
|
|
|
|
| | |
OMA-ERELD-XDM
Candidate Version 2.0
24 Jul 2007
(15 p.) |
|
|
Enabler Release Definition for XML Document Management |
|
The XDM V2.0 enabler defines new functionality that extends XDM to support the OMA SIMPLE Instant Messaging (IM)
V1.0 and Push-to-talk over Cellular (PoC) V2.0 enablers.
To accommodate the needs of these enablers, the following functionality is added in XDM V2.0:
|
| - |
Search for information in documents stored in an XDMS;
|
| - |
Network to Network Interface to enable search and retrieval of information across multiple domains.
|
|
XDM V2.0 inherits the Shared XDMS from XDM V1.0, but renames it as the Shared List XDMS [XDM_List] to
accommodate several new documents that are stored in separate Shared XDMS logical entities:
|
| - |
Group document stored in the Shared Group XDMS [XDM_Group];
|
| - |
User Access Policy document stored in the Shared Policy XDMS [XDM_Policy]; and
|
| - |
User Profile document stored in the Shared Profile XDMS [XDM_Profile].
|
|
The Group and User Access Policy document structures are based on those of the PoC Group and PoC User Access Policy
documents [PoC_XDM], respectively. The XDM 2.0 enabler defines how to handle backwards compatibility with the PoC
V1.0 enabler when the Shared Group XDMS and Shared Policy XDMS are introduced in the network.
|
|
|
|
|
|
|
|
|
|
|
| | |
OMA-AD-XDM
Candidate Version 2.0
24 Jul 2007
(24 p.) |
|
|
XML Document Management Architecture |
|
This document presents an overview of the XML Document Management (XDM) enabler release 2.0. Specifically, it serves
as an introduction to the functionality and architecture (i.e. logical entities and reference points between them) of the XDM
enabler.
|
|
|
|
|
|
|
|
|
|
|
| | |
OMA-RD-XDM
Candidate Version 2.0
24 Jul 2007
(44 p.) |
|
|
OMA XML Document Management Requirements |
This document describes use cases and requirements for the management of information (e.g., URI Lists) that are stored as
documents using an extensible and platform-neutral format that could be used by other OMA service enablers. Therefore, the
requirements contained in this document are limited to these aspects (i.e., the storage, management and re-use of such
documents containing information by other applications).
The privacy of personal data, such as, principal identity is protected according to privacy regulations. However, mechanisms
to obtain the permission of principal (e.g., before they are included in lists that are managed by the XDM enabler) are out of
scope.
The XDM enabler provides mechanisms for principals to specify who can access the data they have stored.
In addition, the owner of a XDM enabler deployment has full access to this data (overriding any principal preferences) for
purposes, such as, administration and maintenance. The application of those administrative rights in relation to principal
preferences may be described in legal or contractual policies, and as such is out of scope for this enabler.
The XDM enabler is designed to support other OMA service enablers and applications. It is envisioned that there will be
multiple enabler specifications to satisfy the requirements in this document.
|
|
|
|
|
|
|
|
|
|
|
| | |
OMA-TS-XDM_Core
Candidate Version 2.0
24 Jul 2007
(63 p.) |
|
|
XML Document Management (XDM) Specification |
|
This document specifies common protocols, data access conventions, common data application usages and functional entities
that are needed to provide XDM services to other enablers. Such enablers can utilize this specification to support any
required application-specific usages.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| | |
OMA-TS-XDM_Shared_Group
Candidate Version 1.0
24 Jul 2007
(39 p.) |
|
|
Shared Group XDM Specification |
|
This specification describes the data format and Application Usage for the Group document, which is a common group
definition that can be used by all OMA enablers (e.g. PoC and IM). It also defines the data format for the Extended Group
Advertisement and procedures for the Shared Group XDMS to send Extended Group Advertisements.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| | |
OMA-TS-XDM_Shared_Policy
Candidate Version 1.0
24 Jul 2007
(19 p.) |
|
|
Shared Policy XDM Specification |
|
This specification describes the data format and Application Usage for the User Access Policy document, which is a common
user access policy definition that can be used by all OMA enablers (e.g. PoC and IM).
|
|
|
|
|
|
|
|
|
|
|
| | |
OMA-TS-XDM_Shared_Profile
Candidate Version 1.0
24 Jul 2007
(28 p.) |
|
|
Shared Profile XDM Specification |
This specification describes the data format and Application Usage for the User Profile document, which can be used by all
OMA enablers.
The User Profile document contains user information that is stored in the network. Typical ways to use it are through search
queries to discover communication partners (e.g.chat) or through requests to obtain information about a specific user.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Related OMA's PDF documents are available at:
http://www.openmobilealliance.org/technical/release_program/poc_v1_0.aspx
|
|
|
|
|
|
|
| | |
OMA-ERELD-PoC
Approved Version 1.0.2
5 Sep 2007
(21 p.) |
|
|
Enabler Release Definition for Push-to-Talk over Cellular |
This document outlines the Enabler Release Definition for Push To Talk over Cellular (PoC) version 1.0 and the respective
conformance requirements for clients and servers implementing claiming compliance to it as defined by Open Mobile
Alliance across the specification baseline.
Push To Talk over Cellular (PoC) service is a two-way form of communications that allows users to engage in immediate
communication with one or more users. POC service is similar to a "walkie-talkie" application in the way that by pressing a
button a talk session with an individual user or a broadcast to a group of participants is initiated. Receiving participants hear
the sender's voice either without any action on their part (auto-answer mode), or may be notified and has to accept the call
(manual answer mode) before listening to the sender's voice. In addition, the PoC service provides 2 models for PoC Session
establishment: the Pre-established Session mode and the On-demand Session mode. The communication is half-duplex,
meaning that one person can talk at a time and all other participants hear the speech. The permission for talk right granting is
controlled via the floor control mechanism.
The PoC service enabler supports the
|
| - |
1-1 PoC Session which is the basic capability to set up voice communication between two users
|
| - |
1-to-many PoC Session which is the capability to enable the setup a voice communication with a multiple
number of other PoC Subscribers in an ad-hoc or pre-defined group manner
|
| - |
Instant Personal Alert which is the capability to inform about the calling user's wish to communicate and the
request the invited user to "call-back".
|
|
The PoC service enabler utilizes basic inter-working with the Group Management service enabler and the Presence service
enabler. Key features to these enablers are e.g. group lists creation and management functions, group sessions emulating
conferencing on demand and integration of user's presence & availability information in the session setup process.
Complementing the basic PoC service, Group Advertisement is available to inform PoC Group members about the existence
and the membership of the group
|
|
|
|
|
|
|
|
|
|
|
| | |
OMA-AD-PoC
Approved Version 1.0.2
5 Sep 2007
(157 p.) |
|
|
Push to talk over Cellular (PoC) - Architecture |
|
The scope of the Push to talk over Cellular (PoC) architecture document is to define the architecture for the PoC service
enabler. This architecture is based on the requirements listed for the system in the PoC requirements document [PoC RD
V1.0].
The architecture of the SIP/IP Core and the underlying access network for PoC is out of scope of this document. When SIP/IP
Core corresponds to the 3GPP IMS the architecture the 3GPP enablers for OMA PoC services are described in
[3GPP TR 23.979].
|
|
|
|
|
|
|
|
|
|
|
| | |
OMA-RD-PoC
Approved Version 1.0
9 Jun 2006
(75 p.) |
|
|
Push to Talk over Cellular Requirements |
This Requirement Document (RD) defines the requirements for the Push to Talk over Cellular. This document captures the
overall service description, primarily from the service subscriber's and user's points of view, but its scope does not include the
details of the human interface itself. The information contained in this RD is applicable to network operators, service
providers and terminal and infrastructure manufacturers.
This RD contains the core requirements for the Push to Talk over Cellular enabler as specified by OMA. By means of this
enabler, together with other OMA service enablers, a service provider SHALL be able to provide a complete service.
The term PoC in this document refers to the Push to Talk over Cellular enabler offered via an OMA compatible environment.
|
|
|
|
|
|
|
|
|
|
|
| | |
OMA-TS-PoC-ControlPlane
Approved Version 1.0.2
5 Sep 2007
(274 p.) |
|
|
OMA PoC Control Plane |
|
This document defines the Control Plane signaling procedures of the PoC Client and PoC Server for Push to Talk over
Cellular (PoC) service. Example detailed signaling flows for the reference points POC-1, POC-2 and IP-1 are also included in
this specification.
This Control Plane specification is based on the procedures specified in [OMA-PoC-AD] "High level procedures".
|
|
|
|
|
|
|
|
|
|
|
| | |
OMA-TS-PoC-UserPlane
Approved Version 1.0.2
5 Sep 2007
(177 p.) |
|
|
PoC User Plane |
|
This document describes the User Plane signaling procedures for the Push to Talk over Cellular (PoC) service over the POC-
3 and the POC-4 reference points as defined in [OMA-POC-AD].
When necessary, interworking between the Control Plane [OMA-POC-CP] and the User Plane is described in this document.
This specification does not specify the underlying SIP / IP Core, its features and functions. However, some parts of the
specification may place requirements on the implementation of SIP / IP Core.
|
|
|
|
|
|
|
|
|
|
|
| | |
OMA-TS-PoC_XDM
Approved Version 1.0.2
5 Sep 2007
(26 p.) |
|
|
PoC XDM Specification |
|
This specification provides the data schema and application usages for PoC-specific documents. PoC XDM Application
Usages include that for PoC Groups and PoC User Acess Policy.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Related OMA's PDF documents are available at:
http://www.openmobilealliance.org/technical/release_program/poc_v2_0.aspx
|
|
|
|
|
|
|
| | |
OMA-ERELD-PoC
Candidate Version 2.0
2 Oct 2007
(28 p.) |
|
|
Enabler Release Definition for Push to talk over Cellular |
|
This document outlines the Enabler Release Definition for Push to talk over Cellular (PoC) version 2.0 and the respective
conformance requirements for PoC Clients and PoC Servers implementation claiming compliance as defined by Open Mobile
Alliance across the specification baseline.
|
|
|
|
|
|
|
|
|
|
|
| | |
OMA-AD-PoC
Candidate Version 2.0
2 Oct 2007
(54 p.) |
|
|
Push to talk over Cellular (PoC) - Architecture |
The scope of the Push to talk over Cellular (PoC) V2.0 architecture document is to define the architecture for the PoC
Enabler V2.0. This architecture is backward compatible with the [OMA PoC V1.0 AD]. The architecture is based on the
requirements listed for the system in the PoC requirements document [OMA PoC V1.0 RD] and [OMA PoC V2.0 RD].
The architecture of the SIP/IP Core and the underlying access network for PoC is out of scope of this document. When SIP/IP
Core corresponds to the 3GPP IMS, the architecture and the 3GPP enablers for OMA PoC services are described in [3GPP
TR 23.979].
System concepts and high-level procedures are described in [OMA PoC V2.0 SD].
|
|
|
|
|
|
|
|
|
|
|
| | |
OMA-RD-PoC
Candidate Version 2.0
2 Oct 2007
(95 p.) |
|
|
Push to talk over Cellular 2 Requirements |
The intention of PoC V2.0 Requirement Document (RD) is to define the requirements for the Push to talk over Cellular
services beyond those requirements created for PoC as developed in OMA [OMA PoC RD 1.0]. As stated in PoC V2.0 Work
Item Document (WID), the following will be covered in this RD:
|
| 1. |
Interworking between PoC domains and non-PoC domains
|
| 2. |
Machine-to-user PoC Session
|
| 3. |
Automatic PoC Session initiated by outside applications
|
| 4. |
Seamless interaction between PoC and other enablers (e.g., instant messaging, VoIP)
|
| 5. |
Use of a variety of media formats to provide enhanced user experience within PoC (e.g., video)
|
|
|
|
|
|
|
|
|
|
|
|
| | |
OMA-TS-PoC_ControlPlane
Candidate Version 2.0
2 Oct 2007
(527 p.) |
|
|
OMA PoC Control Plane |
|
This document defines the Control Plane signaling procedures of the PoC Client, the PoC Box and the PoC Server for Push to
talk over Cellular (PoC) service. Example detailed signaling flows for the reference points POC-1, POC-2, POC-9, POC-11
and IP-1 are also included in this specification.
This Control Plane specification is based on the procedures specified in [OMA-PoC-SD].
| |
|
|
|
|
|
|
|
|
|
|
|
| | |
OMA-TS-PoC_UserPlane
Candidate Version 2.0
2 Oct 2007
(268 p.) |
|
|
PoC User Plane |
This document describes the User Plane signalling procedures for the Push to talk over Cellular (PoC) service over the POC-
3, POC-4, POC-10 and POC-12 reference points as defined in [OMA-PoC-AD] using the Media Burst Control Protocol
(MBCP). This specification version is applicable, if the corresponding CP specification version is used as described in
[OMA-PoC-CP] "Backward compatibility".
The Talk Burst Control Protocol (TBCP) can be used for PoC Speech and is specified in [OMA-PoC-1-UP].
When necessary, the interworking between the Control Plane [OMA-PoC-CP] and the User Plane is described in this
document.
| |
|
|
|
|
|
|
|
|
|
|
|
| | |
OMA-TS-PoC_
Document_Management
Candidate Version 2.0
2 Oct 2007
(31 p.) |
|
|
OMA PoC Document Management |
|
This specification describes the documents used by the PoC Enabler, including description of the PoC Enabler specific usage
of data formats and XCAP Application Usages defined in the XDM Enabler. Additionally, this document specifies PoC
Enabler specific deviations and extensions to the XDM Enabler documents.
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| | |
OMA-TS-PoC_
Interworking_Service
Candidate Version 2.0
2 Oct 2007
(17 p.) |
|
|
PoC Interworking Service |
The present document provides the PoC Service Interworking specification by means of endorsement of the OMA-TSPOC-
ControlPlane-V2 "OMA PoC Control Plane", OMA-TS-POC-UserPlane-V2 "OMA PoC User Plane" and OMATS-
XDM_Core-V2 "XML Document Management (XDM) Specification" and documentation of applicability and
exception thereof in line with the requirements for PoC Interworking Service [OMA-POC-RD].
The present document is applicable to the PoC Interworking Function and PoC Interworking Agent providing PoC
Interworking Service functionality.
| |
|
|
|
|
|
|
|
|
|
|
|
| | |
OMA-TS-PoC_
Invocation_Descriptor
Candidate Version 2.0
2 Oct 2007
(27 p.) |
|
|
PoC Invocation Descriptor |
The OMA PoC Invocation Descriptor specification defines the syntax and semantics of the PoC Invocation Descriptor
and also the behaviour of the UE when it receives a PoC Invocation Descriptor. The behaviour of the Web server is
outside the scope of this document.
The provisioning of the security related parameters such as white list data for server authorization is out of scope. The
intended audience of this specification are implementers of PoC Client and the content developers on the Web servers, as
well as other people who have some in-depth interest in the PoC invocation from browsing. It is not intended to be a
tutorial.
| |
|
|
|
|
|
|
|
|
|
|
|
| | |
OMA-TS-PoC_
System_Description
Candidate Version 2.0
2 Oct 2007
(297 p.) |
|
|
OMA PoC System Description |
The scope of the Push to talk over Cellular (PoC) V2.0 system description document is to define the system concepts and
high level procedures for the PoC service enabler V2.0. This system description is backward compatible with the PoC AD
V1.0 of clause 8 and 9 of [PoC AD V1.0]. It is based on the requirements listed for the system in the PoC requirements
document [PoC RD V1.0] and [PoC RD V2.0].
The system description of the SIP/IP Core and the underlying access network for PoC is out of scope of this document. When
SIP/IP Core corresponds to the 3GPP IMS the architecture the 3GPP enablers for OMA PoC services are described in [3GPP
TR 23.979].
Local policies referred in this document are out of scope of this specification.
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Related OMA's PDF documents are available at:
http://www.openmobilealliance.org/technical/release_program/ims_v1_0.aspx
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| | |
OMA-AD-IMS
Approved Version 1.0
9 Aug 2005
(33 p.) |
|
|
Utilization of IMS capabilities Architecture |
Within the framework of the OMA Service Environment (OSE) [OSE], this Architecture Document (AD) identifies a set of
capabilities within the IP Multimedia Subsystem (IMS) as defined by 3GPP and 3GPP2 that can be utilized for the OMA
service enabler implementations.
The scope of the IMS in OMA AD is to show, for OMA enablers realised on IMS, how they should use IMS and how they
should interface with IMS in a consistent way. Furthermore, the AD describes interoperability and/or interworking of OMA
enablers realized on IMS with other OMA enablers (either IMS realized or not).
Although targeted at implementers of OMA enablers, the information contained in this AD is also targeted at OMA working
groups that are developing service enablers that may be realized using IMS capabilities.
This AD describes how OMA service enabler implementations interface with an underlying IP Multimedia Subsystem (as
specified by 3GPP/3GPP2) in order to ensure interoperability.
This document provides guidance and support for the implementation of service enablers utilizing IMS capabilities in order
to meet the requirements given in the corresponding Requirements Document, ref. [IMS in OMA R].
| |
|
|
|
|
|
|
|
|
|
|
|
| | |
OMA-RD-IMSinOMA
Approved Version 1.0
9 Aug 2005
(15 p.) |
|
|
Utilization of IMS capabilities Requirements |
The scope of the IMS WI is to show, for OMA enablers realised on IMS, how they should use IMS and how they should
interface with IMS in a consistent way, whilst not breaking the principle of interoperability and/or interworking with both
other (IMS realized or not) enablers and non-IMS networks.
The information contained in this RD is applicable for OMA working groups that are developing service enablers that might
be realized using IMS capabilities, since it is targeted to implementers of such enablers.
This RD contains system level requirements to ensure interoperability between OMA service enabler realizations and an
underlying IP Multimedia Subsystem (as specified by 3GPP/3GPP2).
The requirements on specific OMA service enablers are not affected by this RD and are handled by the individual OMA
working groups as usual.
The requirements provided in this RD are oriented towards the recommendations given in the "Technical report on the usage
of 3GPP/3GPP2 IMS in OMA" [TR_IMSinOMA].
| |
|
|
|
|
|
