JP2006503513A - Common protocol hierarchy and method and common protocol packet for mutual data transmission between heterogeneous protocols. - Google Patents

Common protocol hierarchy and method and common protocol packet for mutual data transmission between heterogeneous protocols. Download PDF

Info

Publication number
JP2006503513A
JP2006503513A JP2004555107A JP2004555107A JP2006503513A JP 2006503513 A JP2006503513 A JP 2006503513A JP 2004555107 A JP2004555107 A JP 2004555107A JP 2004555107 A JP2004555107 A JP 2004555107A JP 2006503513 A JP2006503513 A JP 2006503513A
Authority
JP
Japan
Prior art keywords
packet
common protocol
data transmission
layer
protocols
Prior art date
Legal status (The legal status 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 status listed.)
Granted
Application number
JP2004555107A
Other languages
Japanese (ja)
Other versions
JP4577683B2 (en
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
Priority to KR20020073667A priority Critical patent/KR100477513B1/en
Application filed by コリア エレクトロニクス テクノロジ インスティチュート filed Critical コリア エレクトロニクス テクノロジ インスティチュート
Priority to PCT/KR2003/002542 priority patent/WO2004049671A1/en
Publication of JP2006503513A publication Critical patent/JP2006503513A/en
Application granted granted Critical
Publication of JP4577683B2 publication Critical patent/JP4577683B2/en
Application status is Active legal-status Critical
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Application independent communication protocol aspects or techniques in packet data networks
    • H04L69/08Protocols for interworking or protocol conversion

Abstract

The present invention relates to a common protocol layer structure and method and a common protocol packet that accommodate various protocols such as IP, Bluetooth, IEEE 1394, Rontok, etc. and enable mutual communication between them.
The common protocol hierarchical structure for mutual data transmission between different types of protocols according to the present invention enables the communication processing between two longitudinal users configured in a communication network to be divided into layers. In a standard protocol or a reference model (OSI 7 layer), an application layer that is positioned at the top of the layer, a common protocol layer that enables data communication between heterogeneous protocols that are positioned next to the application layer, and the common protocol layer An expression hierarchy next to the expression hierarchy, a session hierarchy next to the expression hierarchy, a transport hierarchy next to the session hierarchy, a network hierarchy next to the transport hierarchy, and a rank next to the network hierarchy Including a data link hierarchy and a physical hierarchy next to the data link hierarchy. There are technical features.

Description

  This patent application is related to Korean Patent Application No. 10-2002-0056725, filed on Sep. 18, 2002, titled (Method and Apparatus for Integrated Processing of Heterogeneous Protocol and Multimedia Data).

  The present invention relates to a common protocol structure for mutual data transmission between different types of protocols. More specifically, the present invention accommodates various protocols such as IP, Bluetooth, IEEE 1394, and Rontok, and enables mutual communication between them. The present invention relates to a common protocol layer structure and a common protocol packet structure.

  The Open System Interconnection (OSI) reference model is based on a wide variety of communication between application programs in which world-wide vendors interconnect other computers and terminal devices. Provide standard rules for processing business.

  Data flow between systems is achieved through the OSI environment. Although there are seven types of hierarchies in OSI, the seven types of hierarchies are roughly divided into an upper layer and a lower layer. The upper layer has an application layer (Application Layer) that enables communication between the user and the central processing unit by performing a protocol for network operation management with the user, and has a structure for communication between functional modules in the application layer. An expression layer (Presentation Layer) that handles an information expression format and a session layer (Session Layer) that controls interaction between application layers.

  The lower layer is a transport layer (Transport Layer) that performs the role of enabling accurate communication between both terminal devices without the upper layer being aware of the line quality and the physical configuration of the additional communication system. A network layer that provides data transmission services for the communication functions of the transmission layer (Network Layer), and a data link layer (data link layer that serves to increase the name and value of physical links in a logical network and send data accurately and gently ) And a physical layer (Physical Layer) that receives and transmits a physical interface between physical media and a beat according to a data transmission request from the data link layer.

  In an open system, the user program data of system A is input to the OSI environment, and sequentially moves from the application layer toward the physical layer and is sent out to the transmission medium. At this time, the data is transmitted in a frame used for HDLC (High Level Data Link Control) procedure. This frame arrives at the destination computer from the open system through the data exchange network called the relay open system in OSI. Among these, the data reaches the application layer through each layer in order from the lower physical layer, and finally moves from the open system to the application process B which is the destination of the system B.

  A data flow between systems can be established between systems, and can also be established between a system and a terminal connected to the system. However, in order to communicate between two or more computer systems, communication between them is not free when the respective protocols are different. For this reason, a protocol converter is required to enable efficient communication between other models.

  According to prior art US Pat. No. 5,852,660, an apparatus and method for converting signal connection functional parts between networks using a protocol converter is presented. This relates to, for example, a method for making network communication compatible by using a remote communication SS7 protocol including application layer data in the OSI layer.

Conventional protocol converters allow two different protocols to exchange data between both central processing units (CPUs). That is, direct data exchange between mutual software or data exchange between mutual hardware using simple logic is established. In such a protocol converter, during the period when the central processing unit performs other operations, an extension element of the period is generated, so that the central processing unit on one side receives a signal and sends a response to the inside of the system. During the exchange, a burden is imposed on the central processing unit, and a time wasted element is generated, resulting in a problem with many losses in terms of performance.
The conventional address conversion method for communication between various protocols is closely related to the protocol conversion process. Therefore, the address conversion method by the protocol conversion method can be roughly classified into three types.

The first is a 1: 1 protocol conversion method. This is a method for converting a specific layer of a specific protocol into a layer corresponding to this of another protocol based on the OSI layer 7. This means that if the number of layers to be converted is m, m conversion methods are required, and if the number of protocols to be converted is n, an n C 2nd method is required, so all m · n C 2 I'm going to need a method of position. Therefore, for the mutual data exchange between various protocols having various protocol layers, there is a disadvantage that the complexity is increased by so many conversion methods.

  The second is a conversion method to a specific protocol. This is a method of performing protocol conversion based on any specific protocol among n protocols. In other words, the method of converting n protocols into one of the standard protocols requires (n-1) conversion methods, and m is the number of cases where conversion is required for each layer for each. For example, since m conversion methods are required, there are m · (n−1) conversion methods. Compared to the first method above, this shows a lot of reduction in the complexity of protocol conversion, but it still has a great disadvantage to convert many protocols.

  The third uses an address conversion method through an overlay, as in US Pat. No. 5,715,250. For example, IP-over-IEEE1394, IP-over-ATM, etc. belong here. This is a structure in which an IP protocol is raised above the IEEE 1394 or ATM layer, and is not a data exchange method between other protocols, although no special conversion is performed.

That is, in the case of IP-over-IEEE 1394, if a device in the IEEE 1394 network sends IEEE 1394 data, it is loaded and sent over IP, and this is received again via IP, and the IEEE 1394 device receives the data via the IEEE 1394 layer above IP. So it is impossible to exchange data between different protocols.
However, conventional protocol conversion methods such as those described above are the complexity of the conversion method, the complexity due to each other's hierarchical structure and role between protocols, and the method by which devices in other networks can be accessed. Inherent complexity. In other words, the number of layers between the protocols to be converted and the number of conversion methods in proportion to the number of protocols are required, so the complexity increases, and the protocol layers each protocol has on the basis of the OSI 7 layers Since the structure and role of each layer are very different, the complexity when converting between them increases more by a specific factor times (this factor should be determined by the various option fields and processing roles in each protocol layer) .) When such complicated protocol conversion is performed and it is assumed that communication is established between the equipments of other networks, there is a problem that there is no common address system that can recognize each other between them. .

  The present invention has been devised in order to solve the above-described conventional problems, and a common protocol layer structure and a common protocol packet structure capable of simultaneously accommodating various protocols are designed, and a general protocol is designed. A technique that inserts a common protocol layer below the application layer in the hierarchical structure, assigns a common address to devices in all networks, and uses the common protocol to determine whether the operating status of devices in each network is possible. Provided is that object of the present invention.

  The object of the present invention is to establish an OSI standard or reference model (OSI 7) that enables communication processing to be divided into layers according to characteristics possessed by each layer in the middle of two longitudinal users configured in a communication network. (Hierarchy) structure, an application layer that is positioned at the top of the hierarchy, a common protocol layer that enables data communication between different types of protocols that are positioned next to the application layer, and an expression layer that is positioned next to the common protocol layer , A session hierarchy next to the representation hierarchy, a transport hierarchy next to the session hierarchy, a network hierarchy next to the transport hierarchy, a data link hierarchy next to the network hierarchy, and the data It is generated by the physical hierarchy that follows the link hierarchy.

  Another object of the present invention is to establish an OSI standard that allows a communication process to be divided into layers with special functions that each layer has in the middle of two longitudinal users configured in a communication network. Common for mutual data transmission between heterogeneous protocols comprising a common protocol layer stage that enables data communication between heterogeneous protocols ranked next to the application layer in the reference model (OSI 7 layer) Generated by protocol hierarchy method.

  Another object of the present invention is for mutual data transmission between different types of protocols consisting of a common protocol header including information about the packet and a payload having data contents in a packet which is all data units moving through the network. Of common protocol packets.

Effects of the invention

  The common protocol layer structure and method for mutual data transmission between the heterogeneous protocols of the present invention and the common protocol packet are inserted in the application layer or the common layer at the lower level, so that only the application program is converted without conversion between the existing protocol layers It is possible to communicate with each other, and by assigning a common address to all devices in all networks that use a common protocol, these devices can be managed and communicate with each other. There is an advantage that can be understood by the gateway, and there is an effect that compatibility between protocols can be increased by designing a common protocol layer and a common protocol packet structure capable of simultaneously accommodating various protocols.

  The emergence and development of various protocols using various existing transmission channels and the development of various middleware and hardware platforms that accommodate them, and the increasing interest in home networking, will increase the networking of home networks and external networks. This is a situation where you are taking a seat to get a seat as a standard as a protocol or middleware. Here, the present invention describes a common protocol structure that can accommodate all such various protocols, and a protocol layer conversion technique for mutual communication between them.

  DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS The above-mentioned objects and technical configurations of the present invention, and detailed matters relating to the operation and effect thereof, will be clearly understood from the following detailed description with reference to the drawings illustrating preferred embodiments of the present invention.

  FIG. 1 is a structural diagram of a common protocol layer according to the present invention. The common protocol layer can be part of the application layer 10 or can exist immediately below the existing application layer.

  The network protocol including the common protocol can be any network protocol attached to the OSI standard protocol specified by the communication standard protocol between networks in the W3C which is the World Wide Web Consortium. Examples of such protocols are the TCP / IP protocol used in networks such as the Internet, Intranet or Xtranet, the IEEE 1394 protocol used for network communication in the Linux operating system, the LonTalk protocol that embodies user-centered systems, and wireless networks Bluetooth protocol used in

  A data transmission method using a network protocol layer including a step of transmitting data through the common protocol layer includes a step of transmitting data through an application layer that enables a communication service between two longitudinal users, a packet switch. Steps in which data is transmitted through a common protocol layer that performs channeling, broadcast or multicast, address conversion, device control, packet classification, security, congestion access control, resource management, etc. A stage in which data is transmitted through an expression hierarchy that is converted to another expression form, a setting for exchanging messages between longitudinal host programs, and a role to control the synchronization of data reception, and configure a communication session Data is transmitted through the session hierarchy Control stage to ensure reliable data transmission between the sections and the stage where data is transmitted through the transport layer to manage errors, control the correct path so that the packet is sent to the correct recipient The stage where data is transmitted through the network hierarchy that controls the data path to be received on the receiving side, providing physical level error control and synchronization, beats to more than one streaming stream The physical layer that provides hardware means for exchanging data through the transmission medium by transporting the bit string through the network where the data is transmitted through the data link layer responsible for transmission confirmation and management and the electromechanical system It includes the step of sending data through.

  Examples of data transmission methods using such a protocol layer include a method of sending data through the TCP / IP protocol used in networks such as the Internet, Intranet or Xtranet, and data through the IEEE 1394 protocol used for network communication in the Linux operating system. There are a method of sending data through a LonTalk protocol that embodies a user-centered system, a method of sending data through a Bluetooth protocol used in a wireless network, and the like.

  FIG. 2 is an example of an application of the common protocol according to the present invention. Among the devices in the network A, the device AA tries to transmit data to the device BA in the other network B using a chipset that supports the common protocol. This is an example of the case. At this time, the protocol layer supported by the chipset and the protocol layer of the home station are as shown in FIG.

  The data in the application layer of device AA is created through the common protocol layer, adding a preamble and a common protocol header in front of the application data to create a final application protocol data unit (application PDU). Separately, a header and a trailer corresponding to each protocol layer are attached through the representation (layer 6) layer to the physical layer.

  The completed packet arrives at the interface module device AZ outside the chipset capable of processing a common protocol through a transmission medium on each protocol network. In this device, the physical layer to the layer 6 are used. While going through the protocol layer, the header and trailer of the corresponding layer are separated to reach the application layer. At this time, the application of the device AZ investigates the pre-emblem of the received application protocol data unit packet, and it becomes clear that the pre-emblem uses the common protocol, and only the common protocol packet with the pre-emblem removed by the packet received from the chip If the pre-emblems do not match, the packet is received with its own device as the destination, and data processing is performed in its own application layer.

  Thereafter, in the chipset that has received the common protocol packet, switching is performed according to the address information in the common protocol header 210 and the common protocol packet is sent to the destination photo. Sent to module device BZ.

  The device BZ recognizes this packet as application data and attaches a pre-emblem and a common protocol header 210 while passing through the common protocol layer 20. Thereafter, the data is sent to the destination device BA through the physical layer 80 and the transmission medium in the layer 6.

  The received packet reaches the common protocol layer 20 through the processing procedures from the physical layer 80 to the layer 6, and after all, the pre-emblem is investigated and the application protocol data unit is transmitted from another network. It can be seen that the packet has passed through the common protocol layer 20.

  FIG. 3 is a structural diagram of a chipset and home station protocol supporting a common protocol. The common protocol layer of the common protocol layer structure performs packet switching, broadcast or multicast, address conversion, device control, packet classification, security, congestion access control, resource management, and the like.

  FIG. 4 is a protocol hierarchy diagram of devices supporting the common protocol. A device supporting a common protocol in a network must use a common protocol layer. At this time, the protocol layer structure of the device is as shown in FIG. 4 below. Here, the route (1) is 110 when communicating with a device in the same network using its own protocol using its own basic protocol, and the route (2) is within another network using a common protocol. It is a figure showing 120 in the case of communicating with the device. In addition, since the route (3) facilitates smooth communication between the common protocol and the existing protocol, the common protocol layer must be able to support 130 the API of the standard determined for communication with the application layer of the existing protocol.

  FIG. 5 is a structural diagram of a common protocol packet according to the present invention. APDU (Application Protocol Data Unit) is data generated as an application layer first, and is transmitted to a common protocol layer when communicating with a device of a heterogeneous network.

  Next, the common protocol packet 200 is composed of a total of 32 bytes, and is composed of a 16-byte pre-emblem and a 16-byte common protocol header 210. The header is composed of a source address 220, a destination address 230, an option field 240, an order field 250, a length field 260, and a reserved field 270 for future use.

  The pre-emblem is composed of 16 bytes, and there are two main uses for this field. The first is to notify whether the currently received packet is a packet that has passed through the common protocol layer, and the second is authentication for security to prevent access to the home without permission from the outside. Key value typing or authentication encryption or the like can be entered.

  The origin address 220 represents the sender's common address, which can be understood only in the common protocol layer 20 and the corresponding application layer 10. This address is actually an address that is mapped 1: 1 to the physical address of all devices in the network, and this address must be centrally managed by a gateway that accommodates this common protocol. At the time of management, the physical address of the device and the corresponding common address should be managed simultaneously.

  In addition, the application layer 10 and the user can have various advantages in terms of management as long as the address is designed so that the network structure in the home and the device that performs what function can be found in any network. To do so, there must be a set of rules for addressing within the common protocol. The destination address 230 has a structure similar to the origin address 220 and represents a common address on the receiving side.

  FIG. 6 is an exemplary diagram of the structure of the option field 240. The option field 240 can be composed of 2 bytes, and is composed of a traffic type (Traffic Type: TT) 310, a packet type (PT) 320, and a management packet (Management Packet: MP) 330 of the current packet. The

  FIG. 7 is a view showing an example of the traffic type 310 which is the detailed contents of the option field 240. Traffic types are classified into control command data, real-time data, and non-real-time data for packet rush and QoS (Quality of Service). The control command data means data used when controlling devices in the home, and the real-time data is used when data that requires real-time processing for entertainment such as audio, video and games is displayed. Non-real-time data is used to represent other Internet data.

  FIG. 8 is a diagram showing definitions of a domain network and a cluster network. The home network can be composed of one or more residence gateways (RG) or home gateways (HG). At this time, a network composed of one RG or HG is defined as a domain network. And one protocol network connected to RG or HG is defined as a cluster network.

  FIG. 9 is a view showing an example of the packet type 320 which is the detailed contents of the option field 240. The packet type field defines a packet transmission method, and provides a unicast method, a broadcast method, and various multicast methods. With the above structure, there can be basically unicast for 1: 1 communication and 1: broadcast for all device communication, and 1: multicast method for multiple device communication. Detailed multicast methods can be cluster-multicast for communication only for devices in the cluster, domain-multicast for communication only for devices in the domain, and RG-multicast for communication only for RG.

  FIGS. 10 and 11 are illustrations of the management packet type 330 which is the detailed contents of the option field 240. The management packet field is a field specially defined for home network management provided by a common protocol. Each field value is composed of 1 byte as shown in FIG. 10 and FIG.

  FIG. 12 shows an example of the structure of the order field 250. Since the common protocol layer exists between the application layer and the presentation layer 80, the MTU (Maximum Transmission Unit) supported in such a layer can be different when exchanging data with the upper and lower layers for each protocol. . In such a case, it is necessary to segment and send the payload part in the common protocol packet. Of course, the receiving side needs a process of resembling them again. The field used at this time is an order field, and can be composed of a sequence number 410 that is currently segmented as shown in FIG. 12 and a field 420 that informs that it is the last packet.

  A length field 260 indicates the size of application data after the common protocol header 210.

  Next, the details of the management packet field 330 will be described in more detail. Management packet includes Device Registration packet and RG or Home Station Registration packet, Orlive-Check packet, status report packet, VOD and broadcast MPEG stream related packet, WAN and stream There are packets related to gateway interfaces, packets related to addition, removal and initialization of devices.

  FIG. 13 is an exemplary diagram for a device registration packet. The device registration packet includes a DRREQ (Device Registration Request) requesting device registration and a DRRES (Device Registration Response) packet responding to device registration. By using these packets, the PnP function of the devices can be provided.

  FIG. 14 is an exemplary diagram for an RG or home station registration packet. In the RG or home station registration packet, HRSREQ (Home Station Registration Start Request) requesting start of home station registration, HRSRES (Home Station Registration Start Response) responding to start request of home station registration, HRREQ requesting home station registration There are (Home Station Registration Request), HRRES (Home Station Registration Response) that responds to home station registration request, and HRIND (Home Station Registration Indication) packet that displays home station registration, and PnP function of home stations by using these packets Can be provided.

  The Orlive-Check packet is composed of an ACREQ (Alive-Check Request) requesting an Orlive-Check and an ACRES (Alive-Check Response) packet responding to the Orlive-Check shown in FIG. This is a packet for confirming whether or not is operating. If ACRES is not received within 3 seconds after sending ACREQ, the corresponding device is considered to have logged out from the home network, and a DDEV (Delete Device) packet is sent to the home network as shown in FIG. Broadcast to all devices.

  FIG. 16 shows the timeline of ACREQ and ACRES packets as an example of using the OLIVE-CHECK packet. Case 1 is a case where an ACRES response packet is received 3 seconds before the ACREQ packet. Therefore, the device that sent the ACREQ packet knows that the device is still logged on to the home network.

  Case 2 is when there is no response within 3 seconds after sending the ACREQ packet. At this time, the DDEV packet is notified to other devices by broadcasting that the corresponding device has been logged out from the home network. The address of the corresponding device is deleted from the address table managed by the user.

  FIG. 17 shows an example of a status report (Report-Status) packet, RSREQ (Report-Status Request) for requesting a status report, RSRES (Report-Status Response) for responding the status report, and RSIND (Report-Status Request) for initializing the status report. Status Indication) packet.

  In FIG. 18, as an example of the use of the status report packet, a device that has received an RSREQ checks its own status against the requested item and sends the result to RSRES. The status report request item and the data for the request item are inserted into the payload portion of the RSREQ packet. The RSIND packet sends the device's own emergency situation to the home station in its domain network.

  FIG. 19 is composed of VODREQ (VOD Request) requesting VOD MPEG stream service, VODRES (VOD Response) responding VOD MPEG stream service, and VODSTR (VOD Stream) packets as examples of VOD MPEG stream related packets. FIG. 20 shows an example of a broadcast MPEG stream-related packet including BRCTREQ (Broadcasting Request) for requesting a broadcast MPEG stream service, BRCTRES (Broadcasting Response) for responding to a broadcast MPEG stream service, and BRCTSTR (Broadcasting Stream) packets. Is done.

  Devices wishing for VOD and broadcast stream services send VODREQ and BRCTREQ packets to the stream gateway interface. At this time, stream information and necessary bandwidth are requested. The stream gateway interface informs the results for the requested content and the actual allocated bandwidth in VODRES and BRCTRES packets. The actual stream sends an 188-byte MPEG stream in the payload of VODSTR and BRCTSTR packets.

  FIG. 21 is an example of a packet related to WAN and stream gateway interface address request. Devices that wish to connect to the WAN and stream service can communicate with each other only if the address of the corresponding gateway interface is known. Therefore, there is a need for a packet that performs a request for the gateway interface address, a response to the request, and a function for the home station having the gateway interface to automatically notify the address. As shown in FIG. 21, WGIREQ (WAN Gateway Interface Request) for requesting the address of the WAN gateway interface, WGIRES (WAN Gateway Interface Response) for responding to the address request of the WAN gateway interface, and the address of the WAN gateway interface WGIIND (WAN Gateway Interface Indication) for initialization, SGIREQ (Stream Gateway Interface Request) for requesting a stream gateway interface address, SGIRES (Stream Gateway Interface Response) for responding to a stream gateway interface address request, and a stream gateway It consists of a SGIIND (Stream Gateway Interface Indication) packet that initializes the interface address. In response to the address request, a home station having the corresponding gateway interface writes a response packet with its address in the payload.

  FIG. 22 is an example of an address table management related packet. As shown in FIG. 22, it consists of ADEV (Add Device), DDEV (Delete Device), and IDEV (Init Device) packets. When any device logs into the home network or logs out, the ADEV / DDEV packet is sent to the home station connected to the device to inform other devices of the new device logon or the existing device logout fact. broadcast. Other devices that received this packet delete the address of the corresponding device from the address table they have. The IDEV packet is used when trying to initialize the address table held by the home station devices.

  FIG. 23 is an example of a UHCP (Universal Home Control Protocol) packet. The UHCP packet for controlling the device at home is stacked in the payload of the CP packet, and the management packet field is set to 0xFF as shown in FIG. 11 in order to show that the content loaded in the payload is a device control packet. . The format of the UHCP packet is composed of a 4-byte UHCP header and a payload as shown in FIG.

  The UHCP header field consists of a message type (MT), action type (AT), transaction ID (TID), length field (LEN), and so on. Message type (MT) represents the message type. There are three types of messages: execution (execution, 0x1), inquiry (query, 0x2), and report (notification, 0x3). The action type (AT) explains in detail the behavior of the message. Other actions are defined for each type of message. The transaction ID (TID) is an ID used to distinguish the response message for the corresponding request message when a large number of response messages arrive. The length field (LEN) represents the length of the payload in bytes. Types of UHCP messages include execution messages, inquiry messages, and report messages.

  FIG. 24 shows an example of an execution message. As shown in FIG. 24, there are three types of AT fields, Act, Register, and Response, which are messages used when performing the AT field. An act is a message that causes the device to execute an instruction in the payload, a register is used to register the device's attributes with the home station, and the characteristics are present in the payload. Responses are used for responses to act and register packets.

  FIG. 25 shows an example of a query message. As shown in FIG. 25, the message has four types of AT fields, that is, an act, a device directory, an attribute directory, and a response, and is used when inquiring about the contents of the AT field. The act is used when requesting device status information, the device directory is used when requesting device directory information on the home network, and nothing is loaded in the payload. The attribute directory is used when requesting attribute information, and nothing is loaded in the payload. The response is used to respond to act, device directory, and attribute directory requests.

  FIG. 26 shows an example of a report message (Notification Message). The report message has a structure as shown in FIG. 26, and is used when devices in the home network notify their specific events and alarms. The AT and TID fields are not used.

FIG. 4 is a structural diagram of a common protocol hierarchy according to the present invention. FIG. 4 is an exemplary diagram of an application of a common protocol according to the present invention. FIG. 3 is a structural diagram of a chip set and a home station protocol supporting a common protocol. It is a hierarchy diagram of the protocol of the apparatus which supports a common protocol. FIG. 4 is a structural diagram of a common protocol packet according to the present invention. It is an illustration figure of the structure of an option field. It is an illustration figure of the traffic kind in the detailed content of an option field. It is a definition diagram of a domain network and a cluster network. It is an illustration figure of a packet type in the detailed content of an option field. It is an illustration figure of the management packet kind in the detailed content of an option field. It is an illustration figure of the management packet kind in the detailed content of an option field. It is an illustration figure of the structure of an order field. It is an illustration figure of a device registration related management packet. It is an illustration figure of a home station registration related management packet. It is an illustration figure of an OLIVE-check packet. FIG. 6 is an exemplary diagram of using an OLIVE-check packet. It is an illustration figure of a status report packet. It is an illustration figure of status report packet use. It is an illustration figure of a VOD MPEG stream related packet. It is an illustration figure of the MPEG stream related packet for a broadcast. FIG. 6 is an exemplary diagram of a packet related to a WAN and a stream gateway interface address request. It is an illustration figure of an address table management related packet. It is an illustration figure of a UHCP packet. It is a structure diagram of a UHCP execution message. It is a structure diagram of a UHCP inquiry message. It is a structure diagram of a UHCP report message.

Explanation of symbols

10: Application hierarchy
20: Common protocol layer 30: Representation layer
40: Session hierarchy 50: Transport hierarchy
60: Network layer 70: Data link layer
80: Physical layer 110: Inter-device communication stage using the same protocol 120: Inter-device communication stage using another protocol 130: API providing stage for communication with existing operations 200: Common protocol packet
210: Common protocol header 220: Originating address
230: Destination address 240: Option field
250: field of order 260: length field
270: Reserved field 280: Payload
310: Traffic type field 320: Packet type field
330: Packet management field 410: Sequence number field
420: Last packet field

Claims (42)

  1. In the network protocol layer structure of the OSI standard (OSI 7 layer) that enables communication processing to be divided into layers according to the characteristics of each layer in the middle of two longitudinal users configured in the communication network.
    An application hierarchy at the top of the hierarchy;
    A common protocol layer that enables data communication between heterogeneous protocols next to the application layer;
    An expression layer next to the common protocol layer;
    A session hierarchy next to the representation hierarchy;
    A transport hierarchy next to the session hierarchy;
    A network hierarchy next to the transport hierarchy;
    A data link hierarchy next to the network hierarchy;
    A common protocol layer structure for mutual data transmission between heterogeneous protocols, comprising a physical layer next to the data link layer.
  2. In the network protocol attached to the OSI standard,
    A common protocol layer structure for mutual data transmission between different types of protocols, including a common protocol layer that enables data communication between different types of protocols next to the application layer.
  3.   The network protocol attached to the OSI standard is any one of TCP / IP, IEEE 1394, LonTalk, and Bluetooth protocol for transmitting mutual data between different types of protocols according to claim 2. Common protocol hierarchy.
  4.   3. The heterogeneous model according to claim 1, wherein the common protocol layer performs packet switching, broadcast or multicast, address conversion, device control, packet classification, security, congestion access control, and resource management. A common protocol hierarchy for mutual data transmission between protocols.
  5.   3. The mutual protocol transmission according to claim 1 or 2, wherein the common protocol layer performs an internal interface of quality of service, security and communication management within a home station chip. Common protocol hierarchy for
  6.   OSI standard protocol (OSI 7 layers) Mutually using network protocol layer that allows communication processing to be divided into layers according to the characteristics of each layer in the middle of two longitudinal users configured in a communication network A method for transmitting data between heterogeneous protocols, comprising the step of transmitting data through a common protocol layer for mutual data transmission between different protocols.
  7.   In the mutual data transmission method using the network protocol layer attached to the OSI standard protocol, the method includes a step of transmitting data through a common protocol layer that enables data communication between different types of protocols next to the application layer. Mutual data transmission method between featured heterogeneous protocols.
  8.   The method according to claim 7, wherein the network protocol attached to the OSI standard is one of TCP / IP, IEEE 1394, LonTalk, and Bluetooth protocol.
  9.   The heterogeneous model according to any one of claims 6 to 7, wherein the common protocol layer performs packet switching, broadcast or multicast, address conversion, device control, packet classification, security, congestion access control, and resource management. Mutual data transmission method between protocols.
  10.   The method of claim 6, wherein the common protocol layer performs an internal interface of quality of service, security, and communication management within a home station chip. .
  11.   When data is transmitted through the common protocol layer, communication between devices using a protocol such as a network bypasses the step in which data is transmitted through the common protocol layer. The method according to claim 6, wherein communication between devices using other protocols performs a step of transmitting data through the common protocol layer step.
  12.   12. The step of transmitting data through the common protocol layer supports a step of transmitting data through an application layer of an existing protocol and an application program interface (API) of a standard determined for communication. Mutual data transmission method between different types of protocols described in 1.
  13.   Common for mutual data transmission between heterogeneous protocols, characterized in that it consists of a common protocol header containing information about the packet and a payload with data content in all data units that travel through the network Protocol packet.
  14. The common protocol header is:
    The origin address with information on the origin of the moving signal;
    A destination address with information on the destination of the moving signal;
    Optional fields related to traffic type, packet transmission method and home network management;
    An order field used for segmentation and riosembluri processes;
    A length field with the size of the application data;
    The common protocol packet for mutual data transmission between different types of protocols according to claim 13, comprising a reserved field for future use.
  15.   The common protocol packet for mutual data transmission between different types of protocols according to claim 14, wherein the common protocol header has a size of 16 bytes.
  16.   15. The common protocol packet for mutual data transmission between different types of protocols according to claim 14, wherein the origin address has a size of 3 bytes in the 16-byte common protocol header.
  17.   The common protocol packet for mutual data transmission between heterogeneous protocols according to claim 14, wherein the destination address has a size of 3 bytes in the 16-byte common protocol header.
  18.   The common protocol packet for mutual data transmission between different types of protocols according to claim 14, wherein the option field has a size of 2 bytes in the 16-byte common protocol header.
  19. The option field includes a traffic type field for distinguishing control command data from real-time data and non-real-time data;
    A packet type field that defines how the packet is transmitted;
    A management packet field for home network management provided by a common protocol;
    The common protocol packet for mutual data transmission between different types of protocols according to claim 14, wherein the common protocol packet is configured as follows.
  20.   The common protocol packet for mutual data transmission between different types of protocols according to claim 19, wherein the traffic type field has a size of 3 bits in the 2-byte option field.
  21.   The common protocol packet for mutual data transmission between different types of protocols according to claim 19, wherein the packet type field has a size of 5 bits in the 2-byte option field.
  22.   The common protocol packet for mutual data transmission between different types of protocols according to claim 19, wherein the management packet field has a size of 8 bits in the 2-byte option field.
  23. The management packet field includes
    A device registration packet that provides the PnP function of the devices;
    A home station registration packet that provides the PnP function of the home stations;
    Orlive-check packet that confirms the presence or absence of device or RG operation in the home network;
    A status report packet that checks the status of the device that received the status report request and sends the result;
    A VOD MPEG stream-related packet that responds to a request for a device requesting VOD stream service;
    A broadcast MPEG stream related packet that responds to a request for a device requesting a broadcast stream service;
    WAN and stream gateway interface address request related packets for which the home station automatically informs the gateway interface address of the device;
    20. The heterogeneous protocol protocol according to claim 19, comprising: an address table management-related packet for adding, deleting, and initializing a new device to a home station connected to the device. Between common protocol packets for mutual data transmission.
  24. The device registration packet is a DRREQ packet that the device sends to the home station when the device starts;
    24. A common protocol packet for mutual data transmission between different types of protocols according to claim 23, comprising: a DRRES packet sent to a device when a home station receives the DRREQ packet.
  25. The home station registration packet is:
    An HRSREQ packet requesting the start of home station registration;
    HRSRES packet responding to start request for home station registration;
    An HRREQ packet requesting home station registration;
    An HRRES packet responding to the home station registration request;
    24. A common protocol packet for mutual data transmission between different types of protocols according to claim 23, comprising: an HRIND packet indicating home station registration.
  26. The OLIVE-check packet is
    An ACREQ packet requesting confirmation that the device is operating;
    24. The common protocol packet for mutual data transmission between different types of protocols according to claim 23, comprising an ACRES packet that responds whether the device is logged on to the home network.
  27. The status report packet is:
    An RSREQ packet containing the status report requirements and data for the requirements;
    An RSRES packet containing the result of checking the status of the device for the requested item;
    24. The common protocol packet for mutual data transmission between different types of protocols according to claim 23, comprising RSIND packet for sending an emergency situation of the device to the home station.
  28. The VOD MPEG stream related packet is
    VODREQ packet requesting VOD MPEG stream service;
    A VODRES packet responding to the VOD MPEG stream service;
    The common protocol packet for mutual data transmission between different types of protocols according to claim 23, comprising a VODSTR packet loaded with an MPEG stream in a payload.
  29. The broadcast MPEG stream related packet is:
    A BRCTREG packet requesting a broadcast MPEG stream service;
    BRCTRES packet that responds to the broadcast MPEG stream service;
    The common protocol packet for mutual data transmission between different types of protocols according to claim 23, comprising a BRCTSTR packet loaded with an MPEG stream in a payload.
  30. The WAN and stream gateway interface address request related packets are:
    A WGIREQ packet requesting the address of the WAN gateway interface;
    WGIRES packets responding to WAN gateway interface address requests;
    A WGIIND packet that initializes the address of the WAN gateway interface;
    An SGIREQ packet requesting a stream gateway interface address;
    A SGIRES packet in response to a stream gateway interface address request;
    24. The common protocol packet for mutual data transmission between different types of protocols according to claim 23, comprising: a SGIIND packet for initializing an address of a stream gateway interface.
  31. The address table management related packet is:
    An ADEV packet that informs the home station of the logon of the new device;
    A DDEV packet that informs the home station of the new device logout;
    The common protocol packet for mutual data transmission between different types of protocols according to claim 23, comprising an IDEV packet for initializing an address table possessed by devices of the home station. .
  32.   14. The common protocol packet for mutual data transmission between different types of protocols according to claim 13, wherein the payload carries a UHCP packet for controlling a device.
  33. The header field of the UHCP packet is:
    A message type representing the message type;
    An action type that details the message behavior;
    A transaction ID that distinguishes when two messages arrive;
    33. The common protocol packet for mutual data transmission between different types of protocols according to claim 32, comprising: a length field representing the length of the payload.
  34. The message type is
    Execution message used when performing action type fields;
    An inquiry message used when querying the action type field;
    A report message used to notify events and alarms of devices in the home network;
    34. A common protocol packet for mutual data transmission between different types of protocols according to claim 33.
  35. The execution message is:
    An act that causes the device to execute the instructions in the payload;
    A register used to register device attributes with the home station;
    35. The common protocol packet for mutual data transmission between different types of protocols according to claim 34, wherein the act includes a response used for a response to the register packet.
  36. The inquiry message is:
    Acts used when requesting device status information;
    A device directory used when requesting device directory information;
    An attribute directory to be used when requesting attribute information;
    35. The common protocol packet for mutual data transmission between different types of protocols according to claim 34, comprising: a response used to respond to an act, a device directory, and an attribute directory request.
  37.   The common protocol packet for mutual data transmission between heterogeneous protocols according to claim 14, wherein the order field has a size of 1 byte in the 16-byte common protocol header.
  38.   38. The sequence field includes a sequence number field that is a segmentation and a last packet field that informs that the last packet is transmitted. Common protocol packet for.
  39.   The common protocol packet for mutual data transmission between different types of protocols according to claim 38, wherein the sequence number field has a size of 7 bits in the one byte order field.
  40.   The common protocol packet for mutual data transmission between different types of protocols according to claim 38, wherein the last packet field has a size of 1 bit in the 1-byte order field.
  41.   The common protocol packet for mutual data transmission between different types of protocols according to claim 14, wherein the length field has a size of 1 byte in the 16-byte common protocol header.
  42.   The common protocol packet for mutual data transmission between heterogeneous protocols according to claim 14, wherein the reserved field has a size of 5 bytes in the 16-byte common protocol header.
JP2004555107A 2002-11-25 2003-11-25 Common protocol layer structure, data transmission method and common protocol packet for mutual data transmission between different protocols Active JP4577683B2 (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
KR20020073667A KR100477513B1 (en) 2002-11-25 2002-11-25 Architecture and method of a common protocol for transferring data between different network protocols and a common protocol packet
PCT/KR2003/002542 WO2004049671A1 (en) 2002-11-25 2003-11-25 Common protocol layer architecture and methods for transmitting data between different network protocols and a common protocol packet

Publications (2)

Publication Number Publication Date
JP2006503513A true JP2006503513A (en) 2006-01-26
JP4577683B2 JP4577683B2 (en) 2010-11-10

Family

ID=36094034

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2004555107A Active JP4577683B2 (en) 2002-11-25 2003-11-25 Common protocol layer structure, data transmission method and common protocol packet for mutual data transmission between different protocols

Country Status (7)

Country Link
US (1) US7882254B2 (en)
EP (1) EP1566036A4 (en)
JP (1) JP4577683B2 (en)
KR (1) KR100477513B1 (en)
CN (1) CN1742473B (en)
AU (1) AU2003282427A1 (en)
WO (1) WO2004049671A1 (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101617651B1 (en) 2014-06-23 2016-05-03 주식회사 에스크레인 Data transffer system and method between heterogeneous systems using transaction editor

Families Citing this family (39)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7334217B2 (en) * 2003-04-02 2008-02-19 Microsoft Corporation Ejection failure mechanism
CN1833403B (en) * 2003-08-08 2011-05-25 小川惠子 Communication system, communication device and communication method
US8296436B2 (en) * 2004-03-22 2012-10-23 Nokia Corporation Conveying parameters for broadcast/multicast sessions via a communication protocol
KR100611173B1 (en) * 2004-06-04 2006-08-10 삼성전자주식회사 Method for transmitting of control data in image processing system with set top box
KR100636380B1 (en) 2004-12-17 2006-10-19 한국전자통신연구원 Homenetwork Universal Middleware Bridge System and Method for home device's Interoperability in Heterogeneous Home Network Middleware
KR100673687B1 (en) * 2005-03-02 2007-01-24 엘지전자 주식회사 Home network system
US8205013B2 (en) * 2005-05-02 2012-06-19 Samsung Electronics Co., Ltd. Method and system for aggregating the control of middleware control points
KR100750880B1 (en) * 2005-12-28 2007-08-22 전자부품연구원 Switching system and its mechanism which enables data-switching of variable-length packets and heterogeneous network packets
KR20070078862A (en) 2006-01-31 2007-08-03 삼성전자주식회사 Method of providing interoperatibility of heterogeneous network devices capable of error handling and network device using the same
KR100789755B1 (en) * 2006-07-12 2008-01-02 인제대학교 산학협력단 Communication apparatus for using common platform adapted multi-protocol in wireless personal area network and method thereof
KR100836739B1 (en) * 2006-12-02 2008-06-10 한국전자통신연구원 Apparatus and method for mapping logical-physical connection of robot device
US8233470B2 (en) * 2007-06-28 2012-07-31 Intel Corporation Multi-radio wireless communication device method for synchronizing wireless network and bluetooth communications
US7725118B2 (en) * 2007-08-22 2010-05-25 Intel Corporation Multi-radio wireless communication device and method for coordinating communications between potentially interfering radios
WO2009143044A2 (en) * 2008-05-19 2009-11-26 Citrix Systems, Inc. Methods and systems for enabling features provided by a first presentation layer protocol in a session implemented according to a second presentation layer protocol
US8549093B2 (en) * 2008-09-23 2013-10-01 Strategic Technology Partners, LLC Updating a user session in a mach-derived system environment
KR101753195B1 (en) * 2010-07-27 2017-07-19 아주대학교산학협력단 Apparatus and method to control session connection in a communication system
US8908531B2 (en) * 2011-08-25 2014-12-09 At&T Mobility Ii Llc Communication gateway for facilitating communications with a supervisory control and data aquisition system
CN102325146A (en) * 2011-10-28 2012-01-18 武汉杰瑞诚光电科技有限公司 Universal data exchange (UDX) protocol stack, and UDX-protocol-based data transmission system and method
US9178792B2 (en) * 2011-11-16 2015-11-03 Tektronix, Inc. Protocol sensitive visual navigation apparatus
CN102647326B (en) * 2012-04-25 2016-01-20 成都思晗科技有限公司 The communication system of cross-region Zigbee network equipment room
CN102612168B (en) * 2012-04-25 2014-09-24 成都思晗科技有限公司 ZStack (Zigbee Protocol Stack)-based heterogeneous network data interaction method
CN102625476B (en) * 2012-04-25 2015-05-13 成都思晗科技有限公司 System for communicating Zigbee equipment with TCP/IP (Transmission Control Protocol/Internet Protocol) equipment
CN103632453A (en) * 2012-08-27 2014-03-12 广州市德信四海电子科技有限公司 Electronic clearing system of recreation facility
CN103281291B (en) * 2013-02-19 2016-04-20 电子科技大学 A kind of application protocol recognition method based on Hadoop
US9398121B1 (en) * 2013-06-24 2016-07-19 Amazon Technologies, Inc. Selecting among virtual networking protocols
US20160021143A1 (en) * 2014-07-21 2016-01-21 David Browning Device federation
KR20160025996A (en) * 2014-08-28 2016-03-09 삼성전자주식회사 Electronic apparatus and method for ip network service
KR101669518B1 (en) * 2014-12-30 2016-10-27 주식회사 시큐아이 Apparatus and method for managing network module based on software defined network
CN104767734A (en) * 2015-03-18 2015-07-08 欧普照明股份有限公司 Network communication system
US10348798B2 (en) 2015-08-05 2019-07-09 Facebook, Inc. Rules engine for connected devices
US10425392B2 (en) 2015-08-05 2019-09-24 Facebook, Inc. Managing a device cloud
US20170041381A1 (en) * 2015-08-05 2017-02-09 Facebook, Inc. Managing a Device Cloud
US10412160B2 (en) 2015-08-05 2019-09-10 Facebook, Inc. Controlling a device cloud
US10541958B2 (en) 2015-08-05 2020-01-21 Facebook, Inc. Controlling a device cloud
US10404832B2 (en) 2015-08-31 2019-09-03 Ayla Networks, Inc. Management of gateway device using virtual gateway device
US10484512B2 (en) * 2015-08-31 2019-11-19 Ayla Networks, Inc. Management of multi-radio gateway device using virtual gateway device
US10432754B2 (en) 2015-09-16 2019-10-01 Profire Energy, Inc Safety networking protocol and method
US10514683B2 (en) 2015-09-16 2019-12-24 Profire Energy, Inc. Distributed networking system and method to implement a safety state environment
CN107277153A (en) * 2017-06-30 2017-10-20 百度在线网络技术(北京)有限公司 Method, device and server for providing voice service

Family Cites Families (25)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH03278260A (en) * 1990-03-28 1991-12-09 Sharp Corp High-speed communication control equipment
US5251205A (en) * 1990-09-04 1993-10-05 Digital Equipment Corporation Multiple protocol routing
US5619650A (en) * 1992-12-31 1997-04-08 International Business Machines Corporation Network processor for transforming a message transported from an I/O channel to a network by adding a message identifier and then converting the message
US5774695A (en) 1996-03-22 1998-06-30 Ericsson Inc. Protocol interface gateway and method of connecting an emulator to a network
US5852660A (en) 1996-04-10 1998-12-22 Ericsson Inc. Network protocol conversion module within a telecommunications system
US5999565A (en) * 1997-10-15 1999-12-07 Cisco Technology, Inc. Data communication using a modifiable number of XDSL modems
KR100250991B1 (en) * 1997-12-31 2000-04-15 이계철 Method of interfacing between networks
US6141686A (en) * 1998-03-13 2000-10-31 Deterministic Networks, Inc. Client-side application-classifier gathering network-traffic statistics and application and user names using extensible-service provider plugin for policy-based network control
JP3464907B2 (en) * 1998-03-20 2003-11-10 富士通株式会社 Protocol conversion system
US6154446A (en) * 1998-07-08 2000-11-28 Broadcom Corporation Network switching architecture utilizing cell based and packet based per class-of-service head-of-line blocking prevention
JP3609948B2 (en) * 1998-12-11 2005-01-12 株式会社日立製作所 Multiprotocol network management method, multiprotocol network management proxy server system, multiprotocol address management server system, and multiprotocol network management system
US7159030B1 (en) * 1999-07-30 2007-01-02 Intel Corporation Associating a packet with a flow
US7703102B1 (en) * 1999-08-23 2010-04-20 Oracle America, Inc. Approach for allocating resources to an apparatus based on preemptable resource requirements
US6804776B1 (en) * 1999-09-21 2004-10-12 Cisco Technology, Inc. Method for universal transport encapsulation for Internet Protocol network communications
US7082140B1 (en) * 2000-03-17 2006-07-25 Nortel Networks Ltd System, device and method for supporting a label switched path across a non-MPLS compliant segment
FI113606B (en) * 2000-05-03 2004-05-14 Nokia Corp Procedure for conveying messages, communication systems and terminal
US6820120B1 (en) * 2000-09-15 2004-11-16 Nortel Networks Limited Routing of data packets in heterogeneous networks
US6901052B2 (en) * 2001-05-04 2005-05-31 Slt Logic Llc System and method for policing multiple data flows and multi-protocol data flows
US7209962B2 (en) * 2001-07-30 2007-04-24 International Business Machines Corporation System and method for IP packet filtering based on non-IP packet traffic attributes
US20030225887A1 (en) * 2002-05-28 2003-12-04 Rene Purnadi Establishing IP level connectivity by use of L-2 dormant mobile node activation
US7239613B1 (en) * 2002-07-30 2007-07-03 Nortel Networks Limited Selective purging of routing data packets in a network
US7636722B2 (en) * 2003-02-28 2009-12-22 Bea Systems, Inc. System and method for describing application extensions in XML
US7191248B2 (en) * 2003-08-29 2007-03-13 Microsoft Corporation Communication stack for network communication and routing
US7644432B2 (en) * 2003-10-10 2010-01-05 Bea Systems, Inc. Policy inheritance through nested groups
US7584274B2 (en) * 2004-06-15 2009-09-01 International Business Machines Corporation Coordinating use of independent external resources within requesting grid environments

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101617651B1 (en) 2014-06-23 2016-05-03 주식회사 에스크레인 Data transffer system and method between heterogeneous systems using transaction editor

Also Published As

Publication number Publication date
JP4577683B2 (en) 2010-11-10
EP1566036A1 (en) 2005-08-24
KR100477513B1 (en) 2005-03-17
KR20040045806A (en) 2004-06-02
US7882254B2 (en) 2011-02-01
EP1566036A4 (en) 2006-12-20
AU2003282427A1 (en) 2004-06-18
WO2004049671A1 (en) 2004-06-10
US20060053229A1 (en) 2006-03-09
CN1742473B (en) 2012-02-01
CN1742473A (en) 2006-03-01

Similar Documents

Publication Publication Date Title
EP1049293B1 (en) Home network gateway
JP3688464B2 (en) Terminal device, server device, communication device, and control method
DE69738560T2 (en) Data transmission control apparatus, relay apparatus and home network control apparatus
US7257821B2 (en) Accessing an in home network through the internet
US6523064B1 (en) Network gateway for collecting geographic data information
US7177325B2 (en) Operations, administration and maintenance (OAM) systems and methods for packet switched data networks
US8473617B2 (en) Media client architecture for networked communication devices
US6160796A (en) Method and system for updating device identification and status information after a local bus reset within a home audio/video network
KR100560549B1 (en) Digital television apparatus for controlling a peripheral device via a digital bus
US7324531B2 (en) Gateway enabling data communication between devices having different middlewares
KR100818809B1 (en) Universal plug-and-play upnp mirroring device
CN101627601B (en) A method and apparatus for remote access to a home network
US6038625A (en) Method and system for providing a device identification mechanism within a consumer audio/video network
EP1049291B1 (en) Remote monitoring and control
US20040078473A1 (en) Information processing apparatus, information processing method, and transmitting medium
CN1183717C (en) Methods for bridging HAVi sub-network and UPnP sub-network and device for implementing said method
KR100657010B1 (en) MULTIMEDIA SERVICE APPARATUS AND METHOD FOR MULTIMEDIA SERVICE PROVIDERS OUTSIDE HOME TO UPnP DEVICES INSIDE HOME USING HOME GATEWAY AND SERVICE GATEWAY PLATFORM
US6885643B1 (en) Method and device for facilitating efficient data transfer via a wireless communication network
EP0848527A1 (en) Method of transferring connection management information in world wide web requests and responses
US20060184661A1 (en) Peer networking host framework and hosting API
CN100508480C (en) Apparatus and method relating to Ethernet access system
JP2005507593A (en) System, method and data structure for multimedia communication
CN1186903C (en) Dynamic network configuration for one-way adapter
CN100493091C (en) Flow-media direct-broadcasting P2P network method based on conversation initialization protocol
EP1050996B1 (en) Command and control transfer

Legal Events

Date Code Title Description
A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20061024

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20070124

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20070320

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20070717

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A821

Effective date: 20070717

A911 Transfer of reconsideration by examiner before appeal (zenchi)

Free format text: JAPANESE INTERMEDIATE CODE: A911

Effective date: 20070821

A912 Removal of reconsideration by examiner before appeal (zenchi)

Free format text: JAPANESE INTERMEDIATE CODE: A912

Effective date: 20070921

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20100308

A602 Written permission of extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A602

Effective date: 20100311

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20100405

A602 Written permission of extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A602

Effective date: 20100408

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20100507

A602 Written permission of extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A602

Effective date: 20100512

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20100604

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20100817

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130903

Year of fee payment: 3

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250