- Discuss PNFD/SDC AID/A&AI Schema Mapping - Action Items and Geolocation
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.
|GEO-LOCATION STANDARDS (RFC 6225 into ETSI SOL 001)|
Add Geolocation RFC6225 as new Element in 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.
CONTACT: Thinh, Anatoly (Nokia), Who from Ericsson?
ACTION: Aug22 have contacted Thinh N. (Nokia); Ericsson contact?
|COMMON LOCATION MODEL|
Alignment to various standards: MEF/SID/Sonata. ITU-T. 3GPP TS32.xxx. IETF. MEF.
|TMF / SID|
(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:
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: TMF standards
|COMPLEX OBJECT OWNER|
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?
CONTACT: (Identify contact). “What field” (semantical descriptor/association)
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
Add informational table for the Geolocation fields from RFC6225. (CLOSED) – see table on slide 22.
ACTION: Fill in tie-in fields to standards elements
|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.
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.
CONTACT: 5G Use Case Vimal & Use Case S/C Alla G.
ACTION: (wait to resolve some of the above item)
|NEXT MEETING||Thursday Sept 5 2019|
Zoom Video / Audio