TI API - New Requirement: UE mobility notification

[FabrizioMoggio]

The API shall provide a notification to AF about UE mobility

It can leverage, southbound, on the GLMC function defined in 3GPP (e.g. 23.273, 29.515). This is an optional notification from the TI API to an API Consumer to alert when an UE is in a region/zone where the conditions to use the TI API are met (e.g. presence of an EAS Instance and an available UPF)

[FabrizioMoggio]

The requirement foresees a new Intent: “Provide me a notification when the device enters an Edge Cloud Zone where an EAS instance is available”

[babunkj]

This will be a useful info for the application.
When UE moves, it could be connected through the same or different UPF. Change of UPF due to mobility could also trigger an appropriate notification to the Application.
It is also likely that an EAS Instance may be onboarded in the new Edge cloud based on the mobility trigger when that is required to meet the Application requirements.

[FabrizioMoggio]

@babunkj very good comment.

It triggers an interesting discussion that also applies to #218

Let's consider your proposal: "Change of UPF due to mobility could also trigger an appropriate notification to the Application".

We should focus on a “potential routing optimization” rather than “new UPF is available”. We should indeed avoid to "talk about UPF" to be coherent with the API philosophy and the overall CAMARA approach to API development. The Developer is not aware of "UPF" or how the Network works. So we need to provide a different kind of feedback more related to the expressed Intent. The main intent for the TI API is “activate the optimal routing for an EAS instance in a specific Region or Zone”

In the "UE mobility notification" scenario, with the proposed Intent (“Provide me a notification when the device enters an Edge Cloud Zone where an EAS instance is available”) this information is somehow, already provided, in my opinion. When the Device enters the new Region or Zone and an EAS Instance is available, and a potential better routing is available (this last part is currently missing in the Intent), the API, with this new requirement, already notifies the API Consumer of a potential improvement that can be achieved invoking the TI API. Not "a new UPF available", but it should notify that a "routing optimization is available due to user mobility". I need to update the Intent to also consider “and a potential better routing is available”.

Such a feedback is not yet considered for the other new requirement "Automatic mobility". In that case, it is the Network that moves the PDU anchor point autonomously, so a notification must be provided back. In this scenario your proposal fits well. The notification will not be "UPF changed due to mobility" though, but something like "routing optimization performed due to mobility."

So, thank you very much for your suggestion, I will make a proposal to add that feedback in the “Automatic Mobility” Use Case. And I will update the Intent for the “UE mobility notification” Use Case.

[FabrizioMoggio]

update for the Intent according to the previous discussion:

Intent: “Provide me a notification when the Device enters an Edge Cloud Zone where an EAS instance is available and a routing optimization is available”

Output: "Routing optimization is available due to Device mobility"

[FabrizioMoggio]

This requirement is currently under discussion in GSMA OPAG. the discussions not technical but it is related to a request from Operators to not expose Network topology information.

Please consider the following sentence from the requirement definition:

"notification from the TI API to an API Consumer to alert when an UE is in a region/zone where the conditions to have use the TI API are met (e.g. presence of an EAS Instance and an available UPF)"

You can see that this "UE mobility notification" can provide the API Consumer information about the Network topology.

I’m would like to propose to keep it simple, for us and for the API Developer, just providing the TI API with two Options:

1. As it is right now. It is a task from the API Consumer to decide when to invoke the API. To support user mobility, the AP Consumer needs to invoke the API many times, every time the user moves in a different Zone.
2. Adding just “Automatic mobility”, in this case the API Consumer invokes the API once and what happen in the network to guarantee the Intent is transparent to the API Consumer

So, the “UE mobility notification” use case can be considered frozen.

[FabrizioMoggio]

Conclusion: the requirement will not be implemented