Wireshark 4.4.2 not able to decode RRC's UE Information Response coarseLocation's degreesLongitude correctly

edit

The description in TS 23.032 is, as it says, of "a coding method for geographical area descriptions." It is not the encoding method using by TS 37.355 (LTE Positioning Protocol, LPP) and hence TS 38.331 (NR-RRC), as in those cases ASN.1 with Basic Packed Encoding Rules (BASIC-PER), Unaligned Variant as specified in ITU-T Rec. X.691 is used. (See TS 37.355 section 6.)

TS 38.331 mentions that "[coarseLocationInfo] is coded as the Ellipsoid-Point defined in TS 37.355."

TS 37.355 defines the Ellipsoid-Point in terms of ASN.1 with PER encoding, saying

The IE Ellipsoid-Point is used to describe a geographic shape as defined in TS 23.032 [15]

   -- ASN1START
   Ellipsoid-Point ::= SEQUENCE {
   latitudeSign ENUMERATED {north, south},
   degreesLatitude INTEGER (0..8388607), -- 23 bit field
   degreesLongitude INTEGER (-8388608..8388607) -- 24 bit field
   }
   -- ASN1STOP

When encoding an INTEGER according to Unaligned PER, bounds as above are PER-visible, and thus ITU-T X.691 11.5 "Encoding of a constrained whole number" is applied, specifically 11.5.6 (where "lb" is the lower bound of the constraint):

In the case of the UNALIGNED variant the value ("n" – "lb") shall be encoded as a non-negative- binary-integer in a bit-field as specified in 11.3 with the minimum number of bits necessary to represent the range. NOTE – If "range" satisfies the inequality 2m < "range" ≤ 2m + 1, then the number of bits = m + 1.

Yes, that means that in the case above, it's a 24 bit field, but due to the subtraction (and the exact values of the constraints here) it is encoded in offset binary, not 2's complement, hence the MSB is inverted compared to what you expect.

In the example above, that means that -233013 is encoded as -233013 - (-8388608) = 8155595 = 0x7C71CB.