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…


B  MNO-specific Service Access Information acquisitionp. 132

B.1  Generalp. 132

A 5GMSd Application Provider may offer its content via multiple Access Networks from different operators. Each access network can consist of a 5G System and one or more 5G Media Streaming Architecture components, in particular its own 5GMSd AFs. The 5GMSd AFs of that access network use their own FQDNs and potentially their own URL root path elements. When a 5GMSd-Aware Application is deployed in different 5G Systems the 5GMSd Client needs to acquire Service Access Information that resolves to the 5GMSd AF endpoint address(es) appropriate for the serving 5G System. The Service Access Information contains the URLs and API parameters of the configured 5GMSd AFs and ASs of that 5G Media Streaming System.
There are different ways to resolve the matching service access information. This Annex focuses on two solutions where the 5GMSd Client fetches the Service Access Information from a 5GMSd AF within the Trusted DN of the serving mobile network.

B.2  Deployment with DNS-based resolutionp. 132

Figure B.2-1 depicts the deployment for DNS-based resolution of the 5GMSd AF in the Trusted DN of the MNO which is currently providing connectivity to the 5GMSd Client. The DNS functions are defined in RFC 1034.
Copy of original 3GPP image for 3GPP TS 26.501, Fig. B.2-1: DNS based resolution of 5GMSd AF in trusted DN
For the DNS-based resolution mechanism, the 5GMSd Client is provisioned with a Service Access Information URL, for example dynamically via M8d or statically within the code of the 5GMSd-Aware Application. The Service Access Information URL contains an FQDN from the 5GMSd Application Provider or a global URL in the GSMA domain (i.e. in the "" domain).
Copy of original 3GPP image for 3GPP TS 26.501, Fig. B.2-2: Message Sequence Chart for DNS-based resolution
Step 1.
The 5GMSd-Aware Application is provisioned (among other parameters) with a URL of the 5GMSd AF from which to acquire Service Access Information. The 5GMSd-Aware Application provides this URL to the 5GMSd Client upon start.
Step 2.
The 5GMSd Client uses DNS to resolve the FQDN of the URL. The 5GMSd Client sends a DNS request to the DNS server in the Trusted DN.
Step 3.
The DNS server in the trusted DN is not responsible for the FQDN and the DNS server forwards the DNS request to a DNS server in the external DN responsible for the FQDN. This may be the DNS server of the 5GMSd Application Provider or a GSMA DNS server.
Step 4.
Based on information from the originating network, the external DNS creates a response. The response may be a CNAME redirect (i.e. FQDN from the serving mobile network responsibility) or an IP address (preferably an IP Anycast Address).
Step 5.
The DNS server forwards the DNS response to the 5GMSd Client.
Step 6.
When the 5GMSd Client received another FQDN with the response (i.e. a CNAME DNS record), then the 5GMSd Client resolves the FQDN to an IP address. The resolved IP address should be an IP address of an 5GMSd AF in the Trusted DN.
Step 7.
The 5GMSd Client issues a request to the resolved 5GMSd AF in order to acquire the Service Access Information.
Step 8.
The 5GMSd AF provides the Service Access Information in its response to the 5GMSd Client. The Service Access Information contains URLs and parameters according to provisioned 5GMS features.
Step 9.
When needed, the 5GMSd Client uses the acquired Service Access Information to activate the needed 5GMSd feature(s).

Up   Top   ToC