Community Attendees:
Thorsten Lohmar , Rajat Kandoi , Barath K , Masaharu Hattori , fabrizio moggio , Jorge Garcia Hospital , Toshi Wakayama , steve.vickers , Alejandro Palmier , Tanja de Groot , @fadime demirer, Surajj Jaggernath Community Attendees:
LF Staff:
Agenda
Antitrust Policy
Agreement of last minutes (Link)
Action Items Review
API Backlog topics
Discussion of Issues and Pull Requests
The Meeting on 30th December is canceled.
Minutes
Agreement of last minutes
No comments (approved)
Action Items Review
Meeting cancelled - invite removed.
AP Closed on “Empty document” - since PR#15 was created
AP on PR#12 - Waiting for additional reviewers and approvals
API Backlog topics
Issue #14 - IoT Data Transfer Activation
Fabrizio - Started from IoT view point, but given CAMARA being agnostic to tech, the IoT concept is in the title. Currently it is hidden.
Given DN API is focus on providing “time”, IoT API parameters - already covered in DN.
DN is not assuming IoT-profiled network
Developer doesn't understand network profiles or network configurations
Provide API related to IoT to configure fleet of SIMs, then dedicated on DN for scheduling.
Current position - but need to consult internally. Not ready to close the discussion.
Thorsten:
Ok to continue discussion - Impact on DN unclear at this point
3GPP APIs have already some APIs for BDT
Tanja:
There could be something specific about IoT devices - this is one detail that also needs to be specified
Fabrizio (alternatives)
Keep the IoT area and keep the IoT API focusing on “those” features and keep DN for scheduling
Find some parameter or feature that can be in DN API and then can close the IOT API and start working on DN
Thorsten
Use case - BDT - can be IoT agnostic
Fabrizio - yes, probably right but our approach / focus was on IoT
Issue #16 - Question on QoD booking proposal
Masaharu Hattori
QoS Booking API - add certain feature in the existing QoD API.
Asked to clarify relations between the two APIs in API Backlog. What is the difference and overlap
Slides prepared and shared. (To be uploaded and linked?)
location and time are common aspects between the APIs
Thorsten: Network capacity is not the only thing (in early days), can also specific multiple QoS profiles possibly.
Management of connectivity can be per device (common between APIs)
Thorsten: Even B2B is probably a lot like B2B2C. Since the entity might leave the actualy configuration to the end user
Who is the B2B2C in QoS Booking API
We can B2C case OTOH B2B2C - first “B” can be company hosting the event.
Thorsten: So could this company be buying bulk and selling to one device?
Masaharu: First booked network resources, then on top of that book individual connection.
Thorsten: So some “B” would not know how many “tickets” can be sold (since they don't know capacity)?
Can continue discussion offline. Continue discussion in Issues.
Key difference is multiple devices - but no requirement to have multiple. Fully okay to have single but probably a niche case for DN.
Fabrizio
Overlapping also with IoT API seemingly
Feature must be simple to developer and how its implemented in network is not important
Scheduling - can decide to have many. And specific config per network.
If we want to have scheduling on one or more devices in also other APIs - or do we want to add this feature - or just in one API, i.e., common API for scheduling
Then what is managed (the resource, e.g. device) is managed b some other API
May be we can use some “id” or “booking parameter” - reasoning out loud
Thorsten: Also interesting and goes in to details of the the DN
Two capabilities - set of QoS Profiles, the other monitoring
DN reservation - what are the capabilities - then would of course use other APIs after DN is activated to interact
Jorge
If use cases are different, then can consider different APIs
May be we need to flesh the APIs and then do a comparison
QoD Booking could also be sandbox but part of the family
Next backlog - Jan 9th. Good to have something.
Discussion of Issues and Pull Requests
Usage Scenarios - pending review
API Design Requirements - PR #15
Use “Considerations” instead of “Requirements” (to avoid MUST, SHOULD discussion)
Thorsten walked through the document
Monitoring aspects should be expanded
Is it one way to start addressing #10? - Tanja - looks good.
Tanja
States - several disctinct standards and should cross-reference
Dont need to map all but dont need to re-invent
State is also potentially related to monitoring
Should be relation to events - not all states may need to be sent to the API consumer
Administrative states and operational states
Once activated and can then monitor
Thorsten:
Separate what to book and what features the device gets access to - as potential continuation
Thorsten: Do you see any existing CAMARA API for monitoring
Tanja: Depends on what is being monitored. TMF also has usage. Possibly volume.
Could also be different SLAs - monitoring nothing to everything
Topic 1
Comments
Action items
- fabrizio moggio to clarify “IoT” requirements
- Create new issue or update issue #14
- Thorsten Lohmar : Comment on Issue #16 (related to Masaharu’s input today)
- Group
- Review PR #12 (should ideally be reviewed and merged offline)
- Review PR #15
- Tanja de Groot - Suggest references from existing specs (esp. TMF)