Using ASN.

1 to Describe
3GPP Layer 3 Message Formats
Objective Systems, Inc., July 2012
Overview
The 3
rd
Generation Partnership Project (3GPP) publishes many standards documents that describe
message formats for signaling and other applications within 3
rd
generation and 4
th
generation (LTE)
wireless networs! "any of these use #bstract $ynta% &otation ' (#$&!') to describe the message
formats including (adio (esource )ontrol ((())* &ode + #pplication Part (&+#P)* etc!
,ther formats such as those within the &on-#ccess $tratum (&#$) layer are described using a tabular
format! These are nown as Layer 3 messages and consist of a set of .nformation Elements (.E/s)
assembled under a common header structure! These information elements range from 0ery simple to
0ery comple% in structure!
1sers of our #$&!' software products (most notably* the #$&') code generation tool) ha0e e%pressed
an interest in being able to process messages of this type within their e%isting #$&')-based
framewor! They ha0e also e%pressed interest in looing for ways to further automate the production
of encoders and decoders for these message types due to the fact that woring with tabular data directly
is tedious and error-prone and the fact that these specifications change often maing forward-going
maintenance imperati0e!
2e ha0e therefore researched ways of e%pressing these message types in #$&!' format for use with our
tools! 2e found that the majority of structures can be directly represented using e%isting #$&!' types
and encoding rules 0ery similar to the Paced Encoding (ules (PE() used to encode and decode the
components! There are some corner cases howe0er* in which it would be 0ery difficult if not
impossible to automate the production of encoders and decoders! 3or these cases* we ha0e added
additional fle%ibility to the code generation process that allows substitution of custom code for either
complete encode4decode functions or* at a finer le0el* for indi0idual elements within functions!
This paper describes the changes we ha0e made to #$&') to allow 3GPP L3 messages to be processed
in the same way as any other #$&!'-based format! +y adding the special logic to produce encoders
and decoders for these formats* users can benefit from the generation of e%isting utility code for other
common operations including printing* copying* comparing* and test code generation!
Why ASN.1?
,ther modeling schemes ha0e been proposed for the automation of 3GPP message parsing and
formatting! The following are arguments for using #$&!' for this tas5
.t is a well understood* standardi6ed synta% used in other 3GPP message format specifications!
"ost constructs for .nformation Elements and "essage can be directly e%pressed using the
standard synta%!
#llows automation of the tas of producing encoders and decoders!
)ode generation tools can also generate supporting code for print* copy* compare* and test code
generation!
Modeling 3GPP Information Element
The first items to be taen into consideration when designing this capability are .nformation Elements
(.E/s)! 2e will use e%amples from 3GPP T$ 74!889* $ection'8 which defines .nformation Elements
used within the 3G &#$! .t should be possible to carry o0er these concepts to other specifications that
define messages in similar ways!
.nformation Element structures are defined in 7 ways5
Through bit field diagrams with accompanying descripti0e te%t
Through the use of :)oncrete $ynta% &otation '; ()$&!')* a synta% for defining comple% bit
patterns
<ow each of these are defined using #$&!' and the configuration items that ha0e been added to deal
with special cases follows!
Configuration Items
+efore proceeding to the details on how .nformation Elements are represented in #$&!' for use with
#$&')* we first e%amine a change to e%isting configuration directi0e processing! The current custom
configuration capability in #$&') 0=!> and below uses an e%ternal ?"L file that targets specific items
within a specification for special processing! 3or e%ample* the following e%ternal configuration file
targets element octet>a within the +acup+earer)ap,ctetGroup> production within the T$74889.E$
module for special processing5
<asn1config>
<module name=TS24008IES>
<production name=BacupBearer!ap"ctet#roup$>
<element name=octet$a>
<end%#E&tElem name='octet$(e&t')>
<)element>
<)production>
<)module>
<)asn1config>
The production that is targeted in this case is as follows5
BacupBearer!ap"ctet#roup$ **= SE+,E-!E .
octet$ Bearer!ap"ctet$/
octet$a Bearer!ap"ctet$a
0
.t is now possible to embed the configuration directi0e for the item being targeted directly as an #$&!'
comment preceding it5
BacupBearer!ap"ctet#roup$ **= SE+,E-!E .
octet$ Bearer!ap"ctet$/
11<end%#E&tElem name='octet$(e&t')>
octet$a Bearer!ap"ctet$a
0
This is a more practical and compact notation that can be used if users are free to edit the #$&!'
specifications they are dealing with! #n e%ternal configuration is good if users are woring with
standardi6ed #$&!' that they are not free to edit! The remainder of this paper will show directi0es in
the embedded notation* although either form may be used to apply the directi0es!
Bit Field Diagram Described Items
#n e%ample of a 3GPP .E bit field diagram is as follows5
8 7 6 5 4 3 2 1
Mobile Identity IEI octet 1
Length of Mobile Identity contents octet 2
0 0 MBMS
Sess
Id indic
MCC
M!C
indic
odd
e"en
indic
#y$e of identity octet 3
s$%&e
MBMS Se&"ice I'
octet 4
octet 5
octet 6
MCC digit 2 MCC digit 1 octet 6%(
M!C digit 3 MCC digit 3 octet 6b(
M!C digit 2 M!C digit 1 octet 6c(
MBMS Session Identity octet 7(
!i"ed#i$e %it !ield
The simplest items to model within these descriptions are single-bit and fi%ed-si6e bit fields! # single
bit is modeled using an #$&!' +,,LE#& type! 3i%ed-si6e fields are modeled using constrained
.&TEGE( types! 3or e%ample* a two-bit field would be of type .&TEGE( (8!!3)* a three-bit field
would be .&TEGE( (8!!@)* etc! The encoding in this case would be identical to that of PE( A the 0alue
would be paced into the minimal width field represented by the range! .t is also possible to model
these fields using fi%ed-si6e +.T $T(.&G types* but the standard use of these items would appear to be
as numeric 0ariables* maing .&TEGE( the better choice!
The specification of bit fields typically also includes the specification of spare bits either for the
purpose of padding to octet boundaries or for future e%tensions! These can be handled in #$&!' by
either creating a separate element for them (typically a constrained .&TEGE( with a BE3#1LT 0alue
of 6ero)* or by combining the width with the adjacent bit field to form a larger constrained .&TEGE(
0alue! The ad0antage of the former is better constraint checing to ensure the 0alue is within the
defined range whereas the latter can pro0ide more compact code as processing for the fields is
combined!
O&tet !ield
"essage fields are sometimes described as a fi%ed-si6e or 0ariable-si6ed array of octets (9-bit bytes)!
#n e%ample is the "+"$ $er0ice .B field in the bit field diagram abo0e!
These are modeled using the #$&!' ,)TET $T(.&G type with a si6e constraint specification! .f the
array is of fi%ed-si6e* the #$&') -strict-si6e command-line option can be used to insert an array of the
gi0en si6e without a length Cualifier!
'%() String
The Telephony +inary )oded Becimal (T+)B) $tring type is a common type used in 3GPP L3
messages as well as other telephony standard applications! 1nfortunately* there is no built-in support
for this type in #$&!'! # special configuration directi0e - DisT+)B$tring4E - has been added that
allows a type to be designated to be a T+)B string! The #$&') compiler generates a standard
character string type for these items and handles the con0ersion to and from paced format (one digit
per 4 bits) on encoding and decoding!
M((*MN( Pair 'y+e
(elated to T+)B $tring is the "))4"&) pair type! This type consists of a pair of T+)B numbers
stored bac-to-bac! Bue to the way the inner 7 digits are paced (one from ")) and one from
"&))* #$&') was unable to generate a proper encoder4decoder by default! 3or this reason* a custom
built-in encode4decode function was created to handle this special case!
#n e%ample of the "))4"&) pair declaration is shown in the bit field diagram abo0e in octets =a
through =c!
En,merated 'y+e
Type definitions within .E structures sometimes define a set of alternati0es! 3or these cases* the #$&!'
E&1"E(#TEB type can be used! .f the number of alternati0es is large enough to co0er the full range
of the defined bit field* the enumerated type definition itself without modification is sufficient for
generation of an encoder and decoder for the range! 3or e%ample* it the ma%imum defined enumerated
0alue is '' and the bit field si6e is 4* the code generator will create the proper si6ed field because
ranges between 9 and '> inclusi0e result in a 4 bit field!
.f* on the other hand* there are not enough alternati0es to co0er the full range* an adjustment to the type
definition is necessary! This can be done in one of two ways5
'! Befine a dummy ma%imum enumerated identifier that is large enough to fully define the range*
or
7! #dd a 0alue range subtype constraint to the type definition that defines the bit field range!
3or e%ample* if the ma%imum enumerated 0alue is = and the bit field width is 4* the following can be
done to ensure the bit field is the correct width5
21 option 1* add dumm3 identifier
43EnumT3pe **= E-,4E56TE7 .
m3Enum1819/ m3Enum829/ 11 ot:er defined items
m3EnumT3pe146;81$9 21 dumm3 identifier to pad field
0
or
11 option 2* add <alue range constraint
43EnumT3pe **= E-,4E56TE7 .
m3Enum1819/ m3Enum2829 11 ot:er defined items
0 80((1$9 21 <alue range constraint to define field si=e
SE-.EN(E
$EF1E&)E is the standard collection type used to define the full set of bit fields in a standard bit field
diagram! The fields are simply declared in the order they appear in the diagram from left-to-right* top-
to-bottom!
#ll fields within a bit field diagram are always reCuired to be present at the specified location! The
#$&!' concept of optional fields may be defined using )oncrete $ynta% &otation! This is discussed
later in the paper!
E"tenion Element
$ometimes an element will be designated to be an extension element! This is a single-bit element
which when set to 6ero signals the presence of a group of elements following it! The general form of
this type of element is as follows5
01 0 0 &%te sign%lling
e)t %ccess id* %d%$tion %ccess $&otocol octet 5(
.n order to delimit the group of elements to which an e%tension element applies* the
:Dend3GE%tElemE; configuration directi0e was added5
<end%#E&tElem name=name)>
where name would be replaced with the name of the element which is used to delimit the group!
SE-.EN(E O!
# shortcoming of the definition of repeating items in L3 .E/s is that a standard* well-defined* consistent
pattern is not established as it is in #$&!' encoding rules! Bepending on whether bit-field diagrams or
)oncrete $ynta% &otation is used* at least two different patterns for representing repeating items ha0e
been identified5
'! 1se of a preceding length field that defines the number of items in the list* or
7! 1se of an e%tension bit based approach in which a bit either within or e%ternal to the structure is
used to indicate either the presence of another item or end-of-list!
3urthermore* on item 7* e0en the con0ention on which bit 0alue signals end-of-list is not consistent! .n
some cases* a 6ero bit signal end-of-list* in other cases it is a one bit!
3or this reason* new configuration directi0es ha0e been introduced to specify the type of list being
created! 3or case '* the :Dis3GGarLenListE; configuration 0ariable identifies the repeating item as a
0ariable length list! This is the primary mechanism used in bit field diagrams and will be discussed
here!
#n e%ample of a 0ariable length list in T$ 74!889 is the $upported )odec List .E which is defined as
follows5
8 7 6 5 4 3 2 1
S+$$o&ted Codec List IEI octet 1
Length ,f S+$$o&ted Codec list octet 2
Syste- Identific%tion 1 .SysI' 1/ octet 3
Length ,f Bit-%$ fo& SysI' 1 octet 4
Codec Bit-%$ fo& SysI' 10 bits 1 to 8 octet 5
Codec Bit-%$ fo& SysI' 10 bits 1 to 16 octet 6
Syste- Identific%tion 2 .SysI' 2/ octet 2
Length ,f Bit-%$ fo& .SysI' 2/ octet 231
Codec Bit-%$ fo& .SysI' 2/0 bits 1 to 8 octet 232
Codec Bit-%$ fo& .SysI' 2/0 bits 1 to 16 octet 233
Syste- Identific%tion ) .SysI' )/ octet -
Length ,f Bit-%$ fo& .SysI' )/ octet -31
Codec Bit-%$ fo& .SysI' )/0 bits 1 to 8 octet -32
Codec Bit-%$ fo& .SysI' )/0 bits 1 to 16 octet -33
.n this case* the length element in the .E determines the total length of the .E in bytes! This element is
identified in the :Dis3GGarLenListE; directi0e using the lengthElem attribute! This item go0erns the
o0erall length of the .E! ,n parsing* it is used to determine the number of elements in the repeating
structure! 3or encoding* the length in the populated structure is ignored and the total length of the .E is
calculated based on the number of elements in the populated structure!
The #$&!' type used to represent the $upported )odec List is as follows5
Supported!odec>ist **= SE+,E-!E .
lengt: I-TE#E5 84((2$49/
11<is%#?ar>en>ist lengt:Elem='lengt:')>
codecs SE+,E-!E 8SI@E 81((8%99 "A Supported!odec
0
)ase 7 is identified using the :Dis3GE%tListE; directi0e! These types of lists are defined in both bit
field diagrams and using )oncrete $ynta% &otation! .n bit field diagrams* an e%tension list is specified
in much the same way as e%tension elements defined abo0e! .n this case* howe0er* descripti0e te%t is
added to indicate the e%tension may repeat more than once and will terminate when a one bit is in the
e%tension element bit field!
This is modeled in #$&!' by using a $EF1E&)E ,3 type to which the following configuration
directi0e is applied5
<is%#E&t>ist pre1eol=1>
This indicates the field will repeat until an end-of-list bit eCual to ' is encountered! The attribute is
named :pre-eol; to indicate the bit precedes the last record! There are cases that can be described using
)$&!' where the bit indicator comes after the record! This is the :post-eol; case and is described in the
section on )oncrete $ynta% &otation!
#n e%ample of this type of specification can be found in T$ 74!889* $ection '8!>!4!> A +earer
)apability! The specification of the repeating octet 3 type is modeled this way! .t is shown in the table
as follows5
01 0 0
e)t co4
ding
C#M
s$%&e
s$eech "e&sion
indic%tion
octet 3% (
01 0 0 0
e)t co4
ding
s$%&e s$%&e S$eech "e&sion
Indic%tion
octet 3b etc(
the #$&!' used to model this is as follows5
Bearer!apaBilit31"ctet%E&t **= SE+,E-!E .
coding B"">E6-/
spare I-TE#E5 80((%9 7EA6,>T 0/
speec:?ersion I-TE#E5 80((1$9
0
11<is%#E&t>ist pre1eol='1')>
Bearer!apaBilit31"ctet%E&t6rra3 **=
SE+,E-!E 8SI@E80((899 "A Bearer!apaBilit31"ctet%E&t
&ote that the /e%t/ element is not included in the element type definition! .t is assumed to occur in the
first position!
Items Described Using Concrete !nta" #otation
"ore comple% .E structures are defined using :)oncrete $ynta% &otation;! #n o0er0iew of this
notation is a0ailable in #nne% + of T$ 74!88@! There is also a basic tutorial located at the following
1(L5
http544csn'!info
"ost items in )$&!' can be directly represented in #$&!'! There are some items that reCuire the use
of new configuration directi0es and some that reCuire custom code be de0eloped to handle! 2e
e%amine certain patterns identified within T$ 74!889 and the #$&!' used to model them!
!i"ed#i$e %it !ield
)$&!' can be used to describe fi%ed-si6e bit fields! The synta% is simply < name * Bit > for a
single-bit field* or < name * Bit 8n9 > for a multiple-bit width field! .n this definition* name would
be replaced by a )$& 0ariable name and n would be replaced with a bit count 0alue!
#s was the case with bit field diagram defined 0alues* a single-bit field is modeled with the #$&!'
+,,LE#& type and a multiple-bit field is modeled with an .&TEGE( type with a 0alue range
constraint that defines the full set of numeric 0alues the bit field will hold!
En,merated 'y+e
Enumerated bit patterns can be defined in )$&!' using the union (H) operator! The general form is5
< name * . pattern1 C pattern2 C D C patternN 0 >
where name would be replaced with an identifier name and each pattern item would be replaced with a
bit pattern! 3or e%ample* the following definition e%ists within T$ 74!8895
< T1#S4 400 Bands Supported * . 01 C 10 C 11 0 >
.n this case* an #$&!' E&1"E(#TEB type can be used to model the item! &ote that there are no
names for the 0arious alternati0es and the type (or element) name in this case is in a rather free form
format which includes embedded whitespace! To model this with an #$&!' type would reCuire
modification of the name and the addition of identifiers for the enumerated items! # type that could be
used for this purpose is as follows5
T1#S414001Bands1Supported **= . Band1819/ Band829/ Band8%9 0
The modifications would ha0e no effect on the final encoding!
SE-.EN(E
#s was the case for bit field diagrams* the primary container for a series of items e%pressed in )$&!' is
a $EF1E&)E type!
# common pattern also e%ists in )$&!' definitions of .E/s for optional elements! This pattern is as
follows5
. 0 C 1 < name > 0
.n this case* name would be the name of a defined item or a complete )$&!' element definition! This
indicates that if a 6ero bit is present* the encoding of the definition is omittedI whereas* if a one bit is
present* it is followed by the encoded item!
This is modeled in #$&!' as an optional element in a $EF1E&)E! The code generator by default will
generate code to implement this pattern for optional elements!
&ote that an optional element in an .E is treated differently than an optional element in an L3 message!
.n the case of a message* it signals a non-imperati0e .E within the message! This will be co0ered in
more detail in the section on 3GPP "essages below!
SE-.EN(E O!
.t is possible to e%press repeating items in )$&!'* the problem from an #$&!' modeling standpoint is
that it is not done in a consistent way in the 3GPP specifications! #s mentioned pre0iously in the +it
3ield Biagram section* one way this is done is through the use of a 0ariable length list in which a length
element within the .E determines the number of encoded items!
.n )$&!'* a common way of specifying repeating items is through an e%tension list! .n this case* a bit
0alue is used to signal the presence of another record in the repeating collection or the end of the list!
,ne form of this synta% is as follows5
< name > **= . 0 * < type > 0 EE 1F
This indicates that the named item is a repeating collection of items of type type. The presence of a
6ero bit indicates that a typed item followsI a one bit signals end-of-list! To e%press this in #$&!'* a
configuration directi0e in the following form is applied to the $EF1E&)E ,3 definition5
<is%#E&t>ist post1eol=1>
Name **= SE+,E-!E "A Type
The :is3GE%tList; directi0e indicates that the type of list is an e%tension list as opposed to the 0ariable
length list type defined earlier! The :post-eol; attribute indicates the list is terminated by the presence
of a one bit after the last record! There is also a :pre-eol; attribute that indicates a list is terminated by
the presence of a gi0en bit 0alue before the last record! This was defined earlier in the section on bit
field diagram descriptions!
(/OI(E
.t is possible to create a choice of items in )$&!' in a similar fashion to how optional elements are
declared! The union operator (H) is used followed by a bit pattern that identifies each item followed by
the type of the item that is to follow5
< name > **= . bit-pattern-1 * < type-1 > C
bit-pattern-2 * < type-2 > C
D
bit-pattern-n * < type-n > 0
This can be directly modeled with an #$&!' choice type as long as the bit patterns that identify the
alternati0es form a seCuential set of numbers (for e%ample* 8* '* or 88* 8'* '8* etc!)! This has been the
case in all obser0ed patterns of this type to date* so a configuration directi0e to handle the case of non-
seCuential numbers has yet to be de0eloped!
Modeling 3GPP Meage
The basic structure of 3GPP Layer 3 messages is a common header structure as defined in T$ 74!88@
followed by a series of .nformation Elements!
/eader
)omponents that mae up the header structure can be defined in #$&!' as follows5
)E 11(2(%(1 Standard >% 4essage Geader E)
>%Gdr"ptions **= !G"I!E .
sipInd I-TE#E580((1$9/
11<inline)>
transId SE+,E-!E .
flag B"">E6-/
<alue I-TE#E5 80((2$$9
0/
epsBearerIdent EHSBearerIdentit3
0
Hroto7iscr **= E-,4E56TE7 .
call!trl8%9/ moB4gmt8$9/ rr4gmt8I9/ eps4oB4gmt8J9/ gprs4oB4gmt889/
sms8K9/ sess4gmt8109
0 80((1$9
HrotocolIE1I7 **= SE+,E-!E .
proto7iscr Hroto7iscr/
msgT3pe I-TE#E580((2$$9
0
$ome definitions ha0e been remo0ed for bre0ity!
2ithin the header structure are protocol discriminator and message type fields that identify the contents
of the body of the message! These are contained within the :Protocol.E-.B; type! This type is used in
the following information object class definition as a ey 0alue to form a relation between this item and
the body of the message5
-6S1H5"T"!">1!>6SS **= !>6SS .
Lid HrotocolIE1I7/
L?alue
0
MITG SN-T6; .
I7 Lid
TNHE L?alue
0
1sing these items* we can come up with a common definition for a message protocol data unit (PB1)5
H7, **= SE+,E-!E .
l%Gdr"pts >%Gdr"ptions/ 11 >% :eader/ octet 1/ Bits $ t:ru 8
id -6S1H5"T"!">1!>6SS(Lid 8.H5"T"!">1IE1"BOE!TSET09/
data -6S1H5"T"!">1!>6SS(L?alue 8.H5"T"!">1IE1"BOE!TSET0.Pid09
0
The P(,T,),L-.E-,+JE)T$ET would then contain all of the .B/s and message types for all
messages defined in the protocol!
Meage
The body of an L3 message is described using an #$&!' type definition! # relation is then set up
between the protocol .B and this type by defining an information object for the message and then this
object is added to the P(,T,),L-.E-,+JE)T$ET!
The type that is created is normally a $EF1E&)E of the .nformation Elements that are identified in
the table describing the message* although in simple cases the body may be empty (header only) in
which case an #$&!' &1LL type is used and in others* only a reference to a single .nformation
Element type is reCuired!
The .nformation Elements that mae up a message are specified in tables within the specification in
which they are defined! The rows in the table define the imperati0e and non-imperati0e parts of the
message!
The imperati0e part defines mandatory elements! These are defined first! .n #$&!'* these items are
defined as non-optional elements in the container $EF1E&)E! &o special processing is reCuired to
handle them in encoding or decoding! They are simply processed in the order they are declared!
The non-imperati0e part of a message begins with the first item in the table in which an .E.
(.nformation Element .dentifier) 0alue is declared! These elements are declared as ,PT.,&#L in the
#$&!' definition! #ll elements after this first optional element will be included in the non-imperati0e
part and must be declared to be optional as well! .t is not possible to mi% mandatory and optional
elements!
.n addition to declaring the non-imperati0e element to be optional* a special configuration directi0e is
reCuired to pro0ide additional information! The general form of this directi0e is as follows5
11<iei format='t|tv|tlv' Qlengt:='length'R>hex-value<)iei>
.n this definition* the format attribute is either /t/ (tag)* /t0/ (tag 0alue)* or /tl0/ (tag-length-0alue) as
defined in T$ 74!88@! The length attribute is optional and only reCuired for format type /t0/ to identify
the length of the 0alue! 3or format /tl0/* the length 0alue will be built into the generated type! The hex-
value would be replaced with the actual he%adecimal 0alue as defined in the table! &o con0ersion to
decimal format is necessary!
$"am%le
The following is a complete e%ample in defining a 3GPP L3 message in #$&!' form for use with our
tools! The message in this case is the Location 1pdating #ccept message defined in 3GPP T$ 74!889*
$ection K!7!'35
I$I Information element &!%e'(eference )resence Format *engt+
Mobility -%n%ge-ent 5&otocol disc&i-in%to& M 6 12
$&otocol disc&i-in%to& 10*2
S7i$ Indic%to& S7i$ Indic%to& M 6 12
10*3*1
Loc%tion 8$d%ting Mess%ge ty$e M 6 1
9cce$t -ess%ge ty$e 10*4
Loc%tion %&e% Loc%tion %&e% M 6 5
identific%tion identific%tion
10*5*1*3
17 Mobile identity Mobile identity , #L6 3410
10*5*1*4
91 :ollo; on $&oceed :ollo; on $&oceed , # 1
10*5*3*7
92 C#S $e&-ission C#S $e&-ission , # 1
10*5*3*10
49 E<+i"%lent 5LM!s 5LM! list , #L6 5447
10*5*1*13
34 E-e&gency !+-be& List E-e&gency !+-be& List
10*5*3*13
, #L6 5450
The #$&!' definition of this message would be as follows5
>oc,pdating6ccept **= SE+,E-!E .
loc6reaIdent >oc6reaIdent/
11<iei format='tl<'>1J<)iei>
moBileIdentit3 4oBileIdentit3 "HTI"-6>/
)E folloS"nHroceed and ctsHermission contain no data/ Tust IEI 8tag9 1
present flags are sufficient to indicate presence or aBsence E)
11<iei format='t'>61<)iei>
folloS"nHroceed -,>> "HTI"-6>/
11<iei format='t'>62<)iei>
ctsHermission -,>> "HTI"-6>/
11<iei format='tl<'>46<)iei>
eUui<H>4-s H>4->ist "HTI"-6>/
11<iei format='tl<'>%4<)iei>
emerg-um>ist Emergenc3-umBer>ist "HTI"-6>
0
The :loc#rea.dent; element is the lone mandatory element that maes up the imperati0e part of the
message! The remaining elements form the non-imperati0e part and are therefore mared as optional!
Each one is preceded by an :iei; configuration directi0e! &ote that the :follow,nProceed; and
:ctsPermission; elements are of format tag-only and therefore ha0e a type field of &1LL!
2e then can define a 0alue constant for the message type and combine this with the protocol
discriminator and message type to form an information object5
mt1>oc,pdating6ccept I-TE#E5 **= 2
oBT1>oc,pdating6ccept -6S1H5"T"!">1!>6SS **= .
I7 . proto7iscr moB4gmt/ msgT3pe mt1>oc,pdating6ccept 0
TNHE >oc,pdating6ccept
0
"essage types for all of the 0arious message defined in T$ 74!889 are declared as bit patterns in
section '8!4! This must be con0erted into a decimal integer 0alue for use in the #$&!' definition!
The information object can then be included in the P(,T,),L-.E-,+JE)T$ET which defines all
messages that mae up the protocol!
Inserting Custom Code
The methodology defined abo0e can be used to automate a large part of the tas of producing encoders
and decoders for L3 messages! Bespite this* there are still some odd and Cuiry parts in the
specifications that cannot be easily automated! 3or these cases* new configuration options are being
introduced which allow custom code to be inserted in place of what would normally be generated by
the code generator!
The first of these directi0es allows complete encode or decode functions to be replaced for a gi0en
type! The 0ariable names are :DcEnc3unc3nameE; and :DcBec3unc3nameE; respecti0ely! These
allow the contents of the ) source file that is specified as the argument to be inserted in place of the
encode or decode function that would normally be generated! &ote that ) is currently the only
supported language for this capability!
.n addition* the :DcEnc$rc3nameE; and :DcBec$rc3nameE; directi0es can be used to insert a code
snippet for what would ha0e been generated for a gi0en element! These also tae the name of a file
containing the code to be inserted as an argument!