Child pages
  • 2018-03-13 - 2018-03-15 F2F WT Meeting Notes
Skip to end of metadata
Go to start of metadata


13 March 2018


(1) Day 1 only

(2) remote participation

(3) partially


Discussion Items

Tuesday 13 March 2018 morning sessionJoint meeting with OTIM and OTCCall team
Tuesday 13 March 2018 afternoon session

Synchronization topics (Joint meeting)

all team
Tuesday 13 March 2018 afternoon sessionDMIP (Joint meeting)Thorsten Heinze
  • Introduction to the team of the actitvities on DMIP (the specific aspects will be discussed in the specific sessions)
Wednesday 14 March 2018 morning session 1

 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
Wednesday 14 March 2018 morning session 2

PoC5 Use cases and organization (Giorgio lead)

Giorgio Cazzaniga
  • 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
Wednesday 14 March 2018 afternoon session 1

Device Management Interface Profile and Requirements (Thorsten lead)

Thorsten Heinze
Wednesday 14 March 2018 afternoon session 2

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

all team
Wednesday 14 March 2018 afternoon session 3Synchronization topicsGiorgio Cazzaniga
  • Overview of ITU-T model (based on Core Model) for synchronization (syncE + PTP) has been provided
Thursday 15 March 2018 morning session 1open issues of TR-532 for R.1.1 (James lead)

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.:


   - 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.


    • 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

Thursday 15 March 2018 morning session 2

Device Management Interface Profile and Requirements (Thorsten lead)

Thorsten Heinze

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
Thursday 15 March 2018 afternoon sessionRemaining points on PoC 5 
  • 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)
Thursday 15 March 2018 afternoon sessionPossible cooperation with other standard bodies 
  • 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

Action Items

    • Giorgio Cazzaniga: develop a slide to be presented by ONF at the ONS, regarding the 5th PoC
    • As WT team we need to understand the relationships with 3GPP for what is concerning the management architecture for 5G
    • Contribute to examples of usage of Core Model with WT cases
    • in order to start analysys of undiirectional airInterface model it is needed to go through the model and identify the parameters that are applicable to TX and RX
    • Thorsten Heinze to circulate mediator interface definition proposal and use cases
    • Action to Thorsten Heinze for adding factory setting for alarms in TR-532
    • Action Point to Martin/Daniela to formalize the proposal for PM Control
    • Action to Danilo and Thorsten to formalize teh proposal for the model for performance monitoring / adaptive modulation
    • Action to Wolfgang/Michael to provide an input for performance measurement methodology on mediator