Tech-invite3GPPspecsSIPRFCs
Overview21222324252627282931323334353637384‑5x

Content for  TS 26.501  Word version:  16.5.0

Top   Top   Up   Prev   None
1…   4…   4.2…   4.3…   5…   5.2…   5.3…   5.4…   5.5…   5.6…   5.7…   5.8   5.9…   6…   6.3…   7…   A…   B…

 

B  MNO-specific Service Access Information acquisitionWord‑p. 74

B.1  General

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.
Up

B.2  Deployment with DNS-based resolution

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 [14].
[not reproduced yet]
Figure B.2-1: DNS based resolution of 5GMSd AF in trusted DN
Up
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 "3gppnetworks.org" domain).
[not reproduced yet]
Figure B.2-2: Message Sequence Chart for DNS-based resolution
Up
Steps:
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

B.3  Deployment with HTTPS-based resolutionWord‑p. 76
Figure B.3-1 depicts the deployment for HTTPS-based resolution of the 5GMSd AF in the Trusted DN of the MNO which is currently providing connectivity to the 5GMSd Client.
[not reproduced yet]
Figure B.3-1: HTTPS based resolution of 5GMSd AF in Trusted DN
Up
For the HTTPS-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 of a 5GMSd AF within the 5GMSd Application Provider domain, which acts as a request redirector.
[not reproduced yet]
Figure B.3-2: Message Sequence Chart for HTTPS based resolution
Up
Steps:
Step 1.
The 5GMSd-Aware Application is provisioned (among other parameters) with a URL of the 5GMSd AF from which to aquire Service Access Information. The 5GMSd-Aware Application passes this URL to the 5GMSd Client upon start.
Step 2.
The 5GMSd Client uses DNS to resolve the FQDN of the URL.
Step 3.
The 5GMSd Client issues a request to the resolved 5GMSd AF in order to acquire the Service Access Information.
Step 4.
Based on information from the originating network (e.g. visible IP of the 5GMSd Client), the 5GMSd AF in the External DN creates an HTTPS redirection response. The 5GMSd AF looks up the according FQDN of the 5GMSd AF in the trusted DN and sends an HTTPS redirection response to the 5GMSd Client.
When the 5GMSd AF in the External DN does not offer 5GMS features, or if the 5GMS features are not provisioned it instead provides a response containing an HTTP error message.
Step 5.
The 5GMSd Client issues a request to the resolved 5GMSd AF in order to acquire the Service Access Information.
Step 6.
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 7.
When needed, the 5GMSd Client uses the acquired Service Access Information to activate the needed 5GMSd feature(s).
Up

$  Change historyWord‑p. 78

Up   Top