FINAL PROJECT - TU Wien · 1.2 Structure of the Thesis 1 2 WAVE Systems 3 2.1 General ... 5.2 Use of FitNesse in this Diploma Thesis 18 5.3 Implementation of a test using FitNesse

TECHNISCHE UNIVERSITÄT WIEN

INSTITUTE OF COMMUNICATIONS AND RADIO FREQUENCY ENGINEERING

UNIVERSIDAD POLITÉCNICA DE VALENCIA

ESCUELA TÉCNICA SUPERIOR DE INGENIEROS DE

TELECOMUNICACIONES

FINAL PROJECT:

Design and development of an automated test environment for car-to-car and car-to-infrastructure

communications based on IEEE 802.11p and IEEE 1609 WAVE standards

Author: Nuria Martí Boix Supervisors: Univ.-Prof. Dipl.-Ing. Dr.-Ing. Christoph Mecklenbräuker Dipl.-Ing. Alexander Paier September 2008

Contents

1 Introduction 1

1.1 Aim of the project 1

1.2 Structure of the Thesis 1

2 WAVE Systems 3

2.1 General description 3

2.2 Architecture and Components 5

3 WAVE Standards 7

3.1 Standard IEEE 1609 7

3.2 PICS (Protocol Implementation Conformance Statement) proforma 8

3.3 Standard IEEE 802.11p 8

4 WAVE Management plane 10

4.1 Primitives 10

4.2 Application Registration 12

4.3 Application Deregistration 13

4.4 WBSS Management 13

4.4.1 Link Establishment 14

4.4.2 WBSS Completion 15

5 Tool for Management Plane Test 17

5.1 Overview of the program 17

5.2 Use of FitNesse in this Diploma Thesis 18

5.3 Implementation of a test using FitNesse 19

5.4 Interpretation of the Results 22

6 WAVE Announcement Frame 23

7 WAVE Management Plane Test Suite 27

7.1 Specific Fixtures 27

7.2 Provider Test Suite 30

7.2.1 Application Registration 32

7.2.2 Link Activation 35


7.3 User Test Suite 49

7.3.1 Application Registration 51

7.3.2 Link Activation 52


i

8 WAVE Radio Frequency parameters 76

9 Tool for Radio Frequency Test 78

9.1 Overview of the program 78

9.2 Advantages of using Labview 79

10 WAVE Radio Frequency parameters Test 80

10.1 GPIB Standard 80

10.2 Test execution 81

10.3 Test development 82

10.4 Results of the Test 85

11. Conclusion 87

Sources 88

Annex I. Primitives description

Annex II. WAVE Management Plane Test Pages

ii

Index of figures

2.1: WAVE system components

2.2: WAVE Protocol stack

3.1: WAVE standards

4.1: Entities communication

4.2: WBSS initiation sequence

4.3: WBSS completion sequence

5.1: FitNesse program structure

5.2: Application Registration

5.3: Editing frame window of FitNesse

5.4: FitNesse test tables before test run

5.5: FitNesse Test Tables after test run

6.1: WSIE structure

6.2: WSA structure

6.3: Implementation of MLME-WSA.request in FitNesse

6.4: Implementation of MLME-WSA.indication in FitNesse

7.1: Use of wait4call detecting a sent primitive

7.2: Use of wait4call detecting a NOT sent primitive

7.3: RegisterTwice

7.4: DeregisterTwice

7.5: RegisterDeregisterTwice

7.6: Provider-Not using IPv6 MLME-WSA.cfm success

7.7: Provider-Not using IPv6 MLME-WSA.cfm not success

7.8: Provider-Using IPv6 TXPROF.cfm success

7.9: Provider-Using IPv6 TXPROF.cfm not success

7.10: Provider-Using IPv6 MLME-WSA.cfm not success

7.11: Provider-Not using IPv6-Deactivation request

7.12: Provider-Using Ipv6-Deactivation request

7.13: Provider-Not using IPv6-Deregistration request

7.14: Provider-Using IPv6-Deregistration request

7.15: Provider-Not using IPv6-Higher priority

7.16: Provider-Not using IPv6-Lower priority

7.17: Provider-Using IPv6-Higher priority

7.18: Provider-Using IPv6-Lower priority

7.19: Provider-Channel inactivity-Not using IPv6

7.20: Provider-Channel inactivity-Using IPv6

7.21: User-Application not match

7.22: User-Match-Confirm before join-Application rsp not success

7.23: User-Match–Cfm success–Join success-Not using IPv6

7.24: User-Match-Cfm success-Join success-Using IPv6 success

iii

7.25: User-Match–Cfm success-Join success-Using IPv6 DeleteTxprofile not

success

7.26: User-Match–Cfm success–Join not success-Using and not using IPv6

7.27: User-Match-Not cfm before join-Join not success-Using and not using IPv6

7.28: User-Match-Not cfm-Join success-Not using IPv6

7.29: User-Match-Not cfm before join-Join success-Using IPv6-REGTXPROF

success

7.30: User-Match-Not cfm before join-Join success-IPv6-REGTXPROF not

success

7.31: User-Application deactivation-Using IPv6

7.32: User-Application deactivation-Not using IPv6

7.33: User-Application deregistration-Using IPv6

7.34: User-Application deregistration-Not using IPv6

7.35: User-New application-Using IPv6-Higher priority-Not cfm before join

7.36: User-New application-Using IPv6-Higher priority-Cfm before join

7.37: User-New application-Using IPv6-Lower priority

7.38: User-New application-Not using IPv6-Higher priority-Not cfm before join

7.39: User-New application-Not using IPv6-Higher priority-Cfm before join

7.40: User-New application-Not using IPv6-Lower priority

7.41: User-Channel inactivity-Not using IPv6

7.42: User-Channel inactivity-Using IPv6

7.43: User-Unavailable request-Not using IPv6

7.44: User-Unavailable request-Using IPv6

8.1: Power of the classes

8.2: Spectrum masks for classes A, B, C and D

10.1: Devices connection

10.2: Front panel

10.3: Establishment of the connection

10.4: Set of parameters

10.5: Set of reference level

10.6: Received signal

10.7: Example of Test Result

Index of tables

4.1: List of primitives

6.1: Provider Contents bit information

7.1: Application registration parameters

iv

v

Acronyms CCH Control Channel

CFR Code of Federal Regulations

DSRC Dedicated Short Range Communications

FCC Federal Communications Commission

IEEE Institute of Electrical and Electronics Engineers

IP Internet Protocol

IPv6 Internet Protocol version 6

LAN Local area Network

LLC Logical Link Control

MAC Medium Access Control

MIB Management Information Base

MLME MAC layer management entity

OBU Onboard Unit

OFDM Orthogonal Frequency-Division Multiplexing

PHY Physical Layer

PLME Physical Layer Management Entity

PSID Provider Service Identifier

RSU Roadside Unit

SCH Service Channel

SAP Service Access Point

TCP Transmission Control Protocol

UDP User Datagram Protocol

WAVE Wireless Access in Vehicular Environments

WBSS WAVE Basic Service Set

WLAN Wireless Local Area Network

WME WAVE Management Entity

WSMP Wave Short Message Protocol

Chapter 1

Introduction

1.1 Aim of the project

Actually, vehicles are equipped with a multitude of passive safety systems.

Nevertheless, traffic accidents are taking a very large number of lives every year,

outnumbering any deadly diseases or natural disasters.

In most of the cases, accidents, congestions and other associated problems are

created by the driver’s inability to deal with complex traffic situations correctly and

instantly. Human visual attention is very limited and the driver has only incomplete

knowledge about the exact position and velocity of surrounding vehicles.

Since the nowadays traffic status is a problem in the society, an advanced

technology is developed to improve safety and efficiency of transportation

systems. This technology is called WAVE (Wireless Access in Vehicular

Environments).

WAVE Systems can enhance the transportation environment in the aspects of

safety, management and data services in a fast speed.

The aim of the present Final Project is to develop a Test Suite that checks if a

device is following the specifications of the IEEE (Institute of Electrical and

Electronics Engineers) standards that define the WAVE systems. I have

developed this Final Project in the company Siemens AG Austria together with the

Institute of Communications and Radio-Frequency Engineering of the Vienna

University of Technology.

1.2 Structure of the Thesis

Chapter 2 describes the WAVE systems and Chapter 3 the standards that define

them.

The WAVE Management plane is deeply detailed in Chapter 4. The tool used to

test this management plane and one simple example of these tests is shown in

Chapter 5.

One important part in WAVE systems is the information sent over the air, which is

tested in the Management plane test suite. The structure of the information sent

1

over the air is explained in Chapter 6. In Chapter 7 all the WAVE Management

plane tests developed in this project are explained in detail.

The other part of this final project tests several WAVE Radio Frequency

parameters. These parameters defined in the standard are described in Chapter 8.

Chapter 9 explains the test tool used and Chapter 10 shows the developed test.

This memory finalizes with my conclusions after finishing this final project.

2

Chapter 2

WAVE Systems

2.1 General Description

WAVE systems are an extension of the IEEE 802.11 wireless LAN (Local Area

Network). The main difference is in the application scenario, changing from indoor

fixed environments to outdoor mobile environments. This difference poses

considerable challenges for baseband signal processing and MAC (Medium

Access Control) protocols due to the fast fading channels, high Doppler shift and

time-varying network topology.

A WAVE device contains a WAVE-conformant MAC and PHY (Physical Layer)

interface to the wireless medium.

A WAVE system is a communications system that provides high-speed car-to-car

and car-to-infrastructure data transmission. These systems are built upon the

IEEE 1609 and IEEE 802.11p standards.

One characteristic that distinguish the WAVE devices from the rest of wireless

devices is that in this environment the stations move faster (can arrive to the 200

km/h) and the time of communication exchange is really shorter (can be in

milliseconds measured). The communication exchange is necessary to be short in

the security messages, when the whole information has to arrive in a short time to

avoid, for example a crash between two vehicles.

The spectrum is allocated in the upper 5 GHz range and OFDM (orthogonal

frequency-division multiplexing) technology providing up to 27 Mb/s data rate in

channels with 10MHz bandwidth is adopted.

The frequency band is divided in seven frequency channels, including one CCH

(Control Channel) for system control and safety service usages and several SCH

(Service Channels) for commercial applications. In order to coordinate the channel

access to the CCH and SCHs, the channel time is divided into synchronization

intervals with a fixed length, consisting of a CCH interval (half of the whole

interval) and a SCH interval (the second half of the whole interval). According to

the coordination scheme all devices have to tune to CCH during all CCH intervals,

where high priority frames, e.g. danger warning messages and management

frames, are exchanged. During SCH intervals, devices can optionally switch to

3

SCHs in order to perform nonsafety applications, like internet access. This

scheme allows WAVE devices to perform non-safety applications on SCHs without

missing important messages on CCH.

In North America there is already a frequency band of 75 MHz allocated specially

for this standard. In Europe the allocation process is currently ongoing for a

communication system similar to the WAVE System.

WAVE devices have a center frequency of 5.9 GHz and use the DSRC (Dedicated

Short Range Communications) WAVE mode. The DSRC is a short to medium

range communications service that supports both public safety and private

operations in car-to-infrastructure and car-to-car communication environments by

providing very high data transfer rates where minimizing latency in the

communication link and isolating relatively small communication zones is

important. It can be said that the DSRC is the previous level before the WAVE

systems in the development of car-to-car communications. DSRC is a general

purpose RF (Radio Frequency) communications link between the car and the

infrastructure, or between two cars.

There are two types of devices included, RSU (Roadside Unit) and OBU (Onboard

Unit).The RSU is stationary and the OBU is a mobile device mounted onboard a

vehicle.

“Generic IPv6 (Internet Protocol version 6) traffic is supported (not IPv4), as well

as a specialized short message service called WSMP (Wave Short Message

Protocol). A control channel provides a common channel for signaling. IP (Internet

Protocol) application data is restricted to service channels; short message

application data may be sent on either type of channel.” (Source [2])

A WBSS (WAVE Basic Service Set) is a set of stations working in WAVE mode

that have successfully synchronized using the JOIN service primitives and one

station that has used the START primitive. The devices (RSU or OBU) take the

role of either provider or user. A device can not be provider and user

simultaneously. The provider initiates the communication and offers services for

consumption by the user. Ergo, who announce the existence of a WBSS and

which are the associated application services is the provider. The user device

receives these announcements and reacts depending on the information received.

There are two kinds of WBSS, persistent and non-persistent. A non-persistent

WBSS is announced only when it is initiated by the provider. It would typically be

used for a transitory exchange among a group of devices whose membership

does not change for the duration of the WBSS. In a persistent WBSS the provider

4

MAC generates announcements every CCH interval. It would typically be used for

an ongoing WBSS whose services and device participation may change over the

duration of the WBSS.

The test suite developed in this Final Project evaluates the non-persistent WBSS.

This Final Project is based in the North American standards but it is important the

fact that there are being developed actually for Europe really similar ones.

2.2 Architecture and components

Figure 2.1 is the representation of the WAVE system components

Figure 2.1: WAVE system components (Source [1]) The applications shown in the upper layer provide the WAVE devices.

As is shown in the Figure 2.2 the WAVE protocol stack consists of two planes,

Management and Data plane:

The Data plane carries traffic between management plane entities of two

different devices or between applications and management plane entities

as well as traffic generated by or directed to the applications. It defines the

use of the exiting UDP (User Datagram Protocol) or TCP (Transmission

Control Protocol), IPv6, LLC (Logical Link Control) and WSMP.

The Management plane has different entities for the layers. There is the

PLME (Physical Layer Management Entity), MLME (MAC Layer

Management Entity) and the WME (WAVE Management Entity).The WME

is a general set of management functions in order to provide networking

services. A detailed description of the WME is provided in Chapter 4.

5

Figure 2.2: WAVE Protocol stack (Source [1])

6

Chapter 3

WAVE Standards

The tests of this Final Project are checking the validation of important

requirements of the two standards: the IEEE 1609.3 and the IEEE 802.11p.

3.1 Standard IEEE 1609

The IEEE 1609.3 belongs to the family of standards IEEE 1609. This family

defines the architecture, management structure, security, communications model

and physical access in WAVE systems.

It is described the physical mechanism of communication, as well as the command

and management services. These standards provide the basis for the design of

applications interfacing with the WAVE environment, and provide network services

so that applications can be seamless without regard to specific manufacturers,

including data storage access mechanisms, device management, and secure

message passing.

There are 5 different IEEE 1609 standards:

IEEE 1609.0: WAVE - architecture

IEEE 1609.0: WAVE - Resource Manager: this standard provides a

resource manager for WAVE, allowing communication between remote

applications and vehicles.

IEEE 1609.1: WAVE - Resource Manager: this standard provides a

resource manager for WAVE, allowing communication between remote

applications and vehicles.

IEEE 1609.2: WAVE - Security Services for Applications and Management

Messages

IEEE 1609.3: WAVE - Networking Services: defines services operating at

the network and transport layers

IEEE 1609.4: WAVE - Multi-channel operation: This standard deals with

communications through multiple channels

7

This Diploma Thesis studies deeply the standard IEEE 1609.3, specifically the

Management plane behavior. This standard will be detailed in next Chapters.

3.2 PICS (Protocol Implementation Conformance Statement) proforma

There is a part of the protocol IEEE 1609.3 called PICS proforma. “The PICS is a

statement of which capabilities and options of the protocol have been

implemented” Source [2].

The PICS proforma is a Table. In this table there are items which represent the

different functionalities described in this standard. In the last column of the Table

is the option yes or not to be filled by the person who is checking if a device is

following the standard.

The PICS proforma shows which functionalities have to been checked by a tester

to prove that the standard is being followed by a device. The tests of the WAVE

management plane developed in this Diploma Thesis tests the items described in

the PICS proforma which can be tested with the used test tool.

In Annex D of IEEE 1609.3 (Source [3]), the PICS proforma is shown.

3.3 Standard IEEE 802.11p

This standard is a part of the IEEE 802.11 standards.

The IEEE 802.11 defines the use of the two lower OSI (Open System

Interconnection) levels in a WLAN (Wireless Local Area Network).

The IEEE 802.11p defines the WLAN MAC (Medium Access Control) and Physical

Layer specifications.

In Figure 3.1 the position of the mentioned tests in this Chapter in the different

layers is represented.

8

Figure 3.1: WAVE standards (Source [1])

9

Chapter 4

WAVE Management Plane

One part of this Final Project is testing the Management plane. In particular it is

WME behavior was under investigation. The entire WAVE management plane test

is based in the IEEE 1609.3 standard.

Applications are higher layer entities that employ the WAVE communications stack

in order to communicate over the Airlink. This is shown in Figure 3.1. The WME

provides a management layer interface to all data plane entities. It exchanges

information with the Application and with the MLME using primitives.

The communication between the entities of a device is like is shown in Figure 4.1.

Figure 4.1: Entities communication In the following subchapters the different management plane services will be

explained in a general view.

4.1 Primitives

The primitives are used for the communication exchange between adjacent layer

entities. The SAPs (Service Access points) support communication between

WAVE networking services entities and other WAVE entities in the same device.

For the management plane, the WME SAP (between Application and WME) and

MLME SAP (between WME and MLME) primitives are used.

There are four types of primitives:

Request

Confirm

Indication

10

Response

The request primitive is used by the upper layer to request a service to the lower

layer which answers with the confirm primitive.

The indication primitive is used by the lower layer (which is providing a service) to

notify an activity to the upper layer which answers with the response primitive.

In the management plane there are request and response primitives from the

Application to the WME and from the WME to the MLME. The indication and

confirm primitives are sent from WME to Application and from the MLME to the

WME.

The primitives of the WME SAP and MLME SAP are shown Table 4.1 and are

described in detail in the Annex I In Chapter 5 an example of the implementation

of the WME-ApplicationRegistration.request primitive is shown.

SAP Primitive

WME WME-Application.request WME-Application.confirm

WME-Application.indication

WME-Application.response

WME-Notification.indication

WME-ApplicationRegistration.request

WME-ApplicationRegistration.confirm

MLME MLME-DeleteTXprofile.request

MLME-DeleteTXprofile.confirm

MLME-RegisterTXprofile.request

MLME-RegisterTXprofile.confirm

MLME-WSA.request MLME-WSA.confirm

MLME-WSA.indication

MLME-WSA.response

MLME-WAVEJOIN.request

MLME-WAVEJOIN.confirm

MLME-WAVEEND.request MLME-WAVEEND.confirm

Table 4.1: List of primitives (Source [2])

4.2 Application Registration

11

An application independently of its role (user or provider) has to be registered

before any action.

The registration is the provision of application parameters to assist the progress of

the management of the communication system. These parameters are used by

the provider to populate the information about the applications that are offering a

service and by the user to decide whether to link to one of these advertised

services. Both entities use this data to manage the establishment and

maintenance of the link in support of the service.

As it is shown in Figure 3.2 the WME contains a MIB (Management Information

Base). In this MIB the application parameters (organized in structures) will be

recorded.

When an application is registered, the registration information is filed in the next

WME MIB structures:

“

ProviderServiceInfo. This MIB structure contains the application information

that is used to generate the announcements that will initiate and advertise a

WBSS in support of the application’s service offering. Each registered

provider application has an entry PstEntry in this table.

UserServiceInfo. This MIB structure is used in detecting whether a received

service advertisement is of interest to applications supported by the local

device. It is not sent over the air. Each registered user application has an

entry UstEntry in this table.

ApplicationStatusTable. This MIB structure shall be initialized at

registration, and used locally in the maintenance of the WBSS that support

application traffic. Each registered application has an entry in this table.

” Source [2]

Therefore the ProviderServiceInfo contains provider applications information, the

UserServiceInfo contains user applications information and the

ApplicationStatusTable contains all applications information.

Each application is uniquely identified by a PSID (Provider Service Identifier), so

this parameter is going to be used to distinguish the applications.

12

The process of registration starts when the application sends a request of

registration addition to the WME through the WME-ApplicationRegistration.request

indicating addition. Then, the WME checks in the MIB if there is not already an

application with the same PSID in the ProviderServiceInfo when it is a provider

application. In the case of a user application the UserServiceInfo will be checked.

This process validates that the application is not already registered.

If the application is already registered, the WME refuses the request by sending a

WME-ApplicationRegistration.confirm to the application indicating the negative

result and reason.

If the application is not registered, the WME accepts the request by sending a

WME-ApplicationRegistration.confirm to the application indicating the positive

result. The information about the registered application is saved in the

corresponding WME MIB structure.

4.3 Application Deregistration

An application has the possibility of being deregistered. In this situation, the

application sends the ApplicationRegistration.request but indicating remove.

When the WME receives a removal demand all the information about this

application shall be deleted from the WME MIB.

It is important to check if this application was the active one of the device because

in this case, the WBSS has to be ended.

In both cases, application registration and deregistration the entities that are

involved are the Application entity and the WME.

4.4 WBSS Management

The Management Plane administrates the WAVE Basic Service Set (WBSS)

participation in support of applications. Only one WBSS is joined by a device.

The fact that it is not allowed to have simultaneous WBSS established in the same

devices is solved with the priority assigned to the applications. This priority

determinates the first access to the communication services and is defined during

the registration process and saved with the rest of parameters in the WME MIB.

Consequently, in a link establishment conflict, the WME will choose a link with the

most priority application.

13

The following subchapters describe the two main WBSS management actions, the

link establishment and the WBSS Completion in the situation that the process

succeeded in order to give a general idea of the Management plane behavior. All

other cases are described in Chapter 7.

4.4.1 Link Establishment

The procedure of the link establishment is summarized in Figure 4.2. As

mentioned before, the provider application initiates the process of the WBSS.

Starting from the point that the provider and user application are registered and

having both the same PSID.

The provider application asks the WME for the activation sending the WME-

Application.request. In this primitive are the WBSS parameters like the

persistence, the MAC address of the recipient device, the number of

advertisement repetitions and the SCH to use.

The WME checks if the application is registered and informs to the MLME sending

MLME-WSA.request. The necessary parameters to create a WBSS are

transmitted within a WAVE Announcement frame over the air on the CCH. If all the

previous process has been successfully implemented, the Application will receive

a WME-Notification..indication.

When the user’s WME receives the MLME-WSA.indication (generated from the

MLME because of the reception of a WAVE Announcement frame) which contains

information about the provider application, the WME shall verify the secured

information.

Later on, the WME has to check in the UserServiceInfo of the WME MIB if there is

a registered application with the same PSID than the provider one. When a match

occurs, the WME generates the MLME-WAVEJOIN.request which is the MAC

primitive that causes the join of the WBSS.

These last steps mean that the user application, after being registered, is waiting

to receive an “offer” to being provided from a Provider application with the same

PSID. This “offer” arrives via WAVE Announcement frame. When user and

provider application have the same identifier, the user device proceeds to start the

link.

After the previous steps have succeeded, the WME informs to the application

about the WBSS initiated with the WME-Notification.indication.

14

The single shared information between the provider and the user is the WAVE

Announcement frame. There is no other frame in order to confirm the link

establishment.

Figure 4.2: WBSS initiation sequence

The link establishment includes simplifications detailed in the next lines:

All the request primitives have a confirmation answer.

In this WBSS establishment of the provider application it has been

supposed that there was not a previous WBSS joined in this device, the

provider is not using IPv6 and the user application is not asking for confirm

before join.

When the provider uses IPv6, the transmitter profile has to be registered in

both devices (provider and user).

When the user asks for confirm before join, the user application has

accepted the link before it is joined.

4.4.2 WBSS Completion

The WME decides to end the link under the following circumstances:

A linked application asks for deregistration (it is the active one).

An application asks for inactivation.

15

The WME receives the primitive MLME–ChannelInactivity.indication, this

primitive indicates that there is no activity on the current channel and the

WBSS should be ended.

A higher priority application demands a WBSS.

The user receives a WSA where the security credentials are not correct.

Although there are some different situations for the link completion, the process is

the same for all of them. When the WME decides to end its participation in the

WBSS, it sends the MLME-WAVEEND.request primitive to the MLME and, after

the answer of the MLME it sends a Notification indicating that the link is terminated

and the reason to the application. Figure 4.3 shows the basic WBSS completion

process.

A detail to stand out is the fact that during the ending a WBSS procedure there is

no information exchange over the air between provider and user.

Figure 4.3 WBSS completion sequence

As with the link establishment, the procedure has been simplified and the provider

application was not using IPv6.

16

Chapter 5

Tool for Management Plane Test

The program used for developing the management plane Test Suite is called

FitNesse.

5.1 Overview of the Program

FitNesse is a software testing tool. It compares customers' expectations to actual

results.

The structure is shown in Figure 5.1. As it is shown, the user defines the Test

Cases These Test Cases are created in the Acceptance Tests that are web pages

containing simple tables of inputs and expected outputs.

Fit (Framework for Integrated Testing) is the engine that processes each FitNesse

test table, using the FixtureCode referred to by that table. The fixtures are Java

classes.

When a test is running, there the following steps executed:

First, FitNesse submits the test table to the underlying FitFramework.

Fit looks for and runs the fixture code corresponding to the test table.

By design, the fixture code calls some underlying application code to do the

real work, and report results back to the fixture.

Fit gives FitNesse back the results from running the fixture code.

FitNesse Figures out whether to turn table cells red, green or yellow and

displays the results page accordingly.

The color of the cell indicates the result of the test. If it is like it was expected the

cell is green. If it is different, the cell is green and if an exception was thrown the

cell appears yellow.

17

http://www.fitnesse.org/FitNesse.FitNesse

http://www.fitnesse.org/FitNesse.FixtureCode

http://fitnesse.org/FitNesse.FitNesse

http://fitnesse.org/FitNesse.FitFramework

http://fitnesse.org/FitNesse.FitNesse

Figure 5.1: FitNesse program structure (Source [6])

As it was mentioned before, the FitNesse tests are expressed as tables of input

data and expected output data.

Test tables are generate on test pages. As the set of test pages grows, they are

organized into hierarchical Test Suites. This hierarchical structure allows the user

to run only a test page, a branch of the structure or the whole test suite.

The fields in the tables without a question mark are inputs and the ones with

question mark are outputs. The output fields have to be filled with the expected

value before running the tests.

In order to introduce the test tables into a page, FitNesse has the edit option which

allows showing a window with an edit frame containing the mark-up language of

the current page. It is a specific format using a simple mark-up language.

5.2 Use of FitNesse in this Diploma Thesis

This Diploma Thesis was developed in a company. The aim of this Thesis is to

create test cases in FitNesse that evaluate the behavior of the WME (Wave

Management Entity) and ensure that follows the requirements of the standard

IEEE1609.3.

18

http://www.fitnesse.org/FitNesse.TestSuites

The WME code (that corresponds to the application under test) and the custom

fixtures code was already programmed by the company. Using this available code

and studying all possible situations related in IEEE 1609.3 standard, I developed

different test cases.

5.3 Implementation of a test using FitNesse

In order to clarify how the test tables look like, it is explained in the following lines

a short and simple case of test tables implementation.

The test scenario is a successful application registration. Figure 5.2 shows the

diagram of the exchanged primitives between the WME and Application Entity.

Figure 5.2: Application Registration The application under test is the WME code and the fixtures code is simulating the

Application Entity behavior sending primitives and checking the received ones.

Figure 5.3 shows the editing frame window, where the tables and values are

introduced.

19

Figure 5.3: Editing frame window of FitNesse

In Figure 5.4 you can find the test page before running the test.

Figure 5.4: FitNesse test tables before test run

In PART 1: REQUEST, the fixture called Register Request sends a primitive to the

WME code (the WME-ApplicationRegistration.request of the standard)

The test table includes the fields:

Action:

0: add provider

1: add user

2: add provider-user

3: remove provider

4: remove user

5: remove provider user

20

Psid: is the Provider Service Identifier

This is the value that identifies the application.

Prio: the priority of the application

Channel Selection:

The channel of operation for the offered service.

Service IPv6: Service IPv6 Address

The end point of the offered IP service.

Service port: Service port (UDP or TCP)

The end point of the offered IP service.

Mac: Service Provider MAC address

The end point of the offered service.

Notification IPv6: Notification IP Address

Address of the application.

Notification port: Notification port.

UDP port of the application.

Confirm before join

Sent?

0: successfully sent

1: not sent

Result?

OK

NON OK

The last two fields are used for checking if the information has been sent to the

WME code correctly. As the name of these fields includes at the end a question

mark, they are filled with the values that are expected, and the last two fields are

going to change of color when the test is run.

In PART 2: CONFIRM, the fixture called Register confirm checks the primitive sent

from the WME code after having received the previous

ApplicationRegistration.request. It is expected that the WME sends the primitive

called WME-ApplicationRegistration.confirm.

The test table has the fields:

Confirm?

0: OK

1: NON OK

21

Result?

0: Success

1: Unspecified failure

2: Invalid parameters

3: PSID conflict

4: Insufficient priority

The first shows if it is received the information from the WME and the second

shows the received Result Code from the primitive.

5.4 Interpretation of the Results

After running the test, the test tables look like shown in Figure 5.5.

Figure 5.5: FitNesse Test Tables after test run

All the fields with a question mark are green colored, that means that the result is

the expected one. If some fields are red colored, an error has occurred.

One possible situation where one field is red is when is received another valued,

for example 1 (Unspecified Failure), in the field called result?. This means that the

WME does not register the application.

It is really important to analyze the results before of taking a conclusion. For

example, when all the tests results are red and giving not logical values, it can be

that the WME is not behaving like it should or, that other reason is blocking the

communication between the software under test and the Test Pages. In my case,

this was happening to me and, the problem was that the WME software was not

running in the moment I was trying to test. So, it was good not to take fast

conclusions and try to analyze the situation.

22

Chapter 6

WAVE Announcement Frame

The information sent over the air from a device with an active provider application

is called WAVE Announcement Frame. This frame announces the service of the

provider offered to a user. One part of such a frame is the WSIE (WAVE service

information element).

The WSIE structure is shown in Figure 6.1:

Figure 6.1: WSIE structure (Source [2]) The WSIE is created by the provider. During the process of a provider link, the

WME creates a WSA with the information about the services offered which are

saved in the WME MIB. Then, the WME sends the signed and secured WSA

message to the MLME via a MLME-WSA.request primitive.

“MLME adds a parameter reflecting the quality of its timing information, to be used

in the receiving devices’ synchronization function, with the resulting collection

known as a WAVE service information element (WSIE). (The timing information

itself is within the MAC header.) At this point, over the air headers and footers are

added and the frame is ready for transmission.” (Source [2])

The WSA contains the WAVE version, the PST (Provider Service Table) and the

WRA (WAVE Routing Advertisement).

23

The WRA is optional because it is the network configuration information

broadcasted by the RSU. The WME includes the WRA when it is included in the

MIB.

“The PST describes the applications that are registered with and available though

a WAVE device, with supporting the channel information.” Source [2]

The structure of the WSA is shown Figure 6.2:

Figure 6.2: WSA structure(Source[3]) The service information includes a Provider Service Table consisting of

ProviderServiceInfo containing the PstEntry of the requesting application, and the

ChannelInfo corresponding to any ChannelNumber contained in the

ProviderServiceInfo.

One of the fields of the ProviderServiceInfo called Provider Contents is a bit string

that indicates which of the fields of the Provider Service Info are used or not in this

specific WSA. The Table 6.1 shows the meaning of each of these bits.

24

BIT Optional Field B0-B8 Reserved B9 Peer MAC Address B10 ProvideDeviceAddressingB11 Service Port B12 IPv6 Address B13 ChannelSelection B14 Application Priority B15 ProviderServiceIdentifier

Table 6.1: Provider Contents bit information

In the test suite, the data in the WSA is sent or received by the WME with the

MLME-WSA.request and MLME-WSA.indication primitives. One of the fields of

these primitives contains the WSA. In the FitNessse tables, when in the test is

included one of these two primitives, there are shown two tables: one for the

primitive field (the lower one position) and the other one (the upper one) shows

the content of a specific field of this primitive. This field is the WSA data and

contents the information about the provider application which is sent over the air

into the WAVE Announcement frame.

In the past Registration case example, the FitNesse tables simulate to be the

Application. For the MLME primitives the Test user is in the MLME position and is

sending from this entity to the WME the primitives and checking the response of

the WME.

In Figure 6.3 is the table implementation of the primitive MLME-WSA.request with

FitNesse. As it is shown, because all the fields are field, the value of pContent is

127, from bit 9 to 15 the value is 1. So, the value in binary of pContent is

0000000001111111, this value is 127 in decimal.

The FitNesse fixture used for the implementation of these primitives has two entry

tables. One table is for the WSA fields (the upper one) and the other for the rest of

the fields of the primitive.

Figure 6.3: Implementation of MLME-WSA.request in FitNesse

25

All the data fields are introduced by the WME because this is the entity which

generates the primitive and the WSA. It uses the information about the offered

service from the WME-MIB.

The tables used in FitNesse to implement the MLME-WSA.indication are shown in

Figure 6.4. Like in the request case there are two tables implementing the WSA

fields and the primitive fields respectively. This primitive is generated by the MLME

so, in FitNesse, is the user of the program who fills the information simulating be

the MLME and filling the tables with the information received over the air.

Figure 6.4: Implementation of MLME-WSA.indication in FitNesse

26

Chapter 7

WAVE Management Plane Test Suite

The structure of the Management Plane Test Suite is a ramification with all the

possible situations a specific process. There exist two groups of tests, one for

devices acting as a user and the other one for the device acting as a provider.

Each one (provider and user) has three chapters:

Application registration,

Link establishment

WBSS completion.

7.1 Specific Fixtures

Before describing the Test Suite structure in detail, it is important to explain a

functionality used in most of the tests.

The developed fixtures implement the primitives that are exchanged between the

different entities. There are two extra fixtures with other target, one of these

fixtures is called Wait4call .This fixture provides the information if the WME has

sent a primitive or not.

The demand of this fixture is due to the fact that a process is not always finished,

sometimes it is interrupted for any reasons. Wait4call allows checking if the next

steps of the process are executed almost if it should not be.

One example of the need of this fixture is when the WME receives a confirm

primitive from another entity with the result not success and that concern the stop

of the process. It is necessary to check that in fact, the process has stopped.

The basic explanation of how this fixture works is the next one:

An identifier (a number) is assigned to each primitive .There are two arrays, one

for the application entity and the other one for the MLME entity. In these arrays

are saved the identifiers of the primitives that are arriving to this entity coming from

the WME. Wait4call checks these arrays searching the primitive requested.

It has three entries:

27

Sec: the maximum time for waiting for the signal (in seconds).

Peer: the entity which should receive the signal, 1 corresponds to the

application and 2 to the MLME entity.

Callid: the identifier of the primitive.

And one exit:

Waited: returns the value 0 when the primitive has not been received and

the value introduced in sec when it has been received.

If during the sec time the WME has not sent this primitive to the peer entity, it will

return 0.

The implementation of this fixture in the FitNesse test implies also the use of

another fixture called Resetwait4CallStates which resets the array of the entity.

Depending on the entry of the fixture, it will reset the array of the application entity

or the one of the MLME (MAC Layer Management Entity)

The Resetwait4CallStates table is positioned before the generation of the primitive

that will generate the WME's primitive to be detected.

In the registration process illustrated in the Overview of the program in Chapter 5

are exchanged the application registration request and confirm primitives between

the Application and WME.

One variation of this test that shows the procedure of these fixtures is shown in

Figure 7.1.

Figure 7.1: Use of wait4call detecting a sent primitive

28

The Register confirm primitive is generated by the WME when it receives a

Register request. So, the primitive ResetWait4call is allocated before the Register

request transmission. It resets the array of the application (peer 1). Wait4Call

detects that the application (peer 1) has received an Application Register confirm

(Identifier 22). The result is the maximum time established to wait, so, it is a

positive detection.

The use of these fixtures in the Test Suite implemented in this project is not the

confirmation of the reception of a primitive. Instead of that, it is used to detect if the

WME is not sending determined primitives because the process has been stopped

for any reason. In the successful case the WME would send such determined

primitives.

One situation where these fixtures are used is when a link establishment process

is stopped. Then it has to be checked that there is no Notification primitive arriving

to the Application Entity. This notification indicates the application that the WBSS

has changed their status. So, it is important that the application does not receive a

Link activation when, in fact, the WBSS is not established.

Taking again the registration case, in Figure 7.2 it is proven that the WME is not

sending an Application Indication after receiving a WME-

ApplicationRegister.request. It has been chosen the Application Indication

arbitrarily because in the registration process is not necessary to check that the

WME does not send a primitive because the registration request always has a

confirm, independently if the process was successful or not. So, this is just an

example not defined in the standard in order to show how the Wait4Call fixture is

used to check that the WME has not sent a specific primitive. As it has been said

before, in the fixture it is defined an identifier for each primitive. This identifier is

not from the standard, is a variable created in the test process to distinguish

between primitives.

29

Figure 7.2: Use of wait4call detecting a NOT sent primitive

As last example, the Resetwait4call table is positioned before the Application

Registration request.

Now, the primitive waited is the Application Indication with the identifier 18 and,

the result visualized in the table is 0. This indicates that the WME has not sent an

Application Registration primitive in a time of duration of 4 seconds after receiving

a Register request from an Application.

The 4 seconds waiting period are chosen because the tested software of the WME

generates the response primitive in a shorter time. So the 4 seconds are

maximum time limit in order to be sure that there is no primitive transmitted.

The use of Wait4call is absolutely necessary, without this test it would be not

possible to test when the process stops making the test suite inefficient.

7.2 Provider Test Suite

Depending on how the Application is registered as a user or a provider, the WME

will respond in a different way.

In the provider case, there are nineteen Test Pages (marked in bold in the

following list) separated in three main groups: application registration, link

activation and WBSS completion.

30

The main requirements about the behavior of the WME specified in the standard

IEEE 1609.3 are included in these three main actions. The structure of the

provider Test Suite is the following one:

Provider

o Application Registration

RegisterOk

RegisterTwice

DeregisterTwice

RegisterDeregisterTwice

o Link Activation

IPv6

MLME-WSA.cfm Not success

MLME-WSA.cfm Success

o RegisterTxProfile.cfm Not success

o RegisterTxProfile.cfm Success

Not IPv6

MLME-WSA.cfm Not success


o WBSS Completion

Application Deactivation

IPv6

Not IPv6

Application Deregistration

IPv6

Not IPv6

New application Activation request

IPv6

o Higher priority

o Lower priority

Not IPv6

o Higher priority

o Lower priority

Channel Inactivity

IPv6

Not IPv6

31

7.2.1 Application registration

There are four tests in the provider application part:

o Application Registration

RegisterOk TEST 1

RegisterTwice TEST 2

DeregisterTwice TEST 3

RegisterDeregisterTwice TEST 4

This group of tests checks the WME behavior during the registration and

deregistration of an application.

The main functionality of the WME is to save the information about the application

in the correct structure information of the WME MIB. Depending on the type of

application, provider or user, the application data will be stored in the

ProviderServiceInfo or in the UserServiceInfo respectively.

As explained in Chapter 5, the Test 1 (RegisterOK) executes a basic registration

and deregistration. The rest of Test Pages have the aim of prove that the WME

MIB is saving the correct information and at the correct place.

The Test 2 (RegisterTwice) registers two times the same application. The

response of the second registration is PSID (Provider Service Identifier) conflict

because the WME has already the information about this application in the MIB.

Figure 7.3: RegisterTwice

During the Test 3 (DeregisterTwice) the application is deregistered two times. The

second deregistration has a response of failure. It proves that in the first

deregistration all the applications information has been deleted in the MIB.

32

APP

WME-AppRegistration.REQ

WME-AppRegistration.CFM

Registration Action: Add Provider

Result Code: Success

PSID = 99



Registration Action: Remove Provider

PSID = 99

WME





Result Code: PSID Conflict

PSID = 99

Figure 7.4: DeregisterTwice

The function of the Test 4 (RegisterDeregisterTwice) is, continuing with the same

idea of the previous test, to investigate if an application asks to be registered two

times that the WME does not save the same information duplicated in the WME.

APP





PSID = 99




PSID = 99

WME






PSID = 99





PSID = 99

Figure 7.5: RegisterDeregisterTwice At this point, the main difference in the registration of a user Application and a

provider Application is explained. This difference is the content of the parameters

that will be scored in the WME-MIB.

These parameters are sent from the Application entity to the WME in the WME-

ApplicationRegistration.request primitive. Table 7.1 specifies which parameters

have to be provided in each case.

33

Service Info Provider User

parameter IP WSM IP WSM

PSID E E E E Application

Priority E E X.1 X.1

Channel O O X.1 X.1 Service IPv6

address E X X X

Service port (UDP or TCP)

E X X X

Service Provider MAC Address

O O X X

Notification IP address

C.1 C.1 C.1 C.1

Notification port C.2 C.2 C.2 C.2 Confirm before

join X X O O

Table 7.1: Application registration parameters (Source [2])

KEY:

E Expected to be provided

O Optionally provided by the application

X Not used

X.1 Not used in registration; the parameter is set by the user WME based on

provider information in the announcement

X.2 Not used in registration; the parameter is set by the user application based

on provider information in the announcement

C.1 Mandatory if IP is used for local notifications, otherwise X

C.2 Mandatory if UDP is used for notifications, otherwise X

There are two possible situations: when IP is used (in this case only the IPv6 is

allowed) and when IP is not used. When IP is not used, the WSMP is

implemented. WSMP is a protocol for rapid, reliable exchange of messages in a

rapidly-varying RF environment.

“The WSMP allows applications to directly control physical layer characteristics,

e.g., channel number and transmitter power, used in transmitting the messages. A

sending application also provides the MAC address of the destination device,

including the possibility of a broadcast address. WSMs are delivered to the correct

34

application at a destination based on Provider Service Identifier (PSID). WSMs are

designed to consume minimal channel capacity and are allowed on both the CCH

and SCHs.” Source [2]

The usage of IP or not is established by the provider application. So, if IP is used

the parameter Service IPv6 address and Service Port in the registration of a

provider Application will be different than zero. These parameters define the end

point of the offered IP service. The user does not fill these parameters in the

registration process because it does not decide if IP is used or not. This fact will

be checked during the link establishment process.

The application priority parameter is only established by the provider. The user

gets the information about the priority of the application with the WSA received.

The provider application can choose the channel of operation. In the case when

the provider application wants to choose a specific channel of operation, it will

send this in the Channel parameter to the WME. Similar to the priority information,

the user WME gets the information from the WSA coming from the provider device

and not from his own Application.

Both, user and provider are using the PSID, Notification IP address and

Notification Port field.

7.2.2 Link Activation

The provider link activation test structure is the following one:

o Link Activation

IPv6

MLME-WSA.cfm Not success TEST 5


o RegisterTxProfile.cfm Not success

TEST 6

o RegisterTxProfile.cfm Success TEST 7

Not IPv6

MLME-WSA.cfm Not success TEST 8

MLME-WSA.cfm Success TEST 9

The WBSS connection establishment is tested. The conditions before the

establishment are that there is no previous link activated and that the application

which asks to be active is already registered.

35

The application is registered and, later on, it asks to be activated. After this, it will

start the link establishment.

When the WME receives an activation request from an application, it checks if the

application is registered and sends a MLME-WSA.reques to the MLME.

Depending on the result of the MLME-WSA.confirm received from the application

the WME will have two different behaviors.

Another factor that determines the WME behavior is using IPv6 or not. Analyzing

the not IPv6 case there are two situations: MLME-WSA.cfm success or not

success.

Figure 7.6 shows the first situation: Test 9 (Not IPv6 and MLME-WSA.cfm

Success). After receiving the confirmation from the MLME, the WME sends an

Application confirm to the Application Entity indicating that the activation has

succeed. Then, a WME-Notification.indication with the Event’s value WBSS Active

and the Reason value Application Requested is sent to the application.

Figure 7.6: Provider-Not using IPv6 MLME-WSA.cfm success

The second situation, when the MLME responds with an MLME-WSA.confirm with

a Result Code of Invalid Parameters, is checked in Test 8 (IPv6 is not used and

MLME-WSA.cfm Not success) and the process is shown in Figure 7.7.

The application receives a WME-Application.confirm, indicating that the activation

has not succeeded, and the WME-Notification.indication will not be sent because

now the link is not established.

In this Test the Wait4call fixture is used to check that the WME is not sending a

Notification Indication. The Resetwait4call fixture is positioned before the MLME-

WSA.confirm because this primitive is the one which would generate the WME-

Notification.indication.

36

APP





PSID = 99

WME MLME

WME-App.REQRequest type : ActivePSID = 99

MLME-WSA.REQ

MLME-WSA.CFM

ResultCode : Invalid Parmeters

Result Code: Unspecified Failure

WME-App.CFM

Figure 7.7: Provider-Not using IPv6 MLME-WSA.cfm not success Analyzing now the other main case, when the provider application is using IPv6,

the process of link activation is the same as before but with an additional

exchange of Register Transmitter Profile primitives between the WME and MLME

entities.

The diagram in Figure 7.8 describes the successful link activation tested in Test 7

(IPv6, MLMEWSA.cfmSuccess, RegisterTxProfile.cfmSuccess).

The transmitter profile data describes the provider communication parameters.

These parameters are the Service Channel number, the power level, the data rate,

the adaptable status of power level, and the data rate for IP-based applications.

The reason of the usage of the Register Transmitted Profile primitives during the

link establishment process is that, before initializing IP data exchanges, the

transmitter profile has to be registered in the MLME.

Figure 7.8: Provider-Using IPv6 TXPROF.cfm success

37

Test 6 (IPv6, MLMEWSA.cfmSuccess, RegisterTxProfile.cfmNOTSuccess) deals

with the situation that the confirmation of the Register Transmitter Profile is not

successful. Then, the WME sends to the Application a negative activation

confirmation.

It is important to determine that the WME is not sending any notification indication

to the Application. For this the Wait4call fixture is used again.

Figure 7.9: Provider-Using IPv6 TXPROF.cfm not success

Continuing with the IPv6 situation, it is confirmed in Test 5 that the WME behavior

after a MLME-WSA.confirm with Result Invalid Parameters is the correct one. The

primitive exchange is the same as the not IPv6 case and is shown in Figure 7.10.

This Test Page is checking that the WME does not send the MLME-

RegisterTxProfile.request like in the case where the link was successful.

APP





PSID = 99

WME MLME


MLME-WSA.REQ

MLME-WSA.CFM

ResultCode : Invalid Parmeters

Result Code: Unspecified Failure

WME-App.CFM

Figure 7.10: Provider-Using IPv6 MLME-WSA.cfm not success

The actions implemented by the entities are the same as in the case where IPv6 is

not used. The difference is that now it is checked that, after the MLME-WSA

38

confirmation with a negative result, the WME does not register the transmitter

profile after sending the Application confirmation.


The conditions before the WBSS completion are that there is an active application

in provider and user part with the same PSID and that the link is established.

There are three possible reasons that cause the end of the link in the provider

part. These causes are the request of an application deactivation, application

deregistration and activation of an application of a higher priority.

The structure of this part is the following one:

o WBSS Completion


IPv6 Test 10

Not IPv6 Test 11


IPv6 Test 12

Not IPv6 Test 13


IPv6

o Higher priority Test 14

o Lower priority Test 15

Not IPv6

o Higher priority Test 16

o Lower priority Test 17

Channel Inactivity

IPv6 Test 18

Not IPv6 Test 19

One important detail about the WBSS completion tests developed in this project is

that the situation of negative confirmation from the MLME is has not been tested.

Let us look at the environment where the WAVE devices are used, when one

vehicle wants to stop the communication with another one, it asks for finishing the

link and afterwards it is really possible that moves to another place. So, it is not

implemented in the device under test to not allow the end of a link because of

physical reasons. That means that when a vehicle goes far from the other one (or

form the infrastructure) even if the MLME entity does not allow the end of the link,

39

the distance between the two vehicles will force this end because there will not the

possibility of communication.

APPLICATION DEACTIVATION

When the application asks to be deactivated, the WBSS completion is started.

In Test 11 (IPv6 is not used Deactivation Request) the WME receives a

deactivation request from an application that does not use IPv6 and sends a

WAVEEND request to the MLME. After the confirmation of the WAVEEND, the

WME confirms the deactivation to the Application and sends a Notification

Indication with the Event WBSS Inactive and the Reason Application Requested.

Figure 7.11: Provider-Not using IPv6-Deactivation request

In Figure 7.12 the active Application is using IPv6, which is implemented in Test

10. When the WME receives an Inactive Request, it sends a MLME-

DeleteTxProfile.request before of asking for the end of the link. The aim of this

action is to delete the transmitter profile from the MLME MIB. After this, the same

process of ending the WBSS (or without using IPv6) starts.

40

Figure 7.12: Provider-Using Ipv6-Deactivation request

APPLICATION DEREGISTRATION

Before allowing a deregistration request, the WME has to check if the requesting

application was the active one. In this case, it has to finish the link before of the

deregistration process.

Figures 7.13 and 7.14 show that the sequence of primitive exchange is the same

as deactivation case. The difference is that after a deactivation, the application is

still registered with all the information stored in the MIB and after deregistration,

there is no more information in the MIB stored.

In the Deregistration case, the application changes from staying active to do not

exist in the WME MIB structure.

In the WBSS End caused by a deregistration request, there are two Test Pages

implemented, one when the application is using IPv6 and the other when not.

In Tests 12 and 13 a link is established, then a deregistration request is sent

followed by removing the link. The difference is the usage of IPv6 or not.

41

APP





PSID = 99

WME MLME


MLME-WSA.REQ

MLME-WSA.CFM

ResultCode : SuccessResult Code:Succes

WME-App.CFM

Event: WBSS Active

WME-Notification IND

Reason: Application Requested

MLME-WAVEEND.REQ

MLME-WAVEEND.CFM

ResultCode : Success

Event: WBSS Inactive




Registration Action: Remove ProviderPSID = 99

WME-AppRegistration.CFM ResultCode : Success

Figure 7.13: Provider-Not using IPv6-Deregistration request

Figure 7.14: Provider-Using IPv6-Deregistration request

42

PRIORITY

During the process of the provider registration some applications parameters are

stored in the WME MIB. One of these parameters is the priority. The Application

Priority has 8 bit with values from 0 to 63, where 63 is the highest priority. Each

provider application has a specific priority.

The standard IEEE 1609.3 defines that, when several applications want to join the

WBSS, it will be taken by the one with the highest priority.

Four Test Pages check the WME behavior if two provider Applications in the same

device want to join the WBSS link. The conflict is solved depending on the priority

of the Applications.

The process is different if the applications use IPv6 or not. There are two possible

situations:

There is an established link and a request of an Application with higher

priority than the active one arrives.

The request comes from an application with lower priority than the active

one.

The active application is called Application 1 and the application that requests to

join is called Application 2.

The basic execution of the test in the case when the Application which asks for the

link has higher priority than the active one is the following one:

1. Registration of Application 1 (priority = 30)

2. Request Activation of Application 1

3. Link establishment with the Application 1:

a. MLME-WSA.request (with the data of the Application 1)

b. MLME-WSA.confirm (result code success)

c. Application 1 activation confirmation (result code success)

d. Notification Indication to de Application 1 (link active)

4. Registration of Application 2 (priority = 35)

5. Request Activation of Application 2

6. End of the Link of the Application 1 (because Application 2 has higher

priority):

a. MLME-WAVEEND.request

b. MLME-WAVEEND.confirm (Result code = success)

c. Notification Indication to de Application 1 (link Inactive)

43

7. Link establishment with the Application 2:

a. MLME-WSA.request (with the data of the Application 2)

b. MLME-WSA.confirm (result code success).

c. Application 2 activation confirmation (result code success)

d. Notification Indication to de Application 2 (link active)

In this Test, none of the applications is using IPv6. This process is implemented in

the Test 16 (Not using IPv6_Higher priority) and summarized in the diagram in

Figure 7.15

APP1 WME MLME

MLME-WSA.REQ

MLME-WSA.CFMResultCode : Success

MLME-WAVEEND.REQ

MLME-WAVEEND.CFMResultCode: Success

APP2



WME-App

PSID = 99

.REQ

WME-App.CFM

WME-Notification.INDLINK ACTIVE



WME-App.REQ

WME-Notification.indLINK INACTIVE

WME-App.CFM

WME-Notification.indLINK ACTIVE

MLME-WSA.REQ

MLME-WSA.CFM

PRIORITY = 30 PRIORITY = 35

PSID = 99PRIORITY =30

Request = Active

PRIO = 30

Result: Success


Request = Active

PSID = 97PRIO = 35

ResultCode : SuccessResult: Success

Figure 7.15: Provider-Not using IPv6-Higher priority

The execution changes when Application 2 has lower priority than Application1:

- The registration and link establishment of the Application 1 is the same as

before

- Application 2 is registered with a priority of 25

- Application 2 asks for being activated

- The WME answers to Application 2: WME-Application.confirmation

primitive (Result Insufficient priority)

The link of Application 1 is not ended and Application 2 is informed that it is not

possible to get active because there is already one Application with higher priority

44

using the link. This functionality is implemented in Test 17 (Not using IPv6_Lower

priority).

APP1 WME MLME

MLME-WSA.REQ

MLME-WSA.CFMResultCode : Success

APP2



WME-App

PSID = 99

.REQ

WME-App.CFM

WME-Notification.INDLINK ACTIVE



WME-App.REQ

WME-App.CFM



Request = Active

PRIO = 30

Result: Success


Request = Active

Result: Insufficient priority

Figure 7.16: Provider-Not using IPv6-Lower priority

The aim of these Test Pages is to check that the WME distinguishes between the

applications priority and proceeds to the end or establishment of a link in the

appropriated situation. The different cases during the establishment of a WBSS

were not tested because is has been already tested in previous Test Pages (the

ones specially developed for the link establishment).

Tests 14 and 15 check the same situations but now the Applications are using

IPv6. As shown in Figures 7.17 and 7.18, the WME executes the link

establishment and completion including the MLME-RegisterTxProfile and MLME-

DeleteTxProfile primitives. This is because both applications have been registered

with the IPv6 parameters with a different value than zero. That means that both

are using IPv6.

45

Figure 7.17: Provider-Using IPv6-Higher priority

46

Figure 7.18: Provider-Using IPv6-Lower priority

CHANNEL INACTIVITY

In case of no activity on the channel, the MLME sends a primitive to the WME

called MLME-ChannelInactivity.indication. Immediately the WME proceeds to end

the link.

47

APP





PSID = 99

WME MLME


MLME-WSA.REQ

MLME-WSA.CFM

ResultCode : SuccessResult Code:Succes

WME-App.CFM

Event: WBSS Active



MLME-WAVEEND.REQ

MLME-WAVEEND.CFMResultCode : Success


Reason: Channel Inactivity


MLME-ChannelInactivity.IND

Figure 7.19: Provider-Channel inactivity-Not using IPv6

Test 19 (Channel Inactivity_NotIPv6) activates a link with a provider application

that is not using IPv6. Then, the WME receives the MLME-

ChannelInactivity.indication and the link is ended. Figure 7.19 shows this process.

When the application is using IPv6, the Register Transmitter Profile primitives

during the WBSS establishment and the Delete Transmitter Profile primitives are

added. This case is implemented in the Test 19 (Channel Inactivity_IPv6) and

illustrated in Figure 7.20.

48

APP





PSID = 99

WME MLME


MLME-WSA.REQ

MLME-WSA.CFM


Result Code:SuccesWME-App.CFM

Event: WBSS Active

WME-Notification.IND


MLME-RegisterTxProfile.REQ

MLME-RegisterTxProfile.CFM


MLME-WAVEEND.REQ

MLME-WAVEEND.CFMResultCode : Success



MLME-DeleteTxProfile.REQ

MLME-DeleteTxProfile.CFMResultCode : Success



Figure 7.20: Provider-Channel inactivity-Using IPv6

One important detail is that the standard IEEE 1609.4 (Source [3]) specifies that in

the provider side the WME ends the WBSS after receiving the Channel Inactivity

indication only in non-persistent systems.

The Test Suite developed in this project is only testing non-persistent systems.

7.3 User Test Suite

In the same situations, the WME does not have the same behavior for the provider

Application and for the user Application.

In the user case, there are thirty one Test Pages (marked in bold) distributed, like

in the provider case, in three main groups: application registration, link activation

and WBSS completion.

The structure of the test is similar to the provider ones, but the implementation

changes. It is really important that the WME distinguishes if an application is

working as a provider or a user.

49

The structure is the following:

UserSide

o RegisterRequestConfirm

RegisterOk

RegisterTwice

DeregisterTwice

RegisterDeregisterTwice

o Link Activation

AppNotMatch

NotConfBeforeJoin

ConfBeforeJoin

AppMatch

ConfBeforeJoin

o AppResponseNotSuccess

o AppResponseSuccess

WaveJoinCfmNotSuccess

Not Used IPv6

Used IPv6

WaveJoinCfmSuccess

Not Used IPv6

UsedIPv6

o RegTxProfileNotSuccess

o RegTxProfileSuccess

NotConfBeforeJoin

o WaveJoinCfmNotSuccess

Not Used IPv6

Used IPv6

o WaveJoinCfmSuccess

NotUsedIPv6

UsedIPv6

RegTxProfileNotSuccess

RegTxProfileSuccess

50

o WBSS Completion


IPv6

Not IPv6


IPv6

Not IPv6


IPv6

o Higher priority

NotConfirmBeforeJoin

ConfirmBeforeJoin

o Lower priority

Not IPv6

o Higher priority

NotConfirmBeforeJoin

ConfirmBeforeJoin

o Lower priority

Channel Inactivity

IPv6

Not IPv6

Application Unavailable request

IPv6

Not IPv6

7.3.1 Application registration

The functionality of the WME in the process of registration and deregistration is

the same for the user and for the provider. In one case it is asked for a provider

registration and in the other for a user registration. The diagrams that describe the

provider registration are valid for the user registration.

So, the four Test Pages for the registration are the following ones:

o RegisterRequestConfirm

RegisterOk TEST 1

RegisterTwice TEST 2

DeregisterTwice TEST 3

RegisterDeregisterTwice TEST 4

51

Figures 5.3, 7.3, 7.4 and 7.5 represent the register diagrams.

One field of the WME-ApplicationRegistration.request primitive that is used by the

user and not by the provider is the Confirm before join field. When this flag has the

value TRUE the WME has to ask the user’s application entity for the confirmation

of the link establishment. This situation is tested in the Link Establishment in the

user part.

The rest of fields have been explained previously in the subchapter 7.2.1.

7.3.2 Link Activation

The structure of the link activation is the following:

o Link Activation

AppNotMatch

NotConfBeforeJoin TEST 5

ConfBeforeJoin TEST 6

AppMatch

NotConfBeforeJoin

ConfBeforeJoin

The subchapters NotConfBeforeJoin and ConfirmBeforeJoin are described later in

this subchapter.

Taking a look in the whole system, when a link is established in the provider

application, a WAVE Announcement frame is send over the air. This frame arrives

at the other WAVE device and its MLME sends the information to the WME via the

primitive MLME-WSA.indication. This information provides the service offered by

the provider application.

When the WME receives this primitive it checks if, there is a registered application

in the UserServiceInfo structure of the MIB with the same PSID as the provider. If

there is no match, the WME will do nothing because it has no user application

waiting for being provided by the offered service.

52

Figure 7.21 shows how, in case of no application match the WME does not

establish a link in the user part. The MLME-WSA.response ResultCode is success

because it indicates that the secured WSA is authenticated successfully. So, this

primitive is not indicating anything about the match of the application.

In all the diagrams of the user, the order of the entities is MLME-WME-Application.

In the case of no match there are two cases tested. Test 5 checks when the user

application has the Confirm Before Join not active, then, the WME has not to send

a MLME-WAVEJOIN.request(the primitive that starts with the joining of the link) to

the MLME. Test 6 deals with the Confirm Before Join active. Additionally is

checked that the WME is asking to the application about the activation of the link

with a WME-Application.indication. The main difference between these two

situations is that if the flag is active, the WME asks to the application before of

joining the link and when is not active, the link is joined directly without the

confirmation of the application. So, in Test 5 and Test 6 is checked that none of

these processes happens because the link establishment should be stopped if

there is no match.

Figure 7.21: User-Application not match

AppMatch

ConfBeforeJoin

o AppResponseNotSuccess TEST 7

o AppResponseSuccess

WaveJoinCfmNotSuccess

Not Used IPv6 TEST 8

Used IPv6 TEST 9

WaveJoinCfmSuccess


UsedIPv6

53

o RegTxProfileNotSuccess

TEST 11

o RegTxProfileSuccess

TEST 12

If there is a match between the PSID of the user and the provider, the first action

of the WME is to check in the user’s application information if the Confirm Before

Join is activated. In this case the WME sends a WME-Application.indication to the

Application entity.

The application will send in the field Link Confirm of the WME-

Application.response primitive either the value TRUE or FALSE depending if the

application chooses to join the offered WBSS or not. In the case of a Link Confirm

value of FALSE, the process of link establishment will stop.

In Test 7 (AppResponseNotSuccess) it is proven that after a negative response

from the application, the WME is not sending the WAVEJOIN request primitive to

the MLME.

Figure 7.22: User-Match-Confirm before join-Application rsp not success

When the user’s application chooses to join the WBSS, the WME starts with the

link process by sending a MLME-WAVEJOIN.request to the MLME. After this, the

MLME answers with a MLME-WAVEJOIN.confirm. The Tests 10, 11 and 12 deal

with the situation if the result code from this primitive is set to success.

Test 10 is dealing with the case if the provider application is not using IPv6. Then,

the WME informs the user’s application with a WME-Notification.indication with the

value Link Active in the field Event. This sequence is shown in Figure 7.23.

54

Figure 7.23: User-Match–Cfm success–Join success-Not using IPv6

If the provider application is using IPv6, the IP parameters of the WSA received

from the MLME are not zero.

If IPv6 is used, the transmitter profile has to be registered. This is done by the user

before informing the Application about the link establishment

.

A success link establishment using IPv6 is investigated in Test 12 and the

sequence of primitive exchange between the entities is illustrated in Figure 7.24.

Figure 7.24: User-Match-Cfm success-Join success-Using IPv6 success

If during the registration of the transmitter profile process, the MLME sends a

negative confirmation, the process is stopped. This means that there will be no

notification sent to the Application. This is checked in Test 11 by sending a MLME-

55

RegisterTxProfile.confirm with Result Code Invalid Parameters to the WME. Then,

it is proven that the WME is not sending any WME-Notification.Indication to the

Application. Otherwise the Application would think that there is an active link,

which is not true because the process has been stopped. Figure 7.25 presents

Test 11.

MLME


WME-AppRegistration.REQRegistration Action: Add User


PSID = 101

WME APP

MLME-WSA.INDPSID = 101

MLME-WSA.RSP

MLME-WAVEJOIN.REQ

MLME-WAVEJOIN.CFM


ResultCode : Invalid Parameters




WME-Application.RSP

WME-Application.IND

Link Confirm = TRUE

Figure 7.25: User-Match–Cfm success-Join success-Using IPv6 DeleteTxprofile not success

The other situation, where the process is stopped, is when the MLME answers

with a MLME-WAVEJOIN.cfm with the Result Code Invalid Parameters, which is

implemented in Tests 8 and 9. Again with the distinction of the provider application

is using IPv6 or not. These two cases are distinguished because, if using IPv6 it

has to be checked that the WME is not continuing with the process. This means

that it is not sending a MLME-RegisterTxProfile.request and a WME-

Notification.indication. If IPv6 is not used it is only checked that the WME is not

sending the Notification to the application.

56

MLME




PSID = 101

WME APP


MLME-WSA.RSP

MLME-WAVEJOIN.REQ

MLME-WAVEJOIN.CFM


Result Code: Invalid Parameters

WME-Application.RSP

WME-Application.IND

Link Confirm = TRUE

Figure 7.26: User-Match–Cfm success–Join not success-Using and not using IPv6

All the link processes explained until now are for a user application with the

Confirm Before Join flag set as TRUE.

The next part of the Test Suite structure deals with the Confirm Before Join flag

set to FALSE.

NotConfBeforeJoin

o WaveJoinCfmNotSuccess


Used IPv6 TEST 14

o WaveJoinCfmSuccess

NotUsedIPv6 TEST 15

UsedIPv6

RegTxProfileNotSuccess

TEST 16

RegTxProfileSuccess TEST 17

The test structure is the same as in the previous part of the Confirm Before Join in

the case when the application chooses to join. The difference during the execution

is that the WME does not ask the application about the link establishment. It only

informs the application after the link is set up

The Not Confirm Before Join tests will not be explained in detail because this

structure was already explained in the previouse Confirm Before Join tests. The

57

focus will be the differences between Confirm Before Join tests and Not Confirm

Before Join tests.

The following four diagrams in Figures 7.27, 7.28, 7.29 and 7.30 represent the

sequence of primitive exchange of the NotConfirmBeforeJoin part.

The functionality of Tests 13 and 14 correspond to the one of the previous Tests 8

and 9. As before, it is checked that no WME-Notification.indication is sent to the

application. Additionally, in Test 14 it is proven that the WME does not execute the

registration of the transmitter profile.

Figure 7.27: User-Match-Not cfm before join-Join not success-Using and not using IPv6

Test 15 executes the same as Test 10 but without the exchange of primitives used

to confirm the link activation.

Figure 7.28: User-Match-Not cfm-Join success-Not using IPv6

58

The functionality of Tests 16 and 17 sequence corresponds to the one of Tests 11

and 12, but without asking to the application for a confirmation before the

establishment of the link.

Figure 7.29: User-Match-Not cfm before join-Join success-Using IPv6-REGTXPROF success

Figure 7.30: User-Match-Not cfm before join-Join success-IPv6-REGTXPROF not success

Although both structures (ConfirmBeforeJoin and NotConfirmBeforeJoin) execute

the same functionality only with the difference in the step of the application

confirmation of the link, the big importance of the implementation of this tests is

that the correct behavior of the WME is implemented. This means that, the fact of

having this flag with different values does not modify the link process in any step.


All the user side, the WBSS can be ended because of different reasons:

The active application asks for being deregistered.

The active application asks for inactivation.

59

A higher priority application demands a WBSS.

The WME receives a primitive called MLME-ChannelInactivity.indication.

This primitive indicates that there is no activity on the current channel and

the WBSS should be ended.

The received WSA with the security credentials not correct.

The last case is not included in this Test Suite. This is because with the FitNesse

fixtures it is not possible to change the security characteristics of the WSA sent

from the MLME.

Like in the provider case, I assumed that is does not happen the situation when

the WBSS completion process is stopped by the MLME of the Application Entity.

This means that no confirmation primitive answers with a negative result. The

reasons for taking this criterion are the same as mentioned in subchapter 7.2.2.

In all the cases of end of WBSS the sequence of primitive exchange used in order

to finish the link is the same. The difference is the previous conditions.

The structure of the WBSS in the user part is the following one:

o WBSS Completion


IPv6 TEST 18

Not IPv6 TEST 19


IPv6 TEST 20

Not IPv6 TEST 21


IPv6

o Higher priority

NotConfirmBeforeJoin TEST 22

ConfirmBeforeJoin TEST 23

o Lower priorityTEST 24

Not IPv6

o Higher priority

NotConfirmBeforeJoin TEST 25

ConfirmBeforeJoin TEST 26

Lower priority TEST 27

60

Channel Inactivity

IPv6 TEST 28

Not IPv6 TEST 29

Application Unavailable request

IPv6 TEST 30

Not IPv6 TEST 31

APPLICATION DEACTIVATION

When the user’s active application asks for inactivation, the link has to be ended.

The process starts when the user application sends a WME-Application.request

asking for deactivation. With this information, the WME knows that the application

is not any more active and starts with the completion of the link. If the provider

application is using IPv6 (Test 18) the WME sends a MLME-

DeleteTxProfile.request. After this step, it sends a MLME-WAVEEND.request to

the MLME in order to end the link. Once the link is ended, the WME confirms the

inactivation request to the application and informs it of the end of the link with the

WME-Notification.indication primitive with the Reason’s value Application Request.

When an application is changing to inactive, in fact what is happening is that in the

ApplicationStatusTable the field called ApplicationStatus that corresponds to this

application is changing to inactive.

61

Figure 7.31: User-Application deactivation-Using IPv6

Figure 7.32 shows the primitive exchange sequence when the process application

is not using IPv6, this is implemented in Test 19. In this case, the Transmitter

Profile primitives are not used.

62

MLME




PSID = 101

WME APP


MLME-WSA.RSP


MLME-WAVEJOIN.REQ

MLME-WAVEJOIN.CFM

Event: Link Active



WME-Application.REQ

Request type : InactivePSID = 101MLME-WAVEEND.REQ

MLME-WAVEEND.CFM

ResultCode : SuccessWME-Application.CFM



Event: Link Inactive


Figure 7.32: User-Application deactivation-Not using IPv6

APPLICATION DEREGISTRATION

The application deregistration of the active user application implies the end of the

link.

This time, the application sends a WME-ApplicationRegistration.request with the

Registration Action value equal to Remove User. When the WME receives this

request, it goes to the ApplicationStatusTable and realizes that before removing

the information about this application has to end the link because the application

that requests is the active one..

The end of the link, like in the other cases, is done by the exchange of the MLME-

DeleteTxProfile and the MLME-WAVEEND. After this end of the link, the WME

deletes the information of this application in the ApplicationStatusTable and the

UserServiceInfo. Then the WME-ApplicationRegistration.confirm is sent to the

application to inform it that the deregistration is already successfully done. The

WME communicates the WBSS end to the application with a WME-

Notification.indication with the Reason’s value equal to Application Requested.

63

MLME




PSID = 101

WME APP


MLME-WSA.RSP


MLME-WAVEJOIN.REQ

MLME-WAVEJOIN.CFM

Event: Link Active






MLME-DeleteTxProfile.CFM



MLME-WAVEEND.REQ

MLME-WAVEEND.CFM







Registration Action:Remove UserPSID = 101


Figure 7.33: User-Application deregistration-Using IPv6

Like in the deactivation application I have developed two testes, one for the

provider application using IPv6 (Test 20) and the other test for the not use of IPv6

(Test 21).

In the IPv6 case there are exchanged the MLME-DeleteTxProfile primitives before

of the end of the WBSS. Both deregister test process are illustrated in Figures

7.33 and 7.34.

64

Figure 7.34: User-Application deregistration-Not using IPv6

PRIORITY

As in the provider part, the Active application of the link depends on the Priority

field. The big difference in the user part is that the priority comes from the provider

application, so, the user application during the registration does not specify its

priority.

During the link activation, the user’s WME receives a WSA with the data of the

provider application. The priority of this application is assigned to the user

application with the same PSID.

After a successful link establishment, if the user receives a request from other

provider application being registered a user application with the same PSID, the

WME has to decide if continuing with the actual link or changing to a new one with

the last application active. The decision depends on the priority of both

applications.

65

Depending if the provider application is using IPv6 or not the process will be

different during the link establishment and end. Tests 22, 23 and 24 execute the

IPv6 case.

In Test 22 (IPv6 _Higher priority_NotCofirmBeforeJoin) a WBSS with a provider

application using IPv6 is established .This application has a priority of 30 and I call

it Application 1. Later on, a MLME-WSA.request arrives with the offered service of

another provider application using IPv6 with priority 35 (the Application 2). Then,

the WME realizes that there is a user application registered with the same PSID

that the Application 2. After checking the priority, it decides to end the link of the

Application 1 and start a link with the Application 2.

Figure 7.35: User-New application-Using IPv6-Higher priority-Not cfm before join

66

Figure 7.35 shows the process of the process followed in Test 22(IPv6 _Higher

priority):

1. User Application 1 registration

2. User Application 2 registration

3. MLME-WSA.indication from provider application with same PSID that

Application 1, with priority = 30 and using IPv6

4. MLME-WAVEJOIN.request and confirm to establish the link in the user part

5. MLME-RegisterTxProfile primitives exchange because the provider of the

Application 1 is using IPv6

6. WME-Notification.indication to the Application 1 with the Event Link Active

7. MLME-WSA.indication from provider application with same PSID that

Application 2, priority 25 and using IPv6

8. MLME-DeleteTxProfile primitives exchange, this is because the provider of

the Application 1 is using IPv6

9. WME-Notification.indication with the Event Link Inactive and the Reason

Priority Preemption

10. MLME-WAVEJOIN.request and confirm, now is the link establishment of

the Application 2

11. MLME-RegisterTxProfile primitives exchange because the provider of the

Application 2 is using IPv6

12. WME-Notification.indication to the Application 2 with the Event Link Active

An extra test in the higher priority has been added. This test checks the same

case than before but now, the second Application has active the flag Confirm

before Join. That means that, before proceeding to the end of the link of the

Application 1, the WME confirms if the Application 2 wants to join. In Test 23

(UsedIPv6 _HigherPriority_ConirmBeforeJoin) the Application 2 does not want to

join, so, the first link is not ended. The implementation of this test is in Figure 7.36.

67

APP1WMEMLME

MLME-WSA.IND

APP2



PSID = 101


PSID = 101

PRIO = 30

Result Code : Success

MLME-WSA.RSP

MLME-WAVEJOIN.REQ

MLME-WAVEJOIN.CFM



WME-Notification.INDEvent: Link Active


MLME-RegisterTxProfile.CFMResult Code: Success


PRIO = 35


PSID = 103Confirm Before Join = TRUE

MLME-WSA.RSPResult Code: Success

Result Code : SuccessWME-AppRegistration.CFM

WME-Application.IND

WME-Application.RSP

Link Confirm = FALSE

Figure 7.36: User-New application-Using IPv6-Higher priority-Cfm before join

The process of Test 24 (UsedIPv6 _LowerPriority) is shown in Figure 7.37.

68

APP1WMEMLME

MLME-WSA.IND

APP2



PSID = 101


PSID = 101

PRIO = 30


MLME-WSA.RSP

MLME-WAVEJOIN.REQ

MLME-WAVEJOIN.CFM





MLME-RegisterTxProfile.CFMResult Code: Success


PRIO = 25

WME-AppRegistration.REQPSID = 103


Result Code = SuccessWME-AppRegistration.CFM

Figure 7.37: User-New application-Using IPv6-Lower priority

In this Test both provider applications are using IPv6 as well. Now, the second

application has lower priority than the first. That means that the WME decides to

continue with the actual link and ignore the request of the second application.

The link establishment of the Application 1 is the same than before. After receiving

the MLME-WSA.indication, the WME responds with the MLME-WSA.response

with Result Code Success because the security credentials of the WSA are

correct and then, it does not do anything more because is not allowing the link

with the Application 2. This fact is checked by the use of the Wait4Call fixture,

detecting that no WAVEJOIN request is sent to the MLME. The

ResetWait4CallStates fixture is positioned before the MLME-WSA.indication table

because is the primitive that makes that the WME generates the WAVEJOIN

request.

In Tests 25, 26 and 27 none of the provider applications that offer a service to the

user are using IPv6.

Test 25 (NotUsedIPv6_HigherPriority) checks the same priority situation that Test

22 (UsedIPv6_HigherPriority). As it is shown in Figure 7.38 the difference is that

now, the Transmitter Profile primitives are not used.

69

Figure 7.38: User-New application-Not using IPv6-Higher priority-Not cfm before join

Test 26 (NotUsedIPv6_Higher_Priority_ConfirmBeforeJoin) and Test 27

(NotUsedIPv6_LowerPriority) are the analogue of Tests 23 and 24 without using

IPv6. These processes are illustrated in Figures 7.39 and 7.40. The difference is

that is not registered the Transmitter Profile in the MLME.

70

Figure 7.39: User-New application-Not using IPv6-Higher priority-Cfm before join

APP1WMEMLME

MLME-WSA.IND

APP2



PSID = 101


PSID = 101

PRIO = 30


MLME-WSA.RSP

MLME-WAVEJOIN.REQ

MLME-WAVEJOIN.CFM





PRIO = 25


PSID = 103


Result Code : SuccessWME-AppRegistration.CFM

Figure 7.40: User-New application-Not using IPv6-Lower priority

71

All these priority tests in the user part are working with the Application 1 with the

flag Confirm Before Join not activated. I have chosen this option because it

simplifies the test the behavior of the WME when this flag is active, it has not

influence in the priority process and it is already tested during the Link

establishment part.

CHANNEL INACTIVITY

Exactly as in the provider, the MLME generates a primitive when there is not

longer activity in the indicated channel. This fact makes that the WME end the link.

In the provider, this completion of WBSS is only happening when there is a non-

persistent system. In the user part it is always ended, independently of the kind of

WAVE system.

The behavior of the WME after receiving a MLME-ChannelInactivity.indication is

checked in Tests 28 and 29. The difference between these tests is that in Test 29,

the provider application that joins the WBSS is not using IPv6. Figure 7.41 shows

the primitives exchange during this test.

MLME




PSID = 101

WME APP


MLME-WSA.RSP


MLME-WAVEJOIN.REQ

MLME-WAVEJOIN.CFM

Event: Link Active



MLME-WAVEEND.REQ

MLME-WAVEEND.CFM






Figure 7.41: User-Channel inactivity-Not using IPv6

72

Test 28 (Figure 7.42) analyzes the same situation but the provider application is

using IPv6. So, the RegisterTransmitterProfile primitives are used for the link join

and the DeleteTrasnmitterProfile primitives for the WBSS completion.

MLME




PSID = 101

WME APP


MLME-WSA.RSP


MLME-WAVEJOIN.REQ

MLME-WAVEJOIN.CFM

Event: Link Active






MLME-DeleteTxProfile.CFM



MLME-WAVEEND.REQ

MLME-WAVEEND.CFM






Figure 7.42: User-Channel inactivity-Using IPv6

After the study of the standard IEEE 1609.3, I arrived to the conclusion that when

it is end a link in the provider side, it is not notifying to the user this completion of

the link. It is the same in the other side. Practically, one part realizes if the other

has closed the link because it receives a channel inactivity indication and then, it

proceeds to finish the link too. So, when one side of the link is completing the

WBSS, the link is end in both devices.

The Channel Inactivity warning does not come from the device that is finishing the

link, it is generated by the device itself when it detects that there is not activity.

This fact makes that the reception of a channel inactivity indication is not always

caused by the end of the link in the other side. It could be generated, for example,

73

when because of extern reasons the signal does not arrive from the provider to

the user. Is important do not forget the not constant conditions of the environment

of the WAVE systems.

APPLICATION UNAVAILABLE REQUEST

In this point, before explaining the Test process it is better to describe the possible

status of an application.

Until now, the two possible status of an application has been active or inactive for

provider and user case. There is an extra status for the user application called

unavailable. In this status, the information about the application stays in the MIB

but, for the WME is like if it was not registered. So, in case of receiving an MLME-

WSA.indication with the same PSID, it will not be established the WBSS because

the WME ignores these application because of the status.

MLME



Registration Action: Add User


PSID = 101

WME APP


MLME-WSA.RSP


MLME-WAVEJOIN.REQ

MLME-WAVEJOIN.CFM

Event: Link Active



WME-Application.REQ

Request type : Unavailable

PSID = 101MLME-WAVEEND.REQ

MLME-WAVEEND.CFM

ResultCode : SuccessWME-Application.CFM







WME-Application.REQ

Request type : Inactive

PSID = 101

WME-Application.CFM


Figure 7.43: User-Unavailable request-Not using IPv6

74

When an application asks for the unavailable state, the process done by the WME

is the same as if it was asking for deregistration. The only difference is that the

information about the application is not deleted from the WME MIB.

Tests 30 and 31 deal with the unavailable request case when the application is

using IPv6 and not.

As is shown in Figures 7.43 and 7.44, if a link is established and the active

application sends the unavailable request. The WME proceeds to end the WBSS.

MLME




PSID = 101

WME APP


MLME-WSA.RSP


MLME-WAVEJOIN.REQ

MLME-WAVEJOIN.CFM

Event: Link Active






WME-Application.REQ

Request type : Unavailable

PSID = 101MLME-DeleteTxProfile.CFM



MLME-WAVEEND.REQ

MLME-WAVEEND.CFM

ResultCode : Success WME-Application.CFM




Reason: Application RequestedMLME-WSA.IND

PSID = 101

MLME-WSA.RSP

WME-Application.REQ

Request type : Inactive

PSID = 101WME-Application.CFM


Figure 7.44: User-Unavailable request-Using IPv6

75

Chapter 8

WAVE Radio Frequency Parameters

Continuing the development of the test suite further requirements of the WAVE

systems were tested in this project. These requirements define the radio

frequency characteristics of the frontend of a transmitter.

All the tests mentioned until now have been concentrated on the network layer

behavior. Now the spectral characteristics of the transmitted signal are tested.

The draft standard IEEE 802.11p defines the physical layer specifications for

WAVE systems (Source [4]). There is especially one chapter dedicated to the

OFDM (Orthogonal Frequency Division Multiplexing) PHY specification in the 5

GHz band, where the transmit requirements are specified.

One of these specifications is the spectrum mask of the transmitted signal.

There are four different classes (A, B, C and D) of the transmitted signal defined.

These four classes are defined in the document FCC CFR 47 (Source [8]) which is

mentioned in the IEEE 802.11p.

The difference between the classes is the output powers and the requirements on

the spectrum masks.

Figure 8.1 shows the range of power of each class.

RSU class

Max. outputPower (dBm)

A 0 B 10 C 20 D 28.8

Figure 8.1: Power of the classes (Source [5])

The transmitted signal is the signal directly after the transmitter, before the

antenna. This means the power without the antenna gain.

Figure 8.2 shows the maximum power in dBr for several frequencies. These

values are for operations using 10 MHz channel spacing.

76

Reduction in Power Spectral Density, dBr

Device Class

± 4.5 MHz Offset

± 5.0 MHzOffset

± 5.5 MHzOffset

± 10 MHzOffset

± 15 MHz Offset

Class A 0 -10 -20 -28 -40 Class B 0 -16 -20 -28 -40 Class C 0 -26 -32 -40 -50 Class D 0 -35 -45 -55 -65

Figure 8.2: Spectrum masks for classes A, B, C and D (Source [4])

The complete shape of the standard spectrum masks is calculated from the values

of Figure 8.2 using interpolation. So, if the spectrum of the received signal has the

same or lower value than the masks, the device is inside of the specifications of

the standard.

77

Chapter 9

Tool for the Radio Frequency Test

The implementation of the test was done with the LabVIEW program, from

National Instruments (Source [7]).

9.1 Overview of the Program

LabVIEW is a graphic tool used to design data acquirement systems,

instrumentation and control through software programming. The language which is

used is called G. In this language the routines are represented by icons grouped

in thematic libraries.

The programs developed with LabVIEW are called Virtual Instruments (VIs).This

gives an idea of the usage: controlling instruments.

Unlike other programming languages which use line of text through instructions

(C, Basic, C++, etc), LabVIEW uses programming based on data flows. The data

flow over the code, which has been implemented in graphic format, is modified as

it moves through the implemented elements. The flow of the data determines the

implementation of the program.

In more specific, LabVIEW graphical programming is structured as follows:

The interactive user interface of a VI is called front panel, because it simulates

the physical instrument panel. The front panel may contain buttons, switches,

graphics and other controls and indicators. The input data is entered with the

mouse and the keyboard, and the results are displayed on the computer screen.

The VI receives instructions from a block diagram which is built in G. The block

diagram is the graphics solution of a particular programming problem. In addition,

the block diagram is the source of the program (VI).

LabVIEW has the advantage of an easy integration of hardware, especially of

measurements with measuring devices, acquisition and data processing (including

imaging). It is often used in systems for monitoring processes.

78

9.2 Advantages of Using LabVIEW Some of the reasons making the choice of LabVIEW to a good option are listed in

the following:

The first reason is that LabVIEW is compatible with similar development tools and

can work with programs of another area of application, as Matlab or Excel. In

addition, it can be used in many operating systems, including Windows and UNIX

because the code is transportable from one to another.

The fact that it is a program focused on the virtual instrumentation implicates many

presentation tools, graphics, buttons, indicators and controls, which are very

schematic and versatile. These would be complicated to carry out in languages

like C++, where the time to achieve the same effect would be much higher

LabVIEW has the advantage of an easy integration of hardware, especially of

measurements with measuring devices, acquisition and data processing (including

imaging). It is often used in systems for monitoring processes.

Since the programming is developed by the creation of subroutines in modules of

blocks, it is also possible to use blocks from other users.

79

Chapter 10

WAVE Radio Frequency Parameters Test

The target of this part of the project is to acquire the spectrum of the signal and

analyze it.

The measurement device used is the spectrum analyzer HP 8593E (source [9]),

which is remote controlled with a LabVIEW program over bus GPIB (General

Purpose Instrumentation Bus) connection. A graphical interface is implemented.

This interface allows interacting with this spectrum analyzer.

The transmitter is directly connected to the Spectrum Analyzer.

Figure 10.1 shows the measurement setup of this test.

LabVIEW

GPIB BUS

DUT

SPECTRUM ANALYZER

Figure 10.1: Devices connection

10.1 GPIB Standard

GPIB is a digital interface where up to 15 devices or instruments can communicate

with each other under the supervision of a monitor unit where we use a computer

as teacher unit. This is of great importance, since with an efficient use of this

feature several advantages can be achieved, including the generation of

interfaces to monitor and control instruments which are located in different areas,

from a single room.

The connected devices may either be a system controller ("chairman"), listener or

talker. The computer includes all these three functions and in our case the device

connected to the GPIB bus (the spectrum analyzer) is able to talk and listen.

80

Each device on the GPIB bust must have a unique address, which is established

in the device itself. Communication between devices is done with device-

dependent messages and interface messages through the interface system. In my

developed test, there is a single instrument which communicates with the

controller.

There are three kinds of exchanged messages:

Commands: cause the instrument to perform an action. One example can

be the take of the measurement.

Data units: are used to exchange the information. One example of data unit

is the value of the power of the signal at the different frequencies that the

spectrum analyzer will pass to the computer.

Queries: are used by the controller to generate a response from the device.

An example is the identification query, where the controller asks the device

about its identification and the device returns the manufacturer, model,

serial number and firmware level.

10.2 Test Execution

The front panel represents the interface with the user. This panel is shown in

Figure 10.2.

Figure 10.2: Front panel

81

There exists a predefined panel for measuring the frequency spectrum. The user

specifies the GPIB direction of the spectrum analyzer (a list with the different

addresses of the devices connected to the computer will appear). Also the center

frequency of the signal has to be set.

After running the test, the value of the maximum power of the signal and the class

will appear in the foreseen boxes. In a screen the spectrum of the signal and the

correspondent mask (depending of the class of the signal) defined in the standard

are visualized.

The unit of the power is dBr (relative to the maximum) and the frequency is

displayed in offset frequency. With these settings the measured spectrum can be

compared with the required spectrum mask of IEEE 802.11p.

10.3 Test Development

Basically, the actions of this test are:

Remote control of the spectrum analyzer

Obtaining the signal

Comparison with the correspondent spectrum mask

Show the results.

Using the remote control I set the center frequency, resolution filter bandwidth,

video filter bandwidth, span and Source level from the spectrum analyzer.

Center frequency: it is introduced by the user and will depend on the

channel used for the measurements. The channels are defined in the

standard IEEE 802.11p

Span: it is the bandwidth that will be represented in the screen of the

spectrum analyzer. The value used in this test is 40 MHz which is defined in

IEEE 802.11p.

Source level: it indicates the level of the signal at the top of the screen. The

selected value is 30 dBm, because the maximum transmitted power is 28.8

dBm. So this value of Source level ensures that every signal sent will be

totally visualized.

Resolution filter bandwidth: the bandwidth of the resolution filter affects the

measurement in two ways. The first one is that the sweep rate increases

with the bandwidth. The second one is that there occurs less noise, when

the resolution bandwidth decreases. The standard specifies a resolution

bandwidth of 100 kHz.

Video filter bandwidth: it is used to soften or eliminate the peaks of short-

term noise. The standard specifies a filter bandwidth of 30 kHz.

82

In order to communicate with the spectrum analyzer there are two basic ways, the

Visa protocol and the drivers.

Visa protocol, is a low level language. It can operate with message based

instruments, which transmit chains of ASCII characters. There are only five

sending/receiving commands between the PC and the instrument: Visa Read,

Write Visa, Visa Assert Trigger, Clear Visa, Visa Read STB.

The LabVIEW drivers are higher level and based on Visa commands. In this test

the hp 859X devices drivers are used.

The first remote access to the spectrum analyzer is executed with the driver called

initialize.vi. It establishes the connection between computer and device, especially

initialize.vi opens a Visa session for the device. It needs the GPIB address of the

spectrum analyzer that is introduced by the user.

Figure 10.3 shows the part of the test which, having as entry the address of the

device, uses the driver that initializes the spectrum analyzer.

Figure 10.3: Establishment of the connection

Other drivers are used to set important measurement parameters. These

parameters are explained above. In Figure 10.4 is the part of the graphic code that

set them.

83

Figure 10.4: Set of parameters

The Write Visa command is used to set the reference level.

Figure 10.5: Set of reference level

After the configuration of the device, the measurement can start.

The received signal is an OFDM modulated signal as defined in IEEE 802.11p.

When I talk about “the signal”, I mean the whole 10 MHz OFDM signal including all

subcarriers. This means that the investigated signal is the envelope of all

subcarriers. A schematic of this signal is shown in Figure 10.5.

Figure 10.6: Received signal

84

Before acquiring the data, the maximum hold is set, which is useful for displaying

modulated signals, which appear unstable otherwise. With this option a time, until

the signal appears stable has to be set. Based on empirical knowledge the delay

time is set to 20 seconds. Afterwards, drivers are used to set the trigger and to get

the data. The driver called Read Waveform to Array.vi provides the frequency and

power data.

Then, the Visa session is closed because the program is not going to interact any

more with the spectrum analyzer.

The aim of the test is to check if the signal follows the requirements. The spectrum

mask of the standard is compared with the measured signal. I implemented four

different blocks which return the spectrum masks of the classes A, B, C and D.

The function of these blocks generates the same number of points that are coming

from the spectrum analyzer with the value of the corresponding spectrum masks.

The standard specifies the value of some specific points, so, the rest of them are

calculated by interpolation.

Depending on the maximum power is determined the class and generated the

mask values. Then, both, the signal and the mask are represented.

10.4 Results of the Tests The automation in acquiring the signal allows a fast check of the quality of the

investigated signal.

Another advantage of this method is that the measured spectrums can be easily

saved and therefore easily compared with results from other devices. It is easy to

check if the investigated device is following the requirements of the standard.

In the case of a negative requirement test, the user is able to check how far away

the device is from the specifications.

One example of a test result is Figure 10.7:

85

Figure 10.7: Example of Test Result

The received signal is the white one, and the standard spectrum mask is the red

one.

In this last example, the received signal is working at a center frequency of 5.92

GHz and the considered class is the class A (the power is less than 0 dBm). We

can see that the measured spectrum follows the specifications of the standard,

because the signal is always below the maximum limit over the whole frequency

range.

86

Chapter 11

Conclusion

After developing this Thesis I realized that, especially in the management plane

part, the time that is invested in the test development part is in the same range as

the development of the software that is tested.

This is because I had the same phase of studying the standard specifications that

the software developers. Another option was that the developers were explaining

me the functionality of the device and I just have to check it. This is not a correct

way because the standards can be a bit diffuse in some parts. At the end, the

implementation of a standard is an interpretation of the developer. It is good that

the developer and tester study separated the standard and get their own

conclusions. Another reason is that the testing tool requires a code generation

which takes time.

Although there was an important quantity of time invested in testing the

functionality of the software, this is necessary for the producer because of

following reasons.

The importance of the test part in a device development process lays in the fact

that it proves that this device will act correctly in the established actions. In my

case, the process of test and software development was done in parallel. This was

an advantage for the software developer because the errors where not carried

until the end of the process and where solved step by step.

Another point is that a test suite result is really useful in the case of having

potential costumers of the product, because these results show the capabilities of

the device.

An extra contribution of the test suite in the develop process is that it shows how

far the characteristics are from the requirements of the standard. One example is

the part of the frequency characteristics test. In this situation, the test allows to see

how far the spectrum of the signal is from the standard spectrum masks.

In this Diploma Thesis I implemented the test of non persistent systems. To be

able to ensure that a device is following the whole IEEE 1609.3 standard there

should be extra tests added, checking the functionality of persistent systems

(when some applications from a device are using a link at the same time).

87

88

Sources

[1] IEEE standard 1609.0 “IEEE Trial-Use Standard for Wireless Access in

Vehicular Environments (WAVE)-WAVE Architecture”, February 2007.

[2] IEEE standard 1609.3, “IEEE Trial-Use Standard for Wireless Access in

Vehicular Environments (WAVE)-Networking Services”, 20 April 2007.

[3] IEEE standard 1609.4, “IEEE Trial-Use Standard for Wireless Access in

Vehicular Environments (WAVE)-Multi-channel Operation”, 29 November 2006.

[4] IEEE P802.11pTM/D4.0, “Draft Standard for Information Technology -

Telecommunications and information exchange between systems - Local and

metropolitan area networks - Specific requirements – Part 11: Wireless LAN

Medium Access Control (MAC) and Physical Layer (PHY) specifications,

amendment 8: Wireless Access in Vehicular Environments “, March 2008.

[5] ASTM E 2213-03, "Standard Specification for Telecommunications and

Information Exchange Between Roadside and Vehicle Systems - 5.9 GHz Band

Wireless Access in Vehicular Environments (WAVE) / Dedicated Short Range

Communications (DSRC) Medium Access Control (MAC) and Physical Layer

(PHY) Specifications".

[6] Manual of FitNesse Program: http://fitnesse.org/

[7] Official page of LabVIEW National Instruments program: www.ni.com/labview

[8] FCC CFR 47, FCC (Federal Communications Commission) rules and

regulation. Title 47 of the CFR (Code of Federal Regulations)

[9] Agilent official web page: www.agilent.com

http://www.ni.com/labview

ANNEX I: PRIMITIVES DESCRIPTION In this Annex, the primitives defined in the standards IEEE 1609.3 (Source [2])

and IEEE 1609.4 (Source [3]) are described.

WME-Application.request o Function

The WME-Application.request primitive allows a provider application to request the

initiation of a WBSS, or a user application to control whether or not to be notified

of a WBSS, or either type of application to end a WBSS.

o Semantics of the service primitive

The parameters of the WME-Application.request primitive are as follows:

WME-Application.request(

ProviderServiceIdentifier,

ProviderServiceContext,

RequestType,

Peer MAC address (optional),

Repeats (optional),

Persistence,

ChannelSelection (optional)

)

o When generated

The WME-Application.request primitive is generated by an application to request a

WBSS establishment, or request a change to the application’s WBSS status, or a

change to the PSC of an active service. When the RequestType equals Active,

then the Peer MAC Address, Repeats, Persistence, and ChannelSelection

parameters are included.

o Effect of receipt

Upon receipt of the WME-Application.request primitive, the WME attempts to

establish a WBSS, or sets the application Inactive (and possibly ends its operation

on a WBSS), or sets the application status to Unavailable, depending on the

RequestType. The SecurityType value indicates the security processing (defined

in IEEE Std 1609.2) expected of the receiving application.

WME-Application.confirm o Function

The WME-Application.confirm primitive is used to indicate the status of an

application request.


1

The parameters of the WME-Application.confirm primitive are as follows:

WME-Application.confirm(

ResultCode

)

o When generated

The WME-Application.confirm primitive is generated in response to, and indicates

the result of, a WME-Application.request.

o Effect of receipt

The requesting application may take action based on the ResultCode value.

WME-Application.indication o Function

The WME-Application.indication primitive is used to inform an application of the

availability of a new WBSS and request confirmation on whether the application

chooses to join the offered WBSS.


The parameters of the WME-Application.indication primitive are as follows:

WME-Application.indication(

ProviderServiceContext,


IPv6Address (optional),

)

o When generated

The WME-Application.indication primitive is generated by the WME, when a

MLME-WSA.indication is received, with a service matching one in the local

UserServiceInfo, and when the matched application has its ConfirmBeforeJoin flag

set.

o Effect of receipt

Upon receipt of the WME-Application.indication primitive, the application responds

with WMEApplication.response.

WME-Application.response o Function

The WME-Application.response primitive is used by an application to respond to a

WME-Application.indication that informs the application of the availability of a new

WBSS.


The parameters of the WME-Application.response primitive are as follows:

WME-Application.response(

LinkConfirm

)

2

o When generated

The WME-Application.response primitive is generated in response to a WME-

Application.indication.

o Effect of receipt

The WME will either join or ignore the WBSS based on the value of LinkConfirm.

WME-Notification.indication o Function

The WME-Notification.indication primitive indicates to a registered application that

a WBSS of interest has changed status.


The parameters of the WME-Notification.indication primitive are as follows:

WME-Notification.indication

(

Event,

Reason,

ProviderServiceContext (optional),

Certificate (optional),

IPv6 Address (optional),

ServicePort (optional),


DefaultGateway (optional),

GatewayMacAddress (optional),

ChannelInfo (optional),

BSSID (optional),

SSID (optional),

Timestamp (optional),

Local time (optional),

BSSBasicRateSet (optional),

OperationalRateSet (optional),

EDCA Parameter Set (optional),

RCPI (optional)

)

o When generated

The WME-Notification.indication primitive is sent when an application's WBSS

status has been modified by the WME. For transitions to Inactive or Unavailable

status, only Event and Reason are used. For a transition to Active, the certificate

is set equal to the certificate output by the signed WSA verification process as

specified in IEEE Std 1609.2. ProviderServiceContext, IPv6Address, Port, Peer

MAC address, and ChannelInfo are set equal to the parameter values in the

3

received WaveServiceAdvertisement. DefaultGateway and GatewayMacAddress

are set to those in the WaveRoutingAdvertisement, if available. Other parameter

values are from the received MLME indication primitive.

o Effect of receipt

The notification is processed as determined by the receiving application.

WME-ApplicationRegistration.request o Function

The WME-ApplicationRegistration.request primitive is used by an application to

request an application registration.


The parameters of the WME-ApplicationRegistration.request primitive are as

follows:

WME-ApplicationRegistration.request

(

RegistrationAction,

CHOICE (UstEntry, PstEntry) (optional),

NotificationIPv6Address (optional),

NotificationPort (optional)

)

o When generated

The WME-ApplicationRegistration.request primitive is generated by an application

to request an application registration. NotificationIPv6Address and NotificationPort

are included when adding application information, and provides addressing

information for notifications sent to the application.

o Effect of receipt

Upon receipt of the WME-ApplicationRegistration.request primitive, the application

and service information are added to or removed from the WME MIB’s

ProviderServiceInfo or UserServiceInfo, depending on the RegistrationAction. It is

recommended that implementers and operators consider any security implications

associated with the installation and registration of applications in their devices.

WME-ApplicationRegistration.confirm o Function

The WME-ApplicationRegistration.confirm primitive is used by the WME to

respond to an application to requested registration.


The parameters of the WME-ApplicationRegistration.confirm primitive are as

follows:

WME-ApplicationRegistration.confirm

(

4

ResultCode

)

o When generated

The WME-ApplicationRegistration.confirm primitive is generated in response to a

WME-ApplicationRegistration.request.

o Effect of receipt

The requesting application may take action based on the ResultCode value.

MLME-DELETETXPROFILE.request o Function

The MLME-DELETETXPROFILE.request primitive is generated by the WME to

delete a transmitter profile in the MLME.


The parameters of the MLME-DELETETXPROFILE.request primitive are as

follows:

MLME-DELETETXPROFILE.request(

Service Channel number

)

o When generated

The MLME-DELETETXPROFILE.request primitive is generated by the WME to

delete a registered transmitter profile in the MLME after the associated IP-based

applications are complete.

o Effect of receipt

Upon receipt of the MLME-DELETETXPROFILE.request primitive, the MLME

deletes the transmitter profile.

MLME-DELETETXPROFILE.confirm o Function

The MLME-DELETETXPROFILE.confirm primitive is used to confirm the outcome

of a MLMEDELETETXPROFILE.request.


The parameters of the MLME-DELETETXPROFILE.confirm primitive are as

follows:

MLME-DELETETXPROFILE.confirm(

ResultCode

)

o When generated

The outcome of a MLME-DELETETXPROFILE.request is confirmed.

o Effect of receipt

The receipt of the MLME-DELETETXPROFILE.confirm primitive by the WME

indicates that the specified transmitter profile has been deleted.

5

MLME-REGISTERTXPROFILE.request o Function

The MLME-REGISTERTXPROFILE.request primitive is generated by the WME to

register a transmitter profile in the MLME.


The parameters of the MLME-REGISTERTXPROFILE.request primitive are as

follows:

MLME-REGISTERTXPROFILE.request(

Service Channel number,

Adaptable,

PowerLevel,

DataRate

)

o When generated

The MLME-REGISTERTXPROFILE.request primitive is generated by the WME to

register a transmitter profile in the MLME before the associated IP-based

applications starts.

o Effect of receipt

Upon receipt of the MLME-REGISTERTXPROFILE.request primitive, the MLME

stores the values associated with the transmitter profile in its MIB.

MLME-REGISTERTXPROFILE.confirm o Function

The MLME-REGISTERTXPROFILE.confirm primitive is used to confirm the

outcome of a MLME-REGISTERTXPROFILE.request.


The parameters of the MLME-REGISTERTXPROFILE.confirm primitive are as

follows:

MLME-REGISTERTXPROFILE.confirm(

ResultCode

)

o When generated

MLME-REGISTERTXPROFILE.confirm confirms the outcome of a MLME-

REGISTERTXPROFILE.request

o Effect of receipt

The receipt of the MLME-REGISTERTXPROFILE.confirm primitive by the WME

indicates that the requested transmitter profile has been registered.

6

MLME-WSA.request o Function

The WSA primitive is generated by the WME to request the MLME to start a

WBSS.


The WSA primitive provides the following parameters:

MLME-WSA.request (

SSID,

BSSBasicRateSet,

OperationalRateSet,

ServiceChannelNumber,

Secured WSA,

Peer MAC address,

Repeats,

Persistence

)

o When generated

The WSA primitive is generated by the WME to start a WBSS.

o Effect of receipt

Upon receipt of the WSA primitive, the MLME schedules the transmission of

WAVE announcement action frames.

MLME-WSA.confirm o Function

The MLME-WSA.confirm primitive reports the result of a MLME-WSA.request.


The MLME-WSA.confirm primitive provides the following parameter:

MLME-WSA.confirm(

ResultCode

)

o When generated

The MLME-WSA.confirm primitive is generated by the MLME in response to a

MLME-WSA.request.

o Effect of receipt

The WME is notified of the result of a MLME-WSA.request.

MLME-WSA.indication o Function

The MLME-WSA.indication primitive indicates the receipt of a WAVE

announcement action frame from a provider.

7


The MLME-WSA.indication primitive provides the following parameters:

MLME-WSA.indication(

BSSID,

SSID,

Timestamp,

Local time,

BSSBasicRateSet,

OperationalRateSet,

EDCA parameter set,

Secured WSA,

RCPI,

Peer MAC address

)

o When generated

The MLME-WSA.indication primitive is generated by the MLME when a WAVE

announcement frame is received.

o Effect of receipt

Upon receipt of the MLME-WSA.indication primitive, the WME issues a MLME-

WSA.response.

MLME-WSA.response o Function

The MLME-WSA.response primitive reports the result of a MLME-WSA.indication.


The MLME-WSA.response primitive provides the following parameters:

MLME-WSA.response(

ResultCode,

BSSID,

SSID,

Timestamp,

Local time

)

o When generated

The MLME-WSA.response primitive is generated by the WME to report the result

of a WSA.indication.

o Effect of receipt

Upon receipt of the MLME-WSA.response primitive, the MLME performs the sync

acquisition procedure.

8

9

MLME-WAVEJOIN.request o Function

The MLME-WAVEJOIN.request primitive requests the MLME of a user to join a

WBSS.


The MLME-WAVEJOIN.request primitive provides the following parameters:

MLME-WAVEJOIN.request

BSSID,

SSID,

OperationalRateSet,

Timestamp,

Local time,

EDCA parameter Set,

Secured WSA,

ChannelNumber

)

o When generated

The MLME-WAVEJOIN.request primitive is generated by the WME to join a

WBSS.

o Effect of receipt

Upon receipt of the MLME-WAVEJOIN.request primitive the MAC entity joins the

WBSS.

MLME-WAVEJOIN.confirm o Function

The MLME-WAVEJOIN.confirm primitive reports the result of a

WAVEJOIN.request.


The MLME-WAVEJOIN.confirm primitive provides the following parameters:

MLME-WAVEJOIN.confirm(

ResultCode

)

o When generated

The MLME-WAVEJOIN.confirm primitive is generated by the MLME to report the

result of an MLMEWAVEJOIN.request.

o Effect of receipt

The WME is notified of the result of a MLME-WAVEJOIN.request.

ANNEX II: TEST PAGES OF THE WAVE MANAGEMENT PLANE ENTITY In the following pages the test pages developed with FitNesse are shown.

The test pages include tables. Each table represents a primitive of the ones of the

Annex I.

TProviderSide.LinkActivation.ActivateIpv6.MlmeWsaCfmNot

Set Up: .WmeTestAppPages.SetUp

Activation values and other constants

REGISTERING + ACTIVATING - WITH IPV6 : THE W

THE ACTIVATION IS STOPPED (DOESN´T TAKE CARE

APPLICATION SENDS REGISTER-REQUEST TO WME: ADD-PROVIDE

APPLICATION RECEIVES REGISTER-CONFIRM FROM WME

WmeTestAppPages

SUITE RESULTS

Test Pages: 50 right, 0 wrong, 0 ignored, 0 exceptions Assertions: 1567 right, 0 wrong, 0 ignored, 0 exceptions

32 right, 0 wrong, 0 ignored, 0 exceptions ProviderSide.LinkActivation.ActivateIpv6.MlmeWsaCfmNotSuccess

35 right, 0 wrong, 0 ignored, 0 exceptions ProviderSide.LinkActivation.ActivateIpv6.MlmeWsaCfmSuccess.RegTxProfCfmNotSuccess

35 right, 0 wrong, 0 ignored, 0 exceptions ProviderSide.LinkActivation.ActivateIpv6.MlmeWsaCfmSuccess.RegTxProfCfmSuccess

30 right, 0 wrong, 0 ignored, 0 exceptions ProviderSide.LinkActivation.ActivateNotIpv6.MlmeWsaCfmNotSuccess

31 right, 0 wrong, 0 ignored, 0 exceptions ProviderSide.LinkActivation.ActivateNotIpv6.MlmeWsaCfmSuccess

12 right, 0 wrong, 0 ignored, 0 exceptions ProviderSide.RegisterRequestConfirm.DeRegisterTwice

16 right, 0 wrong, 0 ignored, 0 exceptions ProviderSide.RegisterRequestConfirm.RegisterDeregisterTwice

8 right, 0 wrong, 0 ignored, 0 exceptions ProviderSide.RegisterRequestConfirm.RegisterOk

8 right, 0 wrong, 0 ignored, 0 exceptions ProviderSide.RegisterRequestConfirm.RegisterTwice

41 right, 0 wrong, 0 ignored, 0 exceptions ProviderSide.WbssCompletion.ApplicationDeactivation.NotUsedIpv6

48 right, 0 wrong, 0 ignored, 0 exceptions ProviderSide.WbssCompletion.ApplicationDeactivation.UsedIpv6

41 right, 0 wrong, 0 ignored, 0 exceptions ProviderSide.WbssCompletion.ApplicationDeregistration.NotUsedIpv6

48 right, 0 wrong, 0 ignored, 0 exceptions ProviderSide.WbssCompletion.ApplicationDeregistration.UseIpv6

38 right, 0 wrong, 0 ignored, 0 exceptions ProviderSide.WbssCompletion.ChannelInactivity.NotUsedIpv6

45 right, 0 wrong, 0 ignored, 0 exceptions ProviderSide.WbssCompletion.ChannelInactivity.UsedIpv6

41 right, 0 wrong, 0 ignored, 0 exceptions ProviderSide.WbssCompletion.NewApplicationRequest.ApplicationIpv6.ApplicationLessPriority

45 right, 0 wrong, 0 ignored, 0 exceptions ProviderSide.WbssCompletion.NewApplicationRequest.ApplicationIpv6.ApplicationMorePriority.ConfirmBeforeJoin

62 right, 0 wrong, 0 ignored, 0 exceptions ProviderSide.WbssCompletion.NewApplicationRequest.ApplicationIpv6.ApplicationMorePriority.NotConfirmBeforeJoin

35 right, 0 wrong, 0 ignored, 0 exceptions ProviderSide.WbssCompletion.NewApplicationRequest.ApplicationNotIpv6.ApplicationLessPriority

35 right, 0 wrong, 0 ignored, 0 exceptions ProviderSide.WbssCompletion.NewApplicationRequest.ApplicationNotIpv6.ApplicationMorePriority.ConfirmBeforeJoin

45 right, 0 wrong, 0 ignored, 0 exceptions ProviderSide.WbssCompletion.NewApplicationRequest.ApplicationNotIpv6.ApplicationMorePriority.NotConfirmBeforeJoin

18 right, 0 wrong, 0 ignored, 0 exceptions UserSide.LinkActivation.AppMatch.ConfBeforeJoin.AppResponseNotSuccess

26 right, 0 wrong, 0 ignored, 0 exceptions UserSide.LinkActivation.AppMatch.ConfBeforeJoin.AppResponseSuccess.WaveJoinCfmNotSuccess.NotUsedIpv6

28 right, 0 wrong, 0 ignored, 0 exceptions UserSide.LinkActivation.AppMatch.ConfBeforeJoin.AppResponseSuccess.WaveJoinCfmNotSuccess.UsedIpv6

27 right, 0 wrong, 0 ignored, 0 exceptions UserSide.LinkActivation.AppMatch.ConfBeforeJoin.AppResponseSuccess.WaveJoinCfmSuccess.NotUsedIpv6

31 right, 0 wrong, 0 ignored, 0 exceptions UserSide.LinkActivation.AppMatch.ConfBeforeJoin.AppResponseSuccess.WaveJoinCfmSuccess.UsedIpv6.RegTxProfileNotSuccess

29 right, 0 wrong, 0 ignored, 0 exceptions UserSide.LinkActivation.AppMatch.ConfBeforeJoin.AppResponseSuccess.WaveJoinCfmSuccess.UsedIpv6.RegTxProfileSuccess

22 right, 0 wrong, 0 ignored, 0 exceptions UserSide.LinkActivation.AppMatch.NotConfBeforeJoin.WaveJoinCfmNotSuccess.NotUsedIpv6

23 right, 0 wrong, 0 ignored, 0 exceptions UserSide.LinkActivation.AppMatch.NotConfBeforeJoin.WaveJoinCfmNotSuccess.UsedIpv6

22 right, 0 wrong, 0 ignored, 0 exceptions UserSide.LinkActivation.AppMatch.NotConfBeforeJoin.WaveJoinCfmSuccess.NotUsedIpv6

26 right, 0 wrong, 0 ignored, 0 exceptions UserSide.LinkActivation.AppMatch.NotConfBeforeJoin.WaveJoinCfmSuccess.UsedIpv6.RegTxProfileNotSuccess

27 right, 0 wrong, 0 ignored, 0 exceptions UserSide.LinkActivation.AppMatch.NotConfBeforeJoin.WaveJoinCfmSuccess.UsedIpv6.RegTxProfileSuccess

13 right, 0 wrong, 0 ignored, 0 exceptions UserSide.LinkActivation.AppNotMatch.ConfBeforeJoin

13 right, 0 wrong, 0 ignored, 0 exceptions UserSide.LinkActivation.AppNotMatch.NotConfBeforeJoin

12 right, 0 wrong, 0 ignored, 0 exceptions UserSide.RegisterRequestConfirm.DeregisterTwice

16 right, 0 wrong, 0 ignored, 0 exceptions UserSide.RegisterRequestConfirm.RegisterDeregisterTwice

8 right, 0 wrong, 0 ignored, 0 exceptions UserSide.RegisterRequestConfirm.RegisterOk

8 right, 0 wrong, 0 ignored, 0 exceptions UserSide.RegisterRequestConfirm.RegisterTwice

32 right, 0 wrong, 0 ignored, 0 exceptions UserSide.WbssCompletion.ApplicationDeactivation.NotUsedIpv6

39 right, 0 wrong, 0 ignored, 0 exceptions UserSide.WbssCompletion.ApplicationDeactivation.UsedIpv6

32 right, 0 wrong, 0 ignored, 0 exceptions UserSide.WbssCompletion.ApplicationDeregistration.NotUsedIpv6

39 right, 0 wrong, 0 ignored, 0 exceptions UserSide.WbssCompletion.ApplicationDeregistration.UsedIpv6

45 right, 0 wrong, 0 ignored, 0 exceptions UserSide.WbssCompletion.ApplicationUnavailable.NotUsedIpv6

52 right, 0 wrong, 0 ignored, 0 exceptions UserSide.WbssCompletion.ApplicationUnavailable.UsedIpv6

29 right, 0 wrong, 0 ignored, 0 exceptions UserSide.WbssCompletion.ChannelInactivity.NotUsedIpv6

36 right, 0 wrong, 0 ignored, 0 exceptions UserSide.WbssCompletion.ChannelInactivity.UsedIpv6

41 right, 0 wrong, 0 ignored, 0 exceptions UserSide.WbssCompletion.NewApplicationRequest.ApplicationIpv6.ApplicationLessPriority

62 right, 0 wrong, 0 ignored, 0 exceptions UserSide.WbssCompletion.NewApplicationRequest.ApplicationIpv6.ApplicationMorePriority

35 right, 0 wrong, 0 ignored, 0 exceptions UserSide.WbssCompletion.NewApplicationRequest.ApplicationNotIpv6.ApplicationLessPriority

45 right, 0 wrong, 0 ignored, 0 exceptions UserSide.WbssCompletion.NewApplicationRequest.ApplicationNotIpv6.ApplicationMorePriority

Set Up Wme Fixture Base

Register Request

action psid prio channel selection service ipv6 service port mac notification ipv

0 99 31 255 ::1 5540 11:22:33:44:55:66 ::1

Register Confirm

Output Captured

EST OUTPUT Success

ME RECEIVES A NEGATIVE MLME-WSA.CFM

OF THE TXPROFILE) R = 0

Expand All | Collapse All


6 notification port confirm before join sent? result?

49204 false 0 OK

1

0: eIE_OP_RETURN_OK, 0: RC_Success

APPLICATION SENDS ACTIVATION-REQUEST TO WME: ACTIVATE = 1

CHECK THE RECEIVED MLME-WSA-REQUEST PARAMETERS ON MLME

PREPARING WAIT 4 CALL STATES IN THE APPLICATION ENTITY (PEER = 1)

0: eIE_OP_RETURN_OK

PREPARING WAIT 4 CALL STATES IN THE MLME ENTITY (PEER = 2)

0: eIE_OP_RETURN_OK

SEND MLME-WSA-CONFIRM FROM MLME

rc=1: Invalid Parmeters, sent=0: eIE_OP_RETURN_OK

CHECK THAT IT HAS NOT BEEN SENT THE MLME-REGISTERTXPROFILE.REQ

APPLICATION RECEIVES THE ACTIVATE-CONFIRMATION

0: eIE_OP_RETURN_OK, 1: RC_InespecifiedFailure

CHECK THAT IT HAS NOT BEEN SENT A NOTIFICATION INDICATION TO THE APPLICATION (LINK NO ACTIVE)

L

Tear Down: .WmeTestAppPages.TearDown

ProviderSide.LinkActivation.ActivateIpv6.MlmeWsaCfmSuccess.RegTxProfCfmNotSuccess



REGISTERING + ACTIVATING - WITH IPV6 : REGISTERTXPROFILE CONFIRM GIVES A INVALID PARAMETERS RESPONSE

THE ACTIVATION IS STOPPED APPLICATION SENDS REGISTER REQUEST TO WME: ADD-PROVIDER = 0

APPLICATION RECEIVES REGISTER CONFIRM FROM WME


confirm? result?

0 0

Application Request

psid context activate mac repeats persistence channel selection sent? result?

99 123456789 1 11:22:33:44:55:66 0 0 255 0 OK

WsaReqData

pCont? pPsid? pContext? pPrio? pServiceIpv6? pServicePort? pMacAppHost? pChannelNr? cChannelNr? cAdaptable? cDdatarate? cTxpwrlevel?

127 99 123456789 31 ::1 5540 00:60:08:27:5D:09 184 184 0 2 22

Wsa Request

ssid? bssBasRate? operRateS? channelSelection? mac? repeats? persistence?

C2X-Dev-1 0B010203040506070809 080102030405060708 184 11:22:33:44:55:66 0 0

ResetWait4CallState

peer result?

1 0

ResetWait4CallState

peer result?

2 0

Wsa confirm

rc sent?

1 0

Wait4Call

sec peer callid waited?

4 2 3 0

Application Confirm

confirm? result?

0 1

Wait4Call


4 1 20 0

Expand All | Collapse AllTear Down Wme Fixture Base

Expand All | Collapse AllSet Up Wme Fixture Base


Register Request

action psid prio channel selection service ipv6 service port mac notification ipv6 notification port confirm before join sent? result?

0 99 31 255 ::1 5540 11:22:33:44:55:66 ::1 49204 false 0 OK

Register Confirm

confirm? result?

0 0

2

APPLICATION SENDS ACTIVATION REQUEST TO WME: ACTIVATE = 1

CHECK THE RECEIVED MLME-WSA.REQUEST PARAMETERS ON MLME

SEND MLME-WSA.CONFIRM FROM MLME

rc=0: RC_Success, sent=0: eIE_OP_RETURN_OK

CHECK THE RECEIVED MLME-REGISTERTXPROFILE.REQUEST PARAMETERS ON MLME

PREPARING WAIT 4 CALL STATES

0: eIE_OP_RETURN_OK

SEND MLME-REGISTERTXPROFILE.CONFIRM FROM MLME

rc=1: RC_Invalid_Parameters, sent=0: eIE_OP_RETURN_OK

APPLICATION RECEIVES THE ACTIVATE CONFIRMATION

0: eIE_OP_RETURN_OK, 1: RC_Unspecified_Failure''

CHECK THAT IT HAS NOT BEEN SENT A NOTIFICATION INDICATION TO THE APPLICATION (LINK NO ACTIVE)

L


ProviderSide.LinkActivation.ActivateIpv6.MlmeWsaCfmSuccess.RegTxProfCfmSuccess



REGISTERING + ACTIVATING - WITH IPV6 APPLICATION SENDS REGISTER REQUEST TO WME: ADD-PROVIDER = 0





Application Request


99 123456789 1 11:22:33:44:55:66 0 0 255 0 OK

WsaReqData


127 99 123456789 31 ::1 5540 00:60:08:27:5D:09 184 184 0 2 22

Wsa Request


C2X-Dev-1 0B010203040506070809 080102030405060708 184 11:22:33:44:55:66 0 0

Wsa confirm

rc sent?

0 0

RegisterTxRequest

channelnr? adaptable? datarate? txpwrlevel?

184 0 2 22

ResetWait4CallState

peer result?

1 0

RegisterTxConfirm

rc sent?

1 0

Application Confirm

confirm? result?

0 1

Wait4Call


4 1 20 0




Register Request


0 99 31 255 ::1 5540 11:22:33:44:55:66 ::1 49204 false 0 OK

Register Confirm

confirm? result?

0 0

Application Request


99 123456789 1 11:22:33:44:55:66 0 0 255 0 OK

WsaReqData


3








NOTIFICATION INDICATION LINK ACTIVE

" event=1: Ee_WBSS_ACTIVE, =1: NOTIF_REASON_ApplicationRequested" L


ProviderSide.LinkActivation.ActivateNotIpv6.MlmeWsaCfmNotSuccess



REGISTERING + ACTIVATING - WITHOUT IPV6 :MLME-WSA RETURNS INVALID PAMETERS

THE ACTIVATION IS STOPPED APPLICATION SENDS REGISTER-REQUEST TO WME: ADD-PROVIDER = 0





PREPARING WAIT 4 CALL STATES IN THE APPLICATION ENTITY (PEER = 1)

0: eIE_OP_RETURN_OK

127 99 123456789 31 ::1 5540 00:60:08:27:5D:09 184 184 0 2 22

Wsa Request


C2X-Dev-1 0B010203040506070809 080102030405060708 184 11:22:33:44:55:66 0 0

Wsa confirm

rc sent?

0 0

RegisterTxRequest


184 0 2 22

RegisterTxConfirm

rc sent?

0 0

Application Confirm

confirm? result?

0 0

NotificationIndicationShort

event reason

1 1




Register Request


0 99 31 255 :: 0 11:22:33:44:55:66 ::1 49204 false 0 OK

Register Confirm

confirm? result?

0 0

Application Request


99 123456789 1 11:22:33:44:55:66 0 0 255 0 OK

WsaReqData


71 99 123456789 31 :: 0 00:60:08:27:5D:09 184 184 0 2 22

Wsa Request


C2X-Dev-1 0B010203040506070809 080102030405060708 184 11:22:33:44:55:66 0 0

ResetWait4CallState

peer result?

1 0

4


rc=1: RC_Invalid_Parameter, sent=0: eIE_OP_RETURN_OK


0: eIE_OP_RETURN_OK, 1: RC_UnespecifiedFailure''

CHECK THAT IT HAS NOT BEEN SENT A NOTIFICATION INDICATION (NO LINK ACTIVE)

L


ProviderSide.LinkActivation.ActivateNotIpv6.MlmeWsaCfmSuccess



REGISTERING + ACTIVATING - WITHOUT IPV6 APPLICATION SENDS REGISTER-REQUEST TO WME: ADD-PROVIDER = 0










event=1: WBSS_Active, reason=1: NOTIF_REASON_ApplicationRequested L


Wsa confirm

rc sent?

1 0

Application Confirm

confirm? result?

0 1

Wait4Call


4 1 20 0




Register Request


0 99 31 255 :: 0 11:22:33:44:55:66 ::1 49204 false 0 OK

Register Confirm

confirm? result?

0 0

Application Request


99 123456789 1 11:22:33:44:55:66 0 0 255 0 OK

WsaReqData


71 99 123456789 31 :: 0 00:60:08:27:5D:09 184 184 0 2 22

Wsa Request


C2X-Dev-1 0B010203040506070809 080102030405060708 184 11:22:33:44:55:66 0 0

Wsa confirm

rc sent?

0 0

Application Confirm

confirm? result?

0 0

Notification Indication

event? reason? mac?

1 1 11:22:33:44:55:66


5

ProviderSide.RegisterRequestConfirm.DeRegisterTwice


Action valuesn and other constants

REGISTERING + DEREGISTERING + DEREGSITERING APPLICATION REGISTERING PART:1 REQUEST

REGISTERING PART:2 CONFIRM: OK


REGISTERING PART:3 DE-REQUEST




REGISTERING PART:6 CONFIRM: UNSPECIFIED FAILURE

0: eIE_OP_RETURN_OK, 1: RC_UnspecifiedFailure L


ProviderSide.RegisterRequestConfirm.RegisterDeregisterTwice



REGISTERING + REGISTERING +DEREGISTERING + DEREGISTERING REGISTERING PART:1 REQUEST



REGISTERING PART:3 SAME PSID REREGISTERING

REGISTERING PART:4 CONFIRM:PSID CONFLICT

0: eIE_OP_RETURN_OK, 3: RC_PSIDconflict




Register Request


0 99 31 255 :: 0 11:22:33:44:55:66 ::1 49204 false 0 OK

Register Confirm

confirm? result?

0 0

Register Request


2 99 31 255 :: 0 11:22:33:44:55:66 ::1 49204 false 0 OK

Register Confirm

confirm? result?

0 0

Register Request


2 99 31 255 :: 0 11:22:33:44:55:66 ::1 49204 false 0 OK

Register Confirm

confirm? result?

0 1




Register Request


0 99 31 255 :: 0 11:22:33:44:55:66 ::1 49204 false 0 OK

Register Confirm

confirm? result?

0 0

Register Request


0 99 31 255 0 0 11:22:33:44:55:66 ::1 49204 false 0 OK

Register Confirm

confirm? result?

0 3

6




REGISTERING PART:8 CONFIRM: UNSPECIFIED FAILURE

0: eIE_OP_RETURN_OK, 1: RC_UnspecifiedFailure L


ProviderSide.RegisterRequestConfirm.RegisterOk



REGISTERING + DEREGISTERING APPLICATION REGISTERING PART:1 REQUEST





0: eIE_OP_RETURN_OK, 0: RC_Success L


ProviderSide.RegisterRequestConfirm.RegisterTwice



REGISTER APPLICATION + REGISTER TWICE THE APPLICLATION REGISTERING PART:1 REQUEST


Register Request


2 99 31 255 :: 0 11:22:33:44:55:66 ::1 49204 false 0 OK

Register Confirm

confirm? result?

0 0

Register Request


2 99 31 255 :: 0 11:22:33:44:55:66 ::1 54004 false 0 OK

Register Confirm

confirm? result?

0 1




Register Request


0 99 31 255 :: 0 11:22:33:44:55:66 ::1 49204 false 0 OK

Register Confirm

confirm? result?

0 0

Register Request


2 99 31 255 :: 0 11:22:33:44:55:66 ::1 49204 false 0 OK

Register Confirm

confirm? result?

0 0




Register Request


0 99 31 255 :: 0 11:22:33:44:55:66 ::1 49204 false 0 OK

Register Confirm

confirm? result?

0 0

7


REGISTERING PART:3 SAME PSID REGISTRATION

REGISTERING PART:4 CONFIRM: PSID CONFLICT

0: eIE_OP_RETURN_OK, 3: RC_PSIDconflict L


ProviderSide.WbssCompletion.ApplicationDeactivation.NotUsedIpv6



LINK ESTABLISHMENT + DEACTIVATING REQUEST APPLICATION SENDS REGISTER REQUEST TO WME: ADD-PROVIDER = 0










event=1: WBSS_Active, reason=1: NOTIF_REASON_ApplicationRequested

APPLICATION SENDS DE-ACTIVATION-REQUEST TO WME: DEACTIVATE = 2

CHECK THE RECEIVED WAVE END-REQUEST PARAMETERS ON MLME

SEND WAVE END CONFIRM FROM MLME

Register Request


0 99 31 255 0 0 11:22:33:44:55:66 ::1 49204 false 0 OK

Register Confirm

confirm? result?

0 3




Register Request


0 99 31 255 :: 0 11:22:33:44:55:66 ::1 49204 false 0 OK

Register Confirm

confirm? result?

0 0

Application Request


99 123456789 1 11:22:33:44:55:66 0 0 255 0 OK

WsaReqData


71 99 123456789 31 :: 0 00:60:08:27:5D:09 184 184 0 2 22

Wsa Request


C2X-Dev-1 0B010203040506070809 080102030405060708 184 11:22:33:44:55:66 0 0

Wsa confirm

rc sent?

0 0

Application Confirm

confirm? result?

0 0


event? reason? mac?

1 1 11:22:33:44:55:66

Application Request


99 123456789 2 11:22:33:44:55:66 0 0 255 0 OK

Wave End Request

bssid? ssid?

00 19 99 03 5A 2F C2X-Dev-1

Wave End Confirm

8


APPLICATION RECEIVES THE DEACTIVATE-CONFIRMATION


NOTIFICATION INDICATION WBSS TERMINATED

event=0: WBSS_Inactive, reason=1: NOTIF_REASON_ApplicationRequested L


ProviderSide.WbssCompletion.ApplicationDeactivation.UsedIpv6



USED IPV6 LINK ESTABLISHMENT + DEACTIVATING APPLICATION APPLICATION SENDS REGISTER REQUEST TO WME: ADD-PROVIDER = 0













rc sent?

0 0

Application Confirm

confirm? result?

0 0


event? reason? mac?

0 1 11:22:33:44:55:66




Register Request


0 99 31 255 ::1 5540 11:22:33:44:55:66 ::1 49204 false 0 OK

Register Confirm

confirm? result?

0 0

Application Request


99 123456789 1 11:22:33:44:55:66 0 0 255 0 OK

WsaReqData


127 99 123456789 31 ::1 5540 00:60:08:27:5D:09 184 184 0 2 22

Wsa Request


C2X-Dev-1 0B010203040506070809 080102030405060708 184 11:22:33:44:55:66 0 0

Wsa confirm

rc sent?

0 0

RegisterTxRequest


184 0 2 22

RegisterTxConfirm

rc sent?

0 0

Application Confirm

confirm? result?

0 0

9


APPLICATION SENDS DE-ACTIVATION REQUEST TO WME: DEACTIVATE = 2

CHECK THE RECEIVED MLME-DELETETXPROFILE.REQUEST PARAMETERS ON MLME

SEND MLME-DELETETXPROFILE.CONFIRMFROM MLME


CHECK THE RECEIVED WAVEEND.REQUEST PARAMETERS ON MLME

SEND WAVEEND CONFIRM FROM MLME





event=0: eE_WBSS_TERMINATED, reason=1: NOTIF_REASON_ApplicationRequested


ProviderSide.WbssCompletion.ApplicationDeregistration.NotUsedIpv6



LINK ESTABLISHED + DEREGISTRATION REQUEST NOT USED IPV6 APPLICATION SENDS REGISTER-REQUEST TO WME: ADD-PROVIDER = 0






event? reason? mac?

1 1 11:22:33:44:55:66

Application Request


99 123456789 2 11:22:33:44:55:66 0 0 255 0 OK

DeleteTxRequest

channelnr?

184

DeleteTxConfirm

rc sent?

0 0

Wave End Request

bssid? ssid?

00 19 99 03 5A 2F C2X-Dev-1

Wave End Confirm

rc sent?

0 0

Application Confirm

confirm? result?

0 0


event? reason? mac?

0 1 11:22:33:44:55:66




Register Request


0 99 31 255 :: 0 11:22:33:44:55:66 ::1 49204 false 0 OK

Register Confirm

confirm? result?

0 0

Application Request


99 123456789 1 11:22:33:44:55:66 0 0 255 0 OK

WsaReqData


71 99 123456789 31 :: 0 00:60:08:27:5D:09 184 184 0 2 22

Wsa Request

10







APPLICATION SENDS DE REGISTER REQUEST TO WME: REMOVE-PROVIDER = 2








ProviderSide.WbssCompletion.ApplicationDeregistration.UseIpv6



USED IPV6-LINK ESTABLISHMENT + DEREGISTERING APPLICATION SENDS REGISTER REQUEST TO WME: ADD-PROVIDER = 0






C2X-Dev-1 0B010203040506070809 080102030405060708 184 11:22:33:44:55:66 0 0

Wsa confirm

rc sent?

0 0

Application Confirm

confirm? result?

0 0


event? reason? mac?

1 1 11:22:33:44:55:66

Register Request


2 99 31 255 :: 0 11:22:33:44:55:66 ::1 59204 false 0 OK

Wave End Request

bssid? ssid?

00 19 99 03 5A 2F C2X-Dev-1

Wave End Confirm

rc sent?

0 0

Register Confirm

confirm? result?

0 0


event? reason? mac?

0 1 11:22:33:44:55:66




Register Request


0 99 31 255 ::1 5540 11:22:33:44:55:66 ::1 49204 false 0 OK

Register Confirm

confirm? result?

0 0

Application Request


99 123456789 1 11:22:33:44:55:66 0 0 255 0 OK

WsaReqData

11



CHECK THE RECEIVED MLME-REGISTERTXPROFILE.REQ PARAMETERS ON MLME







APPLICATION SENDS DE REGISTER REQUEST TO WME: REMOVE-PROVIDER = 3

CHECK THE RECEIVED MLME-DELETETXPROFILE.REQ PARAMETERS ON MLME












127 99 123456789 31 ::1 5540 00:60:08:27:5D:09 184 184 0 2 22

Wsa Request


C2X-Dev-1 0B010203040506070809 080102030405060708 184 11:22:33:44:55:66 0 0

Wsa confirm

rc sent?

0 0

RegisterTxRequest


184 0 2 22

RegisterTxConfirm

rc sent?

0 0

Application Confirm

confirm? result?

0 0


event? reason? mac?

1 1 11:22:33:44:55:66

Register Request


3 99 31 255 :: 0 11:22:33:44:55:66 ::1 59204 false 0 OK

DeleteTxRequest

channelnr?

184

DeleteTxConfirm

rc sent?

0 0

Wave End Request

bssid? ssid?

00 19 99 03 5A 2F C2X-Dev-1

Wave End Confirm

rc sent?

0 0

Register Confirm

confirm? result?

0 0


event? reason? mac?

0 1 11:22:33:44:55:66


12

ProviderSide.WbssCompletion.ChannelInactivity.NotUsedIpv6



LINK ESTABLISHMENT + DEACTIVATING REQUEST APPLICATION SENDS REGISTER REQUEST TO WME: ADD-PROVIDER = 0











MLME SENDS CHANNEL INACTIVITY





event=0: WBSS_Inactive, reason=2: NOTIF_REASON_ChannelInactivity L


ProviderSide.WbssCompletion.ChannelInactivity.UsedIpv6



Register Request


0 99 31 255 :: 0 11:22:33:44:55:66 ::1 49204 false 0 OK

Register Confirm

confirm? result?

0 0

Application Request


99 123456789 1 11:22:33:44:55:66 0 0 255 0 OK

WsaReqData


71 99 123456789 31 :: 0 00:60:08:27:5D:09 184 184 0 2 22

Wsa Request


C2X-Dev-1 0B010203040506070809 080102030405060708 184 11:22:33:44:55:66 0 0

Wsa confirm

rc sent?

0 0

Application Confirm

confirm? result?

0 0


event? reason? mac?

1 1 11:22:33:44:55:66

Channel Inactivity Indication

channelnumber sent?

184 0

Wave End Request

bssid? ssid?

00 19 99 03 5A 2F C2X-Dev-1

Wave End Confirm

rc sent?

0 0


event? reason? mac?

0 2 11:22:33:44:55:66


13



USED IPV6 LINK ESTABLISHMENT + DEACTIVATING APPLICATION APPLICATION SENDS REGISTER REQUEST TO WME: ADD-PROVIDER = 0















CHECK THE RECEIVED MLME-DELETETXPROFILE.REQUEST PARAMETERS ON MLME



CHECK THE RECEIVED WAVEEND.REQUEST PARAMETERS ON MLME



Register Request


0 99 31 255 ::1 5540 11:22:33:44:55:66 ::1 49204 0 0 OK

Register Confirm

confirm? result?

0 0

Application Request


99 123456789 1 11:22:33:44:55:66 0 0 255 0 OK

WsaReqData


127 99 123456789 31 ::1 5540 00:60:08:27:5D:09 184 184 0 2 22

Wsa Request


C2X-Dev-1 0B010203040506070809 080102030405060708 184 11:22:33:44:55:66 0 0

Wsa confirm

rc sent?

0 0

RegisterTxRequest


184 0 2 22

RegisterTxConfirm

rc sent?

0 0

Application Confirm

confirm? result?

0 0


event? reason? mac?

1 1 11:22:33:44:55:66


channelnumber sent?

184 0

DeleteTxRequest

channelnr?

184

DeleteTxConfirm

rc sent?

0 0

Wave End Request

bssid? ssid?

00 19 99 03 5A 2F C2X-Dev-1

14

SEND WAVEEND CONFIRM FROM MLME



event=0: eE_WBSS_TERMINATED, reason=2: NOTIF_REASON_ChannelInactivity L


ProviderSide.WbssCompletion.NewApplicationRequest.ApplicationIpv6.ApplicationLessPriority



REGISTERING FIRST APPLICATION + REGISTERING SECOND APPLICATION + ACTIVE LINK FIRST APPLICATION + REQUEST SECOND APPLICATION ACTIVATION + CHECK NO DELETETXPROFILE AND NO WAVEEND IS SENT TO MLME FIRST APPLICATION SENDS REGISTER-REQUEST TO WME: ADD-USER = 1



SECOND APPLICATION SENDS REGISTER-REQUEST TO WME: ADD-USER = 1



MLME SENDS WSA_INDICATION TO WME

Content:7(psid1+prio2+chan4+)

CHECK THE RECEIVED WSA-RESPONSE ON MLME

CHECK THE RECEIVED WAVE JOIN REQUEST ON MLME

SEND WAVE JOIN CONFIRM FROM MLME



Wave End Confirm

rc sent?

0 0


event? reason? mac?

0 2 11:22:33:44:55:66




Register Request


1 101 0 0 :: 0 0 ::1 49204 0 0 OK

Register Confirm

confirm? result?

0 0

Register Request


1 103 0 0 :: 0 0 ::1 49204 1 0 OK

Register Confirm

confirm? result?

0 0

Wsa Ind Data

pCont pPsid pContext pPrio pServiceIpv6 pServicePort pMacAppHost pChannelNr cChannelNr cAdaptable cDdatarate cTxpwrlevel sent?

63 101 Pers 25 ::1 5540 00:00:00:00:00:00 184 184 0 2 22 0

Wsa Indication

bssid ssid timeStamp localTime bssBasRate operRateS edcAparSet mac sent?

00 19 99 03 5A 2F C2X-Dev-1 111 128000 0B010203040506070809 080102030405060708 123456789 FF:FF:FF:FF:FF:FF 0

Wsa Response

rc? bssid? ssid? timeStamp? localTime?

0 00 19 99 03 5A 2F C2X-Dev-1 111 128000

Wave Join Request

bssid ssid timeStamp localTime operRateS edcAparSet channelNumber

00 19 99 03 5A 2F C2X-Dev-1 111 128000 080102030405060708 123456789 184

Wave Join Confirm

rc sent?

0 0

RegisterTxRequest


15



APPLICATION RECEIVES NOTIFICATION INDICATION FROM WME


PREPARING WAIT 4 CALL STATES ON MLME (PEER = 2)

''0: eIE_OP_RETURN_OK

MLME SENDS WSA_INDICATION TO WME WITH THE DATA OF THE SECOND APPLICATION


CHECK THAT IT HAS NOT BEEN SENT A DELETETXPROFILE.REQ (CALLID = 5)

CHECK THAT IT HAS NOT BEEN SENT A WAVEEND (CALLID = 13)

L


ProviderSide.WbssCompletion.NewApplicationRequest.ApplicationIpv6.ApplicationMorePriority.ConfirmBeforeJoin



REGISTERING FIRST APPLICATION + REGISTERING SECOND APPLICATION + ACTIVE LINK FIRST APPLICATION + REQUEST SECOND APPLICATION ACTIVATION + END FIRST APPLICATION LINK + ACTIVE SECOND APPLICATION LINK FIRST APPLICATION SENDS REGISTER-REQUEST TO WME: ADD-USER = 1






184 0 2 22

RegisterTxConfirm

rc sent?

0 0


event? reason? mac?

1 1 FF:FF:FF:FF:FF:FF

ResetWait4CallState

peer result?

2 0

Wsa Ind Data


63 103 Pers 15 ::1 5540 00:00:00:00:00:00 184 184 0 2 22 0

Wsa Indication



Wsa Response


0 00 19 99 03 5A 2F C2X-Dev-1 111 128000

Wait4Call


4 2 5 0

Wait4Call


4 2 13 0




Register Request


1 101 0 0 :: 0 0 ::1 49204 0 0 OK

Register Confirm

confirm? result?

0 0

Register Request


1 103 0 0 :: 0 0 ::1 49204 1 0 OK

Register Confirm

confirm? result?

0 0

16













CHECK THE RECEIVED APPLICATION INDICATION IN THE APPLICATION 2


0: eIE_OP_RETURN_OK

WME RECEIVES APP-RESPONSE APPLICATION

0: Link_Confirm_FALSE

CHECK THAT IS NOT BEING SEND MLME-DELETETXPROFILE.REQ

L

Wsa Ind Data


63 101 Pers 25 ::1 5540 00:00:00:00:00:00 184 184 0 2 22 0

Wsa Indication



Wsa Response


0 00 19 99 03 5A 2F C2X-Dev-1 111 128000

Wave Join Request


00 19 99 03 5A 2F C2X-Dev-1 111 128000 080102030405060708 123456789 184

Wave Join Confirm

rc sent?

0 0

RegisterTxRequest


184 0 2 22

RegisterTxConfirm

rc sent?

0 0


event? reason? mac?


Wsa Ind Data


63 103 Pers 35 ::1 5540 00:00:00:00:00:00 184 184 0 2 22 0

Wsa Indication



Wsa Response


0 00 19 99 03 5A 2F C2X-Dev-1 111 128000

Application Indication

context? mac? serviceipv6? persistence?

Pers FF:FF:FF:FF:FF:FF ::1 1

ResetWait4CallState

peer result?

2 0

Application Response

linkconfirm? sent?

0 0

Wait4Call


4 2 5 0

17


ProviderSide.WbssCompletion.NewApplicationRequest.ApplicationIpv6.ApplicationMorePriority.NotConfirmBeforeJoin























Register Request


1 101 0 0 :: 0 0 ::1 49204 0 0 OK

Register Confirm

confirm? result?

0 0

Register Request


1 103 0 0 :: 0 0 ::1 49204 0 0 OK

Register Confirm

confirm? result?

0 0

Wsa Ind Data


63 101 Pers 25 ::1 5540 00:00:00:00:00:00 184 184 0 2 22 0

Wsa Indication



Wsa Response


0 00 19 99 03 5A 2F C2X-Dev-1 111 128000

Wave Join Request


00 19 99 03 5A 2F C2X-Dev-1 111 12800 080102030405060708 123456789 184

Wave Join Confirm

rc sent?

0 0

RegisterTxRequest


184 0 2 22

RegisterTxConfirm

rc sent?

0 0


event? reason? mac?


Wsa Ind Data

18







rc=1: Invalid_Parameters, sent=0: eIE_OP_RETURN_OK


event=0: WBSS_Inactive, reason=4: NOTIF_REASON_PriorityPreemption







SECOND APPLICATION RECEIVES NOTIFICATION INDICATION FROM WME



ProviderSide.WbssCompletion.NewApplicationRequest.ApplicationNotIpv6.ApplicationLessPriority



63 103 Pers 35 ::1 5540 00:00:00:00:00:00 184 184 0 2 22 0

Wsa Indication



Wsa Response


0 00 19 99 03 5A 2F C2W-Dev-1 1 128000

DeleteTxRequest

channelnr?

184

DeleteTxConfirm

rc sent?

0 0

Wave End Request

bssid? ssid?

00 19 99 03 5A 2F C2X-Dev-1

Wave End Confirm

rc sent?

1 0


event? reason? mac?


Wave Join Request


00 19 99 03 5A 2F C2X-Dev-1 111 12800 080102030405060708 123456789 184

Wave Join Confirm

rc sent?

0 0

RegisterTxRequest


184 0 2 22

RegisterTxConfirm

rc sent?

0 0


event? reason? mac?




19


REGISTERING FIRST APPLICATION + REGISTERING SECOND APPLICATION + ACTIVE LINK FIRST APPLICATION + REQUEST SECOND APPLICATION ACTIVATION + CHECK NO WAVEEND IS SENT TO MLME FIRST APPLICATION SENDS REGISTER-REQUEST TO WME: ADD-USER = 1



















Register Request


1 101 0 0 :: 0 0 ::1 49204 0 0 OK

Register Confirm

confirm? result?

0 0

Register Request


1 103 0 0 :: 0 0 ::1 49204 0 0 OK

Register Confirm

confirm? result?

0 0

Wsa Ind Data


7 101 Pers 25 :: 0 00:00:00:00:00:00 184 184 0 2 22 0

Wsa Indication



Wsa Response


0 00 19 99 03 5A 2F C2X-Dev-1 111 128000

Wave Join Request


00 19 99 03 5A 2F C2X-Dev-1 111 128000 080102030405060708 123456789 184

Wave Join Confirm

rc sent?

0 0


event? reason? mac?


ResetWait4CallState

peer result?

2 0

Wsa Ind Data


7 103 Pers 15 :: 0 00:00:00:00:00:00 184 184 0 2 22 0

Wsa Indication



Wsa Response


0 00 19 99 03 5A 2F C2X-Dev-1 111 128000

Wait4Call


20

L


ProviderSide.WbssCompletion.NewApplicationRequest.ApplicationNotIpv6.ApplicationMorePriority.ConfirmBeforeJoin

















CHECK THE RECEIVED APPLICATION INDICATION

4 2 13 0




Register Request


1 101 0 0 :: 0 0 ::1 49204 0 0 OK

Register Confirm

confirm? result?

0 0

Register Request


1 103 0 0 :: 0 0 ::1 49204 1 0 OK

Register Confirm

confirm? result?

0 0

Wsa Ind Data


7 101 Pers 25 :: 0 00:00:00:00:00:00 184 184 0 2 22 0

Wsa Indication



Wsa Response


0 00 19 99 03 5A 2F C2X-Dev-1 111 128000

Wave Join Request


00 19 99 03 5A 2F C2X-Dev-1 111 12800 080102030405060708 123456789 184

Wave Join Confirm

rc sent?

0 0


event? reason? mac?


Wsa Ind Data


7 103 Pers 35 :: 0 00:00:00:00:00:00 184 184 0 2 22 0

Wsa Indication




21


0: eIE_OP_RETURN_OK



CHECK THAT IS NOT BEING SEND MLME-WAVEEND.REQ

L


ProviderSide.WbssCompletion.NewApplicationRequest.ApplicationNotIpv6.ApplicationMorePriority.NotConfirmBeforeJoin














Pers FF:FF:FF:FF:FF:FF :: 1

ResetWait4CallState

peer result?

2 0


linkconfirm? sent?

0 0

Wait4Call


4 2 13 0




Register Request


1 101 0 0 :: 0 0 ::1 49204 0 0 OK

Register Confirm

confirm? result?

0 0

Register Request


1 103 0 0 :: 0 0 ::1 49204 0 0 OK

Register Confirm

confirm? result?

0 0

Wsa Ind Data


7 101 Pers 25 :: 0 00:00:00:00:00:00 184 184 0 2 22 0

Wsa Indication



Wsa Response


0 00 19 99 03 5A 2F C2X-Dev-1 111 128000

Wave Join Request


00 19 99 03 5A 2F C2X-Dev-1 111 12800 080102030405060708 123456789 184

Wave Join Confirm

22








FIRST APPLICATION RECEIVES NOTIFICATION INDICATION FROM WME








UserSide.LinkActivation.AppMatch.ConfBeforeJoin.AppResponseNotSuccess



REGISTERING + ACTIVATING WBSS USER APPLICATION SENDS REGISTER-REQUEST TO WME: ADD-USER = 1




rc sent?

0 0


event? reason? mac?


Wsa Ind Data


7 103 Pers 35 :: 0 00:00:00:00:00:00 184 184 0 2 22 0

Wsa Indication



Wave End Request

bssid? ssid?

00 19 99 03 5A 2F C2X-Dev-1

Wave End Confirm

rc sent?

0 0


event? reason? mac?


Wave Join Request


00 19 99 03 5A 2F C2X-Dev-1 111 12800 080102030405060708 123456789 184

Wave Join Confirm

rc sent?

0 0


event? reason? mac?





Register Request


1 101 0 0 :: 0 0 ::1 49204 true 0 OK

Register Confirm

confirm? result?

0 0

Wsa Ind Data

23





0: eIE_OP_RETURN_OK



CHECK THAT IS NOT BEING SEND MLME-WAVEJOIN.REQ

L


UserSide.LinkActivation.AppMatch.ConfBeforeJoin.AppResponseSuccess.WaveJoinCfmNotSuccess.NotUsedIpv6












7 101 Pers 48 :: 0 00:00:00:00:00:00 184 184 0 2 22 0

Wsa Indication



Wsa Response


0 00 19 99 03 5A 2F C2X-Dev-1 111 128000




ResetWait4CallState

peer result?

2 0


linkconfirm? sent?

0 0

Wait4Call


4 2 11 0




Register Request


1 101 0 0 :: 0 0 ::1 49204 true 0 OK

Register Confirm

confirm? result?

0 0

Wsa Ind Data


7 101 Pers 48 :: 0 00:00:00:00:00:00 184 184 0 2 22 0

Wsa Indication



Wsa Response


0 00 19 99 03 5A 2F C2X-Dev-1 111 128000





linkconfirm? sent?

1 0

24



0: eIE_OP_RETURN_OK


rc=1: Invalid_Parameters, sent=0: eIE_OP_RETURN_OK''

CHECK THAT IS NOT BEING SEND WME-NOTIFICATION.IND

L


UserSide.LinkActivation.AppMatch.ConfBeforeJoin.AppResponseSuccess.WaveJoinCfmNotSuccess.UsedIpv6












0: eIE_OP_RETURN_OK

Wave Join Request


00 19 99 03 5A 2F C2X-Dev-1 111 128000 080102030405060708 123456789 184

ResetWait4CallState

peer result?

1 0

Wave Join Confirm

rc sent?

1 0

Wait4Call


4 1 20 0




Register Request


1 101 0 0 :: 0 0 ::1 49204 true 0 OK

Register Confirm

confirm? result?

0 0

Wsa Ind Data


63 101 Pers 48 ::1 0 00:00:00:00:00:00 184 184 0 2 22 0

Wsa Indication



Wsa Response


0 00 19 99 03 5A 2F C2X-Dev-1 111 128000





linkconfirm? sent?

1 0

Wave Join Request


00 19 99 03 5A 2F C2X-Dev-1 111 128000 080102030405060708 123456789 184

ResetWait4CallState

peer result?

1 0

25


0: eIE_OP_RETURN_OK



CHECK THAT IT HAS NOT BEEN SEND A REGISTERTXPROFILE.REQ TO THE MLME


L


UserSide.LinkActivation.AppMatch.ConfBeforeJoin.AppResponseSuccess.WaveJoinCfmSuccess.NotUsedIpv6











linkconfirm : 1 = TRUE



ResetWait4CallState

peer result?

2 0

Wave Join Confirm

rc sent?

1 0

Wait4Call


4 2 3 0

Wait4Call


4 1 20 0




Register Request


1 101 0 0 :: 0 0 ::1 49204 true 0 OK

Register Confirm

confirm? result?

0 0

Wsa Ind Data


7 101 Pers 48 :: 0 00:00:00:00:00:00 184 184 0 2 22 0

Wsa Indication



Wsa Response


0 00 19 99 03 5A 2F C2X-Dev-1 111 128000





linkconfirm? sent?

1 0

Wave Join Request


00 19 99 03 5A 2F C2X-Dev-1 111 128000 080102030405060708 123456789 184

Wave Join Confirm

rc sent?

0 0

26





UserSide.LinkActivation.AppMatch.ConfBeforeJoin.AppResponseSuccess.WaveJoinCfmSuccess.UsedIpv6.RegTxProfileNotSuccess















0: eIE_OP_RETURN_OK



event? reason? mac ?





Register Request


1 101 0 0 :: 0 0 ::1 49204 true 0 OK

Register Confirm

confirm? result?

0 0

Wsa Ind Data


63 101 Pers 48 ::1 5540 00:00:00:00:00:00 184 184 0 2 22 0

Wsa Indication



Wsa Response


0 00 19 99 03 5A 2F C2X-Dev-1 111 128000





linkconfirm? sent?

1 0

Wave Join Request


00 19 99 03 5A 2F C2X-Dev-1 111 128000 080102030405060708 123456789 184

Wave Join Confirm

rc sent?

0 0

RegisterTxRequest


184 0 2 22

ResetWait4CallState

peer result?

1 0

RegisterTxConfirm

rc sent?

27



L


UserSide.LinkActivation.AppMatch.ConfBeforeJoin.AppResponseSuccess.WaveJoinCfmSuccess.UsedIpv6.RegTxProfileSuccess










linkconfirm : 1 = TRUE






rc=0: Invalid_Parameters, sent=0: eIE_OP_RETURN_OK L

1 0

Wait4Call


4 1 20 0




Register Request


1 101 0 0 :: 0 0 ::1 49204 true 0 OK

Register Confirm

confirm? result?

0 0

Wsa Ind Data


63 101 Pers 48 ::1 5540 00:00:00:00:00:00 184 184 0 2 22 0

Wsa Indication



Wsa Response


0 00 19 99 03 5A 2F C2X-Dev-1 111 128000





linkconfirm? sent?

1 0

Wave Join Request


00 19 99 03 5A 2F C2X-Dev-1 111 128000 080102030405060708 123456789 184

Wave Join Confirm

rc sent?

0 0

RegisterTxRequest


184 0 2 22

RegisterTxConfirm

rc sent?

0 0

28


UserSide.LinkActivation.AppMatch.NotConfBeforeJoin.WaveJoinCfmNotSuccess.NotUsedIpv6













0: eIE_OP_RETURN_OK



CHECK THAT IT HAS NOT BEEN SEND AN NOTIFICATION INDICATION TO THE APPLICATION

L


UserSide.LinkActivation.AppMatch.NotConfBeforeJoin.WaveJoinCfmNotSuccess.UsedIpv6





Register Request


1 101 0 0 :: 0 0 ::1 49204 0 0 OK

Register Confirm

confirm? result?

0 0

Wsa Ind Data


7 101 Pers 48 :: 0 00:00:00:00:00:00 184 184 0 2 22 0

Wsa Indication



Wsa Response


0 00 19 99 03 5A 2F C2X-Dev-1 111 128000

Wave Join Request


00 19 99 03 5A 2F C2X-Dev-1 111 128000 080102030405060708 123456789 184

Wave Join Confirm

rc sent?

1 0

ResetWait4CallState

peer result?

1 0

Wave Join Confirm

rc sent?

1 0

Wait4Call


4 1 20 0



29










0: eIE_OP_RETURN_OK


0: eIE_OP_RETURN_OK



CHECK THAT IT HAS NOT BEEN SEND A REGISTERTXPROFILE.REQ TO THE MLME

CHECK THAT IT HAS NOT BEEN SEND AN NOTIFICATION INDICATION TO THE APPLICATION

L


UserSide.LinkActivation.AppMatch.NotConfBeforeJoin.WaveJoinCfmSuccess.NotUsedIpv6


Set Up Wme Fixture Base


Register Request


1 101 0 0 :: 0 0 ::1 49204 0 0 OK

Register Confirm

confirm? result?

0 0

Wsa Ind Data


63 101 Pers 48 ::1 5540 00:00:00:00:00:00 184 184 0 2 22 0

Wsa Indication



Wsa Response


0 00 19 99 03 5A 2F C2X-Dev-1 111 128000

Wave Join Request


00 19 99 03 5A 2F C2X-Dev-1 111 128000 080102030405060708 123456789 184

ResetWait4CallState

peer result?

1 0

ResetWait4CallState

peer result?

2 0

Wave Join Confirm

rc sent?

1 0

Wait4Call


4 2 3 0

Wait4Call


4 1 20 0



30


REGISTERING + ACTIVATING WBSS USER APPLICATION SENDS REGISTER REQUEST TO WME: ADD-USER = 1



MLME SENDS WSA INDICATION TO WME


CHECK THE RECEIVED WSA RESPONSE ON MLME







UserSide.LinkActivation.AppMatch.NotConfBeforeJoin.WaveJoinCfmSuccess.UsedIpv6.RegTxProfileNotSuccess









Register Request


1 101 0 0 :: 0 0 ::1 49204 0 0 OK

Register Confirm

confirm? result?

0 0

Wsa Ind Data


7 101 Pers 48 :: 0 00:00:00:00:00:00 184 184 0 2 22 0

Wsa Indication



Wsa Response


0 00 19 99 03 5A 2F C2X-Dev-1 111 128000

Wave Join Request


00 19 99 03 5A 2F C2X-Dev-1 111 128000 080102030405060708 123456789 184

Wave Join Confirm

rc sent?

0 0


event? reason? mac?





Register Request


1 101 0 0 :: 0 0 ::1 49204 0 0 OK

Register Confirm

confirm? result?

0 0

Wsa Ind Data


63 101 Pers 48 ::1 5540 00:00:00:00:00:00 184 184 0 2 22 0

Wsa Indication



Wsa Response

31






0: eIE_OP_RETURN_OK



CHECK THAT IT HAS NOT BEEN SEND AN NOTIFICATION INDICATION

L


UserSide.LinkActivation.AppMatch.NotConfBeforeJoin.WaveJoinCfmSuccess.UsedIpv6.RegTxProfileSuccess











0 00 19 99 03 5A 2F C2X-Dev-1 111 128000

Wave Join Request


00 19 99 03 5A 2F C2X-Dev-1 111 128000 080102030405060708 123456789 184

Wave Join Confirm

rc sent?

0 0

RegisterTxRequest


184 0 2 22

ResetWait4CallState

peer result?

1 0

RegisterTxConfirm

rc sent?

1 0

Wait4Call


4 1 20 0




Register Request


1 101 0 0 :: 0 0 ::1 49204 0 0 OK

Register Confirm

confirm? result?

0 0

Wsa Ind Data


63 101 Pers 48 ::1 5540 00:00:00:00:00:00 184 184 0 2 22 0

Wsa Indication



Wsa Response


0 00 19 99 03 5A 2F C2X-Dev-1 111 128000

Wave Join Request


00 19 99 03 5A 2F C2X-Dev-1 111 128000 080102030405060708 123456789 184

Wave Join Confirm

32








UserSide.LinkActivation.AppNotMatch.ConfBeforeJoin






PREPAIRING WAIT 4 CALL STATES

0: eIE_OP_RETURN_OK


Content:7(psid1+prio2+chan4+)''


CHECK THAT IT HAS NOT BEEN SEND AN APPLICATION INDICATION (NO MATCHED)

L


UserSide.LinkActivation.AppNotMatch.NotConfBeforeJoin


rc sent?

0 0

RegisterTxRequest


184 0 2 22

RegisterTxConfirm

rc sent?

0 0


event? reason? mac?





Register Request


1 105 0 0 :: 0 0 ::1 49204 true 0 OK

Register Confirm

confirm? result?

0 0

ResetWait4CallState

peer result?

1 0

Wsa Ind Data


7 101 Pers 48 :: 0 00:00:00:00:00:00 184 184 0 2 22 0

Wsa Indication



Wsa Response


0 00 19 99 03 5A 2F C2X-Dev-1 111 128000

Wait4Call


4 1 18 0



33






0: eIE_OP_RETURN_OK


Content:7(psid1+prio2+chan4+)''


CHECK THAT IT HAS NOT BEEN SEND A WAVEJOIN REQUEST(NO MATCHED)


UserSide.RegisterRequestConfirm.DeregisterTwice


Action values and other constants

REGISTERING + DEREGISTERING + DEREGSITERING APPLICATION REGISTERING PART:1 REQUEST









Register Request


1 105 0 0 :: 0 0 ::1 49204 false 0 OK

Register Confirm

confirm? result?

0 0

ResetWait4CallState

peer result?

2 0

Wsa Ind Data


7 101 Pers 48 :: 0 00:00:00:00:00:00 184 184 0 2 22 0

Wsa Indication



Wsa Response


0 00 19 99 03 5A 2F C2X-Dev-1 111 128000

Wait4Call


4 2 11 0




Register Request


1 101 0 0 :: 0 0 ::1 49204 true 0 OK

Register Confirm

confirm? result?

0 0

Register Request


3 101 0 0 :: 0 0 ::1 49204 true 0 OK

Register Confirm

confirm? result?

0 0

Register Request


3 101 0 0 :: 0 0 ::1 49204 true 0 OK

34

0: eIE_OP_RETURN_OK, 1: RC_UnspecifiedFailure


UserSide.RegisterRequestConfirm.RegisterDeregisterTwice



REGISTERING + REGISTERING +DEREGISTERING + DEREGISTERING REGISTERING PART:1 REQUEST




REGISTERING PART:4 CONFIRM: ERROR: RC_PSIDCONFLICT







0: eIE_OP_RETURN_OK, 1: RC_UnspecifiedFailure


UserSide.RegisterRequestConfirm.RegisterOk



REGISTERING + DEREGISTERING APPLICATION REGISTERING PART:1 REQUEST

Register Confirm

confirm? result?

0 1




Register Request


1 101 0 0 :: 0 0 ::1 49204 true 0 OK

Register Confirm

confirm? result?

0 0

Register Request


1 101 0 0 0 0 0 ::1 49204 true 0 OK

Register Confirm

confirm? result?

0 3

Register Request


3 101 0 0 :: 0 0 ::1 49204 true 0 OK

Register Confirm

confirm? result?

0 0

Register Request


3 101 0 0 :: 0 0 ::1 54004 true 0 OK

Register Confirm

confirm? result?

0 1




Register Request


35







UserSide.RegisterRequestConfirm.RegisterTwice



REGISTER APPLICATION + REGISTER TWICE THE APPLICLATION REGISTERING PART:1 REQUEST




REGISTERING PART:4 CONFIRM: ERROR: RC_PSIDCONFLICT



UserSide.WbssCompletion.ApplicationDeactivation.NotUsedIpv6





1 101 0 0 :: 0 0 ::1 49204 true 0 OK

Register Confirm

confirm? result?

0 0

Register Request


3 101 0 0 :: 0 0 ::1 49204 true 0 OK

Register Confirm

confirm? result?

0 0




Register Request


1 101 0 0 :: 0 0 ::1 49204 false 0 OK

Register Confirm

confirm? result?

0 0

Register Request


1 101 0 0 0 0 0 ::1 49204 false 0 OK

Register Confirm

confirm? result?

0 3




Register Request


1 101 0 0 :: 0 0 ::1 49204 0 0 OK

Register Confirm

confirm? result?

0 0

36
















event=0: WBSS_Inactive, reason=1: NOTIF_REASON_ApplicationRequested


UserSide.WbssCompletion.ApplicationDeactivation.UsedIpv6





Wsa Ind Data


7 101 Pers 48 :: 0 00:00:00:00:00:00 184 184 0 2 22 0

Wsa Indication



Wsa Response


0 00 19 99 03 5A 2F C2X-Dev-1 111 128000

Wave Join Request


00 19 99 03 5A 2F C2X-Dev-1 111 128000 080102030405060708 123456789 184

Wave Join Confirm

rc sent?

0 0


event? reason? mac?


Application Request


101 123456789 2 FF:FF:FF:FF:FF:FF 0 0 255 0 OK

Wave End Request

bssid? ssid?

00 19 99 03 5A 2F C2X-Dev-1

Wave End Confirm

rc sent?

0 0

Application Confirm

confirm? result?

0 0


event? reason? mac?





Register Request


1 101 0 0 :: 0 0 ::1 49204 0 0 OK

37


















rc=1: SUCCESS, sent=0: eIE_OP_RETURN_OK




Register Confirm

confirm? result?

0 0

Wsa Ind Data


63 101 Pers 48 ::1 5540 00:00:00:00:00:00 184 184 0 2 22 0

Wsa Indication



Wsa Response


0 00 19 99 03 5A 2F C2X-Dev-1 111 128000

Wave Join Request


00 19 99 03 5A 2F C2X-Dev-1 111 128000 080102030405060708 123456789 184

Wave Join Confirm

rc sent?

0 0

RegisterTxRequest


184 0 2 22

RegisterTxConfirm

rc sent?

0 0


event? reason? mac?


Application Request


101 123456789 2 FF:FF:FF:FF:FF:FF 0 0 255 0 OK

DeleteTxRequest

channelnr?

184

DeleteTxConfirm

rc sent?

0 0

Wave End Request

bssid? ssid?

00 19 99 03 5A 2F C2X-Dev-1

Wave End Confirm

rc sent?

0 0

Application Confirm

confirm? result?

0 0


38



UserSide.WbssCompletion.ApplicationDeregistration.NotUsedIpv6













APPLICATION SENDS REGISTER-REQUEST TO WME: REMOVE-USER = 3




APPLICATION RECEIVES DE-REGISTER-CONFIRM FROM WME

event? reason? mac?





Register Request


1 101 0 0 :: 0 0 ::1 49204 0 0 OK

Register Confirm

confirm? result?

0 0

Wsa Ind Data


7 101 Pers 48 :: 0 00:00:00:00:00:00 184 184 0 2 22 0

Wsa Indication



Wsa Response


0 00 19 99 03 5A 2F C2X-Dev-1 111 128000

Wave Join Request


00 19 99 03 5A 2F C2X-Dev-1 111 128000 080102030405060708 123456789 184

Wave Join Confirm

rc sent?

0 0


event? reason? mac?


Register Request


3 101 0 0 :: 0 0 ::1 49204 0 0 OK

Wave End Request

bssid? ssid?

00 19 99 03 5A 2F C2X-Dev-1

Wave End Confirm

rc sent?

1 0

Register Confirm

confirm? result?

0 0

39





UserSide.WbssCompletion.ApplicationDeregistration.UsedIpv6
















APPLICATION SENDS DEREGISTER-REQUEST TO WME: REMOVE-USER = 3



event? reason? mac?





Register Request


1 101 0 0 :: 0 0 ::1 49204 0 0 OK

Register Confirm

confirm? result?

0 0

Wsa Ind Data


63 101 Pers 48 ::1 5540 00:00:00:00:00:00 184 184 0 2 22 0

Wsa Indication



Wsa Response


0 00 19 99 03 5A 2F C2X-Dev-1 111 128000

Wave Join Request


00 19 99 03 5A 2F C2X-Dev-1 111 128000 080102030405060708 123456789 184

Wave Join Confirm

rc sent?

0 0

RegisterTxRequest


184 0 2 22

RegisterTxConfirm

rc sent?

0 0


event? reason? mac?


Register Request


3 101 0 0 :: 0 0 ::1 49204 0 0 OK

40






APPLICATION RECEIVES DEREGISTER-CONFIRM FROM WME





UserSide.WbssCompletion.ApplicationUnavailable.NotUsedIpv6










DeleteTxRequest

channelnr?

184

DeleteTxConfirm

rc sent?

0 0

Wave End Request

bssid? ssid?

00 19 99 03 5A 2F C2X-Dev-1

Wave End Confirm

rc sent?

1 0

Register Confirm

confirm? result?

0 0


event? reason? mac?





Register Request


1 101 0 0 :: 0 0 ::1 49204 0 0 OK

Register Confirm

confirm? result?

0 0

Wsa Ind Data


7 101 Pers 48 :: 0 00:00:00:00:00:00 184 184 0 2 22 0

Wsa Indication



Wsa Response


0 00 19 99 03 5A 2F C2X-Dev-1 111 128000

Wave Join Request


00 19 99 03 5A 2F C2X-Dev-1 111 128000 080102030405060708 123456789 184

Wave Join Confirm

rc sent?

0 0

41




APPLICATION SENDS UNAVAILABLE-REQUEST TO WME: ACTIVATE = 0




APPLICATION RECEIVES THE UNAVAILABLE-CONFIRMATION





0: eIE_OP_RETURN_OK




APPLICATION SENDS INACTIVE-REQUEST TO WME: ACTIVATE = 2

APPLICATION RECEIVES THE INACTIVE-CONFIRMATION

0: eIE_OP_RETURN_OK, 0: RC_Success''


UserSide.WbssCompletion.ApplicationUnavailable.UsedIpv6



event? reason? mac?


Application Request


101 123456789 0 FF:FF:FF:FF:FF:FF 0 0 255 0 OK

Wave End Request

bssid? ssid?

00 19 99 03 5A 2F C2X-Dev-1

Wave End Confirm

rc sent?

0 0

Application Confirm

confirm? result?

0 0


event? reason? mac?


ResetWait4CallState

peer result?

2 0

Wsa Ind Data


7 101 Pers 48 :: 0 00:00:00:00:00:00 184 184 0 2 22 0

Wsa Indication



Wsa Response


0 00 19 99 03 5A 2F C2X-Dev-1 111 128000

Wait4Call


4 2 11 0

Application Request


101 123456789 2 FF:FF:FF:FF:FF:FF 0 0 255 0 OK

Application Confirm

confirm? result?

0 0



42















APPLICATION SENDS UNAVAILABLE-REQUEST TO WME: ACTIVATE = 0







Register Request


1 101 0 0 :: 0 0 ::1 49204 0 0 OK

Register Confirm

confirm? result?

0 0

Wsa Ind Data


63 101 Pers 48 ::1 5540 00:00:00:00:00:00 184 184 0 2 22 0

Wsa Indication



Wsa Response


0 00 19 99 03 5A 2F C2X-Dev-1 111 128000

Wave Join Request


00 19 99 03 5A 2F C2X-Dev-1 111 128000 080102030405060708 123456789 184

Wave Join Confirm

rc sent?

0 0

RegisterTxRequest


184 0 2 22

RegisterTxConfirm

rc sent?

0 0


event? reason? mac?


Application Request


101 123456789 0 FF:FF:FF:FF:FF:FF 0 0 255 0 OK

DeleteTxRequest

channelnr?

184

DeleteTxConfirm

rc sent?

0 0

Wave End Request

bssid? ssid?

00 19 99 03 5A 2F C2X-Dev-1

Wave End Confirm

rc sent?

0 0

43


APPLICATION RECEIVES THE THE UNAVAILABLE-CONFIRMATION





0: eIE_OP_RETURN_OK




APPLICATION SENDS INACTIVE-REQUEST TO WME: ACTIVATE = 2

APPLICATION RECEIVES THE INACTIVE-CONFIRMATION

0: eIE_OP_RETURN_OK, 0: RC_Success''


UserSide.WbssCompletion.ChannelInactivity.NotUsedIpv6







Application Confirm

confirm? result?

0 0


event? reason? mac?


ResetWait4CallState

peer result?

2 0

Wsa Ind Data


63 101 Pers 48 ::1 5540 00:00:00:00:00:00 184 184 0 2 22 0

Wsa Indication



Wsa Response


0 00 19 99 03 5A 2F C2X-Dev-1 111 128000

Wait4Call


4 2 11 0

Application Request


101 123456789 2 FF:FF:FF:FF:FF:FF 0 0 255 0 OK

Application Confirm

confirm? result?

0 0




Register Request


1 101 0 0 :: 0 0 ::1 49204 0 0 OK

Register Confirm

confirm? result?

0 0

Wsa Ind Data


7 101 Pers 48 :: 0 00:00:00:00:00:00 184 184 0 2 22 0

44












event=0: WBSS_Inactive, reason=2: NOTIF_REASON_ChannelInactivity


UserSide.WbssCompletion.ChannelInactivity.UsedIpv6







Wsa Indication



Wsa Response


0 00 19 99 03 5A 2F C2X-Dev-1 111 128000

Wave Join Request


00 19 99 03 5A 2F C2X-Dev-1 111 128000 080102030405060708 123456789 184

Wave Join Confirm

rc sent?

0 0


event? reason? mac?



channelnumber sent?

184 0

Wave End Request

bssid? ssid?

00 19 99 03 5A 2F C2X-Dev-1

Wave End Confirm

rc sent?

0 0


event? reason? mac?





Register Request


1 101 0 0 :: 0 0 ::1 49204 0 0 OK

Register Confirm

confirm? result?

0 0

Wsa Ind Data


63 101 Pers 48 ::1 5540 00:00:00:00:00:00 184 184 0 2 22 0

Wsa Indication



45


















event=0: WBSS_Inactive, reason=2: NOTIF_REASON_ChannelInactivity''


UserSide.WbssCompletion.NewApplicationRequest.ApplicationIpv6.ApplicationLessPriority



Wsa Response


0 00 19 99 03 5A 2F C2X-Dev-1 111 128000

Wave Join Request


00 19 99 03 5A 2F C2X-Dev-1 111 128000 080102030405060708 123456789 184

Wave Join Confirm

rc sent?

0 0

RegisterTxRequest


184 0 2 22

RegisterTxConfirm

rc sent?

0 0


event? reason? mac?



channelnumber sent?

184 0

DeleteTxRequest

channelnr?

184

DeleteTxConfirm

rc sent?

0 0

Wave End Request

bssid? ssid?

00 19 99 03 5A 2F C2X-Dev-1

Wave End Confirm

rc sent?

0 0


event? reason? mac?





46

REGISTERING FIRST APPLICATION + REGISTERING SECOND APPLICATION + ACTIVE LINK FIRST APPLICATION + REQUEST SECOND APPLICATION ACTIVATION + CHECK NO DELETETXPROFILE AND NO WAVEEND IS SENT TO MLME FIRST APPLICATION SENDS REGISTER-REQUEST TO WME: ADD-USER = 1




















Register Request


1 101 0 0 :: 0 0 ::1 49204 0 0 OK

Register Confirm

confirm? result?

0 0

Register Request


1 103 0 0 :: 0 0 ::1 49204 1 0 OK

Register Confirm

confirm? result?

0 0

Wsa Ind Data


63 101 Pers 25 ::1 5540 00:00:00:00:00:00 184 184 0 2 22 0

Wsa Indication



Wsa Response


0 00 19 99 03 5A 2F C2X-Dev-1 111 128000

Wave Join Request


00 19 99 03 5A 2F C2X-Dev-1 111 128000 080102030405060708 123456789 184

Wave Join Confirm

rc sent?

0 0

RegisterTxRequest


184 0 2 22

RegisterTxConfirm

rc sent?

0 0


event? reason? mac?


ResetWait4CallState

peer result?

2 0

Wsa Ind Data


63 103 Pers 15 ::1 5540 00:00:00:00:00:00 184 184 0 2 22 0

Wsa Indication


47


CHECK THAT IT HAS NOT BEEN SENT A DELETETXPROFILE.REQ (CALLID = 5)



UserSide.WbssCompletion.NewApplicationRequest.ApplicationIpv6.ApplicationMorePriority
















Wsa Response


0 00 19 99 03 5A 2F C2X-Dev-1 111 128000

Wait4Call


4 2 5 0

Wait4Call


4 2 13 0




Register Request


1 101 0 0 :: 0 0 ::1 49204 0 0 OK

Register Confirm

confirm? result?

0 0

Register Request


1 103 0 0 :: 0 0 ::1 49204 0 0 OK

Register Confirm

confirm? result?

0 0

Wsa Ind Data


63 101 Pers 25 ::1 5540 00:00:00:00:00:00 184 184 0 2 22 0

Wsa Indication



Wsa Response


0 00 19 99 03 5A 2F C2X-Dev-1 111 128000

Wave Join Request


00 19 99 03 5A 2F C2X-Dev-1 111 128000 080102030405060708 123456789 184

Wave Join Confirm

rc sent?

0 0

RegisterTxRequest


48






















184 0 2 22

RegisterTxConfirm

rc sent?

0 0


event? reason? mac?


Wsa Ind Data


63 103 Pers 35 ::1 5540 00:00:00:00:00:00 184 184 0 2 22 0

Wsa Indication



Wsa Response


0 00 19 99 03 5A 2F C2X-Dev-1 111 128000

DeleteTxRequest

channelnr?

184

DeleteTxConfirm

rc sent?

0 0

Wave End Request

bssid? ssid?

00 19 99 03 5A 2F C2X-Dev-1

Wave End Confirm

rc sent?

1 0


event? reason? mac?


Wave Join Request


00 19 99 03 5A 2F C2X-Dev-1 111 128000 080102030405060708 123456789 184

Wave Join Confirm

rc sent?

0 0

RegisterTxRequest


184 0 2 22

RegisterTxConfirm

rc sent?

0 0


event? reason? mac?


49

event=1: WBSS_Active, reason=1: NOTIF_REASON_ApplicationRequested Tear Down: .WmeTestAppPages.TearDown

UserSide.WbssCompletion.NewApplicationRequest.ApplicationNotIpv6.ApplicationLessPriority



REGISTERING FIRST APPLICATION + REGISTERING SECOND APPLICATION + ACTIVE LINK FIRST APPLICATION + REQUEST SECOND APPLICATION ACTIVATION + CHECK NO WAVEEND IS SENT TO MLME FIRST APPLICATION SENDS REGISTER-REQUEST TO WME: ADD-USER = 1


















Register Request


1 101 0 0 :: 0 0 ::1 49204 0 0 OK

Register Confirm

confirm? result?

0 0

Register Request


1 103 0 0 :: 0 0 ::1 49204 0 0 OK

Register Confirm

confirm? result?

0 0

Wsa Ind Data


7 101 Pers 25 :: 0 00:00:00:00:00:00 184 184 0 2 22 0

Wsa Indication



Wsa Response


0 00 19 99 03 5A 2F C2X-Dev-1 111 128000

Wave Join Request


00 19 99 03 5A 2F C2X-Dev-1 111 128000 080102030405060708 123456789 184

Wave Join Confirm

rc sent?

0 0


event? reason? mac?


ResetWait4CallState

peer result?

2 0

50





UserSide.WbssCompletion.NewApplicationRequest.ApplicationNotIpv6.ApplicationMorePriority














Wsa Ind Data


7 103 Pers 15 :: 0 00:00:00:00:00:00 184 184 0 2 22 0

Wsa Indication



Wsa Response


0 00 19 99 03 5A 2F C2X-Dev-1 111 128000

Wait4Call


4 2 13 0




Register Request


1 101 0 0 :: 0 0 ::1 49204 0 0 OK

Register Confirm

confirm? result?

0 0

Register Request


1 103 0 0 :: 0 0 ::1 49204 0 0 OK

Register Confirm

confirm? result?

0 0

Wsa Ind Data


7 101 Pers 25 :: 0 00:00:00:00:00:00 184 184 0 2 22 0

Wsa Indication



Wsa Response


0 00 19 99 03 5A 2F C2X-Dev-1 111 128000

Wave Join Request


00 19 99 03 5A 2F C2X-Dev-1 111 128000 080102030405060708 123456789 184

Wave Join Confirm

rc sent?

0 0

51







FIRST APPLICATION RECEIVES NOTIFICATION INDICATION FROM WME









event? reason? mac?


Wsa Ind Data


7 103 Pers 35 :: 0 00:00:00:00:00:00 184 184 0 2 22 0

Wsa Indication



Wave End Request

bssid? ssid?

00 19 99 03 5A 2F C2X-Dev-1

Wave End Confirm

rc sent?

0 0


event? reason? mac?


Wave Join Request


00 19 99 03 5A 2F C2X-Dev-1 111 128000 080102030405060708 123456789 184

Wave Join Confirm

rc sent?

0 0


event? reason? mac?



52

Documents

FINAL PROJECT - TU Wien · 1.2 Structure of the Thesis 1 2 WAVE Systems 3 2.1 General ... 5.2 Use of FitNesse in this Diploma Thesis 18 5.3 Implementation of a test using FitNesse