Device prioritisation in WiFi

[jordonezlucena]

A proposal for a "Device Map & Prioritization API" has been uploaded here. Please add any comments you may have.

[Kevsy]

HI @jordonezlucena - thanks for sharing, but GitHub does not allow for easy review of Office binary files (pptx) . Please can I ask you to upload the .yaml file for the API, and a README.md for the description? You can add images buy uploading them into a new issue called 'images' and then reference them in your markdown.

[jordonezlucena]

In relation to the format conversion, here's the .md file. For the time being, it contains the images from the PPT. We'll reshape it shortly.

[jordonezlucena]

@Kevsy: the YAML code for the first API version is available herehttps://github.com/camaraproject/WorkingGroups/blob/main/APIBacklog/documentation/Contributions/API%20Proposals/WiFicontrol.yml

[eric-murray]

I've discussed this with Vodafone's fixed access team. Whilst we currently use a similar proprietary protocol in some markets, their longer term strategy is to adopt the TR-369 User Services Platform protocol for managing devices connected to a broadband router.

Are you familiar with the USP protocol? If so, can you compare this protocol to your own proposal, highlighting the advantages and disadvantages of each approach?

[jordonezlucena]

Thanks Eric for your suggestion, and for informing us of USP protocol -- we didn't have it in the radar. Nonetheless, our intention is to provide a user-friendly technology-agnostic API, entirely decoupled from underlying specificities, including agents and protocols. What the 3rd party wants is to have means to 1) identify the devices connected to the broadband router, and 2) prioritise traffic of certain device(s) over others in this LAN environment -- how this is enforced downwards (i.e., whether the protocol selected for device management is USP or any other) should be irrelevant to the 3rd party.

Based on your comments, we're currently working on two directions: 1) Provide an API description compliant with the other proposals (.md file capturing business cases, high-level info on input/output params) and a new YAML file version, making the API much more user-friendly and technology-agnostic, in line with the rationale mentioned above. We will publish this during this week. 2) Analysing the capabilities of the TR-369 USP, and working out a comparative analysis against our proposed API solution. The idea is to highlight pros and cons, following your recommendations. We will make this analysis available as soon as we get this done.

[jordonezlucena]

1. The updated MD and YAML files have been updated -> https://github.com/camaraproject/WorkingGroups/tree/main/APIBacklog/documentation/Contributions/API%20Proposals

[eric-murray]

Thanks @jordonezlucena

As mentioned above, I do not currently have internal support for Vodafone to develop this API, but once you have done the comparative analysis of your proposal with USP, I will bring this to the attention of the relevant team within Vodafone.

[jordonezlucena]

TR-369 is regarded as an evolution of the TR-069 standard used for device management. It implements new communication techniques between platform and device to adapt to new communication technologies (TR-069 is built on the basis of SOAP, which carries a fairly high overhead in communications), and uses a data model that is defined by the BBF (in TR-369, the TR-181 data model is implemented). Taking your guidance and suggestions, we’ve conducted an internal analysis to check our proposal against USP (TR-369) protocol. A summary of the golden nuggets from this analysis:

• The API proposal submitted to the backlog provides a REST API aligned with CAMARA spirit (user-friendly and agnostic of the underlying implementation details). In home network scenario, this API allows identifying devices connected to the home network, and request prioritization for some of them. To that end, the API needs to get information on home router identifier, device identifier (IP) and DSCP (to configure traffic prioritization on the device) – but nothing else. With these input parameters, the API becomes a good candidate as an entry point for developers, since it hides (does not disclose/expose) underlying specificities to them, making API consumption much easier for them.

• We see USP (TR-369) as a solution quiet tied to the underlying implementation details/specificities, and therefore not suitable to be offered as-is to developers. What is more, USP uses MAC for device identifier, something that cannot be made accessible to developer for security/privacy reasons (MAC are not accessible on Android/iOS devices either). These are reasons that make us think that in a potential CAMARA API, USP would not scope the northbound side (what is exposed to the developers), but southbound side (not visible to developers) instead.

• Focusing on southbound side, we can confirm that USP (TR-369) is technically comparable to the underlying implementation of the API proposal. It is true that there exist differences on two aspects, though they are minor: -- DSCP representation: String (API proposal) vs Hexadecimal system (USP) -- QoS description: DSCP support (API proposal) vs DSCP/MSCS/SCS support (USP).

• About the support of TR-181 (data model) -> it is difficult nowadays to have data model support in CPEs from vendors, due to limitations in SW. However, this corresponds to implementation details subjected to underlying technological capabilities, so our understanding how the actual data model is configured and enabled in the actual CPEs might be out of scope of CAMARA (i.e., no relevant for developers)

[jordonezlucena]

The API proposal has been formally submitted with the PR camaraproject/WorkingGroups#73, following the instructions captured here.

[eric-murray]

Vodafone have now reviewed Telefonica’s proposal, but in the long run do not see any significant advantages over standards developed by the Broadband Forum for Home Gateways.

[jordonezlucena]

Hi, PR camaraproject/WorkingGroups#73 has been merged together with the rest of API proposals. It will be sent out for SC approval by 13/10. If not approved, I will reopen this PR.