Ecc08 malta
Upcoming SlideShare
Loading in...5
×
 

Ecc08 malta

on

  • 999 views

This paper presents a prototype of a medical Bluetooth Body Area Network (BAN). The central node in the BAN was developed using Smartphones (mobile phones offering advanced capabilities) and Java 2 ...

This paper presents a prototype of a medical Bluetooth Body Area Network (BAN). The central node in the BAN was developed using Smartphones (mobile phones offering advanced capabilities) and Java 2 Micro Edition (J2ME). The utilization of smartphones can take advantage of the user familiarity with cellular devices. The J2ME implementation for monitoring applications is also advantageous since its portability is greater than any application developed with another programming language (e.g.: C++) over Symbian. In the architecture, a Java midlet in the smartphone receives information about patient's location and health status. The midlet encrypts and transmits the data to a server through 802.11 or GPRS/UMTS. In case of detecting a medical alert, the midlet sends a MMS and a SMS. Additionally, the system enables the remote configuration of the BAN from a PC or even a smartphone. In order to study the scalability of this type of telemedicine networks a software for sensor emulation has been incorporated to the architecture. The emulator is prepared to retrieve and transmit realistic signals from a medical Internet data base.

Statistics

Views

Total Views
999
Views on SlideShare
994
Embed Views
5

Actions

Likes
0
Downloads
2
Comments
0

2 Embeds 5

http://www.linkedin.com 4
https://www.linkedin.com 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • La descripción del sistema en el que se enmarca este proyecto, introduciendo de forma concisa el software que se ha desarrollado, se presenta en el capítulo 2. En los capítulos 3 y 4 se hace un repaso todas las tecnologías (tecnologías de comunicación, lenguajes de programación, herramientas de desarrollo, etc.) y dispositivos hardware (teléfonos móviles, sensores, etc.), respectivamente, que se han utilizado en la ejecución del proyecto. Para cada tecnología y dispositivo hardware se efectúa un análisis técnico, resaltando sus principales características. La estructura, el diseño y el funcionamiento del software desarrollado en el presente Proyecto Fin de Carrera se detalla en los capítulos 5, 6 y 7. En el capítulo 5 se aborda el software de monitorización de pacientes que constituye el núcleo de este proyecto. La descripción del sistema en el que se enmarca este proyecto, introduciendo de forma concisa el software que se ha desarrollado, se presenta en el capítulo 2. En los capítulos 3 y 4 se hace un repaso todas las tecnologías (tecnologías de comunicación, lenguajes de programación, herramientas de desarrollo, etc.) y dispositivos hardware (teléfonos móviles, sensores, etc.), respectivamente, que se han utilizado en la ejecución del proyecto. Para cada tecnología y dispositivo hardware se efectúa un análisis técnico, resaltando sus principales características. La estructura, el diseño y el funcionamiento del software desarrollado en el presente Proyecto Fin de Carrera se detalla en los capítulos 5, 6 y 7. En el capítulo 5 se aborda el software de monitorización de pacientes que constituye el núcleo de este proyecto. La aplicación para la recepción y notificación de alarmas se estudia en el capítulo 6, siguiendo una estructura similar a la del capítulo 5. Además, se ha creado una aplicación web para la instalación del software objetivo (capítulos 5 y 6) que se describe en el capítulo 7. Para la instalación y la utilización de las aplicaciones detalladas en los capítulos 5, 6 y 7 se ha incluido un manual de instalación y de usuario, de cada una de ellas, en el capítulo 8 de esta memoria. Una descripción de todas la pruebas realizadas durante el desarrollo software de las aplicaciones diseñadas en este Proyecto Fin de Carrera se incluye en el capítulo 9, mientras que en el capítulo 10 se exponen las principales conclusiones extraídas de la realización del proyecto y se indican posibles líneas de trabajo futuras.
  • La monitorización de pacientes con sensores cableados, que es todavía una práctica normal en hospitales y centros médicos, tiene como principal inconveniente la reducción de la movilidad del paciente y la consecuente disminución de su calidad de vida. En este escenario se plantea la NECESIDAD de monitorizar los pacientes a distancia: Telemedicina. La Telemedicina es un PROBLEMA cuta SOLUCIÓN se denomina e-health. Telemedicina=Monitorización de pacientes a distancia. e-healh=Utilización de las tecnologías de la información para la realización
  • El presente Proyecto Fin de Carrera se encuadra dentro del ámbito de la e-health. El objetivo principal es la realización de un software capaz de concentrar la información de monitorización procedente de varios dispositivos electrónicos, portados por un paciente, y enviarla a un sistema externo encargado de gestionarla. Además, este software debe ser capaz de interpretar los datos del paciente monitorizado con el fin de generar alertas en situaciones críticas. Por otro lado, también es objetivo de este proyecto el desarrollo de un software adicional, para familiares del paciente, que se encargue de la recepción y de la notificación de estas alertas. OBJETIVO (PFC): Realizar sendas aplicaciones SW que se ejecutarán en dispositivos móviles y que sirven para: Concentrar información de monitorización y enviarla a un sistema externo (servidor) que se encarga de gestionarla. Además,analizar los datos monitorizados y generar alarmas en situaciones de emergencia (SW del Nodo Inteligente). Recibir y notificar alarmas de emergencia (SW de recepción y notificación de alarmas).
  • El presente Proyecto Fin de Carrera se encuadra dentro del ámbito de la e-health. El objetivo principal es la realización de un software capaz de concentrar la información de monitorización procedente de varios dispositivos electrónicos, portados por un paciente, y enviarla a un sistema externo encargado de gestionarla. Además, este software debe ser capaz de interpretar los datos del paciente monitorizado con el fin de generar alertas en situaciones críticas. Por otro lado, también es objetivo de este proyecto el desarrollo de un software adicional, para familiares del paciente, que se encargue de la recepción y de la notificación de estas alertas. OBJETIVO (PFC): Realizar sendas aplicaciones SW que se ejecutarán en dispositivos móviles y que sirven para: Concentrar información de monitorización y enviarla a un sistema externo (servidor) que se encarga de gestionarla. Además,analizar los datos monitorizados y generar alarmas en situaciones de emergencia (SW del Nodo Inteligente). Recibir y notificar alarmas de emergencia (SW de recepción y notificación de alarmas).
  • La arquitectura del sistema global, que se muestra en la figura 2.1, está compuesta por los siguientes elementos: 1. La iBAN (intelligent Body Area Network) Bluetooth del paciente, que está formada por sensores Bluetooth y por un nodo central, denominado NI (Nodo Inteligente). Estos dispositivos forman una red Bluetooth, donde el NI centraliza todas las comunicaciones. Este nodo central posee, además, interfaces de WiFi y GSM/GPRS/UMTS que utiliza para la transmisión de la información del paciente al SCC (WiFi o GPRS/UMTS) y para el envío de las alarmas a la Unidad de Control y Monitorización Móvil (UCMM) y a los terminales de los familiares del paciente (GSM/GPRS/UMTS). 2. El SCC (Servidor de Control Central) que es un equipo servidor, dotado de conexión a internet, que centraliza la información de los pacientes monitorizados y proporciona acceso a sus datos desde cualquier PC o dispositivo móvil. 3. La UCMM, que es un terminal móvil, que posee interfaces WiFi y GSM/GPRS/UMTS para la comunicación con el SCC (WiFi o GPRS/UMTS) y para la recepción de alarmas procedentes del NI (GSM/GPRS/UMTS). Se conecta con el SCC para supervisar remotamente la información de los pacientes. 4. Los terminales móviles de los familiares del paciente. Son teléfonos móviles con conexión a la red de telefonía (GSM/GPRS o GSM/GPRS/UMTS), que permiten la recepción de alarmas que envía el NI a través de dicha red. 5. Los PC de monitorización o Unidades de Control y Monitorización No Móvil (UCMNM), con conexión a internet, que acceden al SCC y hacen posible la supervisión remota de los pacientes.
  • La arquitectura del sistema global, que se muestra en la figura 2.1, está compuesta por los siguientes elementos: 1. La iBAN (intelligent Body Area Network) Bluetooth del paciente, que está formada por sensores Bluetooth y por un nodo central, denominado NI (Nodo Inteligente). Estos dispositivos forman una red Bluetooth, donde el NI centraliza todas las comunicaciones. Este nodo central posee, además, interfaces de WiFi y GSM/GPRS/UMTS que utiliza para la transmisión de la información del paciente al SCC (WiFi o GPRS/UMTS) y para el envío de las alarmas a la Unidad de Control y Monitorización Móvil (UCMM) y a los terminales de los familiares del paciente (GSM/GPRS/UMTS). 2. El SCC (Servidor de Control Central) que es un equipo servidor, dotado de conexión a internet, que centraliza la información de los pacientes monitorizados y proporciona acceso a sus datos desde cualquier PC o dispositivo móvil. 3. La UCMM, que es un terminal móvil, que posee interfaces WiFi y GSM/GPRS/UMTS para la comunicación con el SCC (WiFi o GPRS/UMTS) y para la recepción de alarmas procedentes del NI (GSM/GPRS/UMTS). Se conecta con el SCC para supervisar remotamente la información de los pacientes. 4. Los terminales móviles de los familiares del paciente. Son teléfonos móviles con conexión a la red de telefonía (GSM/GPRS o GSM/GPRS/UMTS), que permiten la recepción de alarmas que envía el NI a través de dicha red. 5. Los PC de monitorización o Unidades de Control y Monitorización No Móvil (UCMNM), con conexión a internet, que acceden al SCC y hacen posible la supervisión remota de los pacientes.
  • VERSIONES DE BLUETOOTH en la iBAN: 1) NI= Bluetooth v2.0 2) GPS=Bluetooth v1.2 3) Pulsioxímetro=Bluetooth v1.1
  • VERSIONES DE BLUETOOTH en la iBAN: 1) NI= Bluetooth v2.0 2) GPS=Bluetooth v1.2 3) Pulsioxímetro=Bluetooth v1.1
  • Subsistemas del software de recepción y notificación de alarmas en terminales móviles: Para la recepción y notificación de alarmas, se ha desarrollado un módulo de recepción de mensajes de texto (SMS o Short Message Service) y mensajes multimedia (MMS o Multimedia Messaging Service). Este módulo, que se detalla en el apartado 6.2.3, lleva a cabo las siguientes funciones: 1. Recibir las alarmas SMS/MMS enviadas por el NI. 2. Notificar al usuario la entrada de una alarma SMS/MMS de una manera “insistente”, dada la importancia de la información que contiene dicho mensaje. 3. Permitir la posibilidad de realizar una llamada de teléfono, desde la propia aplicación, a un teléfono de emergencias médicas prefijado o incluso al del propio paciente monitorizado. JSR-205 (Wireless Messaging API 2.0) y JSR-75 (PDA Optional Packages for the J2MEPlatform).
  • Subsistemas del software de recepción y notificación de alarmas en terminales móviles: Para la recepción y notificación de alarmas, se ha desarrollado un módulo de recepción de mensajes de texto (SMS o Short Message Service) y mensajes multimedia (MMS o Multimedia Messaging Service). Este módulo, que se detalla en el apartado 6.2.3, lleva a cabo las siguientes funciones: 1. Recibir las alarmas SMS/MMS enviadas por el NI. 2. Notificar al usuario la entrada de una alarma SMS/MMS de una manera “insistente”, dada la importancia de la información que contiene dicho mensaje. 3. Permitir la posibilidad de realizar una llamada de teléfono, desde la propia aplicación, a un teléfono de emergencias médicas prefijado o incluso al del propio paciente monitorizado. JSR-205 (Wireless Messaging API 2.0) y JSR-75 (PDA Optional Packages for the J2MEPlatform).
  • Se ha desarrollado una aplicación para la recepción de SMS, que mediante el uso de Push Registry de MIDP 2.0, es avisada de la llegada de SMS de alerta a un puerto determinado y lanzada automáticamente sin intervención del usuario. Tras ello, la aplicación se encarga de recoger el SMS, presentar el texto por pantalla y reproducir sonido y vibración de forma continuada, hasta que el usuario lee el contenido del mensaje. El programa también permite realizar una llamada telefónica al paciente o un centro médico, una vez leído el mensaje. Para su diseño se ha hecho uso del API JSR-120 (Wireless Messaging API 1.1) y de la facilidad Push Registry que incorpora MIDP 2.0.
  • Se ha desarrollado una aplicación para la recepción de SMS, que mediante el uso de Push Registry de MIDP 2.0, es avisada de la llegada de SMS de alerta a un puerto determinado y lanzada automáticamente sin intervención del usuario. Tras ello, la aplicación se encarga de recoger el SMS, presentar el texto por pantalla y reproducir sonido y vibración de forma continuada, hasta que el usuario lee el contenido del mensaje. El programa también permite realizar una llamada telefónica al paciente o un centro médico, una vez leído el mensaje. Para su diseño se ha hecho uso del API JSR-120 (Wireless Messaging API 1.1) y de la facilidad Push Registry que incorpora MIDP 2.0.
  • Se ha desarrollado una aplicación para la recepción de SMS, que mediante el uso de Push Registry de MIDP 2.0, es avisada de la llegada de SMS de alerta a un puerto determinado y lanzada automáticamente sin intervención del usuario. Tras ello, la aplicación se encarga de recoger el SMS, presentar el texto por pantalla y reproducir sonido y vibración de forma continuada, hasta que el usuario lee el contenido del mensaje. El programa también permite realizar una llamada telefónica al paciente o un centro médico, una vez leído el mensaje. Para su diseño se ha hecho uso del API JSR-120 (Wireless Messaging API 1.1) y de la facilidad Push Registry que incorpora MIDP 2.0.
  • Se ha desarrollado una aplicación para la recepción de SMS, que mediante el uso de Push Registry de MIDP 2.0, es avisada de la llegada de SMS de alerta a un puerto determinado y lanzada automáticamente sin intervención del usuario. Tras ello, la aplicación se encarga de recoger el SMS, presentar el texto por pantalla y reproducir sonido y vibración de forma continuada, hasta que el usuario lee el contenido del mensaje. El programa también permite realizar una llamada telefónica al paciente o un centro médico, una vez leído el mensaje. Para su diseño se ha hecho uso del API JSR-120 (Wireless Messaging API 1.1) y de la facilidad Push Registry que incorpora MIDP 2.0.
  • Imposibilidad de acceso a ciertas funcionalidades del teléfono usando J2ME (funciones de WiFi, nivel de batería, etc.). Estricto modelo de seguridad de J2ME: adquisición de certificados de una Certification Authority (CA) y firma de aplicaciones J2ME.
  • Imposibilidad de acceso a ciertas funcionalidades del teléfono usando J2ME (funciones de WiFi, nivel de batería, etc.). Estricto modelo de seguridad de J2ME: adquisición de certificados de una Certification Authority (CA) y firma de aplicaciones J2ME.

Ecc08 malta Ecc08 malta Presentation Transcript

  • WSEAS European Computing Conference (ECC’08) Development of wireless Body Area Network based on J2ME for M-Health applications Departamento de Tecnología Electrónica. University of Málaga ETSI de Telecomunicación, Campus de Teatinos, 29071 – Málaga- Spain E-mail: mjmoron@uma.es, ecasilari@uma.es M.J. Morón*, J.R. Luque*, E.J. Cuberos*, A.A. Botella*, E. Gallardo*, E. Casilari*, A. Díaz Estrella*, J.A. Gázquez** *UNIVERSITY OF MÁLAGA, **UNIVERSITY OF ALMERÍA, SPAIN Malta, September 11th, 2008
  • Index
    • Introduction: Brief state of the art
    • Goals
    • System description
    • Testbed Results and present state of the prototype
  • INTRODUCTION
    • NEED of Wireless Telemedicine
    • SOLUTION: M-health
    Continuous Monitoring Certain illnesses/sectors of population Quality of life 1) Mobility 2) Traditional wired sensors
  • Experiences on M-health: Medical Wireless BAN
    • Mobile Health (M-Health): integration of technologies of mobile computing and medical sensors with wireless communications in a system of sanitary assistance
    • Strong international efforts and research on this issue…
    • CodeBlue, a wireless architecture designed in Harvard University for emergency medical care. The project integrates low-power, wireless vital sign sensors, PDAs, and PC-class systems
    • AMON [Dec.2004]: A wearable multi-parameter sensor. Continuous collection of multiple vital signs in wrist-worn enclosure with cellular communications
    • USE of short-range communication Standards
    • Low-power standards (Bluetooth, Zigbee,) in telemedicine reduces cost and eases the deployment of systems
    • Many commercial wearable BT sensors have appeared in recent years (ECG, glucometers, tensiometers, pulse-oximeters, stehoscopes,…)
    • Commercial GPRS gateways for BT medical sensors
    • Body/Personal Area Networks: piconet of sensors. Many examples in the literature [Lee2006] [Yao2005] [Krco2005] [Dong2004]
  • General structure of a medical BAN
    • Normally, each telemedicine project jointly develops its own sensors and its specific dedicated hardware for the gateway
    Sensors Data logger/ Wireless Gateway Central Server BAN Reception Points
  • OBJECTIVES
    • Definition of a wearable medical Personal Area Networks
    • Goals:
      • Use/evaluation of commercial smart phones as the master of the sensor piconet
      • Integration of commercial BT biosensors: use of Serial Server Profile (SSP)
      • Adoption of Java (J2ME) to ease software portability
        • J2ME: Java Technology for the development of software applications in mobile devices.
      • Hybrid transmissions (Always Best Connected Paradigm): free mobility of the users
      • To enable mobility in the medical monitor
      • Detection/Priority of medical alarms: emission of SMS/MMS
  • PROPOSED ARCHITECTURE SPO2 ECG GPS Internet Internet Medical premises Wifi 2. CENTRAL CONTROL SYSTEM Intelligent Node (IN) (Smart Phone) BT Pulse- oximeter GPS 3. CONTROL and MONITORING UNITS GPRS/ UMTS 1. PATIENT BODY AREA NETWORK Bluetooth ECG Belt Internet Smart phone in charge of collecting the signals from wireless sensors and sending them through an hybrid (GPRS/UMTS/Wifi) system. It also detects medical alarms (emission of SMS) and enables remote programming of sensors Software for the remote control and monitoring of the BAN. Also portable to a smart phone In charge of storing biosignals and enabling remote monitoring from any Internet node
  • Employed Technologies (I) Intelligent Node GPS Pulse-oximeter 1. Patient Body Area Network) Central Control Server Alarm Reception terminals GPRS/UMTS WiFi IP over GPRS/UMTS J2ME J2ME Mobile Monitoring units J2ME IP Fixed Monitoring units SMS/ UMTS Java servlets, applets, Web page
  • Employed Technologies (II)
    • Smart Phones: Nokia 9500, E61, N93, N95 (Symbian OS)
    • Intelligent Node: J2ME (Java) program, Bluetooth API (JSR-82) for managing BT connections and Wireless Messaging API (JSR-120 & JSR-205) for sending SMSs/MMSs, Security and Trust Services API (JSR-177) to manage encryption.
    • Biosignals are encrypted by means of a symmetric algorithm DES with a prefixed key
    • Protocols used for transmissions: HTTP commands or TCP or UDP/ IP sockets (configurable)
    • Central Control Server: Apache Server. Servlets
    • Monitoring reception software :
      • Web interface (with a a Java Applet) available for any browser with RMI support.
      • J2ME midlet in the Mobile monitoring unit
    • Bandwidth:
      • GPRS: up to 64-144 Kbps
      • UMTS: up to 384-3600 Kbps
      • Wifi: up to 11 Mbps (802.11b), up to 54 Mbps (802.11g)
  • Employed BT devices (I)
    • GPS Leadtek 9553X
    • Chipset SiRF StarIII
    • Bluetooth v1.2(slave mode, Serial Port Profile)
    • 5V rechargeable Battery ± 5%V DC
    • NMEA-0183 Protocol
    Bluetooth Basics
    • Frequency Band (ISM) at 2.4 GHz. No licence required
    • Transmission Range: 10-100 m
    • Robustness to interferences due to Frecuency hopping
    • Binary rate: up to 1 Mbps (v 1.1), 2-3 Mbps (v 2.0): far enough for most biosignals
    • Low consume (acceptable for most external biosensors)
    • Extremely popular technology: in many models of PDA and cell phones
  • Employed BT devices (II)
    • Pulse-oximeter Nonin 4100 (I) &
    • Measurements of Plethismogram, Heart Rate & SPO2
    • Bluetooth v1.1 (slave mode, Serial Port Profile)
    • Power: 2 AA batteries
    3 bytes/s (Simple Mode) 375 bytes/s (Verbose Mode)
    • Binary Rate
    • CorBELT: Bluetooth ECG sensor from Corscience
    • 1 channel ECG lead with dry electrodes
    • Mobile event recorder: automatic alarms in case of detecting a cardiac event
    • Power: 1 AA batteries
    • Sampling rate: 200 Hz (12 bits/sample)
  • Monitoring (I): Fixed Control Units
    • Information is received in a Web page through a reception Java applet.
  • Monitoring (II): Mobile Control Units
    • Screenshots of Mobile Control Monitoring Units
    • A reception J2ME midlet processes and present the encrypted biosignals
  • Detection of Medical Alarms through SMS/MMS
    • The SW in the phone sends a SMS/MMS when an alarm is detected:
    GSM/GPRS/UMTS MMS Alarm! Reception units J2ME NI GPS Patient iBAN Pulse-oximeter J2ME
  • Detection of Medical Alarms through SMS/MMS
    • The SW in the phone sends a SMS/MMS when an alarm is detected:
    GSM/GPRS/UMTS SMS Alarm! Reception units J2ME NI GPS Patient iBAN Pulse-oximeter J2ME
  • Wireless biosignal emulator (I)
    • Two main research topics about medical WPANs/WBANs:
      • Scalability: how many sensors can be properly integrated in the BAN?
      • Coexistence: different wireless technology (BT, Zigbee, Wifi) may coexist in the same ISM band
    • The evaluation of practical application environments for BANs may require utilization in parallel of dozens of biosensors (still far from being economical)
    • Solution: to implement a generic software biosignal emulator: any BT biosensor can be emulated with a device having BT connectivity (e.g.: a laptop with one ore more BT dongles).
    • Presently, the software emulates electrocardiogram (ECG) signals.
    • Signals can be downloaded from an Internet PhysioBank Data Base)
      • Vast archive of formatted digital recordings of biomedical signals from both healthy and pathological subjects: http://www.physionet.org/physiobank/
  • Wireless biosignal emulator (II)
    • A server module retrieves the Internet data, an emulator module emits them through BT and a reception program receives the signals.
    • All these modules have been also developed with Java technology: a J2EE server and two J2ME midlets.
    PhysioBank Internet Emulator Midlet Reception Midlet Server GPRS/UMTS Wifi J2EE In charge of retreiving the biosignals from the database It includes a GUI to select the record to transmit. The selected record is requested to the server via an Internet connection (WiFi/GPRS-UMTS), then reformatted and transmitted to the reception midlet The reception software can be incorporated in IN of the developed iBAN. Consequently this architecture permits to substitute the Bluetooth ECG sensor by any J2ME capable device.
  • Conclusions (I)
    • The system was systematically tested (not with real patients)
    • Smart phone: good candidate for the role of central node in medical BANs
    • Advantages
      • Decrease of cost (not specific hardware is required)
      • Hybrid communications are natively supported in present smart phones
      • Familiarity of the patient with this type of devices
    • Use of Java (J2ME)
      • Software is easily developed (Easy sinstaxis)
      • Portability
  • Conclusions (II)
    • Disadvantages
      • Usability problems: need of some user interaction
          • Monitoring applications carry out tasks considered by operating system as risky for security. Therefore acknowledgement is requested to user before continuing certain actions
          • This drawback could be avoided by means of a validated certificate
    • INSTABILITIES of OS (Symbian) in certain phone models (portability is not perfect!)
    • HAND OFF between technologies and reconnection to BT sensors is slow and still present problems
    • No all the (low-level) functionalities in the smart-phone are accessible through J2ME
    • Difficulty of debugging errors en complex J2ME applications
  • 29th IEEE EMBS Annual International Conference J2ME and Smart Phones as Platform for a Bluetooth Body Area Network for Patient-Telemonitoring Departamento de Tecnología Electrónica. University of Málaga ETSI de Telecomunicación, Campus de Teatinos, 29071 – Málaga- Spain E-mail: mjmoron@uma.es, ecasilari@uma.es M.J. Morón, J.R. Luque, E.J. Cuberos, A.A. Botella, E. Casilari, A. Díaz Estrella UNIVERSITY OF MÁLAGA, SPAIN Lyon (France), 24th August 2007