7 User Service Description retrieval

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

7.1 Introduction

User Service Description retrieval can be done in several ways

– By retrieving OMA BCAST Service Guide information [27] from the SSF. See clause 7.2;

– By retrieving MBMS USD from the SSF as defined in 3GPP TS 26.346 [11] clause 5.2;

– By executing the Procedure for providing missing parameters before session initiation described in clauses 8.2.2 and 8.3.2 for PSS and MBMS user service respectively.

7.2 User Service Description retrieval for PSS and MBMS

7.2.1 Procedures at the UE

7.2.1.1 Procedure for Service Personalisation

For HTTP-based data retrieval, when sending the HTTP request to the SSFs, the UE may provide personalized information to enable a personalized answer. This shall be done by adding the X-3GPP-Intended-Identity HTTP header to the request to transmit the public identity.

The authentication shall follow 3GPP TS 33.222 [20].

The UE shall implement Transport Layer Security (TLS), as described in 3GPP TS 33.222 [20].

7.2.1.2 Request of OMA BCAST ESG

In the pull model of unicast delivery of an OMA BCAST ESG, the HTTP protocol shall be used conforming to OMA BCAST Service_Guide [27], clause 5.4.3.

7.2.1.3 Use of Service Description information

The UE shall use parameters received from the SSF for session initiation.

NOTE: There is no restriction on the UE to use any parameter received from SSF also for other purposes than session initiation, e.g. to present SSF information to the user.

The UE may store a part of the ESG information covering certain period of time and refresh this information periodically This avoid the UE to contact the SSF every time the user needs to consult the ESG.

If the UE is unable to contact any discovered SSF, it shall not delete stored information immediately.

7.2.2 Procedures at the SSF

7.2.2.1 Authentication and authorisation in case of personalized service description information

In case of service selection personalisation the SSF shall authenticate the user.

The authentication shall follow 3GPP TS 33.222 [20].

The SSF shall implement Transport Layer Security (TLS) as described in 3GPP TS 33.222 [20].

An authentication proxy (AP) may exist between the UE and the SSF in which case the behaviour of the AP is assumed to conform to 3GPP TS 24.423 [21].

If an Authentication Proxy (AP) is provided in the path of the HTTP request, then the SSF receives an HTTP request from a trusted source (the AP) and the request contains an HTTP X-3GPP-Asserted-Identity header (3GPP TS 24.109 [22]) that includes an asserted identity of the user. In this case the SSF does not need to authenticate the user, but just provide authorization to access the requested resource.

If an HTTP X-3GPP-Asserted-Identity header (3GPP TS 24.109 [22]) is not present in the HTTP request or if the request is received from a non-trusted source, then the SSF needs to authenticate the user prior to providing personalise information by applying the procedures defined in 3GPP TS 33.222 [20] and

authorize or deny authorization depending on the authenticated identity.

7.2.2.2 Procedure for Service Personalization

If the public user identity information is present in the query from the UE, the SSF shall extract it to customize/personalize the service information that is returned in the query response.

The SSF shall use the public user identity that is specified in the X-3GPP-Intended-Identity header or the X‑3GPPAsserted-Identity header if an authentication proxy is used to fetch the corresponding user profile associated with the user. For instance, the Parental Control (if present) should be used to remove unsuitable elements from the COD listings that are returned to the UE.

7.2.2.3 Delivery of OMA BCAST ESG

The procedure for retrieving OMA BCAST service selection information is employed to retrieve one or more Service Guide Delivery Descriptors (SGDD) and/or Service Guide Delivery Units (SGDU). The SGDD describes service level information as well as access information to the Service Guide fragments. The SGDU is the transport-independent network structure for encapsulating Service Guide fragments.

When the ESG SSF receives a HTTP POST request, if personalization headers are presents (in the form of key-value pairs) it shall use those headers in order to build a personalized response. For instance, the ESG SSF may use the provided user identity to retrieve the associated Parental Control Level in the user profile. This Parental Control Level would then be used to remove non suitable elements from the ESG data that are sent back. The provided user identity may also be used to retrieve a personalized ESG using the method in OMA BCAST Service Guide [27], clause 5.4.3.3.The ESG SSF shall send an HTTP response conforming to OMA BCAST Service Guide [27], clause 5.4.3.1. The body of the HTTP response shall contain an XML document with SGResponse data, conforming to OMA BCAST Service Guide[27], clause 5.4.3.1.1.