Tiêu chuẩn iso ts 18234 2 2013

ISO/TS 18234 consists of the following parts, under the general title Intelligent transport systems — Traffic and travel information via transport protocol experts group, generation 1 TP

TPEG transmission

TPEG is designed to function over virtually any basic digital data channel, requiring only the capability to transmit a stream of bytes It envisions transmission through a simple "piece of wire," without any extra service features from the bearer.

Figure 1 illustrates various potential transmission channels, with the primary requirement being the ability to transmit a sequence of bytes between the TPEG generator and decoder, known as "transparency." However, it is acknowledged that data channels can introduce errors, such as omitted or corrupted bytes, as well as the reception of additional erroneous data To address these issues, TPEG includes error detection features at suitable points and levels, while it is assumed that bearer systems will provide an adequate level of error correction.

Figure 1 — TPEG data may be delivered simultaneously via different bearer channels

TPEG layer model

In Figure 2, the different layers of the TPEG protocol are identified in accordance with the ISO/OSI model (ISO/IEC 7498-1)

Copyright International Organization for Standardization

Provided by IHS under license with ISO Licensee=University of Alberta/5966844001, User=sharabiani, shahramfs

Figure 2 — TPEG in relation to the ISO/OSI Layer Model via different bearer channels

Layer 7 is the top level and referred to in TPEG as the application layer Initially the following applications were defined:

 TPEG specifications - Part 3: Service and Network Information Application (Service provider name, logo, hand-over information, etc.) (CEN ISO/TS 18234-3);

 TPEG specifications - Part 4: Road Traffic Message application (Event description, location description, etc.) (CEN ISO/TS 18234-4)

Layer 4 is the packetization layer Components are merged into a single stream and encrypted and/or compressed

Layer 3 is the network layer This layer defines the means for synchronization and routing This is the lowest layer of the TPEG protocol

Layer 2, known as the datalink layer, encompasses various bearers that effectively support the TPEG protocol To successfully map the TPEG stream onto these bearers, an adaptation layer may be necessary.

Layer 1 is the physical layer This defines the transmission medium (radio waves, wire, optical, etc.) One particular bearer can make use of different physical layers

Conventions

Byte ordering

Numeric values that require more than one byte are encoded in "Big Endian" format, which prioritizes the most significant byte first In this structure, a byte is divided into bits, with the most significant bit ("b7") positioned on the left and the least significant bit ("b0") on the right.

Method of describing the byte-oriented protocol

TPEG employs a clear and straightforward data-type representation for the various structures that constitute the transmission protocol This textual format is designed to be unambiguous and user-friendly, allowing for easy modifications without necessitating extensive programming knowledge.

Data types are developed incrementally, starting from primitive elements represented as byte sequences, which are then combined into compound elements These compound elements, along with primitives, form increasingly complex structures This Technical Specification outlines certain primitives, compounds, and structures applicable to all TPEG Applications, while others are defined specifically within individual applications, making them local to those contexts.

A resultant byte-stream coded using C-type notation is shown in CEN ISO/TS 18234-2:2006, Annex E.

Reserved data fields

In a TPEG data structure, any undefined part is designated as an unassigned value (UAV) and should be encoded by the service provider as 00 hex This encoding allows future decoders adhering to an updated TPEG Standard to disregard this data when interfacing with providers using an older specification While a decoder unfamiliar with previous UAVs can still utilize the other data fields of the information entity, it will be unable to process any newly defined additional information.

Symbols

Literal numbers

Whenever literal numbers are quoted in TPEG Standards, the following applies:

Variable numbers

Symbols in TPEG Standards represent numbers with undefined values, and these symbols are specific to the data type definition For instance, within a data type definition, symbols like "n" or "m" typically indicate the number of bytes in the structure, while "id" signifies the occurrence of the data type's identifier.

Implicit numbers

A data structure often requires the inclusion of a component that can be repeated zero or more times To represent this repetition conveniently, a numerical symbol, typically "m," is used to indicate the structure's components without explicitly stating the number within the data structure's definition.

General

This clause introduces the terminology and the syntax that is used to define TPEG data elements and structures.

Data type notation

Rules for data type definition representation

The following general rules are used for defining data types:

A data type is represented in upper camel case as a single expression, beginning with a letter and potentially including lowercase letters (a-z), numbers (0-9), underscores ("_"), round brackets ("()"), and colons (":") For example, "IntUnLo" signifies Integer Unsigned Long.

 a data type is framed by angle brackets “ < > ” ;

 the content of a data type is defined by a colon followed by an equal sign “ := ”;

 the end of a data type is indicated by a semicolon “ ; ”;

 a descriptor written in lower camel case may be added to a data type as one single expression without spaces;

 a descriptor is framed by round brackets “ ( ) ”;

 the descriptor contains either a value or a name of the associated type;

 data types in a definition list of another one are separated by commas “ , ” The order of definition is defined as the order of occurrence in a data stream;

 curly brackets (braces) “ { } ” group together a block of data types;

 control statements ( “if”, “infinite”, “unordered” or “external”) are noted in lower case letters A control statement is followed by a block statement or only one data type:

The "if" statement establishes a conditional statement, determining the occurrence of a block or data type based on the validity of the condition This condition is enclosed in parentheses and is applicable to any data type.

2) “infinite” defines endless repetition of the block (or data type) This is only used to mark the main TPEG stream as not ending stream of data;

Camel case refers to the practice of writing compound words where each word is distinguished by a capital letter In upper camel case, the compound word starts with a capital letter, while in lower camel case, it begins with a lowercase letter.

The term "unordered" indicates that the subsequent block includes data types that can appear in any sequence, rather than strictly following the order in which the data types are specified This definition is applicable solely to components.

The term "external" indicates that the data type's content is defined outside the specified scope The control statement "external" should be accompanied by a single data reference, with a corresponding specification noted in the comments Additionally, all types outlined in the TYP specification are considered to be within the scope of any application.

:= : externally defined component external ; : id = 1, See Annex B (Message Management

The expression "n *" signifies the multiplicity of a data type's occurrence, with implicit bounds ranging from 0 to infinity Additional bounds are specified in square brackets, indicated by two points " " following the data type descriptor The asterisk "*" denotes that there is no upper limit on the occurrence.

EXAMPLE 3 m * (Attribute) [1 *] , : The “Attribute” must occur once at least and up to infinite

 a function “ f n ( ) ” that is calculated over a data type is indicated by italic lower case letters The comment behind the definition of the function shall explain which function is used;

 any text after a colon “ : ” is regarded as a comment;

A data type definition can be a template, characterized by a parameter enclosed in round brackets "(x)" at the end of its name Templates serve as foundational structures for other data type definitions, allowing for the declaration of a template by repeating the parameter name as a descriptor in a nested data type within the subsequent definition list This approach enables the specification of data type interfaces, facilitating the understanding of the generalized aspects of various instances For more details, refer to Clause A2.3.2 - Using templates as interfaces.

:= : x defines the template parameter

(x); : descriptor x defines position of setting the parameter in the list

A data type can inherit a template by appending the template's name, including square brackets, to its own name This data type may also be a template itself, indicated by the "(x)" at the end of its name, or it can instantiate the inherited template by specifying the parameter value within the brackets In this case, the brackets should contain the decimal identifier, and the value must be defined in the subsequent definition list The structural definition of the inherited template is reiterated as the first part of the definition list before introducing new data types For more details, refer to Clause A2.3.2 - Using templates as interfaces.

:= : second template inherits first

(x), : repeated definition from 1 st template

:= : instantiation of the second template

(1), : definition of parameter in the stream

(n), : structural definition from template

(value); : some more definition

A specific instance of a template, referred to as a declarative structure, is defined in the definition list without brackets In this context, any inherited data type of the template can appear at that position within the data stream.

(anyAnotherTemplate); : Data stream contains e.g

The following additional guidelines help to improve the readability of data type definitions:

 data type names are written in bold;

 nested data type definitions are defined from top to bottom (i.e higher levels first, then lower levels);

 a box is drawn around a data type definition;

For optimal graphical clarity, long lines within a coding box are split using a backslash "\\" followed by a carriage return, with the continuation of the broken line beginning with an additional backslash.

Description of data type definition syntax

A data type represents the interpretation of one or more bytes and has a defined structure that may consist of other data types This structure outlines the composition and positioning of each data element TPEG specifies data structures in this way.

: Description of data type : Description of data A : Description of data B

This shows an example data structure, which has just two parts, one of type and the other of

A data type can have an associated descriptor that connects it to other definitions Comments regarding the data structure are provided on the right side, separated by a colon Each data type can be made up of other separately defined data types, and ultimately, every data type can be represented as one or more bytes.

Where a data structure is repeated a number of times, this may be shown as follows:

: Description of data type : Description of data A : Description of data B

In certain situations, it is essential to inform the decoder about the frequency of a repeated data type, although alternative methods like framing or internal length coding can sometimes indicate the end of the repeated data Additionally, specifying the total length of a data structure in bytes may be necessary Constraints on occurrences can also be included, indicating the expected number of instances of the data type The use of an asterisk (*) as an upper bound signifies that there are no restrictions on the maximum number of elements, allowing for potentially infinite occurrences.

Where the number of repetitions must be signalled, it may be accomplished using another data element as follows:

: Description of data type : An integer representing the value of "n"

: Description of data A : Description of data B

In the given example, a decoder requires the value of "n" to accurately identify the n’th position of in the list Consequently, due to the IntUnTi data type limitation, a maximum of 255 instances of this data type can be encoded.

In the following example the decoder uses the value of “n” to determine the overall length of the data structure, and the value of “m” determines that is repeated m times:

: Description of data type : Length, n, of data structure in bytes : Description of data A

This data type definition is used to describe a variable structure switched by the value of x:

(x), if (x=1) then , if (x=2) then ,

: Description of data type : Select parameter, x : Included if x equals 1 : Included if x equals 2

Application dependent data types

Data structures

Data structures consist of multiple elements, including primitive and compound types, as well as both non-declarative and declarative structures Any application-specific data type that lacks a component identifier is inherently considered a data structure The term "data structure" specifically refers to data type definitions that include more than one sub-element.

Examples of data structure might be:

: Sound sample : Length of samples, n : Between 0 and 8000 occurrences of a sample

Another example making use of a condition within a data type definition is shown below

EXAMPLE 3 An application could use the example data types above in the following way

: Appointment : Alarm type : Remind with a sound

: Remind with a text : Let some action follow

: Sound alarm : When to wake up : Sound to wake up to!

: Text alarm : When to display : Text to display

A general mechanism utilizing a bitarray is implemented for signaling optional values When a corresponding bit in the bitarray is set to 1, the optional attribute is included in the stream Conversely, if the bit is unset, the attribute is deemed unavailable, and the processing continues with the next attribute in the stream.

EXAMPLE 4 Data structure with optional elements, signalled by a preceding bitarray as selector

(selector), if (bit 0 of selector is set)

(years), if (bit 1 of selector is set)

(months), if (bit 2 of selector is set)

(days), if (bit 3 of selector is set)

(hours), if (bit 4 of selector is set)

(minutes), if (bit 5 of selector is set)

The DaySelector allows users to specify a range of time intervals, including years (0 to 100), months (0 to 12), days (0 to 31), hours (0 to 24), minutes (0 to 60), and seconds (0 to 60) This versatile tool is designed to accommodate various time-related inputs efficiently.

Using templates as interfaces

The syntax allows for the complete and static definition of a data structure, while also accommodating conditionally different components This is indicated by a clearly defined initial segment, which distinguishes various data types within the structure.

A tagged value, or TagLengthValue-Coding, begins with a type and length, followed by the value Initially, the type is defined through an interface, which is then inherited by various tagged value types, incorporating the tagged value data type The decoder utilizes the interface information, specifically the type attribute, to effectively read the remaining tagged value from the stream.

: A list of data : Different instances can have different types

: Template for tagged value : Type of this tagged value : Length in bytes in case that value type is unknown

Code Reference-English ‘word’ Comment

Then the resulting list of inherited tagged value data types would be:

: Template for tagged value : Type of this tagged value : Length in bytes in case that value type is unknown

This interface allows a subsequent list of data types which can easily be extended, by using the same interface.

Components

A component is understood as a declarative structure having an interface as described in the previous clause

A data stream decoder utilizes a unique identifier within the TPEG Application Standard to recognize content structure Alongside this identifier, a length indicator enables the decoder to bypass unknown components, allowing for the integration of new elements even if existing decoders are unaware of their content While older decoders anticipate the first version of a protocol and overlook unrecognized data with minimal performance impact, newer decoders are designed to fully decode the second version It is essential to incorporate components for anticipated future extensions, ensuring robust 'future proofing' capabilities.

This method allows for the introduction of non-backwards compatible changes in the existing market by implementing a migration period that remains backward compatible Eventually, support for older devices will be phased out, although it is anticipated that the migration process will require time.

To enhance size efficiency while maintaining backward compatibility, a second step is introduced alongside declarative structuring The initial segment after a component's header in the data stream is termed the attribute block This block begins with its length in bytes, enabling the decoder to bypass attributes that may not be present in earlier versions of the protocol.

The decoder processes the attribute block length and reduces the byte count when the last known attribute is read If the attribute block count is not zero, it omits the remaining bytes in the data stream to transition to the next well-known section.

6.3.3.1 Definition of standard component interface

A standard component consists of attributes and features a unique "generic component id." It includes a length that specifies the number of bytes of data following the component length, as well as an attribute length that indicates the byte count in the attribute block, which is the first part of the component data.

:= : Component template used for standard components

(x), : id is unique within the scope of the application

(compLengthInByte), : length of the component counted in bytes

(attributeBlockLengthInByte); : length of the attribute block in bytes

6.3.3.2 Example for jumping over unknown content types

 let C1 be a component with an attribute a1 as ShortInt and a sub component C2;

 let C2 be a component with an attribute a2 as one IntUnTi and a second a3 as ShortString;

 let C3 be a component being the successor of C1

To illustrate the method, padding bytes with the value CD in hexadecimal can be added to the stream, enabling a decoder to still interpret bytes C1 to C3 Figure A.1 displays a table with three lines: the first line indicates the position number, the second line shows the abbreviated function of each byte, and the third line presents sample content The arrows beneath the table indicate possible jumps, facilitating navigation over the various padding bytes.

CL : component (data) length in bytes AL : attribute block length in bytes

C1, C2, C3 : component identifier, begin of the component

Figure 3 — Example for jumping over unknown content with component header information

Toolkits and external definition

Different TPEG Applications share certain functionalities, such as location referencing and message management containers Consequently, a TPEG Application can reference a data type definition that is not outlined in its own Technical Specification.

Toolkits are structured to define root components as templates for external reference Consequently, a TPEG Application utilizing a toolkit template must assign a unique generic component ID for this specific interface instantiation.

The toolkit defines its subcomponents starting from 0, which are considered out of scope for the TPEG Application Consequently, the application decoder must recognize that component IDs may be duplicated in the toolkit's subcomponents This structure allows for independent development of both the application and the toolkit.

Application design principles

Variable data structures

Switches in an application allow for variations in the data structure, but they also fix the values of these variations, preventing the introduction of new types without compromising backward compatibility To maintain compatibility, components can be utilized It is crucial to consider that when new features are added, older decoders will ignore new data fields and still anticipate the presence of mandatory old components.

Re-usable and extendable structures

In an application, data structures are utilized consistently across various areas, and as the application protocol evolves, the number of these structures will continue to expand To streamline the decoder's software, component templates can be employed, reducing the frequency of structure definitions and allowing for a broader range of structures to be implemented in specific locations.

Validity of declarative structures

In each application, a component's identifier is uniquely defined, although the same identifier may serve different purposes across various applications Within a single application, each identifier corresponds to a specific component definition Applications can utilize components to create placeholders or modify the arrangement of elements within a fixed structure.

Diagrammatic hierarchy representation of frame structure

Transport Frame: Sync Word Field Length Header CRC Frame Type

Figure 4 — TPEG Frame Structure, Frame Type = 0 (i.e stream directory)

Transport Frame: Sync Word Field Length Header CRC Frame Type

Field Length CRC Service Component Frame:

Figure 5 — TPEG Frame Structure, Frame Type = 1 (i.e conventional data)

Syntactical Representation of the TPEG Stream

TPEG transport frame structure

The following boxes are the syntactical representation of the TPEG frame structure shown in Clause 7.1 The byte stream contains consecutive transport frames Each frame includes:

The synchronization word (syncword) 2 bytes (See Clause A.3.3.1) The length of the service frame in bytes (field length) 2 bytes (See Clause A.3.3.2)

The header CRC 2 bytes (See Clause A.3.3.3)

The frame type indicator 1 byte (See Clause A.3.3.4)

The service frame n bytes (n = Field Length)

The byte stream is constructed based on a repetitive structure of transport frames, where each transport frame typically follows directly after the previous one However, if spacing bytes are necessary, they should be designated as 0 hex (padding bytes).

: Control element, (loop continues infinitely) : Any number of padding bytes (0 hex) : Transport frames

(FF0F hex), (m), (headCRC), (x), ;

: Sync word (FF0F hex) : Number of bytes in Service Frame : Header CRC, (See Clause A.3.3.4) : Frame type of service frame : Any service frame follows

TPEG service frame template structure

: Template for service frame : Content of service frame

Service frame of frame type = 0

The service frame is solely used to transport the stream directory information

Number of services (n) 1 byte n *(SID-A, SID-B, SID-C) n * (3 bytes)

: Stream directory : Number of services : Any number of Service IDs : CRC of Service IDs

Service frame of frame type = 1

SID-A, SID-B, SID-C 3 bytes (See Clause A.3.4.2)

The encryption indicator 1 byte (See Clause A.3.4.1)

The service level is determined by the service frame, with each transport frame containing a single service frame This service frame consists of a multiplex component that includes one or more component frames.

Each service frame may contain a different range and number of component frames as required by the service provider

Each transport frame is exclusively utilized by a single service provider and a specific service, enabling a variety of applications Multiple service providers or services can be combined through the concatenation of several transport frames Additionally, each service frame contains essential service information, including service identification elements and an encryption indicator.

: Conventional data : Service identification : Encryption indicator n 0 = no encryption

: Function f n (…) is utilized according to the chosen encryption algorithm

TPEG service component frame multiplex

The component multiplex consists of multiple component frames, arranged in a type and order specified by the service provider It undergoes transformation based on the required encryption method, with no changes made if the encryption indicator is set to 0 Additionally, the total length of the resulting data must not exceed 65531 bytes.

:= n * (data); : Any number of any component frames

Interface to application specific frames

The service component frame incorporates application-specific code, detailing the data stream as defined by the application specification Historically, various frames have been established to meet different needs within existing application specifications To standardize these frames, particularly for new specification developments, this clause outlines a fundamental frame required for all applications, along with a selection of alternative frames from which an application can choose, eliminating the need for custom frame specifications.

An application specification, however, can specify its own frame, which shall at minimum include the following base service component frame as first sub type

7.2.6.1 TPEG base service component frame structure

A TPEG data stream can support multiple content streams, even from the same application, facilitated by the Service and Network Information (SNI) Application, which acts as a variable directory within the data stream This includes a table that assigns a unique number to each transmitted content stream and specifies the expected application for each specific frame Consequently, the frame begins with a header that defines three initial values common to all service component frames, leading to a structured format for each service component frame.

: Service component frame : Common service component header : Component data

Where the service component header is specified as:

: Common service component frame header : Service component identifier (scid is defined by SNI service component designating the application in this service component frame)

: Length, n, of component data in bytes : Header CRC (See Clause A.3.5.3)

Data is transmitted in component frames with a limited length To accommodate applications that require greater capacity, it is essential to design the application to distribute data across multiple component frames and recombine this information during decoding.

The inclusion of the field length enables the decoder to skip a component

The maximum field length of the component data (assuming that there is no transformation, and only one component is included in the service frame) = 65526

7.2.6.2 TPEG specialized service component data schemata

To ensure consistency across various applications, it is essential that service component frames are defined similarly This involves focusing on three key attributes of a general nature The proposed specialized service component data schemata will provide information regarding the application data of a component frame, ensuring that the dataCRC is error-free.

Data CRC at this level ensures that only the service component frame, which is a relatively small data package, is lost in the event of errors, while other valid parts of the service multiplex remain usable Additionally, the service component frame includes a count of messages, referred to as messageCount.

Understanding the opaque byte count is important, but it's equally essential to know the number of distinct messages the decoder should anticipate for display purposes Additionally, prioritization can be achieved by assigning a group priority.

In certain situations, service components are managed not only by a FIFO buffer but also by prioritizing messages High-priority messages can take precedence over lower-priority ones in the decoder, allowing them to be presented to the user before the decoding of less urgent messages.

7.2.6.2.1 Service component data with dataCRC

Every application must include a data CRC, as outlined in Clause A.3.5.4, at the conclusion of the application data to ensure the detection of bit errors at the service component frame level.

< ServCompFrameProtected >:(header), external (content),

: CRC protected service component frame : Component frame header as defined in A.3.2.6.1 : Content specified by the individual application : CRC starting with first byte after the header

7.2.6.2.2 Service component data with dataCRC and messageCount

This service frame is designed for applications that present messages directly to the user, indicating the expected number of messages at the frame level It also includes data CRC for error checking.

(messageCount), external (content),

: CRC protected service component frame with message count

: Component frame header as defined in A.3.2.6.1 : count of messages in this ApplicationContent : actual payload of the application

: CRC starting with first byte after the header

7.2.6.2.3 Service component data with dataCRC and groupPriority

This service component frame is utilized for grouping messages by priority In cases where messages within the frame have varying priorities, the designation 'typ007_000: undefined' is applied Additionally, the data CRC is included.

(groupPriority), external (content),

: CRC protected service component frame with message count

: Component frame header as defined in A.3.2.6.1 : group priority applicable to all messages in this ApplicationContent

: actual payload of the application : CRC starting with first byte of after the header

7.2.6.2.4 Service component frame with dataCRC, groupPriority, and messageCount

Additionally, an application can also make use of all features described in previous clauses

(messageCount), external (content),

: CRC protected service component frame with group priority and message count

: Component frame header as defined in A.3.2.6

: group priority applicable to all messages in the ApplicationContent

: count of messages in this ApplicationContent : actual payload of the application

: CRC starting with first byte after the header

7.2.6.3 Example of an application implementing a service component frame

An application specification must initially define the component frame in a clear written sentence While it may reiterate the definition of the frame for clarity, it should also include a note indicating that this definition may be updated or replaced in future releases of the specification.

As second definition tree of application starts with:

: link provided by SSF : n root components of the application

(compLengthInByte), : length of the component in bytes (attributeBlockLengthInByte), : length of the attribute block in bytes

(myText), : some first attribute of the application

(sub); : some sub components of Component(0)

Description of data on Transport level

Syncword

The syncword is 2 bytes long, and has the value of FF0F hex

The nibbles F hex and 0 hex have been chosen for simplicity of processing in decoders The patterns

0000 hex and FFFF hex were deprecated to avoid the probability of false triggering in the cases of some commonly used transmission channels.

Field length

The field length consists of 2 bytes and represents the number of bytes in the service frame

This derives from the need of variable length frames.

Header CRC

The Header CRC, which is two bytes in length, utilizes the ITU-T polynomial \(x^{16} + x^{12} + x^{5} + 1\) It is computed over 16 bytes, encompassing the sync word, field length, frame type, and the first 11 bytes of the service frame If the service frame is shorter than 11 bytes, the calculation includes the sync word, field length, frame type, and the entire service frame.

In this case the Header CRC calculation does not run into the next transport frame

The calculation of the CRC is described in Annex C.

Frame type

The frame type (FTY) indicates the content of the service frame Its length is 1 byte The following table gives the meaning of the frame type:

FTY value (dec): Content of service frame: Kind of information in service frame:

0 Number of services, n * (SID-A, SID-B, SID-C) Stream directory information

1 SID-A, SID-B, SID-C, Encryption ID,

If FTY = 0, an extra CRC calculation is done over the whole service frame, i.e starting with n (number of services) and ending with the last SID-C of the last service

The calculation of the CRC is described in Annex C

Synchronization method

To synchronize the receiver, a three-step algorithm is employed: first, it searches for the FF0F hex value; second, it calculates and verifies the header CRC; and finally, it checks the two bytes that follow the service frame as specified by the field length.

The two bytes following the end of the service frame should either be a sync word or 00 hex, when spaces are inserted.

Error detection

The CRC header provides error detection and protection for the synchronization elements and not for the data within the service frame (except the first 11 bytes, when applicable).

Description of data on Service level

Encryption indicator

The encryption indicator is defined as one byte according to TPEG primitive syntax If the indicator has value

All data in the component multiplex is non-encrypted when indicated by 00 hex Any other value of the encryption indicator signifies that various mechanisms for data encryption or compression have been applied to the data in the subsequent multiplex The service provider has the flexibility to select the encryption or compression techniques and algorithms used.

1 to 127 = reserved for standardized methods

128 to 255 = may be freely used by each service provider, may indicate the use of proprietary methods

Service identification

The service IDs are structured in a similar way to Internet IP addresses as follows:

The combination of these three SID elements must be uniquely allocated on a worldwide basis

The following address allocation system applies:

 SID range for TPEG technical tests SIDs = 000.000.000 - 000.127.255

 SID range for TPEG public tests SIDs = 000.128.000 - 000.255.255

 SID range for TPEG regular public services SIDs = 001.000.000 - 100.255.255

 SID range: reserved for future use SIDs = 101.000.000 - 255.255.255

NOTE The above allocations and structure is significantly changed from that originally specified in CEN ISO/TS 18234-2

Description of data on Service component level

Service component identifier

The service component identifier with the value 0 is reserved for the SNI Application (See CEN ISO/TS 18234-3)

Field length

The field length consists of 2 bytes and represents the number of bytes of the component data.

Service component frame header CRC

The component header CRC is two bytes long, and based on the ITU-T polynomial x 16 +x 12 +x 5 +1

The component header CRC is calculated from the service component identifier, the field length and the first

13 bytes of the component data In the case of component data shorter than 13 bytes, the component identifier, the field length and all component data shall be taken into account

The calculation of the CRC is described in Annex C.

Service component frame data CRC

The DataCRC, which is two bytes in length, utilizes the ITU polynomial \(x^{16} + x^{12} + x^{5} + 1\) This cyclic redundancy check (CRC) is computed from all bytes of the service component frame data following the service component frame header.

The calculation of the CRC is described in Annex C

Character tables

The default character coding table used in TPEG is ISO/IEC 8859-1.

Numag derivation

TPEG applications often require a single byte to represent quantities of people or objects This is achieved through a non-linear coding system that offers high resolution for smaller numbers while progressively decreasing resolution for larger quantities.

The primitive describes, in a single byte, quantities which lie in the range 0 - 3 000 000

: Counting numbers with magnitude, 0 > 4); crc = (unsigned short) (crc ^ (swap((unsigned char)(crc)) = days_in_year(y); y++) { days -= days_in_year(y);

} for (tmp->tm_mon = TM_JANUARY; days >= days_in_month(y, tmp->tm_mon);

(tmp->tm_mon)++) { days -= days_in_month(y, tmp->tm_mon);

} tmp->tm_year = y - TM_YEAR_BASE; tmp->tm_yday = (int) days; tmp->tm_mday = (int) (days + 1);

} static unsigned long recalc_time(int year, int month, int day, int hour, int min, int sec)

/* year : 1970-2106, month 1-12, day 1-31, hour 0-23, min 0-59, sec 0-59 */

{ unsigned long secs; int days; int y; int m; days = 0; for (y = year - 1; y >= EPOCH_YEAR; y ) { days += days_in_year(y);

} for (m = TM_JANUARY; m < (month - 1); m++) { days += days_in_month(year, m);

} days += day - 1; secs = (days * SECS_PER_DAY); secs += (hour * SECS_PER_HOUR); secs += (min * SECS_PER_MIN); secs += sec; return (secs);

A description of the TPEG byte-stream using C-type notation

Explanation

A byte stream consists of a sequence of data elements Each data element in the byte stream is in bold type

A data element is characterized by its name, byte length, and a mnemonic indicating its type Data elements can be organized into a sequence defined as a function, with their names having a local scope within that function To access a data element from a parent function, the dotted notation 'function.data_element_name' is utilized, which can be further nested to reference elements up to the top-level function, such as 'function1.function2.data_element_name'.

The effect of a decoded data element in a byte stream is influenced by its value and the previously decoded data elements The process of decoding these data elements and defining the state variables involved is detailed in the clauses that provide the semantic description of the syntax Specific constructs are utilized to indicate the conditions under which data elements are present and are represented in normal type.

Definition of data elements

An array of data is represented as data_element [ ], where the number of elements is specified by the context The element data_element [n] refers to the (n+1)th element in the array, while data_element [m][n] denotes the (m+1, n+1)th element in a two-dimensional array Additionally, data_element [m n] indicates the inclusive range of bits from bit m to bit n within the data_element.

The procedural syntax outlines a valid input bitstream, ensuring it is free of errors To decode accurately, actual decoders must detect start codes and sync bytes, which are essential for initiating the decoding process Additionally, they need to identify errors, erasures, and insertions during decoding However, the techniques for recognizing these issues and the corresponding responses are not standardized.

Definition of conditional expressions

NOTE This syntax uses the ‘C’-code convention that a variable or expression evaluating to a non-zero value is equivalent to a condition that is true while (condition) { data_element

If the condition is true, the group of data elements occurs next in the data-stream This repeats until the condition is not true do { data_element

The data element always occurs at least once The data element is repeated until the condition is not true if (condition) { data_element

If the condition is true, then the first group of data elements occurs next in the data-stream

If the condition is not true, then the second group of data elements occurs next in the data-stream for (i=0 ; i

Tiêu đề	Intelligent Transport Systems — Traffic And Travel Information Via Transport Protocol Experts Group, Generation 1 (TPEG1) Binary Data Format — Part 2: Syntax, Semantics And Framing Structure (TPEG1-SSF)
Trường học	University of Alberta
Thể loại	technical specification
Năm xuất bản	2013
Thành phố	Geneva

Định dạng
Số trang	44
Dung lượng	1,07 MB