wrm_spec_0.2_draft
DESCRIPTION
WRM Specification version 0.2 (WRM-Spec-Ref0.2)TRANSCRIPT
HYNES Specification
WRM Specification version 0.2 (WRM-Spec-Ref0.2)WRM Specification version 0.2WRM Specification version 0.2 (WRM-Spec-Ref0.2)
Ref RRM: RRM-Spec-Ref0.1Date
0.111-23-2009First review done
Major Issues.
Issue titlePriorityStatusDescription
1. Finalize the definition of Network index (N_N) and Zone index (N_Z)CriticalClosedComparing 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.
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.Major
(urgent)Not HandledThis issue is so close to the PRRM design. TBD
3. Define the metrics of WRM performance from network to battery status. Major
(not urgent)Not HandledTBD
4. Finalize a handoff decision algorithm & a handoff execution procedure. CriticalIn progress[11/23/2009] Discussion
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 messagesMajor
(not urgent)Not HandledTBD
6. Defines new header and pack/unpack library for WRM application and the PRRM message handler.Major
(urgent)In ProgressIn the first stage of an integration test, all messages shall not use bit packing, instead, simply use the C structure type casting.
[11/23/2009] Discussion
1. In the document of interoperability tests, some examples of signaling messages shall be presented.
7. Compose interoperability test scenarios.MediumIn Progress[11/23/2009] Discussion
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 ProgressFirst 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.
[11/23/2009] Discussion
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)In ProgressP2P or FTP or other ways to upload whatever networks WRM mobile devices can associate to upload the user log file. [11/23/2009] Discussion
1. Further investigation is required
10. Manage user profile and the WEP key for an automatic login. Major
(not urgent)New registered[11/23/2009] Discussion
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.
Beside, the PRRM and the CRRM are now expected to be released the first version in Jan. 2010.
Contents91Overview
91.1Scope of the Document
91.2Requirements Language
91.3Architecture Reference Model
101.4WRM Architecture
101.4.1Lifecycle
101.4.2States
111.4.3Handlers
121.4.4WRM database
122WRM Application Architecture
122.1Introduction
132.1.1General Overview
142.1.2Architecture Reference Model
142.2Parameters
152.3WRM database
152.3.1Location Table
152.3.2Selection Table
162.3.3Radio Resource Table
162.4WRM database lifecycle
162.4.1Initial stage
212.4.2Active stage
243Session Control Protocol
243.1Introduction
243.1.1General Overview
243.1.2Call Flow
273.2WRM application sequence flow
273.2.1Sequence flow for Case 1) and Case 2)
283.2.2Sequence flow for Case 3) and Case 4)
294Radio Monitoring Protocol
294.1Introduction
294.1.1General Overview
294.1.2Call Flow
304.2WRM application sequence flow
304.2.1Sequence flow for Case 1), Case 2) and Case 3)
315WRM Service Lifecycle
315.1Introduction
315.1.1General Overview
325.1.2Service Lifecycle
335.2Mode 0
345.3Mode 1
355.4WRM-led Handover
355.4.1Handover monitoring
385.4.2Handover execution
396Messages and Database
396.1Messages
396.1.1Common Header
406.1.2Registration Request
456.1.3Registration Reply
466.1.4Radio Report
496.1.5Radio Report Reply
496.2Databases
496.2.1Selection Table
516.2.2Location Table
526.2.3Radio Resource Table
526.2.4User Log Table
55Appendix. A C Structure of WRM signaling messages
67Appendix. B Class Diagram of WRM application
Figures
9 WRM Architecture Reference Model
10 WRM lifecycle
14 WRM Architecture Reference Model
18 Example of WRM DB list
19 Example of WRM Call Flow to Upload the User Log Table
21 Example of WRM-led Handover
24 Call Flow of Session Control Protocol
26 Call Flow for the PRRM-initiated Session Control.
27 Sequence Flow of WRM Application for Case 1) and Case 2).
28 Sequence Flow of WRM Application for Case 3) and Case 4).
29 Call Flow For Radio Monitoring Protocol
30 Sequence Flow of WRM Application for Case 1) , Case 2) and Case 3)
32 WRM Service Lifecycle
Tables
17 Format of User Log Table
18 Example of Location Table
19 Example of Radio Resource Table
19 [Before update] Example of Selection Table
19 [Before update] Example of Radio Resource Table
20 Example of User Log Table
21 [Before update] Example of Selection Table in Active Stage
22 Example of Radio Resource Table in Active Stage
22 [After update 1] Example of Selection Table in Active Stage
23 [After update 1] Example of Selection Table in Active Stage
25 Example of Registration Request message
25 Example of Registration Reply message
27 Example of Registration Reply message for Asynchronous Retrieval
30 Example of Radio Report message
30 Example of Radio Report Reply message
39 Common Header
40 Registration Request message
45 Registration Reply message
46 Radio Report message
49 Radio Report Reply message
49 Selection Table
51 Location Table
52 Radio Resource Table
52 User Log Table
Terms
WRM: WiRider ( or WiRider Manager )
PRRM: Personal Radio Resource Map
CRRM: Cognitive Radio Resource Map1 Overview1.1 Scope of the DocumentThese 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
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
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.
1.4 WRM Architecture
Figure 1.4.1-1 shows the diagram of the WRM lifecycle.
WRM lifecycle
1.4.2 States
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. 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.
2 WRM Application Architecture2.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. 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 ( Longitude, Latitude, Altitude: GPS location information C_T : creation time of this record I_L : index for location type (TBD) S_L : statistical maturity index of current location information (TBD)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_LN_NN_RN_ZW_RNext1Next2Next3Accuracy
C_TU_T
N_N : Network index N_Z : Zone index Next1 : 1st handover target access network Next3 : 3rd handover target access network C_T : record creation timeThis table contains the access network information.
N_RBSSIDSSIDN_NLongitudeLatitudeAltitudeC_TU_TW_R
N_ZI_RU_RS_RS_PPerf
BSSID : the MAC address of WiFi or the cell ID of 3G N_N : network type C_T : record creation time W_R, N_Z, I_R, U_R, S_R, S_P, Perf : TBD2.4 WRM database lifecycleAs 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.
[After update 1] Example of Selection Table in Active StageN_LN_NN_RN_ZW_RNext1Next2Next3Accuracy
N_L1N_N2N_R1N_Z110N_L2,
N_N2, N_R2N_N1-
N_N1N_R4N_Z22N_N2, N_R1N_N2,
N_R2-
N_L2N_N2N_R1N_Z15N_N2,
N_R2N_N1-
N_R2N_Z110N_N2,
N_R1N_L3,
N_N2,
N_R3N_N1-
N_N2N_R4N_Z22N_N2,
N_R1N_N2,
N_R2N_L3,
N_N2,
N_R3
N_L3
N_N2N_R2N_Z15N_N2,
N_R3N_N1
N_R3N_Z310N_L4
N_N2,
N_R3N_N2,
N_R2N_N1
N_N1N_R4N_Z22N_N2,
N_R2N_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:
[After update 1] Example of Selection Table in Active StageN_LN_NN_RN_ZW_RNext1Next2Next3Accuracy
N_L1N_N2N_R1N_Z110N_L2,
N_N2, N_R2N_N1-
N_N1N_R4N_Z22N_N2, N_R1N_N2,
N_R2-
N_L2N_N2N_R1N_Z15N_N2,
N_R2N_N1-
N_R2N_Z110N_N2,
N_R1N_L3,
N_N2,
N_R3N_N1-
N_N1N_R4N_Z22N_N2,
N_R1N_N2,
N_R2N_L3,
N_N2,
N_R3-
N_L3
N_N2N_R2N_Z15N_N2,
N_R3N_N1-
N_R3N_Z310N_L4
N_N2,
N_R3N_N2,
N_R2N_N1-
N_N1N_R4N_Z22N_N2,
N_R2N_N2,
N_R3-
N_L4N_N2N_R3N_Z310N_L4N_L5,
N_N1,
N_R4N_N2,
N_R2-
N_N1N_R4N_Z25N_N2,
N_R3-
The selection table shall be updated whenever the mobile device moves to an already-known location.
3 Session Control Protocol3.1 Introduction
The session control protocol shall be used to manage a WRM session between the WRM application and the PRRM.
3.1.1 General Overview
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. The WRM application is started for the first time.
2. The new day is started
3. The new location is detected
4. A current WRM database is incorrect or out of date.
3.1.2 Call Flow
Figure 3.1.2-1 shows the call flow for the session control protocol. Two signaling messages, a Registration Request message and a Registration Reply message, are defined for the session control protocol.
Call Flow of Session Control Protocol
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.
Example of Registration Request messageCase 1)Case 2)Case 3)Case 4)
Purpose0x010x020x030x04
Current
LocationIncluded
wrm DB update ind0 or 10 or 111
The number of NL_listIf wrm DB update ind is 1, 0~255 (0 indicates all N_L information of PRRM ). Otherwise, it is omitted
NL_listIf 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.
}
sensing
result incl10 or 111
AP listincludedIf sensing result incl is 1,
Included. Otherwise 0.includedincluded
event log incl0 or 1
Event logIf event log incl is 1, Included. Otherwise 0.
Example of Registration Reply messageCase 1)Case 2)Case 3)Case 4)
return code0: No Error
0x01~0x65535 : Errors
Preferred WRM Conf.included
wrm DB update incl0, 1 or 20, 1 or 21 or 21 or 2
DB listIf wrm DB update incl is 1 or 2, included. Otherwise 0.DB list {
The number of records in location table, LN;
Location Table[LN] {
N_L,C_T ,U_T }The number of records in radio resource table, RN;
Radio Resource Table[RN] {
N_L,C_T ,U_T }The number of records in selection table, SN;
Selection Table[SN] {
N_N, Longitude, Latitude, Altitude,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 database being out of date or incorrect, the WRM application starts in mode 0. Otherwise, in general, the application starts in mode 1.
5.1.1 General OverviewIn 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 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.5.1.2 Service Lifecycle
Figure 5.1.2-1 shows the overview of the WRM lifecycle.
WRM Service Lifecycle
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.
In this case, starting at the mode 0 can be ended if the PRRM can provide the latest WRM database for the current location.
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. In this case, starting from the mode 0 can be ended if the PRRM can provide the latest WRM database for the current location.
The Registration Request message with purpose = 0x04 shall be transmitted to the PRRM.
[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.
The Registration Request message with purpose = 0x03 shall be transmitted to the PRRM.
[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.
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.
The Registration Request message with purpose = 0x04 shall be transmitted to the PRRM.
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 [Mode0-Case 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 [Mode0-Case 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 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.
The Registration Request message with purpose = 0x01 or 0x02 shall be transmitted to the PRRM.
[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.
In this case, the WRM application is kept in a current mode, mode 2.
The WRM message consists of the header part and the message body part.
Message body
6.1.1 Common Header
Fielddefault
Version information. Message ID [1 byte] 0 = Registration Request
2 = Radio Report
4 ~ : reservedMessage length
The length of the message body.
[2 bytes] Range : 0 ~ 65535Sequence Ack number.
The latest sequence number received from a receiver.
{
The Sender Identification
1 = the CRRM serverIP address [4 bytes]
} Range : 0 ~ 65535Fielddefault
user ID [20 bytes]
[4 bits] 0: Mobile phone
2: Laptop
1
The capability of supported wireless interfaces
Bit 1 : Wi-Fi (multi)
Bit 3 : Cellular ( 3G or more)
Binary
(3G with one Wi-Fi)
The WRM application needs the latest WRM DB of a current location
1 : neededLocation Info flag
The Location Information has valid or void data.
1: voidLocation Information
This field is included if the Location Info flag is set 1.
Accuracy [1 byte]
latitude [8 bytes]UTC time [4 bytes]}
The size of the N_L ListNL_List[1..nl]
NL_ID [4 bytes]If the WRM application only does not know the N_L ID, NL_ID has 0. Location
0: no sensing performed
Network List size, m
[1 bytes] Range : 0 ~ 255
{
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 Type [5 bits]0
AN ID [32]
BSSID (MAC address) of APFrequency [1 bit]0
0th bit reserved
12th ~ 19th bits reservedSignal Strength
Unit: dbm.Max AP Tx Power [1 byte] Unit: dbmStandard supported
Bit 0 : 802.11a supported
Bit 2 : 802.11g supported
Bit 4 ~ Bit 7: reserved.00000101
Access method
Bit 0 : secured (encryption scheme is unknown ) Bit 2: secured (LEAP) Bit 4~Bit 7: reserved.Key length [8 bits], KLIf Access method & 0x02 (WEP)
If Access method & 0x08 (WAP)
Key values [1..KL]If Access method & 0x02 (WEP), the length of the string in Key Values are 10, 26, 32 or 58 characters for KL=64,128,152,256 respectively.
IP address flag
If the mobile got an assigned IP address from this access point, the flag is set to 1. Otherwise, it got 0. IP addressThe Senders IP address information like the IP address of IP header. 4 bytes represents 4 octets of IP address (Octect.Octet.Octet.Octet.).
Event log flagWRM is supposed to set 1 to this flag for all handoff events. Event Log {
0: Network events
2: User log table
[2 bytes]
If event type is 0{
Event details [8 bits]
Log body blob [variables]
Event type
1: network downed
Event details ( this field is only included if the Event type is 0)
1: VHO to 3G
3: HHO to 3G
Log body blob (block of bits) is used for the purpose of debugging.
Log length = 0
WRM events
Event type [4 bits] Log length [2 bytes]
}
0 : default
0x35~0x3f: reserved LogBLOB
Current network ID [32 bytes]
}Log length = 0
User Log Table Uploaded
Log length [4 bytes]
}
Fielddefault
The processing result of Registration Request
1: fail 0xff: Asynchronous Reply message initiatedReason [1byte]
TBDwrm DB update incl [2 bits] 1 : an embedded DB List in theis message replaces a current DB list
If wrm DB update incl is 1 or 2,
DB List
Location Table LT;
Selection Table ST;
[1 bit] 0: no
0
Scanning report immediate ind [1 bit]
Fielddefault
Range: 0 ~ 255.
What information included.
Bit 1: the latest wireless scanning results Bit 3: the network performance of monitoring wireless networks.
[1 byte]
[4 bytes]
Record type [4 bits] 0 : location
2 : network list (monitoring)
4~15: reservedNetwork Device Type [5 bits] 0 : Wi-Fi
8: Cellular
16 : WiMAX
24 : LTE
0
Record body length
The size of the record body.Body {
= Location Accuracy [1 byte]
latitude [8 bytes]UTC time [4 bytes]}If Record type is 1,
The number of networks, m [1 byte]
Network ID [32 bytes]AN ID [32 bytes]
Signal Strength [1 byte]
Frequency [1 bit]Standard supported [8 bitmask]Key length [8 bits]
IP address flag [1]
}
= Network ListNetwork List [1..m] {Network Device Type [5 bits]AN Address [6 bytes]
Max AP Tx Power [1 byte]Channel [4 bit mask]Access method [8 bitmask]
Key values [variable]IP address flag [1]
}If Record type is 3,
The number of networks, m [1 byte]{
AN ID [32 bytes]
Signal Strength [1 byte]
// TBD**
}
6.1.5 Radio Report Reply Radio Report Reply message descriptionThe processing result of Registration Request
1: failTBDIf wrm DB is included, this field has 1 or 2. Otherwise 0.
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.
DB listThe selection table, the location table and the radio resource table are included. Otherwise omitted.
{
Radio Resource Table RRT;
}Fielddefault
Selection Table [1.. SN]
N_L [4 bytes]
Network Type Table [1..NN]
N_N [1byte]Network Type N_N2 : Cellular (>= 3G)
N_N2 : WiFi
N_N3 : legacy cellular (The number of record in Desire N_Rs, ANR
{
N_R ID to indicate the access point at the upper N_L area for the network selection. C_T [4 bytes]
The last update time of this record. // TBDW_R [1 bytes]The N_R having the biggest W_R value shall be chosen a candidate N_R for the network selection.
0: no weight
1~255: weight N_Z [4 bytes]
The Size of Next N_Rs. NNR shall be less than or equal to 3.Next N_Rs [1.. NNR]
Type [1 bit] 0x0 : only N_R included
If Type is 0x01, the N_L ID of the N_R as a handover candidate. Otherwise, omitted.N_R [4 bytes]
I_R [1 byte]0
TBDS_R [1 byte]0
TBDThe size of Performance blob, PB0
[1..PB bytes]
}
Fielddefault
The size of Location TableLocation Table [1..LN]
Location
The N_L ID assigned to an upper Location fieldC_T [4 bytes]// TBDU_T[4 bytes]
TBDU_L [1 byte]0
TBDS_P[1 byte]0
Fielddefault
The size of Radio Resource TableRadio Resource Table
{
The N_R ID assigned to the access point.Network List
The location of the access point, which its assigned N_R is an upper N_R field.N_L [4 bytes]
The creation time of this record.
The last update time of this record. //TBDI_L [1 byte]0
TBDS_L [1 byte]0
TBD}
6.2.4 User Log Table User Log Table descriptionThe number of records in user log table, ULT
[1.. ULT]
Time [4 bytes]
See Event details [1 byte]
If Event type = 0x01Location loc;
Scanning result incl [1 byte]
Active Network List {
AN ID [32 bytes]
IP Address [4 bytes]
}If Event type = 0x02Location loc;Active Network List {
AN ID [32 bytes]
IP Address [4 bytes]
}
{
Locaton curLocation
Active Network List {
AN ID [32 bytes]
IP Address [4 bytes]
}
{
Locaton loc;Active Network List newNet;
}
Appendix. A C Structure of WRM signaling messages
// Constants #defineMAX_USER_ID 20 // Max length of 'UserID' arrary #define MAX_NET_DEVICE 32 // Max network devices per one user#define MAX_NET_ID 32 // Max length of the name of access network#define MAX_AN_ID 32 // Max length of 'AN_ID' array#define MAX_NET_LIST 16 // Max number of access networks in the list#define MAX_EVENT_LOGBODY 65535 // Max size of log body in one event log.#define NUM_MSG_TAG 9 // The number of HYNSE messages#define MAX_INFO_NUM 5 // Max number of common information records#define MAX_REPRECORD_NUM 10 // Max number of records in a radio report msg.#define MAX_THREADS 10 // Max number of threads #define MAX_WRM_MSG_SIZE 1500 // Max size of a message
#define MAX_NL_LIST 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 unsigned char byte; // one byte typedef unsigned char Bit; // Number of bits typedef unsigned short int word16;// 2 bytestypedef unsigned int word32;// 4 bytestypedef double dword32;// double// Sender IDenum senderID{ WRM = 0, CRRM_SERVER, CRRM_DB};// Message IDsenum messageID{ RegReq_msgId = 0, RegReply_msgId, //RadRepReq_msgId, RadRepReply_msgId, RadReport_msgId, //RegRequired_msgId, //UserMovTrackReq_msgId, //UserMovTrackReply_msgId, //NetListUpdateInd_msgId,};// Information Recordsenum informationID{ NETDEV = 0, // record ID of network device LOCINFO, // record ID of loaction information NETLIST, // record ID of network list EVENTL, // record ID of event log REPR, // record ID of radio report record};// The Pack/Unpack functions in a byte unitword16 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 *)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; // sender ID byte IPAddr[4]; // 'octet.octet.octet.octet' word16 PortNo; // TCP or UDP port number } SenderInfo;} commonHdr_Type; 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];} 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{ 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{ LocationInfo_Type location; 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{ LocationInfo_Bit_Type location; 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; LocationInfo_Type location; word32 N_L; word32 C_T; word32 U_T; byte I_L; byte U_L; byte S_L; byte S_P;} RRTable_rec0_Type;typedef struct{ Bit N_R[32]; NetworkList_Info_Bit_Type netList; LocationInfo_Bit_Type location; 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;
word16 numRec;
SelectionTable_NextNR_Info_Type NextNR[MAX_SELTABLE_NEXT_NR];
byte I_R; byte U_R; byte S_R; byte S_P; word16 blobSize; byte blob[MAX_PERF_BLOBSIZE];} SelectionTable_NR_Info_Type;typedef struct{ Bit N_R[32];
Bit C_T[32];
Bit U_T[32];
Bit W_R[8];
Bit N_Z[32];
Bit numRec[16];
SelectionTable_NextNR_Info_Bit_Type NextNR[MAX_SELTABLE_NEXT_NR];
Bit I_R[8]; Bit U_R[8]; Bit S_R[8]; Bit 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{ 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 purpose; byte userID[MAX_USER_ID]; byte mobileDeviceType; byte netInterfaceCapa;
byte wrmDBUpdateInd;
byte locationInfoFlag; LocationInfo_Type locationInfo; word16 NLListLen;
NL_List_Type NLList[MAX_NL_LIST];
byte sesningResultIncl; byte sizeNetworkList; NetworkList_Info_Type NetworkList[MAX_NET_LIST]; byte eventLogFlag; Event_Info_Type eventLog;} RegReq_Type;typedef struct{ Bit purpose[8]; Bit userID[MAX_USER_ID][8]; Bit mobileDeviceType[4]; Bit netInterfaceCapa[8];
Bit wrmDBUpdateInd[1];
Bit locationInfoFlag[1]; LocationInfo_Bit_Type locationInfo; Bit NLListLen [16]; LocationInfo_Bit_Type NLList[MAX_NL_LIST]; Bit sesningResultIncl[1]; Bit sizeNetworkList[8]; NetworkList_Info_Bit_Type NetworkList[MAX_NET_LIST]; Bit eventLogFlag[1]; Event_Info_Bit_Type eventLog;} RegReq_Bit_Type;typedef struct{ byte returnCode; byte reasonCode;
byte preferredWRMConfig;
byte wrmDBUpdateInd; DBList_Info_Type dbList; byte scanningRequestInd; byte scanningReportImmediate;} RegReply_Type;typedef struct{ Bit returnCode[1]; Bit reasonCode[8];
Bit preferredWRMConfig[8];
Bit wrmDBUpdateInd[2]; DBList_Info_Bit_Type dbList; Bit scanningRequestInd; Bit scanningReportImmediate;} RegReply_Bit_Type;
typedef struct{ LocationInfo_Type locInfo;} repRecordType0_Loc_Type;typedef struct{ LocationInfo_Bit_Type locInfo;} repRecordType0_Loc_Bit_Type;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 timerInterval; byte repInfoInd; byte numRecord; word32 totSizeRecord; RepRecord_Info_Type record[MAX_REPRECORD_NUM];} RadReport_Type;typedef struct{ Bit timerInterval[8]; Bit repInfoInd[8]; Bit numRecord[8]; Bit totSizeRecord[32]; RepRecord_Info_Type record[MAX_REPRECORD_NUM];} RadReport_Bit_Type;typedef struct{ byte returnCode;
byte preferredWRMConfig[8];
byte wrmDBUpdateIncl; DBList_Info_Type dbList;} RadRepReply_Type;typedef struct{ Bit returnCode[1]; Bit preferredWRMConfig[8];
Bit wrmDBUpdateIncl[2]; DBList_Info_Bit_Type dbList;} RadRepReply_Bit_Type;typedef struct { commonHdr_Type header; union { RegReq_Type RegReqMsg; //[11/27/2008] TYPO RegReply_Type RegReplyMsg; RadRepReply_Type RadRepReplyMsg; RadReport_Type RadReportMsg; } Msgbody;} wrmMsg;
// 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, byte record_len, byte empty, word16 len, byte prev);int inf_unpack_netList(byte* infoBuf, void *vnetListnetList, byte record_len, byte empty, word16 length, byte prev);int inf_pack_eventL(byte* msgBuf, void *veventL, byte record_len, byte empty, word16 len, byte prev);int inf_unpack_eventL(byte* msgBuf, void *veventL, byte record_len, byte empty, word16 length, byte prev);int inf_pack_repR(byte* infoBuf,void *vrepR, byte record_len, byte empty, word16 len, byte prev);int inf_unpack_repR(byte* infoBuf,void *vrepR , byte record_len, byte empty, word16 length, byte prev);int inf_pack_repR(byte* infoBuf,void *vrepR, byte record_len, byte empty, word16 len, byte prev);int inf_unpack_locTbl(byte* infoBuf,void *vlocTbl , byte record_len, byte empty, word16 length, byte prev);
int inf_pack_locTbl (byte* infoBuf,void *vlocTbl, byte record_len, byte empty, word16 len, byte prev);int inf_unpack_rrTbl(byte* infoBuf,void *vrrTbl , byte record_len, byte empty, word16 length, byte prev);int inf_pack_selTbl (byte* infoBuf,void *vrrTbl, byte record_len, byte empty, word16 len, byte prev);int inf_unpack_selTbl(byte* infoBuf,void *vselTbl , byte record_len, byte empty, word16 length, byte prev);
int inf_pack_dbList (byte* infoBuf,void *vdbList, byte record_len, byte empty, word16 len, byte prev);int inf_unpack_dbList (byte* infoBuf,void *vdbList, byte record_len, byte empty, word16 length, byte prev);
// 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,
byte record_len, int empty, byte prev);int msg_unpack_RegReply( byte *msgBuf, void *vRegReplyBuf,
int msgLen, int empty, byte prev);int msg_pack_RadRepReply( byte *msgBuf, void *vRadRepReplyBuf,
byte record_len, int empty, byte prev);int msg_unpack_RadRepReply( byte *msgBuf, void *vRadRepReplyBuf,
int msgLen, int empty, byte prev);int msg_pack_RadReport( byte *msgBuf, void *vRadReportBuf,
byte record_len, int empty, byte prev);int msg_unpack_RadReport( byte *msgBuf, void *vRadReportBuf,
int msgLen, int empty, byte prev);
Appendix. B Class Diagram of WRM application
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 (-)
Page 1 of 67Page 2 of 67Page 3 of 67
_1316785936.vsdDrag the side handle to change the width of the text block.
WRM
PRRM
Radio Report
(Re) started
_1316824798.vsdEvent Logger
Comm.Handler
HandoffHandler
WRMHandler
InitialHandler
PRRM
Registration Request
Registration Reply(Selection table update, if needed)
Activate
Result
Location
Location Acquisiton
Result
Activation
Activate
Result
New Day Started
_1316827982.vsdDrag the side handle to change the width of the text block.
WRM
PRRM
(Re) started
Trr_timeout
Radio Report
_1316954871.vsdEvent Logger
Comm.Handler
HandoffHandler
WRMHandler
InitialHandler
PRRM
Registration Request ( Reason )
Registration Reply(DT does not exist)
Activate
Optional, if sniffing(mode2) is requested
Sniff Update
Sniff Update Reply
Reason 2 : Selection Table Incorrect
WRMExplorer
Sniff Function
Activate
Result
Sniff Request
Result
PRRM
Radio Report ( Sniff Result )
Radio Report Reply(Selection Table download)
Reason 1 : New Location Detected
ULT Update
ULT Report Reply
_1317075651.vsdDispatchFromPRRM()getDecision()sendLogging()recordLog()
userNamedeviceInfoprrmInfostatus(mode)
WRM
locationlastUpdatedTime
Decision
1
0..*
1st prefAN2nd prefAN..Nth prefAN
Decision Detail
LoginInfolastLoginTimeQuality
Access Network
1
1..*
1..*
Licensed
Unlicensed
StartingTimeEndTimenumofLoggedEvents
Logging Detail
TimeType
EventLog
1..*
1
nonWRMEvent
WRMEvent
DateisUploaded
Logging
1
0..*
1..*
1
otherEvents
1
Noti_Handler()
currentLocationcurrentANnextLocationnextAN
ConnectionManager
1
1
Noti_Handler1()Noti_Handler2().,,,,,,,,,,,,,,,,,,,,,,,,Noti_HandlerM()
devStatus
3G
Noti_Handler1()Noti_Handler2().,,,,,,,,,,,,,,,,,,,,,,,,Noti_HandlerM()
WiFi Device
3G Device
LBS
Battery
PRRM
MobilePlatform(like Android)
devStatus
WiFi
_1316936256.vsdWRM
Service Agreement
PRRM Creation
WRM Install
Open WRM account
Mode 0 - WRM Explorer- Comm.- Event Logger
Mode 1- WRM Handler- Handoff Handler- Comm.- Event Logger
An user
Mode 2- Sniff Function
WRM uninstall
PRRMDelete
Close WRM account
PRRM
Mode 0- PRRM Explorer- Comm.- CRRM Manager
Mode 1- PRRM Handler- Comm.- UPT Manager- CRRM Manager
Mode 2- Map Updater
State
State Transition
Initial
Initial
Terminated
Terminated
Uninstalled
Uninstalled
_1316827248.vsdEvent Logger
Comm.Handler
HandoffHandler
WRMHandler
ULT Report
PRRM
Radio Report (ULT)
Radio Report Reply
ULT Report Reply
One Day Ended
_1316800524.vsd
_1316812101.vsdDrag the side handle to change the width of the text block.
WRM
PRRM
(Re) started
Treg_timeout
Registration Request
_1316795421.vsd
_1316514627.vsdWRM (re)started
Initial
WRM Installed
WRM Supported (Mode 1)
Comm.Handler
Sniff Function
WRMHandler
HandoffHandler
WRM Not supported(Mode 0)
WRM Uninstalled
WRM terminated
Active state
Event Logger
WRM Explorer
WRM DBMatured
Handler(Substate)
State
State Transition
Handler Dependency
Handler Management
Selection TableLocation TableRadio Resource Table
Tables
Reset
Handler Innovation
_1316777606.vsd0
1
N_Z1
N_Z2
_1316505262.vsdWRM
PRRM
CRRM
WiRider Interface
RRM Interface