9 Feature negotiation
29.1163GPPRelease 18Representational state transfer over xMB reference point between content provider and BM-SCTS
9.1 General
The xMB API needs to provide a mechanism to advertise required and optional features supported by both the Content Provider and BM-SC for interoperability reasons as the functionality of the xMB interface is augmented.
Feature negotiation shall take place during service creation procedure and applies for a given instance of service and its related session(s), and any optionally associated reports and/or notifications associated with that service until the service is terminated. The Content Provider shall include in the HTTP POST the set of supported features as follows:
– if a feature is required for the proper operation of the service, its associated session management, and reporting and/or notification functionality, if applicable, it shall be included within the 3gpp-Required-Features header;
– if a feature is optional for the proper operation of the service, its associated session management, and reporting and/or notification functionality, if applicable, it shall be included within the 3gpp-Optional-Features header.
The BM-SC shall include, within the 3gpp-Accepted-Features header in the response to the HTTP POST, the set of features it supports in common with the Content Provider.
If the BM-SC does not support any of the required features advertised by the Content-Provider within the 3gpp-Required-Features header, the BM-SC shall reject the HTTP POST with an HTTP 412 Precondition Failed status code and shall include the commonly supported features with the Content Provider within the 3gpp-Accepted-Features.
If the BM-SC requires certain features to be supported that are not advertised by the Content Provider, the BM-SC shall reject the HTTP POST with an HTTP 412 Precondition Failed status code and shall include the commonly supported features with the Content Provider within the 3gpp-Accepted-Features and the required features in the 3gpp-required-features.
If the BM-SC and Content Provider successfully negotiate supported features, the list of commonly supported features shall be applicable for the created service, related session(s) and any optionally associated reports and/or notifications, until it is deleted. Features that are not advertised as supported shall not be used for that service.
The sender may send information that is related to the supported features. Any unrecognized/supported information shall be ignored by the receiver.
The table below defines the features applicable to the xMB interface.
Table 9.1-1: Features used in xMB Interface
|
Feature |
M/O |
Description |
|
LocalMBMS |
O |
The feature indicates the support of Local MBMS data delivery. |
|
FilePush |
O |
The feature indicates the support of File Session Push Mode user plane procedures as specified in clause 6.2.2 |
|
FilePull |
O |
The feature indicates the support of File Session Pull Mode user plane procedures as specified in clause 6.2.3 |
|
ApplicationPush |
O |
The feature indicates the support of Application Push Mode user plane procedures as specified in clause 6.3.2 |
|
ApplicationPull |
O |
The feature indicates the support of Application Pull Mode user plane procedures as specified in clause 6.3.3 |
|
RTPStreaming |
O |
The feature indicates the support of RTPStreaming user plane procedures as specified in clause 6.4 |
|
Transport |
O |
The feature indicates the support of Transport user plane procedures as specified in clause 6.5 |
|
FEC |
O |
This feature indicates the support of applying FEC (see IETF RFC 6363 [29]) to downlink packet streams at the BM-SC. |
|
ROHC |
O |
This feature indicates the support of applying ROHC (see IETF RFC 5795 [27] and IETF RFC 3095 [28]) to downlink packet streams at the BM-SC. |
|
GroupContentDelivery |
O |
This feature indicates the support of delivering contents to a group of UEs. |
|
MCExtension |
O |
This feature indicates the support of the xMB mission critical extension as specified in clause 4.3.2 and clause 5.2.2.1. |
|
ResourceSharing |
O |
This feature indicates the support of sharing transmission resource for different MBMS services. |
|
SaProfile |
O |
This feature indicates the support of BM-SC supplied Service Announcement profile. |
|
FileRepair |
O |
This feature indicates the support of content provider supplied file repair function. |
|
Feature: A short name for the feature to which the M/O and description pertain. M/O: Indication on whether the implementation of the feature is mandatory ("M") or optional ("O") in this 3GPP Release. Description: Textual description of the feature. |
||
NOTE: The base functionality for the xMB interface is defined in the Release-14 version of this specification and a feature is an extension of that functionality. The negotiation of supported features allows interworking between the endpoints of the xMB interface whereby each entity may support all, some, or none of the features that the xMB application can support defined in this specification. Features are defined so that they are independent of each other. Any introduced feature is explicitly defined in this specification.
9.2 HTTP custom headers
9.2.0 General
This clause defines any new HTTP custom headers introduced by this specification.
9.2.1 3gpp-Optional-Features
This header is used by the Content Provider to advertise the optional features that are supported by the Content Provider.
The encoding of the header follows the ABNF as defined in IETF RFC 7231 [6].
3gpp-Optional-Features = "3gpp-Optional-Features" ":" 1#token
n example is: 3gpp-Optional-Features: feature1, feature2
9.2.2 3gpp-Required-Features
This header is used by the Content Provider to announce the mandatory features that must be supported in BM-SC.
This header is also used by the BM-SC to indicate the missing features that must be supported in Content Provider.
The encoding of the header follows the ABNF as defined in IETF RFC 7231 [6].
3gpp-Required-Features = "3gpp-Required-Features" ":" 1#token
An example is: 3gpp-Required-Features: feature1, feature2
9.2.3 3gpp-Accepted-Features
The header is used by the BM-SC to confirm the commonly supported set of features with the Content Provider.
The encoding of the header follows the ABNF as defined in IETF RFC 7231 [6].
3gpp-Accepted-Features = "3gpp-Accepted-Features" ":" 1#token
An example is: 3gpp-Accepted-Features: feature1, feature2