Unable to create dynamic Policy Template from Management UI

[stojkovicv]

Description

Management UI is unable to successfully conduct Create operation for Policy templates due to, most likely, not enabled open5gs_integration field in yaml configuration file for the Application Function.

Can we set this field to always be enabled for the operating Application Function?

[rjb1000]

Can we set this field to always be enabled for the operating Application Function?

I don't think so. Enabling this feature causes the 5GMS AF to attempt to register with the NRF and to attempt to invoke the PCF. If neither of these Network Functions is present in the deployment, the 5GMS AF will probably become unhappy.

Management UI is unable to successfully conduct Create operation for Policy templates due to, most likely, not enabled open5gs_integration field in YAML configuration file for the Application Function.

It should still be possible to successfully create a Policy Template without enabling the integration with the 5G Core. It may be that this failure is for another reason.

Assigning to @davidjwbbc to investigate.

[davidjwbbc]

The situation is that the AF will return a 400 response if the the PolicyTemplate doesn't parse or validate, or when the open5gs intergration is disabled. So you don't actually know if it's because the feature is disabled or if the request was bad somehow. However the error response will have the full ProblemDetail object returned.

On the python side, the M1Client will raise an M1ClientError exception with the 400 status_code and the reason set to "M1 Operation failed: " + the ProblemDetail JSON string. The M1Session object will not catch the exception and it will be passed onto the the FastAPI server.

I note that the FastAPI server (management-ui/server.py) does not catch the M1Error, M1ClientError or M1ServerError exceptions (i.e. no @app.exception_handler(M1Error) decorated function) and probably should, converting these into HTTPException exceptions for FastAPI to report back to the client. This would at least return back to the client the error message from the AF that indicates that the operation failed due to open5gsIntegration not being true.

[rjb1000]

Notwithstanding the point about handling exceptions better in the FastAPI server, @davidjwbbc, I wonder what you think about changing the behaviour of the 5GMS AF so that it allows Policy Templates to be created, even when the 5G Core integration is disabled.

In this case, the 5GMS AF could return 200 OK with a ProblemDetails JSON response body warning the invoker that the 5GMS AF is not integrated with a 5G Core and therefore instantiating the Policy Template will have no effect.

I suppose the 5GMS AF could kick the can down the road a bit: instead of rejecting the Policy Template at the provisioning interface (reference point M1) it could return an error to any Media Session Handler attempting to instantiate a Dynamic Policy based on the Policy Template as a blanket response (reference point M5) when there is no integration with a 5G Core.

[davidjwbbc]

Just adding the exception handling reveals this:

I'm not in favour of allowing the AF accept the templates when it cannot use them. I think it has the correct behaviour right now which is to return a 400 error with the following problem detail:

{
    "type": "/3gpp-m1/v2",
    "title": "Problem adding the policy template.",
    "status": 400,
    "detail": "Policy Templates are not available on this instance of the 5GMS Application Function.",
    "instance": "/provisioning-sessions/f722002c-3f9d-41ef-a458-93fe3c46511a/policy-templates"
}

(Note: The AF error log includes a more verbose message about enabling open5gs integration and configuring NRF connection details)

Also by denying the provisioning we would never see a UE attempt a DynamicPolicy session as no dynamic policy configuration would ever be sent to the UE to indicate that it's available.

[davidjwbbc]

What could be nice is maybe changing the behaviour of the OPTIONS method in the AF to omit POST if you can't provision PolicyTemplates with the AF configuration.

That way the web UI could check when it creates a provisioning session if PolicyTemplates are available or not and remove or disable the UI interface for them.

[davidjwbbc]

In fact since it's quick to prototype...

This is done by changing the Allow header in the response for the OPTIONS method for .../provisioning-sessions/{provisioningSessionId}/policy-templates to remove POST if the open5gs integration is not true, adding a webui backend server point to check this new OPTIONS response for POST and then getting the webui to use a message instead of the buttons if the feature is not enabled.

Note: This prototype code uses a synchronous call to fetch the policy templates state when the new provisioning session is added to the table. For a proper release this should probably be made to be asynchronous to maintain the operation of the UI.

[davidjwbbc]

@stojkovicv & @rjb1000, if we're happy with this solution I'll tidy up the code and submit PRs for this repository (new policy_template_checker API on the backend server and associated client side web UI javascript changes) and the rt-5gms-application-function repository (OPTIONS change).

[rjb1000]

Sounds good to me, @davidjwbbc .

[stojkovicv]

Just to make sure @davidjwbbc - your solution doesn't radically remove Dynamic Policies (with values checking layer) from the UI, but instead it checks the response from OPTIONS request from AF and adapts accrodingly? In other words, the creation will still be possible from the UI, if, hypothetically, the AF integration with open5gs is enabled?

[davidjwbbc]

Just to make sure @davidjwbbc - your solution doesn't radically remove Dynamic Policies creation (with values checking layer) from the UI, but instead it checks the response from OPTIONS request from AF and adapts accrodingly? In other words, the creation will still be possible from the UI, if, hypothetically, the AF integration with open5gs is enabled?

Absolutely, all it does is:

  if (policy_templates_enabled(sessionId)) {
          cell6.innerHTML = `<button onclick="setDynamicPolicy('${sessionId}')" class="btn btn-primary table-button">Set</button>
                            <button onclick="showDynamicPolicies('${sessionId}', '${sessionData.policy_template_id}')" class="btn btn-info table-button">Show</button>
                            <button onclick="deleteDynamicPolicy('${sessionId}', '${sessionData.policy_template_id}')" class="btn btn-danger table-button">Delete</button>`;
  } else {
          cell6.innerHTML = 'Dynamic Policies are not available';
  }

So the buttons just don't appear on the UI if the AF indicates it can't provision policy templates, but all the code is still there to do the provisioning if the AF is configured correctly.

An alternative would be to leave the buttons in, but disable them and include the "not available" message. Which would show the user that the facility could be available, but is just disabled in the current configuration. In which case a "Dynamic Policies feature is not configured" message might be better.

[stojkovicv]

Alright, all approved.