radio-signal-id: proposal of simplification

[rservadio]

SUMMARY In air-interface-configuration model there are:

• transmitted-radio-signal-id
• expected-radio-signal-id

In some implementation this two parameters must have the same value and in this case: air-interface-capability:expected-equals-transmitted-radio-signal-id=true

In current implementation to configure the radio-signal-id it is required to send both parameters (transmitted-radio-signal-id and expected-radio-signal-id) with the same values. In case one of the two is missed the request is refused.

PROPOSAL OF SIMPLIFICATION In case expected-equals-transmitted-radio-signal-id=true the proposal is the following:

• configure radio-signal-id sending only transmitted-radio-signal-id
• leave expected-radio-signal-id with his default value -1.
• in case of a configuration attempt on expected-radio-signal-id reply with: "operation-failed" and "#[onf:Attribute/feature not supported by the hardware.]#"

[openBackhaul]

I am supporting this proposal and I am proposing to amend the comment of the expectedRadioSignalID attribute with the following additional phase "Only relevant, if expectedEqualsTransmittedRadioSignalID==false. ".

[demx8as6]

Proposal:

• change type for transmittedRadioSignalID::numericRadioSignalID and expectedRadioSignalID::numericRadioSignalID from uint16 to int32
• in UML and yang the default value is -1 -- "-1" means "feature not supported" -- "0" means "feature disabled"
• change the description as proposed above plus new description for the meaning of the values "0" and "-1".
• if transmittedRadioSignalID::numericRadioSignalID and expectedRadioSignalID::numericRadioSignalID are NOT independent from each other but supported, then the expectedRadioSignalID::numericRadioSignalID must be "-1".

Behavior

• after startup the device SW comes up with the a proper value according to the capability of the hardware.
• LTPs are created by expectedEquipment

Next steps:

• decision in 5G-xHaul [done 2020-06-03 in 5g-xHaul call)
• change UML
• generate new YANG

[openBackhaul]

Decision (5G-xhaul call on 3rd of June): Need for parallel configuration of transmitted-radio-signal-id and expected-radio-signal-id shall be avoided for simplifying configuration processes. So in case AirInterfaceCapability::expectedEqualsTransmittedRadioSignalID==true, the AirInterfaceConfiguration:: expectedRadioSignalID shall be implemented like an unsupported attribute (always sticks with its default value). This means • AirInterfaceConfiguration:: expectedRadioSignalID::numericRadioSignalID=-1 and AirInterfaceConfiguration:: expectedRadioSignalID::alphanumericRadioSignalID=”Not yet defined.” • any attempt to configure expectedRadioSignalID shall be answered with error-tag "operation-failed" and error-message phrase "#[onf:Attribute/feature not supported by the hardware.]#".

The following changes have to be made on the modeling: • numericRadioSignalID datatype has to change from uint16 to int32 • numericRadioSignalID default value has to change from 0 to -1 • numericRadioSignalID comment to be complemented with “-1 = to be used, if numericRadioSignalID is not supported or for expectedRadioSignalID, if it has to equal transmittedRadioSignalID.”

• alphanumericRadioSignalID comment to be complemented with “Not yet defined. = to be used, if alphanumericRadioSignalID is not supported or for expectedRadioSignalID, if it has to equal transmittedRadioSignalID.”

• AirInterfaceConfiguration::expectedRadioSignalID comment to be complemented with “Only relevant, if expectedEqualsTransmittedRadioSignalID==false.”.

[openBackhaul]

Fixed with AirInterface_2.0.0-tsp.220328.1245.