Mobile Health Care , IST-2001-36006
MobiHealth Infrastructure
Document Version:
1.1
Document Status:
DRAFT
Document Release Date: January 2003
© 2002 CMG Wireless Data Solutions — Table of Contents
i
Table of Contents
1
2
3
4
5
ii
MobiHealth System ............................................................................................. 8
1.1
MobiHealth Infrastructure ...................................................................................................... 8
1.1.1
Overview ................................................................................................................. 8
1.2
Description of the BE system ................................................................................................. 9
1.2.1
Wireless Service Broker TM ..................................................................................... 9
1.2.2
Proposed security used in combination with the WSB ........................................... 9
1.2.3
Surrogate Host, Lookup Server, BAN Data Repository ......................................... 9
Interfaces Pull Service Broker ......................................................................... 10
2.1
Location provider ................................................................................................................. 10
2.2
Origin Server ........................................................................................................................ 10
2.3
Short Message Service Centre ............................................................................................ 11
2.3.1
UCP-SMSC .......................................................................................................... 11
2.3.2
SMPP SMSC ........................................................................................................ 11
2.4
Wireless Framework ............................................................................................................ 11
2.5
CMG support ........................................................................................................................ 11
Interfaces Push Service Broker ....................................................................... 12
3.1
Push Initiator ........................................................................................................................ 12
3.1.1
Transfer encoding ................................................................................................. 12
3.2
Wireless Framework ............................................................................................................ 13
3.3
Short Message Service Centre ............................................................................................ 14
3.3.1
UCP-SMSC .......................................................................................................... 14
3.3.2
SMPP SMSC ........................................................................................................ 14
3.4
Mobile Terminal ................................................................................................................... 14
3.5
CMG support ........................................................................................................................ 14
VPN .................................................................................................................... 15
4.1
VPN Concept ....................................................................................................................... 15
4.2
VPN Sessions ...................................................................................................................... 15
VPN Hardware ................................................................................................... 17
5.1
VPN Concentrator, WDS side .............................................................................................. 17
5.2
Firewall, customer side ........................................................................................................ 17
5.3
VPN Client, customer side ................................................................................................... 17
MobiHealth Infrastructure — © 2002 CMG Wireless Data Solutions
6
CMG VPN solution requirements .................................................................... 18
6.1
Requirements CMG side...................................................................................................... 18
6.2
Requirements Customer Side .............................................................................................. 18
© 2002 CMG Wireless Data Solutions — Table of Contents
iii
List of Figures
Figure 1 Overview MobiHealth Infrastructure .......................................................................................... 8
Figure 2-1: External Interfaces ............................................................................................................... 10
Figure 3-1: External interfaces of the system ........................................................................................ 12
Figure 2: Overview BeSys / Management ............................................................................................. 19
Figure 3: Overview MobiHealth / Management BeSys .......................................................................... 20
© 2002 CMG Wireless Data Solutions — List of Figures
v
Preface
Purpose
This document specifies the Infrastructure of the MobiHealth project and the functionality
used by the Wireless Service Broker TM ,the Surrogate Host, Lookup Server and the BAN
Data Repository. All these items called the Back End System (BeSys). This specification is
meant to give a clear overview of the architecture of the MobiHealth Infrastructure and
perspective of what the Wireless Service Broker TM is supposed to offer from a hospital point
of view.
Audience
This document is intended for people who want to know more about the Infrastructure of the
MobiHealth project and the functionality and services of the BeSys. Readers are expected to
be familiar with telecommunication networks and applications.
1
MobiHealth System
1.1 MobiHealth Infrastructure
1.1.1
Overview
GPRS/UMTS
End User Application
Actu
ator
Radio tower
GPRS /
UMTS
Operator
Front-End
Sens
or
Internet
Note: VPN connector
is only needed for remote
support WSB (CMG) and remote
support SH, Lus and BANDR (UT)
MBU
VPN Concentrator
Router
DMZ
DMZ
BeSys
Firewall
IDC
Wireless Service
Broker
IBM
Surrogate Host,
Look Up Server.
BAN
DR
Figure 1 Overview MobiHealth Infrastructure
BAN Data Repository
End User Application
Healthcare
Provider
Network
1.2 Description of the BE system
The MobiHealth Back-End System is located at the Hospitals DMZ, see below the horizontal
line.
Components of the Back-End System:

Wireless Service Broker TM

Surrogate Host, Lookup Server, BAN Data Repository
1.2.1
Wireless Service Broker TM
The Wireless Service Broker enables service providers to structure their electronic services
and to offer them to specific target audiences in a controlled and orderly way. The Wireless
Service Broker in this case is the security gateway. Configurable service offering and
navigating service menu’s is performed by means of point and click.
The following functionality will be used:

User authentication and Authorization, to grant the MBU for the Surrogate Host, this
can be done by Username and Password, or by Pincode.

Push Service Broker, this functionality will be used for push control information to
the MBU by IP address, and when the mobile is not online to make a Session
Initiation Request so the MBU will be asked to make a connection.

The Wireless Service Broker will be used as Security Proxy gateway.

Virtual Gateways will be used for separate Subscriber Data Bases.

Billing functionality for logging information.

Service profiles.
1.2.2
Proposed security used in combination with the WSB
The proposed security used in combination with the Wireless Service Broker is End-to-End
security (HTTPS) in both ways. The protocol W-TCP will be used instead of TCP. This
protocol has a better performance then TCP in a network with wireless characteristics.
1.2.3
Surrogate Host, Lookup Server, BAN Data Repository
The Surrogate Host, Lookup Server and BAN Data Repository will be used to access and
stored data delivered from the MBU. Further from this site the MBU will be controlled.
The “Wireless Service Broker” and the “Surrogate Host, Lookup Server and BAN Data
Repository” will be installed on different hardware platforms. This is for remote support of
software products on different hardware platforms through different departments.
2
Interfaces Pull Service Broker
This chapter focuses on interfaces to external systems. It describes the capabilities of these
interfaces and how they are related to system functionality. In the presented architectural
structure, interfaces used to third party products to complete the system are also described.
CMG
Support
Origin
Server
WSB
Pull Service Broker
Wireless
Framework
Location
Provider
Short Message Service Centre
UCP
SMSC
SMPP
SMSC
Figure 2-1: External Interfaces
2.1 Location provider
WSB can interface with an external Location provider to obtain subscriber related location
information.
To WSB:
From WSB:
- Location and positioning information.
- Location and positioning requests.
2.2 Origin Server
The Origin Server represents the interface to the origin server via the Internet or Intranet,
used to retrieve WML-content for the mobile (either directly or via a web proxy). The output
to the Origin Server consists of HTTP or HTTPS-requests sent over a standard
Transmission Control Protocol/Internet Protocol (TCP/IP) communication facility. Each
request holds specific data for that request.
To WSB:
From WSB:
- HTTP-response or HTTPS-response
- HTTP-request or HTTPS-request.
2.3 Short Message Service Centre
2.3.1
UCP-SMSC
The UCP-SMSC is used to send and/or receive short messages to/from WSB, using the
Universal Computer Protocol (UCP). SMSC takes the initial action by sending short
messages to WSB. These short messages are processed by WSB and the resulting
content, taken from the Internet/Intranet, is sent back to SMSC. Also the UCP-SMSC is
used for sending OTAP and challenge messages to mobile subscribers. The UCP-SMSC is
able to send delivery notifications back to WSB.
To WSB:
From WSB:
- short message
- delivery notification (short message)
- short message
On this interface we support the UCP protocol as specified.
2.3.2
SMPP SMSC
The SMPP-SMSC is used to send and/or receive short messages to/from WSB, using the
SMPP-protocol. SMSC will take the initial action by sending short messages to WSB. These
short messages will be processed by WSB and the resulting content, taken from the
Internet/Intranet, will be sent back to SMSC. Also the SMPP-SMSC is used for sending
OTAP and challenge messages to mobile subscribers. The SMPP-SMSC is able to send
delivery notifications back to WSB.
To WSB:
From WSB:
- short message
- delivery notification (short message)
- short message
2.4 Wireless Framework
The framework module contains the basic software features that are always required to
deploy any of the Wireless Service Broker modules. Moreover the framework contains a
number of software options that can be applied in combination with all available modules
To WSB:
From WSB:
- API responses
- API calls
2.5 CMG support
CMG support can connect to the WSB system by means of a VPN tunnel. The Customer
Support department of CMG has to make a connection. The operator has to open the line
before CMG support is able to make a connection to increase the security. CMG support
has to authorise by means of a PPP-connection.
3
Interfaces Push Service Broker
This chapter discusses the external interfaces of Push Service Broker. For each interface, a
description of in going and outgoing data flows is being given. Figure 3-1 shows the
interfaces to Push Service Broker: (all lines crossing the dotted box are considered to be
Push Service Broker interfaces).
Wireless Framework
(PullSB, OAM, Billing, LDAP)
Short Message Service Centre
Push Initiator
WSB
Push Service Broker
UCP
SMSC
SMPP
SMSC
Mobile Terminal
CMG Support
Figure 3-1: External interfaces of the system
3.1 Push Initiator
The Push Initiator (PI) represents the interface to the push server via the Internet or Intranet,
either directly or via a web proxy. The PI sends push messages to the Push Service Broker
to be forwarded to the end user device
To Push Service Broker:
From Push Service Broker:
-
PAP/HTTP request or PAP/HTTPS request
PAP/HTTP response or PAP/HTTPS response
The notification server is the entity associated to the Push Initiator, which will receive push
notification results in case the Push Initiator requested it during the push submission time.
The Notification server acts as an HTTP server.
From Push Service Broker:
To Push Service Broker:
3.1.1
-
PAP/HTTP request or PAP/HTTPS request
PAP/HTTP response or PAP/HTTPS response
Transfer encoding
 The following transfer encodings are supported on the pap request: None, 7bits and
8bits.
 The following transfer encodings are supported on the control part of the pap request:
None, 7bits, 8bits, base64 and quoted-printable.
 The following transfer encodings are supported on the content part of the pap request:
None, 7bits, 8bits, base64 and quoted-printable.
 The following transfer encodings are supported on the capability part of the pap request:
None, 7bits, 8bits, base64 and quoted-printable.
 The response over HTTP is never encoded.
3.2 Wireless Framework
The framework module contains the basic software features that are always required to
deploy any of the Wireless Service Broker modules. Moreover the framework contains a
number of software options that can be applied in combination with all available modules.
The PullSB is used to send push messages from the Push Service Broker using the OTAWSP protocol. This protocol may be used for connection oriented and connection less push
requests. The COMM interface is used to send push messages over OTA-WSP via the
PullSB.
Client Capabilities Query is a request from the PI for the device capabilities of a certain
subscriber. These capabilities are stored on the Wireless Framework and are requested
using the COMM interface. The returned information is an XML document describing all
known device software, hardware and configuration characteristics so that a PI can tailor the
push content for a certain subscriber.
The Lightweight Directory Access Protocol is used to communicate with a directory server
for data storage and retrieval. This contains data like subscriber information and PI
information.
Interface statistics on the various parts of the PushSB system can be viewed via the OAM
web interface. Also online configuration changes can be done and SNMP traps can be send
to a SNMP Management package. The PushSB system supports SNMP version 1.
The PushSB can access external Prepaid Billing System (PBS) using the Billing API.
From Push Service Broker:
To Push Service Broker:
-
client capabilities query
OTA-WSP push
subscriber data
service data
profile data
meta-profile data
get/set SNMP attribute commands
accounting data (billing)
client capabilities
push result
subscriber data
service data
profile data
meta-profile data
NMP alarms (traps)
NMP attribute values
-
accounting data (billing)
3.3 Short Message Service Centre
3.3.1
UCP-SMSC
The UCP-SMSC is used to send and/or receive short messages to/from Push Service
Broker, using the Universal Computer Protocol (UCP). SMSC takes the initial action by
sending short messages to the Push Service Broker. The Push Service Broker processes
these short messages and the resulting content, taken from the Internet/Intranet, is sent
back to SMSC. Also the UCP-SMSC is used for sending OTAP and challenge messages to
mobile subscribers. The UCP-SMSC is able to send delivery notifications back to the Push
Service Broker.
To Push Service Broker:
From Push Service Broker:
-
short message
delivery notification (short message)
short message
On this interface we support the UCP protocol as specified.
3.3.2
SMPP SMSC
The SMPP-SMSC is used to send and/or receive short messages to/from the Push Service
Broker, using the SMPP-protocol. SMSC will take the initial action by sending short
messages to Push Service Broker. The Push Service Broker will process these short
messages and the resulting content, taken from the Internet/Intranet, will be sent back to
SMSC. Also the SMPP-SMSC is used for sending OTAP and challenge messages to mobile
subscribers. The SMPP-SMSC is able to send delivery notifications back to the Push
Service Broker.
To Push Service Broker:
From Push Service Broker:
-
short message
delivery notification (short message)
short message
3.4 Mobile Terminal
The OTA-HTTP interface is used to send push messages over HTTP as defined by the
WAP 2.0 standards. Due to the characteristics of HTTP this is only applicable for connection
oriented push requests.
To Push Service Broker:
From Push Service Broker:
-
push result
session information
OTA-HTTP push
session information
3.5 CMG support
CMG support can connect to the WSB system by means of a VPN tunnel. The Customer
Support department of CMG has to make a connection. The operator has to open the line
before CMG support is able to make a connection to increase the security. CMG support
has to authorise by means of a PPP-connection.
4
VPN
4.1 VPN Concept
There is an interest in providing VPN connectivity from CMG to the customer. Not all
customers provide ISDN lines into the server rooms and are not interested into providing
one because of policies or the costs. Using existing Internet access is more attractive.
The VNP Concentrator is needed for remote support of the Back-End System. Via the VPN
tunnel the Customer Support department of CMG has the availability to access in a secure
way to give support on the Wireless Service Broker. On the same way it is possible for the
University of Twente to give remote support on the Surrogate Host, Lus and BAN Data
repository of the Back-End System.
Since the VPN solution is to be used in the customer support environment, the choice is
made to separate this VPN solution form the other VPN solutions that are already in place.
The topology is such that the access server is accessed from the CMG intranet and that
from the access server the customer systems can be reached.
The VPN connection starts in the VPN router and ends in the VPN support router. Between
the two, there is an encrypted and authenticated data channel, which can be continuously
authenticated.
4.2 VPN Sessions
A VPN session is a secure session from one point to another over an external network. This
‘tunnel’ will be created by the GRE protocol. To create security in the information through
the ‘tunnel’ the IP-Sec protocol is used to apply 3DES encryption.
To set up a VPN connection via the Internet, the VPN support router needs to establish a
point-to-point connection via the Internet to the public IP address of the VPN client.
Within the firewall, this address will be translated by statically NAT to the private CMG
address assigned to the private interface of the VPN client located on the VPN DMZ.
Therefore, certain ports on the firewall need to be opened to allow the VPN tunnel through
to the VPN client.
See connection scenario below.
VPN client
internet
VPN Concentrator
CMG Nieuwegein (NL)
The customer is controlling the access over the VPN-tunnel. When they want to obtain
support from the CMG organisation, they open the VPN-connection to allow access to their
systems. At the end of the support, the customer has to close the VPN-connection to block
access to their systems.
To open the VPN-connection the customer must telnet to the CS-router (VPN-router) using
the username ‘open’ and to close the VPN-connection the customer must telnet to the CSrouter (VPN-router) using the username ‘close’.
A customer is not able, due to the security policy, to make a connection to another customer
(CS-router) over the VPN-connection.
5
VPN Hardware
5.1 VPN Concentrator, WDS side
In this VPN concept, as the VPN concentrator the Cisco-3640 is used. Every customer
connecting via VPN will have the ‘tunnels’ terminated on this router.
The addresses of the VPN concentrator will be translated by static NAT tables in the
Firewall to a public IP address, so that it can be reached from the Internet.
The firewall between the Internet and the concentrator is configured to allow VPN
connections.
Name
VPN DMZ address
Static NAT
address
NL-NIE-VPN03
XXX.XXX.XXX.XXX
212.136.56.9
5.2 Firewall, customer side
As the customer firewall is outside the scope of this document, only a recommendation can
be given about the configuration. In the configuration it is assumed that the support router
remains where it originally was and that the unused Ethernet port that is connected to the
LAN.
Any firewall between the Internet and the support router are expected to allow certain traffic
through to the support router:
Protocol 50 (ESP) port any
Protocol 51 (AH) port any
Protocol 17 (UDP), port 10000
The administrator of the customer firewall can setup rules to allow only the specific VPN
traffic using a fixed source and destination addresses (CMG Customer Support VPN router
and CMG VPN Concentrator). CMG will provide the necessary information to setup the
greatest security between the customer and CMG as possible.
5.3 VPN Client, customer side
The VPN support router is the Cisco 3002 with ISDN BRI interface that is delivered with, for
example, the SMSC STP. Required is an upgrade in the IOS version to enable IPSec and
3DES and in most cases an upgrade to support 40Mb of RAM and 8 Mb of flash. These are
the requirements to enable IPSec and 3DES. The goal is to reuse the support router for
VPN.
Additional information: The support router needs to have at least 40Mb of ram, 8Mb flash
and an unused Ethernet port.
The Hardware will be delivered by CMG and CMG is also the owner of this hardware.
6
CMG VPN solution requirements
For management of the Back-End-System, the customer support department from CMG has
to connect via the VPN concentrator. The hardware will be provided by CMG
The requirements can be split up into requirements for two parties, namely the CS
department and the connecting customers.
6.1 Requirements CMG side
Transparency for making connection from the support machines towards customers (CS
sees no difference).
Possibility of redundancy (e.g. having 2 or 3 tunnel end-points in different regions) start with
Nieuwegein as end-point only
Security – each tunnel needs to get verified (on IP number and shared secret key)
Security – inbound traffic over the VPN tunnel is only allowed to go to the support machines
(not to other customers)
Tunnel end point devices only for VPN available (no other functionality than support traffic)
Part of the Red Network
Easy to maintain
Document for Implementation
Configuration provided by the ICT Department
Scalable hardware to provide 1 or more tunnels
6.2 Requirements Customer Side
Tunnel end point devices only for VPN available (no other functionality than support traffic)
Security – inbound traffic only from CMG network.
No Network Address Translation (NAT) on IP address used for tunnel end-point (not
available yet in Cisco IOS SW; might change over time – planned mid 2002)
Configuration provided by the ICT Department
Internet connection available
Upgrade of Router Software to support IPsec
Possible upgrade necessary of Router Hardware to include extra port for Internet
connectivity
Possibility to open and close VPN tunnel
Possibility to have ISDN/PSTN/X25 backup line
Additional costs on customer side are for his account
MobiHealth Infrastructure / Customer Support
CMG Customer Support
Internet
Note: VPN connector
is only needed for remote
support WSB (CMG) and remote
support SH, Lus and BANDR (UT)
VPN Concentrator
DMZ
BeSys
IDC
Wireless Service
Broker
IBM
Surrogate Host,
Look Up Server.
BAN
DR
Figure 2: Overview BeSys / Management
BAN Data Repository
End-User
1st level support
CMG Customer Support Department
2nd level support
University Twente
Figure 3: Overview MobiHealth / Management BeSys
WSB
SH, LUS, BANDR
Abbreviations
Abbreviation
Description
API
Application Programming Interface
BAN
Body Area Network
BANDR
BAN Data Repository
BE
Back-End
BRI
Basic Rate Interface
CS
Customer Support department CMG
DMZ
Demilitarised Zone
GPRS
General Packet Radio Service
GRE
Generic Routing Encapsulation
HTTP
HyperText Transfer Protocol
HTTPS
HyperText Transfer Protocol Secure
ISDN
Integrated Services Digital Network
IST
Information Society Technologies
LUS
Lookup Server
MBU
Mobile Base Unit
NMP
Network Management Protocol
OTAP
Over The Air Protocol
PAP
Push Access Protocol
PI
Push Initiator
PPP
Point to Point Protocol
SH
Surrogate Host
SMPP
Short Message Peer to peer Protocol
SMSC
Short Message Service Centre
SNMP
Simple Network Management Protocol
TCP
Transmission Control Protocoll
TCP/IP
Transmission Control Protocol / Internet Protocol
UCP
Universal Control Protocol
UMTS
Universal Mobile Telecommunications System
Abbreviation
Description
VPN
Virtual Privat Network
WAP
Wireless Application Protocol
WSB
Wireless Service Broker
WSP
Wireless Session Protocol
W-TCP
Wireless Profiled TCP
WTLS
Wireless Transport Layer Security
3DES
Data Encryption Standard
Version History
Version
Status
Date
Details of Changes
Author(s)
0.1
DRAFT
29-12-2002
Initial version
Hugo Geuverink
1.1
DRAFT
27-01-2003
Changes, new overviews
Hugo Geuverink
Approval
Version
Date
Approved by
Signature