Create Simple_Edge_Discovery_User_story.md #119
Conversation
Kevsy
requested review from
gunjald,
crissancas,
FabrizioMoggio and
sergiofranciscoortiz
as code owners
Fixed some copy/paste errors
|
|
||
| | ***Activities/Steps*** | **Starts when:** The customer application server|client makes a GET request to the EDS API to query the closest MEC platofrm to the end user terminal. The end user terminal is either implicitly identified (e.g. by its source IP when attached to a cellular network) or explicitly identified (the identity is passed in the request querystring)<br>**Ends when:** The EDS API responds to the customer application server|client . | | ||
| | ***Activities/Steps*** | **Starts when:** The customer application server|client makes a GET request to the EDS API to query the closest MEC platform to the target UE (an end user terminal). The target UE is either implicitly identified (e.g. by its source IP when attached to a cellular network) or explicitly identified (the identity is passed in the request querystring)<br>**Ends when:** The EDS API responds to the customer application server|client . | |
There was a problem hiding this comment.
I know this is outside the changes proposed by this PR. But, on 5G networks, wouldn't be better to identify UEs using the Location Area Code/Tracking Area Code (LAC/TAC) rather than their IPs?
If we use IPs on the N6, I believe there are cases when it won't be possible to distinguish between UEs connected to different UPFs. Considering that UEs' IPs on the N6 can be local to the UPF's network; when using distributed UPFs each UPF can use the same pool of IPs for the UEs. This means that two UEs on different UPFs could have the same IP.
There was a problem hiding this comment.
@nicolacdnll The IP assumes in EDS is the public IP. N6, in most of the cases, is the network on a public DNN (except for private network). Hence N6 IP is uniquely identified and routable. UPF could assign private local IP, to the device, from the common pool on internal network, and perform NAT'ing for outside interface (N6).
There was a problem hiding this comment.
Let's see if I understood you: Are you suggesting that on a telco's public DNN, each UE gets an unique IP? Yeah, it makes sense, and I'm probably biased by MPNs.
If that's it, good and thanks. Otherwise, I think I've missed the point.
There was a problem hiding this comment.
I think the above point is very important, indeed the IP submitted needs to be the private, unique IP and not the public (NATted) IP. This needs to be emphasized in the corresponding documentation to developers.
In general @nicolacdnll's suggestion to rather use location data than IP makes a lot of sense as this would remove the need for the network to perform the function of translating the private IP address into a location information. I would though not use network specific location data (i.e. LAC/TAC) but absolute geocordinates which can be obtained by the device using device-specific mechanisms irrespective of the access technology. In that way e.g. also devices using non-3GPP access could be supported.
There was a problem hiding this comment.
I'm now even more confused and I would love to clear the matter.
I understood that @SyeddR was suggesting to use the public IP, but @ThomasEdgeXR you are now saying the opposite and that it should be the private IP, and this should be unique. If I got you right, maybe we should discuss this in weekly call.
There was a problem hiding this comment.
Also, with public IP in telco network, the binding of an public IP:Port may change with time and can be assigned to other users if the current user becomes Inactive for any reason e.g. device get powered off. So there could be a chance that information become stale which may provide incorrect information at times. So the reliability shall be ensured while defining the behavior.
There was a problem hiding this comment.
Exactly my point Syed. However, if we use the public IP I think that the telco systems need a way to bind/map cloudlets at edge to the DN they are in or to the DN's Public IP. If that is not done, imagining the scenario in the sketch below (oversimplified I know!), how could the system know, and suggest, to the UEs behind the distributed UPF that the Cloudlet @edge has lower latency than the Cloudlet @core?
@nicolacdnll good point. However, i think it would depend on a operator specific implementation how to define the closest edge. The closest edge could be a lowest latency candidate or it could be a closest hop w.r.t to UE's anchor point.
There was a problem hiding this comment.
Also, with public IP in telco network, the binding of an public IP:Port may change with time and can be assigned to other users if the current user becomes Inactive for any reason e.g. device get powered off. So there could be a chance that information become stale which may provide incorrect information at times. So the reliability shall be ensured while defining the behavior.
@gunjald This could be addressed by exposing a notification endpoint for IP changes due to mobility or other factors.
There was a problem hiding this comment.
@nicolacdnll good point. However, i think it would depend on a operator specific implementation how to define the closest edge. The closest edge could be a lowest latency candidate or it could be a closest hop w.r.t to UE's anchor point.
Sounds fair, but if that's the case I would suggest we add this consideration to the user story or assumptions.
There was a problem hiding this comment.
Also, with public IP in telco network, the binding of an public IP:Port may change with time and can be assigned to other users if the current user becomes Inactive for any reason e.g. device get powered off. So there could be a chance that information become stale which may provide incorrect information at times. So the reliability shall be ensured while defining the behavior.
@gunjald This could be addressed by exposing a notification endpoint for IP changes due to mobility or other factors.
Similar to the other point, wouldn't it make sense that it's up to each operator implementation to keep track of the mapping of each UE's publicIP:port>? Unless there is a real use case, this mapping should be completely transparent for UE's and developers.
Fixed formatting issues
There was a problem hiding this comment.
The Post Condition says the API client connects with the application server on MEC platform. While the API itself doesn't talk about any information related to application server endpoint on MEC platform, so in my opinion some indications should be given on how the external clients can retrieve application information on the discovered MEC platform. May be a separate API for this purpose.
|
On Public IP:
Agreed, NAT bindings may not last long: but in general the Simple Edge Discovery API would be requested once at start of the application session. I would expect more complex functionality (notifications of new closest MEC following mobility event etc) be handled in the 'full' discovery API.
Yes, that's up to the operator implementation. Other mappings (e.g. based on MSISDN) may be implemented too.
For Simple Edge Discovery I recommend it's the lowest propagation delay client-server: which of course takes into account the location of the UE anchor point. |
|
As discussed in the last call i looked at this again. I'm not sure if the IP topic is fully solved. I'm not an operator so can't fully judge but i know cases of operators we worked with which were not able to use the (NAT)ted public IP as their systems did not allow to map back to the unique, network internal IP which was the input for the other systems to be used. In conclusion this is really a question to the operators, if all the operators are fine with using the public IP than from a vendor/implementor perspective there is nothing speaking against this. |
I also tend to agree that there will be cases where the Public NATed dynamic IP assignments by mobile networks can lead to inaccurate responses in corner cases due to the changes in the mapping. Also, from a application level purview it needs to ensure that it is not using any cached value from previous sessions to avoid landing into any undesired behaviors. To me using public IPs seems to pose bit stricter requirements on its usage and we may need more details on what should be the appropriate strategy to using Public IP. |
|
I can only speak from our experience, but we (Vodafone) do not need to map the Public (post CGNAPT) to Private (pre CGNAPT) IP address. All we need is the public IP address, because that comes from a subnet issued by a particular packet gateway. As long as we know which gateway, we can then calculate the nearest Edge Cloud Zone. My understanding is that other operators who have tested have done the same (certainly in 5GFF) |
|
In addition to @Kevsy comment. Public IP addresses are unique and not re-used across operator's gateway. Public IP address is a sufficient identifier to determine which gateway UE is connected to. |
A question is what happens if a UE moves to a location served by a different gateway? Would the gateway reassignment if happen will cause the UE Public IP to change? If so then the API consumer would need to take care of ensuring to obtain the current IP of the UE and never cache it. Is this a fair understanding? |
|
@gunjald yes that is a fair understanding.
It is a rare occurrence that the Packet Gateway would change during a session. A moving user may handoff between nodeBs, and for a longer journeys that may may result in a change of Serving Gateway (which a cluster of nodeBs connect to), but changing a Packet Gateway typically requires travelling a large distance and is unlikely to occur across the duration of a session. So for Simple Edge Discovery that's fine - and can be accounted for in other Edge Cloud APIs if required. |
|
Tring to considering all input received so far, and it seems that we all agree that a UE could be identified by a I think that this would cover most, if not all, cases:
Did I miss some scenario? |
|
Thanks @nicolacdnll -
None of the implementations I have seen (3 operators) require port - just the public IP address. Also I'm not aware of a consistent method for the API consumer to obtain the private IP address for a device - do you know of one...? |
Fine by me. I was just considering when multiple operators use the same post-CGNAPT public IP, but they split the port range. Not sure how common this is; thus, it's something we can ignore for now.
Not sure why this question, but I think that's common practice and also not sure how useful it would be. Is there a use for it? |
|
Thanks @nicolacdnll
Sorry, I should have been clearer - I should have said "I'm not aware of a consistent method for the API consumer to obtain the cellular network private IP address for a device", i.e. the pre-CGNAPT IP address. If this private IP address was consistently available then the API consumer could pass it in the API call for the cellular operator to mapping it to the closest Edge Zone, because it is issued by/anchored to a particular PDN-GW (LTE EPC) or UPF (5G SA). But as I say, the operators using SED so far have simply relied on public IP address, because it is easily available to the API consumer, and allows the same mapping.
I'm not aware of it being used by apps on cellular networks...for fixed networks it would be the home-router issued IP address, which I'm not sure is useful.
I agree - since public IP is available and does the same thing, I'm not sure it's needed. But that may not be the case for other access networks, I'm not sure. |
As I commented for #123 , the QoD API defines the ipv4Address as shown below, I think in theory there may not be possibly any impact of SED API if publicPort is not available but it will be good to still keep this parameter publicPort as part of ipv4Address to have consistent uniqueness criteria across all APIs in alignment with other API families. And may be there could be scenario where an app provider may need to refer to unique devices e.g. 2 UEs attached to same GW and mapped to same "publicAddress" where the "publicPort" can help to identify these devices uniquely and help provide different treatment as needed from app logic. And then we may avoid using notion of using private IP addresses in these APIs as they be reused in the network and the APIs needs to solve the complexities arising out of overlapping private IP addresses. |
|
As agreed, I will add public port to the SED API for next update (along with the Commonalities alignment) |
|
Now completed as part of SimpleEdgeDiscovery v0.11.0-rc.1 |
No description provided.