5 xMB API

29.1163GPPRelease 18Representational state transfer over xMB reference point between content provider and BM-SCTS

5.1 Overview

5.1.0 General

The xMB API is a RESTful API that allows Content Providers to provision broadcast services over 3GPP networks and subsequent ingestion of service content for distribution using eMBMS. The xMB API defines a set of resources and the related procedures for the creation and management of broadcast services and sessions are described in clause 5.2. The corresponding JSON schema for the representation of the resources and operations defined by the xMB API is provided in its complete form in Annex B. The syntax follows the rules defined by the OpenAPI specification [22].

5.1.1 Supported Methods

The xMB API follows the RESTful design principles. All operations SHALL be performed using HTTP 1.1 (IETF RFC 7231 [6]) over TLS (3GPP TS 33.246[24]).

Table 5.1.1-1 gives a summary of the supported HTTP methods and their applicability on a per resource basis.

Table 5.1.1-1: Summary of supported HTTP methods of xMB API

HTTP Method	CRUD	Resource	PATH
POST	Create	Service	/xmb/v1.0/services
		Session	/xmb/v1.0/services/{service-res-id}/sessions
GET	Read	Service	/xmb/v1.0/services/{service-res-id}/sessions/{session-res-id}
		Session	/xmb/v1.0/services/{service-res-id}/sessions/{session-res-id}
		Report	/xmb/v1.0/reports?query or /xmb/v1.0/reports/{report-res-id}
		Notification	/xmb/v1.0/notifications?query or /xmb/v1.0/notifications/{notification-res-id}
PUT	Replace	Service	/xmb/v1.0/services/{service-res-id}
		Session	/xmb/v1.0/services/{service-res-id}/sessions/{session-res-id}
PATCH	Modify	Service	/xmb/v1.0/services/{service-res-id}
		Session	/xmb/v1.0/services/{service-res-id}/sessions/{session-res-id}
DELETE	Delete	Service	/xmb/v1.0/services/{service-res-id}
		Session	/xmb/v1.0/services/{service-res-id}/sessions/{session-res-id}

5.1.2 Error Handling

The xMB API shall use the HTTP status codes to indicate any errors that might occur in the processing of operations on xMB resources. Unless defined otherwise, the HTTP status codes shall be interpreted as specified in IETF RFC 7231 [6]. API operations that are not successfully handled shall not leave the resource at an undefined state. The response should provide sufficient information for a human operator to understand and locate the error.

API operations that do not follow the security procedures defined in clause 7 shall be rejected without any impact on the resources.

Errors may also happen during the content ingestion and shall be notified to the Content Provider in a timely manner depending on the severity of the error.

5.1.3 xMB Entry Point Discovery

The Content Provider shall be able to discover the entry point to the xMB interface by one of the following methods:

a) It is provided with the URL that serves as the entry point for the xMB-C interface;

b) It acquires that entry point URL from DNS resolution of the following Fully Qualified Domain Name (FQDN):

http://mbmsbs.mnc<MNC>.mcc<MCC>.pub.3gppnetwork.org,

in which case the Content Provider shall build the following URL for the entry point of the xMB interface:

http://mbmsbs.mnc<MNC>.mcc<MCC>.pub.3gppnetwork.org/xmb/v1.0/.

5.1.4 Content type

The bodies of HTTP request and successful HTTP responses shall be encoded in JSON format (see IETF RFC 8259 [34]).

The MIME media type that shall be used within the related Content-Type header field is "application/json", as defined in IETF RFC 8259 [34].

JSON object used in the HTTP PATCH request shall be encoded according to "JSON Merge Patch" (IETF RFC 7396 [35]) but within the related Content-Type header field the MIME media type shall be signalled as "application/json".

NOTE: In this Release of the specification only MIME media type "application/json" is supported.

5.2 Resources

5.2.1 Services

5.2.1.0 General

The Content Provider shall configure services at the BM-SC using the REST API methods over two resources managed at the BM-SC.

Table 5.2.1-1 summarizes different resources for provisioning and managing services at the BM-SC.

Table 5.2.1-1: Resources for managing services at BM-SC

Resource Name	Resource Type	Description
service	Instance resource	Represents a single service resource. The Content Provider can provision or modify a single service at the BM-SC by invoking REST API requests to this service resource at the BM-SC.
services	Collection Resource	Represents a collection of service resources.

5.2.1.1 Properties

Each service resource described in Table 5.2.1-1 has the set of properties described in Table 5.2.1.1-1. The Content Provider shall modify one or more of the properties of the service resource using the API operations described in clause 5.2.1.2.

Table 5.2.1.1-1 summarizes different service properties of a service resource.

Table 5.2.1.1-1: Properties of service resource

Property Token	JSON Value Type	Defaults			Property Description	Applicability (NOTE)
		Child Parameter	Units	Values
service-id	string		None	N/A	Identifies the MBMS User Service as defined in clause 11.2.1.1 of 3GPP TS 26.346 [3]
service-class	string		None	(operator defined default)	The service class that service belongs to. (see serviceClass element in clause 11.2.1.2 of 3GPP TS 26.346 [3]).
service-languages	array		None	Empty list	List of language of the service content. (see serviceLanguage element in clause 11.2.1.1 of 3GPP TS 26.346 [3]).
service-names	array		None	Empty list	List of Service Names. (see name element in clause 11.2.1.1 of 3GPP TS 26.346 [3])
receive-only-mode	boolean		None	False	When set to ‘true’, the Content Provider indicates that the service is a Receive Only Mode service.
service-announcement-mode	string		None	SACH	Enumeration of Service Announcement Mode. Additional service announcement modes may be added in the future. – "SACH": BM-SC performs the service announcement for the current service using the SACH channel (cf. Annex L.2, L3 of 3GPP TS 26.346 [3]). – "Content Provider": BM-SC provides the necessary service access information used by the Content Provider to create the service announcement information.
consumption-reporting-configuration	object				The Content Provider wishes to collect consumption reports for the service. Reporting start and end time: The reporting period with start and end time. Reporting interval: The interval for which the BM-SC is aggregate the statistics in seconds. (Data type: number; default value: 3600) Sample percentage: Percentage of users to collect reports from (Data type: number; default value: 10) The presence of this object indicates the enabling of consumption reporting; if not present, it indicates the disabling of the consumption reporting.
push-notification-url	string		None	“”	The Content Provider provides Notification URL over which it will receive notifications "pushed" by the BM-SC. The Notification procedure is described in clause 5.3.6. of 3GPP TS 26.348 [33]
push-notification-configuration	string		None	All	If the Content Provider enables push delivery of notifications, then the Content Provider may provide notification filters This parameter contains a comma separated list of Classes it wishes to receive among the following options: Critical, Warning, Information, Service, Session, or All to get all types of notification. The notification message shall be sent immediately to the Content Provider upon its availability.
NOTE: Properties marked with a supported feature are applicable as described in clause 9.

The service instance resource with the properties defined above can be found in Annex B.

5.2.1.2 API Operations

5.2.1.2.1 Introduction

Services can be created, updated, or deleted at the BM-SC by the Content Provider, or the properties of a previously created service at the BM-SC may be obtained by the Content Provider, by invoking HTTP methods on the "service" instance resource or the “services” collection resource.

5.2.1.2.2 Service Creation

POST /xmb/v1.0/services

To create a service, the Content Provider shall use the HTTP POST method on the "services" collection resource as follows:

– the request URI with the "path" part is set to: "/xmb/v1.0/services".

– the Host field is set to the address of the BM-SC

The Content Provider shall follow the procedures defined in clause 9 to advertise support of any feature.

The content body of the POST request shall be empty. Upon receipt of the HTTP POST request from the Content Provider to create a service, the BM-SC will check whether the Content Provider is authenticated and authorized to create services as described in clause 7. If the authorization fails, the BM-SC shall send a 401 message as described in Table 5.2.1.2.2-1. If the authorization is successful, the BM-SC shall create a service with default service property values as described in clause 5.2.1.1. Upon successful creation of a service, the BM-SC shall respond to the Content Provider with a 201 message indicating that the service is successfully created along with the service resource identifier of the service resource. The service resource identifier is the identifier that uniquely identifies the service. When the Content Provider receives the service resource identifier, it shall use this identifier in subsequent requests to the BM-SC to refer to this service. Alternatively, if the creation of service failed, the BM-SC shall send a 403 message to the Content Provider.

Both the Content Provider and BM-SC shall remember the negotiated features for the lifetime of the service.

The possible response messages from the BM-SC, depending on whether the POST request is successful or unsuccessful, are shown in Table 5.2.1.2.2-1.

Table 5.2.1.2.2-1: Response status code, message, and contents for service creation

Status Code	Message	Contents
201 Created	Service created successfully	The BM-SC shall send the service resource identifier of the created service.
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 BM-SC may include optional text to indicate why the request could not be fulfilled
412 Precondition Failed	Request cannot be fulfilled	The precondition given in one or more of the request-header fields evaluated to false when it was tested on the recipient.
Note: In addition to the above response codes, the BM-SC can also send appropriate response codes described in IETF RFC 7231 [6] as applicable.

5.2.1.2.3 Service Modification

5.2.1.2.3.1 Partial Modification of Service Properties

PATCH /xmb/v1.0/services/{service-res-id}

Assuming that a service has been created using the service creation method described in clause 5.2.1.2.2, partial updating of its properties can be performed by the Content Provider using the HTTP PATCH method on the "service" instance resource as follows:

– the request URI with the "path" part is set to: "/xmb/v1.0/services/{service-res-id}"

– the Host field is set to the address of the BM-SC

– the Content-Type header field is set to "application/json"

– the body of the message is encoded in JSON format

The {service-res-id} in the request URI is the service resource identifier of the service as allocated by the BM-SC during service creation.

The content body of the service modification request shall contain updated partial representation of the service resource. The representation of the service is based on the JSON schema of the service resource as described in clause 5.2.1.1. Further, one or more properties of the service listed in Table 5.2.1.1-1, with the exception that the value of the properties "id", "service-id", "pull-notification-url" and "receive-only-mode" cannot be modified.

Upon receipt of the HTTP PATCH request from the Content Provider to update a service, the BM-SC will check whether the Content Provider is authenticated and authorized to update services as described in clause 7. If the authorization fails, the BM-SC shall send a 401 message. If the authorization is successful, the BM-SC shall update the requested service. Upon successful updating of the requested service, the BM-SC shall respond to the Content Provider with a 200 OK message indicating that the service is successfully updated along with the updated service resource. If the service was not found, the BM-SC shall send a 404 Not Found message. If the service cannot be updated, the BM-SC shall send a 403 Forbidden message to the Content Provider.

The possible response messages from the BM-SC, depending on whether the PATCH request is successful or unsuccessful, are shown in Table 5.2.1.2.3.1-1.

Table 5.2.1.2.3.1-1: Response status code, message, and contents for service modification using HTTP PATCH

Status Code	Message	Contents
200 OK	The request has succeeded	The BM-SC shall send the service resource that is modified
204 No Content	The request has succeeded	None
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 BM-SC may include optional text to indicate why the request could not fulfilled
404 Not Found	Requested resource not found	None
Note: In addition to the above response codes, the BM-SC can also send appropriate response codes described in IETF RFC 7231 [6] as applicable.

5.2.1.2.3.2 Full Modification of Service Properties

PUT /xmb/v1.0/services/{service-res-id}

Assuming that a service has been created using the service creation method described in clause 5.2.1.2.2, full modification of its properties can be performed by the Content Provider using the HTTP PUT method on the "service" instance resource as follows:

– the request URI with the "path" part is set to: "/xmb/v1.0/services/{service-res-id}".

– the Host field is set to the address of the BM-SC

– the Content-Type header field is set to "application/json"

– the body of the message is encoded in JSON format

The {service-res-id} in the request URI is the service resource identifier of the service as allocated by the BM-SC during service creation.

The content body of the service update request shall contain the updated representation of the service resource. The representation of the service is based on the JSON schema of the service resource as described in clause 5.2.1.1. Furthermore, when HTTP PUT method is used for updating the service, the Content Provider shall specify the updated values of all the service properties with the exception that the value of the properties "id", "service-id", "pull-notification-url" and "receive-only-mode" cannot be modified.

Upon receipt of the HTTP PUT request from the Content Provider to update a service, the BM-SC will check whether the Content Provider is authenticated and authorized to update services as described in clause 7. If the authorization fails, the BM-SC shall send a 401 message as described in Table 5.2.1.2.3.2-1. If the authorization is successful, the BM-SC update the requested service. While updating the service representation, the BM-SC shall overwrite the values of all properties of the service being updated with the values provided in the update request. Upon successful update of the requested service, the BM-SC shall respond to the Content Provider with a 200 OK success message indicating that the service is successfully updated along with the updated service resource. If the service was not found, the BM-SC shall send a 404 Not Found message. If the service cannot be updated, the BM-SC shall send a 403 Forbidden message to the Content Provider.

The possible response messages from the BM-SC, depending on whether the PUT request is successful or unsuccessful, are shown in Table 5.2.1.2.3.2-1.

Table 5.2.1.2.3.2-1: Response status code, message, and contents for service modification using HTTP PUT

Status Code	Message	Contents
200 OK	The request has succeeded	The BM-SC shall send the service resource that is modified
204 No Content	The request has succeeded	None
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 BM-SC may include optional text to indicate why the request could not be fulfilled
404 Not Found	Requested resource not found	None
Note: In addition to the above response codes, the BM-SC can also send appropriate response codes described in IETF RFC 7231 [6] as applicable.

5.2.1.2.4 Service Deletion

DELETE /xmb/v1.0/services/{service-res-id}

To delete a service, the Content Provider shall use the HTTP DELETE method on the "service" instance resource as follows:

– the request URI with the "path" part is set to: "/xmb/v1.0/services/{service-res-id}"

– the Host field is set to the address of the BM-SC

– the Content-Type header field is set to "application/json"

– the body of the message is encoded in JSON format

The {service-res-id} in the request URI is the service resource identifier of the service as allocated by the BM-SC during service creation.

Upon receipt of the HTTP DELETE request from the Content Provider to delete a service, the BM-SC will check whether the Content Provider is authenticated and authorized to delete services as described in clause 7. If the authorization fails, the BM-SC shall send a 401 message as described in Table 5.2.1.2.4-1. If the authorization is successful, the BM-SC shall delete the requested service. Upon successful deletion of requested service, the BM-SC shall respond to the Content Provider with a 200 OK success message indicating that the service is successfully deleted along with the service resource identifier of the service that is deleted. If the service was not found, the BM-SC shall send a 404 Not Found message. If the service cannot be deleted, the BM-SC shall send 403 Forbidden message to the Content Provider.

The possible response messages from the BM-SC, depending on whether the DELETE request is successful or unsuccessful, are shown in Table 5.2.1.2.4-1.

Table 5.2.1.2.4-1: Response status code, message, and contents for service deletion

Status Code	Message	Contents
200 OK	The request has succeeded	The BM-SC shall send the service resource identifier of the service that is deleted
204 No Content	The request has succeeded	None
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 BM-SC may include optional text to indicate why the request could not be fulfilled
404 Not Found	Requested resource not found	None
Note: In addition to the above response codes, the BM-SC can also send appropriate response codes described in IETF RFC 7231 [6] as applicable.

5.2.1.2.5 Service Retrieval

Services can be read when the Content Provider wishes to know the latest representation of the service resource at the BM-SC.

Retrieval of a specific Service

GET /xmb/v1.0/services/{service-res-id}

The retrieval of a service shall be performed by the Content Provider using the HTTP GET method on the "service" instance resource as follows:

– the request URI with the "path" part is set to: "/xmb/v1.0/services/{service-res-id}"

– the Host field is set to the address of the BM-SC

The {service-res-id} in the request URI is the service resource identifier of the service as allocated by the BM-SC during service creation.

Upon receipt of the HTTP GET request from the Content Provider, the BM-SC will check whether the Content Provider is authenticated and authorized to read services as described in clause 7. If the authorization fails, the BM-SC shall send a 401 message as described in table 5.2.1.2.5-1. If the authorization is successful, the BM-SC shall respond to the Content Provider with a 200 OK message along with the service information. The response from the BM-SC to the Content Provider shall contain the following:

– the Content-Type header field is set to "application/json"

– the body of the message is encoded in JSON format

The content body of this response message shall be the representation of the requested service based on the JSON schema of service resource as described in clause 5.2.1.1. The properties "service-id", "service-class", and "service-announcement-mode" shall be included in the response to the Content Provider. All other properties of the service instance are optional to be returned to the Content Provider.

Alternatively, if the service was not found, the BM-SC shall send a 404 Not Found message. If the request cannot be fulfilled, the BM-SC shall send a 403 Forbidden message to the Content Provider.

The possible response messages from the BM-SC, depending on whether the GET request is successful or unsuccessful, are shown in Table 5.2.1.2.5-1.

Table 5.2.1.2.5-1: Response status code, message, and contents for service modification using HTTP GET

Status Code	Message	Contents
200 OK	The request has succeeded	The BM-SC shall send the service representation of the service resource to the Content Provider
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 BM-SC may include optional text to indicate why the request could not be fulfilled
404 Not Found	Requested resource not found	None
Note: In addition to the above response codes, the BM-SC can also send appropriate response codes described in IETF RFC 7231 [6] as applicable.

Retrieval of all Services

GET /xmb/v1.0/services

The retrieval of all services shall be performed by the Content Provider using the HTTP GET method on the "services" instance resource as follows:

– the request URI with the "path" part is set to: "/xmb/v1.0/services"

– the Host field is set to the address of the BM-SC

Upon receipt of the HTTP GET request from the Content Provider, the BM-SC will check whether the Content Provider is authenticated and authorized to read services as described in clause 7. If the authorization fails, the BM-SC shall send a 401 message as described in table 5.2.1.2.5-2. If the authorization is successful, the BM-SC shall respond to the Content Provider with a 200 OK message along with information of all services configured at the BM-SC. The response from the BM-SC to the Content Provider shall contain the following:

– the Content-Type header field set to "application/json"

– the body of the message encoded in JSON format

The content body of this response message shall be the representation of the list of all services configured at the BM-SC where each service representation is based on the JSON schema of service resource as described in clause 5.2.1.1. The properties "service-id", "service-class", and "service-announcement-mode" shall be included for each service representation in the response to the Content Provider. All other properties of the service instance are optional to be returned to the Content Provider.

Alternatively, if there are no services configured at the BM-SC, the BM-SC shall send message content in the 200 OK message indicating to the Content Provider that there are no services configured at the BM-SC. If the request cannot be fulfilled, the BM-SC shall send a 403 Forbidden message to the Content Provider.

The possible response messages from the BM-SC, depending on whether the GET request is successful or unsuccessful, are shown in Table 5.2.1.2.5-2.

Table 5.2.1.2.5-2: Response status code, message, and contents for service modification using HTTP GET

Status Code	Message	Contents
200 OK	The request has succeeded	If there are services configured at the BM-SC, the BM-SC shall send the representations of all the configured services to the Content Provider. If there are no services configured at the BM-SC, the BM-SC shall send message content in this message that there are no services configured at the BM-SC
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 BM-SC may include optional text to indicate why the request could not be fulfilled
Note: In addition to the above response codes, the BM-SC can also send appropriate response codes described in IETF RFC 7231 [6] as applicable.

5.2.2 Sessions

5.2.2.0 General

The Content Provider shall configure sessions at the BM-SC using the RESTful API methods over two resources managed at the BM-SC.

Table 5.2.2-1 summarizes different resources for provisioning and managing sessions at the BM-SC.

Table 5.2.2-1: Resources for managing sessions at BM-SC

Resource Name	Resource Type	Description
Session	Instance resource	Represents a single session resource. The Content Provider can provision or modify a single session at the BM-SC by invoking REST API requests to this session resource at the BM-SC.
Sessions	Collection Resource	Represents a collection of session resources.

Since sessions are configured for each service, the session instance resource or the sessions collection resource are referenced through a particular service.

5.2.2.1 Properties

Each session resource described in Table 5.2.2-1 has the set of properties described in Table 5.2.2.1-1. The Content Provider shall modify one or more of the properties of the session resource using the API operations described in clause 5.2.2.2

Table 5.2.2.1-1 summarizes the different properties of a session resource.

Table 5.2.2.1-1: Properties of session resource

Property Token	JSON Value Type	Defaults		Parameter Description	Applicability (NOTE)
session-start	number	UTC Date timestamp (with second precision)	Session creation date + 1h	Time at which the MBMS Bearer become active.
session-stop	number	UTC Date timestamp (with second precision)	Session start date + 1h	Time at which the MBMS bearer becomes inactive.
max-ingest-bitrate	number	kbps	0	This requested bitrate by the Content Provider for content ingestion at the BM-SC, which excludes FEC overhead and transport overhead. The BM-SC calculates the MBMS Bearer bitrate from its value, considering overhead like FEC and other transport overheads. The session bitrate is always larger than or equal to the payload bitrate
max-delay	number	ms	-1	Specifies the maximum delay the MBMS System should add, i.e. from the time a packet is received by the BM-SC to the time when the packet should be received by the MBMS client.
session-state	string	None	Idle	The BM-SC may automatically change the state of the session. Possible states: "Session Idle", "Session Announced", "Session Active".
service-announcement-starttime	number	UTC Date timestamp (with second precision)	None	When present, the wall-clock time at which the BM-SC shall start service announcement. If absent, the BM-SC may automatically start service announcement when it has all the data needed to perform such service announcement.
geographical-area	<array> string	None	Empty list	Geographical area to which the service is to be provided, via either unicast or MBMS bearers. The BM-SC derives the MBMS service area and the SAI list corresponding to the geographical area as provided by the Content Provider. The Geographical Area contains list of string. If the mc-extension property is present and the MCExtension feature is supported, the content of each string follows the format specified by clause 5.4.7 of 3GPP TS 26.348 [33]. Else, the content of each string item is left to the business agreement between the Content Provider and the Operator.
qoe-reporting-configuration	object			The Content Provider wishes to collect QoE reports for the session. The Content Provider can supply a list of QoE metric configurations where each metric configuration shall contain: Metric name: Name of QoE metric Metric type: Type of metric Reporting interval: The interval at which the BM-SC should periodically aggregate and report the statistics to the Content Provider. Sample percentage: Percentage of users to collect reports from Start time: Start time of report collection End time: End time of report collection If this configuration is included, the QoE reporting configuration shall be applied only for this session., and the Content Provider is requesting override of service level configuration for this session by this configuration.
session-type	string	None	Files	The Session Type represents the method used by the Content Provider in providing content to the BM-SC (via xMB-U). The BM-SC shall select the appropriate delivery method from the Session Type. Valid values: "Streaming", "Files", "Application", "Transport-Mode" When the Session Type is set to "Streaming", the BM-SC expects a Streaming type input (RTP), and the format shall compliant to MBMS streaming (as defined in 3GPP TS 26.346 [3]). When the Session Type is set to "Files", the BM-SC expects generic files as input. The files can be provided either by on-request pull interactions or continuous push ingest. When the Session Type is set to "Application", then the ingest method depends on the application service description. When the Application Service Description corresponds to DASH, the BM-SC expects an MPD and optionally one or more Initialization Segments. The content is assumed to be 3GP-DASH compliant (as defined by 3GPP TS 26.247 [18]). The BM-SC may either pull the Media Segments from the Content Provider or the Content Provider will continuously push Media Segments to the BM-SC. When the Session Type is set to "Transport-Mode", the BM-SC provides transport of data/TV content in a transparent manner. The Content Provider may provide some properties for the MBMS distribution. The Session Type shall be extensible to include other session types.
max-cid	integer	none	none	integer indicating the MAX CID parameter for the compressor (see IETF RFC 5795 [27]). The value for the LARGE_CID parameter (usage of short CID representation or large CID representation) shall be deducted from MAX_CID as follows: If MAX_CID > 15 then LARGE_CIDS = TRUE else LARGE_CIDS = FALSE. When header compression applies, the "max-cid" property shall be provided together with "header-compression" property.	ROHC
header-compression	<array> object	none	none	Requests the BM-SC to enable ROHC (see IETF RFC 5795 [27] and IETF RFC 3095 [28]) on the input flow. The object consists of: – "ipv4addr": String identifying an IPv4 address formatted in the "dotted decimal" notation as defined in in IETF RFC 1166 [31]. – "ipv6addr": String identifying an IPv6 address formatted according to clause 4 of IETF RFC 5952 [32]. The mixed IPv4 IPv6 notation according to clause 5 of IETF RFC 5952 shall not be used. – "port": integer between 0 and 65535 identifying a UDP or TCP port – "periodicity": a number denoting the target periodicity for ROHC full header packets in units of seconds – "profile": integer denoting the applicable ROHC profile (see IETF RFC 5795 [27]). The value is restricted to the 0x0001 RTP/UDP/IP profile or the 0x0002 UDP/IP profile, 0x0001 profile applies if omitted. Either "ipv4addr"or "ipv6addr" shall be included and "port"and "periodicity" may be included. The BM-SC shall: 1. apply the procedures in IETF RFC 5795 [27] and in IETF RFC 3095 [28] to provide header compression to downlink IP packets and possibly higher protocol layers within the user plane data; 2. use the ROHC profile requested in the "profile" property for downlink packet which belongs to any of the flows listed in this property; 3. use the 0x0000 uncompressed profile for any downlink packet which does not belong to any of the flows listed in this property; and 4. use the ROHC unidirectional mode (see IETF RFC 3095 [28]) without ROHC segmentation (see IETF RFC 5795 [27]).	ROHC
fec	string	none	none	Requests the BM-SC to perform FEC (see IETF RFC 6363 [29]) protection of the input flow when transmitting over the MBMS channel. The string shall include an SDP description of FEC framework configuration information (see clause 5.5 of IETF RFC 6363 [29]) formatted according to clause 8A.5 of 3GPP TS 26.346 [3].	FEC
resource-sharing-ind	boolean	none	false	The resource sharing indication. When present and set to "true", it implies the current transmission resources can be shared with other sessions. Note that other sessions will use the same Max Bitrate, Geographical Area and (in case of MC Services) QoS‑Information.	ResourceSharing
resource-sharing-url	string	none	none	The resource sharing id. When present in the session modification request, the value of the field identifies an existing xMB session resource URL (as specified in table 5.1.1-1) to share the transmission, where Max Bitrate, Geographical Area and (in case of MC Services) QoS‑Information are re-used. Note that the Max Bitrate, Geographical Area and (in case of MC Services) QoS‑Information cannot be changed since the values from the original session will be used.	ResourceSharing
session-announcement-mode	string	– None –	Other	Represents the session announcement mode. The session announcement mode is either "Content Provider" or "SACH", with the following behavior: "Content Provider": The BMSC generates the session parameters and provides those to the Content Provider. "SACH": In this case, the session announcement is done by the MBMS system through the SACH. (see Annex L.2, L.3 of 3GPP TS 26.346 [3]). Additional modes may be added in future releases. Only applicable if the Session Type is set to "Transport-Mode"	Transport
userplane-session-description-parameters	object			This property provides information to the BM-SC on where and how to access the user plane content from the content provider, and comprises one or more of the following components: Type: the type of the content associated with the target resource, for example the Internet Media Type of the resource as identified by an HTTP/S URL. An "embedded" type is defined, which indicates that the xMB-U user plane parameters are embedded in the User Plane Parameters object described below. Access URL: A URL that enables the access to and possibly control of the ingest session. The URL may, for example, be an RTSP URL, a reference to an SDP that describes a multicast stream, or an HTTP/S URL to retrieve an already-packaged MPEG2-TS stream. User Plane Parameters: When the Type is set to "embedded", the Content Provider shall provide an object to the BM-SC which contains the session description. If this property is set to Forward-only, the object may contain a ready-made Session Description and the indication of a single xMB-U reception UDP port. When a Session Description is present, the BM-SC shall use it for Service Announcement. If this property is set to Proxy, the object shall contain a Session Description template and a list of the transmitted UDP flows to be forwarded on the established MBMS bearer for the session. For each list entry, the content provider shall indicate whether a) this UDP flow is directly associated with a media description entry in the Session Description Template – i.e., an "m=" line is present in the template and which contains a port field, or b) this UDP flow is related to a media description entry – e.g., it corresponds to an RTCP flow affiliated with the RTP flow as described by the RTP/AVP profile). If the flow is directly associated with a media description entry, then the BM-SC shall modify the port field of the media description entry in the Session Description Template. If the flow is related to a media description entry, then the BM-SC shall simply forward the flow onto a port whose value is equal to the port of the related media session plus an offset. Note the BM-SC may get input on session properties from the content provider, e.g. bitrate, depending on the ingest session.	Transport
userplane-delivery-mode-configuration	string	– None –	Forward-only	This property defines how the session needs to be delivered to the application, i.e. it basically establishes the delivery mode. Mode Enumeration: Specifies the delivery mode. Forward-only: The BM-SC receives complete IP Multicast packets for to be forwarded. The Content Provider will create the IP multicast packets. Proxy: The BM-SC proxies the incoming UDP payloads to the outgoing UDP payloads. The BM-SC will create the IP multicast packets. Only applicable if the Session Type is set to "Transport-Mode".	Transport
delivery-session-description-parameters	string			The contents of this property depend on the setting of the Session Announcement Mode property. If Session Announcement Mode is set to "Content Provider", then at minimum the following session parameters shall be provided by the BM-SC: TMGI of the MBMS Bearer For Receive Only Mode service, the TMGI shall be allocated from the range specified in 3GPP TS 24.116 [25]. Note that additional session parameters may be provided, based on the configuration options of the delivery method set to "Transport-Mode". Only applicable if the Session Type is set to "Transport-Mode".	Transport
sdp-url	string	– None –	""	A URL to the SDP that describes the streaming session between the Content Provider and the BM-SC, which will be used for BM-SC ingestion of the streaming session via xMB-U. 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. The content shall conform to the constraints of this specification. Only applicable if the Session Type is set to "Streaming".	RTPStreaming
time-shifting	number	second	0	Indicates if and for how long time shifting access to the content (using unicast) may be provided for this session. If not set (so defaulted to 0), there shall be no time shifting access. Only applicable if the Session Type is set to "Streaming".	RTPStreaming
application-service	string	MIME type	application/dash+xml	Internet Media Type of the Application Service Only applicable if the Session Type is set to "Application". To refer to 5GMS DASH content, the MIME content type may include a profile parameter including the profile of 5G Media Streaming as "urn:3GPP:5GMS:iop:DASH", as defined in DASH in clause 7.3.11 of 3GPP TS 26.247 [18].	ApplicationPush, ApplicationPull
ingest-mode	string	None	"Push" when Session Type is set to "Application" "Pull" when Session Type is set to "Files"	The ingest mode enumerates how resources are ingested into the BM-SC via xMB-U. When the Session Type is set to "Application": Pull: The BM-SC pulls the resources as described by the application entry point document. Push: The Content Provider pushes resources. The BM-SC needs to provide a push URL. In case of DASH, resources are Media Segments: Pull: The BM-SC pulls the Media Segments as described by the Segment availability start time from a DASH MPD. Push: The Content Provider pushes Media Segments, so that the Media Segment is available on the BM-SC according to Segment availability start time. The BM-SC needs to provide a push URL. When the Session Type is set to "Files": Push: The Content Provider shall push the file to the BM-SC that will immediately process and deliver as soon as it is ready. The BM-SC may be configured to ignore all files that are pushed before session active time, or store them. In case of Push mode, the BM-SC shall provide back to the Content Provider the URL the Content Provider shall use to push the files. Pull: In this case, the Content Provider provides the resource location from which the BM-SC will fetch the file. The Content Provider may tell the BM-SC when to start fetching the file.	ApplicationPush, ApplicationPull, FilePush, FilePull
application-entrypoint-url	string	None	“”	The application entry point refers to an MPD when Application Service Description pertains to DASH. When the Ingest Mode is set to Push, the MPD URL refers to a DASH MPD which should be fetched, optionally conditioned, and then inserted into Service Announcement. When the Ingest Mode is set to Pull, then the BM-SC will fetch the Segments using unicast. Note that if not set to a valid URL, the session will not be started.	ApplicationPush, ApplicationPull,
push-url	string	None	""	When the Session Type is set to "Application": A resource locator for ingesting Media Segments using HTTP via xMB-U. The Content Provider may create additional sub-resources using WebDAV procedures. This is a read-only property managed by the BM-SC and only present when Ingest Mode is set to Push This property is mandatory if the Session type is set to "Application" and Ingest Mode is set to Push. When the Session Type is set to Files: A resource locator for ingesting content using HTTP via xMB-U. This is a read-only property managed by the BM-SC and only present when Ingest Mode is set to Push.	ApplicationPush, FilePush
unicast-delivery	boolean	None	False	Indicator whether the content is also available for unicast retrieval. Only applicable if the Session Type is set to "Application". If set "true", the application client may access the content referenced in the application entry point from a unicast content server or a 5GMS AS.	ApplicationPush, ApplicationPull,
Components	array	None	Empty list	List of components of the application, which are recommended to be made available on MBMS Bearers. In case of DASH, each component is identified by a representation identifier. Only applicable if the Session Type is set to "Application".	ApplicationPush, ApplicationPull,
file-list	array			List of files to be sent. In the Push mode, the file list is not used since the BM-SC will monitor its push folder and send the files it receives on a first-come first-served basis. In Pull mode, the file list contains the following information per file entry: file URL: the URL to the file the BM-SC will use to fetch the content file display URL: The URL to the file as seen by the UE byte-range (optional): If present and set to "true", indicates that the HTTP(S) URL given in the file display URL parameter can be used for Byte-Range-Based file repair (clause 9.3 of 3GPP TS 26.346 [3]) otherwise file display URL parameter should not be used for Byte-Range-Based file repair e-tag (optional): represents the value of the ETag as defined in IETF RFC 7232 [38] which may also serve as the version identifier for the file in the Byte-Range-Based file repair requests. The ETag should only be supplied by the 3rd party content provider if it is expected that it is different from the one provided over xMB-U when fetching the file. file earliest fetch time: The BM-SC shall fetch the file no sooner than this UTC timestamp. If absent, then the file shall be present on the Content Provider server and the BM-SC may fetch it at a time of its choosing. file latest fetch time: The BM-SC shall fetch the file no later than this UTC timestamp. If absent, then the file shall be present on the Content Provider server and the BM-SC may fetch it at a time of its choosing. file size (optional): The Content Provider may provide the precise or a file size estimate as input. The BM-SC may update the file size once it has started to fetch the file. file status: Enumeration stating the state of the file. Possible values are pending, fetched, prepared, transmitting, sent. Target reception completion time (on the MBMS Client): hint on the deadline by which target time the file should be completely received by the UE. The BM-SC should schedule and order the transmission accordingly. Keep Updated Interval: The BM-SC checks the file resources with the given interval for changes. Unicast availability: Indication that the file is also available for unicast retrieval by the application at a Content Provider server whose location is given by the HTTP(S) URL corresponding to the value of "file display URL". File repetition: The number of times the file shall be sent on the session (a value of 1 means the file shall be sent only once). This counter shall be decreased by one each time the file has been transmitted. When the counter reaches zerothe file will cease to be delivered. The BM-SC may send FEC instead of source information. Note that the expected behavior is that the BM-SC will first send all files in the order of the File List, then decrement the file repetition counter for each file, and subsequently retransmit the list again (only files with counter > 0 are transmitted). This is repeated until all repetitions are completed, or the session stop time has elapsed, whichever event occurring first. Periodic update interval: When present, it is an indication that this file of the list of files is expected to be periodically updated, and the value of this parameter represents the nominally expected time interval between successive updates of this file. This parameter is a signal to the BM-SC to deliver the file and its updates as a Datacasting service. From its value, the BM-SC will choose the delivery mode (‘scheduled-and-periodic’ or ‘back-to-back’), and set the associated interval and @mode values in controlling the transmission of the Datacasting service.	FilePull, FileRepair (NOTE 2)
file-delivery-manifest-url	string	None	""	Alternative to the file list for describing file properties and delivery requirements. The resource may additionally describe scheduling information for the file. Only applicable if the Session Type is set to Files.	FilePush, FilePull
display-base-url	string	None	""	When ingest mode is set to Push, the Base URL as seen by the UE.	FilePush
sa-file-url	string	None	""	When the service announcement mode is set to "Content provider", the BM-SC returns the URL of the SA file announcing the session. The BM-SC shall follow the profile 1c (Annex L.3 of 3GPP TS 26.346 [3])	SaProfile
local-mbms-delivery-information	object			The Content Provider may request the BM-SC to activate an MBMS bearer for local MBMS based MBMS data delivery. If so, the Content Provider shall provide: MBMS eNB IPv4 multicast address: Contains the M1 (transport) plane IPv4 destination multicast address used by MBMS-GW for IP multicast encapsulation of application IP multicast datagrams. MBMS eNB IPv6 multicast address: Contains the M1 (transport) plane IPv6 prefix of destination multicast address used by MBMS-GW for IP multicast encapsulation of application IP multicast datagrams. MBMS GW IPv4 SSM address: Contains the value of MBMS-GW’s IPv4 address for Source Specific Multicasting. MBMS GW IPv6 SSM address: Contains the value of MBMS-GW’s IPv6 address for Source Specific Multicasting. Common Tunnel Endpoint Identifier: Indicates the common tunnel endpoint identifier of MBMS GW for user plane. BM-SC IPv4 address: Indicates the destination IPv4 address of the BM‑SC for the reception of user plane data via the xMB‑U interface. BM-SC IPv6 address: Indicates the destination IPv6 address of the BM‑SC for the reception of user plane data via the xMB‑U interface. BM-SC port: Indicates the destination UDP port of the BM‑SC for the reception of user plane data via the xMB‑U interface.	LocalMBMS
group-ids	array	None	Empty list	This parameter contains a list of group identifiers, applicable if the service-announcement-mode is set to "SACH". It is used by the BM-SC in the service announcement for identifying UE belonging to a group.	GroupContentDelivery
mc-extension	object			If the MCExtension feature is supported, the Content Provider may request the BM-SC to activate an MBMS bearer with a specific QoS. If so, the Content Provider shall provide the following QoS properties in the session modification operation, to be used by the BM-SC within the QoS-Information AVP during the MBMS Session start procedure (3GPP TS 29.061 [20]): gbr: Guaranteed bitrate for the MBMS session in unit kbps. The BM-SC shall use this value for the Guaranteed-Bitrate-DL AVP. The difference between the max-ingest-bitrate and gbr can be used by the BM-SC as a budget for FEC. qci: QoS Class identifier. The BM-SC shall use this value for the QoS-Class-Identifier AVP. arp-priority-level: the BM-SC shall use this value for the Priority-Level AVP within the Allocation-Retention-Priority AVP. arp-pre-emption-capability: the BM-SC shall use this value for the Pre-emption-Capability AVP within the Allocation-Retention-Priority AVP. arp-pre-emption- vulnerability: the BM-SC shall use this value for the Pre-emption- Vulnerability AVP within the Allocation-Retention-Priority AVP. If the Content Provider includes the mc-extension property during the session modification operation, the BM-SC shall return the following property in the session retrieval operation: tmgi: the TMGI of the MBMS session, as returned by the MBMS Session start procedure in 3GPP TS 29.061 [20], the encoding of TMGI is specified in 3GPP TS 24.008 [37], from octet 3 to 8.	MCExtension
NOTE 1: Properties marked with a supported feature are applicable as described in clause 9. NOTE 2: FileRepair feature is only applicable for byte-range and e-tag properties.

The session instance resource with the properties defined above for each session can be found in Annex B.

5.2.2.2 API Operations

5.2.2.2.1 Introduction

Sessions can be created, updated, or deleted at the BM-SC by the Content Provider, or the properties of a previously created session at the BM-SC, may be obtained by the Content Provider by invoking HTTP methods on the “session” instance resource or the “sessions” collection resource.

5.2.2.2.2 Session Creation

POST /xmb/v1.0/services/{service-res-id}/sessions

To create a session, the Content Provider shall use the HTTP POST method on the "sessions" collection resource as follows:

– the request URI with the "path" part is set to: /xmb/v1.0/services/{service-res-id}/sessions.

– the Host field is set to the address of the BM-SC

The {service-res-id} in the request URI is the service resource identifier of the service for which the session creation is sought.

The content body of the session creation request shall be empty.

Upon receipt of the HTTP POST request from the Content Provider to create a session, the BM-SC will check whether Content Provider is authenticated and authorized to create sessions as described in clause 7. If the authorization fails, the BM-SC shall send a 401 message. If authorization is successful, the BM-SC shall verify that the service already exists with the given service resource identifier. If the service with given service resource identifier exists at the BM-SC, the BM-SC shall create the requested session for that service with default session property values described in clause 5.2.2.1. Upon successful creation of requested session, the BM-SC shall respond to the Content Provider with a 201 success message indicating that the session is successfully created along with the session resource identifier of the created session. The session resource identifier is the identifier that uniquely identifies the session within that service. When the Content Provider receives the session resource identifier, it shall use this identifier in subsequent requests to the BM-SC to refer to this session. If the creation of session failed, the BM-SC shall send a 403 message. If the service was not found for which the session creation is sought, the BM-SC shall send a 404 message.

The possible response messages from the BM-SC, depending on whether the POST request is successful or unsuccessful, are shown in Table 5.2.2.2.2-1.

Table 5.2.2.2.2-1: Response status code, message, and contents for session creation

Status Code	Message	Contents
201 Created	Session created successfully	The BM-SC shall send the session resource identifier of the created session.
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 BM-SC may include optional text to indicate why the request could not be fulfilled
Note: In addition to the above response codes, the BM-SC can also send appropriate response codes described in IETF RFC 7231 [6] as applicable

5.2.2.2.3 Session Modification

5.2.2.2.3.0 General

Sessions created using the session creation methods described in clause 5.2.2.2.2 can be updated when the Content Provider wishes to modify the session properties.

5.2.2.2.3.1 Partial Modification of Session Properties

PATCH /xmb/v1.0/services/{service-res-id}/sessions/{session-res-id}

Assuming that a session has been created using the session creation method described in clause 5.2.2.2.2, partial updating of its properties can be performed by the Content Provider by using the HTTP PATCH method on the “session” instance resource as follows:

– the request URI with the "path" part is set to: /xmb/v1.0/services/{service-res-id}/sessions/{session-res-id}

– the Host field is set to the address of the BM-SC

– the Content-Type header field is set to "application/json"

– the body of the message is encoded in JSON format

The {service-res-id} in the request URI is the service resource identifier of the service whose session is being modified.

The {session-res-id} in the request URI is the session resource identifier of the session that is being modified.

The content body of the session update request shall contain updated partial representation of the session resource. The representation of the session is based on the JSON schema of session resource as described in clause 5.2.2.1. Furthermore, one or more properties of the session listed in table 5.2.2.1-1 with the exception that the session properties "id", "session-state", "qoe-report-url", "delivery-session-description-parameters" and "push-url" cannot be modified.

Upon receipt of the HTTP PATCH request from the Content Provider to update a session, the BM-SC will check whether the Content Provider is authenticated and authorized to update sessions as described in clause 7. If the authorization fails, the BM-SC shall send a 401 message as described in table 5.2.2.2.3.1-1. If the authorization is successful, the BM-SC shall verify that the service already exists with the given service resource identifier, and a session already exists with the given session resource identifier. If both of them exist, BM-SC shall update the session as requested for that service. Upon successful update of the requested session, the BM-SC shall respond to the Content Provider with a 200 success message indicating that the session is successfully updated along with the updated session resource. As alternative to the 200 OK message, BM-SC may send a 204 No Content success message without any message content to the Content Provider. If the session cannot be updated, the BM-SC shall send a 403 message. If the session is not found or if the service was not found for which the session creation is sought, the BM-SC shall send a 404 message.

The possible response messages from the BM-SC, depending on whether the PATCH request is successful or unsuccessful, are shown in Table 5.2.2.2.3.1-1.

Table 5.2.2.2.3.1-1: Response status code, message, and contents for session modification using HTTP PATCH

Status Code	Message	Contents
200 OK	The request has succeeded	The BM-SC shall send the session resource that is modified
204 No Content	The request has succeeded	None
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 BM-SC may include optional text to indicate why the request could not be fulfilled
404 Not Found	Requested resource not found	None
Note: In addition to the above response codes, the BM-SC can also send appropriate response codes described in IETF RFC 7231 [6] as applicable.

5.2.2.2.3.2 Full Modification of Session Properties

PUT /xmb/v1.0/services/{service-res-id}/sessions/{session-res-id}

Assuming that a session has been created using the session creation method described in clause 5.2.2.2.2, full update of its properties can be performed by the Content Provider using the HTTP PUT method on the "session" instance resource as follows:

– the request URI with the "path" part is set to: /xmb/v1.0/services/{service-res-id}/sessions/{session-res-id}

– the Host field is set to the address of the BM-SC

– the Content-Type header field is set to "application/json"

– the body of the message is encoded in JSON format

The {service-res-id} in the request URI is the service resource identifier of the service whose session is being modified.

The {session-res-id} in the request URI is the session resource identifier of the session that is being modified.

The content body of the session update request shall contain updated representation of the session resource. The representation of the session is based on the JSON schema of session resource as described in clause 5.2.2.1. Furthermore, when the HTTP PUT method is used for updating the service, the Content Provider shall specify the updated values of all the session properties with the exception that the session properties "id", "session-state", "qoe-report-url", "delivery-session-description-parameters" and "push-url" cannot be modified.

Upon receipt of the HTTP PUT request from the Content Provider to update a session, the BM-SC will check whether the Content Provider is authenticated and authorized to update sessions as described in clause 7. If the authorization is unsuccessful, the BM-SC shall send a 401 message as described in table 5.2.2.2.3.2-1. If the authorization is successful, the BM-SC shall verify that the service already exists with the given service resource identifier, and a session already exists with the given session resource identifier. If both of them exist, BM-SC shall update the session as requested for that service. While updating session representation, the BM-SC shall overwrite the values of all properties of the session being updated with the values from provided in the update request. Upon successful update of the requested session, the BM-SC shall respond to the Content Provider with a 200 success message indicating that the session is successfully updated along with the updated session resource. As an alternative to 200 OK success message, BM-SC may send a 204 No Content success message without any message content to the Content Provider. If the session cannot be updated, the BM-SC shall send a 403 message. If the session is not found or if the service was not found for which the session creation is sought, the BM-SC shall send a 404 message.

The possible response messages from the BM-SC, depending on whether the PUT request is successful or unsuccessful, are shown in Table 5.2.2.2.3.2-1.

Table 5.2.2.2.3.2-1: Response status code, message, and contents for session modification using HTTP PUT

Status Code	Message	Contents
200 OK	The request has succeeded	The BM-SC shall send the session resource that is modified
204 No Content	The request has succeeded	None
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 BM-SC may include optional text to indicate why the request could not be fulfilled
404 Not Found	Requested resource not found	None
Note: In addition to the above response codes, the BM-SC can also send appropriate response codes described in IETF RFC 7231 [6] as applicable.

5.2.2.2.4 Session Deletion

DELETE /xmb/v1.0/services/{service-res-id}/sessions/{session-res-id}

To delete a session, the Content Provider shall use the HTTP DELETE method on the "session" instance resource as follows:

– the request URI with the "path" part is set to: /xmb/v1.0/services/{service-res-id}/sessions/{session-res-id}

– the Host field is set to the address of the BM-SC

The {service-res-id} in the request URI is the service resource identifier of the service whose session is being deleted.

The {session-res-id} in the request URI is the session resource identifier of the session that is being deleted.

Upon receipt of the HTTP DELETE request from the Content Provider to delete a session, the BM-SC will check whether the Content Provider is authenticated and authorized to delete services as described in clause 7. If the authorization is unsuccessful, the BM-SC shall send a 401 message as described in table 5.2.2.2.4-1. If the authorization is successful, the BM-SC shall verify that the service already exists with the given service resource identifier and a session exists with the given session resource identifier. If both of them exist, BM-SC shall delete the requested session for the given service. Upon successful deletion of requested session, the BM-SC shall respond to the Content Provider with a 200 success message indicating that the session is successfully deleted along with the service resource identifier and the session resource identifier. As an alternative to the 200 OK success message, BM-SC may send a 204 No Content success message without any message content to the Content Provider. If the session cannot be deleted, the BM-SC shall send a 403 message. If the session is not found or if the service was not found for which the session creation is sought, the BM-SC shall send a 404 message.

The possible response messages from the BM-SC, depending on whether the DELETE request is successful or unsuccessful, are shown in Table 5.2.2.2.4-1.

Table 5.2.2.2.4-1: Response status code, message, and contents for session deletion

Status Code	Message	Contents
200 OK	The request has succeeded	The BM-SC shall send the session resource identifier of the session that is deleted
204 No Content	The request has succeeded	None
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 BM-SC may include optional text to indicate why the request could not be fulfilled
404 Not Found	Requested resource not found	None
Note: In addition to the above response codes, the BM-SC can also send appropriate response codes described in IETF RFC 7231 [6] as applicable.

5.2.2.2.5 Session Retrieval

Sessions can be read when the Content Provider wishes to know the latest representation of the session resources at the BM-SC.

Retrieval of a specific Session of a specific Service

GET /xmb/v1.0/services/{service-res-id}/sessions/{session-res-id}

The retrieval of a session shall be performed by the Content Provider using the HTTP GET method on the "session" instance resource as follows:

– the request URI with the "path" part is set to: /xmb/v1.0/services/{service-res-id}/sessions/{session-res-id}

– the Host field is set to the address of the BM-SC

The {service-res-id} in the request URI is the service resource identifier of the service as allocated by the BM-SC during service creation.

The {session-res-id} in the request URI is the session resource identifier of the session that is being retrieved.

Upon receipt of the HTTP GET request from the Content Provider, the BM-SC will check whether the Content Provider is authenticated and authorized to read services and sessions as described in clause 7. If the authorization fails, the BM-SC shall send a 401 message as described in table 5.2.2.2.5-1. If the authorization is successful, the BM-SC shall respond to the Content Provider with a 200 OK message and shall include the session resource representation of the session corresponding to the given service to the Content Provider. The response from the BM-SC to the Content Provider shall contain the following:

– the Content-Type header field set to "application/json"

– the body of the message encoded in JSON format

The content body of this response message shall be the representation of the session configured at the BM-SC for the given service where the session representation is based on the JSON schema of session resource as described in clause 5.2.2.1. The properties "session-start", "session-stop", "max-ingest-bitrate", "session-state", "geographical-area", "session-type", "session-announcement-mode", "session-type", "userplane-delivery-mode-configuration", "sdp-url", "application-service-description", "ingest-mode", "application-entryppoint-url", and "unicast-delivery" shall be included in the response to the Content Provider. All other properties of the session instance are optional to be returned to the Content Provider.

Alternatively, if the service was not found or if the session was not found, the BM-SC shall send a 404 Not Found message. If the request cannot be fulfilled, the BM-SC shall send 403 Forbidden message to the Content Provider.

The possible response messages from the BM-SC, depending on whether the GET request is successful or unsuccessful, are shown in Table 5.2.2.2.5-1.

Table 5.2.2.2.5-1: Response status code, message, and contents for service modification using HTTP GET

Status Code	Message	Contents
200 OK	The request has succeeded	The BM-SC shall send the session representation of the session resource to the Content Provider
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 BM-SC may include optional text to indicate why the request could not be fulfilled
404 Not Found	Requested resource not found	None
Note: In addition to the above response codes, the BM-SC can also send appropriate response codes described in IETF RFC 7231 [6] as applicable.

Retrieval of all Sessions of a Service

GET /xmb/v1.0/services/{service-res-id}/sessions

The retrieval of all sessions of a service shall be performed by the Content Provider using the HTTP GET method on the "sessions" instance resource as follows:

– the request URI with the "path" part is set to: /xmb/v1.0/services/{service-res-id}/sessions

– the Host field is set to the address of the BM-SC

The {service-res-id} in the request URI is the service resource identifier of the service as allocated by the BM-SC during service creation.

Upon receipt of the HTTP GET request from the Content Provider, the BM-SC will check whether the Content Provider is authenticated and authorized to read services and sessions as described in clause 7. If the authorization fails, the BM-SC shall send a 401 message as described in table 5.2.2.2.5-2. If the authorization is successful, the BM-SC shall respond to the Content Provider with a 200 OK message. If there are sessions configured at the BM-SC for the corresponding service, the BM-SC shall send the representation of the list of all session resources configured at the BM-SC for that service along with the 200 OK message. If there are no sessions configured at the BM-SC for that service, the BM-SC shall send message content in the 200 OK message indicating to the Content Provider that there are no sessions configured at the BM-SC for that service.

The response from the BM-SC to the Content Provider shall contain the following:

– the Content-Type header field set to "application/json"

– the body of the message encoded in JSON format

The content body of this response message shall be the representation of list of sessions configured at the BM-SC for the given service where each session representation is based on the JSON schema of session resource as described in clause 5.2.2.1. The properties "session-start", "session-stop", "max-ingest-bitrate", "session-state", "geographical-area", "session-type", "session-announcement-mode", "session-type", "userplane-delivery-mode-configuration", "sdp-url", "application-service-description", "ingest-mode", "application-entryppoint-url", and "unicast-delivery" shall be included for each session representation in the response to the Content Provider. All other properties of the session instance are optional to be returned to the Content Provider.

Alternatively, if the request cannot be fulfilled, the BM-SC shall send 403 Forbidden message to the Content Provider. If the service was not found, the BM-SC shall send a 404 Not Found message

The possible response messages from the BM-SC, depending on whether the GET request is successful or unsuccessful, are shown in Table 5.2.2.2.5-2.

Table 5.2.2.2.5-2: Response status code, message, and contents for service modification using HTTP GET

Status Code	Message	Contents
200 OK	The request has succeeded	If there are sessions configured at the BM-SC for that service, the BM-SC shall send the representations of all the configured sessions for that service to the Content Provider. If there are no sessions configured at the BM-SC for that service, the BM-SC shall send message content in this message indicating to the Content Provider that there are no sessions configured at the BM-SC for this service
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 BM-SC may include optional text to indicate why the request could not be fulfilled
404 Not Found	Requested resource not found	None
Note: In addition to the above response codes, the BM-SC can also send appropriate response codes described in IETF RFC 7231 [6] as applicable.

5.2.3 Reports

5.2.3.0 General

The BM-SC shall send reports to the Content Provider upon request by the Content Provider. Table 5.2.3-1 summarizes different report resources that the BM-SC manages for sending reports to the Content Provider.

Table 5.2.3-1: Resources for managing reports at BM-SC

Resource Name	Resource Type	Description
Report	Instance resource	Represents a single report resource. The BM-SC can send an individual report to the Content Provider using the report instance resource
Reports	Collection Resource	Represents a collection of report resources.

Reports can be generated separately for each service or for a session belonging to a particular service. Therefore, a report can be referenced with a given service resource identifier or for a combination of service resource identifier and session resource identifier.

5.2.3.1 Properties

Each report resource described in Table 5.2.3-1 has the set of properties described in Table 5.2.3.1-1. The BM-SC shall deliver the reports as indicated by this structure using the API operations described in clause 5.2.3.2

Table 5.2.3.1-1 summarizes different service properties of a service resource.

Table 5.2.3.1-1: Resources for managing services at BM-SC

Property Token	JSON Value Type	Parameter Description
report-res-id	string	Report resource identifier
report-starttime	string	Report collection start time
report-endtime	string	Report collection end time
report-type	string	Type of report. Three types of reports can be generated by the BM-SC to send to the Content Provider: Consumption report: Report that provides service consumption information QoE report: Report that provides detailed QoE information of the content received File reception report: Report that provides detailed reception information for each file
report-url	string	Location of the report from where the Content Provider can retrieve the detailed report.
Report	string	Detailed report. This may not be included if report-url is included

The report instance resource with the properties defined above for each report can be found in Annex B.

5.2.3.2 API Operations

5.2.3.2.1 Introduction

The Content Provider can request reports from the BM-SC for a given service or a session belonging to a given service.

5.2.3.2.2 Report Retrieval

Reports can be retrieved by the Content Provider for a service or for a session of a given service using HTTP GET method.

Report Retrieval for a Service

GET /xmb/v1.0/services/{service-res-id}/reports

The retrieval of reports of a service shall be performed by the Content Provider using the HTTP GET method on the "reports" collection resource as follows:

– the request URI with the "path" part set to: "/xmb/v1.0/services/{service-res-id}/reports"

– the Host field is set to the address of the BM-SC

QoE reports however are only available on session level. The {service-res-id} in the request URI is the service resource identifier of the service as allocated by the BM-SC during service creation.

Upon receipt of a HTTP GET request from the Content Provider to retrieve all the reports of a service, the BM-SC will check whether the Content Provider is authenticated and authorized to request reports for services and sessions configured at the BM-SC as described in clause 7. If the authorization fails, the BM-SC shall send a 401 message as described in Table 5.2.3.2.2-1. If the authorization is successful, the BM-SC shall verify that the service with the given service resource identifier exists at the BM-SC. If the service exists at the BM-SC, the BM-SC shall respond to the Content Provider with a 200 success message along with the service resource identifier and the list of all reports for that service. The response from the BM-SC to the Content Provider shall contain the following:

– the Content-Type header field set to "application/json"

– the body of the message encoded in JSON format

The content body of this response message shall be the list of report for that service. Each report in this list shall be based on the JSON schema of report resource as described in clause 5.2.3.1.

Alternatively, if the report retrieval request cannot be fulfilled, the BM-SC shall send a 403 message to the Content Provider. If the service for which the report is sought could not be found, the BM-SC shall send a 404 message to the Content Provider.

The possible response messages from the BM-SC, depending on whether the GET request is successful or unsuccessful, are shown in Table 5.2.3.2.2-1.

Table 5.2.3.2.2-1: Response status code, message, and contents for retrieval of all service reports

Status Code	Message	Contents
200 OK	The request has succeeded	The BM-SC shall send the service resource identifier and all the reports for the service
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 BM-SC may include optional text to indicate why the request could not be fulfilled
404 Not Found	Requested resource not found	None
Note: In addition to the above response codes, the BM-SC can also send appropriate response codes described in IETF RFC 7231 [6] as applicable.

GET /xmb/v1.0/services/{service-res-id}/reports/{report-res-id}

The Content Provider can request individual reports of a service if it is aware of the report resource identifiers of that service. A specific report for a service can be retrieved by the Content Provider using the HTTP GET method on the "report" instance resource as follows.

– the request URI with the "path" part set to: "/xmb/v1.0/services/{service-res-id}/reports/{report-res-id}"

– the Host field is set to the address of the BM-SC

The {service-res-id} in the request URI is the service resource identifier of the service whose reports are being sought.

The {report-res-id} in the request URI is the report resource identifier of that service.

It should be noted that QoE reports are only available on session level. Upon receipt of a HTTP GET request from the Content Provider to retrieve a specific report of a service with report resource identifier, the BM-SC will check whether the Content Provider is authenticated and authorized to request reports for services and sessions configured at the BM-SC as described in clause 7. If the authorization fails, the BM-SC shall send a 401 message as described in Table 5.2.3.2.2-2. If the authorization is successful, the BM-SC shall verify that the service with the given service resource identifier and a report with given report resource identifier exists for that service at the BM-SC. If such report exists at the BM-SC, the BM-SC shall respond to the Content Provider with a 200 success message along with the service resource identifier and the report to the Content Provider. The response from the BM-SC to the Content Provider shall contain the following:

– the Content-Type header field set to "application/json"

– the body of the message encoded in JSON format

The content body of this response message shall be the requested report resource for that service whose representation is based on the JSON schema of report resource as described in clause 5.2.3.1.

Alternatively, if the report retrieval request cannot be fulfilled, the BM-SC shall send a 403 message to the Content Provider. If the service for which the report is sought could not be found, the BM-SC shall send a 404 message to the Content Provider.

The possible response messages from the BM-SC, depending on whether the GET request is successful or unsuccessful, are shown in Table 5.2.3.2.2-2.

Table 5.2.3.2.2-2: Response status code, message, and contents for retrieval of a specific report of a service

Status Code	Message	Contents
200 OK	The request has succeeded	The BM-SC shall send the service resource identifier and the requested report of the service
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 BM-SC may include optional text to indicate why the request could not be fulfilled
404 Not Found	Requested resource not found	None
Note: In addition to the above response codes, the BM-SC can also send appropriate response codes described in IETF RFC 7231 [6] as applicable.

Report Retrieval for a Session of a given Service

GET /xmb/v1.0/services/{service-res-id}/sessions/{session-res-id}/reports

The retrieval of all the reports of a session for a given service shall be performed by the Content Provider using the HTTP GET method on the "reports" collection resource as follows:

– the request URI with the "path" part is set to: "/xmb/v1.0/services/{service-res-id}/sessions/{session-res-id}/reports.

– the Host field is set to the address of the BM-SC

The {service-res-id} in the request URI is the service resource identifier of the service as allocated by the BM-SC during service creation.

The {session-res-id} in the request URI is the session resource identifier of the session whose reports are being sought.

Upon receipt of a HTTP GET request from the Content Provider to retrieve all the reports of a session of given service, the BM-SC will check whether the Content Provider is authenticated and authorized to request reports for services and sessions configured at the BM-SC as described in clause 7. If the authorization fails, the BM-SC shall send a 401 message as described in Table 5.2.3.2.2-3. If the authorization is successful, BM-SC shall verify that the service with the given service resource identifier and a corresponding session with the given session identifier exists at the BM-SC. If such a session exists at the BM-SC, the BM-SC shall respond to the Content Provider with a 200 success message along with the list of all reports for that session. If there are no reports for that session at the BM-SC, the BM-SC shall send a 200 OK message with message content indicating that there are no reports for the session at the BM-SC. The response from the BM-SC to the Content Provider shall contain the following:

– the Content-Type header field set to "application/json"

– the body of the message encoded in JSON format

The content body of this response message shall be the list of all reports for that session. Each report in this list of reports sent shall be based on the JSON schema of report resource as described in clause 5.2.3.1.

Alternatively, if the report retrieval request cannot be fulfilled, the BM-SC shall send a 403 message to the Content Provider. If the session for which the report is sought could not be found, or if the service corresponding to that sessions could not be found, the BM-SC shall send a 404 message to the Content Provider.

The possible response messages from the BM-SC, depending on whether the GET request is successful or unsuccessful, are shown in Table 5.2.3.2.2-3.

Table 5.2.3.2.2-3: Response status code, message, and contents for retrieval of all reports for a session

Status Code	Message	Contents
200 OK	The request has succeeded	The BM-SC shall send the service resource identifier, session resource identifier, and all the reports of that session. If there are no reports for that session at the BM-SC, the BM-SC shall include message content indicating that there are no reports for the requested session at the BM-SC.
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 BM-SC may include optional text to indicate why the request could not be fulfilled
404 Not Found	Requested resource not found	None
Note: In addition to the above response codes, the BM-SC can also send appropriate response codes described in IETF RFC 7231 [6] as applicable.

GET /xmb/v1.0/services/{service-res-id}/sessions/{session-res-id}/reports/{report-res-id}

The Content Provider can request individual reports of a given session of a service if it is aware of the report resource identifiers of that session for that service. A specific report for a session can be retrieved by the Content Provider using the HTTP GET method on the "report" instance resource as follows.

– the request URI with the "path" part is set to: "/xmb/v1.0/services/{service-res-id}/sessions/{session-res-id}/reports/{report-res-id}"

– the Host field is set to the address of the BM-SC

The {service-res-id} in the request URI is the service resource identifier of the service as allocated by the BM-SC during service creation.

The {session-res-id} in the request URI is the session resource identifier of the session whose report is being sought.

The {report-res-id} in the request URI is the report resource identifier that is being sought.

Upon receipt of a HTTP GET request from the Content Provider to retrieve a specific report for a session of a service, the BM-SC will check whether the Content Provider is authenticated and authorized to request reports for services and sessions configured at the BM-SC as described in clause 7. If the authorization fails, the BM-SC shall send a 401 message as described in Table 5.2.3.2.2-4. If the authorization is successful, the BM-SC shall verify that a report with report resource identifier exists for a session with given session resource identifier whose service identifier is the given service resource identifier at the BM-SC. If such a report exists at the BM-SC, the BM-SC shall respond to the Content Provider with a 200 success message along with the requested report to the Content Provider. The response from the BM-SC to the Content Provider shall contain the following:

– the Content-Type header field set to "application/json"

– the body of the message encoded in JSON format

The content body of this response message shall be the requested report resource for that session for the given service and whose representation is based on the JSON schema of report resource as described in clause 5.2.3.1.

Alternatively, if the report retrieval request cannot be fulfilled, the BM-SC shall send a 403 message to the Content Provider. If the session for which the report is sought could not be found, or if the service corresponding to that session could not be found, or if the report is not found, the BM-SC shall send a 404 message to the Content Provider.

The possible response messages from the BM-SC, depending on whether the GET request is successful or unsuccessful, are shown in Table 5.2.3.2.2-4.

Table 5.2.3.2.2-4: Response status code, message, and contents for retrieval of a specifc report of a session

Status Code	Message	Contents
200 OK	The request has succeeded	The BM-SC shall send the service resource identifier, session resource identifier, and the requested report for the service
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 BM-SC may include optional text to indicate why the request could not be fulfilled
404 Not Found	Requested resource not found	None
Note: In addition to the above response codes, the BM-SC can also send appropriate response codes described in IETF RFC 7231 [6] as applicable.

5.2.4 Notifications

5.2.4.0 General

Notifications can be exchanged via two alternative methods. In the first method, the Content Provider can "pull" the notifications from the BM-SC using HTTP GET method if and when the Content Provider wishes to acquire notification information as described in this clause. The second method is that the notifications can be "pushed" from the BM-SC to the Content Provider via the push-notification-url as documented in clause 8.

Table 5.2.4-1 summarizes different notification resources that the BM-SC manages for sending notifications to the Content Provider.

Table 5.2.4-1: Resources for managing services at BM-SC

Resource Name	Resource Type	Description
Notification	Instance resource	Represents a single notification resource. The BM-SC can send an individual notification to the Content Provider using the notification instance resource
Notifications	Collection Resource	Represents a collection of notification resources.

5.2.4.1 Properties

5.2.4.1.0. General

Each notification resource described in Table 5.2.4-1 has the set of properties described in Table 5.2.4.1-1. The BM-SC shall deliver the notifications as indicated by this structure using the API operations described in clause 5.2.4.2.

Table 5.2.4.1-1 summarizes different properties of a notification resource.

Table 5.2.4.1-1: Resources for managing services at BM-SC

Property Token	JSON Value Type	Parameter Description
notification-res-id	string	Notification resource identifier
message-class	string	Enumeration with the following values (may be expanded in the future): Critical, Warning, Information, Service, Session. The message classes bear the following meaning: Critical: When some event drastically prevent the proper delivery of content Warning: When the service can be partially delivered but quality is reduced Information: When the service is properly delivered but some interesting event occurred Session/Service: Information about Service/Session related parameters Table 5.2.4.1-2 shows the information that can be notified for each of the message classes.
message-name	string	Unique identifier of the message. Provides information about the message pertaining to the message-class of the notification Table 5.2.4.1-2 shows the information that can be notified for each of the message classes and message names.
Message-information	object	A dictionary of key values containing informations linked to the notification. Every message-information dictionary shall include the following two keys: date: The value of this key contains the UTC timestamp (in ms) of the date of the event source: The value of this key is hierarchical colon separated format of services and sessions with the format "service-resource-identifier session-resource-identifier". If the notification is for a service, only the service-resource-identifier shall be included in this value. An empty value for this key shall represent a system wide notification. Table 5.2.4.1-x shows the additional key value pairs that can be included in the message-information for each of the message-class and message-name.

Table 5.2.4.1-2 shows the notification details that can be sent for each of the message classes.

Table 5.2.4.1-2: Notification Details for different message classes

Message Class	Possible Message Name	Additional Key Value Pairs in message-information dictionary
Critical	network-is-down	None
	service-badly-configured	bad-or-missing-parameters: [ <property name>, ..]
	session-badly-configured	bad-or-missing-parameters: [ <property name>, ..]
Warning	incoming-bitrate-exceed-session-capacity	incoming-bit-rate:<value in kbps>
	no-incoming-data	None
Information	qoe-report-available	None
	consumption-reports-available	None
	reception-reports-available	None
Service	service-announcement-change	None
Session	session-state-change	from-state:<from state> to-state: <to state> where the from state and to state have one of the values in the enumeration: Session Idle Session Announced Session Active Session Terminated
	file-ready-for-transmission	file-url:<file URL> file-size: <file-size> transmission-size: <transmission-size>
	file-download-started	file-url:<file URL>
	file-successfully-sent	file-url:<file URL>
	file-fetch-error	file-url:<file URL> http-error-code: <error-code>
Note 1: For the message-class "Service", the message-name service-announcement-change applies only when the session-state is in Session Announced or Session Active states. Note 2: For the message-class "Session", the message-name file-ready-for-transmission applies only when the session-type is "Files". Note 3: For the message-class "Session", the message-name file-download-started applies only when the session-type is "Files". Note 4: For the message-class "Session", the message-name file-successfully-sent applies only when the session-type is "Files".

The notification instance resource with the properties defined in Table 5.2.4.1-1 can be found in Annex B.5.2.4.2 API Operations

5.2.4.2.1 Introduction

The Content Provider can request individual service and session level notifications and system-wide notifications from the BM-SC. The notifications are configured by the Content Provider when it creates services and sessions at the BM-SC. Notifications can be retrieved by the Content Provider from the BM-SC at times of its choice and shall use techniques such as long polling to poll the BM-SC for available notifications. Notifications can be retrieved from the BM-SC using HTTP methods on the notifications collection resource.

5.2.4.2.2 Notification Retrieval

Retrieval of All Notifications

GET /xmb/v1.0/notifications

The retrieval of all the notifications shall be performed by the Content Provider using the HTTP GET method on the "notifications" collection resource as follows:

– the request URI with the "path" part is set to: /xmb/v1.0/notifications

– the Host field is set to the address of the BM-SC

Upon receipt of a HTTP GET request from the Content Provider to retrieve all the notifications, the BM-SC will check whether the Content Provider is authenticated and authorized to request notifications as described in clause 7. If the authorization fails, the BM-SC shall send a 401 message as described in table 5.2.4.2.2-1. If the authorization is successful, the BM-SC shall respond to the Content Provider with a 200 success message along with the list of all notifications. If there are no available notifications at the BM-SC, the BM-SC shall send a 200 OK message with message content indicating that there are no available notifications. The response form the BM-SC to the Content Provider shall contain the following:

– the Content-Type header field set to "application/json"

– the body of the message encoded in JSON format

The content body of this response message shall be the list of notifications available at the BM-SC. Each notification in this list shall be based on the JSON schema of notification resource as described in clause 5.2.4.1.

Alternatively, if the notification retrieval request cannot be fulfilled, the BM-SC shall send a 403 message to the Content Provider.

The possible response messages from the BM-SC, depending on whether the GET request is successful or unsuccessful, are shown in Table 5.2.4.2.2-1.

Table 5.2.4.2.2-1: Response status code, message, and contents for retrieval of all notifications of service

Status Code	Message	Contents
200 OK	The request has succeeded	The BM-SC shall send all the notifications. If there are no notifications available at the BM-SC, the BM-SC shall include message content indicating that there are no notifications at the BM-SC.
401 Unauthorized	Request requires user authentication	In accordance to conditions as described in IETF RFC 7235 [8] and IETF RFC 7231 [6].
403 Forbidden	Request cannot be fulfilled	The BM-SC may include optional text to indicate why the request could not fulfilled.
Note: In addition to the above response codes, the BM-SC can also send appropriate response codes described in IETF RFC 7231 [6] as applicable.

Individual notifications can be accessed using HTTP GET method by referencing the "notification-res-id".