TS 29.581: Inconsistency in multicast address type in MBS User Services

[rjb1000]

Summary

During reference implementation of the MBSTF, a problem with the configuration of Source-Specific Multicast (SSM) has been identified in TS 29.581 (3GPP CT4 responsibility).

It doesn't appear to be possible for the MBSF to set the User Plane source address for multicast IP packets in the UpTrafficFlowInfo object when configuring the MBSTF at reference point Nbm2. This appears to be an unmet requirement in the scenario where a Multicast MBS Session is provisioned by the MBS Application Provider (AF/AS) at reference point Nmb10 or Nmb5 to use Source-Specific Multicast (SSM) instead of a TMGI as its MBS Session ID (using the MbsSessionId data type specified at these reference points in TS 29.580 and TS 29.522 respectively, and as used by the MBSF to provision an MBS Session in the downstream MB-SMF via reference point Nmb1 per TS 29.532).

This appears to be a long-standing defect dating back to 3GPP Release 17.

Context

An MBS User Service is provisioned by the MBS Application Provider (AF/AS) in the MBSF using the Nmbsf service at reference point Nmb10 or using the Nnef service at reference point Nmb5. The MBSF, in turn, provisions the requisite number of MBS Sessions in the MB-SMF using the Nmbsmf service at reference point Nmb1, and configures corresponding MBS Distribution Sessions in the MBSTF using the Nmbstf service at reference point Nmb2.

(In the 5G-MAG Reference Tools implementation, the MB-SMF is co-located with the SMF and the MB-UPF is co-located with the UPF. This simplified network architecture is depicted below for reference.)

Problem description

The usage of multicast addressing is inconsistent because different information is provided at different reference points, as summarised in the following table:

Reference point	Specification reference	System actors involved	Service operation	Parent data structure and property	Relevant leaf data structure and property	Multicast described as...	Additional issue?
Nmb10	TS 29.580 clause 6.2.6.2.2 and 6.2.6.2.3 TS 29.571 clauses 5.9.4.1 and 5.9.4.3	AF/AS to MBSF	Nmbsf_MBSUserDataIngestSession_​Create	MBSUserDataIngSession.​mbsDisSessInfos.​mbsSessionId	MbsSessionId.​ssm	SSM	AF/AS doesn't know the MBSTF source address
Nmb5	TS 29.522 clause 5.27.5.2 TS 29.580 clause 6.2.6.2.2 and 6.2.6.2.3 TS 29.571 clauses 5.9.4.1 and 5.9.4.3	NEF to MBSF	Nnef_MBSUserDataIngestSession_​Create
Nmb1	TS 29.532 clause 6.2.6.2.2 TS 29.571 clauses 5.9.4.1 and 5.9.4.3	MBSF to MB-SMF	Nmbsmf_MBSSession_​Create	CreateReqData.mbsSession.mbsSessionId	MbsSessionId.​ssm	SSM	MBSF would need to allocate MBSTF first to get the source address
Nmb2	TS 29.581 clauses 6.1.6.2.4 and 6.1.6.2.13	MBSF to MBSTF	Nmbstf_MBSDistributionSession_​Create	CreateReqData.​distSession.​upTrafficFlowInfo	$${\textcolor{red}{UpTrafficFlowInfo}}$$	$${\textcolor{red}{\mathrm{Multicast \space destination \space only}}}$$
Nmb9	TS 23.247 clause 8.2	MBSTF to MB-UPF	$${\textcolor{gray}{(Not \space applicable)}}$$	$${\textcolor{gray}{(Not \space applicable)}}$$	$${\textcolor{gray}{(Not \space applicable)}}$$	SSM

The MbsSessionId data structure passed at reference points Nmb10 and Nmb1 is defined as follows:

    MbsSessionId:
      description: MBS Session Identifier
      type: object
      properties:
        tmgi:
          $ref: '#/components/schemas/Tmgi'
        ssm:
          $ref: '#/components/schemas/Ssm'
        nid:
          $ref: '#/components/schemas/Nid'
      anyOf:
        - required: [ tmgi ]
        - required: [ ssm ]
...
    Ssm:
      description: Source specific IP multicast address
      type: object
      properties:
        sourceIpAddr:
          $ref: '#/components/schemas/IpAddr'
        destIpAddr:
          $ref: '#/components/schemas/IpAddr'
      required:
        - sourceIpAddr
        - destIpAddr

The UpTrafficFlowInfo data structure passed at reference point Nmb2 is defined as follows:

    UpTrafficFlowInfo:
      description: IP Multicast Address and Port Number
      type: object
      properties:
        destIpAddr:
          $ref: 'TS29571_CommonData.yaml#/components/schemas/IpAddr'
        portNumber:
          $ref: 'TS29571_CommonData.yaml#/components/schemas/Uinteger'
      required:
        - destIpAddr
        - portNumber

Notice that only the destination multicast address and port number are described by the UpTrafficFlowInfo data structure passed at reference point Nmb2; the source address is absent. Ignorant of the value provisioned by the MBS Application Provider (AF/AS) at reference point Nmb10, the MBSTF must choose its own multicast source address for packets it transmits. The obvious implementation choice is the IP address of the interface used to send tunnelled multicast packets to the MB-UPF at reference point Nmb9.

There is currently no way for the MBSTF to inform the MBSF in its response at reference point Nmb2 of the source address it has chosen. Hence, the MBSTF's address at reference point Nmb9 is not known by the MBSF, nor by the MBS Application Provider (AF/AS). The MBSF can't even discover the MBSTF source address since this is allocated based on the UDP tunnel address on the MB-UPF when the Distribution Session is created on the MBSTF. This makes it impossible for the MBSF to include the correct multicast source address in the MBS User Service Announcement it compiles and distributes to the population of MBS Clients via reference point MBS-5 or passes back to the MBS Application Provider (AF/AS) at reference point Nmb10 for private advertisement via reference point MBS-8.

In order to get the tunnel address, the MBSF first needs to create an MBS Session via the MB-SMF. But in order to do that, we need to know what the source address for the multicast is going to be.

Moreover, the MBSTF cannot signal back the source address it will use. This would have to be known in advance by the MBSF understanding which interface on an MBSTF would be used to communicate with the MB-UPF for the UDP tunnel at reference point Nmb9.

Candidate solution

If an optional sourceIpAddr property is added to the UpTrafficFlowInfo object in the Distribution Session configured at reference point Nmb2, then rather than using its own interface address as the source IP address of tunnelled multicast packets it produces, the MBSTF could instead use the source address provisioned by the MBS Application Provider (AF/AS) at reference point Nmb10, the presumed original design intent of SA2.

• This would make the interface at reference point Nmb2 consistent with the other reference points in using a full SSM address specification rather than just a bare destination multicast IP address.
• It also aligns with the intent of clauses 6.5.1 and 6.5.3 of TS 23.247.

The MBS Application Provider (AF/AS) would then be able to allocate a source address from its own IP unicast address pool, and this would then be carried throughout the configurations with the MBSF, MB-SMF, MB-UPF and MBSTF.

As a consequence, only the MBS Application Provider (AF/AS) then needs to know the source address it wishes to use beforehand. This would greatly simplify the operations the MBSF would need to support as it wouldn't have to go through discovery of this address: it would just be provided to it in the UserDataIngestSession objects provisioned by the MBS Application Provider (AF/AS) at reference point Nmb10.

[rjb1000]

@haudiobe: I wonder if your CT3/CT4 delegate @hannalim might be able to assist with this issue?

Note that we are currently implementing Release 18, so this is the most critical release to fix.

[rjb1000]

I have included this in the scope of a draft Liaison Statement to CT3/CT4 and have started drafting a Change Request to TS 29.581.

5G-MAG members can download it here:

• TECH0182r3.LS_Service APIs for MBS User Services