Specify client-facing 5GMS AF host name to be used by Media Session Handler at M5

[rjb1000]

Context

In order to retrieve full Service Access Information from the 5GMS AF via reference point M5, the Media Session Handler in the 5GMS Client needs to be provided with the following baseline Service Access Information parameters:

• 5GMS AF host address(es) (domain name or IP address).
• Provisioning Session identifier.

These parameters are combined by the Media Session Handler to form the request URL to retrieve the full Service Access Information from a particular 5GMS AF instance at reference point M5.

These two parameters correspond to the minimum baseline Service Access Information described in TS 26.501 when the 5GMS Application Provider announces the 5GMS service privately to the 5GMS-Aware Application (via reference point M8),

There is a one-to-one correspondence in the 5GMS architecture between a Service Access Information resource exposed by the 5GMS AF at reference point M5 and a Provisioning Session resource created at reference point M1. All of the baseline Service Access Information parameters therefore need to be exposed to the 5GMS Application Provider at reference point M1 so that they can be included in a (private) M8 Service Announcement.

Problem description

The Provisioning Session resource defined in clause 7.2.3.1 of TS 26.512 includes a provisioningSessionId property which is assigned by the 5GMS AF when the resource is created.

It does not, however, expose the client-facing 5GMS AF host address(es), which may differ from the host address used for M1 provisioning interactions for operational and/or security reasons.

At present, the client-facing 5GMS AF host address(es) must be communicated manually to the 5GMS Application Provider, and thence to the 5GMS-Aware Application via M8 which is sub-optimal. A better solution is needed

It is recommended to fix this in Rel-16 onwards.

Suggested solutions

Solution 1

Add a new array property (e.g. serviceAccessInformationLocators) to the ProvisioningSession resource in table 7.2.3.1-1 of TS 26.512.

• Note that there may be several valid Application Function hosts that can provide Service Access Information to 5GMS Clients, and they are all provided by the 5GMS AF in the M1 provisioning response.
• For precedent, see the Client Consumption Reporting Configuration, Dynamic Policy Invocation Configuration and Client Metrics Reporting Configuration (but not Network Assistance Configuration, curiously) in the Service Access Information resource defined in table 11.2.3.1-1 of TS 26.512.

Each member of the array is an opaque URL of the client-facing M5 API, following 5GMS URL format. In the interests of simplicity, it is proposed that the Provisioning Session ID is included as a path element so that it forms the complete URL required by the M5_ServiceAccessInformation_retrieveServiceAccessInformation operation specified in clause 11.2.2.

Solution 2 (DNS-based resolution for 5GMS AF deployed inside the Trusted DN)

(This solution is described in TS 26.501 clause B.2.)

A well-known DNS name for the 5GMS AF (e.g. msaf.3gppnetworks.org) is specified by clause 6.1 of TS 26.512.

When the Media Session Handler attempts to resolve this DNS host name, the MNO's DNS service provides a resolution if a 5GMS System is deployed in the 5G System. Failure to resolve the host name is an indication to the Media Session Handler that the 5GMS System is not available in the current PDU Session. The Media Session Handler can then re-attempt the resolution in other PDU Sessions that are currently configured in the UE until it has exhausted all possibilities.

It is not clear in this solution how the resolution of a 5GMS AF deployed outside the Trusted DN works.

Solution 3 (Lookup service)

The host name of the 5GMS AF is registered in the Network Repository Function (NRF). This solution would require liaison with SA2.

Again, it is not clear how the resolution of a 5GMS AF deployed outside the Trusted DN works in this solution.

Solution 4 (HTTPS-based redirection or request proxying for 5GMS AF deployed outside the Trusted DN)

(This solution is described in TS 26.501 clause B.3.)

A trusted 5GMS AF (i.e. a 5GMS AF deployed in the Trusted DN) is provisioned with a mapping from an ASP identifier to the host name of the 5GMS AF deployed outside the Trusted DN. The M5-facing host name of the trusted 5GMS AF is preferably well known (e.g. msaf.3gppnetworks.org), but could be MNO-specific (e.g. msaf.mno.net).

Conventional provisioning at M1 is used to create a "dummy" Provisioning Session with no other 5GMS features (e.g. no Content Hosting Configuration). This provides a Provisioning Session ID valid in the 5GMS System and an implicit binding to the ASP identifier of the party that provisioned it.

For Service Announcement, the 5GMS AF address may be passed to the 5GMS-Aware Application via M8. If the well-known address is used, it can be burned into the 5GMS-Aware Application or even into the Media Session Handler.

When the Media Session Handler resolves the host name, it initially connects to the trusted 5GMS AF at reference point M5 and provides the Provisioning Session identifier as a parameter. The trusted 5GMS AF looks up the mapping from this to the ASP identifier and then to the (privately provisioned) host name of the externally-deployed 5GMS AF. It issues an HTTP(S) redirect to this host name. The Media Session Handler follows this redirect and retrieves the Service Access Information. The Media Session Handler may cache the redirect response for a period of time to make future requests for Service Access Information faster.

Alternatively, instead of issuing a redirect, the trusted 5GMS AF can proxy the request to the externally-deployed 5GMS AF on behalf of the Media Session Handler. In this case, the trusted 5GMS AF still looks up the mapping from the requested Provisioning Session identifier to the ASP identifier and then to the (privately provisioned) host name of the externally-deployed 5GMS AF. But in this variant, the trusted 5GMS AF makes the request to the externally-deployed 5GMS AF and returns it to the requesting Media Session Handler. The trusted 5GMS AF may cache the Service Access Information document for a period of time to make future requests for Service Access Information faster.

This solution solves the problem of the 5GMS AF being deployed outside the Trusted DN. However, it requires additional provisioning that is currently outside the scope of the M1 Provisioning API currently specified in TS 26.512. Specifically, the ProvisioningSession resource (TS 26.512 clause 7.2.3.1) currently lacks an optional property conveying the name of an externally-deployed 5GMS AF. This resource type could potentially be extended to include such a property. If present, the Provisioning Session acts as a "dummy" for redirection/proxying purposes and provisioning 5GMS features as subresources would not be allowed.

[rjb1000]

@ibouazizi comment: The 5GMS AF was intentionally not specified at reference point M1. The intention was that the Media Session Handler is pre-configured with the 5GMS AF host address(es), for example by the operator.

TS 26.512 could specify a well-known FQDN for the 5GMS AF that resolves in the local network to the correct IP address using DNS.

Alternatively, there could be something defined in the NRF. This would require discussion with SA2.

[rjb1000]

@ibouazizi comment: The 5GMS AF was intentionally not specified at reference point M1. The intention was that the Media Session Handler is pre-configured with the 5GMS AF host address(es), for example by the operator.

TS 26.512 could specify a well-known FQDN for the 5GMS AF that resolves in the local network to the correct IP address using DNS.

Alternatively, there could be something defined in the NRF. This would require discussion with SA2.

It is unclear in both of @ibouazizi's alternative proposed solutions how the address of the 5GMS AF is made available to the Media Session Handler in the collaboration scenario where it is deployed outside the Trusted DN.

[ibouazizi]

@rjb1000 I agree with Richard. If the AF is hosted by the AP in the untrusted domain, then we would need a way to convey the address to the MSH, either through M8-M6 or M1-M5 or for a common solution it would be M1 - Nnrf.
I still prefer a common solution for all scenarios, so my preference would be for the last proposal. We will seek to start the dialogue with SA2 on this topic in SA4.

[rjb1000]

To develop your proposal a bit, @ibouazizi, I think you are suggesting something along the following lines:

• When it creates a new Provisioning Session, the 5GMS AF also squirrels away some information in the NRF mapping some lookup key (e.g. Provisioning Session ID) to its client-facing hostname at M5.
  • (This mapping need to be tied to the life-cycle of the Provisioning Session. When the Provisioning Session is destroyed, the corresponding mapping needs to be removed from the NRF's mapping table.)
• At the start of media streaming session, the Media Session Handler first needs to interrogate this information via the User Plane in order to determine which 5GMS AF instance to contact to obtain full Service Access Information (and to later invoke the various Media Session Handling network APIs) via reference point M5.

A first-order approximation of the changes required for this outline solution appears to be:

1. New lookup table in the NRF mapping from 5GMS Provisioning Session ID to 5GMS AF client-facing host name.
   • Note that the Provisioning Session ID is not currently required to be globally unique, so different 5GMS AF instances (deployed inside or outside the Trusted DN) could assign duplicate values.
     • This problem could be solved by instead indexing the NRF's lookup table with a composite key {Application ID, Provisioning Session ID}.
2. New reference point between 5GMS AF and NRF to allow above mapping table to be populated by any authorised 5GMS AF.
   • Note that the network API also needs to be exposed via NEF to cater for 5GMS AF instances deployed outside the Trusted DN.
3. New reference point between Media Session Handler and NRF to look up the client-facing 5GMS host name to be used for a given media streaming session.
   • 5GMS-Aware Application first needs to supply to the Media Session Handler with the relevant Application ID and Provisioning Session ID values that it has previously obtained from the 5GMS Application Provider via M8.
     • This requires an extension to the M6 client API. (See, for example, 5GMS/rt-5gms-media-session-handler#8.)

This all seems quite a tall order, but it does appear to close the gap that has been identified, and would allow 5G Media Streaming to move from an unimplementable condition to an implementable one.

[tlohmar]

Hello,

btw, there is an informative Annex B in TS 26.501, with title: "MNO-specific Service Access Information acquisition". The Annex also considers usage of GSMA managed FQDNs (i.e. 3gppnetworks.org).

[rjb1000]

btw, there is an informative Annex B in TS 26.501, with title: "MNO-specific Service Access Information acquisition". The Annex also considers usage of GSMA managed FQDNs (i.e. 3gppnetworks.org).

Thanks for pointing this out, @tlohmar. I found this informative statement in clause B.1:

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.

[rjb1000]

Having re-read annex B in TS 26.501, I have summarised my understanding in the list of solutions at the top.

[rjb1000]

@ibouazizi comments:

• Maybe we can pursue to well-known FQDN approach.
• If the user reconfigures the DNS server, this will affect the PDU Session, including potentially the Media Session Handler which would then not be able to resolve the well-known FQFN.
  • Maybe we could specify that the Media Session Handler should always use the MNO-configured DNS server?
  • SA2 faced similar challenges for the Edge Applications architecture. We could check how they solved it.

[rjb1000]

This could be specified in Rel-18 as part of the "5GMS_Pro_Ph2" Work Item.

Is it acceptable to leave this underspecified in Rel-17 and Rel-16?

[rjb1000]

Draft specification text proposal contributed to SA4 ad hoc meeting:

• TS 26.512 Rel-16 - Out of scope.
• TS 26.512 Rel-17 - Out of scope.
• TS 26.512 Rel-18 CR0036 in S4aI230104. See clause 6.1A.2.

[rjb1000]

CR contributed to SA4#125 by @rjb1000:

• TS 26.512
  • Rel-18: CR0036 "API changes to support 3GPP Service URL" in S4-231161.

[rjb1000]

TS 26.512 CR0036 endorsed at SA4#125.

(Possible future merger with CR0046 from @haudiobe.)

[rjb1000]

CR contributed to SA4#126 by @rjb1000 was endorsed as the basis of future agreement:

• TS 26.512
  • Rel-18: CR0036r3 "Rel-18 API changes to support 3GPP Service URL" in S4-231636.

To be converted into a pCR to TS 26.510 in the next meeting cycle.

[rjb1000]

The contribution addressing this issue was split into two at SA4#127 (Sophia Antipolis):

• TS 26.512
  • Rel-18: CR0036r5 "[5GMS_Pro_Ph2] Default 5GMS AF address" in S4-240384.
• TS 26.510
  • Rel-18: pCR "[5GMS_Pro_Ph2] Rel-18 API changes to support 3GPP Service URL" in S4-240099.

Both documents were agreed.

• The TS 26.512 CR goes forward to SA#103 (Maastrict) for approval.
• The TS 26.510 pCR has already been incorporated into the Editor's draft of TS 26.510 V1.1.1.