IVIM (avc, mlc, rsc) - V2 containers can not be decoded

[MrMushroom]

Issue

avc, mlc, rsc containers will lead to failed decoding.

Setup

Generator: https://github.com/brchiu/asn1c.git (velichkov_s1ap_plus_option_group_plus_adding_trailing_ull)

Minimal IVIM received

Encoded Content

value1 IVIM ::= {
  header {
    protocolVersion 2,
    messageID ivim,
    stationID 0
  },
  ivi {
    mandatory {
      serviceProviderId {
        countryCode '1100000001'B,
        providerIdentifier 1
      },
      iviIdentificationNumber 1,
      timeStamp utcStartOf2004,
      iviStatus new
    },
    optional {
      avc : {
        {
          relevanceZoneIds {
            1
          },
          automatedVehicleRules {
            {
              priority 0,
              allowedSaeAutomationLevels {
                0
              }
            }
          }
        }
      }
    }
  }
}

Payload:

020600000000A3010004000000000000000100100640000200010280

Problem Description

The avc is decoded normally, but right after, a mlc is expected.
ASN_DEBUG output

Decoded AutomatedVehicleContainer as SET OF (.../vcits/asn1c/src/constr_SET_OF.c:995)
Decoding member "mlc" in ext1 (.../vcits/asn1c/src/constr_SEQUENCE.c:1170)

Likely Cause

The ISO19321IVIv2.asn specifies

IviContainer::= CHOICE {
	glc		GeographicLocationContainer,
	giv		GeneralIviContainer,
	rcc		RoadConfigurationContainer,
	tc		TextContainer,
	lac		LayoutContainer,
	...,	-- original extension indicator of V1
[[ -- Extension in V2
	avc		AutomatedVehicleContainer,	
	mlc		MapLocationContainer, 
	rsc		RoadSurfaceContainer ]]
	}

This should be interpreted as a CHOICE between eight containers (glc, giv, rcc, tc, lac, avc, mlc, rsc). This can be verified with Wireshark. However, the generator can not handle "[[ ... ]]" within CHOICE objects. The generated C-code in IviContainer.h and IviContainer.c expects the extension (ext1: avc, mlc, rsc) to be one element, with three mandatory containers. In other words, the decoder then decodes the avc perfectly, but expects an mlc.

Unsuccessful Workarounds

• Integrating avc, mlc and rsc directly into the list of the IviContainer does not work, as the extension seems to create some encoding that expects a decoupling of those two messages. Decoding with this integrated setup will decode, but it will decode a LayoutContainer with information gathered from the data that is there.
• Escaping the extension as a new CHOICE object does not work and results in the same behavior as above. Some of the meta information in the bitstream is interpreted wrongly

Possible Solutions

1. The generator has to be adapted to fit this special form of "[[ ]]" extension. However, I'm not in a position to fully understand the generator and its recursive magic. Maybe someone else could fix that.
2. ETSI or ISO might fix the IVIM in an upcoming standard, to be more straight forward.

General Remark from developer perspective: The ETSI files look clean and are easy to parse. However, the ISO standards, especially DSRC and ISO19321IVIv2 are a mess. The standards use specification elements that are niche and not necessary (RegionalExtension and "[[ ]]"). Both of them make the standard hard to parse with existing FOSS. The entry barrier is really high.

Status

We adapted the decoder to fit for one specific use case. As CDD 2.3 will be released soon, we will wait for that.