WO2011002177A2 - 지그비 게이트웨이, 이와 ip 네트워크를 통해 연동하는 ip 서비스 서버 - Google Patents

지그비 게이트웨이, 이와 ip 네트워크를 통해 연동하는 ip 서비스 서버 Download PDF

Info

Publication number
WO2011002177A2
WO2011002177A2 PCT/KR2010/004108 KR2010004108W WO2011002177A2 WO 2011002177 A2 WO2011002177 A2 WO 2011002177A2 KR 2010004108 W KR2010004108 W KR 2010004108W WO 2011002177 A2 WO2011002177 A2 WO 2011002177A2
Authority
WO
WIPO (PCT)
Prior art keywords
primitive
zigbee
network
layer module
frame
Prior art date
Application number
PCT/KR2010/004108
Other languages
English (en)
French (fr)
Other versions
WO2011002177A3 (ko
Inventor
김연수
박재우
이우식
정석주
Original Assignee
주식회사 케이티
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 주식회사 케이티 filed Critical 주식회사 케이티
Priority to US13/382,064 priority Critical patent/US20120099579A1/en
Publication of WO2011002177A2 publication Critical patent/WO2011002177A2/ko
Publication of WO2011002177A3 publication Critical patent/WO2011002177A3/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/16—Gateway arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/66—Arrangements for connecting between networks having differing types of switching systems, e.g. gateways
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/18—Information format or content conversion, e.g. adaptation by the network of the transmitted or received information for the purpose of wireless delivery to users or terminals
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/04—Network layer protocols, e.g. mobile IP [Internet Protocol]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/06—Transport layer protocols, e.g. TCP [Transport Control Protocol] over wireless
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W84/00—Network topologies
    • H04W84/18—Self-organising networks, e.g. ad-hoc networks or sensor networks

Definitions

  • the present invention relates to a Zigbee gateway and an IP service server interworking with the Zigbee gateway.
  • Zigbee Network is a low-power, low-speed wireless network with short-range connectivity that enables remote monitoring and control of environments, objects and spaces via sensors, and is suitable for automation, control, monitoring and sensing applications.
  • ZigBee technology is based on the IEEE 802.15.4 standard, which defines a low-power, low-speed air interface for small devices with limited power, central processing units (CPUs), and memory resources. Network and application protocols.
  • the Zigbee Protocol Stack is built on top of the IEEE 802.15.4 wireless standard.
  • the ZigBee standard provides a set of network and application layers to support user applications.
  • the network layer provides mechanisms to join and leave the network and send messages to the appropriate destinations, manage the formation of the Zigbee network and assign addresses to nodes participating in the network.
  • the application layer includes an application framework, an application support sublayer, and a Zigbee device object. Such inter-layer communication is performed by primitives in the upper and lower layers, and by frames in the peer layers.
  • the ZigBee protocol allows two or more ZigBee nodes within the same ZigBee network to communicate with each other.
  • the Zigbee protocol does not provide a mechanism by which Zigbee nodes can communicate with IP nodes in an IP network.
  • the technical problem to be achieved by the present invention relates to a ZigBee gateway that can transmit and receive messages between the IP network and the ZigBee network without format conversion, and to an IP service server interworking with the IP network.
  • Zigbee gateway connected to a Zigbee node and a Zigbee network according to a feature of the present invention for achieving the above object, and connected through an IP service server and an IP network,
  • a primitive transport layer module for extracting first data from a first primitive frame packet transmitted through the IP network at the IP service server, and receiving the first data from the primitive transport layer module, and receiving the first data from the primitive transport layer module. It includes a ZigBee network layer module that forwards to a ZigBee node.
  • a primitive transport layer module for extracting first data from the first primitive frame packet transmitted through the IP network at the Zigbee gateway, and a Zigbee application layer module receiving the first data from the primitive transport layer module.
  • FIG. 1 is a diagram schematically showing a system for interworking between an IP network and a Zigbee network according to an embodiment of the present invention.
  • FIG. 2 is a diagram schematically illustrating a format of a primitive frame packet according to an embodiment of the present invention.
  • FIG. 3 is a diagram schematically illustrating transmission and reception of primitive frame packets according to an embodiment of the present invention.
  • FIG. 4 is a diagram schematically illustrating a procedure of delivering a primitive message according to an embodiment of the present invention.
  • an IP network includes at least one of an IP version 4 (IPv4) network and a subsequent version of an IP network such as an IP version 6 (IPv6) network.
  • IPv4 IP version 4
  • IPv6 IP version 6
  • FIG. 1 is a diagram schematically showing a system for interworking between an IP network and a Zigbee network according to an embodiment of the present invention.
  • a system 1 for interworking between an IP network and a Zigbee network includes a Zigbee node 100 located in a Zigbee network, and a Zigbee network located between an IP network and a Zigbee network. Gateway 200 and IP service server 300 located in the IP network.
  • the Zigbee node 100 includes a ZigBee application layer module 110, a ZigBee network layer module 120, a media access control (MAC) 130, and a physical layer 140 for an application service.
  • the MAC layer 130 and the physical layer 140 may follow the standard of IEEE 802.15.4.
  • the Zigbee Application Layer Module 110 includes a ZigBee Application Framework 111, a ZigBee Application Support Sublayer 112, and a Zigbee Device Object 113. .
  • the ZigBee application framework 111 provides an interface between the ZigBee application support sublayer 112 and the ZigBee device object 113, and implements a logical association between the application objects.
  • the Zigbee Application Support Sublayer 112 provides appropriate application support when a message arrives at the Zigbee Node 100.
  • the Zigbee device object 113 indicates the node type of the device and initiates device and service discovery on the Zigbee network.
  • the ZigBee network layer module 120 provides a mechanism for sending messages to and from the network as appropriate.
  • the ZigBee network layer module 120 also provides a mechanism for device and service discovery.
  • the ZigBee network layer module 120 manages the formation of the ZigBee network and assigns addresses to nodes participating in the network.
  • ZigBee gateway 200 has an interface between the IP network and the ZigBee network, respectively, the primitive transport layer module 210, ZigBee network layer module 220, TCP (UDP) / IP layer module 230, media access control (media) access control (MAC) 240 and physical layer 250.
  • the MAC layer 240 and the physical layer 250 may follow the standard of IEEE 802.15.4.
  • the primitive transport layer module 210 receives primitives and parameters from the ZigBee network layer module 220 and generates primitive frame packets using the received primitives and parameters.
  • the primitive frame packet according to the embodiment of the present invention will be described later with reference to FIG. 2.
  • the primitive transport layer module 210 delivers the generated primitive frame packet to the IP service server 300 through the TCP (UDP) / IP layer module 230. That is, the primitive transport layer module 210 transmits primitives and parameters exchanged between the IP service servers 300 that are separated from each other on the IP network in one primitive frame packet to the IP service server 300.
  • the primitive transport layer module 210 analyzes the delivered primitive frame packet as a primitive frame packet when the primitive frame packet generated corresponding to the primitive and the parameter transmitted from the IP service server 300 is delivered. Before it is generated, it is restored to the original primitives and parameters and transferred to the Zigbee node 100.
  • the Zigbee network layer module 220 receives the primitives and parameters from the Zigbee node 100 and delivers the delivered primitives and parameters to the primitive transport layer module 210.
  • the ZigBee network layer module 220 also provides a mechanism for sending messages to and from the network.
  • ZigBee network layer module 220 provides a mechanism for device and service discovery.
  • the Zigbee Network Layer Module 220 manages the formation of the Zigbee Network and assigns addresses to nodes participating in the network.
  • the TCP (UDP) / IP layer module 230 delivers the primitives and parameters restored in the primitive transport layer module 210 to the Zigbee node 100 or generates corresponding primitives and parameters transmitted from the Zigbee node 100.
  • the primitive frame packet is transmitted to the IP service server 300.
  • the IP service server 300 may include a ZigBee application layer module 310, a primitive transport layer module 320, a TCP (UDP) / IP layer module 330, a media access control (MAC) for application services ( 340 and the physical layer 350.
  • the MAC layer 340 and the physical layer 350 comply with the IEEE 802.15.4 protocol standard.
  • the IP service server 300 operates as an IP service providing apparatus.
  • the Zigbee Application Layer Module 310 includes a Zigbee Application Framework 311, a ZigBee Application Support 312, and a Zigbee Device Object 313. Primitives and parameters for delivery to the Zigbee node 100 is transferred to the primitive transport layer module 320.
  • the functions of the ZigBee application framework 311, the ZigBee application support sublayer 312 and the ZigBee device object 313 is the ZigBee application framework 111 of the ZigBee application layer module 110, the ZigBee application support sublayer ( 112 and the same as the function of the Zigbee device object 113, a detailed description thereof will be omitted.
  • the primitive transport layer module 320 receives the primitives and parameters from the Zigbee Application Layer module 310 and generates a primitive frame packet using the delivered primitives and parameters.
  • the primitive transport layer module 320 delivers the generated primitive frame packet to the Zigbee gateway 200 through the TCP (UDP) / IP layer module 330. That is, the primitive transport layer module 320 transmits primitives and parameters exchanged between ZigBee gateways 200 that are separated from each other on the IP network in one primitive frame packet to the ZigBee gateway 200.
  • the primitive transport layer module 320 analyzes the delivered primitive frame packet and generates it as a primitive frame packet when the primitive frame packet generated corresponding to the primitive and the parameter transmitted from the Zigbee node 100 is delivered. It is restored to the original primitives and parameters before being transferred to the Zigbee application layer module 310.
  • the TCP (UDP) / IP layer module 330 delivers the primitive frame packet delivered from the primitive transport layer module 320 to the Zigbee gateway 200 or transmits the primitive frame packet delivered from the Zigbee Zigbee gateway 200. Transfer to primitive transport layer module 320.
  • the media access control (MAC) layer 340 and the physical layer 350 may conform to the IEEE 802.15.4 protocol standard.
  • ZigBee gateway 200 and IP service server 300 can be connected through a variety of wired and wireless networks, such as Ethernet (Ethernet), WiBro, Wireless Local Area Network (WLAN), data communication through these Each has a network interface for Ethernet, WiBro, WLAN, etc.
  • Ethernet Ethernet
  • WiBro Wireless Local Area Network
  • WLAN Wireless Local Area Network
  • the primitive transport layer module 210 of the Zigbee gateway 200 and the primitive transport layer module 320 of the IP service server 300 have a primitive frame generation function to facilitate communication of the primitive frame packet. , Primitive frame transfer, and primitive frame decomposition.
  • FIG. 2 is a diagram schematically illustrating a format of a primitive frame packet according to an embodiment of the present invention.
  • the primitive frame packet 400 includes a frame header 410 and a frame payload 420.
  • the frame header 410 indicates the type and function of the frame (that is, the content of the frame payload 420) and may have a fixed length.
  • the frame payload 420 carries data and may have a variable length.
  • the frame header 410 includes a protocol type field 411 indicating a protocol used, a service type field 412 indicating a service type provided by a primitive transport layer, and a type of a frame.
  • Frame Type Field 413 to indicate Message Type Field 414 to indicate the type of primitives loaded in the frame, Sequence Number Field 415 to indicate the sequence number of the frame And a length field 416 indicating the length of the payload.
  • the protocol type field 411 indicates one of TCP and UDP
  • the service type field 412 indicates one of a command service, a data service, and a confirmation service.
  • the frame type field 413 indicates a command.
  • the frame type field 413 may include a command for establishing a primitive transport layer connection [ZPTL (ZigBee primitive transport layer) connect], a response command (ZPTL connect response) and a confirmation command (ZPTL connect ack), A command to disconnect the primitive transport layer connection (ZPTL disconnect), a response command to it (ZPTL disconnect response), message data indicating a data frame, and acknowledgment data indicating acknowledgment of data reception.
  • ZPTL ZigBee primitive transport layer
  • the message type field 414 may contain various messages, for example, a network start request message [NLME (network layer management entity) -NETWORK-FORMATION-REQUEST], a network start confirmation message (NLME-NETWORK-FORMATION-CONFIRM).
  • NLME network layer management entity
  • NLME-NETWORK-FORMATION-CONFIRM a network start confirmation message
  • Network entry permission request message (NLME-PERMIT-JOINING-REQUEST), network entry permission confirmation message (NLME-PERMIT-JOINING-CONFIRM), network entry instruction message (NLME-JOIN-INDICATION), network direct entry request message (NLME) -DIRECT-JOIN-REQUEST), network direct join confirmation message (NLME-DIRECT-JOIN-CONFIRM), network exit request message (NLME-LEAVE-REQUEST), network exit confirmation message (NLME-LEAVE-CONFIRM), network exit indication Message (NLME-LEAVE-INDICATION), router start request message (NLME-START-ROUTER-REQUEST), NLME-START-ROUTER-CONFIRM, network layer reset request message (NLME-RESET-REQUEST), network layer reset confirmation Message (NLME-RESET-C ONFIRM), one of 17 messages such as data request message [NLDE (network layer data entity) -DATA-REQUEST], data confirmation message (NLDE-DATA-CONFIRM), data indication message (NLDE-
  • the frame payload 420 includes a payload field 421.
  • Payload field 421 loads a set of parameters that accompany any primitives.
  • the value of each parameter is extended to an integer multiple of one octet so that the length of the payload field 421 can be represented by an integer multiple of one octet. They are loaded in the order that they accompany the primitives. Therefore, 21 parameters are used and have extended length as follows.
  • the parameters (ScanChannels) are set to 32-bit bitmaps, and the parameters (ScanChannels, BeaconOrder, SuperframeOrder, PANID, PermitDuration, ShortAddress, DstAddr, NsduLength, ScrAddr) are set to 16 bits long, DiscoverRoute, SecurityEnable) and the like are set to 8 bits in length as boolean values.
  • the parameter (CapabilityInformation) is set to an 8-bit long bitmap, the parameters (ExtendedAddress, DeviceAddress) are each set to 64 bits long, and the parameters (Status, NsduHandle, BroadcastRadius, LinkQuality, etc.) are set to 8 bits long.
  • NSDU has an octet length expressed by the parameter NsduLength.
  • the primitive frame packet 400 is determined by function and personality.
  • the primitive parameters constituting the primitive frame packet 400 are displayed in the service type field 412 as a data service, the message type corresponding to the primitive is displayed in the message type field 414, and the type of the frame is the frame type field.
  • the parameters indicated at 413 and accompanying the primitives are indicated in the frame payload 420.
  • the length of the payload is related to the length field 416. That is, the random primitive frame packet 400 has the service type field 412 set to "data service”, the frame type field 413 set to "message data”, and the message type field 414 set to primitive data.
  • a length field 416 is set to the length of data loaded in the payload, and the frame payload 420 is generated as a data frame set as a parameter set.
  • the protocol type field 411 is set to one selected as one of TCP / UDP irrespective of the primitive, and the sequence number field 415 is a sequence of sequence numbers according to the order in which frames are generated regardless of the function and nature of the frame to be transmitted. Is set.
  • the primitive frame packet 400 is for acknowledgment of primitive and parameter data reception, the primitive frame packet 400 is indicated in the service type field 412 as an acknowledgment service for acknowledgment, and " data ack " ), There is no semantic or separate payload for the message type field 414. At this time, the payload does not exist separately, but the length thereof corresponds to "length”. Therefore, the frame for acknowledgment has the service type field 412 set to "acknowledgement", the frame type field 413 set to "data ack”, and the message type field 414 set to a meaningless "NULL" value.
  • the length field 416 is set to the length of data loaded in the payload, that is, a value of "0", and the payload field 421 is generated as a frame that does not contain any data.
  • the protocol type field 411 and the sequence number field field 415 are set the same as the data frame.
  • the primitive frame packet 400 When the primitive frame packet 400 provides a command for the primitive transport layer, it is displayed in the service type field 412 as a command service, and the type of command and the nature of the response thereof are displayed in the frame type field 413. There is no meaning for the message type field 414 or a separate payload. At this time, the payload does not exist separately, but the length thereof corresponds to "length".
  • the types of commands and their responses include commands (ZPTL connect, ZPTL connect response, ZPTL connect ack, ZPTL disconnect, and ZPTL disconnect response).
  • the service type field 412 is set to the command service
  • the frame type field 413 is set to the command and response according to the command and response (ZPTL connect, ZPTL connect response, ZPTL connect ack, ZPTL disconnect, and ZPTL disconnect).
  • the message type field 414 is set to a meaningless "NULL" value
  • the length field 416 is set to the length of the data loaded in the payload, i.e. a "0" value.
  • the payload field 421 is generated as a frame that does not contain any data.
  • the relationship between the primitive and the message applied in the embodiment of the present invention corresponds to the NLME-NETWORK-FORMATION.request primitive corresponds to the network formation request message (NLME-NETWORK-FORMATION-REQUES), and the NLME-NETWORK-FORMATION.confirm primitive to form the network.
  • the NLME-PERMIT-JOINING.request primitive corresponds to the connection approval request message (NLME-PERMIT-JOINING-REQUEST), and the NLME-PERMIT-JOINING.confirm primitive
  • the NLME-JOIN.indication primitive corresponds to the network connection completion message (NLME-JOIN-INDICATION)
  • the NLME-DIRECT-JOIN.request primitive In response to the network direct connection request message (NLME-DIRECT-JOIN-REQUEST), the NLME-DIRECT-JOIN.confirm primitive corresponds to the network direct connection completion confirmation message (NLME-DIRECT-JOIN-CONFIRM), and NLME The -LEAVE.request primitive corresponds to the network exit request message (NLME-LEAVE-REQUEST), the NLME-LEAVE.confirm primitive corresponds to the network exit completion confirmation message (NLME-LEAVE-REQUEST), the NLME-LEAVE.confirm primitive corresponds to the network exit completion confirmation message (NLME-LEAVE-REQUEST), the
  • the primitives of the primitive frame packet 400 according to the embodiment of the present invention are accompanied by different types of? -Related parameters, and the relationship is as follows. That is, the MEIF (NLME-NETWORK-FORMATION.request) indicating the network formation request by the management entity of the Zigbee Network Layer Module 120 of the Zigbee Node 100 may include parameters (ScanChannels, ScanDuration, BeaconOrder, SuperfameOrder, PANID, BatteryLifeExtension, etc.). Accompany).
  • the primitive (NLME-NETWORK-FORMATION.confirm) indicating the confirmation of the completion of network formation to the management entity of the Zigbee network layer module 120 is accompanied by a parameter (Status), and by the management entity of the Zigbee network layer module 120.
  • a primitive (NLME-PERMIT-JOINING.request) indicating a request for connection approval is accompanied by a parameter (PermitDuration), and a primitive (NLME-PERMIT) indicating confirmation of a connection approval request by a management entity of the Zigbee network layer module 120.
  • JOINING.confirm) is accompanied by a parameter (Status).
  • the primitive (NLME-JOIN.indication) indicating a notification of network connection completion for the management entity of the Zigbee network layer module 120 is accompanied by parameters (ShortAddress, Extended Address, CapabilityInformation, etc.), and the Zigbee network layer module 120
  • a primitive (NLME-DIRECT-JOIN.request) indicating a request for a network direct connection by a management entity of A is accompanied by parameters (DeviceAddress, CapabilityInformation, etc.), and a request for a network direct connection request to the management entity of the Zigbee network layer module 120.
  • the primitive indicating the confirmation of completion (NLME-DIRECT-JOIN.confirm) is accompanied by parameters (DeviceAddress and Status).
  • a primitive (NLME-LEAVE.request) indicating a request for leaving of a network by a management entity of the Zigbee network layer module 120 is accompanied by a parameter (DeviceAddress), and a network departure of the management entity of the Zigbee network layer module 120 is included.
  • the primitive (NLME-LEAVE.confirm) indicating confirmation of completion is accompanied by parameters (DeviceAddress and Status).
  • a primitive (NLME-LEAVE.indication) indicating a notification of network departure to the management entity of the Zigbee network layer module 120 is accompanied by a parameter (DeviceAddress), and the router role starts by the management entity of the Zigbee network layer module 120.
  • the primitive indicating the request of NLME-START-ROUTER.request is accompanied by parameters (such as BeaconOrder, SuperframeOrder and BatteryLifeExtension).
  • a primitive (NLME-START-ROUTER.confirm) indicating the confirmation of the initiation of the router role to the management entity of the Zigbee network layer module 120 is accompanied by a parameter (Status) and attached to the management entity of the Zigbee network layer module 120.
  • the primitive (NLME-RESET.request) indicating the request for initialization of network settings by the terminal does not have an associated parameter
  • the primitive (NLME-RESET.confirm) indicating confirmation of completion of initialization of the network settings is accompanied by a parameter (Status). do.
  • the primitive (NLDE-DATA.request) indicating a data transfer request by the data entity of the Zigbee network layer module 120 is accompanied by parameters (DstAddr, NsduLength, Nsdu, NsduHandle, BroadcastRadius, DiscoverRoute, and SecurityEnable).
  • the primitive (NLDE-DATA.confirm) indicating the confirmation of completion of the data transfer requested to the data entity of the module 120 is accompanied by parameters (such as NsduHandle and Status) and sent to the data entity of the Zigbee network layer module 120.
  • the primitive (NLDE-DATA.indication) indicating the notification of the reception of data is accompanied by parameters (ScrAddr, NsduLength, Nsdu and LinkQuality, etc.).
  • ScrAddr the number of bits in the reception of data
  • NsduLength the number of bits in the reception of data
  • Nsdu and LinkQuality the number of bits in the reception of data.
  • the command frame and its response frame are generated at different times than the data frame and the confirmation frame.
  • the command frame (ZPTL connect) is when the primitive (NLME-NETWORK-FORMATION.request) is received, and the response frame (ZPTL connect response) is received when the command frame (ZPTL connect) is received without error.
  • the response frame ZPTL disconnect response is generated when the command frame ZPTL disconnect is received without error.
  • the primitive frame packet 400 includes a ZigBee gateway 200 so that primitive frames for data, commands, and the like can be reliably notified to the ZigBee application layer module 110 and the ZigBee network layer module 120 of the ZigBee node 100. It is transmitted and received between the primitive transport layer module 210 of) and the primitive transport layer module 320 of the IP service server (300).
  • the generated primitive frame packet 400 such as a data frame, a command frame, an acknowledgment frame, and the like are carried in an IP packet on an IP network and transmitted to an equivalent layer of the Zigbee node 100.
  • the primitive transport layer module 210 and the primitive transport layer module 320 transmit the source port number and IP address, the destination port number and the IP address to the corresponding TCP (UDP) / IP layer together with the frame.
  • the source port number and the IP address, the destination port number and the IP address are known in advance to the IP service server 300 and the Zigbee gateway 200, respectively.
  • FIG. 3 is a diagram schematically illustrating transmission and reception of primitive frame packets according to an embodiment of the present invention.
  • the primitive transport layer module 210 of the Zigbee gateway 200 and the primitive transport layer module 320 of the IP service server 300 may receive the received primitive frame packet ( follows the communication procedure caused by 400).
  • the primitive transport layer module 210 of the IP service server 300 receives an arbitrary primitive excluding the primitive (NLME-NETWORK-FORMATION.request) from the Zigbee application layer module 310 (S500). In addition, the primitive transport layer module 210 transmits the primitive frame packet 400 generated in response to an arbitrary primitive to the primitive transport layer module 210 of the Zigbee gateway 200 (S501).
  • the primitive transport layer module 210 is the primitive (NLME-NETWORK-FORMATION).
  • request frame ZPTL connect
  • ZPTL connect to the primitive transport layer module 210 of the Zigbee gateway 200 to establish a connection between the primitive transport layers before forwarding the generated data primitive frame packet 400 in response to.
  • the primitive transport layer module 210 of the Zigbee gateway 200 transmits a response frame (ZPTL connect response) to the primitive transport layer module 320 of the IP service server 300 (S504).
  • ZPTL connect response a response frame
  • the primitive transport layer module 320 of the IP service server 300 transmits a response frame (ZPTL connect ack) corresponding to the response frame (ZPTL connect response) to the primitive transport layer module 210 (S505). Subsequently, the primitive transport layer module 320 transmits the message data generated corresponding to the primitive (NLME-NETWORK-FORMATION.request) to the primitive transport layer module 210 (S506). Then, the primitive transport layer module 210 transmits the primitive (NLME-NETWORK-FORMATION.request) to the Zigbee network layer module 220 (S507).
  • the primitive transport layer module 210 of the Zigbee gateway 200 transmits acknowledgment data (Data Ack) corresponding to the message data to the primitive transport layer module 320 of the IP service server 300 (S508). Then, the primitive transport layer module 320 of the IP service server 300 waits to receive another frame or primitive while maintaining an active state of the primitive transport layer connection without performing a separate operation.
  • Data Ack acknowledgment data
  • Embodiments of the present invention use parameters for reliable delivery of data frames.
  • One is a parameter (T_Max_Wait_Ack) indicating a maximum reception wait time and is for a maximum reception wait allowed for receiving a response frame after transmitting a data frame, and the maximum reception wait time may be measured by a separate timer.
  • N_Max_Retrans indicating the maximum number of retransmissions
  • N_Max_Retrans indicating the maximum number of retransmissions
  • the sending side which has sent any data frame waits for an acknowledgment frame in response to the parameter T_Max_Wait_Ack using a timer. If no acknowledgment frame is received within the waiting time, the transmitting side retransmits the data frame. This retransmission is repeated with the number of parameters N_Max_Retrans until receiving a confirmation frame from the receiving side.
  • the primitive transport layer module 210 of the ZigBee gateway 200 analyzes the primitive frame packet 400 when reception of the primitive frame packet 400 is completed. That is, the primitive transport layer module 210 analyzes the primitive frame packet 400 and reconstructs the primitive frame layer 400 into primitives and related parameters in a form that can be identified and processed by the ZigBee application layer module 110 and the ZigBee network layer module 120. .
  • primitive transport layer module 210 decomposes its frame header 410 to identify the received primitive frame packet 400. At this time, since the frame header 410 is a series of binary data strings, each field constituting the frame header cannot be immediately identified. Thus, the primitive transport layer module 210 checks the field values for each segment so that the datasteering is divided into segments by the length of the configuration field of each frame header 410.
  • the first segment is the protocol type field 411 and all have the same value.
  • the second to fourth segments are the service type field 412, the frame type field 413, and the message type field 414, respectively, which may have different values according to the frame and provide information for uniquely identifying the frame. do.
  • the service type field 412 identifies that the received frame is for one of a command service, a data service, or an acknowledgment service according to the confirmed value
  • the frame type field 413 indicates one of the commands according to the confirmed value.
  • message type field 414 is identified for sending one of the messages according to the identified value.
  • the fifth segment is the sequence number field 415 and is identified as the sequence number of the received frame and used as the sequence number of the response frame.
  • the sixth segment is the length field 416, which provides the length of the payload of the received frame.
  • the sixth segment, the length field 416 is "NULL". Since the received frame does not have any payload, it does not require disassembly of the payload. On the other hand, if the value of the message type field 414 is not "00000000", the sixth segment length field 416 has a bit string other than "NULL". This means that the received frame is identified as sending a related parameter as a primitive message, which means that decomposition of the payload is necessary for the reconstruction of the parameter.
  • the decomposition decision on the payload of the received frame is determined by the value of the length field 416.
  • the value of the message type field 414 is a 32-bit long parameter (ScanChannels) as a related parameter in the payload field 421 of the received frame.
  • ScanDuration 16-bit long parameter
  • BeaconOrder 16-bit long parameter
  • SuperfameOrder 16-bit long parameter
  • PANID 16-bit long parameter
  • 8-bit long parameter Able to know. If the header decomposition is sequentially decomposed for the remaining datastrings, six segments divided into one 32-bit segment, four 16-bit segments, and one 8-bit segment are obtained.
  • the value of the parameter (ScanChannels) from the first segment the value of the parameter (ScanDuration) from the second segment, the value of the parameter (BeaconOrder) from the third segment, the value of the parameter (SuperfameOrder) from the fourth segment, and the fifth
  • the value of the parameter (PANID) is derived from the segment
  • the value of the parameter (BatteryLifeExtension) is derived from the sixth segment.
  • Frames with values of other message type fields 414 may also be resolved in the same manner through the application of the type and order of parameters corresponding to the identified primitives and the length of each parameter. However, a separate payload decomposition process is not performed for a received frame whose value of the message type field 414 is a primitive (NLME-RESET-REQUEST) because its associated parameter is not used.
  • the reconstruction of primitives and related parameters is a process of restoring primitives and related parameters in a form that can be identified and processed by the ZigBee application layer module 110 and the ZigBee network layer module 120 of the ZigBee node 100. Based on the result of decomposing the included primitive frame packet 400.
  • FIG. 4 is a diagram schematically illustrating a procedure of delivering a primitive message according to an embodiment of the present invention.
  • the primitive transport layer module 320 of the IP service server 300 is a primitive (NLDE-DATA.request, DstAddr, NsduLength, Nsdu, NsduHandle, BroadcastRadius, DiscoverRoute) , SecurityEnable) is received from the Zigbee application layer module 310 (S600).
  • the primitive transport layer module 320 generates a primitive frame packet 400 corresponding to the primitive NLDE-DATA.request and transmits the primitive transport layer module 210 to the primitive transport layer module 210 of the Zigbee gateway 200 (S601).
  • the primitive frame packet 400 is transmitted from the primitive transport layer module 320 to the TCP (UDP) / IP layer module 330, and the TCP (UDP) / IP layer module 230 of the Zigbee gateway 200 as an IP packet. It is transmitted to the primitive transport layer module 210 through the).
  • the primitive NLDE-DATA.request is accompanied by a related parameter and corresponds to the message NLDE-DATA-REQUEST, so the frame header 410 of the generated primitive frame packet 400 is the value of the protocol type field 411.
  • "UDP”, "data service” as the value of the service type field 412, "message data” as the value of the frame type field 413, the value of the message type field 414 "NLDE-DATA-REQUEST" is indicated, "Previous sequence number + 1" is indicated by the value of the sequence number field 415, and "68 octets" is indicated by the value of the length field 416.
  • the frame payload 420 is composed of related parameters accompanying the primitive (NLDE-DATA.request) as the value of the payload field 421, with two octets of the perturbation parameter DstAddr and two parameters NsduLength.
  • the primitive frame packet is concatenated with one octet, two octets of parameter (Nsdu), one octet of parameter (NsduHandle), one octet of parameter (BroadcastRadius), one octet of parameter (DiscoverRoute), and one octet of parameter (SecurityEnable).
  • the parameter NSDU is assumed to be 60 octets long.
  • the primitive transport layer module 210 of the Zigbee gateway 200 analyzes the received primitive frame packet 400. Since the first seven octets of the data string of the primitive frame packet 400 are the frame header 410 consisting of six fields 411-416, the primitive transport layer module 210 is the first in the data string of the primitive frame packet 400. Split the part into five one-octet segments and one two-octet segment.
  • the primitive transport layer module 210 may have “UDP” as the value of the protocol type field 411 sequentially identified from each segment, “data service” as the value of the service type field 412, and the frame type field ( 413), “message data”, message type field 414, "NLDE-DATA-REQUEST", sequence number field 415, "previous sequence number + 1", length field 416 Detects an attribute value of "68 octets" as the value.
  • the primitive transport layer module 210 sequentially processes the remaining portions of the data strings of the primitive frame packet 400. It is divided into two 2 octet segments, 60 octet segments, and four 1 octet segments. That is, the primitive transport layer module 210 sequentially detects each attribute value of the parameters DstAddr, NsduLength, Nsdu, NsduHandle, BroadcastRadius, DiscoverRoute, and SecurityEnable.
  • the primitive transport layer module 210 Reconfigures the message NLDE-DATA-REQUEST in the same form as that transmitted from the Zigbee application layer module 310 of the IP service server 300 and transmits it to the Zigbee network layer module 220 (S602).
  • the primitive transport layer module 210 transmits acknowledgment data (Data Ack) to the TCP (UDP) / IP layer module (IP) of the IP service server 300 as an IP packet through the TCP (UDP) / IP layer module 230.
  • the TCP (UDP) / IP layer module 330 transmits the data Ack to the primitive transport layer module 320 (S603).
  • the IP service server 300 when the IP service server 300 generates a primitive frame packet 400 corresponding to the primitive (NLDE-DATA.confirm) from the Zigbee gateway 200 and delivers the IP packet to the IP packet, the primitive transport of the Zigbee gateway 200 is performed.
  • the primitive frame packet 400 is analyzed and reconstructed in the same manner as the layer module 210 performs (S604-S606).
  • the system for interworking between the IP network and the Zigbee network is an IP service server in which the Zigbee Application Layer Module 310 and the Zigbee Network Layer Module 220 are separated from each other. Since it is located in the ZigBee gateway 200 having an IP network interface with the 300, a unique communication procedure can be maintained, and primitives and related parameters exchanged between the IP service server 300 and the ZigBee gateway 200 are included.
  • a separate primitive frame packet 400 is delivered to both systems by TCP / IP packets according to a reliable communication procedure so that the IP service server 300 on one side of the IP network is Zigbee on the Zigbee network on the other side of the IP network.
  • the node 100 may directly communicate with the Zigbee application layer message.
  • application profile and interworking gateway for interworking between the IP network and the Zigbee network, it can be applied to various Zigbee applications, and direct access and data to a specific Zigbee node 100 Since the acquisition is easy, the complexity of the Zigbee gateway 200 can be reduced.
  • the embodiments of the present invention described above are not only implemented through the apparatus and the method, but may be implemented through a program for realizing a function corresponding to the configuration of the embodiments of the present invention or a recording medium on which the program is recorded.
  • the ZigBee application layer module and the ZigBee network layer module which are separated from each other, are placed in a ZigBee gateway having an IP network interface and a service server between the IP networks, respectively, so that the original communication procedure can be used as it is. Can be.
  • the service server since the primitives and related parameters exchanged between layers through the primitive transport layer module are generated as one primitive frame packet and transmitted according to the TCP / IP packet, the service server transmits the Zigbee application layer to the Zigbee node on the other side of the IP network. By passing the message as it is, it can provide the interworking between the efficient IP network and the Zigbee network.
  • a ZigBee application layer module and a ZigBee network layer module which are separated from each other, are located in a ZigBee gateway having a service server and an IP network interface interposed therebetween. And it is easy to acquire data, and the application server can manage the ZigBee network's own management function completely to support various ZigBee applications based on IP network such as real-time monitoring and remote control.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

지그비 노드와 지그비 네트워크로 연결되어 있으며, IP 서비스 서버와 IP 네트워크를 통해 연결되어 있는 지그비 게이트웨이는 프리미티브 수송 계층 모듈 및 지그비 네트워크 계층 모듈을 포함한다. 지그비 게이트웨이의 프리미티브 수송 계층 모듈은 IP 서비스 서버에서 IP 네트워크를 통해 전달된 제1 프리미티브 프레임 패킷에서 제1 데이터를 추출한다. 지그비 네트워크 계층 모듈은 프리미티브 수송 계층 모듈로부터 제1 데이터를 전달받으며, 제1 데이터를 지그비 노드로 전달한다. 지그비 게이트웨이와 IP 네트워크를 통해 연동하는 IP 서비스 서버는 프리미티브 수송 계층 모듈 및 지그비 응용계층 모듈을 포함한다. IP 서비스 서버의 프리미티브 수송 계층 모듈은 지그비 게이트웨이에서 IP 네트워크를 통해 전달된 제1 프리미티브 프레임 패킷에서 제1 데이터를 추출한다. 지그비 응용계층 모듈은 프리미티브 수송 계층 모듈로부터 제1 데이터를 전달받는다.

Description

지그비 게이트웨이, 이와 IP 네트워크를 통해 연동하는 IP 서비스 서버
본 발명은 지그비 게이트웨이, 이와 IP 네트워크를 통해 연동하는 IP 서비스 서버에 관한 것이다.
지그비 네트워크는 센서를 통해 환경, 사물, 공간 등에 대한 원격 모니터링 및 제어가 가능한 단거리 연결성을 가진 저전력, 저속의 무선네트워크이며, 자동화, 제어, 모니터링 및 센싱 응용에 적합하다. 지그비 기술은 제한된 전력, CPU(Central Processing Unit) 및 메모리 자원을 가진 소형 디바이스를 위한 저전력, 저속의 무선 인터페이스를 정의하는 IEEE 802.15.4 표준을 바탕으로 하며, 지그비 디바이스간 네트워킹을 가능하게 하는 일단의 네트워크 및 응용 프로토콜을 포함한다.
지그비 프로토콜 스택은 IEEE 802.15.4 무선통신 표준 위에 탑재된다. 지그비 표준은 사용자 응용을 지원하기 위해 일단의 네트워크 계층과 응용계층을 제공한다. 네트워크 계층은 네트워크에 참여하고 이탈하고 메시지를 적절한 종착지로 전송하는 메카니즘을 제공하며, 지그비 네트워크의 형성을 관리하고 네트워크에 참여하는 노드에 대해 주소를 할당한다. 응용계층은 응용프레임워크, 응용지원 부계층, 지그비 디바이스객체를 포함한다. 이러한 계층간 통신은 상하위 계층의 경우 프리미티브에 의해 이루어지며, 동등계층간의 경우 프레임에 의해서 이루어진다.
이처럼 지그비 프로토콜은 동일한 지그비 네트워크 내에 있는 2개 또는 그 이상의 지그비 노드가 서로 통신할 수 있게 해준다. 그러나, 지그비 프로토콜은 지그비 노드가 IP 네트워크에 있는 IP 노드와 통신할 수 있는 메카니즘을 제공하지 않는다.
따라서, IP 네트워크에 있는 IP 노드와 지그비 노드 사이에 효율적인 통신을 지원하는 게이트웨이에 의한 연동방법이 필요하다.
본 발명이 이루고자 하는 기술적 과제는 포멧의 변환 없이 IP 네트워크와 지그비 네트워크 사이에서 메시지를 송수신할 수 있는 지그비 게이트웨이, 이와 IP 네트워크를 통해 연동하는 IP 서비스 서버에 관한 것이다.
상기한 목적을 달성하기 위한 본 발명의 특징에 따른 지그비 노드와 지그비 네트워크로 연결되어 있으며, IP 서비스 서버와 IP 네트워크를 통해 연결되어 있는 지그비 게이트웨이에 있어서,
상기 IP 서비스 서버에서 상기 IP 네트워크를 통해 전달된 제1 프리미티브 프레임 패킷에서 제1 데이터를 추출하는 프리미티브 수송 계층 모듈, 그리고 상기 프리미티브 수송 계층 모듈로부터 상기 제1 데이터를 전달받으며, 상기 제1 데이터를 상기 지그비 노드로 전달하는 지그비 네트워크 계층 모듈을 포함한다.
또한, 본 발명의 다른 특징에 따른 지그비 게이트웨이와 IP 네트워크를 통해 연동하는 IP 서비스 서버에 있어서,
상기 지그비 게이트웨이에서 상기 IP 네트워크를 통해 전달된 제1 프리미티브 프레임 패킷에서 제1 데이터를 추출하는 프리미티브 수송 계층 모듈, 그리고 상기 프리미티브 수송 계층 모듈로부터 상기 제1 데이터를 전달받는 지그비 응용계층 모듈을 포함한다.
도 1은 본 발명의 실시예에 따른 IP 네트워크와 지그비 네트워크간의 연동을 위한 시스템을 개략적으로 나타내는 도면이다.
도 2는 본 발명의 실시예에 따른 프리미티브 프레임 패킷의 포맷을 개략적으로 나타내는 도면이다.
도 3은 본 발명의 실시예에 따른 프리미티브 프레임 패킷의 송수신을 개략적으로 나타내는 도면이다.
도 4는 본 발명의 실시예에 따른 프리미티브 메시지의 전달절차를 개략적으로 도시한 도면이다.
아래에서는 첨부한 도면을 참고로 하여 본 발명의 실시 예에 대하여 본 발명이 속하는 기술 분야에서 통상의 지식을 가진 자가 용이하게 실시할 수 있도록 상세히 설명한다. 그러나 본 발명은 여러 가지 상이한 형태로 구현될 수 있으며 여기에서 설명하는 실시 예에 한정되지 않는다. 그리고 도면에서 본 발명을 명확하게 설명하기 위해서 설명과 관계없는 부분은 생략하였으며, 명세서 전체를 통하여 유사한 부분에 대해서는 유사한 도면 부호를 붙였다.
명세서 전체에서, 어떤 부분이 어떤 구성요소를 "포함"한다고 할 때, 이는 특별히 반대되는 기재가 없는 한 다른 구성요소를 제외하는 것이 아니라 다른 구성요소를 더 포함할 수 있는 것을 의미한다. 또한 명세서 전체에서 IP 네트워크는 IP 버전 4(internet protocol version 4, IPv4) 네트워크, 그리고 IP 버전 6(internet protocol version 6, IPv6) 네트워크 등의 후속 버전의 IP 네트워크 중 적어도 하나의 네트워크를 포함한다.
도 1은 본 발명의 실시예에 따른 IP 네트워크와 지그비 네트워크간의 연동을 위한 시스템을 개략적으로 나타내는 도면이다.
도 1에 도시한 바와 같이, 본 발명의 실시예에 따른 IP 네트워크와 지그비 네트워크간의 연동을 위한 시스템(1)은 지그비 네트워크에 위치하는 지그비 노드(100), IP 네트워크와 지그비 네트워크 사이에 위치하는 지그비 게이트웨이(200) 및 IP 네트워크에 위치하는 IP 서비스 서버(300)를 포함한다.
지그비 노드(100)는 응용서비스를 위한 지그비 응용계층 모듈(110), 지그비 네트워크 계층 모듈(120), 미디어 접근 제어(media access control, MAC)(130) 및 물리계층(140)을 포함한다. MAC 계층(130)과 물리 계층(140)은 IEEE 802.15.4의 규격을 따를 수 있다.
지그비 응용계층 모듈(110)은 지그비 응용프레임워크(ZigBee Application Framework)(111), 지그비 응용지원 부계층(ZigBee Application Support Sublayer)(112) 및 지그비 디바이스객체(Zigbee Device Object)(113)를 포함한다. 지그비 응용프레임워크(111)은 지그비 응용지원 부계층(112)과 지그비 디바이스객체(113)사이의 인터페이스를 제공하며, 응용객체 사이의 논리적인 연관을 구현한다. 지그비 응용지원 부계층(112)은 메시지가 지그비 노드(100)에 도착할 때 적절한 응용지원을 제공한다. 지그비 디바이스객체(113)는 디바이스의 노드 종류를 나타내며, 지그비 네트워크 상에서 디바이스 및 서비스 디스커버리를 개시한다.
지그비 네트워크 계층 모듈(120)은 네트워크에 참여 및 이탈하는 메시지를 적절한 종착지로 전송하는 메카니즘을 제공한다. 그리고 지그비 네트워크 계층 모듈(120)은 디바이스 및 서비스 발견을 위한 메카니즘을 제공한다. 지그비 네트워크 계층 모듈(120)은 지그비 네트워크의 형성을 관리하고 네트워크에 참여하는 노드에 대해 주소를 할당한다.
지그비 게이트웨이(200)는 IP 네트워크와 지그비 네트워크의 인터페이스를 각각 가지며, 프리미티브 수송계층 모듈(210), 지그비 네트워크 계층 모듈(220), TCP(UDP)/IP 계층 모듈(230), 미디어 접근 제어(media access control, MAC)(240) 및 물리계층(250)을 포함한다. MAC 계층(240)과 물리 계층(250)은 IEEE 802.15.4의 규격을 따를 수 있다.
프리미티브 수송계층 모듈(210)은 지그비 네트워크 계층 모듈(220)로부터 프리미티브와 파라미터를 전달받으며, 수신된 프리미티브와 파라미터를 이용하여 프리미티브 프레임 패킷을 생성한다. 본 발명의 실시예에 따른 프리미티브 프레임 패킷은 도 2에서 후술한다. 프리미티브 수송계층 모듈(210)은 생성된 프리미티브 프레임 패킷을 TCP(UDP)/IP 계층 모듈(230)을 통해 IP 서비스 서버(300)로 전달한다. 즉, 프리미티브 수송계층 모듈(210)은 IP 네트워크상에서 서로 떨어져 있는 IP 서비스 서버(300) 사이에서 교환되는 프리미티브와 파라미터를 하나의 프리미티브 프레임 패킷으로 IP 서비스 서버(300)로 전달한다. 또한, 프리미티브 수송계층 모듈(210)은 IP 서비스 서버(300)로부터 전달된 프리미티브와 파라미터에 대응하여 생성된 프레미티브 프레임 패킷이 전달되는 경우, 전달된 프레미티브 프레임 패킷을 분석하여 프레미티브 프레임 패킷으로 생성되기 전 원래 프리미티브와 파라미터로 복원하여 지그비 노드(100)로 전달한다.
지그비 네트워크 계층 모듈(220)은 지그비 노드(100)로부터 프리미티브와 파라미터를 전달받으며, 전달된 프리미티브와 파라미터를 프리미티브 수송계층 모듈(210)로 전달한다. 그리고, 지그비 네트워크 계층 모듈(220)은 네트워크에 참여 및 이탈하는 메시지를 적절한 종착지로 전송하는 메카니즘을 제공한다. 지그비 네트워크 계층 모듈(220)은 디바이스 및 서비스 발견을 위한 메카니즘을 제공한다. 지그비 네트워크 계층 모듈(220)은 지그비 네트워크의 형성을 관리하고 네트워크에 참여하는 노드에 대해 주소를 할당한다.
TCP(UDP)/IP 계층 모듈(230)은 프리미티브 수송계층 모듈(210)에서 복원된 프리미티브와 파라미터를 지그비 노드(100)로 전달하거나 또는 지그비 노드(100)로부터 전달되는 프리미티브와 파라미터에 대응하여 생성되는 프리미티브 프레임 패킷을 IP 서비스 서버(300)로 전달한다. IP 서비스 서버(300)는 응용서비스를 위한 지그비 응용계층 모듈(310), 프리미티브 수송계층 모듈(320), TCP(UDP)/IP 계층 모듈(330), 미디어 접근 제어(media access control, MAC)(340) 및 물리계층(350)을 포함한다. 맥계층(340) 및 물리계층(350)은 IEEE 802.15.4 프로토콜 규격을 따른다. 이러한 IP 서비스 서버(300)는 IP 서비스 제공 장치로 동작한다.
지그비 응용계층 모듈(310)은 지그비 응용프레임워크(Zigbee Application Framework)(311), 지그비 응용지원 부계층(ZigBee Application Support)(312) 및 지그비 디바이스객체(Zigbee Device Object)(313)를 포함하며, 지그비 노드(100)로 전달하기 위한 프리미티브와 파라미터를 프리미티브 수송계층 모듈(320)로 전달한다. 여기서, 지그비 응용프레임워크(311), 지그비 응용지원 부계층(312) 및 지그비 디바이스객체(313)의 기능은 지그비 응용계층 모듈(110)의 지그비 응용프레임워크(111), 지그비 응용지원 부계층(112) 및 지그비 디바이스객체(113)의 기능과 동일하므로 구체적인 설명은 생략한다.
프리미티브 수송계층 모듈(320)은 지그비 응용계층 모듈(310)로부터 프리미티브와 파라미터를 전달받으며, 전달된 프리미티브와 파라미터를 이용하여 프리미티브 프레임 패킷을 생성한다. 프리미티브 수송계층 모듈(320)은 생성된 프레미티브 프레임 패킷을 TCP(UDP)/IP 계층 모듈(330)을 통해 지그비 게이트웨이(200)로 전달한다. 즉, 프리미티브 수송계층 모듈(320)은 IP 네트워크상에서 서로 떨어져 있는 지그비 게이트웨이(200) 사이에서 교환되는 프리미티브와 파라미터를 하나의 프리미티브 프레임 패킷으로 지그비 게이트웨이(200)로 전달한다. 또한, 프리미티브 수송계층 모듈(320)은 지그비 노드(100)로부터 전달된 프리미티브와 파라미터에 대응하여 생성된 프레미티브 프레임 패킷이 전달되는 경우, 전달된 프레미티브 프레임 패킷을 분석하여 프레미티브 프레임 패킷으로 생성되기 전 원래 프리미티브와 파라미터로 복원하여 지그비 응용계층 모듈(310)로 전달한다.
TCP(UDP)/IP 계층 모듈(330)은 프리미티브 수송계층 모듈(320)에서 전달되는프레미티브 프레임 패킷을 지그비 게이트웨이(200)로 전달하거나 또는 지그비 지그비 게이트웨이(200)로부터 전달되는 프레미티브 프레임 패킷을 프리미티브 수송계층 모듈(320)로 전달한다.
미디어 접근 제어(media access control, MAC) 계층(340) 및 물리계층(350)은 IEEE 802.15.4 프로토콜 규격을 따를 수 있다.
본 발명의 실시예에 따른 지그비 게이트웨이(200) 및 IP 서비스 서버(300)는 이더넷(Ethernet), 와이브로, WLAN(Wireless Local Area Network) 등 다양한 유무선 네트워크를 통해 연결이 가능하며, 이들을 통한 데이터 통신을 위한 이더넷, 와이브로, WLAN 등을 위한 네트워크 인터페이스를 각각 가지고 있다.
본 발명의 실시예에 따른 지그비 게이트웨이(200)의 프리미티브 수송계층 모듈(210)과 IP 서비스 서버(300)의 프리미티브 수송계층 모듈(320)은 프리미티브 프레임 패킷의 통신을 용이하게 하기 위해 프리미티브 프레임 생성기능, 프리미티브 프레임 전달기능, 프리미티브 프레임 분해기능을 갖는다.
도 2는 본 발명의 실시예에 따른 프리미티브 프레임 패킷의 포맷을 개략적으로 나타내는 도면이다.
도 2에 도시한 바와 같이, 본 발명의 실시예에 따른 프리미티브 프레임 패킷(400)은 프레임 헤더(410) 및 프레임 페이로드(420)를 포함한다. 프레임 헤더(410)는 프레임의 종류와 기능[즉, 프레임 페이로드(420)의 내용]을 표시하며, 고정 길이를 가질 수 있다. 프레임 페이로드(420)는 데이터를 실으며, 가변 길이를 가질 수 있다.
프레임 헤더(410)는 사용되는 프로토콜을 나타내는 프로토콜 타입 필드(Protocol Type Field)(411), 프리미티브 수송계층에 의해 제공되는 서비스 유형을 나타내는 서비스 타입 필드(Service Type Field)(412), 프레임의 종류를 나타내는 프레임 타입 필드(Frame Type Field)(413), 프레임에 적재되는 프리미티브의 종류를 나타내는 메시지 타입 필드(Message Type Field)(414), 프레임의 순서번호를 나타내는 시퀀스 넘버 필드(Sequence Number Field)(415) 및 페이로드의 길이를 나타내는 길이 필드(length Field)(416)를 포함한다.
프로토콜 타입 필드(411)는 TCP 및 UDP 중 하나를 표시하며, 서비스 타입 필드(412)는 명령 서비스(Command Service), 데이터 서비스, 확인 서비스 중 하나를 표시한다. 프레임 타입 필드(413)는 명령어를 표시한다. 예를 들어, 프레임 타입 필드(413)는 프리미티브 수송계층 연결의 설정을 명령하는 명령어[ZPTL(ZigBee primitive transport layer) connect], 이에 대한 응답 명령어(ZPTL connect response)와 확인 명령어(ZPTL connect ack), 프리미티브 수송계층 연결의 절단을 명령하는 명령어(ZPTL disconnect), 이에 대한 응답 명령어(ZPTL disconnect response), 데이터 프레임을 나타내는 메시지 데이터(Message Data), 그리고 데이터 수신에 대한 확인을 나타내는 확인 데이터(Data Ack) 중 하나를 표시할 수 있다. 메시지 타입 필드(414)는 프리미티브의 종류를 표시한다. 예를 들어, 메시지 타입 필드(414)는 다양한 메시지, 예를 들면 네트워크 기동 요청 메시지[NLME(network layer management entity)-NETWORK-FORMATION-REQUEST], 네트워크 기동 확인 메시지(NLME-NETWORK-FORMATION-CONFIRM), 네트워크 참가 허가 요청 메시지(NLME-PERMIT-JOINING-REQUEST),　네트워크 참가 허가 확인 메시지(NLME-PERMIT-JOINING-CONFIRM), 네트워크 참가 지시 메시지(NLME-JOIN-INDICATION), 네트워크 직접 참가 요청 메시지(NLME-DIRECT-JOIN-REQUEST), 네트워크 직접 참가 확인 메시지(NLME-DIRECT-JOIN-CONFIRM), 네트워크 이탈 요청 메시지(NLME-LEAVE-REQUEST), 네트워크 이탈 확인 메시지(NLME-LEAVE-CONFIRM), 네트워크 이탈 지시 메시지(NLME-LEAVE-INDICATION), 라우터 개시 요청 메시지(NLME-START-ROUTER-REQUEST), NLME-START-ROUTER-CONFIRM, 네트워크 계층의 리셋 요청 메시지(NLME-RESET-REQUEST), 네트워크 계층의 리셋 확인 메시지(NLME-RESET-CONFIRM), 데이터 요청 메시지[NLDE(network layer data entity)-DATA-REQUEST],　데이터 확인 메시지(NLDE-DATA-CONFIRM),　데이터 지시 메시지(NLDE-DATA-INDICATION) 등의 17가지 메시지 중 하나를 표시할 수 있다. 그리고 프로토콜 타입 필드(411), 서비스 타입 필드(412), 프레임 타입 필드(413) 및 메시지 타입 필드(414)는 각각 1옥텟(octet)의 길이를 가질 수 있다.
프레임 페이로드(420)는 페이로드 필드(Payload Field)(421)를 포함한다. 페이로드 필드(Payload Field)(421)는 임의의 프리미티브에 동반된 일단의 파라미터를 적재한다. 본 발명의 실시예에서는 페이로드 필드(421)의 길이가 1옥텟의 정수배로 표시될 수 있도록 각 파라미터의 값은 1옥텟의 정수배로 확장된다. 이는 프리미티브에 동반된 순서대로 적재된다. 따라서 사용되는 파라미터는 21가지이며 다음과 같이 확장된 길이를 가진다. 즉, 파라미터(ScanChannels)는 32비트 길이의 비트맵으로 설정되며, 파라미터(ScanChannels, BeaconOrder, SuperframeOrder, PANID, PermitDuration, ShortAddress, DstAddr, NsduLength, ScrAddr) 등은 16비트 길이로 설정되고, 파라미터(BatteryLifeExtension, DiscoverRoute, SecurityEnable) 등은 불린(boolean)값으로서 8비트 길이로 설정된다. 파라미터(CapabilityInformation)는 8비트길이의 비트맵으로 설정되고, 파라미터(ExtendedAddress, DeviceAddress)는 각각 64비트 길이로 설정되며, 파라미터(Status, NsduHandle, BroadcastRadius, LinkQuality 등은 8비트 길이로 설정된다. 파라미터(NSDU)는 파라미터(NsduLength)에 의해 표현된 옥텟길이를 가진다.　
이러한 프리미티브 프레임 패킷(400)은 기능과 성격으로 결정된다. 프리미티브 프레임 패킷(400)을 구성하는 프리미티브 파라미터는 데이터서비스로서 서비스 타입 필드(412)에 표시되고, 해당 프리미티브에 대응되는 메시지 종류는 메시지 타입 필드(414)에 표시되고, 프레임의 종류는 프레임 타입 필드(413)에 표시되고, 프리미티브에 동반된 파라미터는 프레임 페이로드(420)에 표시된다. 페이로드의 길이는 길이 필드(416)에 관련된다. 즉,　임의의 프리미티브 프레임 패킷(400)은 서비스 타입 필드(412)가 "데이터서비스"로 설정되고, 프레임 타입 필드(413)가 "메시지 데이터"로 설정되고, 메시지 타입 필드(414)가 프리미티브 데이터와 관련 메시지 종류로 설정되며, 길이 필드(416)가 페이로드에 적재된 데이터의 길이로 설정되며, 프레임 페이로드(420)는 파라미터 집합으로 설정되는 데이터 프레임으로 생성된다. 프로토콜 타입 필드(411)는 프리미티브와 무관하게 TCP/UDP 중 하나로 선택된 것으로 설정되며, 시퀀스 넘버 필드(415)는 전송될 프레임의 기능과 성격에 무관하게 프레임이 생성되는 순서에 따라 일련의 순서번호로 설정된다.
만일, 프리미티브 프레임 패킷(400)이 프리미티브 및 파라미터 데이터 수신에 대한 확인을 위한 것인 경우, 수신 확인을 위한 확인 서비스로서 서비스 타입 필드(412)에 표시되며, "data ack"가 프레임 타입 필드(413)에 표시되지만, 메시지 타입 필드(414)에 대한 의미 또는 별도의 페이로드는 존재하지 않는다. 이때, 페이로드가 별도로 존재하지 않지만 그 길이는 "length" 에 상응한다. 그러므로 수신 확인을 위한 프레임은 서비스 타입 필드(412)가 "acknowledgement"로 설정되고, 프레임 타입 필드(413)가 "data ack"로 설정되고 메시지 타입 필드(414)는 의미 없는 "NULL"값으로 설정되며, 길이 필드(416)가 페이로드에 적재된 데이터의 길이, 즉 "0"값으로 설정되며, 페이로드 필드(421)는 어떠한 데이터도 포함하지 않는 프레임으로 생성된다. 다만, 프로토콜 타입 필드(411)와 시퀀스 넘버 필드 필드(415) 는 데이터 프레임과 동일하게 설정된다.
프리미티브 프레임 패킷(400)이　프리미티브 수송계층을 위한 명령을 제공하는 경우, 명령서비스로서 서비스 타입 필드(412)에 표시되고, 명령의 종류 및 그 응답의 성격이 프레임 타입 필드(413)에 표시되지만, 메시지 타입 필드(414)에 대한 의미나 또는 별도의 페이로드는 존재하지 않는다. 이때, 페이로드가 별도로 존재하지 않지만 그 길이는 "length" 에 상응한다. 여기서 명령의 종류 및 그 응답에는 명령어(ZPTL connect, ZPTL connect response, ZPTL connect ack, ZPTL disconnect, ZPTL disconnect response등)이 있다. 명령 프레임은 서비스 타입 필드(412)가 커멘트 서비스(Command Service)로 설정되고, 프레임 타입 필드(413)가 명령 및 응답에 따라 명령어(ZPTL connect, ZPTL connect response, ZPTL connect ack, ZPTL disconnect,　ZPTL disconnect response) 중에서 한 가지로 설정되며, 메시지 타입 필드(414)는 의미를 갖지 않는 "NULL"값으로 설정되며, 길이 필드(416)는 페이로드에 적재된 데이터의 길이, 즉 "0"값으로 설정되며, 페이로드 필드(421)는 어떠한 데이터도 포함하지 않는 프레임으로 생성된다.
본 발명의 실시예에서 적용되는 프리미티브와 메시지의 관계는 NLME-NETWORK-FORMATION.request 프리미티브는 네트워크 형성 요청 메시지(NLME-NETWORK-FORMATION-REQUES)대응하고, NLME-NETWORK-FORMATION.confirm 프리미티브는 네트워크 형성 완료 확인 메시지(NLME-NETWORK-FORMATION-CONFIRM)에 대응하고, NLME-PERMIT-JOINING.request 프리미티브는 접속 승인 요청 메시지(NLME-PERMIT-JOINING-REQUEST)에 대응하고, NLME-PERMIT-JOINING.confirm 프리미티브는 접속 승인 확인 요청 메시지(NLME-PERMIT-JOINING-CONFIRM)에 대응하고, NLME-JOIN.indication 프리미티브는 네트워크 접속 완료 메시지(NLME-JOIN-INDICATION)에 대응하고, NLME-DIRECT-JOIN.request 프리미티브는 네트워크 직접접속 요청메시지(NLME-DIRECT-JOIN-REQUEST)에 대응하고, NLME-DIRECT-JOIN.confirm 프리미티브는 네트워크 직접접속 완료 확인 메시지(NLME-DIRECT-JOIN-CONFIRM)에 대응하고, NLME-LEAVE.request 프리미티브는 네트워크 이탈 요청 메시지(NLME-LEAVE-REQUEST)에 대응하고, NLME-LEAVE.confirm 프리미티브는 네트워크 이탈 완료 확인 메시지(NLME-LEAVE-CONFIRM)에 대응하고, NLME-LEAVE.indication 프리미티브는 네트워크 이탈 통지 메시지(NLME-LEAVE-INDICATION)에 대응하고, NLME-START-ROUTER.request 프리미티브는 라우터 역할 개시 요청 메시지(NLME-START-ROUTER-REQUEST)에 대응하고, NLME-START-ROUTER.confirm 프리미티브는 라우터 역할 개시 확인 메시지(NLME-START-ROUTER-CONFIRM)에 대응하고, NLME-RESET.request 프리미티브는 네트워크 설정값 초기화 메시지(NLME-RESET-REQUEST)에 대응하고, NLME-RESET.confirm 프리미티브는 네트워크 설정값 초기화 확인 메시지(NLME-RESET-CONFIRM)에 대응하고, NLDE-DATA.rquest 프리미티브는 데이터 전달 요청 메시지(NLDE-DATA-REQUEST)에 대응하고, NLDE-DATA.confirm 프리미티브는 데이터 전달완료 확인 메시지(NLDE-DATA-CONFIRM)에 대응하고, NLDE-DATA.indication 프리미티브는 데이터 수신 통지 메시지(NLDE-DATA-INDICATION)에 각각 대응한다. 여기서 메시지와 프리미티브 관계는 역의 관계로도 성립될 수 있다.
본 발명의 실시예에 따른 프리미티브 프레임 패킷(400)의 프리미티브는 서로다른 종류의　관련 파라미터를 동반하며 그 관계는 다음과 같다. 즉, 지그비 노드(100)의 지그비 네트워크계층 모듈(120)의 관리 엔터티에 의한 네트워크 형성 요청을 나타내는　프리미티브(NLME-NETWORK-FORMATION.request)는 파라미터(ScanChannels, ScanDuration, BeaconOrder, SuperfameOrder, PANID, BatteryLifeExtension 등)를 동반한다.
지그비 네트워크계층 모듈(120)의 관리 엔터티에게 네트워크 형성 완료에 대한 확인을 나타내는 프리미티브(NLME-NETWORK-FORMATION.confirm)는 파라미터(Status)를 동반하며, 지그비 네트워크계층 모듈(120)의 관리 엔터티에 의한 접속 승인의 요청을 나타내는 프리미티브(NLME-PERMIT-JOINING.request)는 파라미터(PermitDuration)를 동반하며, 지그비 네트워크계층 모듈(120)의 관리 엔터티에 의한 접속 승인 요청에 대한 확인을 나타내는 프리미티브(NLME-PERMIT-JOINING.confirm)는 파라미터(Status)를 동반한다.
지그비 네트워크계층 모듈(120)의 관리 엔터티에 대해 네트워크 접속완료에 대한 통지를 나타내는 프리미티브(NLME-JOIN.indication)는 파라미터(ShortAddress, Extended Address 및 CapabilityInformation 등)을 동반하며, 지그비 네트워크계층 모듈(120)의 관리 엔터티에 의한 네트워크 직접접속의 요청을 나타내는 프리미티브(NLME-DIRECT-JOIN.request)는 파라미터(DeviceAddress, CapabilityInformation 등)를 동반하며, 지그비 네트워크계층 모듈(120)의 관리 엔터티에게 네트워크 직접접속 요청의 완료에 대한 확인을 나타내는 프리미티브(NLME-DIRECT-JOIN.confirm)는 파라미터(DeviceAddress 및 Status)를 동반한다.
지그비 네트워크계층 모듈(120)의 관리 엔터티에 의한 네트워크 이탈의 요청을 나타내는 프리미티브(NLME-LEAVE.request)는 파라미터(DeviceAddress)를 동반하며, 지그비 네트워크계층 모듈(120)의 관리 엔터티에 대한 네트워크 이탈의 완료에 대한 확인을 나타내는 프리미티브(NLME-LEAVE.confirm)는 파라미터(DeviceAddress 및 Status)를 동반한다. 지그비 네트워크계층 모듈(120)의 관리 엔터티에게 네트워크 이탈에 대한 통지를 나타내는 프리미티브(NLME-LEAVE.indication)는 파라미터(DeviceAddress)를 동반하며, 지그비 네트워크계층 모듈(120)의 관리 엔터티에 의한 라우터 역할 개시의 요청을 나타내는 프리미티브(NLME-START-ROUTER.request)는 파라미터(BeaconOrder, SuperframeOrder 및 BatteryLifeExtension 등)을 동반한다.
지그비 네트워크계층 모듈(120)의 관리 엔터티에게 라우터 역할의 개시에 대한 확인을 나타내는 프리미티브(NLME-START-ROUTER.confirm)는 파라미터(Status)를 동반하며, 지그비 네트워크계층 모듈(120)의 관리 엔터티에 의한 네트워크 설정값의 초기화 요청을 나타내는 프리미티브(NLME-RESET.request)는 관련 파라미터를 갖지 않고, 네트워크 설정값의 초기화 완료에 대한 확인을 나타내는 프리미티브(NLME-RESET.confirm)는 파라미터(Status)를 동반한다.
지그비 네트워크계층 모듈(120)의 데이터 엔터티에 의한 데이터 전달 요청을 나타내는 프리미티브(NLDE-DATA.request)는 파라미터(DstAddr, NsduLength, Nsdu, NsduHandle, BroadcastRadius, DiscoverRoute 및 SecurityEnable 등)를 동반하며, 지그비 네트워크계층 모듈(120)의 데이터 엔터티에게 요청된 데이터 전달의 완료에 대한 확인을 나타내는 프리미티브(NLDE-DATA.confirm)는 파라미터(NsduHandle 및 Status 등)를 동반하며, 지그비 네트워크계층 모듈(120)의 데이터 엔터티에게 데이터의 수신에 대한 통지를 나타내는 프리미티브(NLDE-DATA.indication) 는 파라미터(ScrAddr, NsduLength, Nsdu 및 LinkQuality 등)을 동반한다. 이처럼 임의의 프리미티브와 파라미터가 수신되거나, 오류 없이 수신되었을 때 각각 데이터 프레임 및 확인 프레임이 생성된다.
한편, 명령 프레임과 그의 응답 프레임은 데이터 프레임 및 확인 프레임과 다른 시점에서 생성된다. 명령 프레임(ZPTL connect)은 프리미티브(NLME-NETWORK-FORMATION.request)가 수신되었을 때, 응답 프레임(ZPTL connect response)은 명령 프레임(ZPTL connect)이 오류 없이 수신되었을 때, 응답 프레임 (ZPTL connect ack)은 응답 프레임(ZPTL connect response)이 오류 없이 수신되었을 때 각각 생성된다. 응답 프레임(ZPTL disconnect response)은 명령 프레임(ZPTL disconnect)이 오류 없이 수신되었을 때 생성된다.
프리미티브 프레임 패킷(400)은 데이터, 명령, 확인 등을 위한 프리미티브 프레임이 신뢰성 있게 지그비 노드(100)의 지그비 응용계층 모듈(110), 지그비 네트워크 계층 모듈(120)에 통지될 수 있도록 지그비 게이트웨이(200)의 프리미티브 수송계층 모듈(210)과 IP 서비스 서버(300)의 프리미티브 수송계층 모듈(320) 사이에서 송수신된다.
여기서 생성된 데이터 프레임, 명령 프레임, 확인 프레임 등의 프리미티브 프레임 패킷(400)은 IP 네트워크 상에서 IP 패킷에 실려서 지그비 노드(100)의 동등계층으로 전송된다. 이를 위해 프리미티브 수송계층 모듈(210) 및 프리미티브 수송계층 모듈(320)은 프레임과 함께 발신지 포트번호 및 IP 주소, 종착지 포트번호 및 IP 주소를 해당하는 TCP(UDP)/IP 계층으로 전달한다. 여기서, 발신지 포트번호 및 IP 주소, 종착지 포트번호 및 IP 주소는 IP 서비스 서버(300) 및 지그비 게이트웨이(200) 각각에 미리에 알려진다.
도 3은 본 발명의 실시예에 따른 프리미티브 프레임 패킷의 송수신을 개략적으로 나타내는 도면이다.
도 3에 도시한 바와 같이, 본 발명의 실시예에 따른 지그비 게이트웨이(200)의 프리미티브 수송계층 모듈(210) 및 IP 서비스 서버(300)의 프리미티브 수송계층 모듈(320)은 수신되는 프리미티브 프레임 패킷(400)에 의해 비롯되는 통신절차에 따른다.
IP 서비스 서버(300)의 프리미티브 수송계층 모듈(210)은 지그비 응용계층 모듈(310)로부터 프리미티브(NLME-NETWORK-FORMATION.request)를 제외한 임의의 프리미티브를 수신한다(S500). 그리고, 프리미티브 수송계층 모듈(210)은 임의의 프리미티브에 대응하여 생성된 프리미티브 프레임 패킷(400)을 지그비 게이트웨이(200)의 프리미티브 수송계층 모듈(210)로 전달한다(S501).
이때, IP 서비스 서버(300)의 지그비 응용계층 모듈(310)로부터 프리미티브(NLME-NETWORK-FORMATION.request)가 처음 수신되면(S502), 프리미티브 수송계층 모듈(210)은 프리미티브(NLME-NETWORK-FORMATION.request)에 대응하여 생성된 데이터 프리미티브 프레임 패킷(400)을 전달하기 전에 프리미티브 수송계층 사이의 연결을 설정하기 위해 명령 프레임(ZPTL connect)을 지그비 게이트웨이(200)의 프리미티브 수송계층 모듈(210)로 전달한다(S503).
지그비 게이트웨이(200)의 프리미티브 수송계층 모듈(210)은 응답 프레임(ZPTL connect response)을 IP 서비스 서버(300)의 프리미티브 수송계층 모듈(320)로 전달한다(S504).
IP 서비스 서버(300)의 프리미티브 수송계층 모듈(320)은 응답 프레임(ZPTL connect response)에 대응하는 응답 프레임(ZPTL connect ack)을 프리미티브 수송계층 모듈(210)로 전달한다(S505). 이어서 프리미티브 수송계층 모듈(320)은 프리미티브(NLME-NETWORK-FORMATION.request)에 대응하여 생성된 메시지 데이터를 프리미티브 수송계층 모듈(210)로 전달한다(S506). 그러면, 프리미티브 수송계층 모듈(210)은 프리미티브(NLME-NETWORK-FORMATION.request)를 지그비 네트워크 계층 모듈(220)로 전달한다(S507).
지그비 게이트웨이(200)의 프리미티브 수송계층 모듈(210)은 메시지 데이터에 대응하는 확인 데이터(Data Ack)를 IP 서비스 서버(300)의 프리미티브 수송계층 모듈(320)로 전달한다(S508). 그러면, IP 서비스 서버(300)의 프리미티브 수송계층 모듈(320)은 별도의 동작을 수행하지 않고 프리미티브 수송계층 연결의 활성상태를 유지하면서 다른 프레임 또는 프리미티브의 수신을 대기한다.
본 발명의 실시예에서는 데이터 프레임의 신뢰성 있는 전달을 위해 파라미터를 사용한다. 하나는 최대수신대기시간을 나타내는 파라미터(T_Max_Wait_Ack)로서 데이터 프레임을 전송한 후 그에 대한 응답 프레임을 수신하는데 허용되는 최대수신대기를 위한 것이며, 최대수신대기시간은 별도의 타이머에 의해 측정될 수 있다.
다른 하나는 최대재전송횟수를 나타내는 파라미터(N_Max_Retrans)로서 파라미터(T_Max_Wait_Ack) 시간 이내에 확인 프레임이 수신되지 않을 경우, 데이터 프레임에 대한 재전송을 반복하기 위한 것이다. 이것이 적용된다면, 임의의 데이터 프레임을 전송한 송신측은 타이머를 이용해서 파라미터(T_Max_Wait_Ack) 동안 그 응답인 확인 프레임을 기다린다. 만약 그 대기시간 이내에 확인 프레임이 수신되지 않는 다면 송신측은 상기 데이터 프레임을 재전송한다. 이와 같은 재전송은 수신측으로부터 확인 프레임을 수신할 때까지 파라미터(N_Max_Retrans)의 횟수로 반복된다.
지그비 게이트웨이(200)의 프리미티브 수송계층 모듈(210)은 프리미티브 프레임 패킷(400)의 수신이 완료되면, 프리미티브 프레임 패킷(400)을 분석한다. 즉, 프리미티브 수송계층 모듈(210)은 프리미티브 프레임 패킷(400)을 분석하여 지그비 응용계층 모듈(110) 및 지그비 네트워크 계층 모듈(120)이 식별, 처리할 수 있는 형태의 프리미티브 및 관련 파라미터로 재구성한다.
구체적으로, 프리미티브 수송계층 모듈(210)은 수신된 프리미티브 프레임 패킷(400)을 식별하기 위해 그의 프레임 헤더(410)를 분해한다. 이때, 프레임 헤더(410)는 일련의 이진 데이터스트링이므로 프레임 헤더를 구성하는 각 필드를 곧바로 확인할 수 없다. 따라서, 프리미티브 수송계층 모듈(210)은 데이터스티링이 각 프레임 헤더(410)의 구성필드의 길이만큼 세그먼트로서 분할되도록 각 세그먼트에 대한 필드값을 검사한다.
첫 번째 세그먼트는 프로토콜 타입 필드(411)로서 모두 동일한 값을 가진다. 두 번째부터 네 번째 세그먼트는 각각 서비스 타입 필드(412), 프레임 타입 필드(413), 메시지 타입 필드(414)로서 프레임에 따라 서로 다른 값을 가질 수 있고 프레임을 고유하게 식별할 수 있는 정보를 제공한다. 여기서, 서비스 타입 필드(412)는 확인된 값에 따라 수신된 프레임이 명령서비스, 데이터서비스, 확인서비스 중 하나를 위한 것으로 식별되며, 프레임 타입 필드(413)는 확인된 값에 따라 명령 중 하나를 위한 것으로 식별되며, 메시지 타입 필드(414)는 확인된 값에 따라 메시지 중 하나를 전송하기 위한 것으로 식별된다. 다섯 번째 세그먼트는 시퀀스 넘버 필드(415)이며 수신 프레임의 시퀀스 넘버(Sequence Number)로서 확인되며, 응답 프레임의 시퀀스 넘버로서 사용된다. 마지막으로 여섯 번째 세그먼트는 길이 필드(416)이며 수신 프레임의 페이로드의 길이를 제공한다.
만일, 서비스 타입 필드(412)의 값과 프레임 타입 필드(413)의 값에 상관없이 메시지 타입 필드(414)의 값이 "00000000"인 경우라면 여섯 번째 세그먼트인 길이 필드(416)는 "NULL"을 갖으며, 수신된 프레임은 어떠한 페이로드를 갖지 않으므로 페이로드의 분해를 필요로 하지 않는다. 한편, 메시지 타입 필드(414)의 값이 "00000000"이 아닌 경우 경우라면 여섯 번째 세그먼트인 길이 필드(416)는 "NULL" 이 아닌 비트 스트링을 갖는다. 이는 수신 프레임이 프리미티브 메시지로서 관련 파라미터를 전송하는 것으로 식별되며, 파라미터의 재구성을 위해 페이로드에 대한 분해가 필요한 것임을 의미한다. 즉, 길이 필드(416)의 값이 "NULL"이면 페이로드 분해가 필요하지 않으며, "NULL"이 아니면 페이로드에 대한 분해 판단이 이루어 진다. 이처럼, 수신 프레임의 페이로드에 대한 분해 판단은 길이 필드(416)의 값으로 결정된다.
예를 들어, 수신 프레임이 메시지 타입 필드(414)의 값이 메시지(NLME-NETWORK-FORMATION-REQUEST)인 경우, 수신 프레임의 페이로드 필드(421)에는 관련 파라미터로서 32비트 길이의 파라미터(ScanChannels), 16비트 길이의 파라미터(ScanDuration), 16비트 길이의 파라미터(BeaconOrder), 16비트 길이의 파라미터(SuperfameOrder), 16비트 길이의 파라미터(PANID), 8비트 길이의 파라미터(BatteryLifeExtension) 등이 실려있음을 알 수 있다. 헤더 분해가 완료된 잔여 데이터스트링에 대해 순차적으로 분해가 된다면, 1개의 32비트를 갖는 세그먼트, 4개의 16비트를 갖는 세그먼트, 그리고 1개의 8비트를 갖는 세그먼트 등으로 분할된 6개의 세그먼트가 얻어진다. 이중에서 첫 번째 세그먼트로부터 파라미터(ScanChannels)의 값이, 두번째 세그먼트로부터　파라미터(ScanDuration)의 값이, 그리고 세번째 세그먼트로부터 파라미터(BeaconOrder)의 값이, 네번째 세그먼트로부터 파라미터(SuperfameOrder)의 값이, 다섯번째 세그먼트로부터 파라미터(PANID)의 값이, 마지막으로 여섯번째 세그먼트로부터 파라미터(BatteryLifeExtension)의 값이 각각 도출된다.
다른 메시지 타입 필드(414)의 값을 갖는 프레임에 대해서도 식별된 프리미티브에 대응하는 파라미터의 종류와 순서, 그리고 각 파라미터의 길이의 적용을 통해 동일한 방법으로 분해될 수 있다. 다만, 메시지 타입 필드(414)의 값이 프리미티브(NLME-RESET-REQUEST)인 수신 프레임에 대해서는 그와 관련 파라미터가 사용되지 않으므로 별도의 페이로드 분해과정이 수행되지 않는다.
이와 같은 프리미티브 및 관련 파라미터의 재구성의 과정은 지그비 노드(100)의 지그비 응용계층 모듈(110) 및 지그비 네트워크계층 모듈(120)이 식별, 처리할 수 있는 형태로 복원하는 과정으로 프리미티브 및 관련 파라미터를 포함한 프리미티브 프레임 패킷(400)을 분해한 결과를 바탕으로 이루어진다.
도 4는 본 발명의 실시예에 따른 프리미티브 메시지의 전달절차를 개략적으로 도시한 도면이다.
도 1 및 도 4를 참고하면, 본 발명의 실시예에 따른 IP 서비스 서버(300)의 프리미티브 수송계층 모듈(320)은 프리미티브(NLDE-DATA.request, DstAddr, NsduLength, Nsdu, NsduHandle, BroadcastRadius, DiscoverRoute,　SecurityEnable)를 지그비 응용계층 모듈(310)로부터 전달받는다(S600). 프리미티브 수송계층 모듈(320)은 프리미티브(NLDE-DATA.request)에 대응하는 프리미티브 프레임 패킷(400)을 생성하여 지그비 게이트웨이(200)의 프리미티브 수송계층 모듈(210)로 전달한다(S601). 즉, 프리미티브 프레임 패킷(400)은 프리미티브 수송계층 모듈(320)에서 TCP(UDP)/IP 계층 모듈(330)로 전달되어 IP 패킷으로 지그비 게이트웨이(200)의 TCP(UDP)/IP 계층 모듈(230)을 통해 프리미티브 수송계층 모듈(210)로 전달된다.
여기서, 프리미티브(NLDE-DATA.request)는 관련 파라미터를 동반하고 메시지(NLDE-DATA-REQUEST)에 대응되므로 생성되는 프리미티브 프레임 패킷(400)의 프레임 헤더(410)는 프로토콜 타입 필드(411)의 값으로 "UDP"를 표시하며, 서비스 타입 필드(412)의 값으로 "data service"를 표시하며, 프레임 타입 필드(413)의 값으로 "message data"를 표시하며, 메시지 타입 필드(414)의 값으로 "NLDE-DATA-REQUEST"를 표시하며, 시퀀스 넘버 필드(415)의 값으로 "이전 순서번호 + 1"을 표시하며, 길이 필드(416)의 값으로 "68옥텟"을 표시한다. 그리고, 프레임 페이로드(420)는 페이로드 필드(421)의 값으로 프리미티브(NLDE-DATA.request)에 동반되는 관련 파라미터로 구성되며, 관란 파라미터(DstAddr)가 2옥텟, 파라미터(NsduLength)가 2옥텟, 파라미터(Nsdu)가 2옥텟, 파라미터(NsduHandle)가 1옥텟, 파라미터(BroadcastRadius)가 1옥텟, 파라미터(DiscoverRoute)가 1옥텟, 파라미터(SecurityEnable)가 1옥텟으로 서로 연접되어 있으므로, 프리미티브 프레임 패킷(400)은 7옥텟 길이의 프레임 헤더(410)와 68옥텟 길이의 프레임 페이로드(420)로 구성되어 총 75옥텟의 데이터스트링으로 이루어진다. 이때, 파라미터(NSDU)는 60옥텟 길이로서 가정된 것이다.
다음으로 지그비 게이트웨이(200)의 프리미티브 수송계층 모듈(210)은 수신된 프리미티브 프레임 패킷(400)을 분석한다. 프리미티브 프레임 패킷(400)의 데이터스트링의 처음 7옥텟이 6개의 필드(411-416)로 구성된 프레임 헤더(410)이므로, 프리미티브 수송계층 모듈(210)은 프리미티브 프레임 패킷(400)의 데이터스트링의처음 부분을 5개의 1옥텟짜리 세그먼트와 1개의 2옥텟짜리 세그먼트로 분할한다. 즉, 프리미티브 수송계층 모듈(210)은 분할된 각 세그먼트로부터 순차적으로 식별된 프로토콜 타입 필드(411)의 값으로 "UDP", 서비스 타입 필드(412)의 값으로 "data service", 프레임 타입 필드(413)의 값으로 "message data", 메시지 타입 필드(414)의 값으로 "NLDE-DATA-REQUEST", 시퀀스 넘버 필드(415)의 값으로 "이전 순서번호 + 1", 길이 필드(416)의 값으로 "68옥텟"의 속성값을 검출한다.
그리고 프리미티브 프레임 패킷(400)의 데이터스트링의 나머지 68옥텟이 관련 파라미터를 적재한 프레임 페이로드(420)이므로, 프리미티브 수송계층 모듈(210)은 프리미티브 프레임 패킷(400)의 데이터스트링의 나머지 부분을 순차적으로 2개의 2옥텟 세그먼트, 60옥텟 세그먼트, 4개의 1옥텟 세그먼트로 분할한다. 즉, 프리미티브 수송계층 모듈(210)은 순차적으로 파라미터(DstAddr, NsduLength, Nsdu, NsduHandle, BroadcastRadius, DiscoverRoute, SecurityEnable)의 각 속성값을 검출한다.
이러한 프리미티브 프레임 패킷(400)의 재구성 과정을 통해 메시지 타입 필드(414)에 의해 식별된 수신 메시지(NLDE-DATA-REQUEST)는 프리미티브(NLDE-DATA.request)로 표시되므로, 프리미티브 수송계층 모듈(210)은 IP 서비스 서버(300)의 지그비 응용계층 모듈(310)로부터 전달된 것과 동일한 형태로 메시지(NLDE-DATA-REQUEST)를 재구성하여 지그비 네트워크 계층 모듈(220)로 전달한다(S602). 이와 동시에, 프리미티브 수송계층 모듈(210)은 확인 데이터(Data Ack)를 TCP(UDP)/IP 계층 모듈(230)을 통해 IP 패킷으로 IP 서비스 서버(300)의 TCP(UDP)/IP 계층 모듈(330)로 전달하며, TCP(UDP)/IP 계층 모듈(330)은 확인 데이터(Data Ack)를 프리미티브 수송계층 모듈(320)로 전달한다(S603).
동일한 방법으로 IP 서비스 서버(300)는 지그비 게이트웨이(200)로부터 프리미티브(NLDE-DATA.confirm)에 대응하는 프리미티브 프레임 패킷(400)이 생성되어 IP 패킷으로 전달되면, 지그비 게이트웨이(200)의 프리미티브 수송계층 모듈(210)이 수행한 것과 동일한 방법으로 프리미티브 프레임 패킷(400)을 분석 및 재구성한다(S604-S606).
이와 같이, 본 발명의 실시예에 따른 IP 네트워크와 지그비 네트워크간의 연동을 위한 시스템은 서로 분리된 지그비 응용계층 모듈(310)과 지그비 네트워크 계층 모듈(220)이 각각 IP 네트워크를 사이에 둔 IP 서비스 서버(300)와 IP 네트워크 인터페이스를 가진 지그비 게이트웨이(200)에 위치하므로, 고유한 통신절차가 유지될 수 있으며, IP 서비스 서버(300)와 지그비 게이트웨이(200) 사이에서 교환되는 프리미티브와 관련 파라미터를 실은 별도의 프리미티브 프레임 패킷(400)이 신뢰성 있는 통신절차에 따라 TCP/IP 패킷에 의해 양 시스템에 전달되어 IP 네트워크의 한편에 있는 IP 서비스 서버(300)가 IP 네트워크의 다른 편에 있는 지그비 네트워크상의 지그비 노드(100)와 지그비 응용계층 메시지로서 직접 연동하여 통신할 수 있다. 또한, IP 네트워크와 지그비 네트워크간의 연동을 위해 별도의 응용소프트웨어, 응용프로파일 및 연동 게이트웨이 등을 구축할 필요가 없으므로 다양한 지그비 응용분야에 적용할 수 있으며, 특정 지그비 노드(100)에 대한 직접 접속 및 데이터 취득이 용이하므로 지그비 게이트웨이(200)의 복잡도를 경감시킬 수 있다.
이상에서 설명한 본 발명의 실시예는 장치 및 방법을 통해서만 구현이 되는 것은 아니며, 본 발명의 실시예의 구성에 대응하는 기능을 실현하는 프로그램 또는 그 프로그램이 기록된 기록 매체를 통해 구현될 수도 있다.
이상에서 본 발명의 실시예에 대하여 상세하게 설명하였지만 본 발명의 권리범위는 이에 한정되는 것은 아니고 다음의 청구범위에서 정의하고 있는 본 발명의 기본 개념을 이용한 당업자의 여러 변형 및 개량 형태 또한 본 발명의 권리범위에 속하는 것이다.
본 발명의 실시예에 따르면, 서로 분리된 지그비 응용계층 모듈과 지그비 네트워크 계층 모듈를 각각 IP 네트워크를 사이에 둔 서비스 서버와 IP 네트워크 인터페이스를 가진 지그비 게이트웨이에 위치시킴에 따라, 본래의 통신절차를 그대로 사용할 수 있다. 그리고, 프리미티브 수송계층 모듈을 통해 계층 간에 교환되는 프리미티브와 관련 파라미터를 하나의 프리미티브 프레임 패킷으로 생성하여 TCP/IP 패킷에 따라 전달하므로, 서비스 서버가 IP 네트워크의 다른 편에 있는 지그비 노드에게 지그비 응용계층 메시지를 그대로 전달하여, 효율적인 IP 네트워크와 지그비 네트워크간 연동을 제공할 수 있다.
또한, 본 발명의 실시예에 따르면, 서로 분리된 지그비 응용계층 모듈과 지그비 네트워크 계층 모듈이 각각 IP 네트워크를 사이에 둔 서비스서버와 IP 네트워크 인터페이스를 가진 지그비 게이트웨이에 위치함에 따라 특정 노드에 대한 직접 접속 및 데이터 취득이 용이하며, 지그비 네트워크 자체의 관리기능을 응용서버가 완전하게 관리하여 실시간 모니터링 및 원격제어 등 IP 네트워크 기반의 다양한 지그비 응용을 지원할 수 있다.

Claims (12)

  1. 지그비 노드와 지그비 네트워크로 연결되어 있으며, IP 서비스 서버와 IP 네트워크를 통해 연결되어 있는 지그비 게이트웨이에 있어서,
    상기 IP 서비스 서버에서 상기 IP 네트워크를 통해 전달된 제1 프리미티브 프레임 패킷에서 제1 데이터를 추출하는 프리미티브 수송 계층 모듈, 그리고
    상기 프리미티브 수송 계층 모듈로부터 상기 제1 데이터를 전달받으며, 상기 제1 데이터를 상기 지그비 노드로 전달하는 지그비 네트워크 계층 모듈
    을 포함하는 지그비 게이트웨이.
  2. 제1항에 있어서,
    상기 제1 데이터는 프리미티브 및 파라미터 중 적어도 하나를 포함하는 지그비 게이트웨이.
  3. 제1항에 있어서,
    상기 IP 네트워크를 통해 전달된 제1 프리미티브 프레임 패킷을 수신하여 상기 프리미티브 수송 계층 모듈로 전달하는 TCP/IP 계층 또는 UDP/IP 계층을 포함하는 포함하는 지그비 게이트웨이.
  4. 제1항에 있어서,
    상기 프리미티브 수송 계층 모듈은,
    상기 지그비 네트워크 계층 모듈에서 전달된 제2 데이터를 수신하며, 상기 제2 데이터를 포함하는 제2 프리미티브 프레임 패킷을 생성하고, 상기 제2 프리미티브 프레임 패킷을 상기 IP 서비스 서버로 전달하는 지그비 게이트웨이.
  5. 제4항에 있어서,
    상기 제1 프리미티브 프레임 패킷은 프레임 헤더 및 상기 제1 데이터를 싣고 있는 프레임 페이로드를 포함하며,
    상기 제2 프리미티브 프레임 패킷은 프레임 헤더 및 상기 제2 데이터를 싣고 있는 프레임 페이로드를 포함하는 지그비 게이트웨이.
  6. 제5항에 있어서,
    상기 프레임 헤더는 상기 프레임 페이로드에 실린 데이터의 종류를 나타내는 메시지 타입 필드 및 상기 프레임 페이로드의 길이를 나타내는 길이 필드를 포함하는 지그비 게이트웨이.
  7. 지그비 게이트웨이와 IP 네트워크를 통해 연동하는 IP 서비스 서버에 있어서,
    상기 지그비 게이트웨이에서 상기 IP 네트워크를 통해 전달된 제1 프리미티브 프레임 패킷에서 제1 데이터를 추출하는 프리미티브 수송 계층 모듈, 그리고
    상기 프리미티브 수송 계층 모듈로부터 상기 제1 데이터를 전달받는 지그비 응용계층 모듈
    을 포함하는 IP 서비스 서버.
  8. 제7항에 있어서,
    상기 제1 데이터는 프리미티브 및 파라미터 중 적어도 하나를 포함하는 IP 서비스 서버.
  9. 제7항에 있어서,
    상기 지그비 게이트웨이를 통해 전달된 제1 프리미티브 프레임 패킷을 수신하여 상기 프리미티브 수송 계층 모듈로 전달하는 TCP/IP 계층 또는 UDP/IP 계층을 포함하는 포함하는 IP 서비스 서버.
  10. 제7항에 있어서,
    상기 프리미티브 수송 계층 모듈은,
    상기 지그비 응용계층 모듈에서 전달된 제2 데이터를 수신하며, 상기 제2 데이터를 포함하는 제2 프리미티브 프레임 패킷을 생성하고, 상기 제2 프리미티브 프레임 패킷을 상기 지그비 게이트웨이로 전달하는 IP 서비스 서버.
  11. 제10항에 있어서,
    상기 제1 프리미티브 프레임 패킷은 프레임 헤더 및 상기 제1 데이터를 싣고 있는 프레임 페이로드를 포함하며,
    상기 제2 프리미티브 프레임 패킷은 프레임 헤더 및 상기 제2 데이터를 싣고 있는 프레임 페이로드를 포함하는 IP 서비스 서버.
  12. 제11항에 있어서,
    상기 프레임 헤더는 상기 프레임 페이로드에 실린 데이터의 종류를 나타내는 메시지 타입 필드 및 상기 프레임 페이로드의 길이를 나타내는 길이 필드를 포함하는 IP 서비스 서버.
PCT/KR2010/004108 2009-07-03 2010-06-24 지그비 게이트웨이, 이와 ip 네트워크를 통해 연동하는 ip 서비스 서버 WO2011002177A2 (ko)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US13/382,064 US20120099579A1 (en) 2009-07-03 2010-06-24 Zigbee gateway and ip service server interworking with zigbee gateway through ip network

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
KR10-2009-0060866 2009-07-03
KR1020090060866A KR20110003209A (ko) 2009-07-03 2009-07-03 지그비 게이트웨이, 이와 ｉｐ 네트워크를 통해 연동하는 ｉｐ 서비스 서버

Publications (2)

Publication Number Publication Date
WO2011002177A2 true WO2011002177A2 (ko) 2011-01-06
WO2011002177A3 WO2011002177A3 (ko) 2011-04-14

Family

ID=43411566

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2010/004108 WO2011002177A2 (ko) 2009-07-03 2010-06-24 지그비 게이트웨이, 이와 ip 네트워크를 통해 연동하는 ip 서비스 서버

Country Status (3)

Country Link
US (1) US20120099579A1 (ko)
KR (1) KR20110003209A (ko)
WO (1) WO2011002177A2 (ko)

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11627186B2 (en) * 2012-05-17 2023-04-11 Digi International, Inc. Wireless network of environmental sensor units
CN103686584B (zh) * 2012-09-04 2016-12-14 上海贝尔股份有限公司 传感器网络中的端到端通信
US9191209B2 (en) * 2013-06-25 2015-11-17 Google Inc. Efficient communication for devices of a home network
TWI536783B (zh) * 2014-03-06 2016-06-01 達創科技股份有限公司 網路系統及其內的通訊裝置
EP3010183B1 (de) * 2014-10-13 2019-06-19 Deutsche Telekom AG Vorrichtung, System und Verfahren zum Verbinden von Feldbusgeräten mit dem Internet
KR101499097B1 (ko) * 2014-12-15 2015-03-05 (주)에이원정보기술 Mdws-600s 전용통신망과의 호환성을 갖는 데이터 게이트웨이 시스템
US9247322B1 (en) 2015-05-29 2016-01-26 Schechter Tech, Llc Low-power user interface device for environmental monitoring system
US10559451B2 (en) * 2017-02-15 2020-02-11 Applied Materials, Inc. Apparatus with concentric pumping for multiple pressure regimes
US10652713B2 (en) 2017-02-22 2020-05-12 Futurewei Technologies, Inc. Method of application data switching between a device in a wireless PAN mesh network and a virtual ethernet interface
US10581673B2 (en) 2017-03-08 2020-03-03 Futurewei Technologies, Inc. Abstracting wireless device to virtual Ethernet interface
CN108770045B (zh) * 2018-06-05 2021-04-23 云丁智能科技（北京）有限公司 入网方法、相关设备及网络系统

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100684612B1 (ko) * 2006-03-07 2007-02-22 주식회사 대우일렉트로닉스 홈 네트워크 시스템 및 홈 게이트웨이
KR20070027915A (ko) * 2005-08-30 2007-03-12 주식회사 옥타컴 지그비/인터넷 게이트웨이에서 멀티채널을 지원하는 방법및 그 장치
KR100824050B1 (ko) * 2007-03-20 2008-04-22 고려대학교 산학협력단 이종의 네트워크를 연동하는 게이트웨이 장치, 그 방법 및기록 매체
KR20080072780A (ko) * 2007-02-03 2008-08-07 김기형 게이트웨이와 이를 이용한 패킷 변환 방법

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA2548412C (en) * 2003-12-08 2011-04-19 Qualcomm Incorporated High data rate interface with improved link synchronization
US20070030848A1 (en) * 2005-07-28 2007-02-08 Yokogawa Electric Corporation Network communication system
JP4942375B2 (ja) * 2006-03-27 2012-05-30 株式会社ソニー・コンピュータエンタテインメント ネットワーク処理装置
US8149849B2 (en) * 2006-08-31 2012-04-03 Sony Ericsson Mobile Communications Ab Zigbee/IP gateway

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20070027915A (ko) * 2005-08-30 2007-03-12 주식회사 옥타컴 지그비/인터넷 게이트웨이에서 멀티채널을 지원하는 방법및 그 장치
KR100684612B1 (ko) * 2006-03-07 2007-02-22 주식회사 대우일렉트로닉스 홈 네트워크 시스템 및 홈 게이트웨이
KR20080072780A (ko) * 2007-02-03 2008-08-07 김기형 게이트웨이와 이를 이용한 패킷 변환 방법
KR100824050B1 (ko) * 2007-03-20 2008-04-22 고려대학교 산학협력단 이종의 네트워크를 연동하는 게이트웨이 장치, 그 방법 및기록 매체

Also Published As

Publication number Publication date
WO2011002177A3 (ko) 2011-04-14
US20120099579A1 (en) 2012-04-26
KR20110003209A (ko) 2011-01-11

Similar Documents

Publication Publication Date Title
WO2011002177A2 (ko) 지그비 게이트웨이, 이와 ip 네트워크를 통해 연동하는 ip 서비스 서버
JP4897884B2 (ja) Ｚｉｇｂｅｅ／ｉｐゲートウェイ
WO2012018190A2 (ko) 트래픽 기반 통신 시스템 및 방법
Cisco IBM Network Protocol Translation Commands
Cisco IBM Network Protocol Translation Commands
Cisco IBM Network Protocol Translation Commands
Cisco IBM Network Protocol Translation Commands
Cisco IBM Network Protocol Translation Commands
Cisco IBM Network Protocol Translation Commands
Cisco IBM Network Media Translation Commands
Cisco IBM Network Protocol Translation Commands
Cisco IBM Network Media Translation Commands
Cisco IBM Network Media Translation Commands
Cisco IBM Network Media Translation Commands
Cisco IBM Network Protocol Translation Commands
Cisco IBM Network Media Translation Commands
Cisco IBM Network Media Translation Commands
Cisco IBM Network Media Translation Commands
Cisco IBM Network Media Translation Commands
Cisco IBM Network Media Translation Commands
Cisco IBM Network Media Translation Commands
Cisco IBM Network Media Translation Commands
Cisco IBM Network Media Translation Commands
Cisco IBM Network Media Translation Commands
Cisco IBM Network Protocol Translation Commands

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 10794312

Country of ref document: EP

Kind code of ref document: A2

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 13382064

Country of ref document: US

122 Ep: pct application non-entry in european phase

Ref document number: 10794312

Country of ref document: EP

Kind code of ref document: A2