AIS Fundamentals

Satellite AIS

Spire satellites spend most of their time over open ocean listening for AIS messages. These messages are published shortly after our satellites pass over a Spire ground station to download them. Given this, satellite-received AIS (S-AIS) messages are often published in “bursts”. The primary advantage of S-AIS is global coverage.

Terrestrial AIS

Terrestrial AIS message (T-AIS) collection generally occurs near coastlines and takes place after a ship transmits them. Given that, terrestrially-received AIS messages are immediately made available to you. The primary advantage of T-AIS is extremely low latency.

Dynamic AIS™

Dynamic AIS™ addresses the growing problem of gaps in AIS data, which directly impact ship safety, trading, revenue, and insurance claims. It delivers more unique MMSIs (up to ten thousand per day) with near-real-time latency, and up to six million additional AIS messages per day.

D-AIS™ leverages thousands of satellite-enabled AIS receivers traveling throughout the busiest shipping lanes in the world, and provides an unprecedented frequency of position updates in areas that are out of the reach of terrestrial collection and overwhelm other satellite AIS providers, particularly in High Traffic Zones such as the South China Sea.

These 2860+ satellite-enabled AIS receivers track vessels and the traffic within 60 nautical miles, sending this data to communication satellites at least every 15 minutes. Approximately 15 receivers a month are added to the network.

AIS message downsampling

Due to the sheer number of Terrestrial AIS (T-AIS) messages Spire receives, we do not by default provide all of Terrestrial AIS messages within the Messages API or TCP Stream. T-AIS messages are downsampled within 5-minute periods based on MMSI and message type. For example, if we receive 2 position messages with a particular MMSI 3 minutes apart from terrestrial sources, only the first of the two position messages would get published. If these messages were 7 minutes apart, both would get published.

Note:  There is an option for clients to receive full (non-downsampled) Terrestrial AIS data.

As an example of data volumes 2021-06-22. A client receiving Spire Satellite AIS and downsampled Terrestrial AIS would receive up to about 80 million AIS messages per day. If they were to receive full (non-downsampled) Terrestrial AIS then the number would jump to over 300 million AIS messages per day.

Neither Satellite AIS nor Dynamic AIS™ messages are downsampled.

AIS messages download priority

Combined Satellite & Terrestrial Feeds

Given that Terrestrial AIS is published immediately and there’s often some delay between the collection and download of a Satellite AIS message, it will often be the case that AIS messages are published within our services out of timestamp order. (We don’t store our AIS messages in a buffer and sort them before publishing them.) This is to give you access to our AIS messages as soon as they’re downloaded.

Satellite AIS Message Download Priority

Spire has many satellites in a variety of orbits and a number of global ground stations to collect and download AIS data. It’s not always realistic for us to get all of the AIS messages off of a satellite on the initial pass of a ground station.

In order to get the most important data down first, we prioritize the most recent message for each MMSI and get all of those down first before moving on to the older messages either during that same contact or during subsequent ones with other ground stations.

What that means in terms of how we push data to our AIS production services is that you’ll get the “freshest” data for an MMSI from each satellite quickly but then in some cases get the “backfill” a little bit later.

Different classes of AIS

AIS on board vessels can be classified as Class A and Class B.

AIS class A

AIS is included in the International Convention for the Safety of Life at Sea (SOLAS) convention for:

• vessels of 300 gross tonnage and upwards engaged on international voyages
• vessels of 500 gross tonnage and upwards not engaged on international voyages
• passenger ships irrespective of size.

The AIS referred to in the SOLAS convention is often defined as ‘AIS Class A’.

AIS class B

AIS Class B is intended for use on non-SOLAS vessels. These can include domestic commercial vessels and pleasure craft.

Static and Voyage information difference between Class A and B AIS

In regards to voyage information, AIS class A vessels reports IMO, destination and eta more as compared to AIS Class B vessels.

When looking at global AIS, it is commonplace that Class B vessels and small Class A vessels do not report voyage data.

24-hour count of vessels reporting destination and eta by AIS Class

AIS channel access methods

Class A transceivers reserve their time slots for AIS transmission via Self Organized Time Division Multiple Access (SOTDMA). They first perform a scan of the area to ascertain which slots have been taken by other vessels and reserve an empty slot. Any transmissions in the newly reserved slot will contain information notifying other nearby AIS devices that the transceiver intends to continue using this slot.

Class B transceivers are permitted to transmit via Carrier Sense Time Division Multiple Access (CSTDMA). Unlike SOTDMA, slots are not reserved. They instead simply scan for available space and transmit when a free one is determined to be available.

AIS channel access priority

Transmission priority is given to Class A transceivers which use SOTDMA since they reserve time slots. The timing of Class B transmissions via CSTDMA must work around the time slots reserved by Class A transceivers. If a Class B transceiver is unable to find an empty space, their transmissions are delayed.

AIS message latency

Latency is the amount of time it takes for a transmitted AIS message to get ingested into Spire Maritime’s systems. In other words, latency is the difference in time between the created_at and timestamp fields in Messages API.

The average latency for AIS messages collected from a Terrestrial AIS source is significantly lower than the average latency for AIS messages collected from a satellite, since there are fewer opportunities for a satellite to download AIS messages while over open ocean. In comparison, once a terrestrial source collects an AIS message, it’s ingested immediately.

Position messages

AIS position messages mostly broadcast information about a vessel’s physical location and motion.

This includes a vessel’s MMSI number, longitude, latitude, rate of turn, speed, true heading, and other parameters.

Spire offers the following position messages to customers:

• Messages 1, 2, and 3 from Class A vessels
• Message 4 from base stations
• Message 18 from Class B vessels
• Message 27 from Class A or B vessels (for long-range applications)

The Nominal Reporting Interval for Class A and B vessels traveling at most 3 knots and 2 knots respectively, or when Anchored/Moored, is a broadcast every 3 minutes.

Static messages

AIS static messages mostly broadcast information about vessel characteristics that should remain (relatively) static over the during of their voyage.

This includes a vessel’s MMSI number, AIS version number, IMO number, call sign, name, type of ship/cargo, ship dimensions, destination, and other parameters.

Spire offers the following static messages to customers:

• Message 5 from Class A vessels
• Message 24 from Class B vessels

The Nominal Reporting Interval for both Class A and B vessels is a broadcast static message every 6 minutes, when an information change has been made, or upon request.

Other messages

Spire offers Message 19 from Class B vessels, which contains some parameters from Messages 18, 24A, and 24B.

We also offer the following AIS messages in an encoded fashion along with their mmsi and flag or origin:

Message 6

Addressed binary Message

Message 7

Binary acknowledge

Message 8

Binary broadcast Message

Message 9

Standard search and rescue aircraft position report

Message 10

Coordinated universal time and date inquiry

Message 11

Coordinated universal time/date response

Message 12

Addressed safety related Message

Message 14

Safety related broadcast Message

Message 15

Interrogation

Message 16

Assigned mode command

Message 17

Global navigation-satellite system broadcast binary Message

Message 20

Data link management Message

Message 21

Aids-to-navigation report

AIS data cleansing methods

Often times raw AIS messages can contain errors, empty or default values, and points over land due to GPS issues or spoofing.

In our API data delivery, we do our best to clean out some of these errors. Below is a list of some of the steps that we take to clean the data:

• Check values against the AIS standard.
• Remove position data with unavailable coordinates (91 / 181).
• Filter out messages with invalid MMSI numbers. (Ships should report 9-digit MMSIs. Base stations should report 7-digit MMSIs.)
• Filter out messages with IMO numbers more than 7 digits. Note 7 digit IMO numbers still returned even when not matching the IMO checksum calculation.
• Positions reported over land. (Note. feature enabled in data from 2019-08-27)

By default, Messages API implements the above data cleaning rules. If you prefer to receive the full feed, including possible errors, simply attach a cleansed=false parameter within your calls to the API.

We do not perform cleansing for:

• Ships reporting an unintelligible name or destination field
• Ships reporting inappropriate dimensions or speeds.
• Other data errors.

If you need a raw AIS feed which does not include data cleansing, please refer to our TCP stream v2.

Vessel flag codes

Vessel flag codes are derived from AIS, more specifically from the uniquely assigned 9 digit MMSI (Maritime Mobile Service Identity) number to the vessel. The first 3 digits of a vessel’s MMSI, also known as MID (Maritime Identification Digits), specify the Vessel’s flag and country.

Full list of MIDs and country codes

The first digit of the MID represents the assigned region, and can have a value of 2 to 7:

2 Europe

(e.g., Italy has MID 247; Denmark has MIDs 219 and 220)

3 North and Central America and Caribbean

(e.g., Canada, 316; Greenland, 331; Panama, 351 through 357, plus 370 through 373; United States, 303(Alaska), 338(domestic), plus 366 through 369)

4 Asia (not the southeast)

( Maldives, 455; Japan, 431)

5 Oceania, and Southeast Asia

(Australia, 503; New Zealand, 512; Philippines, 548; Indonesia, 525)

6 Africa

(Eritrea, 625)

7 South America

(Peru, 760)

How to interpret Navigational Status codes

What is navigational status?

Ships broadcast their navigational status within position message types 1, 2, 3 and 27. It can take on a value from 0 to 15, and each number represents a unique piece of metadata associated with the vessel’s activity. We provide this value within the status field.

What does each number mean?

0

Under way using its engine

1

Anchored

2

Not under command

3

Has restricted maneuverability

4

Ship draught is limiting its movement

5

Moored (tied to another object to limit free movement)

6

Aground

7

Engaged in fishing

8

Under way sailing

9

(Number reserved for modifying reported status of ships carrying dangerous goods/harmful substances/marine pollutants)

10

(Number reserved for modifying reported status of ships carrying dangerous goods/harmful substances/marine pollutants)

11

Power-driven vessel towing astern

12

Power-driven vessel pushing ahead/towing alongside

13

(Reserved for future use)

14

Any of the following are active: AIS-SART (Search and Rescue Transmitter), AIS-MOB (Man Overboard), AIS-EPIRB (Emergency Position Indicating Radio Beacon)

15

Undefined (default)

References & Other Resources

1. International Telecommunications Union (ITU) AIS Technical Characteristics Documentation

Below is a sample (taken 2020-01-05) of decoded navigation status values and their counts by MMSI or IMO, as reported by vessels and returned as the decoded values by Vessels API:

Understanding AIS performance in High-Traffic Zones

Ship activity in some global regions is significantly more dense than average. These regions are called high traffic zones (HTZs).

High traffic zones generally occur near areas with major ports, like the South China Sea or the Mediterranean Sea.

Terrestrial AIS Performance within High Traffic Zones

AIS was originally designed for ground-to-ground reception, so terrestrial stations don’t experience any significant performance degradation in HTZs within their estimated 80-kilometer radius.

Satellite AIS Performance over High Traffic Zones

As compared to terrestrial stations, our satellites are listening to ships within a 2000-kilometer radius, making them prone to AIS message collisioning – an effect that impacts all satellite AIS providers.

When a satellite passes over a HTZ, it becomes difficult for the satellite to differentiate between the higher number of AIS messages being transmitted at the same time. The end result is actually fewer than usual AIS messages being decoded.

As an analogy, this is similar to the effect of listening to one conversation, as compared to 20 simultaneous conversations. Understanding a single conversation is significantly easier than attempting to follow 20.

Spire has and continues to develop methods of reducing the impact of AIS message collisioning on its satellites.

Rate of turn (rot)

Class A vessels periodically report the rate at which they are rotating (if at all) within AIS Messages 1, 2 & 3. This parameter is called the rate-of-turn of the vessel. Vessels reporting this parameter generally have an external “rate-of-turn indicator” (TI) onboard that feeds the measured value from the sensor into the AIS transceiver, where it then gets converted into the “raw” value stored in the AIS messages.

How to convert the decoded “rate-of-turn” (rot) value into degrees per minute

The formula is as follows:

ROT_ais = 4.733 * √(ROT_sensor)

Where:

ROT_ais

“raw” rate-of-turn value stored in the AIS message

ROT_sensor

rate-of-turn in °/min as reported by the TI onboard the vessel

For instance, a value of +126 for ROT_ais translates into a value of +708 °/min for ROT_sensor.

Note: Be aware that without special handling, converting a negative ROT_ais value to the ROT_sensor value will cause it to lose its negative (-) sign in the process. This means that the vessel’s rotation would get reported as turning right/clockwise when it is actually turning left/anti-clockwise.

Range of Possible Values

0 to +126

Vessel is turning right/clockwise at up to 708 °/min or higher

0 to -126

Vessel is turning left/anti-clockwise at up to 708 °/min or higher

+127

Vessel is turning right/clockwise at more than 5° per 30 sec; TI is unavailable

-127

Vessel is turning left/anti-clockwise at more than 5° per 30 sec; TI is unavailable

-128

No turning information is available from the vessel

Ship Type mappings

The table below maps some common AIS shipType codes to the corresponding ship type used with the shipType filter in Maritime 2.0 (both shipType and shipSubType values are available as query output as well).

Speed over ground (sog) rules

The AIS specification for sog (Speed over ground) shows that 102.3 knots is reported when the vessel speed is unavailable. So for some reason the vessel is not transmitting its speed in its AIS messages. This could be a technical issue on the vessel.

Speed over ground in 1/10 knot steps (0-102.2 knots)
1 023 = not available, 1 022 = 102.2 knots or higher

In the Vessels and Messages APIs we return the values as received. We have reports that some other AIS providers take the decision to report the unknown speed value of 102.3 as zero.

Technically this is wrong and while appearing correct when the vessel is in port, would not be correct when the vessel is moving or at sea.

For clarity to customers we have changed our reporting slightly in Vessels 2.0; sog values of 102.3 are reported as null because several users experienced confusion from the reported value.

Vessels 2.0

"collectionType": "TERRESTRIAL", "heading": 358, "speed": null, "timestamp": "2021-08-19T09:36:21.582Z"

Legacy Vessels API

"speed": 102.3, "rot": -1.0, "collection_type": "terrestrial", "timestamp": "2021-08-19T09:30:24+00:00"

Tokens & API keys

Each authorization token is unique

For the TCP feed, if your company uses multiple clients to simultaneously access the Spire Maritime platform, one particular authorization token should not be shared among several users. An exception can be made if you only have one TCP client active at a time. Otherwise, doing so could result in all clients only receiving a subset of available AIS messages.

This restriction does not apply to the Maritime 2.0 API, Messages API or Vessels APIs – multiple API clients can use the same token (provided the rate of API calls remains below below about 30 calls per minute for legacy platforms and rate limiting policies are respected).

If multiple people at your company are interested in simultaneous data access, notify the Customer Experience team so multiple tokens can be created.

What happens when my token expires?

When the agreed upon end date of your access is reached, our services will automatically disable your authorization token. You should receive an error response to an API call such as this one (applicable for Vessels API or Messages API):

13 Permission Denied
Connection closed by foreign host.

If you suspect this has happened in error, please notify the Customer Experience team.

Are multiple tokens necessary to access multiple Spire Sense APIs?

One token can be used to access all Maritime 2.0 root queries, and so is the case for Spire Maritime’s REST APIs, but they are not interchangeable between platforms (this also includes Geospatial Web Services). If you are interested in trying additional APIs, notify the Customer Experience team.

I suspect my authorization token has been compromised

If you unintentionally shared your authorization token with others, notify the Customer Experience team so a new authorization token can be issued. No loss in data should occur as you transition to the new token.

Vessel duplicates

While using AIS data, there is a chance that you may have encountered the duplicate vessel challenge.

AIS does not enforce data integrity, so there are many vessels globally that, in their AIS messages, are transmitting the same MMSI and/or IMO number as other vessels.

AIS data alone does not allow identification of which vessel is correctly using an MMSI or IMO number and which is not. Because of this challenge, in legacy Vessels API, you may have seen instances of:

• 2+ vessels reporting the same MMSI number (different IMO)
• 2+ vessels transmitting only the same IMO number (different MMSI)
• 2+ vessels transmitting the same IMO and MMSI number

With Maritime 2.0, we have improved a logic for vessel identification that helps combat this issue.

In Vessels API, an update would only be made if the same value for a vessel was seen at least three times for static values and at least two times for voyage related fields.

In Maritime 2.0, all static messages will be considered after just two occurrences. The criteria for updating is now based on identity variables to match and create vessels. All position messages are considered for possible update after one occurrence based on two criteria: feasibility criterion on positions and selection of most plausible vessel in case of duplicated MMSIs.

In tests, we have seen a great reduction in duplicate IMO and MMSI positions. Here is a data visualization that illustrates Maritime 2.0’s improvement over the Vessels API:

Handling vessel MMSI changes

Unique vessel identifiers are a complex topic in AIS. From a technical perspective, vessels transmit AIS messages using an MMSI (Maritime Mobile Service Identity) number as their identifier; this is especially true in position messages, where no other identifier is present.

However, when a vessel changes its flag, its MMSI number changes as well. It will thereafter transmit all AIS messages with its new MMSI number, never again including its old MMSI number.

In static voyage messages, however, more vessel information is available alongside the MMSI, such as:

• the IMO number, the only consistent identifier of large vessels (never changes)
• the Name of the vessel (can change)
• the vessel’s Dimensions, distances from the AIS transmitter to both sides, stern, and bow of the vessel (though mainly static can be adjusted by reassessment or physical changes)
• the Callsign, a radio communication identifier linked to the flag registration (changes along with the MMSI number when a vessel changes flag)

Considering that 85% of AIS messages are either static or position messages, and that the MMSI number is the only identifier in position messages, the MMSI is always used to link position messages to static voyage messages; however, in order to track vessels consistently and reliably, it is important to understand its relation to the IMO number, which is a more consistent unique identifier for larger vessels.

Here is an aggregation of AIS static data values received for a vessel which changed MMSI number:

This vessel, with IMO 9150406, stopped transmitting AIS messages using the MMSI 311000889 at 22-04-11 08:56:00 UTC; from then on, it transmitted AIS messages using the MMSI 538009951, with the first AIS static message using that MMSI being received at 2022-04-11 09:26:02 UTC. All subsequent AIS messages from this vessel use that MMSI number.

When a vessel changes MMSI number like this, the old version of the vessel remains in the system and a new vessel is created that reports the new MMSI and IMO combination. This is true for both the Maritime 2.0 and the legacy Vessels API platform.

This means that querying based on the imo or name fields (two identifiers which stayed the same in both the old and new mmsi versions) will return both the old and new version of the vessel, whereas querying by the mmsi field, using the old or new values, will only return the corresponding entries. Likewise, querying on time-based, recent updates using the lastPositionUpdated filter will only return the new vessel.