Skip to end of metadata
Go to start of metadata
StatusEXECUTED
StakeholdersThorsten Heinze
Outcome
Due date 
OwnerDaniela Spreafico Beatriz Ugrinovic Nader Zein
References 

Decision

Analysis resulted in changing into unidirectional objects would (if possible) not be backward compatible.

Unidirectional objects will not to be part of TR-532 v1.1

Issue#25 remains open

Background

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


A table comparing the TX and RX classes have been discussed:

Proposals for sorting airInterface attributes into TX and RX classes

3 Comments

  1. In the WT call of 18/4 it has been decided to have a modified proposal from Thorsten to address the cases of bidirectional parameters; deadline moved to 25/4

  2. In the WT call of 2/5 it has been verified that there are still pending the actions; deadline moved to 25/5 after modelling session in Italy

  3. What about the proposal to have additional attributes ?

    • for capability class, to report if the second receiver on the air-interface is supported (receiverDivIsAvailable ? ) ,
    • for configuration class, to enable (combinerControl?)  the feature and to activate/deactivate (receiverDivIsOn ?) the second receiver )
    • for status class, to report the current signal received on the Diversity receiver (rxDixLevelCur?)
    • for performanceType class , to report the value of Performance Dara referring to Diversity receiver (rxDixLevelMin, rxDixLevelMax, rxDixLevelAvg ?)