68
MobiHealth_WP3_TME_D3.1_v1_01.01.03 IST Programme Project Number: IST-2001-36006 Acronym: MobiHealth A project funded by the European Community under the “Information Society Technologies” Programme(1998-2002) Trial ready GPRS and UMTS networks (D 3.1) Editor: Marta Olivar Dimas, TME, Spain. Authors: UT, UPF, Telia, University of Lulea and TME Preparation Date: January 1st, 2003 Version: Ver 1.0 Contract Start Date: May 01, 2002 Duration: 18 months, (October 2003) Project co-ordinator: Rainer Herzog, Ericsson GmbH

MobiHealth WP3 TME D3.1 v1 01.01.03...2003/01/01  · MobiHealth_WP3_TME_D3.1_v1_01.01.03 5 as providers of the technologies, roaming partnership and coverage can be found here. Finally

  • Upload
    others

  • View
    1

  • Download
    0

Embed Size (px)

Citation preview

  • MobiHealth_WP3_TME_D3.1_v1_01.01.03

    IST Programme

    Project Number: IST-2001-36006

    Acronym: MobiHealth

    A project funded by the European Community under the “Information Society Technologies” Programme(1998-2002)

    Trial ready GPRS and UMTS networks (D 3.1)

    Editor: Marta Olivar Dimas, TME, Spain. Authors: UT, UPF, Telia, University of Lulea and

    TME Preparation Date: January 1st, 2003 Version: Ver 1.0 Contract Start Date: May 01, 2002 Duration: 18 months, (October 2003) Project co-ordinator: Rainer Herzog, Ericsson GmbH

  • MobiHealth_WP3_TME_D3.1_v1_01.01.03

    TABLE OF CONTENTS

    1 INTRODUCTION ................................................................................................4

    2 INTRODUCTION TO GPRS AND UMTS NETWORKS ...............................6 2.1 GPRS..................................................................................................................6

    2.1.1 GPRS ARCHITECTURE OVERVIEW...................................................6 2.1.2 GPRS SERVICES ..................................................................................11

    2.2 UMTS...............................................................................................................18 2.2.1 UMTS ARCHITECTURE OVERVIEW ...............................................19 2.2.2 UMTS SERVICES .................................................................................22

    3 GPRS AND UMTS SITUATION IN EACH TRIAL SITE ............................24 3.1 Spain.................................................................................................................24

    3.1.1 GPRS communication architecture.........................................................24 3.1.2 UMTS STATE........................................................................................25

    3.2 The Netherlands ...............................................................................................26 3.2.1 GPRS communication architecture.........................................................27 3.2.2 UMTS STATE........................................................................................28

    3.3 Germany...........................................................................................................28 3.3.1 GPRS communication architecture.........................................................29 3.3.2 UMTS STATE........................................................................................30

    3.4 Sweden .............................................................................................................30 3.4.1 GPRS communication architecture.........................................................31 3.4.2 UMTS STATE........................................................................................32

    4 TECHNICAL REQUIREMENTS AND LIMITATIONS IN EACH TRIAL SCENARIO .........................................................................................................33

    4.1 BANDWIDTH .................................................................................................33 4.1.1 Spain .......................................................................................................34 4.1.2 The Netherlands......................................................................................35 4.1.3 Germany .................................................................................................36 4.1.4 Sweden....................................................................................................37

    4.2 Coverage and availability.................................................................................38

    4.3 Reliability.........................................................................................................38 4.3.1 Test of TCP/UDP performance over O2 and TME GPRS networks......39 4.3.2 Tests of throughput, latency and jitter over Telia GPRS network..........40

    4.4 Traffic management .........................................................................................41

    4.5 Security ............................................................................................................41 4.5.1 Tests of security......................................................................................42

    4.6 Mobility............................................................................................................43

    5 CONCLUSIONS .................................................................................................45

    6 REFERENCES....................................................................................................46

    7 GLOSSARY ........................................................................................................47

  • MobiHealth_WP3_TME_D3.1_v1_01.01.03 3

    ANNEX I.....................................................................................................................49

    ANNEX II ...................................................................................................................62

    ANNEX III..................................................................................................................63

    ANNEX IV..................................................................................................................67

  • MobiHealth_WP3_TME_D3.1_v1_01.01.03

    1 INTRODUCTION

    This document describes the “Trial ready GPRS and UMTS networks”, deliverable 3.1 of the MobiHealth project.

    The objective of the MobiHealth project is the development and trial of new services and applications in the area of mobile health, promoting the use and development of GPRS and UMTS technologies. This document provides information about the state of the GPRS and UMTS networks in each trial site (Germany, the Netherlands, Spain and Sweden) in order to be ready for the trial of the developed applications.

    The results described in this deliverable 3.1 depend on the conclusions of other deliverables and Workpackages. One of these influences is the definition of the trial scenarios (deliverable 1.3). Technical aspects as bandwidth, coverage, reliability and security have been explained from the point of view of each trial site.

    The bandwidth requirements of the trial scenarios are included in order to evaluate the GPRS or UMTS use. Each trial scenario has been analysed in detail in order to know if real-time transmission can be supported by GPRS networks or cannot.

    Due to the European situation related to UMTS where there is not a defined deadline of the availability of UMTS terminals, the UMTS trials of the project will be affected. There will be test beds in the Netherlands, Sweden and Spain for short trial periods if UMTS terminals are available for the project.

    The deliverable includes security aspects related to WP3 issues. These security aspects have been analysed between WP2 (BAN security related aspects) and WP3 (whole MobiHealth system security aspects) taking in mind the requirements of the trial scenarios defined in WP1.

    Several tests have been done over TME, O2 and Telia GPRS networks in WP3 for evaluating their behaviour. The results of these tests are included in this deliverable.

    The performance of the previous technical aspects will be very important during the trials that are the objective of WP4.

    The information provided by the GPRS and UMTS networks during the trials will be of interest for WP5 in order to evaluate them from a technical point of view. In advance, Deliverable 1.4 “Description of the trial evaluation methodology” introduces a technical evaluation (2.5/·G wireless communications included) that will be taken into consideration by WP5.

    The deliverable is divided into three main parts. The first of all is an Introduction of the GPRS and UMTS networks where the general architecture and services of these technologies are described. After this introduction, there is a description of the situation of GPRS and UMTS in each trial site. Aspects

  • MobiHealth_WP3_TME_D3.1_v1_01.01.03 5

    as providers of the technologies, roaming partnership and coverage can be found here. Finally the technical requirements and limitations in each trial scenario are explained. Bandwidth, reliability (TCP/UDP, throughput, latency and jitter performance) and security are the concepts evaluated in this paragraph.

    At the end of the deliverable, there are four technical annexes that supported the information provided by this deliverable.

  • MobiHealth_WP3_TME_D3.1_v1_01.01.03 6

    2 INTRODUCTION TO GPRS AND UMTS NETWORKS

    2.1 GPRS

    GPRS (General Packet Radio Service) is a new technology that provides high capacity end-to-end IP packet services over the GSM network.

    GPRS uses a packet-mode technique to transfer high-speed and low-speed data signalling in an efficient manner, optimising the use of the network and radio resources.

    New GPRS radio channels are defined, and the allocation of these channels is flexible: from 1 to 8 radio interface timeslots can be allocated per TDMA frame, timeslots are shared by the active users, and uplink and downlink are allocated separately. The radio interface resources can be shared dynamically between speech and data services depending on service load and operator preference. Various radio channel coding schemes are specified to allow different bit rates.

    Applications based on standard data protocols are supported, and interworking is defined with IP network and X.25 network. GPRS also allows SMS transfer over GPRS radio channels.

    GPRS is designed to support from intermittent and bursty data transfers through to occasional transmission of large volume of data.

    2.1.1 GPRS ARCHITECTURE OVERVIEW

    Figure 1: GPRS network architecture

  • MobiHealth_WP3_TME_D3.1_v1_01.01.03 7

    2.1.1.1 Mobile Station (MS)

    The Mobile Station (MS) consists of the Terminal Equipment (TE) and a Mobile Terminal (MT) (the MT and TE parts could actually be in the same piece of equipment).

    The Terminal Equipment (TE) is the computer terminal that the end-user works on. This is the component used by the GPRS system to transmit and receive end-user packet data. The TE could be for example a laptop computer or a PDA. The GPRS system provides IP connectivity between the TE and an Internet Service Provider or Corporate LAN connected to the GPRS system.

    The Mobile Terminal (MT) communicates with a TE and over the air with the Base Transceiver Station (BTS). The MT must be equipped with software for the GPRS functionality when it is used in conjunction with the GPRS system. The MT is associated with a subscriber in the GSM system, and establishes a link to an SGSN. Channel reselection is provided at the radio link between the MT and the SGSN. The IP connection is static from the TE point of view, i.e. the TE is not aware of being mobile and retains its assigned IP address until the MT detaches.

    The SIM card for a GPRS MS stores GPRS-specific information.

    The three possible GPRS classes for MS mode of operation are:

    • Class A for simultaneous GPRS and other GSM services support.

    • Class B for monitoring of both GPRS and other GSM services but operation of only one set of services at a time.

    • Class C for exclusively GPRS services support.

    The MS in GPRS can be in one of three states:

    • Idle: The MS is switched on, but not GPRS attached. Data transfer between MS and the GPRS network is not possible.

    • Standby: The MS is GPRS attached and sends "Routing Area Updates" to the SGSN.

    • Ready: GPRS Attach was performed recently and a packet transfer is ongoing or has recently ended. For a packet transfer to be possible, PDP context activation must take place first. A ready timer, set in the SGSN, defines how long the MS remains in the ready state after the packet transfer has ended. The timer can take values form zero to infinity. After the timer expires the mobile switches over to a standby state. A ready MS is not page.

    2.1.1.2 Base Station System (BSS)

    The Base Station System (BSS) consists of a Base Station Controller (BSC) and a Base Transceiver Station (BTS).

  • MobiHealth_WP3_TME_D3.1_v1_01.01.03 8

    The Base Transceiver Station (BTS) is the radio equipment which transmits and receives information over the air to enable the BSC to communicate with MSs in the BSC area. A group of BTSs is controlled by a BSC. The BTS must contain GPRS-specific software.

    The Base Station Controller (BSC) provides all the radio-related functions. The BSC has the functionality to set up, supervise and disconnect circuit-switched (CS) calls and packet-switched (PS) data sessions. It is a high capacity switch that provides functions such handover, cell configuration data, and channel assignment. The BSC must be equipped with GPRS hardware and software when used for GPRS. So a new component named PCU (Packet Control Unit) has to be installed in the BSC. Its main functionalities are:

    • Multiplexing GPRS traffic and circuit switched traffic.

    • Handling of GPRS radio resources: allocating channels for GPRS connections.

    • Distribution of packet data to the MS.

    • Handling connection towards the SGSN.

    One or several BSCs are served by an MSC, and a number of BSCs are served by an SGSN. A BSC can however only be connected to one SGSN.

    The BTS separates the MS-originated circuit-switched calls from the packet data communication before the BSC will forward CS calls to the MSC/VLR and PS data to the SGSN.

    2.1.1.3 GPRS Support Nodes (GSN)

    A GPRS Support Node (GSN) contains functionality required to support GPRS. GSN is the general notion for both the Serving GPRS Support Node (SGSN) and the Gateway GPRS Support Node (GGSN).

    The Serving GPRS Support Node (SGSN) is a primary component in the GPRS system and is one of the new nodes required in the GSM network to allow GPRS services. The SGSN forwards incoming and outgoing IP packets addressed to/from a mobile station that is attached within the SGSN area. The SGSN provides:

    • Packet routing and transfer to and from the SGSN area. It serves all GPRS subscribers that are physically located within the geographical SGSN area. A GPRS subscriber may be served by any SGSN in the network, all depending on location. The traffic is routed from the SGSN to the BSC, via the BTS to the mobile station.

    • Security over radio access: Ciphering and authentication.

    • Session management.

  • MobiHealth_WP3_TME_D3.1_v1_01.01.03 9

    • Logical link management towards the MS.

    • Connection to HLR, MSC, SMS-GMSC, SMS-IWMSC, GGSN.

    • Output of charging data. The SGSN collects charging information for each MS related to the radio network usage. Both the SGSN and the GGSN collect charging information on usage of the GPRS network resources.

    Like the SGSN, the Gateway GPRS Support Node (GGSN) is a primary component in the GPRS system and is one of the new nodes required in the GSM network to allow GPRS services. The GGSN provides:

    • The interface towards the external IP packet networks. The GGSN therefore contains access functionality that interfaces external ISP functions like routers and RADIUS servers (Remote Access Dial-In User Service) which are used for security purposes. From the external IP network's point of view, the GGSN acts as a router for the IP addresses of all the subscribers served by the GPRS network. The GGSN thus exchanges routing information with the external network.

    • Security functions towards the Internet (Radius client).

    • GPRS session management; communication set up towards external network.

    • Functionality for associating the subscribers to the right SGSN.

    • Output of charging data. The GGSN collects charging information for each MS, related to the external data network usage. Both the SGSN and the GGSN collect charging information on usage of the GPRS network resources.

    The SGSN and GGSN functionalities may be combined in the same physical node (network element) or they may reside in different physical nodes. SGSN and GGSN contain GPRS backbone network protocol (IP) routing functionality and they may be interconnected with IP routers.

    SGSN and GGSN can be located in different PLMNs (Public Land Mobile Network). In this case, the two PLMNs will be connected via Border Gateways for security and interoperability reasons.

    2.1.1.4 Home Location Register (HLR)

    The Home Location Register (HLR) is the database that holds subscription information for every person who has a subscription from the GSM/GPRS operator. The HLR stores information for CS and PS communications. For GPRS, subscriber information is exchanged between HLR and SGSN.

    The HLR also stores the subscription information regarding mobile-terminated SMS, which includes the option of SMS transfer via the SGSN to the MS.

  • MobiHealth_WP3_TME_D3.1_v1_01.01.03 10

    The information going from the HLR to SGSN is what the operator sets up for the subscriber. This information transfer is done when the operator changes the subscriber information, or when a new SGSN needs to have data for a subscriber after attach or roaming. The old SGSN is also informed of the roaming.

    The subscriber file must contain GPRS subscription data:

    • Address of the SGSN currently serving the subscriber.

    • Addresses of GGSNs that will be contacted when activity from MS is detected.

    • Access Point Name (APN) describing the access point to the external computer network.

    2.1.1.5 Visitor Location Register (VLR)

    The Visitor Location Register (VLR) database contains information about all mobile stations currently located in the SGSN routing area. The SGSN in fact contains the VLR functionality for packet-switched communication.

    The VLR contains temporary subscriber information needed by the SGSN to provide services for visiting subscribers. When a MS roams into a new SGSN routing area, the VLR of that SGSN requests and stores data about the MS from the HLR.

    The VLR consists of software in a SGSN. The SGSN VLR contains information that this SGSN is being used. For the GPRS system, the HLR directly instead of the VLR is used for the authentication procedure of the MSs. The SGSN thus obtains the authentication triplets from the HLR.

    2.1.1.6 Mobile services Switching Centre (MSC)

    The Mobile services Switching Centre (MSC) performs the telephony switching functions of the GSM circuit-switched system, just as the SGSN switches the GSM packet-switched traffic.

    The SGSN Routing Area (RA) is a subset of the MSC Location Area (LA). One SGSN can handle several Routing Areas.

    There can be several MSCs corresponding to one SGSN. One MSC can also be connected to several SGSNs. The configuration is a matter of dimensioning for the actual traffic.

    2.1.1.7 Gateway Mobile services Switching Centre (GMSC)

    The Gateway Mobile services Switching Centre (GMSC) switches the communication between the GSM circuit-switched network and the Public Switched Telephone Network (PSTN), i.e. the fixed telephony network. The

  • MobiHealth_WP3_TME_D3.1_v1_01.01.03 11

    GMSC is not changed regarding to the GSM network for using by the GPRS system.

    2.1.2 GPRS SERVICES

    2.1.2.1 Network services

    From the network operator's point of view, the following services are supported in the GPRS system:

    • Payload handling:

    The GSN uses the Internet Protocol (IP) to transfer data. When an MS has attached itself at the GPRS system and had a Packet Data protocol (PDP) context activated, the TE may send end-user packets on the uplink via the MS. Other hosts may also send end-user packets to the TE on the downlink. The SGSN and GGSN route the packets to the correct address.

    The IP packets are segmented into smaller packets when sent over the air interface. The lengths of these packets depend on the coding scheme used.

    Coding Scheme Code rate Coded bits Data rate (kb/s)

    CS-1 1/2 456 9.05

    CS-2 ≈ 2/3 588 13.4

    CS-3 ≈ 3/4 676 15.6

    CS-4 1 546 21.4

    The GSN IP network routers must perform packet filtering. This means that for each IP packet the GPRS network receives from MS or an Internet Host the GSN IP network routers decide if they permit or deny the packet. The filtering is based on the packet header information made available to the IP forwarding process.

    • Radio access:

    The GPRS system provides access to radio frequencies, thus making it possible to transmit packet data on radio channels over the air interface.

    The GPRS system allows transmission of user packet data at different transmission speed. A GPRS MS might use up to 8 time slots. It is possible to combine packet data and speech/circuit data on the same radio frequencies.

  • MobiHealth_WP3_TME_D3.1_v1_01.01.03 12

    The number of time slots (TS) that the end-user can use for the data transmission depends on both the configuration of the terminal and the number of free time slots.

    The theoretic maximum throughput for the end-user depends on the coding scheme, the number of time slots available for the data transmission and the radio electric conditions (C/I, carrier to interference ratio).

    When the C/I value is low, the most efficient coding scheme are CS-1 and CS-2. In a typical GPRS network, CS-3 and CS-4 coding schemes can be used in the cell centre, but not in the borders.

    In general, GPRS network operators use CS-1 and CS-2 coding schemes. The bit rates for different numbers of available time slots are:

    Coding scheme Bit rate with 1 TS Bit rate with 2 TS Bit rate with 3 TS Bit rate with 4 TS

    CS-1 9.05 kbits/s 18.1 kbits/s 27.2 kbits/s 36.2 kbits/s

    CS-2 13.4 kbits/s 26.8 kbits/s 40.2 kbits/s 53.6 kbits/s

    • Mobility:

    The GPRS system provides mobility for TEs. The procedures available are attach/detach, routing area update, combined routing area and location area update and paging.

    - MS Attach: Before sending IP packets, the MS must do a GPRS attach and do a PDP Context Activation. The GPRS attach makes the network aware of the MS being present in the network. The attach is made by the MS to the SGSN. In the GPRS attach, the MS provides its identity (IMSI or Packet TMSI) and an indication of whether PS or combined PS and CS attach is requested. After the GPRS attach, the MS is in Ready state: it can receive SMS over GPRS and paging via GSN and can activate PDP contexts which must be done before sending and receiving GPRS data.

    - MS Detach: The MS can be explicitly detached from GPRS by the MS or the network (SGSN or HLR). The network (without notifying the MS) can also implicitly detach the MS.

    - Roaming: Mobility Management allows the MS to move between cells, between BSCs, between SGSN Routing Areas, between SGSNs within the GPRS PLMN and between PLMNs. The ability to transmit and receive data while moving is limited to roaming within one PLMN. The anchor point, which is PDP context dependent,

  • MobiHealth_WP3_TME_D3.1_v1_01.01.03 13

    within the PLMN is kept in the same GGSN during roaming. The Mobility Management also enables subscribers to roam into other PLMNs (visiting). Whether the visiting subscriber is allowed to roam within the PLMN or not is determined in the HLR. Commercial agreements between operators have to be signed for national and international roaming.

    - Authentication and Ciphering: The network authenticates the subscriber identity to confirm that an MS is the MS that claims to be. This authentication is done before the network allows the MS to access the network. The purpose is to protect the network against unauthorized use and to protect the GPRS subscribers by denying intruders the ability to impersonate authorized users.

    - Subscriber Validation: When the GPRS system authenticates the MS, it simultaneously checks that the subscriber associated with this MS has a valid packet data subscription.

    - Suspend/resume: These functions are used to switch between GPRS and CS GSM of signalling an data transmission for MS in class B mode of operation.

    • Session management:

    The session management procedures comprise:

    - PDP Context Activation: In order to send and receive GPRS data, the MS performs PDP Context Activation after the GPRS Attach. The PDP context Activation makes the MS known in the concerned GGSN and communication via the GGSN to external networks is possible. The SGSN/GGSN supports dynamic and static IP addressing for subscribers operating within their home PLMN as well as for roamer subscribers.

    - PDP Context Deactivation: At GPRS detach, all PDP contexts for the MS are implicitly deactivated. The MS, the SGSN or the GGSN can initiate the PDP Context Deactivation.

    - PDP Context Modification: An SGSN can decide, possibly triggered by the HLR, to modify parameters (the Quality of Service or the Radio Priority) that were negotiated during an activation procedure for one or several PDP contexts.

    These procedures deal with allocation of IP addresses and Quality of Service (QoS) parameters:

    - Both static and dynamic IP addresses can be allocated: The dynamic IP address are allocated by the home network GGSN or the visited network GGSN when roaming. The static IP address can either be defined for the subscription in the HLR or the Radius server could be configured to always allocate the same IP address

  • MobiHealth_WP3_TME_D3.1_v1_01.01.03 14

    to a specific subscriber. The SGSN uses the Access Point Name (APN) to interrogate a Domain name Server (DNS), which provides a list of possible GGSN IP addresses. The APN may be provided by the MS, subscribed or set by default in the SGSN.

    - The SGSN negotiates the QoS with the MS during the PDP context activation, during inter-SGSN routing area updates or if the QoS parameter is changed by an operator in the HLR.

    • Performance monitoring: It enables to detect bottlenecks and to optimise the system.

    • Security management:

    Security Management provides the means against fraudulent access to a GSN node. Security Management includes the following features:

    - MS selective authentication.

    - Data encryption.

    - O&M user authentication (HTTP, FTP, remote login).

    - O&M user authority roles.

    - Logging of O&M service requests.

    - GPRS packet filtering.

    2.1.2.2 End-users services

    An end-user system consists of a TE, an IH (Internet Host) and a cellular phone system subscriber. From the end-user point of view, the following services are supported in the GPRS system:

    • IP connectivity: The GPRS system provides IP connectivity between MSs and IHs. Data transfer is based on the IP protocol. From an end-user point of view, an MS can be used as a "modem" to connect to the Internet via the GPRS system. At each PDP context activation, an IP address is provided.

    • Different-speed transmission: An MS can be made for using different transmission speeds. The transmission rate depends on the radio interface coding scheme used.

    • Access to Internet Services: Since the MSs use IP addresses, you can connect from the GPRS system to IP services obtained from an ISP or from a Corporate LAN. The services and applications could be for example:

    - Applications with high bandwidth: www, e-mail, FTP

  • MobiHealth_WP3_TME_D3.1_v1_01.01.03 15

    - Application with low bandwidth: telemetry, remote control, e-commerce…

    - Multicast services: Meteorological, traffic or corporate information…

    2.1.2.3 Quality of service

    When we talk about quality of service, QoS, we only do reference to a set of parameters that can be observed directly and measured from the access point to the service utilised by the user. The criteria usually contemplated to evaluate the quality of the service are mainly:

    • Velocity

    • Care

    • Reliability

    The velocity with which a service petition is served can be valued in terms of bit rate with that the information is transported or well in terms of interval of time to finish the service petition.

    The care refers, however, to the correction degree with which a service petition is attended.

    The service reliability synthesises the service availability, without considering either the velocity or the care.

    In relation to each one of these evaluation criteria, we can distinguish various type of service:

    • High-quality services, in which the deviation of the measured parameter is not meaningful (guaranteed services)

    • Good-quality services, specified with a precise value of the measured parameter (predictive services)

    • Discrete-quality services characterised by a not specified variation of the measured parameter (best effort service).

    The most significant evaluation parameters, in terms of velocity are:

    • Net velocity of the binary flow (throughput)

    • Information transference time

    The throughput characterisation in a channel can be done based in the binary rhythm media and the highest binary rhythm offered to every user acceding. The necessary time for information transference is the sum of the necessary time to accede the radio channel, the time to propagate the information in the radio channel (not meaningful) and the necessary time for the transference through the net. Some parameters related to the care are:

  • MobiHealth_WP3_TME_D3.1_v1_01.01.03 16

    • Probability of a packet loss

    • Probability of a wrong packet reception

    • Probability of a packet duplication

    • Probability of wrong sequence in the packet reception

    The characteristic parameters in terms of reliability are:

    • Probability of failure in the QoS negotiation between user and network

    • Probability that the QoS established in the negotiation phase will not be guaranteed during the termination of the service petition

    • Service availability

    • Medium time between two consecutive back out of the service

    • Average duration of a back out of the service

    2.1.2.4 Service Topology

    The standard of the GPRS Service provides two different topologies:

    • Point To Point (PTP)

    • Point To Multipoint (PTM)

    A point to point service is that in which a user sends one or more packets to a unique recipient; referring to the modalities of the management of the PTP connection we can distinguish two different service classes:

    • Connectionless Point To Point Services (CLNS)

    • Connection Oriented Point To Point Services (CONS)

    A PTP CLNS is a service in which two successive packets are independent. A service with this characteristic is defined as a datagram service and can be useful to support bursty applications not interactive.

    A PTP CONS service is that in which a logic relation between the sender and receiver is established. This relation is active during the whole time of the connection. The service is a virtual circuit: in the set-up phase of the connection a route is established for the packet routing, with the difference that, respecting a switching circuits connections, physical resources become free when the packet is transmitted (maintaining the logical connection).

    This is a good option for interactive or transactional applications, with a continuo dialogue between the two ends.

  • MobiHealth_WP3_TME_D3.1_v1_01.01.03 17

    2.1.2.5 Security Services and Mechanisms

    The following general security services are defined to avoid security threats:

    • Confidentiality: Protects data to be (almost) impossible to interpret for a non authorised user during communication or storage.

    • Integrity: Protects data against non-authrorised modification, insertion, reordering or destruction during communication or storage.

    • Authentication: Provides the way to corroborate identity of the entities implied in the data creation or communication.

    • Non Repudiation: Protects against unilateral or mutual data repudiation.

    • Access control: Protects the system and resources against not authorised use.

    Different security mechanisms are used to provide the security services that are required for data.

    • Confidentiality: Data encryption.

    • Integrity: Signature or Data Encryption (Symmetrical or asymmetrical). Signature is better, since only the message hash must be encrypted.

    • Authentication: Signature or Symmetrical Encryption with private sender key. Signature is better, since only the message hash must be encrypted. An initial authentication phase including interchange of a symmetrical key, followed by data interchange encrypted with the interchanged key is also commonly used.

    • Non Repudiation: Signature, single or mutual.

    • Access control: Identification (+authentication).

    Security can be added to the different communication layers. Different security features can be provided depending on the layer the security is included.

    Communications security can include the security in all the components of the MobiHealth system, and in all the communication layers of the communication stack:

    • Data link layer: Bluetooth, Zigbee, GPRS/UMTS, ...

    • Network layer: IPsec, ...

    • Transport layer: SSL/TLS, ...

    • Application layer: Data encryption

  • MobiHealth_WP3_TME_D3.1_v1_01.01.03 18

    2.1.2.5.1 Data Link Layer Security

    Security in the Data Link Layer provides Hop-to-hop protection (encryption and authentication), with no user or application authentication.

    Security provided by Bluetooth, Zigbee or GPRS/UMTS, in each case, can be used for the Data Link Layer protection.

    2.1.2.5.2 Network Layer Security

    Security in the Network Layer provides node-to-node protection (encryption and authentication), with no user or application authentication.

    The node-to-node protection in the network layer can be hop-to-hop protection or end-to-end protection.

    For the Network Layer protection, IPsec can be used between systems using static IP.

    2.1.2.5.3 Transport Layer Security

    Security in the Transport Layer provides a end-to-end protection.

    Security in the Transport Layer provides application-to-application protection, and it can also include some user authentication.

    SSL/TLS or HTTPS can be used to provide Transport Layer security.

    2.1.2.5.4 Application Layer Security

    Security in the Application Layer provides application-to-application and application_user-to-application_user protection, including user authentication.

    Application Layer security is usually provided through the encryption or/and signature of the data sent through the communications stack.

    SMIME or user-invoked cryptographic functions (f.e. OpenSSL) could be used to encrypt and sign data for the Application Layer security.

    Source [8]

    2.2 UMTS

    UMTS (Universal Mobile Telecommunications System) is one of the major new 'third generation' (3G) mobile communications systems being developed within the framework defined by the ITU and known as IMT-2000.

    Allowing operators to offer mass-market mobile multimedia services, UMTS provides a route for the information technology and content industries to deliver new, innovative, non-voice based services.

  • MobiHealth_WP3_TME_D3.1_v1_01.01.03 19

    UMTS represents an evolution in terms of services and data speeds from today's "second generation" mobile networks. UMTS takes a fresh approach to optimal use of valuable radio spectrum, achieving greater spectrum efficiency and capacity compared to today’s 2nd generation systems.

    Thanks to UMTS, mobile users will have access to pictures, graphics, video communications and other wide-band information - as well as voice and data. UMTS will build on and extend the capability of today’s mobile technologies (like digital cellular and cordless) by providing increased capacity, data capability and a far greater range of services using an innovative radio access scheme and an enhanced, evolving core network. It will also make it possible to provide alternative billing methods (pay-per-bit, pay-per-session, flat rate, asymmetric bandwidth, and others).

    UMTS will enable tomorrow’s wireless Information Society, delivering high-value broadband information, commerce and entertainment services to mobile users via fixed, wireless and satellite networks. It will speed convergence between telecommunications, IT, media and content industries to deliver new services and create fresh revenue-generating opportunities. UMTS will offer low-cost, high-capacity mobile communication with global roaming and other advanced capabilities.

    2.2.1 UMTS ARCHITECTURE OVERVIEW

    UMTS architecture Release 99 is an evolution of GSM/GPRS system, with a new radio interface based on WCDMA technology, that allows to offer new services with high capacity.

    WCDMA (Wideband Code Division Multiple Access) is a technology for the implementation of third generation cellular systems. WCDMA, which is based on CDMA, allows different users to transmit simultaneously at different data rates and the data rates can even vary in time. WCDMA is a spread spectrum technology that uses unique digital codes to differentiate the users. Because of the wide bandwidth of a spread spectrum signal, it is very difficult to jam, difficult to interfere with, and difficult to identify. Thus UMTS gets higher capacity, better quality, enhanced privacy, better coverage characteristics, and bandwidth on demand.

    Despite UMTS radio access network is new, UMTS core network is similar to GSM/GPRS core network.

    UMTS core network is split into two different switching domains:

    • Circuit switching (CS): Based on GSM model.

    • Packet switching (PS): Based on GPRS model.

  • MobiHealth_WP3_TME_D3.1_v1_01.01.03 20

    UMTS basic architecture is split into:

    • User equipment (UE): Equipment used by the user to access UMTS services.

    • Infrastructure: Physical nodes that perform several functions required to terminate the radio interface and to support the telecommunications services requirements of the users.

    2.2.1.1 User equipment Domain

    The user equipment is sub-divided into:

    • Mobile Equipment Domain (ME): Performs radio transmission and contains applications. It consists of:

    - Mobile termination (MT): Radio transmission and related functions.

    - Terminal Equipment (TE): Contains end-to-end applications.

    • User Identity Module Domain (USIM): Contains data and procedures that unambiguously and securely identify itself.

    2.2.1.2 Infrastructure Domain

    The Infrastructure Domain is split into:

    • Access Network Domain: Consists of the physical entities that manage the resources of the access network and provides the user with a mechanism to access to Core Network Domain. In UMTS the access network is the UTRAN (Universal Terrestrial Radio Access Network).

  • MobiHealth_WP3_TME_D3.1_v1_01.01.03 21

    UTRAN consists of a set of Radio Network Subsystems (RNS) connected to Core Network.

    - A RNS consists of the Radio Network Controller (RNC) and one or more Node Bs. Each RNS is responsible for the resources of its set of cells.

    - RNC is responsible for the handover decisions that require signalling to the UE. It is equivalent to BSC in GSM network.

    - Node B is responsible for radio transmission/reception in one or more cells to/from UE. It is equivalent to BTS in GSM network.

    • Core Network Domain: Consists of the physical entities that provide support for the network features and telecommunications services. The support provided includes functionality such as:

    - Management of user location.

    - Control of network features and services.

    - Transfer (switching and transmission) mechanisms for signalling and user generated information.

    The Core Network Domain is sub-divided into:

    - Serving Network Domain: Represents functions that are local to the users access point and thus their location changes when the user moves. It is responsible for routing calls and for the transport of user data/information from source to destination.

    - Home Network Domain: Represents functions that are conducted at a permanent location regardless of the location of the user’s access point. It contains at least permanently user specific data and is responsible for management of subscription information.

    - Transit Network Domain: It is located on the communication path between the serving network domain and the remote party.

  • MobiHealth_WP3_TME_D3.1_v1_01.01.03 22

    2.2.2 UMTS SERVICES

    UMTS offers teleservices (like speech or SMS) and bearer services, which provide the capability for information transfer between access points. It is possible to negotiate and renegotiate the characteristics of a bearer service at session or connection establishment and during ongoing session or connection. Both connection oriented and connectionless services are offered for Point-to-Point and Point-to-Multipoint communication.

    UMTS network services have different QoS classes for four types of traffic:

    • Conversational class (voice, video telephony, video gaming).

    • Streaming class (multimedia, video on demand, webcast).

    • Interactive class (web browsing, network gaming, database access).

    • Background class (email, SMS, downloading).

    UMTS will also have a Virtual Home Environment (VHE). It is a concept for personal service environment portability across network boundaries and between terminals. Personal service environment means that users are consistently presented with the same personalised features, User Interface customisation and services in whatever network or terminal, wherever the user may be located. UMTS also has improved network security and location based services.

    The launching of UMTS services depends on the evolution of the 3G technology and the availability of UMTS devices. Some foreseen UMTS services are:

    • Telephony services: Standard telephony with higher quality, telephony over IP.

    • Video communication services: videoconference and videotelephony at different bit rates (64, 144, 384 kbps…).

    • Messaging services: SMSs, e-mail access, pull/push information services (news, travel, and traffic…), multimedia messaging,…

    • Internet access at different bit rates (64, 144, 384 kbps…) with voice browsers.

    • Data transmission at different bit rates (64, 144, 384 kbps…).

    • Corporate services: Access to corporate Intranets.

    • Location Based services.

    • Multimedia services: Audio and video downloads, audio and video in real time.

  • MobiHealth_WP3_TME_D3.1_v1_01.01.03 23

    • M-commerce services.

    • Entertainment personalised services.

    • Telemetry and telecontrol services.

    • International roaming.

    .

  • MobiHealth_WP3_TME_D3.1_v1_01.01.03 24

    3 GPRS AND UMTS SITUATION IN EACH TRIAL SITE

    3.1 SPAIN

    Telefónica MoviStar is the commercial brand for GSM and GPRS services of Telefónica Móviles España operator.

    In Spain, two trials will be held by the Corporatió Sanitaria Clinic (Barcelona):

    1. Support of home-based healthcare services, whose purpose is the expansion with additional mobile facilities of the current available portable professional unit by using the Nurse-Ban to perform patients measurements during the nurse visit.

    2. Outdoors patients rehabilitation, in which the improvement of the patient due to the physical activity will be evaluated. The patients will do an outdoors-training program under remote supervision.

    3.1.1 GPRS communication architecture

    3.1.1.1 Commercially available providers

    Nokia is the GPRS provider of TME.

    3.1.1.2 GPRS Roaming partnership

    TME has GPRS roaming service available in 18 countries with more than 30 mobile operators around the world. Between the countries involved in the trial sites, now there are only available agreements with operators in the Netherlands and Germany.

    Countries/Operators where MoviStar customers have ROAMING GPRS available

    COUNTRY OPERATOR WAP GPRS (*)

    INTERNET GPRS (*)

    INTRANET GPRS (*)

    Operator customers have GPRS with

    MoviStar

    Germany T-Mobile Deutschland available available available YES

    E-Plus available available available YES

    O2 Germany available available available YES

    The Netherlands

    KPN available available available YES

  • MobiHealth_WP3_TME_D3.1_v1_01.01.03 25

    (*) Wap, Internet and Intranet GPRS are MoviStar services that are available for TME GPRS customers.

    Source [4]

    3.1.1.3 Coverage maps

    TME offers national coverage for GPRS network, the same as GSM network.

    High Quality Coverage Variable Quality Coverage

    The trial will take place in Barcelona city and its surroundings.

    Source [2]

    3.1.2 UMTS STATE

    Telefónica Móviles has completed the initial roll out of 750 stations of the UMTS network in 21 Spanish cities within the planned deadline (1st June

  • MobiHealth_WP3_TME_D3.1_v1_01.01.03 26

    2002). This involves an extension to the commitment made by Telefónica Móviles when it was awarded a UMTS license to provide UMTS coverage in 16 cities with over 250000 inhabitants.

    This fact implies that Telefónica Móviles have radio coverage in these cities, but it doesn't support 3G commercial services at the moment. Until the commercial launching of UMTS, Telefónica Móviles will work in testing the current 2G services over the new network.

    The network infrastructure installed by Telefónica Móviles in this first phase represents the first step in the creation of the new mobile broadband network in Spain. This infrastructure is a test network which will allow to check the feasibility of the basic services over this new technology, identifying the improvements provided by the new network as for quality of service and transmission capacity.

    The services that probably will be available in a first commercial phase are:

    • Voice transmission

    • Packet-switching data transmission (64 kbps)

    • Circuit-switching data transmission (64 kbps)

    • Handover (only UMTS)

    The degree of technological maturity and the availability of UMTS devices will determine the commercial launching of UMTS services.

    Spanish operators, and so TME, have problems for the deployment of new antenna in urban zones. For this reason, the UMTS test bed for the trials will be limited to restricted points of coverage. Nowadays only circuit-switching data transmission infrastructure is available. TME is working on the availability of the packet-switching data transmission infrastructure.

    It is important to bear in mind that the MobiHealth applications have to be supported by packet-switching data networks.

    It could be possible to have a test bed in Madrid during the trials for a limited period of time. Interoperability issues make difficult to be ready in Barcelona area during the project.

    3.2 THE NETHERLANDS

    O2 is the selected GPRS operator for the trials. O2 provides coverage to the 98% of the population.

    In the Netherlands there will be two scenarios supported by the hospital Medisch Spectrum Twente in Enschede:

  • MobiHealth_WP3_TME_D3.1_v1_01.01.03 27

    1. Tele Trauma Team, which will evaluate if a Tele Trauma Team equipped with telemetry devices can decrease the lag-time between accident and intervention measures in the hospital.

    2. Integrated homecare in women with high-risk pregnancies, which will evaluate if monitoring at a distance of maternal and foetal vital signs is feasible, safe and can postpone hospitalisation.

    3.2.1 GPRS communication architecture

    3.2.1.1 Commercially available providers

    Ericsson is the GPRS provider of O2.

    Source [5]

    3.2.1.2 GPRS Roaming partnership

    O2 offers GPRS roaming service in Germany.

    Source [2]

    3.2.1.3 Coverage maps

    In the Netherlands, the trial will be in Enschede.

    High Quality Coverage Variable Quality Coverage

  • MobiHealth_WP3_TME_D3.1_v1_01.01.03 28

    Source [2]

    3.2.2 UMTS STATE

    The University of Twente is in a negotiation process with one of the leading

    mobile network operators in the Netherlands to use an experimental UMTS

    infrastructure for the MobiHealth trials in the region of the MST hospital and

    the University of Twente. Negotiations are focussed on availability (coverage

    area) and use (duration) of the UMTS infrastructure. Specific details about

    bandwidth, delay and delay variation (i.e. jitter) are not know before the

    experimental infrastructure will be accessible. The negotiations will be

    concluded with the signing of a contract at the end of January 2003.

    Note: The University of Twente is not allowed to disclose the name of the

    mobile network operator and or specific negotiation details without approval of

    this operator. The University of Twente specifically asked the operator about

    the information that can be disclosed and receives most probably an answer

    before February 2003.

    3.3 GERMANY

    D2-Vodafone is the selected GPRS operator for the trials in Germany. It provides coverage to the 98% of the population.

    In Germany there will be one scenario supported by GesunheitScout24, named Secondary Prevention in Coronary Heart Disease. This scenario will

  • MobiHealth_WP3_TME_D3.1_v1_01.01.03 29

    evaluate if patients equipped with a telemetry device can prevent recurrent myocardial infarction, instable angina pectoris, malign arrhythmias or hospitalisation.

    3.3.1 GPRS communication architecture

    3.3.1.1 Commercially available provider

    Siemens is the provider of D2-Vodafone in Germany.

    Source [5]

    3.3.1.2 GPRS Roaming partnership

    D2-Vodafone has GPRS roaming agreement with Vodafone in the Netherlands.

    Source: [4]

    3.3.1.3 Coverage maps

    The trials in Germany will be in Duisburg.

    D2 - Vodafone

    High Quality Coverage Variable Quality Coverage

  • MobiHealth_WP3_TME_D3.1_v1_01.01.03 30

    Source [2]

    3.3.2 UMTS STATE

    There will not be a UMTS test in Germany in a first step. At a later stage, it is possible that there will be any contact with a German mobile operator for the UMTS trials.

    3.4 SWEDEN

    Telia Mobile is the operator for the trials in Sweden.

    In Sweden there will be four scenarios:

    1. The Lighthouse Alarm and locator trial, supported by the Ligthhouse, will test the effectiveness of a new GPRS/UMTS based alarm and locating device according to several determining factors: safety, convenience, empowerment of user, mobility of user and improvement in efficiency of care given.

    2. Physical activity and impediments for activity in women with RA, supported by the Sunderby hospital, will follow the patients' activity level by means of monitoring of heart rate, walking distance, stride length and number of steps, and self-reporting of the activity level, to determine the factors that impede the patients from performing those activities as they wish.

    3. Monitoring of vital parameters in patients with respiratory insufficiency, supported by the Obstructive Lung Disease in Northern Sweden Studies (OLIN), will examine if mobile health facilities with monitoring of some relevant vital signs can contribute to an earlier detection and

  • MobiHealth_WP3_TME_D3.1_v1_01.01.03 31

    treatment of COPD and also reduce the need for checks-ups and hospitalisation.

    4. Home care and remote consultation for recently released patients in a rural area, supported by Sandens Vårdcentral (local health centre), will study if transmission of vital signs from a person at home to a Registered Nurse and/or a physician for consultation and diagnosis can reduce hospital visits and give trusted and safe care at home.

    3.4.1 GPRS communication architecture

    3.4.1.1 Commercially available providers

    Ericsson / Nokia.

    3.4.1.2 GPRS Roaming partnership

    Telia has GPRS roaming agreements with 18 mobile operators in 16 countries around the world. The interesting roaming partnerships for the project are:

    COUNTRY OPERATOR

    Germany T-Mobile

    Spain Amena

    3.4.1.3 Coverage maps

    The trial in Sweeden will be held in Lulea.

    Telia

    High Quality Coverage Variable Quality Coverage

  • MobiHealth_WP3_TME_D3.1_v1_01.01.03 32

    Source [2]

    3.4.2 UMTS STATE

    Telia and Tele2 have 50-50 partnership in Svenska UMTS-Nät AB, the company responsible for the third generation UMTS network in Sweden. Telia and Tele2 have rolled out base stations in most Swedish cities according to the commitment to PTS (Post och Telestyrelsen) in Sweden.

    Telia don’t support 3G commercial services at the moment, but will start testing UMTS services in April 2003. Telia will intend to incorporate MobiHealth trials in the overall service tests. This means also that the MobiHealth UMTS trials might be moved from Luleå area to some other test site.

    Mail focus for the overall service trials will be on:

    • Voice transmission

    • Packet-switching data transmission (64 and 384 kbps)

    • Circuit-switching data transmission (64 and 384 kbps)

  • MobiHealth_WP3_TME_D3.1_v1_01.01.03 33

    4 TECHNICAL REQUIREMENTS AND LIMITATIONS IN EACH TRIAL SCENARIO

    The hospital and the BAN have to be in contact in order to transmit the health information between them. An infrastructure for bi-directional multimedia data communication between the BAN and the client application in the hospital has to be defined.

    Some important issues for the definition of this infrastructure are:

    • Bandwidth

    • Coverage and availability

    • Reliability

    • Traffic management

    • Security

    • Mobility

    4.1 BANDWIDTH

    Two technologies are considered to be used to support wireless communication for each of the MobiHealth trials: GPRS (2.5G) and UMTS (3G).

    The maximum bit rate that the GPRS networks offered to data transmission depends mainly on the number of available timeslots and the coding scheme used for the communication. So four different link capabilities will be available for the trials, depending on:

    • Coding schemes (CS1 or CS2 - available today).

    • Number of time slots (one or two) for data transmission from a GPRS terminal to the network (uplink).

    Note: The GPRS terminal is actually the MobiHealth BAN MBU.

    The optimum GPRS uplink bandwidth is reached by using data coding scheme CS2, and 2 timeslots for data transmission.

    For UMTS we assume a gross link bandwidth of 64 kbps.

    The BAN Applications and the type of sensors determine the amount of data generated by the BAN system.

    Two different parameters can be calculated related to the performance: the bandwidth needed to support real-time transmission of BAN Data and the time needed to transmit bulk data, i.e. all BAN data will be collected during a

  • MobiHealth_WP3_TME_D3.1_v1_01.01.03 34

    measurement interval (duration of the measurement session) and transmitted as a large data set through the operator network to the back-end system. This transmission time strictly depends on the technology used (GPRS/UMTS and type of coding schemes).

    To calculate the amount of generated data, according to the measurement results presented in [7], we use a maximum data overhead/loss rate of 10% for both GPRS and UMTS networks.

    Network Tg (kbps) overhead / loss (%) Tn (kbps)

    2.5G_cs1.ts1 9,05 10 8,15

    2.5G_cs1.ts2 18,10 10 16,29

    2.5G_cs2.ts1 13,40 10 12,06

    2.5G_cs2.ts2 26,80 10 24,12

    3G 64,00 10 57,60

    For GPRS, "t_max" parameter represents the transmission time for the worse case (data coding scheme CS1 and 1 time slot for data transmission) and "t_min" parameter represents the best case (data coding scheme CS2 and 2 time slots for data transmission). For each trial the minimum (t_min) and maximum (t_max) transmission time for bulk data (gross aggregate data volume Dg) transfer is calculated based on the wireless technology available on the trial location. Additionally, the link bandwidth is calculated to support real-time transmission of BAN data; every BAN sample will be transmitted to the MobiHealth back-end system (includes the BAN data repository).A compression factor, which is specific to the TMSI sensor system, is applied over the data in order to reduce the required bandwidth.

    The determination of bandwidth requirements is based on the trial descriptions of the deliverable D1.3 (Source [6]) and the characteristics of the TMSI sensor system.

    Note: The explanations of the calculations of bandwidths and transmission times are included in the annex I to this document.

    4.1.1 Spain

    In the first scenario, Support of home-based healthcare services, the sensors that will be used are:

    • Pulse oximetry (SPO2)

    • ECG-3 leads (heart rate derived)

    • Temperature

  • MobiHealth_WP3_TME_D3.1_v1_01.01.03 35

    • Glucose

    • Spirometer

    • NIBP

    The required bandwidth to support real-time transmission is 14.62 Kbps, which can be supported by GPRS.

    The gross aggregate data volume Dg generated by the BAN in each measurement session is 1431 Kbytes, which imply a maximum transmission time of 1405 seconds and a minimum transmission time of 474 seconds (using GPRS network).

    In the second scenario, Outdoors Patient's rehabilitation, the sensors that will be used are:

    • Pulse oximetry (SPO2)

    • ECG-3 leads (ECG, heart rate)

    • Mobility

    The required bandwidth to support real-time transmission is 14.80 Kbps, which can be supported by GPRS.

    The gross aggregate data volume Dg generated by the BAN in each measurement session is 21978 Kbytes, which imply a maximum transmission time of 21587 seconds and a minimum transmission time of 7290 seconds (using GPRS network).

    4.1.2 The Netherlands

    The first scenario, Tele Trauma Team, is divided into two sub trials: trauma paramedic and trauma patient.

    For the Tele Trauma Team - trauma paramedic, video signals with the information of the location and the state of the patients will be transmitted.

    The required bandwidth to support real-time transmission, with a maximum transmission time of 300 seconds, is 3.07 Kbps, which can be supported by GPRS.

    The gross aggregate data volume Dg generated by the BAN in each measurement session is 380 Kbytes, which imply a maximum transmission time of 373 seconds and a minimum transmission time of 126 seconds (using GPRS network).

    For the Tele Trauma Team - patient paramedic, the sensors that will be used are:

    • Respiration

  • MobiHealth_WP3_TME_D3.1_v1_01.01.03 36

    • ECG

    • Pulse oximetry (SPO2)

    • NIBP

    The required bandwidth to support real-time transmission is 15.55 Kbps, which can be supported by GPRS.

    The gross aggregate data volume Dg generated by the BAN in each measurement session is 7697 Kbytes, which imply a maximum transmission time of 7560 seconds and a minimum transmission time of 2553 seconds (using GPRS network).

    In the second scenario, Integrated homecare in women with high-risk pregnancies, the sensors that will be used are:

    • ExG

    • Marker

    • Respiration

    • NIBP

    The required bandwidth to support real-time transmission is 3.76 Kbps, which can be supported by GPRS.

    The gross aggregate data volume Dg generated by the BAN in each measurement session is 14702 Kbytes, which imply a maximum transmission time of 14440 seconds and a minimum transmission time of 4876 seconds (using GPRS network).

    4.1.3 Germany

    In the trial scenario Secondary Prevention in Coronary Heart Disease the sensors that will be used are:

    • ECG

    • Marker

    • NIBP

    The required bandwidth to support real-time transmission is 14.49 Kbps, which can be supported by GPRS.

    The gross aggregate data volume Dg generated by the BAN in each measurement session is 1782 Kbytes, which imply a maximum transmission time of 1750 seconds and a minimum transmission time of 591 seconds (using GPRS network).

  • MobiHealth_WP3_TME_D3.1_v1_01.01.03 37

    4.1.4 Sweden

    In the first scenario, the Lighthouse and locator trial, the sensors that will be used are:

    • ECG

    • Button

    • Mobility (drop)

    Also video signals with the information of the location of the patients will be transmitted.

    The required bandwidth to support real-time transmission of the sensor data is 2.73 Kbps, which can be supported by GPRS. Pictures are sent sequentially but if we consider the maximum generated volume data, the required bandwidth for real-time transmission is 15.36 Kbps.

    The gross aggregate data volume Dg generated by the BAN in each measurement session is 795 Kbytes, which imply a maximum transmission time of 781 seconds and a minimum transmission time of 264 seconds (using GPRS network).

    In the second trial, Physical activity and impediments for activity in women with RA, the sensors that will be used are:

    • ECG

    • Mobility

    The required bandwidth to support real-time transmission is 5.70 Kbps, which can be supported by GPRS

    The gross aggregate data volume Dg generated by the BAN in each measurement session is 33858 Kbytes, which imply a maximum transmission time of 33255 seconds and a minimum transmission time of 11230 seconds (using GPRS network).

    The third scenario, Monitoring of vital parameters in patients with respiratory insufficiency, the sensors that will be used are:

    • Pulse oximetry (SPO2)

    • Mobility

    The required bandwidth to support real-time transmission is 3.25 Kbps, which can be supported by GPRS.

    The gross aggregate data volume Dg generated by the BAN in each measurement session is 38610 Kbytes, which imply a maximum transmission

  • MobiHealth_WP3_TME_D3.1_v1_01.01.03 38

    time of 37923 seconds and a minimum transmission time of 12806 seconds (using GPRS network).

    The forth scenario, Home care and remote consultation for recently released patients in a rural area, the sensors that will be used are:

    • ECG

    • Pulse oximetry (SPO2)

    • Respiration

    • NIBP

    • Glucose

    The required bandwidth to support real-time transmission is 32.79 Kbps, which cannot be supported by GPRS and UMTS would have to be used. Because of the uncertainty of the UMTS availability during the MobiHealth project, GPRS could be used for transmitting bulk data, i.e. all BAN data will be collected during the measurement interval and transmitted as a large data set to the operator network.

    The gross aggregate data volume Dg generated by the BAN in each measurement session is 313 Kbytes, which imply a maximum transmission time of 308 seconds and a minimum transmission time of 104 seconds (using GPRS network).

    4.2 COVERAGE AND AVAILABILITY

    The trials sites are Barcelona city in Spain, Lulea region in Sweden, Enschede centre in the Netherlands and Duisburg region in Germany.

    GPRS coverage is guaranteed in all the trials sites but not the UMTS coverage because the current situation of the 3G networks in Europe makes that the operators nowadays can offer only coverage and complete service in some points of their countries before the commercial launching of the service.

    Telia and TME are not able to guarantee the availability of UMTS services in the trial sites during the project. For example in Spain, UMTS test beds are in Madrid.

    4.3 RELIABILITY

    In order to measure the reliability of GPRS networks in the project, several tests have been achieved over O2, TME and Telia GPRS networks.

    The performance of TCP/UDP transport layer protocols has been tested over the GPRS networks of O2 in the Netherlands and TME in Spain in order to

  • MobiHealth_WP3_TME_D3.1_v1_01.01.03 39

    evaluate what is the most suitable protocol for BAN Data transmission in the MobiHealth project.

    The throughput and latency have been measured over the Telia GPRS network in order to evaluate if the GPRS networks are suitable for the IP-enabled services required in the MobiHealth project.

    4.3.1 Test of TCP/UDP performance over O2 and TME GPRS networks

    Several issues important for the performance of TCP/UDP over GPRS have to be considered:

    • Network Bandwidth: Available network bandwidth determines the data transmission speed over the GPRS network. For nowadays GPRS networks two coding schemes are available: CS1 and CS2, each corresponding to speed rates (per one time slot) of 9.05 kbps and 13.4 kbps respectively.

    • Unreliable data transmission: In contrast to TCP, UDP is an unreliable transport protocol, which means that data might be lost during the (end-to-end) transmission. The amount of data lost when using UDP as the transport layer protocol is an important factor when considering the usage of UDP.

    • Round trip delay sensitivity: Due to the fact, that TCP and UDP transport protocols handle application layer messages in a different manner, we expect different delays in data transmission. TCP provides a connection-oriented service to the application layer while UDP provides connectionless service. Transmission delays caused by lower communication layers may have a drastic effect the performance of the TCP or UDP protocol.

    The GPRS link of the wireless part of the network is a reliable datalink. For now the usage of UDP as the transport layer protocol can hardly take advantage over the usage TCP as the transport protocol. TCP behaves better if there is not limitation on the packet rate of the traffic that might be caused because of the existence of a buffer in the used modem.

    Under the condition that there is a control on the packet rate of the traffic, UDP can gain better performance than TCP; the data lost rate is low. UDP consumes less time to transfer the same amount of data than that when using TCP.

    The data loss over the E2E communication link was experienced with usage of UDP. In GPRS network there is reliable data link layer provided and additionally there are no problems with the bandwidth reservation in the Operator’s Core network. So the data loss is mainly experienced on the Internet and Enterprise network.

    Summarizing experiments results, based on the measurements’ results, the TCP protocol is suitable for transporting BAN control data (e.g. configuration

  • MobiHealth_WP3_TME_D3.1_v1_01.01.03 40

    data, actuator control, etc) from the End-Host to BAN. The BAN data (e.g. patient data, medical data) can be transported using the UDP protocol, but only under the condition (derived from the MobiHealth system user requirements) that during data transmission some data may be lost.

    According to the experiments, GPRS networks have different behaviours, related to the available time slots, the used coding scheme and the stability of the bandwidth.

    Summarizing the experiment results, we can say that the performance of nowadays' GPRS networks might be sufficient to meet the data rates needed in 90 % of the MobiHealth trials (see section 4.1).

    Source [7]

    4.3.2 Tests of throughput, latency and jitter over Telia GPRS network

    For the tests, a PDA connected to the EIS (Embedded Internet System) sensor platform from EISLAB via Bluetooth was used and at the same time connected to the Telia Mobile GPRS network. Another PDA connected to a wireless access point (WLAN AP) was used for reference evaluations.

    4.3.2.1 Tests of throughput

    The expansion jacket device for the PDA used to connect to the GPRS network is a multi-slot Class 10 device. For data connectivity, it has 4 slots downlink and 2 slots uplink available. At the time of the measurements, the maximum throughput offered for the uplink channel were 26.8 kbps with 2 timeslots and CS-2.

    In the tests, it was measured the throughput performance when sending data from the PDA compared to the performance when sending data from the EIS platform. The results would give the performance degradation when retrieving data from the EIS platform. On the average, the throughput when sending data from the EIS platform is 90% of the PDA. From the measurements, it is noticed that the average segment size when sending from the PDA is 1123 bytes whereas for the EIS platform 656 bytes, thus giving a lower throughput since more packets needs to be sent. In essence, the lower throughput rate comes from the trade-off of utilizing the limited memory available on the EIS platform. Currently, the implementation has a limited number of outstanding TCP segments needed to be acknowledged before able to send more data, thus holding back the utilization of the network pipe.

    4.3.2.2 Tests of latency

    For the purpose of some medical applications required in the MobiHealth project, like the pulse oximetry application, the available throughput is of less importance since the application is latency bound.

    For the WLAN case, the two-way-latency or round trip time (RTT) can be considered stable and the average RTT is about 150 ms. When observing the

  • MobiHealth_WP3_TME_D3.1_v1_01.01.03 41

    GPRS RTT, we found the average RTT to be as high as 2000 ms, something that can be perceived as stressful when interacting with the system.

    4.3.2.3 Tests for tuning the applications

    Having the above variation in network latency, or jitter, some measurements were performed to see how the application must be tuned to cope with the GPRS network characteristics. The inter-arrival time for two consecutive packets, approximately 1 second, can be considered to be fairly stable for the WLAN case. For the GPRS case, the inter-arrival time constantly diverges and is being scattered.

    For sensor data sent over the wireless LAN, almost 90% of the packets arrive between 0.9 and 1.1 seconds relative to the previous packet. For the GPRS case, only 25% of the packets arrive in a timely manner.

    As conclusion, the experimental results show the importance of network aware applications that can adapt to properties such as network latency and jitter by deploying appropriate buffering schemes. However, certain real time aspects such as response time will directly suffer due to network latency.

    Source [9]

    4.4 TRAFFIC MANAGEMENT

    If the network is configured to have data dedicated channels, data transmission will have priority over voice transmission in these channels.

    The networks usually have 2 dedicated PDCH's (Packet Data Channels, which are the physical channels dedicated to packet data traffic) in urban area. In other cases, depending on the data traffic congestion and if the voice traffic allows, TCH (generic Traffic Channel) channels could be configured automatically to PDCH´s.

    The operators involved in the trials can´t guarantee in all cases the priority of the data over the voice so the data traffic can be affected by the voice congestion situation.

    4.5 SECURITY

    In health applications, security aspects are very important to be considered. The confidentiality about the patient information must be guaranteed so security issues in the BAN, relay and hospital end have to be bear in mind.

    In the GPRS and UMTS networks, two security services are required for the data (patients data):

    • Data Confidentiality: to protect the transmitted patients data from unwanted access.

  • MobiHealth_WP3_TME_D3.1_v1_01.01.03 42

    • Authentication: User and server authentication to ensure the identity of the patients sending the data and to ensure the identity of the server that is receiving the data sent by the user.

    In the path from the MS to the Server (the MobiHealth Back-End System (BES)), two different links must be taken into account:

    • Radio Access network: from the ME to the GPRS/UMTS service provider

    • Internet: From the GPRS/UMTS service provider to the Server.

    In MobiHealth, two different security protocols will be used in the path from the MS to the server:

    • All data from the MS to the Server will be sent through a Transport Layer SSL connection, with data encryption and X.509 certificates-based client (ME users) and Server authentication.

    • Additionally, the Radio Access Network also provides data link layer level security, with Terminal (ME) authentication and data encryption, that provides additional security to the data that is sent through the radio link.

    4.5.1 Tests of security

    Several tests of the performance of security packages for the MBU have been achieved over the TME GPRS network.

    For the tests, two scenarios were performed: GPRS scenario, which is the MobiHealth real environment and Fast Ethernet scenario, which is used for reference measurements.

    The tests were performed generating traffic streams at specified rates, with particular burst characteristic and with different sockets implementations: Java Sockets, Java Native Interface (JNI) with OpenSSL, Java Secure Socket Level (JSSE).

    The results of the GPRS and Fast Ethernet tests are summarized as follows:

    • The Uplink is considered a more important channel than the downlink, since the information must go from the MBU to the WSB transferring the sensor information.

    • Different number of packets is required to send the same amount of data bytes, due to packet loss and retransmission.

    • Packet loss over GPRS link is not rare, because number of packets sent in the GPRS tests is clearly bigger than the Fast Ethernet ones.

    • Block size (BS) in both scenarios doesn’t influence much in the throughput. It is recommended to use a block size of 1024 bytes for average analysis of the information.

  • MobiHealth_WP3_TME_D3.1_v1_01.01.03 43

    • The number of bytes sent in unsecure connection, JNI+OpenSSL and JSSE is different, because of security negotiation and transferred encrypted information. This influences directly in the time required to send the full data file.

    • In comparison with unsecured connection, JNI+OpenSSL sends 6% more data bytes, and JSSE 3 % more.

    • The throughput available over GPRS is “highly” variable and can fluctuate rapidly, depending upon the radio conditions.

    • Throughput should not be affected by the usage of security, from the communications point of view, since it should only depend on the network capacity.

    • A difference between the throughput in JNI+OpenSSL and JSSE can be clearly noticed in the Fast Ethernet trial, where throughput of JSSE is only 35% of the throughput of JNI+OpenSSL. The reason for this clear difference is probably that JSSE requires more computational resources than JNI+OpenSSL, and the PDA is not able to encrypt in “real time” at the same time it sends the encrypted information.

    • Although more bytes are sent in the secure connection with JNI + OpenSSL than the JSSE, JNI+OpenSSL has a better GPRS throughput than JSSE, and the elapsed time required to send the information is smaller.

    • The maximum throughput for the Fast Ethernet uplink, where the limit for the PDAs is mainly restricted by its processing power, was 9192480 B/s, for the JNI + OpenSSL 2061971 B/s, and for the JSSE implementation only 660332 B/s. This demonstrates that the JSSE implementation requires much more computer power than the JNI + OpenSSL implementation.

    Considering the main parameter of comparison is the throughput, the recommended secure implementation on GPRS scenario is:

    • JNI + OpenSSL.

    • 1024 byte packet size

    Source [10]

    4.6 MOBILITY

    Roaming functionality allows the users to establish GPRS connections from a foreign country. The visited network VPLMN (Visited Public Land Mobile Network) is selected according to the roaming agreement.

  • MobiHealth_WP3_TME_D3.1_v1_01.01.03 44

    Visitor user can use radio resources of the visited network, but the home network assigns the IP address.

    If the user roams to another network during a GPRS connection, the link goes down. So operators can't offer a service without disruptions because of the mechanism of detach from the home network and the mechanism of attach to the visitor network.

    Moreover, in the same network, the handovers don't produce any disconnection.

    Regarding to UMTS, network operators in general won’t support the roaming functionality roaming in their first phase. Only UMTS handover could be supported.

  • MobiHealth_WP3_TME_D3.1_v1_01.01.03 45

    5 CONCLUSIONS

    Each trial scenario has been analysed in detail in order to know if real-time transmission can be supported by GPRS networks or cannot. The most of the trial scenarios can be achieved with GPRS and real time transmission but in the cases where the constraints of bandwidth are high, the data will be sent as quick as the GPRS link will support.

    Only generic security aspects related to WP3 have been analysed in this deliverable. Deliverable 2.5 “Security services in the MobiHealth BAN” will include the specific security aspects for the BAN and Deliverable 3.2 “MobiHealth System” will include specific security aspects related to the whole system.

    Due to the European situation related to UMTS where there is not a defined deadline of the availability of UMTS terminals, the UMTS trials of the project will be affected. There will be test beds in the Netherlands, Sweden and Spain for short trial periods if UMTS terminals are available for the project.

    The objective of MobiHealth project is the introduction of new mobile health services based on the on-line continuous monitoring of vital signals based on GPRS and UMTS technologies.

    In conclusion, with the possibilities offered by GPRS technology nowadays, we can affirm that the most of the proposed trial scenarios can be supported by GPRS waiting for the real availability of UMTS technology. GPRS is ready to support the MobiHealth applications. The current situation of UMTS is not suitable for a complete evaluation of medical applications because only test beds, short periods of trials and prototype terminals can be achieved.

  • MobiHealth_WP3_TME_D3.1_v1_01.01.03 46

    6 REFERENCES

    WEB SITES

    [1] “Wireless Revolution Insider” October’2002

    http://www.gsmworld.com/technology/voiceless_gsm/wei_oct02.pdf

    [2] GSM World webpage

    http://www.gsmworld.com/roaming/gsminfo/cou_de.shtml

    [3] Datafile of European Telecommunications, CIT Publications Ltd, state on May 2000

    http://banners.noticiasdot.com/termometro/boletines/autor/docs/citpubs/2000/CIT_alemania_moviles_2000.pdf

    [4] Operators websites:

    Vodafone website – The Netherlands www.vodafone.nl

    D2-Vodafone Germany website: http://www.vodafone.de

    MoviStar,Telefonica Móviles website:

    http://www.movistar.com

    http://www.cobertura.movistar.com/Tmoviles/cobertura_moviles/index.asp

    Telia website: www.teliamobile.se

    [5] Mobile GPRS website: http://www.mobilegprs.com

    MOBIHEALTH DELIVERABLES

    [6] Albert Alonso, Bárbara Vallespin (CSC), Val Jones (UT), Deliverable D1.3: "Detailed description of trial scenarios", October 2002.

    MOBIHEALTH REPORTS

    [7] Yu Chen, R. Bults, K. Wac, "Performance analysis of TCP and UDP transport protocols over GPRS network", January 2003.

    [8] Ramón Martí, Jaime Delgado, Xavier Perramón, Juan Carlos Sánchez (UPF), “MobiHealth Security Requirements and Proposal-Version 1.2”, November 2002.

    [9] Ake Östmark, Linus Svensson, Per Lindgren, Jerker Delsing (Lulea University of Technology), “GPRS Mobile Wireless WWW Servers Feasible Through EIS Architecture”, February 2003.

    [10] Juan Carlos Sánchez, Ramon Martí (UPF), “MBU Security Performance Tests – Version 1.2”, February 2003.

  • MobiHealth_WP3_TME_D3.1_v1_01.01.03 47

    7 GLOSSARY

    ACRONYM DEFINITION

    APN Access Point Name

    BSC Base Station Controller

    BTS Base Transceiver Station

    CS Circuit-Switched

    DNS Domain Name System

    EIS Embedded Internet System

    GSM Global System for Mobile telecommunications

    GSN GPRS Support Node

    GPRS General Packet Radio Services

    HLR Home Location Register

    IH Internet Host

    IMSI International Mobile Subscriber Identity

    IP Internet Protocol

    ME Mobile Equipment

    MS Mobile Station

    MSC Mobile services Switching Centre

    MT Mobile Terminal (GPRS) / Mobile Termination (UMTS)

    PDP Packet Data Protocol

    PS Packet-Switched

    QoS Quality of Service

    RA Routing Area

    RADIUS Remote Access Dial-In User Service

    RNC Radio Network Controller

    RNS Radio Network Subsystem

    RTT Round Trip Time

  • MobiHealth_WP3_TME_D3.1_v1_01.01.03 48

    SIM Subscriber Identity Module

    TE Terminal Equipment

    UE User Equipment

    UMTS Universal Mobile Telecommunications System

    USIM User Identity Module

    UTRAN Universal Terrestrial Radio Access Network

    VHE Virtual Home Environment

    VLR Visitor Location Register

    WCDMA Wideband Code Division Multiple Access

  • MobiHealth_WP3_TME_D3.1_v1_01.01.03 49

    ANNEX I

    CALCULATIONS OF THE REQUIRED BANDWIDTH AND TRANSMISSION TIMES IN EACH TRIAL SCENARIO

    Explanation of formulae and parameters

    formulae

    S = cf * sf * (x * Ch + y * Cl) 0 < cf

  • MobiHealth_WP3_TME_D3.1_v1_01.01.03 50

    Bandwidth requirements for MobiHealth trials

    MobiHealth trial bandwidth requirementsfor realtime data transmission

    14,49

    32,79

    0,28

    14,62 14,80

    3,765,70

    3,25 3,07

    15,55

    0

    16

    32

    48

    64

    cardio discharge light nurse outdoors preg ra resp trauma paramedic trauma patient

    trial code Tr 2.5G_cs1.ts1 2.5G_cs2.ts2 3G

    (kbps) t_max (s) t_min (s) t_3g (s)

    cardio 14,49 1.750 591

    discharge 32,79 308 104 43

    light 0,28 61 21 9

    nurse 14,62 1.405 474

    outdoors 14,80 21.587 7.290

    preg 3,76 14.440 4.876 2.042

    ra 5,70 33.255 11.230 4.703

    resp 3,25 37.923 12.806 5.363

    trauma paramedic 3,07 373 126 53

    trauma patient 15,55 4.935 1.666 698

    Note:

    Network Tg (kbps) overhead / loss (%) Tn (kbps)

    2.5G_cs1.ts1 9,05 10 8,15

    2.5G_cs1.ts2 18,10 10 16,29

    2.5G_cs2.ts1 13,40 10 12,06

    2.5G_cs2.ts2 26,80 10 24,12

    3G 64,00 10 57,60

    Realtime transmission of data is not needed for the trauma paramedic, the maximum transmission time is used instead.

  • MobiHealth_WP3_TME_D3.1_v1_01.01.03 51

    1. Support of home-based healthcare services

    Trial code: nurse

    Trial Partner: Corporació Sanitària Clínic, Barcelona, Spain

    Sensor types: Pulse oxymetry (SPO2), ECG, Temperature, Glucose, Spirometer, NIBP

    Table 1. Bandwidth calculations for the nurse trial

    min. 60

    hr. 3.600

    day (continuous) 86.400

    sensor type Ch Cl cf sf S Mi Data

    SPO2 3 1,00 32 96 900 86.400

    ECG 3 0,30 512 1.382 900 1.244.160

    temperature 1 1,00 1 3 1 3

    glucose 1 1,00 1 3 1 3

    spirometer 1 1,00 128 384 3 1.152

    NIBP 1 1,00 1 3 1 3

    Dn (byte) 1.331.721

    Do (%) 10

    Dg (byte) 1.464.893

    Dg (Kbyte) 1.431

    network: 2.5G (GPRS)

    t_max: 1.405 min Tl (kbps) 8,15

    t_min: 474 max Th (kbps) 24,12

    realtime: 1 T (kbps) 14,62

    no. BANs 3

    Notes: support for videoconferencing is not feasible

    support for tele-conferencing (audio) provided by 2G

    spiro, Blood pressure is measured by nurse, and stored via MBU user interface.

    measurement interval (s)

  • MobiHealth_WP3_TME_D3.1_v1_01.01.03 52

    2. Outdoors Patient’s rehabilitation

    Trial code: outdoor

    Trial Partner: Corporació Sanitària Clínic, Barcelona, Spain

    Sensor types: Pulse oxymetry (SPO2), ECG, mobility

    Table 2. Bandwidth calculations for the outdoor trial

    min. 60

    hr. 3.600

    day (continuous) 86.400

    sensor type Ch Cl cf sf S Mi Data

    SPO2 3 1,00 128 384 10.800 4.147.200

    ECG 3 0,30 512 1.382 10.800 14.929.920

    mobility 1 1,00 128 128 10.800 1.382.400

    Dn (byte) 20.459.520

    Do (%) 10

    Dg (byte) 22.505.472

    Dg (Kbyte) 21.978

    network: 2.5G (GPRS)

    t_max: 21.587 min Tl (kbps) 8,15

    t_min: 7.290 max Th (kbps) 24,12

    realtime: 1 T (kbps) 14,80

    no. BANs 10

    Notes: support for verbal communication is provided by 2G

    measurement interval (s)

  • MobiHealth_WP3_TME_D3.1_v1_01.01.03 53

    3. Tele Trauma Team

    Trial sub code: trauma paramedic

    Trial Partner: Medisch Spectrum Twente, Enschede, the Netherlands

    Table 3. Bandwidth calculations for the tele trauma team (trauma paramedic) trial

    sensor type picture compres. number S Data

    spec. factor

    picture cam. 1a y 3 39.322 117.965

    1b y 2 117.965 235.930

    Dn (byte) 353.894

    Do (%) 10

    Dg (byte) 389.284

    Dg (Kbyte) 380

    network: 2.5G (GPRS)

    t_max: 373 min Tl (kbps) 8,15

    t_min: 126 max Th (kbps) 24,12

    network: 3G (UMTS)

    t_3g 53 T (kbps) 57,60

    max. transmission time (s): 300 T (kbps) 6,14

    no. BANs 2

    Notes: pictures are send sequentially and only max data volume is used for calculation

    support for tele-conferencing (audio) provided by 2G

    support for transmission of video clips is feasible

    patient

    picture type

    location

  • MobiHealth_WP3_TME_D3.1_v1_01.01.03 54

    Trial sub code: trauma patient

    Sensor types: Respiration, ECG, pulse oxymetry (SPO2), NIBP

    Table 4. Bandwidth calculations for tele trauma team (trauma patient) trial

    min. 60

    hr. 3.600

    day (continuous) 86.400

    sensor type Ch Cl cf sf S Mi Data

    respiration 1 1,00 64 192 3.600 691.200

    ECG 3 0,30 512 1.382 3.600 4.976.640

    SPO2 3 1,00 128 384 3.600 1.382.400

    NIBP 1 1,00 32 32 3.600 115.200

    Dn (byte) 7.165.440

    Do (%) 10

    Dg (byte) 7.881.984

    Dg (Kbyte) 7.697

    network: 2.5G (GPRS)

    t_max: 7.560 min Tl (kbps) 8,15

    t_min: 2.553 max Th (kbps) 24,12

    network: 3G (UMTS)

    t_3g 1.069 T (kbps) 57,60

    realtime: 1 T (kbps) 15,55

    no. BANs 2

    measurement interval (s)

  • MobiHealth_WP3_TME_D3.1_v1_01.01.03 55

    Pictures formats

    mega pix. colors (bits) size in compres. size in

    hor. ver. hor. (cm) ver. (cm) (2 x̂) mbits factor mbits hor. (cm) ver. (cm)

    1a 768 512 0.4 6.50 4.33 8 3.0 10 0.3 15 10

    1b 24 9.0 10 0.9

    2a 1024 768 0.8 8.67 6.50 8 6.0 10 0.6 18 13

    2b 24 18.0 10 1.8

    3a 1536 1024 1.6 13.0