gr-mcp-docs/reference/cospas-sarsat/r-series/r025.md

---
title: "R025: Draft Prelim. Issue A"
description: "Official Cospas-Sarsat R-series document R025"
sidebar:
  badge:
    text: "R"
    variant: "note"
# Extended Cospas-Sarsat metadata
documentId: "R025"
series: "R"
seriesName: "Reports"
documentType: "report"
isLatest: true
documentDate: "October 2025"
originalTitle: "C/S R.025 - Draft Prelim. Issue A"
---

> **📋 Document Information**
>
> **Series:** R-Series (Reports)
> **Date:** October 2025
> **Source:** [Cospas-Sarsat Official Documents](https://www.cospas-sarsat.int/en/documents-pro/system-documents)

---

COSPAS-SARSAT TWO-WAY COMMUNICATION
OPERATIONAL CONCEPT AND HIGH-LEVEL
REQUIREMENTS
C/S R.025
Draft Preliminary Issue A

C/S R.025 - Preliminary Issue A

COSPAS-SARSAT TWO-WAY COMMUNICATION
OPERATIONAL CONCEPT  AND HIGH-LEVEL REQUIREMENTS
HISTORY
Issue
Revision
Date
Comments
Preliminary A
-

Approved by CSC-73

C/S R.025 - Preliminary Issue A

TABLE OF CONTENTS
Page
History.............................................................................................................................................. i
Table of Contents ............................................................................................................................ ii
List of Tables ................................................................................................................................ xv
List of Figures .............................................................................................................................. xvi
1.
INTRODUCTION ....................................................................................................... 1-1
1.1
Overview ..................................................................................................................... 1-1
1.2
Background ................................................................................................................ 1-1
1.3
Objectives ................................................................................................................... 1-2
1.4
Key Stakeholders ....................................................................................................... 1-2
1.5
Reference Documents ................................................................................................ 1-3
1.6
Terms, Abbreviations, and Definitions .................................................................... 1-3
2.
TWC OPERATIONAL CONCEPT .......................................................................... 2-1
2.1
Overview ..................................................................................................................... 2-1
2.2
Information Flow ....................................................................................................... 2-2
2.3
TWC-Capable Beacons ............................................................................................. 2-3
2.4
Distress cancellation by TWC .................................................................................. 2-4
3.
ROLES AND RESPONSIBILITIES .......................................................................... 3-1
3.1
The Programme ......................................................................................................... 3-1
3.2
TWC Service Provider(s) .......................................................................................... 3-2
3.3
Beacon Manufacturer(s) ........................................................................................... 3-2
3.4
Test Facilities ............................................................................................................. 3-3
3.5
National Administrations.......................................................................................... 3-3
4.
GENERAL GUIDELINES TO TWC-SERVICE PROVIDERS,
ADMINISTRATIONS AND MANUFACTURERS ................................................. 4-1
4.1
SGB Coding Associated with TWC ......................................................................... 4-1
4.1.1
C/S FLAM with Rotating Field \#4 .................................................................... 4-1
4.1.2
Questions, Answers and Instructions ................................................................. 4-4
4.1.3
TWC Database Format Definition ..................................................................... 4-7
4.1.4
Return Link Message for TWC .......................................................................... 4-9
4.1.5
GNSS On-Times .............................................................................................. 4-10
4.2
TWC Considerations for SGB Registries .............................................................. 4-11
4.3
TWC Beacon User Interface .................................................................................. 4-11
4.4
SAR-User Interface ................................................................................................. 4-11

C/S R.025 - Preliminary Issue A

4.5
TWC Beacon Type Approval ................................................................................. 4-12
4.6
TWC Message Dataset Validation ......................................................................... 4-13
4.6.1
TWC message Dataset Validation Principles .................................................. 4-13
4.6.2
TWC message Dataset Validation Process ...................................................... 4-13
4.7
Beacon Design Guidelines ....................................................................................... 4-14
5.
TWC IMPLEMENTATION PLAN ........................................................................... 5-1
5.1
Assumptions and Dependencies ............................................................................... 5-1
5.2
Implementation Steps ................................................................................................ 5-2
5.3
TWC Pilot Capability ............................................................................................... 5-2
5.4
Initial Operational Capability (IOC) ....................................................................... 5-3
5.5
Full Operational Capability (FOC) ......................................................................... 5-4
6.
TWC HIGH LEVEL REQUIREMENTS ................................................................. 6-1
6.1
Integrity ...................................................................................................................... 6-1
6.2
Availability ................................................................................................................. 6-1
6.3
Latency ....................................................................................................................... 6-1
6.4
TWC Coverage .......................................................................................................... 6-2
6.5
Security ....................................................................................................................... 6-2
6.6
Archiving .................................................................................................................... 6-2

C/S R.025 - Preliminary Issue A

LIST OF FIGURES
Figure 4-1: TWC Rotating Field FLAM bit allocation when Answer Format Flag  bit is set to 0
(Short Answer) ..................................................................................................... 4-2
Figure 4-2: TWC Rotating Field FLAM bit allocation when Answer Format Flag  bit is set to 1
(Long Answer) ..................................................................................................... 4-2
Figure 4-3: Answer Field in the Q/A Slot with up to 15 Possible Answers ................................ 4-6
Figure 4-4: Example Encoding of the User's Choice of Multiple Answers  in the Answer Field of
the Long Answer Format ...................................................................................... 4-6
[Figure 4-5: CSV Database Format That Might be Used to Host The Different Versions of the
Dataset] ................................................................................................................. 4-8
Figure 4-6: RLM Type-3 bit allocation ....................................................................................... 4-9
Figure 4-7: Possible Spectrum of TWC Integration of Functionality into Beacons .................. 4-15
Figure A-1: Summary of the data exchange between SAR authorities and beacon ................... A-1
Figure A-2 - Answers to initial questions ................................................................................... A-2
Figure A-3 - Answers to follow-on questions from SAR Authorities ........................................ A-3
Figure A-4 - Delayed answers from the user .............................................................................. A-4
Figure A-5 - Instructions/information message .......................................................................... A-6
Figure A-6 - User not answering initial questions ...................................................................... A-7
Figure B-7 - Example of the CSV Database Format with a Portion of the Current Database] .. B-2

1-1
C/S R.025 - Preliminary Issue A

1.
INTRODUCTION
1.1
Overview
This document outlines the Cospas-Sarsat Programme's operational concept and high-level
requirements for Two-Way Communication (TWC). This capability will be an optional Second
Generation Beacon (SGB) feature. Due to restrictions on the use of the Cospas-Sarsat assigned 406
MHz frequency band, the Cospas-Sarsat TWC capability will be reserved for use for search and
rescue purposes. To enhance the capabilities of the Cospas-Sarsat System, the Programme is
planning to introduce a TWC capability which is limited to the exchange of information between the
beacon user and SAR authorities.
Cospas-Sarsat TWC will be implemented through a collaborative and shared effort among the
International Cospas-Sarsat Programme, Two-Way Communication Service Providers (TWC SPs),
national authorities and beacon manufacturers. The objective will be to provide Search and Rescue
(SAR) authorities with an optional capability to gain additional information about a distress event
and provide instructions. This optional capability will be achieved by implementing bi-directional
communications between the beacon user and the SAR authorities.  Under this optional capability,
the SAR authorities will be able to send pre-defined questions and instructions to the beacon user
via a TWC-SP.  The beacon user will be able to send pre-defined answers to questions to the SAR
authorities via a modified 406 forward link alert message (FLAM).
1.2
Background
In 2020, following the implementation of the Cospas-Sarsat Type 1 Return Link Service (RLS)
capability, the European Commission (EC) proposed an enhancement of the RLS capability to
enable information to be passed between SGBs and Rescue Coordination Centres (RCCs). The
proposed goal of this optional capability was to enable rescue services to retrieve valuable
information from or give instructions to the persons in distress in order to organize and perform
the rescue mission in a more efficient and safe manner.
At CSC-67 the Council decided "to invite participants to work intersessionally, including in an
informal correspondence working group to assess TWC capabilities in the Cospas-Sarsat System".
The EC led a Correspondence Working Group on TWC which was held from January to April
2023 resulting in several papers being submitted to JC-37.
The submissions revealed that there was not yet agreement on the Programme's high-level
strategic vision. As a result, a Plenary splinter group was struck that developed the high-level
strategic vision depicted in Figure 2-1 below. The group, with further iteration intersessionally as
part of the Correspondence Working Group, generally agreed that:
- There are likely to be multiple TWC-SPs, potentially regionally based, making it essential
that the Programme clearly articulate the mechanism and specification that will be common
to all TWC-SPs to interface to the Cospas-Sarsat System.

1-2
C/S R.025 - Preliminary Issue A

- The Cospas-Sarsat Programme will be responsible for ensuring that any TWC-SP linked
to the Programme meets the Cospas-Sarsat TWC high-level requirements provided in the
present document.
- Information presented to the beacon user will be split between an initial automated question
set and a follow-on question/instruction set selected by the SAR authority.
- The initial set of pre-defined questions to the beacon user and possible answers provided
by the beacon user are a core Cospas-Sarsat capability and will remain the responsibility
of the Programme. The answers provided by the beacon users to the initial questions will
be automatically sent to SAR authorities.
- The development and management of the SAR TWC Interface (Web Interface or similar
method) which supports the follow-on pre-defined questions, possible answers and
possible instructions from the SAR authority to the beacon user will be the responsibility
of the TWC-SPs. SAR authorities wishing to access this capability will do so through a
SAR TWC interface operated by the TWC-SPs.
1.3
Objectives
The goal of this document is to guide the implementation of a Cospas-Sarsat-based TWC
capability. Given that Cospas-Sarsat supports SAR stakeholders worldwide, the Programme
should anticipate the eventual participation of multiple TWC-SPs. In order to ensure
interoperability, a common framework and interface between the TWC-SPs and the Cospas-Sarsat
System will be essential. This document provides the Cospas-Sarsat TWC framework and outline
of the roles and responsibilities of stakeholders.
The Programme's objectives in introducing a TWC capability are to:
a) Enhance the Cospas-Sarsat Programme's ability to conduct its current mission of providing
accurate, timely and reliable distress alert and location data to help SAR authorities assist
persons in distress through the addition of an optional two-way communications capability.
b) Introduce a capability that is focussed on the needs of SAR authorities while recognizing
that the first step in providing that support is to encourage the carriage of a beacon by
facilitating the production of a product (beacon) that is appealing to the beacon consumer.
c) Introduce an optional message-based TWC capability focused on enhancing the SAR
responders' situational awareness.
The Programme may consider the introduction of a capability which, subject to technical
limitations, could support limited free text messaging in special-use beacons.
1.4
Key Stakeholders
The Cospas-Sarsat TWC capability will involve a collaborative effort between:
- The Programme
- TWC Service Providers

1-3
C/S R.025 - Preliminary Issue A

- Beacon Manufacturers
- National Authorities
-
Response Organizations/SAR Authorities
-
Beacon Regulatory Authorities
For stakeholder roles and responsibilities see section 3.
1.5
Reference Documents
a) Cospas-Sarsat Document C/S P.011, "Cospas-Sarsat Programme Management Policy".
b) Cospas-Sarsat Document C/S P.016, "Cospas-Sarsat Strategic Plan".
c) Cospas-Sarsat Document C/S G.003, "Introduction to the Cospas-Sarsat System".
d) Cospas-Sarsat Document C/S G.008, "Operational Requirements for Cospas-Sarsat Second-
Generation 406-MHz Beacons".
e) Cospas-Sarsat Document C/S S.011, "Cospas-Sarsat Glossary".
f) Cospas-Sarsat Document C/S T.018, "Specification for Second-Generation Cospas-Sarsat
406-MHz Distress Beacons".
g) Cospas-Sarsat Document C/S T.021, "Second-Generation Cospas-Sarsat 406-MHz Distress
Beacons Type Approval Standard".
h) Cospas-Sarsat Document C/S A.001, "Cospas-Sarsat Data Distribution Plan (DDP)".
i) Cospas-Sarsat Document C/S A.002, "Cospas-Sarsat Mission Control Centres Standard
Interface Description (SID)".
j) Cospas-Sarsat Document C/S A.005, 'Cospas-Sarsat Mission Control Centre Performance
Specification and Design Guidance'.
1.6
Terms, Abbreviations, and Definitions
Specific terms, abbreviations, and definitions are included in document C/S S.011.
- END OF SECTION 1 -

2-1
C/S R.025 - Preliminary Issue A

2.
TWC OPERATIONAL CONCEPT
2.1
Overview
The Cospas-Sarsat TWC will be an optional capability that will enable beacon users to convey
additional information about their situation to SAR authorities and to respond to follow-on
questions that SAR authorities may elect to send. The envisioned concept will involve at least
two message sets. The first will be a series of pre-defined initial questions and possible answers
pre-programmed into the beacon, which will be presented to the beacon operator upon beacon
activation. The answers to these questions will be forwarded to the MCC in FLAMs to be
processed and sent directly to RCC/SPOCs and the TWC-SP. The Programme, in consultation
with SAR authorities and beacon manufacturers, will be responsible for developing and
maintaining this message set.
The second message set will be a set of pre-defined follow-on messages (e.g., questions, possible
responses, instructions, information, etc.) approved and maintained by the Programme but
developed by the TWC-SP in coordination with SAR authorities, beacon manufacturers and the
Programme. Beacon user responses arising from these follow-on messages will flow through the
MCC to the TWC-SP.
The TWC-SP will operate the interface between the SAR authorities and the TWC-SP in order to
allow SAR authorities to communicate with the beacon user via return link messages (RLM) sent
to the beacon using the TWC return link service.
Figure 2-1 depicts the conceptual flow of information and division of operational responsibilities.

2-2
C/S R.025 - Preliminary Issue A

Figure 2-1: TWC Conceptual Flow of Information and Division of Responsibilities
2.2
Information Flow
Once activated, a beacon will send its initial alert in accordance with current Cospas-Sarsat
specifications without delay. The beacon, even if TWC capable, will not wait for additional
information from the beacon user. This alert will be processed in accordance with the
specifications and procedures applicable for all alerts and, if the beacon is TWC-capable the TWC-
SP and the RLSP will be notified.
The TWC questions, answers and instructions data will use a new rotating field RF\#4 which will
alternate with RF\#0 (See Document C/S T.018) in the FLAM to transmit TWC information from
the beacon to SAR authorities.
Upon distress detection and localization by Cospas-Sarsat, the TWC-capable beacon will receive
an Acknowledgement RLM (Type 3 acknowledgement) from the TWC-SP via its associated RLSP
and will indicate it to the beacon user via an appropriate indicator.
If a beacon is TWC-capable, the beacon operator will be presented with a series of initial questions
and possible answers pre-programmed into the beacon. The beacon will include these initial
answers in the subsequent FLAM bursts, as soon as new information is provided. The beacon
information will indicate with which TWC-SP(s) it is associated. The initial FLAM will be
forwarded to RCCs/SPOCs in a standard SIT 185 message and include notification that the

2-3
C/S R.025 - Preliminary Issue A

activated device is TWC capable.  As soon as available, initial answers will be sent to the RCCs
via a standard SIT 185.  RCCs may notify SAR responders that the beacon has a TWC capability
and of the connection details for the SAR TWC interface. This same SAR TWC interface will
provide the initial answers as well.
Furthermore, all initial questions and answers and follow-on questions, answers and instructions
will be made available by the TWC-SP connected to SAR responders and authorities through a
SAR TWC interface. Follow-on TWC messages will flow through the standard Cospas-Sarsat
architecture (beacon to satellite to LUT to MCC) and then to the TWC-SP but should not require
any manual action by the MCC.  If no new information is provided in the allocated TWC bits,
these messages should not be forwarded to the RCC.
After the beacon location is provided by the Cospas-Sarsat System, the FLAMs received by the
MCC shall be forwarded to the TWC-SP in order to keep the complete answers received available
to the RCC operator on the SAR TWC interface for a TWC beacon activation.
Communication with the beacon through the SAR TWC interface will start with the SAR
Authority selecting the activated beacon through the TWC-SP interface and initiating
communication with it. Additionally other authorized SAR users may be granted observer rights,
allowing them to monitor the communication, without being able to send information to the beacon
user.
Furthermore, the TWC-SP interface should be designed to prevent any user from restricting access
to the system, ensuring that all authorized users, as determined by national authorities, can utilize
the interface without interference or obstruction from others.
Follow on TWC messages will flow through the standard Cospas-Sarsat architecture (beacon to
satellite to LUT to MCC) and then to the TWC-SP, but should not require any manual action by
the MCC. Follow-on messages will not flow directly from the MCC to the RCC.
Access to the SAR TWC interface shall be restricted and require SAR authorities to register with
the TWC-SP in order to access the information.
2.3
TWC-Capable Beacons
See documents C/S G.008 for operational requirements and C/S T.018 for technical performance
specification details.
Second-generation beacons enabled with TWC functionality will:
a) receive and extract relevant information from return link messages contained in the RLS signal;
b) provide an interface for the beacon user to:
i.
Read and enter answers to questions presented (e.g., via multiple-choice
selections),
ii.
Read instructions from search and rescue authorities,

2-4
C/S R.025 - Preliminary Issue A

iii.
Provide updates on a distress situation, as required by SAR authorities;
c) have an embedded database of initial automatic questions and possible answers required by the
Cospas-Sarsat Programme that can be updated if a revised set of questions and/or answers are
made available;
d) upon activation present the initial set of Cospas-Sarsat Programme approved automatic questions
and possible answers to the beacon user; and
e) have an embedded database of follow-on questions, possible answers and instructions defined
by the TWC-SP (in accordance with the validation criteria approved by the Programme) and that
can be (optionally) updated if a revised set of questions, possible answers and instructions are
made available.
The user answers to the initial and follow-on questions are sent to the SAR authorities through the
Cospas-Sarsat system and to the TWC-SP.
National administrations are requested to provide in document C/S S.007 information regarding the
permitted use and coding of beacons with TWC capabilities, including any limitations.
Based on the available information in document C/S S.007, manufacturers are required to clearly
identify to the user at the time of purchase the geographic or regulatory limitations that may affect
the availability of TWC functionality in a beacon with that capability.
If the TWC capable beacon supports more than one TWC-SP, the method of selecting the TWC-SP
shall be described in the user manual.
A TWC capable beacon shall have local access to a dataset of pre-defined initial and follow on
questions, possible answers and instructions applicable to each TWC-SP with which it is
associated provided by the beacon manufacturer. These may be stored on the beacon, on a related
display tool or on a compatible smart device.
2.4
Distress cancellation by TWC
The TWC-capable beacon will allow the beacon user to inform the SAR authorities that the alert
was a false alert or that the distress situation ceased by prompting the user using the TWC beacon
interface, resulting in the activation of the standard SGB cancellation function.
If this distress cancellation answer is selected by the beacon user, a confirmation prompt will be
displayed and if confirmed, the beacon will automatically initiate the beacon activation
cancellation function as per document C/S T.018 section 4.5.7, including the transmission of
cancellation messages (Main Field and Rotating Field\#15).  For the avoidance of doubt, the beacon
shall not transmit a response as a TWC message (i.e., not using RF\#4).  Should the user not confirm
the cancellation, the beacon will continue to operate in its normal distress mode, and will redisplay
the previous TWC initial question.
Once the beacon activation cancellation function has started, the TWC interaction with the beacon
user and all further communication ceases.

2-5
C/S R.025 - Preliminary Issue A

The MCC receiving confirming cancellation messages shall also distribute the associated alert
message to the TWC SP destination, such that it can adjusts its operations appropriately if the same
TWC beacon is subsequently reactivated.
- END OF SECTION 2 -

3-1
C/S R.025 - Preliminary Issue A

3.
ROLES AND RESPONSIBILITIES
3.1
The Programme
The Cospas-Sarsat Programme will:
a) define the initial questions and possible answers to be encoded into all TWC capable beacons;
b) approve a set of validation criteria to ensure the adequacy of follow-on questions, possible
answers and instructions that will be offered in library form by TWC-SPs;
c) retain the responsibility for ensuring messages are compliant with the authorized use of the 406
MHz Band and therefore will be required to approve these message sets' adequacy according to
validation criteria defined in section 4.9 through the Validation Panel process;
d) enhance the Cospas-Sarsat system to enable the automatic transmission of a FLAM encoded
with initial questions and answers from the TWC capable beacon to the MCC;
e) enhance the Cospas-Sarsat system to enable the transmission of the first beacon alert message
with TWC information and the subsequent ones if non-redundant from the MCC to the TWC-
SP without delay;
f) enhance the Cospas-Sarsat system to decode the initial questions and answers from the TWC
capable beacon and transmit them to the RCC/SPOC as additional information in the SIT 185
message;
g) enhance the Cospas-Sarsat System to enable the transmission of a FLAM encoded with initial
questions and answers from the MCC to one or more TWC-SP, as appropriate;
h) enhance the Cospas-Sarsat System to enable the transmission of a FLAM from the beacon
through the MCC to one or more TWC-SP(s) of messages sent from the TWC-capable beacon
containing responses to follow-on questions that may be sent to the beacon user from SAR
authorities through the TWC-SP, as well as TWC message reception acknowledgements;
i) develop specifications for inclusion in appropriate Cospas-Sarsat documentation to establish
type-approval standards for beacons having TWC capabilities;
j) in collaboration with TWC Service Providers, define the System-level TWC test scenarios
required for the evaluation of the operational distribution of messages by the Cospas-Sarsat
Ground Segment from TWC-capable beacons including the prerequisites for their execution;
k) consider Beacon Type Approval applications and assign TACs;
l) host the TWC message dataset in all its official language translations;
m) consider the dataset validation panel's outcome for new dataset release; and
n) update the IBRD and/or TAC database to identify TWC beacons, if appropriate.

3-2
C/S R.025 - Preliminary Issue A

3.2
TWC Service Provider(s)
The TWC-Service Providers will:
a) propose follow-on TWC questions, possible answers and instructions, to be tabulated in library
format, in close collaboration with SAR authorities and in consultation with TWC beacon
manufacturers and submit to the Programme for review by the Validation Panel;
b) establish and operate a message-data processing capability and SAR TWC interface to receive,
store and make available to SAR authorities TWC questions, possible answers and instructions
to be exchanged with the TWC-capable beacons;
c) establish and operate a message-data processing facility to relay follow-on question and
instruction messages from SAR authorities to the TWC-capable beacon;
d) manage the registration of national SAR authorities and other authorized stakeholders as users
of the SAR TWC interface;
e) provide materials for the training of the SAR operators intending to utilize the SAR TWC
Interface;
f) ensure all registered SAR authorities and other properly authorized stakeholders have access
to the message-data processing and SAR TWC interface;
g) ensure adequate message-data processing and user-interface capacity for simultaneous access
to the SAR TWC interface by all relevant stakeholders;
h) adhere to Cospas-Sarsat standards, existing and as may be developed, for the initial questions
and answers;
i) in collaboration with the Cospas-Sarsat Programme, define the system level TWC test
scenarios required for the evaluation of the operational distribution of messages by the Cospas-
Sarsat Ground Segment for TWC-capable beacons including the prerequisites for their
execution; and
j) in collaboration with Cospas-Sarsat Programme, implement a new version of the TWC
message database when necessary, taking into account the SAR Authorities needs and
according to validation criteria approved by the Programme.
3.3
Beacon Manufacturer(s)
The Beacon Manufacturer(s) will:
a) develop TWC SGB beacons in compliance with applicable C/S specifications and other
applicable specifications with an initial focus on PLBs;
b) develop and program beacons with the agreed upon initial and follow-on TWC questions and
answers and the ability to receive instructions;
c) provide a way to update the TWC message database contained in the beacon or associated
product(s), if needed;
d) define beacon-user interface in coordination with applicable standards bodies; and

3-3
C/S R.025 - Preliminary Issue A

e) support the system level TWC tests conducted by the Programme and the TWC Service
Provider with beacon prototypes.
3.4
Test Facilities
The Test Facilities will:
a) provide a means to perform type approval testing TWC capable beacons according to
document C/S T.021 to ensure that they meet the C/S T.018 specifications; and
b) develop and implement a test bench capability allowing the testing of the TWC-related
capabilities of the TWC-capable beacons submitted by beacon manufacturers for Type
Approval Certification.
3.5
National Administrations
The National Administrations should consider the following:
a) register (i.e., enter into as service agreement) with the TWC Service Provider and determine
the permission level (active or monitor only) for national SAR authorities with access to the
SAR TWC interface;
b) collaborate with the TWC-SP for the definition of the SAR-User Interface requirements.
c) establish the national regulations for TWC-capable beacons, as necessary;
d) ensure the adequate training of the SAR operators allowed to use the SAR TWC interface;
e) limit access to the SAR TWC interface to trained and authorized operators;
f) provide an official translation of the TWC message database into any alternative language, if
desired, and submit for possible inclusion in the TWC message dataset;
g) review and consider updating the national beacon registry to allow the identification of TWC
capable beacons;
h) update the applicable portion of document C/S S.007 to advise the Programme of the national
regulations regarding TWC beacons; and
i) update document C/S S.007 to indicate the official translation(s) of the dataset appropriate for
potential use in their beacons.
- END OF SECTION 3 -

4-1
C/S R.025 - Preliminary Issue A

4.
GENERAL
GUIDELINES
TO
TWC-SERVICE
PROVIDERS,
ADMINISTRATIONS AND MANUFACTURERS
4.1
SGB Coding Associated with TWC
The following sections present the planned approach for implementing the RLS Type 3 Two-way
communication (TWC) messages. Much of the detailed information which follows, can also be found
in document C/S T.018 "Specification for Second-Generation Cospas-Sarsat 406-MHz Distress
Beacons".  If there are any discrepancies between the information included in this document and the
information presented in document C/S T.018, the information in document C/S T.018 should take
precedence.
4.1.1
C/S FLAM with Rotating Field \#4
TWC Rotating Structure and Bit Allocation
The following data fields have been identified as being necessary in a RLS Type 3 TWC FLAM
(See document C/S T.018 "Specification for Second-Generation Cospas-Sarsat 406-MHz Distress
Beacons", Table 3.7 for further details):
Rotating Field Element
Bit Allocation
Rotating Field ID
4 Bits
TWC Provider ID
3 Bits
TWC
message
dataset
Version ID
5 Bits
RLM Type-3
Acknowledgement
1 Bit
Answer Format Flag
1 Bit
Spare Bit
1 Bit
TWC Q/I/A
33 Bits Either Short Answer Format or Long Answer
Format
Total
48 Bits
The new Rotating Field assigned for RLS Type 3 TWC (RF\#4) follows the bit allocation illustrated in
Figure 4-1 and Figure 4.2.  (See document C/S T.018 "Specification for Second-Generation Cospas-
Sarsat 406-MHz Distress Beacons", Figures 4-2, and 4-3)

4-2
C/S R.025 - Preliminary Issue A

Figure 4-1: TWC Rotating Field FLAM bit allocation when Answer Format Flag
bit is set to 0 (Short Answer)
Figure 4-2: TWC Rotating Field FLAM bit allocation when Answer Format Flag
bit is set to 1 (Long Answer)
This assignment enables having three separate slots of 11 bits each, or one slot of 22 bits followed by
one slot of 11 bits, for Questions/Answers or Instructions / Reception Acknowledgements per burst.
The short answer format is intended to support only a single answer for a specific question. The long
answer format is intended to support selection of multiple answers for a specific question. Both formats
can support an instruction(s) with an acknowledgment(s).
Questions requiring a long answer format will be flagged in the dataset.
Each field of the TWC FLAM structure is described in the following subsections:
Rotating Field ID
Four bits are allocated to the Rotating Field identifier. For TWC Rotating Field the value is 0100
as defined in document C/S T.018 "Specification for Second-Generation Cospas-Sarsat 406-MHz
Distress Beacons", Table 3.7: TWC Rotating Field (\#4).
TWC Provider ID
Three bits have been allocated to identify the TWC service provider or TWC-SP. This allows for
a total of eight different service providers, which seems adequate considering that only three
potential service providers to date have been identified (i.e., BDS, Galileo, Glonass).

4-3
C/S R.025 - Preliminary Issue A

TWC Message Dataset Version ID
The Programme anticipates the need for several versions of the TWC message dataset over the lifetime
of the capability.  Five bits are allocated for this purpose in order to allow for TWC message dataset
updates in case of modifications in the Questions/Answers/Instructions set. This allows for a total of
thirty-two different TWC message dataset versions which seems adequate considering that it is
unlikely that more than one version per year will be needed.
The TWC message dataset will be contained in a single database maintained by the Secretariat in
the three official Programme Languages.  A complete version history of all approved TWC
message dataset versions shall be maintained and shall be made readily available to Programme
stakeholders (e.g., MCC, RCCs, National Administrations, etc.), beacon manufacturers and TWC-
SPs.  Additional languages may be added once Participants provide official translations for
inclusion in document C/S [S.TBD].  The mechanism for how the datasets will be provided and
controlled is still TBD.
The different versions of the dataset shall be available on the Cospas-Sarsat and TWC-SP
websites.  Updates of the dataset will not be obligatory for the beacon users, and the system must
support backward compatibility in the event that a beacon is using an out of date dataset. Beacon
manufacturers are expected to load beacons with the most up to date dataset(s) compatible with
the appropriate TWC-SP(s) at the time of sale.
Additionally, RCCs and MCCs shall be informed of any changes to the Initial questions which
should be implemented as a critical change for MCCs.
Updates of the versions will be notified by the Secretariat to the beacon manufacturers, the TWC-SPs
and the FMCC. The notification of the general public by beacon manufacturers should be left to their
discretion.
The notification to inform the MCCs of TWC dataset updates should follow a similar process to the
TAC notification model with distribution of a narrative SIT 605 message.
The notification to inform the RCCs and SPOCs of TWC dataset updates should be carried out with
distribution of a narrative SIT [915] message.
The Cospas-Sarsat Programme shall make available (e.g., on a server/a website/through an API) all
the different versions of the dataset at all times, in a specific format (i.e., CSV file) allowing remote
access and download. The MCC shall be capable of updating their locally hosted dataset upon
receiving the update notification.
In order to avoid a process that could lead to unnecessary latency in the implementation of a new
version of the dataset, the update of the locally hosted dataset should not trigger an update of the
MCC's software.
The MCC should be able to access and use any of the approved dataset versions.

4-4
C/S R.025 - Preliminary Issue A

A dedicated letter to beacon manufacturers at the time of approval of the change shall also be
transmitted by the Secretariat.
A TWC message dataset version update would be required by the addition, modification, or
suppression of a question, answer, or instruction.  The initial addition of an alternate language will
not require a version update, but substantive changes to a translated message will require a version
update. Proposed changes (which are deemed non-urgent) may be collected until a complete
revision is made. Any version update shall be validated through a systematic process prior to
implementation by the Programme and needs to be approved by the Programme as described in
section 4.6.
RLM Type 3 Feedback
One bit is allocated to acknowledge the reception of the first RLM Type-3 TWC Acknowledgement:
when the distress beacon receives the first RLM Type 3 acknowledgement, this bit changes from
default value 0 to value 1.
Once the TWC link is established, this bit is set according to the behavior specified by the TWC-SP
(e.g., for Galileo it stays at the value 1 until either the beacon battery is depleted or the beacon is
deactivated whichever comes first).
Long/Short Answer Formats
This bit defines the way the Rotating Field (\#4) data has to be structured.
If the bit is set to 0, this means that short-answer-format questions are to be sent, and the bit
allocation is the one displayed in Figure 4-1.
If the bit is set to 1, this means that a long-answer-format question and answer shall be sent, and
the bit allocation is the one displayed in Figure 4-2.
Spare Bit
One spare bit, currently unused, is available for possible future use.
4.1.2
Questions, Answers and Instructions
The main objective of the TWC is to allow the exchange of information between a beacon user
in distress and the SAR Authorities in order to support a more informed SAR response.
The TWC Questions/Answers/Instructions are broken in two categories:
1) Initial Questions, automatically displayed at beacon activation, for which answers will be
directly transmitted to SAR Authorities by MCCs and to the TWC-SP.
The aim of the set of initial questions is to report the essential elements of the distress, such as,
number of persons involved, nature of the distress and type of assistance required. Every

4-5
C/S R.025 - Preliminary Issue A

question should be relevant in any case of distress without other considerations. This
information should help the SAR Authorities to:
- determine the level of distress (assistance / distress / life distress);
- determine which centre is responsible (e.g., land, maritime, aviation, etc.) for the
coordination;
- broadcast safety messages and instructions via other means than Cospas-Sarsat;
- determine whether a medical team is required;
- task the first assets.
2) Follow-on Questions/Answers/Instructions, selected by SAR Authorities and sent by the
TWC-SPs and for which answers are provided by the beacon user will be sent to the TWC-
SP and be available on the SAR TWC interface (web-based or equivalent).
The aim of the set of follow-on Questions/Answers/Instructions is to help the SAR Authorities
better understand the ongoing event. In order to maximize the benefits of communication
between the beacon user and the SAR Authorities, they should cover as many situations as
possible. This information should help the SAR Authorities to:
- task specialized teams;
- ensure a good understanding of the situation;
- maintain link with the beacon user;
- provide the beacon user with relevant advice to maximize the success of the operation;
- be aware of any change in the situation.
Several scenarios are presented in Annex A.
Multiple-Selectable Answers
The TWC beacon shall allow the user to select multiple answers for some pre-defined questions.
Every question allowing the user to choose multiple answers shall be identified as such in the
dataset.
For each of these questions that allow multiple-selectable-answers, the long answer format will be
utilized in the FLAM.
When the Answer format flag bit is set to 1, the long answer format allows for each possible
combination of answer(s) (e.g., A1 or A1 + A2 or A2 + A3 + A4) to be identified by a unique bit
combination. Consequently, by associating each bit with a single answer, a maximum of 15
answers to choose from is possible and the user can choose any combination of answer options.

4-6
C/S R.025 - Preliminary Issue A

The following details the encoding of the choice of multiple answers in the first Q/A slot in the
long answer format.
The number of possible answers is 15, meaning that the user will be able to choose among the 15
possibilities, the answers to be sent. Each answer's option is identified with the following
nomenclature: Ai for the answer i, with i going from 1 to 15.
Each bit is associated with an answer, which means that if a bit is equal to 1 for a particular position
it indicates the corresponding Ai, as illustrated in Figure 4-3 below.
Figure 4-3: Answer Field in the Q/A Slot with up to 15 Possible Answers
If the answers A1, A3, A5, A7, A11 and A13 are the final choice of the user, this results in the
answer field being encoded as shown in Figure 4-4.
Figure 4-4: Example Encoding of the User's Choice of Multiple Answers
in the Answer Field of the Long Answer Format
Decision Tree
Among the initial automatic questions, some have answers that can trigger a new question.
The beacon shall be able to handle a decision tree, meaning that depending on the answer(s) from
the beacon user, the beacon shall automatically display the corresponding next question.
[The beacon user shall be able to go back to the previous question [in a decision tree] (i.e., back
function) and select an alternate response.] [The transmission of intermediate steps in the decision
tree shall be delayed for a period of [30 seconds or one minute] to allow the end user to reach the
final step before any intermediate steps are transmitted.]

4-7
C/S R.025 - Preliminary Issue A

In the case where the question allows multiple answers that trigger new questions, the different
paths of these new questions shall be followed one after the other.
Due to the risk of confusing the beacon user and having incoherent paths of questions, special care
must be taken when defining the dataset.
As with multiple-choice answers, questions for which answers can trigger a subsequent question
shall be identified in the dataset.
Handling Questions and Answers
[TWC beacons shall be capable of allowing the user to backtrack on an answer prior to it being
transmitted in case of an incorrect choice and to choose an alternative answer to a question. This
capability maybe performed by preferably requiring a confirmation of an answer, where a negative
response would automatically take the user back to the start of that question, or by other acceptable
means such as a Back Button (Function). Questions so identified in the Q, A & I dataset shall
require the beacon user to confirm their selected answer to that question prior to it being
transmitted. The end user shall not be able to skip over a question, all Initial questions must be
answered in order, however any Follow-on Questions or Instructions take precedence in the
question queue over any outstanding Initial questions, which are presented to the end user once
they address the Follow-on question or instruction.]
4.1.3
TWC Database Format Definition
[The following Figure 4-5 shows the format of the CSV database containing the dataset. It shall
include:
- Version ID of the dataset,
- Question ID,
- Language,
- Question Text,
- Answer Format Flag
- Multiple-selectable answers Flag
- Next Question
- Initial Question flag,
- The columns corresponding to each answer option,
- The question ID to which each answer can lead (decision tree questions)]
[When the Multiple-selectable answers Flag has a value of 1, the Answer Format Flag shall always
have a value of 1, due to the combination of answers being encoded in a Long Answer format
RF\#4. Moreover, in this case, the beacon shall always display "Select all the answers that apply."
in addition of the Question Text.]

4-8
C/S R.025 - Preliminary Issue A

[For the decision tree among the initial questions, if the subsequent question is independent of the
beacon user choice of answer(s), the column Next Question shall be filled with the ID of the
subsequent question, rather than filling all the "Go to" columns with the same question ID
(exception for the Cancellation Protocol). [During the Initial Question phase, when the beacon
user skips a question, the next question display will be the one corresponding to the ID in the Next
Question column of the skipped question. If there is none, it means that the Initial Question phase
is over.]]
[Finally, note that the flags can take the value 0 or 1 which shall be interpreted as False and True,
respectively.]
Version
ID
Question
ID
Language
Question
Text
Answer
format flag
Multiple-selectable
answers flag
Next
Question
<5 bits>
<7 bits>
<Text>
<Text>
<1 bit>
<1 bit>
<7 bits>
Initial
Question
flag


<7 bits>
<Text> <Text> <Text> <Text> <Text> <Text> <Text> <Text> <Text> <Text>


0001 - Go to
0010 - Go to
<Text>
<Text>
<Text>
<Text>
<Text>
<7 bits>
<7 bits>
0011 - Go to
0100 - Go to
0101 - Go to
0110 - Go to
0111 - Go to
<7 bits>
<7 bits>
<7 bits>
<7 bits>
<7 bits>
1000 - Go to
1001 - Go to
1010 - Go to
1011 - Go to
1100 - Go to
1101 - Go to
<7 bits>
<7 bits>
<7 bits>
<7 bits>
<7 bits>
<7 bits>
1110 - Go to
1111 - Go to
<7 bits>
<7 bits>
[Figure 4-5: CSV Database Format That Might be Used to Host The Different Versions of
the Dataset]

4-9
C/S R.025 - Preliminary Issue A

4.1.4
Return Link Message for TWC
The objective of TWC is to provide the SAR Authorities with the information from the beacon
user as quickly as possible. In order to do so, the TWC-SP shall use RLM Type 3 which is
designed for Two Way Communication, and it shall:
-
Transmit automatic acknowledgement of the detection and localization (without
confirmed position) of the alert by an MCC;
-
Transmit new follow-on questions or instructions and/or acknowledgement to
answers received by the TWC - Service Provider.
This RLM Type-3 should not wait for the confirmation of the position but should be sent as soon
as a location of the beacon is provided to the MCC.
An RLS Type-3 TWC capable beacon may or may not be RLS Type-1 Acknowledgement
capable without any impact on the functioning of either.
Galileo RLM Implementation Details
The following figure illustrates the bit allocation of the RLM Type-3 in the European GNSS
(Galileo) Open Service Signal-in-Space Interface Control Document (OS SIS ICD version
[TBC]).
The following data fields have been identified as being in a RLM Type-3 TWC:
SAR RLM Data Values
Bit Allocation
15 Hex ID
60 Bits
Message Code
4 Bits
Acknowledgement
2 Bits
Question/Instruction ID
14 Bits (2 slots for Q/I ID)
Total
80 Bits
Figure 4-6: RLM Type-3 bit allocation
Each bit field of the RLM Type-3 TWC structure is described in the following subsections:
15 Hex ID
The 15 Hex ID is identical to the 60 bits (15 Hexadecimal characters) of the standard beacon
identification of document C/S T.018.

4-10
C/S R.025 - Preliminary Issue A

Message Code
In the RLMs, a field of 4 bits are dedicated to describe the RLS service for which the RLM is used. In
this case, it is dedicated to TWC. Message code for TWC service is defined as "0011".
TWC RLM Function
Two bits informs on the function of the RLM Type-3 TWC:
- if the bit values are 00, it means that the information carried by the two Q/I ID slots is new
questions or instructions to the beacon. Either the two slots are each filled with a new question
or instruction, or only the first slot (Qx/Ix ID) is filled with a new question or instruction and
the second slot (Qy/Iy ID) is at default value.
- if the bit values are 01, it means that the information carried by the first Q/I ID slot (Qx/Ix
ID) is a new question or instruction to the beacon and the information carried by the second
Q/I ID slot (Qy/Iy ID) is an acknowledgement to an answer provided by the beacon user via
the question identifier.
- if the bit values are 10, it means that the information carried by the two Q/I ID slots is
acknowledgement to the answers provided by the beacon user via the questions identifier.
Either the two slots are each filled with an acknowledgement to an answer, or only the first slot
(Qx/Ix ID) is filled with an acknowledgement to an answer and the second slot (Qy/Iy ID) is
at default value.
- if the bit values are 11, it means that the TWC-SP system is automatically acknowledging
that the alert has been detected and at least a location is available (no location confirmation
required). Hence, the content of the following two Q/I ID slots is at default value and can be
ignored
Question/Instruction ID
Two slots of seven bits are allocated to the identification of two questions and/or instructions.
4.1.5
GNSS On-Times
Currently, the minimum operating times of the GNSS receiver in an RLS capable beacon are that
it is on for the first 30 minutes after beacon activation, followed by an on period of 15 minutes
every hour for 6 hours as defined by Moffset.
For the TWC, the initial on period of the GNSS receiver shall be 180 minutes and after that time
the GNSS receiver is on for 15 minutes every hour for 9 hours as defined by Moffset.

4-11
C/S R.025 - Preliminary Issue A

4.2
TWC Considerations for SGB Registries
[TBD]
4.3
TWC Beacon User Interface
After beacon activation, an indicator should appear in order to notify the beacon user that the TWC
link has been established and that the alert has been located.
In the initial question-answering phase, the questions are presented sequentially and must be
answered before the next question is displayed to the user.
Once the user provides an answer, the question-and-answer pair will be encoded by the beacon in
the Rotating Field \#4 and transmitted. There is no requirement to notify the user that their answer
has been received by the TWC-SP or SAR authorities, but this functionality may also be
implemented.
See document C/S T.018, sections 4.5.17.1 to 4.5.17.4 for details on the TWC Beacon user interface.
4.4
SAR-User Interface
The SAR TWC Interface should allow the SAR authority users to:
-
Display all the communication items (Questions/Answers/Instructions) sorted in
chronological order;
-
Display the links between the questions and the associated answers;
-
Display the status of the questions and instructions (selected/sent/received by the
beacon/answered (for questions only));
-
[Hand-over the right to another SAR authority to be the active user in the communication
with a beacon (only one active user allowed at a time)];
-
Display to the new user the whole communication that took place between the beacon and
previous users;
-
Display the whole communication in monitoring mode only if an active user is currently
communicating with the beacon;
-
Obtain a copy of past (archived) TWC communications, as allowed under the TWC-SPs
policies and user agreements.
The
SAR
TWC
Interface
should
display
the
communication
items
(Questions/Answers/Instructions) taking into account the version of the library installed into the
beacon.

4-12
C/S R.025 - Preliminary Issue A

4.5
TWC Beacon Type Approval
The Programme has responsibility for validating any Cospas-Sarsat specified items as documented
(or to be developed for inclusion) in documents C/S T.018 and C/S T.021, consequently, it has the
responsibility for type approval of TWC beacons.
All TWC features and functionality defined in document C/S T.018 shall be validated by one of the
means of compliance defined in document C/S T.021 section 4.4, and the appropriate method
of compliance shall be set out in relevant parts of document C/S T.021.
Other functionalities related to the TWC that are not specified within the C/S T.018 should be tested
and verified by entities outside Cospas-Sarsat as is currently done for beacons with functions under
third parties' responsibility (e.g., ETSI, EUROCAE, IEC, RTCA, RTCM, etc.).
The development of interface requirements is not an essential function thus it shall be outside of the
scope of the Programme unless specified in document C/S T.018. However, testing shall ensure that
anything connected to a beacon causes no harm to the beacon or prevents it from fulfilling its primary
purpose.
The beacons should be updated with the latest version(s) of TWC message dataset when still in
production, but the beacon user shall also have the possibility to update it after the beacon has left
the manufacturer' facility (e.g., via an external third-party interface). The responsibility to update
the dataset in the beacon and/or external user interface is up to the end user with support from the
manufacturer as it is outside of the Programme's capability. As part of the type approval process, the
beacon manufacturer must include beacon user instructions that demonstrate that the beacon can be
updated and how.
The TAC approval requirements associated with TWC should include confirmation that:
a) The TWC beacon user interface is installed and working (directly through an integrated
screen and interface mechanism or indirectly through an external device or some
combination with limited functionality on the beacon and additional functionality on the
external device).
b) Both initial and follow-on questions and answers work correctly.
c) The most current dataset(s) of questions, answers and instructions is installed and working
with the beacon.
d) Dataset version can be updated.
e) The beacon properly synchronizes the questions and answers prior to transmission.
f) Any additional functionality does not cause the beacon performance to drop below the
approved beacon performance requirements. Typical examples of the performance
requirements of greatest concern would be "Operational Lifetime" (battery life) and
"Frequency Stability" (due to other transmitters such as for external devices).
g) All other integral functions of the beacon, including RLS if integrated in the beacon, operate
in accordance with Cospas-Sarsat specifications independent of a successful coupling with
the TWC interface device.

4-13
C/S R.025 - Preliminary Issue A

4.6
TWC Message Dataset Validation
Initial questions and answers, follow on questions and answers, and instructions in all available
languages will be contained in document C/S [TBD].
The Programme will be responsible for developing and maintaining the dataset of initial questions,
and answers. This will be accomplished through the established Programme management process
as outlined in document C/S P.011, "Cospas-Sarsat Programme Management Policy". Proposed
changes to initial questions and answers will be reviewed by the Joint Committee and/or an Experts
Working Group and recommended to Council for approval.  Once approved by the Council, the
Secretariat will forward a request for an updated translation to any National Administrations that
have provided official translations of the dataset.  Once the text in all three official Programme
languages is available, the Secretariat will document the official dataset version and all translations
in document C/S [TBD], post these updates to the C-S website, and send notification to all TWC-
SPs, beacon manufacturers, and the Parties.  Additional language translations will be added as they
are received and notifications provided.
The Programme will exercise oversight over the validation criteria and process for the TWC
follow-on questions, answers, and instructions (Q/A/I) dataset validation.
4.6.1
TWC message Dataset Validation Principles
The TWC Dataset Validation Panel will ensure that all TWC follow-on Q/A/I messages adhere to
the principles outlined below.
In addition, the Joint Committee and/or an Experts Working Group will consider these principles
when reviewing proposed changes to the initial questions and answers.
These principles include that the Q/A/I messages:
a) be related to safety of life to align with the Programme's mission;
b) use simple phrasing that eases translation among languages;
c) allow for efficient exchange of TWC messages between beacon users and first
responders;
d) not be discriminatory;
e) be as short as possible; and
f) be direct and affirmative messages.
4.6.2
TWC message Dataset Validation Process
The validation of a new release of the follow-on part of the Q/A/I dataset will be performed by a
TWC Dataset Validation Panel for the approval by the Parties.
The TWC Dataset Validation Panel shall be composed of experts nominated by the Parties and the
TWC-SPs and will be supported by the Secretariat.

4-14
C/S R.025 - Preliminary Issue A

The TWC Dataset Validation Panel should be a permanent body, and appropriate amendments to
document C/S P.011 should be developed.
The complete review process of dataset updates is intended to be an expedited process completed
within [TBD] months.
The process begins with either Participants (i.e., Parties, user states, ground and space segment
providers, per document C/S P.011), observers of the Cospas-Sarsat Programme, or SAR Users
submitting a proposal for an update to the dataset to the appropriate TWC-SP.  The TWC-SP will
consolidate proposed updates as needed, solicit concurrence for the proposed update from their
community of SAR Users as appropriate, and forward the mature proposal to the Programme, via the
Secretariat, for validation.
On receipt of a proposal for an update to the follow-on questions/answers and instructions to a
dataset from a TWC-SP, the Secretariat will circulate the proposal to members of the TWC Dataset
Validation Panel for review. Once the panel members have confirmed their concurrence with the
proposed update, the Secretariat will forward the proposed update to the Party Representatives for
approval (typically provided within 14 days). On approval of the update, the Secretariat will advise
the TWC-SP that originally consolidated and submitted the updates, as well as all other TWC-
SPs, and initiate the processes to update the document C/S [TBD] with dataset in each of the
official Programme languages, post it to the Cospas-Sarsat website and inform Participants of the
update.
Once a new or updated follow-on TWC message dataset has been validated, approved, and
documented in document C/S [TBD], the Secretariat will forward a request for an updated translation
to any National Administrations that have provided official translations of the dataset. Once these
translations are received, the Secretariat will document all translations in document C/S [TBD], post
these updates to the Cospas-Sarsat website, and inform Participants of the update.
4.7
Beacon Design Guidelines
The beacon design shall adhere to the requirements defined in document C/S T.018 and other
international standards, as appropriate. Figure 4-7 provides two examples of the spectrum of methods
of implementing a TWC beacon user interface into Second Generation Beacons (other methods of
implementation may also be possible).

4-15
C/S R.025 - Preliminary Issue A

User Interface on
3rd Party Device
C/S Beacon
User
Indications
Library ID
Question &
Answer Data
Library ID and
Q&A Database
User I/F App
Refinements
C/S Beacon
User
Indications
User
Interaction
Library ID and
Q&A Database
Question &
Answer Data
Display System
User Controls
Library ID and
Q&A Database
TWC Fully Integrated
Into C/S Beacon
TWC Minimally
Integrated Into C/S
Beacon
Figure 4-7: Possible Spectrum of TWC Integration of Functionality into Beacons
- END OF SECTION 4 -

5-1
C/S R.025 - Preliminary Issue A

5.
TWC IMPLEMENTATION PLAN
To the extent possible, the Programme intends to align the introduction of an optional TWC
capability with the introduction into operations of SGBs.
The plan described in this section refers to the Galileo RLSP plan for the introduction of SGB
TWC capability.  Other RLSPs plans might be added to this document in the future.
5.1
Assumptions and Dependencies
The successful implementation of the Two-Way Communication (TWC) system in the Cospas-
Sarsat Programme hinges on several critical assumptions and dependencies. These are pivotal in
guiding the project's direction and ensuring its feasibility and effectiveness.
- Operational Capabilities of Beacons: It is assumed that the beacon user segment will be
based on the roll-out of SGB devices and that manufacturers and labs will be capable of
respectively producing and testing the optional capability thus producing type approved
beacon models.
- Coverage: The TWC functionality, as is any other Cospas-Sarsat function, is intended to be
provided globally (and is further described in Section 6.4). However, as TWC is an optional
capability, some RCC/SPOCS might choose not to establish interactive communications
with compatible users in distress.
- Ground Segment: The TWC will entail changes across key System components (e.g.,
MEOLUTs and/or MCCs). This plan assumes that such changes will not be major, and will
be primarily focussed on the MCCs, but represents an important System evolution
introducing the distribution of RLS Type 3 and therefore should be implemented by the
ground segment providers in a timely manner (as endorsed by the Council).
In addition, a new interface and associated infrastructure, will need to be commissioned and
put into operation by the relevant TWC Service Providers (TWC-SP).
- Programme Management: As mentioned above, the rollout of the TWC is heavily
dependent on the collaborative efforts of all the involved stakeholders, including beacon
manufacturers, the Cospas-Sarsat Secretariat, ground and space segment providers, TWC
service providers, national Administrations, as well as SAR operational personnel. Their
coordinated efforts are essential to ensuring that the new functionality of TWC conforms to
a common architecture, complies with agreed performance standards, and does not harm the
current System in operations. In view of this, the plan foresees TWC-focused EWG
meetings, as appropriate, to consolidate any intersessional work performed.

5-2
C/S R.025 - Preliminary Issue A

5.2
Implementation Steps
The deployment of the TWC is a complex matter requiring the cooperation of multiple stakeholders,
and a step-by-step process is the most suitable path for a successful implementation.
Therefore, the plan proposed follows a segmented and distinct, well-defined three phases designed for
a gradual delivery of TWC added value at each stage, while carefully managing the risks and allowing
the multiple stakeholders to progress on their assigned development areas. The three phases consist of:
a TWC Pilot Capability, the Initial Operational Capability (IOC) and the Full Operational Capability
(FOC). These steps delineate the development and validation, the provision of initial TWC data to
SAR providers, and the full compliance to the concept of operations.
The necessity, added value (goals), criteria, required changes, and anticipated challenges are further
described by phase in the sections below.
5.3
TWC Pilot Capability
The TWC Pilot Capability will provide a test environment allowing early access to a subset of the
TWC-SP capabilities. Such phase should be used as driving mechanism to develop and test the
necessary TWC system integration activities within the Cospas-Sarsat Programme leading to the
TWC IOC.
Objective: This Phase's main objective is the deployment and validation of an early version of the
TWC Service, which will:
a) include the development of a test plan for the TWC system which defines success criteria;
b) evaluate all aspects of the TWC data flows, and confirm the expected performance levels and
support the development, and successful execution, of a system test of the TWC;
c) allow SAR authorities to get acclimated to TWC by enabling them to begin preparations for
operational deployment;
d) establish a feedback loop, capturing operational and system inputs essential for refining the
TWC implementation, its operational concept and Service provision;
e) engage beacon manufacturers, aiding them on the development and the testing of their
respective TWC-capable beacons as well as assisting on the type approval process;
f) allow verification of TWC scenarios, analysis of the performance, security and overall
effectiveness for SAR operations;
g) refine C/S System documents if required by the validation;
h) define system testing procedures and success criteria in accordance with the plan developed in
a) above; and
i) perform System testing and report; the successful outcome for system testing shall be a
condition for progressing to the IOC phase.

5-3
C/S R.025 - Preliminary Issue A

Conditions:
a) Provision of the required TWC-SP infrastructure including interface to an associated RLSP
as shown in Figure 2.1.
b) The implementation of the relevant changes by at least the MCC associated with the TWC-
SP for the TWC dataflow from MCC to TWC-SP.
c) The implementation of relevant changes for the TWC dataflow from at least one MCC to
at least one SAR authority.
d) The availability of an SGB TWC-enabled prototype beacon but only for the end-to-end
demonstration and evaluation.
5.4
Initial Operational Capability (IOC)
The IOC phase constitutes the first TWC operational capability implemented by the Programme,
which shall include the ability to operationally relay the TWC Q&A data to the relevant SAR
authorities and TWC-SP in a limited geographical area and the use of an agreed dataset of
questions and answers, based on type-approved beacons. During this phase, provision of the TWC
service might be limited geographically to those regions where administrations have committed to
making appropriate changes to their ground segment and perform the required actions in order to
enable the relevant national SAR authorities to participate in the provision of this service.
Initial operational capability is the declaration by the Cospas-Sarsat Programme that the System is
capable to provide reliable SGB data and that alert data (including from a TWC beacon) is being
distributed operationally between all data distribution regions. IOC is based on a Galileo L-band
space segment, a partial TWC capable ground segment, and completion of the TWC Pilot
Capability Phase. The MEOSAR SGB system shall provide global alert coverage for the TWC
IOC phase.  The distribution of TWC messages from the TWC-SP may be limited in geographical
area.
Criteria for SGB-TWC IOC:
a) The MEOSAR SGB System must be at IOC or FOC.
b) Operational TWC-SP infrastructure (e.g., SAR User Interface, Interface to MCC
Associated with the TWC-SP, RLSP, TWC RLM supported, etc.).
c) An approved Q/A/I dataset must be available in at least English.
d) The ability to type-approve a TWC-SGB.
e) Completion of the approved System Testing for SGB-TWC.
f) Regionally available based upon National declaration of TWC processing capability and
acceptance of SGB-TWC coding in beacons with country ID (MID) (documented in C/S
S.007).

5-4
C/S R.025 - Preliminary Issue A

5.5
Full Operational Capability (FOC)
[Full operational capability is the declaration by Cospas-Sarsat that the TWC service should
be considered fully operational. At FOC the TWC service satisfies all requirements defined by
Cospas-Sarsat and the TWC-SP, including those contained in document C/S A.003. This
ensures that sufficient space and ground segment components have been commissioned in
accordance with Cospas-Sarsat requirements. The MEOSAR SGB system shall provide global
coverage for the FOC phase.]
[Criteria for SGB-TWC FOC:
a) All IOC criteria is met
b) Adopted Q/A/I dataset is available in the 3 Programme languages
c) Global SGB coverage with sufficient TWC processing by the Ground Segment for
distribution]
- END OF SECTION 5 -

6-1
C/S R.025 - Preliminary Issue A

6.
TWC HIGH LEVEL REQUIREMENTS
The objective of this section is to define a minimum standard applicable to all TWC services (all
TWC-SPs). The performance of the TWC service is ultimately limited by the performance of the
elements of this service, i.e., MEOSAR forward and GNSS return links and the performance of
TWC-SP and the TWC SGB.
6.1
Integrity
The
probability
of
processing
anomalies
(i.e.,
an
error
in
the
displayed
question/answer/instruction) from a beacon to SAR service shall be less than [10.0^-04] and from
SAR service to beacon shall be less than [10.0^-04].
6.2
Availability
The TWC service is considered available when all TWC functions are performed with the defined
integrity and within the defined latency performance.
The TWC service shall be available [TBD %] of the time (including the Cospas-Sarsat and TWC-
SP contributions evaluated at [TBD %] each), over any one-year period.
6.3
Latency
The time from selection of answers by the beacon user to the display of these answers on the TWC-
SP interface for the SAR authorities shall be shorter than [TBD] minutes [TBD] percent of the
time in the first 60 minutes of beacon activation and [TBD] minutes [TBD] percent of the time,
thereafter.
The time from the transmission of questions/instructions by the SAR authorities on the TWC-SP
interface to the display of these questions/instructions on the beacon display shall be shorter than
[3] minutes [90] percent of the time assuming the beacon GNSS receiver is active and nominal
reception with a clear sky view.
Once the first [180] minutes after activation has past, the time from the transmission of
questions/instructions by the SAR authorities on the TWC-SP interface to the display of these
questions/instructions on the beacon display shall be shorter than [50] minutes [90] percent of the
time assuming the beacon GNSS receiver is active for [15] minutes every hour with nominal
reception and a clear sky view.

6-2
C/S R.025 - Preliminary Issue A

6.4
TWC Coverage
TWC coverage is a characteristic of a service provided by the Cospas-Sarsat Programme and a
TWC service provider introduced to ensure that the two way communication between a user with
a TWC-capable beacon and SAR personnel is provided at established performance levels in a
defined geographic area of the globe.
The Cospas-Sarsat Programme intends to provide global 406 MHz forward link alert coverage for
SGB TWC capable beacons.
The constellation of satellites used by a TWC service provider for the GNSS return link service
defines the coverage service region for that TWC SP.
It is anticipated that TWC coverage at FOC should be global for each Service Provider.
6.5
Security
The SAR TWC Interface service will be limited to registered users. Access will be controlled by
user ID and authentication credentials.
6.6
Archiving
The TWC service provider should maintain an archive in accordance with local regulatory
requirements.
- END OF SECTION 6 -

A-1
C/S R.025 - Preliminary Issue A

ANNEX A - EXCHANGE MESSAGE SCENARIOS
[To be updated]
[The beacon will exchange information with the SAR authorities via FLAMs (Forward Link Alert
Messages) and TWC Type-3 RLMs (Return Link Messages) that will contain the Questions,
Answers and Instructions. The Initial Questions are displayed automatically when the beacon is
triggered. The follow-on questions are selected by the SAR authorities and sent by the TWC-SP
to the beacon via a GNSS signal.
Furthermore, beacon and TWC-SP exchange acknowledgements in order to indicate the reception
of previous messages. Figure A-1 shows a high-level representation of the operating concept.]
Figure A-1: Summary of the data exchange between SAR authorities and beacon
[Five distinct user cases are presented and described below:
- The user activates the beacon and answers to the initial questions (see Figure A-2)
- The user answers the follow-on questions asked by SAR authorities (see Figure A-3)
- The user does not immediately answer the follow-on questions (see Figure A-4)
- The user receives information or an instruction message (see Figure A-5)
- The user activates the beacon and does not answer any initial question (see Figure A-6)]

A-2
C/S R.025 - Preliminary Issue A

Figure A-2 - Answers to initial questions
[To get an idea of the time scales involved in these scenarios, we can make the following
assumptions. The best-case full loop time, with no delays anywhere, is around 2 minutes. However,
it is likely that the transmission of an TWC Type-3 RLM and its successful decoding at beacon
level will not be immediate, thus a full loop for a given question and answer will probably be of
the order of 4 - 5 minutes, and could be more than this, especially after the first 30 minutes of
beacon operation.
In order to indicate the establishment of the TWC link to the user and to transmit information as
soon as possible, no position confirmation is required for the MCC to send data to the TWC-SP or
to the SAR Authorities.
For all the Figure in this Section, the legend that applies is the following:
1st case (Figure A-1): The user activates the beacon and answers to the initial questions
The user triggers its beacon and sends a FLAM containing the information on the TWC capability.
The TWC capability triggers the transmission of a TWC Type-3 RLM Acknowledging the alert,
without waiting for position confirmations that will be acknowledged by the beacon upon
reception, on the next transmitted FLAM.]

A-3
C/S R.025 - Preliminary Issue A

[Meanwhile, the user has the possibility to answer the initial questions. Once the user answers to
the first question, the appropriate Rotating Field of the FLAM will be updated with the answered
question(s) and their answer(s).
Upon reception by the TWC-SP, the SAR Authorities can visualize the answers on the SAR TWC
interface or equivalent while receiving the information from the MCC\*. The TWC-SP sends to the
beacon an acknowledgement of reception of the answers (TWC Type-3 RLM ACK to answer) in
the next RLMs via Galileo SIS.
The beacon receives the acknowledgement of its initial answers reception by SAR authoritiesand
if no more questions or instructions are waiting in the queue, the beacon shall transmit a FLAM
with a beacon feedback to the last TWC Type-3 RLM ACK. The FLAM continues through the
forward link pipeline and a single alert is transmitted to the TWC-SP.
Finally, after this new reception of the FLAM with beacon feedback to the last TWC Type-3 RLM
ACK, the TWC-SP acknowledges the reception by the beacon and stops the RLM transmissions.]
Figure A-3 - Answers to follow-on questions from SAR Authorities

A-4
C/S R.025 - Preliminary Issue A

[2nd case (Figure A-3): The user answers to follow-on questions from SAR Authorities
Following the first case, the SAR Authorities can now select a set of follow-on questions on the
SAR TWC interface and generate TWC Type-3 RLM transmission requests via the TWC-SP. The
TWC Type-3 RLMs will contain the binary ID of each question.
The beacon receives the questions and the user can answer them by choosing among predefined
answers. The questions and answers binary IDs are encoded in the RF of the FLAM. Upon
reception by the TWC-SP, the SAR Authorities can visualize the answers on the SAR TWC
interface.
On the TWC-SP side, a reception acknowledgement to the answered questions is sent.  At the same
time, by the TWC-SP. After that, the TWC-SP stops the repetition of the questions in the TWC
Type-3 RLM.
The beacon receives the acknowledgement from the TWC-SP and sends a beacon feedback to
the TWC Type-3 RLM ACK in a FLAM.
Finally, after its journey in the forward link pipeline, the FLAM is received by the TWC-SP that
stops the new transmission of TWC Type-3 RLMs upon new reception of a beacon feedback.]
Figure A-4 - Delayed answers from the user

A-5
C/S R.025 - Preliminary Issue A

[3rd case (Figure A-4): The user does not immediately answer the questions
Similarly, to the second case, the SAR Authorities select a set of questions that are encoded in
TWC Type-3 RLMs. The TWC Type-3 RLMs are sent to the beacon via Galileo SIS.
If the questions are received and shown at the beacon level but that for any reason the user cannot
answer them for the time being the beacon sends the FLAM acknowledging the reception of the
questions (beacon feedback to the TWC Type-3 RLM for questions). Upon reception by the TWC-
SP, the SAR authorities are notified that the user has received the questions but did not answer
them yet. The TWC-SP stops RLM repetitions.
When  the user eventually answers the questions,  the beacon updates the FLAM in order to now
include the answers.
Upon reception by the TWC-SP, after the forward link pipeline, the SAR authorities can visualize
the answers on the SAR TWC interface and the TWC-SP to the answers (TWC Type-3 RLM ACK
to answers) sends RLMs containing the reception acknowledgment (TWC RLM ACK).
The beacon receives the acknowledgement to the answers (TWC Type-3 RLM ACK to answers)
by the TWC-SP and sends its own acknowledgement, beacon feedback to the TWC Type-3 RLM
ACK, in the FLAM.
Again, after the forward link pipeline, the TWC-SP receives the acknowledgement and stops the
TWC Type-3 RLM transmissions.]

A-6
C/S R.025 - Preliminary Issue A

Figure A-5 - Instructions/information message
[4th case (Figure A-5): The user receives information or an instruction message
In this simpler case, the SAR Authorities want to send instructions or information to the beacon's
user. A TWC Type-3 RLM transmission by the TWC-SP is requested with the
instruction/information message encoded.
The beacon receives the TWC Type-3 RLM with an instruction and sends a FLAM with a beacon
feedback to the TWC-Type-3 RLM for the instruction.
Upon reception by the TWC-SP, SAR Authorities can visualize the reception acknowledgement
(beacon feedback) transferred by the TWC-SP on the SAR TWC interface and the TWC-SP stops
the TWC Type-3 RLM transmissions.]

A-7
C/S R.025 - Preliminary Issue A

Figure A-6 - User not answering initial questions
[5th case (Figure A-6): The user does not answer initial questions
In this scenario, the user triggers its beacon but does not answer the initial questions. The beacon
is acting like a non-TWC capable beacon and the SAR authorities still receive the necessary
information for the rescue.
The FLAM still requests an Type-3 RLM ACK to alert from the TWC-SP. The TWC-SP sends
the TWC Type-3 RLM to the beacon in order to acknowledge the alert, without position
confirmation. The beacon sends a beacon feedback to the TWC Type-3 RLM ACK to alert the
TWC-SP through the forward link pipeline. The TWC-SP stops the transmission of TWC Type-3
RLM ACK to alert.]
- END OF ANNEX A-

B-1
C/S R.025 - Preliminary Issue A

ANNEX B - EXAMPLE OF THE TWC DATABASE
[The figure XX below illustrates an example of the database with a portion of the current dataset.
The beacon user is first prompted with the question 0000001 "Number of people in distress?" and
can choose one of the following answers:


5-8
-
9-16
-
17 or more
-
Cancel Alert
If the beacon user chooses one of the first 7 answers [or skips the question], the question
corresponding to the ID in the column "Next Question" shall be displayed, which is the question
0000010 "Medicals: Do you need medical Assistance".
If the beacon user selects "Cancel alert" then the SGB Cancellation protocol shall be executed by
the beacon, without sending RF\#4 with the question ID 0000001 and the answer ID 1000
(corresponding to "Cancel Alert").
Another example; if the beacon user is being prompted with the question 0000011 "Nature of
distress: What is the nature of distress?" and the user chooses the answer 0001 "Water", the column
"0001 - Go to" indicates the subsequent question that shall be immediately displayed to the user,
which in this case is 0000100 "Water/Maritime: What is the distress situation?". [If the beacon
user skips this question, no other Initial Question shall be displayed as the column "Next Question"
is empty, Follow-on Question could be displayed if present in the stack.]
Continuing with the question 0000100, the user can choose any combination of answer(s) among
the following proposition, as indicated by the "Multiple-selectable answers" flag:
-
Man overboard
-
Fire/Explosion
-
Sinking/Flooding
-
Piracy/Security threat
-
Craft disabled
-
Trapped
-
I am lost

B-2
C/S R.025 - Preliminary Issue A

The combination of answers will be encoded in the Long format RF\#4 as indicated by the "Answer
format" flag.
Note that if the user chooses several of the 4 answers leading to question 001000 "Number of life
rafts in use?", this subsequent question will be displayed only once.
[Figure TBS]
Figure B-7 - Example of the CSV Database Format with a Portion of the Current
Database]

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