6 User Service Discovery

26.2373GPPIP Multimedia Subsystem (IMS) based Packet Switch Streaming (PSS) and Multimedia Broadcast/Multicast Service (MBMS) User ServiceProtocolsRelease 17TS

6.1 Introduction

This clause specifies how the UE performs the PSS and MBMS User Service Discovery. This is equivalent to discovering the address of the SSF.

6.2 Subscribe/Notify

6.2.1 General description

Figure 6: Service Discovery with Subscribe/Notify

1) The UE sends a SIP SUBSCRIBE message to the IM CN subsystem. It should indicate its capabilities in the message.

2) The IM CN subsystem forwards the request to the SDF, e.g. thanks to an iFC.

3) The SDF determines the proper service discovery information, e.g. according to the UE capabilities, the user’s profile (Personalized Service Discovery). The user profile may be retrieved from the HSS or any other entity where it is stored.

4) The SDF sends a SIP 200 OK response to the IM CN subsystem, which forwards it to the UE.

5) The SDF sends a SIP NOTIFY message to the UE, with service discovery information that includes the SSF(s) address(es).

6) The IM CN subsystem relays the SIP NOTIFY message back to the UE, with the service discovery information related to PSS and MBMS user service.

7) The UE sends back a SIP 200 OK response to the IM CN subsystem.

8) The IM CN subsystem forwards the SIP 200 OK to the SDF.

6.2.2 Procedures at the UE

6.2.2.1 Introduction

The UE shall generate a SUBSCRIBE request. The behaviour of the UE when processing a SUBSCRIBE request shall conform to 3GPP TS 24.229 [7].

6.2.2.2 Subscription

When the UE intends to retrieve service attachment information from the SDF, it shall generate a SUBSCRIBE request for the "ua-profile" event package defined in [28] and extended as described in Annex Y of [24].

The contents of the SUBSCRIBE request shall be as follows:

– The value of the Request-URI shall be set to one of following:

– – the PSI of the SDF which is retrieved using SDF Discovery procedures in clause 5 Service Provider Discovery; or

– – the public user identity of the end user (when the UE does not know the PSI of the SDF).

– The From and To header shall be set to the public user identity of the user.

– The Accept header shall include the content-type identifier that corresponds to the registered MIME type of XML documents representing UE capabilities included in the body, See clause 4.4.2:

– A first Content Type set to "application/3gpp-ims-pss-mbms-ue-capabilities+xml".

– A second Content Type set to "application/rdf+xml".

– The Event header shall be set to the "ua-profile" event package.

– The Event parameters shall be set as follows:

– The "profile-type" parameter shall be set to "application".

– The "vendor", "model" and "version" parameter values shall be set to values specified by the implementer of the user equipment, as specified in 3GPP TS 24.229 [7].

– The "appids" parameter shall be present and set to "urn:org:3gpp:applications:ims-pss-mbms-service-discovery".

The UE shall include a SIP SUBSCRIBE multipart/mixed content-type message body associated with the appid including the PSS and MBMS UE Device Capabilities defined in Annex G and the RDF/XML document describing the PSS base vocabulary defined in Annex F of TS 26.234 [8].

Upon receipt of a 2xx response to the SUBSCRIBE request, the UE shall store the information for the established dialog and the expiration time as indicated in the Expires header of the received response.

The UE shall automatically refresh the subscription, either 600 seconds before the expiration time if the initial subscription was for greater than 1 200 seconds, or when half of the time has expired if the initial subscription was for 1 200 seconds or less. If a SUBSCRIBE request to refresh a subscription fails with a non-481 response, the UE shall still consider the original subscription valid for the duration of the most recently known "Expires" value according to 3GPP TS 24.229 [7]. Otherwise, the UE shall consider the subscription invalid and start a new initial subscription according to 3GPP TS 24.229 [7].

6.2.2.3 Receiving notifications

Upon receipt of a NOTIFY request on the dialog which was generated during subscription, the application within the UE shall parse the XML document contained in the message body. The XML document schema is defined in Annex H. The definition of each parameter in the XML document is defined in 5.2.2.3 of [24]

The list of parameters in the XML document shall be used for service selection information retrieval according to
clause 7.

When parsing the list of parameters the UE shall take the following action:

– information relates to an SSF with whom the UE has already an entry.

– If the "@version" attribute is present and has not the same value or if not present, then the UE performs the following actions:

– for parameters related to this SSF already present in the UE: the UE shall update these parameters with the new values sent by the SDF. If the Segment@Version has not the same value, the UE shall update user service selection information from the SSF before using it,

– for parameters related to this SSF not present in the UE: the UE shall store the new parameters.

– If the "@version" attribute is present and has the same value, the UE shall not update the stored SSF information.

– information relates to an SSF not known by the UE: the UE creates a new entry for this SSF with all indicated parameters.

After all elements have been processed, the UE shall return a 200 OK response to the NOTIFY request.

Failure to perform subscription refresh does not imply that there is a loss of communication to SSF or SCF. The UE has an option to continue using the lists of parameters from the last NOTIFY.

After deregistration, the UE may keep stored information on per user basis. As for subscription refresh, the UE may use the stored information if initial subscription fails after a new registration.

6.2.3 Procedures at the SDF

The SDF addresses are determined by the UE using any of the alternatives as defined in clause 5.

When the SDF receives a SUBSCRIBE request, it may perform user’s identity verification as defined in 3GPP TS 24.229 [7]. After successful user identification, if a User Profile is available it is possible to perform personalization of the body (Service Attachment Information) of the NOTIFY request.

The SDF shall examine the parameters specified in the SIP SUBSCRIBE body and shall then record UE capabilities information as part of the user profile data.

NOTE: The UE capabilities that are recorded as part of the user profile may be used by the SSF for personalization purposes.

In case of successful subscription, the SDF shall generate a SIP 200 OK in response to the SUBSCRIBE request. The SDF shall then send a NOTIFY request immediately.

The contents of the NOTIFY request shall be as follows:

– The Event header shall be set to the "ua-profile" event package.

– The "effective-by" parameter for the event header shall be set to 0.

– The content type shall be set to "application/3gpp-ims-pss-mbms-service-discovery+xml";

– The message body shall contain an XML document listing SSF addresses and the means of connecting to the SSFs for retrieving service selection information defined in Annex H. The definition of each parameter in the XML document is defined in 5.2.2.3 of [24]. The "@technology" element name indicates the technology used to for delivering service selection information. It shall be set to the "openmobilealliance.org_bcast".

When any parameter of service configuration information has changed, the SDF may generate a NOTIFY request including new service configuration information.