WO2022227920A1

WO2022227920A1 - Network nodes and methods therein for control information delivery

Info

Publication number: WO2022227920A1
Application number: PCT/CN2022/081571
Authority: WO
Inventors: Jinyang Xie; Thorsten Lohmar; Jie LING
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2021-04-30
Filing date: 2022-03-18
Publication date: 2022-11-03

Abstract

The present disclosure discloses a method (600) in a first network function. The method (600) includes: transmitting (610), to a second network function, a configuration for in-band delivery of control information associated with a Session Announcement, SA, of a Multicast Broadcast Service, MBS. The control information includes one or more control information items to be delivered to an MBS client. The configuration includes configuration information for each of the one or more control information items.

Description

NETWORK NODES AND METHODS THEREIN FOR CONTROL INFORMATION DELIVERY

TECHNICAL FIELD

The present disclosure relates to communication technology, and more particularly, to network nodes and methods therein for control information delivery.

BACKGROUND

Evolved Multimedia Broadcast Multicast Service (eMBMS) is a point-to-multipoint service in a Long Term Evolution (LTE) system, in which data is transmitted from a single source to multiple recipients. Transmitting the same data to multiple recipients allows network resources to be shared.

Fig. 1 shows an MBMS network architecture model for Evolved Packet System (EPS) in the 3 ^rd Generation Partnership Project (3GPP) Technical Specification (TS) 26.346, V16.9.0, which is incorporated herein by reference in its entirety. As shown in Fig. 1, a reference point between a Content Provider and a Broadcast Multicast -Service Center (BM-SC) is referred to as xMB interface. With the xMB reference point, the Content Provider can invoke procedures supported by the BM-SC to setup and manage MBMS user services from the BM-SC to an MBMS client.

In the eMBMS, the user services are described in the data model as shown in Fig. 2. An MBMS User Service Bundle Description shall contain one or more instances of the userServiceDescription element, each of which in turn represents a single MBMS User Service within the service bundle. The bundle Description element may refer to a single instance of the Forward Error Correction (FEC) Repair Stream Description metadata fragment. A User Service Description instance contains one or more Delivery Method description, which is used to describe how the service is delivered to a User Equipment (UE) . The Delivery Method description refers to Session Description instance, which describes the delivery related parameters. In the event an MBMS User Service carries DASH-formatted contents, the userServiceDescription element shall contain a mediaPresentationDescription element and/or an appService element. One instance of the userServiceDescription element may include at most one schedule element instance. If included, the schedule instance shall refer to one Schedule Description fragment, and the UE can expect to receive MBMS User Service data during the time periods described in the Schedule Description fragment. In the case of a file download service, the Schedule Description fragment may include a file transmission schedule for file objects associated with the User Service. The UE may select which files to receive based on the file transmission schedule information in the Schedule Description fragment. For further details of the data model, reference can be made to TS 26.346.

By default the BM-SC announces all services including different eMBMS parameters to MBMS clients so that the MBMS clients can activate reception of the announced MBMS services. It is also possible that the Content Provider /Application Programming Interface (APl) invoker performs Service Announcement (SA) by itself.

3GPP Service and System Aspects 2 (SA2) workgroup has been exploring potential solutions to enhance the 5 ^th Generation (5G) Multicast-Broadcast functionalities in the 3GPP TS 23.757, V17.0.0, which is incorporated herein by reference in its entirety. Normative work has started in the 3GPP TS 23.247, V0.10, which is incorporated herein by reference in its entirety.

Fig. 3 shows a system architecture of 5G Multicast Broadcast Service (5MBS) . In 5MBS, the BM-SC function is split into control plane (Multicast Broadcast Service Function (MBSF) ) and user plane (Multicast Broadcast Service Transport Function (MBSTF) ) functions, such that a single control plane function can (potentially) control one or more user plane functions. In the architecture, Nmb4, xMB-U, and MB2-U interfaces are provided between the MBSTF and an Application Function (AF) /Application Server (AS) . Nmb6, xMB-C, and MB2-C interfaces are provided between the MBSF and the AF/AS. An Nmb2 interface is provided between the MBSF and the MBSTF.

SUMMARY

As described above, with the xMB reference between the Content Provider and the BM-SC (or the Nmb6 reference between the AF/AS and the MBSF, or the Nmb2 reference between the MBSF and the MBSTF) , the CP can invoke procedures supported by the BM-SC to setup and manage MBMS user services from the BM-SC to the MBMS client.

The BM-SC announces services including different eMBMS parameters to MBMS clients via Service Announcement Channel (SACH) , such that MBMS clients can activate reception of the announced MBMS services. The Content Provider itself may also perform service announcement. The User Service Discovery /SA provides session access information, which is necessary to initiate reception of a MBMS User Service. The session access information may contain information for presentation to an end-user, as well as application parameters used in generating service content to the MBMS client. If the SA is delivered in the SACH, the SA is carousel delivered, and the MBMS client needs to periodically wake up to check if the SA has been changed via Transport Object Identifier (TOI) , or if an etag or Message Digest Algorithm 5 (MD5) checksum indicates a file version in a File Delivery Table (FDT) instance. The carousel delivery of the SA is to secure all the UEs joined from different time could achieve the latest SA files. The periodically wake up of the MBMS client is to minimize battery consumption via effective scheduling and service announcement management.

Since the MBMS client periodically wakes up to check the service announcement, some changes or updates to the SA, referred to as control information or control fragment hereinafter, cannot be fetched by the MBMS client in time. For the unicast delivery/download of the SA, the App will not always check and download the latest SA. Thus, some control information can be delivered in-band of a corresponding service delivery session (independently from the transmission of the SA) . In-band control information can be used for communication between the BM-SC and the MBMS clients. The MBMS aware application, which uses the MBMS client for content reception, does not receive the in-band control information (but maybe some results thereof) . A Content Provider or AF/AS may trigger generation of the control information when changing a content flow, e.g., canceling a file transmission or changing a Dynamic Adaptive Streaming over Hyper Text Transfer Protocol (HTTP) , or DASH, content stream. This may happen “on-purpose” (planned change) and “by accident” (unplanned change) . Alternatively, the BM-SC may generate the control information in response to an operation request from the Content Provider or AF/AS.

It is an object of the present disclosure to provide network nodes and methods therein, capable of supporting in-band delivery of such control information.

According to a first aspect of the present disclosure, a method in a first network function is provided. The method includes: transmitting, to a second network function, a configuration for in-band delivery of control information associated with an SA of a Multicast Broadcast Service (MBS) . The control information includes one or more control information items to be delivered to an MBS client. The configuration includes: configuration information for each of the one or more control information items.

In an embodiment, the configuration information for each of the one or more control information items may include: an ingestion mode for the control information item, and a file Uniform Resource Locator (URL) for the control information item.

In an embodiment, the ingestion mode may include a pull mode, a push mode, or an embedded mode.

In an embodiment, the configuration information for each of the one or more control information items may further include: an envelope URL for the MBS client to fetch the control information item.

In an embodiment, the configuration may further include an indication of support of the in-band delivery of the control information.

In an embodiment, the configuration may further include one or more of: a bit rate for the in-band delivery of the control information, a repetition interval for the in-band delivery of the control information, a maximum duration for the in-band delivery of the control information, a content type of the control information, or an interleaving mode of the control information.

In an embodiment, the maximum duration for the in-band delivery of the control information may be shorter than or equal to a duration for updating the SA.

In an embodiment, the one or more control information items may include session or file based control information and/or application or media stream based control information.

In an embodiment, the session or file based control information may include file cancellation, session cancellation, or location dependent Associated Delivery Procedure (ADP) , and the application or media stream based control information may include Media Presentation Description (MDP) update.

In an embodiment, the first network function may be a content provider or a service provider, and the second network function may be a BM-SC, and the configuration may be transmitted via an xMB interface.

In an embodiment, the first network function may be an AF/AS, and the second network function may be an MBSF, and the configuration may be transmitted via an Nmb6 interface.

In an embodiment, the first network function may be an MBSF, and the second network function may be an MBSTF, and the configuration may be transmitted via an Nmb2 or Nmb4 interface.

According to a second aspect of the present disclosure, a method in a second network function is provided. The method includes: receiving, from a first network function, a configuration for in-band delivery of control information associated with an SA of an MBS. The control information includes one or more control information items to be delivered to an MBS client. The configuration includes configuration information for each of the one or more control information items.

In an embodiment, the configuration information for each of the one or more control information items may include: an ingestion mode for the control information item, and a file URL for the control information item.

In an embodiment, the configuration further may include one or more of: a bit rate for the in-band delivery of the control information, a repetition interval for the in-band delivery of the control information, a maximum duration for the in-band delivery of the control information, a content type of the control information, or an interleaving mode of the control information.

In an embodiment, the session or file based control information may include file cancellation, session cancellation, or location dependent ADP, and the application or media stream based control information may include MDP update.

In an embodiment, the first network function may be a content provider or a service provider, and the second network function may be a BM-SC, and the configuration may be received via an xMB interface.

In an embodiment, the first network function may be an MBSF, and the second network function may be an MBSTF, and the configuration may be received via an Nmb2 or Nmb4 interface.

In an embodiment, the method may further include: transmitting the control information to the MBS client based on the configuration.

In an embodiment, the first network function may be an AF/AS, and the second network function may be an MBSF, and the configuration may be received via an Nmb6 interface.

In an embodiment, the method may further include: transmitting the control information or the configuration to an MBSTF.

According to a third aspect of the present disclosure, a network node is provided. The network node includes a communication interface, a processor and a memory. The memory contains instructions executable by the processor whereby the network node is operative to, when implementing a first network function, perform the method according to the above first aspect, or when implementing a second network function, perform the method according to the above second aspect.

According to a fourth aspect of the present disclosure, a computer-readable storage medium is provided. The computer-readable storage medium has computer-readable instructions stored thereon. The computer-readable instructions, when executed by a processor of a network node, configure the network node to, when implementing a first network function, perform the method according to the above first aspect, or when implementing a second network function, perform the method according to the above second aspect.

With the embodiments of the present disclosure, a configuration for in-band delivery of control information associated with an SA of an MBS can be transmitted, e.g., from a content provider to a BM-SC, from an AF/AS to an MBSF, or from an MBSF to an MBSTF, such that the in-band delivery of the control information can be performed properly in accordance with the configuration.

BRIEF DESCRIPTION OF THE DRAWINGS

The above and other objects, features and advantages will be more apparent from the following description of embodiments with reference to the figures, in which:

Fig. 1 is a schematic diagram showing an MBMS network architecture model for EPS;

Fig. 2 is a schematic diagram showing a simple description data model for eMBMS;

Fig. 3 is a schematic diagram showing a system architecture of 5MBS;

Fig. 4 is a sequence diagram of a file delivery procedure;

Fig. 5 is a sequence diagram of a DASH Media Presentation delivery procedure;

Fig. 6 is a flowchart illustrating a method in a first network function according to an embodiment of the present disclosure;

Fig. 7 is a schematic diagram showing a system architecture of 5MBS according to an embodiment of the present disclosure;

Fig. 8 is a flowchart illustrating a method in a second network function according to an embodiment of the present disclosure;

Fig. 9 is a sequence diagram showing in-band delivery of control information in a file delivery procedure according to an embodiment of the present disclosure;

Fig. 10 is a sequence diagram showing in-band delivery of control information in a DASH Media Presentation delivery procedure according to an embodiment of the present disclosure;

Fig. 11 is a block diagram of a network node according to an embodiment of the present disclosure;

Fig. 12 is a block diagram of a network node according to another embodiment of the present disclosure;

Fig. 13 is a block diagram of a network node according to yet another embodiment of the present disclosure;

Fig. 14 is a schematic diagram showing a user plane model for File Delivery over Unidirectional Transport (FLUTE) ; and

Fig. 15 is a schematic diagram showing in-band fragment related functions of a user plane.

DETAILED DESCRIPTION

References in the specification to "one embodiment, " "an embodiment, " "an example embodiment, " and the like indicate that the embodiment described may include a particular feature, structure, or characteristic, but it is not necessary that every embodiment includes the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to affect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.

It shall be understood that although the terms "first" and "second" etc. may be used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another. For example, a first element could be termed a second element, and similarly, a second element could be termed a first element, without departing from the scope of example embodiments. As used herein, the term "and/or" includes any and all combinations of one or more of the associated listed terms. The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of example embodiments. As used herein, the singular forms "a" , "an" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms "comprises" , "comprising" , "has" , "having" , "includes" and/or "including" , when used herein, specify the presence of stated features, elements, and/or components etc., but do not preclude the presence or addition of one or more other features, elements, components and/or combinations thereof.

In the following description and claims, unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skills in the art to which this disclosure belongs.

In the architecture in Fig. 3, the MBSTF receives content via Nmb4, xMB-U, and/or MB2-U interface from an AF/AS, pre-processes the content based on a configuration from the MBSF, and controls delivery of the content via Nmb5 interface. The MBSF receives service provisioning and control commands from the AF/AS via Nmb6, xMB-C, and/or MB2-C interface. The Nmb2 interface between the MBSF and the MBSTF is used to configure and control the delivery functions, including session management, content ingestion configuration, content delivery method, FEC control, multicast delivery transport, and Quality of Service (QoS) configuration, etc.

In the 5MBS, Temporary Mobile Group Identity (TMGI) (MBS Session Id) allocation is provided by a Multicast Broadcast -Session Management Function (MB-SMF) . The MBSF leverages the MB-SMF for TMGI allocation and will offer other Multicast Broadcast Service (MBS) signaling for the service level management. The MBSF also provides an interface to the AF/AS and has an interface to the MBSTF. The MBSTF supports delivery functions such as MBMS Download Delivery method (referred to as Object Delivery Method in 5MBS) and generic packet transport functionalities to any Internet Protocol (IP) multicast enabled application such as framing, multiple flows, and packet FEC (encoding) , and control the multicast/broadcast delivery of input files as objects or object flows. The MBMS Download Delivery (or Object Delivery in 5MBS) offers a generic file/object delivery function, where binary objects are converted into a sequence of multicast packets and transmitted via MBMS/5MBS. Binary objects may be any binary file or media segments of a multimedia session (e.g. timed DASH media segments) .

Multicast Architecture Enhancement for 5G Media Streaming is defined in the 3GPP Technical Report (TR) 26.802, V1.0.8, which is incorporated herein by reference in its entirety.

A set of different session types can be supported in MBMS/5MBS, including:

- Streaming: the BM-SC may use an MBMS Streaming delivery method for content distribution to MBMS clients.

- Files: the BM-SC may use an MBMS Download delivery method for content distribution to MBMS clients.

- Application: the BM-SC may use an MBMS Download delivery method for content distribution to MBMS clients. This session includes Dynamic Adaptive Streaming over Hyper Text Transfer Protocol (HTTP) , or DASH, and HTTP Live Streaming, or HLS, over MBMS.

- Transport-Mode: the BM-SC is transparent to the stream and passed data via MBMS bearers to UEs.

Fig. 4 shows a file delivery procedure with a pull ingestion mode. Afile here may be a large file, such as a video on demand file, or a small file. As shown, the file delivery procedure includes the following steps:

1. The Content Provider creates the File Delivery Service and Session using xMB procedures.

2. As result of the Service and Session provisioning procedure, the Content Provider gets the service identification information (e.g. Serviceld) , which needs to be used by the Application (App) to request the reception activation from the MBMS Client.

3. When a File Schedule should be inserted into service announcement, the content provider provides the full file list well in advance. The BM-SC determines the file sizes and creates the resulting file schedule entry.

4. The MBMS client receives the service access information via Service Announcement Channel (SACH) or via unicast delivery from the Content Provider.

5. If the App is interested in the service or the file (s) in the SACH, the App requests the MBMS client to activate reception using the appropriate MBMS Client APl call. The App uses the Serviceld as identification for the interested service, or uses the Serviceld and file Uniform Resource Identifier (s) (URl (s) ) for the interesting file (s) in the service.

At scheduled File Delivery Session start time:

6. When not all file Uniform Resource Locators (URLs) to be sent during the file delivery session are provided, the Content Provider updates the File List and adds additional file entries.

7. The BM-SC fetches the file according to the file list.

8. The BM-SC receives the requested file and wraps it into MBMS Download Delivery Objects.

9. The BM-SC sends the file as MBMS Download Delivery Object. When the MBMS Client has activated the reception for that service or file (s) , and is located inside of the broadcast coverage, the MBMS client receives the file (potentially after correcting packet losses) .

10. When the MBMS Client has successfully received the file, it notifies the App.

11. Step 6 can be repeated multi times, independent from steps 7 to 9. Steps 7 to 9 are repeated (as sequence) for every file in the file list until the session schedule end time is reached.

Fig. 5 shows a DASH Media Presentation delivery procedure. A DASH Media Presentation consists of a Media Presentation Description (MPD) , one or more Initialization Segments (ISs) , and sequences of media segments containing media data. A segment is a small file, containing a defined duration, e.g., 2 seconds, of media time. The MPD and ISs are typically provided in the SACH before the actual DASH media segment reception so that the UE has all access information available for tuning in to the DASH stream. As shown, the DASH Media Presentation delivery includes the following steps:

1: The Content Provider creates the DASH Delivery Service and Session using xMB procedures.

2: As result of the Service and Session provisioning procedure, the Content provider gets the service identification information, which needs to be used by the App to request the reception activation from the MBMS Client.

3: The content provider provides the MPD and IS, which should be provided together with other access information using the SACH to the MBMS Client. Or the MBMS client could fetch the Service Announcement from Content Provider via unicast download.

4: The MBMS client receives the service access information.

At scheduled DASH Session start time:

5: The content provider starts pushing DASH media segments to the BM-SC, which wraps the DASH Media Segments into MBMS Download Delivery Objects.

6: The BM-SC sends the File as MBMS Download Delivery Object.

7:

Steps

5 and 6 are repeated for every DASH media segment until the session schedule end time is reached.

8. The App could play the DASH content at any time during the DASH media delivery. The App requests the MBMS client to activate reception using the appropriate MBMS Client APl call.

9. The App sends the play request with MPD URL to Player to play the DASH streaming.

10. The Player will fetch the segment files from MBMS Client (Web Distributed Authoring and Versioning (webdav) ) based on the media info in the MPD.

Fig. 6 is a flowchart illustrating a method 600 according to an embodiment of the present disclosure. The method 600 can be performed at a first network function or a network node implementing the first network function.

At block 610, a configuration for in-band delivery of control information is transmitted to a second network function. The control information is associated with an SA of a Multicast Broadcast Service (MBS) , which may be e.g., MBMS, eMBMS, or 5MBS. Here, the control information, or referred to as control fragment or control object in this context, may be a part or fragment of the SA, and/or may represent a change or update to the SA. As described above, the term “in-band” means that the control information is delivered in-band of a corresponding service delivery session (e.g., along with content data/traffic in the service delivery session and independently from transmission of the SA) . The control information includes one or more control information items to be delivered to an MBS client (e.g., in a UE) . The configuration includes: configuration information for each of the one or more control information items.

In an example, the configuration information for each of the one or more control information items may include: an ingestion mode (e.g., a pull mode, a push mode, or an embedded mode) for the control information item, and a file URL for the control information item. For example, when the ingestion mode is the pull mode, the file URL can be a URL for the second network function to fetch the control information item. When the ingestion mode is the push mode, the file URL can be a webdav URl for the first network function to push the control information item. When the ingestion mode is the embedded mode, the file URL can be a file URL whose content is embedded in a request body.

The configuration information for each of the one or more control information items further may further include an envelope URL for the MBS client to fetch the control information item

In an embodiment, the configuration may further include an indication of support of the in-band delivery of the control information. For example, the indication may be a flag which, when set to true, indicates support of the in-band delivery of the control information.

In an example, the configuration may further include one or more of: a bit rate for the in-band delivery of the control information, a repetition interval for the in-band delivery of the control information, a maximum duration for the in-band delivery of the control information, a content type of the control information, or an interleaving mode of the control information.

Here, the maximum duration for the in-band delivery of the control information can be shorter than or equal to a duration for updating the SA. The maximum duration may be associated with a timer which can be scheduled at the first delivery, and the delivery of the control information can be stopped when the timer expires. The content type may be set to application/mbms-envelope+xml. The interleaving mode may indicate how the control information is to be interleaved with the content data in the corresponding service delivery session, such that the in-band delivery of the control information will not affect the transmission of the content data/traffic in the corresponding service delivery session.

In an example, the one or more control information items may include session or file based control information and/or application or media stream based control information. The session or file based control information may be e.g., inserted by an Object Delivery Method to configure a session schedule or provide file repair or reception reporting information. The application or media stream based control information may be e.g., inserted by an application service provider to update a stream, including MPD update or other media stream related control information. In particular, the session or file based control information may include, but not limited to, for example:

-File cancellation (file cancelled) : When an operator would like to abort an ongoing file delivery, “cancelled” can be set to true for the affected file in a fileSchedule element delivered in-band.

-Session cancellation (session cancelled) . When an operator would like to abort an ongoing session, “cancelled” can be set to true for the affected session in a sessionScheduleOverride element delivered in-band, and Associated Delivery Procedure Description (ADPD) changes can be delivered in-band of the affected session as well.

-Location dependent ADP. For a national broadcast service, it requires ADPs (e.g., file repair, consumption report, reception report) to be supported locally for better performance and network efficiency.

The application or media stream based control information may include, for example:

-MPD update: For DASH streaming, an MPD is a numbering pattern based fragment. In normal cases, after a player starts to play DASH content, the player does not need to refresh the MPD or refresh based on MPD@minimumUpdatePeriod. However, when a segment is restarted due to crash or adjusted due to time shifting, the MPD may be changed. The player needs to retrieve the latest MPD, or otherwise the player would not be able to play the stream. In this case, an MPD update can be delivered in-band.

In an example, e.g., in the architecture shown in Fig. 1, the first network function may be a content provider or a service provider, and the second network function may be a BM-SC, and the configuration may be transmitted via an xMB interface.

In another example, e.g., in the architecture shown in Fig. 3, the control information may be produced (as objects) either by an MBSF or by an AF/AS and then injected (via Nmb2) into an MBSTF. The MBSTF can then convert the control information into a sequence of IP Multicast packets towards an MBMS client. In this case, the first network function may be an AF/AS, and the second network function may be an MBSF, and the configuration may be transmitted via an Nmb6 interface. Alternatively, the first network function may be an MBSF, and the second network function may be an MBSTF, and the configuration may be transmitted via an Nmb2 interface.

Fig. 7 shows a system architecture of 5MBS according to an embodiment of the present disclosure. The system architecture shown in Fig. 7 includes substantially the same network functions and reference points (interfaces) as those shown in Fig. 3, but a number of network functions are omitted in Fig. 7 for the purpose of illustration. The system architecture of Fig. 7 differs from that of Fig. 3 in that a new xMB-U/Nmb4 interface is provided between the MBSF and the MBSTF. In this case, the above configuration may be transmitted from the MBSF to the MBSTF via an Nmb2 or Nmb4 interface.

As shown in Fig. 7, the MBSF controls the MBSTF using Nmb2 APIs. The MBSTF is a user-plane-only function which receives control plane instructions from the MBSF. Thus, the MBSTF can receive any object for in-band delivery, such as the control information as described above, from the MBSF.

The MBSF may either embed the control information into a payload of an Nmb2 APl call (i.e., together with JavaScript Object Notation (JSON) properties) , or use a separate user-plane ingestion point. The separate user-plane ingestion point may be based on xMB-U/Nmb4 (i.e., to support Pull or Push ingestion mode) . The MBSTF may need to treat the control information a bit differently than other user-plane objects. Thus, even when the same xMB-U/Nmb4 protocol is used, it may still be a separate ingestion point. The MBSTF may need to cache the control information for some time in order to insert it multiple times into a 5MBS session. For the pull mode, the MBSTF can download the control information (file content) via the xMB-U/Nmb4 interface based on the file URL included in the configuration. For the push mode, the MBSF can push the control information (file content) via the xMB-U/Nmb4 interface to the webdav URl included in an xMB-C/Nmb2 response. For the embedded mode, the MBSF can include the control information (file content) in a payload of an xMB-C/Nmb2 request.

The MBSF can create 5MBS delivery method related control information itself and receive session related control information from an external AF/AS. The 5MBS delivery method related control information may generally be control information to be received and reacted-on by a 5MBS client (the evolution of MBMS client) . The 5MBS delivery method related control information may be for example an ADPD, which is used to control File Repair and Reception Reporting procedures. Another example of the 5MBS delivery method related control information may be a session schedule, which is inserted to modify a 5MBS Session schedule or to cancel a file repair or reception report procedure. On the other hand, the MBSF may forward session related control information from an external AF/AS, e.g., an MPD update or a new set of ISs (e.g., DASH Streaming related) to the MBSTF. Such control information may be available to a receiving application, such as a DASH Player or an HLS player.

Fig. 8 is a flowchart illustrating a method 800 according to an embodiment of the present disclosure. The method 800 can be performed at a second network function or a network node implementing the second network function.

At block 810, a configuration for in-band delivery of control information is received from a first network function. The control information is associated with an SA of an MBS, which may be e.g., MBMS, eMBMS, or 5MBS. The control information includes one or more control information items to be delivered to an MBS client (e.g., in a UE) . The configuration includes: configuration information for each of the one or more control information items.

The configuration information for each of the one or more control information items further may further include an envelope URL for the MBS client to fetch the control information item.

In an example, the one or more control information items may include session or file based control information and/or application or media stream based control information. For example, the session or file based control information may include file cancellation, session cancellation, or location dependent ADP, and the application or media stream based control information may include MDP update.

In an example, e.g., in the architecture shown in Fig. 1, the first network function may be a content provider or a service provider, and the second network function may be a BM-SC, and the configuration may be received via an xMB interface. The BM-SC can transmit the control information to the MBS client based on the configuration.

In another example, e.g., in the architecture shown in Fig. 3 or 7, the first network function may be an AF/AS, and the second network function may be an MBSF, and the configuration may be received via an Nmb6 interface. The MBSF can transmit the control information or the configuration to an MBSTF. Alternatively, the first network function may be an MBSF, and the second network function may be an MBSTF, and the configuration may be transmitted via an Nmb2 or Nmb4 interface. The MBSTF can transmit the control information to the MBS client based on the configuration.

For other details of the configuration, reference can be made to the method 600 as described above in connection with Fig. 6, and description thereof will be omitted here.

The

methods

600 and 800 will be further explained below with reference to Figs. 9 and 10.

Fig. 9 shows in-band delivery of control information in a file delivery procedure according to an embodiment of the present disclosure. This procedure presents delivery of a control fragment for cancelling a scheduled/ongoing file delivery for on-demand file delivery. The control fragment could be generated by a BM-SC or a Content Provider. As shown, the procedure includes the following steps:

1-7. Same as Steps 1-7 in Fig. 4.

8. The Content Provider would like to cancel the file delivery (i.e., the MBSM client should not try to start file repair) .

9. The Content Provider sends an update session request with a new file list and a control fragment list (alternatively, the CP may only send the file list and the BM- SC may create a control fragment list as a result) . The control fragment list includes a control fragment for file cancellation. The request also contains a configuration for in-band delivery of the control fragment, including e.g., bit rate, repetition interval, duration, interleaving mode, etc.

10. The BM-SC fetches the control fragment from the Content Provider via a user plane interface (e.g., xMB-U) (alternatively, the control fragment may be embedded in a payload of the update session request) .

11. The BM-SC sends the control fragment (fileSchedule) in-band of the session in accordance with the configuration.

12. The MBMS client notifies the App that the file delivery is cancelled. This step can be skipped when the App is not aware about the file (i.e., when the file list is not present in the session schedule) .

13. The BM-SC continues to send the next file in the file list to the MBMS client.

14. The MBMS client notifies the App when the (next) file is ready. Note1: The BM-SC should stop delivery of the control fragment when the duration for in-band delivery of the control fragment expires for better delivery efficiency.

Fig. 10 shows in-band delivery of control information in a DASH Media Presentation delivery procedure according to an embodiment of the present disclosure. In this procedure, when a Content Provider detects a DASH segmenter restart, it notifies a UE (DASH Player) changes in an MPD. It is assumed here that DASH streaming has been activated and started, e.g., with the procedure shown in Fig. 5. As shown, the procedure includes the following steps:

1. The Content Provider detects that the MPD is changed due to DASH segmenter restart or time shifting (an MPD update may also be sent in case of a program change) .

2. The Content Provider sends an update session request with a control fragment to the BM-SC. The request also contains a configuration for in-band delivery of the control fragment, including e.g., bit rate, repetition interval, duration, interleaving mode, etc.

3. The BM-SC fetches the control fragment.

4. The BM-SC sends the control fragment to the MBMS client in-band of the session in accordance with the configuration.

5. The MBMS client notifies an MPD change event to the DASH Player.

6. The DASH player fetches a new MPD file and refresh the player.

7. The Content Provider starts pushing DASH media segments to the BM-SC, which wraps the DASH Media segments into the Object Delivery protocol.

8. The BM-SC sends the media segments as Object Delivery protocol.

9.

Steps

7 and 8 are repeated for every DASH media segment until session schedule end time is reached.

Correspondingly to the method 600 as described above, a network node is provided. Fig. 6 is a block diagram of a network node 1100 according to an embodiment of the present disclosure. The network node 1100 can be configured to implement a first network function.

As shown in Fig. 11, the network node 1100 includes a transmitting unit 1110 configured to transmit, to a second network function, a configuration for in-band delivery of control information associated with an SA of an MBS. The control information includes one or more control information items to be delivered to an MBS client. The configuration includes: configuration information for each of the one or more control information items.

In an embodiment, the session or file based control information comprises file cancellation, session cancellation, or location dependent ADP, and the application or media stream based control information may include MDP update.

The unit 1110 can be implemented as a pure hardware solution or as a combination of software and hardware, e.g., by one or more of: a processor or a micro-processor and adequate software and memory for storing of the software, a Programmable Logic Device (PLD) or other electronic component (s) or processing circuitry configured to perform the actions described above, and illustrated, e.g., in Fig. 6.

Correspondingly to the method 800 as described above, a network node is provided. Fig. 8 is a block diagram of a network node 1200 according to another embodiment of the present disclosure. The network node 1200 can be configured to implement a second network function.

As shown in Fig. 12, the network node 1200 includes a receiving unit 1210 configured to receive, from a first network function, a configuration for in-band delivery of control information associated with an SA of an MBS. The control information includes one or more control information items to be delivered to an MBS client. The configuration includes configuration information for each of the one or more control information items.

In an embodiment, the network node 1200 may further include a transmitting unit configured to transmit the control information to the MBS client based on the configuration.

In an embodiment, the network node 1200 may further include a transmitting unit configured to transmit the control information or the configuration to an MBSTF.

The unit 1210 can be implemented as a pure hardware solution or as a combination of software and hardware, e.g., by one or more of: a processor or a micro-processor and adequate software and memory for storing of the software, a Programmable Logic Device (PLD) or other electronic component (s) or processing circuitry configured to perform the actions described above, and illustrated, e.g., in Fig. 8.

Fig. 13 is a block diagram of a network node 1300 according to yet another embodiment of the present disclosure.

The network node 1300 includes a communication interface 1310, a processor 1320 and a memory 1330.

The memory 1330 may contain instructions executable by the processor 1320 whereby the network node 1300 is operative to, when implementing a first network function, perform the actions, e.g., of the procedure described earlier in conjunction with Fig. 6. Particularly, the memory 1330 may contain instructions executable by the processor 1300 whereby the network node 1300 is operative to, when implementing a first network function: transmit, to a second network function, a configuration for in-band delivery of control information associated with an SA of an MBS. The control information includes one or more control information items to be delivered to an MBS client. The configuration includes: configuration information for each of the one or more control information items.

Alternatively, the memory 1330 may contain instructions executable by the processor 1320 whereby the network node 1300 is operative to, when implementing a second network function, perform the actions, e.g., of the procedure described earlier in conjunction with Fig. 8. Particularly, the memory 1330 may contain instructions executable by the processor 1300 whereby the network node 1300 is operative to, when implementing a second network function: receive, from a first network function, a configuration for in-band delivery of control information associated with an SA of an MBS. The control information includes one or more control information items to be delivered to an MBS client. The configuration includes configuration information for each of the one or more control information items.

In an embodiment, the memory 1330 may contain instructions executable by the processor 1300 whereby the network node 1300 is operative to, when implementing the second network function: transmit the control information to the MBS client based on the configuration.

In an embodiment, the memory 1330 may contain instructions executable by the processor 1300 whereby the network node 1300 is operative to, when implementing the second network function: transmit the control information or the configuration to an MBSTF.

The present disclosure also provides at least one computer program product in the form of a non-volatile or volatile memory, e.g., a non-transitory computer readable storage medium, an Electrically Erasable Programmable Read-Only Memory (EEPROM) , a flash memory and a hard drive. The computer program product includes a computer program. The computer program includes: code/computer readable instructions, which when executed by the processor 1320 causes the network node 1300 to perform the actions, e.g., of the procedure described earlier in conjunction with Fig. 6 or 8.

The computer program product may be configured as a computer program code structured in computer program modules. The computer program modules could essentially perform the actions of the flow illustrated in Fig. 6 or 8.

The processor may be a single CPU (Central Processing Unit) , but could also comprise two or more processing units. For example, the processor may include general purpose microprocessors; instruction set processors and/or related chips sets and/or special purpose microprocessors such as Application Specific Integrated Circuits (ASICs) . The processor may also comprise board memory for caching purposes. The computer program may be carried in a computer program product connected to the processor. The computer program product may comprise a non-transitory computer readable storage medium on which the computer program is stored. For example, the computer program product may be a flash memory, a Random Access Memory (RAM) , a Read-Only Memory (ROM) , or an EEPROM, and the computer program modules described above could in alternative embodiments be distributed on different computer program products in the form of memories.

The disclosure has been described above with reference to embodiments thereof. It should be understood that various modifications, alternations and additions can be made by those skilled in the art without departing from the spirits and scope of the disclosure. Therefore, the scope of the disclosure is not limited to the above particular embodiments but only defined by the claims as attached.

The present disclosure further provides the following embodiments based on the 3GPP TS 26.348, V16.3.0.

Changes in Chapter 5.4.6

For the control fragment delivery extension, the additional properties as defined in Table 5.4-x apply.

Table 5.4-x: Additional properties in the xMB control fragment delivery extension

5.2.2.2.3.3 session modify to ingest control fragment and delivery control

Content ingestion mode, the content ingestion mode should support Pull, Push or Embedded mode.

- for the Pull Mode, the CP/SP provide the file URl, and the BM-SC could fetch the content based on the URl.

- for the Push mode, BM-SC should response the webdav base URl to allow the CP/SP to push the content.

- For the embedded mode, the content will be included in the http request body. for example

1. Add control fragment and delivery control with pull mode example

2. Add control fragment and delivery control with push mode example

3. Add control fragment and delivery control with embedded mode example

The present disclosure further provides the following embodiments based on the 3GPP TS 29.116, V16.6.0.

Changes in Chapter 9

Control fragment in-band delivery is a new optional feature in the xMB interface.

Table 9.1-1: Features used in xMB Interface

Changes in the Annex B (normative) JSON schema

The service provisioning and control commands for Nmb6 interface, and the delivery configuration and control for Nmb2 interface should consider the in-band control fragment delivery besides the standard delivery methods (media, application, file, and Mission Critical delivery) .

The present disclosure further provides the following embodiments based on the 3GPP TR 26.802, V1.0.8.

5.3.1.2 Model of a BM-SC User-Plane Function for MBMS Download

The model in Fig. 14 below assumes that a FLUTE function according to MBMS Download Delivery (clause 7 in TS 26.346 [16] ) is mapped into the MBSTF.

NOTE: FLUTE is used in this clause for illustrative purposes to study the interface between a BM-SC control and user-plane. The reuse, evolution or replacement of this object delivery protocol in Release 17 should be studied in a separate Key Issue.

The purpose of this simplified model is to help identify the xMB-C parameters (xMB Service and Session Parameters) needed to configure an MBSTF at Nx2.

The model depicts some key functions from an xMB-U ingest to an MB-UPF ingest (N6) . In the case of 5MBS Download (e.g. used for DASH/HLS over MBMS or generic file delivery) the MBSTF operates as follows:

1. The HTTP File Receiver is responsible for ingesting content resources intended for multicast transmission at xMB-U. It supports two basic content ingest modes:

a) HTTP Pull, in which the MBSTF pulls resources from an upstream HTTP server, such as the 5GMSd AS. In this mode, the Nx2 APl is used to provide individual URLs to be downloaded.

b) HTTP Push, in which resources are uploaded to the MBSTF by an upstream client using HTTP PUT. In this mode, the Nx2 APl is used to provide a base URL for ingesting data to the APl invoker.

2. The MBSTF may store partial or complete resources in a local File Cache prior to transmission at N6. Optimized implementations may pipe files through with only minimal buffering/caching.

3. HTTP metadata such as Content-Location (resource URL) , Content-Length (resource size) , and Content-Type (MIME content type) is provided by the HTTP File Receiver to the FDT Instance creation function. This acts as input (with other Nx2 parameters) to form the FDT Instance XML document.

4. The File partitioning function segments resources (including FDT Instances) into one or more multicast packet payloads. In the case where a Forward Error Correction scheme such as Raptor FEC (RFC 5053 [23] ) or Compact No-Code FEC (RFC 5445 [24] ) is used, there are recommended schemes and parameters to partition a resource into a sequence of packet paylods (called encoding symbols) .

5. The Delivery object packetization function creates a sequence of IP packets (incl UDP and FLUTE packet headers) for the delivery object. It inserts FLUTE header parameters such as the TSI, sequence number (FEC Symbol ID according to No-Code FEC, RFC 3695 [25] or Raptor FEC, RFC 5053 [23] ) , etc. As result, a complete UDP packet payload is created, which can be written to a UDP socket at the appropriate time of transmission.

6. Finally, the Streamer &Pacer function sends the multicast UDP packets according to a defined bit rate to the configured MP-UPF ingest point, which can be an MB2-U tunnel, some direct multicast, or similar.

5.3.1.3 Handling of Inband Fragment for MBMS Download

The model in Fig. 15 below extends the FLUTE model from Clause 5.3.1.2 with In-Band fragments. TS 26.346 allows transmission of Service Announcement Metadata fragments in band with the session or out of band. Annex L. 2.8 of TS 26.346 further defines handling of inband fragments within the Service Announcement Channel (SACH) profile.

Two categories of In-band control objects are considered

1: 5MBS Delivery function related, i.e. sending control objects (inband) to the 5MBS Client like file repair configuration information

2: 5MBS User Service function related, i.e. sending control objects (inband) to an application component behind the 5MBS Client like a Media Player

In-band fragments in TS 26.346 are typically XML formated documents, which are sends as regular FLUTE transmission objects to the MBMS Client. In-band fragments may be interleaved with other content, i.e. the BM-SC sends the in-band fragment at the same time as a content object (interleaved on packet level) and may be repeated multiple times. When repeating an in-band fragments, it is beneficial to keep the same FLUTE level parameters, specifically the Transport Object Identifier (TOI) , so that the FLUTE receiver can efficiently detect and ignore repetitions.

Fig. 15 shows in-band fragment related functions of a User Plane. The in-band related functions are added the other components are identical as in Fig. 14.

The model adds in-band fragment related functions to the user plane model:

1. The Ingest function is responsible for receiving the ingested control object for in-band delivery. The control object is typically XML formated.

2. The Partitioning, packetization and FDT Inst. Creation function is converting the control object (for inband delivery) into a sequence of FLUTE packets, include the according FDT Instance information. Inband control objects are identified by a special MIME type

3. The Cache function is used to keep the partitioned control object for repetitions

4. The In-band fragment insertion function interleaves the in-band control object with the packet payloads of other user plane objects.

The Ingest function may support a Push or a Pull ingest (similar to xMB-U) . Alternatively, inband fragments may be embedded in Nmb2 control payload, e.g. a base64 encoded of the HTTP body.

Claims

A method (600) in a first network function, comprising:

transmitting (610) , to a second network function, a configuration for in-band delivery of control information associated with a Session Announcement, SA, of a Multicast Broadcast Service, MBS, the control information comprising one or more control information items to be delivered to an MBS client, wherein the configuration comprises configuration information for each of the one or more control information items.
The method (600) of claim 1, wherein the configuration information for each of the one or more control information items comprises:

an ingestion mode for the control information item, and

a file Uniform Resource Locator, URL, for the control information item.
The method (600) of claim 2, wherein the ingestion mode comprises a pull mode, a push mode, or an embedded mode.
The method (600) of claim 2 or 3, wherein the configuration information for each of the one or more control information items further comprises:

an envelope URL for the MBS client to fetch the control information item.
The method (600) of any of claims 1-4, wherein the configuration further comprises an indication of support of the in-band delivery of the control information.
The method (600) of any of claims 1-5, wherein the configuration further comprises one or more of:

a bit rate for the in-band delivery of the control information,

a repetition interval for the in-band delivery of the control information,

a maximum duration for the in-band delivery of the control information,

a content type of the control information, or

an interleaving mode of the control information.
The method (600) of claim 6, wherein the maximum duration for the in-band delivery of the control information is shorter than or equal to a duration for updating the SA.
The method (600) of any of claims 1-7, wherein the one or more control information items comprise session or file based control information and/or application or media stream based control information.
The method (600) of claim 8, wherein the session or file based control information comprises file cancellation, session cancellation, or location dependent Associated Delivery Procedure (ADP) , and the application or media stream based control information comprises Media Presentation Description, MDP, update.
The method (600) of any of claims 1-9, wherein

the first network function is a content provider or a service provider, and the second network function is a Broadcast Multicast -Service Center, BM-SC, and

the configuration is transmitted via an xMB interface.
The method (600) of any of claims 1-9, wherein

the first network function is an Application Function /Application Server, AF/AS, and the second network function is a Multicast Broadcast Service Function, MBSF, and

the configuration is transmitted via an Nmb6 interface.
The method (600) of any of claims 1-9, wherein

the first network function is a Multicast Broadcast Service Function, MBSF, and the second network function is a Multicast Broadcast Service Transport Function, MBSTF, and

the configuration is transmitted via an Nmb2 or Nmb4 interface.
A method (800) in a second network function, comprising:

receiving (810) , from a first network function, a configuration for in-band delivery of control information associated with a Session Announcement, SA, of a Multicast Broadcast Service, MBS, the control information comprising one or more control information items to be delivered to an MBS client,

wherein the configuration comprises configuration information for each of the one or more control information items.
The method (800) of claim 13, wherein the configuration information for each of the one or more control information items comprises:

an ingestion mode for the control information item, and

a file Uniform Resource Locator, URL, for the control information item.
The method (800) of claim 14, wherein the ingestion mode comprises a pull mode, a push mode, or an embedded mode.
The method (800) of claim 14 or 15, wherein the configuration information for each of the one or more control information items further comprises:

an envelope URL for the MBS client to fetch the control information item.
The method (800) of any of claims 13-16, wherein the configuration further comprises an indication of support of the in-band delivery of the control information.
The method (800) of any of claims 13-17, wherein the configuration further comprises one or more of:

a bit rate for the in-band delivery of the control information,

a repetition interval for the in-band delivery of the control information,

a maximum duration for the in-band delivery of the control information,

a content type of the control information, or

an interleaving mode of the control information.
The method (800) of claim 18, wherein the maximum duration for the in-band delivery of the control information is shorter than or equal to a duration for updating the SA.
The method (800) of any of claims 13-19, wherein the one or more control information items comprise session or file based control information and/or application or media stream based control information.
The method (800) of claim 20, wherein the session or file based control information comprises file cancellation, session cancellation, or location dependent Associated Delivery Procedure (ADP) , and the application or media stream based control information comprises Media Presentation Description, MDP, update.
The method (800) of any of claims 13-21, wherein

the first network function is a content provider or a service provider and the second network function is a Broadcast Multicast -Service Center, BM-SC, and

the configuration is received via an xMB interface.
The method (800) of any of claims 13-21, wherein

the first network function is a Multicast Broadcast Service Function, MBSF, and the second network function is a Multicast Broadcast Service Transport Function, MBSTF, and

the configuration is received via an Nmb2 or Nmb4 interface.
The method (800) of claim 22 or 23, further comprising:

transmitting the control information to the MBS client based on the configuration.
The method (800) of any of claims 13-21, wherein

the first network function is an Application Function /Application Server, AF/AS, and the second network function is a Multicast Broadcast Service Function, MBSF, and

the configuration is received via an Nmb6 interface.
The method (800) of claim 25, further comprising:

transmitting the control information or the configuration to a Multicast Broadcast Service Transport Function, MBSTF.
A network node (1300) , comprising a communication interface (1310) , a processor (1320) and a memory (1330) , the memory (1330) comprising instructions executable by the processor (1320) whereby the network node (1300) is operative to, when implementing a first network function, perform the method according to any of claims 1-12, or when implementing a second network function, perform the method according to any of claims 13-26.
A computer-readable storage medium having computer-readable instructions stored thereon, the computer-readable instructions, when executed by a processor of a network node, configure the network node to, when implementing a first network function, perform the method according to any of claims 1-12, or when implementing a second network function, perform the method according to any of claims 13-26.