Device Identifiers in Edge Cloud APIs

[javierlozallu]

The objective is to summarize what is being discussed in #123, #119 and #230 as there is a common topic: Which parameters should be used to identify an UE and why. The resolution in Commonalities shall also be taken into account.

And as proposed by @ThomasEdgeXR at the Edge Cloud Meeting we should have a common Device Object (that contains the identifiers; IP, MSISDN, IP:Port, etc) across all our APIs.

[javierlozallu]

Update according to Edge Cloud Meeting (25/06):

1. Commonalities - PR to simplify Device Object is already merged:

• The first proposal was to remove networkAccessIdentifier as it is not being implemented by any subgroup

• The agreement is to keep the parameter within the Device Object scheme for future-proof but CAMARA does not permit it use. In the case where only networkAccessIdentifier is provided, error 422 should be returned and if is provided along with other IDs, it should be ignored.

  Conclusion: Keep NetworkAccessIdentifier, update it accordingly and remove the example.

2. SED API - PR 119 has a final conclusion:

• Be aligned with other CAMARA APIs (QoD API mainly) and Commonalities v0.4.0

  Conclusion: For IpAddress Identifier, add a unique tuple consisting of publicAddress and publicPort to identify a Device, as this tuple is a global solution for all the Operators.

3. TI API - Issue 123 and Discussion 230

• From Issue 123:

  • Be aligned with other CAMARA APIs (QoD API mainly) and Commonalities v0.4.0

    Conclusion: For IpAddress Identifier, add a unique tuple consisting of publicAddress and publicPort to identify a Device.

• From Discussion 230:

  • It is necessary to identify each traffic flow from the Device to the Edge.

    Conclusion: Add the objects sourceTrafficFilters and destinationTrafficFilters separate from the Device object to identify a Traffic Flow. The Traffic Filter Object contains a single port (sourcePort:destinationPort), so for multiple flows, multiple calls must be made

DEVICE OBJETC FOR EDGE CLOUD

• Scheme

• Special Notes for NetworkAccessIdentifier

• Add Error 422 in the response if only NetworkAccessIdentifier is provided in the API Call

• Remove the example from the NetworkAccessIdentifier scheme
  
• Add also the clarification that if this identifier is provided along with the others it should be ignored and if it is the only identifier provided, a 422 error will be produced

[javierlozallu]

@FabrizioMoggio, @Kevsy, @ThomasEdgeXR, @gunjald and @nicolacdnll are you agree on this resolution?

If so, we can close:

• Create Simple_Edge_Discovery_User_story.md #119
• Usage of IP Address to identify a Device in Traffic Influence API #123 (already closed)
• TI API - New potential requirement: Device Source IP Port #230 (conclusion reached)

[FabrizioMoggio]

this solution is compatible with the TI API recent discussions as you underlined . I will provide a PR and, once merged, I will close the discussions.

Just one doubt: in my understanding the updated API-design-guidelines.md suggests the use of the 3Legs access token to identify the device and the parameter "Device" in the API is optional. This for APIs using 3Legs obviously. The TI API uses 3Legs. I have not started yet a discussion about this but my intention was to implement a solution foe the parameter "Device" as you are proposing and then starting a discussion on also using the access token for the TI API.

[gunjald]

I think except #123 I am fine. I still see an issue on usage of private IP for the device identification being discussed. In my opinion usage of public IP works well in most of the cases while private IP has uniqueness issue. We need to take a call if commonality has suggested usage of private IP then if it addresses such issues or there are other guidance's.

[javierlozallu]

@gunjald good point, could you take the point and ask on commonalities, thanks in advance!