Ryan Malloy 4ed92efd69 refactor: move spec references out of published site

Cospas-Sarsat specification summaries moved to reference/ for internal
use only. Links updated to point to official cospas-sarsat.int site.

The extracted images remain in public/ for use in other pages.

2026-02-13 05:03:09 -07:00

193 KiB

Raw Blame History

title

description

sidebar

documentId

series

seriesName

documentType

isLatest

issue

revision

documentDate

originalTitle

G005: C/S G.005 - Issue 3 - Rev. 2

Official Cospas-Sarsat G-series document G005

badge

text	variant
G	note

G005

General

overview

true

October 2023

C/S G.005 - Issue 3 - Rev. 2

📋 Document Information

Series: G-Series (General) Version: Issue 3 - Revision 2 Date: October 2023 Source: Cospas-Sarsat Official Documents

COSPAS-SARSAT GUIDELINES ON 406 MHz BEACON CODING, REGISTRATION, AND TYPE APPROVAL C/S G.005 Issue 3 – Revision 2

COSPAS-SARSAT GUIDELINES ON 406 MHz BEACON CODING, REGISTRATION, AND TYPE APPROVAL History Issue Revision Date Comments

Approved by the Cospas-Sarsat Council (CSC-9)

Approved by the Cospas-Sarsat Council (CSC-21)

Approved by the Cospas-Sarsat Council (CSC-23)

Approved by the Cospas-Sarsat Council (CSC-37)

Approved by the Cospas-Sarsat Council (CSC-41)

Approved by the Cospas-Sarsat Council (CSC-43)

Approved by the Cospas-Sarsat Council (CSC-45)

Approved by the Cospas-Sarsat Council (CSC-51)

Approved by the Cospas-Sarsat Council (CSC-53)

Approved by the Cospas-Sarsat Council (CSC-59)

Approved by the Cospas-Sarsat Council (CSC-62)

Approved by the Cospas-Sarsat Council (CSC-69)

TABLE OF CONTENTS Page History ................................................................................................................................................. i Table of Contents ................................................................................................................................. ii List of Figures ................................................................................................................................ iv List of Tables ................................................................................................................................. v List of Annexes ................................................................................................................................. v 1. INTRODUCTION .............................................................................................. 1-1 1.1 Overview .............................................................................................................. 1-1 1.2 Scope 1-1 1.3 Reference Documents .......................................................................................... 1-2 1.4 Summary of the Cospas-Sarsat Guidelines on Beacon Coding, Registration and Type Approval ................................................................................. 1-2 2. BACKGROUND INFORMATION ON THE 406 MHz System ................... 2-1 2.1 406 MHz Beacons ................................................................................................ 2-1 2.2 Beacon Identification ........................................................................................... 2-1 2.3 Operational Use of Beacon Registration Databases ............................................. 2-2 2.4 Encoded Position Data ......................................................................................... 2-3 3. FIRST GENERATION 406-MHz BEACON CODING (FGB) ..................... 3-1 3.1 C/S T.001 or C/S T.015 Beacon Types ................................................................ 3-1 3.2 General Coding Requirements ............................................................................. 3-8 3.2.5 General Format and Field Definition of the 406 MHz Beacon Message . 3-8 3.2.5.1 The short message format consists of: ....................................................................... 3-8 3.2.5.2 The long message format consists of: ........................................................................ 3-8 3.2.2 Preamble ................................................................................................... 3-9 3.2.2.1 Standard Preamble ..................................................................................................... 3-9 3.2.2.2 Self-Test Mode Preamble .......................................................................................... 3-9 3.2.3 First Protected Data Field (PDF-1) ........................................................ 3-10 3.2.3.1 General Structure of the First Protected Data Field (PDF-1) .................................. 3-10 3.2.3.2 Format Flag, Protocol Flag and Country Code ........................................................ 3-10 3.2.3.3 Identification Data and Position Data ...................................................................... 3-12 3.2.3.4 Fifteen Hexadecimal Character Beacon Identification ............................................ 3-12 3.2.4 21-bit First BCH Error Correcting Field (BCH-1) ................................. 3-13 3.2.5 Non-Protected Data Field of the Short Message Format ....................... 3-13 3.2.6 Second Protected Data Field (PDF-2) .................................................... 3-14 3.2.7 Second BCH Error Correcting Field (BCH-2) ....................................... 3-15 3.3 Coding User Protocols ....................................................................................... 3-16

3.3.1 General Requirements for User Protocols .............................................. 3-16 3.3.2 Coding Maritime Protocols .................................................................... 3-18 3.3.2.1 Coding the Maritime User Protocol with MMSI ..................................................... 3-19 3.3.2.2 Coding EPIRBs with a Unique Serial Number ........................................................ 3-19 3.3.2.3 Coding EPIRBs with the Radio Call Sign Identification ......................................... 3-21 3.3.2.4 3.3.2.3.1 Coding the Maritime User Protocol with the Radio Call Sign ................. 3-21 3.3.2.5 3.3.2.3.2 Coding the Radio Call Sign User Protocol with the Radio Call Sign ....... 3-22 3.3.3 Coding Aviation Protocols ..................................................................... 3-23 3.3.3.2 3.3.3.1 Coding ELTs with the Beacon Serial Number ............................................ 3-24 3.3.3.3 Coding ELTs with the Aircraft Operator Designator and a Serial Number ............. 3-25 3.3.3.4 Coding ELTs with the Aircraft 24-bit Address ....................................................... 3-25 3.3.3.5 Coding ELTs with the Aircraft Nationality and Registration Marking ................... 3-27 3.3.4 Coding PLBs with the Serial User Protocol ........................................... 3-28 3.3.5 Coding the Test User Protocol ............................................................... 3-28 3.3.6 Coding the National User Protocol ........................................................ 3-30 3.4 Coding Location Protocols ................................................................................. 3-31 3.4.1 Position Data Encoding .......................................................................... 3-32 3.4.2 Coding the User-location Protocols ....................................................... 3-33 3.4.3 Coding the Standard Location Protocols ................................................ 3-34 3.4.4 Coding the National Location Protocol .................................................. 3-38 3.4.5 Coding the RLS Location Protocols....................................................... 3-40 3.4.6 Coding the ELT(DT) Location Protocols ............................................... 3-44 3.4.6.1 ELT(DT) Cancellation Message .............................................................................. 3-48 3.4.7 Coding the Test Location Protocols ....................................................... 3-48 4. SECOND GENERATION 406-MHz BEACON CODING (SGB) ................. 4-1 4.1 C/S T.018 Beacon Types ...................................................................................... 4-1 4.2 General Coding Requirements ............................................................................. 4-2 4.2.1 Overall SGB Message Structure .............................................................. 4-2 4.2.1.2 Preamble .................................................................................................................... 4-2 4.2.1.3 Useful Message ......................................................................................................... 4-2 4.2.1.4 Protected Data Field .................................................................................................. 4-2 4.2.2 General Format and Field Definition of the SGB 406-MHz Message ..... 4-2 4.2.3 23-Hexadecimal ID .................................................................................. 4-3 4.3 SGB Specific Coding Features ............................................................................. 4-3 4.3.1 Location vs. Non-Location Encoded Beacons ......................................... 4-3 4.3.2 Spreading Codes ....................................................................................... 4-4 4.3.3 Transmission Schedule ............................................................................. 4-4 4.3.4 Message Fields ......................................................................................... 4-4 4.3.4.1 Main Field ................................................................................................................. 4-4 4.3.4.2 Rotating Fields .......................................................................................................... 4-6 4.3.5 SGBs and Programming Adaptors ........................................................... 4-6 4.3.6 SGBs Message Format for Transmission in the Ground Segment ........... 4-7 4.4 SGB Coding Examples ......................................................................................... 4-7 4.4.1 EPIRBs ..................................................................................................... 4-7 4.4.2 ELTs ......................................................................................................... 4-7

4.4.3 ELT(DT)s ................................................................................................. 4-7 4.4.4 PLBs ......................................................................................................... 4-7 5. BEACON REGISTRATION ............................................................................. 5-1 5.1 Purpose of Beacon Registration ........................................................................... 5-1 5.2 General Principals for Registering 406 MHz Beacons ........................................ 5-1 5.2.1 Where to Register 406 MHz Beacons ...................................................... 5-1 5.2.2 Country of Registration – Coding Procedure ........................................... 5-2 5.2.3 Control and Updating of Registered Information .................................... 5-2 5.2.4 Access to Registration Databases ............................................................. 5-2 5.2.5 Content of National Registration Databases ............................................ 5-3 5.2.6 Accuracy of Beacon Identification (15 / 23 Hex ID) ............................... 5-3 5.3 Cospas-Sarsat International 406 MHz Beacon Registration Database (IBRD) (www.406registration.com) ...................................................... 5-3 5.3.1 IBRD Management Policy ....................................................................... 5-4 5.3.2 Updating Registration Information in IBRD ............................................ 5-5 6. 406 MHz BEACON TYPE APPROVAL ......................................................... 6-1 6.1 Objectives and Scope of Type Approval .............................................................. 6-1 6.2 Cospas-Sarsat Type Approval Testing ................................................................. 6-1 6.3 Cospas-Sarsat Type Approval Certificate ............................................................ 6-2 6.4 National Type Approval ....................................................................................... 6-2 7. GENERAL GUIDELINES TO ADMINISTRATIONS, MANUFACTURERS AND DISTRIBUTIONS ................................................ 7-1 7.1 Guidelines to Administrations .............................................................................. 7-1 7.2 Guidelines to Manufacturers and Distributors ..................................................... 7-2 LIST OF ANNEXES ANNEX A : EXAMPLES OF 406 MHz BEACON CODES .................................................. A-1 ANNEX B : MODIFIED-BAUDOT CODE ............................................................................ B-1 ANNEX C : BINARY CODED DECIMAL............................................................................ C-1 ANNEX D : GUIDELINES ON THE USE OF THE BEACON REGISTRATION CHECKSUM ..................................................................................................... D-1 LIST OF FIGURES

Figure 3.1: General Format of the 406 MHz Beacon Message ................................................... 3-2 Figure 3.2: Standard Preamble Coding ........................................................................................ 3-9 Figure 3.3: Example of Country Code ....................................................................................... 3-11 Figure 3.4: Short Message Non-Protected Data Field ............................................................... 3-13 Figure 3.5: Bit Assignment for the First Protected Data Field (PDF-1) of User Protocols ........... 3-17 Figure 3.6: Coding the Maritime User Protocol with MMSI ..................................................... 3-19 Figure 3.7: Coding the EPIRB Serial Identification .................................................................. 3-20 Figure 3.8: Coding the Maritime User Protocol with the Radio Call Sign ................................... 3-22 Figure 3.9: Coding the Radio Call Sign User Protocol ................................................................ 3-23 Figure 3.10: Coding ELTs with the Beacon Serial Number ........................................................ 3-24 Figure 3.11: Coding ELTs with the Aircraft Operator Designator and Serial Number ................ 3-25 Figure 3.12: Coding ELTs with the Aircraft 24-bit Address ..................................................... 3-26 Figure 3.13: Coding ELTs with the Aircraft Nationality and Registration Marking................. 3-27 Figure 3.14: Coding PLBs with the Serial User Protocol .......................................................... 3-28 Figure 3.15: Coding the Test User Protocol .............................................................................. 3-29 Figure 3.16: Coding the National User Protocol ......................................................................... 3-30 Figure 3.17: Outline of Location Protocols ............................................................................... 3-31 Figure 3.18: Coding the User-location Protocols’ Second Protected Data Field (PDF-2) ........ 3-33 Figure 3.19: Coding the Standard Location Protocol with MMSI............................................. 3-34 Figure 3.20: Coding a Ship Security Alert System (SSAS) Beacon .......................................... 3-35 Figure 3.21: Coding the Standard Location Protocol with the 24-bit Aircraft Address ............ 3-35 Figure 3.22: Coding the Standard Location Protocol with the Aircraft Operator Designator and Serial Number .................................................................................................... 3-36 Figure 3.23: Coding the ELT/EPIRB/PLB Serial Identification Data ....................................... 3-36 Figure 3.24: Coding the Position Data in the Standard Location Protocols .............................. 3-37 Figure 3.25: Coding the National Location Protocol ................................................................. 3-38 Figure 3.26: Coding the RLS Location Protocol ....................................................................... 3-41 Figure 3.27: Coding the Position Data in the RLS Location Protocols ..................................... 3-41 Figure 3.28: Coding the RLS Data in the RLS Location Protocols ........................................... 3-43 Figure 3.29: Coding the ELT(DT) Location Protocol with the 24-bit Aircraft Address ........... 3-44 Figure 3.30: Coding the ELT(DT) Location Protocol with the Aircraft Operator Designator and Serial Number .................................................................................................... 3-45 Figure 3.31: Coding the C/S Serial Identification Data in the ELT(DT) Location Protocol ..... 3-45 Figure 3.32: Coding the Position Data in the ELT(DT) Location Protocols ............................. 3-46 Figure 3.33: Coding the Supplementary Data in the ELT(DT) Location Protocols .................. 3-47 Figure 4-1: Burst general structure .............................................................................................. 4-2 Figure 4-2: Message content bits ................................................................................................. 4-3 LIST OF TABLES Table 3.1: List of Available Coding Options for User Protocols ........................................... 3-3 Table 3.2: List of Available Coding Options for the Location Protocols (1/4) ........................... 3-4 Table 3.3: Format Flag and Protocol Flag Combinations .......................................................... 3-11 Table 3.4: Maritime Emergency Codes ................................................................................. 3-14

Table 3.5: Non-Maritime Emergency Codes ............................................................................. 3-14 Table 3.6: Auxiliary Radio-locating Device Code .................................................................... 3-18 Table 3.7: Encoding of Position Data ........................................................................................ 3-32 Table 4.1: Transmission Schedule ............................................................................................... 4-4 Table 5.1: Example of Basic Information to be Recorded and .................................................... 5-6 Table 5.2: Example of Ship Categories for Database Description .............................................. 5-7 Table 5.3: Example of Ship Radio Installation Description ........................................................ 5-7 Table B.1: Modified-Baudot Code ............................................................................................. B-1 Table D.1: Translation of characters to ASCII Decimal Values ................................................ D-3 Table D.2: Standard Translation of 4 Bits Blocks to Hexadecimal Characters .......................... D-3 Table D.3: Example UIN Inputs and Resulting Checksums ....................................................... D-3

1-1

INTRODUCTION 1.1 Overview This document describes the various methods of coding 406 MHz distress beacons for maritime, aviation or personal applications and provides guidelines for setting up a 406 MHz beacon registration database. The procedure to be followed by manufacturers to obtain a Cospas-Sarsat type approval certificate is also described, together with recommendations for administrations regarding national type approval of 406 MHz beacons. 1.2 Scope The purpose of this document is to inform administrations, Cospas-Sarsat equipment manufacturers and users on practical matters concerning the coding, registration and type approval of 406 MHz beacons. It is not intended to replace the current System documents which provide the specification for 406 MHz beacons, including all the technical details and options for applicable coding protocols (C/S T.001, T.015, and T.018), or the procedure for Cospas-Sarsat type approval testing (C/S T.007, and T.021*). Some background information on the Cospas-Sarsat 406 MHz System is given in section 2 of these guidelines. The basic information required for coding and registering 406 MHz beacons is presented in sections 3 and 4, and a guide for manufacturers requesting Cospas-Sarsat type approval testing is provided in section 5. General guidelines to administrations, manufacturers and distributors are included in section 6.

Second Generation Beacons have not yet been approved by the programme and therefore it is not currently possible to get a Cospas-Sarsat approval for a C/S T.018 beacon in accordance with C/S T.021.

1-2

1.3 Reference Documents The following documents contain more detailed information on 406 MHz beacons and should be used for reference, as necessary, on specific matters not fully covered by these guidelines: C/S T.001, Specification for Cospas-Sarsat 406 MHz Distress Beacons; C/S T.007, Cospas-Sarsat 406 MHz Distress Beacon Type Approval Standard; C/S T.015, Cospas-Sarsat Specification and Type Approval Standard for 406 MHz Ship Security Alert (SSAS) Beacons; C/S T.018, Specification for Second-Generation Cospas-Sarsat 406-MHz Distress Beacons; C/S T.021, Cospas-Sarsat Second Generation 406-MHz Distress Beacon Type Approval Standard; C/S D.004, Operations Plan for the Cospas-Sarsat International 406 MHz Beacon Registration Database; C/S G.003, Introduction to the Cospas-Sarsat System; C/S S.011, Cospas-Sarsat Glossary; and C/S S.007, Handbook of Beacon Regulations*. These documents may be obtained from the Cospas-Sarsat Secretariat or downloaded from the Cospas-Sarsat web site: www.cospas-sarsat.int (except item (h)). 1.4 Summary of the Cospas-Sarsat Guidelines on Beacon Coding, Registration and Type Approval National authorities are responsible for all regulatory matters concerning the use of 406 MHz beacons. This includes: issuing equipment specifications and carriage requirements; testing and type approving beacon models in accordance with Cospas-Sarsat, IMO, ICAO, ITU and/or their own national performance requirements; defining which coding protocols (see section 3) are applicable; allocating identification codes (see sections 3.3 and 3.4) as appropriate; and defining and implementing registration procedures (see section 4). When developing national regulations, Administrations are invited to consider the guidelines provided herein and other information available from the Cospas-Sarsat Secretariat, concerning type approved beacons, applicable coding protocols and registration procedures recommended by the relevant international organizations.

Note: Document updated semi-annually.

1-3

The Cospas-Sarsat Secretariat maintains a list of points of contact of a number of administrations responsible for 406 MHz beacon matters*. All countries adopting the use of 406 MHz beacons should inform the Cospas-Sarsat Secretariat of their point(s) of contact for 406 MHz beacon matters, for inclusion in this list. In summary, Administrations are invited to: establish appropriate regulations for the use of 406 MHz beacons in their country; test First Generation Beacons (FGBs) for type approval according to the Cospas- Sarsat specification and type approval standard (C/S T.001 and C/S T.007), or authorise the use of only those 406 MHz beacons which have received a Cospas- Sarsat type approval certificate, as published on the Cospas-Sarsat website at: www.cospas-sarsat.int; test Second Generation Beacons (SGBs) for type approval according to the Cospas-Sarsat specification and type approval standard (C/S T.018 and C/S T.021), or authorise the use of only those 406 MHz beacons which have received a Cospas-Sarsat type approval certificate, as published on the Cospas-Sarsat website at www.cospas-sarsat.int; perform additional tests, as appropriate, to ensure that the beacons comply with their specific requirements for the corresponding application, and/or consider whether the same beacon model has already been tested and approved by other administrations for that application; select the beacon coding protocols they wish to use in their country; establish and maintain a beacon register or co-ordinate with other administrations for the establishment and maintenance of a "regional" registration database; and provide the Cospas-Sarsat Secretariat with the address(es) of their point(s) of contact for 406 MHz beacon matters (i.e. type approval, coding and registration).

END OF SECTION 1 -

Note: See “Handbook of Beacon Regulations”, C/S S.007 (Should refer to the C/S website for the POC).

2-1

BACKGROUND INFORMATION ON THE 406 MHz SYSTEM 2.1 406 MHz Beacons The use of the 406 MHz system shall be in accordance with the appropriate provisions of the ITU Radio Regulations, and the alerting signals shall be in accordance with relevant ITU-R Recommendations. 406 MHz distress beacons are normally designed and constructed either as Emergency Position- Indicating Radio Beacons (EPIRBs) for maritime applications, as Emergency Locator Transmitters (ELTs) for aviation applications, or as Personal Locator Beacons (PLBs) for personal use. 406 MHz distress beacons (C/S T.001 or C/S T.015) transmit a half-second burst of data every 50 seconds with the exception of ELT(DT)s which transmit of a variable schedule. All SGB 406-MHz distress beacons (C/S T.018) transmit, on a variable schedule, a one-second burst of data. The Cospas-Sarsat satellites relay this data, referred to as the beacon message, to Cospas-Sarsat earth receiving stations called Local User Terminals (LUTs) which automatically examine the beacon message and determine the geographical location of the distress beacon. To ensure that the System performance requirements are met and to maintain the quality of alert and location data forwarded to search and rescue (SAR) services, it is essential that only beacons which satisfy Cospas-Sarsat specification and type approval requirements are used in the System. The list of Cospas-Sarsat type approved beacons is published on the Cospas-Sarsat website at: www.cospas-sarsat.int. 2.2 Beacon Identification Each message transmitted by a 406 MHz beacon must uniquely identify the beacon. The complete beacon identification code includes the: protocol flag, protocol code, country code, and other identification data, all of which are encoded in the first protected data field (PDF-1) of the 406 MHz message (see section 3.2.3). Identification data can be provided in various alphanumeric formats, depending on the coding protocol required by the responsible administration (see section 3). It is encoded together with the country code and other information in the beacon message in binary format. However, for the purpose of transmission to SAR services in the alert message produced by Cospas-Sarsat, the unique identification of a 406 MHz beacon encoded in bits 26-85 of the beacon message is provided as a 15 hexadecimal character string, referred to as the beacon 15 Hex Identification, or beacon 15 Hex ID (see also item 3.2.3.4).

2-2

The beacon 15 Hex ID is used: to correlate all the messages transmitted by a particular beacon; to provide SAR services with information on the ship, the aircraft or the beacon owner in case of beacon alert (see section 2.3); and to retrieve information from the beacon registration databases. A SGB (C/S T.018) beacon message also contains a unique Hex ID for the beacon. SGBs Hex IDs are provided as a 23 Hex Identification, as described in Table 3.10 of document C/S T.018. The generation of a 23 Hex ID makes use of an FGB spare protocol, thus ensuring that the truncation of a 23 Hex ID to form a SGB 15 Hex ID will result in a unique Hex Identification for all SGB messages and ensures that they can be distinguished from FGB messages. 2.3 Operational Use of Beacon Registration Databases It is crucial that 406 MHz distress beacons are registered in recognized beacon registration databases that are accessible to search and rescue (SAR) authorities 24 hours per day. The information contained in these databases concerning the beacon, its owner, and the vehicle/vessel on which the beacon is mounted is vital for the effective use of SAR resources. The unique information encoded in the Cospas-Sarsat 406 MHz beacon message provides the information necessary to identify the register that should hold the registration information for that beacon, and it is also the unique key used for retrieving the registration details. Both the International Maritime Organization (IMO) and the International Civil Aviation Organization (ICAO) require administrations authorising the use of 406 MHz beacons to make provisions for registering 406 MHz beacons that are under their jurisdiction. For beacon owners in countries that do not operate national registers, Cospas-Sarsat has implemented an International 406 MHz Beacon Registration Database (IBRD). A more detailed description of the registration process, requirements for 406 MHz beacon registers, and an introduction to the IBRD is provided at section 4. Details can be found in document C/S D.004 (Operations Plan for the Cospas-Sarsat International 406 MHz Beacon Registration Database). As mentioned above, because a beacon may be transmitting from anywhere on the globe, access to beacon registration databases must be provided to SAR services world-wide, 24 hours per day and with minimum delay. In order to achieve this objective, the following requirements should be met by all countries which authorise the use of 406 MHz distress beacons: all beacons should be coded in accordance with the Cospas-Sarsat specification (C/S T.001, C/S T.015 or C/S T.018) and national requirements, and include the country code assigned to the country of beacon registration (see section 3.2.3.2) and additional identification data, which together forms a unique beacon 15 Hex ID (see section 3.2.3.4);

2-3

all beacons should be registered with the appropriate administration, or in the International Beacon Registration Database (IBRD) if the administration has chosen to use the IBRD for beacons with their country code(s) (see section 4); appropriate points of contact should be designated, and identified to the Cospas-Sarsat Secretariat*, for providing guidance to beacon owners in respect of national registration and coding; and procedures should be defined for communicating beacon registration database information to SAR services upon request; details of the registry's point of contact should be provided to the Cospas-Sarsat Secretariat for the information of SPOCs and Cospas-Sarsat MCCs. The accuracy of information contained in the registration databases should also be checked periodically, possibly as part of any mandatory periodic beacon testing. 2.4 Encoded Position Data Beacon messages encoded with the location protocols include position data in addition to the beacon identification data. Such position data can be derived from a satellite navigation system, such as GPS, Galileo or GLONASS, using either a receiver integrated into the beacon, or an external navigation receiver connected to the beacon. The incorporation of the position data into the beacon message provides locating capability for 406 MHz alerts received through geostationary satellites in the 406 MHz GEOSAR system. The incorporation of the position data into the beacon messages also provides supplemental location data for the independent locations that are generated using the LEOSAR and MEOSAR system. This data also provides the primary location information for rapidly moving aviation distress tracking (ELT(DT)) beacons. More than 75% of the estimated global beacon population deployed include an encoded location capability, and the proportion of the beacon population which include this capability is expected to increase in the future.

END OF SECTION 2 -

For inclusion in the web list available on www.cospas-sarsat.int

3-1

FIRST GENERATION 406-MHz BEACON CODING (FGB) 3.1 C/S T.001 or C/S T.015 Beacon Types Cospas-Sarsat 406 MHz beacons can be used in different environments and for a variety of applications such as EPIRBs and Ship Security Alert System (SSAS) beacons that service the maritime environment, ELTs and ELT(DT)s (aviation) or PLBs (personal use). The specification of the distress signal characteristics (document C/S T.001), which ensures that all 406 MHz beacons are compatible with the Cospas-Sarsat Space Segment, is applicable to all types of beacons. However, different user groups have different needs; hence the need for various coding protocols. To satisfy these requirements, the Cospas-Sarsat specification provides for various coding options which are divided in two groups of coding protocols: User Protocols, described in section 3.3; and Location Protocols, described in section 3.4. The user protocols can be used for encoding the beacon identification and other data in the digital message transmitted by a 406 MHz distress beacon, but do not allow for encoding beacon position data. The coding options for user protocols are listed in Table 3.1 and further described in section 3.3. The location protocols can be used for encoding beacon position data, in addition to the beacon identification data, in the digital message transmitted by a 406 MHz distress beacon. The coding options for location protocols are listed in Table 3.2 and further described in section 3.4. User protocols are implemented using the short message format whereas location protocols are implemented using the long message format, as described in Figure 3.1. All protocols have the general structure of the 406 MHz digital message described in section 3.2 of this document. The choice of the protocol option to be used in a particular beacon type depends on: the user category (maritime, aviation, or personal); the method used to provide beacon identification data as required by the responsible administration; and the required resolution of encoded position data (only for location protocols). Administrations will normally specify which coding protocols can be used for the applications that they authorise. Manufacturers of 406 MHz beacons should contact the appropriate national authorities to determine how beacons should be coded for each country. The document C/S S.007 “Handbook of Beacon Regulations”, which is semi-annually updated by the Cospas-Sarsat Secretariat, provides a list of points of contact (including addresses and telephone numbers) for beacon matters in a number of countries.

3-2

Administrations should not authorise coding options which are not currently allocated or permitted by the Cospas-Sarsat specification for 406 MHz beacons (C/S T.001). Figure 3.1: General Format of the 406 MHz Beacon Message 3.1.a: Fields of the Short Message Format Bit Synchronization Frame Synchronization First Protected Data Field (PDF-1) BCH-1 Non-Protected Data Field Unmodulated Carrier (160 ms) Bit Synchronization Pattern Frame Synchronization Pattern Format Flag Protocol Flag Country Code Identification Data 21-Bit BCH code Emergency Code/ National Use or Supplement. Data Bit No. 1-15 16-24

27-36 37-85 86-106 107-112 15 bits 9 bits 1 bit 1 bit 10 bits 49 bits 21 bits 6 bits 3.1.b: Fields of the Long Message Format Bit Synchronization Frame Synchronization First Protected Data Field (PDF-1) BCH-1 Second Protected Data Field (PDF-2) BCH-2 Unmodulated Carrier (160 ms) Bit Synchronization Pattern Frame Synchronization Pattern Format Flag Protocol Flag Country Code Identification or Identification plus Position 21-Bit BCH code Supplementary and Position or National Use Data 12-Bit BCH code Bit No. 1-15 16-24

27-36 37-85 86-106 107-132 133-144 15 bits 9 bits 1 bit 1 bit 10 bits 49 bits 21 bits 26 bits 12 bits In addition to the available coding options listed in Table 3.1 and Table 3.2, a "national" user protocol and a specific "orbitography" protocol have been defined. The national user protocol allows for coding data which is defined and controlled by national administrations. It is described further in section 3.3.6. The orbitography protocol is not described in this document as its use is restricted to a small number of orbitography beacons under the control of Cospas-Sarsat System operators.

3-3

Table 3.1: List of Available Coding Options for User Protocols Application Identification Data Protocols Figure No. EPIRBs (Maritime) MMSI Maritime User Fig. 3.6 Unique EPIRB Serial Number* Serial User Fig. 3.7 Radio Call Sign a. Maritime User b. Radio Call Sign Fig. 3.8 Fig. 3.9 ELTs (Aviation) Unique ELT Serial Number* Serial User Fig. 3.10 Aircraft Operator Designator & Serial Number* Serial User Fig. 3.11 Aircraft 24-bit Address Serial User Fig. 3.12 Aircraft Registration Marking Aviation User Fig. 3.13 PLBs (Personal) Unique PLB Serial Number* Serial User Fig. 3.14 Test† Any Unique Combination All Fig. 3.15

Serial number means a unique number assigned by an administration or a beacon manufacturer. Administrations must ensure that the assigned serial numbers provide a unique beacon identification when used with the country code. Serial numbers assigned by a manufacturer must provide a unique beacon identification when used with the Cospas- Sarsat type approval certificate number assigned to that beacon model. † The test protocol is used in trials (to be co-ordinated with the appropriate MCC) which involve live transmissions to satellites. It is described further in section 3.3.5.

3-4

Table 3.2: List of Available Coding Options for the Location Protocols (1/4) Application Identification Data Location Data Protocols Figure No. EPIRBs (Maritime) MMSI 4-minute resolution encoded in PDF-2 User-location Fig. 3.6 Fig. 3.18 position offset to a 4-second resolution encoded in PDF-2 in addition to a 15-minute resolution encoded in PDF-1 Standard Location Fig. 3.19 Fig. 3.24 Unique EPIRB Serial Number 4-minute resolution encoded in PDF-2 User-location Fig. 3.7 Fig. 3.18 position offset to a 4-second resolution encoded in PDF-2 in addition to a 15 minute resolution encoded in PDF-1 Standard Location Fig. 3.23 Fig. 3.24 position offset to a 4-second resolution encoded in PDF-2 in addition to a 30-minute resolution encoded in PDF-1 RLS Location Fig. 3.26 Fig. 3.27 Fig. 3.28 Radio Call Sign 4-minute resolution encoded in PDF-2 User-location Fig. 3.8 Fig. 3.9 Fig. 3.18 Serial Number* Assigned by Administration position offset to a 4-second resolution encoded in PDF-2 in addition to a 2-minute resolution encoded in PDF-1 National Location Fig. 3.25 SSAS (Maritime) MMSI position to a 15-minute resolution encoded in PDF-1 and offset to a 4-second resolution encoded in PDF-2 Standard Location Fig. 3.20

Serial number means a unique number assigned by an administration or a beacon manufacturer. Administrations must ensure that the assigned serial numbers provide a unique beacon identification when used with the country code. Serial numbers assigned by a manufacturer must provide a unique beacon identification when used with the Cospas- Sarsat type approval certificate number assigned to that beacon model.

3-5

Table 3.2: List of Available Coding Options for the Location Protocols (2/4) Application Identification Data Location Data Protocols Figure No. ELTs (Aviation) Unique ELT Serial Number* 4-minute resolution encoded in PDF-2 User-location Fig. 3.10 Fig. 3.18 position offset to a 4-second resolution encoded in PDF-2 in addition to a 15-minute resolution encoded in PDF-1 Standard Location Fig. 3.23 Fig. 3.24 position offset to a 4 second resolution encoded in PDF-2 in addition to a 30 minute resolution encoded in PDF-1 RLS Location Fig. 3.26 Fig. 3.27 Fig. 3.28 Aircraft Operator Designator & Serial Number* 4 minute resolution encoded in PDF-2 User-location Fig. 3.11 Fig. 3.18 position offset to a 4-second resolution encoded in PDF-2 in addition to a 15-minute resolution encoded in PDF-1 Standard Location Fig. 3.22 Fig. 3.24 Aircraft 24-bit Address 4 minute resolution encoded in PDF-2 User-location Fig. 3.12 Fig. 3.18 position offset to a 4-second resolution encoded in PDF-2 in addition to a 15-minute resolution encoded in PDF-1 Standard Location Fig. 3.21 Fig. 3.24 Aircraft Registration Marking 4 minute resolution encoded in PDF-2 User-location Fig. 3.13 Fig. 3.18 Serial Number* Assigned by Administration position offset to a 4-second resolution encoded in PDF-2 in addition to a 2-minute resolution encoded in PDF-1 National Location Fig. 3.25

Serial number means a unique number assigned by an administration or a beacon manufacturer. Administrations must ensure that the assigned serial numbers provide a unique beacon identification when used with the country code. Serial numbers assigned by a manufacturer must provide a unique beacon identification when used with the Cospas- Sarsat type approval certificate number assigned to that beacon model.

3-6

Table 3.2: List of Available Coding Options for the Location Protocols (3/4) Application Identification Data Location Data Protocols Figure No PLBs (Personal) Unique PLB Serial Number* 4-minute resolution encoded in PDF-2 User-location Fig. 3.14 Fig. 3.18 position offset to a 4-second resolution encoded in PDF-2 in addition to a 15-minute resolution encoded in PDF-1 Standard Location Fig. 3.23 Fig. 3.24 position offset to a 4-second resolution encoded in PDF-2 in addition to a 30-minute resolution encoded in PDF-1 RLS Location Fig. 3.26 Fig. 3.27 Fig. 3.28 Serial Number* Assigned by Administration position offset to a 4-second resolution encoded in PDF-2 in addition to a 2-minute resolution encoded in PDF-1 National Location Fig. 3.25 RLS Test Test position offset to a 4-second resolution encoded in PDF-2 in addition to a 30-minute resolution encoded in PDF-1 RLS Location Fig. 3.26 Fig. 3.27 Fig. 3.28 Test† Any Unique Combination All ELT(DT) Test Test position offset to a 4-second resolution encoded in PDF-2 in addition to a 30-minute resolution encoded in PDF-1 ELT(DT) Location Fig. 3.29 to Fig. 3.31 Fig. 3.32 Fig. 3.33

Serial number means a unique number assigned by an administration or a beacon manufacturer. Administrations must ensure that the assigned serial numbers provide a unique beacon identification when used with the country code. Serial numbers assigned by a manufacturer must provide a unique beacon identification when used with the Cospas- Sarsat type approval certificate number assigned to that beacon model. † The test protocol is used in trials (to be co-ordinated with the appropriate MCC) which involve live transmissions to satellites. It is described further in section 3.3.5.

3-7

Table 3.2: List of Available Coding Options for the Location Protocols (4/4) Application Identification Data Location Data Protocols Figure No ELT (Distress Tracking (DT)) Aircraft 24-bit Address position offset to a 4-second resolution encoded in PDF-2 in addition to a 30-minute resolution encoded in PDF-1 ELT(DT) Location Fig. 3.29 Fig. 3.32 Fig. 3.33 Aircraft Operator Designator & Serial Number position offset to a 4-second resolution encoded in PDF-2 in addition to a 30-minute resolution encoded in PDF-1 ELT(DT) Location Fig. 3.30 Fig. 3.32 Fig. 3.33 Unique ELT Serial Number* position offset to a 4-second resolution encoded in PDF-2 in addition to a 30-minute resolution encoded in PDF-1 ELT(DT) Location Fig. 3.31 Fig. 3.32 Fig. 3.33

Serial number means a unique number assigned by an administration or a beacon manufacturer. Administrations must ensure that the assigned serial numbers provide a unique beacon identification when used with the country code. Serial numbers assigned by a manufacturer must provide a unique beacon identification when used with the Cospas- Sarsat type approval certificate number assigned to that beacon model.

3-8

3.2 General Coding Requirements 3.2.5 General Format and Field Definition of the 406 MHz Beacon Message The message transmitted by a Cospas-Sarsat 406 MHz beacon can be encoded either in a short message format or a long message format, as shown in Figure 3.1. 3.2.5.1 The short message format consists of: unmodulated carrier signal (160 ms), bit synchronization pattern (bits 1 to 15) and frame synchronization pattern (bits 16 to 24), often referred to as the preamble; the first protected data field (PDF-1) which includes the format and protocol flags, the country code, and beacon identification data (bits 25 to 85); the first BCH error correcting field (BCH-1) associated with the PDF-1 (encoded in bits 86 to 106); and the non-protected data field (variable / optional or supplementary data contained in bits 107 to 112). 3.2.5.2 The long message format consists of: the preamble; the first protected data field (PDF-1); the first BCH error correcting field (BCH-1); the second protected data field (PDF-2) which includes supplementary and position data of the location protocols, or information defined in national requirements (encoded in bits 107 - 132); and the second BCH error correcting field BCH-2 associated with the PDF-2 (encoded in bits 133 to 144). The 82 bits of the combined PDF-1 and BCH-1 are also referred to as the first protected field. The 38 bits of the combined PDF-2 and BCH-2 are also referred to as the second protected field.

3-9

3.2.2 Preamble 3.2.2.1 Standard Preamble The preamble of the 406 MHz digital message allows the receiver-processor to: detect the incoming signal and lock on its frequency, using the unmodulated carrier transmission; lock on the phase and bit timing of the modulation using the bit synchronization pattern; and identify the first data bit of the message using the frame synchronization pattern. Therefore, this preamble must be fixed and identical for all Cospas-Sarsat 406 MHz beacons, and encoded according to the format of Figure 3.2. Figure 3.2: Standard Preamble Coding 3.2.2.2 Self-Test Mode Preamble A 406 MHz beacon should be designed to perform a short self-test. The self-test transmission may consist of a short duration emission of a single burst. If the beacon transmits in the self-test mode, the signal must have a frame synchronization pattern of 011010000 to ensure that the satellite or ground equipment will not process this test transmission. This eliminates the risk of a false alert being generated by the self-test burst. Unless prior co-ordination has been accomplished in accordance with Cospas-Sarsat document C/S A.004 “Cospas-Sarsat System Exercising”, no other test transmissions are permitted when using a beacon coded with an "operational" protocol (see the "test" protocol coding in sections 3.3.5 and 3.4.7), as any such test could generate a false alert. In addition, self-test transmissions must be kept to a minimum as they interfere with "real" 406 MHz distress alerts. In the self-test transmission mode the complete test transmission must be limited to one burst only of a maximum duration of 440 ms (+1%) for a short message or 520 ms (+1%) for a long message. If a 440 ms transmission is used for a beacon encoded with the long format message, the message should be truncated without changing the format flag bit.

The self-test mode described in section 3.2.2.2 should not be confused with the "test" protocols described in sections 3.3.5 and 3.4.5 which are processed by Cospas-Sarsat satellites. 160 ms Bits 1-15 Bits 16-24 Unmodulated Carrier Bit Synchronization Pattern Frame Synchronization Pattern

unmodulated carrier: 160 ms;
bits 1 to 15: all set to "1";
bits 16 to 24: set to the pattern "000101111" (except in self-test mode *).

3-10

For location protocols, the default bits should replace the position data in encoded position data fields of the self-test mode messages. Therefore, the content of the self-test message shall always provide the beacon 15 Hex ID. 3.2.3 First Protected Data Field (PDF-1) 3.2.3.1 General Structure of the First Protected Data Field (PDF-1) The first protected data field (PDF-1) (bits 25 to 85) includes (see Figure 3.1): the format flag (bit 25) which indicates the use of the short message or long message formats as described in Table 3.3; the protocol flag (bit 26) which is set to "1" for all user protocols and user- location protocols, and to “0” for all other location protocols (i.e. standard location protocols and national location protocol); the country code which is a three-digit decimal number (see section 3.2.3.2) encoded in bits 27 to 36 in binary notation; identification data: a number of bits (different for each protocol, depending on the method used to encode the beacon 15 Hex ID: see Figures 3.5 and 3.17) which must remain fixed as this information will: • provide, with the preceding flags and country code, a unique identification of each beacon transmission and of the corresponding Doppler measurements used by LUTs to compute the beacon location, • permit a fast and reliable identification of the vehicle / user in distress, in order to obtain all information required to assist search and rescue operations, • permit a fast identification of the transmitter in case of false alert, allowing its cancellation at minimum cost to SAR services; and position data: a number of bits (different for each protocol, depending on the method used to encode the beacon 15 Hex ID: see Figure 3.17) which will be used in standard location protocols, national location protocols, RLS location protocols, and ELT(DT) location protocols to encode beacon position data. In the case of user and user-location protocols, the PDF-1 may also include information which is specific to an application or a beacon type (e.g. information on auxiliary radio- locating devices available in that beacon). 3.2.3.2 Format Flag, Protocol Flag and Country Code The bit allocations for the format flag, protocol flag and country code are identical in all beacon protocols. The possible combinations of format flag and protocol flag values are summarised in Table 3.3.

3-11

Table 3.3: Format Flag and Protocol Flag Combinations Format Flag (bit 25) → Protocol Flag (bit 26) 

(short)

(long)

(protocol code: bits 37-40) No longer allowed Standard Location Protocols National Location Protocol RLS Location Protocol ELT(DT) Location Protocol

(protocol code: bits 37-39) User Protocols User-Location Protocols National and Test User Protocols The country code is part of every beacon identification data. This code is the 3-digit decimal number allocated to each country/territory by the International Telecommunication Union (ITU) and listed as Maritime Identification Digits (MID) in Appendix 43 of the ITU Radio Regulations. The up-to-date list of MIDs is available from the ITU web site at: http://www.itu.int/en/ITU-R/terrestrial/fmd/Pages/mid.aspx The country code is encoded in binary notation in bits 27 to 36 of the message, with the least significant bit on the right. The country code indicates the administration maintaining the beacon registration data base (see section 4). If the appropriate registration database exists, the country code should always match the flag of the vessel or aircraft. The example presented in Figure 3.3 shows the country code for the United Kingdom, where: MID=232 (i.e., decimal number "232" coded "0011101000" in binary notation). Figure 3.3: Example of Country Code Bits

3-12

3.2.3.3 Identification Data and Position Data The unique Beacon Identification consists of the protocol flag, country code and the fixed (non-variable) bits of identification data specific for each protocol. In some location protocols, PDF-1 also includes variable bits which provide for the encoding of beacon position (see Figure 3.17). Therefore, the interpretation of data contained in the PDF-1 requires determining which protocol is being used, as indicated by the setting of the protocol flag (bit 26) and the protocol code (bits 37 to 40 for standard, national, RLS, and ELT(DT) location protocols (long format), and bits 37 to 39 for all user protocols, including user-location protocols). The bit settings for the protocol code and the bit assignments for identification data and position data are described in sections 3.3 and 3.4. Some user protocols (i.e. the serial user protocol and the national user protocol) have, as part of the identification data, data fields that may be defined by administrations to fulfil specific identification requirements. Administrations should inform the Cospas-Sarsat Secretariat of their national identification coding schemes to ensure that these schemes remain compatible with the general Cospas-Sarsat coding requirements. 3.2.3.4 Fifteen Hexadecimal Character Beacon Identification The fifteen hexadecimal character representation of PDF-1 excluding bit 25 (message format flag) is used for the purpose of distribution of distress alerts over Cospas-Sarsat ground communication network. It is referred to as the beacon 15 Hex ID. The beacon 15 Hex ID must uniquely identify each 406 MHz beacon. The beacon 15 Hex ID is derived from a 406 MHz message by presenting every 4 bits of a beacon message, starting from bit 26 to bit 85, as a hexadecimal character: “0000” = Hex 0 up to “1111” = Hex F. The beacon 15 Hex ID is, therefore, represented as a string of fifteen characters, for example: ADCD0228C500401 for the bit sequence: 1010 1101 1100 1101 0000 0010 0010 1000 1100 0101 0000 0000 0100 0000 0001. In the case of location protocol, bits 26 to 85 include variable position data. The position data in PDF-1 must be set to specified default values to create the fixed unique 15 Hex ID of the beacon. In the case of the SGBs, the 15 Hex ID is a truncated form of the full 23 Hex ID as defined in Table 3.9 of document C/S T.019. A specific FGB user-location-protocol code “101”, equivalent to Bits 37-39, which has been assigned to ensure that the 23 Hex ID for SGBs will always truncate to a unique 15 Hex ID with the first bit always set to a value of “1”.

3-13

3.2.4 21-bit First BCH Error Correcting Field (BCH-1) The 61 bits forming the first protected data field (PDF-1, bits 25 to 85) are followed by a 21- bit Bose-Chaudhuri-Hocquenhem (BCH) error-correcting code (bits 86 to 106), in a field defined as the first BCH error correcting field (BCH-1). This code can detect and correct up to three bit errors in the 82 bits of the first protected field (PDF-1 and BCH-1). The error- correcting code is generated from the content of PDF-1 as described in Annex A of C/S T.001. Therefore, it must be computed and encoded together with the PDF-1. When updates to the PDF-1 are required for encoding position data, the error-correcting code must be regenerated after each update. 3.2.5 Non-Protected Data Field of the Short Message Format The data field (bits 107 to 112) following the BCH-1 in the short message format is not error protected. It can be used to transmit supplementary data indicating the distress situation (emergency code) or specific features of the beacon (radio-locating device). The bits of the non-protected data field have different assignments in the user protocols group or the location protocols group, which are described in Figure 3.4. Figure 3.4: Short Message Non-Protected Data Field Figure 3.4.a: Emergency Code/National Use Data (*) for Short Format User Protocols Bits

Content Emergency Code Flag Activation Code Emergency Code or National Use Data

bit 107: flag bit set to "1" means that bits 109 to 112 contain one of the agreed emergency codes (Table 3.4 and Table 3.5); flag bit set to "0" means that bits 109 to 112 contain data defined by the administration designated in the country code; default coding for bit 107 is "0";
bit 108: the activation code is set to "1" if beacon is designed for both automatic and manual activation; it is set to "0" if beacon can be activated manually only;
bits 109 to 112: encoded with one of the agreed emergency codes (Table 3.4 and Table 3.5) or with data defined according to national requirements; default coding for bits 109 to 112 is "0000".

For national user protocols, the content of bits 107 to 112 of the non-protected field may be reassigned and controlled by national administrations (see section 3.3.6).

3-14

Table 3.4: Maritime Emergency Codes* IMO Indication(†) Binary Code Usage

1001 to 1111 Fire/explosion Flooding Collision Grounding Listing, in danger of capsizing Sinking Disabled and adrift Unspecified distress‡ Abandoning ship Spare (could be used in future as necessary) Table 3.5: Non-Maritime Emergency Codes Bits Usage §

No fire (=0); fire (=1) No medical help (=0); medical help required (=1) Not disabled (=0); disabled (=1) Spare (=0) 3.2.6 Second Protected Data Field (PDF-2) The twenty-six bits (bits 107 to 132) following the BCH-1 in the long message format form the second protected data field (PDF-2). The PDF-2 is available only in the long message format.

The maritime emergency codes are in accordance with the list of IMO Nature of Distress Indications, except for code "1111" which, for 406 MHz beacons, is defined as "spare" instead of "test" code in the IMO list (see also the test protocol in section 3.3.5). † IMO indication is an emergency code number, it is different from the binary encoded number. ‡ If no emergency code data has been entered, bit 107 remains set to (=0). § If no emergency code data has been entered, bit 107 remains set to (=0).

3-15

The second protected data field (PDF-2) is used for encoding supplementary data and position data as defined for the various location protocols described in section 3.4. However, administrations can also define their own bit assignments for this field to satisfy specific national requirements, as provided for in the national user protocol (see section 3.3.6). 3.2.7 Second BCH Error Correcting Field (BCH-2) The twenty-six bits forming the PDF-2 (bits 107 to 132) of the beacon message are followed by a 12-bit BCH error-correcting code (bits 133 to 144) in a field defined as the second BCH error correcting field (BCH-2), which can detect and correct up to 2 bit errors in the 38 bits of the second protected field (PDF-2 plus BCH-2). The error-correcting code is generated from the content of PDF-2 as described in Annex A of C/S T.001. Therefore, it must be computed and encoded together with the PDF-2. When updates to the PDF-2 are required, the error-correcting code must be regenerated after each update. The 12-bit BCH error-correcting code must be computed and encoded in the second BCH error correcting field (BCH-2) of all protocols using the long message format (with the exception of orbitography protocol which is intended for use only by the Cospas-Sarsat System operators).

3-16

3.3 Coding User Protocols This section defines the user protocol message formats which can be used to encode the beacon identification data and other data in the message transmitted by a 406 MHz distress beacon. 3.3.1 General Requirements for User Protocols There are 6 different options for coding user protocols, which are described in Figure 3.5. The applicable user protocol type is selected by setting bits 37 to 39 according to the appropriate pattern. Most of the user protocols are available only in the short message format, selected by setting bit 25 (format flag) to “0”. The coding of the user protocols is described with further details in section 3.3.2 to 3.3.6. The national user protocol and the test user protocol can be coded either with the short or the long message format, as indicated by the format flag: “0” (short message), or “1” (long message). The national user protocol which can be used to meet specific national requirements must be defined in accordance with section 3.3.6. The user-location protocol, described in section 3.4 as part of the location protocol group, uses the long message format, but has the same definition as the user protocols for the first protected data field (PDF-1).

3-17

Figure 3.5: Bit Assignment for the First Protected Data Field (PDF-1) of User Protocols

MARITIME USER PROTOCOL Bits 25 26 27 36 37 39 40 81 82

.....

Country Code

MMSI or Radio Call Sign (42 bits)

R L 2. RADIO CALL SIGN USER PROTOCOL Bits 25 26 27 36 37 39 40 81 82

.....

Country Code

Radio Call Sign (42 bits)

R L 3. SERIAL USER PROTOCOL Bits 25 26 27 36 37 39 40 42 43

73 74

.....

Country Code

T T T C Serial Number and other Data C/S Cert. No or National Use R L 4. AVIATION USER PROTOCOL Bits 25 26 27 36 37 39 40 81 82

.....

Country Code

Aircraft Registration Marking (42 bits) E N R L 5. NATIONAL USER PROTOCOL Bits 25 26 27 36 37 39 40

...... F

Country Code

National Use (46 bits) 6. TEST USER PROTOCOL Bits 25 26 27 36 37 39 40

..... F

Country Code

Test Beacon Data (46 bits) 7. ORBITOGRAPHY PROTOCOL Bits 25 26 27 36 37 39 40

...... F

Country Code

Orbitography Data (46 bits) 8. SGB PROTOCOL (Reserved for SGB – but not transmitted) Bits 25 26 27 36 37 39 40

...... …

Country Code

As Defined in C/S T.018 (46 bits) Notes: RL

Auxiliary radio-locating device (see Table 3.6) TTT = 000 - ELT with serial number 010 - float free EPIRB with serial number 011 - ELT with 24-bit aircraft address 100 - non float free EPIRB with serial number 001 - ELT with aircraft operator 110 - personal locator beacon (PLB) with serial number designator and serial number C

C/S Type Approval Certificate Flag: "1" C/S Type Approval Certificate number encoded in bits 74 to 83 "0" other national use F

Format Flag (“0” = short message, “1” = long message) EN* = Specific ELT number on designated aircraft (see Figure 3.13) Radio call sign of six or fewer alphanumeric characters can be encoded in Maritime User Protocol. Radio call sign of up to seven characters (four alphanumeric and three digits) can be encoded in Radio Call Sign User Protocol.

Effective as of 1 November 2011.

3-18

Table 3.6: Auxiliary Radio-locating Device Code

No Auxiliary Radio-locating Device
121.5 MHz Auxiliary Radio-locating Device
9 GHz SART Locating Device
Other Auxiliary Radio-locating Device(s) Note: If other auxiliary radio-locating device(s) is (are) used in addition to 121.5 MHz, the code for 121.5 MHz (i.e. 01) should be used. 3.3.2 Coding Maritime Protocols Resolution A.810(19) of the International Maritime Organization (IMO) 19th Assembly meeting states that: "A unique beacon identification code shall be made part of all messages. This identification code shall include a 3-digit code for the country in which the beacon is registered, followed by either: .1 the trailing 6 digits of the ship station identity in accordance with Appendix 43 of ITU Radio Regulations; or .2 a unique serial number; or .3 a radio call sign. Preference is given to method .1.” Note: For the purpose of this document the Maritime Mobile Service Identity (MMSI) and the Ship Station Identity are equivalent and are defined as a 9-digit number consisting of the MID (country code) followed by six digits. Coding of beacons with the identification codes recommended by IMO is detailed in the following sections: 3.3.2.1 Coding the Maritime User Protocol with MMSI; 3.3.2.2 Coding EPIRBs with a Unique Serial Number; and 3.3.2.3 Coding EPIRBs with the Radio Call Sign Identification.

3-19

3.3.2.1 Coding the Maritime User Protocol with MMSI* The maritime user protocol can be used to encode the Maritime Mobile Service Identity (MMSI) in EPIRBs as shown in Figure 3.6. Figure 3.6: Coding the Maritime User Protocol with MMSI Bits 25 26 27 ........ 36 37 .. 39 40 ..................... 75 76 ..... 81 82 83 84 85 0 1 Country Code 0 1 0 (36 bits) Trailing 6 digits of MMSI Beacon Number 0 0 R L

bit 25: format flag set to "0" (short message)
bit 26: protocol flag set to "1";
bits 27 to 36: country code = 3 digit, decimal number encoded in binary notation (see section 3.2.3.2);
bits 37 to 39: protocol code, set to "010" (maritime user protocol);
bits 40 to 75: contain the trailing 6 digits of MMSI number encoded using the modified-Baudot code (i.e. 6 bits per digit, see Table B.1 of Annex B);
bits 76 to 81: a consecutive decimal number for each beacon on that vessel, encoded using the modified-Baudot code (see Table B.1 of Annex B), where the first or only float free beacon is to be coded with a modified-Baudot zero: "001101"; additional beacons shall be numbered consecutively using modified-Baudot characters 1 to 9 and A to Z;
bits 82 and 83: spare, set to "00";
bits 84 and 85: (RL) set to "01" if a 121.5 MHz radio-locating transmitter is included in the beacon (see Table 3.6 to indicate other radio-locating devices). 3.3.2.2 Coding EPIRBs with a Unique Serial Number Protocol code bits 37 to 39 for this method of encoding identification data are set to "011" (i.e. the serial user protocol) to indicate that a beacon serial number is contained in the message as described in Figure 3.7, unless the beacon serial identity number is defined otherwise by the national regulation. Bits 40 to 42 are used to identify the beacon type, as the same serial protocol is used in several applications.

This coding method should be used only if the first 3 digits (MID) forming part of a unique 9-digit code of ship station identity correspond to the 3 digit country code encoded in bits 27 to 36.

3-20

Figure 3.7: Coding the EPIRB Serial Identification Bits 25 26 27 .... 36 37 .. 39 40 .. 42 43 44 ....... 63 64 .... 73 74 ....... 83 84 85 0 1 Country Code 0 1 1 T T T C (20 bits) Serial Number All ‘0’ or National Use C/S Cert. No or National Use R L

bit 25: format flag set to "0" (short message);
bit 26: protocol flag set to "1";
bits 27 to 36: country code = 3 digit decimal number encoded in binary notation (see section 3.2.3.2);
bits 37 to 39: protocol code set to "011" (serial user protocol);
bits 40 to 42: (TTT) beacon-type code set to "010" for EPIRBs which can be automatically released and activated, (float free type) or to "100" for EPIRBs which can be manually activated only (survival type);
bit 43: (C) set to "1" to indicate that the Cospas-Sarsat type approval certificate number is encoded in bits 74 to 83, or set to "0" otherwise *;
bits 44 to 63: sequential number, allocated by the manufacturer *, encoded in binary notation with the least significant bit on the right;
bits 64 to 73: all "0", unless designated otherwise by the responsible administration *;
bits 74 to 83: if bit 43 is set to "1", these bits contain the Cospas-Sarsat type approval certificate number for that beacon model (i.e. a unique number assigned by Cospas-Sarsat for each beacon model), encoded in binary notation with the least significant bit on the right; if bit 43 is set to "0", these bits are designated by the responsible administration *;
bits 84 and 85: (RL) set to "01" if a 121.5 MHz radio-locating transmitter is included in the beacon (see Table 3.6 to indicate other radio-locating devices). The serial identification coding format described in Figure 3.7, which uses the Cospas-Sarsat type approval certificate (TAC) number, is compatible with other existing serial formats defined by administrations (as notified to the Cospas-Sarsat Secretariat). The Cospas-Sarsat TAC number is a unique number assigned by the Cospas-Sarsat Secretariat to each beacon model which has been successfully tested in accordance with the Cospas-Sarsat Type Approval Standard (C/S T.007). The list of Cospas-Sarsat TAC numbers of type approved beacon models is published by the Cospas-Sarsat Secretariat in the document "Cospas-Sarsat System Data". Using the Cospas-Sarsat TAC number ensures that the serial production number assigned by a manufacturer provides a unique beacon 15 Hex ID, independent of the country of beacon registration encoded in the country code. If the Beacon 15 Hex ID is assigned by the national administration of the country designated by the country code, bit 43 can be set to “0” and the content of bits 44 to 83

Alternative means of allocating and controlling serial numbers on a national basis may be adopted by administrations, but they must be compatible with the serial user protocol defined in document C/S T.001, and provide a unique beacon 15 Hex ID.

3-21

reassigned as required. However, in that case, the national administration must ensure that the beacon 15 Hex ID is unique. 3.3.2.3 Coding EPIRBs with the Radio Call Sign Identification The radio call sign is an alphanumeric sequence (letters and digits) assigned to a particular vessel by the Flag State administration. This call sign can be encoded in bits 40 to 75 of the maritime user protocol or the radio call sign user protocol. The coding of these two protocols is detailed in the following paragraphs. 3.3.2.4 3.3.2.3.1 Coding the Maritime User Protocol with the Radio Call Sign Radio call signs consisting of six or fewer alphanumeric characters can be encoded using the maritime user protocol as shown in Figure 3.8. Although the same protocol is used for both MMSI and Radio Call Signs of 6 or fewer characters, the use of letters in Radio Call Signs ensures that the Radio Call Sign will not be confused with MMSI composed of only digits.

3-22

Figure 3.8: Coding the Maritime User Protocol with the Radio Call Sign Bits 25 26 27 ........ 36 37 .. 39 40 .................. 75 76 ..... 81 82 83 84 85 0 1 Country Code 0 1 0 (6 alphanumeric characters = 36 bits) Radio Call Sign Beacon Number 0 0 R L

bit 25: format flag set to "0" (short message);
bit 26: protocol flag set to "1";
bits 27 to 36: country code = 3 digit, decimal number encoded in binary notation (see section 3.2.3.2);
bits 37 to 39: protocol code, set to "010" (maritime user protocol);
bits 40 to 75: up to 6 alphanumeric characters encoded using the modified-Baudot code (see Table B.1 of Annex B); if the radio call sign has fewer than six characters, blank spaces should be encoded to the left of the characters using the modified-Baudot space symbol: "100100"; if the radio call sign has seven characters it can only be encoded with the Radio Call Sign User Protocol (see item 3.3.2.3.2);
bits 76 to 81: a consecutive serial number for each beacon on that vessel, encoded using the modified- Baudot code, where the first or only float free beacon is to be coded with a modified- Baudot zero "001101"; additional beacons shall be numbered consecutively using modified-Baudot characters 1 to 9 and A to Z;
bits 82 and 83: set to "00";
bits 84 and 85: (RL) set to "01" if a 121.5 MHz radio-locating transmitter is included in the beacon (see Table 3.6 to indicate other radio-locating devices). 3.3.2.5 3.3.2.3.2 Coding the Radio Call Sign User Protocol with the Radio Call Sign Radio call signs of up to seven characters can be encoded according to Figure 3.9 if they comply with the ITU Radio Regulations on the formation of call signs (Article 25 of the Radio Regulations) whereby alphabetic characters are allowed only in the first four characters of the sequence. These first four characters are coded with the modified-Baudot code in bits 40 to 63 (see Table B.1 of Annex B) and the final three digits are coded in binary-coded decimal form in bits 64 to 75. Characters coded with the modified-Baudot code can be either alphabetic or numeric; characters coded in binary-coded decimal (BCD) must be numeric. If the radio call sign protocol is used for a call sign of less than seven characters, the radio call sign should be left justified (i.e. data on the left) in the data field (bits 40 to

and padded to the right of the last character with BCD "space" characters (see Annex C) in the binary-coded decimal field (bits 64-75).

3-23

Figure 3.9: Coding the Radio Call Sign User Protocol Bits 25 26 2

........ 36

.. 39 4

............ 6

64 .. 75 7

..... 81 8

83 8

Country Code 1 1

(4 alphanumeric char. of Radio Call Sign) (3 last digits) Beacon Number 0 0 R L

bit 25: format flag set to "0" (short message);
bit 26: protocol flag set to "1";
bits 27 to 36: country code = 3 digit, decimal number encoded in binary notation (see section 3.2.3.2);
bits 37 to 39: protocol code, set to "110" (radio call sign user protocol);
bits 40 to 63: first 4 characters of the radio call sign (letters or digits) encoded using the modified- Baudot code (see Table B.1 of Annex B);
bits 64 to 75: last BCD characters (see Annex C) of the radio call sign (3 digits or less), and padded with "space" ("1010") to the right of the last digit, if less than 3 digits (see example hereunder);
bits 76 to 81: a consecutive number for each beacon on the same vessel, encoded using the modified- Baudot code, where the first or only float free beacon is to be coded with a modified- Baudot zero "001101"; additional beacons shall be numbered consecutively using modified-Baudot characters 1 to 9 and A to Z;
bits 82 and 83: set to "00";
bits 84 and 85: (RL) set to "01" if a 121.5 MHz radio-locating transmitter is included in the beacon (see Table 3.6 to indicate other radio-locating devices). Example of radio call sign coding: "ABC123" will be coded: " 111000 110011 101110 011101 0010 0011 1010 " A B C 1 2 3 ( ) 3.3.3 Coding Aviation Protocols The International Civil Aviation Organization (ICAO) has defined four coding methods which can be used to identify 406 MHz Emergency Locator Transmitters (ELTs) (Convention on International Civil Aviation, Annex 10, Appendix D to Part I - Emergency Locator Transmitter Coding). The identification codes recommended by ICAO are in accordance with the general structure of Cospas-Sarsat user protocols shown in Figure 3.5 and described in the following sections: 3.3.3.1 Coding ELTs with the Beacon Serial Number; 3.3.3.2 Coding ELTs with the Aircraft Operator Designator and a Serial Number; 3.3.3.3 Coding ELTs with the Aircraft 24-bit Address; and 3.3.3.4 Coding ELTs with the Aircraft Nationality and Registration Marking.

3-24

All aviation coding methods include a country code based on ITU Radio Regulation Appendix 43 (see section 3.3.1). ICAO also recommends that "each beacon shall be assigned a unique coding and shall be registered" with the appropriate authority (Convention on International Civil Aviation, Annex 10, Volume I, Part I, Chapter 5. Emergency Locator Transmitter (ELT) for Search and Rescue). 3.3.3.2 3.3.3.1 Coding ELTs with the Beacon Serial Number Protocol code bits 37 to 39 for this method of encoding identification data are set to "011" to designate the serial user protocol. Bits 40 to 42 are used to identify the beacon type and coding method (i.e. "000" to indicate an ELT serial number) since the same serial user protocol is used for several applications. If bit 43 is set to "1", the Cospas-Sarsat type approval certificate number is encoded in bits 74 to 83, as shown in Figure 3.10. This will help ensure that the serial identity of the beacon is unique (see also item 3.3.2.2). Figure 3.10: Coding ELTs with the Beacon Serial Number Bits 25 26 27 ..... 36 37 .. 39 40 .. 42 43 44 ........ 63 64 ..... 73 74 ........ 83 84 85 0 1 Country Code 0 1 1 0 0 0 C (20 bits) Serial Number All "0" or Nation. Use C/S Cert.No or National Use R L

bit 25: format flag set to "0" (short message);
bit 26: protocol flag set to "1";
bits 27 to 36: country code = 3 digit decimal number encoded in binary notation (see section 3.2.3.2);
bits 37 to 39: protocol code, set to "011" (serial user protocol);
bits 40 to 42: beacon type set to "000" for ELTs with serial identification;
bit 43: (C) set to "1" to indicate that the Cospas-Sarsat type approval certificate number is encoded in bits 74 to 83, set to "0" otherwise;
bits 44 to 63: sequential number, allocated by manufacturers*, encoded in binary notation with the least significant bit on the right;
bits 64 to 73: all "0", unless designated otherwise by the responsible administration*;
bits 74 to 83: if bit 43 is set to "1", these bits contain the Cospas-Sarsat type approval certificate number for that beacon model (i.e. a unique number assigned by Cospas-Sarsat for each beacon model), encoded in binary notation with the least significant bit on the right; if bit 43 is set to "0", these bits are designated by the responsible administration* ;
bits 84 and 85: (RL) set to "01" if a 121.5 MHz radio-locating transmitter is included in the beacon (see Table 3.6 to indicate other radio-locating devices).

Alternative means of allocating and controlling serial numbers on a national basis may be adopted by administrations, but they must be compatible with the serial user protocol defined in document C/S T.001, and provide a unique beacon 15 Hex ID.

3-25

3.3.3.3 Coding ELTs with the Aircraft Operator Designator and a Serial Number The 3-letter Aircraft Operator Designator (AOD), defined in ICAO DOC 8585, is a unique identification of Aircraft Operators. The AOD can be coded in the serial user protocol as shown in Figure 3.11. Figure 3.11: Coding ELTs with the Aircraft Operator Designator and Serial Number Bits 25 26 27 ..... 36 37 .. 39 40 .. 42 43 44 ........ 61 62 ..... 73 74 ........ 83 84 85 0 1 Country Code 0 1 1 0 0 1 C Operator 3-letter Designator Serial Number C/S Cert.No or National Use R L

bit 25: format flag set to "0" (short message);
bit 26: protocol flag set to "1";
bits 27 to 36: country code = 3 digit decimal number encoded in binary notation (see section 3.2.3.2);
bits 37 to 39: protocol code, set to "011" (serial protocol);
bits 40 to 42: beacon type set to "001" for ELTs identified with the 3-letter aircraft operator designator and a serial number;
bit 43: (C) set to "1" to indicate that the Cospas-Sarsat type approval certificate number is encoded in bits 74 to 83, set to "0" otherwise*;
bits 44 to 61: 3-letter aircraft operator designator, encoded using the Modified-Baudot code (see Table B.1 of Annex B);
bits 62 to 73: serial number, as designated by the operator, is encoded in binary notation with the least significant bit to the right (No. 0001 up to 4096);
bits 74 to 83: if bit 43 is set to "1", these bits contain the Cospas-Sarsat type approval certificate number for that beacon model (i.e. a unique number assigned by Cospas-Sarsat for each beacon model), encoded in binary notation with the least significant bit on the right; if bit 43 is set to "0", these bits are designated by the responsible administrations ;
bits 84 and 85: (RL) set to "01" if a 121.5 MHz radio-locating transmitter is included in the beacon (see Table 3.6 to indicate other radio-locating devices). 3.3.3.4 Coding ELTs with the Aircraft 24-bit Address The Aircraft 24-bit Address is a unique 24-bit binary code assigned to the aircraft by national administrations in accordance with Annex 10 to the Convention on International Aviation. The Aircraft 24-bit Address is coded in the serial user protocol as shown in Figure 3.12.

3-26

Figure 3.12: Coding ELTs with the Aircraft 24-bit Address Bits 25 26 27 ..... 36 37 .. 39 40 .. 42 43 44 ........ 67 68 ..... 73 74 ........ 83 84 85 0 1 Country Code 0 1 1 0 1 1 C 24-bit Aircraft Address Specific ELT number C/S Cert. No or National Use R L

bit 25: format flag set to "0" (short message);
bit 26: protocol flag set to "1";
bits 27 to 36: country code = 3 digit decimal number encoded in binary notation (see section 3.2.3.2);
bits 37 to 39: protocol code, set to "011"(serial protocol);
bits 40 to 42: beacon type set to "011" for ELTs identified with aircraft 24-bit address;
bit 43: (C) set to "1" to indicate that the Cospas-Sarsat type approval certificate number is encoded in bits 74 to 83, set to "0" otherwise;
bits 44 to 67: 24-bit aircraft address;
bits 68 to 73: 6 bit specific ELT number, in binary notation with the least significant bit on the right, if several ELTs are carried in the same aircraft and encoded with the same 24 bit address, or default to 0's when one ELT is carried, see Notes (1) and (2) below;
bits 74 to 83: if bit 43 is set to "1", these bits contain the Cospas-Sarsat type approval certificate number for that beacon model (i.e. a unique number assigned by Cospas-Sarsat for each beacon model), encoded in binary notation with the least significant bit on the right; if bit 43 is set to "0", these bits are designated by the responsible administrations;
bits 84 and 85: (RL) set to "01" if a 121.5 MHz radio-locating transmitter is included in the beacon (see Table 3.6 to indicate other radio-locating devices). Notes: (1) Before attempting to encode an ELT with the serial user protocol using the aircraft 24-bit address, to avoid repeating an existing 15 Hex ID, manufacturers / programming facilities should request the inquirer / user to provide appropriate information on the specific number to be encoded in bits 68 to 73. Cospas-Sarsat recommendation is to assign the first ELT the default value “000000” and then increment the binary number for subsequent ELT, (e.g., 2nd ELT = “000001”, 3rd ELT = “000010”, etc.) (2) Administrations should advise users to inform manufacturers / programming facilities on the number to be encoded in bits 68 to 73 each time they request the coding of an ELT with a specific aircraft 24-bit address to ensure that each coded beacons results in a unique Hex-ID.

3-27

3.3.3.5 Coding ELTs with the Aircraft Nationality and Registration Marking The aircraft nationality and registration marking is a unique alphanumeric number assigned by national administrations in accordance with Annex 10 to the Convention on International Civil Aviation. This is coded in the aviation user protocol as shown in Figure 3.13. Figure 3.13: Coding ELTs with the Aircraft Nationality and Registration Marking Bits 25 26 27 ...... 36 37 .. 39 40 .................................. 81 82 83 84

0 1 Country Code

0 1 Aircraft Registration Marking (42 bits = up to 7 alphanumeric charact.) ELT number R L

bit 25: format flag set to "0" (short message);
bit 26: protocol flag set to "1";
bits 27 to 36: country code = 3 digit decimal number encoded in binary notation (see section 3.2.3.2);
bits 37 to 39: protocol code, set to "001" (aviation user protocol);
bits 40 to 81: aircraft nationality and registration marking, containing up to 7 alphanumeric characters, is encoded using the modified-Baudot code (see Table B.1 of Annex B); if the aircraft nationality and registration marking include less than 7 characters, blank spaces should be encoded to the left of the characters using the modified-Baudot space symbol: "100100";
bits 82 and 83: Specific ELT number where “00” indicates the first ELT on the aircraft coded with this protocol and “01”, “10” and “11” identify additional ELTs on the same aircraft, all coded with the Aviation User protocol*;
bits 84 and 85: (RL) set to "01" if a 121.5 MHz radio-locating transmitter is included in the beacon (see Table 3.6 to indicate other radio-locating devices).

Effective as of 1 November 2011.

3-28

3.3.4 Coding PLBs with the Serial User Protocol The serial user protocol is used to code beacons that have been designed as Personal Locator Beacons (PLB). These PLBs are coded as shown in Figure 3.14 using the serial user protocol with protocol code bits (40 - 42) set to “110”. Figure 3.14: Coding PLBs with the Serial User Protocol Bits 25 26 27 ..... 36 37 .. 39 40 .. 42 43 44 ........ 63 64 ..... 73 74 ........ 83 84 85 0 1 Country Code 0 1 1 1 1 0 C (20 bits) Serial Number All "0" or Nation. Use C/S Cert.No or National Use R L

bit 25: format flag set to "0" (short message);
bit 26: protocol flag set to "1";
bits 27 - 36: country code = 3 digit decimal number encoded in binary notation (see section 3.2.3.2);
bits 37 - 39 protocol code set to "011" (serial user protocol);
bits 40 - 42: beacon-type code set to "110" (personal);
bit 43: (C) set to "1" to indicate that the Cospas-Sarsat type approval certificate number is encoded in bits 74 to 83, or set to "0" otherwise*;
bits 44 - 63: sequential number, allocated by the manufacturer *, encoded in binary notation with he least significant bit on the right;
bits 64 - 73: all "0", unless designated otherwise by the responsible administration *;
bits 74 - 83: if bit 43 is set to "1", contain the Cospas-Sarsat type approval certificate number for that beacon model (i.e., a unique number assigned by Cospas-Sarsat for each beacon model), encoded in binary notation with the least significant bit on the right; if bit 43 is set to "0", these bits are designated by the responsible administration *;
bits 84 - 85: (RL) set to "01" if a 121.5 MHz radio-locating transmitter in included in the beacon (see Table 3.6 to indicate other radio-locating devices). 3.3.5 Coding the Test User Protocol The test protocols are used when conducting any tests of beacons (e.g. demonstrations, type approval tests, training exercises, etc.) whenever the emitted signals might be detected by the satellites. The test user protocol can be formed from any of the other user protocols by setting

Alternative means of allocating and controlling serial numbers on a national basis may be adopted by administrations, but they must be compatible with the serial user protocol defined in document C/S T.001, be made known to the Cospas-Sarsat Secretariat, and provide a unique beacon 15 Hex ID.

3-29

bits 37 - 39 to "111". When using the test protocol, bits 40 to 85 and 107 to 112 may be set to any bit pattern (even random) provided that the error-correcting code is set accordingly. Cospas-Sarsat MCCs will neither respond to, nor forward alert messages corresponding to beacons coded with the test user protocol, unless requested by the appropriate authority of the country conducting the test (e.g. the SPOC in that country) and co-ordinated with the appropriate MCC (i.e. the MCC in which service area the test is being conducted). Details of the procedure to co-ordinate tests are provided in the System document C/S A.001 (DDP). The test user protocol is different than the beacon "self-test" mode described in section 3.2.2.2, which transmits a single burst having a modified frame synchronization bit pattern. The self test mode transmission of the beacon is not processed by the Cospas-Sarsat satellite equipment. Figure 3.15: Coding the Test User Protocol Bits 25 26 27 ........ 36 37 .. 39 40.................................................. .

F 1 Country Code 1 1 1 Any combination of bits allowed in the user protocol format

bit 25: (F) format flag set to "0" (short message) or "1" (long message);
bit 26: protocol flag set to "1";
bits 27 - 36: country code = 3 digit, decimal number encoded in binary notation (see section 3.2.3.2);
bits 37 - 39: protocol code set to "111" (test user protocol);
bits 40 - 85: any combination of bits (with the proper error-correcting code).

3-30

3.3.6 Coding the National User Protocol The national user protocol is a special coding format having certain data fields, indicated as "national use", which are defined and controlled by the national administration of the particular country which is identified by the country code field. The national user protocol may be either a short or a long message, as indicated by the format flag (bit 25). The correct BCH code(s) must be encoded in bits 86-106, and in bits 133-144 if a long message is transmitted. The national user protocol coding format is described in Figure 3.16: Figure 3.16: Coding the National User Protocol Bits 25 26 27 ..... 36 37 38 39 40................85 86......106 107..........132 133....144 F 1 Country Code 1 0 0 National Use (46 bits) BCH Code (21 bits) National Use (26 bits) BCH Code (12 bits)

bit 25: (F) format flag set to "0" (short message) or "1" (long message);
bit 26: protocol flag set to "1";
bits 27 - 36: country code = 3 digit decimal number encoded in binary notation (see section 3.2.3.2);
bits 37 - 39 protocol code set to "100" (national user protocol);
bits 40 - 85: national use;
bits 86-106: 21-bit BCH code;
bits 107 - 112: national use;
bits 113 - 132: national use (if long message);
bits 133 - 144: 12-bit BCH code (if long message). Once the beacon has been activated, the content of the message in bits 1 to 106 must remain fixed, but bits 107 onwards are permitted to be changed periodically, provided the correct 12-bit BCH code is also re-computed and that such changes do not occur more frequently than once every 5 minutes. It should be noted that the content of distress alert messages encoded with the national user protocol cannot be interpreted by Cospas-Sarsat MCCs and will be forwarded to SAR services only as hexadecimal data.

3-31

3.4 Coding Location Protocols This section defines the protocols which can be used for encoding beacon position data, as well as the beacon identification data, in the digital message transmitted by a 406 MHz distress beacon. Five types of location protocols are defined for use either with the long message format or with the short message format, as illustrated in Figure 3.17. The three protocol types available are: • User-location Protocol; • Standard Location Protocol; • National Location Protocol. Figure 3.17: Outline of Location Protocols U s e r - L o c a t i o n P r o t o c o l s bit

bits 27-39 bits 40-83 bits 84-85 bits 86-106 bit 107 bits 108-132 bits 133-144

....... Identification Data (44 bits) Radio- locating Device 21-Bit BCH code Position. Data Source Position Data to 4 min Resolution (25 bits) 12-Bit BCH code S t a n d a r d L o c a t i o n P r o t o c o l s bit

bits 27-40 bits 41-64 bits 65-85 bits 86-106 bits 107-112 bits 113-132 bits 133-144

....... Identification Data (24 bits) Position Data to 15 min Resolution (21 bits) 21-Bit BCH code Supplementary Data Position Data to 4 sec Resolution (20 bits) 12-Bit BCH code N a t i o n a l L o c a t i o n P r o t o c o l bit

bits 27-40 bits 41-58 bits 59-85 bits 86-106 bits 107-112 bits 113-126 bits 127-132 bits 133-144

....... Identification Data (18 bits) Position Data to 2 min Resolution (27 bits) 21-Bit BCH code Supplementary Data Position Data to 4 sec Resolution (14 bits) National Use 12-Bit BCH code E L T ( D T ) a n d R L S L o c a t i o n P r o t o c o l bit

bits 27-40 bits 41-66 bits 67-85 bits 86-106 bits 107-114 bits 115-132 bits 133-144

....... Identification Data (26 bits) Position Data to 30 min Resolution (19 bits) 21-Bit BCH code Supplementary Data (8 bits) Position Data to 4 sec Resolution (18 bits) 12-Bit BCH code

3-32

3.4.1 Position Data Encoding All position information is encoded as degrees, minutes and seconds of latitude or longitude, or as fractions of these units. Latitude and longitude data are rounded off (i.e. not truncated) to the available resolution. When a position is encoded in the PDF-1, the higher resolution information given in the PDF 2 is an offset (Δ latitude and Δ longitude) relative to the position provided in PDF 1. The position is encoded as follows. The coarse position encoded in the PDF-1 is selected to be as close as possible to the actual position. Then the actual position is rounded off. The offset encoded in the PDF-2 is selected so that it may be summed with the coarse position to produce a finer position that equates to the rounded position. Subsequent position updates (if applicable) are encoded in exactly the same way. An example of encoding of position data for the standard location protocol is presented in Table 3.7. More examples of encoding of the position data with the Standard Location and National Location protocols are provided in Annex A. Table 3.7: Encoding of Position Data Position data: actual latitude: 43 43' 57'' N actual longitude: 0 57' 51'' E actual latitude rounded to nearest 4'' increment: 43 43' 56''N actual longitude rounded to nearest 4'' increment: 000 57' 52''E coarse latitude: 43 45' N coarse longitude: 001 0' E latitude offset:

1' 4'' longitude offset:
2' 8'' Binary encoding: position bits setting Latitude Flag: N

Latitude in Degrees (in 1/4 degree increment): 43 66-74 0101011 11 Longitude Flag: E

Longitude in Degrees (in 1/4 degree increment):

76-85 00000001 00 Latitude offset sign:

Latitude offset in min:

114-118

Latitude offset in sec:

119-122

Longitude offset sign:

Longitude offset in min:

124-128

Longitude offset in sec:

129-132

3-33

The latitude and longitude values contained in the PDF-1 are positive numbers regardless of their directions. The offset is applied by adding or subtracting the offset value in accordance with the offset sign in PDF-2. For example: 100° E. longitude + 30 offset = 100° 30 E. longitude 100° W. longitude + 30 offset = 100° 30 W. longitude (not 99° 30 W. longitude) 100° W. longitude - 30 offset = 99° 30W. longitude (not 100° 30 W. longitude). 3.4.2 Coding the User-location Protocols The applicable user-location protocol is selected by setting bit 26 (protocol flag) to "1" and bits 37 to 39 as defined in section 3.3. The protocols are available only in long message format, with bit 25 (format flag) set to “1”. The beacon identification data is provided in the PDF-1 by any one of the user protocols defined in section 3.3, except the orbitography user protocol and the national user protocol. Position data is provided as latitude and longitude, to 4-minute resolution, encoded in the PDF-2. The 26 bits available in the PDF-2 can be encoded as shown in Figure 3.18. Figure 3.18: Coding the User-location Protocols’ Second Protected Data Field (PDF-2) Bits

......

Position Data Source Flag N/S Latitude Data Flag E/W Longitude Data

bit 107: encoded position data source bit set to "0" means that the encoded position data is provided by an external navigation device, encoded position data source bit set to "1" means that the encoded position data is provided by an internal navigation device;
bits 108 to 119: latitude data (12 bits) with 4 minute resolution, including:
bit 108: N/S flag (N=0, S=1),
bits 109 to 115: degrees (0 to 90) in 1 degree increments,
bits 116 to 119: minutes (0 to 56) in 4 minute increments, (default value of bits 108 to 119= 0 1111111 0000);
bits 120 to 132: longitude data (13 bits) with 4 minute resolution including:
bit 120: E/W flag (E=0, W=1),
bits 121 to 128: degrees (0 to 180) in 1 degree increments,
bits 129 to 132: minutes (0 to 56) in 4 minute increments, (default value of bits 120 to 132= 0 11111111 0000).

3-34

3.4.3 Coding the Standard Location Protocols The applicable standard location protocol is selected by setting bit 26 (protocol flag) to "0" and bits 37 to 40 as defined below. The protocols are available in long message format with bit 25 (format flag) set to “1”. The beacon identification data is provided in a standardised format in 24 bits of the PDF-1 and can be encoded for different standard location protocols as shown in Figures 3.19 to 3.23*. Position data to 15-minute resolution is also given in the PDF-1, with position offsets to 4- second resolution in the PDF-2. The coding of this data is the same for all types of standard location protocols and is described with further details in Figure 3.24. Figure 3.19: Coding the Standard Location Protocol with MMSI Bits

.... 36

.... 60 61 ...

Country Code

(20 bits) Last 6 Digits of MMSI Specific Beacon Number

bit 25: format flag set to "1" (long message);
bit 26: protocol flag set to "0";
bits 27 to 36: country code = 3 digit , decimal number encoded in binary notation (see section 3.2.3.2);
bits 37 to 40: protocol code, set to "0010" (EPIRB -MMSI Standard Location Protocol);
bits 41 to 60: contain the last 6 digits of MMSI in binary form;
bits 61 to 64: 4-bit specific EPIRB number (in binary notation with the least significant bit on the right) used if several EPIRBs are carried on same vessel and encoded with the same 20 bit MMSI address, all bits defaulted to “0” when only one EPIRB is carried.

3-35

Figure 3.20: Coding a Ship Security Alert System (SSAS) Beacon Bits

.... 36

.... 60 61 ...

Country Code

(20 bits) Last 6 Digits of MMSI Specific Beacon Number

bit 25: format flag set to "1" (long message);
bit 26: protocol flag set to "0";
bits 27 to 36: country code = 3 digit , decimal number encoded in binary notation (see section 3.2.3.2);
bits 37 to 40: protocol code, set to "1100" (Ship Security Alert);
bits 41 to 60: contain the last 6 digits of MMSI in binary form;
bits 61 to 64: values set to "0000" Figure 3.21: Coding the Standard Location Protocol with the 24-bit Aircraft Address Bits 25

.... 36

.. ..

...................... 64

Country Code

24 bit Aircraft Address

bit 25: format flag set to "1" (long message);
bit 26: protocol flag set to "0";
bits 27 to 36: country code = 3 digit , decimal number encoded in binary notation (see section 3.2.3.2);
bits 37 to 40: protocol code, set to "0011" (ELT 24-bit Address Standard Location Protocol);
bits 41 to 64: contain the 24-bit aircraft address (only one ELT per aircraft can be identified using this protocol). Note: * ELTs carried to satisfy the requirements of ICAO Annex 6, Parts I, II and III shall operate in accordance with ICAO Annex 10.

3-36

Figure 3.22: Coding the Standard Location Protocol with the Aircraft Operator Designator and Serial Number Bits

.... 36 37 .. ..

....

...

Country Code

(15 bits) 3-letter of AOD code 9 bit ELT Number

bit 25: format flag set to "1" (long message);
bit 26: protocol flag set to "0";
bits 27 to 36: country code = 3 digit, decimal number encoded in binary notation (see section 3.2.3.2);
bits 37 to 40: protocol code, set to "0101" (ELT - Aircraft Operator Designator Standard Location Protocol);
bits 41 to 55: 3-letter aircraft operator designator, encoded using the Modified-Baudot code (see Table B.1 of Annex B) in shortened form: the first bit which is =1 for any letter is deleted to form a 5 bit code;
bits 56 to 64: 9-bit unique ELT number (1-511) in binary form assigned by operator. Figure 3.23: Coding the ELT/EPIRB/PLB Serial Identification Data in the Standard Location Protocols Bits

.... 36

.. ..

.... 50

...

Country Code X X X X 10 bit C-S type approval certificate Number 14 bit Serial Number

bit 25: format flag set to "1" (long message);
bit 26: protocol flag set to "0";
bits 27 to 36: country code = 3 digit, decimal number encoded in binary notation (see section 3.2.3.2);
bits 37 to 40: standard location protocol code, set to: 0100 for ELT, 0110 for EPIRB, 0111 for PLB;
bits 41 to 50: contain the 10-bit Cospas-Sarsat type approval certificate number of the beacon (1 to 1,023);
bits 51 to 64: 14-bit serial number (1 to 16,383) in binary form.

3-37

Figure 3.24: Coding the Position Data in the Standard Location Protocols Bits

66-74 75 76-85 86-106 107-112 113 114-118 119-122 123 124-128 129-132 133-144 Flag Lat Lat degr Flag Long Long degr 21-bit BCH code Suppl. Data Lat  Sign Lat  min Lat  sec long  sign Long  min Long  sec 12-bit BCH code

bits 65 to 74: latitude data (10 bits) with 15 minute resolution, including:
bit 65: Latitude flag (N=0, S=1)
bits 66 to 74: degrees (0 to 90) in 0.25 degree increments (default value of bits 65 to 74 = 0 111111111);
bits 75 to 85: longitude data (11 bits) with 15 minute resolution including:
bit 75: Longitude flag (E=0, W=1)
bits 76 to 85: degrees (0 to 180) in 0.25 degree increments (default value of bits 75 to 85 = 0 1111111111);
bits 86 to 106: 21-bit BCH code;
bit 107-110: “1101” (fixed);
bit 111: position data source flag set to "0" means that the position data encoded in PDF-1 is provided by an external navigation device; position data source flag set to "1" means that the position data encoded in PDF-1 is provided by an internal navigation device;
bit 112: 121.5 MHz radio-locating device flag set to "0" means that there is no 121.5 MHz auxiliary radio-locating transmitter in the beacon; 121.5 MHz radio-locating device flag set to "1" means that the beacon is equipped with a 121.5 MHz auxiliary radio-locating transmitter;
bits 113 to 122: offset () latitude data (10 bits) with 4 second resolution, including:
bit 113:  sign (0=minus, 1=plus)
bits 114 to 118: minutes (0 to 30) in 1 minute increments
bits 119 to 122: seconds (0 to 56) in 4 second increments (default value of bits 113 to 122 = 1 00000 1111);
bits 123 to 132: offset () longitude data (10 bits) with 4 second resolution, including:
bit 123:  sign (0=minus, 1=plus)
bits 124 to 128: minutes (0 to 30) in 1 minute increments
bits 129 to 132: seconds (0 to 56) in 4 second increments (default value of bits 123 to 132 = 1 00000 1111);
bits 133 to 144: 12-bit BCH code.

Fig 3.24 defines the coding scheme for all Standard Location Protocols, some newer beacons where the coarse position in PDF-1 is always selected to be as close as possible to the actual position will have a maximum offset in PDF-2 of +/- 7 minutes 30 seconds, in which case bits 114, 115, 124 and 125 of the message will not be used and should be permanently set to “0”.

3-38

3.4.4 Coding the National Location Protocol The applicable national location protocol is selected by setting bit 26 (protocol flag) to “0” and bits 37 to 40 as defined below. The protocol is available in the long message format with bit 25 (format flag) set to “1”. The beacon identification data is provided in a nationally-defined format in 18 bits of the PDF-1. Position data, to 2-minute resolution, are given in the PDF-1, with position offsets to 4-second resolution in the PDF-2. The coding of the national location protocol is described with further details in Figure 3.25. Figure 3.25: Coding the National Location Protocol Figure 3.25.a: Data of the PDF-1 and BCH-1 Fields of National Location Protocol Bits

27-36 37-40 41-58

60-66 67-71

73-80 81....85 86-106 Format Flag Prot. Flag MID Prot. Code Ser. Numb Flag Lat Lat degr Lat min Flag Long Long degr Long min 21-bit BCH code

bit 25: format flag set to "1" (long message);
bit 26: protocol flag set to "0";
bits 27 to 36: country code = 3 digit, decimal number encoded in binary notation (see section 3.2.3.2);
bits 37 to 40: National location protocol code set to: 1000 for ELT, 1010 for EPIRB, 1011 for PLB;
bits 41 to 58: contain the 18-bit identification data consisting of a serial number assigned by the responsible administration;
bits 59 to 71: latitude data (13 bits) with 2 minute resolution, including:
bit 59: N/S flag (N=0, S=1)
bits 60 to 66: degrees (0 to 90) in 1 degree increments
bits 67 to 71: minutes (0 to 58) in 2 minute increments (default value of bits 59 to 71= 0 1111111 00000);
bits 72 to 85: longitude data (14 bits) with 2 minute resolution including:
bit 72: E/W flag (E=0, W=1)
bits 73 to 80: degrees (0 to 180) in 1 degree increments
bits 81 to 85: minutes (0 to 58) in 2 minute increments (default value of bits 72 to 85 = 0 11111111 00000);
bits 86 to 106: 21-bit BCH code.

3-39

Figure 3.25.b: Data of the PDF-2 and BCH-2 Fields of National Location Protocol Bits 107-112

114-115 116-119

121-122 123-126 127.................132 133-144 Supplem. Data Lat  Sign Lat min Lat sec long  sign Long min Long sec National Use 12-bit BCH code

bit 107-109: “110” (fixed);
bit 110: additional data flag: set to “1” means that  position data encoded in PDF-2, set to “0” means that data in PDF-2 is defined nationally;
bit 111: position data source flag set to "0" means that the position data encoded in PDF-1 is provided by an external navigation device; position data source flag set to "1" means that the position data encoded in PDF-1 is provided by an internal navigation device;
bit 112: 121.5 MHz radio-locating device flag set to "0" means that there is no 121.5 MHz auxiliary radio-locating transmitter in the beacon; 121.5 MHz radio-locating device flag set to "1" means that the beacon is equipped with a 121.5 MHz auxiliary radio-locating transmitter;
bits 113 to 119: offset () latitude data (7 bits) with 4 second resolution, including:
bit 113:  sign (0=minus,1=plus)
bits 114 to 115: minutes (0 to 3) in 1 minute increments
bits 116 to 119: seconds (0 to 56) in 4 second increments (default value of bits 113 to 119 = 1 00 1111);
bits 120 to 126: offset () longitude data (7 bits) with 4 second resolution, including:
bit 120:  sign (0=minus, 1=plus)
bits 121 to 122: minutes (0 to 3) in 1 minute increments
bits 123 to 126: seconds (0 to 56) in 4 second increments (default value of bits 120 to 126 = 1 00 1111);
bits 127 to 132: Additional beacon type identification (national use) (default value of bits 127 to 132= 000000);
bits 133 to 144: 12-bit BCH code.

Fig 3.25.b defines the coding scheme for all National Location Protocols, some newer beacons where the coarse position in PDF-1 is always selected to be as close as possible to the actual position will have a maximum offset in PDF-2 of +/- 1 minute, in which case bits 114 and 121 of the message will not be used and should be permanently set to “0”.

3-40

3.4.5 Coding the RLS Location Protocols The applicable Return Link System (RLS) location protocol is selected by setting bit 26 (protocol flag) to "0" and bits 37 to 40 to “1101”. The protocols are available in long message format with bit 25 (format flag) set to “1”. The beacon identification data is provided in a standardised format in 26 bits of the PDF-1 and can be encoded for different RLS beacon types as shown in Figure 3.26. Position data to a 30-minute resolution is also given in the PDF-1, with position offsets to 4-second resolution in the PDF-2. The coding of this data is the same for all RLS beacons and is described with further details in Figure 3.27. Supplementary and RLS data is encoded in the message as shown in Figure 3.28.

3-41

Figure 3.26: Coding the RLS Location Protocol Bits

.... 36

.. .... 40 41 … 42 43 .... 52

...

Country Code

Beacon Type 10 bit RLS type approval certificate Number 14 bit RLS ID Serial Number

Country Code

Beacon Type 10 bit National RLS Number 14 bit serial number assigned by a Competent Authority Bits

.... 36

.. .... 40 41 … 42 43 .... 46

...

Country Code

Beacon Type 1 1 1 1 20 bit last six digits of MMSI

bit 25: format flag set to "1" (long message);
bit 26: protocol flag set to "0";
bits 27 to 36: country code = 3 digit, decimal number encoded in binary notation (see section 3.2.3.2);
bits 37 to 40: RLS location protocol code, set to: 1101;
bits 41 to 42: beacon type, set to: 00 for ELT, 01 for EPIRB, 10 for PLB, 11 for RLS Test Protocol except when bits 43 to 46 have the value “1111” in which case these bits indicate the following; “00” First EPIRB on Vessel, “01” Second EPIRB on Vessel, “10” PLB and “11” Location Test Protocol;
bits 43 to 52: contain the 10-bit Cospas-Sarsat RLS truncated*†‡ type approval certificate number of the beacon (1 to 919) or National RLS Number, except when bits 43 to 46 are set to “1111”;
bits 53 to 66: 14-bit serial number (1 to 16,383) in binary form, or 14-bit identification data consisting of a Competent Authority assigned serial number (1 to 16,383), associated with a National RLS Number that has been allocated to an Administration by the Cospas-Sarsat Programme (920 to 949), except when bits 43 to 46 are set to “1111”;
bits 47 to 66:. When bits 43 to 46 are set to “1111” then and only then, do these bits provide the last six digits of the MMSI in binary form§. Figure 3.27: Coding the Position Data in the RLS Location Protocols

The 10-bit RLS truncated TAC or National RLS number is the last 3 decimal numbers in the TAC number data field, which allows a range of 1 to 948. The RLS beacon TAC number 949 is reserved for type-approval testing. The RLS beacon TAC number or National RLS number series are assigned as follows: 1000 series is reserved for EPIRBs (i.e. 1001 to 1948), 2000 series is reserved for ELTs (i.e. 2001 to 2948), and 3000 series is reserved for PLBs (i.e. 3001 to 3948). These are represented in the RLS messages as bits 41 to 42 (except when bits 43 to 46 are set to “1111”) indicating the beacon type series (EPIRB, ELT, or PLB) and a 10 bit (1-1024) TAC number which is added to the series to encode the full TAC number. (e.g., TAC 1042 would be encoded as “01” for EPIRB in bits 41 to 42 representing 1nnn, where “nnn” is “042” determined by “0000101010” in bits 43 to 52, and form a binary representation “00 0010 1010” of the decimal number “42”. † The numbers 920 to 948 (i.e., National RLS Numbers 920 to 948) are set aside for National Use by Competent Authorities. That is full National RLS Numbers 1920 to 1948 for EPIRBs, 2920 to 2948 for ELTs, and 3920 to 3948 for PLBs. ‡ The numbers in the ranges x700 to x799 in the 1000, 2000 and 3000 series have been set aside for allocation to special-use beacon models approved under letters of compatibility. § The full 9-digit MMSI is comprised of the Country Code in bits 27 to 36 providing the Flag State (MID) of the vessel and bits 47 to 66 providing the unique 6-digit identity for the vessel.

3-42

Bits

68-75 76 77-85 86-106 107-108 109-

115 116-119 120-123 124 125-128 129-132 133-144 Flag Lat Lat degr Flag Long Long degr 21-bit BCH code Suppl. Data RLS Data Lat  Sign Lat  min Lat  sec long  sign Long  min Long  sec 12-bit BCH code

bits 67 to 75: latitude data (9 bits) with 30 minute resolution, including:
bit 67: Latitude flag (N=0, S=1)
bits 68 to 75: degrees (0 to 90) in 0.5 degree increments (default value of bits 67 to 75 = 0 11111111);
bits 76 to 85: longitude data (10 bits) with 30 minute resolution including:
bit 76: Longitude flag (E=0, W=1)
bits 77 to 85: degrees (0 to 180) in 0.5 degree increments (default value of bits 76 to 85 = 0 111111111);
bits 86 to 106: 21-bit BCH code;
bit 107 to 108: Supplementary Data (See Figure 3.28)
bit 109 to 114: RLS Data (See Figure 3.28)
bits 115 to 123: offset () latitude data (9 bits) with 4 second resolution, including:
bit 115:  sign (0=minus, 1=plus)
bits 116 to 119: minutes (0 to 15) in 1 minute increments*
bits 120 to 123: seconds (0 to 56) in 4 second increments (default value of bits 115 to 123 = 1 0000 1111);
bits 124 to 132: offset () longitude data (9 bits) with 4 second resolution, including:
bit 124:  sign (0=minus, 1=plus)
bits 125 to 128: minutes (0 to 15) in 1 minute increments*
bits 129 to 132: seconds (0 to 56) in 4 second increments (default value of bits 123 to 132 = 1 0000 1111);
bits 133 to 144: 12-bit BCH code.

For RLS Location Protocol beacons the coarse position in PDF-1 is always selected to be as close as possible to the actual position and will have a maximum offset in PDF-2 of +/- 15 minutes.

3-43

Figure 3.28: Coding the RLS Data in the RLS Location Protocols Bits

68-75 76 77-85 86-106 107-108 109-

bit 107 to 108: Supplementary Data;
bit 107: position data source flag set to "0" means that the position data encoded in PDF-1 is provided by an external navigation device; position data source flag set to "1" means that the position data encoded in PDF-1 is provided by an internal navigation device;
bit 108: 121.5 MHz radio-locating device flag set to "0" means that there is no 121.5 MHz auxiliary radio-locating transmitter in the beacon; 121.5 MHz radio-locating device flag set to "1" means that the beacon is equipped with a 121.5 MHz auxiliary radio-locating transmitter;
bit 109 to 114: RLS Data;
bit 109 to 110: RLM Request
bit 109: Capability to process RLM Type-1: "1": Acknowledgement Type-1 (automatic acknowledgement) accepted by this beacon, "0": Acknowledgement Type-1 not requested and not accepted by this beacon;
bit 110: Capability to process manually generated RLM: "1": Manually generated RLM (such as Acknowledgement Type-2) accepted by this beacon, "0": Manually generated RLM (such as Acknowledgement Type-2) not requested and not accepted by this beacon
bit 111 to 112: Beacon feedback (acknowledging the reception of the RLM)
bit 111: Feedback on RLM Type-1: "1": Acknowledgement Type-1 (automatic acknowledgement) received by this beacon, "0": Acknowledgement Type-1 not (yet) received by this beacon;
bit 112: Feedback on RLM Type-2: "1": Acknowledgement Type-2 (or manually generated RLM) received by this beacon, "0": Acknowledgement Type-2 not (yet) received by this beacon
bit 113 to 114: RLS Provider Identification "01": GALILEO Return Link Service Provider, "10": GLONASS* Return Link Service Provider, “11”: BDS* Return Link Service Provider, and "00": Spare (for other RLS provider);

Beacons shall not be coded with these coding options (except for the RLS location test protocol) until the GLONASS or BDS RLS services are declared operational by the Cospas-Sarsat Programme and type approval for these versions of the RLS Location protocols cannot be granted.

3-44

3.4.6 Coding the ELT(DT) Location Protocols The applicable ELT(DT) location protocol is selected by setting bit 26 (protocol flag) to "0" and bits 37 to 40 to “1001”. The protocols are available in long message format with bit 25 (format flag) set to “1”. The beacon identification data is provided in a standardised format in 26 bits of the PDF-1 and can be encoded for different ELT(DT) ID types as shown in Figures 3.29 to 3.31. Position data to a 30-minute resolution is also given in the PDF-1, with position offsets to 4-second resolution in the PDF-2. The coding of this data is the same for all ELT(DT) beacons and is described with further details in Figure 3.32. Supplementary ELT(DT) data is encoded in the message as shown in Figure 3.33. WARNING: Administrations are cautioned that the use of the ELT(DT) location protocol with 24-bit aircraft address (Figure 3.29) including the PDF-2 rotating field option (Figure 3.33), is the only ELT(DT) coding protocol which is fully compatible with the Cospas-Sarsat MCC network allowing the automated processing of these messages for transmission to the ICAO LADR. All other ELT(DT) protocol options will require Administrations’ aviation authorities to establish guidance for their aircraft operators to deposit the alert information into the ICAO LADR. Figure 3.29: Coding the ELT(DT) Location Protocol with the 24-bit Aircraft Address Bits 25

.... 36

.. ..

41 ..42 43 ....................

Country Code

0 0 24 bit Aircraft Address

bit 25: format flag set to "1" (long message);
bit 26: protocol flag set to "0";
bits 27 to 36: country code = 3 digit , decimal number encoded in binary notation (see section 3.2.3.2);
bits 37 to 40: ELT(DT) location protocol code, set to: 1001;
bits 41 to 42: Aircraft ID, 2-bits for type of beacon identity set to “00” for Aircraft 24 bit address;
bits 43 to 66: contain the 24-bit aircraft address (only one ELT per aircraft can be identified using this protocol). Or
bits 43 to 66: encoded with all “0”s or all “1”s to indicate ELT(DT) Location Test protocol.

3-45

Figure 3.30: Coding the ELT(DT) Location Protocol with the Aircraft Operator Designator and Serial Number Bits

.... 36 37 .. ..

41 … 42

....

...

Country Code 1

0 1 (15 bits) 3-letter of AOD code 9 bit ELT Number

bit 25: format flag set to "1" (long message);
bit 26: protocol flag set to "0";
bits 27 to 36: country code = 3 digit, decimal number encoded in binary notation (see section 3.2.3.2);
bits 37 to 40: ELT(DT) location protocol code, set to: 1001;
bits 41 to 42: Aircraft ID, 2-bits for type of beacon identity set to “01” for Aircraft operators designator and serial number;
bits 43 to 57: 3-letter aircraft operator designator, encoded using the Modified-Baudot code (see Table B.1 of Annex B) in shortened form: the first bit which is =1 for any letter is deleted to form a 5 bit code;
bits 58 to 66: 9-bit unique ELT number (1-511) in binary form assigned by operator. Or
bits 43 to 66: encoded with all “0”s or all “1”s to indicate ELT(DT) Location Test protocol. Figure 3.31: Coding the C/S Serial Identification Data in the ELT(DT) Location Protocol Bits

.... 36

.. .... 40 41 … 42 43 .... 52

...

Country Code

1 0 10 bit C/S type approval certificate Number 14 bit Serial Number

bit 25: format flag set to "1" (long message);
bit 26: protocol flag set to "0";
bits 27 to 36: country code = 3 digit, decimal number encoded in binary notation (see section 3.2.3.2);
bits 37 to 40: ELT(DT) location protocol code, set to: 1001;
bits 41 to 42: Aircraft ID, 2-bits for type of beacon identity set to “10” for TAC with serial number;
bits 43 to 52: contain the 10-bit Cospas-Sarsat type approval certificate number of the beacon (1 to 1,023);
bits 53 to 66: 14-bit serial number (1 to 16,383) in binary form. Or
bits 43 to 66: encoded with all “0”s or all “1”s to indicate ELT(DT) Location Test protocol.

3-46

Figure 3.32: Coding the Position Data in the ELT(DT) Location Protocols Bits

68-75 76 77-85 86-106 107-114 115 116-119 120-123 124 125-128 129-132 133-144 Flag Lat Lat degr Flag Long Long degr 21-bit BCH code Suppl. Data Lat  Sign Lat  min Lat  sec long  sign Long  min Long  sec 12-bit BCH code

bits 67 to 75: latitude data (9 bits) with 30 minute resolution, including:
bit 67: Latitude flag (N=0, S=1)
bits 68 to 75: degrees (0 to 90) in 0.5 degree increments (default value of bits 67 to 75 = 0 11111111);
bits 76 to 85: longitude data (10 bits) with 30 minute resolution including:
bit 76: Longitude flag (E=0, W=1)
bits 77 to 85: degrees (0 to 180) in 0.5 degree increments (default value of bits 76 to 85 = 0 111111111);
bits 86 to 106: 21-bit BCH code;
bit 107 to 114: Supplementary Data (See Figure 3.33)
bits 115 to 123: offset () latitude data (9 bits) with 4 second resolution, including:
bit 115:  sign (0=minus, 1=plus)
bits 116 to 119: minutes (0 to 15) in 1 minute increments*
bits 120 to 123: seconds (0 to 56) in 4 second increments (default value of bits 115 to 123 = 1 0000 1111);
bits 124 to 132: offset () longitude data (9 bits) with 4 second resolution, including:
bit 124:  sign (0=minus, 1=plus)
bits 125 to 128: minutes (0 to 15) in 1 minute increments*
bits 129 to 132: seconds (0 to 56) in 4 second increments (default value of bits 123 to 132 = 1 0000 1111);
bits 133 to 144: 12-bit BCH code.

Section A3.3.7 defines the coding scheme for the ELT(DT) Location Protocol. For these new beacons the coarse position in PDF-1 is always selected to be as close as possible to the actual position and will have a maximum offset in PDF-2 of +/- 15 minutes.

3-47

Figure 3.33: Coding the Supplementary Data in the ELT(DT) Location Protocols Bits

bit 107 to 108: Means of Activation; “00”: manual activation by the user “01”: automatic activation by the beacon “10”: automatic activation by external means “11”: spare;
bit 109 to 112: Encoded Altitude; “0000”: altitude is less than or equal to 400 m (1312 ft) “0001”: altitude is greater than 400 m (1312 ft) up to and including 800 m (2625 ft) “0010”: altitude is greater than 800 m (2625 ft) up to and including 1200 m (3937 ft) “0011”: altitude is greater than 1200 m (3937 ft) up to and including 1600 m (5249 ft) “0100”: altitude is greater than 1600 m (5249 ft) up to and including 2200 m (7218 ft) “0101”: altitude is greater than 2200 m (7218 ft) up to and including 2800 m (9186 ft) “0110”: altitude is greater than 2800 m (9186 ft) up to and including 3400 m (11155 ft) “0111”: altitude is greater than 3400 m (11155 ft) up to and including 4000 m (13123 ft) “1000”: altitude is greater than 4000 m (13123 ft) up to and including 4800 m (15748 ft) “1001”: altitude is greater than 4800 m (15748 ft) up to and including 5600 m (18373 ft) “1010”: altitude is greater than 5600 m (18373 ft) up to and including 6600 m (21654 ft) “1011”: altitude is greater than 6600 m (21654 ft) up to and including 7600 m (24934 ft) “1100”: altitude is greater than 7600 m (24934 ft) up to and including 8800 m (28871 ft) “1101”: altitude is greater than 8800 m (28871 ft) up to and including 10000 m (32808 ft) “1110” altitude is greater than 10000 m (32808 ft) “1111”: default value if altitude information is not available
bit 113 to 114: Encoded location freshness; "00”: PDF-2 rotating field indicator, “01”: encoded location in message is more than 60 seconds old, or the default encoded position is transmitted, “10”: encoded location in message is greater than 2 seconds and equal to or less than 60 seconds old, “11”: encoded location in message is current (i.e., the encoded location freshness is less or equal to 2 seconds). When bit 113 to 114 = “00” i.e., PDF-2 Rotating Field Bits

68-75 76 77-85 86-106 107-114 115-117 118-132 133-144 Flag Lat Lat degr Flag Long Long degr 21-bit BCH code Suppl. Data PDF-2 Rotating Field Type PDF-2 Rotating Field 12-bit BCH code

bits 113 to 114: “00”: PDF-2 rotating field indicator

bit 115 to 117: PDF-2 Rotating Field Type “000”: Aircraft Operator 3LD Other: Spare

bit 115 to 117: equal to “000”

3-48

bit 118 to 132 3-letter aircraft operator designator*, encoded using the Modified-Baudot code (see Table B.1 of Annex B) in shortened form: the first bit which is =1 for any letter is deleted to form a 5 bit code; if there is no 3LD for the aircraft operator, then the 3LD is coded as “ZGA”, i.e., bits 115 to 132 are set to 000 10001 01011 11000). 3.4.6.1 ELT(DT) Cancellation Message In case of alert cancellation, a specific message shall be sent with the following bit assignment: bits 37 to 40: 4-bit protocol code as defined as 1001 bits 41 to 42: 2-bits for type of beacon identity bits 43 to 66: 24 bits of beacon identification data, or ELT(DT) Location Test protocol bits 67 to 75: fixed sequence “1 11111010”; bits 76 to 85: fixed sequence “1 111111010”; bits 86 to 106: BCH-1 bits 107 to 114: fixed sequence “00111100” bits 115 to 123: fixed sequence “0 1111 0000” bits 124 to 132: fixed sequence “0 1111 0000” bits 133 to 144: BCH-2 3.4.7 Coding the Test Location Protocols The test protocol for all coding methods (i.e. "user" and "location" protocols (except RLS and ELT(DT) protocols)) is encoded by setting bits 37-39 (protocol code) to "111". In addition, bit 40 is used to distinguish between the test format of the standard location protocols (bit 40 = "0") and national location protocols (bit 40 = "1"). With the above exception, the coding described in section 3.3.5 and Figure 3.15 (Test User Protocol) remain valid for the Test Location Protocol. The RLS test protocol is indicated by setting bits 41 to 42 to binary “11”. Thus, for an RLS test beacon it is not possible to distinguish between different types of beacon (i.e., ELT, EPIRB, or PLB). The remaining fields allow multiple beacon IDs to be encoded however there will be some ambiguity as to the beacon type and hence whether the beacon should be assigned to the 1000, 2000, or 3000 series of TACs would be unknown with the test protocol. The ELT(DT) test protocol is indicated by setting bits 43 to 66 to all “0”s or all “1”s. Thus, for an ELT(DT) there are only two ID bits (41 and 42) which can be used to distinguish between different test protocol beacons available for use in combination with the country code (bits 27 to 36) field.

3LD is a 3-Letter aircraft operator Designator from the list of "Designators for Aircraft Operating Agencies, Aeronautical Authorities and Services" published by the International Civil Aviation Organization (ICAO) as document 8585.

3-49

END OF SECTION 3 -

4-1

SECOND GENERATION 406-MHz BEACON CODING (SGB) 4.1 C/S T.018 Beacon Types Cospas-Sarsat 406 MHz beacons can be used in different environments and for a variety of applications such as EPIRBs that service the maritime environment, ELTs and ELT(DT)s (aviation) or PLBs (personal use). The specification of the distress signal characteristics (document C/S T.018), which ensures that all 406 MHz beacons are compatible with the Cospas-Sarsat Space Segment, is applicable to all types of beacons. However, different user groups have different needs; hence the need for various coding options. To satisfy these requirements, the Cospas-Sarsat specification provides for various coding options which for FGBs were divided in two groups of coding protocols: user protocols and location protocols. However, unlike FGBs, SGBs do not have coding protocols and the differentiation between "location” and "non-location” beacons is provided by the data encoded in the location field of the SGB message. See section 4.2.2 below for a description. All SGB messages have the general structure of the 406 MHz digital message described in section 4.2 of this document. Administrations will normally specify which coding options can be used for the applications that they authorise. Manufacturers of 406 MHz beacons should contact the appropriate national authorities to determine how beacons should be coded for each country. The document C/S S.007 “Handbook of Beacon Regulations”, which is semi-annually updated by the Cospas-Sarsat Secretariat, provides a list of points of contact (including addresses and telephone numbers) for beacon matters in a number of countries. Administrations should not authorise coding options which are not currently allocated or permitted by the Cospas-Sarsat specification for 406 MHz beacons (C/S T.018).

4-2

4.2 General Coding Requirements 4.2.1 Overall SGB Message Structure Preamble Correcting bits Useful message 166.7 ms 673.3 ms 160 ms 1s Figure 4-1: Burst general structure Figure 4-1 depicts the general message structure of an SGB burst. 4.2.1.2 Preamble The initial 166.7 ms of the transmitted signal shall consist of the combination of the first 6400 chips of the two PRN code segments (each segment 38,400 chips long for the entire burst) used to spread the I and Q message components as illustrated in Figure 2-3. There will be no useful information encoded on either the I or Q components during the preamble. I and Q component information bits shall all be set to ‘0’ during the preamble. 4.2.1.3 Useful Message The contents of the useful message are described in section 4.2.2 below. 4.2.1.4 Protected Data Field The entire 202 bits forming the message data field are followed by a 48-bit Bose- Chaudhuri-Hocquenhem (BCH) error-correcting code (bits 203 to 250), in a field defined as the BCH error correcting field (BCH). This code can detect and correct up to six bit errors in the 250 bits of the SGB message. The error-correcting code is generated from the content of the message field as described in Appendix B of C/S T.018. Therefore, it must be computed and encoded together with the message data. When updates to the message content are required for encoding position data, or other dynamic message data (time since activation, remaining battery life, etc.), the error-correcting code must be regenerated prior to each transmission as the message content changes. 4.2.2 General Format and Field Definition of the SGB 406-MHz Message The message transmitted by a Cospas-Sarsat SGB 406-MHz beacon is encoded as shown in Figure 4-1.

4-3

202 information bits 48 error correction bits 154 bit main field 48 bit rotating field 48 bit BCH field Main Message Spare

…

….……

…………….

Figure 4-2: Message content bits A graphical representation of the detailed SGB message structure can be found on the Cospas-Sarsat website at: https://www.cospas-sarsat.int/images/content/articles/SGB_Message_Structure_-_63_Hex_- _23_Hex_-_15_Hex_Ver-11-NN.pdf The SGB graphic provided on the Cospas-Sarsat website summarizes in a single graphic the SGB message content specified in document C/S T.018. It shows the structure of the SGB message, what information will be provided by the SGB messages, and where this information will be allocated in the message. It also shows the relationship between the 63 hexadecimal characters composing the full SGB Message and the specific contents of the 23 Hex ID and of the truncated SGB 15 Hex ID. 4.2.3 23-Hexadecimal ID The 23-Hex ID unlike a FGB 15-Hex ID is not directly transmitted in the beacon message. The SGB 23-Hex ID needs to be constructed by combining specific data bits in the message as described in the SGB data structure graphic (see section 4.2.2) or document C/S T.018, Table 3.10. The 23-Hex ID can be truncated to become a 15-Hex ID and the combination rules ensure that it results in a unique Hex ID as one of the spare 15-Hex IDs from the FGB coding standards has been reserved for that purpose. 4.3 SGB Specific Coding Features 4.3.1 Location vs. Non-Location Encoded Beacons As SGBs all use a similar message format (i.e., no different protocols), the capabilities of the beacon to provide an encoded location in the message are indicated by the use of default values in the encoded message. If the beacon is capable of providing encoded location information than the beacon message will either contain an encoded GNSS location or the default value in bits: 44 to 66 of “0 1111111 000001111100000”, and 67 to 90 of “0 11111111 111110000011111”.

4-4

Alternatively, if the beacon does not have GNSS location capabilities, the alternate default values (i.e., the N/S (bit 44) and E/W (bit 67) flags are switched from 0 to 1 in the default pattern indicating no GNSS capability is provided by this beacon) are used as follow: 44 to 66 of “1 1111111 000001111100000”, and 67 to 90 of “1 11111111 111110000011111”. 4.3.2 Spreading Codes SGBs messages are transmitted using one of two distinct pseudo random noise (PRN) spreading codes. These two codes allow “normal” distress transmissions to be distinguished from “self-test” transmissions. 4.3.3 Transmission Schedule SGB are designed to include a variable transmission rate into their transmission schedule. This allows more frequent transmissions to occur earlier in the distress sequence and gradually reducing the transmission rate later in the distress which allows the conservation of the beacon battery. Table 4.1 indicates the nominal transmission repetition intervals during various phases of beacon operation. Table 4.1: Transmission Schedule IAMSAR Stage Nominal Time from Activation Transmission Nominal Repetition Interval Randomization Initial 0 to 30* Seconds 5 Seconds

Action / Planning 30† Seconds to 30 minutes 30 Seconds ± 5 Seconds 30 minutes + 120 Seconds ± 5 Seconds ELT (DT) 0 to 120 Seconds 5 Seconds

120 to 300 Seconds 10 Seconds

300 Seconds + 28.5 Seconds ± 1.5 Seconds 4.3.4 Message Fields The message fields are described in the SGB data structure graphic (see section 4.2.2). 4.3.4.1 Main Field The following text provides basic guidance on programming an SGB. Unlike FGBs, all SGBs are serialized and include a TAC and Serial Number in their transmitted messages forming a

For EPIRBs this value is 33 seconds.

4-5

unique beacon ID. However, SGBs may also contain additional vessel identification information (analogous to coding protocols in FGBs) as a secondary identity field. TAC Number – The Type Approval Certificate number between 10,000 and 17,999 assigned to the beacon by the Secretariat excluding the suffixes ‘M’ and ‘m’, see document C/S T.021 Section 2.2.1 for further details. Serial Number – A numerical serial number between 0 and 16,383 assigned by the beacon manufacturer to a beacon during production. The TAC and Serial Number together form a unique identity for each beacon produced and shall not be capable of being changed once programmed by the manufacturer. Once a manufacturer uses up all available serial numbers, they shall apply to the Secretariat for an Extension TAC in order to continue inserting a unique identity into every beacon that they produce. Identities shall never be reused, if for example a beacon is scrapped, then that identity is not reused. Country Code – The three-digit decimal country code based on the ITU MID related to the country of beacon registration, or the normal place of residence of the beacon owner. Note that the Country Code is not necessarily the same as the first 3 digits of the Maritime Mobile Service Identity (MMSI) that may be assigned to a beacon associated with a vessel. The country code may be changed as necessary during the life of a beacon to reflect changes of beacon registration or place of residence. Vessel ID – If a Vessel (Aircraft or Ship) Identity is available / known then it should be included in the beacon message using one of the following options: SHIPS – In addition to the TAC and Serial Number ships may also be coded with either the MMSI of the vessel or its Radio Call Sign, with preference being given to the former. If neither are available then these fields are set to default values. MMSI – An identity allocated to a beacon associated with a vessel in accordance with Recommendation ITU-R M.585. This may be the MMSI assigned to a ship station as defined in ITU-R M.585 Annex 1 Section 1 or the MMSI assigned to a craft associated with a parent ship as defined in ITU-R M.585 Annex 1 Section 5. It shall not be the freeform number identity as defined in ITU-R M.585 Annex 2 Section 2, commencing with 970, 972 or 974 which is only used to identify an AIS locating signal transmitter if one is included as part of a 406 MHz beacon. However, if the beacon includes an AIS locating signal, then the AIS identity commencing with 974 should be added in bits 94-123 AFTER the ships MMSI. Note that if during the life of a beacon a vessel on which it is provided changes flag state and as a result is allocated a different MMSI, then the MMSI in the beacon must be updated accordingly. This will not affect the identity of the AIS locating signal, however, as this is not linked to the vessel identity.

4-6

Radio Call Sign – If an MMSI for the vessel is not available then the ships Radio Call Sign may be inserted here instead. Radio Call Signs of up to 7 characters may be inserted. AIRCRAFT – In addition to the TAC and Serial Number aircraft may also be coded with one of three forms of identity, either the Aircraft Registration Marking (commonly referred to as the Tail Number), the Aviation 24-Bit Address (as used by the ADS-B system) or the Aircraft Operator designator followed by a serial number. The Aviation 24-Bit Address may also be followed by the 3-letter Aircraft Operator Designator (3LD), which is essential for ELT(DT)s. Aircraft Registration Marking – This identity, often referred to as the aircraft Tail Number can be encoded in up to 7 alphanumerical characters. Aviation 24-Bit Address – This identity is becoming more common in larger aircraft as it is allocated to an aircraft for use with systems such as the ADS-B. For ELT(DT)s required to meet the Automatic Distress Tracking (ADT) requirements of the ICAO GADSS system, it is essential to code the ELT(DT) with the aircraft 24-Bit address followed by the 3-letter Aircraft Operator Designator, as both of these data items are required by the ICAO Location of an Aircraft in Distress Repository (LADR). Note that the Aircraft 24-Bit address followed by the Aircraft Operator Designator can also be used to code ELTs other than ELT(DT)s if required. Aircraft Operator and Serial Number – This identity is less common but can be used to identify an aircraft it consists of the identity of the aircraft operator followed by a serial number allocated to the beacon by the aircraft operator to create a unique identity for that aircraft. [Other message fields not currently described include: • Status of Homing Device • RLS Function • Test Protocol • Encoded GNSS Location • Beacon Type] 4.3.4.2 Rotating Fields [Text in this section is still under development.] 4.3.5 SGBs and Programming Adaptors [Text in this section is still under development.] [Key features to describe include:

4-7

• SGB programming adaptors are controlled by C/S requirements, • SGB programming adaptors do not program the beacons, they simply provide ID data which supersedes the identity information in the beacon when it is connected to the beacon and is used in transmitted messages (which is a different paradigm than used with FGBs), • Use of PA requires two registrations, one of the adaptor related beacon ID and also the ID associated with the beacon model the adaptor can be used with] 4.3.6 SGBs Message Format for Transmission in the Ground Segment A SGB message consist of 250 bits which does not divide by four to form an even hexadecimal number and therefore two leading 0’s are added to “round” out to an even number of Hexadecimal characters. When displaying a message as 63 hex characters, one bit is inserted at the beginning of the message to indicate the PRN sequence (0 = Normal, 1 = self-test), followed by one zero, to form the 63 hexadecimal representation (2 bits + 250 bit message) for processing by the Cospas-Sarsat ground segment. 4.4 SGB Coding Examples 4.4.1 EPIRBs [Text in this section is still under development.] 4.4.2 ELTs [Text in this section is still under development.] 4.4.3 ELT(DT)s [Text in this section is still under development.] 4.4.4 PLBs [Text in this section is still under development.] – END OF SECTION 4 –

5-1

BEACON REGISTRATION 5.1 Purpose of Beacon Registration One of the advantages of 406 MHz beacons is that each beacon is designed to transmit a unique message allowing its identification. However, to take advantage of this feature, a register is needed to relate each beacon to a particular ship, aircraft or individual user. Beacon registration is valuable for the resolution of SAR cases. Identification of the beacon user (ship, aircraft or individual user) helps SAR services to properly respond to a distress alert provided that the registration database contains the information listed below in section 5.2. This information provides important search planning data to allow the timely rescue of people in distress. Registration information also helps to resolve false alerts without diverting SAR resources. All 406 MHz beacons (EPIRBs, ELTs or PLBs) should, therefore, be registered. Every administration requiring or allowing the use of 406 MHz beacons should make suitable arrangements for the registration of 406 MHz beacons, and enforce their registration. 5.2 General Principals for Registering 406 MHz Beacons 5.2.1 Where to Register 406 MHz Beacons The International Maritime Organization (IMO) and the International Civil Aviation Organization (ICAO) require that administrations authorising the use of 406 MHz beacons on board vessels and aircraft make provisions for registering these beacons in a database register that is accessible by SAR services 24 hours a day. The administrative and operational contact details for national 406 MHz beacon registers that have been reported to Cospas-Sarsat are published respectively in the following Cospas-Sarsat documents, which can be downloaded free of charge from the Cospas-Sarsat website at www.cospas-sarsat. int: • "Handbook of Beacon Regulations” (C/S S.007); • "Cospas-Sarsat Data Distribution Plan” (C/S A.001). Beacon owners should first consult the Cospas-Sarsat website to determine whether a national registration service exists in which they can register their beacons. For beacon owners in countries that do not operate national registers, Cospas-Sarsat has implemented an International 406 MHz Beacon Registration Database (IBRD). The IBRD is provided solely for the purpose of assisting SAR Services in SAR operations and is not intended to fulfil the obligation of National Administrations, as required by IMO or ICAO. A more detailed description of the IBRD is provided at Section 5.3.

5-2

5.2.2 Country of Registration – Coding Procedure As the administration authorising the use of the beacon does not always maintain a beacon registration database but could, alternatively, use the service of another administration or the IBRD, the country code in the 406 MHz beacon message must provide a link that identifies the operator of the database (i.e., the operator of the national database where the records are held). The country code should always enable SAR services to retrieve pertinent registration data through the point of contact associated with that country code, either the IBRD (if the country has chosen to use the IBRD for registration of beacons with their country codes), or the national registration facility. If a registration database is implemented and maintained regionally by agreement between several countries, the administration of the country of registration should arrange with Cospas-Sarsat and appropriate SAR authorities that its country code be recognised as one associated with that particular database, and provide information about such arrangements to the beacon owner. 5.2.3 Control and Updating of Registered Information Administrations should provide the means for beacon owners to readily and expeditiously update information in the registration database. Owners of beacons are responsible for reporting any change in the registered information, including: • de-registration of the beacon in the case of a change of ownership, or • indicating if the beacon has been stolen or permanently removed from service. Administrations should also regularly verify the accuracy of the database information by contacting the beacon owners. A census of registered 406 MHz beacons should be undertaken by administrations at least every two years. Administrations should also require a check of the beacon registration during mandatory periodic inspections of the beacon. Authorities maintaining or using databases should ensure that information supplied for beacon registration is treated as proprietary, and ensure that it is used only by appropriate recognised authorities. Specific guidance for updating registration information contained in the IBRD is provided at Section 5.3.2. 5.2.4 Access to Registration Databases Administrations maintaining registration databases should provide the means for SAR services to obtain relevant information on a 24 hour, seven day per week basis. Beacon registration information contained in the IBRD can be accessed by SAR services on a 24 hour basis via the Internet. SAR services requiring a password to access the IBRD should submit requests to Cospas-Sarsat via their Representative to either IMO, ICAO or the Cospas-Sarsat Programme.

5-3

5.2.5 Content of National Registration Databases It is desirable that the appropriate information from Tables 5.1, 5.2 and 5.3 be recorded in beacon registration databases or in other appropriate registers and be made available to SAR services in case of distress alerts. Examples of beacon registration cards are provided in the document C/S S.007 “Handbook of Beacon Regulations”, which is semi-annually updated by the Cospas-Sarsat Secretariat. 5.2.6 Accuracy of Beacon Identification (15 / 23 Hex ID) It is critical that the beacon’s 15 or 23 Hex ID (C/S T.001 beacons use a 15 Hex ID, C/S T.018 beacons use a 23 Hex ID) is correctly entered in the registration database as any mismatch between the data encoded into the beacon and that in the database may delay a rescue or provide misleading information to SAR services. Before proceeding, Administration involved in the registration, such as beacon maintenance facilities or beacon register operator, should be requested and recommended to check and verify the correct programming of the beacon. Errors may result in a mismatch in a number of ways, but the most common come from misreading the 15 / 23 Hex ID and entering an incorrect 15 / 23 Hex ID into the database, for example, entering a letter ‘D’ as an ‘0’ or a letter ‘B’ as an ‘8’. In order to reduce such data entry errors, a checksum for T.001 compliant beacons has been implemented on the IBRD and some national registration databases and is under development or implemented for T.018 compliant beacons, whereby the beacon manufacturer calculates and provides a 5 digit checksum, which is checked during registration data entry to identify possible input errors. Provision of the beacon registration checksum by manufacturers, though not required, is strongly encouraged. Guidelines on the use of the beacon registration checksum are provided in Annex D. 5.3 Cospas-Sarsat International 406 MHz Beacon Registration Database (IBRD) (www.406registration.com) The IBRD is hosted on the Internet at www.406registration.com. It provides beacon owners who do not have access to national registration facilities the capability to register their beacons or have their beacons registered on their behalf. The IBRD has been configured as follows: registrations will not be accepted for beacon type(s) with country codes of countries that have advised Cospas-Sarsat that they operate national registers; registrations of beacon type(s) will be accepted only from the designated national representative (the National Data Provider) in countries that have informed Cospas-Sarsat that they will use the IBRD, but want to control the entry of registration data at a national level; and registrations of beacon type(s) will be accepted directly from beacon owners via the Internet, if neither a) nor b) apply.

5-4

For direct registration by the beacon owner (paragraph (c) above), the IBRD provides a web based user friendly interface in English, French, Russian and Spanish languages that makes registering new beacons and updating existing registration information both quick and easy. The application includes extensive online help features that answer most of the common questions that arise during the registration process. For issues not addressed in the online help, users can also send questions directly to the Database Administrator via Email. 5.3.1 IBRD Management Policy Cospas-Sarsat policy regarding the operation and management of the IBRD is contained in the document C/S D.004, "Operations Plan for the Cospas-Sarsat International 406 MHz Beacon Registration Database”, which is available at www.cospas-sarsat.int. Users of the IBRD are encouraged to read this document in its entirety. As a minimum IBRD users and potential users should be aware of the following: The content of registration information stored in the IBRD is the responsibility of the person, organisation, or Administration that provides the information. Cospas-Sarsat does not accept any responsibility or liability in respect of the accuracy of registration information submitted by users. Cospas-Sarsat will only accept beacon registrations submitted via the online facilities provided by the IBRD. Beacon registrations submitted in paper format or via other communication facilities will not be accepted. Cospas-Sarsat will not modify beacon registration information, unless absolutely essential to repair a problem that, if not corrected, could damage the system or corrupt the database. Cospas-Sarsat will implement procedures to avoid where possible the loss or corruption of beacon registration data in the IBRD. Nevertheless, Cospas-Sarsat will not accept responsibility for any loss or corruption of registration information that may occur. Cospas-Sarsat will not provide facilities in the IBRD to accommodate or enforce national requirements nor provide guidance on matters that fall within the jurisdiction of national administrations (e.g., will not limit the coding options accepted by the IBRD based on specific requirements established at the national level, will not recommend specific beacon models for use, will not identify which beacon models are authorised by specific national administrations, etc.). The IBRD was developed to improve the effectiveness of Cospas-Sarsat alert data, and is offered for use “as provided”. Cospas-Sarsat will support the operation of the IBRD on a best effort basis, but provides no guarantee in respect of its availability or performance. The IBRD includes security features that limit the release of registration data to SAR services. Nevertheless, Cospas-Sarsat will not be responsible for unauthorised

5-5

access or unauthorised changes to registration data which may result from malicious activities. Cospas-Sarsat, on a best effort basis, will respond to requests for assistance by Administrations, SAR services and beacon owners. Support services provided by Cospas-Sarsat will only be offered during normal working hours, and subject to the availability and workload of the staff operating the database. 5.3.2 Updating Registration Information in IBRD When a beacon is initially entered in the IBRD, a password is created that provides access to the person / organisation that entered the registration information. This password is needed for updating registration details as circumstances change. As a minimum, the registration data provider should update the beacon registration every two years. If data registered in the IBRD with a particular country code is under the exclusive control of the Administration acting as the National Data Provider (section 5.3 (b)), then it is the sole responsibility of that Administration to update registration data for all beacons with its country code. Registration reminder notices are automatically sent by email to the email address provided in the beacon's registration record. It is thus very important that this email address be accurate and current. According to Annex 10 of ICAO’s Chicago Convention, a valid email address is mandatory to register an ELT.

5-6

Table 5.1: Example of Basic Information to be Recorded and Made Available through Beacon Registration PLB ELT EPIRB Beacon Identification (15 Hex ID *) Full length (22/30 Hex) message with default position bits Name of owner/ organization email address Name, address and phone number of emergency contact person Alternative 24-hour emergency phone number Town, city of residence or base Any critical personal information Beacon Identification (15 Hex ID*) Full length (22/30 Hex) message with default position bits Aircraft registration number/ name of aircraft operator email address Name, address and phone number of emergency contact person Alternative 24-hour emergency phone number Type of aircraft, colour, aircraft marking Capacity for persons on board (passengers, crew) Home base Emergency equipment Navigation/communication equipment Beacon Identification (15 Hex ID*) Full length (22/30 Hex) message with default position bits Name of vessel/ call sign/MMSI email address Name, address and phone number of emergency contact person Alternative 24-hour emergency phone number Brief vessel description † Capacity for persons on board (passengers, crew) Home port Ship radio installation (see Table 4-3)

Beacon Identification (Beacon 15 Hex ID) - the 15 hexadecimal characters that uniquely identify each 406 MHz beacon. This Beacon Identification is derived from bits 26 to 85 of the 406 MHz beacon message. For location protocols, the position data in the first protected data field (PDF-1) is set to specified default values to obtain the unique Beacon 15 Hex ID. † A brief vessel description may include:

Length of vessel - Vessel type (see Table 5.2)
Hull colour
Hull type (see Table 5.2)
Superstructure colour
Propulsion (see Table 5.2). Examples of ship descriptions are given hereunder: Example A Bulk carrier, 270 metres in length, black hull, white superstructure. Example B Stern trawler, 52 metres in length, green hull, grey superstructure. Example C Sail boat, 21 metres in length, double hull, single mast, white hull and superstructure. Example D Fishing vessel, 30 metres in length, superstructure aft, red hull and buff superstructure.

5-7

Table 5.2: Example of Ship Categories for Database Description Vessel Type Hull Tug Single hull General cargo Double hull Bulk carrier Triple hull Tanker Container Passenger Fishing Ferry Pleasure craft Government Drilling platform Ro-ro Other Propulsion Sail Power Single mast Inboard Two mast Outboard Three mast Inboard/Outboard Table 5.3: Example of Ship Radio Installation Description Inmarsat - A / B / M Inmarsat - C VHF with DSC / UHF HF MF with DSC 9 GHz Radar Transponder – END OF SECTION 5 –

6-1

406 MHz BEACON TYPE APPROVAL 6.1 Objectives and Scope of Type Approval The issuing of performance requirements, carriage regulations and the testing and type approving of 406 MHz distress beacons are the responsibilities of national authorities. However, to ensure beacon compatibility with Cospas-Sarsat Space Segment and Ground Segment equipment, it is essential that beacons meet specified Cospas-Sarsat performance requirements. Compliance with these requirements provides assurance that the tested beacon performance is compatible with, and will not degrade, the Cospas-Sarsat System. The Cospas-Sarsat type approval tests are designed to ensure that the signals transmitted by the beacons and their coding meet all applicable requirements of the Cospas-Sarsat specification for 406 MHz distress beacons (document C/S T.001, C/S T.015 or C/S T.018). These tests primarily measure the electrical characteristics of beacon transmissions on 406 MHz and, with the exception of temperature, do not take into account environmental conditions the beacon may encounter during normal use. In addition to the Cospas-Sarsat requirements, there might be other requirements (e.g., radio- locating, environmental, activation, etc.) that administrations and/or International Organizations may specify. Although a Cospas-Sarsat beacon must always be tested according to its normal operating mode (i.e. with auxiliary devices in operation), the control of the performance of these additional devices is not part of the Cospas-Sarsat testing requirements. Testing to ensure proper operation of such additional features, under the required environmental conditions, is the responsibility of the national authorities. 6.2 Cospas-Sarsat Type Approval Testing In order to ensure that beacons do not degrade the System and to ensure uniformity of testing, Cospas-Sarsat has defined the necessary tests and overall procedure which a manufacturer must follow to receive Cospas-Sarsat type approval (document C/S T.007 “Cospas-Sarsat 406 MHz Distress Beacon Type Approval Standard” or document C/S T.021 “Cospas-Sarsat Second Generation 406 MHz Distress Beacon Type Approval Standard”). The tests described in C/S T.007 or C/S T.021 consist of a series of indoor laboratory tests in which the beacon does not transmit to the satellite, and an outdoor functional test of the beacon transmitting to the satellite. Cospas-Sarsat type approval testing must be performed by a Cospas-Sarsat accepted test facility. The Cospas-Sarsat Secretariat maintains a list of such test facilities. The beacon manufacturers should submit for Cospas-Sarsat type approval testing beacons coded with a test protocol of appropriate type and format. All protocol types intended for use with the beacon should be verified. The verification of the different coding options within each type is not

6-2

required. However, sample messages should be provided for each applicable coding protocol as required by C/S T.007 or C/S T.021. 6.3 Cospas-Sarsat Type Approval Certificate After successful completion of Cospas-Sarsat type approval testing, the test report and other technical documentation (as specified in C/S T.007 or C/S T.021) is submitted to the Secretariat. A Cospas-Sarsat type approval certificate (TAC) will be issued to the beacon manufacturer by the Cospas-Sarsat Secretariat, after review and approval of the test results by Cospas-Sarsat. TAC numbers will be issued only in the following cases: • type approval of new beacon models, • significant changes to an approved beacon model that has been retested at an accepted test facility, and • the need for additional serial numbers to encode a unique identification with the Standard Location Protocol, provided that the capacity of all possible serial numbers associated with previously assigned TAC numbers was fully used. Should it be demonstrated subsequently that the production models do not meet the same standard as the type approved model, Cospas-Sarsat reserves the right to revoke the certificate. 406 MHz beacons that have received Cospas-Sarsat type approval are listed on the Cospas-Sarsat web-site at: www.cospas-sarsat.int 6.4 National Type Approval Cospas-Sarsat encourages national administrations to adopt national requirements (e.g., radio- locating, environmental, activation, etc.) for 406 MHz beacons. National administrations should also consider requirements which may contribute to reducing false alerts such as: • visual/audio indicators; • 2 step activation mechanism; and • including a description of testing procedures in the beacon user manual. Depending on the intended use of the beacon, administrations should also consider the recommendations of international organizations (e.g. IMO, ICAO, ITU, etc.). Administrations are urged to harmonise their requirements with those defined by other administrations or international organizations.

6-3

Administrations are urged to test beacons to the full requirements, or accept type approval results from other administrations, and to only approve beacons for use that have received Cospas-Sarsat type approval and passed all national type approval testing. – END OF SECTION 6 –

7-1

GENERAL GUIDELINES TO ADMINISTRATIONS, MANUFACTURERS AND DISTRIBUTIONS 7.1 Guidelines to Administrations 406 MHz beacon coding protocols have been developed to satisfy maritime (EPIRB), aeronautical (ELT) and personal (PLB) applications. Regardless of the application or protocol used, the creation and maintenance of a registration database is very important. Administrations are responsible for the definition and control of beacon identifications registered in their national databases. All measures should be undertaken to avoid possible duplication of beacon identifications. Using the Cospas-Sarsat type approval certificate number may help ensure that the serial number assigned by a manufacturer provides a unique beacon 15 Hex ID, independent of the country of registration indicated by the country code. When a beacon 15 Hex ID is assigned by the national administration of the country designated by the country code, bit 43 can be set to “0” and the content of bits 44 to 83 redefined as required. However, in that case, the national administration must ensure that the beacon 15 Hex ID is unique. In selecting the best coding protocol, administrations should consider: • whether harmony with beacon coding for other applications is desirable, where national SAR systems support other than just one user community (maritime/aviation/PLBs); • what protocol is already in common use; • availability of useful emergency information; • timely availability of up-to-date registration data; • ability to forward automatically to RCCs information from the database together with 406 MHz alerts; • ease and timeliness of updating registration database information; • beacon cost; • ease of beacon replacement world-wide; • ease of re-coding beacons, if required; • availability of extra bits in the protocol for national use, if required; and • that the location protocols which can be used for encoding beacon position data, as well as the beacon identification data, provide for 406 MHz GEOSAR alerts with beacon location information not otherwise available.

7-2

Having selected the appropriate protocol, administrations should: • become well informed on the unique capabilities of the various 406 MHz beacon types and select those for use which best support their national requirements; • promulgate clear and timely guidance to manufacturers and owners on coding and registration procedures; • ensure that reliable means are provided for automatic or fast access to database information for SAR authorities; • cooperate with other administrations, manufacturers, owners and organizations to help resolve any registration or information retrieval problems that may arise; • disseminate procedures via ICAO, IMO, Cospas-Sarsat, Inmarsat and other service providers on how beacon registration database information can be obtained by SAR services, and inform the Cospas-Sarsat Secretariat of the details of their point of contact for 24 hour access to registered information (telephone, facsimile, telex numbers); • encourage manufacturers and distributors to advise customers, upon purchase of properly coded beacons, about registration requirements, and refer unresolved coding and registration issues to proper national authorities for resolution; and • encourage manufacturers and distributors to educate users about the maintenance of beacons. In order to ensure that 406 MHz beacons are correctly coded and registered, administrations should make arrangements for periodic testing and on-board inspection of beacons. Periodic testing or inspection should include a check of the beacon coding and a verification of appropriate beacon registration. 7.2 Guidelines to Manufacturers and Distributors Beacon manufacturers and distributors are an important part of the coding and registration process. They should ensure that a beacon is properly coded to meet the requirements of the administration authorising its use. In addition, they should inform the beacon owner of the requirements of the registering administration as a part of the instruction material provided with the beacon. In order to facilitate the examination of beacon coding and registration during periodic beacon testing or inspections, beacon manufacturers should make provisions to ensure that the beacon 15 Hex ID, together with the hexadecimal presentation of the full length beacon message are adequately displayed on the exterior of the beacon. For location protocol beacons, the 15 Hex ID and full length beacon message displayed should correspond to position data set to default values. Manufacturers/distributors should cooperate with administrations in all countries where their products are introduced to implement coding and registration procedures. Coding beacons for export is a particular concern. Improper coding and registration of beacons limit the effectiveness of the System.

7-3

On selling a beacon, manufacturers or distributors should: determine the identity of the administration authorising its use; provide the user with a beacon that meets the requirements of the authorising administration; provide beacon registration guidance to the owner; inform the owner of his responsibilities regarding registration; comply with administration registration requirements imposed upon the manufacturer; and provide beacon maintenance advice to the user. Manufacturers/distributors should be aware that the use of some kinds of 406 MHz beacons are not authorised in a number of countries. Manufacturers should refer unresolved beacon coding and registration issues to the proper national authorities for resolution. – END OF SECTION 7 –

ANNEXES TO THE COSPAS-SARSAT GUIDELINES ON 406 MHz BEACON CODING, REGISTRATION AND TYPE APPROVAL

A-1

ANNEX A: EXAMPLES OF 406 MHz BEACON CODES

Maritime User Protocol with MMSI Bit Field Name Content Bit Field Bits Location Message Format: Short Message

Protocol Flag: User Protocol

Country Code: 257 Norway 27-36

User Protocol Type: Maritime 37-39

Trailing 6 digits of the Ship Station Identity (modified-Baudot code):

40-75

Specific EPIRB:

76-81

Spare: Not Used 82-83

Radio-locating: 121.5 MHz 84-85

BCH-1: 21-bit BCH Code 86-106

Emergency Code Flag: Not Used

Beacon Activation: Manual Only

Emergency/National Code or National use data: Not used 109-112

Beacon 15 Hex ID (bits 26 to 85): A029C 2900D 97591 406 MSG (Short) (bits 25 to 112): 5014E 14806 CBAC8 D2DAA 00 Bits 25 26 27 36 37 40 75 76 81 83 85 ───┼─┼─┼──────────┼─┬─┬─┼────────────────────────────────────┼──────┼─┬─┼─┬─┼─ │0│1│0100000001│0│1│0│011100001010010000000011011001011101│011001│0│0│0│1│ ───┴─┴─┴──────────┴─┴─┴─┴────────────────────────────────────┴──────┴─┴─┴─┴─┴─ Bits 86 112 ────┼───────────────────────────┼─ │101001011011010101000000000│ ────┴───────────────────────────┴─

A-2

Radio Call Sign User Protocol (radio call sign includes 2 of maximum 3 last characters (digits)) Message Format: Short Message Protocol Flag: User Protocol Country Code: 219 Denmark User Protocol Type: Radio Call Sign Radio Call Sign: XPAO2 Specific EPIRB:

Radio-locating: 121.5 MHz Emergency/National Use: Not Used Beacon Activation: Automatic or Manual Beacon 15 Hex ID (bits 26 to 85): 9B7B7 B788C AA9D1 406 MSG (Short) (bits 25 to 112): 4DBDB DBC46 554E8 C8BD7 10 Bits 25 26 27 36 37 40 63 64 75 76 81 83 85 ───┼─┼─┼──────────┼─┬─┬─┼────────────────────────┼────────────┼──────┼─┬─┼─┬─┼─ │0│1│0011011011│1│1│0│110111101101111000100011│001010101010│011101│0│0│0│1│ ───┴─┴─┴──────────┴─┴─┴─┴────────────────────────┴────────────┴──────┴─┴─┴─┴─┴─ Bits 86 112 ────┼───────────────────────────┼─ │100100010111101011100010000│ ────┴───────────────────────────┴─ 3) ELT Serial Identification Message Format: Short Message Protocol Flag: User Protocol Country Code: 503 Australia User Protocol Type: Serial Beacon Type: Aviation Serial Number:

National Use Bits:

Radio-locating: 121.5 MHz Emergency/National Use: Not Used Beacon Activation: Automatic or Manual Beacon 15 Hex ID (bits 26 to 85): BEEC0 358DC 00001 406 MSG (Short) (bits 25 to 112): 5F760 1AC6E 00000 E4A09 10 Bits 25 26 27 36 37 40 44 63 64 73 74 83 85 ───┼─┼─┼──────────┼─┬─┬─┼─┬─┬─┬─┼────────────────────┼──────────┼──────────┼─┬─┼─ │0│1│0111110111│0│1│1│0│0│0│0│00001101011000110111│0000000000│0000000000│0│1│ ───┴─┴─┴──────────┴─┴─┴─┴─┴─┴─┴─┴────────────────────┴──────────┴──────────┴─┴─┴─ Bits 86 112 ────┼───────────────────────────┼─ │110010010100000100100010000│ ────┴───────────────────────────┴─

A-3

Aircraft Nationality and Registration Marking (marking includes 5 of maximum 7 alphanumeric characters) Message Format: Short Message Protocol Flag: User Protocol Country Code: 316 Canada User Protocol Type: Aviation Aircraft Registration Marking: C7518 ELT Number: 0 (First ELT) Radio-locating: 121.5 MHz Emergency/National Use: Emergency Code On Beacon Activation: Manual Only Nature of Distress: No Fire, Medical Help Required, Disabled Beacon 15 Hex ID (bits 26 to 85): A7864 92E70 174C1 406 MSG (Short) (bits 25 to 112): 53C32 49738 0BA60 FD0F5 26 Bits 25 26 27 36 37 40 81 83 85 ───┼─┼─┼──────────┼─┬─┬─┼──────────────────────────────────────────┼─┬─┼─┬─┼─ │0│1│0100111100│0│0│1│100100100100101110011100000001011101001100│0│0│0│1│ ───┴─┴─┴──────────┴─┴─┴─┴──────────────────────────────────────────┴─┴─┴─┴─┴─ Bits 86 112 ────┼───────────────────────────┼─ │111110100001111010100100110│ ────┴───────────────────────────┴─
Personal User Protocol Message Format: Short Message Protocol Flag: User Protocol Country Code: 273 Russia User Protocol Type: Serial Beacon Type: Personal Locator Beacon Serial Number:

National Use Bits:

Radio-locating: 121.5 MHz Emergency/National Use: Not Used Beacon Activation: Manual Only Beacon 15 Hex ID (bits 26 to 85): A22F0 35044 00001 406 MSG (Short) (bits 25 to 112): 51178 1A822 00000 BB4E2 C0 Bits 25 26 27 36 37 40 44 63 64 73 74 83 85 ───┼─┼─┼──────────┼─┬─┬─┼─┬─┬─┬─┼────────────────────┼──────────┼──────────┼─┬─┼─ │0│1│0100010001│0│1│1│1│1│0│0│00001101010000010001│0000000000│0000000000│0│1│ ───┴─┴─┴──────────┴─┴─┴─┴─┴─┴─┴─┴────────────────────┴──────────┴──────────┴─┴─┴─ Bits 86 112 ────┼───────────────────────────┼─ │011101101001110001011000000│ ────┴───────────────────────────┴─  Effective as of 1 November 2011.

A-4

Test User Protocol Message Format: Short Message Protocol Flag: User Protocol Country Code: 725 Chile User Protocol Type: Test Binary Data Field:

Radio-locating: None Emergency/National Use: Not Used Beacon Activation: Manual Only Beacon 15 Hex ID (bits 26 to 85): DABFE 0F83E 0F83C 406 MSG (Short) (bits 25 to 112): 6D5FF 07C1F 07C1E 02121 C0 Bits 25 26 27 36 37 40 83 85 ───┼─┼─┼──────────┼─┬─┬─┼────────────────────────────────────────────┼─┬─┼─ │0│1│1011010101│1│1│1│11111000001111100000111110000011111000001111│0│0│ ───┴─┴─┴──────────┴─┴─┴─┴────────────────────────────────────────────┴─┴─┴─ Bits 86 112 ────┼───────────────────────────┼─ │000001000010010000111000000│ ────┴───────────────────────────┴─

A-5

EPIRB Serial Identification User-location Protocol (Encoded position = 43 32' N, 1 28' E) Bit Field Name Content Bit Field Bits Location Message Format: Long Message

Protocol Flag: User Protocol

Country Code: 477 Hong Kong 27-36

User Protocol Type: Serial 37-39

Beacon type: Maritime (float free) 40-42

C-S Type approval Certificate Indicator: Type Approved

Serial Number:

44-63

National use: Not used 64-73

C/S Certificate No:

74-83

Radio-locating: 121.5 MHz 84-85

BCH-1: 21-bit BCH Code 86-106

Position Data Source: Internal

Latitude Flag: N

Latitude in Degrees:

109-115

Latitude in Minutes:

116-119

Longitude Flag: E

Longitude in Degrees:

121-128

Longitude in Minutes:

129-132

BCH-2: 12-bit BCH Code 133-144

Beacon 15 Hex ID (bits 26 to 85): BBAD5 EE4A4 00191 406 MSG (Long) (bits 25 to 144): DDD6A F7252 000C8 C236C A5700 17151 Bits 25 26 27 36 37 40 44 63 64 73 74 83 85 ───┼─┼─┼──────────┼─┬─┬─┼─┬─┬─┬─┼────────────────────┼──────────┼──────────┼─┬─┼─ │1│1│0111011101│0│1│1│0│1│0│1│01111011100100101001│0000000000│0001100100│0│1│ ───┴─┴─┴──────────┴─┴─┴─┴─┴─┴─┴─┴────────────────────┴──────────┴──────────┴─┴─┴─ Bits 86 106 109 119 121 132 133 144 ────┼─────────────────────┼─┼─┼───────────┼─┼────────────┼────────────┼ │100001000110110110010│1│0│01010111000│0│000000010111│000101010001│ ────┴─────────────────────┴─┴─┴───────────┴─┴────────────┴────────────┴

A-6

Standard Location Protocol with MMSI (Encoded position = 43 43' 56" N, 0 58'52"E)* Bit Field Name Content Bit Field Bits Location Message Format: Long Message

Protocol Flag: Location Prot.

Country Code: 257 Norway 27-36

Standard Protocol Type: EPIRB-MMSI 37-40

Trailing 6 digits of the Ship Station Identity (in binary form): 506153 41-60

Specific EPIRB (in binary form): 2 61- 64

Latitude Flag: N

Latitude in degrees:

66-72

Latitude in ¼ degree increment: ¾ 73-74

Longitude Flag: E

Longitude in degrees:

76-83

Longitude in ¼ degree increment: ¼ 84-85

BCH-1: 21-bit BCH Code 86-106

Fixed bits: 107-110

Position data provided by: external navig. device

121.5 auxiliary radio location device: yes

Latitude offset sign:

Latitude offset in min.:

114-118

Latitude offset in sec.:

119-122

Longitude offset sign:

Longitude offset in min.:

124-128

Longitude offset in sec.:

129-132

BCH-2: 12-bit BCH Code 133-144

Beacon 15 Hex ID (bits 26 to 85): 2024F 72524 FFBFF† 406 MSG (Long) (bits 25 to 144): 90127 B9292 2BC02 B4968 F5045 0220B Bits 25 26 27 36 37 41 60 64 66 74 76 85 ───┼─┼─┼──────────┼─┬─┬─┬─┼────────────────────┼────┼─┼─────────┼─┼──────────┼─ │1│0│0100000001│0│0│1│0│01111011100100101001│0010│0│010101111│0│0000000101│ ───┴─┴─┴──────────┴─┴─┴─┴─┴────────────────────┴────┴─┴─────────┴─┴──────────┴─ Bits 86 106 109 114 119 123 132 133 144 ────┼─────────────────────┼─┼─┼─┼───┼─┼─────┼────┼─┼─────┼────┼────────────┼ │011010010010110100011│1│1│0│101│0│00001│0001│0│10000│0010│001000001011│ ────┴─────────────────────┴─┴─┴─┴───┴─┴─────┴────┴─┴─────┴────┴────────────┴

This example uses the location protocol coding system defined in section A3.3.1 of document C/S T.001, Issue 3 - Revision 8 where the location encoded in PDF-1 may not be the closest to the actual location. This method of encoding will not be permitted after 1 November 2010, see Example 10 for an example of the current encoding method. † With default values for position data.

A-7

National Location Protocol (Encoded position = 43 31' 56'' N, 1 25'52''E)* Bit Field Name Content Bit Field Bits ` Location Message Format: Long Message

Protocol Flag: Location Prot. 26

Country Code: 257 Norway 27-36

National Protocol Type: EPIRB Serial 37-40

Serial Number:

41-58

Latitude Flag: N

Latitude in Degrees:

60-66

Latitude in Minutes:

67-71

Longitude Flag: E

Longitude in Degrees:

73-80

Longitude in Minutes:

81-85

BCH-1: 21-bit BCH Code 86-106

Fixed bits: 107-109

additional data flag: position data as defined by Cospas-Sarsat

Position data provided by: external navig. device

121.5 auxiliary radio location device: no

Latitude offset sign:

Latitude offset in min.:

114-115

Latitude offset in sec.:

116-119

Longitude offset sign:

Longitude offset in min.: 2 121-122

Longitude offset in sec.: 8 123-126

Additional Beacon type identification:

127-132

BCH-2: 12-bit BCH Code 133-144

Beacon 15 Hex ID (bits 26 to 85): 20341 500BF 81FE0 406 MSG (Long) (bits 25 to 144): 901A0 A804A E0017 69AC9 B4028 AA140 Bits 25 26 27 36 37 41 58 60 66 67 71 73 80 81 85 ───┼─┼─┼──────────┼─┬─┬─┬─┼──────────────────┼─┼───────┼─────┼─┼────────│─────┼─ │1│0│0100000001│1│0│1│0│000010101000000001│0│0101011│10000│0│00000001│01110│ ───┴─┴─┴──────────┴─┴─┴─┴─┴──────────────────┴─┴───────┴─────┴─┴────────┴─────┴─ Bits 86 106 109 116 123 127 133 144 ────┼─────────────────────┼─┼─┼─┼─┼──┼─┼──┼────┼─┼──┼────┼──────┼────────────┼ │110100110101100100110│1│1│0│1│00│0│00│0001│0│10│0010│101010│000101000000│ ────┴─────────────────────┴─┴─┴─┴─┴──┴─┴──┴────┴─┴──┴────┴──────┴────────────┴ 10) Standard Location Protocol with MMSI (Actual Location = 43 43' 56" N, 0 11’10” E) (Encoded position = 43 43' 56" N, 0 11’12” E)

This example uses the location protocol coding system defined in section A3.3.1 of document C/S T.001, Issue 3 - Revision 8 where the location encoded in PDF-1 may not be the closest to the actual location. This method of encoding will not be permitted after 1 November 2010, see Example 11 for an example of the current encoding method.  With default values for position data.

A-8

Bit Field Name Content Bit Field Bits Location Message Format: Long Message

Protocol Flag: Location Prot. 26

Country Code: 257 Norway 27-36

Standard Protocol Type: EPIRB-MMSI 37-40

Trailing 6 digits of the Ship Station Identity (in binary form):

41-60

Specific EPIRB (in binary form):

61-64

Latitude Flag: N

Latitude in degrees:

66-72

Latitude in ¼ degree increment: ¾ 73-74

Longitude Flag: E

Longitude in degrees:

76-83

Longitude in ¼ degree increment: ¼ 84-85

BCH-1: 21-bit BCH Code 86-106

Fixed bits: 107-110

Position data provided by: external navig. device

121.5 auxiliary radio location device: yes

Latitude offset sign:

Latitude offset in min.:

114-118

Latitude offset in sec.:

119-122

Longitude offset sign:

Longitude offset in min.: 3 124-128

Longitude offset in sec.: 48 129-132

BCH-2: 12-bit BCH Code 133-144

Beacon 15 Hex ID (bits 26 to 85): 2024F 724E4 FFBFF* 406 MSG (Long) (bits 25 to 144): 90127 B9272 2BC00 FF7B3 B5044 3CA54 Bits 25 26 27 36 37 41 60 64 66 74 76 85 ───┼─┼─┼──────────┼─┬─┬─┬─┼────────────────────┼────┼─┼─────────┼─┼──────────┼─ │1│0│0100000001│0│0│1│0│01111011100100100111│0010│0│010101111│0│0000000001│ ───┴─┴─┴──────────┴─┴─┴─┴─┴────────────────────┴────┴─┴─────────┴─┴──────────┴─ Bits 86 106 109 114 119 124 129 133 144 ────┼─────────────────────┼─┼─┼─┼───┼─┼─────┼────┼─┼─────┼────┼────────────┼ │111111101111011001110│1│1│0│101│0│00001│0001│0│00011│0010│101001010100│ ────┴─────────────────────┴─┴─┴─┴───┴─┴─────┴────┴─┴─────┴────┴────────────┴ 11) National Location Protocol (Actual Location = 43 42' 58'' N, 0 0' 58'' E) (Encoded position = 43 43' 0'' N, 0 1' 0'' E) Bit Field Name Content Bit Field Bits Location

With default values for position data

A-9

Message Format: Long Message

Protocol Flag: Location Prot. 26

Country Code: 257 Norway 27-36

National Protocol Type: EPIRB Serial 37-40

Serial Number:

41-58

Latitude Flag: N

Latitude in Degrees:

60-66

Latitude in Minutes:

67-71

Longitude Flag: E

Longitude in Degrees:

73-80

Longitude in Minutes:

81-85

BCH-1: 21-bit BCH Code 86-106

Fixed bits: 107-109

additional data flag: position data as defined by Cospas-Sarsat

Position data provided by: external navig. device

121.5 auxiliary radio location device: no

Latitude offset sign: +

Latitude offset in min.:

114-115

Latitude offset in sec.:

116-119

Longitude offset sign: +

Longitude offset in min.: 1 121-122

Longitude offset in sec.: 0 123-126

Additional Beacon type identification:

127-132

BCH-2: 12-bit BCH Code 133-144

Beacon 15 Hex ID (bits 26 to 85): 20341 500BF 81FE0* 406 MSG (Long) (bits 25 to 144): 901A0 A804A EA000 2F3B3 F4A14 2A843 Bits 25 26 27 36 37 41 58 60 66 67 71 73 80 81 85 ───┼─┼─┼──────────┼─┬─┬─┬─┼──────────────────┼─┼───────┼─────┼─┼────────│─────┼─ │1│0│0100000001│1│0│1│0│000010101000000001│0│0101011│10000│0│00000000│00000│ ───┴─┴─┴──────────┴─┴─┴─┴─┴──────────────────┴─┴───────┴─────┴─┴────────┴─────┴─ Bits 86 106 109 116 123 127 133 144 ────┼─────────────────────┼─┼─┼─┼─┼──┼─┼──┼────┼─┼──┼────┼──────┼────────────┼ │010111100111011001111│1│1│0│1│00│1│01│0000│1│01│0000│101010│100001000011│ ───┴─────────────────────┴─┴─┴─┴─┴──┴─┴──┴────┴─┴──┴────┴──────┴────────────┴

END OF ANNEX A –

With default values for position data.

B-1

ANNEX B: MODIFIED-BAUDOT CODE Table B.1: Modified-Baudot Code Letter Code MSB LSB Letter Code MSB LSB Figure Code MSB LSB A B C D E F G H I J K L M

N O P Q R S T U V W X Y Z

( )* ( - )** /

MSB: most significant bit

Space LSB: least significant bit ** Hyphen Note: The modified-Baudot code is used to encode alphanumeric characters in beacon messages.

END OF ANNEX B -

C-1

ANNEX C: BINARY CODED DECIMAL To encode a decimal number in the Binary Coded Decimal (BCD) format, each digit of the decimal number is encoded using a four bit binary pattern as illustrated below: For Example 127 is represented as: 1 2 7 0001 0010 0111 The following table represents the decimal numbers from 0 to 9 and the “space character” in BCD format authorized for use in the Radio Call Sign User protocol. Decimal Number BCD

“space character”

END OF ANNEX C -

D-1

ANNEX D: GUIDELINES ON THE USE OF THE BEACON REGISTRATION CHECKSUM National Administrations wishing to implement a beacon registration checksum should note the following guidance. • Beacon manufacturers should calculate the 5 character checksum based on the 15 or 23 hexadecimal Unique Identification Number (UIN) for serialized beacons. • The beacon manufacturer should include the 5 character checksum on the registration documentation that it provides to the first buyer of the beacon. Note that some national administration registration documents may not contain space for the checksum. The beacon manufacturer should not provide a checksum when the beacon manufacturer cannot determine the beacon ID in their factory (e.g., for EPIRBs containing a Maritime User Protocol – MMSI, or ELTs containing an Aircraft 24-bit address), as the beacon coding details are not known until the beacon is about to be installed on a specific aircraft or vessel. • The 5 character checksum should not be placed on the beacon itself only on the registration form provided with the beacon. • The Five Character Checksum should be implemented using the algorithm provided in Appendix 1. • Administrations that implement the checksum should ensure that the checksum is calculated correctly. Administrations may decide that checksums should only be generated by beacon manufacturers. If an Administration decides that the checksum should be implemented by distributors and service agents it should note that this may be difficult to achieve and regulate. • Administrations should not require the checksum to be computed for beacons already on the market.

D-2

Appendix 1 to Annex D - Implementation of Five Character Checksum for UIN The algorithm defined below produces a running sum using the ASCII decimal values for each character modified by arithmetic operations involving primary numbers. Intermediate results are directly truncated to avoid integer variable overflows, restricting all values within the positive range of values associated with standard 4 byte integers (0 to 2,147,483,647). The final result is also truncated to an integer of 20 bits or less, which yields the desired five hexadecimal characters. In the pseudo-code listing below the symbols (*, /, -, +) represent standard arithmetic operators of multiplication, division, subtraction and addition respectively, and inline comments follow the designator of //. // Initializations: ReturnLimit = 1048576 // used to limit the return value to a 20 bit result RunningSumLimit = 538471 // large prime which will not cause an overflow ConstPrimVal = 3911 // small prime value, stays constant throughout ModifierLimit = 3847 // small prime which will not cause an overflow Modifier = 3803 // modifier, simply initialized to a prime value RunningSum = 0 // holds the running value of the checksum // Main Computation: Loop for first (BcnIdLength – 1) hexadecimal characters in UIN, 1 to (BcnIdLength – 1): // incorporate a character into running checksum DecimalValue = ASCII decimal value of this character (See Table 1) TmpLongValue = (RunningSum * Modifier) + DecimalValue; TmpLongValue2 = TmpLongValue / RunningSumLimit; // whole number quotient RunningSum = TmpLongValue - (TmpLongValue2 * RunningSumLimit); // remainder // Compute next Modifier TmpLongValue = ConstPrimVal * Modifier; TmpLongValue2 = TmpLongValue / ModifierLimit; // whole number quotient Modifier = TmpLongValue - (TmpLongValue2 * ModifierLimit); // remainder End Loop // Process Final Character: DecimalValue = ASCII decimal value of this character (See Table 1) TmpLongValue = (RunningSum * Modifier) + DecimalValue; // Truncation to 20 Bits for final checksum value: TmpLongValue2 = TmpLongValue / ReturnLimit; // whole number quotient CheckSumValue = TmpLongValue - (TmpLongValue2 * ReturnLimit); // remainder The CheckSumValue, now 20 bits in length, is then translated to a 5 character hexadecimal representation by converting 4 bit blocks as per standard mechanisms (see Table D.2).

D-3

Table D.1: Translation of characters to ASCII Decimal Values Char Dec Char Dec Char Dec Char Dec

Table D.2: Standard Translation of 4 Bits Blocks to Hexadecimal Characters Bits Char Bits Char Bits Char Bits Char

F Table D.3: Example UIN Inputs and Resulting Checksums

UIN

Checksum 1 2DCC3FB834FFBFF 885BC 2 2DCC3FB858FFBFF AE919 3 ADCE089F7C4106D D31F8 4 ADCE08AA044006D B3066 5 ADCE08ABE84106D 56B73 6 ADCE08BC004086D 97A1D 7 ADCE08BC744006D

8 2DCC44328EFFBFF 93F7C 9 ADCE08958C4046D 3B7A0 10 ADCE0895A04046D 58C78 11 2DC8555076FFBFF A8163 12 ADCE08969C4046D 0D618 13 ADCE089A1C4006D EA65B 14 ADCE08B69C4106D 33ADA 15 ADCE08BB484106D 71DCF 16 2DCE4E1FE0FFBFF 9ADD3 17 2DCE4E17B8FFBFF 2DBC4 18 ADCC07FC0440401 F95BB 19 ADCC07FCB440401 F093A 20 ADCC07FCB840401 B539B 21 ADCE0884984046D BA05E 22 2DCC3FC806FFBFF AA605 23 2DCC445744FFBFF 3DA69 24 ADCD02355542801 2D88A 25 ADCD02354542801 7CC0C 26 ADF7DA6D7090000000F9129 2C019 27 9EF7DA6D709000000000000 BC494 28 ADF7DA6D7092E33BA475940 E1A38 29 A037DA6D7092937D7175940 25A20 30 B5F46E783F23924E9D65028 5052C 31 9977DA6D709000000000000 A3BEC

D-4

UIN

Checksum 32 ADF587AA62B157AE36DC552 6E036 33 A2F669AB2D930E18709B40C 47E37 34 ADF68E50F4B47C5D5700000 6AAD4 35 99B49C6B4E9444914B00000 620B8 36 A794B4C00872E33B9D64A04 1A5E4 37 CF559BC97704D7B87B00000 428B0 38 9E15CA4E9DA396A62CB83D0 CC69C 39 AF54F301DC75A77F98D3FFF 73526 40 A2D7691BC1714264B696523 C1D43 41 9D149C6C22B38E39A5C5774 09F64 42 CCB7EA73355000000000000 C79D4 43 9A7400030395CB3D62BBFFF F9B02 44 9A749FFF0395CB3D62BBFFF 54092 45 A794CEE960B2C2C54DA6AB8 5351C 46 9C55E7DC0172F33D7E75974 CE074 47 9A14A18EEE82CA363DE6DE4 A66B4 48 CF54D901AF93FA6EAD72B90 4B93C 49 CE1631B32394C147FA00000 34D44 50 BB34CB138F5000000000000 53BA8

END OF ANNEX D -
END OF DOCUMENT –

Cospas-Sarsat Secretariat 1250 René-Lévesque Blvd. West, Suite 4215, Montreal (Quebec) H3B 4W8 Canada Telephone: +1 514 500 7777 Fax: +1 514 500 7996 Email: mail@cospas-sarsat.int Website: http://www.cospas-sarsat.int

193 KiB Raw Blame History Unescape Escape

As Defined in C/S T.018 (46 bits) Notes: RL

C/S Type Approval Certificate Flag: "1" C/S Type Approval Certificate number encoded in bits 74 to 83 "0" other national use F

68-75 76 77-85 86-106 107-114 115-117 118-132 133-144 Flag Lat Lat degr Flag Long Long degr 21-bit BCH code Suppl. Data PDF-2 Rotating Field Type PDF-2 Rotating Field 12-bit BCH code

bits 113 to 114: “00”: PDF-2 rotating field indicator

bit 115 to 117: PDF-2 Rotating Field Type “000”: Aircraft Operator 3LD Other: Spare

UIN

UIN

193 KiB

Raw Blame History