WO2013069217A1

WO2013069217A1 - Station device and transaction relay method

Info

Publication number: WO2013069217A1
Application number: PCT/JP2012/006787
Authority: WO
Inventors: 西岡　伸一郎; 諭千賀; 太田　雄策
Original assignee: パナソニック株式会社
Priority date: 2011-11-09
Filing date: 2012-10-23
Publication date: 2013-05-16

Abstract

A station device that is capable of improving the communication speed of a transaction between a remote network and a memory device placed on a local bus. A station (340) comprises: a local bus interface (341) for connection to a local bus; a station-to-station network interface (342) for connection to a remote network; a logical connection management unit (344) that establishes a logical connection between the remote network and the memory device, said connection not being via a host device; a transaction relay unit (345) that uses the logical connection to relay the transaction between the remote network and the memory device; and a receiving emulation unit (346) that receives a trigger from the host device, and generates a pseudo-remote transaction that emulates access from the remote network to the memory device.

Description

Station apparatus and transaction relay method

The present invention relates to a station device and a transaction relay method for relaying a transaction between a local bus in which a host device and a memory device are arranged and a remote network.

Conventionally, large-capacity content has been moved between various AV (Audio Video) devices in an office or home. The AV device is, for example, a PC (Personal Computer), a mobile phone, a digital still camera, or a BD (Blu-ray Disk) recorder. For moving content between AV devices, PAN (Personal Area Network) based on wired communication such as USB (Universal Serial Bus) or bridge media (Bridge Media) such as an SD memory card is used.

However, the conventional USB or SD memory card requires cable connection or card insertion / extraction. On the other hand, from the viewpoint of improving the usability of devices, wireless connection between AV devices is required.

For this reason, for example, a wireless USB in which the physical layer of the USB is made wireless has already been standardized (see Non-Patent Document 1). In addition, as a bridge medium such as an SD memory card, a product incorporating a wireless LAN (Local Area Network) conforming to the IEEE 802.11 system standard (see Non-Patent Document 2) has appeared (see Non-Patent Document 3).

Also, in wireless communication, as another viewpoint for improving the usability of devices, a communication speed comparable to wired communication is required in order to reduce user communication waiting time.

Therefore, for example, standardization of a wireless PAN technology using a millimeter wave in a 60 GHz band is performed assuming replacement of wired PAN usage exceeding 1 Gbps such as USB 3.0.

Specifically, this standardization is performed by IEEE 802.15.3C or Wireless Gigbit (WiGig) Alliance. In particular, WiGig Alliance defines an extended MAC layer that is backward compatible with the existing IEEE 802.11 system MAC layer.

Furthermore, in WiGig Alliance, IO-PAL (Protocol Adaptation Layer) is being formulated as an upper layer in order to adapt the protocol of the IO bus such as USB or PCI Express.

The standardization of high-speed wireless is expected to spread because the various IO architectures described above facilitate the wireless connection of the existing IO bus protocol.

As a conventional technique for expanding a network by such wireless connection, there is a technique in which a wireless node connected to a wired network collects and stores other node information and discloses it to a connected wireless device. (See Patent Document 1).

According to such conventional technology, a user of a wireless device can search and access content in a storage connected to a wired network, for example, without being aware of physical connection. In wireless connection between a wireless device and a wireless node, high-speed communication with reduced protocol conversion overhead is possible by using a protocol suitable for a wired network, such as IO-PAL shown above. .

JP 2000-115173 A

However, when the prior art is applied to a bus (wired) that forms a star-type logical topology centering on a host (host device), such as an SD bus in a USB or SD memory card (or SDIO), the following is achieved. It has various problems.

For example, when a wireless node is connected as a device on the bus, the wireless device cannot directly access the memory device on the bus via the wireless node. In this case, the wireless node notifies the host of the bus (hereinafter referred to as “local bus”) to which the wireless device directly accesses an access request to the memory device from the wireless device, and accesses the memory device via the host. There is a need. For this reason, the communication speed is significantly reduced.

An object of the present invention is to improve the communication speed between a remote network and a memory device arranged on a local bus.

A station device of the present disclosure is a station device that relays a transaction between a local bus in which a host device and a memory device are arranged and a remote network, and a local bus interface for connecting to the local bus, and the remote network An inter-station network interface for connecting to the network, a logical connection management unit for establishing a logical connection between the remote network and the memory device without passing through the host device, and the remote network using the logical connection. A transaction relay unit that relays transactions between the remote network and the memory device, and a pseudo-function that emulates access to the memory device from the remote network in response to a trigger from the host device. Has a receiving emulation section for generating a remote transaction, the.

A transaction relay method of the present disclosure is a transaction relay method for relaying a transaction between a local bus in which a host device and a memory device are arranged and a remote network, and the host between the remote network and the memory device. Using a logical connection, establishing a logical connection not via a device, generating a pseudo remote transaction emulating access to the memory device from the remote network in response to a trigger from the host device; And relaying transactions between the remote network and the memory device.

According to the present disclosure, the communication speed of transactions between a remote network and a memory device arranged on a local bus can be improved.

The system block diagram which shows the structure of the communication system containing the station which concerns on one embodiment of this invention The figure which shows typically an example of the logical topology of the communication apparatus in this Embodiment The figure which shows typically the 1st example of the physical topology of the communication apparatus in this Embodiment. The figure which shows typically the 2nd example of the physical topology of the communication apparatus in this Embodiment. The figure which shows an example of the flow of the information in the communication system at the time of the basic mode in this Embodiment The figure which shows an example of the flow of the information in the communication system at the time of the expansion mode in this Embodiment The figure which shows the example of the packet format in the local bus of this Embodiment The figure which shows the example of the packet format in the network between stations of this Embodiment The sequence diagram which shows an example of the flow of the transaction of the local bus in this Embodiment A block diagram showing an example of a configuration of a station according to the present embodiment A flowchart showing an example of the operation of the host in the present embodiment The figure which shows an example of the structure information in this Embodiment A flowchart showing an example of initiator-side device handle setting processing in the present embodiment The flowchart which shows an example of the target side device handle setting process in this Embodiment The flowchart which shows an example of operation | movement of the station in this Embodiment. The flowchart which shows an example of the device handle acquisition process in this Embodiment The figure which shows an example of the transaction relay process in this Embodiment The flowchart which shows an example of the device handle release process in this Embodiment The figure which shows an example of the flow of the information inside the station which concerns on this Embodiment

Hereinafter, an embodiment of the present invention will be described in detail with reference to the drawings.

<Configuration of communication system>
FIG. 1 is a system configuration diagram showing a configuration of a communication system including a station according to an embodiment of the present invention.

1, the communication system 100 includes an inter-station network 200 and an initiator device 300-1 and a target device 300-2 that are connected to the inter-station network 200, respectively.

The inter-station network 200 is, for example, a wireless PAN (PersonalsonArea Network) that uses millimeter waves in a 60 GHz band.

The initiator device 300-1 and the target device 300-2 are communication devices that each include a wired bus and execute a transaction via the inter-station network 200, for example. Here, a communication device that starts a certain transaction is called an initiator device 300-1, and a communication device that is opposite to the initiator is called a target device 300-2. It is assumed that the initiator device 300-1 and the target device 300-2 have the same configuration.

The initiator device 300-1 includes a first bus 310-1, a first memory device 320-1, a first host 330-1, and a first station 340-1. The first memory device 320-1, the first host 330-1, and the first station 340-1 each have a local bus interface (not shown), and the first bus 310-1 Connected to.

The first memory device 320-1 is, for example, a memory device with a built-in nonvolatile memory module capable of writing and reading data.

The first host 330-1 controls the entire initiator device 300-1 including each slave device connected to the first bus 310-1. Here, the slave devices are the first memory device 320-1 and the first station 340-1.

More specifically, the first host 330-1 incorporates a system LSI (Large Scale Integration) for performing such control as a host controller. Then, the first host 330-1 controls each slave device under control from an application operating on a CPU (Central Processing Unit) or control from software such as a device driver.

The first station 340-1 has an inter-station network interface (not shown) that functions in the MAC layer and the PHY layer of the wireless PAN.

The inter-station network interface provides access to the inter-station network 200 via MAC-SAP (Media Access Control Service Access Point). That is, the first station 340-1 connects the initiator device 300-1 and the target device 300-2 using MAC-SAP. Then, the first station 340-1 relays a transaction between the initiator device 300-1 and the target device 300-2.

The target device 300-2 has a second bus 310-2, a second memory device 320-2, a second host 330-2, and a second station 340-2. The second memory device 320-2, the second host 330-2, and the second station 340-2 each have a local bus interface (not shown), and the second bus 310-2. Connected to.

The second memory device 320-2 is, for example, a memory device with a built-in nonvolatile memory module capable of writing and reading data.

The second host 330-2 controls the entire target device 300-2 including each slave device connected to the second bus 310-2. Here, the slave devices are the second memory device 320-2 and the second station 340-2.

The second station 340-2 has an inter-station network interface (not shown) that functions in the MAC layer and the PHY layer of the wireless PAN.

The inter-station network interface provides access to the inter-station network 200 via MAC-SAP. That is, the second station 340-2 connects the target device 300-2 and the initiator device 300-1 using MAC-SAP. Then, the second station 340-2 relays the transaction between the target device 300-2 and the initiator device 300-1.

Hereinafter, the common part between the initiator device 300-1 and the target device 300-2 will be appropriately referred to as “communication device 300”. Further, the communication device 300 including the device to be described is appropriately represented as “local communication device 300l”. The communication device 300 (that is, the remote network) that does not include the device to be described is appropriately represented as “remote communication device 300r” (see FIG. 10).

The common part between the first bus 310-1 and the second bus 310-2 is appropriately represented as “bus 310”. In view of the device to be described, the bus 310 included in the local communication device 300l is appropriately expressed as “local bus 310l”. From the viewpoint of the device to be described, the bus 310 included in the remote communication device 300r is appropriately expressed as “remote bus 310r” (see FIG. 10).

The common part between the first memory device 320-1 and the second memory device 320-2 is appropriately expressed as “memory device 320”. Further, from the viewpoint of the device to be described, the memory device 320 included in the local communication device 300l is appropriately expressed as “local memory device 320l”. From the viewpoint of the device to be described, the memory device 320 included in the remote communication device 300r is appropriately represented as “remote memory device 320r” (see FIG. 10).

The common part between the first host 330-1 and the second host 330-2 is appropriately expressed as “host 330”. Further, when viewed from the device to be described, the host 330 included in the local communication device 300l is appropriately expressed as “local host 330l”. From the viewpoint of the device to be described, the host 330 included in the remote communication device 300r is appropriately expressed as “remote host 330r” (see FIG. 10).

The common part between the first station 340-1 and the second station 340-2 is appropriately expressed as “station 340”. Further, when viewed from the device to be described, the station 340 included in the local communication device 300l is appropriately expressed as “local station 340l”. From the viewpoint of the device to be described, the station 340 included in the remote communication device 300r is appropriately expressed as “remote station 340r” (see FIG. 10).

Further, each of the initiator device 300-1 and the target device 300-2 may include slave devices other than those shown in FIG.

FIG. 2 is a diagram schematically showing an example of the logical topology of the communication device 300 (the initiator device 300-1 and the target device 300-2) in the basic mode. Here, the other slave devices described above are also illustrated.

As shown in FIG. 2, the logical topology 420 of the communication device 300 is a star type centered on the host 330. That is, in the communication device 300, communication is basically performed under the initiative of the host 330.

For example, the host 330 assigns a device ID that is an address in the local bus 310l to each of the slave devices # 1 to #N when the local communication device 300l is initialized.

Here, the slave devices # 1 to #N include a local station 340l and a local memory device 320l. As the device ID, for example, “0” is always assigned to the host 330, and another unique value is assigned to other slave devices. Thereafter, the host 330 starts communication with the communication target slave device by transmitting a command in which the device ID of the communication target slave device is embedded in the destination field.

Here, in the communication apparatus 300, only the host 330 basically has the command transmission right. For this reason, the host 330 detects a transmission request from each slave device by polling or interruption with each slave device, and transmits a command in response to detection of the transmission request. That is, in the basic mode, transactions with the local memory device 320l via the local bus 310l are always performed via the local host 330l.

3 and 4 are diagrams schematically showing an example of the physical topology of the communication device 300 for realizing the logical topology shown in FIG.

As shown in FIG. 3, the physical topology 410 of the communication device 300 can take, for example, a hub configuration. Further, as illustrated in FIG. 4, the physical topology 410 of the communication device 300 may take, for example, a ring configuration.

In the case of the hub configuration shown in FIG. 3, the command transmitted from the host 330 is distributed by the hub 421 to a slave device corresponding to the destination field among the plurality of slave devices # 1 to #N. In the case of the ring configuration shown in FIG. 4, the slave device # 1 to #N determines whether the command transmitted from the host 330 should be received or relayed according to the destination field.

The communication system 100 is configured to perform a transaction between the initiator device 300-1 and the target device 300-2 via the inter-station network 200 under the control of the first and second hosts 330-1 and 330-2. Can be executed.

The communication device 300 performs all transactions via the local host 330l as an operation in the basic mode. Further, the communication apparatus 300 according to the present embodiment further realizes a transaction that does not pass through the local host 330l as an operation in the extended mode. The operation in the extended mode is realized by the function of the local station 340l.

<Operation of communication system in basic mode>
First, an outline of the operation of the communication system 100 in the basic mode will be described.

FIG. 5 is a diagram illustrating the flow of information in the communication system 100 in the basic mode. Here, a case where the data of the first memory device 320-1 is written to the second memory device 320-2 will be described as an example.

As described above, since the first host 330-1 is arranged in the initiator device 300-1, it is a host device on the initiator side. Further, as described above, the second host 330-2 is a target-side host device because it is arranged in the target device 300-2.

First, the first host 330-1 transmits a device handle acquisition request (GET_DH_REQ: Get Device Handle Request) to the second host 330-2 (S1010). This device handle acquisition request is for establishing a logical connection with the second memory device 320-2 (target device).

When the request is accepted by the second host 330-2, the first host 330-1 issues a local read command to the first memory device 320-1, and the first memory device 320- Data is read from 1 (S1020). Then, the first host 330-1 issues a remote write command targeting the second memory device 320-2 to the second host 330-2, and transmits the read data (S1030).

Then, the second host 330-2 issues a local write command to the second memory device 320-2, and writes the received data to the second memory device 320-2 (S1040).

As described above, in the basic mode, a transaction between the first memory device 320-1 and the second memory device 320-2 is performed via the first host 330-1 and the second host 330-2. Done.

This completes the description of the outline of the operation of the communication system 100 in the basic mode.

<Operation of communication system in extended mode>
Next, an outline of the operation of the communication system 100 in the extended mode will be described.

FIG. 6 is a diagram showing an example of information flow in the communication system 100 in the extended mode, and corresponds to FIG. In FIG. 6, the information flow is shown in a more detailed manner depending on the protocol layer processed by the station 340.

First, the first host 330-1 transmits a device handle acquisition request (GET_DH_REQ: Get Device Handle Request) to the second host 330-2 (S2010). This device handle acquisition request is for establishing a logical connection with the second memory device 320-2 (target device).

When the request is accepted by the second host 330-2, the second host 330-2 transmits the configuration information of the second memory device 320-2 held by itself to the second station 340-2 ( Target station) is set (S2020). Then, the second host 330-2 delegates the access right to the second memory device 320-2 to the second station 340-2, and thereafter the second memory 330-2 until the access right is released. Access to the device 320-2 is stopped.

The configuration information of the second memory device 320-2 is shared in advance between the second host 330-2 and the second station 340-2 when the target device 300-2 is initialized. Also good. In this case, setting of configuration information here is not necessary.

Similarly, the first host 330-1 sets the configuration information of the first memory device 320-1 (initiator device) held by itself in the first station 340-1 (initiator station) ( S2030). Then, the first host 330-1 delegates the access right to the first memory device 320-1 to the first station 340-1, and thereafter, until the access right is released, Access to the memory device 320-1 is stopped.

The configuration information of the first memory device 320-1 is shared in advance between the first host 330-1 and the first station 340-1 when the initiator device 300-1 is initialized. Also good. In this case, setting of configuration information here is not necessary.

Then, the first host 330-1 transmits a remote write command to the target device 300-2 via the first station 340-1 (S2040).

Then, the second station 340-2 redirects the remote write command as a local write command addressed to the second memory device 320-2 using the set configuration information (S2050). Here, the second memory device 320-2 executes the local write command using the second station 340-2 as a temporary host.

Also, the first host 330-1 accesses the MAC-SAP of the first station 340-1 (S2060). This access is emulated at the first station 340-1 as reception of a remote read command from the second host 330-2.

Then, the first station 340-1 redirects the pseudo remote read command as a local read command addressed to the first memory device 320-1 using the set configuration information (S2070). Here, the first memory device 320-1 executes the local read command using the first station 340-1 as a temporary host.

The first station 340-1 transmits the read data read from the first memory device 320-1 to the target device 300-2 as the write data of the remote write command by the pseudo remote read command (S2080).

Then, the second station 340-2 redirects the write data as local write data addressed to the second memory device 320-2 using the set configuration information (S2090).

Then, the first station 340-1 notifies the first host 330-1 of the completion of the remote write command and the remote read command instructed from the first host 330-1. Then, the first station 340-1 releases the access right of the first memory device 320-1 (S2100).

In response, the first host 330-1 transmits a device handle release request (REL_DH_REQ: Release ： Device Handle Request) to the second host 330-2 (target host) (S2110).

This device handle release request is for releasing the logical connection with the second memory device 320-2 (target device). Here, the second station 340-2 notifies the release of the access right to the first memory device 320-1 when notifying the reception to the second host 330-2.

In addition, when the access right is released by the first station 340-1 and the second station 340-2, the extended mode ends and returns to the basic mode.

As described above, in the extended mode, the transaction between the first memory device 320-1 and the second memory device 320-2 does not pass through the first host 330-1 and the second host 330-2. To be done.

This completes the description of the outline of the operation of the communication system 100 in the extended mode.

The operation in the extended mode is realized by setting the configuration information of each memory device 320 to the corresponding station 340 and emulating remote command reception at the first station 340-1 on the initiator side. Details of these will be described later.

<Communication protocol and packet format>
Next, the communication protocol and packet format of the communication system 100 will be described.

The protocol of the first bus 310-1 included in the initiator device 300-1 and the protocol of the second bus 310-2 included in the target device 300-2 are not necessarily the same. However, by making the both protocols the same, it is possible to reduce the load of protocol conversion when using the inter-station network 200.

Therefore, in the present embodiment, it is assumed that the protocol of the first bus 310-1 and the protocol of the second bus 310-2 are the same.

Packets transmitted and received on the bus 310 are mainly classified into five packet types (detailed types). The five packet types are a control command (CCMD: Control Command), a data command (DCMD: Data Command), a response (RES: Response), data (DATA), and a message (MSG: Message).

The control command is a packet used for register access. The data command is a packet used for bulk data transfer. The response is a packet of a response to the control command or data command. Data is a packet of data transferred with a data command. The message is a packet used for status notification or the like.

In the following, a packet whose packet type is a control command is simply referred to as “control command”, and a packet whose packet type is a data command is simply referred to as “data command”. A packet with a packet type of response is simply called “response”, a packet with a packet type of data is simply called “data”, and a packet with a packet type of message is simply called “message”.

FIG. 7 is a diagram showing an example of a packet format in the bus 310. FIG. 7A shows the packet format of the control command. FIG. 7B shows the packet format of the data command. FIG. 7C shows the packet format of the response. FIG. 7D shows a packet format of data. FIG. 7E shows the packet format of the message.

As shown in FIG. 7A, the control command 510 in the bus 310 includes a header 600, an argument (Argument) 601, and a payload (Payload) 602. The header 600 includes a packet type (TYPE) 610, a destination ID (DID: Destination ID) 611, a transmission source ID (SID: Source ID) 612, and a tag ID (TID: Tag ID) 613.

Packet type 610 indicates the detailed type of the packet. The destination ID 611 and the transmission source ID 612 indicate the destination and transmission source of the packet, respectively, and are specified by the device ID assigned to each slave device. The tag ID 613 is identification information used for associating a command issued to the other slave device from the first and second host hosts 330-1 and 330-2 with a response or data transferred accordingly. It is.

Note that the configuration of the header 600 is the same for packets of other packet types such as data commands. However, the contents of the packet type 610 are different.

The argument 601 of the control command 510 includes an R / W flag 700, a payload length (PLEN) 701, and an IO address 702.

The R / W flag 700 indicates a read or write access type. The payload length 701 indicates the size of the control data. The IO address 702 indicates an address of control data. The payload 602 of the control command 510 includes control data 703 having a size specified by the payload length 701 only when the R / W flag 700 is set to write.

When the R / W flag 700 is set to read, the control data is included in the response to the control command 510. For this reason, the control command 510 does not include control data. The control command 510 may not have the payload 602.

As will be described later, the configuration information of each slave device is held in each slave device as a register that can be specified by the IO address 702. Therefore, the first and second hosts 330-1 and 330-2 can access the configuration information held by each slave device by the control command 510.

For example, the first host 330-1 can read the capability field information from the first memory device 320-1 by the control command 510 with the R / W flag 700 set to read. Further, for example, the first host 330-1 can write information in the setting field of the first station 340-1 by the control command 510 in which the R / W flag 700 is set to write.

As shown in FIG. 7B, the data command 520 on the bus 310 includes a header 600, an argument 601 and an extension argument 603.

The argument 601 of the data command 520 includes an R / W flag 710 indicating a read or write access type. The extension argument 603 includes a memory address 711 that is a data transfer start address and a transfer size 712 that indicates the total size of the data transfer.

As shown in FIG. 7C, the response 530 in the bus 310 includes a header 600, an argument 601, and a payload 602.

The argument 601 of the response 530 includes a NACK (Negative Acknowledge) flag 720 indicating whether or not the device specified by the destination ID 611 has correctly received the control command or the data command. The payload 602 of the response 530 includes the control data 721 read by the control command only when the R / W flag 700 of the control command is set to read.

However, when the R / W flag 700 of the control command is set to write, the control data is included in the control command 510 as described above. For this reason, in such a case, the control data is not included in the response 530. Note that the response 530 may not include the payload 602.

As shown in FIG. 7D, data 540 in the bus 310 includes a header 600 and a payload 602.

The payload 602 of the data 540 includes a data block 730 obtained by fragmenting the data with a predetermined block size. Note that the maximum size of the data block 730 is defined by the maximum packet size (Max Packet Size) included in the configuration information setting field described later (see FIG. 12B).

As shown in FIG. 7E, the message 550 on the bus 310 includes a header 600 and an argument 601.

The argument 601 of the message 550 includes a message category (CTG) 740 indicating a message classification and a message code (CODE) 741 indicating additional information for each message category.

The message category 740 includes, for example, a flow control request (FC_REQ: Flow ： Control Request), a flow control response (FC_ACK: Flow ： Control Acknowledge), a status (STAT: Status), and an interrupt (INT: Interrupt). .

The flow control request and the flow control response are messages of flow control information exchanged between the transmission source and the destination prior to data transfer. The status is a message used to notify a transmission error from the data transfer destination to the transmission source after the data transfer.

Interrupt is a message used to send asynchronous status notifications from the device to the host.

The message code 741 includes, for example, the presence or absence of a reception error in the case of a status message, and the identification number of the interrupt in the case of an interrupt.

In the following, a message whose message category is a flow control request is simply referred to as “flow control request”, and a message whose message category is a flow control response is simply referred to as “flow control response”.

FIG. 8 is a diagram illustrating an example of a packet format in the inter-station network 200.

As shown in FIG. 8, the packet 750 of the inter-station network 200 includes a MAC header 751, a frame body 752, and a frame check sequence (FCS) 753. The frame body 752 further includes a PAL header (PAL Header) 754 and a PAL data payload (PAL Data Payload) 755.

Here, PAL is a protocol conformance layer for transmitting an existing wired interface (USB interface, SD interface, etc.) via wireless MAC / PHY. The functions are classified into a C-Plane (Control Plane) function and a D-Plane (Data Plane) function.

The C-Plane function is a function for managing establishment and release of a logical connection for remote access. The D-Plane function is a function for wirelessly transmitting a packet defined by an existing wired interface as a data payload.

Therefore, the PAL packet type is described in the PAL header 754. The PAL packet type is information for identifying whether the PAL data payload 755 includes a C-Plane function or a D-Plane function.

In the PAL header 754, a device handle ID is also described. The device handle ID is information for identifying a slave device in the target apparatus that is a destination of remote access.

When the PAL packet type indicates C-Plane, the PAL data payload 755 includes DH_ID 761 describing a function code (FCODE: Function Code) indicating the detailed type of the C-Plane function.

Specific examples of the function code include a device handle acquisition request (GET_DH_REQ) and a device handle release request (REL_DH_REQ). The function code further includes a device handle acquisition response (GET_DH_ACK), a device handle release response (REL_DH_ACK), and the like, which are responses to these requests.

Here, in the case of a response packet (device handle acquisition response or device handle release response packet), a result flag (Result) 762 indicating success or failure of device handle acquisition and release is further included.

When the PAL packet type indicates D-Plane, the packet 770 of the bus 310 described in FIG. 7 is stored in the PAL data payload 755.

In the packet 770 wirelessly transmitted via the inter-station network 200 by the D-Plane function, the destination ID 611 or the transmission source ID 612 is appropriately rewritten in the destination station 340. For this reason, the packet 770 does not need to have a particularly significant value in the destination ID 611 or the transmission source ID 612.

Specifically, the station 340 recognizes a slave device that is a remote access destination by the device handle ID in the PAL header, and sets a destination ID 611 corresponding to the slave device. Further, since the station 340 accesses the slave device as a temporary host, the device ID of the station 340 itself is set as the transmission source ID 612.

<Outline of transaction>
Next, an outline of the transaction of the bus 310 in the basic mode will be described.

FIG. 9 is a sequence diagram illustrating the flow of a transaction between the local host 330l and the local memory device 320l on the local bus 310l.

As shown in FIG. 9, the transaction between the local host 330l and the local memory device 320l is divided into a control transaction 810, a data read transaction 820, and a data write transaction 830.

Next, the control transaction 810 will be described.

In the control transaction 810, the local host 330l issues a control command (CCMD) to the local memory device 320l. Then, the local memory device 320l returns a response (RES) to the control command to the local host 330l (see FIGS. 7A and 7C). Thereby, the control transaction 810 is completed.

Here, the control data that the local host 330l writes (writes) to the local memory device 320l is included in the control command. On the other hand, control data that the local host 330l reads (reads) from the local memory device 320l is included in the response.

Next, the data read transaction 820 will be described.

In the data read transaction 820, the local host 330l issues a data command (DCMD) in which the R / W flag 710 is set to “read” addressed to the local memory device 320l. Then, the local memory device 320l returns a response (RES) to this to the local host 330l (see FIG. 7B). As a result, the data read transaction 820 starts the burst transfer 821 of data designated by the data command.

In the burst transfer 821, the local memory device 320l serving as the data transmission source issues a flow control request (FC_REQ) to the local host 330l serving as the data destination when the transmission data is prepared. When the local host 330l is ready to receive data, it returns a flow control response (FC_ACK) to this flow control request to the local memory device 320l. These flow control requests and flow control responses are transmitted and received as messages as described above (see FIG. 7E).

Thereby, the local host 330l and the local memory device 320l can notify each other of the buffer status. Then, the local memory device 320l starts data (DATA) transfer to the local host 330l (see FIG. 7D).

After the data transfer is completed, the local host 330l that is the data destination issues a status (STAT) including the reception result of the data transfer in the message code 741 to the local memory device 320l (see FIG. 7E). . The local memory device 320l receives this status and knows the reception result from the content of the message code 741.

The data read transaction 820 is completed by repeating a series of burst transfers from the flow control request to the status for the size specified by the transfer size 712 of the data command (see FIG. 7B).

Next, the data write transaction 830 will be described.

In the data write transaction 830, the local host 330l issues a data command (DCMD) in which the R / W flag 710 is set to write to the local memory device 320l (see FIG. 7B). The local memory device 320l returns a response (RES) to the local host 330l (see FIG. 7C). As a result, the data write transaction 830 starts a burst transfer 831 of data designated by the data command.

In the burst transfer 831, when the local host 330 l serving as the data transmission source is ready for transmission data, it issues a flow control request (FC_REQ) to the local memory device 320 l serving as the data destination (see FIG. 7E). When the local memory device 320l is ready to receive data, it returns a flow control response (FC_ACK) to the local host 330l.

These flow control requests and flow control responses are transmitted and received as messages as described above (see FIG. 7E). Thereby, the local host 330l and the local memory device 320l can notify each other of the buffer status.

Then, the local host 330l starts data (DATA) transfer to the local memory device 320l (see FIG. 7D).

After the data transfer is completed, the local memory device 320l that is the destination of the data issues a status (STAT) including the reception result of the data transfer in the message code 741 to the local host 330l (see FIG. 7E). . The local host 330l receives this status and knows the reception result from the content of the message code 741.

The data write transaction 830 is completed by repeating a series of burst transfers from the flow control request to the status for the size specified by the transfer size 712 of the data command (see FIG. 7B).

In the data transfer related to read or write, the data of the size specified by the transfer size 712 of the data command (see FIG. 7B) is divided for each maximum packet size (Max Packet Size) of the memory device 320. A predetermined number of the divided data bundled as data packets is transferred in burst transfer units.

Here, the maximum packet size of the memory device 320 and the maximum number of packets that can be included in the burst transfer are defined by the maximum burst transfer number (Max Burst Num) included in the configuration information described later (see FIG. 12B). .

It should be noted that the present embodiment and the modifications described later are not limited to the protocol described in the above packet format and transaction, and different configurations can be considered.

For example, when the bus 310 is USB, the control command and the data command correspond to a token packet in USB. The response and status correspond to a handshake packet in USB. The control transaction corresponds to control transfer in USB. The data transaction corresponds to bulk transfer in USB.

<Station configuration>
Next, the configuration of the station 340 will be described.

FIG. 10 is a block diagram showing an example of the configuration of the station 340. Here, for convenience of explanation, the peripheral device unit of the station 340 (herein referred to as “local station 3401”) to be explained is also illustrated.

10, the local station 340l includes a local bus interface (BUS IF) 341, a network interface (NW IF) 342 between stations (STA), and a control unit 343. The control unit 343 includes a logical connection management unit 344 and a transaction relay unit 345. Further, the local station 340 l has a reception emulation unit 346.

The local bus interface 341 is connected to the local bus 310l.

The inter-station network interface 342 is connected to the remote bus 310r via the inter-station network 200 by connecting to the inter-station network 200.

More specifically, the inter-station network interface 342 includes a PHY layer, a MAC layer, and a PAL layer. Here, the PAL-SAP is a PAL service access point. The PAL layer provides access of the D-Plane function via the PAL-SAP to the control unit 343 which is an upper layer.

The PHY layer, MAC layer, and PAL layer are controlled via PLME (PHY layer management entity), MLME (MAC layer management entity), and PALME (PAL layer management entity), respectively. For example, the C-Plane function in the PAL layer is all controlled via PALME-SAP.

The logical connection management unit 344 accesses the PAL layer via PALME-SAP. Then, the logical connection management unit 344 establishes a logical connection with the memory device (that is, the remote memory device) connected to the local bus (that is, the remote bus 310r) of the opposing communication device. Then, the logical connection management unit 344 transmits a device handle acquisition request (GET_DH_REQ).

Also, the logical connection management unit 344 notifies the local host 330l of the device handle acquisition request (GET_DH_REQ) received from the remote bus 310r via PALME-SAP. Then, the logical connection management unit 344 acquires the configuration information of the local memory device 320l specified by the device handle acquisition request from the local host 330l.

As a result, the local station 340l temporarily becomes the host of the local memory device 320l, and establishes a logical connection between the remote bus 310r and the local memory device 320l without the local host 330l.

The transaction relay unit 345 relays transactions using the logical connection established by the logical connection management unit 344. This transaction is a transaction between the local bus 310l and the remote memory device 320r, or between the remote bus 310r and the local memory device 320l.

For example, it is assumed that the transaction relay unit 345 receives a first local transaction destined for the remote bus 310r from the local host 330l. In this case, the transaction relay unit 345 relays the received first local transaction as the first remote transaction to the remote bus 310r.

Further, it is assumed that the transaction relay unit 345 receives the second remote transaction from the remote bus 310r. The transaction relay unit 345 relays the received second remote transaction as a second local transaction addressed to the local memory device 320l to the local memory device 320l without the local host 330l.

Also, the transaction relay unit 345 handles user data transmitted by a pseudo remote transaction generated by the reception emulation unit 346 described later as user data transmitted by the first remote transaction.

In response to the trigger from the local host 330l, the reception emulation unit 346 generates a pseudo remote transaction that emulates access from the remote bus 310r to the local memory device 320l.

More specifically, the reception emulation unit 346 relays between the PAL and the transaction relay unit 345 using the PAL-SAP as an interface. Furthermore, the reception emulation unit 346 further includes a pseudo reception interface that can be accessed from the local host 330l via the local bus interface 341.

When receiving a trigger from the local host 330l to the pseudo reception interface, the reception emulation unit 346 behaves as if a remote transaction is received via the PAL-SAP to the transaction relay unit 345.

In the present embodiment, the trigger is reception of a data read command for the remote bus 310r or a data write command for the remote bus 310r from the local host 330l. Hereinafter, the data read command and the data write command (hereinafter collectively referred to as “emulation trigger”).

Although not shown, the local station 340l is, for example, a CPU (central processing unit), a storage medium such as a ROM (read only memory) storing a control program, a working memory such as a RAM (random access memory), a communication circuit, and the like Have In this case, the function of each unit described above is realized by the CPU executing the control program.

Such a local station 340l can realize a transaction between the remote bus 310r and the local memory device 320l without using the local host 330l.

Thereby, the local station 340l can improve the communication speed of the transaction between the remote bus 310r and the local memory device 320l.

Also, the local station 340l receives a trigger from the local host 330l and generates a pseudo remote transaction emulating access from the remote bus 310r to the local memory device 320l. Then, the local station 340l transmits the generated pseudo remote transaction to the local memory device 320l.

Thus, regardless of whether the local station 340l is on the target side or the initiator side, the above-described transaction that does not pass through the local host 330l can be realized.

This completes the description of the configuration of the station 340.

Although not shown, similarly, the host 330 includes, for example, a CPU and a storage medium storing a control program, and implements operations described later by executing the control program with the CPU.

<Host operation>
Next, the operation of the host 330 will be described.

FIG. 11 is a flowchart showing an example of the operation of the host 330.

First, in step S3010, the host 330 shares configuration information with each slave device arranged on the local bus 310l including the local memory device 320l, and holds the shared configuration information. As a result, the maximum size of the data block that can be received by each other can be grasped between the host 330 and each slave device, and buffer overflow due to burst transfer can be avoided.

FIG. 12 is a diagram showing an example of the configuration information.

The configuration information is each slave device attribute information such as a descriptor in USB, for example. Specifically, the configuration information includes, for example, a capability field 850 as shown in FIG. 12A and a setting field 860 as shown in FIG. 12B. The capability field 850 indicates the capability of each slave device. A setting field 860 indicates a device ID and communication parameters of the slave device. In FIG. 12, the size (Byte) indicates a data size such as a device type code.

The capability field 850 includes, for example, a device type code (Device Type), a device protocol code (Device Protocol), and a maximum buffer size (Max Buffer Size).

The device type code indicates the type of a slave device such as a wireless IO device (station), a general-purpose IO device, or a memory device. The device protocol code indicates a protocol supported by the slave device. The maximum buffer size indicates the buffer size that the slave device can use for communication with the host 330. The contents of the capability field 850 are described in advance when the slave device is shipped, for example.

The setting field 860 includes, for example, a device ID (Device ID), a maximum packet size (Max Packet Size), and a maximum burst transfer number (Max Burst Num).

The device ID indicates the address of the slave device in the local bus 310l. The maximum packet size indicates the maximum packet size that can be communicated within the local bus 310l. The maximum burst transfer number indicates the maximum number of packets that can be burst transferred within the local bus 310l. Here, the maximum burst transfer size between the host 330 and the slave device is defined by the product of the maximum packet size and the maximum burst transfer number.

The logical connection management unit 344 discloses the information of the capability field 850 held by itself to the local host 330l. Then, the logical connection management unit 344 holds the communication parameters (maximum packet size and maximum burst transfer number) acquired from the host 330 in the corresponding place of the setting field 860.

Here, the host 330 obtains capability field information (device type code, device protocol, maximum buffer size) from the logical connection management unit 344 of the device for each slave device of the memory arranged on the local bus 310l. Then, the host 330 determines the maximum packet size and the maximum burst transfer number within a range that fits in the acquired maximum buffer size. Then, the host 330 sets the determined maximum packet size and maximum burst transfer number in the corresponding part of the logical connection management unit 344 of the local station 330l.

11, the host 330 performs control for initializing the inter-station network 200 with respect to the memory station 340 arranged on the local bus 310l.

In step S3030, the host 330 determines whether there is a device handle acquisition instruction. The device handle acquisition instruction is a transmission instruction of a device handle acquisition request that is performed to the host 330 by a user operation or the like.

If there is no device handle acquisition instruction (S3030: NO), the host 330 proceeds to step S3050 described later. If there is a device handle acquisition instruction (S3030: YES), the host 330 proceeds to step S3040.

In step S3040, the host 330 performs initiator-side device handle setting processing, and proceeds to step S3050.

The initiator-side device handle setting process is a process for causing the communication device 300 to which the host 330 itself belongs to operate as the initiator device 300-1. Further, the initiator side device handle setting process is a process for establishing a logical connection between the target device 300-2 and the local memory device 320l without passing through the local host 330l. Details of the initiator-side device handle setting process will be described later.

In step S3050, the host 330 determines whether a device handle acquisition request has been received from the remote bus 310r.

If the host 330 has not received the device handle acquisition request (S3050: NO), the process proceeds to step S3070 described later. If the host 330 receives a device handle acquisition request (S3050: YES), the host 330 proceeds to step S3060.

In step S3060, the host 330 performs target-side device handle setting processing, and proceeds to step S3030.

The target-side device handle setting process is a process for causing the communication device 300 to which the host 330 itself belongs to operate as the target device 300-2. Furthermore, the target device handle setting process is a process for providing a logical connection between the initiator device 300-1 and the remote memory device 320r without using the remote host 330r. Details of the target device handle setting process will be described later.

In step S3070, the host 330 determines whether there is a device handle release instruction. The device handle release instruction is a device handle release request transmission instruction issued to the host 330 by a user operation or the like.

If there is no device handle release instruction (S3070: NO), the host 330 proceeds to step S3090 to be described later. If the device 330 is instructed to release the device handle (S3070: YES), the host 330 proceeds to step S3080.

In step S3080, the host 330 transmits a device handle release request and proceeds to step S3100 described later. The device handle release request is a request for releasing the logical connection between the host 330 and the remote memory device 320r.

Note that the device handle release request transmitted in step S3080 is sent to the remote host 330r via the local station 340l and the inter-station network 200.

In step S3090, the host 330 determines whether a device handle release request has been received from the remote bus 310r.

If the host 330 has not received the device handle release request (S3090: NO), the process proceeds to step S3120 described later. If the host 330 receives a device handle release request (S3090: YES), the host 330 proceeds to step S3100.

In step S3100, the host 330 instructs the local station 340l to delete (or invalidate) the configuration information of the local memory device 320l. That is, the host 330 controls the update of the configuration information management table that the local station 340l has.

In step S3110, the host 330 transmits a device handle release response, and releases the logical connection between the remote bus 310r and the local memory device 320l.

Note that the device handle release response transmitted in step S3110 is sent to the remote host 330r via the local station 340l and the inter-station network 200.

In step S3120, the host 330 determines whether or not an instruction to end the host operation is given by a user operation or the like.

When the host 330 is not instructed to end the host operation (S3120: NO), the host 330 returns to step S3030. When the host 330 is instructed to end the host operation (S3120: YES), the host 330 proceeds to step S3130.

In step S3130, the host 330 performs control for causing the local station 340l to release the connection of the inter-station network 200, and ends the series of operations.

<Initiator side device handle setting process>
FIG. 13 is a flowchart showing an example of the initiator-side device handle setting process (S3040 in FIG. 11).

First, in step S3041, the host 330 transmits a device handle acquisition request.

Note that the device handle acquisition request transmitted in step S3041 is sent to the remote host 330r via the local station 340l and the inter-station network 200. Here, the local station 340l corresponds to the first station 340-1, and the remote host 330r corresponds to the second host 330-2.

In step S3042, the host 330 determines whether a device handle has already been set for the local memory device 320l (initiator device) specified by the device handle acquisition instruction.

If the device handle has already been set (S3042: YES), the host 330 proceeds to step S3045 described later. If the device handle has not yet been set (S3042: NO), the host 330 proceeds to step S3043.

In step S3043, the host 330 transmits configuration information of the held initiator device (here, the first memory device 320-1) to the local station 340l (here, the first station 340-1). That is, the host 330 controls the update of the configuration information management table that the local station 340l has.

In step S3044, the host 330 delegates the command transmission right to the initiator device to the local station 340l, and the process proceeds to step S3045.

In step S3045, the host 330 transmits an emulation trigger for generating a pseudo remote transaction to the local station 340l. Specifically, the host 330 transmits a data read command or a data write command to the local station 340l as an emulation trigger.

<Target device setting process>
FIG. 14 is a flowchart illustrating an example of the target-side device handle setting process (S3060 in FIG. 11).

First, in step S3061, the host 330 determines whether or not the memory device 320 (target device) specified by the device handle acquisition request exists in the managed local bus 310l. More specifically, the host 330 searches for a target device corresponding to the device handle number included in the device handle acquisition request from the managed slave devices.

When the designated device does not exist (S3061: NO), the host 330 proceeds to step S3062. If the designated device exists (S3061: YES), the host 330 proceeds to step S3063.

In step S3062, the host 330 transmits a device handle acquisition response including a result flag indicating failure in searching for the target device. Here, the device handle acquisition response has contents describing the device ID of the second station 340-2 and the device ID of the second host 330-2 as the destination ID 611 and the transmission source ID 612 (see FIG. 7), respectively. .

In step S3063, the host 330 determines whether a device handle has already been set for the device 320 (target device) specified by the device handle acquisition request.

If the device handle has already been set (S3063: YES), the host 330 proceeds to step S3064. If the device handle has not yet been set (S3063: NO), the host 330 proceeds to step S3065.

In step S3064, the host 330 transmits a device handle acquisition response including a result flag indicating a successful search for the target device. Here, the device handle acquisition response has contents describing the device ID of the second station 340-2 and the device ID of the second host 330-2 as the destination ID 611 and the transmission source ID 612 (see FIG. 7), respectively. .

In step S 3065, the host 330 transmits the configuration information of the held target device (here, the second memory device 320-2) to the local station 340 l (here, the second station 340-2). That is, the host 330 controls the update of the configuration information management table that the local station 340l has.

In step S3066, the host 330 transmits a device handle acquisition response and delegates the command transmission right to the target device to the local station 340l.

The device handle acquisition response transmitted in steps S3662, S3664, and S3666 is sent to the remote host 330r via the local station 340l and the inter-station network 200. Here, the local station 340l corresponds to the second station 340-2, and the remote host 330r corresponds to the first host 330-1.

By such an operation, the host 330 can establish an inter-station network, and can delegate the command transmission right to the local station 340l in response to a request from the remote communication device 300r or the user. Further, when the host 330 is on the initiator side, the pseudo remote transaction can be triggered to the local station 340l after the command transmission right is transferred.

This completes the description of the operation of the host 330.

<Station operation>
Next, the operation of the station 340 will be described.

FIG. 15 is a flowchart showing an example of the operation of the station 340.

First, in step S4010, the logical connection management unit 344 shares configuration information (see FIG. 12) with the host 330.

In step S4020, the logical connection management unit 344 initializes the inter-station network 200 under the control of the host 330. Accordingly, the logical connection management unit 344 establishes a physical connection between the target device 300-1 and the initiator device 300-2.

More specifically, the transaction relay unit 345 establishes a wireless connection (physical connection) with the remote station 340r that faces the remote station 340r by, for example, a procedure similar to the IEEE 802.11 system standard (see Non-Patent Document 2). Establish.

Therefore, the transaction relay unit 345 controls the inter-station network interface 342 to periodically transmit a beacon frame including an SSID (Service Set IDentifier) that identifies a wireless connection.

Then, the transaction relay unit 345 receives the probe request or association request from the opposite station 340 and makes a response to the received probe request or association request.

In step S4030, the logical connection management unit 344 determines whether a device handle acquisition request has been received from the remote host 330r.

If the logical connection management unit 344 has not received the device handle acquisition request (S4030: NO), the logical connection management unit 344 proceeds to step S4050 described later. If the logical connection management unit 3440 receives a device handle acquisition request (S4030: YES), the logical connection management unit 3440 proceeds to step S4040.

In step S4040, the logical connection management unit 344 transfers the device handle acquisition request received from the remote host 330r to the local host 330l. At that time, the logical connection management unit 344 rewrites the destination ID 611 and the transmission source ID 612 (see FIG. 7) of the device handle acquisition request with the device IDs of the local host 330l and the local station 340l, respectively.

Although not shown here, the logical connection management unit 344, when receiving a device handle acquisition response from the local host 330l, transfers it to the remote host 330r.

In step S4050, the logical connection management unit 344 determines whether device configuration information (here, configuration information including the device ID of the local memory device 320l) is received from the local host 330l.

If the logical connection management unit 344 has not received the configuration information (S4050: NO), the logical connection management unit 344 proceeds to step S4070 described later. If the logical connection management unit 344 receives the configuration information (S4050: YES), the logical connection management unit 344 proceeds to step S4060.

In step S4060, the logical connection management unit 344 performs device handle acquisition processing, and proceeds to step S4070. The device handle acquisition process is a process for realizing a transaction between the remote communication device 300r and the local memory device 320l without using the local host 330l. Details of the device handle acquisition process will be described later.

In step S4070, the transaction relay unit 345 performs transaction relay processing. The transaction relay process is a process of relaying a transaction between the local bus 310l and the remote bus 310r using the logical connection established by the logical connection management unit 344. Details of the transaction relay process will be described later.

In step S4080, the logical connection management unit 344 determines whether a device handle release request has been received from the remote host 330r.

If the logical connection management unit 344 has not received the device handle release request (S4080: NO), the logical connection management unit 344 proceeds to step S4100 described later. If the logical connection management unit 3440 receives a device handle release request (S4080: YES), the logical connection management unit 3440 proceeds to step S4090.

In step S4090, the logical connection management unit 344 transfers the device handle release request received from the remote host 330r to the local host 330l. At that time, the logical connection management unit 344 rewrites the destination ID 611 and the transmission source ID 612 (see FIG. 7) of the device handle release request with the device IDs of the local host 330l and the local station 340l, respectively.

Although not shown here, when receiving a device handle release response from the local host 330l, the logical connection management unit 344 transfers it to the remote host 330r.

In step S4100, the logical connection management unit 344 determines whether there is an instruction to delete the device configuration information (here, the configuration information including the device ID of the local memory device 320l) from the local host 330l.

If there is no instruction to delete the configuration information (S4100: NO), the logical connection management unit 344 proceeds to Step S4120 described later. If there is an instruction to delete the configuration information (S4100: YES), the logical connection management unit 344 proceeds to step S4110.

In step S4110, the logical connection management unit 344 performs device handle release processing. The device handle release process is a process for ending the above-described transaction not via the local host 330l. Details of the device handle release process will be described later.

In step S4120, the logical connection management unit 344 determines whether the end of the station operation is instructed by a user operation or the like.

If the logical connection management unit 344 is not instructed to end the station operation (S4120: NO), the logical connection management unit 344 returns to Step 4030. When the logical connection management unit 344 is instructed to end the station operation (S4120: YES), the logical connection management unit 344 proceeds to step S4130.

In step S4130, under the control of the local host 330l, the logical connection management unit 344 releases the connection of the inter-station network 200 and ends the series of operations.

<Device handle acquisition processing>
FIG. 16 is a flowchart illustrating an example of device handle acquisition processing (S4060 in FIG. 15).

First, in step S4061, the logical connection management unit 344 determines whether the device handle of the device specified by the received device handle acquisition request has been acquired. More specifically, the logical connection management unit 344 refers to the held configuration information management table (see FIG. 12) to determine whether configuration information corresponding to the device handle number included in the device handle acquisition request has been acquired. Judging.

When the device handle has been acquired (S4061: YES), the logical connection management unit 344 directly returns to the process of FIG. If the logical connection management unit 344 has not yet acquired the device handle (S4061: NO), the logical connection management unit 344 proceeds to step S4062.

In step S4062, the logical connection management unit 344 stores the configuration information received from the local host 330l in the configuration information management table in association with the device handle number. That is, the logical connection management unit 344 updates the configuration information management table.

In step S4063, the logical connection management unit 344 receives the device handle acquisition response from the local host 330l, takes over the command transmission right to the local memory device 320l, and returns to the processing of FIG.

Note that the logical connection management unit 344 may notify the local host 330l of the device handle acquisition result.

<Transaction relay processing>
FIG. 17 is a diagram illustrating an example of the transaction relay process (S4070 in FIG. 15).

First, in step S4071, the transaction relay unit 345 determines whether either a local command or local data is received.

When the transaction relay unit 345 receives neither a local command nor local data (S4071: NO), the transaction relay unit 345 proceeds to step S4073 described later. If the transaction relay unit 345 receives either a local command or local data (S4071: YES), the transaction relay unit 345 proceeds to step S4072.

In step S4072, the transaction relay unit 345 relays the transaction using the connection established by the logical connection management unit 344, and proceeds to step S4073. For example, the transaction relay unit 345 redirects the local command as a remote command.

In step S4073, the transaction relay unit 345 determines whether either a remote command or remote data has been received.

If the transaction relay unit 345 receives neither the remote command nor the remote data (S4073: NO), the transaction relay unit 345 proceeds to step S4075 described later. If the transaction relay unit 345 receives either the remote command or the remote data (S4073: YES), the transaction relay unit 345 proceeds to step S4074.

In step S4074, the transaction relay unit 345 relays the transaction using the connection established by the logical connection management unit 344, and proceeds to step S4075. For example, when a logical connection not via the local host 330l is established, the transaction relay unit 345 redirects the received remote command to the local memory device 320l as a local command.

In step S4075, the reception emulation unit 346 determines whether an emulation trigger is received from the local host 330l.

The reception emulation unit 346 proceeds to step S4076 when the emulation trigger is received (S4075: YES). If the emulation emulation unit 346 has not received an emulation trigger (S4075: NO), the reception emulation unit 346 directly returns to the process of FIG.

In step S4076, the reception emulation unit 346 emulates the transaction relay unit 345 to receive a remote command. That is, the reception emulation unit 346 generates a pseudo remote command.

As a result, when the processing next proceeds to step S4070 in FIG. 15, the transaction relay unit 345 redirects the pseudo remote command to the local memory device 320l as a local command (S4074).

At this time, the transaction relay unit 345 associates the local read data from the local memory device 320l with the PAL-SAP that transmits the remote write data from the local host 330l.

As a result, when the transaction relay unit 345 receives local read data from the local memory device 320l (S4071: YES), the transaction relay unit 345 transmits it as remote write data from the local host 330l.

<Device handle release processing>
FIG. 18 is a flowchart illustrating an example of the device handle release process (S4110 in FIG. 15).

First, in step S4111, the logical connection management unit 344 determines whether or not the device handle of the device instructed to be deleted from the local host 330l has been acquired. More specifically, the logical connection management unit 344 refers to the held configuration information management table (see FIG. 12) and determines whether or not configuration information corresponding to the device handle number included in the instruction has been acquired. To do.

The logical connection management unit 344 returns to the processing of FIG. 15 as it is when the device handle is not acquired (S4111: NO). If the logical connection management unit 344 has acquired the device handle (S4111: YES), the logical connection management unit 344 proceeds to step S4112.

In step S4112, the logical connection management unit 344 deletes (or invalidates) the configuration information of the device instructed to be deleted from the local host 33l from the configuration information management table. That is, the logical connection management unit 344 updates the configuration information management table.

In step S4113, the logical connection management unit 344 receives the device handle release response from the local host 330l and returns the command transmission right to the local memory device 320l. Also, the logical connection management unit 344 transfers the received device handle release response to the transmission source of the device handle release request.

The logical connection manager 344 may notify the local host 330l of the result of releasing the device handle.

<Flow of information inside the station>
FIG. 19 is a diagram illustrating an example of a flow of information inside the station.

The station 340 acquires configuration information of the local memory device 320l held by the local host 330l (S5010), and establishes a logical connection between the local memory device 320l and the remote communication device 300r. Then, when the first local transaction is started by the local host 330l (S5020), the station 340 issues the first remote transaction to the remote communication device 300r (S5030).

Further, the station 340 receives the second remote transaction from the remote communication device 300r (S5040). Then, the station 340 redirects the received second remote transaction as a second local transaction addressed to the device 320 based on the configuration information of the local memory device 320l (S5050). That is, the station 340 realizes a transaction between the remote communication device 300r and the local memory device 320l without using the local host 330l.

Further, the station 340 generates a pseudo remote transaction emulating reception of the second remote transaction by access from the local host 330l (S5060). As a result, the station 340 redirects the pseudo remote transaction as a third local transaction addressed to the local memory device 320l (S5070).

Then, the station 340 associates the user data transmitted in the second local transaction as user data of the third remote transaction to the remote communication device 300r.

By such an operation, the station 340 can establish a logical connection not via the local host 330l between the local memory device 320l and the remote communication device 300r (S5080, S5090).

Further, the station 340 receives the trigger from the local host 330l and generates a pseudo remote transaction, so that the logical connection can be realized also on the initiator side.

This completes the description of the operation of the station 340.

As described above, the station 340 according to the present embodiment receives the command transmission right delegation. Accordingly, the station 340 can realize a transaction between the remote communication device 300r and the local memory device 320l without passing through the local host 330l.

In the case of the initiator side, the station 340 according to the present embodiment receives a trigger from the local host 330l and generates a pseudo remote transaction. As a result, the station 340 can realize the transaction regardless of whether it is on the target side or on the initiator side.

Therefore, the station 340 can improve the communication speed of the transaction between the remote communication device 300r and the local memory device 320l.

Note that the station 340 may use other service access points such as MAC-SAP (see Non-Patent Document 2) instead of PAL-SAP for emulation of reception of remote transactions.

Further, the station 340 may issue and transmit a request from the local host 330 l such as a device handle acquisition request in response to an instruction from the host 330 instead of transferring (relaying) the request.

Also, when the device handle acquisition request fails, the station 340 may change the device handle number included in the device handle acquisition request and try to acquire the device handle again.

Further, the station 340 may cancel the network connection between stations when the device handle acquisition request fails.

Further, the station 340 may use information other than the device ID as a device handle number included in a device handle acquisition request or the like. In this case, each device device 320 needs to manage the device handle number included in the device handle acquisition request and the device ID of the target device in association with each other.

Further, the station 340 may be configured to include only one of the initiator side function and the target side function, instead of both.

As described above, the station device of the present disclosure is a station device that relays a transaction between a local bus in which a host device and a memory device are arranged and a remote network, and a local bus interface for connecting to the local bus. When,
A network interface between stations for connecting to the remote network, a logical connection management unit for establishing a logical connection between the remote network and the memory device without passing through the host device, and the logical connection, A transaction relay unit that relays transactions between the remote network and the memory device, and a pseudo remote transaction that emulates access to the memory device from the remote network in response to a trigger from the host device And a receiving emulation unit.

In the station apparatus, the logical connection management unit may acquire the configuration information of the memory device from the host apparatus, and establish the logical connection using the acquired configuration information.

In the station device, when the transaction relay unit receives a first local transaction destined for the remote network from the host device, the transaction relay unit transmits the first remote transaction to the remote network, and When the second remote transaction destined for the memory device is received, the second local transaction may be redirected to the memory device without going through the host device.

In the station apparatus, the transaction relay unit may treat user data transmitted by the pseudo remote transaction as user data transmitted by the first remote transaction.

In the station apparatus, the reception emulation unit includes a MAC-SAP or higher-layer service access point for the transaction relay unit, and inputs the pseudo remote transaction to the transaction relay unit using the service access point. May be.

In the station apparatus, the local bus is a connection interface with a wired network, the network interface between stations is a connection interface with a wireless network, and the reception emulation unit is configured to transmit the transaction relay unit to the transaction relay unit. A service access point of a protocol conformance layer between a communication protocol of a wired network and a communication protocol of the wireless network may be included, and the pseudo remote transaction may be input to the transaction relay unit using the service access point.

In the station device, the logical connection management unit establishes the logical connection when there is a request for establishment of the logical connection from the host device or from the remote network, and from the host device or the remote network. When there is a request for releasing the logical connection, the logical connection may be released.

Further, in the station apparatus, when the trigger is a data read command for the remote network, the reception emulation unit generates a data write command from the remote network for the memory device as the pseudo remote transaction, When the trigger is a data write command for the remote network, a data read command from the remote network for the memory device may be generated as the pseudo remote transaction.

A transaction relay method according to the present disclosure is a transaction relay method for relaying a transaction between a local bus in which a host device and a memory device are arranged and a remote network in the station device, the transaction between the remote network and the memory device. In between, establishing a logical connection not through the host device, generating a pseudo remote transaction emulating access to the memory device from the remote network in response to a trigger from the host device; Relaying transactions between the remote network and the memory device using the logical connection.

The disclosure of the specification, drawings and abstract contained in the Japanese application of Japanese Patent Application No. 2011-245513 filed on November 9, 2011 is incorporated herein by reference.

The present invention is useful as a station apparatus and a transaction relay method because the communication speed of transactions between a remote network and a device arranged on a local bus can be improved.

DESCRIPTION OF SYMBOLS 100 Communication system 200 Station network 300 Communication apparatus 300l Local communication apparatus 300r Remote communication apparatus 300-1 Initiator apparatus 300-2 Target apparatus 310 Bus 310-1 1st bus 310-2 2nd bus 310l Local bus 310r Remote bus 320 memory device 320-1 first memory device 320-2 second memory device 320l local memory device 320r remote memory device 330 host 330-1 first host 330-2 second host 330l local host 330r remote host 340 Station 340-1 first station 340-2 second station 340l local station 340r remote station 341 b Local bus interface 342 Inter-station network interface 343 Control unit 344 Logical connection management unit 345 Transaction relay unit 346 Reception emulation unit

Claims

A station device that relays a transaction between a local bus in which a host device and a memory device are arranged and a remote network,
A local bus interface for connecting to the local bus;
An inter-station network interface for connecting to the remote network;
A logical connection management unit that establishes a logical connection between the remote network and the memory device without passing through the host device;
A transaction relay unit that relays transactions between the remote network and the memory device using the logical connection;
A reception emulation unit that receives a trigger from the host device and generates a pseudo remote transaction that emulates access to the memory device from the remote network;
Station device.
The logical connection manager is
Acquiring configuration information of the memory device from the host device, and using the acquired configuration information to establish the logical connection;
The station apparatus according to claim 1.
The transaction relay unit
When a first local transaction destined for the remote network is received from the host device, a first remote transaction is transmitted to the remote network, and a second remote transaction destined for the memory device from the remote network When the second local transaction is redirected to the memory device without going through the host device,
The station apparatus according to claim 1.
The transaction relay unit
Treating user data transmitted by the pseudo remote transaction as user data transmitted by the first remote transaction;
The station apparatus according to claim 3.
The reception emulation unit is
Including a MAC-SAP or higher-layer service access point for the transaction relay unit, and using the service access point, inputting the pseudo remote transaction to the transaction relay unit;
The station apparatus according to claim 1.
The local bus is
A connection interface with a wired network,
The inter-station network interface is
A connection interface with a wireless network,
The reception emulation unit is
A service access point of a protocol conformance layer between the communication protocol of the wired network and the communication protocol of the wireless network for the transaction relay unit, and the pseudo remote transaction is transferred to the transaction relay unit using the service access point input,
The station apparatus according to claim 1.
The logical connection manager is
When there is a request for establishment of the logical connection from the host device or from the remote network, the logical connection is established, and when there is a request for release of the logical connection from the host device or the remote network, the logical connection is established. Disconnect,
The station apparatus according to claim 1.
The reception emulation unit is
When the trigger is a data read command for the remote network, a data write command from the remote network for the memory device is generated as the pseudo remote transaction, and the trigger is a data write command for the remote network. A data read command from the remote network to the memory device is generated as the pseudo remote transaction,
The station apparatus according to claim 1.
A transaction relay method for relaying a transaction between a local bus in which a host device and a memory device are arranged and a remote network,
Establishing a logical connection between the remote network and the memory device without going through the host device;
Generating a pseudo remote transaction that emulates access to the memory device from the remote network in response to a trigger from the host device;
Relaying a transaction between the remote network and the memory device using the logical connection,
Transaction relay method.