International Journal

on Marine Navigation

and Safety of Sea Transportation

Volume 3

Number 3

September 2009

333

1 INTRODUCTION

The main challenge in the MarCom- project will be

to find out how to adapt existing and emerging land

based communication technology to the limitations

that maritime use entails: Enormous areas to cover,

poor or no infrastructure on land, low density of us-

ers and limited willingness to pay for services.

The solution lies in integrating the different tech-

nologies, develop solutions for multi hop and ad hoc

networks between stable and mobile units, and an

Information and Communication Technology (ICT)

architecture (software and network) that allows for

variation in service quality.

In addition one must stimulate increased use of

communication services on board in order to get a

broader base for payment.

This will be done through the development for

several new applications for use on board.

We will exploit the synergy between low cost

wireless communication ship to shore and ship to in-

stallation at sea (oil platforms etc) on one hand, and

Wireless Local Area Network (WLAN) on board on

the other hand.

Accordingly we have launched the following

three R&D priority fields as the most important in

the project: (themes of this paper in bold)

− Communication ship to shore

− A generic scalable ICT service platform

− Optimized maritime mobile and wireless LAN-

solutions

Figure 1. MARINTEK (Norwegian Marine Technical Institute)

1.1 The ICT-Solutions

Figure 2.

User requirements

and needs

Communication

technologies

MarCom approach:

Case orientation (project plan)

Requirements

Applications

Technologies

Demonstrations

MarCom

MarCom’s ABC

WP4 = A WP5 = B and C plus

OSP Network

MarCom

’

ABC

WP4 = A WP5 = B and C

plus

OSP Network

Cases (also 8 -

high North

challenges and 9

- International

shipping) are

consolidated in

the 3 pilots

On-board Communication Challenges

N. Garmann-Johnsen

Origo Mobikom AS, Kristiansand, Norway

ABSTRACT: The main objectives of the MarCom project (Maritime Communication, broadband at sea) are

to investigate the main user needs and requirements to communication technologies within the maritime

community. An important part of this is providing on board services to the crew, passengers and ship opera-

tions. In order to facilitate the MarCom project will propose a Generic Scalable Service Platform to handle the

‘nuts-and-bolts’ of communication. Development of this platform presents a series of challenges and consid-

erations presented in this paper.

In this paper we will indicate what challenges and possibilities this implicates for a solution for On Board

LAN (Local Area Network), SOA (a WebService Oriented Architechture), and wireless communication.

334

Focus-areas:

During work in the project, we expanded from 7

cases listed in the proposal to the Norwegian Re-

search Council, to 9 (including High North Chal-

lenges, and International Shipping). We then consol-

idated these cases in 3 pilots. In WP 5 we will focus

on B and C in the figure above and below. We will

probably also expand the software engineering focus

to include the basis for land based networks to work

in conjunction with the ones on board.

Figure 3. MARINTEK / Mowgly

1.1.1 Requirements from the pilots

We have changed our original project plan and

started up the three pilots (1. Remote Diagnosis, 2.

Integrated Operations, 3. High Speed Craft Monitor-

ing) ahead and parallel to the integration works in

WP4 and 5. This way, we get practical studies and

further requirements to the solution(s).

Firewall requirements are being studied in project

run by the Norwegian offshore industry network;

OLF, and the project has contacts with this.

1.2 Generic Scalable Service Platform

The purpose of this part of the MarCom-project is to

demonstrate the benefit of broadband at sea, and

land-to-ship ICT-integration through the develop-

ment of a demonstrator for “The generic scalable

service platform” (Integrated platform, GSS). The

main requirements for this platform are to provide

an integration platform for:

− Several on-board applications

− Integration with systems and utilities onshore

(cloud computing, software as a service…)

− Provide seamless roaming of data communication

between different communication technologies

and infrastructures (WiMAX and likes of it-, 3G/

4G mobility, VHF/ UHF, NMT, SatCom etc.) and

Multihop networks

− WLAN and data capture/ sensor networks

Figure 4. Future logical communication lines on an offshore

supply vessel (NG/ Origo Mobikom AS)

− Cope with different communication Service Lev-

els (SL’s)

− - Sort and prioritize communication with differ-

ent SL’s

The solution must (on a commercial basis) ac-

commodate shared applications/ cooperation tech-

nologies; GIS/ planning systems etc. from any 3 par-

ty application or content provider, for use in

integrated operations and commercial shipping in

general.

Figure 5. Marintek/ FB jf MarCom Delivery 4.1

One main theory is to build on the CALM-

standard; and build a dialect of this (CALMSEA).

This can be a topic for a new European R and D pro-

ject (EuroMarCom), to finance further work.

Figure 6. A CALM-solution, courtesy of Q-Free, Trondheim,

from: (presentation at) APEC-ISO Joint Workshop Ottawa 12

November 2008

Focus-areas

Focus

areas

GNSS

335

1.3 Application Groups

Analysis of the cases in MarCom resulted in finding

six common application groups as shown in the fig-

ure below (Figure 1).

Figure 7. MARINTEK/ MarCom Delivery 3.1

1.3.1 Technical Maintenance

These applications deal with reporting condition

of the ship or platform, and (remotely) updating data

and software. This group of applications includes:

− State monitoring and analysis: This is technical

monitoring system, detection tools, information

system, remote control system for monitoring of

oil, gas, water tanks and sewerage system. This

updates of FDV systems

− Online SW updates and maintenance, such as

new SW versions on applications monitoring e.g.

the propulsion machinery

− Online data updates, such as online updates of

ENC’s (both for ECDIS/other chart systems

onboard and for pilot laptops), online updates of

meteorological and hydrological data, technical

drawings, sea maps/3D seabed topology, updates

of documents and regulations following a vessel

1.3.2 Reporting

These applications are related to the (onshore)

management’s need for tracking and status reports

from their ships. This can include operational and

technical information about the ship and its cargo,

but also navigational reports and data needed by

government regulations fit within this group.

1.3.3 Bandwidth and Quality of Service

The bandwidth and integrity (quality of service

and uplink time) requirements are summarised in the

following figure.

1.3.4 Security requirements

The security requirements on the communication

channel differ from application to application. The

main threats on the communication channel level are

denial of service and traffic analysis attacks. Hence,

protection of important user data can be implement-

ed on higher layers (the network, transport or appli-

cation layer).

Seen from a user point of view, a division in low,

medium and high security requirements have been

provided for each group of applications. Low means

that losing some of the data to unauthorised persons

is not crucial.

Medium means that losing some of the data to

unauthorised persons is not desirable, but still not

crucial.

High means that losing data to unauthorised per-

sons is crucial and one should secure the communi-

cation channels.

In addition to Tripple –A data-security in the ap-

plications (ref. Cisco IOS Security Configura-

tion Guide, Release 12.2), which is especially criti-

cal in safety and special purpose applications, we

will also demonstrate how to meet standards and

safety requirements in equipment, especially for ex-

plosion safety demands in different shipzones (0-2

where 0 indicates the highest demands)

___________________________________________________

Application Security Comments

group requirement

___________________________________________________

Technical Low Losing status data and images of

maintenance machinery to unauthorised persons

is not crucial.

Reporting Medium Losing reports to unauthorised

persons could be very undesirable

if the reports contain sensitive

information. Still, it is not crucial.

Safety & High Losing images and pictures of e.g.

passengers monitoring to

unauthorised persons due to e.g.

laws and regulations from the Data

Inspectorate is crucial and should

by all means be avoided.

Training & Low Losing training instructions and

qualification certificates to unauthorised persons

is not considered very crucial.

Infotainment Low Losing TV-signals and e-mails

Medium, might be undesirable and

High, unpleasant however this is not

crucial. However, eavesdroppng of

personal information like social

security number or credit card

information will be highly

undesirable

Special High The requirements here will vary

Purporse depending on data transmitted and

business policy of the company.

However it is likely that the data

transmitted will be important for

business purposes and should be

shielded against unauthorized

access

___________________________________________________

1.4 Protocols and message formats

The messages and protocols used in the applications

should be based on open standards as much as pos-

sible. The exact protocols and formats to be used

have to be decided when more work is done in

MarCom, later parts of project. Some examples of

possible standards are:

336

1.4.1 Protocols

− VHF data link (VDL) for transfer of AIS messag-

es.

− SMS for transfer of small status messages via

GSM.

− Internet Protocol (IP) for transfer of larger data

packages such as large reports, documents, exper-

imental data, images and pictures. This can be

TCP/IP (point to point communication) or

UDP/IP (broadcast).

− SMTP for transfer of e-mails

1.4.2 Messages

− NMEA message format for messages transferred

on AIS network and for communication with nav-

igational onboard equipment.

− XML format for reports and services to the

crew/passengers (infotainment)

− JPEG, GIF, BMP, PDF, WMF for transfer of im-

ages and pictures

− E.g. AVI for transfer of live video from web

cameras

___________________________________________________

Application Input Output

group

___________________________________________________

Technical Sensor data Status data

maintenance Status data from Status reports

equipment Deviation reports

Software updates Alarms/notifications

Time-for-service

messages

Reporting Status data from Status reports (to

applications within management)

the ‘technical Deviation reports (to

maintenance’ and management)

‘Safety and Mandatory reports to

monitoring’ authorities

application groups

Safety & Images and sound Real-time image/sound

monitoring from cameras combined with

Counting systems necessary data

Alarms and notifications

Training & Course documents Qualified crew

qualification and instructions

Web-seminars

Certificates/diplomas

Infotainment TV /Film Infotainment to crew and

Local information passengers

E-mail

Internet

Advertisements

Special Analyses data from Analyses data to experts

Purpose crew and systems on land

onboard

___________________________________________________

2 APPLICATION REQUIREMENTS (A

GENERAL APPROACH)

2.1 Service platform

One of the greatest challenges is of course getting

the signal to the ship with high enough bandwidth

and integrity. This is the main focus of the MarCom

project and is described in another TransNav paper.

Another major challenge is how to make use of the

signal, maintaining the needs of all the partners

(crew, captain, ship owner, government etc) in-

volved. To ascertain this, there is a need to develop a

common platform that handles the nuts-and-bolts of

the communication.

This service platform can be described as having

three layers. First, the Middleware receives the sig-

nals and makes it available to the recipients. The

service platform performs common tasks, like usage

tracking for billing, deciding bandwidth need for

each request and performing authorization and vali-

dation. Finally, there are applications, as described

below.

2.1.1 Administrative systems

There is a range of administrative systems on

board a modern ship. One of the main challenges is

to integrate the different systems, so that information

is easily available to crew and ship owner.

2.1.2 Wellbeing of crew

An important, but easily overlooked part of

onboard information systems, is applications availa-

ble to the crew when not on duty. In order to attract

and keep highly qualified personnel, the ship owners

are trying to narrow the gap between being on board

and onshore. Applications range from full blown

video conferencing (with family) to email and chat.

2.1.3 Special Purposes

These are core ship operation information, like

alarm systems including search and rescue, naviga-

tional systems and propulsion systems. Being top

priority data transmission, this requires special atten-

tion, but will not be addressed in further detail in this

paper.

2.2 Coverage on board

A special challenge on board a ship is determining

the availability of wireless access. Walls, bulkheads

and other metal structures create radio shadows. In

addition, the presence of explosive or flammable

substances e.g. in Ex zones , requires use of radio

equipment approved for such environments.

337

2.3 Other demand, research and innovation,

commercial implications

One also has to think of:

− Research and innovation; how and where to push

state-of-the-art ahead (MarCom is a usability

study with intermodal/ maritime transport and

supply systems, so it is not necessarily within ICT

one wishes to push the state of the art further

ahead, rather the use of it.)

− Business models. Without a good business model

around the new infrastructure, there will be no in-

centive to provide it. So the technology must

provide for business models; content billing etc.

− IPR considerations.

Figure 8. The figure shows a high level overview of the soft-

ware being developed in MarCom. Note that the data stream

will go both ways.

Signals

These are the signals received on board and

transmitted from the ship. How the signal transfer is

done is the topic for other work packages in

MarCom. The signals could also be from on-board

entities such as sensors etc.

Middleware

The middleware receives different signals

(GPRS, WiMax, UMTS, AIS etc) and makes the da-

ta stream available for the upper layers. This layer

will also translate the data stream from the upper

layers into appropriate and available formats for

transport out of the ship.

Service platform

The service platform will provide services (API)

to the applications for easy use of the broadband

available. The functions provided by the service

platform will typically be related to security, billing

and notification services.

Applications

This layer represents the actual applications; e-

mail, maintenance surveillance, video etc.

3 SUMMARY AND CONCLUSIONS

Terrestrial communication can supplement satellite

communication and provide for wireless broadband

at sea in growing areas. This opens for a whole new

range of online applications, and new ways of organ-

izing maritime transport and operations, and cooper-

ation between onshore and offshore co-workers. The

long term implications for efficiency and welfare on

board are tremendous.

The building of infrastructure and implementation

of such systems will off course have to be stepwise.

As there is not connectivity all over yet, the less cru-

cial applications (for welfare, maintenance, planning

and administration etc.) will probably be the “first

mowers”?

REFERENCES AND SOURCES

[1] http://www.isotc204wg16.org/whoiswho

[2] http://www.hegnar.no/nyhetsoversikt¬/article231191.

ece

[3] http://esafetyoffice.com/download/working_groups/C

ommunications/4th_meeting/ITS%20Standardisation

%20-%20Evensen.pdf

[4] http://www.itu.int/dms_pub/itu-

t/oth/21/04/T21040000010062PPTE.ppt#269,12,Prop

osed TR-48 Project on Emergency Information Deliv-

ery Protocol