This page describes the Information Element development for Geolocation Model.
Geolocation Information Element
...
| Section | Description |
|---|---|
Information Element Name |
Place Object (Class) |
| Points of Contact |
Information Element |
Main Contact - Benjamin Cheung , Jacqueline Beaulac [Ericsson] Information Modeling Contact - Benjamin Cheung , Jacqueline Beaulac [Ericsson] Schema Definition Contact - Benjamin Cheung , Jacqueline Beaulac [Ericsson] | |
| Related Use Cases | The Place object for PNFs will first be used in R7 by the OOF / SON / PCI Use case |
Use Cases that have interactions using this Information Element.
ProducersWIKI PAGE: R7 OOF SON Use Case Main Contacts: Swaminathan Seetharaman , N. K. Shankar The Plug and Play Use Case, WIKI PAGE: R7 PNF Plug and Play PnP Main Contacts: Benjamin Cheung damian.nowak |
Participating ONAP Components |
The list of ONAP Components that are stakeholders for the Information Element
Description
Overview and description of the Information Element.
Related Standards & Industry Activities
Please refer to any standards or industry activities that should be taken into account when defining the Information Model related to this Information Element. Please provide links to relevant material.
Attributes
Attributes: Name and describe each attribute of this Information Element. Please include the datatype of the attribute if possible. Is this attribute read-only, read-write? Are there any default values?
Relationships
Relationships: Describe how this Information Element is related to other Information Elements. Also describe nature of the relationship: association, inheritance, dependency, etc. and multiplicity.
Originator
Where does this information come from? (What component initially creates it)
Who uses this information inside & outside of ONAP? How do they use it?
Includes description of information consumed (whole class, specific attributes, etc.)
Main components affected are: PRH (PNF Registration Handler for PnP), DCAE, OOF SON PCI (Use Case) Micro-service | |||||||||||||||||||||||||||||||||||||||||||||||
| Related JIRA |
| ||||||||||||||||||||||||||||||||||||||||||||||
Description | The development of the PLACE object will introduce the ability to associate generic "place" (location) information to xNFs. The root model wiki: Root
The recording, meeting minutes and discussion pages for model development are here: PNFD/SDC AID/AAI Schema Modeling/5G Svc Model - R7 Discussion | ||||||||||||||||||||||||||||||||||||||||||||||
Related Standards & Industry Activities | Related Industry Standards are here:
| ||||||||||||||||||||||||||||||||||||||||||||||
Attributes | The fields are described here in this document: PNFPlaceModel_202007Jy02.xlsx
| ||||||||||||||||||||||||||||||||||||||||||||||
Relationships | RUN TIME - (PNF Plug and Play Use Case). PNFs instantiates need to be related to Place instances. Note: the VNF instantiation process already points to the Complex object. RUN TIME - (OOF SON PCI Use Case) - The PCI Micro-service to point the Cell recording (in the C&PS DB) to associate with Place instances. | ||||||||||||||||||||||||||||||||||||||||||||||
Originator | DESIGN TIME - Services are designed with resources (xNFs). xNFs would associate with PLACE information during Run-Time. Cells (logical objects) in C&PS DB would associate with the PLACE information. RUN TIME - (Plug and Play Use Case) Service & Resources (PNFs) are instantiated. PNF registers itself with ONAP. At the point of registration PLACE information is set. The PNF instance needs to "point" the Place instance. SO BPMN/WF/BB need to create an instance of the Place object for the PNF to "point to" during registration. RUN TIME - (OOF SON PCI Use Case) - Logical objects, cells associated with the PNF will set PLACE information. During run-time, the PCI Micro-service to point the Cell recording (in the C&PSDB) to associate with Place instances. | ||||||||||||||||||||||||||||||||||||||||||||||
| Consumers | PNF Plug and Play Use Case (Inside ONAP) - The Plug and Play use case describes the process that a PNF performs when it tries to register with ONAP. This means that during installation & commissioning, ONAP needs to set the PNF Place information. This would likely not be reported by the PNF itself, but would be cross-correlated with the PNF resource instantiation during SO BPMN/WF/BB execution. OOF SON PCI Use Case (Inside ONAP) - The OOF SON PCI Use Case is an existing Use Case that was started in R3 Casablanca. It has continued to develop throughout R4, R5 and R6. This Use Case is all about PCI location and cell location. Which requires location and place information to be associated with the cell logical object. External Apps tracking location (Outside of ONAP to External APIs) - (Future). Analytical post-processing applications use geographic information. RF planning & optimization, RF maps would use geographic information. This is used to setup a wireless network. Once place information is stored about PNFs there are existing external systems that would use this information. | ||||||||||||||||||||||||||||||||||||||||||||||
Producers | PNF Plug and Play Use Case (Inside ONAP) - This would likely be updated during PnP registration for the PNF resource instantiation during SO BPMN/WF/BB execution. OOF SON PCI Use Case (Inside ONAP) - This information is updated when the PCI micro-service executes. It needs to know about neighbors and cell geographic locations. When setting up its data it needs to know the relative geographic location of cells. Note: this is also captured in the Neighbor Lists. Who updates this information inside & outside of ONAP? Under what conditions do they update it? Includes description of information produced (whole class, specific attributes, etc.) | ||||||||||||||||||||||||||||||||||||||||||||||
Steward |
Where will this information stored and maintained in ONAP?
PNF Plug and Play Use Case (Inside ONAP) - The Geo-location information should be captured in an instantiation of the PLACE object. The PNF instance should associated with the PNF object instance. Instance of the place object would be in A&AI or C&PS DB. OOF SON PCI Use Case (Inside ONAP) - The geolocation information should be captured in an instantiation of the PLACE object. The PNF instance should associated with the Cell object record instanced used by the PCI Micro-service. Stored in the C&PS DB. Instance of the place object would be in A&AI or C&PSDB. NEEDS UPDATE | |
| Impacted APIs & Schemas | PNF Plug and Play Use Case (Inside ONAP) - The SO API for BB should be impacted. The C&PS API (A&AI API) will be impacted. OOF SON PCI Use Case (Inside ONAP) - The C&PS API (A&AI API) will be impacted, which is where the PCI Use Case stores information. Ext-API - would be impacted as well to allow external entities to access the place information. Service inventory. Identify impacted ONAP schemas & APIs Are there existing schemas be used or extended? |
Information Modeling Status |
This is |
scheduled in the R7 Modeling planning page. The Wiki page: ONAP R7 Modeling High Level Requirements It is being tracked by the Modeling-368 Jira which can be found here:
Status: It is active for the current release, the PnP use case has been accepted. The model is being developed. | ||||||||
Schema Definition Status |
What is the status of ONAP Schema Definition activities associated with this Information Element.
Please provide links to relevant wiki pages & JIRANot started, the Place object first needs to be defined. when A&AI would be updated, the schema proposal would be drafted. |
ONAP Release Priority |
R6 Frankfurt - Experimental model introduction of Place Object was introduced by Kevin Scaggs R7 Guilin - Model introduction of Place should be developed. in the R7 planning page: Guilin Release Requirements , the Modeling-368 is under REQ-318 and TSC Priority 0 "Go" |