Ukraine We stand with Ukraine

TOP
home | What's New | Installing the Tools | Getting Started | Knowledge Center | Standards Conformance

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

Applies to: ASN.1/C v11.3-11.3.1

Contents

What's New in ASN.1/C 11.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)

Improvements

  • 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 11.3

Improvements

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

  • 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 a 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.
  • 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.
  • Module names are now included in conflicting PDU names created for types used in a DEFAULT syntax inside information object classes. Previously, module names were not used. The new v11.2PdusForTypesFromDEFAULTInsideInfoObjClass compat flag can be used to restore the previous behavior.

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

What's New in ASN.1/C 11.2

New Features

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

  • Additional RTOED code is now generated to enable or disable support for the Memory Handling API. To enable support for the RTOED Memory Handling API, specify the -DOSS_RTOED_MEMORY_HANDLES_SUPPORTED option when you compile the RTOED code file for your application. By default, RTOED Memory Handling API support is disabled, which can reduce the application code size by approximately 4Kb.
  • The -2015 compiler option is now an alias of the new -2021 compiler option.
  • The ASN1.Version compiler directive now accepts "2021" as an argument.
New API functions

The TOED/RTOED runtime supports the following new functions:

  • ossBinary2AVN(), which is used to convert data encoded in ASN.1 binary form (e.g., BER, PER, DER, OER, etc.) to ASN.1 value notation (AVN) text encoding.
  • ossAVN2Binary(), which is used to convert data encoded in ASN.1 value notation (AVN) to ASN.1 binary form (e.g., BER, PER, DER, OER, etc.).
New IAAPI functions
  • ossASN2CSV(), which converts an ASN.1 encoded PDU to Comma-Separated-Value format.
  • ossCSV2ASN(), which converts an encoded PDU from Comma-Separated-Value format to ASN.1.
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)

Improvements

The new v11.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 11.1.0.2

Improvements

The following compat flags have been added:

What's New in ASN.1/C 11.1.0.1

Improvements

The following -compat flags have been added:

What's New in ASN.1/C 11.1

New Features

ASN.1 Value Notation encoding rules (AVN)
  • 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 ossSetEncodingRules() API function, the ossDecode() function decodes a PDU value represented in ASN.1 value notation text format and the ossEncode() function encodes an in-memory PDU value to this format. ASN.1 value notation text format is similar to the format produced by the ossPrintPDU() API function.
    The ossGetAVNFlags() and ossSetAVNFlags() API functions 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: Support of ASN.1 Value Notation encoding rules is a chargeable feature in non-evaluation licenses. Contact Sales to obtain pricing information.
New API functions
  • The OSS TOED runtime supports the ossUnknownExtensionFound(OssGlobal *world) API function, which allows you to detect whether the last PDU decoded by the ossDecode() function contained at least one unknown SEQUENCE, SET, or CHOICE type extension. The presence of unknown extensions indicates that the sender is using a newer ASN.1 specification version. 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 ossPrintPDUToBuffer() and ossDeterminePDUBufferLength() API functions.
Interpretive ASN.1 API (IAAPI) enhancements
  • Functions that convert decoded internal format values into CSV format support the OSS_SKIP_EMPTY_CSV setting, which instructs the CSV encoder to skip CSVs that include only column separators and spaces, that is, CSVs with empty values for all nested simple types.
  • When OCTET STRING values marked with OSS.PrintFunctionName directives cannot be converted to the specified OSS format, IAAPI functions that convert decoded internal format values into CSV format now include the original value in hexadecimal format, prefixed with the ??? string, in the output CSV. Functions used to decode CSVs ignore the ??? prefix, skip conversion, and process such values as hstrings. For backward compatibility, the OSS_EMPTY_OCTSTR_IF_CONVERSION_FAILS flag is supported.
  • The limit of 50 on the user-specified maximum number of CSVs created for multiple components of each SET OF and SEQUENCE OF type value has been removed in functions that convert decoded internal format values into CSV format. The ossSetCsvSetting() function can be used to set a user-specified maximum for the OSS_CSV_MAX_SET_OF_SEQ_OF_COMPONENTS setting. The total number of additional CSVs for all SET OF and SEQUENCE OF types is limited to the maximum between the user-specified number and 50, multiplied by 50.
  • The ossGetComponentByAbsRef() and ossPutComponentByAbsRef() functions now accept absolute references generated by the ossGetCsvOfPDU() and ossGetCsvOfType() functions in a new extended CSV header format. They now support the "*" token for unnamed SET OF and SEQUENCE OF type value components, which is equivalent to "1", and PDU names or numbers inside parentheses for open type values and type values with contents constraints.
  • The ossGetComponentByAbsRef() now supports absolute references prefixed with a typereference name that is not a PDU.
  • IAAPI functions used for CSV conversion support the new CSV header format that includes the OSS_CHR_ABREF_EXTENDED identifier. The identifier is equivalent to OSS_CHR_ABREF, except for the following additions that can also be set separately using the OSS_CSV_FLAGS identifier:
    • The PDU name prefix is used for all nodes in the CSV header.
    • The "*" token is used for unnamed SET OF and SEQUENCE OF type components.
    • A component's index that starts with "1" is used for unnamed of SET, SEQUENCE, and CHOICE type components.
  • Functions that convert decoded internal format values into CSV format support the OSS_CSV_ALL_MAX setting, which is used to specify the maximum number of all CSVs to create for a top-level PDU type value that can include multiple components for multiple SET OF and SEQUENCE OF type values for which additional CSVs are created.

NOTE: IAAPI functions are not supported in the Time-Optimized Encoder/Decoder library (TOED), which is the runtime library used by default.

Updated 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)

Improvements

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

  • 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.
  • Extensible internal subtype constraints on TIME types are now correctly considered as OER-invisible.
  • A warning is now issued when an untagged open type precedes 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).
  • An error about unresolved GlobalReferences is no longer issued in some cases when a type imported from another module using WITH SUCCESSORS is not yet defined.
  • 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 are no longer issued. The new v11.0ImportedWithSuccessorForwardedReferences compat flag can be used to restore the previous behavior.
  • TOED code is now correctly generated 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.
  • TOED partial decoding functions are now correctly generated for types that include contents constraints.

The following corrections have been made to the OSS ASN.1 runtime:

  • The ossConvertOctetToIPAddress() API function now correctly converts the hexadecimal representation of an IP address to "*.*.*.*" decimal representation.
  • When the value passed to the ossPrintPDU() function contains a field that is invalid or does not satisfy the implementation restrictions, the function now returns a non-zero return code (126) and a meaningful error message, for example:
    "D0375E: An invalid PDU number in open type value."
    or
    "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 omits an octet at offset 1024 in the output buffer while encoding nested extension additions.

What's New in ASN.1/C 11.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.
  • There is now improved protection from stack smashing in the error handling code of the SOED, TOED, and LED runtimes.
  • 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. The new OSS_NO_EXER_ENCODING_OF_DEFAULT_VALUES_AS_COMMENTS macro can be used to control performance or memory footprint when TOED is enabled.

    • Improvements

  • The compiler will now generate additional TOED code that enables the ossBinary2XML(), ossXML2Binary(), ossBinary2JSON(), and ossJSON2Binary() OSS conversion API functions to always report the D0373S error and return the CONVERSION_NOT_POSSIBLE error code when a proper conversion is not possible due to any of the following reasons:
    • Component relation constraints cannot be resolved for an extensible open type.
    • The OSS.NoConstrain compiler directive is applied to an open type or a contents constrained type.
    • When you use the TOED library without specifying the -autoencdec or -constr option at ASN.1 compile time.
    Previously, these functions could leave some parts of the encoding in its original form, thus an invalid output message was produced.
    When the application does not need these conversion functions and you link with the TOED library, compile the generated code file using the -DOSS_NO_BINARY_TEXT_API_CHECKS option to reduce the code size.
  • The order of the typedefs generated for shared open types derived from component relation constraints that are present within a contents constraint applied to a BIT STRING or OCTET will no longer cause C-compilation errors. The problem could occur when the default union representation was used for decoded values of open types. A new compat flag, v10.7OrderOfSharedTypedefsForOpenTypes, can be used to restore the order of typedefs generated by previous ASN.1 compiler versions.
  • The ASN.1 compiler will now generate sample code that refers to the correct constants for named bits when the input syntax includes several BIT STRING types that contain a NamedBitList syntax.
  • 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.
  • When an OSS.PrintFunctionName directive that contains an OSS conversion function specified as a parameter is applied to OCTET STRING types and conversion is possible, the value notation will now include the actual BCD, TBCD, ASCII, IP address, or time stamp values inside an ASN.1 comment.

What's New in ASN.1/C 10.7

New Features

Support for X.680 Amendment 1

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

A special type of absolute reference notation

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.

An alternative form of encoding values

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

New compiler directives

The OSS.JEREncodeFunction directive allows you to customize a JSON encoding of an ASN.1 type using a user-provided function that will generate the custom encoding. Note that the OSS.JEREncodeFunction directive is available only when the -soed or -toed compiler option is specified.

The OSS.NOENCODE and OSS.NODECODE compiler directives 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.

New compiler options

The -compactNoDecode compiler option instructs the compiler to generate a compact version of the Time-Optimized Decoder code for fields marked with the OSS.NODECODE directive.

The -jer command-line option is now an alias for the -json command-line option.

New samples
  • A sample for the DIN EN 15722 Intelligent transport systems - ESafety - ECall minimum set of data standard. The sample demonstrates how the ECallMessage message can be created and serialized to binary (UPER) and XML formats.
  • A sample for 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.
  • A sample for 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 have been created for release 15 of the LTE and 5G protocols and the existing samples for releases 13 and 14 have been updated to the most recent versions of the ASN.1 schemas available. The samples for release 12 of the LTE protocols have been removed.

  • 5g_e1ap_r15 TS 38.463 V15.1.0 (2018-09)
  • 5g_e1ap_r15 TS 38.463 V15.3.0 (2018-09)
  • 5g_f1ap_r15 TS 38.473 V15.3.0 (2018-09)
  • 5g_ngap_r15 TS 38.413 V15.1.0 (2018-09)
  • 5g_xnap_r15 TS 38.423 V15.1.0 (2018-09)
  • lte_lcsap_r13 TS 29.171 V13.3.0 (2017-06)
  • lte_lcsap_r14 TS 29.171 V14.2.0 (2017-12)
  • lte_lcsap_r15 TS 29.171 V15.1.0 (2018-09)
  • lte_lppa_r13 TS 36.455 V13.1.0 (2016-03)
  • lte_lppa_r14 TS 36.455 V14.5.0 (2018-09)
  • lte_lppa_r15 TS 36.455 V15.1.0 (2018-09)
  • lte_m2ap_r13 TS 36.443 V13.3.0 (2016-03)
  • lte_m2ap_r14 TS 36.443 V14.1.0 (2018-09)
  • lte_m2ap_r15 TS 36.443 V15.0.0 (2018-09)
  • lte_m3ap_r13 TS 36.444 V13.2.0 (2016-03)
  • lte_m3ap_r14 TS 36.444 V14.1.0 (2017-06)
  • lte_m3ap_r15 TS 36.444 V15.0.0 (2018-09)
  • lte_rrc_cv2x_r14 TS 36.331 V14.8.0 (2018-09)
  • lte_rrc_nb_iot_r13 TS 36.331 V13.10.0 (2018-07)
  • lte_rrc_nb_iot_r14 TS 36.331 V14.8.0 (2018-09)
  • lte_rrc_r13 TS 36.331 V13.11.0 (2018-09)
  • lte_rrc_r14 TS 36.331 V14.8.0 (2018-09)
  • lte_rrc_r15 TS 36.331 V15.3.0 (2018-09)
  • lte_s1ap_nb_iot_r13 TS 36.413 V13.7.0 (2018-06)
  • lte_s1ap_nb_iot_r14 TS 36.413 V14.7.0 (2018-09)
  • lte_s1ap_r13 TS 36.413 V13.7.0 (2018-06)
  • lte_s1ap_r14 TS 36.413 V14.7.0 (2018-09)
  • lte_s1ap_r15 TS 36.413 V15.3.0 (2018-09)
  • lte_sbcap_r13 TS 29.168 V13.3.0 (2017-09)
  • lte_sbcap_r14 TS 29.168 V14.2.0 (2017-12)
  • lte_sbcap_r15 TS 29.168 V15.1.0 (2018-09)
  • lte_slmap_r15 TS 36.459 V15.0.0 (2018-01)
  • lte_x2ap_nb_iot_r13 TS 36.423 V13.7.0 (2017-06)
  • lte_x2ap_nb_iot_r14 TS 36.423 V14.6.0 (2018-06)
  • lte_x2ap_r13 TS 36.423 V13.7.0 (2017-06)
  • lte_x2ap_r14 TS 36.423 V14.6.0 (2018-06)
  • lte_x2ap_r15 TS 36.423 V15.3.0 (2018-09)
  • lte_xwap_r13 TS 36.463 V13.1.0 (2016-07)
  • lte_xwap_r14 TS 36.463 V14.2.0 (2017-06)
  • lte_xwap_r15 TS 36.463 V15.0.0 (2018-06)

Improvements

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

  1. The ASN.1 compiler now generates user-defined functions for fields to which a CONSTRAINED BY included within a WITH COMPONENTS syntax is applied. The new compat flag, noConstrainedByFunctionsFromInnerSubtype, can be used to generate a user-defined function for the parent type.
  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 previous behavior.
  3. The ASN.1 compiler no longer generates structures with additional pointers for circularly defined types with contents constraints applied within inner subtypes in helper mode. The new compat flag, v10.6PointeredTypesFromInnerWithContentConstraints, can be used to restore the previous behavior.
  4. 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. To generate mangled names, use the v10.6DefineNamesForTypesFromInnerWithContentConstraints compat flag.
  5. The ASN.1/C compiler now generates correct header files when the -splitHeader option is specified with the -c++ or -dualHeaders option and the input ASN.1 syntax includes an inner subtype and a contents constraint or a CONSTRAINED BY constraint. The oldLocationOfTypesFromInnerWithContentConstraints compat flag can be used to restore the previous behavior.

What's New in ASN.1/C 10.6

New Features

Support for CPER

Support for the Canonical Packed Encoding Rules (ALIGNED and UNALIGNED) as specified by ITU-T Recommendation X.691 (08/2015) | ISO/IEC 8825-2:2015 has been added.

For better security, the CPER decoder operates in a strict mode: every deviation from the X.691 standard requirements is reported.

The JSON encoders 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.

New compiler options

To enable support for CPER, use the new compiler options: -cper and -cuper.

New samples

A new sample that demonstrates processing of CDR files described by 3GPP TS 32.297 has been added. 3GPP CDR files contain a non-ASN.1 file header and non-ASN.1 record headers while record bodies are encoded by one of the ASN.1 encoding rules (BER, PER unaligned, PER aligned, or XER).

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:

  • lte_lcsap_r13 TS 29.171 V13.3.0 (2017-06)
  • lte_lcsap_r14 TS 29.171 V14.1.0 (2017-06)
  • lte_lppa_r13 TS 36.455 V13.1.0 (2016-03)
  • lte_lppa_r14 TS 36.455 V14.3.0 (2017-09)
  • lte_m2ap_r12 TS 36.443 V12.2.0 (2015-03)
  • lte_m2ap_r13 TS 36.443 V13.3.0 (2016-03)
  • lte_m2ap_r14 TS 36.443 V14.0.1 (2017-09)
  • lte_m3ap_r12 TS 36.444 V12.2.0 (2015-03)
  • lte_m3ap_r13 TS 36.444 V13.2.0 (2016-03)
  • lte_m3ap_r14 TS 36.444 V14.1.0 (2017-06)
  • lte_rrc_cv2x_r14 TS 36.331 V14.4.0 (2017-09)
  • lte_rrc_nb_iot_r13 TS 36.331 V13.7.1 (2017-09)
  • lte_rrc_nb_iot_r14 TS 36.331 V14.4.0 (2017-09)
  • lte_rrc_r12 TS 36.331 V12.15.1 (2017-09)
  • lte_rrc_r13 TS 36.331 V13.7.1 (2017-09)
  • lte_rrc_r14 TS 36.331 V14.4.0 (2017-09)
  • lte_s1ap_nb_iot_r13 TS 36.413 V13.6.0 (2017-06)
  • lte_s1ap_nb_iot_r14 TS 36.413 V14.4.0 (2017-10)
  • lte_s1ap_r12 TS 36.413 V12.7.0 (2016-03)
  • lte_s1ap_r13 TS 36.413 V13.6.0 (2017-06)
  • lte_s1ap_r14 TS 36.413 V14.4.0 (2017-10)
  • lte_sbcap_r12 TS 29.168 V12.10.0 (2017-09)
  • lte_sbcap_r13 TS 29.168 V13.3.0 (2017-09)
  • lte_sbcap_r14 TS 29.168 V14.1.0 (2017-09)
  • lte_x2ap_nb_iot_r13 TS 36.423 V13.7.0 (2017-06)
  • lte_x2ap_nb_iot_r14 TS 36.423 V14.4.0 (2017-09)
  • lte_x2ap_r12 TS 36.423 V12.9.0 (2016-07)
  • lte_x2ap_r13 TS 36.423 V13.7.0 (2017-06)
  • lte_x2ap_r14 TS 36.423 V14.4.0 (2017-09)
  • lte_xwap_r13 TS 36.463 V13.1.0 (2016-07)
  • lte_xwap_r14 TS 36.463 V14.2.0 (2017-06)

Improvements

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.

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.

What's New in ASN.1/C 10.5

New Features

Conformance to Draft ITU-T Recommendation X.jsoner

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

The JSON codec supports the following encoding instructions:

  • JER:ARRAY
  • JER:BASE64
  • JER:NAME
  • JER:OBJECT
  • JER:TEXT
  • JER:UNWRAPPED
Smaller TOED footprint

By defining OSS_REDUCED_ERROR_MSGS when compiling the generated .c, error messages will contain just the 5 character message prefix, instead of the full message. Alternatively, if OSSDEBUG=0 is defined, the error message strings will be removed completely, leaving only the return code to determine which error occurred. On Linux x86, you can reduce the footprint of your application by approximately 20 kilobytes. This number may vary depending on the processor, operating system, and C compiler.

New samples

The following samples have been added for the LTE protocols:

What's New in ASN.1/C 10.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.

New samples

The its_sae_j2735_2016 sample for the 2016-03 version of the J2735 protocol has been created. The sample does not include the J2735:2016 ASN.1 specification due to licensing reasons. Users should obtain it directly from the ITS SAE site.

A sample for the 3GPP XwAP (TS 36.463) protocol has been created.

Improvements

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.

The name of the OSS_ALLOW_ABSENT_OR_BAD_SECONDS_OR_ABSENT_Z runtime compatibility flag has been changed to OSS_ALLOW_ABSENT_OR_BAD_SECONDS; the original name was deemed somewhat misleading. For backward compatibility, the previous name is still available.

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 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 10.3

New Features

The following new features have been added:

Support for the JSON Encoding Rules

Support for the JSON Encoding Rules is available in all three runtime libraries of the OSS ASN.1/C Tools: Space-Optimized Encoder/Decoder (SOED), Time-Optimized Encoder/Decoder (TOED), and Lean Encoder/Decoder (LED). With JSON, 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 generation of code for JSON.

New API functions

The ossBinary2JSON() and ossJSON2Binary() API functions have been added to convert data encoded in ASN.1 binary form (e.g., BER, PER, DER, OER, etc.) to JSON text encoding form (JSON) and vice versa.

The ossPrintJSON() API function is now supported. This function allows you to print the contents of a JSON encoding in a well-formatted manner.

Also, the following API functions have been added:

New IAAPI functions

The ossDetectCDRHeaders() IAAPI function accepts the input buffer with BER-based encoded messages and returns information stored in CDR headers when a supported format is detected.

The following IAAPI functions for converting to and from CSV have been added:

  • ossClearCsvSettings()
  • ossGetCsvSetting()
  • ossSetCsvSetting()
  • ossSetDefaultCsvSettings()
  • ossConvertCsvToPduValue()
  • ossConvertCsvToTypeValue()
  • ossConvertPduValueToCsv()
  • ossConvertTypeValueToCsv()
  • ossGetNumberOfExtraCsvs()
New IAAPI flag

The TLV_NOCDRHEADERS IAAPI flag suppresses automatic detection of CDR headers.

Improvements

IAAPI improvements

IAAPI functions that print BER-encoded messages in TLV format now automatically detect and skip CDR headers.

The following CDR formats are supported:

  • CDR files consisting of a CDR file header and CDR records with a CDR record header before each BER-based message.
  • CDR files consisting of CDR record headers that hold the record identifier in the first two octets and the record length in the next two octets.
Samples improvements

The samples for Releases 10, 11, and 12 have been updated to the latest versions of the standards. New samples for 3GPP LTE Release 13 have been added.

What's New in ASN.1/C 10.2

New Features

The following new features have been added:

Partial Decoding

The partial decoding feature enables you to:

  • Decode preselected fields from incoming messages at a high speed.
  • Directly access the decoded field in the callback function 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.

The partial decoding feature requires TOED runtime version 10.2 or later and it is available upon request. For information about purchasing the license, contact Sales <info@oss.com>.

For more information, see the Partial Decoding section.

New command-line options

The -enablePartialDecode and -partialDecodeOnly options instruct the compiler to generate code that enables the ossPartialDecode() TOED runtime API function. The options are available if 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 functions

The ossPartialDecode() and ossTestPD() API functions have been added.

The following API utility functions that support BCD and TBCD encodings have been added to the ASN.1/C runtime libraries. The functions print octet-aligned data as BCD or TBCD strings and convert octet strings to or from BCD or TBCD strings.

  • ossPrintOctetAsBCDString()
  • ossPrintOctetAsTBCDString()
  • ossConvertOctetToBCDString()
  • ossConvertOctetToTBCDString()
  • ossConvertBCDStringToOctet()
  • ossConvertTBCDStringToOctet()
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/tap3_bin2xml sample demonstrates conversion from binary (BER) encoding to XML (XER) encoding. It uses the ASN.1 specification from the standards/tap3 sample.
  • 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.

Improvements

The ossCreateUnencodedValueOfPDU() and ossCreateUnencodedValueOfType() IAAPI functions now create unencoded values for PDU types that have a CONTAINING clause inside ASN.1 types with ContentsConstraint.

What's New in ASN.1/C 10.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.

Support for 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.

New command-line options

The new -useQualifiedNames compiler option instructs the ASN.1 compiler to add a prefix, depending on the type name, to:

  • enumerators generated for an ENUMERATED ASN.1 type
  • constants generated for named numbers of an INTEGER type
  • constants generated for named bits of a BIT STRING type

Improvements

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 is changed so as to now accept 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 10.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 SOED, TOED, and IAAPI runtime libraries, ASN.1 Studio, and CAGL.

OER messages can generally be encoded/decoded significantly faster compared to BER and PER messages, while being only slightly less compact than PER messages. Support for OER in ASN.1/C LED will be provided in the next release.

New utility API functions

Two new utility API functions are provided:

  • ossPrintPDUToBuffer() serializes the content of the compiler-generated structures (before encoding or after decoding) into standard ASN.1 value notation format and then writes it into the output buffer; this function is similar to ossPrintPDU(), which writes to the standard output.
  • ossDeterminePDUBufferLength() is used to determine the length of the output buffer (in bytes) required by ossPrintPDUToBuffer().
New samples

The set of samples provided includes new 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.

Improvements

You can now decode open types with table (component relation) constraints, without setting the AUTOMATIC_ENCDEC runtime flag.

The compiler will now generate TOED decoding functions so that even when the AUTOMATIC_ENCDEC runtime flag is not set, the decoder resolves component relation constraints and sets the pduNum field of the OpenType structure accordingly. The field is set to zero when neither the -autoencdec nor the -constr compiler options are specified, or when the NOCONSTRAIN runtime flag is set.

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

The compiler will now implicitly turn on the -debug option while generating TOED functions even when the -lean option is specified. Previously, the -lean option suppressed the implicit -debug option. As a result, the TOED printing functions were not generated unless -debug was specified explicitly.

Some OSS API functions (ossDecode(), ossEncode(), ossSkipPadBytes(), ossBinary2XML(), ossXML2Binary(), etc.) will now return new error codes and messages when file/socket 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 the OSS® ASN.1 Tools for C release 11.3 and later.

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 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 are available to you.