6 User Plane Procedures
29.1163GPPRelease 18Representational state transfer over xMB reference point between content provider and BM-SCTS
6.1 Introduction
The xMB-U user plane procedures cover the transmission of service data between the Content Provider to the BM-SC. Only authorized and authenticated Content Provider sources shall be able to provide user plane data over xMB-U to the BM-SC. The following data transfer modes are supported:
– File Push: the Content Provider uploads or transmits files to the BM-SC either as soon as they become available, or in advance.
– File Pull: the Content Provider makes files available prior to the session start and at least during the lifetime of a session. The BM-SC will retrieve the files when it needs to deliver them.
– RTP Streaming: the BM-SC establishes an RTSP session to the Content Provider and starts the streaming session to relay media streams.
– Transport: the BM-SC listens on one IP address and one port number to receive UDP packets.
The details of these procedures are provided in the following clauses.
6.2 File Session
6.2.1 General
Provisioning files for file distribution shall use one of the two options in the following clauses.
6.2.2 Push Mode
WebDAV as described in IETF RFC 4918 [9] or HTTP v1.1 shall be used over TLS. The Content Provider shall use the PUT method and place the file in the message body of the request associated with the push-url. The Content Provider shall ensure that each file is available at the BM-SC latest at its provided "file-earliest-fetch-time", or if that parameter is not provided, prior to the session start. Potential response codes and their interpretation is provided in Table 6.2.2-1.
Table 6.2.2-1: Response status code, message, and contents of File Push mode
|
Status Code |
Message |
Contents |
|
201 Created |
File pushed successfully |
None |
|
401 Unauthorized |
Request requires user authorization |
In accordance to conditions as described in IETF RFC 7231 [6] and IETF RFC 7235 [8] |
|
403 Forbidden |
Request cannot be fulfilled |
The Content Provider may include optional text to indicate why the request could not be fulfilled, e.g. incorrect URL used |
6.2.3 Pull Mode
HTTP v1.1 shall be used over TLS in Pull mode. The BM-SC shall use GET method to request each file as defined by the file-list or alternatively by the manifest received from the file-delivery-manifest-url. The BM-SC shall pull each file earliest at its provided "file-earliest-fetch-time", or if that parameter is not provided, prior to the session start. Upon a successful GET, the Content Provider shall provide the requested file in the response body. Potential response codes and their interpretation is provided in Table 6.2.3-1.
Table 6.2.3-1: Response status code, message, and contents of File Pull mode
|
Status Code |
Message |
Contents |
|
200 OK |
The request has succeeded |
The Content Provider shall send the requested file in the response body. |
|
401 Unauthorized |
Request requires user authentication |
In accordance to conditions as described in IETF RFC 7231 [6] and IETF RFC 7235 [8] |
|
403 Forbidden |
Request cannot be fulfilled |
The Content Provider may include optional text to indicate why the request could not be fulfilled |
|
404 Not Found |
Requested resource not found |
None |
|
Note: If "file-delivery-manifest-url" is used, and if there is any error code in response to the request to get the manifest from the provided URL, the session is not started. |
||
6.3 Application Session
6.3.1 General
Application mode, including DASH service delivery shall use one of the two options in the following clauses.
6.3.2 Push Mode
WebDAV as described in IETF RFC 4918 [9] or HTTP v1.1 shall be used over TLS. The Content Provider shall use PUT method with the resource (Application Session) or the Media Segment (DASH) in the message body, to place it at the push-url. The Content Provider shall ensure that each Segment is available at the BM-SC prior to its prescribed Segment availability start time in the MPD, or if that parameter is not provided, prior to the session start. Potential response codes and their interpretation is provided in Table 6.2.2-1.
Table 6.3.2-1: Response status code, message, and contents of Application (including DASH) Push mode
|
Status Code |
Message |
Contents |
|
201 Created |
File pushed successfully |
None |
|
401 Unauthorized |
Request requires user authorization |
In accordance to conditions as described in IETF RFC 7231 [6] and IETF RFC 7235 [8] |
|
403 Forbidden |
Request cannot be fulfilled |
The Content Provider may include optional text to indicate why the request could not be fulfilled, e.g. incorrect URL was used |
6.3.3 Pull Mode
HTTP v1.1 shall be used over TLS in Pull mode. For DASH service, the BM-SC shall use the application-entry-point-url to retrieve the MPD. The BM-SC shall use GET method to request the resource, or for DASH, each Media Segment as defined by the MPD. Upon a successful GET, the Content Provider shall provide the requested resource or DASH Segment, respectively, in the response body. Potential response codes and their interpretation is provided in Table 6.2.3-1.
Table 6.3.3-1: Response status code, message, and contents of Application (including DASH) Pull mode
|
Status Code |
Message |
Contents |
|
200 OK |
The request has succeeded |
The Content Provider shall send the requested resource or DASH Segment in the response body. |
|
401 Unauthorized |
Request requires user authentication |
In accordance to conditions as described in IETF RFC 7231 [6] and IETF RFC 7235 [8] |
|
403 Forbidden |
Request cannot be fulfilled |
The Content Provider may include optional text to indicate why the request could not be fulfilled |
|
404 Not Found |
Requested resource not found |
None |
The BM-SC shall ensure that each DASH Media Segment is fully received prior to its prescribed availability start time, or if not provided, prior to the session start.
Note: If "application-entry-point-url" is used, and if there is any error code in response to the request to get the MPD from the provided URL, the session shall not be started.
6.4 RTP Streaming
The Content Provider shall support PSS server functionality according to PSS as described in clause 5.3 of 3GPP TS 26.234 [5]. The streaming session shall be accessible prior to the start of the session. A URL to the SDP file that describes the streaming session between the Content Provider and the BM-SC is provided via the sdp-url, which shall be used for ingesting the streaming session. The SDP shall include the RTSP links for every media session as part of the “a=control” attribute to enable RTSP control of the session. The SDP shall also contain the required bitrate for each of the media sessions.
When the user plane data is provided via UDP, then SRTP over DTLS as described in 3GPP TS 33.246 [24] shall be used for user plane protection. Establishment of TCP based user plane sessions with PSS is not supported.
If there is any error retrieving the SDP, the session shall not be started.
6.5 Transport
For Transport sessions, the BM-SC shall activate the receivers on the indicated IP address and port numbers and shall ensure that firewall and NAT traversal is enabled on these IP addresses and port numbers as defined in the SDP retrieved from the sdp-url. If there is any error retrieving the SDP, the session shall not be started. All traffic shall use DTLS as specified in 3GPP TS 33.246 [24] where both client and server certificates are verified.