5 Protocols

26.2383GPPRelease 17TSUplink streaming

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

5.1 General

Protocol instantiations that can be configured by the functionalities in clause 7 may be used in the context of this specification.

5.2 IMS-based system

5.2.1 System configuration

5.2.1.1 Introduction

In an IMS-based FLUS system, the FLUS control plane or F-C enables the configuration and selection of a FLUS sink for the reception of Media streams delivered over the FLUS user plane or F-U during a FLUS session.

5.2.1.2 FLUS sink configuration and selection

The means for discovery or configuration, and selection by the FLUS source of the FLUS sink depend on the deployment scenario and location of the FLUS sink, as described in sub-clauses 5.2.1.2.1 and 5.2.1.2.2.

5.2.1.2.1 UE-based FLUS sink

In this deployment scenario, the FLUS sink is a directly-targeted recipient of the media content streamed by the FLUS source, The FLUS source is expected to be aware of the identity of the FLUS sink, in the form of a SIP URI, which will be included in the Request-Line of the SIP INVITE message. There is no need for a separately-defined FLUS sink configuration and selection procedure in the delivery of the SIP INVITE from the FLUS source to the FLUS sink.

5.2.1.2.2 Network-based FLUS sink

In this deployment scenario, the FLUS sink is a network ingest server that performs post-processing of the Media streams(s) uploaded from the FLUS source, for subsequent distribution to the recipient UEs. It acts as a SIP Application Server (AS) in the IMS network architecture, and its identity shall be in the form of a "FLUS Factory URI.

The FLUS source may be pre-provisioned with the FLUS Factory URI of the FLUS sink. In that case, the FLUS source shall send the INVITE message with the Request-Line-URI set to the value of that URI. If the FLUS Factory URI is not pre-provisioned in the UE, the UE shall construct a default FLUS Factory URI (similar to the procedures defined in clause 13.10 of TS 23.003 [7] regarding default Conference Factory URI construction) in either of the following formats:

a) sip:flus@flus-factory.operator.com, when the UE of the FLUS source contains the ISIM application and assumes that the name of its home network domain is ‘operator.com’, or

b) sip:flus@flus-factory.ims.mnc<MNC>.mcc<MCC>.3gppnetwork.org, when the UE of the FLUS source does not contain the ISIM application, and has a home network domain name of ‘ims.mnc<MNC>.mcc<MCC>.3gppnetwork.org’.

Such a FLUS Factory URI shall in turn be used by the S-CSCF to select an appropriate FLUS sink (AS) to which the INVITE message from the FLUS source is routed for IMS session establishment.

5.2.1.3 FLUS management object

The UE may be pre-provisioned with a FLUS sink URI through a 3GPP FLUS Management Object.

The FLUS Management Object shall have a Management Object Identifier: "urn:oma:mo:ext-3gpp-flus:1.0". The MO shall be compatible with OMA Device Management protocol specification version 1.2 and above as described in [21]. The following nodes for FLUS configuration are defined:

Node: /<X>

This interior node specifies the unique object id of a FLUS Management Object. The purpose of this interior node is to group together the parameters of a single object.

– Occurrence: ZeroOrOne

– Format: node

– Minimum Access Types: Get

The following interior nodes shall be contained if the FLUS sink in the terminal supports the FLUS Management Object.

/<X>/Sink/<X>

This node is a collection of information about a FLUS sink

– Occurrence: OneOrMore

– Format: node

– Minimum Access Types: Get

/<X>/Sink/<X>/SIP_URI

This leaf node provides the SIP URI for the FLUS sink that is described by the parent node.

– Occurrence: One

– Format: string

– Minimum Access Types: Get

/<X>/Sink/<X>/Capabilities

This leaf node provides a URL to a JSON or XML document that describes the capabilities of the FLUS sink. The format of the document is outside the scope of this specification.

– Occurrence: ZeroOrOne

– Format: string

– Minimum Access Types: Get

The structure of this FLUS MO is depicted in Figure 5.2-1.

/<X>/Sink/<X>/Ext

The Ext is an interior node where the vendor specific information can be placed (vendor meaning application vendor, device vendor etc.). Usually the vendor extension is identified by vendor specific name under the ext node. The tree structure under the vendor identified is not defined and can therefore include one or more un-standardized sub-trees.

– Occurrence: ZeroOrOne

– Format: node

– Minimum Access Types: Get

/<X>/Ext

– Occurrence: ZeroOrOne

– Format: node

– Minimum Access Types: Get

Figure 5.2-1: FLUS management object tree

5.2.2 Session management

The IMS-based FLUS System uses the SIP protocol for all session management. The FLUS sink and FLUS source shall support the IMS procedures as defined by TS 24.229 [12].

Use of the "a=3gpp-qos-hint:" SDP attribute, as described by TS 26.114 [4] clause 6.2.7.4, is recommended for FLUS media descriptions if specific QoS in the form of maximum loss and/or latency is required.

In addition, the following SDP offer/answer procedures apply for "a=label:flus…" (see also [18]):

– Generating the SDP offer:

– "a=label:flus…" shall be included in every media description used for FLUS media in the SDP offer, where the string after "a=label:" shall start with the characters "flus" but may be followed by more characters, indicated below through an ellipsis ("…").

– Generating the SDP answer:

– "a=label:flus…" shall be kept in every media description in the SDP answer where "a=label:flus…" was received in the SDP offer and that is accepted by the SDP answerer to be used for FLUS media. The label characters after the initial "flus" may differ between offer and answer.

– If "a=label:flus…" is not included in a media description in the received SDP offer, "a=label:flus" shall not be included in the corresponding media description in the SDP answer.

– Receiving the SDP answer:

– If an accepted SDP media description in the received SDP answer contains "a=label:flus…", and if "a=label:flus…" was also included in the corresponding media description in the SDP offer, the media description shall be considered as negotiated for use with FLUS media. The label characters after the initial "flus" shall not be included in the comparison between SDP offer and SDP answer.

– If an accepted SDP media description in the received SDP answer does not contain "a=label:flus", and if "a=label:flus" was included in the corresponding media description in the SDP offer, the SDP answerer likely does not know of FLUS media and the SDP offerer should send an SDP re-offer with this media description disabled (port set to 0).

– If an accepted SDP media description in the received SDP answer contains "a=label:flus…", and if "a=label:flus…" was not included in the corresponding media description in the SDP offer, the SDP answerer is using FLUS media "a=label:flus…" incorrectly and the SDP offerer shall send an SDP re-offer with this media description disabled (port set to 0).

5.2.3 Data transport

The FLUS source and sink that implement the IMS-based FLUS system shall support data transport as specified in section 7 of TS 26.114 [4].

5.3 Generic FLUS system

5.3.1 System configuration

In this version of the specification, this function is left for implementation, but expected to be specified in a future version.

5.3.2 Session management

5.3.2.1a FLUS sink capability discovery

A FLUS session is the association between a source and a sink. The Session Management procedures defined in this section target the FLUS sink configuration and management of the FLUS session.

5.3.2.1b FLUS sink discovery

This procedure allows a Control Source to discover a list of available FLUS sinks.

Figure 5.3.2.1b-1: Get current a list of available FLUS sinks

1. The Control Source sends the FLUS sinks request to the FLUS Sink Discovery Server.

2. The Sink Discovery Server provides a list of FLUS sinks

5.3.2.2 Create a FLUS Sink Configuration

It is assumed that the Control Source has selected a FLUS sink and acquired the necessary information (e.g. the HTTPS URL) to establish an F-C connection to the Control Sink of the FLUS sink.

The procedure allows a Control Source to create a new FLUS Sink Configuration. Configuration properties and in particular FLUS media instantiation selection is added or modified in subsequent procedures.

Figure 5.3.2.2-1: FLUS Sink Configuration creation

1. The FLUS Sink Configuration is created. The Control Source provides a valid access token.

2. On successful creation, the Control Sink of the FLUS sink responds with the resource id of the FLUS Sink Configuration. FLUS Sink Configuration properties are fetched and modified with subsequent transactions.

5.3.2.3 Get FLUS Sink Configuration properties

The procedure allows a Control Source to fetch the current FLUS Sink Configuration.

Figure 5.3.2.3-1: Get current FLUS Sink Configuration properties

1. The Control Source sends along with the FLUS Sink Configuration request, the access token and the resource id of the FLUS Sink Configuration to the Control Sink .

2. The Control Sink provides the FLUS Sink Configuration properties in response.

5.3.2.4 Update a FLUS Sink Configuration

The procedure allows a Control Source to update the current FLUS Sink Configuration.

Figure 5.3.2.4-1: FLUS Sink Configuration update

The Control Source may first fetch the current FLUS Sink Configuration using the Get FLUS Sink Configuration properties procedure.

1. The Control Source modifies the properties of the FLUS Sink Configuration resource. The procedure may allow modification of individual properties or all properties.

2. The Control Sink updates the resource identified by the id of the FLUS Sink Configuration.

5.3.2.5 FLUS session termination

The Control Source may explicitly terminate a FLUS session and all its provisioned and active Media sessions. Alternatively, the FLUS session is automatically terminated, when the last Media session of the FLUS session is terminated. The procedure allows a Control Source to terminate a FLUS session. All Media streams will be terminated automatically with the termination of the FLUS session.

Figure 5.3.2.5-1: FLUS session termination

1. The Control Source sends the terminate FLUS session command. The access token and the resource id of the FLUS session is provided as input.

2. The Control Sink terminates the FLUS session, including all active Media streams and acknowledges the reception of the request.

5.3.2.6 Void

5.3.2.7 Void

5.3.2.8 Void

5.3.2.9 Void

5.3.2.10 Session establishment for Remote Control

When remote control is needed, the Remote Control Target in the FLUS Source is provisioned with the relevant information to establish one or more F-RC sessions. The Remote Control Target creates the F-RC sessions and then listens for incoming messages.

Figure 5.3.2.10-1: FLUS F-RC Session creation

1. The F-RC session is established triggered by the Remote Control Target.

2. On successful creation, the Remote Control Target receives a positive acknolwedgement.

The Remote Control Target starts waiting for remote control related messages.

5.3.2.11 FLUS Source capability discovery

This procedure allows discover capabilities of the FLUS Source.

Figure 5.3.2.11-1 shows the sequence diagram of the FLUS Source capability discovery message exchange using F-RC.

The set of FLUS Source capabilities is specified in clause 5.3.5.

Figure 5.3.2.11-1: Get current FLUS source capabilities

1. The Remote Controller functions sends the FLUS Source capability request to the Remote Control Target of the FLUS Source.

2. The Remote Control Target provides a list of FLUS Source capabilities in response.

5.3.2.12 Remote FLUS Source configuration creation

When the FLUS Source has established a F-RC session, the Remote Controller function can create FLUS Source Configurations. FLUS Source Configuration properties and in particular FLUS media instantiation selection is added in subsequent procedures.

Figure 5.3.2.12-1 shows the sequence diagram of the remote FLUS Source Configuration establishment message exchange.

Figure 5.3.2.12-1: Remote FLUS Source configuration creation

1. The FLUS Source Configuration is created. The Remote Controller function provides a valid access token.

2. On successful creation, the Remote Control Target acknowledges the creation. FLUS Source Configuration properties (such as the FLUS Session information to identify the FLUS Sink resources) are fetched and modified with subsequent transactions.

5.3.2.13 Get FLUS Source configuration properties

This procedure allows a Remote Controller function to obtain the current FLUS Source configuration.

Figure 5.3.2.13-1 shows the sequence diagram of the FLUS Source Configuration properties retrieval message exchange.

Figure 5.3.2.13-1: Get current FLUS Source Configuration properties

1. The Remote Controller function sends along with the FLUS Source Configuration properties request, the access token.

2. The Remote Control Target of the FLUS source provides the FLUS Source Configuration properties in response.

5.3.2.14 Update FLUS Source configuration

The procedure allows a Remote Controller function to update the current FLUS Source configuration.

Figure 5.3.2.14-1 shows the sequence diagram of the Remote FLUS Source Configuration update message exchange.

Figure 5.3.2.14-1: Remote FLUS Source Configuration update

1. The Remote Controller function modifies any or all of the properties of the FLUS Source Configuration resource.

2. The FLUS source updates the resource.

5.3.2.15 Delete a FLUS Source configuration

This procedure allows a Remote Controller function to delete a FLUS Source configuration. All active Media sessions and streams will be terminated automatically with the termination of the FLUS session.

Figure 5.3.2.15-1 shows the sequence diagram of the Remote FLUS Source configuration deletion message exchange.

Figure 5.3.2.15-1: Remote FLUS Source configuration deletion

1. The Remote Controller function sends the Delete FLUS Source configuration command.

2. The Remote Control Target of the FLUS source deletes the FLUS Source configuration, including all active Media streams. The Remote Control Target may discard the FLUS session configuration.

3. The Remote Control Target acknowledges the execution of the request.

5.3.2.16 RAN signaling based uplink assistance

This procedure enables the RAN (eNB/gNB) to inform the UE (specifically, the MAC entity of the UE containing the FLUS source) about the recommended physical layer uplink bitrate for the associated logical channel. The bitrate recommendation sent by the RAN may be unsolicited, or as shown in the example below in Figure 5.3.2.16-1, in response (as a logical grant) to a boost request from the UE.

In Figure 5.3.2.16-1, it is assumed that the uplink streaming is performed by the FLUS source in the UE, and the sending of ANBRQ and reception of ANBR is performed by the MAC entity in the UE. Also, it should be noted that the procedures as shown in Figure 5.3.2.16-1 are applicable to either MTSI-based or non-MTSI-based FLUS instantiation.

Figure 5.3.2.16-1: Uplink bitrate boost via RAN signaling

1. Initially, the UE is streaming on the uplink at bitrate R0

2. UE requests a boost on the uplink by sending ANBRQ containing the desired bitrate R1.

3. RAN grants the boost at a lower rate R2 than R1 but higher than R0, by sending ANBR containing the recommended bitrate R0 < R2 < R1.

4. UE performs bit rate adaptation decision.

5. UE streams on the uplink at the increased bitrate R2.

5.3.3 Data transport

In this version of the specification, this function is left for implementation, but expected to be specified in a future version.

5.3.4 List of FLUS sink capabilities

The FLUS sink capabilities should include the features that are listed under sub-clause 4.4.4.

5.3.5 FLUS source characterisation, capabilities and configuration properties

FLUS source devices are characterized so that the basic FLUS-related functionality can be made known to the FLUS sink.

The following FLUS source properties are specified:

– Available video format(s);

– Available audio format(s);

– Available ancillary stream format(s): subtitles / captions, content metadata – for that which is not embedded in the Media stream(s);

– Connectivity: RAN, wired – and which system/s;

– Remote control – one of: manual, remote, none – and which system/s;

– Mobility – one of: fixed, on foot, ground vehicle, airborne vehicle, surface water vehicle, underwater;

– Power – one of: Battery, battery with autonomous charging, mains.

The Remote Controller function uses the FLUS source capability discovery message exchange as specified in sub-clause 5.3.2.11 to retrieve the capabilities of the FLUS source and its attached media capture device(s).

The Remote Controller function uses the FLUS Source Configuration properties retrieval message exchange as specified in sub-clause 5.3.2.13to retrieve the current status of the FLUS source device. The status is returned in the form of the capabilities of the FLUS source populated with the applicable setting to indicate the current state of the corresponding parameter.

Some parameters can contain a particular capability setting, e.g. the current media format being transmitted. Other parameters contain one of the possible settings, possibly adding auxiliary information, e.g. when running on battery power, the current charge level and estimated operating time before needing to re-charge is indicated. When charging, the charge level and estimated time to full charge could be indicated.

In the table below, the following assertions are made:

– Table header: C stands for Create FLUS Source configuration procedure, G is for Get FLUS Source Configuration properties procedure, U is for Update FLUS Source configuration properties procedure and T is for Terminate FLUS Source configuration procedure. "I", and "O" respectively denote "request" (going Into the FLUS sink), and response (going Out of the FLUS Source).

– Optional ("O") means that the property may or may not be sent/received during a REST transaction. It does not necessarily mean that the property is optional. It is possible, for example, that a session is not yet active because the FLUS Source has not set the property in any previous update transaction using the PUT or PATCH HTTP method, as opposed to representing a hint on the importance of the property for the FLUS Source.

– A property marked as optional (O) in a request message may be present in the request. When not present in the request body, the property, if present in the FLUS Source, will not be updated.

– A property marked as optional (O) in a response message is only present in the response when a value is assigned or changed by the FLUS Source.

– A property marked as mandatory (M) in a response message is always present in the response. The FLUS Source provides defaults, which may be modified subsequently by the content provider.

– A blank cell in the table means "forbidden" (the property cannot be added to the request or returned by the FLUS Source, depending on the transaction direction).

Table 5.3.5-1: List of FLUS Source Configuration properties

Property Name

Property Description

C
I

C
O

G
I

G
O

U
I

U
O

T
I

Identifier of the FLUS Source Configuration resource.

Note that "id" is only provided within an HTTP body during the Create FLUS session response. Otherwise, "id" should be present in the message URL to identify the resource in the FLUS Source.

Type	Unit	Default
Integer	None	N/A

fu_instantiation

Identifier of the FLUS media instantiation that is used by this FLUS session.

Vendor specific enumeration values shall start with "vnd-" followed by a unique vendor name and optionally followed by additional characters.

The F-U instantiation shall be provided as a globally unique URN.

Type	Unit	Default
URI	None	All

entrypoint_URL

Entry point URL information (e.g., SIP URL) for establishing the F-U connection to start the Media streaming. Details on the Entrypoint URL is F-U instantiation specific.

5.3.6 List of FLUS Sink Configuration properties

All FLUS Sink Configuration properties, except for the resource id, are always carried in an HTTP message body. The access-token is always carried as part of HTTP headers. Except for the FLUS session creation request (where the id is not present), the resource id shall be present in the URL of all requests that relate to a specific FLUS Sink Configuration.

In the table below, the following assertions are made:

– Table header: C stands for Create FLUS session procedure, G is for Get FLUS session properties procedure, U is for Update FLUS session properties procedure and T is for Terminate FLUS session procedure. "I", and "O" respectively denote "request" (going Into the FLUS sink), and response (going Out of the FLUS sink).

– Optional ("O") means that the property may or may not be sent/received during a REST transaction. It does not necessarily mean that the property is optional. It is possible, for example, that a session is not yet active because the FLUS source has not set the property in any previous update transaction using the PUT or PATCH HTTP method, as opposed to representing a hint on the importance of the property for the FLUS sink.

– A property marked as optional (O) in a request message may be present in the request. When not present in the request body, the property, if present in the FLUS sink, will not be updated.

– A property marked as optional (O) in a response message is only present in the response when a value is assigned or changed by the FLUS sink.

– A property marked as mandatory (M) in a response message is always present in the response. The FLUS sink provides defaults, which may be modified subsequently by the content provider.

– A blank cell in the table means "forbidden" (the property cannot be added to the request or returned by the FLUS sink, depending on the transaction direction).

Table 5.3.6-1: List of FLUS Sink Configuration properties

Property Name

Property Description

C
I

C
O

G
I

G
O

U
I

U
O

T
I

Identifier of the FLUS Sink Configuration resource.

Note that "id" is only provided within an HTTP body during the Create FLUS session response. Otherwise, "id" should be present in the message URL to identify the resource in the FLUS sink.

Type	Unit	Default
Integer	None	N/A

fu_instantiation

Identifier of the FLUS media instantiation that is used by this FLUS session.

Vendor specific enumeration values shall start with "vnd-" followed by a unique vendor name and optionally followed by additional characters.

The F-U instantiation shall be provided as a globally unique URN.

Type	Unit	Default
URI	None	All

entrypoint_URL

Entry point URL information (e.g., SIP URL) for establishing the F-U connection to start the Media streaming. Details on the Entrypoint URL is F-U instantiation specific.

processing_description

This object provides a media processing description document that defines the post processing pipeline that the FLUS sink shall apply to received media components. The pipeline description may also set the distribution target (incl FLUS sink storage) for the media.

The Object has the following properties:

– type: the MIME type of the media processing description document

– document: the media processing document may be embedded in this element. The document may be base64 encoded depending on the MIME type.

– url: the URL to the media processing document.

– response-code: the response code to a request in the media processing document. The syntax of this property is defined by the MIME type.

The type and either the document property or the url property shall be provided.

The following formats are supported:

– The MPEG NBMP Workflow Resource, UTF-8 encoded,, as defined in [17], which describes the requested media processing and the desired distribution mechanism after the processing has been performed. The type field shall be set to "application/mpeg-nbmp-wdd+json" See Annex X on use of NBMP in FLUS.

5.4 RAN Signaling based Uplink Assistance

5.4.1 General

Overall description of RAN signaling based uplink assistance is provided in clause 4.6.2, and a sequence diagram on uplink bitrate boost is shown in clause 5.3.2.16. The following sub-clauses in this section contain detailed normative description of RAN signaling based uplink assistance.

5.4.2 Uplink bitrate recommendation and boost request

Notification from the RAN to the UE (its MAC entity) of the most current uplink bitrate recommendation information, on a per logical channel basis, is carried by the ANBR message as described in clause 4.6.2. Request from the UE (its MAC entity) to the RAN for updated recommended uplink bitrate information on a per logical channel basis, in the form of a bitrate boost query, is carried by the ANBRQ message also as described in clause 4.6.2. The ANBR and ANBRQ messages are modelled after, and are functionally equivalent to, the identically-named message pair ANBR/ANBRQ for access network bitrate recommendation/query as defined for MTSI in TS 26.114 [4].

5.4.3 ANBR/ANBRQ mapping to MAC signaling and nominal usage

ANBR and ANBRQ, in representing bitrate recommendation and boost request, are logical or conceptual messages, and similar to MTSI, usage of these logical messages in FLUS are mapped to the Recommended bit rate MAC CE and Recommended bit rate query MAC CE, respectively, as defined in TS 36.321 [19] and TS 38.321 [20].

The RAN employs the Recommended bit rate MAC CE, carried in a MAC PDU, to inform the UE (via the UE’s MAC entity), and not necessarily only in response to UE query for such information, about the recommended bitrate for the associated logical channel on the uplink radio bearer. It is expected that an ANBR message will be sent whenever the RAN finds it reasonable or useful to notify the UE about a change in the recommended bitrate, such that the FLUS source is generally provided with up-to-date recommended bitrate information. Therefore, there is no provision for explicit bitrate recommendation request (nor need for such request) from the UE in RAN signaling based uplink assistance.

The UE, via its MAC entity, may send an ANBRQ (ANBR Query) message to query the RAN for updated recommended bitrate, i.e., ANBR information. An ANBRQ is typically sent by the UE when it wishes to seek RAN recommendation on increasing the bitrate of its uplink transmission on the logical channel identified in the request. Should the RAN determine that a higher bitrate can be supported, it is expected to transmit an updated ANBR in response.

5.4.4 Uplink assistance in the context of QoS

The radio bearer associated with ANBR and ANBRQ messaging can be either a GBR bearer/GFBR flow or non-GBR bearer/non-GFBR flow. The following descriptions apply to the various scenarios described below on MTSI or non-MTSI based FLUS instantiations in the context of GBR bearer/GFBR flow vs. non-GBR bearer/non-GFBR flow.

For either MTSI-based or non-MTSI-based FLUS system:

– In the case of GBR bearer/GFBR flow, and assuming GBR/GFBR < recommended bitrate < MBR/GFBR, the RAN may send ANBR recommending UE transmission at an uplink bitrate R1 greater than the current rate R0. This recommendation shall stand until the RAN sends another ANBR recommending UE transmission at a different bitrate.

– In the case of non-GBR bearer/non-GFBR flow, the RAN may send ANBR recommending UE transmission at an uplink bitrate R1 greater than the current rate R0. This recommendation stands until the RAN sends another ANBR recommending UE transmission at a different bitrate.