PNF: PnP - PNFD/SDC AID/AAI Schema Modeling - Discussion Oct 3 2019

Owned by Benjamin Cheung
Last updated: Oct 07, 2019
5 min read

Date

Attendees

Goals

  • Discuss PNFD/SDC AID/A&AI Schema Mapping - Action Items and Geolocation

Discussion items

TimeItemWhoNotes

MULTI-LANGUAGE

SUPPORT


LANGUAGE – Check on representation of location for Non-western Languages & scripts. Civil address specify in the data. How would A&AI represent addresses but expressed in different language. Store the address with way to designate language type. Relevant only if SP deals with more than one language at a time.

  1. MULTI-LANGUAGE (VID/ Ittay Stern) – There is no plan for VID to support multi-language functionality.
  2. MULTI-LANGUAGE (PORTAL/Manoop) – Portal Already Supports Multi-language Support portal-multi-language.pptx
  3. MULTI-LANGUAGE (UUI/ Tao) – Multi-language support will be supported by UUI project (was first developed in R4/ Dublin)
  4. MULTI-LANGUAGE (SDC/ Ofir) – There is no plan for SDC to support multi-language functionality.

DEVELOPMENT OF PLACE OBJECT

Development and incorporation of TM Forum Standard GB922 models into ONAP.

MEF core model.

This will be worked as the GEOLOCATION Modeling work in the R6 Modeling HLR: ONAP R6 Modeling High Level Requirements

Additional fields (low level fields) - consider context of how ONAP would use the information; it is unlikely that some of the lower level fields will be useful. (e.g. Cubicle, workstation level). Potentially rack information; equipment model IETF in M3100 stored on the Managed Element attribute.

Wiki page: Root (Root Model object)

ACTION: Investigate how to incorporate into the Modeling work S/C. As common model. Kevin will draft a proposal.

ACTION: How would this tie into the complex object or link/associate with the complex object.


GEO-LOCATION STANDARDS (RFC 6225 into ETSI SOL 001)

STEP 1: INPUTS - Inputs for place location

STEP 2: DEVELOP LOCATION CLASS FOR ONAP - Once we complex / place location object should

STEP 3: ETSI SOL001 - work with ETSI to incorporate it into ETSI SOL 001. Contact the representatives working the ETSI SOL 001 standards and see if we can add a Geolocation element to the existing civic_address_element.

ACTION: Aug22 have contacted Thinh N. (Nokia); Ericsson contact? Thinh RESPONDED to bring it up at the Modeling Call. RESULT: Oct 3 Need to show in ETSI that there is a need for it. Need to understand what the ONAP need is. Geoloc harmonization standards would go back to ETSI SOL001.


COMMON LOCATION MODEL  / GB922

TMF (TM Forum) / SID


Alignment to various standards: MEF/SID/Sonata. ITU-T. 3GPP TS32.xxx. IETF. MEF.

GB922 - Location Modeling Discussion

(Email) Keong Lim For your investigation into the location attributes, I wonder if you’ve considered what is in the TMF SID, specifically the classes for Urban Property Address and Urban Property Sub-Address as per:

https://www.tmforum.org/resources/suite/gb922-information-framework-models-r18-5/

From previous work on inventory systems, I know that these classes and properties have been implemented and used, so they would be useful for integration with AAI, even though there might not be an ONAP use case that documents the specific usages. Unfortunately, I cannot find my downloaded copy of the framework to send you, but you may be able to obtain it yourself through the website (needs a login).

ACTION: Retrieve GB922 (DONE)


COMPLEX OBJECT w/ PLACE-LOCATION OBJECT

Find out who the principle subject matter expert (SME) or contact for the Complex Object is. Would changes to the complex object be easy? Are they already being used throughout the source code? Would they be Schema breaking changes?

Honor what has already been done in Complex Object.

Take what is more data-center focused.

Introduce new attributes as necessary.

Info Model - Data model Map between.

CONTACT: (Identify contact). “What field” (semantical descriptor/association). ANSWER: A&AI Team.


COMPLEX OBJECT UPDATES FOR GEOLOCATION INFO


– There are a number of A&AI Complex geolocation information that are driven by the ETSI NFV Geolocation RFC 6225 that we need to investigate how they are acquired or set in DHCP. And once point #2 is solved, mapping those to the appropriate complex object elements.

CONTACT: Jimmy Forsyth

RESULT: (Oct 3) - Ben was on A&AI (Oct 2) Jimmy said that Complex Object is rooted and entwined in the code so it would be very hard to redact it; it would be smarter to evolve. Need to understand how to tie place into the complex object, maybe complex could be subobject of place. Jimmy also mentioned that the Place & complex could be linked together. That might be a solution/way forward. Maybe complex would be a subobject to place if there is overlap in fields & concepts.


RFC6225 GEOLOCATION FIELDS

Add informational table for the Geolocation fields from RFC6225.  (CLOSED) – see table on slide 22.

ACTION: Fill in tie-in fields to standards elements

Description

Latitude Uncertainty - When the Ver field = 1, this field represents latitude uncertainty. Uncertainty = 2 ^ ( 21 - x ). x = 21 - ceil( log2( uncertainty ) )

Latitude – Latitude in binary geodetic form. A 34-bit fixed-point value consisting of 9 bits of integer and 25 bits of fraction.

Longitude Uncertainty - When the Ver field = 1, this field represents longitude uncertainty. Uncertainty = 2 ^ ( 21 - x ). x = 21 - ceil( log2( uncertainty ) )

Longitude – Longitude in binary geodetic form. A 34-bit fixed-point value consisting of 9 bits of integer and 25 bits of fraction.

Altitude Uncertainty - When the Ver field = 1, this field represents altitude uncertainty.

Altitude – A 30-bit value defined by the Altitude Type field

Altitude Type – (1) Altitude in Meters, (2) Altitude in Floors. 1 (indicates Altitude in Meters)

Altitude Resolution - value encodes the number of high-order altitude bits that should be considered valid

Map Datum - The Map Datum used for the coordinates given in this option: WGS84, NAD83 + NAVD88, NAD83 + MLLW. 2 (Indicates NAD83+  NAVD88)


ALIGN SOL001 & A&AI

There are 12 elements from the civic_address_element that do not map “nicely” to the complex elements fields. These are notably: division, block, street group, additional loc info, residence name, unit, floor, room, postal name, PO box, additional Code, seat/cubicle. We need to decide if we wish to intentionally not map these or introduce new fields into the complex object. Note this item is dependent on a number of above items being solved first.

ACTION: Analysis to complex object. If what’s in complex object is sufficient and raise at the modeling and second opinion. (1) Internationalize the complex object, IETF 4776. (2) resolution. Maybe generalize the country/regional specific location elements. as a discussion group, discuss the model; for the missing field would have to show that there is a need within ONAP; is there a ONAP requirements for those item. Is there another attribute that covers that or is it something new that needs to be added. a Topic in Common. If the discussion would is good with it discuss it in Poll.

RESULT: (Oct 3) should be covered with the analysis & development of the PLACE & Complex object (see above)


TIMETABLE (WHEN TO INTRODUCE)

Investigate when these would be really necessary. Are they needed in R6? Our discussion today (educated guess) is that they will be needed probably a release or two AFTER an actual, real physical DU is integrated with ONAP.

No code changes being requested in R6; but will likely need S/W changes in R7.

ACTION: R6: OUTPUT in R6 - Need to document what S/W and U/C (PnP) impacts that there will be. Schema impacts, API changes, and consumers of the API impacts.


NEXT MEETING

PRESENTATIONS

DescFile
discussion slides (updated Sept 5)

RECORDING

RecordingFile

Zoom Video / Audio

MP4

Audio Only

M4A

Playback M3U

  •