Difference between revisions of "IALA and Patentable subject matters"

(This page is visible on the World Wide Web)

Introduction[edit]

IALA is a non profit, international technical association.

Established in 1957, it gathers together marine aids to navigation authorities, manufacturers, consultants, and, scientific and training institutes from all parts of the world and offers them the opportunity to exchange and compare their experiences and achievements.

IALA encourages its members to work together in a common effort to harmonize aids to navigation world-wide and to ensure that movements of vessels are safe, expeditious and cost effective, while ensuring sustainability and the protection of the environment.

IALA develops Standards, Recommendations, Guidelines, Manuals and other guidance, i.e. “IALA Documents”, through expert discussions in its technical committees.

IALA Documents should be kept free of matters which could infringe essential patents or patent applications, unless a free Patent License or a Patent License on reasonable terms is awailable.

It is preferred not to apply for (patent) protection of new patentable matters arising from discussions within IALA technical committees. Instead it prefered to make such matters available in the public domain, in order to prevent anyone from patenting these, since this could obstruct the effective world-wide useage and implementation of the contents of IALA Documents.

One means of publishing said subject matters, is for IALA members to place them here on Wikipedia, as subsections of this article.

Enhanced RADAR positioning[edit]

First published 4. March 2011.

Details can be found in another article titled Enhanced RADAR positioning.

VDES (VHF Data Exchange)[edit]

First published in 2015 by ITU in M.2092-0.

VDES Details[edit]

The next chapters describe patentable aspects of VDES implementational aspects in detail. This publishing has the purpose to protect these ideas and therefore create freedom to operate for all entities that wish to implement VDES equipment and/or services. This section does not give any guarantee, but it can give help to parties that get under pressure by organizations claiming right to these inventions.

Usage of VDE-SAT paging[edit]

I'd like to elevate a thought here publicly about VDE-SAT paging, assuming the default bulletin board.

We have earlier discussed that paging is an optional method to find out if a ship is reachable right now and here. As I understand paging, we'd send a paging message and the corresponding ship would answer in the random access channel immediately. That is, within the first TDMA subframe (20 seconds).

If the satellite would try to just send assinged DL data to the designated ship, using a DL assignment, etc. it could safe 1 TDMA subframe. However, it could also loose 3 TDMA subframes where data is repeated, without the ship receiving, before the (adjustable) 3-subframe timeout would stop the DL session due to missing DL NACK from the ship in 3 consecutive subframes.

So paging could be used to avoid spending much time (1 minute) and ressources in transmitting data that is not received by the ship.

One could even go as far as assigning a DL channel and sending the DL data together with a paging request, "speculatively" transmitting into the blue to save time. (published here 2021-04-19 by eNAV WG3 chiarman Stefan Pielmeier)

Retransmission of received maritime positions[edit]

1. A VDES shore station or satellite may have significantly improved reception range for AIS and VDES position updates compared to ships
2. The concept of retransmission or re-broadcasting of available positions through the VDES technology is covered by this captured idea:
   1. a VDES station (shore or satellite) may retransmit available position updates of other vessels and AtoN and AIS/VDES transceivers by use of VDES
   2. in a standardized way, such that ship stations can receive and visualize that information on ship equipment
   3. and by that increasing their AIS/VDES ship equipment reception range with a "virtual" range that is achieved through the re-broadcast by a satellite or shore station

(published here 2021-04-05, by eNAV WG3 chairman Stefan Pielmeier, presented and discussed openly at IALA during eNAV conferences in 2019 and 2020, see eNAV WG3 reports)

Improving Reception under bad conditions[edit]

It is seen to give advantage in receivers to:

• keep bad received packets (non matching CRC)
• and reuse the received soft bits when the retransmission arrives
• to calculate the highest probablity dependent on the FEC used

A clever system might even:

• use the retransmit system called incremental redundancy, where the turbo coder output parity bits are transmitted in a retransmit instead of the original sequence. This adds information.

However:

• it is also seen that just selecting the retransmitted data by pure received SNR can give advantages if the 2 received frames have significantly different quality and one of them immediately is detected with a matching CRC.

Therefore, it might be advisable always to handle retransmissions as such:

• check if CRC matches, if yes: use the data and stop decoding here
• if the CRC of the retransmission does not match: try to combine the soft bits before decoding (SNR boost method)
• if that doesn't work, ask for retransmit
• if you see that often, use better source, channel coding, scrambling, interleaving, FEC, channel equalization, bandwidth (selective channel) or finally waveform

(published the 4th of April, 2019, by IALA ENAV Workinggroup 3 Chairman Stefan Pielmeier)

VDE SAT Vehicle receiver puncturing[edit]

When there are strong transmissions from earth interfering with the VDE Satellite, or any SDR based receiver for that sake, it is seen that just changing all samples (@ different sampling rates, e.g. *4) over a certain threshold (like e.g. -80 dBm) to 0 (- infinite dBm) on the digital receiver side can significantly improve reception of a otherwise totally blocked receiver.

Measurements presented to IALA show that this works e.g. to block out extremely strong transmissions from ground. While under strong interference the satellite was still able to receive the low power ground signal from a ship VHF station after "zero-puncturing" out samples above a certain threshold.

(published the 4th of April, 2019, by IALA ENAV Workinggroup 3 Chairman Stefan Pielmeier; editorial change on November, 1st 2019 removing references to interfering sources)

Architecture[edit]

The VDES components embed in the shore and ship infrastructure according to the Maritime Connectivity Platform (MCP).

Following compenents are part of a complete end to end VDES system:

• The service provider (typically a https:// based JSON web service)
• the Maritime Connectivity Platform Component MMS
  • which can be hosted by a shipping company for internal services
  • which can be hosted by a country for services issued by that country
  • which provides fully secured services to the service clients
  • which can be federated by it's owners at their wish to reflect the owner's own service quality requirements
  • which has to be selected by the service client as a service broker
  • can be seen as a trusted service list provider
  • can be seen as a filter for all available services, filtering out only the ones trusted by the MMS federation
  • can be seen as a guarantee for a certain level of quality and service
  • can be e.g. the Danish Maritime Administration, providing the trusted services for the arctic region around Greenland, telling which URL's are the right ones to use for ice maps, coastal reporting, maritime safety information (MSI), wather reports, chart updates, sea depth chart overlays, "other trusted vessel" lists, telemedical services, 48h window server for each port, etc.
• a VDES Gateway, connecting the Maritime Connectivity world (IP based) to the VDES transport & roaming system
• a VDES Basestation, that might consist of a terrestrial coast station for VDES or a satellite proxy down on earth, providing connectivity to ships through a satellite network
• the air interface between the VDES base station and the VDES Terminal (ship station)
• the service client which might be:
  • integrated into the VDES terminal
  • located in the ECDIS (ice map overlay client)
  • located in the DGNSS (differential GNSS transmitter list update from IALA service)
  • located in the ECDIS (chart mapping of MSI information)
  • located in the ECDIS (base chart update service for the region from the chart provider)
  • located in a communication terminal (Medical Remote Assistance service client trusted by the shipping company)
  • located in a MFHF Radio (MFHF coastal station list update)
  • located in a VHF Radio (VHF coastal station list update)

The VDES connection can handle multiple service client flows (context) through only one MMSI of the ship and the base station by use of a temporary ID used to identify the flow/context. This ID can be a Port address or similar, assigned by the VDES gateway for outgoing traffic towards the MMS and the service provider. It will follow the data through the VDES connection to make each data block identifiable for the VDES terminal in order to know where to route the data, dependent on if the VDES terminal itself terminates the service or if it just forwards the messages by e.g. 61162-450 (Light Weight Ethernet) connection to the service client inside another bridge device (i.e. ECDIS).

The trust model of the MCP helps very efficiently to secure that no unsolicited traffic will reach the VDES network or the ship station; that makes the great difference between any internet service and the maritime dedicated VDES service, where the gateway securely only transports service data that comes from a trusted source and was transported in a secured channel (SSL/TLS protected) from the trusted service provider to the trusted gateway, using URLs that come from the trusted MMS.

(published the 4th of April, 2019, by IALA ENAV Workinggroup 3 Chairman Stefan Pielmeier)

References[edit]