Canonical Extension Namespace: Modulation / Signal Type

[bhilburn]

One of the most popular annotation types is going to be signal / modulation type. Per #13, for anything that we know is going to be used heavily, we are going to create canonical extension namespaces so that we don't end up with a bunch of competing sub-standards for describing annotations in SigMF.

(Recall, supporting canonical extension namespaces are not required to be SigMF compliant, but simply provide a common namespace for those that want it).

Thus, I would like to start hammering down how this namespace works. In my mind, there is a taxonomy of signal types that people will want to use. For example:

• The system is using 64QAM
• The system is using OFDM with 64QAM
• The system is using 802.* with OFDM-64QAM
• The system is a DJI drone signal link

So, a few questions based on this:

1. How far should we go?
2. Am I missing a layer that makes sense to add?
3. How do we represent these?

[kpreid]

Thoughts:

• I believe there are not any already-existant vocabularies for describing all of these layers. You will have to invent some of them, and some of them need to be fairly freely extensible (e.g. "DJI drone signal link" as you said is just one company's invention and there will be many, many more like that).

• Arguably, you should not have a fixed number of layers. There is always the possibility of someone adding another protocol on top of an existing one (though they may become more and more irrelevant to RF signal analysis), or at the other end sending a perfectly good signal into a FM modulator.

[mbr0wn]

This is an extremely difficult problem. There's such a large number of combinations. Professional taxonomers are there for a reason... Based on, in particular, SIGINT efforts I've seen here, I would expect that whatever we do here will fail at some point. We could also just not try, and make the modulation / signal type a free text field.

[bhilburn]

My problem with making it a free-text field is that we will end up creating many "standards within the standard". I really think we need a canonical way of representing this, but it needs to be flexible, per @kpreid's comments.

I wonder if there are other efforts that have solved similar problems from which we could draw?

[bhilburn]

So, what are people's thoughts on defining a canonical listing for "common" modulations / PHYs, a way of specifying a hierarchy, and allowing free-form definition of everything else?

It's a compromise, and is open to misuse, but also provides some degree of portability. Thoughts?

[kpreid]

Thought: If it is important that readers be able to recognize specific values, and you allow freeform input as well as a canonical list, then writers should be able to specify multiple names for the same thing. Otherwise, the de-facto standard will be whichever "freeform" values get there first, because nobody can change to more uniform ones without breaking compatibility with existing reader software that hasn't been updated.

This same feature also allows writers to provide a general value and a more specific value and the reader does not need to recognize every possible specific value in order to interpret the general one.

(An alternative would be to publish a standard list of synonyms, and have reader software expected to keep up to date with that list, but I dislike this out of vague principle.)

[dimitriblock]

I started to draft modulation annotation type for common digital modulations:

modulation = single_carrier_modulation | multi_carrier_modulation

Modulation type is composed of various subfields:

single_carrier_modulation_type = "QAM" | "PSK" | "ASK" | "FSK" | new_single_carrier_modulation_type
single_carrier_modulation_symbols = "2" | "B" | "4" | "Q" | "8" | "16" | new_single_carrier_modulation_symbols
single_carrier_modulation = single_carrier_modulation_symbols ["-"] single_carrier_modulation_type
subcarrier_modulations = single_carrier_modulation [ "/" single_carrier_modulation [...]]
multiplexing_type = "OFDM" | "GFDM" | "FBMC" | new_multiplexing_type
multi_carrier_modulation = multiplexing_type "-" subcarrier_modulations

The modulation types is extensible with three optional free fields:

• new_multiplexing_type alphanumeric string
• new_single_carrier_modulation_type alphanumeric string
• new_single_carrier_modulation_symbols alphanumeric string

They shall be not equal to any already specified single_carrier_modulation_type, single_carrier_modulation_symbols, multiplexing_type

Valid examples are

• modulation = "BPSK" which is equal to "B-PSK", "2PSK", "2-PSK" "2PSK"
• modulation = "OFDM-64QAM"
• modulation = "OFDM-64QAM/BPSK" in case subcarrier modulation types vary
• modulation = "OFDM-2FSK" (doesn't make sense, but possible)

• Definition of a new modulation type

   new_single_carrier_modulation_type = "OOK" 
   modulation = "OFDM-OOK"

  Modulation parameters should be specified separately

• freq_subcarrier_spacing double-valued frequency (HZ) of subcarrier spacing valid only for multi_carrier_modulation

[bhilburn]

@kpreid - Good point.

@dimitriblock - Whoa, nice work! It's really helpful to see sketch of what this might look like. I like the direction you are taking this, too.

To enable the addition of arbitrary new layers to further describe things, we could append something like (trying to mimic your meta-language, here):

new_type_descriptor = [new_descriptor "-" [...]] multi_carrier_modulation

One question: should we organize this going the opposite direction? So, for example, should it be: Wireless Webcam - 802.11ac - OFDM - 64QAM

Or: 64QAM - OFDM - 802.11ac - Wireless Webcam

[dimitriblock]

@bhilburn From signal-point of view the modulation type is more important than its application. Therefore, a modulation/signal type should focus on modulation and not on higher-layer coding, PDUs, ...

In my opinion the spec extension shall limit to:

• Analog modulation types
• Digital modulation types
  • Single-carrier digital modulation types
  • Multi-carrier digital modulation types

Higher-layer processing like framing, coding, spectrum spreading techniques have limited impact on signal characteristics and should not be considered in the spec extension.

[bhilburn]

@dimitriblock - You have a good point, but at the same time, I don't want to prevent people from creating a deeper / more precise description of signals and links. That said, I think what you described is a great justification for where to describe the boundary of what we define canonically and what we leave "open".

So, going back to your original list, what analog or digital modulations should we add to the list? =)

[dimitriblock]

Mainly adapted from wikipedia:

modulation = analog_modulation | digital_single_carrier_modulation | digital_multi_carrier_modulation

analog_modulation = "AM" | "DSB" ["-" analog_am_carrier_variants] | "SSB" [ "-" analog_am_carrier_variants] | "VSB" ["-" analog_am_carrier_variants] | "QAM" | "FM" | "PM" | new_analog_modulation_type
analog_am_carrier_variants = "WC" | "SC" | "RC"

digital_single_carrier_modulation_type = "QAM" | "PSK" | "ASK" | "FSK" | "OOK" | "CPM" | "MSK" | "CPFSK" | "WDM" | new_digital_single_carrier_modulation_type
digital_single_carrier_modulation_symbols = "2" | "B" | "4" | "Q" | "8" | "16" | new_digital_single_carrier_modulation_symbols
digital_single_carrier_modulation = digital_single_carrier_modulation_symbols ["-"] digital_single_carrier_modulation_type | "OQPSK"

digital_multiplexing_type = "OFDM" | "GFDM" | "FBMC" | "TDM" | "FDM" | "PDM" | "SM" | "SMX" | new_digital_multiplexing_type
digital_subcarrier_modulations = digital_single_carrier_modulation [ "/" digital_single_carrier_modulation [...]]
digital_multi_carrier_modulation = digital_multiplexing_type "-" digital_subcarrier_modulations

The modulation types is extensible with four free fields:

• new_analog_modulation_type alphanumeric string
• new_digital_multiplexing_type alphanumeric string
• new_digital_single_carrier_modulation_type alphanumeric string
• new_digital_single_carrier_modulation_symbols alphanumeric string

The list is still not complete but contains the common modulations.

Actually, IMO the modulation field should be parsable. So, in case a free field is nonempty, its content must be used in modulation. So, while remaining extensible, it has to follow specific form.

@bhilburn The same parseble concept could be applied for more detailed descriptions eg WLAN. But I didn't consider it yet.

I removed the modulation parameters eg freq_subcarrier_spacing because they maybe very specific and also nonstatic.

Comment: Maybe the terms digital_subcarrier_modulations and digital_multi_carrier_modulation are misleading for non-FDM multiplexing.

[bhilburn]

Closing this to follow conversation in #87