Mobile Health Care , IST-2001-36006

bunchlearnedNetworking and Communications

Oct 30, 2013 (3 years and 10 months ago)

184 views




©
2002

CMG Wireless Data Solutions



Table of Contents

i


Mobile Health Care

,
IST
-
2001
-
36006




MobiHealth Infrastructure

Document Version:

1.1

Document Status:

DRAFT

Document Release Date:

January 2003






ii



MobiHealth Infrastructure



©
2002

CMG Wireless Data Solutions


Table of Contents

1

MobiHealth System

................................
................................
................................
........
8

1.1

Mobi Health 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

Propo
sed security used in combination wit h the WSB

................................
.......

9

1.2.3

Surrogat e Host, Lookup Server, BAN Dat a Repository

................................
......

9

2

Interfaces Pull Service Broker
................................
................................
..................

10

2.1

Location provider

................................
................................
................................
........

10

2.2

Origi n Server

................................
................................
................................
..............

10

2.3

Short Message Service Centre

................................
................................
....................

11

2.3.1

UCP
-
SMSC

................................
................................
................................
..

11

2.3.2

SMPP SMSC
................................
................................
................................

11

2.4

Wireless Frame
work

................................
................................
................................
...

11

2.5

CMG support

................................
................................
................................
..............

11

3

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 Termi nal

................................
................................
................................
..........

14

3.5

CMG support

................................
................................
................................
..............

14

4

VPN

................................
................................
................................
................................
..

15

4.1

VPN Concept
................................
................................
................................
..............

15

4.2

VPN Sessions
................................
................................
................................
.............

15

5

VPN Hardware

................................
................................
................................
...............

17

5.1

VPN Concen
trator, WDS side

................................
................................
......................

17

5.2

Firewall, customer side

................................
................................
................................

17

5.3

VPN Client, customer side

................................
................................
...........................

17




©
2002

CMG Wireless Data Solutions



Table of Contents

iii

6

CMG VPN solution requirements
................................
................................
.............

18

6.1

Requirements CMG
side

................................
................................
.............................

18

6.2

Requirements Customer Side

................................
................................
......................

18





©
2002

CMG Wireless Data Solutions



List of Figures

v

List of Figures

Figure 1 Overvi ew 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





Pre
face

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 wi
th telecommunication networks and applications.






1

MobiHealth System

1.1

MobiHealth Infrastructure

1.1.1

Overview



Figure
1

Overview MobiHealth Infrastructure






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 ca
se 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 aske
d 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 combina
tion 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 wire
less 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 “Wirele
ss 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 produc
ts to complete the system are also described.



Figure
2
-
1
: External Interfaces

2.1

Location provider

WSB can interface with an external Location provider to obtain subscriber related l
ocation
information.

To WSB:

-

Location and positioning information.

From WSB:

-

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:

-

HTTP
-
response or HTTPS
-
response

From WSB:

-

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). SM
SC 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:

-

short message


-

delivery notification (short message)

From WSB:

-

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/In
tranet, 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:

-

short message


-

delivery notification (short message)

From WSB:

-

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 a
pplied in combination with all available modules

To WSB:

-

API responses

From WSB:

-

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).


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:

-

PAP/HTTP request or PAP/HTTPS request

From Push Service Broker:

-

PAP/HTTP response or PAP/HTTPS response


The notificatio
n 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:

-

PAP/H
TTP request or PAP/HTTPS request

To Push Service Broker:

-

PAP/HTTP response or PAP/HTTPS response

3.1.1

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
depl
oy 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 OTA
-
W
SP 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 tha
t 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.

Interf
ace 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:

-






-

client capabilities query





-

OTA
-
WSP push





-

subscriber data





-

service data





-

profile data





-

meta
-
profile data





-

get/set SNMP a
ttribute commands





-

accounting data (billing)

To Push Service Broker:

-






-

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 mess
ages 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 subscribe
rs. The UCP
-
SMSC is able to send delivery notifications back to the Push
Service Broker.

To Push Service Broker:

-

short message





-

delivery notification (short message)

From Push Service Broker:

-

short message


On this interface we support the UCP pro
tocol 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 notif
ications back to the Push
Service Broker.

To Push Service Broker:

-

short message





-

delivery notification (short message)

From Push Service Broker:

-

short message




3.4

Mobile Terminal

The OTA
-
HTTP interface is used to send push messages over HTTP as de
fined 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:

-

push result





-

session information

From Push Service Broker:

-

OTA
-
HTTP push





-

session info
rmation

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 secur
ity. 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 i
n 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 connect
ion 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 assig
ned 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.





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 CS
-
router (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 expect
ed 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 so
urce 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 rou
ter 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 require
ments 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 requ
irements 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 tun
nel 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 provi
de 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 tun
nel 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 Hardwar
e 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



Figure
2
:

Overview BeSys / Management





Figure
3
: Overview MobiHealth / Management BeSys






Abbreviations

Abbreviation

Description

API

Application Programming Interface

BAN

Body Area Network

BANDR

BAN Data Repos
itory

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

S
urrogate 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 Protoco
l

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 En
cryption 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