SECOND GENERATION BEACON HEX ID OPTIONS

Transcription

1 Cospas-Sarsat Task Group Meeting TG-1/2014/6/7 Second Generation Beacon Specifications Origin: RTCM February 2014 Date: 13 January 2014 Agenda Item 6.1 SECOND GENERATION BEACON HEX ID OPTIONS 1. ACTION REQUIRED The Task Group is invited to: a) consider the proposed Second Generation Beacon unique identity coding schemes proposed herein; and b) recommend inclusion of a preferred coding method within C/S T.X01 at JC BACKGROUND Message Coding of Second Generation Beacons (SGBs) has been the subject of a number of papers and much discussion at recent Experts Working Group and Joint Committee meetings. Most recently the matter was discussed at JC-27 and the outcome of those discussions are contained in sections to of the JC-27 Report. This paper is however only concerned with one specific aspect of message coding of SGBs, that being the Beacon Unique Identity (BUI). In order to differentiate between 406 MHz beacons it is essential that every beacon in the world has its own unique identity. For current First Generation Beacons (FGBs) this is achieved by the use of a 15 Hex ID as defined in C/S T.001 Section 3.2. For SGBs it is again essential that every beacon has a BUI and that this BUI is different to any of those used by FGBs. It has been proposed that every SGB should contain a unique identity that remains with the beacon for its entire lifetime (i.e. a unique serial number) and that this data could form a 15 Hex ID for a SGB and would consist of: Country Code C/S Type Approval Certificate (TAC) No Beacon Unique Serial Number However some participants at JC-27 were of the opinion that such a SGB BUI should also contain the aircraft / vessel ID as this was used by some SPOCs (including RCCs) and Inspectors during surveys. These participants felt this was necessary even if the vessel ID was transmitted during every beacon burst. Therefore consideration should thus be given to creating a Hex-ID longer than 15 characters, to allow both the unique ID and the vessel ID to be contained in a single Hex-ID. As a result the wording in C/S G.008 Section a. was modified to indicate that the Beacon ID shall include: a country code,

2 2 TG-1/2014/6/7 additional information that uniquely identifies the beacon when combined with the country code, a Type Approval Certificate (TAC) number. Action Item JC-27/AI.7 was raised to invite participants to study and propose an extended Hex ID (more than 15 characters) for second-generation beacons to transmit in the Hex-ID both the beacon unique ID (TAC number, serial number + country code) and the vessel or aircraft ID for database lookup, as agreed in the proposed changes to document C/S G.008 (see Attachment 1, section (a) and (h) to Annex 32 to this Report). Further Cospas-Sarsat requested that ITU WP5B consider this issue and at its recent November 2013 meeting WP5B concluded in a liaison statement back to Cospas-Sarsat that (see ITU Document 5B/TEMP/193-E) WP5B is of the view that the MMSI should be retained within the 15 character Hex ID. This paper looks at the options for a SGB BUI with a view to the Task Group selecting what it considers to be the most appropriate solution to recommend to JC DISCUSSION 3.1 Current First Generation Beacon 15 Hex ID The 15 Hex ID in a FGB is composed of bits 26 to 85 of PDF-1 and contains the following information: Protocol Flag (which identifies which type of protocol is programmed into the beacon), Country Code (which identifies the Country of Beacon registration), Protocol Code (which specifies which type of Beacon Identification has been used), Beacon Identification or Identification plus Course Position information. The Beacon Identification currently depends on the coding scheme permitted by the relevant national administration and could be any one of the following: A Serial Identification Number (usually also containing the beacon TAC number), An MMSI number, A Radio Call Sign, Aircraft Registration Markings, Aircraft 24-bit Address, Aircraft Operator Designator and Serial Number. The combination of all this information creates the unique 15 Hex ID which is used by Cospas- Sarsat and other bodies (e.g. ICAO, IMO etc.) to identify each beacon. As registration is a very

3 3 TG-1/2014/6/7 important part of the overall system, the 15 Hex ID is a key parameter which is often checked as part of any inspection process of a 406 MHz Beacon (e.g. Annual Testing of Beacons). As well as providing an individual unique identity for every beacon in the world, in some cases the 15 Hex ID is also used by RCC s as a means to contact the aircraft or vessel on which the beacon is installed (for example given the MMSI of an EPIRB this can be used to call the vessel via either radio or satcoms without the need to access any registration database). 3.2 Beacon Coding, Registration and Change of Ownership Although there are many possible beacon coding system, in principle there are only two types of code: Beacon Serial Number, Aircraft or Vessel Identity. In the former case the beacon contains a unique serial number and it is necessary to enter the users details and contact information (and those of their emergency contacts etc.) in a special beacon registration database. In the latter case a special database is often not required as the details of the aircraft or vessel are already stored in a suitable database (e.g. ITU MARS). In the first case if the beacon changes ownership, then nothing needs to be done to the beacon itself (unless the country of registration changes, as it just contains a serial number) however it is essential to ensure that the new owners details are inserted in the special beacon registration database. In the second case if the beacon moves to another aircraft or vessel it is necessary to reprogram a new identity into the beacon to replicate that of the new aircraft or vessel on which the beacon is installed, however there is generally no need to update the database as this already exists for both aircraft / vessels. 3.3 Backwards Compatible 15 Hex ID As detailed in the USA paper EWG-1/2013/4/13 in order to create a 15 Hex ID that is backwards compatible with FGBs it is necessary to ensure that any SGB 15 Hex ID does not duplicate an FGB 15 Hex ID. The only way to do this is to allocate to SGBs a combination of bits that to date has not been used by FGBs and thus will create a unique ID for SGBs. As proposed in EWG-1/2013/4/13 the least number of bits that will achieve this aim is to use the remaining spare FGB User Protocol. Thus in order to create a unique 15 Hex ID for SGBs that is backwards compatible with FGBs the following bits would have to be fixed as shown below: Hex ID Bit 1 = 1 (FGB Message Bit 26) Hex ID Bit 12 = 1 (FGB Message Bit 37) Hex ID Bit 13 = 0 (FGB Message Bit 38) Hex ID Bit 14 = 1 (FGB Message Bit 39)

4 4 TG-1/2014/6/7 All of the remaining 56 bits making up the 15 Hex ID could be any combination of 1 s and 0 s. Of course as it will be possible to differentiate a SGB message at a LUT from a FGB message, then it may be possible to flag SGB 15 Hex IDs and still process these through MCC s and in Registration Databases even if they do duplicate FGB 15 Hex IDs, but this would require further investigation. 3.4 SGB 15 Hex ID Dilemma The current perceived requirements for information to be included within the 15 Hex ID in Second Generation Beacons is potentially as follows: Data No Bits Comments Country Code 10 Potentially 000 to 999 C/S TAC No 20 1,048,576 TAC numbers Beacon Serial Number 10 1,024 numbers Ships MMSI Number 36 6 digits encoded using Modified Baudot Code Aircraft Registration Mark 42 7 Modified Baudot encoded characters Message Type Identifier 2 To identify between aircraft / vessel coding schemes Backwards Compatibility 4 See section 3.3 above Total (worst case) Hex (All above except MMSI) Clearly all of this data will not currently fit in 15 Hex. 3.5 Rationalization of Aircraft / Vessel Identity Data Ships MMSI Currently the ships MMSI 6 trailing digits (the first 3 digits being the Country Code) are encoded using a Modified Baudot Code, which requires 36 bits (this was due to this field also being used to encode ships Radio Call Signs as well). Assuming that Radio Call Signs are NOT required in this field going forward, we can now simply encode these 6 trailing digits as a binary number, which only uses 20 Bits Aircraft Registration Marking This information consists of 7 alphanumerical characters, which requires 42 bits, where the first group (usually but not always two characters) provide the Country of Registration Prefix (e.g. C3 = Andorra, N = USA) and the trailing group of characters (maximum 5, A to Z and 0 to 9) provide the unique identity of the aircraft.

5 5 TG-1/2014/6/7 On the basis that the country is already provided by the Country Code (albeit using a different Country identity scheme, but it would be easy to cross reference these at MCC s in a look up table) then going forward it should be possible to just encode these final 5 characters. Unfortunately this still requires the use of the Modified Baudot Code as there are 36 possible combinations of each character and this still use 30 Bits Aircraft 24-Bit Address As the name suggests this aircraft coding scheme uses 24 bits and there would seem no way to reduce this Aircraft Operator Designator and Serial Number This coding scheme contains a 3 letter aircraft operator designator and a 12 Bit serial number, making a total of 30 Bits. At this time it is not known if it is possible to reduce this number of bits or how often this coding method is used on beacons. But as it is the same length as the reduced aircraft registration marking proposal, then for the purposes of this analysis this does not matter Summary of Coding Rationalisation Thus considering the least number of bits required Ships need 20 bits and Aircraft need 30 bits. 3.6 Beacon Identity Options available for Second Generation Beacons This section of the paper is intended to list all the potential coding schemes that Cospas-Sarsat could adopt to address this issue. No Description of Coding Scheme No Bits Hex ID 1 All Data Backwards Compatible with Existing Coding System Hex 2 All Data not Backwards Compatible with Existing Coding System Hex 3 All Data Backwards Compatible with Reduced Coding System Hex 4 All Data not Backwards Compatible with Reduced Coding System Hex 5 Backwards Compatible Serial No plus only MMSI System Hex 6 Not Backwards Compatible Serial No plus only MMSI System Hex 7 Backwards Compatible Serial Number only (no vessel or aircraft identity data) Hex (16 spare bits) 8 Not Backwards Compatible Serial Number only (no vessel data) Hex 9 Retain Existing FGB System (Backwards Compatible) Hex 10 Print Aircraft / Vessel data on Beacon label but don t put it in Hex ID and use Option 7 above Hex

6 6 TG-1/2014/6/7 Notes on Coding Schemes: 1 Requires 88 Bits as detailed in Section 3.4 of this paper. 2 Requires 4 less Bits than Scheme 1. 3 Only requires 30 Bits for the Aircraft identity rather than 42, thus saving 12 Bits. 4 Requires 4 less Bits than Scheme 3. 5 If only the reduced Vessel MMSI identity (20 Bits) is required (not Aircraft), then this saves 24 Bits (42 20 Bits plus Message Identifier 2 Bits as only one type now) 6 Requires 4 less Bits than Scheme 5. 7 Only contains Country Code, TAC and Serial Number and Backwards Compatibility. 8 Requires 4 less Bits than Scheme 7. 9 Existing FGB scheme used for SGBs, which means Serial Number excluded from Identity of any Aircraft or Vessel coding scheme. 10 As Scheme 7 but proposes a compromise of recording Aircraft / Vessel ID on beacon (Note this might address Inspectors survey needs but it would not help SPOCs / RCCs). 3.7 Conclusions Clearly it is not possible to provide all the proposed SGB data within 15 Hex, thus a compromise of some sorts must be implemented to address this issue, in this respect there would appear to be three options as follows: 1) increase the current 15 Hex ID to either 18, 19, 21 or 22 Hex for Second Generation Beacons, 2) accept that you cannot include both Serial and Aircraft / Vessel identity in the 15 Hex ID, or 3) accept a system that includes Serial data and ships MMSI in the 15 Hex but excludes Aircraft data and requires a secondary means of differentiating FGB 15 Hex IDs from SGB 15 Hex IDs. 4. RECOMMENDATIONS RTCM recommends that the Task Group considers the information on potential Second Generation Beacon Identities provided herein and: a) reviews the proposed SGB Beacon Coding Schemes identified herein and make a recommendation for the adoption of one of the proposed schemes; b) if the TG recommends that a 15 Hex ID is required for SGBs then advise if a true Backwards Compatible 15 Hex ID is required or if it would be possible to differentiate between Hex IDs from FGBs and SGBs by a secondary message tagging means at LUTs or MCCs; and c) request participants to develop suitable wording for consideration at JC-28 defining the requirements for the recommended coding scheme within C/S T.X01. - END OF DOCUMENT -