• 沒有找到結果。

L OCATION E STIMATION

CHAPTER 7 CONCLUSIONS AND FUTURE RESEARCH .63

7.3. L OCATION E STIMATION

The information about the location of sensors is needed to detect the movement of patients and the positions of patients in the home health-care system. Doctors can use this information to track patients and know the positions of the patients. As shown in recent studies [14], location estimation consists of two types of devices, reference devices and blindfolded devices. The reference device knows its position, and the blindfolded device does not know its position. The latter must use an estimation location algorithm to calculate its location. The estimation location algorithm derives the location of the blindfolded device from the positions of reference devices. In the future, we can implement the estimation location algorithm into our wireless sensor network to determine a patient’s location.

Appendix A.

A.1. NLDE Entity

A.1.1. NLDE-Data Service

The primitive is used to send data frame to specific destination in network layer. If the device is not associated currently, the primitive will issue an NLDE-data-confirm primitive with status of INVALID-REQUEST. If the device is associated device, the NLDE-data -request primitive first constructs an NPDU in order to transmit the supplied NSDU. If the destination address is 0xffff, it represent the data will be sent by using broadcast way, so the broadcast radius and broadcast mode will be considered. Once the NPDU is constructed, the NSDU is routed using routing algorithm, this study only implements hierarchy routing according to neighbor table.

The Source Address Mode (SrcAddrMODE) and Destination Address Mode (DstAddrMode) parameter will be set to 0x02 that indicating the use of 16 bit address. The Source PAN Identifier (SrcPANID) and Destination PAN Identifier (DstPANID) parameters should be set to the current value of MAC PAN ID from the MAC PIB. If the network-wide security level specified in the NIB has a non-zero value and the Security Enable parameter has a value of true, the security processing will be applied to the frame before transmission. Finally, the NLDE-data-request will issue the MCPS-data-request to send the NPDU to destination using routing algorithm and wait for completion of transmission, when the transmission has been completed, the primitive will issue NLDE-data-confirm to report the result of transmission to upper layer. The flowchart of NLME-data-request primitive is shown in Fig. A-1.

Fig. A-1 Flowchart of data service of network layer

A.2. NLME Entity

The NLME entity consists of a lot of primitives, such as network discovery, network join /leave and others about management related primitives, these is explained later.

A.2.1. NLME-Network-Discovery-Request/Confirm Primitives

The NLME-network-discovery-request primitive allows the next higher layer to request that the NWK layer discover networks currently operating within the personal operating space (POS). The NLME-network-discovery-request is used to find existing device in the POS by issuing MLME-SCAN-request primitive with active scan type parameter. When the active scan has been completed, the scan result will store in PAN descriptor that is used for recording all existing device in the POS. Finally, the NLME-network-discovery-confirm is issued, it will assemble the network

descriptor list and calculate network count according to return information of MLME-scan-confirm. The flowchart of NLME-network-discovery service is shown in Fig. A-2.

Fig. A-2 Flowchart of network discovery service of network layer

A.2.2. NLME-Network-Formation-Request/Confirm Primitives

The primitive allows the next higher layer (application layer) to request that the device starts a new network with itself as the coordinator. If the device is not capable of being a ZigBee coordinator of a network, the NLME-network-formation-request will issue the NLME-network -formation-confirm primitive with the status parameter set to INVALID_REQUEST. The NLME-network-formation-request primitive first requests the MLME-scan-request with energy detection scan parameter to perform energy detection.

On receipt of the result from a successful energy detection scan, it orders the channels according to increasing energy measurement and discards those channels whose energy levels are beyond an acceptable level. And then run active scan by issuing MLME-scan-request primitive with a scan type parameter set to active scan and channel list is set to the list of acceptable channels to search for other ZigBee devices. The NLME-network-formation selects a suitable channel and PAN ID that is not conflict with other existing PANS. Once a suitable channel and PAN ID are determined, the NLME- network-formation will choose 0x0000 as the 16 bit network address, And then the NLME- network-formation will initialize the new super-frame configuration by issuing the MLME-start-request primitive with PAN coordinator parameter is be set to true, beacon order and super-frame order will be set as same those given to the NLME-network-formation-request.

Finally, the NLME-network-formation-request will issues the NLME- network-formation- confirm to notify next higher layer of the status of request with same status returned from the MLME-start-confirm primitive, the flowchart of NLME network formation is shown in Fig. A-3.

Fig. A-3 Flowchart of network formation in network layer

A.2.3. NLME-Permit-Joining-Request/Confirm Primitives

These primitives are used to define how the next higher layer of a ZigBee coordinator or router can request that devices be permitted to join its network. If the next layer of a ZigBee coordinator or router wants to define a fixed period during which it may accept devices onto its network by set its MAC layer association permit flag, it can issues the NLME- network-permit-join-request primitive with permit duration parameter. On receipt of the NLME-permit-join-request by the ZigBee end device, the NLME-permit-join-confirm returns a status of INVALID REQUEST.

If the permit duration parameter of the NLME-permit-joining-request is set to 0x00, the NLME sets the MAC PIB attribute, The MAC association permit variable is set to false by issuing the MLME-SET-request. If the permit duration parameter of the NLME -permit-joining-request is set to 0xff, the NLME sets the MAC PIB attribute, The MAC association permit variable is set to true by issuing the MLME-SET-request. If the permit duration parameter of the NLME-permit-joining-request is set to in range of 0x01 to 0xfe, the NLME sets the MAC PIB attribute, MAC association permit to true by issuing the MLME-SET-request, and then the NLME-permit-joining starts a timer to expire after permit duration seconds. If the timer has been set, the NLME will return a status of NLME by issuing the NLME-permit-joining-confirm. If the timer has expired, the NLME-permit-joining will sets MAC association permit to false by issuing the MLME-SET primitive, the flowchart of NLME permit join service is shown in Fig. A-4.

Fig. A-4 flowchart of network permits joining service

A.2.4. NLME-JOIN-Request/Confirm Primitives

These primitive is used to generate a request to join a new network using MAC layer association procedure and report status of joining. If the device is currently joined to a network, the NLME issues a NLME-join-confirm primitive with the status parameter set to invalid request. If the device is not currently joined to a network, the NLME attempts to join the network specified by the PAN ID parameter.

If the rejoin network parameter is false, and Join as router parameter is false, the NLME issues an MLME-associate-request with its coordinator address parameter set to the address of a router in its neighbor table. If the rejoin network parameter is false and Join as router parameter is true, the Device will function as a ZigBee router in the network. If the device is not joined to a network and the rejoin network parameter is equal to true, and then run orphan scan by issuing an MLME-scan-request with the scan type parameter set to indicate an orphan scan. Finally, the NLME will issues the NLME-join-confirm with status is equal to status of MLME-scan-confirm, the flowchart of NLME join service is shown in Fig. A-5.

Fig. A-5 Flowchart of network joining service

A.2.5. NLME-JOIN-Indication Primitives

The primitive is used to inform the next higher layer of ZigBee coordinator or router that a new device has successfully joined it network by association. The primitive is issued by MLME-association-indication MAC layer to inform network layer that a new device has join it network by MAC Layer association.

A.2.6. The Message Flow of Establishing a New Network

The procedure of establishing a network is completed by using NLME- network- formation-request primitive. If the device is ZigBee Coordinator capable and not currently joined to a network, the procedure allows the device to establish a new network. If the device is no ZigBee coordinator capable or currently joined to a network, the procedure is not allows the device to establish a new network. The procedure first performs an energy scan over specified channels by requesting MLME-scan-request with the scan type parameter set to energy detection scan. After the energy detection scan has been completed successfully, the procedure will order the channels according to increasing energy measurement and choose an acceptable channel. And the procedure performs active scan to search other existing ZigBee devices by issuing the MLME-scan-request with the scan type parameter set to active scan. After the active scan has been completed successfully, the procedure will choose a PAN ID according to parameter of primitive or random number that are must not conflict with existing PAN ID. Once a PAN ID is selected, the procedure will select a 16 bit network address equal to 0x0000 and set the MAC short address of PIB attribute in the MAC layer. Once a network is selected, the NLME will begin operation of the new PAN by issuing the MLME-start -request primitive, the flowchart of network formation is shown in Fig. A-6.

Fig. A-6 Message flow chart of establishing a new network

A.2.7. The Message Flow of Joining a Network through Association

The procedure for joining a network using the MAC layer association is first to do network discovery by issuing NLME-network-discovery-request primitive. The NLME -network-discovery-request primitive is to research existing devices in POS by issuing the MLME-scan-request with scan type set to active scan. Once the MLME-scan-request primitive has been completed, the procedure will issue the MLME-scan-confirm to inform result of network layer. The procedure issue the NLME-discovery-confirm primitive to inform application layer of discovery result.

Once the network discovery has been completed, the procedure will join a network according to existing PAN of discovery result by issuing NLME-join -request with the PAN ID of the desired network. If the device is already joined a network, the procedure will terminate the procedure and notify the application layer of the illegal request by issuing the NLME-JOIN-confirm primitive with status parameter set to invalid request. If the device is not already joined a network, the procedure will join the desired network by issued the MLME-associate-request primitive with address parameter. Once the association procedure has been completed, the procedure will get result of association through MLME-associate-confirm. If the device can not join the PAN successfully, the procedure will terminate the procedure by issuing the NLME-join-confirm with the status parameter set to the value returned in the last received MLME- associate-confirm primitive. If the device can join the PAN successfully, the procedure will get a 16 bit logical address through MLME-associate-confirm primitive. Once the device has joined the network successfully and the application layer has issued a NLME- start-router-request primitive to setup its super-frame configuration and begin transmitting beacon frames. The NLME-start-router-request primitive setup its super-frame configuration by issuing the MLME-start-request, the message flow chart of joining a network through association procedure is shown in Fig. A-7.

Fig. A-7 Message flow chart for network discovery.

A.2.8. NLME-LEAVE-Request/Confirm Primitives

The set of primitives define how the next layer of a device can request to leave or request that another device leaves a network if the device is not currently joined to a network, the NLME-leave-confirm primitive with a status of invalid request. If the device is currently joined to a network and with the device address parameter equal to NULL, the NLME issues the MLME-disassociate-request primitive. The NLME issues the NLME-leave-confirm primitive with status equal to status of MLME-disassociate-confirm primitive. And the NLME clear its routing table entries.

If the issuing device is ZigBee coordinator or Router and the device address parameter is not equal to NULL, the NLME searches its neighbor table whether the specified device exists. If the specified device doesn’t exist, the NLME issues the NLME -leave-confirm primitive with a status of unknown device. If the specified device exists, the NLME removes it entry in the neighbor table and issues the MLME -disassociate-request primitive, on receipt of the corresponding MLME-disassociate-confirm primitive, the NLME issues the NLME-leave-confirm primitive with status returned from the MLME -disassociate-confirm primitive, the flowchart of NLME leave service is shown in Fig. A-8.

Fig. A-8 Flowchart for network leave

A.2.9. NLME-LEAVE-Indication Primitive

The primitive is used to inform application layer of coordinator or router of successful exit of one of that device’s associated children from the network. The primitive is also used to inform application layer of router or end device that the device has been successfully removed from the network by its associated router or coordinator.

A.2.10. Child Initiates its own Removal from a Network

If a child device wants to leave the network, the procedure will issues the NLME- leave-request primitive with the device address parameter set to null. If the child device is not joined the network currently, the procedure will terminate the Procedure and issues the NLME-leave-confirm with the status parameter set to invalid request. If the child device is joined the network currently, the procedure will first issues MLME- disassociate-request to send disassociated command to its parent device. The status report of MLME -disassociate-request is communicated back via the MLME-disassociate-confirm primitive. On receipt of the status of the disassociation, the procedure will notify network layer of the disassociation status by issuing the NLME-leave-confirm with the status parameter set to the status value returned in the MLME-disassociate-confirm primitive, the message flow chart for a child to initiate its own removal from a network is shown in Fig. A-9.

Fig. A-9 Message flow chart for a child device to initiate its own removal from a network

A.2.11. Parent Device Handles a Leave Request from its Child

When the parent device receives a disassociation request command, it will issue the MLME-DISASSOCIATE-indication primitive to inform network layer that a child device want to leave its network. When the network layer of parent device receives the Disassociation indication, the NLME will search its neighbor table in order to determine whether a child device can be found. If the child device is not found, the NLME will terminate the procedure. If the child device is found, the NLME will remove the appropriate entry from its neighbor table and inform the network layer that the child device has been removed by issuing the NLME-LEAVE-indication primitive, the message flow chart for parent to handle a leave request from its child is shown in Fig. A-10.

Fig. A-10 Message flow chart for parent to handle a leave request from its child

A.2.12. Parent Device Forces a Child Device Leaves its Network

The procedure for a parent device to remove a child leave its network by issuing the NLME-leave-request primitive with device address parameter set to the address of the device to be removed from the network. If the procedure is initiated on end device, the procedure will terminate the procedure and notify the network layer of the illegal request by issuing the NLME-leave-confirm primitive with the status parameter set to invalid-request. If the procedure is initiated on coordinator or

router, the NLME first search its neighbor table in order to determine whether the specified device can be found. If the specified device is not found, the NLME will terminate the procedure and inform network layer of the unknown device by issuing the NLME-leave-confirm primitive with the status parameter set to unknown device. If the specified device is found, the NLME will remove the appropriate entry from the neighbor table and perform a disassociation procedure.

The status of disassociation procedure is communicated back via the MLME- disassociate -confirm primitive. On receipt of the results from the disassociation procedure, the NLME will inform the network layer of the status of its request to remove the device from the network by issuing the NLME-leave-confirm primitive with the status parameter set to the status returned in the MLME-disassociate-confirm primitive, the message flow for a parent device to force a child device leaves its network is shown in Fig. A-11.

Fig. A-11 Message flow chart for a parent to force a child from its network.

A.2.13. Child Removes itself from a Network at the Request of its Parent

When the child device receives a disassociation command, the NLME will issues the NLME-disassociate-indication to inform the network layer that the child device is forced to leave its

network. The NLME first compare 64 bit extended address with the extended address of disassociation request command. If the two addresses are same, the child device will inform the network layer that it always removed from the network by issuing the NLME-leave-indication. If the two addresses are not the same, the NLME will terminate the procedure, the message flow for a child to remove itself from a network at the request of its parent is shown in Fig. A-12.

Fig. A-12 Message flow chart for a child to remove itself from a network

Appendix B.

To verify correctness of firmware code, the study uses the Chipcon sniffer to capture IEEE 802.14.4 MAC packets.

B.1. PAN Coordinator

B.1.1. Hyper-Terminal

The PAN coordinator is responsible for creating a network and wait for join of routers, it status of test can be seen in hyper-terminal is shown in Fig. B-1.

Fig. B-1 Status of PAN coordinator is shown in hyper-terminal

B.1.2. Frames Measurement

The PAN Coordinator first starts a new network by issuing NLME-NETWORK -FORMATION-request primitive, which broadcasts a beacon request command to all devices in Personal Operating Space (POS). We can see the following packet diagram, the Dest Address represents destination address is equal to 0xffff that representing is to use broadcast way to send the packet. When PAN Coordinator or Router receives the beacon request command, it will broadcast a beacon frame that contains the PAN and device information. The PAN Coordinator can get existing PAN ID to prevent new PAN ID from conflicting with existing PAN ID, Measurement of frames is shown in Fig. B-2.

Fig. B-2 Frames Measurement for PAN coordinator using Chipcon sniffer

B.2. Router

B.2.1. Hyper-terminal

The router is responsible for scheduling sending time of associated device and forwarding data that received from associated devices to PAN Coordinator by using hierarchy routing according its neighbor

The router is responsible for scheduling sending time of associated device and forwarding data that received from associated devices to PAN Coordinator by using hierarchy routing according its neighbor

相關文件