1. Issues to extend
TR-532 mw model

2. Issues Summary Mantis ID # Summary Priority 24
Netconf requests to configure a link bundling (multi-radio)
High 25
Space Diversity enhancement 29
Expected Radio Signal Identifier 30
Performance Monitoring – Activation/Deactivation 31
Performance Monitoring – Adaptive Modulation 26
Minimum Power on ATPC
Medium 27
1+1 HSB - Driving Criteria in Adaptive Modulation 28
1+1 HSB - Driving Criteria in ATPC 32
Performance Monitoring - Radio (G.826) and RSL data counters on Link base (1+1) 34
MW Ethernet Statistics 33
Performance Monitoring – Threshold Data Association
Low 35
Net Bandwidth / Operative Bandwidth
Topology (Split-mount, Full outdoor, …)
IDU, Radio types?
Market?
Green field or upgrade?
Limitations?

3. Issue # 24 Netconf requests to configure a link bundling (multi-radio)
Description of the problem (1)
The need is to create a Radio Link Aggregation (or Link Bundling) through NetConf client.
The following is the picture of all the entities involved before of the Radio Link Aggregation creation.
There are 4 radio equipment configured on Slot S, Port1 to Port4 working in 1+0:
4 MW_AirInterface_Pac instances
4 MW_PureEthernetStructure_Pac instances
4 MW_EthernetContainer_Pac instances
Each MW_AirInterface_Pac is associated to own MW_PureEthernetStructure_Pac using also the client-ltp and server- ltp attributes
The same for MW_PureEthernetStructure_Pac and own MW_EthernetContainer_Pac
All these entities are created by the NetConf agent when the HW radio equipment are configured on 1+0 on the device. .
Topology (Split-mount, Full outdoor, …)
IDU, Radio types?
Market?
Green field or upgrade?
Limitations?

4. Issue # 24 Netconf requests to configure a link bundling (multi-radio)
Description of the problem (2)
The following is the picture of all the entities involved after the Radio Link Aggregation creation (through Local Manager). .
The Radio Link Aggregation is aggregating 4 radio equipment configured on Slot S, Port1 to Port4:
4 MW_AirInterface_Pac instances
4 MW_PureEthernetStructure_Pac instances
1 MW_EthernetContainer_Pac instance
Each MW_AirInterface_Pac is associated to own MW_PureEthernetStructure_Pac using also the client-ltp and server-ltp attributes
The same for the association between all the MW_PureEthernetStructure_Pac and the only MW_EthernetContainer_Pac
The change on the entities between Figure 1 and Figure 2 is performed when a Radio Link Aggregation (or Link Bundling) is created and each radio HW member is added to.
Topology (Split-mount, Full outdoor, …)
IDU, Radio types?
Market?
Green field or upgrade?
Limitations?
Actually the Radio Link Aggregation is created (and members added to) through Local Manager (SNMP or http).
The problem is how to perform this change through NetConf interface using an atomic command .

5. Issue # 24 Netconf requests to configure a link bundling (multi-radio)
Concrete Solution (1)
To create the Radio Link Aggregation :
a single ‘edit-config’ command (‘create’ operation) to create a new instance of MW_EthernetContainer_Pac with specific uuid = “LTP-ETC-LAG#<x> (<x> is an arbritary number provide by operator ) and no segmentsIDList instance on _ethernetContainerConfiguration (that’s no radio members).
To add a Radio member to a Radio Link Aggregation, the idea is to have only a single and complete Netconf command, that as a consequence implies several steps to be automatically done by the Netconf server in the device.
Topology (Split-mount, Full outdoor, …)
IDU, Radio types?
Market?
Green field or upgrade?
Limitations?

6. Issue # 24 Netconf requests to configure a link bundling (multi-radio)
Concrete Solution (2)
  For this purpose the following sequence is proposed to be executed after creating a new EthernetContainer pac for the link bundling configuration:
a single ‘edit-config’ command (‘create’ operation) shall be used for creating a new instance in the segmentsIDList attribute in the _ethernetContainerConfiguration of the MW_EthernetContainer_Pac of Radio Link Aggregation (that created on step 1, uuid = LTP-ETC-LAG#<x>). The segmentsIDList attribute is of SegmentIDType data type. The SegmentIDType data type contains the structureIdRef attribute and the segmentIdRef attribute. The structureIdRef attribute has to be filled with the uuid of the PureEthernetStructure_Pac of the air Interface, which is to be added to the link bundling. The segmentIdRef attribute has to be filled with the highest segment number of the referred structure (would be "0" in case of a PureEthernetStructure).
As a consequence, on receiving the ‘edit-config’ of step 2 , the NetConf agent on the device has to remove automatically the EthernetContainer pac (uuid = LP-ETC#<SP>) associated to a physical port.
The Netconf server in the device shall also automatically update the client and server attributes within the ltp classes of the container and the structure.
Topology (Split-mount, Full outdoor, …)
IDU, Radio types?
Market?
Green field or upgrade?
Limitations?

7. Issue # 25 Space Diversity enhancement
Description of the problem
The need is to manage Space Diversity configuration where a radio equipment is hosting 1 transmitter and 2 receivers
The main features requested are:
reporting the capability of the support of SpaceDiversity (Combiner) on the radio equipment (according to HW availability);
enable/disable the SpaceDiversity feature (if there is the capability);
activate/deactivate the main or the diversity receiver;
reporting the current received signal of main and diversity receiver
reporting on the Performance Monitoring data the received signal of main and diversity receiver (min, max and average)
configuration of radio parameters only at radio equipment level.
On the current ONF TR model the management of this Space Diversity arrangement is not suitable using a single MW_AirInterface_Pac instance.
Topology (Split-mount, Full outdoor, …)
IDU, Radio types?
Market?
Green field or upgrade?
Limitations?

8. Issue # 25 Space Diversity enhancement
First Solution
To use only a single MW_AirInterface_Pac instance and to extend ONF TR (MW model) as in the following:
new attribute combinerCapability (true/false) to AirInterfaceCapability class. True in case the Diversity receiver is present on radio equipment, false otherwise.
new attribute combinerControl (true/false) to AirInterfaceConfiguration class to enable/disable the Diversity feature (if combinerCapability true).
new attribute receiverDivIsOn (true/false) to AirInterfaceConfiguration class to activate/deactivate the Diversity receiver (at least, one of the 2 attributes receiverIsOn receiverDivIsOn, related to Main receiver, has to be true).
new attribute rxDixLevelCur to AirInterfaceStatus class to report the current signal received on the Diversity receiver.
new attributes rxDixLevelMin, rxDixLevelMax, rxDixLevelAvg to AirInterfacePerformanceType to report the value of Performance Dara referring to Diversity receiver .
 Pro: - all the needed features are managed;
- the radio parameters configuration is only one set addressed to the only existing MW_AirInterface_Pac instance.
- the receiver status and Performance Monitoring n ew data are only that needed (no data duplicated).
Cons: need to add new attributes.
Topology (Split-mount, Full outdoor, …)
IDU, Radio types?
Market?
Green field or upgrade?
Limitations?

9. Issue # 25 Space Diversity enhancement
Second Solution (1)
To stay with the current MW model using 2 MW_AirInterface_Pac instances , one with transmit and receiver capablities (lpDirection = bidirectional ?) and a second one with receiver capabilities only (lpDirection = sink ?) and one AirInterfaceDiversity_Pac associating these 2 airInterfaces. 1 mwStructurePac is in any case used to address a 1+0 radio configuration.
In any case something is missing:
the reporting of the Diversity capability (perhaps using the AirInterfaceDiversity_Pac instance created when HW Diversity is present ?))
the enabling/disabling of the feature (once the capability is there). Perhaps a new attribute (combinerControl) on AirInterfaceDiversity_Pac is needed.
Topology (Split-mount, Full outdoor, …)
IDU, Radio types?
Market?
Green field or upgrade?
Limitations?

10. Issue # 25 Space Diversity enhancement
Second Solution (2)
Pro :
only few attributes (or none) to add to the MW model (on AirInterfaceDiversity_Pac )
activation/deactivation of each single receiver already there.
Report of the receiver status and Performance Monitoring new data already there.
Cons:
Duplication of radio parameters (that have to be common) on 2 MW_AirInterface_Pac instances ; how to manage it? Check on the device or on the manager?
Duplication of transmit status and Performance Monitoring data common to MW_AirInterface_Pac instances (es, ses..).
Over the transmit and receiver functions , the radio equipment includes common part like Dem function: in case of problems raised on this function (DEM fail), on which MW_AirInterface_Pac instance could be addressed an alarm?
Topology (Split-mount, Full outdoor, …)
IDU, Radio types?
Market?
Green field or upgrade?
Limitations?

11. Issue # 29 Expected Radio Signal Identifier
Description of the problem
Radio Signal Identifier is managed on the ONF TR in bidirectional mode (expected identifier = sent identifier), configuring a single attribute (radioSignalId).
The request is to allow the configuration of 2 radio signal values , one as sent value and a second one as expected value.
The proposal is to add a new attribute for the expected value (expectedRadioSignalId) on the AirInterfaceConfiguration class.
The radioSignalId already present will be used as sent-value.
This is according to ITU-T REG , including trace identifier mismatch (TIM) alarms
Topology (Split-mount, Full outdoor, …)
IDU, Radio types?
Market?
Green field or upgrade?
Limitations?

12. Issue # 30 Performance Monitoring – Activation/Deactivation
Description of the problem
With the ONF TR model the CurrentPerformance class cannot be activated/deactivated separately from the associated *_Pac .
For example the AirInterfaceCurrentPerformance class of a MW_AirInterface_Pac instance cannot be deactivated once the MW_AirInterface_Pac instance is created .
Only the administrativeState is reported as a read-only attribute.
The administrativeControl (read-write attribute) is not present.
The request is to allow this activation/deactivation adding the administrativeControl to AirInterfaceCurrentPerformance class or similar attribute.
Topology (Split-mount, Full outdoor, …)
IDU, Radio types?
Market?
Green field or upgrade?
Limitations?

13. Issue # 31 Performance Monitoring – Adaptive Modulation
Description of the problem
The current ONF TR 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 proposal could be to add to AirInterfacePerformanceType 2 new attributes:
time2QuarterStates
time2HalfStates
Topology (Split-mount, Full outdoor, …)
IDU, Radio types?
Market?
Green field or upgrade?
Limitations?

14. Issue # 26 Minimum Power on ATPC
Description of the problem
With the current ONF TR model , in ATPC mode the range in which the tx power could be changed by the ATPC algorithm is defined by:
the txPower attribute(of AirInterfaceConfiguration class) as the max power value
the (txPower - atpcRange) as the minimum power value, where atpcRange is a radio capability (attribute of AirInterfaceCapability class) representing the allowed (and fixed) power range associated to the typeOfEquipment.
The txPower attribute is configurable by Netconf client, atpcRange is a capability with a constant value associated to the typeOfEquipment.
The idea is to allow also the configuration of the minimum power value in ATPC, overlapping the (txPower – atpcRange) value . The (txPower – atpcRange) represents now the minimun value where to select this new ‘minimum power value in ATPC’.
This request is to avoid to go with ATPC on a minum power (even if allowed) : in this scenario the ATPC algorithm of the remote NE may be on continuos work to increase the power due to slow Received Signal Level.
The proposal could be to add a new attribute on AirInterfaceConfiguration class:
- atpcTxPowerMin
with the following constraint: (txPower – atpcRange) < atpcTxPowerMin < txPower
Topology (Split-mount, Full outdoor, …)
IDU, Radio types?
Market?
Green field or upgrade?
Limitations?

15. Issue # 27 1+1 HSB – Driving criteria in Adaptive Modulation
Description of the problem
The request is to allow on 1+1 HSB radio configuration the selection of which Received Signal Level between the 2 receivers has to be considered for the Adaptive modulation shift up/down within the following:
the lowest value
the highest value
The proposal could be to add a new attribute ‘amDrivingCriteria’ with the allowed values:
notRelevant (for radio configuration not 1+1
lowestReceivedValue
highestReceivedValue
On which class? 2 solutions:
on MW_AirInterfaceHsbFcSwitch_Pac
on PureEthernetStructure_Pac (where the 2 airInterface_Pac involved are connected to)
Topology (Split-mount, Full outdoor, …)
IDU, Radio types?
Market?
Green field or upgrade?
Limitations?

16. Issue # 28 1+1 HSB – Driving criteria in APTC
Description of the problem
The request is to allow on 1+1 HSB radio configuration the selection of which Received Signal Level between the 2 receivers has to be considered for the ATPC algorithm within the following:
the lowest value
the highest value
The proposal could be to add a new attribute ‘atpcDrivingCriteria’ with the allowed values:
notRelevant (for radio configuration not 1+1
lowestReceivedValue
highestReceivedValue
On wich class? 2 solutions::
on MW_AirInterfaceHsbFcSwitch_Pac
on PureEthernetStructure_Pac (where the 2 airInterface_Pac involved are connected to)
Topology (Split-mount, Full outdoor, …)
IDU, Radio types?
Market?
Green field or upgrade?
Limitations?

17. Issue # 32 Performance Monitoring – Radio (G
Issue # 32 Performance Monitoring – Radio (G.826) and RSL data counters on link basis (1+1)
Description of the problem
In case of 1+1 HSB radio configuration (2 MwAirInterface_Pac instances and 1 MwPureEthernetStructure_Pac instance) the Performance Data (Current and Historical) of the selected radio frames received (the only signal resulting of the 2 air- interfaces after the selection function) are not reported on the current ONF TR model .
The AirInterfaceCurrentPerformance class of each MW_AirInterface-Pac instance reports the counters related to the radio frames received on own receiver calculated before the selection process.
The request is to report on PureEthernetStructureCurrentPerformance and PureEthernetStructureHistoryPerformance of the MW_PureEthernetStructure_Pac instance (on 1+1 HSB configuration) the counters needed adding on StructureCurrentPerformanceType definition type the following attributes:
es , ses, cses
Unavailability
txLevelMin, txLevelMax, txLevelAvg
rxLevelMin, rxLevelMax, rxLevelAvg
Topology (Split-mount, Full outdoor, …)
IDU, Radio types?
Market?
Green field or upgrade?
Limitations?

18. Issue # 34 MW Ethernet statistics
Description of the problem
IOn the current ONF TR MW model the Radio Ethernet Performance Data are supported on EthernetContainerCurrentPerformance and EthernetContainerHistoricalPerformances classes of MW_EthernetContainer_Pac (using ContainerPerformanceType type definiton).
Nokia need is to report also some ethernet counters as Ethernet statistics (free values not reset at each period).
A proposal could be to add the following new attributes on EthernetContainerStatus class:
txEthernetBytes
txEthernetFrames
txEthernetDiscardedFrames
Topology (Split-mount, Full outdoor, …)
IDU, Radio types?
Market?
Green field or upgrade?
Limitations?

19. Issue # 33 Performance Monitoring – Threshold Data Association
Description of the problem
The request is to manage the thresholds used to raise or clear a Threshold Cross Alarm (TCA) on Performance counters (es , ses and cses).
On the current ONF TR model these thresholds are not foreseen.
A TCA alarm related to a counter should be raised (and cleared) on an MW_AirInterface_pac instance according to an <counter>HighThr (for alarm raise) and <counter>LowThr (for alarm clear) values, specific for each counter and for each period type (15m, 24h), predefined or user configured.
Topology (Split-mount, Full outdoor, …)
IDU, Radio types?
Market?
Green field or upgrade?
Limitations?

20. Issue # 33 Performance Monitoring – Threshold Data Association
First proposal
To add a new class, PerformanceThresholdData, that is a list of elements (PerformanceThresholdDataList) containing the following attributes:
granularityPeriod, esHighThr , esLowThr, sesHighThr , sesLowThr , csesHighThr , csesLowThr
The key of each element on PerformanceThresholdDataList is a simple identifier (integer value).
2 elements, one for each granularityPeriod , will contain predefined values not modifiable.
Other elements (till a max number according to device capability) ) could be created with values provided by operator.
A new attribute (read-write), ThresholdDataReference, should be added to AirInterfaceCurrentPerformance/ current- performance-data-list to associate the instance of CurrentData (15m or 24h) to an instance of PerformanceThresholdDataList.
Topology (Split-mount, Full outdoor, …)
IDU, Radio types?
Market?
Green field or upgrade?
Limitations?

21. Issue # 33 Performance Monitoring – Threshold Data Association
Second proposal
The thresholds could be added to MW_AirInterface_pac::AirInterfaceConfiguration :
es15mHighThr , es15mLowThr ,
ses15mHighThr , ses15mLowThr ,
cses15mHighThr , cses15mLowThr,
es24hHighThr , es24hLowThr
ses24hHighThr , ses24hLowThr
cses24hHighThr , cses24hLowThr
A manager is able to define all these values for each interface (even if same values could be repeated for some of them).
Topology (Split-mount, Full outdoor, …)
IDU, Radio types?
Market?
Green field or upgrade?
Limitations?

22. Issue # 35 Net Bandwidth & Operative Bandwidth
Description of the problem
The need is to have an indication of
the current net bandwidth (or capacity in Mb/s) related to a single radio channel (MW_AirInterface_Pac instance);
the value of operative bandwidth (in Mb/s) available on a radio link , whatever it is the radio link composition (1+1 protection, 2+0, link aggregation of more than 2 radio modules).
The current net bandwidth (Mb/s) is the net capacity related to the current modulation.
The operative bandwidth (Mb/s) is the net capacity taking in account the sum of the net capacity of each radio module on a radio link and the decrease of the bandwidth due to any reason (configuration for limitation).
The only information available on th current ONF TR model is the codeRateCur but nothing regarding the capacity in Mb/s.
The proposal could be to add a new attribute to AirInterfaceStatus:
netBitRateCur (Mb/s) or txCapacityCur
and on MW_EthernetContainer_Pac
operativeBitRate (Mb/s)
Topology (Split-mount, Full outdoor, …)
IDU, Radio types?
Market?
Green field or upgrade?
Limitations?