identityref coding-modulation does not cover all values

[niloda]

Having implemented the model in the 4th ETSI Plugtest for mw devices, we realized that the identityref coding-modulation does not provide all possible values. Some mw devices support 8 PSK modulation which is not included.

The use of identityrefs, even if it currently covers all values, also has the disadvantage of having to update the YANG model if new and more complex modulation schemes are standardized in the future.

A different approach could be taken to overcome this limitation. Let the device declare the acm profiles it supports, making explicit the parameters of each transmission ACM profile, and point to one of these in selected-min-acm, selected-max-acm or selected-cm.

Whereas each ACM profile is basically described by

• bandwidth
• modulation
• code rate (ratio between net bandwidth and gross bandwidth
• a reduction factor of the symbol rate (usefull for half-bpsk)
  to which generic parameters can be added, such as (for example) a descriptive name of the profile and a value to organize the profiles in ascending/descending order

the following structure could be assumed as an ACM profile entry:

grouping acm-profile {
 leaf acm-profile-name {
      typestring;
      ...
     "Eg: 4qam-strong"
 }
 leaf acm-profile-order {
   type int32;
   ...
   "1 to N"
 }
 leaf channel separation {
   type int32;
   units "kHz";
   ...
 }
 leaf modulation-scheme {
   type int16;
   units "symbols";
   ...
   "2=BSPK ... 10=1024qam ... 12=4096qam"
 }
 leaf code rate {
   type int8;
   units "%";
   ...
 }
 leaf symbol-rate-reduction-factor {
   type int8;
   default "1";
    "Reduction factor for the symbol rate. Example: value would be 2 for 1/2BPSK.";
 }
 leaf supported-as-fixed-configuration {
   type boolean;
   defaults "false";
    "true = This acm profile is available for manual configuration when Adaptive Modulation is switched off.";
 }

}

From which it would also be possible to obtain the available radio capacity with the simple formula:
tx-capacity = channel-separation * log2(modulation-scheme) * code-rate / symbol-rate-reduction-factor / K ;
K takes into account the rolloff (approx. 1.15).

The device could only show the profiles of the selected channel-separation, if one accepted that the list containing the ACM profiles is not invariant over time. In this case, acm-profile grouping might not include the channel-separation attribute.

The selected-min-acm, selected-max-acm or selected-cm attributes should become leafrefs pointing to one of the ACM profiles.

With this approach, although complex, it is not necessary to maintain the identityref in the future.
Even the user who has to configure the ACM profiles would be facilitated in the setting, having the list of values supported by the device available.

[niloda]

After the discussion we had in the weekly meeting, the proposal could be changed as in the description below.

A new data type is defined with the grouping <acm-profile> which is composed of the following attributes:

Where:

• profile-id uniquely identifies the acm profile.
• profile-name is a short string describing the profile
• modulation-scheme is the logarithm base two of the number of points in the transmitted constellation. E.g.: value would be 2 for 4QAM, 10 for 1024QAM and 12 for 4096QAM
• code-rate is the percentage of the ratio between net bandwidth and gross bandwidth
• symbol-rate-reduction is the reduction factor for the symbol rate. E.g.: value would be 2 for 1/2BPSK.
• supported-as-fixed-modulation is true when the profile can be used in a fixed modulation scheme.
• max-tx-power is the maximum transmitted power when the radio link is operating this profile
• min-tx-power is the minimum transmitted power when the radio link is operating this profile
• upshift-threshold is the received power value, beyond which the next higher profile is activated
• downshift-threshold is the received power value, under which the next lower profile is activated
• upper-profile is the pointer to the next higher profile
• lower-profile is the pointer to the next lower profile

The <acm-profile-list> list of acm profiles indexed by <profile-id> must be added to the <capabilities> container. The list contains the acm profiles operated by the radio link for the selected channel separation. In other words, every time you change the value of <channel-separation> the device rebuilds the list.

The elements of the acm profile list are doubly linked to each other via the <upper-profile> and <lower-profile> attributes. It is thus evident what will be the sequence of the profiles operated according to the fading conditions. The figure below shows these relationships.

Having chosen to keep the identityref <coding-modulation> type for <profile-id>, <available-min-acm> and <available-max-acm> would 'point' respectively to the lowest and highest profile present in <acm-profile -list>. Choosing the identityref <coding-modulation> type for <profile-id> means keeping this type in the model which is not future-proof, but would be a good compromise for backward compatibility (A better defined model would require changing the type of <available-min-acm> and <available-max-acm> to leafref).

In the /if:interfaces/if:interface augment, which contains the radio link configuration attributes, the <selected-min-acm> and <selected-max-acm> (or <selected-cm>) attributes must 'point ' to an element of the <acm-profile-list> list. Also for these attributes it is possible to maintain the type identityref <coding-modulation>.

The proposed solution would bring the following benefits:

• list the acm profiles supported and operated by the radio link
• provide a description of the characteristics of each value defined for the identityref <coding-modulation>
• help user configure <selected-min-acm> and <selected-max-acm> (or <selected-cm>)
• help the user configure the transmitted power (whose range is influenced by <selected-min-acm> or <selected-cm>)
• facilitate the calculation of the nominal radio link capacity for every acm profile (if necessary)
• help calculate radio link availability with <upshift-threshold> and <downshift-threshold>

[DanielaSpreafico]

Now I understood the proposal.

I agree to add the capabilities with the list of acm-profile (used also for fixed modulation) .
This allow to know at client level the allowed values to use to configure selected-min-acm/selected-max-acm or selected-acm.

Using the profile-id as identityref coding-modulation the backward compatibility is maintained.

Few comments:

1. the list is related to the selected channel-separation, so each time this field is selected the list is needed to be reloaded from the node.
   I know the list is increasing adding also as a key the channel-separation , but these values could be considered 'capabilities' or 'allowed values' from the node, helping further the selection of the configuration parameters.
   channel-separation , selected-min-acm/selected-max-acm or selected-acm remain the same.
   At the end we can add a new key (profile-channel-separation-id ?) and change the profile-id to profile-coding-modulation-id.

2. I propose to use a new attribute tx-capacity (or nominal-tx-capacity) instead of code-rate and symbol-rate-reduction

3. related to max-tx-power and min-tx-power , I agree to add to the 'acm-profile' because the transmit power range is specific to each acm profile, but how to configure the associated value maximum-nominal-power ? Inside the minimum and maximum values of all acm instances ? How to add also the capabilities for atpc-lower-threshold and atpc-upper-threshold ?

[samans]

Discussed on 4 May 2023 call:
This issue is related to #14 and #15 and if resolved, the other two issues can be closed.

Discussing Danilo's and Daniela's comments the following was decided to propose for the next draft of the YANG module:

The acm-profile-list is added to the capabilities container. the acm-profile-list uses the grouping called acm-profile and is indexed by profile-coding-modulation-id and profile-channel-separation-id.

Use a new attribute called nominal-tx-capacity, instead of code-rate and symbol-rate-reduction because the calculation of nominal-tx-capacity is derived from code-rate and symbol-rate-reduction by formulas that are not standardized and are specific to the equipment. So the nominal-tx-capacity value should be provided to avoid confusion on how to calculate it.

Rename minimum-power to min-tx-power and maximum-available-power to max-tx-power.

Discussion on upshift and downshift with the ONF, it is unclear how to fill out those values.

Other issues related to atpc, need to be made into new issues.

[samans]

Update from 4 May:
keep minimum-power and maximum-available-power names because those are the names used in the ETSI documents.
Suggestion to remove upshift and downshift from the proposal above.

add: 8 PSK modulation

[JonasAhl]

Based on the latest proposal from Danilo the follwoing changes were suggested.

• Change order of the key to make channel separation the first.
• Change the type of profile-channel-separation-id to uint32, to align with the other related leafs in the module.
• "The channel-separation and selected-cm configuration parameters (or the selected-min-acm/selected-max-acm pair) must address one of the profiles in the list." need to be reformulated to reflect that capabilities are optional leafs.

[samans]

Implemented the first two bullets in Jonas' comment above. Need more information about the third bullet.

[samans]

For "The channel-separation and selected-cm configuration parameters
(or the selected-min-acm/selected-max-acm pair) must address
one of the profiles in the list.";

Add: "If acm-profile-list is supported then the channel-separation and ...

Update: Change acm-profile-list to be a YANG feature. And propose yang.

Action to team: Check the list of coding-modulations to validate completeness.

[JonasAhl]

A few additional comments:

• We have similar tables/profiles for our nodes, but channel-separation is not part or impacting those profiles.
• Reference spectrum efficiency class, RSEC, is on the other hand a deciding factor for us.
• supported-as-fixed-modulation means that the same profile values could apply also for fixed modulations. In our systems max-tx-power might be different depending on if it is fixed or adaptive. How would that be handled in the suggested model construct?
• Is this really modelling an industry standard or is this perhaps something more system specific & proprietary and if so should be modelled as such?
• I'm still struggling to understand how this information is supposed to be used by a PNC (microwave domain controller).
  Is is possible to provide a set of example data and a description of how that could be used by a PNC?