TI API - New potential requirement: Device Source IP Port #230
Replies: 14 comments 55 replies
-
I will add this topic to the agenda to ask for feedback, @FabrizioMoggio if you can explain there a bit what this new requirement is about it would be perfect. |
Beta Was this translation helpful? Give feedback.
-
There are scenarios where a device has multiple traffic/streams which are identified based on Port numbers. An example is the camera with low and high resolution traffic which have different port numbers allocated to each. There are use cases where only one or selected streams from the device need to be routed to a specific Edge or Application Server. This identification of the traffic can be done by introducing source port numbers in the request, wherein which the Application can specify which stream (corresponding to the ports mentioned) need to be routed / influenced. |
Beta Was this translation helpful? Give feedback.
-
Currently we have in the TrafficInfluence resource some attibutes related to the Destination EAS and some others related to the Source that is the smartphone: -Device: here we identify the Source With the goal to manage a Source port, we can modify Device adding a new "devicePort" parameter, maybe in Ipv4Address and Ipv6Address definition. or even better we can define two trafficFilters: destintionTrafficFilters and sourceTrafficFilters. So we don't need to modifiy Device or Ipv4Address and Ipv6Address. I propose to introduce: destintionTrafficFilters and sourceTrafficFilters |
Beta Was this translation helpful? Give feedback.
-
I agree, introducing destintionTrafficFilters and sourceTrafficFilters will bring more clarity on how the application can define 'what to influence'. They can be such that application can create them with minimum information that it may have. |
Beta Was this translation helpful? Give feedback.
-
About the improvement in the Documentation that is needed, we can start looking at: Commonalities have this document on UE identification: https://github.com/camaraproject/Commonalities/blob/main/documentation/UE-Identification.md#af-specific-ue-external-identifier |
Beta Was this translation helpful? Give feedback.
-
Additional information: GSMA OPG.03 defines Public_IP and Source Port to identify the UE. So we can at least have the following conclusion: Conclusion: We need to introduce Source IP port in the TI API How to, this is still under discussion but I suggest to be aligned with: #247 |
Beta Was this translation helpful? Give feedback.
-
According to the explanation ( thank you, I had it wrong before) I don't think we need sourceTrafficFilter. this is way I wasn't able to differentiate them, they are the same. Am I right? @babunkj what do you think? |
Beta Was this translation helpful? Give feedback.
-
Implemented with: #249 |
Beta Was this translation helpful? Give feedback.
-
Merged rel 0.9.5 |
Beta Was this translation helpful? Give feedback.
-
Actually not all is implemented in Rel 0.9.5: #230 (reply in thread) |
Beta Was this translation helpful? Give feedback.
-
Proposed solution according to: #249 (comment) Proposal: we use Device as defined in Commonalities |
Beta Was this translation helpful? Give feedback.
-
please note that if we go for just one source port, sourceTrafficFilters, if used, must be equal to the port defined in Device, if used. What happens if are used two different ports? We can document that if they are both valorised, if not equal, the one defined in sourceTrafficFilters, will "win". |
Beta Was this translation helpful? Give feedback.
-
According to the above discussion: Conclusion:
|
Beta Was this translation helpful? Give feedback.
-
implemented in: #278 |
Beta Was this translation helpful? Give feedback.
-
it is possible for a Device to setup more data flows using specific Source IP Ports. Currently the TI API doesn't support a Device with source port number.
Are there use cases requiring to support this feature?
Beta Was this translation helpful? Give feedback.
All reactions