JP7353775B2 - Communication device, control method and program for communication device - Google Patents

Description

The present invention relates to a communication device capable of joining and leaving a network, a method of controlling the communication device, and a program.

UPnP (Universal Plug and Play) is one of the network technologies for searching for devices that provide a predetermined service on a network and linking their functions.
In UPnP, a logical unit that provides a predetermined service is called a "service," a logical unit that has one or more services is called a "device," and a logical unit that controls one or more services is called a "service." They are referred to as ``control points.''

When a device defined by UPnP (hereinafter referred to as a "UPnP device") provides a service, the service to be provided can be set in a NOTIFY message as a Network Location Signature (NLS) and transmitted. A UPnP device is given a UUID (Universally Unique Identifier), which is an identifier that uniquely identifies the UPnP device.
When a control point defined by UPnP (hereinafter referred to as "UPnP control point") receives a service from a UPnP device having the same UUID, it can recognize whether the received service is the same based on NLS.

Furthermore, messages are exchanged between the UPnP device and the UPnP control point using SSDP (Simple Service Discovery Protocol). The SSDP:ALIVE message is a message indicating that a UPnP device exists in the UPnP network, and the SSDP:BYEBYE message is a message indicating that the UPnP device is leaving the UPnP network.

Patent Document 1 discloses a communication device that first transmits an SSDP:BYEBYE message and then transmits an SSDP:ALIVE message when a UPnP device participates in a UPnP network. By sending the SSDP:BYEBYE message before the SSDP:ALIVE message, even if the SSDP:BYEBYE message was not received normally when leaving the network last time, communication with the UPnP control point is reset and the connection is re-entered the network. You can participate.

Japanese Patent Application Publication No. 2005-175724

By the way, UPnP allows the combined use of a plurality of different address systems, such as IPv4 and IPv6.
However, when UPnP devices implementing multiple different address systems transmit the same service to a UPnP control point, the following problems may occur. That is, when a UPnP device transmits the same service using multiple address systems, a sequence of an SSDP:BYEBYE message and a subsequent SSDP:ALIVE message are executed for each address system. Here, it is assumed that a sequence is executed in which an SSDP:BYEBYE message in the next address system is transmitted following the SSDP:ALIVE message in the first address system. In this case, the subsequent SSDP:BYEBYE message in the next address system will cause the service that was made available by sending it in the first address system to become unavailable.
In this way, when providing services using a plurality of different address systems, there is a risk that the service may unexpectedly transition to an unavailable state, reducing user convenience.

The present invention has been made in view of the above-mentioned problems, and its purpose is to reduce the possibility that the service will become unintentionally unavailable when services are provided using a plurality of different address systems. There is a particular thing.

In order to solve the above problems, a communication device according to the present invention includes a participation means that sets one or more of first and second address systems to participate in a network, and a communication device that participates in a network joined by the participation means. a first transmitting means for transmitting a presence message to the network indicating that the network exists; a second transmitting means for transmitting a withdrawal message to the network indicating leaving the network; determining means for determining which of the two address systems has been set; and when the determining means determines that both of the first and second address systems have been set, causing the sending means of No. 2 to send the leave message to the network in both the first and second address systems , and after the sending of the leave message in both the first and second address systems is completed; and transmission control means for controlling the first transmission means to transmit the presence message to the network.

According to the present invention, when providing services using a plurality of different address systems, it is possible to reduce the possibility that the services will become unintentionally unavailable.

FIG. 1 is a diagram showing an example of a network configuration of a network system according to an embodiment of the present invention. FIG. 1 is a diagram showing an example of the hardware and functional configuration of a UPnP device according to the present embodiment. FIG. 3 is a diagram showing an example of the hardware and functional configuration of a UPnP control point according to the present embodiment. Diagram showing an example of a device management table managed by a UPnP control point FIG. 3 is a diagram illustrating a message sequence for service provision between a UPnP device and a UPnP control point when they have a plurality of different address systems. 5 is a flowchart illustrating an example of a processing procedure of a service providing process executed by a UPnP device according to the present embodiment. 5 is a flowchart illustrating an example of a processing procedure for controlling a service executed by a UPnP control point according to the present embodiment. FIG. 3 is a diagram showing a message sequence for providing a service between a UPnP device and a UPnP control point in this embodiment. FIG. 3 is a diagram illustrating a description example of an SSDP:BYEBYE message according to the present embodiment. FIG. 3 is a diagram illustrating a description example of an SSDP:ALIVE message according to the present embodiment.

DESCRIPTION OF THE PREFERRED EMBODIMENTS Hereinafter, embodiments for carrying out the present invention will be described in detail with reference to the accompanying drawings. The embodiment described below is an example of means for realizing the present invention, and should be modified or changed as appropriate depending on the configuration of the device to which the present invention is applied and various conditions. It is not limited to the embodiment. Furthermore, not all combinations of features described in this embodiment are essential to the solution of the present invention.

An example in which the communication device is a communication device that complies with UPnP (Universal Plug and Play) and joins or leaves a network defined by UPnP will be described below, but the communication protocol that can be used in this embodiment is UPnP. but not limited to. For example, a communication device may join or leave a network and use another communication protocol that allows functional cooperation with other communication devices.

<Network configuration of this embodiment>
FIG. 1 is a diagram showing an example of a network configuration of a network system according to this embodiment.
The network system in FIG. 1 includes a UPnP device 1, a UPnP control point 2, and an access point 3. The UPnP device 1, the UPnP control point 2, and the access point 3 each have a network interface compliant with Wi-Fi (registered trademark), Bluetooth (registered trademark), or the like.
The UPnP devices 1 are connected to and can communicate with a UPnP control point 2 via an access point 3 via a network defined by UPnP (hereinafter referred to as "UPnP network") 4.

The UPnP device 1 is a device that has a function of operating as a device defined by UPnP, and in this embodiment, a digital still camera (DSC) will be described as an example. However, the UPnP device 1 applicable to this embodiment is not limited to a digital camera, and may be any device that has one or more UPnP services and is connectable to the UPnP network 4. The UPnP device 1 includes, but is not limited to, a digital video camera, a mobile phone, a smartphone, a PC (Personal Computer), a notebook PC, a server, etc., for example.
The UPnP control point 2 is a device having a function of operating as a control point defined by UPnP, and in this embodiment, a PC (Personal Computer) will be described as an example. However, the UPnP control point 2 applicable to this embodiment is not limited to a PC, and may be any device that can control one or more services in UPnP and connect to the UPnP network 4.

The UPnP device 1, which is a digital camera, may operate as a media server defined by the AV Working Committee. The UPnP device 1 has services such as Connection Manager, Content Directory, and AV Transport, and can provide these services to the UPnP control point 2 and other devices.

<Configuration of UPnP device 1>
FIG. 2 is a diagram showing an example of the hardware and functional configuration of the UPnP device 1 according to the present embodiment.
The UPnP device 1 in FIG. 2 includes a CPU 101, a ROM 102, a RAM 103, an operation section 104, a network I/F 105, a drive 106, a display section 107, an optical section 108, an encoding/decoding section 109, and a timer 110. Each part of the UPnP device 1 in FIG. 2 is communicably interconnected by a system bus 111.
Note that the UPnP device 1 does not need to include all of the above modules, and may include additional modules in addition to the configuration shown in FIG. 2.

A CPU (Central Processing Unit) 101 centrally controls operations in the UPnP device 1, and controls each component (102 to 110) via a system bus 111. That is, when executing various processes, the CPU 101 loads necessary programs, etc. from a storage medium such as the ROM 102 or an HDD (Hard Disk Drive: not shown) into the RAM 103, and executes the programs to perform various functional operations. Realize.
A ROM (Read Only Memory) 102 is a nonvolatile memory that stores control programs, parameters, etc. that do not require modification and are necessary for the CPU 101 to execute various processes. Note that these control programs and the like may be stored in an external memory or a removable storage medium (not shown).

In this embodiment, the ROM 102 stores a UUID (Universally Unique Identifier), various network setting parameters, a device description, a service description, and the like. The UUID is an identifier (identification information) that uniquely identifies the UPnP device 1. The device description describes device information specific to the UPnP device 1. The service description describes service information specific to the service that the UPnP device 1 has.
A RAM (Random Access Memory) 103 functions as the main memory, work area, etc. of the CPU 101, and temporarily stores programs and data.

The operation unit 104 includes an imaging button, a button for switching ON/OFF of network participation, a button for switching start/end of UPnP service, a network setting button, and the like.
The network I/F 105 is a network interface for connecting the UPnP device 1 to the UPnP network 4.
The drive 106 writes to and reads from a recording medium.
The display unit 107 displays and outputs the processing results of various processes, such as the operation results of the operating unit 104.
The optical section 108 is composed of an optical lens, a CCD, etc., and captures images such as still images and moving images.

The encoding/decoding unit 109 performs compression encoding/decoding processing on the image supplied by the optical unit 108 .
The timer 110 measures and manages the elapse of time such as processing of a program executed by the CPU 101.
Note that when the UPnP device 1 participates in the UPnP network 4, the user explicitly presses the network participation button to turn it on. On the other hand, when the UPnP device 1 leaves the UPnP network 4, it may be set to the OFF state by pressing the network participation button again, or it may be configured to leave the UPnP network 4 when a power off button or the like is operated. It's okay.

<Configuration of UPnP control point 2>
FIG. 3 is a diagram showing an example of the hardware and functional configuration of the UPnP control point 2 according to the present embodiment.
The UPnP control point 2 in FIG. 3 includes a CPU 201, a ROM 202, a RAM 203, an external storage device 204, a network I/F 205, an input section 206, a display control section 207, and a display section 208. Each part of the UPnP control point 2 in FIG. 3 is communicably interconnected by a system bus 209.
Note that the UPnP control point 2 does not need to include all of the above modules, and may include additional modules in addition to the configuration shown in FIG. 3.

The CPU 201 centrally controls the operations at the UPnP control point 2, and controls each component (202 to 208) via the system bus 209. That is, when executing various processes, the CPU 201 loads necessary programs and the like from the ROM 202 and a storage medium such as an HDD into the RAM 203, and executes the programs to realize various functional operations.
The ROM 202 is a non-volatile memory that stores control programs, parameters, etc. that do not require modification and are necessary for the CPU 201 to execute various processes.
In this embodiment, the ROM 202 stores a boot program, BIOS (Basic Input/Output System), various network setting parameters, device descriptions, device management tables, and the like. Details of this device management table will be described later with reference to FIG.
Note that these control programs and the like may be stored in the external storage device 204.
The RAM 203 functions as the main memory, work area, etc. of the CPU 201, and temporarily stores programs and data.

The external storage device 204 stores an OS, various applications, a program that interprets and executes XML (Extended Markup Language) for functioning as a UPnP control point, various data files, and the like.
The network I/F 205 is a network interface for connecting the UPnP control point 2 to the UPnP network 4.
The input unit 206 includes a pointing device such as a keyboard and a mouse.
The display control unit 207 has a built-in video memory, executes drawing processing on the video memory according to instructions from the CPU 201, reads drawing data from the video memory, and outputs it to the display unit 208 as a video signal.
The display unit 208 receives the video signal from the display control unit 207, and displays data drawn in the video memory as an image based on the received video signal.

Note that the lower layer of the UPnP network 4 between the UPnP device 1 and the UPnP control point 2 may be configured as a wireless network. This wireless network includes a wireless PAN (Personal Area Network) such as Bluetooth (registered trademark), ZigBee (registered trademark), and UWB (Ultra Wide Band). It also includes wireless LAN (Local Area Network) such as Wi-Fi (Wireless Fidelity) (registered trademark) and wireless MAN (Metropolitan Area Network) such as WiMAX (registered trademark). Furthermore, it includes wireless WAN (Wide Area Network) such as LTE/3G.
Alternatively, the lower layer of the UPNP network 2 may be, for example, a wired network such as a wired LAN (Local Area Network) that conforms to a communication standard such as Ethernet (registered trademark). Furthermore, the wireless LAN communication function and the wired LAN communication function may be combined.

<Device management table>
In this embodiment, the UPnP control point 2 stores a device management table in the RAM 203 or the external storage device 204. The device management table is a table used to manage information on the UPnP devices 1 that have services controlled by the UPnP control point 2.
FIG. 4 shows an example of a device management table that stores information on UPnP devices. The device management table 41 in FIG. 4A includes fields of an IP address 42, a UUID 43, an NLS 44, device specific information 45, and a service status 46.

The IP address 42 indicates the IP address assigned to the UPnP device 1. This IP address 42 may be written in either IPv4 or IPv6 address system. The UUID 42 indicates an identifier that uniquely identifies the UPnP device 1. NLS (Network Location Signature) 44 specifies the service provided by UPnP device 1 .
The device specific information 45 indicates the contents of the device description and service description of the UPnP device 1. The service status 46 indicates the status of the service provided by the UPnP device 1. In this embodiment, the service status 46 indicates either "idle" or "busy".
The UPnP control point 2 extracts parameters described in various messages received from the UPnP device 1 and writes values into each field of the device management table 41.

<Providing UPnP services using multiple different address systems>
FIG. 5 shows an example of a conventional message sequence when the UPnP device 1 participates in the network and provides services to the UPnP control point 2 using a plurality of different address systems. The process in FIG. 5 may be started when the power of the UPnP device 1 is turned on.
In S51, the UPnP device 1 performs network settings for participating in the UPnP network 4. Here, it is assumed that network settings for both IPv4 and IPv6 are performed.
In S52, the UPnP device 1 participates in the IPv4 and IPv6 networks.

In S53, the UPnP device 1 starts the UPnP service by pressing the UPnP service start button on the operation unit 104 or the like. Here, it is assumed that the UPnP device 1 starts a UPnP service using both IPv4 and IPv6 address systems.
In FIG. 5, the message transmission sequence is to transmit an SSDP:BYEBYE message followed by an SSDP:ALIVE message using IPv4. The following description assumes that an SSDP:ALIVE message is sent following the SSDP:BYEBYE message using IPv6. The SSDP:ALIVE message is a message indicating that the UPnP device exists in the UPnP network 4, and the SSDP:BYEBYE message is an SSDP message indicating that the UPnP device is leaving the UPnP network 4.

In S54, the UPnP device 1 first transmits an SSDP:BYEBYE message to the UPnP control point 2 using IPv4.
Next, in S55, the UPnP device 1 transmits an SSDP:ALIVE message to the UPnP control point 2 using IPv4.
In S56, the UPnP control point 2 refers to the SSDP:ALIVE message sent in S55 and sends an HTTP GET command to the UPnP device 1 to obtain the device description of the UPnP device 1.
In S57, the UPnP device 1 transmits the device description of the UPnP device 1 to the UPnP control point 2 in response to the HTTP GET command (status code: 200 OK).

In S58, the UPnP control point 2 that has received the device description becomes available for service in the IPv4 address system. Here, the service availability state refers to a state in which the service description of the UPnP device 1 can be obtained based on the contents of the device description.
After the UPnP control point 2 transitions to a service available state using the IPv4 address system in S58, the UPnP device 1 transmits an SSDP:BYEBYE message to the UPnP control point 2 in IPv6 in S59.

As a result of receiving the SSDP:BYEBYE message using IPv6 in S59, the UPnP control point 2 transitions to a state in which services in the IPv4 address system cannot be used in S60. The IPv6 SSDP:BYEBYE message is associated with the UUID and device-specific information of the UPnP device 1 acquired from the IPv4 message. For this reason, an IPv6 SSDP:BYEBYE message with a different address system also changes the IPv4 service to an unusable state.

In S61, the UPnP device 1 transmits an SSDP:ALIVE message to the UPnP control point 2 using IPv6. Note that the NLS of the IPv6 SSDP:ALIVE message transmitted by the UPnP device 1 in S61 is the same value as the NLS of the IPv4 SSDP:ALIVE message transmitted in S55. In this embodiment, services with the same NLS value are treated as the same service.

In S62, the UPnP control point 2 refers to the SSDP:ALIVE message received in S61 and transmits an HTTP GET command to the UPnP device 1 in order to obtain the device description of the UPnP device 1.
In S63, the UPnP device 101 transmits the device description of the UPnP device 1 to the UPnP control point 2 in response to the HTTP GET command (status code: 200 OK).
In S64, the UPnP control point 2 that has received the device description becomes available for service in the IPv6 address system. Note that the service that became available in S64 is the same service that became available once in the IPv4 address system in S58.

In this way, in the above message sequence, the service that was once made available in the IPv4 address system in S58 becomes unavailable in S60 by sending the IPv6 SSDP:BYEBYE message from the UPnP device 1 in S59. turn into.
Therefore, the UPnP control point 2 must send the HTTP GET command to the UPnP device 1 again in S62, and the UPnP device 1 must respond with a device description in S63 to restore the service to a usable state. This requires extra communication between the UPnP control point 2 and the UPnP device 1, which may reduce communication efficiency in service provision.

The reason why a service that has once become available changes to an unavailable state is because the UPnP device 1 sends the SSDP:BYEBYE message to the UPnP control point 2 in S59. That is, if the SSDP:BYEBYE message is not sent in S59, the UPnP control point 2 that received the IPv6 SSDP:ALIVE message in S61 need not send the HTTP GET command in S62. This makes it possible to reduce the number of times messages are sent and received regarding the HTTP GET command. This is because the NLS that identifies the services in the IPv4 and IPv6 SSDP:ALIVE messages in S55 and S61 are the same.

Therefore, in this embodiment, when transmitting the same service to the UPnP control point 2 using a plurality of different address systems, the SSDP:ALIVE message is not transmitted until the SSDP:BYEBYE message has been transmitted using each of the different address systems. Note that in either address system, the SSDP:BYEBYE message shall be sent before the SSDP:ALIVE message.
By controlling the message sequence in this way, the UPnP control point 2 is prevented from unexpectedly transitioning to a service unavailable state in the first address system, and also reduces the number of messages sent and received related to subsequent HTTP GET commands. can.
Furthermore, since it is possible to avoid the service becoming unavailable between S59 and S63, the convenience of the UPnP control point 2 is improved.

<Processing flow of service provision processing of UPnP device 1>
FIG. 6 is a flowchart illustrating an example of the procedure of service provision processing executed by the UPnP device 1. The process shown in FIG. 6 may be started, for example, when the power of the UPnP device 1 is turned on.
The UPnP device 1 can execute the process shown in FIG. 6 by having the CPU 101 read and execute a necessary program from the ROM 102 or external memory. However, the processing in FIG. 6 may be realized by at least some of the elements shown in FIG. 2 operating as dedicated hardware. In this case, the dedicated hardware operates under the control of the CPU 101.

In S1, the UPnP device 1 executes the configuration of the UPnP network 4. This network setting may be automatically set when the power of the UPnP device 1 is turned on or when a physical connection is established, or may be set by operating a network setting button or the like from the operation unit 104.
In the network settings of S1, specifically, the IP address, subnet mask, and gateway of the UPnP device 1 are set. The network settings may be set for either the IPv4 address system or the IPv6 address system, or both address systems may be set. The address system set in S1 is stored in the ROM 102 of the UPnP device 1.

In S2, the UPnP device 1 participates in the UPnP network 4 via the network I/F 105. Participation in the UPnP network 4 may be performed automatically after the network settings in S1 are completed, or may be performed by pressing the network participation button on the operation unit 104. Note that in this embodiment, the UPnP device 1 and the UPnP control point 2 communicate using the TCP/IP protocol, but other communication protocols may be used instead.

In S3, the UPnP device 1 starts the UPnP service by pressing the UPnP service start button on the operation unit 104 or the like. At this time, the CPU 101 of the UPnP device 1 determines the address system set in S1, and starts the UPnP service using the address system determined to have been set.
By determining the address system used by the service to be started by the CPU 101, it is possible to omit the need for the user of the UPnP device 1 to select and input which address system to start the UPnP service. In S3, if the determined address system is only one of IPv4 or IPv6, the process advances to S4, and if the determined address system is both IPv4 and IPv6, the process advances to S6.

Note that in S3, if the determined address system is only IPv4, the CPU 101 of the UPnP device 1 generates a warning screen or an error screen prompting the other party to configure the IPv6 network, and displays the display unit 107 before starting the UPnP service. It may also be displayed via By notifying warnings and errors in this way, it is possible to prevent unexpected situations such as when the user of UPnP device 1 intends to start a UPnP service using both IPv4 and IPv6, but is actually able to start a UPnP service only using IPv4. It can be prevented. Similarly, even if the determined address system is only IPv6, the CPU 101 generates a warning screen or an error screen prompting the other IPv4 network settings before starting the UPnP service, and displays the screen via the display unit 107. Good too.

If the determined address system is only IPv4 or IPv6, the network I/F 105 of the UPnP device 1 first transmits an SSDP:BYEBYE message to the UPnP control point 2 in S4. In S4, the network I/F 105 transmits the SSDP:BYEBYE message using the address system determined in S3, that is, using only IPv4 or IPv6 address system.

Upon receiving the SSDP:BYEBYE message, the UPnP control point 2 compares the UUID 43 stored in the device management table 41 with the UUID of the SSDP:BYEBYE message transmitted from the UPnP device 1 in S4.
As a result of the comparison, if there is a UUID 43 in the device management table 41 that matches the UUID of the SSDP:BYEBYE message transmitted in S4, the UPnP control point 2 deletes the entry from the device management table 41.

In this embodiment, the UPnP device 1 transmits the SSDP:BYEBYE message in S4 prior to transmitting the SSDP:ALIVE message in S5. Thereby, the UPnP control point 2 can learn of the withdrawal of the service of the UPnP device 1 from the UPnP network 4 before the cache period, which is a period during which information such as the UUID and device-specific information is continued to be held, has elapsed.
Note that in this embodiment, the cache period is set to 1800 seconds as an example, but any cache period may be set. When the cache period has elapsed, the UPnP control point 2 deletes the entry of the UPnP device 1 whose cache period has expired from the device management table 41. The cache period is updated by receiving an SSDP:ALIVE message from the UPnP device 1. Note that the UPnP device 1 may periodically transmit the SSDP:ALIVE message during S8 to S10.

In S5, the network I/F 105 of the UPnP device 1 transmits the SSDP:BYEBYE message and then transmits the SSDP:ALIVE message. In S5, the network I/F 105 transmits the SSDP:ALIVE message using the address system determined in S3, that is, using only IPv4 or IPv6 address system.
Returning to S3, on the other hand, if the determined address system is both IPv4 and IPv6, the network I/F 105 of the UPnP device 1 first transmits an SSDP:BYEBYE message to the UPnP control point 2 in S6. In S6, the network I/F 105 transmits the SSDP:BYEBYE message using the address system determined in S3, that is, using both IPv4 and IPv6 address systems.
In this way, by sending SSDP:BYEBYE using both IPv4 and IPv6 address systems before sending the SSDP:ALIVE message, the communication load and service unavailable state explained in Figure 5 can be avoided. is resolved.

In S7, the network I/F 105 of the UPnP device 1 transmits an SSDP:BYEBYE message using both IPv4 and IPv6 address systems, and then transmits an SSDP:ALIVE message. In S7, the network I/F 105 transmits the SSDP:ALIVE message using the address system determined in S3, that is, using both IPv4 and IPv6 address systems.
Note that when executing the process in S7 after S6, even if the CPU 101 starts the SSDP:ALIVE message sending process in S7 after confirming that the SSDP:BYEBYE message sending process in S6 has operated normally. good. Alternatively, the time at which the processing in S6 will be sufficiently completed may be set in advance, and the processing at S7 may be started when the time measured by the timer 110 passes the set value after S3.

In S8, the CPU 101 of the UPnP device 1 determines whether an HTTP GET command has been received from the UPnP control point 2. If an HTTP GET command is received (S8: Y), the process proceeds to S9; on the other hand, if an HTTP GET command is not received (S8: N), S9 is skipped and the process proceeds to S10.
If the HTTP GET command is received, in S9 the network I/F 105 of the UPnP device 1 transmits the service content to the UPnP control point 2 that is the source of the HTTP GET command. In this embodiment, the network I/F 105 of the UPnP device 1 transmits a device description to the UPnP control point 2.

In S10, the CPU 101 of the UPnP device 1 determines whether to stop the service. If the service is not to be stopped (N at S10), the process returns to S408, whereas if the service is to be stopped (S10: Y), the process is to proceed to S411.
In S11, the network I/F 105 of the UPnP device 1 transmits an SSDP:BYEBYE message to the UPnP control point 2. In S11, the network I/F 105 transmits the SSDP:BYEBYE message using all the address systems determined in S3. As a result, it is possible to avoid a situation where the service availability status differs between the UPnP control point 2 that receives only IPv4 or IPv6 and the UPnP control point 2 that receives both IPv4 and IPv6.

The phenomenon that the service availability status differs between the UPnP control points 2 will be explained below.
Assume that when the UPnP device 1 transmits the SSDP:ALIVE message using both IPv4 and IPv6 in S7, it transmits only the SSDP:BYEBYE message of IPv6 in S11.
In this case, the UPnP control point 2 that receives only IPv4 is in a service available state in the IPv4 address system, but the UPnP control point 2 that receives both IPv4 and IPv6 is in a service unavailable state.

Similarly, if only the IPv4 SSDP:BYEBYE message is sent in S11, the UPnP control point 2 that receives only IPv6 becomes available for service in the IPv4 address system. On the other hand, the UPnP control point 2 that receives both IPv4 and IPv6 is in a service unavailable state. In order to resolve the discrepancy that the service availability status differs between the UPNP control points 2 after sending the SSDP:BYEBYE message, in this embodiment, the SSDP:BYEBYE message is sent for all address systems when the service is stopped.
Note that in this embodiment, in S11, if transmission of the SSDP:BYEBYE message fails in any of the address systems determined in S3, error processing may be executed. In this error handling, for example, the SSDP:BYEBYE message may be retransmitted using the address system in which the transmission failed, or the UPnP device 1 may forcibly leave the UPnP network 4.

<Processing flow of service reception processing of UPnP control point 2>
FIG. 7 is a flowchart illustrating an example of the procedure of the service reception process executed by the UPnP control point 2. The process shown in FIG. 7 may be started, for example, when the power of the UPnP control point 2 is turned on.
In S71, the UPnP control point 2 executes network settings. This network setting may be automatically set when the power of the UPnP control point 2 is turned on or when a physical connection is established, or may be set by an operation from the input unit 206.
In the network setting at S71, specifically, the IP address, subnet mask, and gateway are set. Network settings may be made for either the IPv4 address system or the IPv6 address system, or for both address systems.

In S72, the UPnP control point 2 participates in the UPnP network 4 via the network I/F 205. Participation in this UPnP network 4 may be performed automatically after completion of the network settings in S71, or may be performed by pressing a network participation button on the input unit 206.
In S73, the network I/F 205 of the UPnP control point 2 determines whether the SSDP:ALIVE message has been received from the UPnP device 1. If the SSDP:ALIVE message is received (S73: Y), the process advances to S74. On the other hand, if the SSDP:ALIVE message is not received (S73:N), the process advances to S78.

If the SSDP:ALIVE message is received, in S74 the CPU 201 of the UPnP control point 2 determines whether the SSDP:ALIVE message received in S73 is a target to which an HTTP GET command should be transmitted.
In S74, the CPU 201 of the UPnP control point 2 refers to the device management table 41 to determine whether the device is a target to which an HTTP GET command should be transmitted. Specifically, the UPnP control point 2 compares the UUID 43 and NLS 44 of the device management table 41 with the UUID and NLS in the received SSDP:ALIVE message, respectively.

As a result of this comparison, if there is an entry in the device management table 41 that matches both the UUID and NLS in the received SSDP:ALIVE message, it is determined that the HTTP GET command is not to be sent (S74: N). , proceed to S77. On the other hand, if there is no entry in the device management table 41 that matches both the UUID and NLS in the received SSDP:ALIVE message, it is determined that the device is the target to which the HTTP GET command should be sent (S74: N). , proceed to S75.
If it is determined that the HTTP GET command is to be transmitted, the network I/F 205 of the UPnP control point 2 transmits the HTTP GET command to the UPnP device 1 in S75.

In S76, the network I/F 205 of the UPnP control point 2 receives the device description of the UPnP device 1 as a response from the UPnP device 1 that sent the HTTP GET command in S75. The CPU 201 of the UPnP control point 2 updates the device management table 41 with the information received in response to S73 and S75.
Specifically, the CPU 201 of the UPnP control point 2 updates the device management table 41 with the IP address, UUID, and NLS of the UPnP device 1 extracted from the SSDP:ALIVE message received in S73. Further, the CPU 201 of the UPnP control point 2 updates the device management table 41 with the device description of the UPnP device 1 received as the response in S75.

On the other hand, if it is determined that the target is not a target to which an HTTP GET command should be transmitted, the CPU 201 of the UPnP control point 2 updates the device management table 41 in S77.
Specifically, the CPU 201 of the UPnP control point 2 updates the device management table 41 with the IP address, UUID, and NLS extracted from the SSDP:ALIVE message received in S73. At this time, the device specific information 45 and service status 46 of the device management table 41 may be written with a character representing a blank such as NULL, or may be written based on the value of the device management table 41 that matches in the comparison process in S74. good.

Returning to S73, if the SSDP:ALIVE message is not received, the network I/F 205 of the UPnP control point 2 determines whether or not the SSDP:BYEBYE message has been received from the UPnP device 1 in S78.
If the SSDP:BYEBYE message is received (S78: Y), the process proceeds to S79; on the other hand, if the SSDP:BYEBYE message is not received (S78: N), S79 is skipped and the process proceeds to S80.

In S79, the CPU 201 of the UPnP control point 2 updates the device management table 41.
Specifically, the CPU 201 of the UPnP control point 2 compares the UUID extracted from the SSDP:BYEBYE message received in S78 and the UUID 43 in the device management table 41. As a result of the comparison, if there is a UUID 43 in the device management table 41 that matches the UUID in the received SSDP:BYEBYE message, the corresponding entry is deleted from the device management table 41. On the other hand, if there is no UUID 43 in the device management table 41 that matches the UUID in the received SSDP:BYEBYE message, the device management table 41 is not updated.
In S80, the CPU 201 of the UPnP control point 2 determines whether to leave the UPnP network 4. If it is determined not to leave the UPnP network 4 (S80: N), the process returns to S73 and the processes from S73 to S80 are repeated. On the other hand, if it is determined to leave the UPnP network 4 (S80: Y), the process advances to S81, leaves the UPnP network 4, and ends the process.

<UPnP service provision processing sequence of this embodiment>
The processing procedure for providing UPnP services from the UPnP device 1 to the UPnP control point 2 in this embodiment will be described below with reference to FIGS. 8 to 10.
FIG. 8 shows an example of a message sequence during UPnP service transmission between the UPnP device 1 and the UPnP control point 2. Note that in each step in FIG. 8, processes similar to those in the conventional sequence in FIG. 5 will be described with the same reference numerals.

In comparison with the conventional message sequence shown in FIG. 5, in FIG. 8, before sending the SSDP:ALIVE message in IPv4 in S55, an SSDP:BYEBYE message in IPv6 is sent (S59), and from S60, S62 to S64 Each step up to this point has been omitted.
In FIG. 8, it is assumed that the UPnP control point 2 has completed the network settings (S71) and participation in the network (S72) in FIG. 7 in advance. It is also assumed that the UPnP control point 2 can receive messages and services in both IPv4 and IPv6 address systems.

In S51, the UPnP device 1 performs network settings for participating in the UPnP network 4 by pressing the network setting button on the operation unit 104 or the like. Here, it is assumed that network settings for both IPv4 and IPv6 are performed.
Specifically, it is assumed that the UPnP device 1 has an IPv4 IP address set to 192.168.1.10 and an IPv6 IP address set to fe80::4828:23c3:52de:5df8.
In S52, the UPnP device 1 participates in the IPv4 and IPv6 UPnP networks 2 via the network I/F 105 by pressing the network participation button on the operation unit 104 or the like.

In S53, the UPnP device 1 starts the UPnP service by pressing the UPnP service start button on the operation unit 104 or the like. Since network settings have been made for both IPv4 and IPv6 in S51, in S53 the UPnP device 1 starts the UPnP service using both IPv4 and IPv6 address systems.
In S54, the network I/F 105 of the UPnP device 1 transmits the SSDP:BYEBYE message to the UPnP control point 2 using the IPv4 address system network.

FIG. 9A shows the description content of the SSDP:BYEBYE message transmitted by the network I/F 105 of the UPnP device 1 using IPv4 in S54 of FIG. 8.
The SSDP:BYEBYE message sent in S54 is received by the network I/F 205 of the UPnP control point 2. The CPU 201 of the UPnP control point 2 compares the UUID in the received SSDP:BYEBYE message with the UUID 43 recorded in the device management table 41 (S79 in FIG. 7).
The UUID of the UPnP device 1 described in the SSDP:BYEBYE message is represented by the character string "adcd...6bf6" following "USN:uuid:" in FIG. 9(a). On the other hand, at this point, the device management table 41 is in an initial state and no entries are recorded.
Therefore, as a result of the comparison, the UUID in the received SSDP:BYEBYE message does not match the UUID 43 in the device management table 41, so there is no entry to be deleted in the device management table 41, and the device management table 41 is not updated.

Returning to FIG. 8, following S54 and before S55, in S59, the network I/F 105 of the UPnP device 1 transmits an SSDP:BYEBYE message to the UPnP control point 2 in the IPv6 address system network.
FIG. 9B shows the description content of the SSDP:BYEBYE message transmitted by the network I/F 105 of the UPnP device 1 using IPv6 in S59 of FIG.
The SSDP:BYEBYE message sent in S59 is received by the network I/F 205 of the UPnP control point 2 (S73:N, S78:Y in FIG. 7). The CPU 201 of the UPnP control point 2 compares the UUID in the received SSDP:BYEBYE message with the UUID 43 recorded in the device management table 41 (S79 in FIG. 7).
Even at this point, the device management table 41 is in its initial state and no entries are recorded. Therefore, as a result of the comparison, the UUID in the received SSDP:BYEBYE message does not match the UUID 43 in the device management table 41, so there is no entry to be deleted in the device management table 41, and the device management table 41 is not updated.
Note that in FIG. 8, the order of S54 and S59 may be reversed.

After S59, in S55, the network I/F 105 of the UPnP device 1 transmits the SSDP:ALIVE message to the UPnP control point 2 over the IPv4 address system network.
FIG. 10A shows the description content of the SSDP:ALIVE message transmitted by the network I/F 105 of the UPnP device 1 using IPv4 in S55 of FIG.
The SSDP:ALIVE message transmitted in S55 is received by the network I/F 205 of the UPnP control point 2 (S73:Y in FIG. 7).
The CPU 201 of the UPnP control point 2 determines whether the received SSDP:ALIVE message is a target for transmitting an HTTP GET command (S74).

The UUID of the UPnP device 1 written in the SSDP:ALIVE message received in S55 is represented by the character string "adcd...6bf6" following "USN:uuid:" in FIG. 10(a). Further, the NLS of the UPnP device 1 described in the SSDP:ALIVE message received in S55 is represented by the character string "508e...5ae0" following "01-NLS:" in FIG. 10(a). On the other hand, at this point, the device management table 41 is in an initial state and no entries are recorded.
Therefore, the CPU 201 of the UPnP control point 2 determines that both the UUID and NLS in the received SSDP:ALIVE message do not match the UUID 43 and NLS 44 in the device management table 41 (74:Y in FIG. 7).
Returning to FIG. 8, in S56, the network I/F 205 of the UPnP control point 2 transmits an HTTP GET command to the UPnP device 1 (S75 in FIG. 7). The HTTP GET command sent in S56 is sent with the character string "192.168.1.10" following "Location:" in the SSDP:ALIVE message of FIG. 10(a) received in S55 as the destination. .
It is determined that the HTTP GET command transmitted in S56 has been received by the UPnP device 1 (S8:Y in FIG. 6).

In S57, the network I/F 105 of the UPnP device 1 transmits the device description of the UPnP device 1 as the service content to the UPnP control point 2 in response to the HTTP GET command (S9 in FIG. 6).
The network I/F 205 of the UPnP control point 2 receives the device description from the UPnP device 1, and the CPU 201 of the UPnP control point 2 updates the device management table 41 (S76 in FIG. 7).
At this stage, an entry for the IPv4 address system of the UPnP device 1 is added to the device management table 41, as shown in FIG. 4(a).
In S58, the CPU 201 of the UPnP control point 2 refers to the device specific information 45 of the device management table 41, and is now in a state where it can acquire the service description of the UPnP device 1 using the IPv4 address system. That is, in S58, the UPnP control point 2 transitions to a service available state in the IPv4 address system.

In S61, the network I/F 105 of the UPnP device 1 transmits an SSDP:ALIVE message to the UPnP control point 2 using IPv6.
FIG. 10(b) shows the description content of the SSDP:ALIVE message transmitted by the network I/F 105 of the UPnP device 1 using IPv6 in S61 of FIG.
The network I/F 205 of the UPnP control point 2 receives the SSDP:ALIVE message from the UPnP device 1 (S73:Y in FIG. 7). The CPU 201 of the UPnP control point 2 determines whether the received SSDP:ALIVE message is a target of the HTTP GET command (S74).

The UUID of the UPnP device 1 described in the SSDP:ALIVE message received in S61 is represented by the character string "adcd...6bf6" following "USN:uuid:" in FIG. 10(b). Further, the NLS of the UPnP device 1 written in the SSDP:ALIVE message received in S61 is represented by the character string "508e...5ae0" following "01-NLS:" in FIG. 10(b).

On the other hand, the entry for the UPnP device 1 has been added to the device management table 41 in S76 of FIG. 7, as shown in FIG. 4(a). Therefore, the CPU 201 of the UPnP control point 2 determines that there is a UUID 43 and an NLS 44 that match both the UUID and NLS of the received SSDP:ALIVE message. That is, the CPU 201 of the UPnP control point 2 determines that the received SSDP:ALIVE message is not a target of the HTTP GET command (S74:N in FIG. 7).
Next, the CPU 201 of the UPnP device 1 adds an entry for the IPv6 address system to the device management table 41, and changes the device management table 41 shown in FIG. 4(a) to the device management table 47 shown in FIG. 4(b). Update.

In this embodiment, even if the IPv6 SSDP:ALIVE message is received from the UPnP device 1 in S61 of FIG. 8, the UPnP control point 2 does not subsequently send an HTTP GET command to the UPnP device 1. Therefore, the UPnP device 1 also does not send the device description to the UPnP control point 2 in response to the HTTP GET command. The CPU 201 of the UPnP control point 2 can determine from the device management table 41 that the same service is already available in the IPv4 address system. Therefore, there is no need to transmit HTTP GET commands to obtain device descriptions for the same service over IPv6.

As explained above, in this embodiment, when a UPnP device sends the same service to a UPnP control point using a plurality of different address systems, the UPnP device sends an absence message (BYEBYE) in all address systems before sending an presence message (ALIVE). ) to send. Furthermore, the UPnP control point refers to the device management table to determine whether there is an entry for the same service from the same UPnP device, and if there is an entry for the same service, it does not transmit the HTTP GET command.
With this, it is possible to effectively prevent a service transmitted from a UPnP device using the first address system from unexpectedly transitioning to a service unavailable state due to the UPnP device leaving the network using another address system. Further, since the service transmitted from the UPnP device using the first address system does not temporarily become unavailable, the convenience of the service is improved.
Furthermore, if information on a device for receiving a service for the same service is available for any of multiple different address systems, no HTTP GET command is sent, which improves communication efficiency in providing the service. .

Furthermore, the present invention can also be implemented by a program that implements a part or one or more functions of the embodiments described above. That is, it can be realized by a process in which the program is supplied to a system or device via a network or a storage medium, and one or more processors in the computer (or CPU, MPU, etc.) of the system or device read and execute the program. be. Further, the program may be provided by being recorded on a computer-readable recording medium.
Further, the functions of the embodiments are not limited to those that are realized by executing a program read by a computer. For example, an operating system (OS) running on a computer may perform part or all of the actual processing based on instructions from a program, and the functions of the embodiments described above may be realized by the processing.

1...UPnP device, 2...UPnP control point, 3...Access point, 4...UPnP network, 101...CPU, 102...ROM, 103...RAM, 104...Operation unit, 105...Network I/F, 106...Drive, 107 ...Display section, 108...Optical section, 109...Encoding/decoding section, 110...Timer

Claims (12)

Participating means for configuring one or more of the first and second address systems to participate in the network;
a first transmitting means for transmitting a presence message to the network indicating that the network exists on the network joined by the participating means;
a second transmitting means for transmitting a withdrawal message to the network indicating withdrawal from the network;
determining means for determining which address system has been set among the first and second address systems;
If the determination means determines that both of the first and second address systems are set, the withdrawal message is sent to the second transmission means in both the first and second address systems. Transmission control means for controlling the first transmitting means to transmit the presence message to the network after transmission of the leave message in both the first and second address systems is completed. A communication device comprising: and . further comprising a starting means for starting a predetermined service to the network in the address system determined to be set by the determining means,
The communication device according to claim 1, wherein the transmission control means controls the leaving message and the presence message to be transmitted to the network when the predetermined service is started by the starting means. . If the determination means determines that one of the first and second address systems is set, the transmission control means determines that the other of the first and second address systems is not set. The communication device according to claim 1 or 2, wherein the communication device generates a notification indicating. The communication device according to claim 3, wherein the transmission control means generates a notification prompting setting of the other of the first and second address systems. further comprising a stopping means for stopping the predetermined service started by the starting means,
The transmission control means controls the withdrawal message to be transmitted to the network using both the first and second address systems when the predetermined service is stopped by the stop means. The communication device according to item 2 . The communication device is a UPnP device defined by UPnP (Universal Plug and Play),
The communication device according to any one of claims 1 to 5, wherein the network to which the participation means participates is a UPnP network defined by UPnP. The communication device according to claim 6, wherein the existence message is an SSDP (Simple Service Discovery Protocol): ALIVE message, and the departure message is an SSDP: BYEBYE message. 8. The communication device according to claim 7, wherein the first transmitting means sets information indicating a predetermined service to the network in NLS (Network Location Signature) of the SSDP:ALIVE message. 9. The communication device according to claim 8, wherein the communication device operates as a media server, and the predetermined service is a service related to the media server. 10. The communication device according to claim 9, wherein the communication device includes an imaging section and a storage section. configuring one or more of the first and second addressing schemes to join the network;
determining which address system has been set among the first and second address systems;
If it is determined that both of the first and second address systems have been set, a withdrawal message indicating withdrawal from the network is sent to the network in both the first and second address systems. step and
sending the leave message to the network in both the first and second addressing schemes; sending a presence message to the network indicating that the
A method for controlling a communication device, comprising: A program for causing a computer to function as each means of the communication device according to claim 1.

Images