ASN.1
Previous: Information Objects and Table Constraints Up: Additional Features Next: Summary

Parameterization

Parameterization is used to avoid repetition when there is some sort of common pattern that occurs in messages. Each of the various kinds of assignments can be parameterized. Here is an example of a paramerized type being defined and then used:

      MSString{INTEGER:maxSize} ::= CHOICE {
         printable  PrintableString(SIZE (1..maxSize)),
         teletex    TeletexString(SIZE (1..maxSize)),
         general    GeneralString(SIZE (1..maxSize)),
         universal  UniversalString(SIZE (1..maxSize)),
         bmp        BMPString(SIZE (1..maxSize))
      }
      
      ShortMS ::= MSString{40}
      LongMS ::= MSString{180}
      

ShortMS and LongMS are both defined using MSString, each one providing a different value for the parameter.

When the parameter is a Type or a class, there is no governor for the parameter. Here is an example where the parameter is a type:

      SIGNED {ToBeSigned} ::= SEQUENCE {
         toBeSigned  ToBeSigned,
         algorithm   AlgorithmIdentifier,
         signature   BIT STRING
      }
      
      SignedInteger ::= SIGNED {INTEGER}
      SignedFooBar ::= SIGNED {FooBar}
      

Combining Parameterization and Table Constraints

You may often see parameterization used with table constraints. There's nothing fundamentally new in this section, but the syntax won't be intelligble unless you understand the syntax for information objects and table constraints, already discussed in this tutorial here.

To illustrate, let's look at an example from the 5G communications protocol, NGAP (3GPP TS 38.413). First, we have this CLASS definition:

      NGAP-PROTOCOL-IES ::= CLASS {
         &id            ProtocolIE-ID UNIQUE,
         &criticality   Criticality,
         &Value,
         &presence      Presence
      }
      WITH SYNTAX {
         ID          &id
         CRITICALITY &criticality
         TYPE        &Value
         PRESENCE    &presence
      }
      

Next, we see a type that uses an object set of class NGAP-PROTOCOL-IES for some table constraints:

      ProtocolIE-Field {NGAP-PROTOCOL-IES : IEsSetParam} ::= SEQUENCE {
         id           NGAP-PROTOCOL-IES.&id           ({IEsSetParam}),
         criticality  NGAP-PROTOCOL-IES.&criticality  ({IEsSetParam}{@id}),
         value        NGAP-PROTOCOL-IES.&Value        ({IEsSetParam}{@id})
      }
      

Here, the governor for the parameter is a class, and since the parameter begins with an uppercase letter, we know it is an information object set and not a single information object. The type models a pattern of having an id, criticality, and value while allowing the valid combinations of values to vary according to context. Here's another parameterized type, one that simply uses the parameterized type just defined:

      ProtocolIE-Container {NGAP-PROTOCOL-IES : IEsSetParam} ::= 
         SEQUENCE (SIZE (0..maxProtocolIEs)) OF ProtocolIE-Field {{IEsSetParam}}
      

In the above example, notice that the actual parameter is passed as {IEsSetParam} rather than just IEsSetParam. The reason for this is that when an actual parameter is an information objet set, the syntax calls for an ObjectSet, which is defined thus: ObjectSet ::= "{" ObjectSetSpec "}". Therefore, you will always have curly braces around such a parameter (and we see this again in the next example).

Finally, here's a non-parameterized type that specifies a specific set of NGAP-PROTOCOL-IES objects to use with the parameterized type ProtocolIE-Container (and, in turn, with ProtocolIE-Field):

      
      HandoverRequired ::= SEQUENCE {
         protocolIEs    ProtocolIE-Container { {HandoverRequiredIEs} },
         ...
      }
      

If you're curious, the actual parameter above refers to HandoverRequiredIEs, which is a defined object set. Its (abbreviated) definition follows below. Unlike other examples in this tutorial, the information objects here are not separately defined (individually named):

      HandoverRequiredIEs NGAP-PROTOCOL-IES ::= {  
         { ID id-HandoverType    CRITICALITY reject   TYPE HandoverType    PRESENCE mandatory   } |
         { ID id-Cause           CRITICALITY ignore   TYPE Cause           PRESENCE mandatory   } |
         { ID id-TargetID        CRITICALITY reject   TYPE TargetID        PRESENCE mandatory   },
         ...
      }
      

Previous: Information Objects and Table Constraints Up: Additional Features Next: Summary

This site was developed from: Computer Networks and Open Systems An Application Development Perspective by Lillian N. Cassel Richard H. Austing Jones & Bartlett Publisher ISBN 0-7637-1122-5

This site is hosted by: Real World ASN.1 and XML Solutions