Note: UML part has been executed. TR document paragraph is still to be written.
Decision
Adding a new symbolRateReductionFactor:Integer attribute to the TypeDefinitions::TransmissionModeType data type to express the reduced symbol rate applied e.g. with ¼ BPSK (symbolRateReductionFactor = 4) and ½ BPSK (symbolRateReductionFactor = 2).
Defining the default value of TypeDefinitions::TransmissionModeType::symbolRateReductionFactor == 1.
Adding the following comment to the symbolRateReductionFactor: "Reduction factor for the symbol rate. Example: value would be 4 for 1/4BPSK."
Adding a new transmissionModeName:String attribute to the TypeDefinitions::TransmissionModeType data type to allow naming of the transmission mode by the vendor.
.
Adding AirInterface::AirInterfaceConfiguration::_transmissionModeMin and AirInterface::AirInterfaceConfiguration::_transmissionModeMax attributes according to issue#15 for configuring the symbolRateReductionFactor.
.
Adding an AirInterface::AirInterfaceStatus::_transmissionModeCur attribute according to issue#14 for expressing the operational status of the symbolRateReductionFactor.
.
Defining the TypeDefinitions::timeXStatesType data type and adding the TypeDefinitions::AirInterfacePerformanceType::timeXStatesList attribute according to issue#15 for expressing the performance values.
.
Adding a paragraph to TR-532 that explains the behavior in regards to characteristics (e.g. channel bandwidth) that are not recorded as a performance value by the device.
Background
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.
Mainly, the idea is to replace with a list the whole set of counters of the number of seconds the device operated a specific transmission-mode .
A list entry is composed by a key and a counter (as in the figure 1). The key references a valid transmission mode.
In the list are created only the entries related to the transmission-mode whose channel-bandwidth matches the one set in air-configuration.
The following figure shows the transition from the air-interface performance defined by the current model to the proposed structure.
Figure 1
Overview
Content Tools
Activity
8 Comments
Giorgio Cazzaniga
Discussion of the proposal held on 18/4; indicated a deadline for decision on 9/5
Daniela Spreafico
This solution is flexible but not backward compatible. For the devices already supporting the PM, this is a rework.
Thorsten Heinze
Remark: Proposal has been changed since this comment
Michael Binder
This approach requires that the other parameters being part of the transmission modes, e.g. channel bandwidth, do not change during the measurement interval and until the data is reported if the NE does not store the "historical" values for these parameters and thus the transmission modes. That is, a change of these parameters would prevent retrieval of valid PM data.
Thorsten Heinze
You are right, there is a problem with manual changes of the channel bandwidth.
Appart from that, I would say, the device must be able to provide performance information about every characteristic, which is matter to automatic change.
Giorgio Cazzaniga
WT call of 2/5: the presented solution is complete and flexible but not backward compatible; there are some concerns on this point; we need to find a way to have the solution with some backward compatibility (marking as 'obsolete' the current model?)
Thorsten Heinze
Remark: Proposal has been changed since this comment
Thorsten Heinze
Underscores have been added to the new attributes' names to express that no new instances of TransmissionModeType data type have to be created, but the existing instances from the capability Information are referenced.