5G-MAG / rt-5gms-application-function

5G Media Streaming - Application Function
https://www.5g-mag.com/streaming
Other
11 stars 6 forks source link

Uplift to TS 26.512 V17.9.0 #163

Closed davidjwbbc closed 2 months ago

davidjwbbc commented 4 months ago

Description

Version 17.9.0 of specification 3GPP TS 26.512 has recently been released. We will need to make some changes to the 5GMS AF in order to bring it in line with this new Release 17 specification version.

This release sees changes to 3 things which will affect the current Reference Tools 5GMS Application Function implementation:

  1. The data type of the members of the metrics array are now Uri rather than just a string.
  2. Value ranges for reportingInterval and samplingPeriod are now declared in the YAML.
  3. The metricsReportingConfigurationId property, previously missing, is now always added to Service Access Information.

It has also been noticed that the sliceScope property was added in v17.8.0 and will need to be included in this change.

Work to be done

For the 3 changes detailed above:

  1. Introduce the string validation regex matching (Issue #128) and then test that the Uri style regex match is applied to the metrics array.
  2. The extra bounds for the reportingInterval and samplingPeriod properties should be picked up by the validation in the OpenAPI templates and so will just need the 5G_APIs version updating, then the code building and testing, no code changes should be required.
  3. Some code will need to be added to copy the relevant metricsReportingConfigurationId and sliceScope (from v 17.8.0) values into the correct properties in the v17.9.0 ServiceAccessInformation structure. This will need implementing and testing and will then trigger changes in the 5G-MAG 5GMS Aware App once implemented (ack @dsilhavy).

Additionally:

stojkovicv commented 3 months ago

In addition, V17.9.0 defines slightly different Metrics Reporting Configuration data model (clause 7.8.3.1). Do we want to include sliceScope with this uplift?

rjb1000 commented 3 months ago

In addition, V17.9.0 defines slightly different Metrics Reporting Configuration data model (clause 7.8.3.1). Do we want to include sliceScope with this uplift?

Good spot, @stojkovicv. I just checked, and sliceScope was actually added in V17.8.0, so this new parameter should have already been included in a previous uplift! So yes, let's include it in the scope of this issue. Please could you add it to the issue description, @davidjwbbc?

There is a knock-on effect: this parameter is also exposed in the clientMetricsReportingConfigurations object in Service Access Information at clause 11.2.3.1, so code will need to be written to copy it across from M1 to M5.

Other than that copying, I don't think the 5GMS internal logic changes in any way, so this should be simple to implement.

davidjwbbc commented 3 months ago

Updated the main description to include sliceScope.

davidjwbbc commented 2 months ago

Implemented the basic uplift, only the additional passing back of error parameter names to be done now. This is a sizeable job as it touches every bit of API interface code and the error sending routine.

davidjwbbc commented 2 months ago

Implemented filling in of the invalidParams field in the ProblemDetails by adding the extra function parameter to pass back the field name where parse errors are happening. Also added a few URL path field invalidParams returns for when things like the {provisioningSessionId} from the URL path does not match an existing provisioning session.

Now I need to test everything to make sure it all still works as expected.

davidjwbbc commented 2 months ago

Uplift merged in PRs 5G-MAG/rt-common-shared#39, #164 and 5G-MAG/rt-5gms-application-provider#56