Currently, there is no code generated for following ASN.1 excerpt.
Thus application is not aware of these values.

    ProtocolIE-ID ::= INTEGER (0..65535)

    id-MME-UE-S1AP-ID  ProtocolIE-ID ::= 0
    id-HandoverType    ProtocolIE-ID ::= 1
    id-Cause           ProtocolIE-ID ::= 2
    id-SourceID        ProtocolIE-ID ::= 3
      ...

    ProcedureCode ::= INTEGER (0..255)

    id-HandoverPreparation         ProcedureCode ::= 0
    id-HandoverResourceAllocation  ProcedureCode ::= 1
    id-HandoverNotification        ProcedureCode ::= 2
    id-PathSwitchRequest           ProcedureCode ::= 3
    ...

This commit adds corresponding macro definitions in
ProtocolIE-ID.h and ProcedureCode.h respectively.

    #define ProtocolIE_ID_id_MME_UE_S1AP_ID       ((ProtocolIE_ID_t)0)
    #define ProtocolIE_ID_id_HandoverType ((ProtocolIE_ID_t)1)
    #define ProtocolIE_ID_id_Cause        ((ProtocolIE_ID_t)2)
    #define ProtocolIE_ID_id_SourceID     ((ProtocolIE_ID_t)3)
    ...

    #define ProcedureCode_id_HandoverPreparation ((ProcedureCode_t)0)
    #define ProcedureCode_id_HandoverResourceAllocation    ((ProcedureCode_t)1)
    #define ProcedureCode_id_HandoverNotification ((ProcedureCode_t)2)
    #define ProcedureCode_id_PathSwitchRequest    ((ProcedureCode_t)3)
    ...

Only types of ASN_BASIC_INTEGER and ASN_BASIC_ENUMERATED referenced
by these constant variables are handled.

Other built-in types shall be added in the future.

Currently, there is no code generated for following ASN.1 excerpt.
Thus application is not aware of these values.

    maxnoofErrors           INTEGER ::= 256
    maxnoofBPLMNs           INTEGER ::= 6
    maxnoofPLMNsPerMME      INTEGER ::= 32
    maxnoofEPLMNs           INTEGER ::= 15
    ...

This commit generate asn_constant.h which has the following macro
defitions :

    #define maxnoofErrors (256)
    #define maxnoofBPLMNs (6)
    #define maxnoofPLMNsPerMME (32)
    #define maxnoofEPLMNs (15)
    #define maxnoofEPLMNsPlusOne (16)
    ...

It only handles ASN_BASIC_INTEGER type. Other built-in types shall
be added in the future.

With previous commit, the following data types are generated in ProtocolIE-Field.h
for S1AP's ASN.1 :

```
typedef enum ProtocolIE_Field_6564P0__value_PR {
    ProtocolIE_Field_6564P0__value_PR_NOTHING, /* No components present */
    ProtocolIE_Field_6564P0__value_PR_E_RABToBeSetupItemBearerSUReq
} ProtocolIE_Field_6564P0__value_PR;

typedef struct ProtocolIE_Field_6564P0 {
    ProtocolIE_ID_t      id;
    Criticality_t        criticality;
    struct ProtocolIE_Field_6564P0__value {
        ProtocolIE_Field_6564P0__value_PR        present;
        union ProtocolIE_Field_6564P0__value_u {
            E_RABToBeSetupItemBearerSUReq_t      E_RABToBeSetupItemBearerSUReq;
        } choice;

        /* Context for parsing across buffer boundaries */
        asn_struct_ctx_t _asn_ctx;
    } value;

    /* Context for parsing across buffer boundaries */
    asn_struct_ctx_t _asn_ctx;
} ProtocolIE_Field_6564P0_t;

```

It's difficult for developer to recognize to which ASN.1 type they are linked.
They all start with 'ProtocolIE_Field_'. It will be error-prone.

With this commit, more human comprehensible data types are generated :

```

typedef enum E_RABToBeSetupItemBearerSUReqIEs__value_PR {
    E_RABToBeSetupItemBearerSUReqIEs__value_PR_NOTHING, /* No components present */
    E_RABToBeSetupItemBearerSUReqIEs__value_PR_E_RABToBeSetupItemBearerSUReq
} E_RABToBeSetupItemBearerSUReqIEs__value_PR;

typedef struct E_RABToBeSetupItemBearerSUReqIEs {
    ProtocolIE_ID_t      id;
    Criticality_t        criticality;
    struct E_RABToBeSetupItemBearerSUReqIEs__value {
        E_RABToBeSetupItemBearerSUReqIEs__value_PR present;
        union E_RABToBeSetupItemBearerSUReqIEs__value_u {
            E_RABToBeSetupItemBearerSUReq_t               E_RABToBeSetupItemBearerSUReq;
        } choice;

        /* Context for parsing across buffer boundaries */
        asn_struct_ctx_t _asn_ctx;
    } value;

    /* Context for parsing across buffer boundaries */
    asn_struct_ctx_t _asn_ctx;
} E_RABToBeSetupItemBearerSUReqIEs_t;

```

Developers can understand they are generated from :

```

E-RABToBeSetupItemBearerSUReqIEs S1AP-PROTOCOL-IES ::= {
    { ID id-E-RABToBeSetupItemBearerSUReq CRITICALITY reject TYPE E-RABToBeSetupItemBearerSUReq PRESENCE mandatory },
    ...
}

```

For example,

E-RABToBeSetupItemCtxtSUReqIEs S1AP-PROTOCOL-IES ::= {
    { ID id-E-RABToBeSetupItemCtxtSUReq CRITICALITY reject TYPE E-RABToBeSetupItemCtxtSUReq PRESENCE mandatory },
    ...
}

generate :

static const asn_ioc_cell_t asn_IOS_E_RABToBeSetupItemCtxtSUReqIEs_1_rows[] = {
};

Solve the problem that 'TYPE OCTECT STRING' fails to generate corresponding item.

ClassObj S1AP-PROTOCOL-IES ::= {
  { ID id-eNB-UE-S1AP-ID   CRITICALITY reject   TYPE ENB-UE-S1AP-ID  PRESENCE mandatory}|
  { ID id-S1-Message       CRITICALITY reject   TYPE OCTET STRING    PRESENCE mandatory}|
  ...
}

Set the key.sequence to eclass's _type_unique_index and increment
it in each object parsing call, then set the result back to
_type_unique_index field. It can keep a class-wise counter for
eash object instantiated.

This new method not only solve name duplication when union two
information object sets, but also avoid name duplication within
multiple instances of this class.

If one item's name already exists in this OPEN TYPE, simply do not
add it to expression open_type_choice.

It slightly modifies previous commit :
dcc822a0.

With this modification, asn1f_parameterization_fork() will fork
parameterization if rhs_pspecs and stored rhs_pspecs have different
constraints, e.g. expressions parameterized by different
VALUESET references. Associated information object tables will be
generated accordingly.

This file can be included and transformed via automake

The generated Makefile.am.example is not really in the automake style.
Renaming it to converter-example.mk to reflect that it is a plain makefile
snippet and that it is for creating the converter-example

Ref :

https://github.com/vlm/asn1c/pull/237#issuecomment-342356046