Technologies for Road Advanced Cooperative Knowledge...

Technologies for Road Advanced Cooperative Knowledge Sharing Sensors

Project Number: Project Acronym: Project Title:

027329 TRACKSS Technologies for Road Advanced Cooperative Knowledge Sharing Sensors

Contractual Delivery Date: Actual Delivery Date: Deliverable Type* - Security*:

30/06/2006 31/07/2006 R - PU *Type: P – Prototype, R – Report, D – Demonstrator, O – Other

**Security Class: PU – Public, PP – Restricted to other programme participants (including the Commission), RE – Restricted to a group defined by the consortium (including the Commission), CO – Confidential, only for members of the consortium (including the Commission)

Responsible: Organisation: Contributing WP:

Manuel Serrano ETRA WP1

Authors (organisation): Organisation: Contributing WP:

Antonio Marqués, ETRA Patricia Rodriguez, ETRA Manuel Serrano, ETRA Sonia Belinchón, ETRA Santiago Cáceres, ETRA Uwe Beutnagel-Buchner, BOSCH Elisa Sánchez, MOV Nieves Gallego Ripoll, ITACA Julia McKillop, TRL Mathias Perrollaz, LCPC Allen Tully, UNEW Jérôme Douret, CTL

Title: Document Version:

D1.2 Requirements of the TRACKSS operational framework 10.0

D1.2 Requirements of the TRACKSS operational framework Page 2 of 88

Abstract:

This document describes the operational framework requirements which will be deployed in TRACKSS. It provides a preliminary analysis of possible collaborative scenarios involving TRACKSS sensors. Furthermore, considering those scenarios, a list of requirements for the operational framework, including the communication infrastructure, has been provided

Keywords:

TRACKSS, Cooperative, Sensors, Road, Requirements, Operational, Framework, Communications

Contract no 027329 FP6-2004-IST-4


Revision History Revision Date Description Author (Organisation)

V1 13.6.2006 Template and first contents. Manuel Serrano (ETRA)Elisa Sánchez (MOV)

V2 19.6.2006 New Contents from ITACA and TRL and new foot.

Manuel Serrano (ETRA)Nieves Gallego Ripoll, (ITACA) Julia McKillop (TRL)

V3 07.7.2006 New contents from different partners and revision of Section 2.

Santiago Cáceres (ETRA) Uwe Beutnagel-Buchner (BOSCH) Mathias Perrollaz (LCPC) Allen Tully (UNEW) Jérôme Douret (CTL)

V4 10.7.2006 First completed draft. Conclusions added.

Manuel Serrano (ETRA)Antonio Marqués (ETRA)

V5 14.7.2006 Knowledge Sharing Model. Observables provided by sensors.

Sonia Belinchón (ETRA)

V6 18.7.2006 Modified template. Manuel Serrano (ETRA)

V7 18.7.2006 Final draft. Antonio Marqués (ETRA)

V8 20.7.2006 List of requirements updated. Validation process tracing updated.

Sonia Belinchón (ETRA) Elisa Sánchez (MOV)

V9 31.7.2006 Updated list of collaborations. Final Version.

Manuel Serrano (ETRA)Antonio Marqués (ETRA) Santiago Cáceres (ETRA) Nieves Gallego Ripoll, (ITACA) Julia McKillop (TRL) Uwe Beutnagel-Buchner (BOSCH)



Mathias Perrollaz (LCPC) Allen Tully (UNEW) Jérôme Douret (CTL)

V10 19.12.2006 Modified introduction Sonia Belinchón (ETRA)



Table of Contents 1. INTRODUCTION .............................................................................................................................8

2. PRELIMINARY ANALYSIS OF POSSIBLE COLLABORATIVE SCENARIOS..................11 2.1. COLLABORATIVE MATRIX..........................................................................................................11 2.2. LIST OF POSSIBLE COLLABORATIONS .........................................................................................13

2.2.1. Test trackss pilot site .....................................................................................................13 2.2.2. Crossing section pilot site..............................................................................................14 2.2.3. Network pilot site...........................................................................................................17

3. IDENTIFICATION OF THE REQUIREMENTS........................................................................20 3.1. OPERATIONAL FRAMEWORK REQUIREMENTS.............................................................................20

3.1.1. Collaboration between heterogeneous sensors .............................................................20 3.1.2. Knowledge Sharing Model ............................................................................................22 3.1.3. Methodology to identify the requirements .....................................................................25

3.2. COMMUNICATION INFRASTRUCTURE REQUIREMENTS ................................................................26 3.2.1. State of the art ...............................................................................................................27 3.2.2. Methodology to identify the requirements .....................................................................49

4. VALIDATION OF THE REQUIREMENTS................................................................................52

4.1. METHODOLOGY.........................................................................................................................52 4.2. RESULTS ....................................................................................................................................52

5. CONCLUSIONS..............................................................................................................................54

6. GLOSSARY .....................................................................................................................................55

7. BIBLIOGRAPHY............................................................................................................................58

ANNEX A – LIST OF REQUIREMENTS......................................................................................59 A.1. INTEROPERABILITY REQUIREMENTS...........................................................................................59 A.2. INFORMATION PROCESSING REQUIREMENTS ..............................................................................60 A.3. DATA MANAGEMENT REQUIREMENTS........................................................................................61 A.4. SCALABILITY REQUIREMENTS....................................................................................................62 A.5. COMMUNICATIONS REQUIREMENTS ...........................................................................................63 A.6. RELATIONSHIP REQUIREMENTS..................................................................................................65 A.7. GENERAL FEATURES REQUIREMENTS.........................................................................................66

ANNEX B – VALIDATION FORM ................................................................................................67

ANNEX C – LIST OF OBSERVABLES .........................................................................................73 C.1. IN-ROAD INDUCTIVE LOOP SENSOR............................................................................................73 C.2. LASER SCANNER ........................................................................................................................75 C.3. VIDEO CAMERA FOR INFRASTRUCTURE APPLICATIONS ..............................................................76 C.4. SMART DUST SENSOR FOR INFRASTRUCTURE APPLICATIONS......................................................79 C.5. AIRBORNE SENSOR.....................................................................................................................82 C.6. ADVANCED AC20 RADAR SENSOR FOR TRAFFIC MONITORING...................................................83 C.7. ROAD SURFACE SENSOR FOR IN-VEHICLE ICE DETECTION ..........................................................85 C.8. VIDEO CAMERA FOR IN-VEHICLE APPLICATIONS.......................................................................86 C.9. VEHICLE IDENTIFICATION SENSOR FOR IN-VEHICLE APPLICATIONS...........................................87 C.10. PASSIVE MM WAVE SENSOR FOR IN-VEHICLE PEDESTRIAN DETECTION ......................................88



List of Figures Figure 1 – Requirements gathering process................................................................... 8 Figure 2 – TRACKSS framework.................................................................................... 9 Figure 3 – Possible collaborations identified in the test tracks scenario....................... 13 Figure 4 – Possible collaborations identified in the crossing section scenario ............. 14 Figure 5 – Possible collaborations identified in the network scenario .......................... 17 Figure 6 – Knowledge Sharing Model and the Communication Infrastructure ............. 20 Figure 7 – Knowledge shared by three different sensors ............................................. 21 Figure 8 – Preliminary Knowledge Sharing architecture............................................... 23 Figure 9 – Possible communication protocols .............................................................. 41



List of Tables Table 1: Collaborative Matrix ........................................................................................ 12 Table 2: Form to analyse the list of observables .......................................................... 26 Table 3: DRSC 5.9GHz prototype attributes................................................................. 42 Table 4: Sensor Communications Properties schema.................................................. 51 Table 5: List of Framework requirements Ids. .............................................................. 52 Table 6: List of type of requirements Ids....................................................................... 52 Table 7: Validation process .......................................................................................... 53



1. INTRODUCTION Work package 1 ‘Requirement Assessment’ sets the basis for the TRACKSS project work. In order to achieve its objectives, i.e. to assess the requirements TRACKSS developments will have to meet, this work package has been structured into three lines of work, each one covered by a specific activity:

• Analysis and formalisation of the requirements of the new or evolved sensing technologies which will collaborate within TRACKSS operational framework (task 1.1, which results are reported in this document).

• Analysis and formalisation of the main requirements of the operational framework (task 1.2, which results are reported in Deliverable 1.2).

• Analysis of the co-operative requirements related to a whole network (task 1.3, which results are reported in Deliverable 1.3).

Operational Framework

Requirements

Sensors Requirements

Communicationsexperts

Sensors developers

CTS,s Requirements

Transport system experts

Transport system experts

Gaps identification Innovations which fill gapsProject objectives

Collaboration needs

1.1

TASK

1.3

TASK

Collaborationscenarios

Observables

Validation and refinement By sensor developers and other transport systems experts

Validation and refinement By other sensor developers, transport system experts and communications experts

1.2

TASK

Sensors Requirements ApproachInnovationsIdentify gapsSensors

SOTA

Operational Framework

Requirements Approach

Data management

Interoperability

Brainstorming

Communications

General features

Relationship

Scalability

Information processing

CommunicationsSOTA

Cooperative sensors networks

SOTA

CTS,s Requirements Approach

Administration

Data fusionDecision support

ITS System Architectures

Requirements evaluation survey By transport systems experts from different countries

Figure 1 – Requirements gathering process



The Figure 1 shows the requirements gathering process which have consisted of a number of phases or stages and related decision points. A preliminary study of the state of the art of Intelligent Transport Systems (ITS) involving sensor developers, transport system experts and communications experts has helped us to identify the gaps of current ITS,s and to detect potential improvements that will be tackle within this project. Certainly, pre-existing solutions have been analysed and we have tried to find out which technology resources are available. Furthermore, expert sensor developers have helped to understand the technical constraints the design will need to accommodate. All the experts have also been involved in identifying and defining the needs or requirements to manage the accomplishment of the project goal: “Developing new systems for cooperative sensing and predicting flow infrastructure and environmental conditions surrounding traffic with a view to improve road transport operations safety and efficiency”. Finally, it has been worthwhile to validate and refine all the requirements by some experts different from those who defined them. Thus, it has been ensured as much as possible the objectivity of the results. In this context, this document reports on the work done within Task 1.2. The operational framework that will be developed in TRACKSS has been analysed. In order to gather and formalise the requirements of TRACKSS framework, the work was organized in two main topics: the definition of the Knowledge Sharing Model requirements, and the definition of the communication infrastructure requirements. Although the main focus of the project is not the research and development of new communications technologies, and actually they are just considered in a certain way as part of the knowledge sharing model, it has been considered important to treat them separately due to the importance they have in any sharing activity -without a good communications system the sharing of knowledge would not be possible.

SENSOR X SENSOR Y SENSOR Z. . .

KNOWLEDGE SHARING MODEL

KS LAYER KS LAYER KS LAYER

COMMUNICATIONS

CTS 1 CTS 2 CTS n. . .

TRACKSS FRAMEWORK

INTE

RO

PER

ABILITY

CTS X

CTS Y

CTS Z

e-Safety

AR

CH

ITECTU

RE

SENSOR X SENSOR Y SENSOR Z. . .

KNOWLEDGE SHARING MODEL

KS LAYER KS LAYER KS LAYER

COMMUNICATIONS

CTS 1 CTS 2 CTS n. . .

TRACKSS FRAMEWORK

INTE

RO

PER

ABILITY

CTS X

CTS Y

CTS Z

e-Safety

AR

CH

ITECTU

RE

Figure 2 – TRACKSS framework



Three main sources of information have been used to define the different constraints and gathering the sensor developers requirements:

• Brainstorming through the experts in the consortium in order to identify a preliminary list of possible collaboration scenarios between sensors (see chapter 2 of this deliverable).

• Production of forms to gather data format and data model requirements (observables and measures) for the knowledge Sharing Model

• Production of forms to gather communication requirements in order to establish the structure and preliminary specifications of the communication infrastructure.

Together with the description of the identified requirements, this deliverable also presents the validation methodology applied on them.



2. PRELIMINARY ANALYSIS OF POSSIBLE COLLABORATIVE SCENARIOS 2.1. COLLABORATIVE MATRIX

As a first step to motivate the discussion among the partners involved in the development of new sensing technologies, and to contribute defining a preliminary set of possible collaborative scenarios, a matrix was proposed to help partners to identify the sensors that could be used under a cooperative environment. Table 1 shows the results of these discussions, and identify a preliminary list of 33 possible collaborative scenarios. Some of them will be used as start point for the validation in WP6, and some will be used as a dissemination tool to help explaining the potential benefits of a knowledge sharing sensor system. When defining the possible scenarios, the consortium has tried to make only use of the resources available, avoiding complex scenarios that could not be feasible. The pilot sites available in the project are:

• DLR provides their test tracks facilities in Berlin (Germany). The circuit is 2000 m long, with a lot of modern sensors for traffic data measurement, with two bridges for traffic signs and over head sensors, with a meteorological station for collecting data about the current weather situation and a Traffic Tower to manage the trials. Additionally, INRETS can also offer their test TRACKSS located in Versailles (VESTA), a suburb in the west of Paris (France). VESTA is a test site dedicated to testing and qualifying intelligent transportation systems (ITS) related to driver assistance. It includes 14 km of test tracks with different layouts: motorway, highway, rural roads and intersections.

• INRETS provides a second pilot site in the town of Versailles. At least one intersection with cameras will be equipped just in front of a railway station with a lot of pedestrian flows and bus lines.

• The municipality of Valencia, the third biggest urban centre in Spain, offers a section of its urban network (approx. 8 intersections) and lends its traffic facilities and experience in traffic management to further validate the project’s results.



KNOWLEDGE SHARING: ORIGIN DESTINY

Origin Destiny

In-Road inductive

loop sensor

Laser scanner

Video camera for inf. apps.

Smart dust sensor for inf. apps.

Airborne sensor

Road surface sensor

Video Camera for In-Vehicle

apps.

Vehicle identifica

tion sensor

Smart dust sensor for in-vehicle

apps.

Passive mm wave sensor

Adv. AC20 radar sensor

In-Road inductive loop

sensor X X X

Laser scanner X X X

Video camera for

infrastructure apps.

X X X

Smart dust sensor for inf. apps.

X X X X X X X

Airborne sensor

Road surface sensor

X X

Video Camera for In-Vehicle

apps. X X

Vehicle identification

sensor. X

Smart dust sensor for in-vehicle apps.

X X X X X X

Passive mm wave sensor

X X

Adv. AC20 radar sensor

X

Table 1: Collaborative Matrix



2.2. LIST OF POSSIBLE COLLABORATIONS

The list of possible collaborations has been organized considering the three pilot sites available in TRACKSS. The objective was to provide the preliminary input to the validation work package (WP6) that will have to asses the collaborations described at this point and formalise and specify the different use cases to be validated.

2.2.1. TEST TRACKSS PILOT SITE

Figure 3 – Possible collaborations identified in the test tracks scenario

2.2.1.1. VEHICLE IDENTIFICATION SENSOR AND VIDEO CAMERA FOR IN-VEHICLE APPLICATIONS

The collaboration of Vehicle Identification (VI) Sensor to Video Camera for in-vehicle applications (CV) is a vehicle on-board collaboration. It aims to identify and locate a vehicle on the road which is broadcasting messages in a vehicle-to-vehicle communication scenario. The identification of the broadcasting vehicle gives other vehicles the possibility to decide if the messages of the broadcasting vehicle are relevant or not. For instance, if one vehicle on the road receives a message that another vehicle is going to perform an emergency braking, it does not know if the braking vehicle is directly in front of it, which would be relevant, or to the side or behind it, which would be not directly relevant. The collaboration is performed in a way that VI sensor receives from broadcasting vehicle ahead additional visual information in the invisible infrared spectral range, which identifies the vehicle as the sender of the messages. VI sensor transmits this information together with a rough position of the vehicle in front, a region of interest (ROI), via the vehicle network to CV sensor. CV sensor searches within the ROI for the vehicle, detects and locates it within the camera image and passes this information either to the driver of the car or to another application.



2.2.1.2. VEHICLE IDENTIFICATION SENSOR AND SMART DUST SENSOR FOR IN-VEHICLE APPLICATIONS

This is a bidirectional collaboration. The Vehicle Identification Sensor (VI) identifies vehicles in the optical scene and localizes them. Using Smart dust (SV), that also identifies vehicles without localizing them, we can have better confidence on the VI detected vehicles. A basic application will be to just increase the confidence of a VI-detected vehicle if it is also detected by SV. A more complex application would be to confirm a VI-detected vehicle if it is also SV-detected, but with a information about the direction the SV signal comes from (using SI-SV cooperation), or using two VI sensors, one in front of the vehicle, one in the rear.

2.2.1.3. PASSIVE MM WAVE SENSOR AND VIDEO CAMERA FOR IN-VEHICLE APPLICATIONS

Similarly, information from the PMMW sensor may be used to augment the information from the video camera (LV) to identify possible visible targets as pedestrians rather than as vehicles. The information available from the PMMW sensor will be presence, range and bearing. This can be compared with the CV sensor information on position in the image.

2.2.1.4. VEHICLE IDENTIFICATION SENSOR AND SMART DUST SENSOR FOR INFRASTRUCTURE APPLICATIONS

The application proposed could deal with road sign recognition. Road signs can be automatically detected and identified using VI. So, if the road signs are also equipped with Smart Dust (SI) identifying them, it will be a very good confirmation of their correct detection. Furthermore, SI can send additional information about the roadsign, for example, a curve-warning sign could send the curvature of the coming curve.

2.2.2. CROSSING SECTION PILOT SITE

Figure 4 – Possible collaborations identified in the crossing section scenario



2.2.2.1. VIDEO CAMERA FOR INFRASTRUCTURE APPLICATIONS AND ADVANCED AC20 RADAR SENSOR

TRW Conekt is to develop the AC20 77GHz radar for standalone operation to measure vehicle location, flow rate, average speed and to count vehicles (that is robust to poor weather and shadows). Citilog’s video camera sensor will provide on a pulse mode (for each vehicle): speed and classification (based on vehicle length). This raw data will be available for sharing with the AC20 sensor every 100 ms (pulse mode). The shared data will be fused in order to provide enhanced traffic information, possibly occupancy, speed, vehicle spacing measures and classification. This fusion can be embedded in the radar or even located in an external processor. The enhanced traffic information can then be used by some application or shared with other sensors.

2.2.2.2. VIDEO CAMERA FOR INFRASTRUCTURE APPLICATIONS AND VIDEO CAMERA FOR INFRASTRUCTURE APPLICATIONS

This collaboration aims to improve the real-time pedestrian detection on a crossing. it uses two smart cameras viewing the same pedestrian crossing and measuring the presence of pedestrians for improving each single camera measurement. In order to improve the pedestrian presence detection, image processing measurements issued from two cameras will be used. These measurements will concern the same pedestrian crossing viewing from two different locations. Data fusion techniques from these two set of measurements will be performed in order to increase the accuracy of the measures. The idea is to use cameras in an intersection area which are not dedicated for pedestrians crossing. The interest is to use one camera for several purposes: detect the traffic flow, the pedestrians flow, the bus detection etc. If the camera is not well positioned for pedestrians, there are some risks during the signal cycle that the pedestrians crossing being partially masked by cars, bus, trucks, etc. Using the view of two cameras for the same crossing area increases the accuracy of the pedestrian detection.

2.2.2.3. IN-ROAD INDUCTIVE LOOP SENSOR AND VIDEO CAMERA FOR INFRASTRUCTURE APPLICATIONS

From the Video Camera Infrastructure (CI) point of view, the expectation is to obtain an initial detection of any bus presence on a link in real-time to be provided to the CI sensor. The objective is to provide a new way for tracking a bus along its trip by making collaborate an initial source detection and its tracking along links. The first objective is to detect the arrival of each bus at the beginning of a link and to follow the bus along the link until the stop line. The In-road inductive Loop (IL) detector will provide the detection of a bus approaching. The bus detection information will be



provided to the CI detector that will find the bus inside the image and will track the bus until the stop line. Without this cooperation between these two sensors (IL+CI), it will not be possible for any of both sensors to provide a complete bus tracking. The CI brings the spatial information that the IL cannot have as sensor that provides punctual information. On contrary, it is difficult to a camera to detect a bus in an image without any other information, especially when the bus is far. The CI can also provide an indicator of the number of vehicles in front of the bus. This information is useful for forecasting the bus journey time.

2.2.2.4. IN-ROAD INDUCTIVE LOOP SENSOR AND SMART DUST SENSOR FOR INFRASTRUCTURE APPLICATIONS

The collaboration between the sensors Inductive Loop (IL) and Smart Dust Infrastructure (SI) is a bidirectional communication. The information exchanged between these two sensors will be used mainly to confirm and verify the results of vehicle counting (traffic flow, density), vehicle classification, vehicle counting and speed measurement. Occasionally, data can be used to initialize the sensors systems after an error happens. This relation will be implemented in the scenario: Crossing Section and/or Network.

2.2.2.5. PASSIVE MM WAVE SENSOR AND SMART DUST SENSOR FOR INFRASTRUCTURE APPLICATIONS

The information from the PMMW sensor, a positive indication of the presence of a pedestrian in the path of the vehicle, will be made available to SI sensor.

2.2.2.6. PASSIVE MM WAVE SENSOR AND SMART DUST SENSOR FOR IN-VEHICLE APPLICATIONS

The information from the PMMW sensor, a positive indication of the presence of a pedestrian in the path of the vehicle, will be made available to SV sensor.

2.2.2.7. SMART DUST SENSOR FOR INFRASTRUCTURE APPLICATIONS AND VIDEO CAMERA FOR INFRASTRUCTURE APPLICATIONS

SI (maybe coupled with SV) detects the presence of any bus. CI’s objective is to provide a new way for tracking a bus during its journey. This requires an initial detection of the buses (which implies vehicle classification) in the range of the CI cameras. By lining up SI/SVs along the predetermined course, buses can be detected and tracked early enough before being picked up by the CI cameras. Note that not all buses will be equipped with SV, so accurate magnetometer reading through SI will be required in order to distinguish buses from other vehicles. In this one direction collaboration, SI will provide initial detection and classification of vehicles (in particular, buses), and this information will be fed in real time to the CI sensors, enabling them to perform vehicle tracking and estimation of journey time.



2.2.2.8. SMART DUST SENSOR FOR INFRASTRUCTURE APPLICATIONS AND SMART DUST SENSOR FOR IN-VEHICLE APPLICATIONS

This is a bidirectional collaboration. Multiple SI/SVs may form an ad-hoc wireless network, where most of the devices will act as a hopping point, and some will act as a gateway. The main objective is to provide a wireless network through which data can be communicated. This network may also be used by other sensors for passing their readings to other parties. SI and SV can be connected to a laptop (using a programming board), which then acts as a gateway to the Ethernet. Note that bandwidth and data storage is limited, and the range of the Zigbee radio (in particular with regard to a moving SV) might pose a challenge. SI and SV can also be equipped with sensors, enabling them to measure temperature, light level, acceleration, sound, magnetic field, humidity and barometric pressure. Each of the devices will carry a unique identity, so they can be used for identification and other id-based measures.

2.2.2.9. SMART DUST SENSORS AND PASSIVE MM WAVE SENSOR FOR IN-VEHICLE PEDESTRIAN DETECTION

PMMW will provide positive indication of the presence of a pedestrian in the path of the vehicle. The collaboration aims to detect pedestrians (or other objects such as animals) in the path of the vehicle, enabling the driver to avoid collision with them. SI and SV (in this case, SV will be attached to the pedestrian) could also provide verification of PMMW reading. SI can detect the time-stamped presence of SV carried by the pedestrian. For this purpose, pedestrian’s SVs will contain specific information differentiating them from those used for vehicles.

2.2.3. NETWORK PILOT SITE

Network (VLC)

Laser scanner for inf. apps.ITACA

Road surface sensor CRF

In-road inductive

loop sensorITACA

Smart dust for inf. apps.

UNEW

Smart dust sensor for in-vehicle apps.

UNEW

Airborne Sensor

DLR

Figure 5 – Possible collaborations identified in the network scenario



2.2.3.1. ROAD SURFACE SENSOR FOR IN-VEHICLE ICE DETECTION AND LASER SCANNER FOR INFRASTRUCTURE APPLICATIONS

The collaboration between the sensors Laser Scanner (LS) and Road Surface Sensor (IC) is a one way direction communication. It aims to take advantage of the road surface sensor and its capability of warn about ice in the road. Thus communication flows from the IC to the LS. This communication should be used to modify the measurements in accordance with the ice detection warning. This relation will be implemented in the network scenario.

2.2.3.2. ROAD SURFACE SENSOR FOR IN-VEHICLE ICE DETECTION AND SMART DUST SENSORS

This collaboration aims to certificate IC reading and connect IC sensors to the rest of the network. This is a bidirectional collaboration. SV will provide temperature reading that can be used by IC to verify its detection of ice on the road. The SV wireless network can then be used to communicate the information gathered by IC to interested parties. Note that fine tuning might be required as ice formation cannot be determined exclusively based on temperature. It is also possible to obtain “ice on the road” warning from IC by passing the information through SV to SI. In turn, SI can broadcast to any SV of vehicles within range (which might not be equipped with IC) about the danger.

2.2.3.3. IN-ROAD INDUCTIVE LOOP SENSOR AND LASER SCANNER FOR INFRASTRUCTURE APPLICATIONS

The collaboration between the sensors IL and LS is a bidirectional communication. The information exchanged between these two sensors will be used mainly to confirm and verify the results of vehicle counting (traffic flow, density), vehicle classification and vehicle counting. Occasionally, data can be used to initialize the sensors systems after an error happens. This relation will be implemented in the scenario: Network.

2.2.3.4. ROAD SURFACE SENSOR FOR IN-VEHICLE ICE DETECTION AND IN-ROAD INDUCTIVE LOOP SENSOR

The collaboration between the sensors IL and IC is a one way direction communication. It aims to take advantage of the ice detector sensor and its capability of warn about ice in the road. Thus communication flows from the IC to the IL. This communication should be used to modify the measurements in accordance with the ice detection warning. This relation will be implemented in the scenario: Network.

2.2.3.5. LASER SCANNER FOR INFRASTRUCTURE APPLICATIONS AND SMART DUST SENSORS

The collaboration here will mostly involve bidirectional data sharing, enabling verification of various measures.



The objective is the confirmation and verification of vehicle counting (traffic flow and density), vehicle classification, and vehicle counting. Various measurements can be obtained and verified by using SI on its own or by using a combination of SI and SV. Occasionally, data can be used to initialize the sensors systems after an error happens.

2.2.3.6. IN-ROAD INDUCTIVE LOOP SENSOR AND SMART DUST SENSOR FOR INFRASTRUCTURE APPLICATIONS

The collaboration here will mostly involve bidirectional data sharing, enabling verification of various measures. The objective is the confirmation and verification of vehicle counting (traffic flow and density), vehicle classification, and speed measurement. Various measurements can be obtained and verified by using SI on its own or by using a combination of SI and SV. Occasionally, data can be used to initialize the sensors systems after an error happens.

2.2.3.7. AIRBORNE SENSOR AND SMART DUST SENSORS

AS will provide a wealth of information that will be used for verification of SI/SV measurements. The objective is that the data collected by AS can be used for the verification of SI’s (SV’s) measure on vehicle counting, speed and direction, vehicle classification, traffic density and flow, and vehicle location. Communication from AS to SI (SV’s) needs to be investigated. Only one direction of communication is possible: from AS to SI sensor, since AS does not include an uplink channel from the ground to the airborne part of the AS sensor. The ground segment of AS sensor includes a computer, which processes all measurements in real time and provides estimated traffic parameters through the network to other sensors. Once communication between AS and SI can be established, AS data can also be transmitted to other sensors through the wireless network and Ethernet.



3. IDENTIFICATION OF THE REQUIREMENTS

Figure 6 – Knowledge Sharing Model and the Communication Infrastructure

The Knowledge Sharing Model tackled by TRACKSS has to consider different topics, as the characteristics of the observables (sensing targets), the kind of information the sensor is going to gather, and the different functions that are going to be required by the new knowledge sharing capabilities. One of these functions, required by the new sharing capabilities, will cover the communications, a key point in the project since the communication infrastructure has to guarantee the actual feasibility of any knowledge sharing activity. The following sections describe in detail the approach followed to identify the operational framework requirements, including the communications infrastructure requirements. An extensive list of them can be found in Annex A.

3.1. OPERATIONAL FRAMEWORK REQUIREMENTS

3.1.1. COLLABORATION BETWEEN HETEROGENEOUS SENSORS

3.1.1.1. SHARING DATA/KNOWLEDGE

Knowledge Sharing refers to the use of information by one or more consumers that is produced by another source different from the original consumer. In most of the cases, it is beneficial to share knowledge and receive information from a different source rather than simply work in a stand-alone way.



Nowadays, technological innovations have moved sensors well beyond their original capability as simple, standalone detection devices. By connecting a variety of sensors through wired/wireless connections, sensors are moving beyond individual smart objects to more complex intelligent networks capable of taking benefit of data/knowledge provided by other sensors. This could produce several important benefits:

• Improvement of the quality of measures.

• Detection of inconsistent results.

• Increase of accuracy. The wide variety of sensors used in Intelligent Transportation Systems (ITS) applications (loops, radar, cameras, etc.) has created a need for general methods to share data among them and other Cooperative Transport Systems (CTS). Thus, it is required that the sender and receiver of the data agree on a method for transferring knowledge.

3.1.1.2. COOPERATION WITHIN SENSORS

Cooperative systems require cooperative sensors. Cooperation consists of several sensors working together for a common task. It shall be considered that collaboration techniques are all those that enable sensors to distribute tasks, information and resources in the advancement of a common labour. Tasks are distributed by means of supply and demand mechanisms. All sensors can be offering supplies and making demands at the same time without any centralising organ.

Figure 7 – Knowledge shared by three different sensors

Two ways of cooperation within sensors can be distinguished:

• Same measurements: Redundant information coming from different sensors can easily be merged improving at the same time the level of confidence in all measures. As widely illustrated over the past years, using more than one sensor contributing with the same measurements can greatly improve perception performance making use of suitable data fusion techniques.

• Complementary measurements: Additional information is added to support more detailed perception of the scenario. A multisensor system could take



advantage of this complementarily property of sensors and behave in a more robust manner to adverse conditions, more accurate and reliable.

In the last times, cooperation between heterogeneous sensors has become the main focus of interest. However, some very important points need to be considered when tackling this kind of cooperation:

• Measurements: Different sensors measure different properties. We have to find which sensors could share data measurements in a cooperative or in a complementary way.

• Data synchronisation: Sensors must exchange data to others correlated in time with a time stamp from a common clock. However, sensors are asynchronous. Therefore, a synchronisation step is necessary before any kind of cooperation. This sensor’s coordination will ensure the knowledge is shared in a coherent manner.

• Fusion strategy: Choice depends on the sensors, the available data/knowledge and the goal of the system.

3.1.2. KNOWLEDGE SHARING MODEL

The term “Knowledge Sharing Model” refers to the way knowledge flows through a network. The objective of the KSM is to provide a generic and extensible model that supports a wide range of heterogeneous sensors cooperating through a simple interface. The KSM must be designed to facilitate interoperability of sensors, fusion of heterogeneous sensor knowledge and, optionally, raw data, with the aim of ensuring accurate and precise measurements. It must define a mean to describe sensor measurements for the purpose of exchanging knowledge from disparate sensors. The KSM is a representation of the data and its relationships, a model that provides a conceptual view of the data flow. In this context, communication of sensor data requires the exchange of the sensor information as well as the metadata in which the meaning and quality of data can be described and assessed. Sometimes a sensor, depending on its features, can provide several mixed data measurements. Maybe not all the measurements are relevant to another cooperative sensor. Thus, irrelevant data measurements need to be discarded. Since different types of sensors may not be able to share raw data because their limited process capabilities, a post-before-process requirement exists in order to standardize a formal way for sharing data measurements and facilitate their comprehension by any sensor. The transformation of raw data into knowledge involves a minor bandwidth requirement. Despite of this functionality, optionally, sharing raw sensor data (e.g., an image from a camera) could be also feasible. This optional functionality results in a much more complete system, though it introduces a big disadvantage: a largest bandwidth will be required.



Sensor i

D

FE DFM

EDM

CM

KD

Figure 8 – Preliminary Knowledge Sharing architecture



Both sensors and CTS will take advantage of the KSM to search, discover, subscribe, and process relevant knowledge as well as identify fusible features from any sensor which may be able to assist in the solution of any IT issue. This will be done by means of whatever of those techniques: Data collection

• Periodic sampling: When certain conditions or processes need to be monitored constantly, sensor data is acquired and forwarded to close sensors or another CTS like the Data Fusion Module (DFM) on a periodic basis. The sampling period mainly depends on how fast the condition or process varies and what intrinsic characteristics need to be captured. Hence, sensors should be able to adapt its sampling rates.

• Event driven: There are many cases that require monitoring one or more crucial variables immediately following a specific event or condition. To support event-driven operations with adequate power efficiency and speed of response, the sensor must be designed such that its power consumption is minimal in the absence of any triggering event, and the wake-up time is relatively short when the specific event or condition occurs.

• Store and forward: Data can be captured and stored or even processed by a sensor before it is transmitted. Instead of immediately transmitting every data measurement as it is acquired, aggregating and processing data by remote sensor can potentially improve overall network performance in both power consumption and bandwidth efficiency.

Bidirectional dialog • Polling: In this model, there is an initial sensor discovery process that

associates a sensor id with each physical sensor in the network. The controller then polls each sensor on the network successively, typically by sending a serial query message and waiting for a response to that message.

• On demand: The on-demand data model supports highly mobile sensor nodes in the network where a gateway device enters the network, automatically binds to that network and gathers data, then leaves the network. With this model, one mobile gateway can bind to multiple networks and multiple mobile gateways can bind to a given network.

A prior knowledge about the sensors and measurements to be extracted should be represented explicitly in a knowledge data base. This knowledge will enable the system, for example, to identify and classify an object. The KSM must be designed to support a wide range of sensors:

• Sensors on infrastructure: Super loops, laser scanners, smart cameras, smart dust, remote sensing, …

• Sensors on-board: Ice detector, CMOS camera, smart dust, wave advanced pedestrian detectors, advanced vehicle identification, …

Adding new sensors to the framework should not require modification or development of new interfaces, adapters, or model translators.



3.1.3. METHODOLOGY TO IDENTIFY THE REQUIREMENTS

The identification of the requirements related to the knowledge sharing approach, was performed through the use of two main tools:

• The analysis of the different collaborations described in the previous section and the preparation of a first list of requirements tackling the main functionalities demanded.

• The analysis of the data format and data model requirements (observables, measures and events) making use of a specific form to query the sensor developers involved in the project.

3.1.3.1. IDENTIFICATION OF THE LIST OF OBSERVABLES

The process of designing a data model begins with identifying necessary data and the relationships among components of that data. Observational characteristics

• Event or physical properties measured: speed, road occupancy …

• Description of the measurement features.

• Quality characteristics: accuracy, precision, …

• Constraints.

• Hazards.

• Information about the location of the sensor relative to a coordinate reference system: a measurement feature binds the result to the location where the measurement was made.

• Time instant relative to a common clock. Sensor description The purpose of the sensor description is:

• General sensor information: provide general information about the sensor (sensor id, sensor name, etc.).

• Performance characteristics (e.g. accuracy, threshold, etc.).

• Fundamental properties and assumptions regarding sensor

• Technical data. Additional information

• Scenario to which the sensor is attached.

In order to proceed with this identification of measurements and events, every sensor developer specified all the observables its sensor is able to detect once the raw data has been processed, i.e. the final information they are going to provide both to the system and to the rest of the sensors they are going to share information with.

More concretely, each observable detected and processed by a sensor was specified by:

• a name that identifies the event or property being measured,



• classification of the measure or event.

• range of values of the measurements (minimum and maximum values, units of measures supported, threshold) or description of the event,

• method applied to extract the information above listed from the raw data. The following table shows the template used to gather the definition of each measurement or event. Some information as the accuracy, the hazard type or the data extraction method (to translate the raw data into processed data) are also part of the model data (Annex C provides the results of this form).

List of observables provided by Name of the sensor

Observable Name of the observable

Observable type Event, Measurement, …

Measure or event associated with the observable

For instance, If detecting pedestrians then … Measure: Pedestrian detection Measure type or category: Human being recognition Value: Pedestrian crossing a pedestrian crossing Accuracy: 98% Hazard type: Run over If measuring type of vehicle then … Measure: Type of vehicle Measure type or category: Classification Value: truck (Other possible Knowledge Basis values: car, motorbike, bus, …) Accuracy: 90% Data extraction method: Image processing (vehicle outline)

Table 2: Form to analyse the list of observables

3.2. COMMUNICATION INFRASTRUCTURE REQUIREMENTS

The future of in-car infotainment, telematics, safety, and comfort and convenience applications is expected to be influenced by a range of emerging and promising wireless network technologies and protocols. Bluetooth, WiFi, WiMax, Ultra wide band, ZigBee and wireless USB are some of the new wireless technologies that are offering the automakers and their suppliers exciting possibilities of greatly enhancing the



infotainment and telematics potential of their products by supporting a range of advanced and innovative applications. The emerging wireless network technologies and protocols are heralding a new era where the cars and light trucks in roads will communicate with the world outside and devices within them with each other thereby converging greater electronic content with automobiles. The automotive market penetration of the wireless network technologies is greatly dependent on the success and penetration of these technologies in the consumer electronics market. Infotainment systems and mobile phones in the consumer electronics market are expected to be the early adopters of these technologies inciting consumer awareness regarding their value attributes. Although the application potential of the emerging wireless network technologies and protocols in the automotive industry is promising, there are some serious technological issues that need to be addressed before these technologies are adopted by the automotive industry. The most important of these issues is the effective performance of the devices enabled with these technologies under the rigors of automotive operating conditions. In addition to this the security, reliability, robustness and interoperability of the networks under all operating conditions are crucial issues that need to resolved to accelerate the automotive market penetration of these technologies and protocols. The network security, imperviousness to intrusions and interferences, and interoperability of the network technologies are key precursors that need to be resolved for optimizing these technologies for automotive applications. The study of the state of the art in this kind of technologies offers the market participants an in-depth analysis of the key emerging in-car wireless network technologies and protocols which include Bluetooth, WiFi, WiMax, UWB, and ZigBee, CALM, UMTS, CAN, EDGE, etc. The state-of-the-art in most of these technologies are presented in this document and the perceived automotive application areas and functions are described which will help the market participants understand the futuristic products that will utilize these technologies and protocols.

3.2.1. STATE OF THE ART

Mobile environments are characterized by mobility and other different issues: highly limited resources, multiple access points and clients, unreliable communication, and ubiquity. Recent developments in mobile devices have greatly pushed back the limits of programmability and software complexity. While these devices are still much more limited than desktop computers, they now allow deployment of quite advanced applications from intelligent agents to video games. Considering presence applications, modern devices are sufficiently equipped to be an active part of a presence service, while user interface limitations and reliance on battery power remain restrictive factors. Having an application that frequently sends and receives data updates over the air is a constant drain on battery power. Also, directly interacting with systems designed primarily for desktop usage may result in excessive traffic amounts, since acceptable bandwidth usage is typically on a whole different scale.



3.2.1.1. MOBILE NETWORK TECHNOLOGIES

Mobile network technologies have evolved from analogue based systems to digital based systems and from circuit switching to packet switching technologies. This evolution can be described by different generations of mobile technologies, i.e. first-generation (1G), second-generation (2G), 2.5G and third-generation (3G) technologies. Only 1G is based on analogue technology. Some of the main standards for each generation technology are:

• 1G: Total Access Communication System (TACS) in Europe, Advance Mobile Phone System (AMPS) in North America, Nippon Telegraph & Telephone (NTT) in Japan, Code Division Multiple Access One (CDMAONE).

• 2G: Global System for Mobile Communication (GSM), Code Division Multiple Access 2000 (CDMA2000), High Speed Circuit Switched Data Technology (HSCSD).

• 2.5G: General Packet Radio System (GPRS), Enhanced Data Rate for GSM Evolution (EDGE).

• 3G: Universal Mobile Telephone Standard (UMTS).

3.2.1.1.1. GLOBAL SYSTEM FOR MOBILE COMMUNICATIONS (GSM)

Global System for Mobile Communication is a second generation standard for mobile communication, developed by the European Telecommunications Standards Institute (ETSI) and now currently owned by the Third generation Partnership Project (3GPP). GSM differs significantly from its predecessors in that both signalling and speech channels are digital. Operating in the 900 MHz and the 1800 MHz frequency band, GSM is the most widespread mobile standard currently in use across Europe and the Asia-Pacific region. GSM is an open standard. GSM is the most popular standard for mobile phones in the world (GSM phones are used by over a billion people across more than 200 countries). The design of the service is moderately complex because it must be able to locate a moving phone anywhere in the world, and accommodate the relatively short battery life, limited input/output capabilities, and weak radio transmitters on mobile devices.. The ubiquity of the GSM standard makes international roaming very common with "roaming agreements" between mobile phone operators. GSM was designed using digital techniques, unlike with previous analogue cellular systems like AMPS in the US and TACS in Europe. The techniques used are a combination of Time Division Multiple (TDMA) and Frequency Division Multiple Access (FDMA), which are primarily for voice transmission and control. Since all users must share a limited radio spectrum, these techniques are used to divide the bandwidth among as many users as possible. Also, Space Division Multiple Access is used to provide a system based on a series of base stations each covering a limited area. FDMA divides the radio frequency into several frequency carriers of 200 Hz, while TDMA enables 8 voice channels in each 200 Hz carrier by dividing each one in time.



GSM Services: • Teleservices: telecommunication services can be divided into bearer services,

teleservices, and supplementary services. The most basic teleservice supported by GSM is telephony.

• Data Services: Internet Services: GSM users can send and receive data, at rates up to

9.6K bps, to users on POTS (Plain Old Telephone Service), ISDN, Packet Switched Public Data Networks, and Circuit Switched Public Data Networks.

SMS (Short Messaging Service): unique to GSM technology, SMS is a bidirectional service for short alphanumeric (up to 160 bytes) messages.

Facsimile: Sending and receiving of fax messages, using a GSM phone and a laptop computer.

Secure Corporate LAN Access: secure access to e-mails, faxes, and file transfer via an encrypted link to a corporate LAN.

Supplementary Services: Such services include call forwarding, call barring, caller identification, call waiting and multiparty conversation. These services can be controlled via service applications using a GSM network API, such as those specified by the Parlay Group, allowing application developers to access GSM network capabilities. GSM technologies are limited due to its low data transmission speed, therefore with the growth in data services the long term future of GSM is uncertain, unless it is changed to offer high bandwidth data services. Also, internet browsing using GSM phones is subject to charging of on-line duration and reconnection is necessary for each browsing session, as opposed to with GPRS (General Packet Radio Service), charging is based on the data received or viewed, with all time connectivity is available. GSM in practice: From the point of view of the consumer, the key advantage of GSM systems has been early delivery of new services at low costs. The advantage for network operators has been the low infrastructure cost which is caused by open competition. The primary disadvantage has been that GSM's radio network is based on TDMA technology, which is considered less advanced than competing CDMA-based systems. Practical performance figures are rather similar, however.

3.2.1.1.2. GENERAL PACKET RADIO SERVICE (GPRS)

General Packet Radio Service is packet switched wireless protocol providing non-voice value added services that allows information to be sent and received across a mobile telephone network. It is described as a 2.5G technology which supplements Circuit Switched technology such as GSM. Data transmissions speeds go from 9.6 kbps to a theoretical maximum speed of up to 171.2 kbps are achievable with GPRS using all eight timeslots at the same time. In addition to higher data rates, GPRS provides users with all time connectivity while only charged for the data viewed or received with a minimal on-line charge. GPRS is an evolutionary step towards 3G technologies, such



as EDGE (Enhanced Data GSM Environment) and UMTS (Universal Mobile Telephone Service). GPRS may be considered as an overlay network on the GSM networks, using the GSM resources to the fullest potential. To enable this, extra network elements are required for this packet based mobile network. Certain hardware elements are added to provide the IP infrastructure needed for packet based services. The SGSN (Serving GPRS Support Node) and GGSN (Gateway GPRS Support node) are the mobile network equivalents of routers and gateways. Other main additions are the upgrading with new software to existing cellular infrastructure. GPRS only uses its radio resources when users are actually sending or receiving data, therefore the available radio resource can be concurrently shared between several mobile data users, rather than dedicating a radio channel to a single user for a fixed period of time. This efficient use of scarce radio resources means that large numbers of GPRS users can potentially share the same bandwidth and be served from a single cell. GPRS uses the same radio channel as voice calls, a channel that is 200 kHz wide and which carries a raw digital radio stream of 271 kbps. For voice calls this channel is divided into 8 separate data streams, each carrying about 34 kbps. After protocol and error correction overhead, 13 kbps is left for each voice connection or about 14 kbps for data. Packet-switched data can use several channels where as circuit-switched data uses one voice channel. GPRS can combine up to 8 of these channels, and with 14 kbps of data throughput each the delivered bandwidth can be up to 100 Kbps. Most economical phones will be ones that are limited to 56 kbps, as not all eight voice channels have to be used. A mobile station can request the amount of bandwidth it desires at the time it establishes a data session. GPRS applications includes Intranet access, Internet access, E-Mail, Fax, and unified messaging, using a single mailbox for all messages, including voice mail, faxes, e-mail, short message service (SMS), and pager messages. Limitations of GPRS:

• The limited cell capacity during voice and GPRS transmission calls. The use of a bearer for a different type of radio resource, such as SMS, would better utilize the cell capacity.

• Achieving the theoretical maximum GPRS data transmission speed of 172.2 kbps would require a single user taking over all eight timeslots which is unlikely that a network operator will allow all timeslots to be used by a single GPRS user. The bandwidth available to a GPRS user will therefore be severely limited.

• Suboptimal Modulation - GPRS employs a modulation technique called Gaussian minimum-shift keying (GMSK) while the EDGE uses a new modulation technique to allow a much higher bit rate across an air interface, called eight-phase-shift-keying (8PSK) modulation. This type of modulation is used for 3G systems, so upgrading to 3G technology seems inevitable for a network operator.

• Transit Delays - GPRS sends data packets through different channels to reach a destination, therefore data corruption or data loss may occur. Data integrity



and retransmission capabilities are used to avoid this, but the result is that potential delays can occur.

• No Store and Forward - Unlike SMS technology, GPRS does not provide a store and forward mechanism for data transmission, therefore SMS may be need to enable sending and receiving of short messages.

GPRS in practice: Today nearly all major Mobile Phone Operators in Europe offer GPRS-compatible mobile phones. GPRS upgrades GSM data services providing:

• Point-to-point (PTP) service: internet working with the Internet.

• Point-to-multipoint (PTM) service: point-to-multipoint multicast and point-to-multipoint group calls.

• Short Message Service (SMS).

• Anonymous service: anonymous access to predefined services.

• Future enhancements: flexible to add new functions, such as more capacity, more users, new accesses, new protocols, new radio networks.

GPRS today is offered by all international mobile phone operators in Europe. All recent devices as Mobile Phones, Smart Phones or PDA’s with mobile function are GPRS compatible.

3.2.1.1.3. ENHANCED DATA FOR GLOBAL EVOLUTION (EDGE)

Enhanced Data for Global Evolution is a higher bandwidth version of GPRS permitting transmission speeds of up to 384 Kbps. It is compatible with the GSM protocol, but it requires higher quality radio signals to reach the increased speed. Deploying EDGE will allow mobile network operators to offer high-speed, mobile multimedia applications. It allows a migration path from GPRS to UMTS, because the modulation changes that will be necessary for UMTS at a later stage will already be implemented. A number of mobile operators are considering implementing EDGE as an interim data technology between GPRS and UMTS, but no investments have been made in this technology as yet. The opportunity window for EDGE is very short.

3.2.1.1.4. UNIVERSAL MOBILE TELECOMMUNICATION SYSTEM (UMTS)

UMTS is a new standard heralding the so-called third generation of mobile telephony. It represents a technological leap, with faster data rates and an enlarged network capacity for mobile data transmission. It was developed within the ITU's IMT-2000 framework. UMTS is a realisation of a new generation of broadband multi-media mobile telecommunications technology. The coverage area of service provision is to be world wide in the form of FLMTS (Future Land Mobile Telecommunications Services and now called IMT2000). The coverage will be provided by a combination of cell sizes ranging from 'in building' Pico Cells to Global Cells provided by satellite, giving service to the remote regions of the world.



Data speeds up to 384 kbits/s are possible. This opens the door to a wealth of new broadband services, such as video telephony, audio and video streaming and downloading audio and video (permanent storage on mobile devices). UMTS requires a new, dedicated mobile network. Transceivers from the existing GSM network can be used for this as well. Users will need to have UMTS-enable devices (mobile phones, PDAs, laptops with special cards, etc.). In the future today's UMTS networks will be upgraded with High Speed Downlink Packet Access (HSDPA), sometimes known as 3.5G. This will make transfer speed of up to 10 Mbit/s possible. Marketing material for UMTS has emphasised the possibility of mobile videoconferencing, although whether there is actually a mass market for this service remains untested. UMTS Mobile Multimedia Services that are already or will be available for UMTS networks:

• Video telephony, instant voicemail.

• High Speed internet browsing.

• Streaming Video and audio .

• Push newspaper and magazines.

• E-commerce, e-cash, telebanking, , micro-billing shopping.

• News, Online libraries, search engines.

• Location tracking, emergency use.

• location sensitive information and guidance, e-tour, location awareness, time tables, e-ticketing.

• TV, radio, PC, access to remote computer, MP3 player, camera, video camera, GPS, remote control unit.

UMTS in practice: At the air interface level, UMTS itself is incompatible with GSM. Though all UMTS phones sold today (as of 2004) are UMTS/GSM dual-mode phones, hence they can also make and receive calls on regular GSM networks. If a UMTS customer travels to an area without UMTS coverage, a UMTS phone will more or less automatically switch to GSM (roaming charges may apply). If the customer travels outside of UMTS coverage during a call, the call will be transparently handed off to available GSM coverage. At least this is the theory, in practice there are still lot of problems when switching from UMTS to GSM mode. Regular GSM phones cannot be used on the UMTS networks. Although the sales of UMTS phones is increasing it is still too early to evaluate the overall acceptance of UMTS-compatible devices as most of the international mobile phone operators only started end of 2004 to really push UMTS-compatible mobile phones and UMTS HighSpeed Internet connection cards. However, so far a real profit of this technology can only partly be experienced in urban areas. Rural areas and smaller cities are not yet included in the UTMS coverage. When asking different representatives of the industry, at what moment in time an overall UMTS coverage will be available –any serious answer is obtained.



3.2.1.1.5. HIGH SPEED DOWNLINK PACKET ACCESS (HSDPA)

High Speed Downlink Packet Access is a packet-based data service in W-CDMA downlink with data transmission up to 8-10 Mbps (and 20 Mbps for MIMO systems) over a 5MHz bandwidth in WCDMA downlink. HSDPA is a similar boost for WCDMA that EDGE does for GSM. It provides a two-fold increase in air interface capacity and a five-fold increase in data speeds in the downlink direction. HSDPA also shortens the round-trip time between the network and terminals and reduces variance in downlink transmission delay. HSDPA improves system capacity and increases user data rates in the downlink direction, that is, transmission from the radio access network to the mobile terminal. The improvements in performance are achieved by:

• bringing some key functions, such as scheduling of data packet transmission and processing of retransmissions (in case of transmission errors) into the base station - that is, closer to the air interface

• using a short frame length to further accelerate packet scheduling for transmission

• employing incremental redundancy for minimizing the air-interface load caused by retransmissions

• adopting a new transport channel type, known as High Speed Downlink Shared Channel (HS-DSCH) to facilitate air interface channel sharing between several users

Adapting the modulation scheme and coding according to the quality of the radio link. WIMAX WiMAX is defined as Wireless Interoperability for Microwave Access by the WiMAX Forum [1], formed in April 2001 to promote conformance and interoperability of the standard IEEE 802.16, also known as WirelessMAN. The Forum describes WiMAX as "a standards-based technology enabling the delivery of last mile wireless broadband access as an alternative to cable and DSL." The WiMAX Forum is "the exclusive organization dedicated to certifying the interoperability of BWA products, the WiMAX Forum defines and conducts conformance and interoperability testing to ensure that different vendor systems work seamlessly with one another." Those that pass conformance and interoperability testing achieve the “WiMAX Forum Certified” designation and display this mark on their products and marketing materials. Vendors claiming their equipment is “WiMAX-ready,” "WiMAX-compliant,” or "pre-WiMAX," are not WiMAX Forum Certified, according to the Forum. [2] Overview The IEEE 802.16 media access controller (MAC) is significantly different from that of IEEE 802.11 Wi-Fi MAC. In Wi-Fi, the MAC uses contention access—all subscriber stations wishing to pass data through an access point are competing for the AP's attention on a random basis. This can cause distant nodes from the AP to be repeatedly interrupted by less sensitive, closer nodes, greatly reducing their



throughput. And this makes services, such as VoIP or IPTV which depend on a determined level of quality of service (QoS) difficult to maintain for large numbers of users. In contrast, the 802.16 MAC is a scheduling MAC where the subscriber station only has to compete once (for initial entry into the network). After that it is allocated a time slot by the base station. The time slot can enlarge and constrict, but it remains assigned to the subscriber station meaning that other subscribers are not supposed to use it but take their turn. This scheduling algorithm is stable under overload and over-subscription (unlike 802.11). It is also much more bandwidth efficient. The scheduling algorithm also allows the base station to control Quality of Service by balancing the assignments among the needs of the subscriber stations. A recent addition to the WiMAX standard is underway which will add full mesh networking capability by enabling WiMAX nodes to simultaneously operate in "subscriber station" and "base station" mode. This will blur that initial distinction and allow for widespread adoption of WiMAX based mesh networks and promises widespread WiMAX adoption. WiMAX/802.16's use of OFDMA and scheduled MAC allows wireless mesh networks to be much more robust and reliable. The original WiMAX standard, IEEE 802.16, specifies WiMAX in the 10 to 66 GHz range. 802.16a, updated in 2004 to 802.16-2004, added support for the 2 to 11 GHz range, of which most parts are already unlicensed internationally and only very few still require domestic licenses. Most business interest will probably be in the 802.16-2004 standard, as opposed to licensed frequencies. The WiMAX specification improves upon many of the limitations of the Wi-Fi standard by providing increased bandwidth and stronger encryption. It also aims to provide connectivity between network endpoints without direct line of sight in some circumstances. The details of performance under non-line of sight (NLOS) circumstances are unclear as they have yet to be demonstrated. It is commonly considered that spectrum under 5-6 GHz is needed to provide reasonable NLOS performance and cost effectiveness for PtM (point to multi-point) deployments. WiMAX makes clever use of multi-path signals. Uses for WiMAX WiMAX is a framework for wireless development based on a forward-looking core set of technologies. More recently 3GPP cellular's 4G, 802.22 Cognitive Radio RAN (Rural Area Network), and 802.20, the High Speed Mobile Broadband Wireless Access (MBWA) Working Group, have shifted toward use of similar constructs of multi-channel scalable OFDM, HARQ, FEC, MIMO-AAS and other complementary technologies as are part of WiMAX. WiMAX is designated as the metropolitan area network (MAN) technology that can connect IEEE 802.11 (Wi-Fi) hotspots with each other and to other parts of the Internet and provide a wireless alternative to cable and DSL for last mile (last km) broadband access. However, the field of uses is broader and overlaps those for mobile WAN (wide area networks) and WLANs. IEEE 802.16 provides up to 50 km (31 miles) of linear service area range and allows connectivity between users without a direct line of sight. Note that this should not be taken to mean that users 50 km (31 miles) away without line of sight will have connectivity. Practical limits from real world tests seem to be around "3 to 5 miles" (5 to 8 kilometers). The technology has been claimed to provide shared data rates up to 70 Mbit/s, which, according to WiMAX



proponents, is enough bandwidth to simultaneously support more than 60 businesses with T1-type connectivity and well over a thousand homes at 1Mbit/s DSL-level connectivity. Real world tests, however, show practical maximum data rates between 500kbit/s and 2 Mbit/s, depending on conditions at a given site. It is also anticipated that WiMAX will allow inter-penetration for broadband service provision of VoIP, video, and Internet access—simultaneously. Most cable and traditional telephone companies are closely examining or actively trial-testing the potential of WiMAX for "last mile" connectivity. This should result in better price-points for both home and business customers as competition results from the elimination of the "captive" customer bases both telephone and cable networks traditionally enjoyed. Even in areas without preexisting physical cable or telephone networks, WiMAX could allow access between anyone within range of each other. Home units the size of a paperback book that provide both phone and network connection points are already available and easy to install. There is also interesting potential for interoperability of WiMAX with legacy cellular networks. WiMAX antennas can "share" a cell tower without compromising the function of cellular arrays already in place. Companies that already lease cell sites in widespread service areas have a unique opportunity to diversify, and often already have the necessary spectrum available to them (i.e. they own the licenses for radio frequencies important to increased speed and/or range of a WiMAX connection). WiMAX antennae may be even connected to an Internet backbone via either a light fiber optics cable or a directional microwave link. Some cellular companies are evaluating WiMAX as a means of increasing bandwidth for a variety of data-intensive applications. In line with these possible applications is the technology's ability to serve as a very high bandwidth "back-haul" for Internet or cellular phone traffic from remote areas back to a backbone. Although the cost-effectiveness of WiMAX in a remote application will be higher, it is definitely not limited to such applications, and may in fact be an answer to expensive urban deployments of T1 back-hauls as well. Given developing countries' (such as in Africa) limited wired infrastructure, the costs to install a WiMAX station in conjunction with an existing cellular tower or even as a solitary hub will be diminutive in comparison to developing a wired solution. The wide, flat expanses and low population density of such an area lends itself well to WiMAX and its current diametrical range of 30 miles. For countries that have skipped wired infrastructure as a result of inhibitive costs and unsympathetic geography, WiMAX can enhance wireless infrastructure in an inexpensive, decentralized, deployment-friendly and effective manner. Spectrum Allocations for WiMAX The 802.16 specification applies across a wide swath of RF spectrum, but specification is not the same as permission to use. There is no uniform global licensed spectrum for WiMAX. In the US, the biggest segment available is around 2.5GHz, and is already assigned, primarily to Sprint Nextel. Elsewhere in the world, the most likely bands used will be around 3.5GHz, 2.3/2.5GHz, or 5GHz, with 2.3/2.5 GHz probably being most important in Asia. There is some prospect that some of a 700MHz band might be made available for WiMAX use, but it is currently assigned to the analog TV and awaits the complete



rollout of HD digital TV before it can become available, likely by 2009. And, in any case, there will be other uses suggested for that spectrum if and when it actually becomes open. It seems likely that there will be several variants of 802.16, depending on local regulatory conditions and thus on which spectrum is used. Even if everything but the underlying radio frequencies is the same. WiMAX equipment will not, therefore, be as portable as it might have been. And perhaps even less so than WiFi, whose assigned channels in unlicensed spectrum varies more than a little from jurisdiction to jurisdiction. Standards The current 802.16 standard is IEEE Std 802.16-2004, approved in June 2004. It renders the previous (and 1st) version 802.16-2001 obsolete, along with its amendments 802.16a and 802.16c. IEEE Std 802.16-2004 addresses only fixed systems. An amendment 802.16e is in the works which adds mobility components to the standard. 802.16-2004 IEEE Standard for Local and metropolitan area networks Part 16: Air Interface for Fixed Broadband Wireless IEEE 802.16e IEEE 802.16-2005, approved December, 2005 (formerly named but still best known as 802.16e or Mobile WiMAX). The WiMAX mobility standard, is an improvement on the modulation schemes stipulated in the original (fixed) WiMAX standard. It allows for fixed wireless and mobile Non Line of Sight (NLOS) applications primarily by enhancing the OFDMA (Orthogonal Frequency Division Multiple Access). Many think that by stipulating a new modulation method called Scalable OFDMA (SOFDMA), 802.16-2005 will make the older 802.16-2004 which uses OFDM-256 obsolete. However, several manufacturers plan for a migration path from the older version of the standard to the more robust, mobile modulation scheme. In any case, manufacturers are working through the WiMAX Forum to achieve compatibility between similar system profiles. SOFDMA will improve upon OFDM256 for NLOS applications by:

• Improving NLOS coverage by utilizing advanced antenna diversity schemes, and hybrid-Automatic Retransmission Request (hARQ)

• Increasing system gain by use of denser sub-channelization, thereby improving indoor penetration

• Introducing high-performance coding techniques such as Turbo Coding and Low-Density Parity Check (LDPC), enhancing security and NLOS performance

• Introducing downlink sub-channelization, allowing administrators to trade coverage for capacity or vice versa

• Improving coverage by introducing Adaptive Antenna Systems (AAS) and Multiple Input Multiple Output (MIMO) technology

• Eliminating channel bandwidth dependencies on sub-carrier spacing, allowing for equal performance under any RF channel spacing (1.25-14 MHz)



• Enhanced Fast Fourier Transform (FFT) algorithm can tolerate larger delay spreads, increasing resistance to multipath interference

SOFDMA and OFDMA256 are not compatible so most equipment will have to be replaced. However, some manufacturers are attempting to provide a migration path for older equipment to SOFDMA compatibility which would ease the transition for those networks which have already made the OFDMA256 investment. SR Telecom. IEEE 802.16e Standard: What will it mean for fixed wireless applications.

3.2.1.2. WIRELESS NETWORKS

3.2.1.2.1. WIRELESS LAN

A wireless LAN or WLAN is a wireless local area network that uses radio waves as its carrier: the last link with the users is wireless, to give a network connection to all users in a building or campus. The backbone network usually uses cables. WLAN is expected to continue to be an important form of connection in many business and public areas. The market is expected to grow as the benefits of WLAN are recognized. Frost and Sullivan estimate the WLAN market to have been 0.3 billion US dollars in 1998 and 1.6 billion dollars in 2005. So far WLANs have been installed primarily in warehouses and resellers, but are recently being installed in various kinds of schools. Large future markets are estimated to be in health care, educational institutes and corporate offices. In the business environment, meeting places, public areas and side offices would be ideal for WLAN (although in the UK the exorbitant cost of using such connections has so far limited use to airports' Business Class lounges etc.) Standard 802.11 In 1997, the Institute of Electrical and Electronics Engineers (IEEE) created the first WLAN standard. They called it 802.11 after the name of the group formed to oversee its development. Unfortunately, 802.11 only supported a maximum bandwidth of 2Mbps-too slow for more applications. For this reason, ordinary 802.11 wireless products are no longer being manufactured. Standard 802.11b IEEE expanded on the original 802.11 standard in July 1999, creating the 802.11b specification. 802.11b supports bandwidth up to 11 Mbps, comparable to traditional Ethernet. 802.11b uses the same radio signalling frequency - 2.4 GHz - as the original 802.11 standard. Being an unregulated frequency, 802.11b gear can incur interference from microwave ovens, cordless phones, and other appliances using the same 2.4 GHz range. However, by installing 802.11b gear a reasonable distance from other appliances, interference can easily be avoided. Vendors often prefer using unregulated frequencies to lower their production costs.

• Pros of 802.11b - lowest cost; signal range is best and is not easily obstructed

• Cons of 802.11b - slowest maximum speed; supports fewer simultaneous users; appliances may interfere on the unregulated frequency band



Standard 802.11a When 802.11b was developed, IEEE created a second extension to the original 802.11 standard called 802.11a. Because 802.11b gained in popularity much faster than did 802.11a, some people believe that 802.11a was created after 802.11b. In fact, 802.11a was created at the same time. Due to its higher cost, 802.11a fits predominately in the business market, whereas 802.11b better serves the home market. 802.11a supports bandwidth up to 54 Mbps and signals in a regulated 5 GHz range. Compared to 802.11b, this higher frequency limits the range of 802.11a. The higher frequency also means 802.11a signals have more difficulty penetrating walls and other obstructions. Because 802.11a and 802.11b utilise different frequencies, the two technologies are incompatible with each other. Some vendors offer hybrid 802.11a/b network gear, but these products simply implement the two standards side by side.

• Pros of 802.11a - fastest maximum speed; supports more simultaneous users; regulated frequencies prevent signal interference from other devices.

• Cons of 802.11a - highest cost; shorter range signal that is more easily obstructed.

Standard 802.11g In 2002 and 2003, WLAN products supporting a new standard called 802.11g began to appear on the scene. 802.11g attempts to combine the best of both 802.11a and 802.11b. 802.11g supports bandwidth up to 54 Mbps, and it uses the 2.4 GHz frequency for greater range. 802.11g is backwards compatible with 802.11b, meaning that 802.11g access points will work with 802.11b wireless network adapters and vice versa.

• Pros of 802.11g - fastest maximum speed; supports more simultaneous users; signal range is best and is not easily obstructed.

• Cons of 802.11g - costs more than 802.11b; appliances may interfere on the unregulated signal frequency.

Standard 802.11p WAVE WAVE- Wireless Access for Vehicular Environments defines enhancements to 802.11 required to support Intelligent Transportation Systems (ITS) applications. This includes data exchange between high-speed vehicles and between these vehicles and the roadside infrastructure in the licensed ITS band of 5.9 GHz (5.85-5.925 GHz). 802.11p will be used as the groundwork for DSRC (Dedicated Short Range Communications), a US Department of Transportation project – which will be emulated elsewhere - looking at vehicle- based communication networks, particularly for applications such as toll collection, vehicle safety services, and commerce transactions via cars. The ultimate vision is a nationwide network that enables communications between vehicles and roadside access points or other vehicles. The work builds on its predecessor, ASTN a2213-O3. Standard Status: The 802.11p Task Group is still active. Per the official IEEE 802.11 Work Plan predictions the formal 802.11p standard is scheduled to be published in April 2008.



Wi-Fi Vs GSM and UMTS Some argue that Wi-Fi and related consumer technologies hold the key to replacing mobile telephone networks such as GSM or UMTS networks. Some obstacles to this happening in the near future are missing roaming and authentication features, the narrowness of the available spectrum and the limited range of Wi-Fi. Despite such problems, companies like Zyxel, SocketIP and Symbol Technologies are offering telephony platforms that use Wi-Fi transport. Many operators are now selling mobile internet products that link cellular wireless and Wi-Fi radio system in a more or less transparent way to take advantage of the benefits of both systems. Future wireless systems are expected to routinely switch between varieties of radio systems. The term 4G is occasionally used for Wi-Fi, the implication being that the bandwidth and capabilities offered are already greater than those promised by the 3G mobile telephone standards. The main difference between mobile system and Wi-Fi is that mobile system use licensed spectrum, and Wi-Fi is implemented in unlicensed bands. The economic basis for their implementation is therefore completely different. The success of Wi-Fi has made many people look to unlicensed spectrum as the future of wireless access, rather than spectrum licensed and controlled by large corporations. Today there are more and more Mobile operators that offer services around W-Lan. CeBIT 2004 featured WLAN as one of the most interesting trends in mobile communication. At the moment mobile operators work on packages which offer connections via GPRS, UMTS and WLAN. Connect Cards for Laptops which include both (GPRS and WLAN) techniques are already on the market. With UMA – Unlicensed Mobile Access – a standard for GSM, WLAN and Bluetooth transmission – has already been set up. Interesting to note that UMTS standards were not considered.

3.2.1.2.2. WIRELESS PAN

Wireless Personal Area Networks, or PANs, like Bluetooth were initially aimed at cable replacements. Since then, the concept of the truly personal network has emerged. BLUETOOTH Bluetooth is an industrial specification for wireless personal area networks. Bluetooth likewise was intended to unify different technologies like computers and mobile phones. Bluetooth provides a way to connect and exchange information between devices like personal digital assistants (PDA’s), mobile phones, laptops, PCs, printers and digital cameras via a secure, low-cost, globally available short range radio frequency. Bluetooth lets these devices talk to each other when they come in range, even if they're not in the same room, as long as they are within 10 metres. It can be used to wirelessly connect peripherals to computers, or to have PDA’s communicated with other nearby PDA’s or computers. Mobile Phones with integrated Bluetooth technology have also been sold in large numbers, and are able to connect to computers, PDA’s and, specifically, to hands-free devices.



The standard includes support for more powerful longer-range devices suitable for constructing a wireless LAN. Bluetooth connection is free of charge, no matter how much data has been transferred. WIMEDIA/UWB 802.15.3 is structured to offer an extremely wide bandwidth over a much more limited area. It is for this reason that 802.15.3 is classified as an 'ultra wideband' wireless technology, as opposed to generic Wi-Fi. Not only is UWB capable of shuttling multimedia-heavy data at speeds in excess of 100M bits/sec, but it is also more capable than Wi-Fi when it comes to penetrating walls and physical barriers, at least over its short-distance transmission area. The data rates vary among different wireless alternatives (802.11b vs. 802.11g vs. UWB and so on) because of the assigned frequency on which these signals travel, the power requirements, and the techniques used to transfer information. For example, Bluetooth transmits on the same frequency as 802.11 systems (2.4GHz), but relies on much lower power requirements than Wi-Fi, so the range and overall speeds are limited. (We might add that there are plans in the works to unveil a 100 Mbps version of 802.11 at some point, but back to 802.15.3 and UWB!) Since UWB is restricted when it comes to longer-range wireless communications, initial uses will be confined to consumer entertainment (wireless stereos and high-definition television), automotive collision systems, medical imaging systems, construction applications (ground-penetrating radar), law enforcement applications (peering through buildings and walls), and peer-to-peer networking. But, UWB is not the only personal area networking (PAN) game in town. There is also a technology called ZigBee (802.15.4), which utilizes a variety of licensed and unlicensed bands worldwide, operates on extremely low power, and is positioned for control and remote management applications. Possible Applications Due to the extremely low emission levels, UWB systems tend to be short-range. However, due to the short duration of the UWB pulses, extremely high data rates are possible, and data rate can be readily traded for range by simply scaling the number of pulses per data bit. Conventional OFDM technology can also be used subject to the minimum bandwidth requirement of the regulations. High data rate UWB can enable wireless monitors, the efficient transfer of data from digital camcorders, wireless printing of digital pictures from a camera without the need for an intervening personal computer, and the transfer of files among cell phone handsets and other handheld devices like personal digital audio and video players. UWB also has the potential to enable "see-through-the-wall" imaging technology and high-precision time-of-arrival-based localization approaches. [3] and [4] ZIGBEE ZigBee is a low data rate, two-way standard for home automation and data networks. The standard originates from the Firefly Working Group and provides a specification for up to 254 nodes including one master, managed from a single remote control. Real usage examples of ZigBee includes home automation tasks such as turning lights on,



turn up the heat, setting the home security system, or starting the VCR. With ZigBee all these tasks can be done from anywhere in the home at the touch of a button. ZigBee also allows for dial-in access via the Internet for automation control. The ZigBee standard uses small very low-power devices to connect together to form a wireless control web. A ZigBee network is capable of supporting up to 254 client nodes plus one full functional device (master). ZigBee protocol is optimized for very long battery life measured in months to years from inexpensive, off-the-shelf non-rechargeable batteries, and can control lighting, air conditioning and heating, smoke and fire alarms, and other security devices. The standard supports 2.4 GHz (worldwide), 868 MHz (Europe) and 915 MHz (Americas) unlicensed radio bands with range up to 75 meters.

Source: www.ieee.org

Figure 9 – Possible communication protocols

3.2.1.1. SPECIFIC COMMUNICATION STANDARDS

DSRC - Dedicated Short-Range Communications A number of complementary standards are being developed specifically to support short-range vehicle-to-roadside, roadside-to-vehicle, and vehicle-to-vehicle communications. Of particular interest are Dedicated Short-Range Communications (DSRC) and a new family of standards termed Wireless Access in Vehicular Environments (WAVE). Both are being developed by the Institute of Electrical and Electronics Engineers (IEEE). The Dedicated Short-Range Communications (DSRC) effort, originally sponsored by the U.S. DOT and later migrated to the IEEE Standard Development Organization, is a derivative of the IEEE 802.11 family of standards. DSRC technology uses industry- standard IEEE 802.11a components, thereby leveraging a wider market for the base technology. The 802.11 version will be called 802.11p. The proposed standards upon which DSRC will be based are expected to be promulgated by mid-2006 to 2007. Equipment based on the proposed standard was

SHO

RT

<

R

AN

GE

>

LON

G

LOW < ACTUAL THROUGHPUT > HIGH

TEXT INTERNET/AUDIO COMPRESSEDVIDEO

MULTI-CHANNELDIGITAL VIDEO

Bluetooth1

Bluetooth 2

ZigBee

802.11b

802.11a/HL2 & 802.11g

802.15.3/WIMEDIA

SHO

RT

<

R

AN

GE

>

LON

G

LOW < ACTUAL THROUGHPUT > HIGH

TEXT INTERNET/AUDIO COMPRESSEDVIDEO

MULTI-CHANNELDIGITAL VIDEO

Bluetooth1

Bluetooth 2

ZigBee

802.11b

802.11a/HL2 & 802.11g

802.15.3/WIMEDIA



demonstrated at the 2005 ITS World Congress in San Francisco, and a consortium of toll operators is currently working on prototype equipment and demonstration programs. According to the DSRC Interoperability Consortium, the technology is about five years from deployment.

Frequency range 5.855-5.925 MHz

Data Rate 6-27 Mbps

Power Output 18dBm

Channel Bandwidth 10MHz

Channel Switch time <=2us

Transmit frequency stability 10ppm

Transmit Spectral Mask FCC to Class C

Safety Message Protocol Support IEEE 1609 WAVE Short Message

External Interface Ethernet (RJ-45)

Internet Protocol Support IPv6

Input Power +12VDC @ 3.25 Watts.

Operating and storage temperatures -10 to +70 deg C

Table 3: DRSC 5.9GHz prototype attributes

The DSRC standard was designed to transmit messages in a short period of time. In doing so, the standard attempts to achieve the following performance levels: low latency; short to medium range; high data rate; and directional and omnidirectional frequency capability. Based on the FCC-assigned frequency and bandwidth 5.9 MHz band (specifically 5.850 to 5.925 MHz), the standard will support:

• 10 channels.

• Middle channel is a control channel established to listen to announcements (for two-way exchange the channel will announce where the reply will broadcast).

• Two public safety channels in upper portion of the frequency band.

• Lower channels are medium powered channels that are shared among all uses (vehicle to vehicle and roadside to vehicle) for commercial applications such as map updates and large files.

• Lowest channel will have the highest availability and lowest delay, for emergency situations such as crash avoidance.

• Highest channel contains a power level consistent with traffic signal priority (TSP) and intersection collision avoidance technology applications.

The DSRC Task Group is developing the IEEE 802.11p standard, which addresses the wireless signal (physical layer) and access control. The associated network and data layers of the interface protocol will be addressed by IEEE 1609 (the WAVE family of



standards: WAVE Management, Channel Management, and Resource Manager). Security standards are being developed under IEEE 1609.2. [5]

CAN – Controller Area Network CAN (Controller Area Network) is a serial bus system, which was originally developed for automotive applications in the early 1980's. The CAN protocol was internationally standardized in 1993 as ISO 11898-1 and comprises the data link layer of the seven layer ISO/OSI reference model. CAN, which is by now available from around 40 semiconductor manufacturers in hardware, provides two communication services: the sending of a message (data frame transmission) and the requesting of a message (remote transmission request, RTR). All other services such as error signalling, automatic re-transmission of erroneous frames are user-transparent, which means the CAN chip automatically performs these services. CAN provides the following:

• a multi-master hierarchy, which allows building intelligent and redundant systems. If one network node is defect the network is still able to operate.

• broadcast communication. A sender of information transmits to all devices on the bus. All receiving devices read the message and then decide if it is relevant to them. This guarantees data integrity as all devices in the system use the same information.

• sophisticated error detecting mechanisms and re-transmission of faulty messages. This also guarantees data integrity.

The CAN protocol is an international standard defined in the ISO 11898. Beside the CAN protocol itself the conformance test for the CAN protocol is defined in the ISO 16845, which guarantees the interchange ability of the CAN chips. CAN is based on the “broadcast communication mechanism”, which is based on a message-oriented transmission protocol. It defines message contents rather than stations and station addresses. Every message has a message identifier, which is unique within the whole network since it defines content and also the priority of the message. This is important when several stations compete for bus access (bus arbitration). As a result of the content-oriented addressing scheme a high degree of system and configuration flexibility is achieved. It is easy to add stations to an existing CAN network without making any hardware or software modifications to the present stations as long as the new stations are purely receivers. This allows for a modular concept and also permits the reception of multiple data and the synchronization of distributed processes. Also, data transmission is not based on the availability of specific types of stations, which allows simple servicing and upgrading of the network.



Figure 10: Principles of data exchange. Source: http://www.can-cia.org/can/

Detecting and signalling errors Unlike other bus systems, the CAN protocol does not use acknowledgement messages but instead signals errors immediately as they occur. For error detection the CAN protocol implements three mechanisms at the message level:

• Cyclic Redundancy Check (CRC): The CRC safeguards the information in the frame by adding a frame check sequence (FCS) at the transmission end. At the receiver this FCS is re-computed and tested against the received FCS. If they do not match, there has been a CRC error.

• Frame check: This mechanism verifies the structure of the transmitted frame by checking the bit fields against the fixed format and the frame size. Errors detected by frame checks are designated "format errors".

• ACK errors: Receivers of a message acknowledge the received frames. If the transmitter does not receive an acknowledgement an ACK error is indicated.

The CAN protocol also implements two mechanisms for error detection at the bit level:

• Monitoring: The ability of the transmitter to detect errors is based on the monitoring of bus signals. Each station that transmits also observes the bus level and thus detects differences between the bit sent and the bit received. This permits reliable detection of global errors and errors local to the transmitter.

• Bit stuffing: The coding of the individual bits is tested at bit level. The bit representation used by CAN is "Non Return to Zero (NRZ)" coding. The synchronization edges are generated by means of bit stuffing. That means after five consecutive equal bits the transmitter inserts a stuff bit into the bit stream. This stuff bit has a complementary value, which is removed by the receivers.

Real-time data transmission In real-time processing the urgency of messages to be exchanged over the network can differ greatly: a rapidly changing dimension, e.g. engine load, has to be transmitted



more frequently and therefore with less delays than other dimensions, e.g. engine temperature. Bus access conflicts are resolved by bit-wise arbitration of the identifiers involved by each station observing the bus level bit for bit. Transmission requests are handled in order of their importance for the system as a whole. This proves especially advantageous in overload situations. Since bus access is prioritized on the basis of the messages, it is possible to guarantee low individual latency times in real-time systems. CAN standardization The CAN protocol specification is standardized by the International Organization of Standardization (ISO) headquartered in Geneve (Switzerland). The ISO 11898 document is under review and will be published in different parts. Besides these basic specifications, there are several international activities in official standardization bodies and non-profit trade associations regarding higher-layer protocols for CAN networks. Some of these specifications are very application-specific while others are more generic. In automotive applications, OSEK-COM and OSEK-NM are going to be standardized within ISO 17356. For truck/trailer communication ISO has developed the 11992 standard, which is based on the J1939 application profile. The SAE J1939-71 application profile defines the CAN-based in-vehicle communication in trucks and buses. [6]

CALM – Continuous Air interface for Long and Medium distance Due to the ever increasing needs of road safety and sustainable mobility, a level of communication is needed that in the past did not exist. The result is that new standards in automotive communications have been designed in the last several years. CALM is an acronym for Continuous Air interface for Long and Medium distance. The Wide Area Communications standard, ISO TC204/WG16, has produced a series of draft standards known as CALM. The scope of CALM it to provide a standardised set of air interface protocols and parameters for medium and long range, high-speed ITS communication using one or more of several media, with multi-point and networking protocols and upper layer protocols. Therefore CALM is a platform that separates applications from media, allows choice between media and networking/handover between media. It is recognised that media will change over time, so CALM is so structured to be able to accept new media, while other media will fall out of use. CALM supports continuous communications, client/server and peer-peer modes, user transparent networking, many communications medium through network layer, handover spanning multiple media, media providers and beacons. The media defined in the current phase of CALM are:

• Cellular Systems: 2/2.5G and 3G.

• Wireless LAN in 5GHz.

• IEEE 802.11p (WAVE).

• Mobile Wireless Broadband.



• Wireless systems in 60GHz range (Millimetre).

• Infrared Communication. CALM has the support of Internet services and Intelligent Transportation Systems (ITS) applications, media independent through DSRC L7. It has the cooperation of IEEE 802.11p and P1609 - Wireless Access in the Vehicular Environment (WAVE). CALM defines 5 communication scenarios:

• Vehicle to Infrastructure (V2I) Non-IPv6 communications.

• V2I/Vehicle to Vehicle (V2V) Local IPv6.

• V2I MIPv6.

• V2I NEMO.

• V2V Non-Ipv6. CALM System Architecture:

IMEInterface Manager

ISO 24102

NMENetworkManager

ISO 21210

CMECALM

Manager

ISO 21210

NETWORK INTERFACERouting and Media Switching based on mobile IPv6

ISO 21210

Non-CALM-awareISO 15628-basedAPPLICATIONS

Convergence LayerPart of ISO 15628

ISO 21210

CALM-AwareAPPLICATIONS

TCP/UDP/…INTERNET

STANDARDSSAP

SAP SAP

SAP

SAP

SAP

SAP

Non-CALM-awareIP (Internet)

APPLICATIONS

Convergence LayerIP socket/ISO 21210

SAPSAP

SAP

ApplicationManagementISO 24101

UM

TS

GPR

S

ED

GE

2G /3G CellManager

ISO 21212/3ISO 21218

SAPU

MT

S

GPR

S

ED

GE

2G /3G CellManager

ISO 21212/3

UM

TS

GPR

S

ED

GE

2G /3G CellManager

ISO 21212/3ISO 21218

SAP

SAP

SAP

… IR-B

IR-A

ISO 21214IR

Manager

ISO 21218

SAP

… IR-B

IR-A

ISO 21214IR

Manager

… IR-B

IR-A

ISO 21214IR

Manager

ISO 21218

… WiFi

M5

ISO 21215W-LAN

Manager

SAP

ISO 21218

… WiFi

M5

ISO 21215W-LAN

Manager

SAP

… WiFi

M5

ISO 21215W-LAN

Manager

SAP

ISO 21218

RA

DA

R

MM

-J

MM

-E

ISO 21216MillimeterManager

SAP

ISO 21218

RA

DA

R

MM

-J

MM

-E


SAP

RA

DA

R

MM

-J

MM

-E


SAP

ISO 21218

K-D

SRC

J-DSR

C

C-D

SRC

DSRC ISO15628

ISO 24103

SAP

K-D

SRC

J-DSR

C

C-D

SRC

DSRC ISO15628

ISO 24103

SAP

ISO 21218

…

HC

-SDM

A

WiM

AX

ISO 24xxxW-MAN

Manager

SAP

ISO 21218

…

HC

-SDM

A

WiM

AX

ISO 24xxxW-MAN

Manager

SAP

…

HC

-SDM

A

WiM

AX

ISO 24xxxW-MAN

Manager

SAP

ISO 21218

… DA

B

GPS

ISO 24xxxBroadcastManager

SAP

ISO 21218

… DA

B

GPS


SAP

… DA

B

GPS


SAP

ISO 21218

…

W-U

SB

BlueT

ISO 24xxxPAN

Manager

SAP

ISO 21218

…

W-U

SB

BlueT

ISO 24xxxPAN

Manager

SAP

…

W-U

SB

BlueT

ISO 24xxxPAN

Manager

SAP

ISO 21218

Ether

AM

IC

CA

N

ISO 24xxxWired

Manager

SAP

ISO 21218

Ether

AM

IC

CA

N

ISO 24xxxWired

Manager

SAP

Ether

AM

IC

CA

N

ISO 24xxxWired

Manager

SAP

ISO 21218

SAPSAPSAP

CME

Registration ofIngress/Egress

InterfacesSAP

SAP

CALM Media External Media CALM Network 21218 = LSAP Applications

SAP SAPData SAP Management SAP Source: http://www.can-cia.org/can/

Figure 11: CALM System Architecture

Summarizing, the set of standards comprises about 20 separate work items. The backbone is the newest generation of Internet Protocol (Mobile IPv6), and there are several media such as 2G/3G mobile phone, 5GHz Wireless LAN, 60GHz Millimetre wave and DSRC being developed in various stages.



CALM related standards: • ISO/CD 21210-1: CALM Networking Protocols – Part 1: CALM Networking for

Internet Connectivity. Status of the standard: Approved CD being enhanced before DIS ballot.

• ISO/CD 21210-2: CALM Networking Protocols – Part 2: CALM Networking for Direct Mode Connectivity. Status of the standard: Approved CD being enhanced before DIS ballot.

• ISO/CD 21212: CALM – 2G Celullar Systems. Status of the standard: CD Approved in DIS ballot.

• ISO/CD 21213: CALM – 3G Celullar Systems. Status of the standard: CD Approved in DIS ballot.

• ISO/DIS 21214: CALM – Infrared System. This protocol determines the air interface using infra-red systems at 820 nm to 1 010 nm. It provides protocols and parameters for medium-range, medium- to high-speed wireless communications in the ITS sector using infra-red systems. Such links are required for quasi-continuous, prolonged or short communications

• between vehicles and the roadside.

• between vehicles.

• between mobile equipment and fixed infrastructure points. Wherever practicable, ISO 21214:2006 has been developed by reference to suitable extant International Standards, adopted by selection. Required regional variations are provided. Due account is given to, and use made of, any relevant parts of appropriate communications systems, such as global positioning systems (GPS), digital audio broadcasting (DAB), digital video broadcasting (DVB), radio local area networks (RLANs), digital data broadcasting (DDB), TETRA, FM subcarrier, mobile broadband systems (MBS, W-ATM), internet protocols, and dedicated short range communication (DSRC). ISO 21214:2006

• supports data rates of 1 Mbit/s up to 128 Mbit/s (it may support higher data rates).

• supports vehicle speeds up to a minimum of 200 km/h (closing speeds could be double this value).

• defines or references environmental parameters relevant to link operation.

• supports communication distances up to 100 m (it may support longer communication distances of 300 m to 1 000 m).

• supports latencies and communication delays in the order of milliseconds.



• is compliant to regional/national regulatory parameters.

• may support other regional/national parameters as applicable. Application-specific requirements are outside the scope of ISO 21214:2006. These requirements will be defined in the CALM management and upper layer standards and in application standards. Application-specific upper layers are not included in ISO 21214:2006, but will be driven by application standards (which may not be technology specific).

• ISO/DIS 21215: CALM - Microwaves via 5GHz. CALM M5 uses the 5 GHz spectrum adjacent to DSRC. IEEE 802.11p has developed a vehicle-optimised version of the well-known WiFi standards under the name Wireless Access in Vehicular Environments (WAVE). This development is done in cooperation with CALM. A superset of this is called CALM M5 (ISO 21215), and adds extra functionality such as spectrum agility, multi-channel / multi-antenna operation and coexistence with current DSRC systems. The European Frequency Allocation prepared:

• 20 MHz for Pan-European time-critical Safety.

• 40 MHz for less time-critical safety applications.

• 200 MHz unlicensed spectrum for other applications. Status of the standard: Developed linked with the development of IEEE802.11P. It is actually largely developed but the standard is delayed due to the delay of WAVE. WIP SRD completed by ETSI and 20MHz band allocation requested from CEPT.

• ISO/AWI 21216: CALM-MM. Medium and long range, high speed, air interface parameters and protocols for boradcast, point-point, vehicle-vehicle, and vehicle-point communications in the ITS Sector using MILLIMETRE WAVE MOCROWAVE COMMUNICATIONS, including specifications for Master/Slave and Peer to Peer Communications. CALM via 60Ghz. Status of the standard: Work in Progress. SRD largely developed (final mods) after which it will go to CEPT for band allocation 62-63 GHz (2 GHz allocation)

• ISO/CD 21217: CALM – Architecture. Status of the standard: Approved CD en route for DIS ballot.

• ISO 21218: CALM – Lower Layer SAPs. Status of the standard: Work in progress.

• ISO 24101: CALM – Application Manager. Status of the standard: Work in progress.

• ISO 24102: CALM – Interface Manager. Status of the standard: Work in progress.

• ISO 24103: CALM – MAIL. Status of the standard: Work in progress.



• ISO 25111: CALM via Mobile Wireless Broadband – IEEE 802.20. Status of the standard: Work in progress.

• ISO 25112: CALM via Mobile Wireless Broadband – IEEE 802.16. Status of the standard: Work in progress.

• ISO 25113: CALM via Mobile Wireless Broadband – HC-SDMA. Status of the standard: Work in progress.

In the future, CALM may become the general purpose communication medium and also be used in safety applications. CALM provides universal access through a number of complimentary media and links them with modern Internet protocols, adaptation layers, and management entities. In addition, multi-channel communication units will enable vehicles to talk to other nearby vehicles or to the roadside infrastructure. The main technology development project is called Cooperative Vehicle-Infrastructure System (CVIS) [7], but also SafeSpot [8], Prevent [9], Coopers [10] and others have adopted CALM as a communications framework. [11], [12], [13], [14], [15], [16]

3.2.2. METHODOLOGY TO IDENTIFY THE REQUIREMENTS

The description of the methodology followed for the identification of the requirements related to the communication part of TRACKSS operational framework described in this document was to, starting from a first proposal of such requirements, review it and accept comments in order to redefine those requirements that were considered by the expertise of the partners of the Consortium. In this way, after several reviewing of the requirements the result will be very closed to the functionalities demanded and the validation will be easier since the evaluators are involved in the process of definition of the requirements. The wide spectrum of the knowledge held by the different partners involved in TRACKSS project arises the possibility of proposing a communication protocol that could match every requirement or functionality in an environment as TRACKSS exposes, taking into account that all the roles inside this environment are met within the partnership Consortium. Taking advantage of the expertise of each one of the partners within the Consortium and following the methodology exposed, the result of the definition of the communication requirements can be considered like the best one in order to match, not only the functionalities but also the way to achieve them. Knowledge division Since the Consortium is formed by different partners related to different technological areas, this particular nature of each partner has been taken into consideration taking advantage of their particular know-how in order to reach the exact communication requirements in the best and optimal way possible. On one hand, the partners involved in communications as a general concept have described their knowledge in the “State of the art” part of this document, detailed above, and on the other hand, those partners involved with different sensors needed in



the TRACKSS solution proposal have offer their knowledge through a specific evaluation form sent out with this objective to them. This information was studied in detailed trying to cover all the specific functionalities that each of the products used in the market by the partners. Joined with the expertise proved by the other side of the partners in general communications, a first draft of the requirements concerning communications was released to these same partners for their review and comments. This first draft only contained a very general idea of what and how should the Communications Protocol fulfill all the requirements and functionalities for the partners and their different sensors with which they are working. Results of the evaluation form From this first release, every communication requirement was studied in detail by all the partners so all the needed requirements in order to offer the sensors actual functionalities and the new ones that could possible arise under TRACKSS perspective, were perfectly met. The result of new comments and reviews made by the partners was a new refinement of the old ones described in previous releases. This way, after several rounds of comments over the requirements for the Communication Protocol presented, a final version of these ones was published and validated by users and partners involved in this part. This methodology followed tried to define a correct creation of the interface and protocol of this communication field that is described as a key-part of the operational framework described here in this document. The following schema is the one sent out to the partners in order to gather all the different characteristics and details of each one of the sensors with they currently work.

Name of the sensor

Communication Properties

Type of data collection

Bidirectional dialog

Network Protocol (OSI Model)

Physical

Data Link

Network

Transport

Session

Presentation

Application



Other Communication Properties

…more???

Table 4: Sensor Communications Properties schema

To clarify the idea or subject of the evaluation form sent out to the partners, the following schema of architecture was included in it. This way, the partners could have a better idea of the results that were pretended by the part dealing with communications of the TRACKSS operational framework described in this document.

Figure 12: Initial communication architecture

The final conclusions that were gathered from the different comments from the partners were evaluated and validated by these ones and were put all together as part of the rest of the requirements that are described as part of the Annex A attached in this document.



4. VALIDATION OF THE REQUIREMENTS 4.1. METHODOLOGY

The validation process followed the same methodology used in D1.1 Requirements of the TRACKSS sensors. The validation form was adapted to consider the different types of requirements identified in this document (Annex A). Furthermore, the form was refined with the feedback from the validation performed in D1.1, and some questions were edited to make easier the process. The validation panel was formed once again by all the partners in the consortium, but this time each expert read and analysed all the requirements looking for possible problems, and proposing a list of solutions. In order to make easier the traceability of the defined requirements a system for uniquely identify them was proposed. An id, was created for each one of the types of framework requirements and each one of the different group of requirement being tackled. This way, each requirement has a unique id:

• Id. for KSM requirements and communication requirements

KSM Requirements K Communication Requirement C

Table 5: List of Framework requirements Ids.

• Id. for the kind of KSM requirements

Interoperability requirements I Communications requeriments C

Information processing requirements IP Relationship requeriments R

Data management requirements DM General features requirements GF

Scalability requirements S

Table 6: List of type of requirements Ids.

• Numeric Id. (0-99) Example: K_IP_01

4.2. RESULTS

The following table shows the different evolutions and versions of the requirement document (annex A). None of the experts approved the document in the first iteration, which helped to improve the quality of the requirements, not only from a formal point of view but also regarding the contents of the different requirement definitions.



Partner 1st iteration

Reqs after 1st

iter.

2nd iteration

Reqs after 2nd iter.

3rd iteration

Reqs after

3rd iter.

4th iteration

Reqs after 4th

iter.

ITACA X X X X

CITILOG X X

KTI X X

UNEW X X X X

BOSCH X X

DLR X X

INRETS X X

CDV X X

TRW X X X

LCPC X X

CRF

TRL

Table 7: Validation process



5. CONCLUSIONS This document relates the first approach to one of the key results of the project, the Knowledge Sharing Model. The discussions and brainstorming promoted to identify the different possible collaborations have helped the members of the consortium to understand the limits and benefits of the cooperative sensing framework. A list of requirements has been elaborated trying to consider, not only the particular problems and interests of the sensor developers involved in the project, but also a more general point of view, which should allow the easy adoption of TRACKSS philosophy by any interested third party. Last but not least, the requirements of the communication infrastructure have been tackled separately. As it has been explained, communications are not the objective of the project, but nevertheless they are a critical part of any cooperative activity. Without a good communication infrastructure, it will never be possible to share information or processes. By querying the partners in TRACKSS consortium and analysing the different possibilities available nowadays, the requirements for the communications of TRACKSS operational framework have been established. All in all, this document is the first step in the definition of the Knowledge Sharing Model. It will be the main input to work package 2 and will play a key role at the end of the project in the assessment of the level of completion of the progress objectives in relation to the provision of new knowledge sharing capabilities to sensors.



6. GLOSSARY • 3GPP: Third Generation Partnership Project. • 8PSK: 8-Phase-Shift-Keying. • AAS: Adaptive Antenna Systems. • ACK: Acknowledgment.

• AMPS: Advance Mobile Phone System. • AS: Airborne Sensor. • BWA: Broadband Wireles Association. • CALM: Continuous Air interface for Long and Medium distance. • CAN: Controller Area Network. • CeBIT: One of the world's most important computer expositions.

• CDMA2000: Code Division Multiple Access 2000. • CEPT: European Conference on Postal and Telecommunications Administrations.

• CDMAONE: Code Division Multiple Access ONE. • CI: Video camera for infrastructure applications. • CTS: Cooperative Transport Systems. • CV: Video camera for in-vehicle applications. • CRC: Cyclic Redundancy Check. • DAB: Digital Audio Broadcasting. • DDB: Digital Data Broadcasting. • DFM: Data Fusion Module. • DIS: Draft International Standard.

• DSL: Digital Subscriber Line. • DSRC: Dedicated Short-Range Communications. • DVB: Digital Video Broadcasting. • EDGE: Enhanced Data Rate for GSM Evolution. • ETSI: European Telecommunications Standards Institute. • FCS: Frame Check Sequence. • FEC: Forward Error Correction.

• FDMA: Frequency Division Multiple Access. • FFT: Fast Fourier Transform. • FLMTS: Future Land Mobile Telecommunications Services. • FM: Frequency Modulation. • GGSN: Gateway GPRS Support Node. • GMSK: Gaussian Minimum-Shift Keying. • GPRS: General Packet Radio Service.



• GPS: Global Positioning Systems. • GSM: Global System for Mobile Communication. • hARQ: hybrid-Automatic Retransmission Request. • HD: High Density.

• HS-DSCH: High Speed Downlink Shared Channel. • HSCSD: High Speed Circuit Switched Data Technology. • HSDPA: High Speed Downlink Packet Access. • IC: Road surface sensor for in-vehicle ice detection. • IEEE: Institute of Electrical and Electronics Engineers. • IL: In-road inductive loop sensor. • IP: Internet Protocol. • ISDN: Integrated Services Digital Network.

• ISO: International Standard Organitation. • ITS: Intelligent Transportation Systems. • ITU: International Telecommunication Union.

• KSM: Knowledge Sharing Model. • KSS: Knowledge Sharing Sensor. • LAN: Local Area Network. • LDPC: Low-Density Parity Check. • LS: Laser scanner for infrastructure applications. • MAC: Media Access Controller. • MAN: Metropolitan Area Network. • MBS: Mobile Broadband Systems. • MBWA: Mobile Broadband Wireless Access. • MIMO: Multiple Input Multiple Outputs. • MIMO-AAS: Multiple Input Multiple Outputs – Adaptive Antenna Systems. • NLOS: Non-Line Of Sight. • NRZ: Non Return to Zero. • NTT: Nippon Telegraph & Telephone.

• OFDMA: Orthogonal Frequency Division Multiple Access.

• PAN: Personal-Area Network. • PC: Personal Computer. • PDA: Personal Digital Assistant. • PMMW: Passive mm wave sensor for in-vehicle pedestrian detection. • POTS: Plain Old Telephone Service. • PTM: Point-to-multipoint. • PTP: Point-to-point.



• QoS: Quality of Service. • RAN: Rural Area Network. • RLAN: Radio Local Area Networks. • RTR: Remote Transmission Request. • SAP: Service Access Point. • SGSN: Serving GPRS Support Node. • SI: Smart dust sensor for infrastructure applications. • SMS: Short Messaging Service. • SOFDMA: Scalable Orthogonal Frequency Division Multiple Access. • SV: Smart dust sensor for in-vehicle applications • TACS: Total Access Communication System. • TETRA: Terrestrial Trunked Radio.

• TDMA: Time Division Multiple. • TSP: Traffic Signal Priority. • UMA: Unlicensed Mobile Access. • UMTS: Universal Mobile Telephone Standard. • UWB: Ultra-Wideband. • V2V: Vehicle to Vehicle. • VCR: Video Cassette Recorder. • VoIP: Voice over IP. • VI: Vehicle identification sensor for in-vehicle applications. • W-CDMA: Wideband-Code Division Multiple Access.

• W-ATM: Wireless Asynchronous Transfer Mode.

• WAVE: Wireless Access in Vehicular Environments. • Wi-Fi: Wireless Fidelity.

• WiMAX: Wireless Interoperability for Microwave Access. • WLAN: Wireless Local Area Network.



7. BIBLIOGRAPHY [1] http://www.wimaxforum.org/ [2] http://www.wimaxforum.org/technology/faq [3] http://en.wikipedia.org/wiki/WiMAX [4] Strategic Analysis of North American In-Vehicle Wireless Network Technologies and Protocols. Auth. Frost & Sullivan [5] http://www.fta.dot.gov/documents/SOAFinalReportVer1_1_3.pdf [6] http://www.can-cia.org/can/ [7] CVIS - Co-operative Vehicle-Infrastructure Systems. IST-2004-027293. http://www.cvis-project.org [8] SAFESPOT – Co-operative Systems for Road Safety “Smart Vehicles on Smart Roads”. IST-2004-026963. http://www.safespot-eu.org [9] PREVENT - Preventive and active safety applications contribute to the road safety goals on European roads. IST-2002-507075. http://www.prevent-ip.org [10] COOPERS - Preventive and active safety applications contribute to the road safety goals on European roads. IST-026814. [11] European Commission, DG INFSO “INFSO G4/JJ D(2006) 701211” [12] Gregory S. Bickel. “Inter/Intra-Vehicle Wireless Communication” [13] Hans-Joachim Fischer. “Technical developments in standarisation” I14] International Organisation for Standardisation: www.iso.org” [15] ETSI: TG 37:Intelligent Transport Systems “Standards and Spectrum” [16] ITS Norway: “Directory & Handbook 2005-2006” [17] D1.1 Requirements of the TRACKSS sensors. TRACKSS, 2006.



Annex A – LIST OF REQUIREMENTS A.1. INTEROPERABILITY REQUIREMENTS

Interoperability requirements

K_I_01 TRACKSS Framework shall promote interoperability and fusion of disparate sensor data.

K_I_02 TRACKSS Framework shall be designed to support a wide range of sensors and allow data exchange across different types:

Sensors on infrastructure: super loops, laser scanners, smart cameras, smart dust, airborne sensor,…

Sensors on-board: ice detector, CMOS camera, smart dust, wave advanced pedestrian detectors, advanced vehicle identification, …

K_I_03 TRACKSS Framework shall be synchronized with a common clock (e.g. high accuracy atomic clock) at an application level.

K_I_04 TRACKSS Framework shall provide association mechanisms taking into account sensors location.



A.2. INFORMATION PROCESSING REQUIREMENTS

Information processing requirements

K_IP_01 Data shall be processed before sending it to other KSSs or CTSs.

K_IP_02 KSM shall provide basic common sensor function for data processing.

K_IP_03 KSM should be able to detect non coherent measures taking into account a pre-established range of values.

K_IP_04 The information provided by the KSM shall be complete.

K_IP_05 The information provided by the KSM shall be accurate.

K_IP_06 KSM shall be able to process information coming from different kind of KSSs located in far away places within the communications network range.

K_IP_07 KSM shall be able to analyse the information in several forms, consistency and upsets, logical constraints, range errors, etc. (Data plausibility).

K_IP_08 KSM shall be able to produce elaborated, filtered information by means of data completion techniques, data editing techniques, sensor failure identification and discard sample, etc. (Data editing).

K_IP_09 KSM shall be able to produce high level information based on low level gathered data.

K_IP_10 KSM should be able to detect non coherent measures by analysing data coming from other KSS.



A.3. DATA MANAGEMENT REQUIREMENTS

Data management requirements

K_DM_01 KSM shall be capable of capturing and describing data.

K_DM_02 KSM shall be able to consider the accuracy of the data provided by other KSSs and improve it through data fusion techniques.

K_DM_03 One model for all KSSs shall be designed.

K_DM_04 KSM should allow the rapid parsing and segmentation of sensor data.

K_DM_05 KSM should allow sensor data discovery.

K_DM_06 KSM should allow discovery of metadata entry.

K_DM_07 KSM should allow self validation.

K_DM_08 Data aggregation: Additional information shall be added to support more detailed perception of the scenario.

K_DM_09 KSM shall be able to provide a well structured and defined representation of a sensor with sharing capabilities.

K_DM_10 KSM, in the context of sharing information, will define at least: the information to be shared (measure), the kind of information (unit), the valid values (maximum and minimum allowed) and the reliability of the results (accuracy).

K_DM_11 The information exchanged among KSSs shall be coherent.

K_DM_12 Knowledge database shall enable KSM, for example, to identify and classify an object.



A.4. SCALABILITY REQUIREMENTS

Scalability requirements

K_S_01 The whole system (TRACKSS Framework, KSSs and CTSs) shall be easily scalable.

K_S_02 No modifications shall be required on KSSs when new sensors are introduced.

K_S_03 TRACKSS Framework shall facilitate registration of different sensors and the correlations among them.

K_S_04 TRACKSS Framework shall be adaptable to new sensors and operational scenarios.



A.5. COMMUNICATIONS REQUIREMENTS

Communication Requirements

K_C_01 The communication network used by TRACKSS communication platform must be transparent for the final user.

K_C_02 TRACKSS communication platform shall be able to support wireless and wired communications depending on the device communication capabilities.

K_C_03 TRACKSS communication platform must support sensor-to-sensor communications.

K_C_04 TRACKSS communication platform must support sensor-to- CTS communications.

K_C_05 TRACKSS communication platform must support CTS-to-CTS communications.

K_C_06 TRACKSS API should follow an open standard of distributed programming, such as SOAP, CORBA, RMI, EJBs…

K_C_07 TRACKSS communication platform must facilitate real time, minimum latency for data exchange.

K_C_08 TRACKSS communication platform shall be able to manage the bandwidth between the existing links.(It should be able to manage network congestion resulting from dense network deployment).

K_C_09 Systems in TRACKSS communication platform shall be developed to minimize traffic loads and ensuring network reliability.

K_C_10 TRACKSS communication platform shall be able to assure the network security, providing means to avoid intrusion, mainly by means of encryption and authentication.

K_C_11 TRACKSS communication platform shall take into account the topology of a possible wireless sensor network. (Changes in the network topology: the variability of network topologies due to node failures, introduction of additional nodes, variations in sensor location, changes to cluster allocations in response to network demands, requires the adaptability of underlying network structures and operations. Advanced communication protocols are required to support high level services and real-time operation, adapting rapidly to extreme changes in network conditions) .

K_C_12 TRACKSS sensors must use an unique communication interface (API) in order to communicate in TRACKSS framework.



K_C_13 TRACKSS communication platform shall be able to use fully digitalized packetized information based on a universal high level standard such the HTTP Protocol (over TCP/IP) or Streaming protocols (over UDP/IP for real time or multimedia applications).

K_C_14 TRACKSS communication platform must provide a mechanism for detecting and recovering from possible communication errors (channel errors, delays, packet losses…).

K_C_15 TRACKSS communication protocol should allow an initialization mechanism for any sensor. This mechanism should allow the initialization on demand.

K_C_16 TRACKSS communication protocol should allow to provide information related to its functionality, type of data collection and format used by sensors on demand.

K_C_17 TRACKSS sensors should be able to broadcast processed information to TRACKSS communication platform.

K_C_18 TRACKSS sensors should have an unique identifier.

K_C_19 TRACKSS communication protocol should allow to send the status of the device on demand. It should have different values: (BUSY, OK, ERROR).

K_C_20 TRACKSS communication protocol should allow configuration management on demand.

K_C_21 TRACKSS communication platform must enable a confirmation mechanism to assure that the information is sent from the origin to destination correctly.



A.6. RELATIONSHIP REQUIREMENTS

Relationship requirements

K_R_01 KSSs through the KSM should be able to choose the suitable KSSs for sharing data with them.

K_R_02 The relationships within sensors must be established.

K_R_03 TRACKSS Framework shall be able to identify the different KSSs that are part of the system.

K_R_04 Systems to be developed from the TRACKSS Framework shall produce their output within a time that is sufficient to be useful.

K_R_05 KSM shall be able to provide facilities (for initiating, terminating, joining, leaving) to enable cooperation.



A.7. GENERAL FEATURES REQUIREMENTS

General features requirements

K_GF_01 KSM should be application independent. It must make no assumption about how data will be used.

K_GF_02 KSM design shall focus on the collection of observed data or events captured on sensors.

K_GF_03 KSSs through the KSM should provide data with time stamped to allow cooperation between them.

K_GF_04 Each sensor type shall be capable of collecting different types of data and handling different types of input and output data and ignoring any data not relevant to it.

K_GF_05 TRACKSS Framework shall be able to define a complete model of the cooperative approach, instantiating all the objects that participate in the framework and monitoring their dynamic behaviour.

K_GF_06 KSM shall provide configuration capabilities such as selecting data to be captured, which KSSs provide information, which kind of information, and so on.

K_GF_07 TRACKSS Framework shall require all systems developed from it to comply with current European and National laws concerning data security and protection of individual privacy.

K_GF_08 KSM shall be able to provide functionality such that the quality of information content is continuous and consistent.

K_GF_09 The status of the KSSs involved in TRACKSS should be able to be monitored in real time.

K_GF_10 TRACKSS Framework shall be able to be initialized, loading the pre-existing set of parameters of all the sensors under its control.

K_GF_11 TRACKSS Framework shall be configurable, customising both the sharing behaviour and the interaction between KSSs to customize it to a specific field of application.

K_GF_12 The different sensors and the CTSs shall be able to be enabled and disabled.



Annex B – VALIDATION FORM

SENSORS REQUIREMENTS VALIDATION FORM VALIDATION PANEL SECTION

Validation Expert Curriculum

Expert Name

Organisation Name

Expertise

Requirements Document

Document Version 1st Iteration Final Version YES/NO

Requirements Checklist


Q1 Are the requirements uniquely identified?

Q2 Are specialised terms defined in the glossary?

Q3 Does a requirement stand on its own? i.e. you do not have to examine other requirements to understand what it means

Q4 Do individual requirements show any inconsistency?

Q5 Are there any redundancies in the requirements?

Q6 Are there any contradictions in the requirements?

Q7 If the requirements make reference to any external resource, is it described elsewhere in the document?

Q8 Are the individual requirements correctly grouped?






























Communications requirements

Q1 Are the requirement uniquely identified?


Q3 Does a requirement stand on its own or do you have to examine other requirements to understand what it means?

Q4 Do individual requirements use the terms consistently?

Q5 Is the same service requested in different requirements?

Q6 Are there any contradictions in these requests?

Q7 If the requirements makes reference to some other facilities, are these described elsewhere in the document?

Q8 Are related requirements grouped together? If not, do they refer to each other?




Q3 Does a requirement stand on its own? i.e. you do not have to



examine other requirements to understand what it means















Main Issues

MI1 Requirements Clarification

MI2 Missing Information

MI3 Requirements conflict

MI4 Unrealistic requirements

General Issues

GI1 Understandability

GI2 Redundancy

GI3 Completeness

GI4 Ambiguity

GI5 Consistency

GI6 Organisation

GI7 Conformance to Standards

GI8 Traceability

Problem List

# Description



1

2

…

Agreed Actions

# Description

1

2

…

VALIDATION RESULTS

Iteration nb Document version

Is the document… Approved?

Iteration nb Document version

Is the document… Approved?

OPERATIONAL FRAMEWORK RESPONSIBLES SECTION

Answers to the Requirements Checklist


Q1

Q2

Q3

Q4

Q5

Q6

Q7

Q8


Q1

Q2

Q3

Q4

Q5

Q6

Q7

Q8




Q1

Q2

Q3

Q4

Q5

Q6

Q7

Q8


Q1

Q2

Q3

Q4

Q5

Q6

Q7

Q8

Communications requirements

Q1

Q2

Q3

Q4

Q5

Q6

Q7

Q8


Q1

Q2

Q3

Q4

Q5

Q6



Q7

Q8


Q1

Q2

Q3

Q4

Q5

Q6

Q7

Q8

Answers to the Main Issues

MI1

MI2

MI3

MI4

Answers to the General Issues

GI1

GI2

GI3

GI4

GI5

GI6

GI7

GI8

Answers to the Problem List

1

2

…

Answers to the Agreed Actions

1

2

…



Annex C – LIST OF OBSERVABLES C.1. IN-ROAD INDUCTIVE LOOP SENSOR

Observable Vehicle Detection

Observable type Event


Measure: Vehicle Detection Measure type or category: Detection Value: Vehicle Crossing over detection area Accuracy: 98% Hazard type: Run over, Very slow circulation during calibration

Observable Vehicle Classification

Observable type Measurement


Measure: Type of vehicle Measure type or category: Classification Value: truck, car, auto vans, bus Accuracy: 90% Data extraction method: Magnetic signature recognition

Observable Speed Measurement



Measure: Speed of vehicle Measure type or category: Classification Value: Different ranges Accuracy: 90% Data extraction method: Magnetic signature recognition



Observable Environmental state of conservation of the road



Measure: State of the loop in the road Measure type or category: Incident Value: Deformations in the road, broken loop Accuracy: 95% Data extraction method: Frequency oscillation and determined quantification

Observable Vehicle passing through two different loops



Measure: Same vehicle Measure type or category: Avoid double detection Value: Same vehicle in two lanes Accuracy: 95% Hazard type: Sensibility or frequency variation Data extraction method: Magnetic signature recognition and correlation

Observable Traffic Incident



Measure: Occupation time of the vehicle Measure type or category: Traffic Jam Detection Value: Frequency Accuracy: 95% Hazard type: Sensibility or frequency variation



C.2. LASER SCANNER

Observable Vehicle Detection



Measure: Vehicle Detection Measure type or category: Detection Value: Vehicle Crossing over detection area Accuracy: 98% Hazard type: Run over, Fast circulation during event, Overlap, Climatologic inclemency Data extraction method: Use of parametric tests, nonparametric, correlation, logistic regression and neuronal networks.




Measure: Type of vehicle Measure type or category: Classification Value: Different groups Accuracy: 90% Hazard type: Run over, Fast circulation during event, Overlap, Climatologic inclemency Data extraction method: Tree discrimination

Observable Traffic Incident



Measure: Occupation time of the vehicle Measure type or category: Traffic Jam Detection Value: Constant measurement from the laser scanner Accuracy: 95%



C.3. VIDEO CAMERA FOR INFRASTRUCTURE APPLICATIONS

Observable Bus position



If bus detected by selective detection system then it is tracked up to the stop line: Measure: Bus Position Measure type or category: Tracking / Computer Vision Value: distance in meters from the stop line. Accuracy: Accuracy is a function of the distance from the camera. Data extraction method: Image processing

Observable Bus stop notification



If bus tracked and is at its commercial stop (if there is one): Event: Bus at its commercial stop Measure type or category: Presence and stop detection / Computer Vision Data extraction method: Image processing

Observable Reliability Indicator



If bus detected by selective detection system then it is tracked up to the stop line: Measure: Effectiveness of the tracking during all the tracking (bus on tracking, bus lost) Measure type or category: Bus signature recognition / Computer Vision Value: bus on tracking, bus lost (eventually a percentage of recognition) Data extraction method: Image processing



Observable Stop line



If bus arrives to the stop line and passes through it: Event: Stop line notification Measure type or category: Line crossing / Computer Vision Data extraction method: Image processing

Observable Congestion Level



If bus detected by selective detection system then it is tracked up to the stop line: Measure: Congestion Level Between Bus and stop line Measure type or category: Computer Vision Analysis Value: 4 states (Below capacity – Fluid – Dense – Congested) Data extraction method: Image processing based on average speeds estimation

Observable Pedestrians



Motion detection inside a delimitated zone (pedestrian crossing) for pedestrians presence notification: Measure: Motion on the zone Measure type or category: Computer Vision Value: true or false Data extraction method: Image processing



Observable Speed



Vehicle speed given for each vehicle (pulse mode) Measure: instantaneous speed Measure type or category: Computer Vision Value: speed in Km/h Data extraction method: Image processing

Observable Classification



Vehicle classification based on vehicle length in 2 classes Measure: class of vehicles for each passed vehicle (pulse mode) Measure type or category: Computer Vision Value: C1 or C2 for personal vehicle or trucks Data extraction method: Image processing (vehicles length extraction)



C.4. SMART DUST SENSOR FOR INFRASTRUCTURE APPLICATIONS

Observable Vehicle detection



Event: Detection event (time-stamped) Event type or category: Detection of a passing vehicle Value: Universal time Data extraction method: Magnetometer reading

Observable Vehicle speed



Measure: Speed and direction Measure type or category: Velocity Value: meter per second Data extraction method: Magnetometer reading coupled with information regarding the fixed distance between the two Smart Dust sensors used.

Observable Temperature



Measure: Temperature reading Measure type or category: Numeric value Value: Temperature reading in Celcius Range: -40 to 70 °C Data extraction method: Thermistor reading



Observable Vehicle Identification



Event: Identification event (time-stamped) Event type or category: Identification of a passing vehicle Value: Unique ID of SV and Universal Time of identification Accuracy: 100% Data extraction method: Zigbee communication




Measure: Type of vehicle Measure type or category: Classification Value: to be determined, possibly based on Germany’s TLS standard Data extraction method: Magnetometer reading

Observable Vehicle counting



Measure: Number of passing vehicles Measure type or category: Calculation Value: integer Data extraction method: Magnetometer reading used in Vehicle Detection

Observable Traffic density/flow



Measure: Number of passing vehicles over time Measure type or category: Calculation Value: integer per second Data extraction method: Vehicle counting coupled over a certain period of time



Observable Vehicle location



Measure: Location of a vehicle equipped with an SV Measure type or category: Location Value: Position of a vehicle within a certain range of a particular SI Accuracy: close to 100% Data extraction method: Identification of SV onboard a vehicle by SI on a fixed location (through Zigbee communication)



C.5. AIRBORNE SENSOR

Observable Traffic Measurement

Observable type

Measurement of single car parameter (position, speed and velocity) Measurement of average traffic parameter (average velocity and density)


If flying above a street then using onboard camera system Measure: Vehicle detection, speed and traffic density Measure type or category: Real time traffic monitoring Value: Vehicles on the road, position, velocity Accuracy: depends on the application scenario Constraints:

Velocity: 0 – 250 km/h Position of vehicle: 1-2 m

Observable Traffic Measurement

Observable type

Measurement of single car parameter (position, speed and velocity) Measurement of average traffic parameter (average velocity and density)


If measuring category of vehicle then … Measure: category of vehicle (vehicle-like or truck-like) Measure type or category: Classification Value: truck (Other possible Knowledge Basis values: car, motorbike, bus, …) Accuracy: 90% Data extraction method: Automatically real time image processing Constraints:

Velocity: 0 – 250 km/h Position of vehicle: 1-2 m



C.6. ADVANCED AC20 RADAR SENSOR FOR TRAFFIC MONITORING

Observable Doppler Speed



Measure: Direct Vehicle Speed Measurement based on Doppler Shift. Measure Type: Direct Measurement Value: 0 to 180 kph. Resolution: Unknown for this application. Estimate: ≤0.25 kph (0.07m/s)

Observable Range



Measure: Vehicle Range. Measure Type: Direct Measurement Value: 2 to 200m. Accuracy: Unknown for this application. Estimate: ±1m between 1 and 20m ±5% above 20m

Observable Azimuth



Measure: Vehicle Azimuth (or angle). Measure Type: Direct Measurement Value: -6.5 to 6.5 degrees. Accuracy: Unknown for this application. Estimate: ± 0.3 degrees



Observable Target Return Level



Measure: Target Return Level. Measure Type: Direct Measurement Value: 0 to 127dBm.

Observable Flow rate

Observable type Possible cooperative measurement


Measure: Flow rate Data Extraction Method: Target Tracking Methods used to give tracked position and speed of up to 20 vehicles in the field of view of the radar.

Observable Vehicle count



Measure: Vehicle count Data Extraction Method: Target Tracking Methods used to give tracked position and speed of up to 20 vehicles in the field of view of the radar.

Observable Occupancy



Measure: Occupancy Data Extraction Method: Target Tracking Methods used to give tracked position and speed of up to 20 vehicles in the field of view of the radar.



C.7. ROAD SURFACE SENSOR FOR IN-VEHICLE ICE DETECTION

Observable ICE presence

Observable type Event: presence of ice on the road surface


Measure: ICE detection Measure type or category: Ice presence recognition Value: Two options: 1) Yes or No (data will be processed locally and shared with the sensor network one bit info). 2) Intermediate values could be considered, for instance “high probability ice formation”. In this case the data will be processed locally and shared with the sensor network with a two bits signal: for instance 00 no ice, 01 low probability, 10 intermediate probability, 11 very high probability. Data extraction method: The raw data are the Infra Red spectra taken by an on board IR spectrometer. The raw data will identify an n dimensional space (n is the number of channels of the spectrometer, i.e. the measured frequencies). Regions of this space will be identified as very high probability ice presence (more than 90%), intermediate ice presence probability (50-90%), low ice presence probability (10-50%), no ice presence (0-10%). Hazard type: Reduced vehicle control, tire-road friction compromised



C.8. VIDEO CAMERA FOR IN-VEHICLE APPLICATIONS

Observable Vehicle



Measure: vehicle presence Measure type or category: Detection Value: binary (present or not) [0 .. 1] Data extraction method: Image processing

Observable Vehicle



Measure: vehicle lateral relative position Measure type or category: Detection Value: lateral relative position [0 .. max. horizontal resolution of camera]] Data extraction method: Image processing

Observable Vehicle



Measure: vehicle pixel map Measure type or category: Part of whole image from camera Value: vehicle pixel map (boundary box) with vehicle [1 x 1 .. max. horizontal resolution of camera x max. vertical resolution of camera] Data extraction method: Image processing



C.9. VEHICLE IDENTIFICATION SENSOR FOR IN-VEHICLE APPLICATIONS

Observable Localized identified vehicle



Measure: ID and position of vehicle Measure type or category: position and ID Value: 3 float position array and 1 integer ID per detected vehicle Data extraction method: Image processing



C.10. PASSIVE MM WAVE SENSOR FOR IN-VEHICLE PEDESTRIAN DETECTION

Observable Pedestrian presence



Measure: pedestrian_presence (derived from: - "human or living creature" detection at suitable ranges - "human or living creature" discrimination from environment - "human or living creature" location (range and bearing) -"human or living creature" tracking (at sufficient update rate) ) Measure type or category: Human or living creature detection Value: pedestrian_on_carriageway (as description of the event)

Date post:	29-Oct-2020
Category:	Documents
Upload:	others
View:	1 times
Download:	0 times

Technologies for Road Advanced Cooperative Knowledge...

Documents