IEC PAS 61162-100:2002

IEC/PAS 61162-100
Edition 1.0
2002-04
Maritime navigation and radiocommunication
equipment and systems –
Digital interfaces –
Part 100:
Single talker and multiple listeners –
Extra requirements to IEC 61162-1
for the UAIS
PUBLI C LY AVAI LABLE SPECI F I CATI O N
IN TER N A TION AL
E L E C T R OT E CHNI CA L
Reference number
C O MMI S S I O N
IEC/PAS 61162-100
IEC/PAS 61162-100
Edition 1.0
2002-04
Maritime navigation and radiocommunication
equipment and systems –
Digital interfaces –
Part 100:
Single talker and multiple listeners –
Extra requirements to IEC 61162-1
for the UAIS
PUBLI C LY AVAI LABLE SPECI F I CATI O N
IN TER N A TION AL
E L E C T R OT E CHNI CA L
Reference number
C O MMI S S I O N
IEC/PAS 61162-100
– 2 – Copyright  2002, IEC
CONTENTS
FOREWORD .3

INTRODUCTION.4

Clause
1 Scope .5

2 Normative references .5

3 Definitions .6
3.1 Parametric sentences .6
3.2 Encapsulation sentences .6
4 Data requirements of the AIS.7
5 Existing IEC 61162-1 sentences for the AIS .7
6 Additional IEC 61162-1 parametric sentences for the AIS .8
7 New encapsulation sentence structures for the AIS .18
8 Data format protocol errors – error detection and handling .21
Annex A (normative) Approved encapsulation sentence structure .22
Annex B (normative) Summary of changes to existing IEC 61162-1 clauses which
have been modified to include encapsulation sentences .23
B.1 Message .23
B.2 Sequential Message Identifier .23
B.3 Multi-sentence Messages .23
B.4 Proprietary Sentences .23
B.5 Future additions to Approved sentences.24
B.6 Changes to the Reserved Character List .24
B.7 Changes to Character Symbol Table .24
B.8 Additions to field type summary : .25
Annex C (normative) Six bit binary field conversion .26
Annex D (informative) Example encapsulation sentences.29
D.1 New clause 7 to IEC 61162-1.29
D.2 Background Discussion - encapsulation coding .29
D.3 Decoding the Encapsulated String .31
D.4 Conversion from symbols to binary bits .31
D.5 Organizing the Binary Message Data .32
D.6 Interpreting the Decoded Binary Strings .32
Annex E (informative) Copy of ITU-R M.1371-1:2000, TABLE 15 .35
Figures
Figure C-1 - 6-bit binary code converted to valid IEC 61162-1 character .27
Figure C-2 - Valid IEC 61162-1 character converted to 6-bit binary code.28
Figure D-1 - Message Data format .30
Figure D-2 - Work sheet for decoding and interpreting encapsulated string .34

Copyright  2002, IEC – 3 –
INTERNATIONAL ELECTROTECHNICAL COMMISSION

____________
MARITIME NAVIGATION AND RADIOCOMMUNICATION EQUIPMENT

AND SYSTEMS – DIGITAL INTERFACES –

Part 100: Single talker and multiple listeners –

Extra requirements to IEC 61162-1 for the UAIS

FOREWORD
A PAS is a technical specification not fulfilling the requirements for a standard, but made available to
the public.
IEC-PAS 61162-100 has been processed by IEC technical committee 80: Maritime navigation and
radiocommunication equipment and systems.
The text of this PAS is based on the This PAS was approved for
following document: publication by the P-members of the
committee concerned as indicated in
the following document:
Draft PAS Report on voting
80/330/PAS 80/338/RVD
Following publication of this PAS, the technical committee or subcommittee concerned will investigate
the possibility of transforming the PAS into an International Standard.
This PAS document relates to International Standard IEC 61162-1. The document has been co-
ordinated with the TC 80 Working Group preparing the AIS Standard IEC 61993 Part 2, and the NMEA
Standards Committee.
1) The IEC (International Electrotechnical Commission) is a worldwide organization for standardization comprising
all national electrotechnical committees (IEC National Committees). The object of the IEC is to promote
international co-operation on all questions concerning standardization in the electrical and electronic fields. To
this end and in addition to other activities, the IEC publishes International Standards. Their preparation is
entrusted to technical committees; any IEC National Committee interested in the subject dealt with may
participate in this preparatory work. International, governmental and non-governmental organizations liaising
with the IEC also participate in this preparation. The IEC collaborates closely with the International
Organization for Standardization (ISO) in accordance with conditions determined by agreement between the
two organizations.
2) The formal decisions or agreements of the IEC on technical matters express, as nearly as possible, an
international consensus of opinion on the relevant subjects since each technical committee has representation
from all interested National Committees.
3) The documents produced have the form of recommendations for international use and are published in the form
of standards, technical specifications, technical reports or guides and they are accepted by the National
Committees in that sense.
4) In order to promote international unification, IEC National Committees undertake to apply IEC International
Standards transparently to the maximum extent possible in their national and regional standards. Any
divergence between the IEC Standard and the corresponding national or regional standard shall be clearly
indicated in the latter.
5) The IEC provides no marking procedure to indicate its approval and cannot be rendered responsible for any
equipment declared to be in conformity with one of its standards.
6) Attention is drawn to the possibility that some of the elements of this International Standard may be the subject
of patent rights. The IEC shall not be held responsible for identifying any or all such patent rights.

– 4 – Copyright  2002, IEC
INTRODUCTION
This document is issued as a IEC Publicly Available Specification according to the IEC/PAS

approval process. This agreed process allows the new information needed for the

development of UAIS to be placed in the public domain in a shorter timescale than revising

the appropriate International standards.

This document provides information on the necessary interface standards for use with the

UAIS, which are not available in the current issue of IEC 61162-1 Ed 2. The information in this

PAS supersedes that in annex B (informative) of IEC 61993-2, the Standard for UAIS.

This PAS will include the interface standards, which are currently being adopted in the NMEA
0183 standard and alignment will be maintained.
This PAS will be replaced at a future date by, or be included within, a revision of the
international standard IEC 61162-1.

Copyright  2002, IEC – 5 –
MARITIME NAVIGATION AND RADIOCOMMUNICATION EQUIPMENT

AND SYSTEMS – DIGITAL INTERFACES –

Part 100: Single talker and multiple listeners –

Extra requirements to IEC 61162-1 for the UAIS

1 Scope
All the requirements to effectively transmit the data of the mobile TDMA based AIS station are
included in this PAS.
Whilst the established Standard IEC 61162-1 sentences are available for certain functions a
number of new sentences are now required to permit all specified AIS data to be transmitted.
The total requirements for the AIS are included in this PAS document but the current
Standard IEC 61162-1 should be referred to for the reference data applicable to the existing
format.
The reader should be aware that certain of the new sentences may include new features not
currently included in IEC 61162-1. For this reason the PAS has been divided into three
sections, namely: -
- Existing IEC 61162-1 sentences to be employed in the AIS (and elsewhere) – see clause 5
- Additional IEC 61162-1 sentences to cover new AIS requirements, but maintaining the
standard format – see clause 6
- Proposed new sentence structures to meet specific AIS requirements and which cannot be
accommodated in the standard IEC 61162-1 format. These new sentence standards are
essentially designed to meet the AIS requirements and are not for general use – see
clause 7 and annex A.
2 Normative references
The following referenced documents are indispensable for the application of this document.
For dated references, only the edition cited applies. For undated references, the latest edition
of the referenced document (including any amendments) applies.
The references contained in IEC 61162-1 apply to this PAS. In addition the following apply:
IEC Standard 61993 Part 2: Universal Shipborne Automatic Identification System (AIS);
Operational and Performance Requirements, Methods of Test and required Test Results.

ITU-R M.1371-1:2001 Technical characteristics for a Universal Shipborne Automatic
Identification System (AIS) using TDMA in the VHF maritime mobile band.
IMO Recommendation on Performance Standards for a Universal Automatic Identification
System (AIS) MSC.74(69)
IMO SOLAS Convention, Chapter V (2002)
IMO HSC Code, Chapter 13
ISO/IEC 10646-1 (1993-05). Unicode Standard

– 6 – Copyright  2002, IEC
3 Definitions
3.1 Parametric sentences
(See IEC 61162-1 clause 5 Data format protocol)

These sentences start with the “$” (HEX 24) delimiter and represent the majority of approved

sentences defined by IEC 61162-1 and this PAS. This is the preferred method for conveying

information. Refer to clauses 5 and 6 for details.

The maximum number of characters in a sentence shall be 82, consisting of a maximum of 79

characters between the starting delimiter “$” and the terminating delimiter .

The minimum number of fields in a sentence is one (1). The first field shall be an address field
containing the identity of the talker and the sentence formatter, which specifies the number of
data fields in the sentence, the type of data they contain and the order in which the data fields
are transmitted. The remaining portion of the sentence may contain zero or multiple data
fields.
The maximum number of fields allowed in a single sentence is limited only by the maximum
sentence length and shall always be used even if data for that field is unavailable.
The basic rules for parametric sentence structures are:
- The sentence begins with the “$” delimiter.
- Only approved sentence formatters are allowed. Formatters used by special-purpose
encapsulation sentences cannot be re-used. (See IEC 61162-1, clause 6.2 (table 5).)
- Only valid characters are allowed. (See IEC 61162-1, clause 6.1 (tables 1 and 2).)
- Only approved field types are allowed. (See IEC 61162-1, clause 6.2 (table 6).)
- Data fields (parameters) are individually delimited, and their content is identified and often
described in detail by this standard.
- Encapsulated non-delimited data fields are NOT ALLOWED.
3.2 Encapsulation sentences
(New definition not currently in IEC 61162-1)
These sentences start with the “!” (HEX 21) delimiter. The function of this special-purpose
sentence structure is to provide a means to convey information, when the specific data
content is unknown or greater information bandwidth is needed. This is similar to a modem
that transfers information without knowing how the information is to be decoded or
interpreted.
The basic rules for encapsulation sentence structures are:
- The sentence begins with the “!” delimiter.
- Only approved sentence formatters are allowed. Formatters used by conventional
parametric sentences can not be re-used. (See clauses 5 and 6, and IEC 61162-1, clause
6.2 (table 5)).
- Only valid characters are allowed. (See IEC 61162-1, clause 6.1 (tables 1 and 2).)
- Only approved field types are allowed. (See annex B.5 and IEC 61162-1, clause 6.2
(table 6).)
- Only Six bit coding may be used to create encapsulated data fields. (See annex B.5.)
- Encapsulated data fields may consist of any number of parameters, and their content is
not identified or described by this standard.
- The sentence must be defined with one encapsulated data field and any number of
parametric data fields separated by the “,” data field delimiter. The encapsulated data

Copyright  2002, IEC – 7 –
field shall always be the second to last data field in the sentence, not counting the

checksum field. (See IEC 61162-1, clause 5.2.2.)

- The sentence contains a “Total Number Of Sentences” field. (See annex A.)

- The sentence contains a “Sentence Number” field. (See annex A.)

- The sentence contains a “Sequential Message Identifier” field. (See annex A.)

- The sentence contains a “Fill Bits” field immediately following the encapsulated data field.

The Fill Bits field shall always be the last data field in the sentence, not counting the

checksum field. (See annex A.)

NOTE : This method of conveying information is to be used only when absolutely necessary, and will only be

considered when one or both of two conditions are true, and when there is no alternative.

Condition 1: The data parameters are unknown by devices having to convey the information. For example, the ABM
and BBM sentences meet this condition, because the content is not known to the Automatic Identification System
(AIS) transponder.
Condition 2: When information requires a significantly higher data rate than can be achieved by the IEC61162-1
(4,800baud) and IEC61162-2 (38,400baud) standards utilising parametric sentences.
By encapsulating a large amount of information, the number of overhead characters such as “,” field delimiters can
be reduced, resulting in higher data transfer rates. It is very unusual for this second condition to be fulfilled. As an
example, an AIS transponder has a data rate capability of 4,500 messages per minute, and satisfies this condition,
resulting in the VDM and VDO sentences.
4 Data requirements of the AIS
A portion of the information broadcast by an AIS unit is obtained from sensors using existing
IEC 61162-1 sentence formatters. The sensor data and the existing sentence formatters
recognised by the AIS unit are listed in IEC 61993-2 ( See IEC 61993-2 clauses : 6.10.1.1;
7.6.2.3, table 9 – preferred IEC 61162-1 sensor sentences; and 7.6.3.3.)
Expanded data requirements, not satisfied by the present IEC 61162-1 sentence formatters,
are satisfied by the new sentence formatters described in clauses 6 and 7. The new sensor
input sentence formatters include : ABM, ACA, AIR, BBM, LRF, LRI, SSD AND VSD.
5 Existing IEC 61162-1 sentences for the AIS
Listing of approved sentences as given in IEC 61162-1 that apply. Only the sentence header
and description to be given here. Refer to IEC 61162-1 clause 6.3
Formatter Meaning
ACK Acknowledgement alarm
ALR Set alarm state
DSI DSC transponder initialise
DSR DSC transponder response
DTM Datum reference
GBS GNSS satellite fault detection
GLL Geographic position, latitude/longitude
GNS GNSS fix data
HDT Heading true
OSD Own ship data
RMC Recommended minimum specific GNSS data
ROT Rate of turn
RTE Routes
TXT Text transmission
VBW Dual ground/water speed
VTG Course over ground and ground speed
WPL Waypoint location
– 8 – Copyright  2002, IEC
6 Additional IEC 61162-1 parametric sentences for the AIS

Listing of the new approved sentences, including structure and notes

ABK - AIS addressed and binary broadcast acknowledgement

The ABK-sentence is generated when a transaction, initiated by reception of an ABM, AIR, or

BBM sentence, is completed or terminated. This sentence provides information about the

success or failure of a requested ABM broadcast of either ITU-R M.1371 messages 6 or 12.

The ABK process utilises the information received in ITU-R M.1371 messages 7 and 13.

Upon reception of either a VHF Data-link message 7 or 13, or the failure of messages 6 or 12,

the AIS unit delivers the ABK sentence to the external application. This sentence is also used
to report to the external application the AIS unit’s handling of the AIR (ITU-R M.1371 message
15) and BBM (ITU-R M.1371 messages 8, 14, 19, and 21) sentences. The external
application initiates an interrogation through the use of the AIR-sentence, or a broadcast
through the use of the BBM sentence. The AIS unit generates an ABK sentence to report the
outcome of the AIR, or BBM broadcast process.
$--ABK,xxxxxxxxx,x,x.x,x,x*hh
Type of acknowledgement
Message sequence number
ITU-R M.1371Message ID
AIS channel of reception
MMSI of the addressed AIS unit
NOTE 1 Identifies the distant addressed AIS unit involved with the acknowledgement. If more than one MMSI are
being addressed (ITU-R M.1371 messages 15 and 16), the MMSI of the first distant AIS unit, identified in the
message, is the MMSI reported here. This is a null field when the ITU-R M.1371 message type is 8 or 14.
NOTE 2 Indication of the VHF Data Link channel upon which a message type 7 or 13 acknowledgement was
received. An “A” indicates reception on channel A. A “B” indicates reception on channel B.
NOTE 3 This indicates to the external application the type of ITU-R M.1371 message that this ABK sentence is
addressing. Also see the Message IDs listed in Note 4.
NOTE 4 The Message sequence number, together with the Message ID and MMSI of the addressed AIS unit,
uniquely identifies a previously received ABM, AIR, or BBM sentence. Generation of an ABK sentence makes a
sequence message identifier available for re-use. The Message ID determines the source of the Message
sequence number. The following table lists the source by message ID:
ITU-R M.1371 Message ID Message Sequence Number source
6 sequential message identifier from ABM-sentence, (See clause 5, ABM sentence)
7 addressed AIS unit’s message 7, sequence number, ITU-R M.1371-1

8 sequential message identifier from BBM-sentence, (See clause 5, BBM sentence)
12 sequencial message identifier from ABM-sentence, (See clause 5, ABM sentence)
13 addressed AIS unit’s message 13, sequence number, ITU-R M.1371-1
14 sequential message identifier from BBM-sentence, (See clause 5, BBM sentence)
15 no source, the Message sequence number shall be null
NOTE 5 Acknowledgements provided are:
0 = message (6 or 12) successfully received by the addressed AIS unit,
1 =message (6 or 12) was broadcast, but no acknowledgement by the addressed AIS unit,
2 =message could not be broadcast (i.e. quantity of encapsulated data exceeds five slots)
3 =requested broadcast of message (8, 14 or 15) has been successfully completed,
4 =late reception of a message 7 or 13 acknowledgement that was addressed to this AIS unit (own-ship) and
referenced as a valid transaction

Copyright  2002, IEC – 9 –
ACA – AIS Channel assignment message

An AIS device can receive regional channel management information in four ways: ITU-R
M.1371-1 message 22, DSC telecommand received on channel 70, manual operator input,
and an ACA sentence. The AIS unit may store channel management information for future

use. Channel management information is applied based upon the actual location of the AIS

device. An AIS unit is “using” channel management information when the information is being

used to manage the operation of the VHF receiver and/or transmitter inside the AIS unit.

This sentence is used both to enter and obtain channel management information. When sent

to an AIS unit, the ACA sentence provides regional information that the unit stores and uses

to manage the internal VHF radio. When sent from an AIS unit, the ACA sentence provides
the current channel management information retained by the AIS unit. The information
contained in this sentence is similar to the information contained in an ITU-R M.1371-1
message 22. The information contained in this sentence directly relates to the Initialisation
Phase and Dual Channel Operation and Channel Management functions of the AIS unit as
described in ITU-R M. 1371.
$--ACA,x,llll.ll,a,yyyyy.yy,a,llll.ll,a,yyyyy.yy,a,x,xxxx,x,xxxx,x,x,x,a,x,hhmmss.ss*hh
Time of “inuse” change
In-Use Flag
Information source
Power level control
Tx/Rx mode control
Channel B bandwidth
Channel B
Channel A bandwidth
Channel A
Transition Zone Size
Region southwest corner longitude - E/W
Region southwest corner latitude - N/S
Region northeast corner longitude - E/W
Region northeast corner latitude - N/S
Sequence Number , 0 to 9
NOTE 1 This is used to bind the contents of the ACA and ACS sentences together. The ACS sentence, when
provided by the AIS unit, shall immediately follow the related ACA sentence, containing the same sequence
number. The AIS unit generating the ACA and ACS sentences, shall increment the sequence number each time an
ACA/ACS pair is created. After 9 is used the process shall begin again from 0. Information contained in the ACS
sentence is not related to the information the ACA sentence if the sequence numbers are different. When an AIS
unit is queried for an ACA sentence, the AIS unit should respond with the ACA/ACS sentence pair. When an
external device is sending an ACA sentence to the AIS unit, the sequence number may be null if no ACS sentence
is being sent.
NOTE 2 Range of 1 to 8 nautical miles.
NOTE 3 VHF channel number, see ITU-R M.1084, Annex 4
NOTE 4 Value of 0, bandwidth is specified by channel number, see ITU-R M.1084, Annex 4
Value of 1, bandwidth is 12.5 kHz.
NOTE 5 Value of 0, transmit on channels A and B, receive on channels A and B
Value of 1, transmit on channel A, receive on channels A and B
Value of 2, transmit on channel B, receive on channels A and B
Value of 3, do not transmit, receive on channels A and B
Value of 4, do not transmit, receive on channel A
Value of 5, do not transmit, receive on channel B
NOTE 6 Value of 0, high power
Value of 1, low power
NOTE 7 Source identifiers:
A = ITU-R M.1371 message 22: Channel Management addressed message,

– 10 – Copyright  2002, IEC
B = ITU-R M.1371 message 22: Channel Management broadcast geographical area message,

C = IEC 61162-1 AIS Channel Assignment sentence,

D = DSC Channel 70 telecommand, and

M = operator manual input.
This field should be null when the sentence is sent to an AIS device.

NOTE 8 This value is set to indicate that the other parameters in the sentence are “in-use” by an AIS unit at the

time that the AIS unit sends this sentence. A value of “0” indicates that the parameters are not “in-use,” and a

value of “1” indicates that the parameters are “in-use.” This field should be null when the sentence is sent to an
AIS unit.
NOTE 9 This is the UTC time that the “In-Use Flag” field changed to the indicated state. This field should be null
when the sentence is sent to an AIS unit

ACS - AIS Channel management information Source
This sentence is used in conjunction with the ACA sentence. This sentence identifies the
originator of the information contained in the ACA sentence and the date and time the AIS unit
received that information.
$--ACS,x,xxxxxxxxx,hhmmss.ss,xx,xx,xxxx*hh
Year
Month, 01 to 12        UTC
Day, 01 to 31
UTC of receipt of channel management information
MMSI of originator
Sequence number 0 to 9
,
NOTE 1 This is used to bind the contents of the ACA and ACS sentences together. The ACS sentence, when
provided by the AIS unit, shall immediately follow the related ACA sentence, containing the same sequence
number. The AIS unit generating the ACA and ACS sentences, shall increment the sequence number each time an
ACA/ACS pair is created. After 9 is used the process shall begin again from 0. Information contained in the ACS
sentence is not related to the information the ACA sentence if the sequence numbers are different. When an
external device is sending an ACA sentence to the AIS unit, the sequence number may be null if no ACS sentence
is being sent.
Copyright  2002, IEC – 11 –
AIR - AIS Interrogation request.

This sentence supports ITU-R M.1371 message 15. It provides an external application with
the means to initiate requests for specific ITU-R M.1371 messages, from distant mobile or
base station, AIS units. A single sentence can be used to request up to two messages from

one AIS unit and one message from a second AIS unit, or up to three messages from one AIS

unit. The message types that can be requested are limited. The complete list of messages

that may be requested can be found within the Message 15 description in ITU-R M.1371.

Improper requests may be ignored.

The external application initiates the interrogation. The external application is responsible for

assessing the success or failure of the interrogation. After receiving this sentence, the AIS
unit initiates a radio broadcast (on the VHF Data Link) of a message 15 - Interrogation. The
success or failure of the interrogation broadcast is determined by the application using the
combined reception of the ABK-sentence and future VDM sentences provided by the AIS unit.
After receiving this AIR-sentence, the AIS unit shall take no more than four seconds to
broadcast the message 15, and the addressed distant unit(s) shall take no more than another
four seconds to respond - a total of eight seconds.
$--AIR,xxxxxxxxx,x.x,x,x.x,x,xxxxxxxxx,x.x,x*hh
Message sub-section
Number of messages requested from station-2
MMSI of interrogated station-2
Message sub-section
Number of second message requested from station-1
Message sub-section
ITU-R M.1371 message requested from station-1
MMSI of interrogated station 1
NOTE 1 Identifies the first distant AIS unit being interrogated. Two messages can be requested from the first AIS
unit.
NOTE 2 Examples of messages that may be requested from a distant mobile AIS unit include :
Message 3, = Position Report,
Message 5, = Ship static and voyage related data, see additional information in Note 3.
Message 9, Standard SAR Aircraft Position Report
Message 18, Standard Class B equipment position report.
Message 19, Extended Class B equipment position report
Message 21, Aids-to-navigation report.

Examples of messages that may be requested from a distant AIS base station include :
Message 4 = Base Station Report
Message 17 = GNSS Broadcast Binary Message. Message 20 = Data Link Management Message
Message 20 = Data link management message
Message 22 = Channel Management
NOTE 3 This field is used to request a message that has been further sub-divided into alternative data structures.
When requesting a message with alternative data structures, this message sub-section field must be provided, so
that the correct sub-division of the message data is provided. If the message structure is not sub-divided into
different structures, this field should be null.
NOTE 4 This identifies the second distant AIS unit being interrogated. Only one message may be requested from
the second AIS unit. The MMSI of the second AIS unit may be the same MMSI as the first AIS unit.

– 12 – Copyright  2002, IEC
LRI - AIS Long-range Interrogation

The Long-range interrogation of the AIS unit is accomplished through the use of two
sentences. The pair of interrogation sentence formatters, a LRI sentence followed by a LRF
sentence, provides the information needed by a universal AIS unit to determine if it must

construct and provide the reply sentences (LRF, LR1, LR2, and LR3). The LRI sentence

contains the information that the AIS unit needs in order to determine if the reply sentences

need to be constructed. The LRF sentence identifies the information that needs to be in those

reply sentences.
Longitude - E/W (south-west coordinate)
Latitude - N/S (south-west coordinate)
$--LRI,x,a,xxxxxxxxx,xxxxxxxxx,llll.ll,a,yyyyy.yy,a,llll.ll,a,yyyyy.yy,a*hh
Longitude - E/W (north-east co-ordinate)
Latitude - N/S (north-east co-ordinate)
MMSI of destination
MMSI of requestor
Control Flag
Sequence number , 0 to 9
NOTE 1 This is used to bind the contents of the LRI and LRF sentences together. The LRF sentence shall
immediately follow the LRI sentence and use the same sequence number. The requestor process shall increment
the sequence number each time a LRI/LRF pair is created. The sequencing process shall continuously increment.
After 9 is used the process shall begin again from 0.The long-range interrogation is not valid if the LRI and LRF
sequence numbers are different.
NOTE 2 The control flag is a single character that qualifies the request for information. The control flag affects AIS
unit’s reply logic. The control flag cannot be a null field. When the Control Flag is “0”, the logic is normal. Under
“normal” operation, the AIS unit responds if either :
- The AIS unit is within the geographic rectangle provided, and
- the AIS unit has not responded to the requesting MMSI in the last 24 hours and
- the MMSI “destination” field is null.
or
_ The AIS unit’s MMSI appears in the MMSI “destination” field in the LRI sentence.
When the Control Flag is “1”, the AIS unit responds if :
- The AIS unit is within the geographic rectangle provided.
NOTE 3 This is the nine digit number that uniquely identifies the specific AIS unit that should respond. This field

should be null when the interrogation is for a geographic region. When addressing a specific AIS unit, it is not
necessary to provide the geographic co-ordinates of the region.
NOTE 4 The geographic region being interrogated is a rectangle defined by the latitude and longitude of the north-
east and south-west corners. These should be null fields when interrogating a specific AIS unit (see Note 2).

Copyright  2002, IEC – 13 –
LRF - AIS Long-Range Function
This sentence is used in both long-range interrogation requests and long-range interrogation
replies. The LRF-sentence is the second sentence of the long-range interrogation request
pair, LRI and LRF (see the LRI-sentence).

The LRF-sentence is also the first sentence of the long-range interrogation reply. The
minimum reply consists of a LRF-sentence followed by a LR1-sentence. The LR2-sentence

and/or the LR3-sentence follow the LR1-sentence if information provided in these sentences

was requested by the interrogation. When the AIS unit creates the LRF-sentence for the long-

range interrogation reply, fields 1, 2, 3 and 4 should remain as received in the long-range

interrogation request; and field 5 (function reply status) and the new checksum are added to
the LRF reply sentence.
$--LRF,x,xxxxxxxxx,c—c,c—c,c—c*hh
Function reply status
Function request , 1 to 26 characters
Name of requestor, 1 to 20 character
MMSI of requestor
Sequence number 0 to 9
,
NOTE 1 This is used to bind the contents of the LRI and LRF sentences together. The LRF sentence shall
immediately follow the LRI sentence and use the same sequence number. The requestor process shall increment
the sequence number each time a LRI/LRF pair is created. After 9 is used the process shall begin again from 0.
The Long-range interrogation is not valid if the LRI and LRF sequence numbers are different.
NOTE 2 The Function request field uses alphabetic characters, based upon IMO Resolution A.851(20), to request
specific information items. Specific information items are requested by including their function identification
character in this string of characters. The order in which the characters appear in the string is not important. All
characters are upper-case. Information items will not be provided if they are not specifically requested - even if
available to the AIS unit. The IMO Resolution defines the use of all characters from A to Z, but not all defined
information is available to the AIS unit. The following is a list of the function identification characters, with the
information they request:
A = Ship’s: name, call sign, and IMO number
B = Date and time of message composition
C = Position
E = Course over ground
F = Speed over ground
I = Destination and Estimated Time of Arrival (ETA)

O = Draught
P = Ship / Cargo
U = Ship’s: length, breadth, type
W = Persons on board
NOTE 3 The Function reply status field provides the status characters for the “Function request” information. When
the long-range interrogation request is originated, the “Function reply status” field should be null. The “Function
reply status” characters are organised in the same order as the corresponding function identification characters in
the “Function request” field. The following is a list of the “Function reply status” characters with the status they
represent :
2 = information available and provided in the following LR1, LR2 or LR3 sentence,
3 = information not available from AIS unit,
4 = information is available but not provided (i.e. restricted access determined by the ship’s master)

– 14 – Copyright  2002, IEC
LR1 - AIS Long-range Reply Sentence 1

The LR1 sentence identifies the destination for the reply and contains the information items
requested by the “A” function identification character (See the LRF sentence).

$--LR1,x,xxxxxxxxx,xxxxxxxxx,c—c,c—c,xxxxxxxxx*hh

IMO Number , 9-digit number
Call Sign , 1 to 7 characters
Ship’s name , 1 to 20 characters
MMSI of requestor (reply destination)
MMSI of responder
1,2
Sequence Number
NOTE 1 The three fields, sequence number, MMSI of responder and MMSI of requestor are always provided.
NOTE 2 The sequence number should be the same number as the sequence number of the LRI and LRF sentences
that initiated this reply.
NOTE 3 The characters that can be used are listed in the ITU-R M.1371, 6-bit ASCI Table 14. Some of the
acceptable characters in this 6-bit ASCI table are the reserved characters within this standard IEC 61162-1, Table
1. These characters must be represented using the “^” method (see IEC 61162-1 clause 5.1.3). The individual
information items shall be a null field if any of the following three conditions exist:
The information item was not requested,
the information item was requested but is not available,
the information item was requested but is not being provided.
LR2 - AIS Long-range Reply Sentence 2
The LR2-sentence contains the information items requested by the “B, C, E and F” function
identification characters,(see the LRF sentence)
Speed over ground, Knots
Course over ground, degrees, True
Longitude, E/W
$--LR2,x,xxxxxxxxx,xxxxxxxx,hhmmss.ss,llll.ll,a,yyyyy.yy,a,x.x,T,x.x,N*hh

Latitude - N/S
UTC time of Position
Date: ddmmyyyy, 8 digits
MMSI of responder
1,2
Sequence Number
NOTE 1 The two fields, sequence number and MMSI of responder, are always provided.
NOTE 2 The sequence number should be the same as the sequence number of the LRI and LRF sentences that
initiated this reply.
NOTE 3 This field should be null if any of the following three conditions exist:
The information item was not requested,
the information item was requested but is not available,
the information item was requested but is not being provided.

Copyright  2002, IEC – 15 –
LR3 - AIS Long-range Reply Sentence 3

The LR3 sentence contains the information items requested by the “I, O, P, U and W” function
identification character (see the LRF sentence).

3, 4
Persons , 0 to 8191
3,6
Ship type
Ship breadth
Ship length
$--LR3,x,xxxxxxxxx,c—c,xxxxxx,hhmmss.ss,x.x,x.x,x.x,x.x,x.x,x.x*hh
3,6,6
Ship/cargo
Draught
ETA Time
ETA Date: ddmmyy
3,5
Voyage destination , 1 to 20 characters
MMSI of responder
1,2
Sequence Number
NOTE 1 The two fields, sequence number and MMSI of responder are always provided.
NOTE 2 The sequence number should be the same as the sequence number of the LRI and LRF sentences that
initiated this reply.
NOTE 3 This field should be null if any of the following three conditions exist:
the information item was not requested,
the information item was requested but is not available,
the information item was requested but is not being provided.
NOTE 4 Current number of persons on-board, including crew members : [0 to 8191,
0 = default (not available), ]
8191 = 8191 or more people.
NOTE 5 The characters that can be used are listed in the ITU-R M.1371, 6-bit ASCI Table 14. Some of the
acceptable characters in this 6-bit ASCI table are the reserved characters within this standard IEC 61162-1, Table
1. These characters must be represented using the “^” method (see IEC 61162-1 clause 5.1.3).
NOTE 6 See ITU-R M.1371, Table 17, Parameter “Type of ship and cargo type” for the range of valid values for this
field.
– 16 – Copyright  2002, IEC
SSD – AIS Ship static data
This sentence is used to enter static parameters into a shipboard AIS unit. The parameters in
this sentence support a number of the ITU-R M.1371 messages.

$--SSD,c—c,c—c,xxx,xxx,xx,xx,c,aa*hh

Source identifier
DTE indicator flag
Pos. ref.,point dist. “D,” from starboard beam , 0 to 63 metres
Pos. ref., point dist.“C,” from port beam , 0 to 63 Metres
Pos. ref.,point dist. “B,” from stern , 0 to 511 Metres
Pos. ref., point dist.“A,” from bow , 0 to 511 metres
Ship’s Name , 1 to 20 characters
Ship’s Call Sign , 1 to 7 characters
NOTE 1 Ship call sign. A null field indicates that the previously entered call sign is unchanged. The string of
characters “@@@@@@@” are used to indicate that the call sign is not available.
NOTE 2 The characters that can be used in the name are listed in the ITU-R M.1371, 6-bit ASCI Table 14. Some
of the acceptable characters in this 6-bit ASCI table are the reserved characters within this standard IEC 61162-1,
Table 1. These characters must be represented using the “^” method (see IEC 61162-1 clause 5.1.3). A null field
indicates that the previously entered name is unchanged. The string of characters
“@@@@@@@@@@@@@@@@@@@@” is used to indicate that the ship’s name is not available.
NOTE 3 These are the four dimensions from the bow, stern, port beam, and starboard beam to the horizontal
reference point on the ship for which the current “position reports” are valid. The sum of A + B is the length of the
ship in meters, and the sum of C + D is the width of the ship in meters. Refer to the ITU-R M.1371, Message 5,
“Reference Point for reported position and Dimensions of Ship.” If the reference point of “reported position” is not
available, but the dimensions of the ship are available: A = C = 0 and B > 0 and D > 0. If neither the reference
point for the reported position nor the dimensions of the ship are available: A = B = C = D = 0 (default). Use of a
null field for A, B, C, and/or D indicates that the previously entered dimension for that parameter is unchanged. In
many cases, the ship’s reference point for “reported position” will be the location of the positioning antenna.
NOTE 4 The DTE indicator is an abbreviation for Data Terminal Equipment indicator. The purpose of the DTE
indicator is to inform distant receiving applications that, if set to “available,” the transmitting station conforms, at
least, to the minimum keyboard and display requirements. The DTE indicator is only used as information provided
to the application layer - indicating that the transmitting station is available for communications. On the
transmitting side, the DTE indicator may be set by an external application using this sentence. DTE indicator flag
values are:
0 = Keyboard and display are a standard configuration, and communication is supported.
1= Keyboard and display are either unknown or unable to support communication.
NOTE 5 The source identifier contains the Talker ID of the equipment at this location

Copyright  2002, IEC – 17 –
VSD – AIS Voyage static data
This sentence is used to enter information about a ship’s transit that remains relatively static
during the voyage. However, the information often changes from voyage to voyage. The
parameters in this sentence support a number of the ITU-R M.1371 messages.

$--VSD,x.x,x.x,x.x,c—c,hhmmss.ss,xx,xx,x.x,x.x*hh

Regional application flags , 0 to 15
Navigational status , 0 to 15
Estimated month of arrival at destination , 00 to 12 (UTC)
Estimated day of arrival at destination , 00 to 31 (UTC)
Estimated UTC of arrival at destination
Destination , 1-20 characters
Persons on-board , 0 to 8191
Maximum present static draught , 0 to 25.5 Meters
Type of ship and cargo category , 0 to 255
NOTE 1 Type of ship and cargo category are defined under Message 5 of ITU-R M.1371. The descriptions of ship
and cargo are indicated by a number. The values are defined in ITU-T M. 1371, message 5. A null field indicates
that this is unchanged.
NOTE 2 The draught is reported in units of metres. valid range is 0 to 25.5. The value 0 = not available and the
value 25.5 indicates that the draught is 25.5 metres or more. A null field indicates that this is unchanged.
NOTE 3 Current number of persons on-board including crew. Valid range is 0 to 8191.The value 0 = not available
and the value 8191 = 8191 or more people. A null field indicates that this is unchanged.
NOTE 4 The characters that can be used in the destination are listed in the ITU-R M.1371, 6-bit ASCI Table 14.
Some of these characters are reserved characters in IEC 61162-1, table 1. These characters must be represented
“A”
using the method (see IEC 61162-1, clause 5.1.3). A null field indicates that the previously entered destination
is unchanged. The string of characters “@@@@@@@@@@@@@@@@@@@@” are used to indicate that the
ship’s destination is not available.
NOTE 5 If the hour of arr
...