3GPP TR 24.841 V6.0.0：基于SIP的3G核心网络存在服务功能模型

需积分: 9 138 浏览量更新于2024-07-19 收藏 3.04MB DOC 举报

3GPP TR 24.841 V6.0.0 (2004-06) 是由3rd Generation Partnership Project (3GPP) 的 Technical Specification Group Core Network (TSG CN) 发布的一份技术报告。这份文档聚焦于在Release 6背景下基于Session Initiation Protocol (SIP) 的 Presence 服务功能模型、信息流以及协议细节的阐述。3GPP TR 24.841旨在为3GPP的未来工作提供指导，特别是在 Universal Mobile Telecommunications System (UMTS) 和 IP Multimedia Subsystem (IMS) 的融合环境中，其中SIP作为一种关键的通信协议被用于实现用户在线状态的实时更新和共享。该文档详细地探讨了如何通过SIP来构建一个可靠的网络环境，支持Presence服务，即让用户能够得知其他人在网络中的在线情况。它可能包括了对SIP信令流程的深入解析，如INVITE请求与UPDATE响应之间的交互，以及如何通过IMS架构实现多接入点间的无缝通信。此外，文档还可能涵盖了安全性和QoS（Quality of Service）管理，确保在大规模移动网络中提供稳定且高效的服务。值得注意的是，这份规范并非正式的3GPP标准，也没有经过组织合作伙伴的审批，因此不能直接应用于实际系统部署。如果需要实施3GPP系统的相关规格和报告，用户应从3GPP的官方出版机构获取。版权方面，任何未经授权的复制或分发都是不被允许的，且3GPP提供了联系方式以便于获取更多信息和支持。 3GPP TR 24.841 V6.0.0 (2004-06) 提供了一个关于SIP在3GPP网络中支持Presence服务的关键文档，为理解UMTS和IMS网络中的实时通信机制提供了深入的技术参考。对于那些在开发、优化或研究这类服务的IT专业人员来说，它是不可或缺的研究资料。

5 SIP related procedures

5.1 Introduction

5.2 Functional entities

5.2.1 User Equipment (UE)

A UE shall implement the role of a PUA (see subclause@5.3.1), a watcher (see subclause@5.3.2) or both.

5.2.2 Application Server (AS)

An application server may implement either of the roles of a PUA (see subclause@5.3.1), Watcher (see subclause@5.3.2),

PS (see subclause@5.3.3), RLS (see subclause@5.3.4), or PNA.

For this version of the document, the interface between the PNA and the PS is not defined.

5.3 Roles

5.3.1 Presence User Agent (PUA)

5.3.1.1 General

A PUA is an entity that provides presence information to a PS.

In addition to the procedures specified in subclause@5.3.1, the PUA shall support the procedures specified in

3GPP@TS@24.229@[8] appropriate to the functional entity in which the PUA is implemented.

Editor's Note: There is a need for a mechanism to let the IMS network and/or PS control the rate at which PUAs

generate PUBLISH requests. Unless referenced IETF specifications provide support for implementation

of this kind of control, such a mechanism or guidance on max rates must be identified and described here.

5.3.1.2 Publication of presence information

When the PUA intends to publish its own view of the presentity’s presence information it shall generate a PUBLISH

request by acting as an Event Publication Agent (EPA) in accordance with draft-ietf-sip-publish-03@[22].

The PUA shall implement the "application/pidf+xml" content type as described in draft-ietf-impp-cpim-pidf-08@[20]

together with the Presence Information Data Format (PIDF) extensions defined in draft-ietf-simple-rpid-03@[25].

The PUA may implement the PIDF extensions defined in draft-ietf-simple-cipid-01@[31].

The PUA may implement location information according to the format defined in draft-ietf-geopriv-pidf-lo-01@[36].

NOTE@1 The categorisation of presence attributes to generic information attributes and communication address

specific attributes is done using the <contact-type> element. The value of the <contact-type> element

categorises the content of the tuple in such a way that the value "presentity" denotes general information

about the presentity and the value "service" denotes the communication mean specific information. The

presence document consists of one or more tuples describing the presentity related information and one or

more tuples describing information about different communication means.

The eXtensible Markup Language (XML) Schema Definition of the "application/pidf+xml" format or the

"application/pidf-partial+xml" format cover the definition of the 3GPP subscriber's presence attributes and the PUA

shall perform the following mapping:

3GPP

3GPP TR 24.841 V6.0.0 (2004-06)11Release 6

- the communication address (containing communication means, status and contact address) attribute and the

priority attribute are represented by a <tuple> element including a basic <status> element and one or more

<contact> elements containing a priority attribute as defined in draft-ietf-impp-cpim-pidf-08@[20].

The PUA represents the subscriber's status by including a <contact-type> element defined in draft-ietf-simple-

rpid-03@[25] with the value "presentity" and a basic <status> element defined in draft-ietf-impp-cpim-pidf-

08@[20]. In order to express more granularity in values, <activity> and <privacy> elements both defined in draft-

ietf-simple-rpid-03@[25] can be used inside the <status> elements. Further PIDF extensions as defined in draft-

ietf-simple-cipid-01@[31] can also be used.

In case of including multiple presentity related tuples in the presence document, all the presentity related tuples

except one contains information about an alternate contact related to the presentity; the type of the alternate

contact shall be indicated using the <relationship> element defined in draft-ietf-simple-rpid-03@[25];

NOTE@2: draft-ietf-simple-rpid-03@[25] defines also other values of the <contact-type> element. Those values can

be used to create additional categories.

- the text attribute is represented by the <note> element as defined in draft-ietf-impp-cpim-pidf-08@[11]; and

- the location attribute is represented by the elements defined in draft-ietf-geopriv-pidf-lo-01@[36] and the

<placetype> element defined in draft-ietf-simple-rpid-03@[25].

NOTE@3: Only information elements relevant for the application is included in the PUBLISH request. Attributes not

relevant or available (e.g. the text attribute or the location attribute) are omitted.

Additional extensions can be used to express application specific attributes, but their usage is outside the scope of this

version of the specification.

The PUA shall implement draft-ietf-simple-prescaps-ext-00@[24] if it wants to make use of SIP user agent capabilities in

the presence document. The extension may be used for describing the type of the service described by the presence

tuple.

The PUA shall implement the "multipart/related" content type as described in RFC@2387@[13] if it wants to aggregate

other Multipurpose Internet Mail Extensions (MIME) objects with the "application/pidf+xml" content type.

When a presence attribute has a value of a MIME object, the PUA shall either:

a) publish the presence document and the MIME object utilising the "multipart/related" content-type in the

PUBLISH request; or

b) make use of content indirection.

When the PUA decides to use the content indirection mechanism for publishing an initial or modified value of a

presence attribute the PUA shall follow the following procedure:

a) either store the MIME object behind an HTTP URI on the PS or ensure that the MIME object and a HTTP URL

pointing to that MIME object already exists on the PS;

b) use the "multipart/related" content type as described in RFC@2387@[13] with the content indirection mechanism

as specified in draft-ietf-sip-content-indirect-mech-03.txt@[39] for the publication of presence information format

as follows:

- set a CID URI referencing to other MIME multipart body which contains the content indirection information

as the value of the XML element whose value is delivered as an indirect content;

- include the presence document of the format "application/pidf+xml" or "application/pidf-partial+xml" in the

root of the body of the "multipart/related" content;

- specify the part having information about the MIME object by using the "message/external-body" content

type, defining the HTTP URI, versioning information and other information about the MIME object as

described in draft-ietf-sip-content-indirect-mech-03.txt@[39].

NOTE@1: The versioning information is used for determining whether or not the MIME object indirectly referenced

by a URI has changed or not;

When storing a MIME object on the PS the PUA shall:

3GPP

3GPP TR 24.841 V6.0.0 (2004-06)12Release 6

a) construct as many HTTP URIs as many objects to be stored; and

b) formulate every HTTP URI according to a predefined directory structure.

NOTE@2: The PUA has the root directory for storing the MIME objects on the PS preconfigured.

NOTE@3: The PUA needs to store the MIME objects on the PS behind the HTTP URI(s) created previously using

standard HTTP procedures as defined in RFC@2616@[14].

The PUA may indicate its support for partial publishing by including the "application/pidf-partial+xml" content type as

described in draft-ietf-simple-partial-pidf-format-00@[37]. The initial PUBLISH request shall contain the full

publication, where the state attribute is set to value "full".

On successful response from the PS, the PUA in subsequent PUBLISH requests shall generate partial publications,

where the state attribute is set to value “partial”.

If the PUA receives a 415 (Unsupported Media Type) response to the PUBLISH request with "application/pidf+xml" in

the Accept header field, the PUA shall send a PUBLISH request including the "application/pidf+xml".content type.

Editor’s Note: The above procedures on partial publishing will be replaced by references to the IETF draft-lonnfors-

simple-publish-partial-00 once the draft has been discussed in IETF.

The PUA shall update the presence information, either 600 seconds before the publication expiration time if the

publication period indicated from the PS in the response to the PUBLISH request was for greater than 1200 seconds, or

when half of the time has expired if the publication period was for 1200 seconds or less, unless the UE has determined

that an update to the presence information is not required.

When the PUA intends to show different value of the same presence attribute to different watchers, the PUA shall

publish a tuple for every value it intends to show, all including a different value of the same presence attribute. The

PUA shall label different information with different value of the <class> element in every published tuple as defined in

draft-ietf-simple-rpid-03@[25]. The PUA shall also authorize different tuples to different watchers or watcher groups by

manipulating the subscription authorisation policy as defined in subclause@6.3.1.2.

5.3.1.3 Subscription for the watcher information event template package

Upon activation of the presence service, the PUA application shall subscribe for the watcher information state changes

in accordance with draft-ietf-simple-winfo-package-05@[27] and draft-ietf-simple-winfo-format-04@[28].

The PUA application may include filters in the body of the SUBSCRIBE request in accordance with draft-ietf-simple-

filter-format-00@[29] and draft-ietf-simple-filter-funct-00@[30].

5.3.1.4 Subscription for the xcap-change package

In order to get notifications of changes to XML documents manipulated via the Ut reference point the PUA may

generate a SUBSCRIBE request in accordance with draft-ietf-simple-xcap-package-01@[33].

5.3.2 Watcher

5.3.2.1 General

A watcher is an entity that is subscribed or requests presence information about a presentity from the PS.

In addition to the procedures specified in subclause@5.3.2, the watcher shall support the procedures specified in

3GPP@TS@24.229@[8] appropriate to the functional entity in which the watcher is implemented.

5.3.2.2 Subscription for presence information state changes and notification

acceptance

When the watcher application intends to subscribe for presence information state changes of a presentity, it shall

generate a SUBSCRIBE request in accordance with RFC@3265@[18] and draft-ietf-simple-presence-10@[26].

3GPP

3GPP TR 24.841 V6.0.0 (2004-06)13Release 6

剩余63页未读，继续阅读

dssuen

粉丝: 0
资源: 23

3GPP TR 24.841 V6.0.0：基于SIP的3G核心网络存在服务功能模型

TR 36.814_100

Technical Report on C++ Performance

3GPP TR 38.913 V14.2.0 (2017-03)-e20

3GPP TR 24.802 V12.1.0 (2014-06)

Milenage算法实现及测试代码(根据3GPP TS 35.206 V6.0.0程序修改)

3GPP TR 36.885 V14.0.0 (2016-06)

3GPP视频协议规范：3GPP TR 26.233，3GPP TR 26.234，3GPP TR 26.244，3GPP TR 26.937

25814-700.zip_3GPP TR _3GPP TR25.814V_3gpp tr 25.814_T. 25. 814

3GPP TR 23.785 V14.0.0 (2016-09)

3GPP TR 36.873 V12.0.0 (2014-09)

最新资源