Tracking: Unclear aspects around nr+ specifications

[chrysn]

• Network beacons and scanning:

  For any given band, what's the expectation of which channel the network beacons would be sent?

  Following -4 5.1.2 operating channel selection picks the best channel (which, on the green field, would be practically random). But that's the cluster beacon channel, and not the network beacon channel ("Network Beacon message indicates the operating channel").

  "The Network Beacon message can be transmitted on a limited set of channel(s) to reduce other RDs' search time", but which ones to pick?

  We can sure pick some, but the idea is to interoperate. Lacking a consistent channel, and with beacons every N seconds, and given that there are 10 usable (odd) channels in band 1, it'd take 10*N seconds to find the network.

  Or do we just have some preference, and start scanning there?

• IPv6: Why no CVG E2E encryption?

  I do get that it wouldn't make a lot of sense for P2P (because then every IP exchange would need to be preceded by a non-IP CVG layer exchange to establish pairwise keys), but at least to the sink that'd be useful, because it'd allow making a decision on whether or not that device is allowed routing into the Internet.

• Audio: Is there any profile for codec? (Probably LC3 or LC3plus?)

  (See also Tracking: Applications #10 -- what do we pick for audio?)

• MAC IEs: "The IE type defines the length of the IE payload"

  … but nowhere near all this did I find how it says so. Judging from wireshark code that parses all this linearly and with full knowledge of the types, this takes into account

  • the remaining length (for padding)
  • inner structure of the field (eg. in dissect_group_assignment_ie when !ie_lenght_present it utilizes the single_field bit)

  Also no words about how to handle reserved values -- and that's even when errors are supposed to be local ("If the receiver receives a field with a code value that is reserved, it shall consider that the IE is incorrect and not act on this IE."). And "The receiver may process all the received MAC messages or MAC IEs received in a single MAC PDU in any order." is not really possible that way.

  Yikes.

• Scrambling values: Why the values?

  The scrambling required during transmission in -3 7.6.6 depends on the network ID. That's fine; I don't understand the precise details of what is even being scrambled, given that enabling it on the 9151 has no effect on reception, but so be it.

  For a Type 1 PCC, the scrambling value is the 8-bit network ID. That's fine, that is part of the PCC.

  For a Type 2 PCC, the scrambling value is the 24 MSBs of the network ID. That is not part of the header.

  So: Why? If that information is to be passed around and generally available, all transmissions could follow the full network ID, and there'd be less inconsistency.

  The -4 4.2.3.1 definition of the IDs doesn't help clarify this, and adds that not both the 24 long and the 8 short can be 0 -- so what now, does the random process for selecting the LSB 8 bit need to special-case for when the 24 bit are all 0? (Way to create a bug that will only hit one out of 1M users).

• How do sinks coordinate on using the same key material? Relatedly: Is that all that defines "being a single network"?

  • DECT advertises no need to administer network IDs; then, how do they get assigned?

• MCS: What's the point of MCS-0?

  Generally, larger MCS have more complex modulation, less redundancy, and in total work only with higher link budget. MCS=0 is BPSK with 1bps, MCS=1 is QPSK with 2bps, both with a +100% FEC.

  But the PCC data's coding, per -3 7.5.3, is QPSK with 2bps for its 98 REs (whereas the coding of the PDC is whatever the data in the PCC says). If PCC needs to work first, why is there even an option to downgrade?