21 Content Referral Service (CRS)

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

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

Content referral service has two different scenarios, namely user initiated content referral service and service provider initiated content referral service. They are specified in sub-clauses 21.1 and 21.2, respectively.

21.1 User Initiated CRS

21.1.1 General Description

Content referral service enables a user to recommend a PSS or MBMS user service to another user.

Following is a general call flow for user initiated content referral service

Figure 46: User initiated content referral service

1-2 The Initiated UE issues a content referral request through the IM CN Subsystem to the SCF. The request carries the necessary parameters indicating the type of the recommended service, (e.g. PSS, MBMS or HTTP Streaming service), content identifier, identifier of target UE.

3 The SCF performs service authorization, to check:

– If the initiated UE is allowed to perform content referral service;

– If the target UE/User accepts content referral service from the initiated UE;

– Following that, the SCF forwards content referral service request through the IM CN Subsystem to the target UE. And the user of target UE may deny the request even if the SCF authorized.

4 The target UE sends a proper response to the initiated UE.

5 The target UE issues a SIP NOTIFY to the initiated UE through the IM CN Subsystem, indicating the session initialization of the recommended service is about to start.

6. The initiated UE response with 200 OK.

7 The target UE initiates the service indicated in the content referral service request, e.g.

– PSS session initiation as per the procedures defined in clause 8.2.3, or

– MBMS session initiation as per the procedures defined in clause 8.3.3

8 The target UE issues a SIP NOTIFY to the initiated UE, indicating the session initialization of the recommended service is done.

9. The initiated UE response with 200 OK.

21.1.2 Procedure at Initiated UE

When the initiated UE wants to recommend a PSS or MBMS user service to the target UE, the initiated UE shall issue a SIP REFER request to target UE as defined in [43], and the REFER message is routed to SCF. The content of the SIP REFER request shall be as follows:

– The Request-URI in the REFER request shall be set to the IMPU of the target UE;

– From shall be set to the IMPU of the initiated UE;

– To headers shall be set to the public GRUU or the IMPU of the target UE;

– Refer-To shall include the following parameters:

– the SIP URI shall be set to:

– "PSS_COD_<content-id>@<Domain name>" for CoD service, wherein content-id shall be globalContentID defined in [27].

– the well known PSI (Public Service Identifier) for live service, i.e. Live Stream@<Domain name>.

– the "method" shall be set to "INVITE".

– Content-Type: shall be set to "application/3gpp-ims-pss-mbms-bookmark+xml", if the message body contains a bookmark.

– The message body may contain a bookmark as defined in annex J, to indicate the recommended start time of the recommended service.

When receives the NOTIFY message, the initiated UE shall send a 200 OK to the target UE.

21.1.3 Procedure at SCF

Upon receiving a SIP REFER request, the SCF shall check:

– If the initiated UE is allowed to perform content referral service;

– If the target UE/User accepts content referral service from the initiated UE, which is set beforehand;

If the request is authorized, the SCF then forwards the request to the target UE.

21.1.4 Procedure at Target UE

When receiving a SIP REFER request, the target UE shall check whether or not it is capable of initiating the indicated PSS or MBMS user service, if the target UE is capable of initiating the service, the target UE shall send a 202 message immediately, and the 202 message shall be the same as the received REFER request except the "contact" head field:

– Contact shall be set to the IMPU of the target UE;

Then the target UE shall send an immediate NOTIFY message as defined in [43], to initiated UE for informing the status. The NOTIFY message shall be set as follows:

– From shall be set to the IMPU of the target UE;

– To headers shall be set to IMPU of the initiated UE;

– Content-Type shall be set to "message/sipfrag";

– Event shall be set to "refer";

– Subscription-State shall be set to "active";

When the target UE have sent the NOTIFY message, it shall initiate the PSS or MBMS service initialization according to the "Refer-To" message header of the REFER. If the REFER request further contains a bookmark, the target UE shall start the consumption of the service at the time point indicated in the bookmark.

After completion of the service initiation, it shall send another NOTIFY message to initiated UE, and the "Subscription-State" of such NOTIFY message shall be set to "terminated".

21.2 Service Provider Initiated CRS

21.2.1 General Description

The service provider initiated CRS service procedures include 3 major steps:

1) CRS event detection. This step is triggered according to service provider’s policy or user profile. The events may include new content arrival referral, presence update, request from the UE, channel change report from UE etc.

2) CRS information generation for specific user according to the preconfigured content referral policy. The CRS info includes one or more content identifiers (Annex O), identifying the recommended content. The user profile (e.g. user preference, watching habits etc) is used for filtering/sorting of CRS info.

3) CRS information delivery to the UE. SCF sends SIP MESSAGE containing the generated CRS information to the UE.

Figure 47: Procedure for CRS provided by SCF

21.2.2 Procedure at Initiated UE

Upon reception of a SIP MESSAGE request, the UE shall identify it as a content referral message by comparing the Content-Type header with "application/3gpp-ims-pss-mbms-contentreferral+xml". Following that, the UE shall parse the XML document according to the schema defined in Annex O, and then take appropriate further action, e.g. initiate a PSS session as defined in sub-clause 8.2.3.2

21.2.3 Procedure at SCF

Upon detection of a CRS event for a user, the SCF shall generate a SIP MESSAGE request and send it to the target UE via IM CN Subsystem

The contents of the above SIP MESSAGE request shall be as follows:

– The Request-URI of the SIP MESSAGE request shall be set to the IMPU of the target UE.

– The From header shall be set to the SIP URI of the SCF.

– The To header shall be set to the IMPU of the target UE.

– The Content-Type header shall be set to "application/3gpp-ims-pss-mbms-contentreferral+xml".

– The message body shall carry an XML document conforming to the XML schema defined in annex Y:

– ContentIdentifier shall be set to the content identifier related to the referral, if present;

– ReferralSender shall be set to the identifier of the originator who provides the referral, if present;

– ReferralReceiver shall be set to the identifier of target UE, if present.

– ContentReferralInfo shall be set to the information for content referral;

Annex A (normative):
3gpp_rtsp application

The 3gpp_rtsp application defines a set of RTSP parameters. An RTSP parameter is included in "a=fmtp" line of the SDP and is expressed in the form of parameter=value.

a=fmtp:3gpp_rtsp <parameter name>=<value>

The "version" parameter sets the "version-number" representing the version of RTSP that will be used in the RTSP media stream. The version number shall be "1.0" in this version of the specification. The RTSP version shall be included in all SDP offers and answers. The same version shall be used by all entities.

a=fmtp:3gpp_rtsp version=<version-number>

To exchange RTSP header fields within the SIP offer/answer, the RTSP media stream allows for attributes with the following format:

a=fmtp:3gpp_rtsp h-<header-name>=<header-value>,

where "header-name" is the name of the RTSP header field being described and "header-value" is the value of the RTSP header field. The value of the header-name is case insensitive. The value of the header-value is interpreted according to the rules of RTSP. The list of authorized headers in the SIP offer/answer is as follows:

– Session: this is the RTSP session id as established by the PSS adapter to be used for further RTSP transactions.

– Offset: this is a range value to be used in the first PLAY request by the UE.

– Supported" header filed with the following feature tags (see 3GPP TS 26.234 [8]):

– – "3gpp-switch" feature-tag, clause 5.5.4.2.

– – "3gpp-switch-req-sdp" feature-tag, clause 5.5.4.3.

– – "3gpp-switch-stream" feature-tag, clause 5.5.4.4.

– Require (see 3GPP TS 26.234 [8]).

– Pipelined-Requests (see 3GPP TS 26.234 [8]).

– 3GPP-Adaptation (see 3GPP TS 26.234 [8]).

UE, PSS Servers and PSS adapters shall support all these headers and feature tags.

Annex B (informative):
Examples

Void (TBD).

Annex C (normative):
Void

Annex D (normative):
XML Schema for PSS and MBMS commands

<?xml version="1.0" encoding="UTF-8"?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:pss="urn:org:etsi:ngn:params:xml:ns:PssContentSwitchData" xmlns:mbms="urn:org:etsi:ngn:params:xml:ns:MbmsContentSwitchData" xmlns:local="urn:org:etsi:ngn:params:xml:ns:PssMbmscommand" targetNamespace="urn:org:etsi:ngn:params:xml:ns:PssMbmscommand" elementFormDefault="qualified" attributeFormDefault="unqualified">

<xs:import namespace="urn:org:etsi:ngn:params:xml:ns:PssContentSwitchData" schemaLocation="PssSwitchData.xsd"/>

<xs:import namespace="urn:org:etsi:ngn:params:xml:ns:MbmsContentSwitchData" schemaLocation="MbmsSwitchData.xsd"/>

<xs:element name="ImsPssMbmsCommand">

<xs:complexType>

<xs:choice>

<xs:element name="PssSwitch" type="local:tPssSwitch" minOccurs="0" maxOccurs="unbounded"/>

<xs:element name="MbmsSwitch" type="local:tMbmsSwitch" minOccurs="0" maxOccurs="unbounded"/>

</xs:choice>

</xs:complexType>

</xs:element>

<xs:complexType name="tPssSwitch">

<xs:choice>

<xs:element ref="pss:PssSwitchData"/>

</xs:choice>

</xs:complexType>

<xs:complexType name="tMbmsSwitch">

<xs:choice>

<xs:element ref="mbms:MbmsSwitchData"/>

</xs:choice>

</xs:complexType>

</xs:schema>

Annex E (normative):
XML Schemas for the PSS content switch data

This annex specifies XML schemas for PSS content switch data:

<?xml version="1.0" encoding="UTF-8"?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns="urn:org:etsi:ngn:params:xml:ns:PssContentSwitchData" targetNamespace="urn:org:etsi:ngn:params:xml:ns:PssContentSwitchData" elementFormDefault="qualified" attributeFormDefault="unqualified">

<xs:element name="PssSwitchData">

<xs:complexType>

<xs:sequence>

<xs:element name="ContentID" type="xs:string" minOccurs="0"/>

<xs:element name="DateTime" type="xs:dateTime" minOccurs="0"/>

<xs:element name="Extension" type="tExtension" minOccurs="0"/>

<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>

</xs:sequence>

</xs:complexType>

</xs:element>

<xs:complexType name="tExtension">

<xs:sequence>

<xs:any processContents="lax" minOccurs="0" maxOccurs="unbounded"/>

</xs:sequence>

</xs:complexType>

</xs:schema>

Annex F (normative): XML Schemas for the MBMS content switch data

This annex specifies XML schemas for MBMS content switch data:

<?xml version="1.0" encoding="UTF-8"?>

<xs:schema xmlns="urn:org:etsi:ngn:params:xml:ns:MbmsContentSwitchData" xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="urn:org:etsi:ngn:params:xml:ns:MbmsContentSwitchData" elementFormDefault="qualified" attributeFormDefault="unqualified">

<xs:element name="MbmsSwitchData">

<xs:complexType>

<xs:sequence>

<xs:element name="ServiceId" type="xs:string" minOccurs="0"/>

<xs:element name="ProgrammeId" type="xs:string" minOccurs="0"/>

<xs:element name="DateTime" type="xs:dateTime" minOccurs="0"/>

<xs:element name="Extension" type="tExtension" minOccurs="0"/>

<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>

</xs:sequence>

</xs:complexType>

</xs:element>

<xs:complexType name="tExtension">

<xs:sequence>

<xs:any processContents="lax" minOccurs="0" maxOccurs="unbounded"/>

</xs:sequence>

</xs:complexType>

</xs:schema>

Annex G (normative):
XML Schema for PSS and MBMS UE Device Capabilities

This XML Schema defines the UE device capabilities that are signalled by the UE within the body of the SIP SUBSCRIBE request when attaching to the service. Another document is also part of the body to describe PSS Capabilities as defined in TS 26.234.

<?xml version="1.0" encoding="UTF-8"?>

<xs:schema

targetNamespace="urn:3GPP:metadata:2008:IMS-PSS-MBMS:UECap"

xmlns:xs="http://www.w3.org/2001/XMLSchema"

elementFormDefault="qualified" attributeFormDefault="unqualified">

<xs:annotation>

<xs:documentation xml:lang="en">

Defines the capabilities of the UE that is currently associated with the user

</xs:documentation>

</xs:annotation>

<xs:element name="UEInformation" type="tUEProfile"/>

<xs:complexType name="tUEProfile">

<xs:sequence>

<xs:element name="UserEquipmentModelName" type="xs:string"/>

<xs:element name="UserEquipmentModelVersion" type="xs:string"/>

<xs:element name="UserEquipmentID" type=" tUEID"/>

<xs:element name="UserEquipmentClass" type="tUserEquipmentClass"/>

<xs:element name="UserEquipmentMBMSCapable" type="xs:boolean"/>

</xs:sequence>

</xs:complexType>

<xs:simpleType name="tUEID" final="list restriction">

<xs:annotation>

<xs:documentation>

<label xml:lang="en">User Equipment ID</label>

<definition xml:lang="en">Unique Identifier for the UE(eg;Could be MAC address of UE) </definition>

</xs:documentation>

</xs:annotation>

<xs:restriction base="xs:string">

<xs:minLength value="0"/>

<xs:maxLength value="16"/>

</xs:restriction>

</xs:simpleType>

<xs:simpleType name="tUserEquipmentClass" final="list restriction">

<xs:annotation>

<xs:documentation>

<label xml:lang="en">User Equipment class</label>

<definition xml:lang="en">Specifies the type of UE</definition>

</xs:documentation>

</xs:annotation>

<xs:restriction base="xs:string">

<xs:enumeration value="STB"> </xs:enumeration>

<xs:enumeration value="PC"> </xs:enumeration>

<xs:enumeration value="Handset"> </xs:enumeration>

</xs:restriction>

</xs:simpleType>

</xs:schema>

Annex H (normative):
XML Schema for Service Attachment Information

This annex describes the XML schema for the service attachment information to be returned to UE by SDF.

<?xml version="1.0" encoding="UTF-8"?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified">

<xs:element name="SSF" type="tSSF">

<xs:annotation>

<xs:documentation>XML Body of the SDF SIP Notify Response</xs:documentation>

</xs:annotation>

</xs:element>

<xs:complexType name="tSSF">

<xs:sequence>

<xs:element name="Description" type="tMultilingual" minOccurs="0" maxOccurs="unbounded"/>

<xs:element name="ServiceProvider" type="tSSFServiceProvider" minOccurs="0"/>

<xs:element name="Pull" type="tSSFPull" minOccurs="0" maxOccurs="unbounded"/>

<xs:element name="Push" type="tSSFPush" minOccurs="0" maxOccurs="unbounded"/>

<xs:element name="MBMSSecurityProcedure" type="tMBMSSec" minOccurs="0"/>

<xs:element name="Extension" type="tExtension" minOccurs="0"/>

<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>

</xs:sequence>

<xs:attribute name="ID" type="tHexadecimal16bit" use="required"/>

<xs:attribute name="Technology" type="xs:string" use="required"/>

<xs:attribute name="Version" type="tVersion">

<xs:annotation>

<xs:documentation>The version number is incremented when one or more attributes of the SSF element have changed, so that the receiver knows whether it should update its data or not.</xs:documentation>

</xs:annotation>

</xs:attribute>

<xs:anyAttribute namespace="##other" processContents="lax"/>

</xs:complexType>

<xs:simpleType name="tVersion">

<xs:restriction base="xs:integer">

<xs:minInclusive value="0"/>

<xs:maxInclusive value="255"/>

</xs:restriction>

</xs:simpleType>

<xs:complexType name="tSSFServiceProvider">

<xs:sequence>

<xs:element name="Name" type="tMultilingual" maxOccurs="unbounded"/>

<xs:element name="Description" type="tMultilingual" minOccurs="0" maxOccurs="unbounded"/>

<xs:element name="Extension" type="tExtension" minOccurs="0"/>

</xs:sequence>

<xs:attribute name="DomainName" type="tDomain" use="required">

<xs:annotation>

<xs:documentation>It is recommended that the DomainName complies with the "preferred name syntax" of RFC1034 clause 3.5</xs:documentation>

</xs:annotation>

</xs:attribute>

<xs:attribute name="LogoURI" type="xs:anyURI" use="optional"/>

<xs:anyAttribute namespace="##other" processContents="lax"/>

</xs:complexType>

<xs:simpleType name="tDomain">

<xs:restriction base="xs:string">

<xs:pattern value="((.|\n|\r)*)?(\.(.|\n|\r)*)+"/>

</xs:restriction>

</xs:simpleType>

<xs:complexType name="tSSFPull">

<xs:complexContent>

<xs:extension base="tDataTypeList">

<xs:attribute name="Location" type="xs:anyURI" use="required"/>

<xs:anyAttribute namespace="##other" processContents="lax">

<xs:annotation>

<xs:documentation>Extension attribute to define further data</xs:documentation>

</xs:annotation>

</xs:anyAttribute>

</xs:extension>

</xs:complexContent>

</xs:complexType>

<xs:complexType name="tSSFPush">

<xs:complexContent>

<xs:extension base="tDataTypeList">

<xs:attribute name="IpVersion" type="tVersion" use="optional"/>

<xs:attribute name="MulticastAddress" type="xs:string" use="required"/>

<xs:attribute name="MulticastPort" type="xs:unsignedShort" use="required"/>

<xs:attribute name="SourceAddress" type="xs:string" use="optional"/>

<xs:anyAttribute namespace="##other" processContents="lax">

<xs:annotation>

<xs:documentation> Extension attribute to define further data ></xs:documentation>

</xs:annotation>

</xs:anyAttribute>

</xs:extension>

</xs:complexContent>

</xs:complexType>

<xs:complexType name="tDataTypeList">

<xs:sequence maxOccurs="unbounded">

<xs:element name="DataType">

<xs:complexType>

<xs:sequence minOccurs="0" maxOccurs="unbounded">

<xs:element name="Segment">

<xs:annotation>

<xs:documentation>Segments are used to logically separate Service Selection information</xs:documentation>

</xs:annotation>

<xs:complexType>

<xs:attribute name="ID" type="tHexadecimal16bit" use="required"/>

<xs:attribute name="Version" type="tVersion" use="optional"/>

</xs:complexType>

</xs:element>

</xs:sequence>

<xs:attribute name="Type" type="tHexadecimal8bit" use="required">

<xs:annotation>

<xs:documentation> Specify the type of Service Selection Information that is delivered by the SSF

</xs:documentation>

</xs:annotation>

</xs:attribute>

</xs:complexType>

</xs:element>

</xs:sequence>

</xs:complexType>

<xs:complexType name="tExtension">

<xs:sequence>

<xs:any processContents="lax" minOccurs="0" maxOccurs="unbounded"/>

</xs:sequence>

</xs:complexType>

<xs:complexType name="tMultilingual">

<xs:simpleContent>

<xs:extension base="xs:string">

<xs:attribute name="Language" type="tLanguage" use="required"/>

</xs:extension>

</xs:simpleContent>

</xs:complexType>

<xs:simpleType name="tLanguage">

<xs:restriction base="xs:string">

<xs:annotation>

<xs:documentation>

<definition xml:lang="en">ISO 639-2 Language code</definition>

</xs:documentation>

</xs:annotation>

<xs:minLength value="3"/>

<xs:maxLength value="3"/>

</xs:restriction>

</xs:simpleType>

<xs:simpleType name="tHexadecimal8bit">

<xs:restriction base="xs:string">

<xs:pattern value="[0-9a-fA-F]{1,2}"/>

</xs:restriction>

</xs:simpleType>

<xs:simpleType name="tHexadecimal16bit">

<xs:restriction base="xs:string">

<xs:pattern value="[0-9a-fA-F]{1,4}"/>

</xs:restriction>

</xs:simpleType>

<xs:simpleType name="tMBMSSec">

<xs:restriction base="xs:string">

<xs:enumeration value="SIP"/>

<xs:enumeration value="HTTP"/>

</xs:restriction>

</xs:simpleType>

</xs:schema>

Annex I (normative):
XML Schemas for SIP based MBMS security procedures