APIproposal_CapabilitiesandRuntimeRestrictions_T-MobileUS.md
August 13, 2024 · View on GitHub
| Field | Description |
|---|---|
| API family name | Capability and Runtime Restrictions |
| API family owner | T-Mobile US |
| API summary | CAMARA Service APIs are designed with many optional parameters and features. It’s unreasonable to expect each API Producer (i.e. Operator) to support all these optional parameters. In addition, some supported features and parameters may not be enabled at Service API invocation time, based on network state, who might be invoking and/or for whom/which device, location, …) There is currently no mechanism to exchange such information with API Consumers (i.e. Application Service Providers (ASP)/Developers/Aggregators) and keep the CAMARA APIs the same across the Exposure Gateways. API Family is intended to cover the following areas: 1. Exchange of runtime restrictions (i.e. not supported parameters/features) 2. Exchange of capabilities (i.e. enabled/not enabled a set of parameters/features) 3. Topology exchange (i.e. abstraction) for capability-footprint association For the first area following examples can be given: 1. Device identifier in QoD can be of type Phone Number, IPv4 Address, IPv6 Address, Network Access Identifier (NAI). One operator may support all of these identifiers in which case there will not be a need to list any restrictions towards the schema in the QoD API, however another operator supports only Phone Number, thus will need to inform ASPs not to use them. 2. If there is a regulation specific maximum accuracy level that must be set greater than the minimum Radius defined in ‘location-retrieval.yaml’, operator must be able to overwrite this new minimum. For the capabilities following example can be given: 1. While the operator may not support only one of the default set of QoD Profiles, at the time of invocation, one ore more of the supported QoD profiles may not be available due to network state and/or location. Invocation of QoD with not-enabled QoD profile will result in error and lead to bad developer experience. Operators must be able to efficiently exchange this information. |
| Technical viability | Yes (reuse of JSON Validation Schema with little to no impact to current API designs) |
| Commercial viability | This is not a product, but rather Service Management API which falls under CAMARA purview. |
| YAML code available? | YES |
| Validated in lab/productive environments? | In progress |
| Validated with real customers? | NO |
| Validated with operators? | NO |
| Supporters in API Backlog Working Group | T-Mobile US |