Simplified STDMA description:

1.

BACKGROUND

By equipping e.g. aircraft or vessels with a position determining device (e.g. a satellite receiver) which is connected to a digital time division multiplex radio link on VHF or UHF, the own position as well as that of other mobile units forming part of the system, can be presented on a graphical display. This is accomplished in such a way that all units forming part of the system are transmitting a short message with identity, position etc. The transmission is performed by Self-organizing Time Division Multiple Access in so called "time slots". These digital messages can also be used for a number of different applications, such as collision warning, air traffic services etc. This type of system can be used as a supplement to or, in some cases, even replace radar based systems, resulting in improved performance.

2.

PROBLEMS

One of the main problems is the system capacity, i.e. how many users that can be served by the system within a certain area without overloading the radio channel. Transmitting digital radio messages may be considered a well known technology, but a closer study will show that new methods are required to achieve the desired capacity in a fully operational system.

In order to allow an efficient use of time division, it is necessary that all units have a common time basis. The time slots must be very accurately defined and synchronized. As regards e.g. aviation applications, the synchronization requirement applies all over the globe as each unit can be part of a global "mosaic". Mosaic implies here that a user being a great distance off can be relatively close to another user being still further away and so on. For smaller areas a fixed base station can of course act as a "master" and by that synchronize the users. However, over e.g. the oceans this is not possible as the system is to operate autonomously in such areas.

A certain area will constantly be entered by new users while others will leave the area. Should several users enter the area at the same time, there is a risk of the same vacant time slot being selected by more than one user, which would result in a blocking of the position message.

A system with many users will of course have a capacity limit. One of the factors that affect the system is the reporting rate. To enable solving time critical situations involving a collision hazard, a high reporting rate is required, which will reduce the number of users.

Should a loss of the navigation satellites occur, the possibility to determine the own position will lapse. The reasons for loss of satellites or their signals can be several; e.g. intentional changes of codes in the event of an international crises arising. Another reason can be that the required clear view to the satellites momentarily is blocked by buildings or other such things. As the introduction of this type of guidance system may result in a total dependence on the satellites and on the organization managing and maintaining these, it is necessary to have an alternative method for position determination.

3.

SOLUTIONS

By receiving time signals from satellites, the positions of which are known, a global time basis can be produced in a very simple and inexpensive way. As the distance between the satellites and the different users varies, certainly the received time will be differing between the users. This, however, does not pose any problem as the own position as well as that of the satellite is known and thus also the distance to the time reference. It is then possible to compensate for the differences in propagation delay and by that bring about a global time basis having an accuracy of about 100 Ns. This type of time reference is known and is being used in connection with position determination by means of satellite navigation.

By synchronizing the communication equipment with the globally synchronized satellite time, the communication can be carried out in a very effective way as, due to the accurate synchronization, the time slots between the messages can be minimized. The principle is also cost-effective as the satellite receiver anyhow is being used for navigation and position determination.

In autonomous transmission mode each user periodically (e.g. every fifth to eight minute) changes the independently allocated time slot for transmission. Information concerning slotchange is also included in each position report to form the Self-organizing TDMA datalink. This prevents two or more users systematically to block each other's transmission. This is of special importance when users arrive from distant areas where a quite different traffic situation prevailed with other or similar time slot allocations.

By storing and updating information concerning all audible users in the communication system's computers (at each user), the present distance to each user can be calculated. This implies that at autonomous transmission the interval between the messages may be extended if the distance to the nearest user is long and thus not critical. If also information regarding speed and direction is used, the system will be further improved. Users that are moving away from each other are not critical even if the distance between them is short. In a corresponding way the time between the transmissions is shortened in critical situations. By this adaptive reporting the total system capacity as well as the performance can be considerably improved.

The position messages are transmitted on the radio channel as asynchronous data packages consisting of start frames, user identity, position, speed etc. followed by a check sum and stop frames.

By the fact that the position messages are containing the transmitter position as well as the exact time for the transmission, these messages can be used to determine one's own position. By this method a second order of navigation can be achieved, should it for some reason not be possible to pick up the satellite signals. If position messages from fixed located base stations are used, only one available satellite is required to time synchronize the base stations. Should the base stations have their own accurate external time reference, there is no need for any navigation satellite at all, but the precision will be downgraded. In case of an external time reference being used at the base station, this can be synchronized by using the signals from one and the same TV satellite.

4.

PROTOTYPE OF A GNSS-TRANSPONDER

The GNSS-transponder prototype consists of a microprocessor board, radio board and a GPS board mounted in a H.F. shielded cartridge. The microprocessor board is fitted with an HD64180 microprocessor and a Siemens SAB 82525 (Note! version VA3) communication circuit. In and outputs are RS232 and RS422. The microprocessor board has a real time operating system (RTX) stored in an EPROM and the application programs stored in an EEPROM for easy updating. There is also a debugger for program development stored in the EPROM. The software is since long thoroughly tested.

The radio board consists of a transmitter, receiver and a GMSK (Gaussian Minimum Shift Keying) modulator/demodulator. The prototype's modulation method allows transmission rates of 9600 bps. The radio board has been custom designed for this project. For higher datarate (19200- 31500) another radio board can be used. However before changing the radio and modulation method a final decision from CIAO is required. The GNSS-transponder is fitted with power supply for 10-32 V DC.

NOTE! The modulation method, rate, frequency selection, output power etc. are independent of the GNSS-transponder principle and shall thus be adapted to the application areas. An advisable selection, fore the time being, is 9600 bps GMSK modulation (See appendix concerning radio specification).

The software consists of a number of modules which are combined for different applications and purposes.

5.

COMMUNICATION

5.1

Software

A number of different data blocks are generated and transmitted by means of the communication circuit. This circuit is also managing the generation of preamble startflag checksum and stopflag (in the following data block means only the contents of the block). When the block has been packed and transferred to the circuit, the transmitter is switched on by setting RTS. At the same time as RTS is set, transmission of alternating binary digits during 5 byte is initiated (preamble). The prototype simulates this by transmitting a short HDLC block corresponding to 5 byte. The reason is that the transmitter shall start up and the receiver shall be adjusted to the center frequency band of the carrier. These bits are thus not data carrying. The transmission rate shall be 9600 bps or higher. When switching from transmission to reception the prototype receiver will be "deaf" for about 1 mS due to the design. The transmission time is limited to about 200 mS. The reason for the automatic limitation is to prevent transmission in the event of malfunction.

The informat from the GPS receiver to the microprocessor of the mobile radio link is at present preliminary and will be established later on. For tests, however, the same format can be used as that between radio and the basestation. A simulator using the same format is available for test purposes.

Position messages picked up from other mobiles are transmitted out to a serial port for presentation on a digital map. Also the own identity and position are included. The format is the same as that of the control center.

The software in the radio computer consists of a real time operating system. In the operating system five different programs with dynamic priorities are run as follows.

Prog. 1 Reading and decoding data from the mobile's or the control center's computer.

Prog. 2 Reading and decoding data from the GPS receiver.

Prog. 3 Generation of messages and transmission and control of the radio.

Prog. 4 Reception and decoding of data messages from the radio.

Prog. 5 Generation and sorting of tables of current radio traffic. The program is also removing timeout units.

5.3

The radio protocol.

The format between the radio devices is not definitely specified. It is of paramount importance that the length of the messages is kept as short as possible. Normally the position report messages are transmitted at 9600 bps in 4 consecutive time slots (or 2 slots for short ground positions reports) of 6.666 mS (1 min/9000 = 6.666 mS). However, some messages (ex. DGPS-corrections) take up more then 4 time slots. The time slots are within a 60 s frame; thus there are totally 9000 time slots. The frame and the slots are synchronized to UTC time through the GNSS receivers or, if there is no GNSS receiver or should it be unserviceable, to synchronized messages from other mobiles or base stations (slaved synchronization). The time slot 0 starts at each minute.

The first 8 bits of the message are defining the type of message. The types can be divided into two main groups. Type 1 to 127, which are transmitted from mobiles and type 128 to 255, which are transmitted from control centers.

Type 1 to 127 can be further divided into two groups, type 1 to 63, which are transmitted from autonomous mobiles and type 64 to 127, which are transmitted from mobiles controlled by a base station. In mobiles as well as in the control center's radio computer tables containing data about all radio traffic are stored. These tables include data such as ID, time slots used at the latest transmission from the unit, position, speed etc. The tables are automatically updated and timeout units are removed. Also stored is a 2250 (or 4500 if higher datarate is used) by 8 bit's table showing which time slots are being used. Each time a position message is received a "timeout" of 5 minutes is entered in the table. This implies that the time slot is occupied for 5 minutes or until the user changes time slot by signalling with "time offset" (see description of message type 1). In order to prevent collisions between position reports from different users, the mobiles automatically change time slots at regular intervals. The change takes place after an evaluation of which time slots that are not being used.

The message length has been limited to 64 byte data. At 9600 bps a time slot contains 5 byte synchronization + 1 byte start frame + 1 byte extended start frame (HDLC address) + 20 byte data + 2 byte CRC + stop frame + 2 byte pause; together adding up to 32 byte. This is called a 20 byte standard data message and is used e.g. for position reports. The only exception is short ground position reports which is using only 3 byte synchronization and 1 byte pause.

NOTE! The HDLC format is using NRZI and "bitstuffing" which implies that should more than 5 zeroes come in sequence, a one is added. This means that the pause can be shorter than 2 byte. However, as the total time between information in two consecutive time slots is 46 bit (5 byte + 2 byte pause), this does not pose any problem.

For longer data messages, e.g. text messages, 4 or more time slots are used; for each additional time slot the message length can be extended by 32 byte. Thus eight time slots can contain as a maximum 52 byte data plus frames etc.

The synchronous data block is packed in groups of 8 bit (1 byte). Should e.g. a 25 bit's longitude be packed, it will be stored with bit 0-7 (the 8 least significant bit ) in the first byte, bit 8-15 in the next byte, bit 16-23 in the third byte and finally bit 24 (MSB) in the fourth byte bit 0 (LSB). When broadcasting, the most significant bit (bit 7) is transmitted first. Thus the longitude's bit are transmitted in the following order:

7-6-5-4-3-2-1-0-15-14-13-12-11-10-9-8-23-22-21-20-19-18-17-16-X-X-X-X-X-X-X-24.

5.4

The mobile's radio format.

5.4.1

The basic position report from a mobile is:

MMMMMMMM TTTTTTTT TTTTTTTT TTTTTTTT TTTTTTTT TTTTTTTT TTTTTTTT XXXXXXXX XXXXXXXX XXXXXXXX YYYYYYYY YYYYYYYY YYYYYYYY SSSSSSSY HHHHSSSS HHHHHHHH AAAAAAAA TTTTAAAA CCDULLTT 00000000

8 bit M identification of message type (type 1 autonomous mobile)

48 bit T mobile identification (8 characters of 6 bit each)

24 bit X latitude in 1/1000 min.(+-90 degrees, N=pos., S=neg.)

25 bit Y longitude in 1/1000 min (+-180 degrees, E=pos., W=neg.)

11 bit S speed in 2 kt stages (0-4095 kt)

12 bit H heading/direction in 1/10 degree (0-359,9)

12 bit A altitude in 16 ft stages (0 - 19,7 km)

6 bit   T   time marking of the position in seconds UTC (0-59 s) or 63 s, which means that the GPS receiver is not navigating

2 bit L climbing/descending, 0 = maintaining altitude, 1 = climbing, 2 = descending, 3 = GPS altitude not determined (2D-nav.)

(12 bit communication status in accordance with the following:)

1 bit U GPSSYNC 1 = the communication is GPS time synchronized

1 bit D DGPS 1 = differential GPS navigation

2 bit C SLOT TIMEOUT 0 = the last transmission in this time slot, then change to time slot in accordance with the time offset. 1-2 = 1 or 2 minutes left to change. 3 = 3 minutes or more left to change.

8 bit O time slot offset (+-127 or 128, which means offset greater than 127)

= 160 bit (20 byte)

In addition to this:

5 byte synchronization (001100110011 etc. for 4,166 mS)

1 byte start frame

1 byte HDLC address (used as extended start frame, Transparent Mode 1)

(20 byte data message as above)

2 byte checksum

1 byte stop frame

2 byte pause (no transmission for 1.666 mS at 9600 bps)

= 256 bit (32 byte)

This implies that the total length of the message will be 32 byte (256 bit) which corresponds to 26.666 mS at 9600 bps.

The identification of the mobile (8 ASCII characters) is stored in the PROM (default) and is at startup copied to the RAM area. By that the identification may, as and if necessary, be modified from the navigation computer if such one is connected. The last byte of the message is the time offset, which is being used to make reservation for a new time slot for transmission in autonomous mode. At the change of time slot, the time offset in the message will indicate how many time slots forwards or backwards that the message will be moved when the change takes place. In this way other mobiles will be informed about which time slots will be used in the future; this means that conflicts and blockings can be prevented. The offset can be +/- 127 multiplyed by 4 time slots (in increments of 4 time slots) as a maximum. Should the message be moved more than 127 * 4 time slots, the offset is set to 128. The offset is thus used to reserve new time slots and to release old ones. This technology is called the Self-organizing TDMA.

Should an autonomous mobile catch that a base station controlled transmission is going on, i.e. message types with numbers higher than 63, use of the nearest time slots shall, as far as possible, be avoided. By that uncontrolled mobiles are prevented from blocking base station wishing to extend a sequence.

5.4.2

Message type 2 is identical to type 1 except that crypto is used for byte 8 (latitude) to byte 18 (4 bit UTC time and 4 bit altitude).

NOTE! Byte 1 (message type) to 7 (identification) and byte 19 to 20 are sent clear. The reason is that these bytes are used to coordinate communication for all users (clear and encrypted).

Clear and encrypted messages can be mixed, however only crypto equipped users can decode and output position messages of both types. Crypto can be switched on and off by command. Typical application are police, costgard, military aircraft etc.

5.4.3

The message type 65 (base station controlled mobile) is, except for the message identification and the time offset, identical with type 1. The time offset is replaced by "timeout" in minutes for transmission controlled by a base station. Should no new allocation from the base be made, the mobile will cease to reply when the time is up and will change to autonomous transmission.

A polled mobile GPS transponder which is transmitting positions type 65 can, should need arise, (e.g. sudden near collisions or changes of speed vectors occurring) transmit occasional autonomous positions of type 1. The base station's attention will then be called so that it can change the transmission interval. In such nonrepetitive transmission, the SLOT TIMEOUT is set to 0 and the time offset to 128, in order not to reserve the time slot.

5.4.4

Message type 66 is identical to type 65 except that crypto is used (see message type 2).

5.4.5

Transmission of messages mobile - mobile or mobile - control center is carried out as message type 32, which is acknowledged with message type 33. For public messages (the identification has no importance) e.g. emergency and warning messages, type 34 is used. The messages are transmitted in the form of 6 bit packed ASCII characters. The text message is limited to 63 ASCII characters as a maximum. This is limited by 1 byte ID + 6 byte transmitter + 6 byte receiver + 1 byte length/option + 63 ASCII characters x 6/8 (=47.25) byte text, in all 62 byte which corresponds to 3 time slots at 9600 bps. Should a longer text message be required this can be achieved by transmitting several blocks and using the option bits.

48 bit transmitter identification (8 characters of 6 bit each)

48 bit receiver identification (8 characters of 6 bit each)

8 bit ID (32 or 34 or, from a control center, 160 or 162)

2 bit option (e.g. to be continued)

6 bit message length X (X is given in number of ASCII characters)

6X bit message (X = message length after packing)

Acknowledgment of a received text message (see message type 32 and 160)

8 bit ID (33 and, from a control center, 161)

48 bit transmitter identification (8 characters of 6 bit each)

48 bit receiver identification (8 characters of 6 bit each)

2 bit status, set equal to the transmitted option (see ID 32)

5.4.6

Inquires about UTC time can be made with message 62 from a mobile or 190 from a control center. The device asked will reply with message 63 or 191 respectively. Time inquires can be used for synchronization if one for some reason is lacking own GPS time e.g. due to GPS receiver malfunction. After that a message 62 (time inquiry) has been transmitted, the possibility to make a new inquiry is blocked for randomly 5-12 seconds. The reason is to prevent chaos if several users transmit time inquiries.

8 bit ID (62 and, from a control center, 190)

48 bit transmitter identification (8 characters of 6 bit each)

48 bit receiver identification (8 characters of 6 bit each)

Reply to a time inquiry:

8 bit ID (63 and, from a control center, 191)

48 bit mobile identification (8 characters of 6 bit each)

24 bit latitude in 1/1000 min. (+- 90 degrees, N=pos., S=neg.)

25 bit longitude in 1/1000 min. (+-180 degrees, E=pos., W=neg.)

5 bit UTC time hours (0-23)

6 bit UTC time minutes (0-59)

12 bit number of the time slot used for the message (0-2249)

12 bit altitude in 16 ft stages (0-19.7 km)

6 bit UTC time seconds (0-59)

2 bit climbing/descending, 0 = altitude maintained, 1 = climbing, 2 = descending, 3 = GPS altitude not calculated (2d nav.)

1 bit GPSSYNC 1 = the communication GPS time synchronized

1 bit DGPS 1 = differential GPS navigation

4 bit UTC month (1-12)

5 bit UTC date (1-31)

1 bit option

= 160 bit (20 byte)

If the time is transmitted from a mobile unit the position will be extrapolated to the factual time for the transmission. The reason is that time can be used for position determination in a future system. The difference between the time message and the position message is that speed and heading/ direction are replaced by time and that the bits for change of time slot are replaced by date. As a base station does not move or change time slots, a message type 191 can suitably be transmitted from base stations with regular intervals to be used for position determination when there is no GPS.

NOTE! Should a GNSS transponder not be synchronized to own GNSS time, but external, all received time messages are checked. If the time does not tally, three consecutive time messages are required to result in a resynchronization. The reason is to prevent synchronization on an erroneous time message. This, however, does not apply if a time inquiry has been made.

5.4.7

The short ground position report (requested and assigned by a base station) from a mobile is:

TTTTTTTT TTTTXXXX XXXXXXXX XXXXYYYY YYYYYYYY YYYYYSSS SSHHHHHH

12 bit T mobile binary identification (0-4095)

16 bit X latitude in 1/1000 min.(MSB is not transmitted)

17 bit Y longitude in 1/1000 min (MSB is not transmitted)

5 bit S speed in 2 kt stages (0-63 kt)

6 bit H heading/direction in increments of 5.625 degree.

= 56 bit (7 byte)

In addition to this:

3 byte synchronization (001100110011 etc. for 2.500 mS)

1 byte start frame

1 byte HDLC address (used as extended start frame, Transparent Mode 1)

(7 byte data message as above)

2 byte checksum

1 byte stop frame

1 byte pause (no transmission for 0.83333 mS at 9600 bps)

= 128 bit (16 byte)

This implies that the total length of the message will be 16 byte (126 bit) which corresponds to 13.3333 mS at 9600 bps. The link capacity is approximately 70 position reports per second at 9600 bps and 140 per second at 19200 bps.

NOTE! The 8 bit identification of message type is not used for short position reports. However the message type can be identified by message length if CRC is received correct. This message is the only used short message and can therefore be special treated.

The binary identification (1-4095) of the mobile is assigned from a base station by using the 8 ASCII characters normally used as identification. The assignment of binary ID is made by sending message 129 from the base station.

5.4.8

Inquires about software and hardware can be made with message 60 from a mobile or 188 from a control center. The device asked will reply with message 61. The messages can be used by system operators to verify that units has appropriate functionality and revision level. After the message 60 (inquiry) has been transmitted, the possibility to make a new inquiry is blocked for randomly 5-12 seconds. The reason is to prevent high link load if several users transmit inquiries.

MARK! The inquiry message 60 is only implemented in units intended for test and service. The reply message 61 is implemented in all inits.

8 bit message type (60 and from a control center 188)

48 bit transmitter identification (8 characters of 6 bit each)

48 bit receiver identification (8 characters of 6 bit each)

8 bit requested submessage type

Reply to an inquiry:

8 bit message type (61)

48 bit mobile identification (8 characters of 6 bit each)

8 bit submessage type

(12 bytes submessage)

Submessage 1:

16 bit system manufacturer identification code

0-99 = Swedish (10 = Swedish Space Corporation, 20 = Celsius Tech etc.)

100-199 = Danish

200-299 = USA

300-399 = German

400-499 = French

500-599 = British

8 bit communication processor hardware (manufacturer code)

16 bit communication processor software revision (manufacturer code)

8 bit GPS receiver hardware (manufacturer code)

8 bit GPS receiver software revision (manufacturer code)

8 bit radio hardware (manufacturer code)

8 bit radio software revision (manufacturer code)

8 bit radio output power (W)

16 bit message standard level (international standard specification)

= 160 bit (20 byte)

Submessage 2-255 not yet specified.

5.5

The radio format from a base station.

5.5.1

The message type 129 (128 + 1) is allocation of time slots from the control center to a mobile. Each control center is allocating time slots from a series of its own which starts e.g. on an even 500 number. By this it is possible to identify who is controlling the mobile. The mobile replies with message type 65 or 66. The control center shall allocate time slots in such a way that space is left for uncontrolled traffic, e.g. new devices coming in.

8 bit identification of message type (type 129 allocation)

48 bit transmitter identification (control center) (8 characters of 6 bit each)

48 bit receiver identification (mobile) (8 characters of 6 bit each)

16 bit allocated binary ID number (1-4095) for short ground position reports (0 means that short position reports are not used)

16 bit first allocated time slot (2 LSB = 0 if 9600 baud)

16 bit time increment (time slot 2 = first + the time increment)

4 bit number of minutes transmission (0 = stops after this minute)

4 bit radio channel (normally 0)

= 160 bit (20 byte)

5.5.2

The message type 130 (128 + 2) is used for datalink and system management. This message is periodically broadcasted from base stations to mobile units. Normally base stations are alternating between this message and message 191 (time-position).

MMMMMMMM TTTTTTTT TTTTTTTT TTTTTTTT TTTTTTTT TTTTTTTT TTTTTTTT SSSSSSSS ........ ........ ........ ........

8 bit M identification of message type (type 130 datalink management)

48 bit T mobile identification (8 characters of 6 bit each)

8 bit S submessage type (1= timeslot reservation, 2= other channels and frequencies in use).

= 160 bit (20 byte)

Submessage 1:

This message is used for timeslot reservation to ensure space for multiple base stations in an area.

MMMMMMMM TTTTTTTT TTTTTTTT TTTTTTTT TTTTTTTT TTTTTTTT TTTTTTTT 00000001 VVVVVVVV OOOOOOOO FFFFFFFF FFFFFFFF NNNNNNNN IIIIIIII IIIIIIII FFFFFFFF FFFFFFFF NNNNNNNN IIIIIIII IIIIIIII

8 bit V information valid for V minutes (time-out). If V=0 then remove reservation.

8 bit O optional bits (not used)

16 bit F first timeslot to reserve

8 bit N number of sequential timeslot to reserve or 0 no timeslot to reserve (reservation not in use).

16 bit I increment to repeat reservation block

16 bit F first timeslot to reserve

8 bit N number of sequential timeslot to reserve or 0 no timeslot to reserve (reservation not in use).

16 bit I increment to repeat reservation block

= 160 bit (20 byte)

Submessage 2:

Definition of other channels in use.

MMMMMMMM TTTTTTTT TTTTTTTT TTTTTTTT TTTTTTTT TTTTTTTT TTTTTTTT 00000010 IIIIIIII CCCCCCCC FFFFFFFF FFFFFFFF IIIIIIII CCCCCCCC FFFFFFFF FFFFFFFF IIIIIIII CCCCCCCC FFFFFFFF FFFFFFFF

8 bit I information type on this channel (0= general purpose, 1= ADSB and DGNSS, 2= AFIS, 3= exchange of clearance).

8 bit C channel to be defined.

16 bit F frequency in kHz (+100 MHz = 100-165 MHz) for defined channel.

= 160 bit (20 byte)

5.5.3 ***TBD ***Broadcasting of runway WAYPOIT from an airport:

MMMMMMMM TTTTTTTT TTTTTTTT TTTTTTTT TTTTTTTT TTTTTTTT TTTTTTTT XXXXXXXX XXXXXXXX XXXXXXXX YYYYYYYY YYYYYYYY YYYYYYYY SSSSSSSY HHHHSSSS HHHHHHHH AAAAAAAA TTTTAAAA CCDULLTT 00000000

8 bit M identification of message type (type ?)

48 bit T identification (8 characters of 6 bit each)

?? bit X latitude in 1/10.000 min.(+-90 degrees, N=pos., S=neg.)

?? bit Y longitude in 1/10.000 min. (+-180 degrees, E=pos., W=neg.)

?? bit A altitude in 1 ft increment

16 bit L localizer in 1/100 deg.

10 bit G glideslope in 1/100 deg. (0-10.32 deg)

12 bit R runway length in 1 meter (0-4095 m)

= 160 bit (20 byte)

5.5.4

The message types 171 and 172 mean transmission of DGPS data. Data are read from the same serial port as the GPS receiver in the mobile device and are stored in the radio computer of the control center. The mobile's computer converts these data to NMEA messages 671 and 672 respectively and transmits the message to the serial port of the GPS receiver. The channel is thus transparent.

8 bit identification of message type (type 171 and 172 DGPS)

2 byte DGPS binary ID (2-65535)

1 byte GPS hour

1 byte number of sat records (X)

2 byte Z count

5 byte X number of sat records (number of received satellites)

The message has a varying length depending on the number of satellites above the horizon. For 9 satellites the message length will be 52 byte (7+9*5) plus start frames, CRC etc. (10 byte) which means a message time of 51.66 mS at 9600 bps. Normally messages 171, 172 and 194 are transmitted in a sequence without interruption in order to save time.

5.5.5

The message type 193 (128 + 65) is single polling from a control center of one or more mobiles transmitting short position reports. The mobiles reply with message type 1 in any vacant time slot.

8 bit identification of message type (type 193 = polling)

48 bit transmitter identification (control center) (8 characters of 6 bit each)

16 bit polling number for mobile 1

16 bit polling number for mobile 2

16 bit polling number for mobile 3

16 bit polling number for mobile 4

16 bit polling number for mobile 5

16 bit polling number for mobile 6

8 bit option

= 160 bit (20 byte)

6.

Data format between base station and presentation computer.

The outformat from the microprocessor of the radio link to the presentation computer of the control system is a string of ASCII characters. The string starts with '$PRGPS', followed by the message and finally *## (## = checksum). The checksum is obtained by XOR of all bytes between '$' and '*'. (Note! '$' and '*' are not included). The format and the checksum are in accordance with the NMEA-0183 standard. The string is terminated by CR+LF. The data rate is normally 19200 (9600 is used only for test and trials). The checksum including '*' can be omitted but is to be recommended. Should compatibility with NMEA-0183 not be required, also 'PRGPS' can be omitted. The string will then start with merely a '$' character. In order to shorten the message length between the base device and the control center, 'PRGPS', is not normally used from the base device.

6.1.1

Position: $ITTTTTTTTXXXXXXXYYYYYYYSSSDDDZZZZZNTTS*##+CR+LF

where: I = type (1*ASCII HEX) 1= own GPS position, 2=incoming position

T = 8 characters identification e.g. SE-GNI_. (8* ASCII)

X = latitude in 1/1000 min. (7*ASCII HEX)

Y = longitude in 1/1000 min. (7*ASCII HEX)

S = speed in knots (3*ASCII HEX)

D = heading/direction in 1/10 degrees (3*ASCII)

Z = altitude in ft (5*ASCII HEX) FFFFF = land/see

N = navigation mode (1*ASCII HEX) 3 = 3-D nav. etc.

T = time for the position in seconds UTC (2*ASCII HEX)

S = climbing/descending, 1=up, F=down (1*ASCII HEX)

With 9600 bps this format is able to update about 21 active mobiles/second. This corresponds to 45.8 mS per message and is thus slower than the radio link, which can manage a position report in 26.6 mS. This implies that 19200 bps shall be used for an operational system.

The presentation is automatically generating labels with the text TTTTTTTT. If the name is in the list of the computer the label will be moved to the position X, Y. Should the updating be discontinued for 40 seconds the label will turn red and will after 3 minutes be erased.

Data link management ASCII message type 9 from radio message type 130.

$ITTTTTTTTS……………..*CK

where: I = type (1*ASCII HEX) = 9

T = 8 characters identification (8* ASCII)

S = submessage type (2* ASCII HEX) (1= timeslot reservation, 2= radio channels)

Submessage 1:

$9TTTTTTTT01VVOOFFFFNNIIIIFFFFNNIIII*CK

where: V = information valid for V minutes (time-out) (2* ASCII HEX)

O = optional bits (2*ASCII HEX) (not used)

F = first timeslot to reserve (4*ASCII HEX)

N = number of sequential timeslots to reserve (2*ASCII HEX) (0=no reservation)

I = Increment to repeat reservation block (4*ASCII HEX)

Submessage 2:

$9IIIIIIII02TTCCFFFFTTCCFFFFTTCCFFFF*CK

where: T = information type on this channel (2*ASCII HEX)

0= GENERAL PURPOUSE

1= ADSB AND DGNSS

2= AFIS

3= EXCHANGE OF CLEARANCE

C = channel to be defined (2*ASCII HEX)

F = frequency in kHz for defined channel (4*ASCII HEX) (add 100 MHz)

6.1.3

Status: $IHHMMSSAMVVEENN*##+CR+LF

where: I = type (1*ASCII HEX) OAH = own GPS status

H = hours GPS UTC (2*ASCII HEX)

M = minutes GPS UTC (2*ASCII HEX)

S = seconds GPS UTC (2*ASCII HEX)

A = number of satellites in use (1*ASCII HEX)

M = number of possible satellites (1*ASCII HEX)

V = VDOP * 10 (2*ASCII HEX)

E = EDOP * 10 (2*ASCII HEX)

N = NDOP * 10 (2*ASCII HEX)

6.1.4

GPS satellite status: $I,P1,A1,E1, S1,.s,P2,A2,E2,S2.s..........

where: I = type (1*ASCII HEX) 0CH (satellite 1-4) or ODH (satellite 5-8)

P# = Prn

A# = azimuth

E# = elevation

S# = S/N

6.1.5

Radio traffic status: $ILSNNNTTTTTTTT*##+CR+LF

where: I = type (1*ASCII HEX) OBH = radio status

S = radio status 0 = autonomous, 1 = polled (1*ASCII HEX)

L = radio channel load 0-100% (2*ASCII HEX) the load is average load during 60 seconds

N = number of devices on the radio channel (3*ASCII HEX)

T = ID of the latest base station (8*ASCII HEX)

6.1.6

Received text message from a mobile or a control center.

Text: $IAAAAAAAAOTTTTT.....TT*##+CR+LF

where: I = type OEH (1*ASCII HEX)

A = transmitter ID (8*ASCII HEX)

O = option 0 to 3 (1*ASCII HEX)

T = message (1 to 40 ACII)

6.1.7

Acknowledgment that a transmitted text message has reached the addressee

Text: $IAAAAAAAA*##+CR+LF

where: I = type OFH (1*ASCII HEX)

A = transmitter ID (8*ASCII)

S = status = earlier transmitted option (1*ASCII HEX)

6.1.8

Output of differential pseudorange correction data from a base station or a GNSS-Transponder. This message can be used in order to get the corrections via a telephone modem for remote use. The message $PRGPS,106,X selects or deselects this optional output message.

DGPS:

$PRGPS,671,0300,8C,5,5A0B,1801C5EF7C,990014F7D8,1401570BDF,0300690A3D,1D00E400BF*6F

or$PRGPS,672,.......

where: $PRGPS,671, is format identifier

0300, = DGPS binary ID (2-65535)

8C, = hours in the week

5, = number of satellites

5A0B, = seconds in the hour (LSB = 1 second)

180….. = HEX representation of the correction data for each satellite. Data is in RTCM Version 2.0 format, 40 bites per satellite including: PRN, correction, correction rate, scale bits, IODE.

6.2

The following commands can be transmitted from the mobile device or from the control center to the radio computer:

$PRGPS, 000+CR = Return from command mode and start normal operation.

This command is normally used if command $RPGPS,100 has been used.

6.2.2

$PRGPS,10 = Text message from a mobile or a control center.

$PRGPS,010,AAAAAAAA,0,TTTTT.....TT+CR+LF

where: A = receiver identification (8*ASCII), if ID is omitted e.g. $PRGPS, 010,,) the message will turn public i.e. it will reach all system users

O = option 0 to 3 (1*ASCII DEC)

T = message (1 to 40 ASCII)

6.2.3

$PRGPS,101+CR = connect the GPS receiver transparently

6.2.4

$PRGPS,102,TTTTTTTT+CR = set new transponder ID

Where: T = new ID (8 ASCII characters)

6.2.5

$PRGPS,103,NAVMOD,ALTITUDE+CR = set navigation mode

where: NAVMOD=1 Auto (2D + preset altitude or 3D-nav. if possible

NAVMOD=2 2D-nav. and preset altitude

NAVMOD=3 2D = last calculated 3D altitude or 3D-nav if possible

ALTITUDE=altitude in feet

6.2.6 $PRGPS,104+CR = inquiry about azimuth, elevation S/N the inquiry is replied to with the messages OCH and ODH.

6.2.7 $PRGPS,105,C = select/deselect crypto

where: C = 0 crypto off, C= 1-7 crypto on

C = 99 turn off transmitter. This command can be used for special applications.

6.2.8 $PRGPS,106,O

where: O = Differential correction output as a ASCII string. (0 = ASCII off, 1 = ASCII output)

$PRGPS,200,FFFFFF = Select radio freqoency.

Where: F = frequency in kHz (6 ASCII digits)

6.2.10 Input of differential pseudorange correction data from a telephone modem or a GPS-reference receiver.

DGPS:

$PRGPS,671,0300,8C,5,5A0B,1801C5EF7C,990014F7D8,1401570BDF,0300690A3D,1D00E400BF*6F

or $PRGPS,672,.......

where: $PRGPS,671, is format identifier

0300, = DGPS biary ID (2-65535)

8C, = hours in the week

5, = number of satellites

5A0B, = seconds in the hour (LSB = 1 second)

180… = HEX representation of the correction data for each satellite. Data is in RTCM Version 2.0 format, 40 bites per satellite including: PRN, correction, correction rate, scale bits, IODE.

6.2.11 Inquires about software and hardware can be made with message "$PRGPS,60,…". The device asked will reply with message "$PRGPS,61…". The messages can be used by system operators to verify that units has appropriate functionality and revision level.

MARK! The inquiry message "$PRGPS,60.." is only implemented in units intended for test and service.

$PRGPS,60,TTTTTTTT,S[*CK]

where: T = 8 characters identification of requested unit (8* ASCII)

S = requested submessage type (ASCII digits) 1= hardware/software status

Reply to an inquiry:

$PRGPS,61,TTTTTTTT,SSDDDDDDDDDDDDDDDDDDDDDDDD*CK

where: T = identification (8*ASCII)

S = submessage type (2 ASCII HEX)

D = 12 bytes submessage (12*2 ASCII HEX)

Submessage 1:

HHHH = system manufacturer identification code. HH=LSB, HH=MSB

0-99 = Swedish (10 = Swedish Space Corporation, 20 = Celsius etc.)

100-199 = Danish

200-299 = USA

300-399 = German

400-499 = French

500-599 = British

HH = communication processor hardware (manufacturer code)

HHHH = communication processor software revision (manufacturer code)

HH = GPS receiver hardware (manufacturer code)

HH = GPS receiver software revision (manufacturer code)

HH = radio hardware (manufacturer code)

HH = radio software revision (manufacturer code)

HH = radio output power (W)

HHHH = message standard level (international standard specification)

Submessage 2-255 not yet specified

7.1

Networking of base stations.

8.1.2 >D

8.1.3 >F

8.1.4 >U

8.1.5 >V

8.1.6 >S+

8.1.7 >H+

9.

SUMMARY

2. ICAO/FANS II/1-2 - INFORMATION PAPERS. (IP's)

3. ICAO/FANS II/3 WP 32 - DIFFERENTIAL GPS AT CHICAGO AND DALLAS FT. WORTH.

4. ICAO/FANS II/3 WP 56 - A COST-EFFECTIVE SOLUTION TO THE IMPLEMENTATION OF A WORLD-WIDE CIVIL AVIATION GNSS-BASED CNS/ATM AND ATN DATA LINK SYSTEM CONCEPT.

5. ICAO/FANS II/3 WP 61 - CONSIDERATION OF GLOBAL STANDARDS FOR ADS IN THE TERMINAL AREA AND ON AIRPORTS.

6. ICAO/FANS II/4 WP 21 - A COST-EFFECTIVE WORLD-WIDE GNSS-BASED CELLULAR CNS/ATM SYSTEMS CONCEPT.

7. ICAO/FANS II/4 WP 46 - SUMMARY OF STATEMENTS AND RECOMMENDATIONS RELATED TO GNSS-BASED CNS/ATM, ATC AND ATN DATA LINK ISSUES AND SOME TECHNICAL DETAILS AND SYSTEM OPERATIONS OF A PROTOTYPE GNSS-BASED CNS/ATM, ATC AND ATN DATA LINK SYSTEM CONCEPT.

8. ICAO/AMCP/3 WP 21 - GNSS-TIME SYNCHRONIZED SELF ORGANIZING TDMA VDL.

9. ICAO/AMCP/3 WP 22 - A TDMA ALTERNATIVE/COMPLEMENT TO CSMA VDL.

10. ICAO/AMCP/3 WP 23 - CAPACITY AND SAFETY CONSIDERATIONS OF ALTERNATIVE VDL's.

AMCP/3 WP 23, APPENDIX 1: - RELATIVE CAPACITIES OF GENERIC ADS PROTOCOLS, MITRE CORPORATION, STANLEY R. JONES, MARCH 1994.

11. ICAO/AMCP/3 WP 53 - REPORT ON AGENDA ITEM 8; VDL ENHANCEMENTS.

12. ICAO/AWOP WP 46 - HYBRID ILS/GNSS SYSTEM

13. ICAO/AWOP WP 49 - BERN REPORT APPENDIX F, DATA LINK.

14. ICAO/SICAS IP - THE NEXT GENERATION OF COLLISION AVOIDANCE SYSTEMS - THE GNSS TRANSPONDER AND IT'S SELF ORGANIZING TDMA DATA LINK.

15. ICAO ADSP/3 IATA WP - THE NEED FOR SURVEILLANCE BEYOND ADS.

16. RTCA PAPER NO. 376/92/ SC-159-368, MAY 1992 - AN INTRODUCTION TO THE GP&C SATELLITE NAVIGATION USER SYSTEM.

17. IEEE-MICROVAWE SYMPOSIUM MTT-S, ATLANTA, JUNE 1993 - APPLICATION OF GPS FOR ATC MISSIONS WITH SPECIAL EMPHASIS ON AUTOMATIC DEPENDENT SURVEILLANCE (ADS).

18. ICAO CNS/ATM SEMINARS IN NAIROBI AND CASABLANCA, AUGUST AND OCTOBER 1 - THE GNS-TRANSPONDER - A COST-EFFECTIVE WORLD-WIDE CNS/ATM, ATC, ATN DATA LINK AND COLLISION AVIODANCE SYSTEM CONCEPT.

19. VNIS CONFERENCE, OTTAWA, OCTOBER 1993. - TIME AUGMENTED GPS/DGPS IN SWEDEN.

20. RTCA TASK FORCE 2, WASHINGTON D.C., OCTOBER 1993. - "APPENDIX R - THE GNSS TRANSPONDER - A COST EFFECTIVE WORLD-WIDE GNSS-BASED CIVIL AVIATION, DGNSS, CNS/ATM, ATC, ATN DATA LINK AND COLLISION AVOIDANCE SYSTEM CONCEPT". (NOT PUBLISHED).

21. EUROCONTROL COMMITTEE OF MANAGEMENT WP, 1 NOVEMBER 1993;

- REPORT ON GNSS AND DATA LINK RESEARCH AND DEVELOPMENT RESULTS.

22. ECAC WORKSHOP ON SMGCS, 6-8 APRIL 1994;

- SUMMARY OF RUNWAY INCURSION SYSTEM EVALUATION, SWEDEN 1991;

- EXTRACTS FROM AIRNC's WP 32 TO THE ICAO FANS II/3 ON THE CHICAGO TRIALS, PRESENTED MAY 1993.

- THE GNSS TRANSPONDER; A COST-EFFECTIVE WORLDWIDE GNSS-BASED CIVIL AVIATION CNS/ATM, ATN DATA LINK, AND COLLISION AVOIDANCE SYSTEM CONCEPT.

AIR TRAFFIC CONTROL QUARTERLY, 1994;

- A GNSS-BASED TIME DIVISION MULTIPLE ACCESS DATA LINK (J. NILSSON AND H. LANS).

24. ICAO/SICAS PANEL WG 2, 20TH MEETING, STOCKHOLM, MAY 1994, ATTACHEMENT 5:

- BRIEF REPORT ON THE CARD SYSTEM DEMONSTRATION.

25. ICAO CNS/ATM SEMINAR, LIMA, JUNE 1994:

- DATA LINKS SUITABLE FOR CIVIL AVIATION APPLICATIONS IN AN OPERATIONAL CONTEXT?

- DATA LINK - THE KEY TO THE IMPLEMENTATION OF GNSS-BASED CNS/ATM SYSTEMS!

26. IATA GLOBAL NAVCOM, GENEVA, JULY 1994 - GNSS TRANSPONDER

27. ICAO CNS/ATM SEMINAR, CAIRO, AUGUST 1994; TWO PAPERS:

- DATA LINKS SUITABLE FOR CIVIL AVIATION

- THE GNSS TRANSPONDER AND IT'S WORLD-WIDE GNSS-TIME SYNCHRONIZED

- SELF-ORGANIZING TDMA DATA LINK.

28. PCA, SAUDI-ARABIA SYMPOSIUM ON THE FUTURE AIR NAVIGATION SYSTEM, JEDDAH, OCTOBER 1994;

- DATA LINKS SUITABLE FOR CIVIL AVIATION,

- THE GNSS TRANSPONDER AND IT'S WORLD-WIDE GNSS-TIME SYNCHRONIZED SELF-ORGANIZING TDMA DATA LINK.

29. US DOT/VOLPE CENTER, REPORT, OCTOBER 1994;

- EVALUATION OF THE SWEDISH GP&C SYSTEM FOR ASTA DATA LINK.

30. 13TH DIGITAL AVIONICS SYSTEM CONFERENCE, PHOENIX, OCTOBER 1994;

- THE GNSS TRANSPONDER AND IT'S WORLD-WIDE GNSS-TIME SYNCHRONIZED TDMA DATA LINK.

31. ICAO/SICAS PANEL, CARLESTON, OCTOBER 1994:

- AGENDA ITEM 6 WP - IMPROVEMENTS TO ACAS SURVEILLANCE AND COMMUNICATIONS CAPABILITIES BY THE USE OF A GNSS-TIME SYNCHRONIZED SELF-ORGANIZING TDMA TECHNOLOGY.

32. ICAO AMCP WORKING GROUP OF THE WHOLE, KOBE, JAPAN OCTOBER 1994;