5GMSd Aware Application - DVB-I Service List Acquisition

[dsilhavy]

Background

TR 103972 v1.1.1 Section 6.3.3.2 describes the service discovery procedure that a DVB-I client uses to discover the set of available DVB-I services. This realizes the M8d service announcement procedure in the context of 5G Media Streaming.

Each service instance in the DVB-I Service List plays the role here of a Service Announcement at reference point M8d. As a consequence, the DVB-I Service List document needs to convey at minimum the baseline Service Access Information parameters, namely the available 5GMSd AF host address(es) and the Provisioning Session identifier of the 5GMSd downlink streaming service corresponding to the DVB-I service.

NOTE: The annotation of a DVB-I service instance with 5GMS baseline Service Access Information parameters is identified as a gap in clause 6.3.4.

Feature Description

The 5GMSd Aware Application shall parse the DVB-I Service List and provide a list of the available services for selection by the user. This is similar to what is being done today using a JSON-based format (see Additional Context below). It is up to the implementation how to visualize the list of available services. Probably a dropdown menu is not optimal. Moreover, there should be an easy way to switch between DVB-I and JSON based service descriptions, both provided via interface M8.

Note: In this case we are assuming that the DVB-I client is integrated into the 5GMSd-Aware Application. It would also be possible that a dedicated DVB-I client launches the 5GMSd Aware Application once a service has been selected

Additional Context

The current implementation of the 5GMSd Aware Application uses a JSON based format at reference point M8:

{
  "m5BaseUrl": "http://10.147.67.179:3003/3gpp-m5/v2/",
  "serviceList": [
    {
      "provisioningSessionId": "3",
      "name": "BBC",
      "entryPoints": [
        {
          "locator": "https://rdmedia.bbc.co.uk/testcard/vod/manifests/avc-full.mpd",
          "contentType": "application/dash+xml",
          "profiles": [
            "urn:mpeg:dash:profile:isoff-live:2011"
          ]
        }
      ]
    },
    {
      "provisioningSessionId": "3",
      "name": "AWS",
      "entryPoints": [
        {
          "locator": "https://d24rwxnt7vw9qb.cloudfront.net/v1/dash/e6d234965645b411ad572802b6c9d5a10799c9c1/All_Reference_Streams/4577dca5f8a44756875ab5cc913cd1f1/index.mpd",
          "contentType": "application/dash+xml",
          "profiles": [
            "urn:mpeg:dash:profile:isoff-live:2011"
          ]
        }
      ]
    }
  ]
}

[dsilhavy]

@rjb1000 @haudiobe, @jordijoangimenez : Is it reasonable that the DVB-I client is part of the 5GMSd Aware Application. When checking 6.3.3 it looks like the default architecture recommends having two separate applications, the DVB-I client and the 5GMSd Aware Application. Looking at our current implementation, I find it more suitable to integrate the DVB-I layer into the 5GMSd Aware Application directly. This can be realized via different M8 adapters or by having a DVB-I library that serves as a dependency for the 5GMSd Aware Application.

[rjb1000]

Bear in mind that the reference architecture diagrams and call flows are couched in terms of logical functions, and that these can be deployed in different combinations in an implementation, including co-location.

Given that there is no well-defined API between a DVB-I Client function and a 5GMS-Aware Application, it doesn't seem unreasonable to deploy them together in a composite Android app. It feels like a fairly natural deployment architecture choice to me.

[rjb1000]

Regarding reference point M8: this is realised by the DVB-I interfaces B1/B2, C1/C2, etc. So I don't understand what you mean by adapters.

[dsilhavy]

Thanks @rjb1000

Regarding reference point M8: this is realised by the DVB-I interfaces B1/B2, C1/C2, etc. So I don't understand what you mean by adapters.

From my understanding: The information derived via M8 can have various formats. It can be a JSON format as we are using today, but it can also be a DVB-I service list with DVB-I services. Other formats are possible as well. A reference application should deal with various formats, so my idea was to implement a dedicated "adapter" for each format. In the end, we need the same information to initialize the playback: AF host address, provisioning session ID and an optional locator. Whether this is coming from an XML file, a JSON file or any other input is not relevant after a certain step. Each adapter outputs the required information in the same format. This output serves as an input for a function that performs further processing such as setting the M5 endpoint in the Media Session Handler.

[rjb1000]

Got it. Good idea to make it modular. Maybe the M8 adaptor would be a choice at build time?

[rjb1000]

NOTE: The annotation of a DVB-I service instance with 5GMS baseline Service Access Information parameters is identified as a gap in clause 6.3.4.

Just to add that DVB is currently looking at how to close this gap.