557 lines
22 KiB
Plaintext
Executable File
557 lines
22 KiB
Plaintext
Executable File
A.1 ASN.1 definition of MSD
|
||
|
||
This module definition is appropriate for transmission of MSD via Pan-European eCall (via any means ofcommunication, see before)
|
||
and may be used for transmission of MSD via EN 16102 (Operatingrequirements for third party support).
|
||
|
||
|
||
MSDASN1Module
|
||
-- Definition of the eCall related MSD message in ASN.1
|
||
-- Any MSD message will encoded using this scheme, following the
|
||
-- UPER encoding rules.
|
||
|
||
-- The MsD message is defined in CEN standard EN 15722.Comments in this definition are taken from that standard. In
|
||
-- case of inconsistency in the comment,the text of EN 15722 prevails.
|
||
|
||
|
||
DEFINITIONS
|
||
AUTOMATIC TAGS ::=
|
||
BEGIN
|
||
|
||
|
||
-- Version of this ASN.l MD specification
|
||
-- (inclusion of this element allows software developers to
|
||
-- automatically read out the current version number from the ASN.1
|
||
-- compilation for automatic inclusion into the msdVersion parameter
|
||
-- of the MsD message,i.e. can reduce the chance of using an ASN.1
|
||
-- description ofone version but saying it is another)
|
||
|
||
|
||
CurrentVersion::INTEGER(3)
|
||
|
||
-- ECallMessage is the top level information element
|
||
-- The ECallMessage structure supports only one message type (msd)
|
||
-- Extendibility at this level is not allowed, thus ensuring that the
|
||
-- msdVersion (message format version) can be extracted directly.
|
||
-- Elements :
|
||
-- msdVersion: MSD format version
|
||
-- The format described in this document carries version 3
|
||
-- msd: Minimum Set Of Data uplink from vehicle
|
||
|
||
-- The OCTET STRING(CONTAINING ,..)construct is used to ensure that any
|
||
-- implementation can extract the msdVersion value from any version,
|
||
-- without decoding errors.
|
||
|
||
|
||
ECallMessage::SEQUENCEmsdVersionINTEGER {
|
||
msdVersion INTEGER(0 .. 255)，
|
||
msd OCTET STRING(CONTAINING MMessage)
|
||
}
|
||
|
||
-- The main uplink msd message from the vehicle
|
||
-- Elements:
|
||
-- msdStructure: The main MSD strueture
|
||
-- optionalAdditionalData: Additional data
|
||
|
||
|
||
-- Extendable in future versions at this level e.g. to add extra data
|
||
--
|
||
MSDMessage ::= SEQUENCE {
|
||
msdStructure MSDStructure，
|
||
optionalAdditionalData AdditionalData OPTIONAL,
|
||
...
|
||
}
|
||
|
||
-- The main MSD structure, excluding additional data
|
||
-- Elements:
|
||
-- messageIdentifier: Message identifier, starting with l for each
|
||
-- new eCall session and to be incremented with
|
||
-- every application layer MSD retransmission
|
||
-- control: see ControlType
|
||
-- vehicleIdentificationNumber: see VIN
|
||
-- vehiclePropulsionStorageType: see VehiclePropulsionStorageType
|
||
-- timestamp: Timestamp of incident event
|
||
-- As seconds elapsed since midnight January lst,1970 UTC
|
||
-- Failure value for time stamp set to "0"
|
||
-- vehicleLocation: see VehicleLocation
|
||
-- vehicleDirection: Direction of travel
|
||
-- in 2 degrees steps from either magnetic or
|
||
-- geographical north(0-358，clockwise)
|
||
-- If direction of travel is invalid or unknown
|
||
-- the value 255 shall be used
|
||
-- Only values from 0 to 179 and 255 are valid
|
||
-- recentVehiclelocationNl: location delta with respect to vehicleLocation
|
||
-- recentVehicleLocationN2: location delta with respect to recentVehicleLocationN1, see VehicleLocationDelta
|
||
-- numberOfOccupants: Number of occupants in the vehicle according to available information.
|
||
-- If no information about the number of occupants is available，this parameter needs to be omitted or set to 255.
|
||
|
||
MSDStructure ::= SEQUENCE {
|
||
messageldentifier INTEGER(0 .. 255)
|
||
control ControlType，
|
||
vehicleldentificationNumber VIN,
|
||
vehiclePropulsionStorageType VehiclePropulsionstorageType,
|
||
timestamp INTEGER(0 .. 4294967295)
|
||
vehicleLocation VehicleLocation，
|
||
vehicleDirection INTEGER(0 .. 179 | 255)
|
||
recentVehicleLocationN1 VehicleLocationDelta,
|
||
recentVehicleLocationN2 VehicleLocationDelta,
|
||
numberOfOccupants INTEGER(0 .. 255) OPTIONAL,
|
||
...
|
||
}
|
||
|
||
-- The ControlType is a collection of the following elements:
|
||
-- Elements:
|
||
automaticActivation: true = Automatic activation,
|
||
false = Manual activation
|
||
-- testCall: true = Test call,false=Emergency
|
||
-- positionCanBeTrusted: true = Position can be trusted，
|
||
false = low confidence in position
|
||
-- NOTE "Low confidence in position"
|
||
shall mean that there is less than 95%
|
||
confidence that exact position is within the limits of a radius of +150m(-150m)
|
||
of reported position
|
||
-- vehicleType : see VehicleType
|
||
|
||
|
||
ControlType ::= SEQUENCE {
|
||
automaticAetivation BOOLEAN，
|
||
testCal1 BOOLEAN，
|
||
positionCanBeTrusted BOOLEAN，
|
||
vehicleType VehicleType
|
||
}
|
||
|
||
-- Definition of the vehicle type reporting the incident.
|
||
-- NOTE: Vehicle definitions category M,N according directive 2007/46/EC;
|
||
category l according directive 2002/24/EC,other categories
|
||
according tO UNECE UNECE TRANS/WP.29/78/Rev.4(2016) World Forum for
|
||
Harmonization of Vehicle Regulations; Consolidated Resolution on the Construction of Vehicles(R.E.3)
|
||
|
||
-- NOTE: The normal encoding of the MSD is ASN. 1 UPER in which case the
|
||
numerical values specified below are ignored
|
||
|
||
-- Extendable in future versions for new vehicle types. Implementations should anticipate on receiving an unknown value.
|
||
|
||
VehicleType ::= ENUMERATED {
|
||
passengerVehicleCategoryM1 (1),
|
||
busesAndCoachesCategoryM2 (2),
|
||
busesAndCoachesCategoryM3 (3),
|
||
lightCommercialVehiclesN1 (4),
|
||
heavyDutyVehiclesCategoryN2 (5),
|
||
heavyDutyVehiclesCategoryN3 (6),
|
||
motorcyclesCategoryL1e (7),
|
||
motorcyclesCategoryL2e (8),
|
||
motorcyclesCategoryL3e (9),
|
||
motorcyclesCategoryL4e (10),
|
||
motorcyclesCategoryL5e (11),
|
||
motorcyclesCategoryL6e (12),
|
||
motorcyclesCategoryL7e (13),
|
||
trailersCategory0 (14),
|
||
agriVehiclesCategoryR (15),
|
||
agriVehiclesCategoryS (16),
|
||
agriVehiclesCategoryT (17),
|
||
offRoadVehiclesCategoryG (18),
|
||
specialPurposeMotorCaravanCategorySA (19),
|
||
specialPurposeArmouredVehicleCategorysB(20),
|
||
specialPurposeAmbulanceCategorySC (21),
|
||
specialPurposeHearseCategorySD (22),
|
||
otherVehicleCategory(23),
|
||
...
|
||
}
|
||
|
||
-- VIN ( vehicle identification number ) according ISO 3779
|
||
-- isowmi: World Manufacturer Index (WMI)
|
||
-- isovds: Vehicle Type Descriptor(VDS)
|
||
-- Vehicle Identifier Section (VIS) consisting of
|
||
-- isovisModelyear: Modelyear from Vehicle Identifier Section (VIS)
|
||
-- isovisSeqPlant: Plant code + sequential number from Vehicle Identifier Section (VIS)
|
||
|
||
|
||
VIN ::= SEQUENCE {
|
||
isowmi PrintableString(SIZE(3))
|
||
(FROM("A".."H"|"J".."N"|"P"|"R".."Z"|"0".."9")),
|
||
isovds PrintableString(SIZE(6))
|
||
(FROM("A".."H"|"J".."N"|"P"|"R".."Z"|"0".."9")),
|
||
isovisModelyear PrintableString(SIZE(1))
|
||
(FROM("A".."H"|"J".."N"|"P"|"R".."Z"|"0".."9")),
|
||
isovisSeqPlant PrintableString(SIZE(7))
|
||
(FROM("A".."H"|"J".."N"|"P"I"R".."Z"|"0".."9"))
|
||
}
|
||
|
||
-- VehiclePropulsionStorageType is a collection of elements
|
||
-- that contain information about the presence of propulsion
|
||
-- storage inside the vehicle sending the MSD.
|
||
--
|
||
-- For each storage type the following coding applies:
|
||
-- false = indicates a type of storage not present
|
||
-- true = indicates type of storage which is present
|
||
-- The following storage types are supported:
|
||
-- Gasoline tank
|
||
-- Diesel tank
|
||
-- Compressed natural gas (CNG)
|
||
-- Liquid propane gas(LPG)
|
||
-- Electric energy storage (vehicle has electric propulsion and associated batteries)
|
||
-- Hydrogen storage
|
||
-- other storage
|
||
-- If the type of energy storage is unknown, then all elements
|
||
-- shall be set to false.
|
||
-- Extendible in future versions for new fuel storage types
|
||
|
||
|
||
VehiclePropulsionStorageType ::= SEQUENCE {
|
||
gasolineTankPresent BOOLEAN DEFAULT FALSE,
|
||
dieselTankPresent BOOLEAN DEFAULT FALSE,
|
||
compressedNaturalGas BOOLEAN DEFAULT FALSE,
|
||
liquidPropaneGas BOOLEAN DEFAULT FALSE,
|
||
electricEnergyStorage BOOLEAN DEFAULT FALSE,
|
||
hydrogenStorage BOOLEAN DEFAULT FALSE,
|
||
otherStorage BOOLEAN DEFAULT FALSE,
|
||
...
|
||
}
|
||
|
||
-- VehicleLocation:
|
||
-- The current location of the vehicle
|
||
-- Elements:
|
||
-- Position latitude (WGS84) in milliarcsec
|
||
-- Position longitude (WGS84) in milliarcsec
|
||
-- 32 bits (4 octets) allocated to make signed value handling easier
|
||
--
|
||
-- If latitude and/or longitude is invalid or unknown,
|
||
-- the representation of value 2147483647 shall be transmitted.
|
||
|
||
VehicleLocation ::= SEQUENCE {
|
||
-- Actual valid value range (-324000000 to 324000000)
|
||
positionLatitude INTEGER(-2147483648..2147483647),
|
||
-- Actual valid value range(-648000000 to 648000000)
|
||
positionLongitude INTEGER(-2147483648..2147483647)
|
||
}
|
||
|
||
-- VehicleLocationDelta:
|
||
-- Description of (the delta of) a recent vehicle location
|
||
-- before the incident
|
||
|
||
-- Latitude Delta (+ for North and - for South)
|
||
-- Longitude Delta(+ for East and - for West)
|
||
-- both with respect to a previous location.
|
||
-- 1 Unit = 100 miliarcseconds, which is approximately 3m
|
||
|
||
VehicleLocationDelta ::= SEQUENCE {
|
||
latitudeDelta INTEGER(-512..511),
|
||
longitudeDelta INTEGER(-512..511)
|
||
}
|
||
|
||
-- AdditionalData:
|
||
-- Further additional bytes of data encoded as in a
|
||
-- seperate ASN.1 definition
|
||
|
||
-- Elements:
|
||
-- oid: Object identifier which uniquely identifies the format
|
||
and meaning of the data which follows.
|
||
-- data:Transparent optional additional data,
|
||
according to the format referenced by the oid
|
||
The user must ensure that the size of this element
|
||
is restricted to ensure that the total ECallMessage is
|
||
small enough for the relevant transmission medium.
|
||
|
||
|
||
AdditionalData ::= SEQUENCE {
|
||
oid RELATIVE-OID,
|
||
data OCTET STRING
|
||
}
|
||
|
||
|
||
-- Several of the elements above are "extendable"
|
||
-- according to the ASN.1 standard to facilitate future extensions
|
||
-- whilst also maintaining backwards compatibility. Implementations must provision for such extensions
|
||
|
||
END
|
||
|
||
A.2 Syntax check of ASN.1 definition of MSD
|
||
|
||
ASN.1 Studio Version 9.0
|
||
Copyright (C) 2018 OSS Nokalva,Inc. All rights reserved.
|
||
This product is licensed for use by "Cheiron IT bv,Leiden,Holland - Standards Editor",
|
||
License "66410E", only for project "CEN TC278 WG15 related standards work"
|
||
|
||
ASN.1 syntax check result: cO043I: 0 error messages, 0 warning messages and 0 informatory messages issued.
|
||
|
||
MSDv3: Compilation summary: The project MSDv3 includes 3 PDUs and 0 ASN.1 values.
|
||
|
||
A.3 Examples of ASN.1 encoded MSD
|
||
The example below is shown in ASN.1 value encoding(plain text):
|
||
value ECallMessage ::=
|
||
{
|
||
msdVersion 3,
|
||
msd
|
||
CONTAINING
|
||
{
|
||
msdStructure
|
||
{
|
||
messageIdentifier 1,
|
||
control
|
||
{
|
||
automaticActivation TRUE,
|
||
testCall FALSE,
|
||
positionCanBeTrusted TRUE,
|
||
vehicleType passengerVehicleCategoryM1
|
||
},
|
||
vehicleIdentificationNumber
|
||
{
|
||
isowmi "ECA",
|
||
isovds "LLEXAM",
|
||
isovisModelyear "P",
|
||
isovisSeqPlant "LE02020"
|
||
},
|
||
vehiclePropulsionStorageType
|
||
{
|
||
|
||
gasolineTankPresent TRUE,
|
||
electricEnergyStorage TRUE
|
||
},
|
||
timestamp 1579992331,
|
||
vehicleLocation
|
||
{
|
||
positionLatitude 187996428,
|
||
positionLongitude 18859320
|
||
},
|
||
vehicleDirection 45,
|
||
recentVehicleLocationN1
|
||
{
|
||
latitudeDelta 0,
|
||
longitudeDelta 10
|
||
},
|
||
recentVehicleLocationN2
|
||
{
|
||
latitudeDelta 0,
|
||
longitudeDelta 30
|
||
},
|
||
numberOfOccupants 2
|
||
}
|
||
}
|
||
}
|
||
|
||
{
|
||
msdVersion 3,
|
||
msd
|
||
CONTAINING
|
||
{
|
||
msdStructure
|
||
{
|
||
messageIdentifier 1,
|
||
control
|
||
{
|
||
automaticActivation TRUE,
|
||
testCall FALSE,
|
||
positionCanBeTrusted TRUE,
|
||
vehicleType passengerVehicleCategoryM1
|
||
},
|
||
vehicleIdentificationNumber
|
||
{
|
||
isowmi "ECA",
|
||
isovds "LLEXAM",
|
||
isovisModelyear "P",
|
||
isovisSeqPlant "LE02020"
|
||
},
|
||
vehiclePropulsionStorageType
|
||
{
|
||
gasolineTankPresent TRUE,
|
||
electricEnergyStorage TRUE
|
||
},
|
||
timestamp 1579992331,
|
||
vehicleLocation
|
||
{
|
||
positionLatitude 187996428,
|
||
positionLongitude 18859320
|
||
},
|
||
vehicleDirection 45,
|
||
recentVehicleLocationN1
|
||
{
|
||
latitudeDelta 0,
|
||
longitudeDelta 10
|
||
},
|
||
recentVehicleLocationN2
|
||
{
|
||
latitudeDelta 0,
|
||
longitudeDelta 30
|
||
},
|
||
numberOfOccupants 2
|
||
}
|
||
}
|
||
}
|
||
|
||
|
||
|
||
The same example encoded in UPER (hexadecimal representation,38 bytes):
|
||
0324101A 01C614A2873C52AB A870010010089AF166285C59 A4C86408 FE29C16C 01054010 F010
|
||
|
||
Annex B
|
||
(informative)
|
||
|
||
ASN.1 Data representation PER and BER explained
|
||
|
||
B.1 What is ASN.1
|
||
NOTE This introduction was inspired by the information found in http://www.w3.org/Protocols/HTTP-NG/asn1.html.Definitions,examples and encoding traces were created using OSS Nokalva ASN.1 Studio.
|
||
ASN.1 is a notation for describing data structures;it is very much like a type declaration in Cor C++.
|
||
One of the key components of ASN.1 are Procotol Data Units (PDUs).Let's take a look at the ASN.1 definition for the MSD.
|
||
It contains the PDU ECallMessage',which is defined like so:
|
||
|
||
ECallMessage ::=SEQUENCE {
|
||
msdVersion INTEGER(0 .. 255),
|
||
msd MSDMessage
|
||
}
|
||
|
||
This defines EcallMessage as an object with two members:
|
||
-- msdVersion, which content is an integer value between 0 and 255,and msd,which is a complex object of type MSDMessage,defined later on
|
||
Hence ASN.1 offers means of defining the type (i.e.INTEGER), the range (i.e.0.255) and more complex constructions.
|
||
Further down the definition one can find additional functionality that ASN.1 had to offer:
|
||
-- optional element: some elements can be declared optional, and thus be left out of a data encoding(see MSDStructure.recentVehicleLocationN1);
|
||
-- enumeration: an element can contain enumerated data, in such a way that the encoding is very efficient without losing content (see VehicleType);
|
||
—- strict range checking: not only ranges like 0 .. 255 are possible,but combined ranges as well(see VIN)
|
||
|
||
The ASN.1 definition is used to encode and decode data content.Several encoding rules exist,among which:
|
||
-- Basic Encoding Rules (BER):the original rules for taking an ASN.1 data type, and turning it into a sequence of bits and bytes;
|
||
-- Packed Encoding Rules (PER): instead of using a generic style of encoding that encodes all types in a
|
||
uniform way,the PER specialise the encoding based on the data type to generate much more compact representations;
|
||
|
||
-- XML Encoding Rules (XER):an encoding using XML
|
||
|
||
|
||
B.2 Encoding data using ASN.1
|
||
The main purpose of any ASN.1 definition is to encode and decode data. This paragraph describes some of the basic procedures.
|
||
|
||
|
||
The Basic Encoding Rules (BER) were the original rules for taking an ASN.1 data type,
|
||
and turning it into a sequence of bits and bytes.BER uses a form of encoding commonly known as Tag-Length-Value.
|
||
Each item is encoded as a tag,indicating what type it is,a length indicating the size of the object,and a value,
|
||
which contains the actual contents of the object.
|
||
|
||
Tags are reasonably simple-in there simplest form they consist of a single byte;
|
||
the highest two bits indicate the tag class:whether the tag is an official ISO tag,
|
||
an application wide tag,a private tag,or a tag that only has meaning for this particular structure.
|
||
The next bit is a flag to indicate whether the tagged object is a simple type,such as a number or a string,
|
||
or a compound type made up from a bunch of other types.The remaining 5 bits are used to represent the tag number.
|
||
If the tag is too big to fit in 5 bits,then these bits are set to all ones,
|
||
and the tag number is encoded in the following bytes as a sequence of seven bit bytes.
|
||
The high bit of these bytes is used as a flag to indicate whether there's more tag available.
|
||
|
||
|
||
Lengths are also quite simple.There are two ways of encoding lengths - the definite form, and the indefinite form.
|
||
For the definite form, if the length is less than 128, you just use a single byte,with the high bit set to zero.
|
||
Otherwise the high bit is set to one,and the low seven bits set to the length of length.
|
||
The length is then encoded in that many bytes.The indefinite form is encoded by sending a length field with a length of length of O-i.e.[1000|0000].
|
||
The objectis ended by sending two zero bytes.
|
||
|
||
|
||
DER is a restricted variant of BER for producing unequivocal transfer syntax for data structures described by ASN.1.
|
||
DER is the same thing as BER with allbut one sender's options removed.It provides for exactly one way to encode an ASN.1 value.
|
||
DER is intended for situations when a unique encodingis needed,such as in cryptography,
|
||
and ensures that a data structure that needs to be digitally signed produces a unique serialized representation.
|
||
DER can be considered a canonical form of BER. For example, in BER a Boolean value of true can be encoded as any of 255 non-zero byte values,
|
||
while in DER there is only one way to encode a Boolean value of true.
|
||
|
||
The most significant DER encoding constraints are:
|
||
-Length encoding shall use the definite form. Additionally,the shortest possible length encoding shall be used.
|
||
-Bitstring,octetstring,and restricted character strings shall use the primitive encoding
|
||
—Elements of a Set are encoded in sorted order,based on their tag value.
|
||
|
||
|
||
The packed encoding rules use a different style of encoding.Instead of using a generic style of encoding that encodes all types in a uniform way,
|
||
the PER specialise the encoding based on the data type to generate much more compact representations.
|
||
Packed encoding rules have particular value for messages of known data structure (such as the MSD)
|
||
|
||
PER only generates tags when they are needed to prevent ambiguity this only occurs when ASN.1's version of union (CHOICE) is used.
|
||
PER also only generates lengths when the size of an object can vary. Even then,PER tries to represent the lengths in the most compact form possible.
|
||
The presence of optional elements in a sequence is indicated by a list of single bit flags placed at the start of a sequence-if the bit is set,then the option is present.
|
||
PER encodings are not always aligned on byte boundaries-if the'aligned'variant of the rules is used,then strings *will*be aligned.
|
||
The unaligned variant(UPER)treats the encoding as a string of bits, allowing things like booleans and small integers to be squished together in one byte.
|
||
|
||
Data can obviously also be encoded into an XML representation. Apart from XER,the 'basic XML encoding', one can choose to use the Canonical or the Extended XML encoding rules (CXER or EXER).
|
||
|
||
|
||
B.3 Examples
|
||
|
||
This paragraph shows in depth examples using ASN.1 encoding rules.For clarity a basic example(source: https://en.wikipedia.org/wiki/ASN.1) is used,examples of MSD encodings are found elsewhere.
|
||
|
||
|
||
The examples in this appendix will use the following definition:
|
||
FooProtocol
|
||
|
||
DEFINITIONS::=BEGIN
|
||
FooQuestion ::=SEQUENCE {
|
||
trackingNumber INTEGER,
|
||
question PrintableString
|
||
}
|
||
FooAnswer ::=SEQUENCE {
|
||
questionNumber INTEGER,
|
||
answer BOOLEAN
|
||
}
|
||
END
|
||
|
||
This definition gives us two PDU's:FooQuestion and FooAnswer. We'll create an instance of both:
|
||
myQuestion FooQuestion ::= {
|
||
trackingNumber 5,
|
||
question "Anybody there?"
|
||
}
|
||
|
||
theirAnswer FoOAnswer ::= {
|
||
questionNumber 5,
|
||
answer TRUE
|
||
}
|
||
|
||
In the remainder we will find out how these are encoded using the different encoding rulesets.
|
||
myQuestion encoded using DER or BER(definite length)gives the following hexadecimal representation:
|
||
|
||
30 13 02 01 05 13 0E 41 6E 79 62 6F 64 79 20 74 68 65 72 65 3F
|
||
30 SEQUENCE
|
||
13 of length .13 (19) bytes, containing
|
||
02 INTEGER (type .02 (2))
|
||
01 of length .01 (1) byte, containing
|
||
05 value .05 (5)
|
||
13 PrintableString(type .13 (19))
|
||
OE of length .0E (14) bytes, containing
|
||
41 character .41 (65,"A")
|
||
6E character .6E (110,"n")
|
||
79 character .79 (121,"y")
|
||
62 character .62 (98,"b")
|
||
...
|
||
65 character .65 (101,"3")
|
||
3F character .3F (63,"!")
|
||
Using BER with indefinite length,the coding is slightly different:
|
||
30 80 02 01 05 13 0E 41 6E 79 62 6F 64 79 20 74 68 65 72 65 3F 00 00
|
||
Where.80 represents the indefinite length,and the encoded message is terminated by'.00.00'.
|
||
|
||
|
||
If myQuestion is encoded using(aligned)PER the result differs 'drastically':
|
||
01 05 0E 41 6E 79 62 6F 64 79 20 74 68 65 72 65 3F
|
||
|
||
The difference is caused by not including information about the data structure in the encoded content.
|
||
As a result the encoding is 4 bytes less than when using BER encoding.
|
||
To decode,one needs the encoding definition,to be able to decode like this:
|
||
--TYPE INFORMATION: SEQUENCE
|
||
--TYPE INFORMATION: INTEGER
|
||
01 First byte: length = .01, 1 byte
|
||
05 Value bytes (1 byte): .05 (5)
|
||
--TYPE INFORMATION: PrintableString
|
||
OE First byte: length= .0E, 14 bytes
|
||
... Value bytes (14 bytes) =.41.6E.79.62.6F.64.79.20.74.68.65.72.65.3F
|
||
The information in the bold lines is taken from the encoding schema.
|
||
|
||
Using unaligned PER(UPER) the encoded data gets changed completely and the result is 1 byte less than the aligned version:
|
||
01050E 83 BB CE 2D F93C A0 E9 A32F 2C AF C0
|
||
The difference is caused by the fact that a elements ofa PrintableString are made up from 7 bit characters and
|
||
these are now no longer aligned on an 8-bit boundary by prepadding the bits with a 0.
|
||
This table shows the different encoding of the beginning of the string"Are":
|
||
.41 .6E .79 .62 result
|
||
PER encoding 01000001 01101110 01111001 01100010 01000001011011100111100101100010
|
||
UPER encoding 1000001 1101110 1111001 1100010 1000001110111011110011100010 83 BB CE
|
||
|
||
The number of bytes spared by using UPER is depending on how strict the schema is made and what data types are used.
|
||
|
||
When the XML Encoding Rules are used a rather simple XML representation can be created:
|
||
<?xml version="1.0"encoding="UTF-8"?>
|
||
<FooQuestion>
|
||
<trackingNumber>5</trackingNumber>
|
||
<question>Anybody there?</question>
|
||
</FooQuestion>
|
||
|
||
|
||
|