Merge branch 'camaraproject:main' into shutdownservicestatus

CODEOWNERS

@@ -7,3 +7,7 @@
 # These are the default owners for the whole content of this repository. The default owners are automatically added as reviewers when you open a pull request, unless different owners are specified in the file.
 
 * @TEF-RicardoSerr @jgarciahospital @NoelWirzius @caubut-charter
+
+# Owners of the CODEOWNER and Maintainer.md files are the admins of CAMARA (to allow them to keep the teams within the CAMARA organization in sync in case of changes)
+/CODEOWNERS @camaraproject/admins
+/MAINTAINERS.MD @camaraproject/admins

MAINTAINERS.MD

@@ -1,9 +1,9 @@
-| Org                    | Name                                                |
-| -----------------------| ----------------------------------------------------|
-| Charter Comunications | Christopher Aubut |
-| Deutsche Telekom | Noel Wirzius |
-| GSMA | Mark Cornall |
-| Orange | Ludovic Robert |
-| Telefonica | Jorge Garcia |
-| Telefonica | Ricardo Serrano |
-| Vodafone | Eric Murray |
+| Org                    | Name                     | GitHub Username           |
+| -----------------------| -------------------------|---------------------------|
+| Charter Comunications | Christopher Aubut | caubut-charter |
+| Deutsche Telekom | Noel Wirzius | NoelWirzius |
+| GSMA | Mark Cornall | MarkCornall |
+| Orange | Ludovic Robert | bigludo7 |
+| Telefonica | Jorge Garcia | jgarciahospital |
+| Telefonica | Ricardo Serrano | TEF-RicardoSerr |
+| Vodafone | Eric Murray | eric-murray |

README.md

@@ -32,7 +32,7 @@ The Working Group has no (pre)releases yet, work in progress is within the main
 	* Subscribe / Unsubscribe to the mailing list of this Sub Project <https://lists.camaraproject.org/g/wg-abl>.
 	* A message to the community of this Sub Project can be sent using <wg-abl@lists.camaraproject.org>.
 * Lifecycle of API proposals:
-	* [APIbacklog.md](https://github.com/camaraproject/WorkingGroups/blob/main/APIBacklog/documentation/APIbacklog.md)
+	* [APIbacklog.md](https://github.com/camaraproject/APIBacklog/blob/main/documentation/APIbacklog.md)
 * Procedure for the submission, discussion and approval of new API proposals:
 	* [API-onboarding.md](https://github.com/camaraproject/Governance/blob/main/documentation/API-onboarding.md)
 

documentation/API proposals/APIProposa_Device_Volume.md

@@ -0,0 +1,10 @@
+| **Field** | Description |
+ | ---- | ----- |
+ | API family name |Device Data Volume |
+ | API family owner | Deutsche Telekom (Noel Wirzius)|
+ | API summary | This API offers detailed insights into the customer's data usage status, including whether they have remaining data volume available and their current position within that volume allocation. It accurately determines whether the customer is nearing the beginning or the end of their allocated data volume, providing valuable information for managing data usage efficiently.|
+ | Technical viability | The API should get information for a dedicated Sim-Card and also offer this in a subscription mode. The return value should not be a fixed value more an estimated indicator  (e.g. <200mb, <1Gb ...) |
+ | Commercial viability | This API was requested by different content providers. It helps them to get more insights, how to deliver their traffic. | NO |
+ | Validated in lab/productive environments? | Yes |
+ | Validated with operators? | Yes |
+ | Supporters in API Backlog Working Group | Vodafone, Vonage, Deutsche Telekom |

documentation/API proposals/APIProposal_Device_Connection_Quality_Indicator.md

@@ -0,0 +1,11 @@
+| **Field** | Description | 
+| ---- | ----- |
+| API family name |Device Connection Quality Indicator |
+| API family owner | Deutsche Telekom (Noel Wirzius)|
+| API summary | The API enables App Developers to get insights about the network status of a defined mobile device. For this the API will return an indicator which is bundeling information about the device network status such as availibilty, open datavolume, congjestion, historical congjestion or the connecitvity status (2G, 3G, 4G, 5G). The API service will also alert the consumers when an indicator changes. This API would be useful for applications that optimize user experience based on the connecitvity status of a defined device.|
+| Technical viability | The type of ndata required for this API can be categorized into 4 groups as listed below <br>1\.	User data <br>2\.	Network Data <br>3\.	Historical data <br>4\. Device Data <br> <br> The following inputs are suggested as a first scope for the indicator:  <br> - Device Avalibilty (https://github.com/camaraproject/DeviceStatus/tree/release-0.5.0-rc) <br> - Network Insights ( https://github.com/camaraproject/WorkingGroups/blob/main/APIBacklog/documentation/SupportingDocuments/API%20proposals/APIproposal_NetworkInsights_Verizon.md) <br> - connection standard (2g,3g,4g,5g) <br> - Remaining datavolume of the contract <br> - Speed limitations of the contract|
+| Commercial viability | This API was requested by different content providers. It helps them to set up the right content quality in their applications.|
+| YAML code available? | NO. |
+| Validated in lab/productive environments? | NO|
+| Validated with operators? | NO |
+| Supporters in API Backlog Working Group | Deutsche Telekom Vodafone |

documentation/API proposals/APIScopeEnhancement_QoDProvisionMode.md

@@ -0,0 +1,12 @@
+| **Field** | Description | 
+| ---- | ----- |
+| API family name | QoD Provision Mode |
+| API family owner | Telefonica |
+| API summary | (*As a scope modification of the existing QoD API*)<br> <br>QoD Service provides the customer with the ability to set certain profile of QoS to an access network connection. Currently, the API supoports a session mode:  <ul><li>the developer wants to set the required QoD profile for a certain period of time, after which the be network configuration must be set back to the default one.</li></ul> But there is another possible use case for QoD, which is not currently supported: <ul><li>the developer wants to set the required QoD profile indefinitely, this is, each time that the UE connects to the network, it will use the required QoD profile instead of the default one, until the association is removed.</li></ul> Proposed evolution of the existing API is to add support for a new "provision" mode, complementary to the current "session mode", with equivalent operations under a new path, to model: <ul><li>Creating a QoD provision for a device </li><li>Removing a QoD provision for a device </li><li>Getting the QoD provision details for a device</li><li>Updating QoD provision details for a device</li></ul>|
+| Technical viability | Same tecnhical concerns and limitations apply as in the existing QoD service, already validates in live commercial environments|
+| Commercial viability | This new model is more convenient for those B2B use cases where the devices being connected are used for a single purpose. For example reporters on the move, using backpacks to cover events and perform live video connections, that need the networking conditions provided by the QoD profile each time the backpack is used.|
+| YAML code available? | YES |
+| Validated in lab/productive environments? | ONGOING <br> Telefonica testing environment |
+| Validated with real customers? | PLANNED <br> As trial with Telefonica's customer |
+| Validated with operators? | NO |
+| Supporters in API Backlog Working Group |  |

documentation/API proposals/API_Proposal_Tenure_Vodafone.md

@@ -0,0 +1,12 @@
+| **Field** | Description | 
+| ---- | ----- |
+| API family name | Tenure |
+| API family owner | Vodafone |
+| API summary | Establishes a level of trust against the mobile ID by verifying the length of tenure for a mobile user who is bound to a mobile number with their current mobile operator; tenure means the period of time a MSISDN has been associated with a specific user with their current CSP. API checks whether the lifetime tenure of a given MSISDN is longer than an input date and indicates the type of mobile contract.<br><br>[Use Case]: Enterprises can use Tenure API to gauge and establish a level of trust (or Trust Score) with a mobile user who is associated with a specific mobile number, based on how long they have been associated with that number. |
+| Technical viability | The data for this API comes from backend systems/sources (i.e. CRM). 
+| Commercial viability | To Establish level of trust (or Trust Score) against a mobile ID (MSISDN). The Tenure API will return a True or False answer as to whether the customer's tenure with an operator has been longstanding.<br><br>[Example]: Customer submits MSISDN to understand if the mobile number has been registered to a CSP for longer than a specific date. <br><br>* Sample Request: {"tenure_before_date":{"value": "2019-01-15"}} <br>* API   Response: True/False -  if tenure is longer than specified date + billing segment  (PAYG/PAYM/Business) <br>* Sample   Response: "tenure_before_date_check":   true,    "billing_segment":   "PAYM" |
+| YAML code available? | YES |
+| Validated in lab/productive environments? | YES |
+| Validated with real customers? | YES - TMT Analysis |
+| Validated with operators? | YES - Telefonica, Hutchinson Group |
+| Supporters in API Backlog Working Group | Telefonica, Deutsche Telekom, Orange, KDDI |

documentation/API proposals/APIproposal_Number_Recycling_API_KDDI.md

@@ -0,0 +1,14 @@
+# APIproposal_Number Recycling API_KDDI
+
+| **Field** | Description | 
+| ---- | ----- |
+| API family name | Number Recycling |
+| API family owner | KDDI |
+| API summary | To know whether a phone number is linked to a subscriber, the Number Recycling API can be used to check whether the subscriber of the phone number has changed. <br>A common scenario is when a fraudster obtains a phone number that previously belonged to another person who did not properly deactivate or verify it. The fraudster can then use this number to commit identity theft or engage in fraudulent activities, such as obtaining access codes for accounts associated with that number. In some cases, fraudsters may also attempt to use services or avoid charges by leveraging old, no longer used numbers that were previously used by other users.|
+| Technical viability | This API is applicable for 4G and 5G devices and not dependent on specific network functions or cloud capabilities.|
+| Commercial viability | Check whether there has been a change in the subscriber associated with the specific phone number after the specified date. <br>Also, enterprise/app service providers want to prevent mis-delivery before sending messages to customers. <br>Furthermore, the enterprise may authenticate the user using SMS-OTP/phone as a means of account recovery. If the specific phone number is canceled and someone else is using it, the enterprise wants to prevent it from being reset. <br>Option 1: Response regarding whether there will be changes from the specified date <br>Input: MSISDN, Specified Date ("value": "2019-01-15") <br>Response: Boolean (True/False - Contract change) <br>Option2: Response regarding the start date of the current contract <br>Input: MSISDN <br>Response: Contract Start Date|
+| YAML code available? | NO. <br><em> To be provided. </em> |
+| Validated in lab/productive environments? | NO. |
+| Validated with real customers? | NO. |
+| Validated with operators? | NO. |
+| Supporters in API Backlog Working Group | DT, Vodafone <br><em> NOTE: That shall be added by the Working Group. </em> |

documentation/API proposals/APIproposal_RegionDeviceCount_ChinaUnicom.md

@@ -0,0 +1,13 @@
+| **Field** | Description | 
+| ---- | ----- |
+| API family name | Region Device Count | 
+| API family owner | China Unicom |
+| Initial API Contributors | Fan Yang - China Unicom , Jin Xu - Huawei |
+| API summary | **Description**     <br>  This API allows for the API Consumer to query the number of active users (i.e., excluding idle mode users). lin the specified area. The query area can be a circle or a polygon composed of longitude and latitude points.    <br>  **Use Cases**     <br>  User Story     1    : Emergency Rescue    <br> - As an emergency rescue worker, I hope to be able to obtain the number of users in an area where a special emergency activities could be needed through an API, so as to quickly understand the situation, plan and guide the rescue work. <br>|
+| Technical viability | This API is based on real-time location information expansion. It allows obtaining, on a per operator basis, the number of active users in a certain area based on their real-time location. |
+| Commercial viability | For use in emergency rescue, disaster relief, intelligent transportation, smart tourism and other scenarios| 
+| YAML code available? | NO<br>To be provided  |
+| Validated in lab/productive environments? | YES<br>Available in China UniCom test environment |
+| Validated with real customers? | YES<br>For emergency rescue use by the Blue Eye Emergency Rescue Platform |
+| Validated with operators? | YES<br>Available for China Unicom in China |
+| Supporters in API Backlog Working Group | China Unicom,Huawei |

documentation/API proposals/APIproposal_Verified Caller.md

@@ -0,0 +1,12 @@
+| **Field**                                 | Description                                                  |
+| :---------------------------------------- | ------------------------------------------------------------ |
+| API family name                           | Verified Caller                                              |
+| API family owner                          | China Telecom, China Unicom，ZTE                             |
+| API family summary                        | **High-level description**. This API allows accurate operator-certified "Verified Caller" information, including SMS and video clips, to be displayed on the phone screen of the called user before they answer the call. This API enables enterprise customers to vividly present their multimedia business cards and reduces the incidence of malicious calls. It is applicable to customers in industries such as government, finance, express delivery, healthcare, education, etc., who have outbound call requirements. For instance, when a hospital arranges follow-ups and communication between customer service and rehabilitation patients, patients might doubt the hospital's identity and typically refuse the calls. By utilizing this API, the hospital's identity can be displayed, thereby improving connection rates and significantly enhancing customer service satisfaction.This API supports fixed line and mobile phone customers to use. **Input params**: APIserviceID, TargetNumber, SenderNumber, TemplateCode, TemplateParams. **Output params**: API success or failure response. | 
+| Technical viability                       | This API leverages existing SMS and RCS services provided by operators. |
+| Commercial viability                      | This API has been commercially launched in China Telecom and several other operators. However, the API is not yet standardized. In order to achieve a wider range of commercialization and easy use for enterprises and developers, it is necessary to standardize the service API. |
+| YAML code available?                      | TBD                                                          |
+| Validated in lab/productive environments? | YES, Commercially launched in China Telecom.                 |
+| Validated with real customers?            | Yes                                                          |
+| Validated with operators?                 | Yes, China Mobile, China Unicom.                             |
+| Supporters in API Backlog Working Group   |                                                              |

documentation/API-Scope-Enhancement-Template.md

@@ -0,0 +1,17 @@
+# API Scope Enhancement Template
+This template captures all the information that a partner should fill out when proposing a scope enhancement for an existing CAMARA API
+
+
+| **Field** | Description | 
+| ---- | ----- |
+| API name | [Name of the API or API family whose scope is proposed to be enhanced](url) |
+| New API name | New API name proposed to encompass the new scope (if applies) |
+| Scope Enhancement owner | Company submitting the API enhancement. |
+| Scope Enhancement summary | High level description / scope of the API or API family, and two/three examples of in-scope business cases. |
+| Technical viability | Identify the underlying network/cloud capabilities which are needed for the support of this API or API family, relating these capabilities them to standards maturity. <br><em>Example: this API requires the availability of NEF with this Rel-15 "X"feature</em>. 
+| Commercial viability | Specify the availability of commercial or (industrialized) open-source solutions for the identified network/cloud capabilities. <br><em> NOTE: If open-source, provide a publicly available reference/link to the actual solution, and specify the version under consideration.</em>|
+| YAML code available? | YES / NO. |
+| Validated in lab/productive environments? | YES / NO. <br>If YES, specify if it was lab network or productive network. |
+| Validated with real customers? | YES / NO. <br>If YES, specify how many customers participated in the evaluation, and what their use cases were. <br><em>NOTE: It is not mandatory (though recommendable) to specify the name of the customers. </em> |
+| Validated with operators? | YES / NO. <br> If YES, specify how many operators participated in the evaluation. <br><em>NOTE: It is not mandatory (though recommendable) to specify the name of the operators. </em> |
+| Supporters in API Backlog Working Group | List of supporters. <br><em> NOTE: That shall be added by the Working Group. </em> |