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

3GPP

24.841

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

身份认证购VIP最低享 7 折!

领优惠券(最高得80元）

资源详情

资源推荐

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 TS 36.521-1和3GPP TS 36.331-1的主要区别

3gpp ts 27.005 v14.0.0 (2017-03)

3gpp tr 38.901 下载

3gpp ts 36.521-1

3GPP TS 38.323 V15.4.0的下载链接

3gpp ts 38.521 -1

3gpp ts 27.007

3GPP TS 48.018 set-up PFC

3GPP TS 36.521-1主要是什么

3gpp ts 27.007 协议

3gpp 24.301

3gpp ts 23.040 TPDU

3GPP 8.1.4.1.9.3

tr 38.901协议全文下载

linux 插入sim卡检查是否已激活并可以连接到移动网络输入示例

3gpp 23.285

Flow-Description in TS29.212

最新资源