1. Pages
2. …
3. Open Transport Configuration and Control Home
4. 5G-xHaul
5. 5G-xHaul Call-in Details & Notes

2018-03-13 - 2018-03-15 F2F WT Meeting Notes

• See Notes in OTIM web page: 2018 March 12 - 16 OIMT & OTCC Interim Meeting Minutes
• High Level overview of the WT activities: WT Activities.pptx
• Touch points between WT and OTIM/OTCC:
• Sync model (specific session planned during this F2F meeting)
• Ethernet model
• Controller model

Synchronization topics (Joint meeting)

• Respect to synchronization topics:
  • a model, based on Core model, for managing both synchronization and PTP (1588v2) is part of the ITU-T Gsyncmgmt: oimt2018.LS.006.00_g.sync-mgmt_v0.05
  • This model can be considered a reference for the synchronization implementation in microwave products, and needs the implementation of the Core Model 1-3
  • As reference: 2018 March 12 - 16 OIMT & OTCC Interim Meeting Minutes

• Introduction to the team of the actitvities on DMIP (the specific aspects will be discussed in the specific sessions)

 open issues of TR-532 for R.1.1 (James lead)

James Ries

Daniela Spreafico

• Input presentation: TR-532-1.0-OpenIssuesEd01.pptx
  1) Discussion about #24: Netconf requests to configure a link bundling
• proposal#1: to add different radio members to the same LAG group with a single 'edit' command (segmetIDList) where the Uid of the 'structures' to be added are indicated
• • proposal#2: have in a single transaction the modification of the client/layer relationships and the deletion of the ethernet containers that are no more needed; in case of usage of candidate database this applies to the 'commit' action that needs to be applied when all the changes have been done

--> working assumption to accept the proposal#1 (if this works also in case of candidate database - to be checked offline after the F2F meeting)

2) Discussion about #25: Space Diversity enhancement:

• • • when radio is equipped with single transmitter and 2 receivers

    • two possible solutions presented in the proposals

    • decision to stick with the 'solution 2' with 2 airInterface and to work to a 'clean' solution to introduce unidirectional objects; this would cover the case of space diversity and future scenarios of P2MP

    • the  proposal would be that the new solution would be added to the current one (possibly marked as 'deprecated')
    • in order to start this analysys it is needed to go through the model and identify the parameters that are applicable to TX and RX

3) Discussion about #29  Expected Radio Signal Identifier:

• • • this point is related to the fact that the model is bidirectional
    • this point can be either addressed together with the previous point #25 and would be solved in case of unidirectional model is implemented or can be addressed already for the bidirectional case. 
    • It is decided to address in the current model and to add to the model a value for expectedSignalID, transmittedSignalID, receivedSignalID (status report) and mismatch alarm; this will imply as well to deprecated the current 'radioSignalID'
    • It should be possible to disable the feature inserting a default value (0)
    • Consequent actions in case of mismatch needs to be also defined

PoC5 Use cases and organization (Giorgio lead)

• Input document: PoC5 discussion.pptx
  1) Discussion about topics for the PoC:
  • mediator management interface: proposal is to define the management interface for mediator and to show first implementation in the 5th PoC:
    • first step would be the review of definition of the management interface model
    • it is requested to produce also some use cases for this application
    • specific application on SDN Controller will take care of mediator control
  • request from Telefonica to add as a potential candidate for PoC 5 the L3VPN topic (open to router vendors or MW vendors implementing the functionality); existing models have been reviewed and activity is ongoing in Telefonica to complete and restructure the model
  • in the same event of 5th PoC the optical disaggregated network use cases will be also shown
  • Core model 1.3.1: the alignment with 1.3.1 respect to 1.2 means the reimplementation of the MW model (due to the changes in the basic structures):
    • this would allow to have a generic model to attach new functionalities to the core model through conditional package;
    • note that the UML to Yang tool for generating the yang file for this new model will require some modifications on the UML for MW
    • from content point of view, the synchronization topics will be the aspects that will strictly require the 1.3.1 model (so if staying with 1.2, the option would be to show what was shown in the PoC 4 or some use cases over the same architecture/model)
    • working assumption for MW: stay with 1-2
  • MW model (TR-532 1.1): this discussion is deferred when the content of the 1-1 will be agreed
  • ODL version: "Nitrogen' aligned with the version of ODL integrated as well in ONAP (Bejing)
  • Distributed / Cloud architecture: combination of participants on site and connected to other SDN controllers (eg DT cloud) will be in the scope of the PoC 5
  • Updated document after discussion: PoC5 discussion.pptx

Device Management Interface Profile and Requirements (Thorsten lead)

• Input document: 180311_DMIP_TR-545_v0_2.docx
• Documents discussed during the meeting:
  • 180311 DMIP on f2f.pptx
  • 180315 DMIP Open Issues.xls
• For the discussion about "Relevance of IETF RFC 8071 (Netconf/Restconf Call Home)" a dedicated meeting/call needs to be organized (see DMIP action item)
• Action to Thorsten Heinze for adding factory setting for alarms in TR-532

ONAP Use cases and Next Integration steps (with remote participation from AT&T)

• Join ONAP SDN-R weekly call
  • See minutes in SDN-R wiki: https://wiki.onap.org/pages/viewpage.action?pageId=25441220
  • Presentation of ONAP PNF Plug&Play: https://wiki.onap.org/download/attachments/10784151/PNFPlugnPlay_19Feb2018v14.pdf?api=v2  
  • Discussion around 5G Use cases: https://wiki.onap.org/display/DW/Use+case+proposal%3A+5G-+RAN+deployment%2C+Slicing%2C+SON 

• Overview of ITU-T model (based on Core Model) for synchronization (syncE + PTP) has been provided

James Ries

Daniela Spreafico

Continuation of the discussion about open topics for TR-532:

4) Discussion about #30  Performance Monitoring – Activation/Deactivation + Issue # 33  Performance Monitoring – Threshold Data Association

#30: The request is to allow this activation/deactivation adding the administrativeControl to AirInterfaceCurrentPerformance class or similar attribute.

#34: proposal to manage the thresholds for performance monitoring counters

Proposal is to have inside airInterface, Structure and Container classes (where applicable) an attribute (in a new class 'management') that allows to perform activation, threshold, etc.:

Management

   - PM Control:

• • • on/off

• 15 min
  • Threshold per PM Counter
• 24 h
  • Threshold per PM Counter

Agreed to prepare a proposal, for inclusion in TR-532, but at the same time to submit this model proposal as well to the OTIM team for inclusion in the Core Model that is not currently supporting this capability

Granularity: per current Performance (not per counter)

Action Point to Martin/Daniela to formalize the proposal as agreed here

5) Issue # 31  Performance Monitoring – Adaptive Modulation

The current ONF TR-532 1.0 model doesn’t foresee on AirInterfacePerformanceType the dedicated attributes for ¼ BPSK and ½ BPSK modulation value as for the other modulations (like time2States and so on), to report the time the radio interface (MW-AirInterface_Pac instance)  stays on ¼ BPSK or on  ½ BPSK modulation values.

The request is to manage also these counters.

Discussion:

• • The triple (Channel bandwidth, modulation scheme, coding) defines the characteristics of the channel; adaptive modulation is so that one or more parameters of the triple is changed in case of conditions of the channel changed
  • There should be the possibility to express in the performance data the counters for the meaningful triple
  • In performance data, the adaptive modulation performance values could be a list of the new data type, where there will be a reference to the triple ID + number of seconds; in this way it would be flexible enough to follow the capability of the equipment

 Action to Danilo and Thorsten to formalize the proposal for the model

The remaining open issues not discussed will be put in the agenda of the coming WT calls

Device Management Interface Profile and Requirements (Thorsten lead)

The following items are in the agenda for DMIP related topics:

• optional component of RFC4253 (SSH)
• AP Thorsten to prepare a proposal for such non mandatory parameters
• minimum performance requirements: discussion about inserting in the document absolute values; we need anyway a reference architecture where the performances need to be measured (AP Wolfgang/Michael to provide an input for this on mediator)
• performance test environment
• mediator resource consumption
• consumption test environment

Additional proposal (new): adding to URL to the model - this would allow the possibility from the vendor to provide additional information or documentation on server and allow network elements to access the server; this needs analysis of archtiecture and check from vendors. This will be put on the table on next meetings

Additional discussion: respect to the sentence "Missing, unplug or out-of-operation hardware (e.g. boards) cannot be successfully configured" in section 21 of DMIP proposal, there is consensus to modify the sentence, in order to accept the configuration even if the HW is not present

• it has been also indicated the 'operational state' added to the transmission resources, as a way to manage the situations where the configuration is ok but the service is not active due to hw failures for example

• SDN Controller redundancy: technically viable with SDN federation, already tested initially in the PoC 4-1
  • use case detailed analysis to be performed
  • failure situations and conditions need to be identified
  • this is general use case (not applicable only to MW)
  • we can address in PoC 5 but we need to go in details of what is needed and the behaviour associated
• Overall review of the PoC 5 content after F2F meeitng: PoC5 discussion FINAL.pptx
  (this contains considerations and actions to be addressed in the next WT calls)

• Cooperation with ETSI mmW (with reference to SDN Plugfest): target of this is northbound interface so not southbound interface, but it could be interesting to inform ETSI about the PoC intiative to verify possible interest
• When new version of TR-532 will be issued information liason to IETF CCAMP may be issued