Integration of the DCAF into the 5GMS Application Function

[ErikGaida]

1. The current 5GMS AF is related to Release 17, specifically v17.10.0, while the DCAF is related to Release 18.

In 3GPP TS 26.501 V17.10.0, clause 4.7.1 describes R2 as follows:

R2 This reference point is not instantiated in the 5GMS architecture. Instead, it is logically realised by the
combination of the following components:
- Internal interfaces between the Direct Data Reporting Client and its subordinate functions, namely Metrics
Collection & Reporting and Consumption Reporting & Reporting.
- Internal interface between the Media Session Handler and its subordinate Direct Data Collection Client
function.
- Reference point M5, as defined below.
- Internal interface between the 5GMS AF and its subordinate Data Collection AF function.

In 3GPP TS 26.501 V18.9.0, clause 4.7.1 describes R2 as follows:

Direct data reporting by the Direct Data Collection Client to the Data Collection AF of ANBR-based Network Assistance invocations.

For the provision of QoE metrics and consumption reports, R2 is instead logically realised by the combination of the following components:
- Internal interfaces between the Direct Data Reporting Client and its subordinate functions, namely Metrics Collection & Reporting and Consumption Reporting & Reporting.
- Internal interface between the Media Session Handler and its subordinate Direct Data Collection Client function.
- Reference point M5, as defined below.
- Internal interface between the 5GMS AF and its subordinate Data Collection AF function.

The DCAF implementation itself is not the issue here. The question is whether the R2 reference point is instantiated and exposed by the 5GMS architecture.

According to Release 17, it is explicitly not instantiated. Since the current 5GMS AF is based on Release 17, my understanding is therefore that an R2 interface should not be exposed by this AF.

The 5GMSd Master Plan, on the other hand, is based on Release 18, where R2 is part of the 5GMS architecture.

A Release 17 5GMS AF should therefore not expose an R2 interface solely because it contains a Release 18-based DCAF implementation.

So the remaining question is specifically:

1.1 R2 exposure
Should an R2 interface be available from a Release 17 5GMS AF when that AF embeds a Release 18 DCAF, or should the externally exposed interfaces remain aligned with the Release 17 5GMS architecture?

1.2 Logical realisation of R2 via M5

When R2 is not instantiated, the specification states that it is logically realised through a combination of internal interfaces and the M5 reference point.

How is this logical mapping expected to work in practice? In particular, which component is responsible for translating or forwarding the corresponding R2 functionality via M5, and what would that flow look like?

2. DCAF operating modes
   Would the 5GMS AF support two operating modes: one involving the DCAF and one operating without it?

3. Impact on M5
   Does integrating the DCAF require any changes to the M5 interface or to the behaviour of the existing M5 APIs?

Clear Work Items

The main integration work for the DCAF concerns the implementation of the corresponding clients in the following components:

• Media Session Handler: R2 Client (Release 18)
• 5GMS AS: R4 Client (Release 17)
• 5GMS AP: R6 Client (Release 17)

@davidjwbbc, @rjb1000, @dsilhavy and @jordijoangimenez

[davidjwbbc]

When we designed the Data Collection AF library we did so with the knowledge that the 5GMS AF would not want most of the standard Data Collection reference points. This is why these interfaces can be disabled by the application when it initialises the library.

The original plan was based around the 5GMS AF only providing the standard R5 and R6 interfaces for event reporting to the NWDAF and Application Provider, all other interfaces would be replaced by internal DCAF library API calls from the 5GMS AF:

• R1 is not needed because provisioning is done via M1 and the 5GMS AF configuration of the DCAF library using the library APIs.
• R2 was not needed because all metrics reporting was being done via M5 and the 5GMS AF could then use the DCAF library APIs to directly insert the metrics.
  • As far as I remember there was some additional metrics, suggested later on, that might get reported directly via R2.
• R3 is not needed as there is no indirect metrics route via the Application Provider.
• R4 originally was going to be replaced by a reporting API on M3 and use the DCAF library APIs to do the reporting, but I think (@rjb1000 will likely remember the detail) it was decided that the R4 route was preferable.

This would allow the 5GMS AF to react to the metrics itself instead of them being hidden away in the Data Collection function, the 5GMS AF would then pass on relevant metrics in a suitable form to the Data Collection function during processing of the metrics events.

Some things have changed a little since then, such as the direct R4 and R2 interfaces. But the library remains configurable by the controlling application so that it is able to pick which interfaces it wants the library to handle and which it will handle itself (or just not implement).

[ErikGaida]

@davidjwbbc, @rjb1000

My main question is how the information that would normally be exchanged over R2 is carried over M5. The specifications define different data structures for the two interfaces, so I cannot see how they map to each other. Could you explain which M5 messages correspond to the R2 functionality and how the 5GMS AF passes their contents to the DCAF internally?

I have included the relevant schema definitions below. Please let me know if I have misunderstood how this is intended to work in 5GMS Release 17.10.0.

Thanks for helping clarify this.

R2

26532-h30/TS26532_Ndcaf_DataReporting.yaml:

DataReportingSession:
      description: "A representation of a Data Reporting Session."
      type: object
      properties:
        sessionId:
          readOnly: true
          allOf:
            - $ref: 'TS26512_CommonData.yaml#/components/schemas/ResourceId'
        validUntil:
          readOnly: true
          allOf:
            - $ref: 'TS29571_CommonData.yaml#/components/schemas/DateTime'
        externalApplicationId:
          $ref: 'TS29571_CommonData.yaml#/components/schemas/ApplicationId'
        supportedDomains:
          type: array
          items:
            $ref: '#/components/schemas/DataDomain'
          minItems: 0
        samplingRules:
          readOnly: true
          type: object
          additionalProperties:
            type: array
            items:
              $ref: 'TS26532_CommonData.yaml#/components/schemas/DataSamplingRule'
            minItems: 0
        reportingConditions:
          readOnly: true
          type: object
          additionalProperties:
            type: array
            items:
              $ref: 'TS26532_CommonData.yaml#/components/schemas/DataReportingCondition'
            minItems: 0
        reportingRules:
          readOnly: true
          type: object
          additionalProperties:
            type: array
            items:
              $ref: 'TS26532_CommonData.yaml#/components/schemas/DataReportingRule'
            minItems: 0
      required:
        - sessionId
        - validUntil
        - externalApplicationId
        - supportedDomains
        - samplingRules
        - reportingConditions
        - reportingRules

M5

26512-ha0/TS26512_M5_ServiceAccessInformation.yaml:

ServiceAccessInformationResource:
      description: "A representation of a Service Access Information resource."
      type: object
      required:
      - provisioningSessionId
      - provisioningSessionType
      properties:
        provisioningSessionId:
          $ref: 'TS26512_CommonData.yaml#/components/schemas/ResourceId'
        provisioningSessionType:
          $ref: 'TS26512_CommonData.yaml#/components/schemas/ProvisioningSessionType'
        streamingAccess:
          type: object
          properties:
            entryPoints:
              type: array
              items:
                $ref: '#/components/schemas/M5MediaEntryPoint'
            eMBMSServiceAnnouncementLocator:
              $ref: 'TS26512_CommonData.yaml#/components/schemas/AbsoluteUrl'
        clientConsumptionReportingConfiguration:
          type: object
          required:
            - serverAddresses
            - locationReporting
            - accessReporting
            - samplePercentage
          properties:
            reportingInterval:
              $ref: 'TS29571_CommonData.yaml#/components/schemas/DurationSec'
            serverAddresses:
              $ref: '#/components/schemas/ServerAddresses'
            locationReporting:
              type: boolean
            accessReporting:
              type: boolean
            samplePercentage:
              $ref: 'TS26512_CommonData.yaml#/components/schemas/Percentage'
        dynamicPolicyInvocationConfiguration:
          type: object
          required:
            - serverAddresses
            - policyTemplateBindings
            - sdfMethods
          properties: 
            serverAddresses:
              $ref: '#/components/schemas/ServerAddresses'
            policyTemplateBindings:
              type: array
              minItems: 1
              items: 
                type: object
                required:
                  - externalReference
                  - policyTemplateId
                properties: 
                  externalReference:
                    type: string
                  policyTemplateId:
                    $ref: 'TS26512_CommonData.yaml#/components/schemas/ResourceId'
            sdfMethods:
              type: array
              items:
                $ref: 'TS26512_CommonData.yaml#/components/schemas/SdfMethod'
              minItems: 0
        clientMetricsReportingConfigurations:
          type: array
          minItems: 1
          items:
            type: object
            required:
            - metricsReportingConfigurationId
            - serverAddresses
            - scheme
            - samplePercentage
            - samplingPeriod
            - metrics
            properties:
              metricsReportingConfigurationId:
                $ref: 'TS26512_CommonData.yaml#/components/schemas/ResourceId'
              serverAddresses:
                $ref: '#/components/schemas/ServerAddresses'
              sliceScope:
                type: array
                items:
                  $ref: 'TS29571_CommonData.yaml#/components/schemas/Snssai'
                minItems: 1
              scheme:
                $ref: 'TS29571_CommonData.yaml#/components/schemas/Uri'
              dataNetworkName:
                $ref: 'TS29571_CommonData.yaml#/components/schemas/Dnn'
              reportingInterval:
                $ref: 'TS29571_CommonData.yaml#/components/schemas/DurationSec'
              samplePercentage:
                $ref: 'TS26512_CommonData.yaml#/components/schemas/Percentage'
              urlFilters:
                type: array
                items:
                  type: string
                minItems: 1
              samplingPeriod:
                $ref: 'TS29571_CommonData.yaml#/components/schemas/DurationSec'
              metrics:
                type: array
                items:
                  $ref: 'TS29571_CommonData.yaml#/components/schemas/Uri'
        networkAssistanceConfiguration:
          type: object
          required: 
            - serverAddresses
          properties:
            serverAddresses:
              $ref: '#/components/schemas/ServerAddresses'
        clientEdgeResourcesConfiguration:
          type: object
          required:
            - easDiscoveryTemplate
          properties:
            eligibilityCriteria:
              $ref: 'TS26512_CommonData.yaml#/components/schemas/EdgeProcessingEligibilityCriteria'
            easDiscoveryTemplate:
              $ref: '#/components/schemas/EASDiscoveryTemplate'
            easRelocationRequirements:
              $ref: '#/components/schemas/M5EASRelocationRequirements'

26512-ha0/TS26512_M5_NetworkAssistance.yaml:

NetworkAssistanceSession:
      description: "A representation of a Network Assistance Session resource."
      type: object
      required: 
        - naSessionId
        - provisioningSessionId
        - serviceDataFlowDescriptions
      properties:
        naSessionId:
          readOnly: true
          allOf:
            - $ref: 'TS26512_CommonData.yaml#/components/schemas/ResourceId'
        provisioningSessionId:
          $ref: 'TS26512_CommonData.yaml#/components/schemas/ResourceId'
        serviceDataFlowDescriptions:
          type: array
          items: 
            $ref: 'TS26512_CommonData.yaml#/components/schemas/ServiceDataFlowDescription'
          minItems: 1
        mediaType:
          $ref: 'TS29514_Npcf_PolicyAuthorization.yaml#/components/schemas/MediaType'
        policyTemplateId:
          $ref: 'TS26512_CommonData.yaml#/components/schemas/ResourceId'
        requestedQoS:
          $ref: 'TS26512_CommonData.yaml#/components/schemas/M5QoSSpecification'
        recommendedQoS:
          readOnly: true
          allOf:
            - $ref: 'TS26512_CommonData.yaml#/components/schemas/M5QoSSpecification'
        notficationURL:
          readOnly: true
          allOf:
            - $ref: 'TS26512_CommonData.yaml#/components/schemas/AbsoluteUrl'

26512-ha0/TS26512_M5_MetricsReporting.yaml:

The endpoint is defined here, but the report body has no detailed schema in this OpenAPI file
its format depends on the configured metrics reporting scheme.

26512-ha0/TS26512_M5_DynamicPolicies.yaml:

DynamicPolicy:
      description: "A representation of a Dynamic Policy resource."
      type: object
      required:
        - dynamicPolicyId
        - policyTemplateId
        - serviceDataFlowDescriptions
        - provisioningSessionId
      properties:
        dynamicPolicyId:
          readOnly: true
          allOf:
            - $ref: 'TS26512_CommonData.yaml#/components/schemas/ResourceId'
        policyTemplateId:
          $ref: 'TS26512_CommonData.yaml#/components/schemas/ResourceId'
        serviceDataFlowDescriptions:
          type: array
          items: 
            $ref: 'TS26512_CommonData.yaml#/components/schemas/ServiceDataFlowDescription'
        mediaType:
          $ref: 'TS29514_Npcf_PolicyAuthorization.yaml#/components/schemas/MediaType'
        provisioningSessionId:
          $ref: 'TS26512_CommonData.yaml#/components/schemas/ResourceId'
        qosSpecification:
          $ref: 'TS26512_CommonData.yaml#/components/schemas/M5QoSSpecification'
        enforcementMethod:
          readOnly: true
          type: string
        enforcementBitRate:
          readOnly: true
          type: integer

26512-ha0/TS26512_M5_ConsumptionReporting.yaml:

ConsumptionReport:
      description: "A representation of a Consumption Report."
      type: object
      required:
        - mediaPlayerEntry
        - reportingClientId
        - consumptionReportingUnits
      properties:
        mediaPlayerEntry:
          $ref: 'TS26512_CommonData.yaml#/components/schemas/AbsoluteUrl'
        reportingClientId:
          type: string
        consumptionReportingUnits:
          type: array
          items: 
            $ref: '#/components/schemas/ConsumptionReportingUnit'
    ConsumptionReportingUnit:
      description: "A Consumption Reporting Unit."
      type: object
      required:
        - mediaConsumed
        - startTime
        - duration
      properties:
        mediaConsumed:
          type: string
        clientEndpointAddress:
          $ref: 'TS26512_CommonData.yaml#/components/schemas/EndpointAddress'
        serverEndpointAddress:
          $ref: 'TS26512_CommonData.yaml#/components/schemas/EndpointAddress'
        startTime:
          $ref: 'TS29571_CommonData.yaml#/components/schemas/DateTime'
        duration:
          $ref: 'TS29571_CommonData.yaml#/components/schemas/DurationSec'
        locations:
          type: array
          items:
            $ref: 'TS26512_CommonData.yaml#/components/schemas/TypedLocation'
          minItems: 1

[ErikGaida]

Just to make sure I understand the architectural point correctly:

1. In Release 17, the 5GMS AF does not expose the R2 interface externally at all, correct?
2. There is no mapping of R2 data structures DataReportingSessiononto the M5 API.

In other words: The M5 interface remains strictly as defined in Release 17, without trying to embed or mimic R2 parameters.
The 5GMS AF simply receives standard M5 data and transforms it internally to feed the embedded DCAF library.

[ErikGaida]

Just to give some context on why I originally assumed we might need to map or parse the R2 data structures over M5, it was this specific phrasing in the specification that threw me off:

3GPP TS 26.501 V17.10.0 (2024-06) 4.7.1:

" R2 This reference point is not instantiated in the 5GMS architecture. Instead, it is logically realised by the combination of the following components:
- Internal interfaces ...
- Reference point M5, as defined below.
- Internal interface between the 5GMS AF and its subordinate Data Collection AF function."

Reading that R2 is "logically realised by [...] Reference point M5" made it sound like the actual R2 data model might be tunneled or embedded within the M5 payload.

[davidjwbbc]

Just to make sure I understand the architectural point correctly:

1. In Release 17, the 5GMS AF does not expose the R2 interface externally at all, correct?
2. There is no mapping of R2 data structures DataReportingSession onto the M5 API.

In other words: The M5 interface remains strictly as defined in Release 17, without trying to embed or mimic R2 parameters. The 5GMS AF simply receives standard M5 data and transforms it internally to feed the embedded DCAF library.

Yes, that is correct. The 5GMS AF receives metrics event messages on M5 from the UE and uses internal mechanisms to insert the data into the DCAF library. The 5GMS AF will also need to implement a hook function that can transform the data, which it has stored in the DCAF library, into the relevant event types for R5 & R6. It is up to the 5GMS to define the internal storage formats and provide the function to transform these into event notification data.

[davidjwbbc]

Just to give some context on why I originally assumed we might need to map or parse the R2 data structures over M5, it was this specific phrasing in the specification that threw me off:

3GPP TS 26.501 V17.10.0 (2024-06) 4.7.1:

" R2 This reference point is not instantiated in the 5GMS architecture. Instead, it is logically realised by the combination of the following components:
- Internal interfaces ...
- Reference point M5, as defined below.
- Internal interface between the 5GMS AF and its subordinate Data Collection AF function."

Reading that R2 is "logically realised by [...] Reference point M5" made it sound like the actual R2 data model might be tunneled or embedded within the M5 payload.

This simply means that an equivalent to R2 (i.e. direct reception of metrics - but not the actual format) is realised by using M5 and internal interfaces for direct metrics reporting.

[jordijoangimenez]

Thank you @davidjwbbc. When discussing with @ErikGaida yesterday the question was if that logic is to be designed on implementation or if it is specified, which he could not find. I think it is not specified but need to ensure consistency to the outside on M5 and to the inside on R2, right?

[ErikGaida]

This message summarizes the outcome of the call involving @davidjwbbc, @rjb1000, and me. It is intended to record the main points for further discussion.

5GMS AF

Interfaces not required in the AF:

• R1: All provisioning for 5GMS is handled via reference point M1, so reference point R1 is redundant and not instantiated.
• R2: In Rel-17, client reporting is implicit, based on media session handling interactions via reference point M5, removing the need to instantiate reference point R2. (But note that Rel-18 introduces explicit reporting via R2 of ANBR-based Network Assistance.)
• R3: Indirect data reporing via the Application Provider is not permitted in the 5GMS instantiation, rendering reference point R3 unnecessary.

Interfaces needed in the AF:

• R4: Kept as the preferred route for indirect metrics reporting.
• R5: Exposes event reports so they can be retrieved or subscribed to by the NWDAF.
• R6: Exposes event reports so they can be retrieved or subscribed to by the Application Provider (AP).

Questions:

1. Should the R4, R5, and R6 interfaces be assigned separate IP addresses within the AF?

Answer: For flexibility of deployment, the ability to configure different IP addresses and ports for R4, R5, and R6 is highly desirable. Different data exposure policies may exist at the different reference points.

2. Should the AF be configurable to operate in two distinct modes, with and without DCAF integration?

Answer: Yes. This is feasible and is the recommended approach. DCAF integration should be configurable at runtime through the presence/absence of the relevant stanzas in the msaf.yaml configuration file, allowing the additional functionality to be enabled or disabled as needed.

3. M5-to-DCAF integration: David previously stated that the 5GMS AF consumes QoE metrics through /metrics-reporting/ in the TS 26.247 format and will need to transform them according to TS 26.512, Clause 18. Does this scope cover only MetricsReporting, or should ConsumptionReporting also be transformed and forwarded to DCAF?

As an example, a Communication Record has already been implemented in the 5GMS AF. This implementation serves as a reference for the DCAF integration. A corresponding mechanism would need to be implemented for every M5 data structure to transfer the data from M5 to DCAF.

The existing TS 26.532 Communication Record implementation illustrates how this could be designed and integrated as a handler for each 5GMS feature; the details can be derived from the code.

Open point: @dsilhavy must confirm whether a full DCAF integration is intended.
Under a full integration, all data structures received through M5 would be passed to the DCAF library.

Open5GS Core? (NWDAF)

1. Where should the R5 client be implemented in the 5G Core? Do we need to modify the Open5GS Core, for instance by extending the NWDAF with an R5 client?

The Open5GS Core currently does not include an NWDAF implementation. Therefore, implementing an R5 client would require implementing an NWDAF, which is outside the scope of this project.

In practice, R5 and R6 use the same API: the only distinction is the source of the subscription:

• R5 subscriptions originate from the NWDAF.
• R6 subscriptions originate from the Application Provider (AP).

5GMS AP

1. Regarding the Event Consumer AF located inside the 5GMS AP: The naming seems a bit misleading here. Is it correct to assume that this is not actually a dedicated 5G 'Application Function', but rather just a generic term for the AP's backend (or whichever entity) that consumes the R6 events?

The name “AF” is a little confusing in this context. It could also simply be called an Event Consumer; this is only a naming choice.
The data received via R6 could be displayed in the 5GMS AP, for example in a dashboard similar to the existing CMCD dashboard.

UE

Since R2 is not instantiated in Release 17, an R2 client in the UE is not required. However, with the upcoming 5GMS Release 18/19 uplift of the 5GMS AF, implementing it early is perfectly fine. It can be considered an optional task for now.

Create a GitHub issue to add the R2 client implementation to the Media Session Handler backlog. The implementation can be treated as an optional work item for now and should be addressed as part of the 5GMS Release 18 uplift, where an R2 client component will be required.

Uplift to 5GMS AF

The uplift to the 5GMS AF can happen before or after the integration of DCAF. However, we have decided that we will first integrate DCAF into the 5GMS AF before considering the uplift.

[dsilhavy]

Thanks for the summary @ErikGaida. Regarding your question:

Open point: @dsilhavy must confirm whether a full DCAF integration is intended.
Under a full integration, all data structures received through M5 would be passed to the DCAF library.

That should be goal but I suggest to break it down into small incremental steps and PRs. Create a high level issue with subissues for the individual structures. Then tackle them one by one in small PRs.