Updating the project scope in the ReadMe

[RandyLevensalor]

Updating the project scope to be inclusive of wire-line networks.

What type of PR is this?

Add one of the following kinds:

• documentation

What this PR does / why we need it:

Updates the subproject scope to include wire-line networks in additional to mobile networs. This reflects the state of the API as well as current operatos working on this subproject.

Which issue(s) this PR fixes:

Fixes #238

Special notes for reviewers:

Changelog input

 release-note

Additional documentation

This section can be blank.

docs

[eric-murray]

@RandyLevensalor

Is this your final proposal? There is an outstanding suggested change from @hdamker. If you don't want to incorporate that, can you comment why and dismiss the suggested change.

[jlurien]

I've been checking this issue internally and it is not as simple as changing the README. It has implications on the scope of the API, as this API was originally proposed as an API for mobile networks when presented to the API Backlog. Even if most of concepts and terms introduced in the API would be applicable to fixed networks as well, implementation and commercialization of the same API covering both technologies is not that straight-forward. AFAIK this topic is also being discussed in GSMA Product stream, so I suggest to keep this on hold until some consensus is achieved across Product owners, or raise it to CAMARA Backlog as a new feature to include in the CAMARA porfolio. cc @jgarciahospital

[RandyLevensalor]

@jlurien thanks for the feedback

Even if most of concepts and terms introduced in the API would be applicable to fixed networks as well, implementation and commercialization of the same API covering both technologies is not that straight-forward.

We have implemented this API in our lab across DOCSIS, PON and 5G networks from the same API endpoint. Once we added the QoS Profiles, it became much easier to do this.

Once we resolve issue #166, it will also help to identify which QoS profiles are supported by a given device. That will help filter QoS profiles based on network and device capabilities.

I don't see any technical issues with this implementation across fixed and mobile networks. Can you expand an the none technical issues? I'd be happy to join any discussions to share our experience.

[jlurien]

Hi @RandyLevensalor, the debate is not about the technical feasibility and complexity, but about the convenience to address both mobile connections and fixed connections in the same API. CAMARA APIs are intended to be offered by different operators in a consistent way, so consensus about the scope of an API has to be reached and any subsequent change has to be discussed in the forums where Product teams are present.

[RandyLevensalor]

@jlurien Thanks for the clarification.

We see enabling a single API as critical for both wireless-wireline convergence (WWC) and a better mobile Wi-Fi experience. Additionally, the growth of fixed wireless access (FWA) is further blurring the lines between mobile and wireline networks.

Can you please share where these are being discussed in CAMARA or GSMA either on this thread or a DM in slack / e-mail if there is GSMA member only content that shouldn't be shared publicly? I'd really like to have the opportunity to participate and/or have a representative for the wireline group on some operators provide input.

[hdamker]

@jlurien @RandyLevensalor

The functional scope of CAMARA includes both mobile and fixed networks of Telco operators (ProjectCharter.md):

From a functional perspective the scope is limited to telco APIs, that means APIs in the domain of telco mobile networks, telco fixed line networks, telco edge cloud, etc. or supporting these (e.g. for authentication).

The scope of QoD was only initially limited to mobile (4G/5G). But we had already spent effort within 0.9.0 and 0.10.0 to get/keep the API technically suitable for both mobile and fixed network (see e.g. the discussion about parameters in QoSProfiles). If there are no technical reasons to restrict the scope of the API still to mobile networks we should decide to raise this limit. That was also the consensus within the last QoD call.

That the technical scope of the API includes fixed networks does not imply that any operator has to offer a product based on the API for its fixed network. The definition of products and the implementation mechanism behind the API are out of scope of CAMARA.

BTW: Due to project history there is no proposal within API Backlog for QoD which need to be changed/updated. It was therefore also never presented within the API Backlog group.

[hdamker]

a) Merged recent changes from main (release v0.10.0).
b) Added maintainers for review.

Please review before the next QoD call on March 22nd.

[hdamker]

Looks that we are ready to go.