Due to a ransomware attack, the wiki was reverted to a July 2022 version. . We apologize for the lack of a more recent valid backup.

 | 3am PDT | 6am EDT | 10:00 UTC | 10:00 GMT | 11:00 CET | 12:00 EET | 15:30 IST | 18:00 CST | 19:00 JST |

Web Conference:



(please feel free to correct and update your names (wink) Thank you very much!!!) 

Info to: 


  • going forward

Discussion items

00:00chair topic 
no update 


Daylight savings start in most parts of Europe 2021-03-28 

proposed times for next week onwards

| 2am PDT | 5am EDT | 09:00 UTC | 10:00 BST | 11:00 CEST | 12:00 EEST | 14:30 IST | 17:00 CST | 18:00 JST |



Next meetings

2020-03-31: Martin Skorupski

2020-04-07: Martin Skorupski

2020-04-14: Martin Skorupski

2020-04-21: Martin Skorupski



Thorsten Heinze
@Eduardo Yusta

UML and YANG are out for review


  • Request for approval for integration into TR532.

Last minute questions:

  • about  ‘firmware-component-activation-date’: if the ‘firmware-component-list’ instance has been activated using the upper ‘firmware-component-list’ (with ‘firmware-component-class = Package), what has to be the content of this attribute? The same as reported on upper ‘firmware-component-list’ or a default one?

[sko] same as on the upper - no updates needed. 

  • About ‘related-kinds-of-equipment-list’ (in capability container):  perhaps I missed something in our last meeting.

The Description reports   "... Values should be identical with entries in Equipment::ManufacturedThing::EquipmentType::modelIdentifier attribute. Might be empty, if firmwareComponentClass==PACKAGE.";

Does ‘EquipmentType’ mean something already present on an instance of Equipment ? And if not yet configured ? Do you mean that when the associated Equipment instance is created the capability container has to be updated?

[sko] no - values was known in advance

And what about to have an EMPTY list?[sko]  nothing special  No problem on RESTCONF?

[sko] no - the attribute is not showing up in NETCONF.

  • For each  ‘firmware-component-list’ instance the ‘subordinate-firmware-component-list’ reports all the ‘firmware-component-list’ instances associated to.

And for the contrary?

To understand if a ‘firmware-component-list’ instance is part of an upper  ‘firmware-component-list’ instance’ it is needed to pass all the ‘firmware-component-list’ instances to find it on a ‘subordinate-firmware-component-list’. Is it fine for an application layer?

[sko] yes – it is fine – we discussed and wanted to avoid references in two direction.

  • activation-available

Which is the expected value for the "package"? 

Answer: Value should be "true"

  • firmware-component-status

What is the expected value for the "boot-component"?

Answer: in the discussed use case it should be "active", because it was active in the last boot process. 

Any objections?

  • no objection, but one abstain

>> Accepted - The FirmwareModel should be integrated into TR532. Thanks a lot!

Next steps?

  • combination with other Interface update - compilation of a new document later. 
00:40AirInterface Issue #36

Different multiplicity at problemKindSeverityList and supportedAlarmList

  • Request for approval to as proposed.

Any objections?

  • no objections → accepted

Next steps?

  • UML and YANG to be updated
00:35AirInterface Issue #37Thorsten Heinze

Scope of transmission-mode-list/xpic-is-available?

  • Continue the discussion about the proposed solution

Proposal made - review starts - approval for 2021-04-07 expected. 

End of the meeting

00:xxAirInterface Issue #41

XltsThresholdCrossAlarmType::xltsLevel should have a default value

  • Request to agree on meeting at 31-03-2021
  • Any objections so far about the proposed solution?

AirInterface Issues 

22, 23, 24, 25, 26, 27, 28, 30 and 32

xlts-threshold-cross-alarm-list: Threshold cannot be identified if being changed

  • intent to close issues are they are for all the listed issues. 

Action items