A.4 Capability exchange
26.2343GPPProtocols and codecsRelease 17Transparent end-to-end Packet-switched Streaming Service (PSS)TS
A.4.1 Overview
Clause A.4 provides detailed information about the structure and exchange of device capability descriptions for the PSS. It complements the normative part contained in clause 5.2 of the present document.
The functionality is sometimes referred to as capability exchange. Capability exchange in PSS uses the CC/PP [39] framework and reuse parts of the CC/PP application UAProf [40].
To facilitate server-side content negotiation for streaming, the PSS server needs to have access to a description of the specific capabilities of the mobile terminal, i.e. the device capability description. The device capability description contains a number of attributes. During the set-up of a streaming session the PSS server can use the description to provide the mobile terminal with the correct type of multimedia content. Concretely, it is envisaged that servers use information about the capabilities of the mobile terminal to decide which stream(s) to provision to the connecting terminal. For instance, the server could compare the requirements on the mobile terminal for multiple available variants of a stream with the actual capabilities of the connecting terminal to determine the best-suited stream(s) for that particular terminal. A similar mechanism could also be used for other types of content. A device capability description contains a number of device capability attributes. In the present document they are referred to as just attributes. The current version of PSS does not include a definition of any specific user preference attributes. Therefore we use the term device capability description. However, it should be noted that even though no specific user preference attributes are included, simple tailoring to the preferences of the user could be achieved by temporary adjustments of the available attributes. E.g. if the user for a particular session only would like to receive mono sound even though the terminal is capable of stereo, this can be accomplished by providing an override for the "AudioChannels" attribute. It should also be noted that the extension mechanism defined would enable an easy introduction of specific user preference attributes in the device capability description if needed. In another example, PSS content may be rendered to the user by a peripheral remote display device connected to the PSS-enabled mobile terminal. In this setting, the mobile terminal may host the PSS application and associated session control mechanisms, while content rendering and playback to the user may occur in the connected peripheral device, such that the graphics/display engine is hosted in the connected peripheral device. In such cases, temporary adjustments to the available device capability attributes could be performed in order to signal attributes describing the capabilities of the connected peripheral display device.
The term device capability profile or profile is sometimes used instead of device capability description to describe a description of device capabilities and/or user preferences. The three terms are used interchangeably in the present document.
Figure A.1 illustrates how capability exchange in PSS is performed. In the simplest case the mobile terminal informs the PSS server(s) about its identity so that the latter can retrieve the correct device capability profile(s) from the device profile server(s). For this purpose, the mobile terminal adds one or several URLs to RTSP and/or HTTP protocol data units that it sends to the PSS server(s). These URLs point to locations on one or several device profile servers from where the PSS server should retrieve the device capability profiles. This list of URLs is encapsulated in RTSP and HTTP protocol data units using additional header field(s). The list of URLs is denoted URLdesc. The mobile terminal may supplement the URLdesc with extra attributes or overrides for attributes already defined in the profile(s) located at URLdesc. This information is denoted Profdiff. As URLdesc, Profdiff is encapsulated in RTSP and HTTP protocol data units using additional header field(s).
The device profile server in Figure A.1 is the logical entity that stores the device capability profiles. The profile needed for a certain request from a mobile terminal may be stored on one or several such servers. A terminal manufacturer or a software vendor could maintain a device profile server to provide device capability profiles for its products. It would also be possible for an operator to manage a device profile server for its subscribers and then e.g. enable the subscriber to make user specific updates to the profiles. The device profile server provides device capability profiles to the PSS server on request.
Figure A.1: Functional components in PSS capability exchange
The PSS server is the logical entity that provides multimedia streams and other, static content (e.g. images, and graphics) to the mobile terminal (see Figure A.1). A PSS application might involve multiple PSS servers, e.g. separate servers for multimedia streams and for static content. A PSS server handles the matching process. Matching is a process that takes place in the PSS servers (see Figure A.1). The device capability profile is compared with the content descriptions at the server and the best fit is delivered to the client.
A.4.2 Scope of the specification
The following bullet list describes what is considered to be within the scope of the specification for capability exchange in PSS.
– Definition of the structure for the device capability profiles, see clause A.4.3.
– Definition of the CC/PP vocabularies, see clause A.4.4.
– Reference to a set of device capability attributes for multimedia content retrieval applications that have already been defined by UAProf [40]. The purpose of this reference is to point out which attributes are useful for the PSS application.
– Definition of a set of device capability attributes specifically for PSS applications that are missing in UAProf.
– It is important to define an extension mechanism to easily add attributes since it is not possible to cover all attributes from the beginning. The extension mechanism is described in clause A.4.5.
– The structure of URLdesc, Profdiff and their interchange is described in clause A.4.6.
– Protocols for the interchange of device capability profiles between the PSS server and the device profile server is defined in clause 5.2.7.
The specification does not include:
– rules for the matching process on the PSS server. These mechanisms should be left to the implementations. For interoperability, only the format of the device capability description and its interchange is relevant.
– definition of specific user preference attributes. It is very difficult to standardise such attributes since they are dependent on the type of personalised services one would like to offer the user. The extensible descriptions format and exchange mechanism proposed in this document provide the means to create and exchange such attributes if needed in the future. However, as explained in clause A.4.1 limited tailoring to the preferences of the user could be achieved by temporarily overriding available attributes in the vocabularies already defined for PSS. The vocabulary also includes some very basic user preference attributes. For example, the profile includes a list of preferred languages. Also the list of MIME types can be interpreted as user preference, e.g. leaving out audio MIME’s could mean that user does not want to receive any audio content. The available attributes are described in clause 5.2.3 of the present document.
– requirements for caching of device capability profiles on the PSS server. In UAProf, a content server can cache the current device capability profile for a given WSP session. This feature relies on the presence of WSP sessions. Caching significantly increases the complexity of both the implementations of the mobile terminal and the server. However, HTTP is used between the PSS server and the device profile server. For this exchange, normal content caching provisions as defined by HTTP apply and the PSS server may utilise this to speed up the session set-up (see clause 5.2.7)
– intermediate proxies. This feature is considered not relevant in the context of PSS applications.
A.4.3 The device capability profile structure
A device capability profile is a description of the capabilities of the device and possibly also the preferences of the user of that device. It can be used to guide the adaptation of content presented to the device. A device capability profile for PSS is an RDF [41] document that follows the structure of the CC/PP framework [39] and the CC/PP application UAProf [40]. The terminology of CC/PP is used in this text and therefore briefly described here.
Attributes are used for specifying the device capabilities and user preferences. A set of attribute names, permissible values and semantics constitute a CC/PP vocabulary. An RDF schema defines a vocabulary. The syntax of the attributes is defined in the schema but also, to some extent, the semantics. A profile is an instance of a schema and contains one or more attributes from the vocabulary. Attributes in a schema are divided into components distinguished by attribute characteristics. In the CC/PP specification it is anticipated that different applications will use different vocabularies. According to the CC/PP framework a hypothetical profile might look like Figure A.2. A further illustration of how a profile might look like is given in the example in clause A.4.7.
Figure A.2: Illustration of the profile structure
A CC/PP schema is extended through the introduction of new attribute vocabularies and a device capability profile can use attributes drawn from an arbitrary number of different vocabularies. Each vocabulary is associated with a unique XML namespace. This mechanism makes it possible to reuse attributes from other vocabularies. It should be mentioned that the prefix ccpp identifies elements of the CCPP namespace (URI http://www.w3.org/2002/11/08-ccpp-ns#), prf identifies elements of the UAProf namespace (URI http://www.wapforum.org/profiles/UAPROF/ccppschema-20070511#), rdf identifies elements of the RDF namespace (URI http://www.w3.org/1999/02/22-rdf-syntax-ns#) and pss identifies elements of the PSS Release-6 namespace. (URI http://www.3gpp.org/profiles/PSS/ccppschema-PSS6#).
Attributes of a component can be included directly or may be specified by a reference to a CC/PP default profile. Resolving a profile that includes a reference to a default profile is time-consuming. When the PSS server receives the profile from a device profile server the final attribute values can not be determined until the default profile has been requested and received. Support for defaults is required by the CC/PP specification [39]. Due to these problems, there is a recommendation made in clause 5.2.6 to not use the CC/PP defaults element in PSS device capability profile documents.
A.4.4 CC/PP Vocabularies
A CC/PP vocabulary shall according to CC/PP and UAProf include:
– an RDF schema for the vocabulary based on the CC/PP schema;
– a description of the semantics/type/resolution rules/sample values for each attribute;
– a unique namespace shall be assigned to each version of the profile schema.
Additional information that could be included in the profile schema:
– a description about the profile schema, i.e. the purpose of the profile, how to use it, when to use it etc;
– a description of extensibility,i.e.how to handle future extensions of the profile schema.
A device capability profile can use an arbitrary number of vocabularies and thus it is possible to reuse attributes from other vocabularies by simply referencing the corresponding namespaces. The focus of the PSS vocabulary is content formatting which overlaps the focus of the UAProf vocabulary. UAProf is specified by WAP Forum and is an architecture and vocabulary/schema for capability exchange in the WAP environment. Since there are attributes in the UAProf vocabulary suitable for streaming applications these are reused and combined with a PSS application specific streaming component. This makes the PSS vocabulary an extension vocabulary to UAProf. The CC/PP specification encourages reuse of attributes from other vocabularies. To avoid confusion, the same attribute name should not be used in different vocabularies. In clause 5.2.3.3 a number of attributes from UAProf [40] are recommended for PSS. The PSS base vocabulary is defined in clause 5.2.3.2.
A profile is allowed to instantiate a subset of the attributes in the vocabularies and no specific attributes are required but insufficient description may lead to content unable to be shown by the client.
A.4.5 Principles of extending a schema/vocabulary
The use of RDF enables an extensibility mechanism for CC/PP-based schemas that addresses the evolution of new types of devices and applications. The PSS profile schema specification is going to provide a base vocabulary but in the future new usage scenarios might have need for expressing new attributes. This is the reason why there is a need to specify how extensions of the schema will be handled. If the TSG responsible for the present document updates the base vocabulary schema a new unique namespace will be assigned to the updated schema. In another scenario the TSG may decide to add a new component containing specific user related attributes. This new component will be assigned a new namespace and it will not influence the base vocabulary in any way. If other organisations or companies make extensions this can be either as a new component or as attributes added to the existing base vocabulary component where the new attributes uses a new namespace. This ensures that third parties can define and maintain their own vocabularies independently from the PSS base vocabulary.
A.4.6 Signalling of profile information between client and server
URLdesc and Profdiff were introduced in clause A.4.1. The URLdesc is a list of URLs that point to locations on device profile servers from where the PSS server retrieves suitable device capability profiles. The Profdiff contains additional capability description information; e.g. overrides for certain attribute values. Both URLdesc and Profdiff are encapsulated in RTSP and HTTP messages using additional header fields. This can be seen in Figure A.1. In clause 9.1 of [40] three new HTTP headers are defined that can be used to implement the desired functionality: "x-wap-profile", "x-wap-profile-diff" and "x-wap-profile-warning". These headers are reused in PSS for both HTTP and RTSP.
– The "x-wap-profile" is a request header that contains a list of absolute URLs to device capability descriptions and profile diff names. The profile diff names correspond to additional profile information in the "x-wap-profile-diff" header.
– The "x-wap-profile-diff" is a request header that contains a subset of a device capability profile.
– The "x-wap-profile-warning" is a response header that contains error codes explaining to what extent the server has been able to match the terminal request.
Clause 5.2.5 of the present document defines this exchange mechanism.
It is left to the mobile terminal to decide when to send x-wap-profile headers. The mobile terminal could send the "x-wap-profile" and "x-wap-profile-diff" headers with each RTSP DESCRIBE and/or with each RTSP SETUP request. Sending them in the RTSP DESCRIBE request is useful for the PSS server to be able to make a better decision which presentation description to provision to the client. Sending the "x-wap-profile" and "x-wap-profile-diff" headers with an HTTP request is useful whenever the mobile terminal requests some multimedia content that will be used in the PSS application. Clause 5.2.5 of the present document gives recommendations for when profile information should be sent.
It is up to the PSS server to retrieve the device capability profiles using the URLs in the "x-wap-profile" header. The PSS server is also responsible to merge the profiles then received. If the "x-wap-profile-diff" header is present it must also merge that information with the retrieved profiles. This functionality is defined in clause 5.2.6.
It should be noted that it is up the implementation of the mobile terminal what URLs to send in the "x-wap-profile" header. For instance, a terminal could just send one URL that points to a complete description of its capabilities. Another terminal might provide one URL that points to a description of the terminal hardware. A second URL that points to a description of a particular software version of the streaming application, and a third URL that points to the description of a hardware or software plug-in that is currently added to the standard configuration of that terminal. From this example it becomes clear that sending URLs from the mobile terminal to the server is good enough not only for static profiles but that it can also handle re-configurations of the mobile terminal such as software version changes, software plug-ins, hardware upgrades, etc.
As described above the list of URLs in the x-wap-profile header is a powerful tool to handle dynamic changes of the mobile terminal. The "x-wap-profile-diff" header could also be used to facilitate the same functionality. To use the "x-wap-profile-diff" header to e.g. send a complete profile (no URL present at all in the "x-wap-profile header") or updates as a result of e.g. a hardware plug-in is not recommended unless some compression scheme is applied over the air-interface. The reason is of course that the size of a profile may be large.
A.4.7 Example of a PSS device capability description
The following is an example of a device capability profile as it could be available from a device profile server. The XML document includes the description of the imaginary "Phone007" phone.
Instead of a single XML document the description could also be spread over several files. The PSS server would need to retrieve these profiles separately in this case and would need to merge them. For instance, this would be useful when device capabilities of this phone that are related to streaming would differ among different versions of the phone. In this case the part of the profile for streaming would be separated from the rest into its own profile document. This separation allows describing the difference in streaming capabilities by providing multiple versions of the profile document for the streaming capabilities.
<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:ccpp="http://www.w3.org/2002/11/08-ccpp-ns#"
xmlns:prf="http://www.wapforum.org/profiles/UAPROF/ccppschema-20070511#"
xmlns:pss6="http://www.3gpp.org/profiles/PSS/ccppschema-PSS6#">
<rdf:Description rdf:about="http://www.bar.com/Phones/Phone007">
<ccpp:component>
<rdf:Description rdf:ID="HardwarePlatform">
<rdf:type rdf:resource="http://www.wapforum.org/profiles/UAPROF/ccppschema-20070511#HardwarePlatform" />
<prf:BitsPerPixel>4</prf:BitsPerPixel>
<prf:ColorCapable>Yes</prf:ColorCapable>
<prf:PixelAspectRatio>1×2</prf:PixelAspectRatio>
<prf:PointingResolution>Pixel</prf:PointingResolution>
<prf:Model>Phone007</prf:Model>
<prf:Vendor>Ericsson</prf:Vendor>
</rdf:Description>
</ccpp:component>
<ccpp:component>
<rdf:Description rdf:ID="SoftwarePlatform">
<rdf:type rdf:resource="http://www.wapforum.org/profiles/UAPROF/ccppschema-20070511#SoftwarePlatform" />
<prf:CcppAccept-Charset>
<rdf:Bag>
<rdf:li>UTF-8</rdf:li>
<rdf:li>ISO-10646-UCS-2</rdf:li>
</rdf:Bag>
</prf:CcppAccept-Charset>
<prf:CcppAccept-Encoding>
<rdf:Bag>
<rdf:li>base64</rdf:li>
<rdf:li>quoted-printable</rdf:li>
</rdf:Bag>
</prf:CcppAccept-Encoding>
<prf:CcppAccept-Language>
<rdf:Seq>
<rdf:li>en</rdf:li>
<rdf:li>se</rdf:li>
</rdf:Seq>
</prf:CcppAccept-Language>
<prf:DMCapable>Yes</prf:DMCapable>
<prf:DMVersion>1.2</prf:DMVersion>
</rdf:Description>
</ccpp:component>
<ccpp:component>
<rdf:Description rdf:ID="PssCommon">
<rdf:type rdf:resource="http://www.3gpp.org/profiles/PSS/ccppschema-PSS6#PssCommon" />
<pss6:AudioChannels>Stereo</pss6:AudioChannels>
<pss6:MaxPolyphony>24</pss6:MaxPolyphony>
<pss6:PssVersion>3GPP-R6</pss6:PssVersion>
<pss6:RenderingScreenSize>160×120</pss6:RenderingScreenSize>
</rdf:Description>
</ccpp:component>
<ccpp:component>
<rdf:Description rdf:ID="Streaming">
<rdf:type rdf:resource="http://www.3gpp.org/profiles/PSS/ccppschema-PSS6#Streaming" />
<pss6:ThreeGPPLinkChar>Yes</pss6:ThreeGPPLinkChar>
<pss6:AdaptationSupport>Yes</pss6:AdaptationSupport>
<pss6:ExtendedRtcpReports>Yes</pss6:ExtendedRtcpReports>
<pss6:MediaAlternatives>Yes</pss6:MediaAlternatives>
<pss6:RtpProfiles>
<rdf:Bag>
<rdf:li>RTP/AVP</rdf:li>
<rdf:li>RTP/AVPF</rdf:li>
</rdf:Bag>
</pss6:RtpProfiles>
<pss6:VideoPreDecoderBufferSize>30720</pss6:VideoPreDecoderBufferSize>
<pss6:VideoInitialPostDecoderBufferingPeriod>0</pss6:VideoInitialPostDecoderBufferingPeriod>
<pss6:VideoDecodingByteRate>16000</pss6:VideoDecodingByteRate>
<pss6:StreamingAccept>
<rdf:Bag>
<rdf:li>audio/AMR</rdf:li>
<rdf:li>video/H264; profile-level-id=42e00a</rdf:li>
</rdf:Bag>
</pss6:StreamingAccept>
</rdf:Description>
</ccpp:component>
<ccpp:component>
<rdf:Description rdf:ID="ThreeGPFileFormat">
<rdf:type rdf:resource="http://www.3gpp.org/profiles/PSS/ccppschema-PSS6#ThreeGPFileFormat" />
<pss6:Brands>
<rdf:Bag>
<rdf:li>3gp4</rdf:li>
<rdf:li>3gp5</rdf:li>
<rdf:li>3gp6</rdf:li>
<rdf:li>3gr6</rdf:li>
</rdf:Bag>
</pss6:Brands>
<pss6:ThreeGPAccept>
<rdf:Bag>
<rdf:li>audio/AMR</rdf:li>
<rdf:li>audio/AMR-WB;octet-alignment=1</rdf:li>
<rdf:li>video/H264; profile-level-id=42e00a</rdf:li>
<rdf:li>video/H263-2000;profile=3;level=45</rdf:li>
<rdf:li>video/Timed-Text</rdf:li>
</rdf:Bag>
</pss6:ThreeGPAccept>
</rdf:Description>
</ccpp:component>
Annex B (informative):
SMIL authoring guidelines
The SMIL authoring guidelines are given in [52].
Annex C (normative):
MIME media types