Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update of API design considerations #19

Closed
wants to merge 1 commit into from
Closed

Update of API design considerations #19

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
9 changes: 8 additions & 1 deletion documentation/SupportingDocuments/ApiDesignConsiderations.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,7 +1,7 @@
# API Design Considerations

## Introduction
The API design considerations are derived from the API usage scenarios (PR#12). The aim of the API is to hide telco specific complexity, while offering the needed capabilities. There may be different realization of the needed network capabilities, e.g. using shared network slices or even exclusive network slices.
The API design considerations are derived from the API [usage scenarios](UsageScenarios.md). The aim of the API is to hide telco specific complexity, while offering the needed capabilities. There may be different realization of the needed network capabilities, e.g. using shared network slices or even exclusive network slices.

## General Considerations
The API should allow combination with other CAMARA APIs, such as QOD, Connectivity Insights / Monitoring, etc.
Expand All @@ -22,6 +22,8 @@ Reservation of resources should allow for time and location (service area) limit

The Network Provider should control the state transition from *requested* state to either *reserved*, *activated* or *terminated* state. The state transition from *reserved* to *activated* is triggered by the reservation start time. The state transition from *activated* to either *reserved* or *terminated* is triggered by the reservation end time. The API consumer should get notified upon state-transitions.

Note: Functionality to trigger state transition from *activated* back to *reserved* state is not in scope of the initial API, but mentioned for completeness.

There can be different form of resources and capabilities:
- It is essential for many use-cases to reserve connectivity capacity, e.g. expressed in aggregated throughput
- Several use cases require usage of different network capabilities, like for providing Quality on Demand (QOD) or connectivity monitoring, etc.
Expand All @@ -37,3 +39,8 @@ Devices, which have access to the dedicated network, will use one of the pre-sel

## Considerations for Monitoring
There are several potential relevant CAMARA APIs for monitoring, e.g. Connectivity Insights, Connectivity Insights Subscriptions, Session Insights, Device Status, Device Quality Indication, …

## Assumptions for API usage
There are several pre-steps outside of the Dedicated Network API scope. These are for example
- API consumer on-boarding, specifically obtaining API access credentials.
- information about other API features.