Issue #

#250

Infosys

In Home Device Management API

The API template is available in #281

LAST UPDATES:

The API enables full management of devices connected to a home network, providing connection details and control functions for both customer and operator devices.

• @Eric Murray - What use cases could this API support that TR-369 cannot? And if TR-369 has gaps, why is it preferable to create a new API in CAMARA instead of evolving TR-369 within the Broadband Forum?

  • @ravim95-eng: The BBF TR-369 standard focuses on low-level broadband network operations intended for service providers. In contrast, CAMARA offers a higher-level abstraction through simplified APIs, making them accessible to non-telecom consumers without requiring knowledge of underlying protocols like TR-369, TR-069, or TR-181. The proposed CAMARA Device API is designed to be standards-agnostic and easily consumable across domains.

• @Alberto Ramos Monaga: Bit concerned about a possible overlap with the already approved Home Devices QoD API, since both build on the same household device inventory.

  • @ravim95-eng: I see the proposed InHomeDeviceAPI to be foundational/pre-requisite API for usecases like Home Devices QOD API rather than functional overlap

Aug 28, 2025: The presentation will be on the next Backlog meeting with all needed supporting documentation and the API proposal.

AP: The presentation will be on the next Backlog meeting with all needed supporting documentation and the API proposal.

Sep 11, 2025: AP: The presentation will be on the next Backlog meeting with all needed supporting documentation and the update API proposal.

Key Architects are out of office; hence team would be presenting ‘AP 20250828-01’ on the next call of 25th September.

Sep 25, 2025: The presentation has been carried out during the meeting. Discussion:

• @Mahesh Chapalamadugu (verizon):

  • Noted that the IoT Device Management repo is still very early, with the goal of basic lifecycle management, later extending to diagnostics.

  • Raised the possibility of overlap/synergy between IoT Device Management and the new In-home Device API.

  • Emphasized CAMARA’s principle of keeping APIs small, intent-based and simple, rather than large YAMLs covering multiple functions.

  • Asked whether In-home Device API is really distinct or if it should be consolidated with IoT device management.

• @Ravi:

  • Explained that In-home Device API is intended to manage household connected devices (desktops, laptops, mobiles) behind a modem, exposing standard APIs for ISPs and third-party apps (voice assistants, apps, etc.).

  • Suggested that IoT and connected devices should be unified under one specification rather than kept separate.

  • Argued that at an abstraction level the data attributes for IoT and connected devices are nearly identical, so one generalized API could cover both.

  • Clarified that the proposal is not about putting everything in one YAML but keeping separate operations with a shared model for all devices.

  • Conceded that while the current focus is “in-home”, the model could extend beyond (e.g., connected cars).

AP1: Create a PR with the API proposal following the template - OK

• Join to the call of IoT Device Management to clarify scope and positioning (if the API remain separate, clearly document the distinct use cases, if not proposed a unified device object model that works across IoT, home, and possible other domains like automotive).

• https://github.com/camaraproject/APIBacklog/issues/50 - This is the issue in API backlog for device management. You will also find a pdf file which has high level scope defined in the same issue.

  • @Ravi Shekhar attended IoT device management backlog meeting earlier to understand the scope of it and overlap with proposal here. Based on those discussions, #50 is about IoT devices management and the one proposed here is related to devices connected to modem, so the scope are different. I am refining the usecase for this proposal & mostly have it for upcoming call - OK

AP2: Upload the presentation to the supporting document within the current PR - OK

Oct 9, 2025, Oct 23, 2025: Not treated

Nov 13, 2025: Create the PR with the related presentation. The last point of IoT Device management has been solved (see previous minutes).

Nov 27, 2025: Not treated - Review posible overlap with https://github.com/camaraproject/NetworkAccessManagement (Discussed): NetworkAccessManagement API scope to enable developers to manage network operator-supplied devices(ie. Modem). Scope of proposed API here is to enable developers to manage network access of home devices(ie. Laptop, Smartphone) that are connected to Modem.

MEETING UPDATE:

Dec 11, 2025: There are no further topics pending on this issue. The idea would be to present this API to the TSC for approval.

#259

Heksagon

Voice One Time Password Call

The API template is available at #263

INITIAL CONTEXT:

The “Voice One Time Password Call” API is used to send short-lived one time passwords (OTP) to a phone number via voice call and validate it afterwards, in order to provide a proof of possession of the phone number.

AP1: Update the PR by creating a new entry under documentation/API-proposals instead of modifying documentation/API-proposal-template.md.

AP2: Create an issue with the API proposal label and link it to this PR.

AP3: Resolve the easyCLA error by clicking the provided link and signing the authorization

Sep 25, 2025: Not treated

Relation with Voice Verification Code (#233) - Herbert suggest if we can merge this with this issue.

Heksagon: Regarding your suggestion to merge our issue proposal with #233, we have checked and it looks like that their use case works only for "IMS based audio codes" as explained in their API description which is not the case for our API. So we don't think that merging the two issues would be a good idea. If there is any further discussion needed on that, we can have a call to evaluate it.

Oct 10, 2025, Oct 23, 2025, Nov 13, 2025,Nov 27, 2025: Not treated

MEETING UPDATE:

Dec 11, 2025: Resolve the PR comments and upload the PowerPoint presentation - Not treated

#267

Ericsson

Radio signal Strength API

The API template is available at #268

INITIAL CONTEXT:

The API exposes microwave link endpoints, carrier frequencies and the current attenuation level for a given geographical area. API Consumer can convert a link’s attenuation in dB into mm/h of rain intensity. The API can be used by weather companies or by climate researchers to improve accuracy, delay, geographical coverage and spatial resolution.

Oct 23, 2025:

AP1: The person responsible for sending the ppt will present it at the next Backlog session - OK

AP2: Solve the EasyCLA - OK

Nov 13, 2025: Ericsson made a presentation for the proposal.

• Question from @Kevin Smith: For a service API this looks like too much low-level network detail. Instead, we should expose something the average application provider can actually use – e.g. in a rainfall use case, give “predicted rainfall” as a simple outcome, not raw network-state parameters. He’s asking whether you or the others agree with that direction.

• Response from @kamran: Our original intention with this API was precisely the opposite: to expose raw data, because weather companies and researchers can combine it with their own sensors and that’s where the added value is for them. I agree that some of this can reveal network details, but we could mitigate that with compromises such as adding noise or similar techniques.

• Point from Vodafone:

  • Common concern: the proposed API is far too technical for a CAMARA service API; several participants suggest shifting toward a use-case–driven service (e.g., rainfall prediction) instead of exposing raw network metadata.

  • Vodafone’s position: their teams are already building an algorithmic, processed-data solution, not a raw-network interface; they see more market value in outcome-level insights aligned with concrete use cases.

  • Open question: while meteorological agencies could use raw data, it’s unclear whether the market truly wants that, or whether CAMARA should instead standardize a higher-level “results” API rather than a low-level RF-data feed.

• Point from @Eric Murray:

  • This proposal is too technical, with a very narrow audience, because most customers don’t care about attenuation itself, they care about rainfall at a given place and time.

  • Therefore he suggests shifting to an API where rainfall is the response, and the telco (or provider) handles the internal problem of converting network data into rainfall prediction, which he considers a solvable problem.

AP: Ericsson will have a internal discussion to see if they want to change anything related with the collected feedback and if not, notified backlog to review the PR and sent to TSC for approval.

Nov 27, 2025: New update will come in the next session.

MEETING UPDATE:

Dec 11, 2025: Suggestion naming, avoid attenuation and the technical output parameters (tx, rx, and polarization). The group want to use Radio Signal Strength. No objections to sent to next TSC.

Issue #

18

Totogi

New Proposal: Receive SMS

The API template is available in PR#75

• 20240327-02 was completed. Herbert responded but not the subgroup owners, no activity seems to had happened for a month: Issue #9 · camaraproject/ShortMessageService

Seems to fit in the SMS as a new scope enhancement 

The issue is not eligible to be closed yet.

ACTION: Ricardo to formally proceed with the scope enhancement os the SMS group.

MEETING UPDATE:

• Reminder sent

→ Follow-up on API onboarding tracker: Pending.

20

Deutsche Telekom

Best Interconnection

The API template is available in PR#88

Input from OGW Drop 3

Seek for support

ACTION: See if there is any overlap within EdgeCloud

ACTION: Nick (centillion) to review with Noel (DT) about the match of use cases and consider support.