Tech-invite3GPPspaceIETFspace
idxwho21222324252627282931323334353637384‑5x

Content for  TS 26.501  Word version:  18.0.0

Top   Top   Up   Prev   Next
1…   4…   4.2…   4.2.2…   4.3…   4.5…   4.6…   4.7…   5…   5.2…   5.3…   5.3.2   5.4…   5.5…   5.5.3…   5.6…   5.7…   5.7.3   5.7.4…   5.8   5.9…   5.10…   5.10.5   5.10.6   5.11…   6…   6.2…   6.3…   6.5…   6.8…   7…   8…   8.2   A…   A.3…   A.5…   A.7…   A.9   A.10   A.11   A.12   A.13   A.14   A.15   B…   B.3   C…   C.3   C.4   C.5   D…

 

A  Usage Guidelines for collaboration scenariosp. 108

A.0  Generalp. 108

This Annex describes a set of collaboration scenarios and deployment options of the 5G Media Streaming architecture. The intention is to illustate different deployment options.
Note that the scenarios focus on the ownership of the functions. Scalability realizations such as a CDN are not illustrated. As result of the scalability considerations, the M4-serving 5GMS AS and/or M5-serving 5GMS AF:
  • May consist of multiple (physical) servers, which may be addressed using a single FQDN. A load balancer forwards client requests to one of these servers. Forwarding may be via HTTP redirects or transparent towards the client.
  • May consist of multiple (physical) servers, where different servers, or different groups of servers, may be addressed with different FQDNs. The client may be made aware of this via the manifest (i.e. listing multiple base URLs).
  • May be addressed with a single FQDN. For example, the MNO AS is mostly transparent and acts as a proxy/cache.
Up

A.1  Downlink media streaming with AS deployed in an external Data Network (OTT)p. 108

The collaboration scenario shown in Figure A.1-1 represents a typical OTT collaboration scenario, where only the 5GMSd AS is deployed and which resides in an external Data Network. In this collaboration scenario, neither the 5GMSd AF nor the Media Session Handler function of the 5GMSd Client is present/necessary for downlink media streaming operation. All Service Announcement Information is delivered at reference point M8d from the 5GMSd Application Provider to the 5GMSd-Aware Application. The latter then passes the Service Acess Information contained in the service announcement to the Media Player to enable downstream media streaming session establishment and media transfer. In addition, M8d is used for UE application-level data reporting from the 5GMSd Aware Application to the 5GMSd Application Provider. The Provisioning API (M1d') and Ingest API (M2d') may follow 5GMS specifications.
Copy of original 3GPP image for 3GPP TS 26.501, Fig. A.1-1: Downlink media streaming with AF and AS in an external Data Network
Up
The interfaces M1d' and M2d' may be similar to interfaces M1d and M2d respectively. Interface M4d follows 3GPP specifications.

A.2  Downlink media streaming with both AF and AS deployed in the trusted Data Networkp. 109

This collaboration scenario shown in Figure A.2-1 represents a MNO CDN scenario, where the CDN is used for ingest and delivery of the content. In this collaboration scenario, similar to that in clause A.1, the Media Session Handler is not present/necessary for downlink media streaming operation since all Service Access Information is delivered at reference point M8d from the 5GMSd Application Provider to the 5GMSd-Aware Application, and in turn the Service Access Information is passed to the Media Player. Similarly, M8d is used for UE application-level data reporting from the 5GMSd-Aware Application to the 5GMSd Application Provider. The 5GMSd AF is present in this scenario to obtain Service Access Information from the 5GMSd Application Provider (at M1d), and in turn, passes that information to the 5GMSd AS.
Copy of original 3GPP image for 3GPP TS 26.501, Fig. A.2-1: Downlink media streaming with AF and AS in the trusted Data Network
Up

Up   Top   ToC