Issue

A defintion of SEQUENCESIZE(1..128, ...) can not be decoded/encoded (see CPM v2.1.1)[https://github.com/virtual-vehicle/vehicle_captain_its_asn1_specifications/blob/master/experimental/CPM-PDU-Descriptions.asn].

Setup

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

Problem Description

Encoding of such a datatype leads into a bitshift of one to the left of the first decoded value after the start of the sequence (when compared to Wireshark as reference decoder).

Decoding of a valid CPM results into a bitshift to the right of the first decoded value after the start of the sequence (when compared to Wireshark as reference decoder).

Likely Cause

The additional "..." seems to be important and needs to be respected by the decoder/encoder. But this seems not be implemented into the Generator

Unsuccessful Workarounds

• removing the "..." in the asn1 definition will not fix the problem. The newly generated code is exactly the same. Hence this issue is most likely part of the core components of the generator.

Possible Solutions

none

Status

If you want to use specifications of that type, we suggest to use another Generator for the messages. Thank you though for trying to opt for this FOSS!

Issue

This is only an observation. No issue has been detected yet.

./command.sh uses a file as dependency that is not loaded. Instead of loading the file, another file is checked twice.

This is also the case with original ETSI sources

Setup

Not necessary, it is in the source files.

Problem Description

Copied mistake from original sources in syntax_check.bash from ETSI forge

This Repo

One file is loaded twice.

  if [ ! -f "$ETSI_ITS_BUILD_ROOT_DIR"/asn1/"ISO14906(2018)EfcDsrcGenericv7.asn" ]; then
    wget -P "$ETSI_ITS_BUILD_ROOT_DIR"/asn1 'https://standards.iso.org/iso/14906/ed-3/en/ISO14906(2018)EfcDsrcGenericv7.asn'
  fi
  if [ ! -f "$ETSI_ITS_BUILD_ROOT_DIR"/asn1/TS17419_2014_CITSapplMgmtIDs.asn ]; then
    wget -P "$ETSI_ITS_BUILD_ROOT_DIR"/asn1 'https://standards.iso.org/iso/ts/17419/TS%2017419%20ASN.1%20repository/TS17419_2014_CITSapplMgmtIDs.asn'
  fi
  if [ ! -f "$ETSI_ITS_BUILD_ROOT_DIR"/asn1/"ISO14906(2018)EfcDsrcGenericv7.asn" ]; then
    wget -P "$ETSI_ITS_BUILD_ROOT_DIR"/asn1 'https://standards.iso.org/iso/14906/ed-3/en/ISO14906(2018)EfcDsrcGenericv7.asn'
  fi

ISO14823-missing.asn will not be present

function compile_IVIM() {
  install -d "$VC_ITS_LIB_ROOT_DIR"/ivim
  asn1c -D "$VC_ITS_LIB_ROOT_DIR"/ivim -R -no-gen-example -fcompound-names -fno-include-deps -pdu=IVIM \
    "$VC_ITS_ASN1_SPECS_DIR"/"$IVIM_SPEC" \
    "$VC_ITS_ASN1_SPECS_DIR"/"$CDD_SPEC_v2" \
    "$IS_TS_ISO_DIR"/'ISO24534-3_ElectronicRegistrationIdentificationVehicleDataModule-patched.asn' \
    "$IS_TS_ISO_DIR"/'ISO14823-missing.asn' \
    "$ADDITIONAL_MODULES_DIR"/'TS17419_2014_CITSapplMgmtIDs.asn' \
    "$IS_TS_ISO_DIR"/'ISO14906(2018)EfcDsrcGenericv7-patched.asn' \
    "$IS_TS_ISO_DIR"/'ISO14906(2018)EfcDsrcApplicationv6-patched.asn' \
    "$ADDITIONAL_MODULES_DIR"/'ISO-TS-19091-addgrp-C-2018-patched.asn' \
    "$ADDITIONAL_MODULES_DIR"/'ISO14816_AVIAEINumberingAndDataStructures.asn' \
    "$ADDITIONAL_MODULES_DIR"/'ISO19321IVIv2.asn'

  install -d "$VC_ITS_LIB_ROOT_DIR"/ivim/src
  mv "$VC_ITS_LIB_ROOT_DIR"/ivim/*.c "$VC_ITS_LIB_ROOT_DIR"/ivim/src/

  echo "Compiled PDU: IVIM"
}

Original ETSI forge source

One file is loaded twice.

if [ ! -f 'build/asn1/ISO14906(2018)EfcDsrcGenericv7.asn' ]; then
  wget -P build/asn1 'https://standards.iso.org/iso/14906/ed-3/en/ISO14906(2018)EfcDsrcGenericv7.asn'
fi
if [ ! -f 'build/asn1/TS17419_2014_CITSapplMgmtIDs.asn' ]; then
  wget -P build/asn1 'https://standards.iso.org/iso/ts/17419/TS%2017419%20ASN.1%20repository/TS17419_2014_CITSapplMgmtIDs.asn'
fi
if [ ! -f 'build/asn1/ISO14906(2018)EfcDsrcGenericv7.asn' ]; then
  wget -P build/asn1 'https://standards.iso.org/iso/14906/ed-3/en/ISO14906(2018)EfcDsrcGenericv7.asn'
fi

ISO14823-missing.asn will not be present

install -d build/ivim
asn1c -D build/ivim -R -no-gen-example -fcompound-names \
	'IVIM-PDU-Descriptions.asn' \
	'cdd/ITS-Container.asn' \
	'iso-patched/ISO24534-3_ElectronicRegistrationIdentificationVehicleDataModule-patched.asn' \
	'iso-patched/ISO14823-missing.asn' \
	'build/asn1/TS17419_2014_CITSapplMgmtIDs.asn' \
	'iso-patched/ISO14906(2018)EfcDsrcGenericv7-patched.asn' \
	'iso-patched/ISO14906(2018)EfcDsrcApplicationv6-patched.asn' \
	'build/asn1/ISO-TS-19091-addgrp-C-2018-patched.asn' \
	'build/asn1/ISO14816_AVIAEINumberingAndDataStructures.asn' \
	'build/asn1/ISO19321IVIv2.asn' \

Effects and Solution

The missing file does not seem to affect the library. However, there might be elements missing.

These might be the correct files.

Status

More information needed. There was not yet an issue. This is only an observation.

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.