What's New in the OSS ASN.1 Tools for C++

Applies to: ASN.1/C++ v7.3-7.3.1

What's New in ASN.1/C++ 7.3.1

New Features

New Samples

The following new 3GPP Release 18 samples have been created for the 5G and LTE protocols:

  • 5g_e1ap_r18 TS 37.483 V18.0.0 (2023-12)
  • 5g_f1ap_r18 TS 38.473 V18.0.0 (2023-12)
  • 5g_ngap_r18 TS 38.413 V18.0.0 (2023-12)
  • 5g_rrc_r18 TS 38.331 V18.0.0 (2023-12)
  • 5g_xnap_r18 TS 38.423 V18.0.0 (2023-12)
  • lte_rrc_cv2x_r18 TS 36.331 V18.0.0 (2023-12)
  • lte_rrc_nb_iot_r18 TS 36.331 V18.0.0 (2023-12)
  • lte_rrc_r18 TS 36.331 V18.0.0 (2023-12)
  • lte_s1ap_nb_iot_r18 TS 36.413 V18.0.0 (2023-12)
  • lte_s1ap_r18 TS 36.413 V18.0.0 (2023-12)
  • lte_x2ap_nb_iot_r18 TS 36.423 V18.0.0 (2023-12)
  • lte_x2ap_r18 TS 36.423 V18.0.0 (2023-12)


  • A carefully crafted malformed message passed to the time-optimized decoder could cause all subsequent calls to the decoder to fail to decode valid messages correctly. This problem has been fixed.
  • Further improvements have been made in the stack smashing protection mechanism of the error handling code in the SOED, TOED, and LED runtimes.

What's New in ASN.1/C++ 7.3


The following changes have been made to the ASN.1 compiler:

  • All reference type fields are now omitted when a reference type is used in the COMPONENTS OF Type notation of a field that appears after the extension marker within another reference type used in the COMPONENTS OF Type notation after the extension marker, as required by the ASN.1 standard.
  • PDU types that include nested types with ALL EXCEPT constraints within inner subtypes are now correctly handled when creating sample values. Previously, COMPILER ERROR #9 or other error messages could be issued.
  • ASN.1 values of BIT STRING types with named bit lists and size constraints are now correctly handled when the values are defined using one or more identifiers from the parent type list. These values can be present within the DEFAULT syntax, within a single value constraint, or nested within other values.
    The generated values now have the smallest possible length permitted by the size constraint, which includes the largest bit value from identifiers specified in the ASN.1 value definition. If the smallest length is greater than the largest bit value, the value is padded with trailing zero bits until it reaches the smallest length.
  • A warning is now issued when the same symbol is imported multiple times from the same module and the -designerWarnings command-line option is specified. Previously, duplicate symbols were silently ignored.
  • Module names are now included in conflicting PDU names created for types used in the DEFAULT syntax inside information object classes. Previously, module names were not used. The new v7.2PdusForTypesFromDEFAULTInsideInfoObjClass compat flag can be used to restore the old behavior.

In addition, the ASN.1/C++ Tools now includes ASN.1 Studio release 10.5.

What's New in ASN.1/C++ 7.2

New Features

The following changes have been made to the ASN.1 compiler:

  • The -2015 compiler option is now an alias of the new -2021 compiler option.
  • The ASN1.Version compiler directive accepts "2021" as an argument.
New API Methods
  • The SOED runtime now supports two new methods: PDU::asn2csv() and PDU::csv2asn(). These methods convert data encoded in an ASN.1 binary form (e.g., in BER, PER, DER, OER, etc.) to comma-separated values (CSV) text encoding form, and vice versa. For more information, see the online OSS ASN.1/C++ Product Documentation.
  • The TOED/RTOED runtime now supports two new methods: PDU::binary2AVN() and PDU::AVN2Binary(). These methods convert data encoded in an ASN.1 binary form (e.g., in BER, PER, DER, OER, etc.) to ASN.1 value notation (AVN) text encoding form, and vice versa. For more information, see the online OSS ASN.1/C++ Product Documentation.
New Samples

The ASN.1 Standards repository now includes ASN.1 specifications for 3GPP Release 17, as follows:

  • 5g_e1ap_r17 TS 37.483 V17.1.0 (2022-06)
  • 5g_f1ap_r17 TS 38.473 V17.1.0 (2022-06)
  • 5g_ngap_r17 TS 38.413 V17.1.1 (2022-06)
  • 5g_rrc_r17 TS 38.331 V17.1.0 (2022-07)
  • 5g_xnap_r17 TS 38.423 V17.1.0 (2022-06)
  • lte_lcsap_r17 TS 29.171 V17.0.0 (2022-03)
  • lte_lppa_r17 TS 36.455 V17.0.0 (2022-04)
  • lte_m2ap_r17 TS 36.443 V17.0.1 (2022-04)
  • lte_m3ap_r17 TS 36.444 V17.0.0 (2022-04)
  • lte_rrc_cv2x_r17 TS 36.331 V17.1.0 (2022-07)
  • lte_rrc_nb_iot_r17 TS 36.331 V17.1.0 (2022-07)
  • lte_rrc_r17 TS 36.331 V17.1.0 (2022-07)
  • lte_s1ap_nb_iot_r17 TS 36.413 V17.1.0 (2022-06)
  • lte_s1ap_r17 TS 36.413 V17.1.0 (2022-06)
  • lte_sbcap_r17 TS 29.168 V17.1.0 (2021-12)
  • lte_slmap_r17 TS 36.459 V17.0.0 (2022-04)
  • lte_x2ap_nb_iot_r17 TS 36.423 V17.1.0 (2022-06)
  • lte_x2ap_r17 TS 36.423 V17.1.0 (2022-06)
  • lte_xwap_r17 TS 36.463 V17.0.0 (2022-04)
  • umts_rrc_r17 TS 25.331 V17.1.0 (2022-07)


The new v7.1FieldNamesAndGlobalPrefix compat flag has been added. The flag can be used to restore generation of truncated names that match one of the reserved names when the OSS.DefineName directive is applied to the parent's field marked with OPTIONAL and the -prefix option is specified.

What's New in ASN.1/C++


  • Non-parameterized types that include nested references to parameterized types that are not yet defined, are imported using WITH SUCCESSORS, and used inside actual parameters with inner subtype constraints in instances of parameterized types are now correctly processed. Previously, warnings or errors about Parameterized<X> not being processed were issued in non-relaxed mode. The new compat flag, v7.1ForwardedNonParamReferencesImportedWithSuccessors, can be used to restore the old behavior of the ASN.1 compiler.
  • New artificial PDUs are now created for recursive types defined through a CONSTRAINED BY syntax inside parameterized types. Previously, COMPILER ERROR #22 could occur or types were missing in the generated code. The new compat flag, v7.1ArtificialPDUsForRecursivesTypes, can be used to restore the old behavior of the ASN.1 compiler.
  • A type used in a contents constraint included in an open type value is now correctly matched with a type used in an information object set specified in a component relation constraint. Previously, instead of using the existing type, the compiler created a new artificial PDU type for such open type values, which caused constraint violation errors. The new compat flag, v7.1ContentsConstraintInsideOpenTypeValue, can be used to restore the old behavior.

What's New in ASN.1/C++


The generated TOED decoder code will now always set the pointer to an extension addition in a decoded SEQUENCE/SET value to NULL when the following conditions hold:

  • The extension addition type is not an INTEGER, REAL, ENUMERATED, NULL, and SEQUENCE OF).
  • The extension addition is absent in the input message.

Previously in this case, the delete, copy, and "=" operator for a value containing such a decoded SEQUENCE/SET could have memory problems at runtime. The bug may or may not manifest itself depending on the memory layout at runtime. The problem can be demonstrated by the following specification:

    st ST
v S ::= { }

What's New in ASN.1/C++ 7.1

New Features

The Time-Optimized runtime (TOED) now supports the ASN.1 Value Notation encoding rules (AVN). The new ?avn compiler option instructs the compiler to generate encoding/decoding code for AVN. When the OSS_ASN1_VALUE_NOTATION rules are set by the OssControl::setEncodingRules() method, the PDU::decode() method decodes a PDU value represented in ASN.1 value notation text format and the PDU::encode() method encodes an in-memory PDU value to this format. ASN.1 value notation text format is similar to the format produced by the ASN1Handle::print() method. The getAVNFlags and setAVNFlags methods of the OssControl class and the OSS_AVN_DECODE_CONTAINED_IN_HEX and OSS_AVN_RESOLVE_OPEN_TYPE_BY_NAME C++-compiler macros are introduced to control the AVN encoder/decoder behavior.
NOTE: The support of ASN.1 Value Notation encoding rules is a chargeable feature in non-evaluation licenses. Contact Sales to obtain pricing information.

The TOED runtime now supports the new OssControl::unknownExtensionFound() method, which allows you to detect whether the last decoded PDU contained at least one unknown extension of a SEQUENCE/SET/CHOICE type. The presence of unknown extensions indicates that the sender is using a newer version of the ASN.1 specification. This feature is disabled by default due to some performance and size overhead. To enable it, C-compile the generated code using the -DOSS_DETECT_UNKNOWN_EXTENSION option.

The ASN.1/C++ RTOED runtime now supports the toString() and toStringLength() methods of the ASN1Handle class.

The new utility classes, OssBCD and OssTBCD, are added to the ASN.1/C++ runtime. The classes contain methods that perform data conversions between octet strings and BCD/TBCD strings.

New samples

The cam_denm sample has been updated to use the most recent version of the ASN.1 schema:

  • CAM ETSI EN 302 637-2 V1.4.1 (2019-04)
  • DENM ETSI EN 302 637-3 V1.3.1 (2019-04)
  • ITS-Container ETSI TS 102 894-2 V1.3.1 (2018-08)

The existing 3GPP Release 13 samples have been removed and other samples have been updated to newer versions of the ASN.1 schemas:

  • 5g_e1ap_r15 TS 38.463 V15.8.0 (2020-10)
  • 5g_e1ap_r16 TS 38.463 V16.5.0 (2021-04)
  • 5g_f1ap_r15 TS 38.473 V15.13.0 (2020-03)
  • 5g_f1ap_r16 TS 38.473 V16.4.1 (2021-03)
  • 5g_ngap_r15 TS 38.413 V15.11.0 (2021-04)
  • 5g_ngap_r16 TS 38.413 V16.5.0 (2021-04)
  • 5g_rrc_r15 TS 38.331 V15.13.0 (2021-03)
  • 5g_rrc_r16 TS 38.331 V16.4.1 (2021-03)
  • 5g_xnap_r15 TS 38.423 V15.11.0 (2021-04)
  • 5g_xnap_r16 TS 38.423 V16.5.0 (2021-04)
  • lte_lcsap_r14 TS 29.171 V14.3.0 (2019-09)
  • lte_lcsap_r15 TS 29.171 V15.5.1 (2021-03)
  • lte_lcsap_r16 TS 29.171 V16.2.0 (2020-12)
  • lte_lppa_r14 TS 36.455 V14.5.0 (2018-09)
  • lte_lppa_r15 TS 36.455 V15.2.1 (2019-01)
  • lte_lppa_r16 TS 36.455 V16.1.0 (2021-04)
  • lte_rrc_cv2x_r14 TS 36.331 V14.16.0 (2021-01)
  • lte_rrc_cv2x_r15 TS 36.331 V15.16.0 (2021-03)
  • lte_rrc_cv2x_r16 TS 36.331 V16.4.0 (2021-03)
  • lte_rrc_nb_iot_r14 TS 36.331 V14.16.0 (2021-01)
  • lte_rrc_nb_iot_r15 TS 36.331 V15.16.0 (2021-03)
  • lte_rrc_nb_iot_r16 TS 36.331 V16.4.0 (2021-03)
  • lte_rrc_r14 TS 36.331 V14.16.0 (2021-01)
  • lte_rrc_r15 TS 36.331 V15.16.0 (2021-03)
  • lte_rrc_r16 TS 36.331 V16.4.0 (2021-03)
  • lte_s1ap_nb_iot_r14 TS 36.413 V14.9.0 (2019-07)
  • lte_s1ap_nb_iot_r15 TS 36.413 V15.10.0 (2020-10)
  • lte_s1ap_nb_iot_r16 TS 36.413 V16.5.0 (2021-04)
  • lte_s1ap_r14 TS 36.413 V14.9.0 (2019-07)
  • lte_s1ap_r15 TS 36.413 V15.10.0 (2020-10)
  • lte_s1ap_r16 TS 36.413 V16.5.0 (2021-04)
  • lte_sbcap_r14 TS 29.168 V14.2.0 (2017-12)
  • lte_sbcap_r15 TS 29.168 V15.1.0 (2018-09)
  • lte_sbcap_r16 TS 29.168 V16.0.0 (2020-07)
  • lte_slmap_r15 TS 36.459 V15.0.0 (2018-01)
  • lte_slmap_r16 TS 36.459 V16.0.0 (2020-07)
  • lte_x2ap_nb_iot_r14 TS 36.423 V14.8.0 (2019-10)
  • lte_x2ap_nb_iot_r15 TS 36.423 V15.11.0 (2020-10)
  • lte_x2ap_nb_iot_r16 TS 36.423 V16.5.0 (2021-04)
  • lte_x2ap_r14 TS 36.423 V14.8.0 (2019-10)
  • lte_x2ap_r15 TS 36.423 V15.11.0 (2020-10)
  • lte_x2ap_r16 TS 36.423 V16.5.0 (2021-04)
  • lte_xwap_r14 TS 36.463 V14.2.0 (2017-06)
  • lte_xwap_r15 TS 36.463 V15.0.0 (2018-06)
  • lte_xwap_r16 TS 36.463 V16.0.0 (2020-07)
  • umts_rrc_r16 TS 25.331 V16.1.0 (2020-10)


The ASN.1 compiler now issues a warning when an untagged open type appears before the extension marker in an extensible type in violation of the tag uniqueness requirement (see X.680 clauses 25.7, 52.7.3, 52.7.4, X.681 14.2 b) NOTE 2).

The compiler now correctly considers extensible internal subtype constraints on TIME types as OER-invisible.

The ASN.1 compiler no longer issues an error about unresolved GlobalReferences in some cases when a type imported from another module using WITH SUCCESSORS is not yet defined.

The ASN.1 compiler no longer issues warnings about dummy parameters not being used when they are specified inside an inner subtype that is applied to a parameterized type whose right-hand side type includes an instance of another parameterized type that has imported forwarded references using WITH SUCCESSORS. Previously, constraints defined inside the inner subtype were ignored. The new v7.0.1ImportedWithSuccessorForwardedReferences compat flag can be used to restore the previous behavior.

The compiler now correctly generates TOED partial decoding functions for types with contents constraints.

The ASN.1 compiler now correctly generates TOED code when all the following conditions are met:

  • The -partialDecodeOnly option is specified.
  • The "old" non-Union open type representation is forced by the -extendopentype or -compat noUnionRepresentationForOpenType option or by a -compat vN.*.* option, where "N<10".
  • The -helperAPI option is specified.

When a field referenced by component relation constraints belongs to the same SEQUENCE or SET type as an open type field or to one of its subtypes, the TOED JSON decoder now automatically decodes the open type field when its encoding precedes the encoding of the referenced field. Note that this TOED decoder feature incurs some performance and decoder size overhead. When JSON encodings have open type fields that always follow their referenced fields (as is the case for JSON encodings produced by the OSS JSON encoders) this feature can be disabled to reduce the size and to increase the speed of the resulting application. To do so, C-compile the TOED code generated by the ASN.1 compiler using the -DOSS_OPENTYPE_PRECEDES_REFERENCED_FIELD_IN_JSON option.

When the value passed to the ASN1Handle::print() method contains a field that is invalid or does not satisfy the implementation restrictions, the method now returns a non-zero return code (126) and a meaningful error message, for example:
D0375E: An invalid PDU number in open type value.
D0375E: Decimal real value implementation limit exceeded.

The outdated _System macro has been removed from the header files included in the product installation. Previously, this macro could conflict with the macro defined in the MSVC xfilesystem_abi.h header.

The TOED UPER encoder no longer loses an octet at offset 1024 in the output buffer while encoding nested extension additions.

What's New in ASN.1/C++ 7.0.1

New Features

The OSS ASN.1 Tools for C++ now includes ASN.1 Studio 10.0.1. For a summary of the improvements in ASN.1 Studio 10.0.1, see the Enhancements History section.


The setFromValueNotation() method will now correctly initialize values for fields that have the DEFAULT syntax.

What's New in ASN.1/C++ 7.0

New Features

The new -rtoed compiler option instructs the compiler to generate code for the new RTOED runtime. In the generated code, all function pointers are now constant, so the C++ compiler toolchain can place them in read-only memory. This protects the pointers from being maliciously overwritten.

When the new EXER_ENCODING_OF_DEFAULT_VALUES_AS_COMMENTS encoding flag is set, the E-XER encoder will now encode absent DEFAULT fields as XML comments that contain the corresponding default values. Previously, the E-XER encoder ignored absent DEFAULT fields.
The new OSS_NO_EXER_ENCODING_OF_DEFAULT_VALUES_AS_COMMENTS macro can be used to control performance or the memory footprint when TOED is enabled. When it is defined while compiling the C++ codefile, the macro eliminates the code generated to encode these fields.


There is now improved protection from stack smashing in the error handling code of the SOED, TOED, and LED runtimes.

The Binary2XML(), XML2Binary(), Binary2JSON(), and JSON2Binary() SOED and LEAN conversion API methods can now report error D0373S and return the new CONVERSION_NOT_POSSIBLE return code. The methods perform the conversion by decoding and then re-encoding the input message using the other encoding rules. However, if some open type or contents constrained type remains in undecoded form the conversion becomes impossible. It could happen when component relation constraints cannot be resolved for an extensible open type or when the OSS.NoConstrain compiler directive is applied to an open type or contents constrained type.
Previously, these methods could leave some parts of the encoding in its original form, which produced an invalid output message.

The ASN.1 compiler will now generate PDUs for types derived from contents constraints that include a user-defined constraint applied to a recursively defined type. Previously, additional PDUs were not generated. When the -constraints option was specified with the default -toed option, an internal error could occur. To restore the names in the header file generated by previous compiler versions, use the standalone v6.7ContentsConstraintsWithRecursiveTypeInsideConstrainedBy compat flag.

The OSS ASN.1 runtime will now check whether the value of the day component of a TIME type corresponds to the number of days of the specified month. Previously, the runtime checked whether the value exceeded 31. Also, negative values for the year component are now rejected.

What's New in ASN.1/C++ 6.7

New Features

The ASN.1 compiler now supports X.680 Amendment 1, which relaxes the IMPORTS clause to allow symbols to be imported from the latest module version, as indicated by the object identifier. The IMPORTS clause can now include WITH SUCCESSORS and WITH DESCENDANTS as the SelectionOption.

The OSS.NOENCODE and OSS.NODECODE compiler directives have been added. They reduce the generated TOED code by excluding the encoding or decoding routines for the directive's operand. Under certain conditions, the generated code can be reduced even further using the new -compactNoDecode compiler option.

The JSON encoders now support an alternative form of encoding values of BIT STRING or OCTET STRING types with contents constraints when an ENCODED BY is absent. When you select this method, the values are encoded as text (the JSON value represents the contained value) rather than hex string.

Added support for partial decoding using a pre-allocated buffer.

New samples

New samples have been created for the following:

  • The DIN EN 15722 Intelligent transport systems - ESafety - ECall minimum set of data standard. The sample demonstrates how an ECallMessage message can be created and serialized to binary (UPER) and XML formats.
  • The eUICC Profile Package standard. The sample demonstrates how the eUICC Profile Package can be constructed and saved to the disk file in binary (DER) and text (JSON) formats.
  • The GSMA Remote SIM Provisioning standard. The sample demonstrates the RSP communication using the GetBoundProfilePackageRequest request to the SM-DP+ as an example.

New samples for the 5G NGAP, XnAP, E1AP, F1AP, and LTE SLmAP protocols for 3GPP Release 15 have been created. The samples for the LTE S1AP, X2AP, M2AP, M3AP, RRC, LCSAP, LPPa, SBcAP, and XwAP protocols have been updated to 3GPP Release 15.


Improved handling of types within inner subtype constraints with nested CONSTRAINED BY or contents constraints:

  1. A special type of absolute reference notation that allows you to access ASN.1 types located within WITH COMPONENTS and WITH COMPONENT (inner subtype) clauses and consists of two dollar signs ($$) followed by an index number indicating a particular WITH COMPONENTS or WITH COMPONENT is now supported. You can now assign user-defined names within CONSTRAINED BY clauses that are present within an inner subtype or a compiler-generated structure.
  2. When contents constraints are applied within an inner subtype constraint, the generated representations of the base type and the constrained type are now different. The ASN.1 compiler no longer uses the same name for both representations when the TYPENAME directive is applied to the base type. The new compat flag, oldTypesFromInnerSubtypeWithContentConstraints, can be used to restore the old behavior.
  3. The ASN.1/C++ compiler now preserves the same global define names and values that are generated for similar fields within artificial types created after applying a contents constraint within an inner subtype constraint. Previously, the define names were always mangled. To generate mangled names, you can use the v6.6DefineNamesForTypesFromInnerWithContentConstraints compat flag.

What's New in ASN.1/C++ 6.6

New Features

The OSS ASN.1 Tools for C++ now supports the Canonical Packed Encoding Rules (ALIGNED and UNALIGNED), as specified by ITU-T Recommendation X.691 (08/2021) | ISO/IEC 8825-2:2021.

The ASN.1 compiler supports the UPPERCAMELCASED and LOWERCAMELCASED keywords in the NAME and TEXT JER encoding instructions. You can now describe a wider range of JSON data in an ASN.1 schema.

New samples

New samples have been created for 3GPP Release 14 of the LTE protocols and the existing Release 12 and 13 samples have been updated to the most recent versions of the ASN.1 schema.

  • TS 29.171 (LCSAP) V13.3.0 (2017-06)
  • TS 29.171 (LCSAP) V14.1.0 (2017-06)
  • TS 36.455 (LPPA) V14.2.0 (2017-06)
  • TS 36.443 (M2AP) V13.3.0 (2016-04)
  • TS 36.443 (M2AP) V14.0.1 (2017-09)
  • TS 36.444 (M3AP) V14.1.0 (2017-06)
  • TS 36.331 (RRC CV2X) V14.4.0 (2017-09)
  • TS 36.331 (RRC NB IOT) V13.6.1 (2017-07)
  • TS 36.331 (RRC NB IOT) V14.4.0 (2017-09)
  • TS 36.331 (RRC) V12.15.0 (2017-09)
  • TS 36.331 (RRC) V13.6.1 (2017-17)
  • TS 36.331 (RRC) V14.4.0 (2017-09)
  • TS 36.413 (S1AP NB IOT) V13.6.0 (2017-06)
  • TS 36.413 (S1AP NB IOT) V14.3.0 (2016-07)
  • TS 36.413 (S1AP) V12.7.0 (2016-03)
  • TS 36.413 (S1AP) V13.6.0 (2017-06)
  • TS 36.413 (S1AP) V14.3.0 (2017-06)
  • TS 29.169 (SBCAP) V14.0.0 (2017-03)
  • TS 36.423 (X2AP NB IOT) V14.3.0 (2017-07)
  • TS 36.423 (X2AP) V12.9.0 (2016-07)
  • TS 36.423 (X2AP) V13.7.0 (2017-06)
  • TS 36.423 (X2AP) V14.3.0 (2017-07)
  • TS 36.463 (XWAP) V14.2.0 (2017-06)


Generated TOED code will now correctly call the _dp_bad_pdu() function when the -enablePartialDecode or -partialDecodeOnly option is specified and the OSS.ENCODEONLY directive is applied to a PDU. Previously, the wrong function name, _dps_bad_pdu(), was generated, and C++ compilation failed with the "C2065: '_dps_bad_pdu' : undeclared identifier ..." error.

The compiler will now instruct the runtime to issue more descriptive error messages when encoding or decoding cannot be performed because the -encodeOnly or -decodeOnly option is used or the OSS.ENCODEONLY or OSS.DECODEONLY directive is specified.

The JSON encoders now encode a non-special REAL value as a JSON number. Previously, it could be encoded as a JSON object. For example, value 3.14 of an unconstrained REAL type was encoded as {base10value: 3.14}. The JSON decoders now accept both encoding forms: JSON number and JSON objects.

The DER/CER/CXER/COER encoders now automatically convert any valid value of GeneralizedTime and UTCTime types to the canonical form specified by X.690 Clause 11.7 and 11.8. Previously it was assumed that the value to be encoded already satisfied the restrictions imposed on its encoding by these clauses. For example, the UTCTime value "171231235900Z" was accepted but "17122359Z" was rejected because the seconds component was absent.

The implementation of the ASN.1/C++ PER encoders is now fully consistent with ITU-T Recommendation X.691: "The restrictions imposed on the encoding of the generalized time and universal time types by Rec. ITU-T X.690 | ISO/IEC 8825-1, 11.7 and 11.8, shall apply here."
Previously, the encoding of GeneralizedTime and UTCTime values could deviate from the standard as follows:

  • When the input value contained a time differential, the time differential was incorrectly included in the encoding.
  • When the input value represented as a NULLTERM string did not contain a minutes or seconds component, the component was also omitted from the encoding.

What's New in ASN.1/C++ 6.5

New Features

JSON Encoding Rules support in the ASN.1/C++ compiler and the SOED, TOED, and LED runtime libraries now conforms to Draft ITU-T Recommendation X.jsoner. The existing -json command-line option now instructs the compiler to enable support for X.jsoner at runtime.

A new #define macro can be used to remove the error message text from TOED executables. By defining OSS_REDUCED_ERROR_MSGS when compiling the generated .cpp, error messages will consist of just the 5 character message prefix, instead of the full message. Alternatively, if OSSDEBUG=0 is defined, then the error message strings will be removed completely, leaving only the return code to determine which error occurred. These features can be used to reduce the executable size on platforms with limited resources.

New samples

Samples have been created for the following protocols:

  • LTE RRC NB-IoT release 13
  • LTE S1AP NB-IoT release 13
  • LTE X2AP NB-IoT release 13
  • 3GPP XwAP (TS 36.463)
  • J2735 2016-03 version
  • LCS Application Protocol (LCS-AP) TS 29.171 V13.2.0 (2016-03)
  • LTE Positioning Protocol A (LPPa) TS 36.455 V13.1.0 (2016-03)
  • LTE RRC Protocol TS 36.331 V14.2.2 (2017-03)


The Compiler now correctly generates inner constraints data for the SOED runtime when a presence constraint is empty in a component constraint applied to a DEFAULT field. Previously, the SOED runtime mistakenly reported a presence constraint violation when such a field was absent.

The OSS ASN.1/C++ Compiler now generates TOED E-XER decoding functions for SET types so that the SET destructor works correctly with decoded values where an optional SEQUENCE OF field is absent.

The OSS.DataCallback compiler directive will no longer suppress automatic TOED decoding of nested open type fields when the -enablePartialDecode or -partialDecodeOnly option is specified. Previously, such an open type value could be left undecoded in the "encoded" field of the type representation.

The OSS ASN.1 Compiler now correctly generates PER/OER TOED partial decoders when the -enablePartialDecode (-partialDecodeOnly) option is specified.

The SOED constraint checker now correctly handles multiple type constraints when a non optional component is omitted from a full specification. Previously, the constraint checker mistakenly reported a MultipleTypeConstraints violation in this case.

What's New in ASN.1/C++ 6.4

New Features

64-bit precision in TIME type fractions

The ASN.1/C++ Compiler and Runtime now support 64-bit precision (19-20 decimal digits) in TIME type fractions. The only visible change to the C++ API is that the OssTimePoint and OssDuration classes now use 64-bit integers to represent fractional values.


TIME type values with constraints

For ISO 8601 TIME type values with a property settings constraint that specifies "Basic=Date" and "Date=Y", "Date=YM", or "Date=YMD", with no Year settings:

  • The ASN.1/C++ Compiler now correctly generates an SOED control table and TOED functions.
  • The SOED/LEAN Octet Encoding Rules (OER) encoder/decoder now correctly encodes/decodes such values.
  • Previously, the OER encoder produced a verbose encoding instead of an optimized binary encoding.

ASN.1 standards conformance

The ASN.1/C++ SOED/LEAN/TOED PER encoder-decoder implementation now conforms to the recent X.691 corrigendum (2015): an encoding contained in a BIT STRING should be at least one octet for PER ALIGNED and 1 bit for PER UNALIGNED.

OER encoding of untagged CHOICE values is now aligned with Corrigendum 1 of the X.696 standard. Previously, such CHOICE values were encoded BER-style: the outermost tag of the chosen alternative was encoded only once.

The ASN.1/C++ runtime implementations are now aligned to conform to ITU-T X.680 Clause 46.3c. This clause states that the minutes component of a GeneralizedTime type value can be omitted when the difference between local time and UTC is an integral number of hours. Previously, a false error could be issued when the minutes component was absent.

What's New in ASN.1/C++ 6.3

New Features

Support for the JSON Encoding Rules

The ASN.1/C++ Compiler and the Space-Optimized Encoder/Decoder (SOED), Time-Optimized Encoder/Decoder (TOED), and Lean Encoder/Decoder (LED) Runtime libraries all support the JavaScript Object Notation (JSON) Encoding Rules. With JSON encoding rules, you can preserve the power of text (JSON) encodings, yet take advantage of the conversion to or from binary (ASN.1) encodings for fast transmission or compact storage.

New command-line option

The -json command-line option enables code generation for JSON.

New API functions

The PDU::binary2JSON() and PDU::JSON2Binary() methods have been added to convert data encoded in ASN.1 binary form (e.g., BER, PER, DER, OER, etc.) to JSON text encoding form and vice versa.

What's New in ASN.1/C++ 6.2.1


The ASN.1/C++ Tools for Windows packages now include binaries targeted for Microsoft Visual Studio 2015, along with those targeted for MVS2005 through MVS2013. All Microsoft Visual Studio versions (VS2005 through VS2015) are now in a single installer package.

What's New in ASN.1/C++ 6.2

New Features

Partial Decoding

The partial decode feature enables you to

  • Decode preselected fields from incoming messages at a high speed.
  • Directly access the decoded field in the callback method without traversing from the top of the PDU.
  • Get the offset and length of the field encoding in a binary BER/DER/OER/COER message. It allows you to replace the value of the field directly in the binary message, if the encoding of the new value is of the same length as of the previous one.

For more information, see Partial Decoding.

New Command-line Options

The -enablePartialDecode and the -partialDecodeOnly options instruct the compiler to generate code that enables the ConcretePDU::partialDecode() TOED Runtime API method. These options are available when the -toed option is specified or implied by default.

New Compiler Directives

The OSS.DataCallback and OSS.InfoCallback compiler directives have been added.

New API Methods

The ConcretePDU::partialDecode() and ossTestCPPPD() API methods have been added.

New Samples

You can find the partial_decode and s1ap_pd_r12 samples that illustrate the partial decoding feature usage in the samples/advanced.

The provided set of samples has been updated:

  • The new standards/cam_denm sample shows you how to handle CAM and DENM messages specified by the ETSI EN 302 637-2, ETSI EN 302 637-3, and ETSI TS 102 894-2 standards.
  • The LTE samples for 3GPP Release 12 (RRC, S1AP, X2AP, M2AP, M3AP, SbcAP) have been added.

What's New in ASN.1/C++ 6.1

New Features

Enhanced OER Support

The ASN.1/C++ Compiler and the TOED, SOED, and LED Runtimes have all been augmented to support OER as defined in "Rec. ITU-T X.696 | ISO/IEC 8825-7", rather than only the subset of ASN.1 types as defined in the "NTCIP 1102:2004 Octet Encoding Rules (OER) Base Protocol" document.

The Canonical Octet Encoding Rules (COER) as defined in "Rec. ITU-T X.696 | ISO/IEC 8825-7" are now supported by the ASN.1/C++ Compiler and the TOED, SOED, and LED Runtimes.

Sample Code Generation

The ASN.1 C++ Compiler can now generate sample code for a user-provided asn1 specification. The sample code is an application that uses the C++ interface of the runtime to encode/decode generated values that conform to the specification.

New Samples
  • Samples that illustrate use of the SBc-AP, M2AP, and M3AP LTE protocols based on 3GPP Release 11.
  • A sample that illustrates using the DSRC Message Set Standard, SAE J2735_200911.
Default Error Handling

The default error handling mechanism is now "full-exception mode". Therefore, legacy code written for C++ runtimes v6.0 and older using "no-exception mode" default error handling should be modified to either catch exceptions of the new ASN1RuntimeException class or revert to "no-exception mode". To revert to the legacy "no-exception mode", add the following line before instantiating or calling any OSS ASN1 objects or functions:

Non-breaking Spaces

The ASN.1/C++ Compiler now supports non-breaking spaces in the input ASN.1 syntax as UTF-8 format Unicode characters. Other Unicode characters that are treated as spaces are supported in UTF-8 format as well.


The ASN.1/C++ Compiler now generates huge values of base 2 REAL types without losing precision.

Choice alternatives containing an untagged choice are now canonically ordered correctly by the compiler.

The ASN.1/C++ Compiler now accepts GeneralizedTime values where the minutes and seconds components are omitted and a time difference component is present.

The compiler now accepts comments within compiler command files. The "--" characters specify the beginning of a comment and can be placed anywhere on the line. The comment continues until either a subsequent "--" is reached or the line ends.

What's New in ASN.1/C++ 6.0

New Features

Octet Encoding Rules (OER) Support

Support for the Octet Encoding Rules (OER), as specified by the NTCIP 1102:2004 Octet Encoding Rules (OER) Base Protocol document, has been implemented in the ASN.1/C++ Compiler, the TOED, and ASN.1 Studio.

OER messages can generally be encoded/decoded significantly faster compared to BER and PER messages, while being only slightly less compact than PER messages.

Decode Open Types without AUTOMATIC_ENCDEC

Decode open types with table (component relation) constraints, without setting the AUTOMATIC_ENCDEC runtime flag. The compiler now generates a class derived from the OssConstrainedOpenType class when an open type has a table constraint applied that restricts the set of possible types the open type can contain.

New Methods
  • New methods have been added to support decoding into preallocated memory buffers:

    Generated files now contain the following additional methods:

    void set_const_data(const <Type> & d);
    const <Type> *get_const_data() const;


    void set_const_<Type> (const <Type> &);
    const <Type> *get_const_<Type>() const;

    This method has been added to the PDU class:

    virtual int decode(OssControl &ctl, EncodedData &input, EncodedBuffer &output);

    The following method has been added to the ASN1Handle class:

    int is_constant() const;

    Two methods have been added to the OssOpen class, which replace the previous get_decoded() method:

    int get_decoded_data(PDU &);
    int get_decoded_data(PDU &) const.

  • The reset() method has been added to the EncodedBuffer and the PEREncodedBuffer classes. Use this method to reset the buffer to its initial state when you want to reuse the same buffer for the output of several encoding/decoding operations.

  • Two methods have been added to the ASN1Handle class:

    This method prints the data contained in ASN1Handle to a specified pre- or newly allocated memory buffer in ASN.1 value notation format:

    char *toString(OssControl &ctl, char *buffer = NULL, unsigned long length = 0) const;

    This method returns the size of the memory buffer required by the first function to print the data:

    unsigned long toStringLength(OssControl & ctl) const.

  • Two methods have been added to the EncodedBuffer class:

    The following method pretty-prints the data contained in EncodedBuffer in hexadecimal format

    int print_hex(OssControl & ctl) const;

    The following method prints the data contained in EncodedBuffer in XML format:

    int print_xml(OssControl & ctl, int pretty-print) const.
New Samples

Samples illustrating the use of protocols based on the SAE J2735 Intelligent Transportation standard, as well as the RRC, S1AP, and X2AP LTE protocols based on 3GPP Release 10 have been added.


The SOED decoders will now fill in an open type pduNum field unless the NOCONSTRAIN runtime flag is set. Previously, the decoders did not fill in the pduNum field for new (union based) open types when the AUTOMATIC_ENCDEC flag was not set.

Some methods (decode, encode, pre_decode, etc.) will now return new error codes and messages when memory manager errors occur. Previously, most such errors produced the common FATAL_ERROR (18) error code and an error message such as "x0087S: Undefined memory-management error #N.". To check for a specific error you had to parse the message and extract the #N value.

This documentation applies to release 7.3 and later of the OSS® ASN.1 Tools for C++.

Copyright © 2024 OSS Nokalva, Inc. All rights reserved.
No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or by any means electronic, mechanical, photocopying, recording or otherwise, without the prior permission of OSS Nokalva, Inc.
Every distributed copy of the OSS® ASN.1 Tools for C++ is associated with a specific license and related unique license number. That license determines, among other things, what functions of the OSS ASN.1 Tools for C++ are available to you.