WRM Spec 0.2 Draft

1WRM Specification version 0.2 (WRM-Spec-Ref0.
2)
2
3
1
2
3
4
WRM Specification for Mobile Devices

Ref WRM: WRM-Spec-Ref0.2
Ref RRM: RRM-Spec-Ref0.1
5
6
7
8
9
10
11
History
Date
10-15-2009
11-23-2009
Version
0.1
0.2
First draft released for the purpose of a review.

First review done
12
13
14
Warning
This document can be updated or modified at any time without pre-notification.
Also this document is the property of the MAG lab and so, nobody can use all
things defined or introduced in this paper without our agreement ahead before.
The contact information: Seungil Yoon (-)
MAG
Lab presents
4
Page 1 of 67
1WRM Specification version 0.2
2
1Major Issues.
2
3
Issue title
1. Finalize the definition
of Network index (N_N)
and Zone index (N_Z)
Priority
Critical
Status
Closed
Description
Comparing to the original approach suggested by
Dr. Lim, the N_N and the N_Z have rather different
definitions.
[11/23/2009] Discussion
1. The PRRM can divide all N_Rs, which can
provide session continuity, into multiple N_Z
areas based on a location type. For example, a
campus wireless WiFi network having the
same SSID can have either one N_Z ID or a
different N_Z ID per each campus building.
2. The PRRM should provide an intelligent way
of assigning N_L and N_R IDs rather than
simply assign a meaningless number. Like
Cellular, probably N_L and N_R can embed
Country Code or Area Code with Network
Information such as network type and network
provider information plus cell ID or SSID.
[11/23/2009] Conclusion
1. The revised N_N and N_Z are accepted.
This issue is so close to the PRRM design. TBD
2. Finalize or temporally
define all weight factor
values (for example,
W_R) and the way of
manipulating other
operation related
parameters such as
statistical time values.
3. Define the metrics of
WRM performance from
network to battery status.
4. Finalize a handoff
decision algorithm & a
handoff execution
procedure.
Major
(urgent)
Not
Handled
Major
(not
urgent)
Critical
Not
Handled
TBD
In
progress
1. Because Androids internal operations, which
are related to handoff procedures, are not clear,
any impacts caused by the WRM-led handover
are unpredictable. Further investigation is
required.
5. Define all maximum

values of constants
defined in Appendix A for
WRM signaling messages
6. Defines new header
and pack/unpack library
for WRM application and
the PRRM message
handler.
Major
(not
urgent)
Not
Handled
TBD
Major
(urgent)
In
Progress
In the first stage of an integration test, all messages

shall not use bit packing, instead, simply use the C
structure type casting.
1. In the document of interoperability tests, some
examples of signaling messages shall be
presented.
Page 2 of 67
MAG Lab presents
1WRM Specification version 0.2 (WRM-Spec-Ref0.2)
2
3
7. Compose
interoperability test
scenarios.
Medium
In
Progress
1. The specification of the interoperability tests
will be defined as soon as possible.
8. Define the structure of

the user log table, and the
way of uploading to the
PRRM.
Critical
(urgent)
In
Progress
First of all, a format of the user log table must be

defined. Then, the WRM application must be able
to compact some multiple events as one. For
example, the android phone may make multiple
sensing reports having a little different the list of
found access points. However, the WRM
application may list up all access points into one
event log record instead. Lets discuss this.
1. A review on the suggested user log table is
required.
2. For a real time monitoring, the PRRM and the
WRM should be able to setup a filtering
configuration for event reports. For example,
some events should be immediately reported to
the PRRM.
[11/23/2009] Next action
1. Preferred WRM Configuration field of a
Registration Reply message and a Radio
Report message can be used to setup which
events should be reported immediately. The
next spec, v 0.2, will define the field.
9. Detail how to upload

the user log table.
Because of its size, the
upload in a log file shall
be required.
Major
(urgent)
10. Manage user profile

and the WEP key for an
automatic login.
Major
(not
urgent)
In
Progress
P2P or FTP or other ways to upload whatever

networks WRM mobile devices can associate to
upload the user log file.
1. Further investigation is required
New
registered
1. The PRRM will not keep a user profile for an
automatic WiFi/3G login.
[11/23/2009] Next action
1. However, it is required to check whether the
WRM application can retrieve the user profile
from the Android.
2. Network List will be revised to save the WEP
key.
1
2Beside, the PRRM and the CRRM are now expected to be released the first version
3in Jan. 2010.
4
MAG
Lab presents
4
Page 3 of 67
2
3
1Contents
2
31
Overview......................................................................................................................9
4 1.1
Scope of the Document........................................................................................9
5 1.2
Requirements Language......................................................................................9
6 1.3
Architecture Reference Model.............................................................................9
7 1.4
WRM Architecture.............................................................................................10
8
1.4.1
Lifecycle....................................................................................................10
9
1.4.2
States..........................................................................................................10
10
1.4.3
Handlers.....................................................................................................11
11
1.4.4
WRM database...........................................................................................12
122
WRM Application Architecture.................................................................................12
13 2.1
Introduction........................................................................................................12
14
2.1.1
General Overview......................................................................................13
15
2.1.2
Architecture Reference Model...................................................................14
16 2.2
Parameters..........................................................................................................14
17 2.3
WRM database...................................................................................................15
18
2.3.1
Location Table...........................................................................................15
19
2.3.2
Selection Table...........................................................................................15
20
2.3.3
Radio Resource Table................................................................................16
21 2.4
WRM database lifecycle....................................................................................16
22
2.4.1
Initial stage.................................................................................................16
23
2.4.2
Active stage...............................................................................................21
243
Session Control Protocol...........................................................................................24
25 3.1
Introduction........................................................................................................24
26
3.1.1
27
3.1.2
Call Flow...................................................................................................24
28 3.2
WRM application sequence flow.......................................................................27
29
3.2.1
Sequence flow for Case 1) and Case 2).....................................................27
30
3.2.2
Sequence flow for Case 3) and Case 4).....................................................28
314
Radio Monitoring Protocol........................................................................................29
32 4.1
Introduction........................................................................................................29
33
4.1.1
34
4.1.2
Call Flow...................................................................................................29
35 4.2
WRM application sequence flow.......................................................................30
36
4.2.1
Sequence flow for Case 1), Case 2) and Case 3).......................................30
375
WRM Service Lifecycle............................................................................................31
38 5.1
Introduction........................................................................................................31
39
5.1.1
40
5.1.2
Service Lifecycle.......................................................................................32
41 5.2
Mode 0...............................................................................................................33
42 5.3
Mode 1...............................................................................................................34
43 5.4
WRM-led Handover..........................................................................................35
44
5.4.1
Handover monitoring.................................................................................35
45
5.4.2
Handover execution...................................................................................38
466
Messages and Database.............................................................................................39
MAG
Lab presents
4
Page 4 of 67
2
3
1 6.1
Messages............................................................................................................39
2
6.1.1
Common Header........................................................................................39
3
6.1.2
Registration Request..................................................................................40
4
6.1.3
Registration Reply.....................................................................................45
5
6.1.4
Radio Report..............................................................................................46
6
6.1.5
Radio Report Reply...................................................................................49
7 6.2
Databases...........................................................................................................49
8
6.2.1
Selection Table...........................................................................................49
9
6.2.2
Location Table...........................................................................................51
10
6.2.3
Radio Resource Table................................................................................52
11
6.2.4
User Log Table...........................................................................................52
12Appendix. A C Structure of WRM signaling messages....................................................55
13Appendix. B Class Diagram of WRM application...........................................................67
14
MAG
Lab presents
4
Page 5 of 67
2
1Figures
2
3<FIGURE 1.4.1-1> WRM ARCHITECTURE REFERENCE MODEL...........................................9
4<FIGURE 1.4.1-1> WRM LIFECYCLE................................................................................10
5<FIGURE 2.1.2-1> WRM ARCHITECTURE REFERENCE MODEL........................................14
6<FIGURE 2.4.1-1> EXAMPLE OF WRM DB LIST...............................................................18
7<FIGURE 2.4.1-2> EXAMPLE OF WRM CALL FLOW TO UPLOAD THE USER LOG TABLE 19
8<FIGURE 2.4.2-1> EXAMPLE OF WRM-LED HANDOVER..................................................21
9<FIGURE 3.1.2-1> CALL FLOW OF SESSION CONTROL PROTOCOL...................................24
10<FIGURE 3.1.2-2> CALL FLOW FOR THE PRRM-INITIATED SESSION CONTROL..............26
11<FIGURE 3.2.1-1> SEQUENCE FLOW OF WRM APPLICATION FOR CASE 1) AND CASE 2).
12
...................................................................................................................................27
13<FIGURE 3.2.2-1> SEQUENCE FLOW OF WRM APPLICATION FOR CASE 3) AND CASE 4).
14
...................................................................................................................................28
15<FIGURE 4.1.2-1> CALL FLOW FOR RADIO MONITORING PROTOCOL.............................29
16<FIGURE 4.2.11-1> SEQUENCE FLOW OF WRM APPLICATION FOR CASE 1) , CASE 2) AND
17
CASE 3)......................................................................................................................30
18<FIGURE 5.1.22-1> WRM SERVICE LIFECYCLE...............................................................32
19
Page 6 of 67
MAG Lab presents
2
3
1Tables
2
3<TABLE 2.4.1-1> FORMAT OF USER LOG TABLE ...............................................................17
4<TABLE 2.4.1-2> EXAMPLE OF LOCATION TABLE.............................................................18
5<TABLE 2.4.1-3> EXAMPLE OF RADIO RESOURCE TABLE................................................19
6<TABLE 2.4.1-4> [BEFORE UPDATE] EXAMPLE OF SELECTION TABLE..............................19
7<TABLE 2.4.1-5> [BEFORE UPDATE] EXAMPLE OF RADIO RESOURCE TABLE...................19
8<TABLE 2.4.1-6> EXAMPLE OF USER LOG TABLE............................................................20
9<TABLE 2.4.2-1> [BEFORE UPDATE] EXAMPLE OF SELECTION TABLE IN ACTIVE STAGE.21
10<TABLE 2.4.2-2> EXAMPLE OF RADIO RESOURCE TABLE IN ACTIVE STAGE...................22
11<TABLE 2.4.2-3> [AFTER UPDATE 1] EXAMPLE OF SELECTION TABLE IN ACTIVE STAGE 22
12<TABLE 2.4.2-4> [AFTER UPDATE 1] EXAMPLE OF SELECTION TABLE IN ACTIVE STAGE 23
13<TABLE 3.1.2-1> EXAMPLE OF REGISTRATION REQUEST MESSAGE..................................25
14<TABLE 3.1.2-2> EXAMPLE OF REGISTRATION REPLY MESSAGE......................................25
15<TABLE 3.1.2-3> EXAMPLE OF REGISTRATION REPLY MESSAGE FOR ASYNCHRONOUS
16
RETRIEVAL.................................................................................................................27
17<TABLE 4.1.2-1> EXAMPLE OF RADIO REPORT MESSAGE.................................................30
18<TABLE 4.1.2-2> EXAMPLE OF RADIO REPORT REPLY MESSAGE.....................................30
19<TABLE 6.1.1-1> COMMON HEADER.................................................................................39
20<TABLE 6.1.2-1> REGISTRATION REQUEST MESSAGE.......................................................40
21<TABLE 6.2.1-1> REGISTRATION REPLY MESSAGE............................................................45
22<TABLE 6.1.4-1> RADIO REPORT MESSAGE......................................................................46
23<TABLE 6.1.5-1> RADIO REPORT REPLY MESSAGE...........................................................49
24<TABLE 6.2.1-1> SELECTION TABLE.................................................................................49
25<TABLE 6.2.2-1> LOCATION TABLE..................................................................................51
26<TABLE 6.2.3-1> RADIO RESOURCE TABLE......................................................................52
27<TABLE 6.2.4-1> USER LOG TABLE..................................................................................52
28
MAG
Lab presents
4
Page 7 of 67
2
1Terms
2
3WRM: WiRider ( or WiRider Manager )
4
5PRRM: Personal Radio Resource Map
6
7CRRM: Cognitive Radio Resource Map
Page 8 of 67
MAG Lab presents
2
3
11
Overview
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
1.1
Scope of the Document
This standard document presents technical requirements for mobile devices in the
WiRider (WRM) network system. These requirements assume that a WRM compliant
mobile device can obtain WRM services through WRM network conforming to this
standard with the help of PRRM and CRRM servers.
These requirements are only dedicated to technical necessities for the design and
implementation of the WRM compliant mobile device. Any quality and performance
measurements are not described in this document.
1.2
Requirements Language
Any WRMs compliant mobile device can obtain WRM services with PRRM and
CRRM servers conforming to this standard.
Shall and Shall not means that requirements shall be strictly followed to a given
requirement or action in the standard while Should and Should not indicate that
one of multiple possible configurations or combinations will be chosen depending on
a particular condition. May and may not indicate that requirements are possibly
implemented but not required.
1.3
Architecture Reference Model
The WRM architecture reference model consists of the following functional

subsystems: The WRM compliant mobile device, the PRRM server and the CRRM
server.
<Figure 1.4.1-1> WRM Architecture Reference Model
The WRM interface exists between WRM and the PRRM, and the protocols for the
interface are defined in this standard document.
MAG
Lab presents
4
Page 9 of 67
2
1
2
3
4
5
1.4
WRM Architecture
The WRM architecture consists of five major handlers and one function unit, but all
of them are integrated as one application, WRM, to make the interface easily be
ported over any type of mobile device platforms.
6
1.4.1 Lifecycle
7
8
Figure 1.4.1-1 shows the diagram of the WRM lifecycle.
9
10<Figure 1.4.1-2> WRM lifecycle
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
1.4.2 States
The WRM application shall stay in the Initial state for a while when the application is
(re)executed.
1. Initial state: the WRM application shall check the availability of location
information retrieval and should check network connectivity to the Internet.
The location information retrieval shall use a network-based GPS positioning
service, and the WRM application should prefer WiFi services to connect to
the Internet, but the Internet connection over other access networks should be
Page 10 of 67
MAG Lab presents
2
3
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
accepted. A state transition to the active state shall be occurred when two
functionalities are successfully operated.
2. Active state: the WRM application shall perform WRM-led network selection
and handover, monitor mobile device performance, and gather all monitoring
results in user log table. The user log table shall be uploaded to the PRRM on
a scheduled time. Monitoring results may be uploaded in a real time or
periodically when the PRRM requested to do it. A state transition to the initial
state shall be only occurred when the WRM application is terminated.
In the active state, a handler transition shall be taken when the mobile device moves
to a new location or known location but a WRM database of the new location is out of
date. This handler transition shall disable WRM-led handover and enable a Sniff
function unit to collect available access networks. With the help of the Sniff function
unit, the WRM application can help the PRRM build or update the WRM database of
the new location. When the WRM database becomes matured, the state transition to
the Active state shall be taken.
1.4.3 Handlers
Each handler should perform their own functionality.
1. Initial Handler: This handler shall be executed while the WRM application
stays in the Initial state. During this state, the validity of retrieving location
information shall be checked.
2. WRM Explorer: when a WRM compliant mobile device enters into a new
location or recognizes the WRM database of a current location incorrect or out
of date, the WRM Explorer handler performs the WRM database
reconstruction of the current location through searching available access
networks and/or updating the WRM database with the help of the Sniff
function unit.
3. WRM Handler: this handler as a main controller manages other handlers
execution. The WRM Handler shall provide User Interface to a mobile user to
configure WRM application settings and provide handling procedures for all
WRM events. The WRM Handler shall handle all signaling messages that are
exchanged with the PRRM.
4. Handoff Handler: the handoff handler provides an intelligent vertical or
horizontal handover. This handler shall be executed in parallel with the WRM
Handler if the WRM-led handover is enabled. Handover algorithms and
procedures are defined in this document.
5. Communication Handler: the communication handler performs all signaling
message transmission to and retrieval from the PRRM.
6. Event Logger Handler: the event logger handler shall save all events and
monitoring in the user log table, and the handler shall upload the user log table
to the PRRM on a scheduled time or in a real time periodically or
asynchronously. Scheduling the upload timing shall be possible through
modifying an upload time profile in the WRM application preference.
MAG
Lab presents
4
Page 11 of 67
2
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
312
Two protocols are defined in the WRM Interface.

1. Session Control Protocol: this protocol defines signaling messages and
message handling procedures, used in between the WRM application and the
PRRM server, to initiate, update and terminate the WRM session.
2. Radio Monitoring Protocol: this protocol defines signaling messages that are
used to report WRM events, which are registered as events that are to be
informed to the PRRM, in a real time or periodically rather than the user log
table cumulated over a pre-defined time such as every day.
The WRM Handler and the WRM Explorer shall provide handling-building,
interpreting and processing-two protocols signaling messages.
1.4.4 WRM database

The WRM database consists of three tables.
1. Selection Table: a selection table shall present handover information that
helps the WRM application select the best or alternative access network at a
current location and next possible location.
2. Location Table: a location table shall present the list of locations where the
mobile device has visited or are expected to visit in near the future.
3. Radio Resource Table: a radio resource table shall present the list of
available and/or associated access networks at all locations that are shown in
the location table.
Manipulation and usage of three tables in the WRM application are described in the
third chapter.
WRM Application Architecture
32
33
34
35
36
37
38
39
40
41
42
2.1
Introduction
The main objective of the WRM application is to help a mobile device select
efficiently an access point as an active one at an area that multiple homogeneous
and/or heterogeneous networks exist.
Every mobile device can have different access network interfaces, and in addition,
some users can be able to associate to one specific access network while other users
can not do it at the same location. Instead of building a global radio resource map, all
users can have its own private radio resource map as its own virtual network.
Page 12 of 67
MAG Lab presents
2
3
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
2.1.1 General Overview

After the WRM application is installed on the mobile device, the WRM application
shall simply gather locations where the mobile device has visited and access networks
that the mobile device has associated and detected. The WRM application also shall
monitor mobile device performance-network, CPU load, active tasks and battery
status and record all in the user log table. At a promised time, those collected
information shall be uploaded to the PRRM.
The PRRM shall analyze the uploaded user log table to find out a user behavior
pattern: where the mobile device navigates, which access networks are available and
are actively associated, which access network at each location seems to be better in a
performance matter. Based on the analysis, the location table, the radio resource table
and the selection table for the mobile device shall be constructed.
There are three conceptual objects and one constant that form these tables.
1. Location: this object represents the GPS position values of a current location.
Every user assigns one unique location index (N_L) to every location, which
is retrieved from network-based location services. Two users can assign
different N_L values to the same location.
2. Network Type: this constant indicates the network type of an access point at a
location. There are five network types defined as the following
N_N1 : Cellular (>= 3G)
N_N2 : WiFi
N_N3 : legacy cellular (<3G)
N_N4 : Femtocell (WiFi+Cellular)
N_N5: WiMax
N_N6~N10: reserved
3. Radio Resource: this object indicates which access points or base stations can
be associated to the mobile device. Like the location object, every user assigns
unique radio resource index number (N_R) to every base station or access
point. The access point, which was associated successfully before, shall be
registered in each users WRM database. Other access points should be
included when they are classified as accessible networks to the user.
4. Zone: this object represents that all radio resources having the same Zone
index (N_Z) can provide session continuity. For instance, if multiple WiFi
access points have the same SSID, they can provide session continuity without
assigning a new IP address or logging in everytime whenever the mobile
device needs to connect to the Internet.
The location described in the GPS position (longitude, latitude, altitude) is the core
object. Three tables indexed by the location are constructed. All WRM operations
start from retrieving a current location and then access three tables to receive what
access networks can be the best to be associated in network selection and handover.
MAG
Lab presents
4
Page 13 of 67
2
1
2
2.1.2 Architecture Reference Model
3
4
Figure 2.1.2-1 shows the WRM architecture reference model. There are two physical
5
objects, Location and Radio Resources. According to a users network accessibility,
6
each users unique WRM database may be constructed with three conceptual objects.
7
8<Figure 2.1.2-3> WRM Architecture Reference Model
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
3
The access point, indicated as (a) in Figure 2.1.2-1, can be registered as N_R1 and
N_R2 to user 1 and user 2 respectively. Also, the location, indicated as (b) in Figure
2.1.2-1, can be registered as N_L1 and N_L3 to user 1 and user 2 respectively.
With the same access point, all users can have different pairs of <N_L, N_R> since
they can assign different index values to the access point. For all public hotspots or
any WiFi networks having the same SSID, usually they will have also the Zone index
or ID, N_Z, to all N_Rs that belong to the same SSID.
2.2
Parameters
Page 14 of 67
MAG Lab presents
2
3
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
The WRM application shall collect the following parameters.
2.3
N : index
o N_L: Location index
o N_Z: Zone index (TBD)
o N_R: Radio resource index
o N_N: Network index
N_U : user type (TBD)
N_A : application type (TBD)
N_E : event type (TBD)
S : statistical maturity (TBD)
W: weight (TBD)
U: statistical time of usage (TBD)
t: measured time of usage (TBD)
I: index for indoor/outdoor/moving (TBD)
Q: statistical quality (TBD)
q: temporal quality (TBD)
P: position (TBD)
G: CRRM parameters (TBD)
WRM database
The WRM application shall maintain three tables, the location table, the radio
resource table, and the selection table.
2.3.1 Location Table

The WRM application shall retrieve the GPS location wherever it goes to. The
following table shows the definition of the location table.
Longitude Latitude
I_L U_L
S_L
29
30
31
32
33
34
35
36
37
Altitude
S_P
N_L
C_T U_T
Longitude, Latitude, Altitude : GPS location information

N_L : Location Index
C_T : creation time of this record
U_T : last update time
I_L : index for location type (TBD)
U_L : time stayed at a current location (TBD)
S_L : statistical maturity index of current location information (TBD)
S_P : statistical maturity index of current location (TBD)
MAG
Lab presents
4
Page 15 of 67
2
1
2
3
4
5
6
2.3.2 Selection Table

The WRM application shall use the selection table to find a next access network when
the handover is required. The access network indicated by Next1 is the most desired
access network the mobile device can hand over to while Next3 is the least one.
N_L
C_T
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
N_N
U_T
N_R
N_Z
W_R Next1 Next2 Next3 Accuracy
N_L : Location index

N_N : Network index
N_R : Radio resource index
N_Z : Zone index
W_R : Weight index
Next1 : 1st handover target access network
Next2 : 2nd handover target access network
Next3 : 3rd handover target access network
Accuracy : TBD
C_T : record creation time
2.3.3 Radio Resource Table

This table contains the access network information.
N_R BSSID SSID N_N Longitude Latitude Altitude C_T U_T W_R
N_Z I_R U_R S_R S_P
Perf
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
2.4
N_R : Location Index

BSSID : the MAC address of WiFi or the cell ID of 3G
SSID : WiFi SSID or no mean to 3G
N_N : network type
Longitude, Latitude, Altitude : the location of the access point
C_T : record creation time
W_R, N_Z, I_R, U_R, S_R, S_P, Perf : TBD
WRM database lifecycle
The WRM database can be manipulated inserted, deleted, and updated- by the
PRRM. The WRM application can only provide the collection of location and radio
resource information plus what network related events are really occurred in the
mobile device, which means that the WRM application shall not directly modify the
WRM database.
Page 16 of 67
MAG Lab presents
2
3
1
2
3
4
5
6
7
8
9
10
11
12
13
14
2.4.1 Initial stage

With a given location, the WRM database may have location table and/or radio
resource tables with empty or less information. The WRM application should be
dedicated to collect information if the WRM database is immature.
The WRM application shall run the WRM Explorer handler, and the handler shall
execute periodically the Sniff function unit to gather what kinds of access networks
are accessible. Also, the WRM Explorer shall monitor what access networks are
really associated to the mobile device. Every event shall be saved in one event record
as the following table.
<Table 2.4.1-1> Format of User Log Table
Time
Event Type
0x01: Operation
0x02: Network
Status Event
15
16
17
Event Details
0x01 : WRM started
0x02 : WRM terminated
0x03 : New day started
0x04 : New day ended
0x05 : DB List incorrect
0x06 : DB List out of date
0x07 : log update initiated
0x08~0x0f: reserved
0x11 : network unavailable
0x12 : network login
0x13 : network logout
0x14 : IP address changed
0x15~0x1f: reserved
0x03: Location
Event
0x21 : Location changed

0x22 : New location detected
0x23~0x2f: reserved
0x04: Handover
Event
0x31 : VHO to WLAN

0x32 : VHO to 3G
0x33 : HHO to WLAN
0x34 : HHO to 3G
0x35~0x3f: reserved
Event Log
1. A current location
2. DB List for a
current location
3. scanning result if
it exists
4. active access
network
information
2. active access
network
information
3. Performance of
last active access
network
1. An old/new
location
2. active access
network
information
1. Handoff result
3. old/new access
network
information
4. Performance of
old network
Every record shall include other information as the following.

A current location: the current location where the event is captured.
MAG
Lab presents
4
Page 17 of 67
2
1
DB List: the WRM database that the WRM application uses.
2
i. The location table
3
ii. The radio resource table
4
iii. The selection table
5
Network List: the list of access point that are detected at the current location
6
i. Type, SSID or Cell ID, BSSID, Beacon or Paging Information (TBD)
7
Active network information: the network information of a current active access
8
network.
9
i. AP information : Type, SSID or Cell ID, BSSID, security info (TBD)
10
ii. IP address and etc.
11
Performance of associated access network : TBD
12
13
According to the time order, all events shall be saved in the user log table. The table
14
shall be uploaded to the PRRM. From the table, the PRRM shall update the location
15
table, the radio resource table and the selection table.
16
17<Figure 2.4.1-4> Example of WRM DB list
18
19
20
21
22
With the example of Figure 2.4.1-1, following tables shows how three tables can be
constructed through the initial stage.
Page 18 of 67
MAG Lab presents
2
3
1
2
3
<Table 2.4.1-2> Example of Location Table

Longitude
X
4
5
6
7
Latitude
Y
SSID
B
A
A
N_N
1
2
2
2
Longitude Latitude Altitude C_T

X1
Y1
Z1
X2
Y2
Z2
X3
Y3
Z3
X4
Y4
Z4
U_T
-
N_N N_R N_Z W_R Next1 Next2 Next3 Accuracy C_T

1
1
3
2
2
1
2
3
2
2
4
2
-
U_T
-
The selection table can be continuously updated depending on which access networks
the mobile device has associated to. For example, the mobile device has associated to
N_R4 and N_R3 most of times, and the mobile device has the best experience on
N_R4 than any other access points. Then, the selection table shall be updated like :
<Table 2.4.1-5> [Before update] Example of Radio Resource Table
N_L
1
1
1
1
21
22
23
24
25
26
27
28
C_T U_T
-
<Table 2.4.1-4> [Before update] Example of Selection Table

N_L
1
1
1
1
12
13
14
15
16
17
18
19
20
N_L
1
<Table 2.4.1-3> Example of Radio Resource Table

N_R BSSID
1
Cell A
2
3
B
4
A
8
9
10
11
Altitude
Z
N_N
1
2
2
2
N_R
1
2
3
4
N_Z
3
1
2
2
W_R Next1 Next2

1
4
3
1
4
3
8
4
2
10
3
2
Next3
2
1
1
1
Accuracy
-
Among all radio resources, N_R4 (=4) shall be the most desired access point to the
mobile device at the location, N_L1(=1) . At the next time, the mobile device shall try
to connect to the N_R4 at first.
Figure 2.4.1-2 shows the call flow how the user log table is uploaded.
MAG
Lab presents
4
Page 19 of 67
2
1<Figure 2.4.1-5> Example of WRM Call Flow to Upload the User Log Table
2
3
4
5
6
7
8
9
10
11
Instead of instantly reporting any event, the WRM application shall be requested to
upload the user log table at a scheduled time such as Case 1) or Case 2) as shown in
Figure 2.4.1-2. With the previous example, the user log table shall have the following
records.
<Table 2.4.1-6> Example of User Log Table
Time
2
3
4
5
5
6
12
13
14
15
16
17
Event Type
0x02
0x02
0x02
0x03
0x02
0x01
Event Log
Performance of N_R4
Performance of N_R3
Based on Table 2.4.1-6, the PRRM server can update the selection table like the
following table.
<Table 2.4.1-7> [After update] Example of the Selection Table
N_L
N_L1
N_N
N_N2
N_N2
Event Details
0x12: network login to N_R4
0x13: network logout
0x12: network login to N_R3
0x33: HHO to WLAN (N_R2)
0x14: IP address changed
0x07: log update initiated
N_R
N_R4
N_R3
N_Z
N_Z2
N_Z2
W_R
10
2
Next1
N_L1,
N_N2,
N_R3
N_N2,
Page 20 of 67
Next2
N_N1,
N_R4
Next3
N_L1,
N_N1,
Accuracy
-
MAG Lab presents
2
3
N_R2
N_N2,
N_R3
N_R4
1
2.4.2 Active stage
2
3
With a given location, the WRM database shall have matured location, radio resource
4
and selection tables. The WRM application shall execute the WRM Handler and the
5
Handoff handler.
6
7
Figure 2.4.2-1 shows how the WRM application can help the mobile hand over
8
throughout moving multiple locations when the WRM application has matured WRM
9
database tables for all locations.
10
11
12<Figure 2.4.2-6> Example of WRM-led Handover
13
14
15
16
17
18
19
20
At the location 1, the WRM application is started. In this step, the WRM application
shall have the following selection table and the radio resource table.
<Table 2.4.2-1> [Before update] Example of Selection Table in Active Stage
MAG
Lab presents
4
Page 21 of 67
2
N_L
N_L1
N_L2
N_N
N_N2
N_R4
N_Z2
N_N2
N_R1
N_Z1
N_R2
N_Z1
10
N_Z2
N_N2,
N_R1
Next2
N_N1
Next3
Accuracy
-
N_N2,
N_R2
N_N1
N_L3,
N_N2,
N_R3
N_N2,
N_R2
N_N1
N_L3,
N_N2,
N_R3
type
WiFi
WiFi
3G
SSID Or Cell ID
A
A
A
BSSID
A
B
-
Location
-
As the mobile device approaches to the location 2, the WRM application might
experience that the signal strength of N_R1 is getting weakened while the signal
strength of N_R2 is getting stronger. According to the selection table, because the
preferred next access network is N_R2 and two N_Rs have the same zone ID (N_Z1),
the WRM application is not involved in the handover because a typical handover can
provide a seamless handover. After the location is changed to N_L2, the selection
table shall be updated like Table 2.4.2-3.
<Table 2.4.2-3> [After update 1] Example of Selection Table in Active Stage
N_L
N_L1
N_L2
N_N
N_N2
N_R
N_R1
N_Z
N_Z1
W_R
10
N_N1
N_R4
N_Z2
N_N2
N_R1
N_Z1
N_R2
N_Z1 10
N_N2
N_R4
Next1
N_L2,
N_N2,
N_R2
N_N2,
N_R1
N_N2,
N_R2
N_N2,
N_R1
<Table 2.4.2-2> Example of Radio Resource Table in Active Stage

N_R
N_R1
N_R2
N_R4
5
6
7
8
9
10
11
12
13
14
N_Z
W_R
N_Z1 10
N_N1
N_N1
1
2
3
N_R
N_R1
N_R4
N_Z2
Next1
N_L2,
N_N2,
N_R2
N_N2,
N_R1
N_N2,
N_R2
N_N2,
N_R1
N_N2,
N_R1
Page 22 of 67
Next2
N_N1
Next3
Accuracy
-
N_N2,
N_R2
N_N1
N_L3,
N_N2,
N_R3
N_N2,
N_R2
N_N1
N_L3,
N_N2,
N_R3
MAG Lab presents
2
3
N_L3
N_N2
N_N1
1
2
3
4
5
6
7
8
9
10
11
12
N_R2
N_Z1
N_R3
N_Z3 10
N_R4
N_Z2
N_N2,
N_R3
N_L4
N_N2,
N_R3
N_N2,
N_R2
N_N1
N_N2,
N_R2
N_N1
N_N2,
N_R3
As the mobile device approaches to the location 3, like the previous case, the WRM
application might experience that the signal strength of N_R2 is getting weakened
while the signal strength of N_R3 is getting stronger. According to the selection table,
the zone of N_R3 is different to the zone of N_R2, a horizontal hand over causing the
IP address change should be occurred. The WRM application shall lead logging into
N_R3 when the signal strength of N_R2 shall reach to a pre-defined threshold for the
HHO of WLAN for the WRM application. When the WRM application arrives at the
location 3, the selection table shall be updated like:
<Table 2.4.2-4> [After update 1] Example of Selection Table in Active Stage
N_L
N_L1
N_L2
N_N
N_N2
N_L4
N_Z
N_Z1
W_R
10
N_N1
N_R4
N_Z2
N_N2
N_R1
N_Z1
N_R2
N_Z1 10
N_N1
N_L3
N_R
N_R1
N_N2
N_R4
N_Z2
N_R2
N_Z1
N_R3
N_Z3 10
N_N1
N_R4
N_Z2
N_N2
N_R3
N_Z3
10
N_N1
N_R4
N_Z2
Next1
N_L2,
N_N2,
N_R2
N_N2,
N_R1
N_N2,
N_R2
N_N2,
N_R1
N_N2,
N_R1
N_N2,
N_R3
N_L4
N_N2,
N_R3
N_N2,
N_R2
N_L4
N_N2,
N_R3
13
MAG
Lab presents
4
Page 23 of 67
Next2
N_N1
Next3
Accuracy
-
N_N2,
N_R2
N_N1
N_L3,
N_N2,
N_R3
N_N2,
N_R2
N_N1
N_L3,
N_N2,
N_R3
N_N1
N_N2,
N_R2
N_N2,
N_R3
N_L5,
N_N1,
N_R4
N_N1
N_N2,
N_R2
2
1
2
3
The selection table shall be updated whenever the mobile device moves to an alreadyknown location.
43
Session Control Protocol
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
3.1
Introduction
The session control protocol shall be used to manage a WRM session between the
WRM application and the PRRM.

The WRM session shall be created when the PRRM is created, and the WRM
application connects to the PRRM for the first time. The WRM session shall be
demolished when the PRRM is also deleted. Otherwise, the WRM session shall be
maintained in connectionless mode. In general, there are four cases that the WRM
session is (re)started.
1.
2.
3.
4.
The WRM application is started for the first time.

The new day is started
The new location is detected
A current WRM database is incorrect or out of date.
21
3.1.2 Call Flow
22
23
Figure 3.1.2-1 shows the call flow for the session control protocol. Two signaling
24
messages, a Registration Request message and a Registration Reply message, are
25
defined for the session control protocol.
26
27<Figure 3.1.2-7> Call Flow of Session Control Protocol
28
Page 24 of 67
MAG Lab presents
2
3
1
2
3
4
5
6
7
8
Depending on the reason of the session initiation, the Registration Request message
and the Registration Reply message shall contain a little different information as
shown in Table 3.1.2-1.
<Table 3.1.2-1> Example of Registration Request message
Purpose
Current
Location
wrm DB
update ind
The number
of NL_list
NL_list
sensing
result incl
AP list
event log
incl
MAG
Lab presents
4
Case 1)
0x01
Included
Case 2)
0x02
Case 3)
0x03
Case 4)
0x04
0 or 1
0 or 1
If wrm DB update ind is 1, 0~255 (0 indicates all N_L

information of PRRM ). Otherwise, it is omitted
If The number of NL_list is greater than 0,
NL_list [The number of NL_list] {
N_Lid,
# if N_Lid is 0, it means no N_L ID is
Location
# assigned to Location.
}
1
0 or 1
1
1
included
If sensing
result incl is 1,
Included.
Otherwise 0.
0 or 1
Page 25 of 67
included
included
2
Event log
1
2
3
4
<Table 3.1.2-2> Example of Registration Reply message
return code
Preferred
WRM Conf.
wrm DB
update incl
DB list
Sensing
request
ind
sensing report
immediate flag
5
6
7
8
9
10
If event log incl is 1, Included. Otherwise 0.
Case 1)
Case 2)
0: No Error
0x01~0x65535 : Errors
included
Case 3)
Case 4)
0, 1 or 2
1 or 2
1 or 2
0, 1 or 2
If wrm DB update incl is 1 or 2, included. Otherwise 0.

DB list {
The number of records in location table, LN;
Location Table[LN] {
Longitude, Latitude, Altitude
N_L,C_T ,U_T
I_L, U_L, S_L, S_P
}
The number of records in radio resource table, RN;
Radio Resource Table[RN] {
Longitude, Latitude, Altitude
N_L,C_T ,U_T
I_L, U_L, S_L, S_P
}
The number of records in selection table, SN;
Selection Table[SN] {
N_R, BSSID, SSID,
N_N, Longitude, Latitude, Altitude,
C_T, U_T, W_R, N_Z, I_R, U_R, S_R, S_P, Perf
}
}
0 or 1
If sensing request ind is 1, 0 or 1. Otherwise omitted.
In a case of the WRM application terminated, the Radio Report Reply message shall
be omitted.
Figure 3.1.2-2 shows that the PRRM can asynchronously send the Registration Reply
message to the WRM application when the WRM database for any location is
Page 26 of 67
MAG Lab presents
2
3
1
updated. The PRRM may initiate this asynchronous WRM database update when the
2
PRRM expects that the WRM application may be running in the mode 0.
3
4<Figure 3.1.2-8> Call Flow for the PRRM-initiated Session Control.
5
6
7
8
9
10
11
12
13
Table 3.1.2-3 shows the example of Registration Reply message that is initiated by
the PRRM.
<Table 3.1.2-3> Example of Registration Reply message for Asynchronous Retrieval
return code
Preferred WRM
Conf.
wrm DB update incl
DB list
sensing
request
ind
sensing report immediate flag
Case 5)
0xff
included
1 or 2
0 or 1
If sensing request ind is 1, 0 or 1. Otherwise
omitted.
14
15
3.2
WRM application sequence flow
16
3.2.1 Sequence flow for Case 1) and Case 2)
17
18
Figure 3.2.1-1 shows the sequence flow of WRM Handlers when the new day is
19
started.
20
21<Figure 3.2.1-9> Sequence Flow of WRM Application for Case 1) and Case 2).
MAG
Lab presents
4
Page 27 of 67
2
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
The WRM application shall be configured to initiate the session update at a certain
time. First of all, the initial handler shall provide an alert notification to start the
communication handler, and then retrieve a current location when the communication
handler is successfully started. Now, the initial Handler shall send the Registration
Request message with purpose = 0x02, and the handler shall wait the Registration
Reply message. If a new WRM database is included in the Registration Reply
message, the initial shall update the WRM database with the retrieved one from the
message.
If the communication handler can not connect to the Internet, the Initial Handler
reports this to the Event Logger. However, the initial handler shall keep receiving the
notification that any access network is successfully activated. If the retrieved location
information indicates that the mobile device is at the new location, the session
initiation shall be transferred to the case of the new location detection.
18
3.2.2 Sequence flow for Case 3) and Case 4)
19
20
Figure 3.2.2-1 shows the sequence flow of WRM Handlers when the new location is
21
detected or when the WRM database is out of date or incorrect.
22
23<Figure 3.2.2-10> Sequence Flow of WRM Application for Case 3) and Case 4).
24
Page 28 of 67
MAG Lab presents
2
3
1
2
3
4
5
6
Since the WRM database is not appropriate to a current location, the WRM
application shall transit its operation mode into the monitoring mode, mode 0, to
collect state-of-art network environments of the current location. In this case, the
Sniff function unit is also enabled to gather all available access networks.
74
Radio Monitoring Protocol
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
4.1
Introduction
The radio monitoring protocol shall be used to report the user log table collected by
the WRM application to the PRRM.

The user log table shall be uploaded when the WRM application is terminated or the
upload is required. Since the WRM session operates in connectionless mode,
uploading the log table shall not change directly the status of the WRM session
except the case that the WRM application is terminated.
In general, there are three cases that the Radio Monitoring Protocol is applied.
1. The WRM application is terminated.
2. One day is ended
3. Update of the user log table initiated
MAG
Lab presents
4
Page 29 of 67
2
1
4.1.2 Call Flow
2
3
Figure 4.1.2-1 shows the call flow for the radio monitoring protocol.
4
5<Figure 4.1.2-11> Call Flow For Radio Monitoring Protocol
6
7
8
9
10
11
12
Depending on the reason, the Radio Report message and the Radio Report Reply
message shall contain a little different information as shown in Table 4.1.2-1.
<Table 4.1.2-1> Example of Radio Report message
Purpose
Location
wrm DB update
ind
sensing
result incl
AP list
event log incl
Event log
reply required
flag
13
14
15
16
Case 1)
0x11
Included
0
Case 2)
0x12
Case 3)
0x13
included
1
Included.
0
included
1
Included.
0
included
1
Included.
0 or 1
<Table 4.1.2-2> Example of Radio Report Reply message
Page 30 of 67
MAG Lab presents
2
3
return code
Preferred WRM
Conf.
wrm DB update
incl
DB list
Case 1)
Case 2)
0: No Error
0x01~0x65535 : Errors
included
Case 3)
0 or 1
If wrm DB update incl is 1 or 2, included.

Otherwise 0.
1
2
4.2
WRM application sequence flow
3
4.2.1 Sequence flow for Case 1), Case 2) and Case 3)
4
5
Figure 4.2.1-1 shows the sequence flow of WRM Handlers when the one day is
6
ended. Like the case of the new day started, at a certain time, the WRM application
7
shall upload the user log table, which is collected during one day, to the PRRM.
8
9<Figure 4.2.11-12> Sequence Flow of WRM Application for Case 1) , Case 2) and Case
103)
11
12
13
14
15
165
WRM Service Lifecycle
17
18
19
20
21
5.1
Introduction
The WRM application shall operate one among three modes, 0, 1 and 2. When the
WRM application starts at an unknown location or known location but the WRM
MAG
Lab presents
4
Page 31 of 67
2
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
database being out of date or incorrect, the WRM application starts in mode 0.
Otherwise, in general, the application starts in mode 1.

In the mode 0, the WRM application shall simply monitor the network operations of
the mobile device. All monitoring results, retrieved from the Sniff function unit, shall
be saved in the user log table. The WRM-led handover shall be disabled. The WRM
application can upload the user log table when detected access points are not changed.
Based on the uploaded log, the PRRM can make a temporal WRM database for a
current location. The transition to the mode 1 shall be occurred when a matured
WRM database is retrieved from the PRRM.
In the mode 1, the WRM application shall not only run the network performance
monitoring but also lead the network selection through the WRM-led handover. Both
the network selection and a handover procedure, first, the WRM application finds a
N_L ID of a current location. With found N_L ID, the WRM application shall search
the record of the selection table having the largest W_R value. With a found record,
the WRM application shall try to connect to the access point, indicated by N_R. This
operation should be repeated for all records indicated by the given N_L ID in a
descending order of a W_R value. If the WRM application can not associate to all
candidate N_Rs, the WRM application shall claim the WRM database to be out of
date, and then send the Registration Request message to report the need of the WRN
database updated while the WRM application transits its operating mode to the mode
0. Otherwise, the WRM application shall report the success of the association to the
access point based on the WRM database in the user log table.
The mode 2 is designed to help the WRM application gather all detected access points
as a result of sensing wireless channels. In both mode 0 and mode 1, the WRM
application can transit its running mode for a while to the mode 2 to collect available
access networks. The mode 2 may be embedded into the WRM Handler and/or the
WRM Explorer as a supplemental function or unit.
The WRM application shall monitor a battery status whatever mode it is under. When
a battery remaining is below a certain threshold, for example less than 20%, the
WRM application shall hold all operations and then transit the operating mode to the
mode 0 with only enabling the notification retrieval when a battery is recharged over
a certain threshold like 70%. The battery threshold values are not specified in this
standard.
39
5.1.2 Service Lifecycle
40
41
Figure 5.1.2-1 shows the overview of the WRM lifecycle.
42
43<Figure 5.1.22-13> WRM Service Lifecycle
44
Page 32 of 67
MAG Lab presents
2
3
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
When the WRM application is (re)started, the WRM application should execute the
initial handler. After a successful retrieval of a current location, the WRM application
shall decide which mode is an operating mode based on whether the WRM
application has a proper WRM database for the current location.
Except the case that the WRM application is uninstalled, the WRM application shall
be running under one of three modes with an initial stage managed by the initial
handler.
5.2
Mode 0
Running under the mode 0 can be happened when the WRM application meets one of
following cases.
[Mode0-Case 1] The WRM application is (re)started or tries to send the

notification of the new day started where a current location is never visited
before.
o In this case, starting at the mode 0 can be ended if the PRRM can provide
the latest WRM database for the current location.
o The Registration Request message with purpose = 0x01 or 0x02 shall be
transmitted to the PRRM.
[Mode0-Case 2] The WRM application recognizes that the last update time of
the WRM database for a current location is too old. The decision of whether
the WRM database is out of date is totally up to the WRM application
implementation.
MAG
Lab presents
4
Page 33 of 67
2
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
o In this case, starting from the mode 0 can be ended if the PRRM can
provide the latest WRM database for the current location.
o The Registration Request message with purpose = 0x04 shall be
[Mode0-Case 3] The WRM application detects that the mobile device moves
to a new location that even the PRRM can not have or build a WRM database.
[Mode0-Case 4] The WRM application has experienced that the WRM-led
handover failed in connecting to a neighbor access point that is defined in the
selection table.
o This specification does not explicitly describe how the WRM application
decides whether the WRM-led handover is failed, and the WRM database
is needed to be updated.
For all cases, the WRM application, the WRM application shall send the Registration
Request message with purpose = 0x01 ~ 0x04. For the [Mode0-Case 3] and [Mode0Case 4], the WRM Explorer shall handle the Registration Request message and the
Registration Reply message. For the [Mode0-Case 2], the WRM Explorer shall
handle the messages when [Mode0-Case 2] is detected while the WRM application
has been running. Otherwise, when [Mode0-Case 2] is detected just after the WRM
application is (re)started, the WRM initial handler shall handle them. For the [Mode0Case 4], the WRM Handler shall process the messages, and then the WRM Handler
shall initiate the mode transition to the mode 0.
In the mode 0, the WRM application can transit an operating mode to the mode 2 to
sense any available access networks at the current location. If both sensing request
ind and sensing report immediate flag of a Registration Reply message are 1, the
WRM application shall send the Radio Report message containing the list of sensed
access networks after gathering multiple sensing results plus any active access
networks that the mobile device currently connects to. This specification does not
impose how many access points are gathered. The number is up to the WRM
application implementation.
If sensing report immediate flag of the Registration Reply message is 0, the WRM
Explorer shall be supposed to gather the network performance of current active access
networks in the user log table. If sensing request ind of the Registration Reply
message is 1, the WRM shall save sensing results in the user log table. To make an
effective memory usage, the WRM application can optimize the sensing results rather
than record all of them.
If the WRM application is enforced to be terminated, the WRM Explorer shall send a
Radio Report message with purpose = 0x11 and reply required flag = 0. The WRM
application shall send the Radio Report message with purpose = 0x12 and reply
Page 34 of 67
MAG Lab presents
2
3
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
required flag = 0 if the application receives the notification that the one day is ended.
The WRM application shall send the Radio Report message with purpose = 0x13 and
reply required flag = 1 if the application receives the notification that the one day is
ended.
In the mode 0, the WRM application may receive the Registration Reply message
with return code = 0xff from the PRRM. If the DB list.Location Table of the
Registration Reply message includes the N_L ID of the current location, the WRM
application shall update the WRM database with the DB list of the message, and then
transit its operating mode to the mode 2. Otherwise, the WRM application shall
update the WRM database, but the application remains in the mode 0.
5.3
Mode 1
Running under the mode 1 can be happened when the WRM application meets one of
following cases.
[Mode1-Case 1] The WRM application is (re)started or tries to send the

notification of the new day started at a known location with a proper WRM
database.
o The Registration Request message with purpose = 0x01 or 0x02 shall be
[Mode1-Case 2] The WRM application has experienced that the WRM-led
handover succeeded in associating to a neighbor access point that is defined in
the selection table.
o In this case, the WRM application is kept in a current mode, mode 2.
In general, the WRM Handler shall be dedicated on the performance collection from
network to battery status while the Handover Handler dedicated on the WRM-led
handover. This standard does not explicitly impose a specific algorithm of the WRMled handover, and how the WRM Handler and the Handover Handler work in detail.
For example, like a typical handover operation, monitoring a possibility of handover
and executing a handover can be performed by one handler or separated handler.
However, the WRM Handler and the handoff handler should provide all actions of the
WRM-led handover.
If the WRM application is enforced to be terminated, the WRM Explorer shall send a
Radio Report message with purpose = 0x11 and reply required flag = 0. The WRM
application shall send the Radio Report message with purpose = 0x12 and reply
The WRM application shall send the Radio Report message with = 0x13 and reply
In the mode 1, the WRM application may receive the Registration Reply message
with return code = 0xff from the PRRM in an asynchronous mode. The WRM
application shall update the WRM database with the DB list of the received
MAG
Lab presents
4
Page 35 of 67
2
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
Registration Reply message. The WRM Handler shall inform the Handoff Handler of
the WRM database update.
5.4
WRM-led Handover
The WRM-led Handover consists of two major parts: handover monitoring and
handover execution. This standard does not restrict how the WRM application can
decide whether a current time is the best time to take a handover. When the need of a
handover is recognized, the selection table can provide which one among multiple
handover target access points is the most or reasonable new access network.
Anyway, a simple WRM-led handover decision algorithm, which uses the signal
strength of the current active access network, is suggested.
5.4.1 Handover monitoring

The handover monitoring may use other metrics as packet loss rate, packet
throughput and delays. For example, if there are more than two access points, which
their W_R values are not quite different; the handover decision algorithm could
choose one that the mobile device experienced less packet loss or more packet
throughput with less delays over the past.
The following handover decision algorithm simply uses two metrics, signal strength
for handover monitoring and the Zone IDs for handover execution.
First of all, in handover monitoring, there are two kinds of the signal strength
thresholds and one monitoring duration time.
threshold_readySigStrength[N_N]
threshold_monitoringDurTime[N_N]
threshold_goSigStrength[N_N]
Due to the characteristics of wireless channels, the handover monitoring shall not
declare the handover until signal strength of a current active access network is kept
below a threshold for a certain time. Therefore, the WRM application should only
consider the handover when the WRM application stays over a reasonable time at the
handover required area.
Here is a simple handover decision algorithm, which is handled by the Handover
Handler. As long as the location is not changed or the new location is not registered in
the location table, but its distance from a previous distance is not far away, the
Handover Handler shall maintain the following handover decision algorithm.
Algorithm HandoverDecision
readyCount = 0;
cntStart = 0;
Page 36 of 67
MAG Lab presents
2
3
cntEnd = 0;
oldN_L = current N_L ID;
curN_L = current N_L ID;
While (1)
Begin
If a current active access network is WiFi
Begin
N_N = WiFi
End
If a current active access network is 3G
Begin
N_N = 3G
End
Begin
If a measured signal strength < threshold_readySigStrength[N_N]
Begin
If readyCount == 0
Begin
cntStart = currentTime;
End
readyCount++;
If a measured signal strength < threshold_goSigStrength[N_N] or
readyCount > threshold_monitoringTime[N_N]
Begin
cntEnd = currentTime;
ready = DecisionEngine(cntStart,cntEnd);
If ready == YES
Begin
Call HandoverExecution
End
readyCount = cntStart = cntEnd = 0;
End
Else
If readyCount != 0
Begin
readyCount--;
End
End
End
MAG
Lab presents
4
Page 37 of 67
2
End
1
2
3
4
5
6
The DecisionEngine algorithm shall simply enforce the WRM-led handover when a
candidate access point has a different Zone ID (N_Z), which means that a horizontal
handover causing the IP address changed is required, or a candidate access point has a
different Network ID (N_N), which means that a vertical handover is required.
Algorithm DecisionEngine (cntStart, cntEnd)
// TBD other metrics shall be considered at a later time
curN_R = N_R of a current active access network
curN_L = a current N_L ID
For all Next1/Next2/Next3 of <curN_L, curN_R> in the selection table
Begin
bestN_R from Next1/Next2/Next3
bN_Zid from N_Z of bestN_R;
cN_Zid from N_Z of curN_R;
If bN_Zid == cN_Zid
Begin
return NO;
Else
return YES;
End
End
7
8
9
10
The handover decision algorithm caused by the location change shall be managed by
the WRM Handler.
Algorithm locationBasedHandoverDecision
oldN_L = current N_L ID;
While (1)
Begin
If location change is detected
Begin
oldN_L = curN_L;
If curN_L is in the location table
Begin
bestN_R from the selection table as the best N_R for curN_L;
Page 38 of 67
MAG Lab presents
2
3
If bestN_R == current N_R
Begin
Continue;
Else
bN_Zid from N_Z of bestN_R;
cN_Zid from N_Z of currentN_R;
If bN_Zid == cN_Zid
Begin
Continue;
Else
Call HandoverExecution;
End
End
End
End
End
1
2
3
4
5
6
5.4.2 Handover execution

The WRM Handler shall be informed from the Handover Handler that a current time
is the best time to execute the WRM-led handover.
Algorithm HandoverExecution
//TBD,
If the next N_R is WiFi
Begin
Run Association and Log in to the next N_R
End
If the next N_R is 3G
Begin
Run Association and Log in to the next N_R
Release WiFi connection & WiFi Interface
End
7
86
Messages and Database
MAG
Lab presents
4
Page 39 of 67
2
1
2
3
6.1
Messages
The WRM message consists of the header part and the message body part.
Common Header
4
5
6
7
8
Message body
6.1.1 Common Header

All messages contain the common header.
<Table 6.1.1-1> Common Header
Field
Version [1 byte]
Message ID [1 byte]
Message length
[2 bytes]
Sequence number
[2 bytes]
Sequence Ack number.
[2 bytes]
Sender Information
{
Sender Id [1 byte]
IP address [4 bytes]
Port [2 bytes]
}
description
Version information.
The message identification
0 = Registration Request
1 = Registration Reply
2 = Radio Report
3 = Radio Report Reply
4 ~ : reserved
The length of the message body.
Range : 0 ~ 65535
The sequence number is used to get rid of
duplicated messages.
Range : 0 ~ 65535
The latest sequence number received from
a receiver.
Range : 0 ~ 65535
default
1
The Sender Identification

0 = the WRMs Map (sniffer)
1 = the CRRM server
The Senders IP address information like
the IP address of IP header. 4 bytes
represents 4 octets of IP address
(Octect.Octet.Octet.Octet.)
The Senders Port information
Range : 0 ~ 65535
9
10
11
12
13
6.1.2 Registration Request

<Table 6.1.2-1> Registration Request message
Field
description
Page 40 of 67
default
MAG Lab presents
2
3
Purpose [1 byte]
user ID [20 bytes]

Mobile Device Type
[4 bits]
Network Interface
capability [10 bit
mask]
WRM DB update ind

[1bit]
Location Info flag

[1 bit]
Location Information
MAG
Lab presents
4
0x01 : WRM started

0x05 : WRM DB incorrect
0x06 : WRM DB out of date
0x08~0x0f: reserved
0x15~0x1f: reserved
0x23~0x2f: reserved
0x31 : VHO to WLAN
0x32 : VHO to 3G
0x33 : HHO to WLAN
0x34 : HHO to 3G
0x35~0x3f: reserved
The size is limited to 20 characters in the
User ID.
The mobile device information
0: Mobile phone
1: PDA or smart phone
2: Laptop
3 ~ 15: reserved
The capability of supported wireless
interfaces
Bit 0 : Wi-Fi (single)
Bit 1 : Wi-Fi (multi)
Bit 2 : Cellular ( 2G or 2.5G)
Bit 3 : Cellular ( 3G or more)
Bit 4 ~ Bit 9: reserved.
The WRM application needs the latest
WRM DB of a current location
0 : not needed
1 : needed
The Location Information has valid or
void data.
0: valid
1: void
This field is included if the Location
Page 41 of 67
Binary
00001001
(3G with one
Wi-Fi)
2
Info flag is set 1.
Location {
Accuracy [1 byte]
longitude [8 bytes]
latitude [8 bytes]
speed [4 bytes]
UTC time [4 bytes]
altitude [8 bytes]
}
NL List size, nl [2
bytes]
NL_List[1..nl]
{
NL_ID [4 bytes]
Location
}
sensing
result incl [1 bit]
Network List size, m
[1 bytes]
Accuracy represents the accuracy level

in meters. For example, if it got 10, it
means the mobile phone is located
within 10 meters from the GPS location
information. If the accuracy got 0, it
means the accuracy level is not known.
The size of the N_L List
The N_L ID that the WRM application

wants to retrieve the WRM database.
If the WRM application only does not
know the N_L ID, NL_ID has 0.
The location of NL_ID
0: no sensing performed
1: sensing performed
The size of the Network List.
Range : 0 ~ 255
If the Scanning status is 0, m should be
0 also.
Network List [1..m]

{
Network ID [32
bytes]
If the network scanned is known, the

Network ID is included. Otherwise, the
WRM should at least the country code,
which can be extracted from a Country
Information Element from a received
beacon frame.
Network Device
The type of a network device that found 0
Type [5 bits]
this access network.
** Following all fields are only valid if the network Device Type is 0. Other
Page 42 of 67
MAG Lab presents
2
3
cases are out of this paper.
AN ID [32]
SSID of AP
AN Address [6]
BSSID (MAC address) of AP
Frequency [1 bit]
0 : 2.4 GHz, 1 : 5GHz
Channel [20bits]
0th bit reserved
T th bit represents channel T when T
is from 1 to 11.
12th ~ 19th bits reserved
Signal Strength
Unit: dbm.
[8 bits]
Max AP Tx Power This value can be extracted from the
[1 byte]
Country Information Element included
in the Beacon frame.
Unit: dbm
Standard supported Bit 0 : 802.11a supported
[8 bitmask]
Bit 1 : 802.11b supported
Bit 2 : 802.11g supported
Bit 3 : 802.11n supported
Bit 4 ~ Bit 7: reserved.
Access method
If the access is open, the access method
[8 bitmask]
has 0. Otherwise,
Bit 0 : secured (encryption scheme is
unknown )
Bit 1: secured (WEP)
Bit 2: secured (LEAP)
Bit 3: secured (WAP)
Bit 4~Bit 7: reserved.
Key length [8 bits], If Access method is not 0, this field
KL
indicates the size of Key values.
Otherwise, omitted.
If Access method & 0x02 (WEP)
KL should be one of 64,128,152 and
256.
If Access method & 0x08 (WAP)
KL should be 64.
Key values [1..KL]
If Access method is not 0, this field

indicates a hexadecimal string for key
values. Otherwise, omitted.
If Access method & 0x02 (WEP), the
length of the string in Key Values are 10,
MAG
Lab presents
4
Page 43 of 67
Binary
00000101
: 802.11a/g
supported
2
26, 32 or 58 characters for
KL=64,128,152,256 respectively.
If Access method & 0x08 (WAP), the
length of the string in Key Values is 64.
IP address flag
[1 bit]
IP address
[4 bytes]
If the mobile got an assigned IP address

from this access point, the flag is set to
1. Otherwise, it got 0.
The Senders IP address information like
the IP address of IP header. 4 bytes
represents 4 octets of IP address
(Octect.Octet.Octet.Octet.).
This field is only included if the IP
address flag is set 1. Otherwise, this is
not included in this message.
}
Event log flag
If the event log is included and purpose

is ranged from 10 to 19, the event log
flag can be set to 1. Otherwise, it
always is set to 0.
WRM is supposed to set 1 to this flag
for all handoff events.
Event Log {
Event Type [2 bits]
0: Network events
1: WRM events
2: User log table
3~4: reserved.
Event Log length

[2 bytes]
Event Log body
[variable]
If event type is 0
Network events
{
Event type [4 bits]
Event details [8 bits]
Log length [2 bytes]
Log body blob [variables]
}
Log length =
0
Event type
0: network switched
1: network downed
2~15: reserved.
Page 44 of 67
MAG Lab presents
2
3
Event details ( this field is only included
if the Event type is 0)
0: VHO to WLAN
1: VHO to 3G
2: HHO to WLAN
3: HHO to 3G
4~15: reserved
Log body blob (block of bits) is used for
the purpose of debugging.
If event type is 1
WRM events
{
Event type [4 bits]
Event details [8 bits]
Log body Blob [variables]
}
Event type
0 : default
Event details
0x01 : WRM started
0x05 : WRM DB incorrect
0x06 : WRM DB out of date
0x08~0x0f: reserved
0x15~0x1f: reserved
0x23~0x2f: reserved
0x31 : VHO to WLAN
0x32 : VHO to 3G
0x33 : HHO to WLAN
0x34 : HHO to 3G
MAG
Lab presents
4
Page 45 of 67
Log length =
0
0x35~0x3f: reserved
Log body blob (block of bits) is used for

the purpose of debugging.
LogBLOB
{
Current network ID [32 bytes]
Target network ID [32 bytes]
}
If event type is 2
Otherwise, the log length is 0.

User Log Table Uploaded
{
Log body Blob [variables]
}
}
1
2
3
4
6.1.3 Registration Reply

<Table 6.2.1-1> Registration Reply message
Field
Return code [1 bit]
Reason [1byte]
Preferred WRM
configuration [1byte]
wrm DB update incl [2
bits]
description
The processing result of Registration
Request
0: success
1: fail
2~0xfe: reserved
0xff: Asynchronous Reply message
initiated
TBD
TBD
If wrm DB is included, this field has 1
or 2. Otherwise 0.
default
1 : an embedded DB List in theis

message replaces a current DB list
2 : all tables are partially updated
to a current DB list. The below DB
List will contain only any records
in all tables if some fields of the
records are supposed to be updated
Page 46 of 67
MAG Lab presents
2
3
DB List [variables]
with the new values.

If wrm DB update incl is 1 or 2,
The selection table, the location table
and the radio resource table are
included. Otherwise omitted.
DB List
{
Location Table LT;
Radio Resource Table RRT;
Selection Table ST;
}
Scanning request ind
The flag whether the PRRM asks
[1 bit]
WRM of reporting the scanning result.
0: no
1: yes
Scanning report immediate If Scanning request ind has 1, this
ind [1 bit]
field can have 0 (no) or 1 (yes).
Otherwise, omitted.
1
2
3
4
5
6
7
If the reason code is 1, all fields after the reason field are not included in the
registration reply message.
6.1.4 Radio Report

<Table 6.1.4-1> Radio Report message
Field
Timer interval [1 byte]
Report Information
Indicator [8 bitmask]
The number of record, n

[1 byte]
The total size of records.
MAG
Lab presents
4
description
Range: 0 ~ 255.
If this field got 0, this message is
originated to report instantly rather
than a periodic report.
What information included.
Bit 0: a current position
Bit 1: the latest wireless scanning
results
Bit 2: the list monitoring wireless
networks
Bit 3: the network performance of
monitoring wireless networks.
Bit 4~Bit 7: reserved.
Range 1~255
The size of total records.
Page 47 of 67
default
2
[4 bytes]
Record {
Record type [4 bits]
The information type,

0 : location
1 : network list (scanned)
2 : network list (monitoring)
3 : network performance
4~15: reserved
Network Device Type
Access Network Type.
0
[5 bits]
0 : Wi-Fi
1~7: reserved for Wi-Fi
8: Cellular
9 ~ 15: reserved for Cellular
16 : WiMAX
17 ~ 23: reserved for WiMAX
24 : LTE
25~31 : reserved for 4G.
** Following all fields are only valid if the network Device Type is 0. Other
cases are out of this paper.
Record body length
The size of the record body.
[2 bytes]
Body {
If record type is 0,
Location Information {
= Location
Accuracy [1 byte]
longitude [8 bytes]
latitude [8 bytes]
speed [4 bytes]
UTC time [4 bytes]
altitude [8 bytes]
}
If Record type is 1, The number of networks, m [1 byte]
= Network List
Network List [1..m] {
Network ID [32 bytes]
Network Device Type [5 bits]
AN ID [32 bytes]
AN Address [6 bytes]
Signal Strength [1 byte]
Max AP Tx Power [1 byte]
Frequency [1 bit]
Channel [4 bit mask]
Standard supported [8 bitmask]
Access method [8 bitmask]
Key length [8 bits]
Key values [variable]
Page 48 of 67
MAG Lab presents
2
3
IP address flag [1]
IP address [ 5 bytes]
}
If Record type is 2,
= Network List
If Record type is 3,
= Network
performance
The number of networks, m [1 byte]

Network List [1..m] {
AN ID [32 bytes]
Frequency [1 bit]
Channel [4 bit mask]
Standard supported [8 bitmask]
Access method [8 bitmask]
Key length [8 bits]
Key values [variable]
Signal strength [1byte]
IP address flag [1]
IP address [ 5 bytes]
}
The number of networks, m [1 byte]{
AN ID [32 bytes]
// TBD
}
**
}|
}
1
2
3
4
5
6.1.5 Radio Report Reply

<Table 6.1.5-1> Radio Report Reply message
Field
return code [1 bit]
Preferred WRM
Conf. [1 byte]
MAG
Lab presents
4
description
The processing result of Registration
Request
0: success
1: fail
TBD
Page 49 of 67
default
2
wrm DB update incl [2
bits]
If wrm DB is included, this field has 1

or 2. Otherwise 0.
DB list
1 : an embedded DB List in theis

message replaces a current DB list
2 : all tables are partially updated
to a current DB list. The below DB
List will contain only any records
in all tables if some fields of the
records are supposed to be updated
with the new values.
If wrm DB update incl is 1 or 2,

The selection table, the location table
and the radio resource table are
included. Otherwise omitted.
DB List
{
Location Table LT;
Radio Resource Table RRT;
Selection Table ST;
}
1
2
3
4
5
6.2
Databases
6.2.1 Selection Table
<Table 6.2.1-1> Selection Table

Field
The number of records in selection
table, SN
Selection Table [1.. SN]
{
N_L [4 bytes]
The number of record in Network
Type, NN
Network Type Table [1..NN]
{
N_N [1byte]
description
default
The N_L ID assigned to an

upper Location field
Network Type
N_N2 : Cellular (>= 3G)
N_N2 : WiFi
N_N3 : legacy cellular
Page 50 of 67
MAG Lab presents
2
3
The number of record in

Desire N_Rs, ANR
Desire N_Rs [1.. ANR]
{
N_R [4 bytes]
C_T [4 bytes]
U_T[4 bytes]
W_R [1 bytes]
(<3G)
N_N4 : Femtocell
(WiFi+Cellular)
N_N5: WiMax
N_N6~N10: reserved
N_R ID to indicate the access

point at the upper N_L area for
the network selection.
The creation time of this
record. // TBD
The last update time of this
record. // TBD
The weight value that is used
to choose one among multiple
N_Rs.
The N_R having the biggest
W_R value shall be chosen a
candidate N_R for the network
selection.
N_Z [4 bytes]
0: no weight
1~255: weight
TBD
The number of record in

Next N_Rs, NNR
Next N_Rs [1.. NNR]
{
Type [1 bit]
N_L [4 bytes]
N_R [4 bytes]
MAG
Lab presents
4
0: no Zone ID assigned
>=1: N_Z ID for the upper
N_R field.
The Size of Next N_Rs. NNR
shall be less than or equal to 3.
To indicate that a handover
candidate N_R is
0x0 : only N_R included
0x1 : N_L & N_R included
If Type is 0x01, the N_L ID of
the N_R as a handover
candidate. Otherwise, omitted.
The N_R ID of the handover
candidate access point.
Page 51 of 67
2
}
I_R [1 byte]
U_R [1 byte]
S_R [1 byte]
S_P [1 byte]
The size of Performance
blob, PB
Performance
[1..PB bytes]
TBD
TBD
TBD
TBD
0
0
0
0
0
TBD
}
}
}
1
2
3
4
6.2.2 Location Table

<Table 6.2.2-1> Location Table
Field
The number of records in
location table, LN
Location Table [1..LN]
{
Location
N_L [4 bytes]
C_T [4 bytes]
U_T[4 bytes]
I_L [1 byte]
U_L [1 byte]
S_L [1 byte]
S_P[1 byte]
description
The size of Location Table
default
The location at where the mobile

device stands currently or before.
The N_L ID assigned to an upper
Location field
The creation time of this record.
// TBD
record. //TBD
TBD
TBD
TBD
TBD
0
0
0
0
}
5
6
7
8
9
6.2.3 Radio Resource Table

<Table 6.2.3-1> Radio Resource Table
Field
The number of records in radio
resource table, RN
Radio Resource Table
description
The size of Radio Resource Table
Page 52 of 67
default
MAG Lab presents
2
3
[1.. RN]
{
N_R [4 bytes]
Network List
Location
N_L [4 bytes]
C_T [4 bytes]
U_T[4 bytes]
I_L [1 byte]
U_L [1 byte]
S_L [1 byte]
S_P[1 byte]
The N_R ID assigned to the access

point.
The access point information
The location of the access point,
which its assigned N_R is an upper
N_R field.
The N_L ID that sensed the access
point having an upper N_R ID.
The creation time of this record.
// TBD
record. //TBD
TBD
TBD
TBD
TBD
0
0
0
0
description
default
}
1
2
3
4
5
6.2.4 User Log Table

<Table 6.2.4-1> User Log Table
Field
The number of records in user
log table, ULT
User Log Table Record
[1.. ULT]
{
Time [4 bytes]
Event type [1 byte]
Event details [1 byte]
Event log {
If Event type = 0x01
See <Table 2.4.1-1>

See <Table 2.4.1-1>
{
Location loc;
DB List dbList;
Scanning result incl [1 byte]
byte numActiveNetwork;
Active Network List {
AN ID [32 bytes]
IP Address [4 bytes]
MAG
Lab presents
4
Page 53 of 67
2
}
}
{
Location loc;
AN ID [32 bytes]
// Performance // TBD
}
}
{
Location prevLocation
Locaton curLocation
AN ID [32 bytes]
// Performance // TBD
}
}
{
byte handoffResult; // 0 : success
Locaton loc;
Active Network List oldNet;
Active Network List newNet;
}
Page 54 of 67
MAG Lab presents
2
3
1Appendix.
2
A C Structure of WRM signaling messages
// Constants
#define MAX_USER_ID
#define MAX_NET_DEVICE
#define MAX_NET_ID
network
#define MAX_AN_ID
#define MAX_NET_LIST
list
#define MAX_EVENT_LOGBODY
20
32
32
// Max length of 'UserID' arrary

// Max network devices per one user
// Max length of the name of access
32
16
// Max length of 'AN_ID' array

// Max number of access networks in the
65535
// Max size of log body in one event log.
#define NUM_MSG_TAG
#define MAX_INFO_NUM
records
9
5
// The number of HYNSE messages

// Max number of common information
#define MAX_REPRECORD_NUM
msg.
#define MAX_THREADS
10
#define MAX_WRM_MSG_SIZE
#define MAX_NL_LIST
10
// Max number of records in a radio report

// Max number of threads
1500 // Max size of a message

65535 // Max size of NL List
// Max size of NL Table in Selection Table

#define MAX_REC_SEL_NL_TABLE
100
// Max size of Radio Resource Records in Radio Resource Table
#define MAX_REC_RADIORESOURCE_TABLE 256
// Max size of Location Records in Location Table
#define MAX_REC_LOCATION_TABLE
256
// Max size of NR Records in Selection Table
#define MAX_SELTABLE_NR
256
// Max size of NN Records in Selection Table
#define MAX_SELTABLE_NN
8
// Max size of Next NR Records in Selection Table
#define MAX_SELTABLE_NEXT_NR
256
// Max size of Performance Blob in Selection Table
#define MAX_PERF_BLOBSIZE
256
// Max Key Length : the maxlength of WEP or WPA keys in hexadecimal string.
#define MAX_KEY_LENGTH
64
typedef
typedef
typedef
typedef
typedef
unsigned
unsigned
unsigned
unsigned
double
char
char
short int
int
byte; // one byte

Bit;
// Number of bits
word16;// 2 bytes
word32;// 4 bytes
dword32;// double
// Sender ID
enum senderID
{
WRM = 0,
CRRM_SERVER,
CRRM_DB
};
// Message IDs
enum messageID
{
RegReq_msgId = 0,
RegReply_msgId,
MAG
Lab presents
4
Page 55 of 67
2
//RadRepReq_msgId,
RadRepReply_msgId,
RadReport_msgId,
//RegRequired_msgId,
//UserMovTrackReq_msgId,
//UserMovTrackReply_msgId,
//NetListUpdateInd_msgId,
};
// Information Records
enum informationID
{
NETDEV = 0, // record
LOCINFO,
// record
NETLIST,
// record
EVENTL,
// record
REPR,
// record
};
ID
ID
ID
ID
ID
of
of
of
of
of
network device
loaction information
network list
event log
radio report record
// The Pack/Unpack functions in a byte unit

word16 pack_byte(byte *array, word32 val, word16 index, word16 width);
word32 unpack_byte( byte *array, word16 index, word16 width);
// Macro for Pack function of Informatin Record
// - Range checke performed before calling a pack function.
// - [11/03/2008] prev is not used, but is defined for the future use.
//
Default valus is '1'.
#define PkInf(infoId, infob, info_record, record_len, empty, len, prev) \
(infoId < 0 || infoId > MAX_INFO_NUM) ? 0 : \
inf_fuc[infoId].pack(infob,info_record,record_len,empty,len,prev)
// Macro for Unpack function of Informatin Record
#define UnpkInf(infoId, infob, info_record,record_len, empty, len, prev) \
(infoId< 0 || infoId> MAX_INFO_NUM) ? 0 : \
inf_fuc[infoId].unpack(infob,info_record,record_len,empty,len,prev)
// Macro for Pack function of Informatin Record
#define PkMsg(msgId, msgb, msgl, msg_record, empty, prev) \
(msgId< 0 || msgId > NUM_MSG_TAG) ? 0 : \
msg_fuc[msgId].pack(msgb,msg_record,sizeof(msg_record),empty,prev)
// info_record changed to msg_record
// Macro for Unpack function of Informatin Record
#define UnpkIMsg(msgId, msgb, msgl, msg_record, empty, prev) \
(msgId< 0 || msgId > NUM_MSG_TAG) ? 0 : \
msg_fuc[msgId].unpack(msgb,msg_record,sizeof(msg_record),empty,prev)
// info_record changed to msg_record
// Macro for a starting address of the field.
#define BPOS(type, field) \
((unsigned int)&( ( (type *) (0))->field[0]))
// Macro for calculating the bit length of the field.
#define BLEN(type,field) (sizeof(((type *) (0))->field))
// Macro for the Pack_byte function that is used by the message pack function
#define WRM_PACK(pmsg,val,type,item,len) len += pack_byte((byte *)pmsg,val,\
empty + BPOS( type, item ), BLEN( type, item ) )
// Macro for the Unpack_byte function that is used by the message pack
function
#define WRM_UNPACK(pmsg,val,ret_type,type,item) \
val = (ret_type)unpack_byte((byte
Page 56 of 67
MAG Lab presents
2
3
*)pmsg,empty+BPOS(type,item),\
BLEN(type,item ) ); \
length += BLEN( type, item )
// Alternative macro for the pack_byte function
// - [11/03/2008] This macro assumes that a caller gives the bit length
//
of the field explicitely.
#define WRM_PACKL(pmsg,val,pos,length) \
len += pack_byte((byte *)pmsg,val,pos,length)
// Alternative macro for the pack_byte function
#define WRM_UNPACKL(pmsg,val,ret_type,pos,len) \
val = (ret_type)unpack_byte((byte *)pmsg,pos,len); \
length += len
// The structure of the common header
typedef struct
{
byte
version;
// version = 1
byte
msgId;
// message ID
word16 megLen;
// message length of the message body
// except the rest of the common header
word16 seqNum;
// sequence number
word16 seqNumAck;
// sequence number acked from a correspondent.
struct SenderInfo_Type
{
byte
senderId;
byte
IPAddr[4];
word16 PortNo;
} SenderInfo;
} commonHdr_Type;
// sender ID
// 'octet.octet.octet.octet'
// TCP or UDP port number
typedef struct
{
byte netDeviceType;
byte MACAddr[6];
} AddrNetDevices_Info_Type;
typedef struct
{
Bit netDeviceType[5];
Bit MACAddr[6][8];
} AddrNetDevices_Info_Bit_Type;
typedef struct
{
byte
accuracy;
double longitude; // [11/27/2008] SIYOON Added
double latitude;
double altitude;
dword32 speed;
dword32 UTCtime;
} LocationInfo_Type;
typedef struct
{
Bit accuracy[8];
Bit longitude[64]; // [11/27/2008] SIYOON Added
Bit latitude[64];
Bit altitude[364];
Bit speed[32];
Bit UTCtime[32];
MAG
Lab presents
4
Page 57 of 67
2
} LocationInfo_Bit_Type;
typedef struct
{
byte
networkID[MAX_NET_ID];
byte
netDeviceType;
byte
ANID[MAX_AN_ID];
byte
ANAddr[6];
byte
freq;
word32 channel;
byte
signalStrength;
byte
maxAPTxPwr;
byte
standardSupported;
byte
accessMethod;
byte
keyLength;
byte
keyValues[MAX_KEY_LENGTH];
byte
IPaddrFlag;
byte
IPaddr[4];
} NetworkList_Info_Type;
typedef struct
{
Bit networkID[32][8];
Bit netDeviceType[5];
Bit ANID[32][8];
Bit ANAddr[6][8];
Bit freq[1];
Bit channel[20];
Bit signalStrength[8];
Bit maxAPTxPwr[8];
Bit standardSupported[8];
Bit accessMethod[8];
Bit keyLength[8];
Bit keyValues[MAX_KEY_LENGTH][8];
Bit IPaddrFlag[1];
Bit IPaddr[15][8];
} NetworkList_Info_Bit_Type;
typedef struct
{
byte
eventType;
byte
details;
word16 logLen;
byte
logBody[MAX_EVENT_LOGBODY];
} NetEvent_Info_Type;
typedef struct
{
Bit eventType[4];
Bit details [4];
Bit logLen[16];
Bit logBody[MAX_EVENT_LOGBODY][8];
} NetEvent_Info_Bit_Type;
typedef struct
{
byte
eventType;
byte
logLen;
NetEvent_Info_Type eventLogBody;
} Event_Info_Type;
typedef struct
Page 58 of 67
MAG Lab presents
2
3
{
Bit eventType[2];
Bit logLen[16];
NetEvent_Info_Bit_Type eventLogBody;
} Event_Info_Bit_Type;
typedef struct
{
word32 NL_ID;
LocationInfo_Type location;
} NL_List_Type;
typedef struct
{
Bit NL_ID[32];
LocationInfo_Bit_Type location;
} NL_List_Bit_Type;
typedef struct
{
word32 N_L;
word32 C_T;
word32 U_T;
byte
I_L;
byte
U_L;
byte
S_L;
byte
S_P;
} LocationTable_rec0_Type;
typedef struct
{
Bit N_L[32];
Bit C_T[32];
Bit U_T[32];
Bit I_L[8];
Bit U_L[8];
Bit S_L[8];
Bit S_P[8];
} LocationTable_rec0_Bit_Type;
typedef struct
{
word16 numRec;
LocationTable_rec0_Type locTable[MAX_REC_LOCATION_TABLE];
} LocationTable_Info_Type;
typedef struct
{
Bit numRec[16];
LocationTable_rec0_Bit_Type locTable[MAX_REC_LOCATION_TABLE];
} LocationTable_Info_Bit_Type;
typedef struct
{
word32 N_R;
NetworkList_Info_Type netList;
word32 N_L;
MAG
Lab presents
4
Page 59 of 67
2
word32
word32
byte
byte
byte
byte
C_T;
U_T;
I_L;
U_L;
S_L;
S_P;
} RRTable_rec0_Type;
typedef struct
{
Bit N_R[32];
NetworkList_Info_Bit_Type netList;
Bit N_L[32];
Bit C_T[32];
Bit U_T[32];
Bit I_L[8];
Bit U_L[8];
Bit S_L[8];
Bit S_P[8];
} RRTable_rec0_Bit_Type;
typedef struct
{
word16 numRec;
RRTable_rec0_Type rrTable[MAX_REC_RADIORESOURCE_TABLE];
} RadioResourceTable_Info_Type;
typedef struct
{
Bit numRec[16];
RRTable_rec0_Bit_Type rrTable [MAX_REC_RADIORESOURCE_TABLE];
} RadioResourceTable_Info_Bit_Type;
typedef struct
{
byte type;
word32 N_L;
word32 N_R;
} SelectionTable_NextNR_Info_Type;
typedef struct
{
Bit type[8];
Bit N_L[32];
Bit N_R[32];
} SelectionTable_NextNR_Info_Bit_Type;
typedef struct
{
word32 N_R;
word32 C_T;
word32 U_T;
byte
W_R;
word32 N_Z;
Page 60 of 67
MAG Lab presents
2
3
word16 numRec;
SelectionTable_NextNR_Info_Type NextNR[MAX_SELTABLE_NEXT_NR];
byte
byte
byte
byte
I_R;
U_R;
S_R;
S_P;
word16 blobSize;
byte
blob[MAX_PERF_BLOBSIZE];
} SelectionTable_NR_Info_Type;
typedef
{
Bit
Bit
Bit
Bit
Bit
struct
N_R[32];
C_T[32];
U_T[32];
W_R[8];
N_Z[32];
Bit numRec[16];
SelectionTable_NextNR_Info_Bit_Type NextNR[MAX_SELTABLE_NEXT_NR];
Bit
Bit
Bit
Bit
I_R[8];
U_R[8];
S_R[8];
S_P[8];
Bit blobSize[16];
Bit blob[MAX_PERF_BLOBSIZE][8];
} SelectionTable_NR_Info_Bit_Type;
typedef struct
{
byte
N_N;
word16 numRec;
SelectionTable_NR_Info_Type selNR[MAX_SELTABLE_NR];
} SelectionTable_NN_Info_Type;
typedef struct
{
Bit N_N[8];
Bit numRec[16];
SelectionTable_NR_Info_Bit_Type selNR[MAX_SELTABLE_NR];
} SelectionTable_NN_Info_Bit_Type;
typedef struct
{
word32
N_L;
word16 numRec;
SelectionTable_NN_Info_Type selNR[MAX_SELTABLE_NN];
} SelectionTable_NL_Info_Type;
typedef struct
{
MAG
Lab presents
4
Page 61 of 67
2
Bit N_L[32];
Bit numRec[16];
SelectionTable_NN_Info_Bit_Type selNR[MAX_SELTABLE_NN];
} SelectionTable_NL_Info_Bit_Type;
typedef struct
{
word16 numRec;
SelectionTable_NL_Info_Type selTable[MAX_REC_SEL_NL_TABLE];
} SelectionTable_Info_Type;
typedef struct
{
Bit numRec[16];
SelectionTable_NL_Info_Bit_Type selTable [MAX_REC_SEL_NL_TABLE];
} SelectionTable_Info_Bit_Type;
typedef struct
{
LocationTable_Info_Type locTable;
RadioResourceTable_Info_Type rrTable;
SelectionTable_Info_Type selTable;
} DBList_Info_Type;
typedef struct
{
LocationTable_Info_Bit_Type locTable;
RadioResourceTable_Info_Bit_Type rrTable;
SelectionTable_Info_Bit_Type selTable;
} DBList_Info_Bit_Type;
typedef struct
{
byte
byte
purpose;
userID[MAX_USER_ID];
byte
byte
byte
mobileDeviceType;
netInterfaceCapa;
wrmDBUpdateInd;
byte
LocationInfo_Type
locationInfoFlag;
locationInfo;
word16
NL_List_Type
NLListLen;
NLList[MAX_NL_LIST];
byte
byte
NetworkList_Info_Type
sesningResultIncl;
sizeNetworkList;
NetworkList[MAX_NET_LIST];
byte
Event_Info_Type
eventLogFlag;
eventLog;
} RegReq_Type;
Page 62 of 67
MAG Lab presents
2
3
typedef struct
{
Bit
Bit
purpose[8];
userID[MAX_USER_ID][8];
Bit
Bit
Bit
mobileDeviceType[4];
netInterfaceCapa[8];
wrmDBUpdateInd[1];
Bit
LocationInfo_Bit_Type
locationInfoFlag[1];
locationInfo;
Bit
LocationInfo_Bit_Type
NLListLen [16];
NLList[MAX_NL_LIST];
Bit
Bit
NetworkList_Info_Bit_Type
sesningResultIncl[1];
sizeNetworkList[8];
NetworkList[MAX_NET_LIST];
Bit
Event_Info_Bit_Type
eventLogFlag[1];
eventLog;
} RegReq_Bit_Type;
typedef struct
{
byte
byte
byte
byte
DBList_Info_Type
byte
byte
} RegReply_Type;
typedef struct
{
Bit
Bit
returnCode;
reasonCode;
preferredWRMConfig;
wrmDBUpdateInd;
dbList;
scanningRequestInd;
scanningReportImmediate;
returnCode[1];
reasonCode[8];
Bit
Bit
preferredWRMConfig[8];
wrmDBUpdateInd[2];
DBList_Info_Bit_Type
dbList;
Bit
Bit
scanningRequestInd;
scanningReportImmediate;
} RegReply_Bit_Type;
typedef struct
{
LocationInfo_Type locInfo;
} repRecordType0_Loc_Type;
typedef struct
{
LocationInfo_Bit_Type locInfo;
} repRecordType0_Loc_Bit_Type;
MAG
Lab presents
4
Page 63 of 67
2
typedef struct
{
byte numNetList;
NetworkList_Info_Type netList[MAX_NET_LIST];
} repRecordType1n2_NetList_Type;
typedef struct
{
Bit numNetList[8];
NetworkList_Info_Bit_Type netList[MAX_NET_LIST];
} repRecordType1n2_NetList_Bit_Type;
typedef struct
{
byte
recordType;
byte
netDevType;
word16 bodyLen;
union
{
repRecordType0_Loc_Type
loc;
repRecordType1n2_NetList_Type netList;
} record;
} RepRecord_Info_Type;
typedef struct
{
Bit recordType[4];
Bit netDevType[5];
Bit bodyLen[16];
union
{
repRecordType0_Loc_Bit_Type
loc;
repRecordType1n2_NetList_Bit_Type netList;
} record_Bit;
} RepRecord_Info_Bit_Type;
typedef struct
{
byte
byte
timerInterval;
repInfoInd;
byte
word32
numRecord;
totSizeRecord;
RepRecord_Info_Type record[MAX_REPRECORD_NUM];
} RadReport_Type;
typedef struct
{
Bit
Bit
Bit
Bit
timerInterval[8];
repInfoInd[8];
numRecord[8];
totSizeRecord[32];
RepRecord_Info_Type record[MAX_REPRECORD_NUM];
} RadReport_Bit_Type;
Page 64 of 67
MAG Lab presents
2
3
typedef struct
{
byte
byte
byte
DBList_Info_Type
returnCode;
wrmDBUpdateIncl;
dbList;
} RadRepReply_Type;
typedef struct
{
Bit
Bit
Bit
returnCode[1];
wrmDBUpdateIncl[2];
DBList_Info_Bit_Type dbList;
} RadRepReply_Bit_Type;
typedef struct
{
commonHdr_Type header;
union {
RegReq_Type
RegReply_Type
RadRepReply_Type
RadReport_Type
} Msgbody;
} wrmMsg;
RegReqMsg; //[11/27/2008] TYPO

RegReplyMsg;
RadRepReplyMsg;
RadReportMsg;
// Pack& Unpack function declarations for information records

int inf_pack_locInfo(byte* infoBuf, void *vlocInfo,
byte record_len, byte empty, word16 len, byte prev);
int inf_unpack_locInfo(byte* infoBuf,void *vlocInfo,
byte record_len, byte empty, word16 length, byte prev);
int inf_pack_netList(byte* infoBuf, void *vnetList,
int inf_unpack_netList(byte* infoBuf, void *vnetListnetList,
int inf_pack_eventL(byte* msgBuf, void *veventL,
int inf_unpack_eventL(byte* msgBuf, void *veventL,
int inf_pack_repR(byte* infoBuf,void *vrepR,
int inf_unpack_repR(byte* infoBuf,void *vrepR ,
int inf_pack_repR(byte* infoBuf,void *vrepR,
int inf_unpack_locTbl(byte* infoBuf,void *vlocTbl ,
MAG
Lab presents
4
Page 65 of 67
2
int inf_pack_locTbl (byte* infoBuf,void *vlocTbl,
int inf_unpack_rrTbl(byte* infoBuf,void *vrrTbl ,
int inf_pack_selTbl (byte* infoBuf,void *vrrTbl,
int inf_unpack_selTbl(byte* infoBuf,void *vselTbl ,
int inf_pack_dbList (byte* infoBuf,void *vdbList,
int inf_unpack_dbList (byte* infoBuf,void *vdbList,
// Pack& Unpack function declarations for HYNES messages
int msg_pack_RegReq( byte *msgBuf, void *vRegReqBuf,
byte record_len, int empty, byte prev);
int msg_unpack_RegReq( byte *msgBuf, void *vRegReqBuf,
int msgLen, int empty, byte prev);
int msg_pack_RegReply( byte *msgBuf, void *vRegReplyBuf,
int msg_unpack_RegReply( byte *msgBuf, void *vRegReplyBuf,
int msg_pack_RadRepReply( byte *msgBuf, void *vRadRepReplyBuf,
int msg_unpack_RadRepReply( byte *msgBuf, void *vRadRepReplyBuf,
int msg_pack_RadReport( byte *msgBuf, void *vRadReportBuf,
int msg_unpack_RadReport( byte *msgBuf, void *vRadReportBuf,
1
Page 66 of 67
MAG Lab presents
2
3
1Appendix.
B Class Diagram of WRM application
2
3
MAG
Lab presents
4
Page 67 of 67

WRM Spec 0.2 Draft

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

WRM Spec 0.2 Draft

Uploaded by

Copyright:

Available Formats

1WRM Specification version 0.2 (WRM-Spec-Ref0.

WRM Specification for Mobile Devices

First draft released for the purpose of a review.

1WRM Specification version 0.2

5. Define all maximum

In the first stage of an integration test, all messages

MAG Lab presents

1WRM Specification version 0.2 (WRM-Spec-Ref0.2)

8. Define the structure of

First of all, a format of the user log table must be

9. Detail how to upload

10. Manage user profile

P2P or FTP or other ways to upload whatever

1WRM Specification version 0.2 (WRM-Spec-Ref0.2)

1WRM Specification version 0.2 (WRM-Spec-Ref0.2)

1WRM Specification version 0.2

MAG Lab presents

1WRM Specification version 0.2 (WRM-Spec-Ref0.2)

1WRM Specification version 0.2

MAG Lab presents

1WRM Specification version 0.2 (WRM-Spec-Ref0.2)

Scope of the Document

Architecture Reference Model

The WRM architecture reference model consists of the following functional

1WRM Specification version 0.2

MAG Lab presents

1WRM Specification version 0.2 (WRM-Spec-Ref0.2)

1WRM Specification version 0.2

Two protocols are defined in the WRM Interface.

1.4.4 WRM database

WRM Application Architecture

MAG Lab presents

1WRM Specification version 0.2 (WRM-Spec-Ref0.2)

2.1.1 General Overview

1WRM Specification version 0.2

MAG Lab presents

1WRM Specification version 0.2 (WRM-Spec-Ref0.2)

The WRM application shall collect the following parameters.

2.3.1 Location Table

Longitude, Latitude, Altitude : GPS location information

1WRM Specification version 0.2

2.3.2 Selection Table

W_R Next1 Next2 Next3 Accuracy

N_L : Location index

2.3.3 Radio Resource Table

N_R : Location Index

WRM database lifecycle

MAG Lab presents

1WRM Specification version 0.2 (WRM-Spec-Ref0.2)

2.4.1 Initial stage

0x21 : Location changed

0x31 : VHO to WLAN

Every record shall include other information as the following.

1WRM Specification version 0.2

MAG Lab presents

1WRM Specification version 0.2 (WRM-Spec-Ref0.2)

<Table 2.4.1-2> Example of Location Table

Longitude Latitude Altitude C_T

N_N N_R N_Z W_R Next1 Next2 Next3 Accuracy C_T

<Table 2.4.1-4> [Before update] Example of Selection Table

<Table 2.4.1-3> Example of Radio Resource Table

W_R Next1 Next2

1WRM Specification version 0.2