RECOMMENDED SOLUTION

GROUP D
RECOMMENDED SOLUTION
INTRA-PLATFORM NAVAL COMMUNICATIONS SYSTEM
This report contains 7942 words as counted by Open Office
including the main body and Appendices A, B & D
MENG GROUP PROJECT
12th November 2004
-1-
TABLE OF CONTENTS
Acronyms...................................................................................................................5
Introduction................................................................................................................6
Task Description......................................................................................................................6
Clarifications............................................................................................................................6
Team Processes........................................................................................................................6
Solution Synopsis.....................................................................................................................7
Personal Communications..................................................................................................7
Additional Features.............................................................................................................7
Requirements Analysis and Specification.................................................................8
Introduction..............................................................................................................................8
Requirements...........................................................................................................................8
Functional Requirements....................................................................................................8
Non-functional Requirements.............................................................................................9
Communications......................................................................................................................9
Telephony ..........................................................................................................................9
Calling Styles ..................................................................................................................10
Identification System........................................................................................................10
Location Tracking.............................................................................................................10
Broadcast Announcements................................................................................................11
Video Considerations........................................................................................................12
Text-based Communication..............................................................................................12
Specification.....................................................................................................................13
Additional Features................................................................................................................13
CCTV................................................................................................................................13
Battle Damage Assessment...............................................................................................13
Entertainment....................................................................................................................14
Security..................................................................................................................................14
The Logging on process....................................................................................................14
Data Encryption................................................................................................................14
TEMPEST.........................................................................................................................14
Specification.....................................................................................................................15
The Human Computer Interface.............................................................................................15
Increased Efficiency..........................................................................................................15
Ships Data Dissemination.................................................................................................15
Interface model.................................................................................................................15
-2-
Specification.....................................................................................................................16
The Solution.............................................................................................................17
Platform considerations..........................................................................................................17
Basic Hardware Considerations........................................................................................17
The Terminals : Operating System...................................................................................17
The Servers : Operating System........................................................................................17
The Data Store..................................................................................................................17
Audio-Visual Communication Technologies.........................................................................18
Voice over IP....................................................................................................................18
Real Time Protocols..........................................................................................................18
VOIP Protocols.................................................................................................................18
System Interaction and Failure.........................................................................................20
Text Based Communication...................................................................................................20
E-mail................................................................................................................................20
Message of the Day...........................................................................................................20
Additional Features................................................................................................................21
Web based CCTV.............................................................................................................21
Battle Damage Assessment...............................................................................................21
Location Tracking..................................................................................................................22
Swipe cards.......................................................................................................................22
Pagers................................................................................................................................22
Radio Frequency Identification.........................................................................................22
Summary...........................................................................................................................23
Human Computer Interaction.................................................................................................23
Implementation Language.................................................................................................23
HTML Interface for Extensible Functionality..................................................................23
A Tabbed Interface............................................................................................................23
The User Interface.............................................................................................................24
Screen Shots......................................................................................................................24
Conclusion................................................................................................................25
Appendices...............................................................................................................26
Appendix A : Entity-Relationship Diagram...........................................................................26
Appendix B : SIP Communications & the Cinema architecture............................................27
SIP Conference Server (SIPCONF)..................................................................................27
SIP Proxy Redirect and Registrar Server (SIPD)..............................................................27
Terminal User Agent.........................................................................................................27
Using LibSip++ to create user agent.................................................................................27
Appendix C : Use Cases.........................................................................................................28
Use Case Diagram.............................................................................................................28
-3-
Textual Use Cases.............................................................................................................28
Appendix D : Interaction Diagrams.......................................................................................30
A Simple Call ...................................................................................................................30
A Roaming Call................................................................................................................31
A Simple Conference Call................................................................................................32
SIP Server Failure.............................................................................................................32
Router Failure...................................................................................................................33
Total Failure......................................................................................................................33
Battle Damage...................................................................................................................34
Appendix E : Bandwidth Considerations...............................................................................35
Appendix F : Screen Shots.....................................................................................................36
The Default Tab................................................................................................................36
The Login Screen..............................................................................................................36
Initiating a Call.................................................................................................................37
The Additional Features Web Interface............................................................................37
The Damage Assessment Request Screen........................................................................38
-4-
ACRONYMS
AMSG
Allied Military Standards General
CESG
Communications and Electronic Security Group
COMSEC
Communications Security
GCHQ
Government Communications Headquarters
HCI
Human Computer Interface
IA
Information Assurance
MGCP
Media Gateway Communications Protocol
NATO
North Atlantic Treaty Organisation
NRPL
NATO Recommended Products List
RFC
Request for Comments
RFID
Radio Frequency Identification
RTP
Real-time Transport Protocol
RTCP
Real-time Transport Control Protocol
SIP
Session Initiation Protocol
TCP
Transport Control Protocol
UDP
User Datagram Protocol
VOIP
Voice over IP (Internet Telephony)
-5-
INTRODUCTION
TASK DESCRIPTION
The task set by Thales Underwater Systems Ltd (TUSL) is to design a replacement for the RICE
communications system, currently used aboard UK Naval vessels for intra-platform
communication. The replacement hardware has been pre-defined as touch-screen Tablet PC's,
mounted at strategic positions about the vessel. These should provide internal communications
facilities of various forms.
All terminals shall be connected using a switched Ethernet network of unspecified speed, but
capable of transmitting video and data information between all nodes simultaneously. It has been
requested that the visual capability of the displays should provide at least a “Ships Data
Dissemination” area, and Crew Interaction facilities.
An optional video capability will be evaluated during the study, and security issues will be
addressed where necessary.
Our group have been tasked specifically with proposing a system for use aboard a frigate, although
an early decision was taken to produce a system suitable for use aboard the complete range of
vessels used by the Royal Navy.
CLARIFICATIONS
Before considering possible solutions, several clarifications were sought from TUSL. Firstly it was
confirmed that no previous work had been undertaken with similar aims. This was an important
consideration – ensuring that our efforts didn't reproduce those of others.
Our request for further information on the operation of RICE – current usage patterns, functionality,
density of units etc. – was denied. Whilst not essential, this information would have better enabled
us to produce a solution with both a similar interaction model, and enhanced functionality. A large
part of our recommended solution is therefore based around our what we assume RICE to be
capable of, and its typical use aboard a vessel. The remaining clarifications confirmed that a textbased, persistent, form of communication would be useful additions to current functionality.
TEAM PROCESSES
Whilst we felt it presumptuous to immediately elect group members to specific functions, the group
evolved quickly within its initial meeting, with several members taking on specific administrative
and coordinative roles. The role of customer interaction was assigned to one group member, and
another took ownership of the written reports, editing together submissions from the rest of the
group. Each of the major features were divided up amongst the group, based upon previous
experience in each of the major functionality domains. Regular meetings were held each weekday
morning, with each being chaired by a member of the group. A road-map was agreed at the start of
the project, setting out deadlines for submission to each stage of the reports, thus allowing time for
a thorough editorial process.
-6-
SOLUTION SYNOPSIS
The solution proposed by this group builds upon the functionality of RICE as we understand it.
RICE has been extended in those areas where we feel significant improvements can be made.
Personal Communications
The functionality provided by the RICE system has been duplicated:
•
•
•
•
Point-to-point voice communication
Conference calling
Location-based calling (i.e. you call a specific terminal not a specific user)
Broadcast and Multicast announcement functionality
In addition, several extensions have been proposed:
•
Video
The introduction of video is perhaps the extension most visible to end-users. The
system we propose allows the transmission of video between terminals during either
a two-way or conference call.
•
Individual-oriented calling
When moving to a new location, users identify themselves to a local terminal. Thus,
you can direct a call to a specific user, and the call will reach them wherever they are
logged in.
•
Location tracking
The system knows the location of all users aboard the platform (through Radio
Frequency Identification Tags), and can direct a call to a terminal in close proximity,
even if the user is not logged in.
•
Individual-oriented multicast
The multi-cast system, provided by RICE can be extended to play the announcement
in either every room in which a user on the multi-cast recipient list is logged in or in
every room in which a user on the multi-cast recipient list is located. This would
depend upon the priority level of the message.
Additional Features
Several additional features are proposed, utilising the hardware infrastructure proposed by
Thales. These features include:
•
•
•
A remote CCTV monitoring service
A Battle Damage Assessment utility
The ability to extend the system with other web-based functionality (proprietary or
otherwise).
The report also discusses other issues surrounding the proposed functionality – security
concerns, the human-computer interface and others.
-7-
REQUIREMENTS ANALYSIS AND
SPECIFICATION
INTRODUCTION
This section focuses on both the requirements specifically set out in the project brief, and those
implied in supplemental material, verbally during the project briefing, and given as answers to
questions submitted to TUSL by the group.
Firstly, the requirements will be extracted, and listed explicitly (see next section). The sections
following that will consider options for a possible specification, highlighting the requirements met
in each case. It is our intention to not only specify a solution – as requested – with additional
functionality, but to also offer an extensible solution, allowing comprehensive upgrading in the
future, should that become necessary.
Each section documented here will be further discussed in the “Technical Solution” section,
following this. Technical and implementation details, based upon decisions made here, will be
given for each area.
REQUIREMENTS
Functional Requirements
The solution should replace the current RICE system – currently providing intra-platform
communications facilities aboard UK Naval assets. The specification states the new
communication system should perform “various forms of intra-vessel communications”. The
following five requirements represent existing functionality provided by the RICE hardware
currently in use. In order to increase performance aboard the platform, it is inferred that this
functionality should be extended, and thus is required in the new system.
1. Point-to-point communication
2. Conference communication
3. Broadcast announcements
4. Multi-cast announcements
5. Audible alarms
The specification supplied, specifically states that “Ships Data Dissemination” should be
provided for via the visual capability of the terminals,
6. Ships Data Dissemination
-8-
It has been determined that whilst not specifically required in the project specification, the
following requirements should be met in the design in order to meet existing expectations.
7. Surveillance Facilities
8. Intranet Facilities, providing a platform for additional functionality
Non-functional Requirements
The following requirements have been identified as non-functional, but specifically stated in
the briefing document. The precise definition of “Increases Performance”, given in the
specification – is “increased levels of information can be supplied to the crew”, however it has
also been interpreted to imply that ease-of-use is a requirement. Whilst ease of use might not
necessarily increase performance, the lack of it would certainly decrease it.
9. Increases performance
10. Ease of use
11. Compatible with a Tablet PC interface
12. System should be secure – where necessary
It should be noted here that it is not our intention to specify where it is necessary or not
necessary to secure the system. It is assumed this information will be supplied by the Ministry
of Defence at a later date. However, the compatibility of our system with the various methods
of encryption available, and periphery issues such as TEMPEST considerations will be
discussed.
COMMUNICATIONS
Telephony
Point-to-Point communication should be provided as part of
the duplication of the existing RICE functionality (thus
accommodating requirement 1). It is important to note that
the requirement to increase performance refers to not just
Point-to-point Communication
increasing crew performance, but also to not decreasing it.
By duplicating the functionality of the old system within the proposed new system, users will
be be confident in its use, and will not have to adapt working patterns. Thus, the inclusion of
audio based communication goes some way to meeting the ease of use and increased
performance requirements (9 and 10).
Conference communication in the existing RICE system is
also audio based and should remain in the replacement
system. (Satisfying requirement 2). Conference calls should
be established by a user selecting the recipients of the call on
the screen. In the same manner as that above, the ease of use
and increased performance requirements (9 and 10) are
partially met as a result of the inclusion of this functionality.
Conference Communication
-9-
Calling Styles
The RICE system currently provides for location-based point-to-point calling. Location-based
calling is defined as a caller contacting the terminal that they expect their intended recipient to
be near – i.e. the location is dialled, rather than the individual. Location based calling remains
desirable in situations where the location is is the most important aspect of the call i.e. (the
captain wants a report from the engine room, but not necessarily a particular engineer).
However, alternative situations should be catered for. For example, when the location of the
recipient is unknown to the caller, if the system directs the call to the terminal at which the
recipient is located, great crew performance increases could be made. This style of calling shall
be referred to as individual-oriented for the duration of this report.
Both location based and individual-oriented calling will be provided for point-point and
conference communication. It is anticipated that the addition of this new calling style will
greatly increase performance (requirement 9), allowing members of the crew to communicate
with others without knowing their location in advance. Individual-oriented calling will require
the user to log on to a terminal for calls to be directed to them, leading to worst case
performance (when users never log off) as location-based calling.
Identification System
The specification of a new calling style has also introduced a necessity for users to identify
themselves to the terminal. The specifics of this will be discussed in the Security section. It is
important however, that callers do not need to identify themselves to a terminal to make a call
– this could dramatically decrease crew performance. In addition, several users should be able
to identify themselves to a shared terminal and receive individual-oriented calls on it.
When individual-oriented calls are received, the terminal should make clear to whom the call is
destined. The manner in which the terminal rings should be decided locally – options should
include both visual, loudspeaker and headset alerts.
Location Tracking
The solution proposed thus far describes a standard corporate communications system as
supplied (using telephone handsets) by BT and others. Our last major recommendation,
however, represents a novel addition to current functionality, and distances our solution from
that supplied by other leading suppliers.
The major drawback of the system as currently proposed, is that individual-oriented calls can
only be routed if the callee has identified their location to the system. As our solution – a core
component within the proposal – the communications system will able to locate a person
anywhere on the platform. Benefits include:
•
Crew tracking – allowing the system to find any particular crewman on the ship.
•
Accurate individual-oriented calling – knowing the location of every individual, it is
always possible to direct a call to a terminal in close proximity to the callee.
•
Accurate Multi-casting will be achieved – if a multicast needs to go to all sonar
operators, the announcement will occur in every room in which a sonar operator is
- 10 -
present (regardless of whether they are logged in to a terminal).
•
Battle Damage Assessment – following the destruction of, or damage to an area of the
platform, the system will compile a list of crewmen possibly trapped or killed.
•
Audit trails for security personnel – a historical record of crew-members movements
aboard a platform. Whilst this is outside the scope of our brief, it is an added facility that
may be investigated further.
The inclusion of a location tracking system will mean callers unable to connect to users not
currently logged in, will be able to at least contact a terminal in the same room. It is our
opinion that this functionality will greatly increase performance, and if implemented with the
priority system outlined below, that it will also improve ease of use.
Two different priorities of call are proposed:
•
Low Priority
The call will ring at the terminal to which the user is logged on, or not at all if the
user is not logged on anywhere.
•
High Priority
The call will ring at the terminal to which the user is logged on, only if the user is in
the same room as the terminal. If this is not the case, a terminal will ring in the users
current location.
Broadcast Announcements
There are two types of broadcast communication that should be included, broadcast-to-all and
multicast (broadcast to a specific group of recipients). These represent a duplication of
functionality provided in the existing RICE system.
Broadcast
Some users will be given the privilege to broadcast a
message to all rooms. Each room will have a master
terminal connected to some loud speakers. Broadcast
messages will be sent to all master terminals and the
announcement will be broadcast via these loud speakers.
Multicast
Multicast communication will allow users to direct
announcements to specific people or locations, or a
combination of the two. Each room will have a designated
master terminal – responsible for playing the announcement.
Multicast Communication (red
indicates a non recipient)
Individual-oriented multicasts will also be possible – with
the message being played out of the master terminal in every room in which a recipient is
located. For Low Priority messages, this will be based upon the room in which each of the
users is logged into terminals, but for High Priority messages, this can be based upon the users
actual location at the time of the announcement (from the Location Tracking system).
- 11 -
Video Considerations
Providing video support will allow users to see the people to whom they are talking. This
gives many of the benefits of face-to-face communication, reading facial expressions and body
language.
The replacement system will provide optional support for video. Video will not be supported
for broadcast or multicast communications – it provides negligible additional information in
unidirectional communication. In addition, audio broadcasts will be amplified, so there is no
reason to assume that users will be looking at a terminal.
The support for video communication will place intensive strain on network bandwidth. The
section “The Solution” considers bandwidth requirements in detail.
Text-based Communication
Textual communications such as e-mail, instant messaging and paging are other possible
methods in which point-to-point and conference calling can be achieved.
Text requires extensive use of data input devices such as keyboards or stylus, imposing the
need for efficient typing / writing skills. In time-critical systems where fast and efficient
communications are imperative, an entirely-text-based communication system appears fallible.
However, textual communications can be an essential complement to other forms of
communications for non-urgent conversations.
Instant Messaging
Instant messaging can handle both point-to-point and conference communication, although is
usually used for time-critical, non-persistent communication. As stated above, text is not a
suitable medium for this – it would reduce performance, and be cumbersome to operate.
Instant Messaging is not included in our recommended solution.
E-mail
Whilst e-mail alone cannot handle all point-to-point and conference communication
requirements, it is a persistent form of communication useful for non time-critical
communication. Thus, a simple email system will be included in the solution to complement
the audio/video previously proposed.
Message of the Day
This an invaluable tool for broadcasting non-urgent, persistent daily messages across the
terminals. There will be a designated message of the day section on the main screen. It is
anticipated that this feature will be used in a variety of manners aboard each vessel. Possible
uses include meal times, crew rosters, shift times and information, announcements, new
mission details etc. Some contact with a representative from the Royal Navy would be required
before laying down exact specifications for this area.
It is recommended that only certain officers have the ability to add text to the message of the
day area – using either an on-screen keyboard, handwriting recognition or a plug-in keyboard
available in certain areas (cabinet space perhaps).
- 12 -
Specification
•
•
•
•
•
•
•
•
•
•
Audio-visual point-to-point communication.
Audio-visual conference communication.
Caller instigated conference calls.
Location based calling.
Individual-oriented calling.
Amplified audio broadcast communication.
Amplified location-based and individual-oriented multicast communication.
Location tracking system.
Simple e-mail facility for non-time-critical persistent communication.
Message of the day facility – updated by certain crew-members only
ADDITIONAL FEATURES
CCTV
The system currently proposed allows a crew-member to optionally view a video feed of the
user being called. In certain situations however, it will often be more informative to view a
video feed from elsewhere in the ship – perhaps an inaccessible place, or at a time in the past.
To this end, we propose installing additional cameras focused in vital and inaccessible parts of
the ship. For example, cameras showing the winch mechanisms, the ammunition store and the
helicopter hangar/launch pad. This solution could either act as an on-platform security system,
or merely to enhance intra-platform communications during critical periods.
The video from these cameras should be available stored, as well as live, and should allow
random-accessing – back to any time stored within the archive.
Battle Damage Assessment
As part of the supported functionality, an improved damage reporting mechanism is proposed.
If a Battle Damage Assessment (BDA) report or status check is required from some or all of
the ship’s departments, the terminals can display a message prompting the relevant users to
give feedback.
When a response is entered, it gets transmitted to the captain or relevant officers tablet and is
displayed in an easy to understand fashion as a grid of coloured lights, for instance. If complex
additional data is required the other communications facilities should be utilised to gather this:
• CCTV recordings can be examined to check for damage (especially in unreachable areas)
• A simple front-end for the location system, can utilise the information provided by RFID
tags to show the position of all crew-members – perhaps highlighting those stuck in
damaged areas. Damage to the location tracking infrastructure (the receivers could go
off-line) will also show up and can be harnessed as a further indication of potentially
damaged areas.
- 13 -
Entertainment
Entertainment features are a possible addition that would make good use of the infrastructure
already in place for the Communication system. As a result of the consoles being shared and
with the majority of them being located in operational areas of the ship, it is considered that
providing entertainment features would be inappropriate. It is thought that providing additional
functionality that is capable of effectively blocking a communications terminal, would be
detrimental to the effective operation of the vessel.
SECURITY
Naval crew members can be considered to be working as a team, within a secure environment,
and thus highly intensive security procedures are considered both unnecessary and potentially
damaging to the efficiency of the vessel. However, sensible security measures will be
beneficial to the vessel’s operations, and will ensure the safety of sensitive data.
The Logging On Process
The need for control of data is immediately apparent, as well as personal preferences for each
crew-member. To control this, a log-on process is recommended, whereby a crew-member has
access to his features (and only his features) by entering a secure area of the system. These
accounts can be controlled centrally and audited such that rights and permissions to different
data and vessel’s information can be managed.
It is noted however, that any logging in system needed to be very transparent and simple as it
would be ineffective for crew-members to have to remember too much information. Additional
HCI (Human Computer Interface) complexity could also be unacceptable – “Soft” keyboards
may be unwieldy to use when wearing gloves etc.
Data Encryption
The need for privacy of communication is paramount on-board the vessel – conversations and
video data need to be unobservable by unauthorised third parties. Our solution will include a
data encryption system, which will conform with the recommendations of CESG (the
Information Assurance (IA) arm of GCHQ) or equivalent military IA or Communications
Security (COMSEC) body.
TEMPEST
The solution proposed in this document is highly flexible, and would be suitable for use not
only on a variety of UK Naval Platforms, but also those of other countries, and possibly landbased assets too. Thus, it is important that the product is accepted both within and outside the
Ministry of Defence, and meets the required standards – one of which is TEMPEST.
TEMPEST is the study of the unintentional emission of protectively marked data from an
equipment or system. In a real commercial situation, any end-product would be put forward for
TEMPEST accreditation by CESG or an equivalent MOD IA body. The resulting accreditation
would allow the system to be put forward for the NRPL (NATO Recommended Products List).
- 14 -
Specification
•
•
•
•
A logging system for crew-members which is easy to use and secure.
A secure data store of everyone’s personal preferences, information and rights.
A data encryption scheme that will prevent third party access.
TEMPEST AMSG accreditation through CESG or equivalent MOD body.
THE HUMAN COMPUTER INTERFACE
The main Human Computer Interface (HCI) requirement states that the system should be
operable through the interface provided by a Tablet PC (without mouse or keyboard). Thus, the
system should be controllable entirely through a touch-screen. This requirement affects all
other HCI requirements, and the majority of the specification decisions made below.
Increased Efficiency
Interface Size
A wide variety of users, performing a vast array of jobs aboard the platform will be utilising the
system. It is anticipated that some users will be wearing protective equipment – fire-fighting or
engine room gloves for example. Thus the first major interface requirement is that it should
cater for these situations. A good parallel with which to compare is interfaces designed to run
through a television – with the user sitting a distance away, and interaction elements being
oversized.
Interface Depth
The large interface requirement will restrict the amount of information available on screen at
any one time. This could easily lead to a large interface depth – the number of screens to
navigate in order to achieve an objective. This depth will be kept to a minimum, in order to
maximise the users' efficiency.
Ships Data Dissemination
It is anticipated that each platform, and each mission will have very varied, and perhaps
dynamically changing requirements regarding the availability of information for the crew. As
standard, the proposed system will provide a default screen displaying the time (both local and
UTC1) along with vessel position and course details. As an option, privileged users may restrict
access to this screen if the need arises. Part of the screen will be a “message of the day” field –
discussed previously.
Interface Model
Whilst most end-user software available for use on standard home computer hardware follows
a specific interface model – familiar to most home-users – the large interface requirement
attached to this software, opens up the range of choices. Several existing 'soft-phones' operating
on computers follow a telephone interface-metaphor, and arrange the screen to look like a
telephone, rather than following traditional design guidelines. Our recommended solution has
the option of following an interface-metaphor such as this.
1 Standard Military Time – also known as Zulu-time
- 15 -
In order to keep the system as open as possible, and to prevent the development of a proprietary
interface, it is recommended that this software follow traditional guidelines, but with oversized
interface widgets. It is also suggested that a tabbed interface is used – easily highlighting the
separate areas of functionality provided by the terminals. This method will keep the interfacedepth (see above) to a minimum, an will also allow users to easily switch between functions –
allowing multitasking. Alternative options include a menu based system – though this could
prove difficult to comprehend, would result in a larger interface depth, and could cause multitasking problems (users cannot easily return to where they left off if they have to navigate back
through a deep menu).
Specification
•
•
•
Large interface widgets.
Small interface depth.
Tabbed interface.
- 16 -
THE SOLUTION
PLATFORM CONSIDERATIONS
Basic Hardware Considerations
It is recommended that Tablet PC's with built in web-cams, and external-audio patch-bay are
procured. As specified in the brief, the system will operate on a switched Ethernet network,
assumed to be running IPV4 compatible switching hardware. IPV4 is well established and
although doesn't provide Quality of Service, can be augmented with Real-Time protocols (see
later). IPV6, the more recent alternative, is largely unproven and requires more expensive
hardware.
The Terminals : Operating System
The terminals are all Tablet PC's, and as such will be shipped with Microsoft Windows XP
Tablet PC edition (unless otherwise requested). This software provides a range of useful Tablet
PC oriented software extensions – through .net extensions – including handwriting recognition
and an ability to write on the screen in a text box. In addition a large number of commerciallyavailable Voice-over-IP (see below) Software Development Kits (SDK) are produced for the
Windows platform. It is recommended that the terminals run Microsoft Windows XP Tablet
PC Edition.
The Servers : Operating System
The servers required to run this system are minimal, and consist of a data-store (see below), a
multimedia conference server (for relaying conference data to all participants) and a web-server
for running some of the additional features – and providing extensibility for the future.
The majority of the applications and software packages discussed in the remainder of this
document are UNIX based. UNIX and open-source software is rapidly becoming an industry
standard solution. In October 2004 the Office of Government Commerce released a report
stating:
“Open Source software is a viable and credible alternative to proprietary software
for infrastructure implementations...”
The server-side of our recommended solution will be based on the Linux operating system.
The Data Store
There are several methods of storing the data necessary to run the solution proposed in this
paper effectively. The most efficient method of storing the data – eliminating duplication –
however, is a relational database. Whilst a flat-file data-store – the only suitable alternative –
could be used, this would lead to data-duplication, and would be slow at accurately modelling
the relationships between entities.
- 17 -
Relational databases are managed through a Database Management Systems (DBMS), with
several examples of both commercial and open-source solutions available. The database
running will be small, although with a reasonably high load (as a result of constantly
maintaining an accurate position for every member of the crew aboard a vessel). The choice to
run the server-side of the system on an open-source platform leaves only UNIX based DBMS
available, of which MySQL has proven itself to be highly dependable for hosting smallmedium sized databases. It is very well supported within the open-source community. MySQL
is the database platform of choice in this situation.
Appendix A contains an entity-relationship model for the database, with further information on
it's structure and use.
AUDIO-VISUAL COMMUNICATION TECHNOLOGIES
There are two main choices for the audio-visual component of the communication system:
Conventional PSTN and Voice over IP (VOIP). Using conventional telephony would require extra
hardware and over-complicate the Ethernet based network-backbone of the system. The proposed
system will use Voice over IP techniques.
Voice Over IP
Voice over IP (VOIP) is the transmission of voice and/or video over IP based networks. It
provides telephony functionality at a low cost. VOIP is ideal for audio and video
communication over Ethernet, requires no additional hardware (except microphones and webcams), and can handle all required methods of communications.
Real Time Protocols
In addition to UDP at the Transport layer, a real-time protocol (RTP) at the application level is
used to assist with re-building data in the correct sequence on the receiving end.
Closely linked to RTP is the Real-Time Control Protocol (RTCP) which provides a quality of
service for real-time multicast communication. By supplying a feedback of information like
number of packets lost, round trip time and jitter, sources can adjust the audio/video data rate
according to bandwidth restrictions. RTCP also controls the synchronisation of separately
transmitted audio and video.
As RTP and RTCP are the only defined standard for real-time audio/video multicast
communication they will be used in the proposed system.
VOIP Protocols
At the Application level there are thee main standards for implementing VOIP on top of the
Real Time Transport Protocol, H.323, SIP and MGCP. The benefits of each with relevance to
the problem will be discussed.
- 18 -
Session Initiation Protocol
The Session Initiation Protocol (SIP) is a signalling protocol used for establishing sessions over
an IP based network, including audio-visual, uni-cast and multi-cast sessions. SIP is an RFC
standard and has been widely adopted as the protocol of choice for VOIP applications, rapidly
replacing H.323 as industry leader. SIP is simple, cheap and highly scalable (unlike H.323
which limits itself by trying to cover and enclose everything).
The Open Source community are yet to release a full-scale SIP implementation, although
Microsoft’s RTP is based on SIP and can be integrated into C# and VB.Net applications easily.
RTP SDK V1 currently only supports uni-cast audio-visual interactions although V2, due for
release within the next 6 months, will support multicast audio-visual communication.
Multicast functionality is required, and until RTP SDK V2 is available, the recommended
solution is the University of Columbia’s ‘Columbia Internet Extensible Multimedia
Architecture (CINEMA)2. CINEMA is one of the few multi-platform, open and modular
multimedia architectures to support conference calls. It provides both Conference and Proxy
Redirect & Registration servers (SIPCONF and SIPD). A user agent, to be included on each
terminal, will be developed using the University of Columbia’s Open Source SIP Library
libSip++3, which will connect to the SIP proxy and conference servers to receive and send
audio and video.
A further benefit of using the CINEMA architecture is that it provides a host of additional
features that could be utilised in future releases. SimUM (SIP Unified Messaging Service) an
audio answer-phone service with web-interface, and a streaming video server for entertainment
or other features are examples. Appendix B provides more information on CINEMA and an
example infrastructure diagram.
H.323
H.323 is a standard suite of protocols that allows multimedia transmission over IP. It is the
most widely used of the VOIP protocols and there is a large project dedicated to providing an
open source H.3234 implementation. Recent trends in Internet telephony, however, suggest a
move to SIP – allowing amongst other things for larger telephony networks.
Audio/Video Codecs
There are a number of different audio and video codecs, providing varying quality for varying
bandwidth availability. The most widely used is G.711 however it has a large bandwidth
requirement (64Kb/s). Therefore it will be used alongside GSM which requires a lot less
bandwidth (just 16Kb/s). Both of these codecs are supported by the SIP conference server to be
used in the proposed system (SIPCONF).
The video codecs most widely used for video conferencing at present are H.263 and H.324
(MPEG-4-10). Whilst H.324 will work better in high bandwidth systems, previous use has
shown that it can appear worse than H.263 if bandwidth is limited. Due to the large number of
2
3
4
http://www.cs.columbia.edu/IRT/cinema/
http://www1.cs.columbia.edu/~kns10/software/siplib/
www.openh323.org
- 19 -
people potentially aboard a platform, all potentially using audio-visual communication at the
same time, the replacement system will use H.263 for video encoding.
Appendix E considers the worst-case bandwidth requirements for both audio and audio-visual
communication aboard a large Naval platform. A gigabit network will be ample for running the
system aboard a frigate. Unfortunately in a worst-case scenario aboard an aircraft carrier,
required bandwidth could exceed that available. As explained, however, this is unlikely to
occur.
System Interaction And Failure
Appendix D contains diagrams illustrating the interaction between various systems and users
involved during call-routing and setup. In addition, several diagrams indicate how the system
handles hardware failure – i.e. failure of each of the servers, and then total system failure.
TEXT BASED COMMUNICATION
E-mail
Post Office Protocol (POP) and Internet Message Access Protocol (IMAP) are two e-mail
protocols that govern how information is to be transmitted over a network. POP is older and is
rapidly becoming outdated, whereas MAP is relatively new and hosts a variety of extra
features.
IMAP – E-mail and folders reside on the e-mail server and therefore one can easily access
email and folders regardless of which computer, or terminal, is being used.
POP – Suitable only if e-mail is to be accessed from the same computer every time because all
activities are performed on the local machine. E-mail is deleted from the server once it has been
downloaded.
E-mail communications will be supported via an open-source IMAP server, which can be
integrated into the system easily. It is recommended that a large part of the non-telephony user
interface be web-based, one part of which would be an open-source web mail solution to act as
an e-mail client. This would be cut-down and tailed specifically for military use – removing
some advanced functionality, and leaving a simple core text-based messaging application.
Message Of The Day
The Message of the Day (MOTD) will be a Hyper-Text Mark-up Language (HTML) field on
each terminal – reading its contents from a server. The content of the message will need to be
refreshed from the server to view updated information, although this could be performed
automatically. HTML is an open standard, providing a wide variety of layout options, and is
supported by a range of servers operating over the associated Hyper-Text Transfer Protocol
(HTTP). A number of open-source Content Management Systems are available allowing easy
updating of live content by users with the correct privileges.
- 20 -
ADDITIONAL FEATURES
Web Based CCTV
A network-based CCTV system is a Closed Circuit Television (CCTV) surveillance system
composed of digital video cameras and PCs connected to a network. Most systems allow
simultaneous recording and transmission of video streams to terminals, and remote access
control to the cameras.
There are a number of commercial applications that implement these facilities: the most
prominent being WebCCTV by Quadrox.
WebCCTV
This is free camera monitoring software which
supports simultaneous recording, archiving and
transmission over a network or telephone lines.
Recording is optimised through the principle of
activity detection – recording is started only when a
camera sensors movement. The software allows
simultaneous access of multiple users and complete
management of the camera operations (PTN for
example).
WebCCTV
The software supports multiple cameras (up to 4 in
the commercial version with a licensing option to provide support for more), with the server
running on the Windows XP platform. The client is web-based, and so will fit in with the
proposed infrastructure (with additional facilities all being web-based, and viewable through an
embedded web-browser in the terminal software).
uViewIt
Like WebCCTV, uViewIt provides network-based CCTV, controls video cameras or web-cams
and records all activity. It allows remote access via an Internet Browser to live images, or
review recorded ones. uViewIt can also send Email & Pager alerts when motion is detected on
any camera.
In terms of the the features, extensibility and versatility, Web-CCTV is more appropriate than
uViewIt and will be used.
Battle Damage Assessment
The Damage Assessment signals can be implemented using the SIP signal splitting facility –
allowing a broadcast signal to be sent to all terminals requesting an assessment report. The
signal will be interpreted by the user-agent software, utilising the lipSip++ library as a receiver.
Likewise, the return signal will utilise the same system, returning one of a set number of
customisable responses, perhaps:
- 21 -
•
•
•
•
No damage
Minor structural damage
Serious structural damage
Serious injury or death
These options would be configured to best suit the platform.
Example Damage Response Box
Appendix D contains a diagram illustrating user and system interaction during a Battle Damage
assessment scenario.
LOCATION TRACKING
To facilitate some of the more advanced features of the system, such as individual-oriented
calling, some location-tracking of crew-members needs to be performed. There are several
ways of doing this, each with advantages and disadvantages.
Swipe Cards
The system could use swipe cards to identify where personnel are on-board the vessel. Swipe
card readers would be placed at key locations, and when a crew-member moves around they
swipe into the area to let the system know where they are. This has several major drawbacks.
Equipment would need to be bought and installed, personnel would have to remember to swipe
in wherever they went, which could possibly be an arduous task. It also requires the crew to
carry cards around with them – perhaps it's most negative point.
Pagers
Each crew-member could be issued with a pager. This would be a form of passive tracking,
although the system does not know individual locations, each can be contacted directly. Pagers
are cheap and inoffensive to carry around, allowing crew-members to be alerted discreetly to
incoming calls and access a terminal to receive them. This represents an advantage over RFID
(following). The largest drawback would be the lack of pager coverage aboard a Naval vessel –
a Pager infrastructure would have to be built into the platform.
Radio Frequency Identification
Radio Frequency Identification (RFID) tags could be issued to each crew member, causing
little or no irritation to those carrying them. Receivers take the form of active units that
energise the passive (unpowered) tags, and read back their unique signature. Receiver units
would be installed around the vessel, allowing the location of each crew-member to be resolved
to a single room. Alternative schemes are available, including high-range powered tags, with
the inconvenience of having to maintain a battery supply. Passive tags, until recently restricted
to a 1m range, are now available in UHF models, extending usability up to 10m. Once such
technology is the TAGIDU RF IDIC ATA5590 tag, produced by Atmel Corp5. This tag, priced
at only $0.50, uses frequencies between 800MHz and 1GHz, has a low power consumption and
hence is effective up to 10m from a receiver.
5 http://www.atmel.com
- 22 -
RFID facilitates potential extensibility of the system to new features such as security tracking
and tracking of non-human resources such as sensitive material. Though the equipment
involved has a high installation cost, it is our opinion that the value added as a result justifies
the expense, negligable in comparison to total installation.
Summary
We deemed swipe cards to be too user intensive as they required a large amount of user
interaction with the system. Relying on log-on information was deemed inaccurate for locating
crew-members aboard a military vessel.
The only advantage of pagers above RFID (the only options remaining) is that pagers are nonintrusive when a call is to be received (the alert is not broadcast to the room to alert the crewmember). This was felt to be a negligible advantage compared to the disadvantage of installing
(and arranging the stealth of) a pager infrastructure. RFID also represents the ability to add a
great deal of extra functionality into the system, either in the initial, or later releases.
In conclusion, RFID tags will be issued to each crew-member and receivers placed in each
room. The central server will dynamically keep a track of where everyone is and supply this
information to the routing system for individual-oriented calling and multi-cast
announcements.
HUMAN COMPUTER INTERACTION
Implementation Language
When choosing an implementation language, there are several alternatives to consider. Each
has it's own advantages and disadvantages. The only really appropriate choices are Java, Visual
Basic/C# .NET and C++. VB, C# and C++ can often use the same external libraries as each
other, which is a definite advantage.
All four of the languages have their benefits and drawbacks; however they are all suitable for
this application. VB and C# are both largely aimed at rapid prototyping rather than enterprise
applications, while Java concentrates on platform independence. The availability of third-party
libraries precipitated our choice of C++ as our preferred language of implementation.
HTML Interface For Extensible Functionality
The platform for extensibility is provided through an HTML/HTTP interface. This provides
several advantages. Firstly, it simplifies the development of additional features, with a lot of
the required functionality being widely available through HTML interfaces – e-mail, bulletin
boards and WebCCTV are all examples. Additional features can be added through the addition
of another tab on the terminal, or a link within the HTML area of an existing tab. Functionality
can also be updated server-side without having to interfere with any end-user equipment.
A Tabbed Interface
Our proposed interface uses a simple system of tabbed pages, increasing ease of navigation for
the user. Since the primary interface tool is the user’s finger, the tabs are quite large, and are
- 23 -
situated on the right of the screen. An option to move them to
the left can be easily included to make it easier for left handed
users.
An important decision was whether to use text or images/icons
to identify the tabs. The advantage of text is that it can describe
the purpose of each tab, which may make it easier for first time
users to use. However an icon can infer a similar description
while taking up far less space than the equivalent text, it is also
more easily visible, and can be understood by foreign-speaking
users (perhaps visiting the platform, or on a join exercise).
The Tabbed Interface
The User Interface
The system starts by displaying a default tab. This screen displays information about the ship
(such as course and position), information relevant to the crew (the Message of the Day) and
other general information. To the right is the list of tabs allowing access to the other parts of
the system. The first tab is used for logging on to the system, and the second tab is for making
a call.
To log on, the user selects their name from a list of people in the room (as determined by the
RFID location system), and is then prompted to enter their PIN. Once logged on, several extra
features are enabled, depending on the privileges of the user.
The first extra feature, which is available to all logged in crew-members, is the e-mail system.
This is accessed via a web browser embedded in one of the tab pages. More senior personnel
can make use of the ship-wide broadcast and multicast communications systems. Access is
also provided for some personnel to use the damage report request system.
The communications system starts by showing a tree of ships personnel and locations. The
user can add any combination of locations or people that they want to call. If only one
recipient is selected, then the system starts an ordinary point-to-point call – it brings up a
prompt on the recipient’s console asking if they wish to accept the call. If they accept, the
system proceeds to the call screen where the users can add video feeds etc. A similar
procedure is followed with a conference call, except invitations go out to all the parties
involved. Assuming at least one of them accepts, the conference proceeds.
Appendix C contains further technical information on the User Interface.
Screen Shots
Sample screen-shots illustrating the concepts and functionality described above, are available
in Appendix F.
- 24 -
CONCLUSION
Our solution comprises a full spectrum of useful augmentations to RICE. All of the features are
designed to be useful to the crew and many can be configured nearer to installation, to specialise
the system to each platform. Our design is primarily based around open source, robust technologies
and standards that are integrated through our intuitive user interface. We hope that a design such as
ours will one day be present on British, and indeed international, vessels as an augmentation of
crew work styles and interactions.
We would like to thank Richard Wilson for his continual support in this project and Mark Thomas
and Paul Keeler from Thales Underwater Systems Ltd for setting us such an interesting challenge.
If you have any further queries regarding any aspect of this proposal, please don't hesitate to contact
our group representative, Richard Frosztega on rf113@york.ac.uk.
We look forward to your reply, and to hearing your comments on our recommended solution.
- 25 -
APPENDICES
APPENDIX A : ENTITY-RELATIONSHIP DIAGRAM
The diagram below illustrates how a relational database will be used for location tracking, and
hence to handle call routing. A users RoomID will be updated by the system when they are
detected by a different RFID reader. When turned on, terminals will register themselves with the
SIP proxy server (see Appendix B) so that a SIP address can be associated with the terminal (this is
stored in the CINEMA SQL Database). When users log in to a terminal, the call routing database
will be used to associate the two, so that calls can be routed to the correct place.
An example of an SQL query for a low-priority call:
SELECT SIPAddress from User WHERE UserID = 'callee'
An example of the SQL queries required for a high-priority call:
Locate the user and which terminal they're logged into
SELECT RoomID, SIPAddress FROM User WHERE UserID = 'callee'
Find the room that the terminal is located in
SELECT RoomID FROM Terminal WHERE SIPAddress = 'calleeSIPAddress'
If the callee is in the same room as their logged-in terminal, call it,
else call master terminal in their current room:
if (CalleeRoom == TerminalRoom) {
return calleeSIPAddress;
} else {
SELECT MasterTerminal FROM Room WHERE RoomID='CalleeRoom'
return CalleeMasterTerminal;
}
0 ..* a re in
Use r
co n ta in s1
Ro o m
User(UserID, Pin, Name, RoomID, SIPAddress)
1
0 ..*
L og g e d in to
ha s
Room(RoomID, MasterTerminal)
Terminal(SIPAddress, RoomID)
Te rmin a l
Ha s lo gg ed in
1
0..*
a re in
- 26 -
APPENDIX B : SIP COMMUNICATIONS & THE CINEMA ARCHITECTURE
The proposed system follows a modular design, comprised of a SIP Proxy Redirect and Registrar
Server (SIPD)6, SIP Conference Server (SIPCONF)7 and relational database modules provided by
‘Columbia InterNet Extensible Multimedia Architecture’ a multi-platform C++ multimedia
communication architecture. The use of a SIP Library API (libSip++)8 is recommended, to create
the user agent. This would interface with the proxy and conference server and also communicate
with database described in Appendix A to handle call routing.
SIP Conference Server (SIPCONF)
SIPCONF is a multi-platform SIP based
audio conference bridge, which uses SIP for
signalling and RTP for media. It has a
modular design so that components can be
reused selectively. Configuration information
is stored in the CINEMA SQL Database. The
user agent at the terminal will register a sip
address for the conference call with the
conference server when a user wishes to set
up a conference. SIPCONF provides a web
interface, our user agent will hide this by
using our user interface to set up the
conference through the web interface without
the user knowing.
The CINEMA Architecture
SIP Proxy Redirect And Registrar Server (SIPD)
SIPD is a proxy, redirect and registrar server that provides name mapping and user location, it
allows users to register their location with the server. However to provide the proposed location
tracking system for emergency calls. Instead of users having individual sip addresses, sip
addresses will be kept static to terminals and users sip addresses will change depending on
where they are calling from or where they are logged on.
Terminal User Agent
LibSip++ will be used to provide a user agent for the terminals. It will deal with connecting to
the proxy server and conference server and will process audio and video to be sent across the
network. It will also interface with the database as described in appendix A to handle call
routing, for more information on call routing see Appendix (ROB).
Using LibSip++ To Create User Agent
The lipSip API documentation, including examples illustrating its use are available on-line9.
6
7
8
9
http://www.cs.columbia.edu/IRT/cinema/doc/sipd.html
www.cs.columbia.edu/IRT/cinema/doc/sipconf.html
http://www1.cs.columbia.edu/~kns10/software/siplib/
http://www1.cs.columbia.edu/~kns10/software/siplib/
- 27 -
APPENDIX C : USE CASES
Use Case Diagram
<<uses>>
Crew Members
Priveleged Crew
Members
Phone a Location
Logout
Answer Call
Logon
Initiate a Conference
Phone a Person
Send Damage Status
Multicast
Broadcast
<<uses>>
Captain/OOW
SIP Proxy Server
Request Damage Assesment
Find User
SIP Registrar and
Location Server
Textual Use Cases
Use Case:
Logon
Available to: Crew-members, Privileged Crew-member, OOW
Scenario:
1. Press the “Logon” button.
2. Enter your 6-digit PIN.
Use Case:
Logout
Available to: Crew-members, Privileged Crew-member, OOW
Scenario:
1. Press the “Logout” button.
2. <System will log you out automatically if you move sufficiently far away
from the terminal> (optional feature).
- 28 -
Use Case:
Answer Call
Available to: Crew-members, Privileged Crew-member, OOW
Scenario:
• <System shows a message stating who is being call and the caller. Audible alert is also
sounded>
• Press the “Answer Call” button (Any user).
Use Case:
Phone a Location
Available to: Crew-members, Privileged Crew-member, OOW
Scenario:
1. Press the “Make Call” button.
2. Select the “Locations” menu.
3. Select the location you wish to call and press the “Add” button.
4. Press the “Call” button.
Use Case:
Phone a Person
Available to: Crew-members, Privileged Crew-member, OOW
Scenario:
• Press the “Make Call” button.
• Select the “People” menu.
• Select the person you wish to call and press the “Add” button.
• Press the “Call” button.
Use Case:
Initiate a conference
Available to: Crew-members, Privileged Crew-member, OOW
Scenario:
• Press the “Make Call” button.
• Navigate through the “People” and “Locations” menus and find the people/locations
you wish to conference with.
• Select each person/location in turn and press the “Add” button.
• Press the “Initiate Conference” button.
- 29 -
APPENDIX D : INTERACTION DIAGRAMS
A Simple Call
A Roaming Call
- 30 -
A Simple Conference Call
SIP Server Failure
- 31 -
Router Failure
Total Failure
- 32 -
Battle Damage
- 33 -
APPENDIX E : BANDWIDTH CONSIDERATIONS
The codecs chosen for transmission of audio-visual data are considered below.
Audio
The G.711 codec will be used for the transmission of audio during point-to-point and
conference telephony. The codec requires 64kbps each-way, at the standard rate – each sample
represents 20ms. A two-way call thus requires two links, comprising the following:
64kbps
68.8kbps
72kbps
80kbps
87.2kbps
for the VOIP payload
including the RTP real-time protocol header information
including the UDP header information
including the IP header information
including the link layer information (Ethernet headers)
Thus, a two-way call requires a bandwidth of 174.4kbps.
Assuming the system should be scalable to allow for use on-board an aircraft-carrier, with up to
2500 personnel on board, the bandwidth requirements are:
2500 / 2 = 1250 possible calls in progress at once
1250 x 174.4kbps = 218,000kbps = 212.89mbps.
Thus, a 100mbps would be unable (assuming a hub-architecture) to handle the maximum
throughput of calls required on board a large platform. The network is specified as a switched
network – with the result that network traffic would be routed only to the destination, and not
around the complete network. A worst-case situation though, where everybody calls a crewmember at the other side of the network, could still cause an overload. A gigabit network is
recommended.
Video
The H.263 codec will be used for the transmission of video communications. The codec can
handle 30-fps full-colour video at 128kbps, although it is rate-adaptive. Assuming this rate
would be selected during period of high demand, an extra 348.8kbps will be required for video
(including RTP, UDP and IP header information – see “Audio” above).
The complete calculation, representing 2500 people in simultaneous calls, on a hubarchitecture network is:
1250 calls x 523.2kbps = 1,308,000kbps = 1277.34mbps = 1.247gbps.
Whilst from this calculation it is clear that 1250 simultaneous calls cannot be supported by a
gigabit network (it would be running at 125% of capacity), additional factors must be
considered. The calculation represents the worst case, where every crew-member is in a call.
This is never likely to occur. In addition, as mentioned previously, the network is switched, and
so, when taking into account local calls, the network usage is likely to be reduced considerably.
- 34 -
APPENDIX F : SCREEN SHOTS
The Default Tab
The Login Screen
- 35 -
Initiating A Call
The Additional Features Web Interface
- 36 -
The Damage Assessment Request Screen
- 37 -