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 Information Modeling Contact - Benjamin Cheung , Jacqueline Beaulac Schema Definition Contact - Benjamin Cheung , Jacqueline Beaulac | ||||||||||||||||||||||||||||||||||||||||||||||
| Related Use Cases | The Place object for PNFs will first be used in R7 by the OOF / SON / PCI Use case WIKI 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 | Main components affected are: PRH (PNF Registration Handler for PnP), DCAE, OOF SON PCI (Use Case) Micro-service | ||||||||||||||||||||||||||||||||||||||||||||||
| Related JIRA | MODELING-368 - Getting issue details... STATUS | ||||||||||||||||||||||||||||||||||||||||||||||
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 | 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: MODELING-368 - Getting issue details... STATUS Status: It is active for the current release, the PnP use case has been accepted. The model is being developed. | ||||||||||||||||||||||||||||||||||||||||||||||
Schema Definition Status | Not 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" |
