专利名称：控制方法、控制点设备、设备及系统的制作方法
技术领域：
本发明涉及对UPnP设备的控制，具体涉及一种控制UPnP设备的 方法，控制UPnP设备的UPnP控制点设备，相应的UPnP设备和系统， 能够方便用户尽早发现UPnP网络中异常退出的UPnP设备。
背景技术：
UPnP是针对智能家电、无线设备以及各种外观尺寸的个人电脑的普 遍对等(peer-to-peer)网络连接而设计的一种架构。它旨在为家庭、小 型企业、公共场所中或连接到互联网的ad-hoc网或未管理网络提供易于 使用、灵活且基于标准的连接。
UPnP不仅仅只是即插即用外设模式的简单扩展。它设计用于支持零 配置、"不可见"联网，以及对众多厂商的广泛设备类型的自动发现。这 就意味着， 一台设备能够动态加入一个网络，获取一个IP地址，通报其 功能，以及了解其它设备的存在和功能。DHCP和DNS服务器为可选服 务器，仅当他们在网上存在时可以使用。最后，设备能够顺利地自动离 线，而不会造成任何不期望的影响。
UPnP网络互连的基础是IP寻址。每台设备均配有动态主机配置协议 (DHCP)客户端，并在设备首次与网络连接时搜索DHCP服务器。如果 DHCP服务器可以使用，即网络处于管理状态，则设备采用分配给它的IP 地址。如果没有DHCP服务器可用，即网络处于未管理状态，则设备利 用Auto IP来获取一个地址。
图20是根据现有UPnP标准的网络系统中信息传输过程的流程图。 如果获取了一个IP地址，则UPnP网络的第1步是发现，如图20所示， 在将一个设备添加到网络上之后，UPnP发现协议允许该设备向网络中 的控制点宣告其服务。
UPnP网络中的第2步是描述。控制点在发现一个设备之后仍然对其知之甚少。为了使控制点了解到更多关于设备及其能力的信息或与设备
进行交互，则控制点必须取得来自该设备在发现消息中所提供之URL的 设备描述。设备可能包含其它逻辑设备，以及功能单元或服务。对于设 备的UPnP描述通过XML来表达，并包括诸如模型名称和号码、序列号、 制造商名称和厂商专门网站URL等专门针对厂商的制造商信息。该描述 还包括一列任意的嵌入式设备或服务，以及用于控制、事件触发和展示 的URL。对于每项服务，此描述均包括一列命令或动作，而服务(参数 或变量)对于每个动作做出响应；针对服务的描述还包括一列变量；这 些变量模型化服务在运行时的状态，并通过数据类型、范围和事件特征 进行描述。
UPnP网络中的第3步是控制。当一个控制点取得设备描述后，该控 制点可将动作发至一个设备的服务。为此，控制点将一条适当的控制消 息发至服务的控制URL (在设备描述中提供)。控制消息同样利用简单 对象访问协议(SOAP)通过XML来表达。
UPnP网络的第4步是事件触发。针对服务的UPnP描述包括一个服务 响应的动作列表，以及一个对服务器运行时状态进行展示的变量列表。 在这些变量变更时服务会发布更新， 一个控制点可以预订接收此信息。 服务通过发送事件消息来发布更新。事件消息包含一个或多个状态变量 名和这些变量的当前值。这些消息同样通过XML来表达，并采用通用事 件通知架构(GENA)格式。
UPnP网络中的第5步是展示。如果设备有用于展示的URL，那么控 制点就可以通过此URL取得一个页面，在浏览器中加载该页面，并且根 据页面的功能，支持用户控制设备和/或浏览设备状态。
图21是描述如图20所示的网络系统的控制点在UPnP设备异常退出 时的控制过程的示意图。如图21所示，在生存期间为30分钟的设备登陆 控制点后的15分钟，由于某种原因该设备的网线被拔掉。在这种情况下， 控制点无法尽快得知此事，仍旧认为设备在其控制之下，直到该设备的 生存周期届满，才主动解除对该设备的控制。也就是，在30分钟的生存 期间，控制点错误控制了15分钟，未能及时发现存在问题的设备。
图22是描述如图20所示的网络系统中的控制点控制UPnP设备的流程图。如图22所示，控制点记录各个UPnP设备(称为受控设备)的名称 以及相应的生存期间(S100)，并且开始监视各个设备的退出宣告消息 (S110)。
当控制点收到来自设备的退出宣告消息时，退出处理模块针对该设 备进行相应的退出处理，将该设备从控制点的设备列表中删除(S140)。
如果控制点未收到来自设备的退出宣告消息，则判断该设备的生存 期间是否已经过去(S120)。如果当前时间超过了该设备的生存期间， 则进行退出处理(S140)，否则，控制点继续监视各个设备的退出宣告 消息。
同样，在上述过程中，即使在生存期间内设备出现了故障，无法发 送退出宣告消息，控制点就只能等到该设备的生存期间届满，才决定解 除对该设备的控制。这导致不能及时发现设备的异常退出，会造成错误 的控制或者事故。
发明内容
本发明的目的是提出一种用于UPnP网络系统中的控制方法，控制 点设备、UPnP设备以及UPnP网络系统，能够尽早发现设备的异常退出。 在本发明的第一方面，提出了一种通过UPnP控制点控制网络中的UPnP 设备的方法，包括步骤该UPnP控制点基于预定的准则判断该UPnP 设备是否异常；以及在该UPnP设备发生异常的情况下，该UPnP控制 点以主动询问的方式向该UPnP设备确认该UPnP设备是否退出了网络。
在本发明的第二方面，提出了一种在网络中控制UPnP设备的UPnP 控制点设备，包括异常处理装置，基于预定的准则判断该UPnP设备 是否异常；以及询问装置，在该UPnP设备发生异常的情况下，以主动 询问的方式向该UPnP设备确认是否退出网络。
在本发明的第三方面，提出了一种UPnP设备，包括存储装置， 存储该UPnP设备的生存期间和用于发送存活信息的再送间隔；存活通 知装置，用于UPnP在设备登陆时向UPnP控制点设备发送至少包括该 UPnP设备的生存期间和再送间隔的消息；以及应答生成装置，在从UPnP 控制点设备接收到询问时生成针对该询问的应答消息，以发送给UPnP控制点设备。
在本发明的第四方面，提出了一种网络系统包括至少一个UPnP控 制点设备和至少一个UPnP设备，至少一个UPnP控制点设备包括异 常处理装置，基于预定的准则判断该UPnP设备是否异常；以及 询问装置，在该UPnP设备发生异常的情况下，以主动询问的方式向该 UPnP设备确认该UPnP设备是否退出网络；至少一个UPnP设备包括 存储装置，存储该UPnP设备的生存期间和用于发送存活信息的再送间 隔；存活通知装置，用于在UPnP设备登陆时向UPnP控制点设备发送 至少包括该UPnP设备的生存期间和再送间隔的消息；以及应答生成装 置，在从UPnP控制点设备接收到询问时生成针对该询问的应答消息， 以发送给UPnP控制点设备。
利用上述方案，控制点可以在设备异常退出的情况下尽早发现，进 而做出正确操作。
从下面结合附图的详细描述中，本发明的上述特征和优点将更加明 显，其中
图1是根据本发明实施例的网络系统中的控制点和UPnP设备的结 构示意图2示出了描述根据本发明实施例的网络系统中控制UPnP设备的 方法的流程图3是描述根据本发明的实施例，在UPnP设备定期发送Notify Alive 消息情况下的控制过程的示意图4是描述根据本发明的实施例，在UPnP设备随机发送Notify Alive
消息情况下的控制过程的示意图5是描述根据本发明的实施例，在网络系统中控制各个设备的过 程的详细示意图6示出了如图5所示的各个设备启动后控制点的设备列表的示意
图7示出了如图5所示的设备C异常退出后控制点的设备列表的示意图8示出了如图5所示的设备C异常确认后控制点的设备列表的示 意图9示出了如图5所示的设备B异常退出后控制点的设备列表的示 意图10示出了如图5所示的各个设备在进入网络时所发送的消息的例
子；
图11示出了如图5所示的设备C异常时控制点对设备C的异常退 出的判断过程的例子；
图12示出了在判断设备C异常时控制点对设备C的询问的例子
(M-SEARCH方式)；
图13示出了设备C对M-SEARCH方式的询问的应答的例子；
图14示出了在判断设备C异常时控制点对异常设备的询问的例子
(HTTPGET方式)；
图15示出了设备C对HTTPGET方式的询问的应答的例子；
图16示出了在判断设备C异常时控制点对异常设备的询问的例子
(POST方式)；
图17示出了设备C对POST方式的询问的应答的例子； 图18示出了在判断设备C异常时控制点对设备C的询问的例子 (SUBSCRIBE方式)；
图19示出了设备C对SUBSCRIBE方式的询问的应答的例子； 图20是根据现有UPnP标准的网络系统中信息传输过程的流程图； 图21是描述如图20所示的网络系统的控制点在UPnP设备异常退
出时的控制过程的示意图；以及
图22是描述如图20所示的网络系统中的控制点控制UPnP设备的
流程图。
具体实施例方式
下面，参考附图详细说明本发明的优选实施方式。为了清楚和简明， 包含在这里的已知的功能和结构的详细描述将被省略，以防止它们使本发明的主题不清楚。
图1是根据本发明实施例的网络系统中的UPnP控制点(以下简称 未控制点或CP)和UPnP设备的结构示意图。如图l所示，根据本发明 实施例的控制点100包括控制点收发模块110，迸入/退出处理模块120， 异常处理模块170，设备列表160以及询问模块140。
控制点收发模块110向UPnP设备200发送相应的消息，例如 M-SEARCH消息等等，和/或接收来自UPnP设备的消息，例如对 M-SEARCH消息的应答等等。
进入/退出处理模块120在控制点收发模块110收到设备200的登陆 请求时，执行相应的进入处理操作，允许该设备登陆到控制点100，并 且在设备列表160中记录该设备的相关信息，例如编号，名称，生存期 间，送信间隔和状态等等。进入/退出处理模块130在控制点收发模块110 接收到来自设备200的退出宣告消息时，进行相应的退出处理，解除对 该设备的控制，从设备列表160中删除该设备的信息。
根据本发明的实施例，该进入/退出处理模块130在控制点收发模块 110未收到对询问模块140的主动询问的应答消息时，也进行退出处理， 从设备列表160中删除该设备的信息，解除对该设备200的控制。
根据本发明的实施例，在设备200登陆之后，异常处理模块170根 据预定的准则，例如是否定期收到来自设备200的存活消息(NotifyAlive 消息)，判断设备是否存在异常退出的嫌疑。如果在预定的时刻未收到来 自设备的存活消息，则异常处理模块170认为该设备200可能异常退出。 在这种情况下，异常处理模块170在设备列表160中将该设备的状态修 改未'异常(正在确认退出)'。
为了确认该判断，防止因为控制点本身可能存在的问题而导致的误 判，询问模块140主动向该设备200发送主动询问消息，例如M-AREACH 消息，HTTPGET消息，POST消息或者SUBSCRIBE消息等等。
如果仍旧未收到来自该设备的对主动询问消息的应答，则异常处理 模块170认为该设备确实己经退出该网络。在这种情况下，异常处理模 块170向进入/退出处理模块130发送消息，指出该设备200已经异常退 出。如上所述，进入/退出处理模块130从设备列表160中删除该设备的信息，从而解除对该设备的控制。
如图1所示，根据本发明实施例的UPnP设备200包括通信接口 210，存活通知模块210，存储单元230，退出宣告消息生成模块240以 及应答生成模块250。
通信接口 210负责向控制点100发送各种消息，和/或从控制点接收 各种消息。
在存储单元230中事先存储了该设备的名称，厂商，生存期间，送 信间隔之类的信息。根据本发明的实施例，可以通过外部输入来修改该 设备的生存期间等等信息，以适应于特定的应用。
根据本发明的实施例，在设备200登陆控制点IOO后，存活通知模 块220根据存储单元220中存储的生存期间，通过通信接口 210，定期 向控制点IOO发送表示其仍旧存在于网络中的存活消息。例如，存活通 知模块220以生存期间的分数，如1/3或1/2，为周期向控制点100发送 存活消息。
根据另一实施例，存活通知模块220也可以在登陆之后随机地向控 制点发送存活消息。在这种情况下，控制点100以该设备的生存期间的 1/3或者1/2为基准，判断该设备是否存在异常退出的嫌疑。下面将对此 进行更为详细的描述。
另外，在该设备的生存期间内，如果该设备决定主动退出网络，则 退出宣告消息生成模块240生成退出宣告消息，通过通信接口 210发送 给网络中包括控制点在内的各个设备。
应答生成模块250针对从通信接口 210所接收的各种消息，例如 M-AREACH消息，HTTPGET消息，POST消息或者SUBSCRIBE消息 等等，做出相应的应答。下面将对这些消息进行更为详细的描述。
图2示出了描述根据本发明实施例的网络系统中控制UPnP设备的 方法的流程图。如图2所示，迸入/退出处理模块130根据通过控制点收 发模块110所接收的设备登陆消息/退出宣告消息，在设备列表中登记/ 注销相应设备的信息(SIO)。
在设备登陆之后，控制点收发模块130监视各个设备的退出宣告消 息(Sll)。当收到设备200的退出宣告消息时，将该消息通知给进入/退出处理模块130，从设备列表160中删除该设备的信息，从而解除对 该设备的控制(S15)。
在未收到退出宣告消息时，异常处理模块170对该设备是否异常进 行判断，例如根据是否定期收到来自设备的存活消息(Notify Alive消 息)，来判断设备是否存在异常退出的嫌疑(S12)。如果在预定的时刻 未收到来自设备的存活消息，则异常处理模块170认为该设备200可能 异常退出。在这种情况下，异常处理模块170在设备列表160中将该设 备的状态修改为'异常(正在确认退出)'，询问模块140以主动询问的 方式向该设备200确认是否异常退出并且判断是否收到应答(S13)。
如果未收到针对该主动询问的应答，则表明该设备己经退出了网络。 在这种情况下，异常处理模块160通知进入/退出处理模块130该设备已 经异常退出。进入/退出处理模块130从设备列表中删除该设备的信息， 以解除对该设备的控制。
如果控制点收发模块110收到了针对该主动询问的应答，或者异常 处理模块170判断该设备没有异常，则流程返回到步骤SIO，继续接收 来自设备的消息并且记录设备的信息。
图3是描述根据本发明的实施例，在UPnP设备定期发送Notify Alive
消息情况下的控制过程的示意图。
根据本发明的实施例，UPnP设备200可以定期发送Notify Alive消 息。例如设备200的生存期间是30分钟，送信间隔是10分钟。也就是 在登陆之后，设备200没IO分钟向控制点100发送Notify Alive消息。 如果在15分钟时拔掉了设备200的网线，则控制点100在第20分钟将 无法收到下一次的Notify Alive消息，它将会发出主动询问，例如 HTTPGET消息。
如果该设备没有响应，例如控制点未收到来自设备的HTTP OK消 息，则认为该设备已经退出了网络。这样，在网线拔掉后5分钟后控制 点就得知该设备已经异常退出网络，而不是像现有技术那样，需要等到 生存周期结束。
根据本发明的实施例，异常处理模块170还可以判断该设备的生存 周期是否大于预定的阈值，例如12小时。如果大于12小时，则可以将设备定期发送Notify Alive消息的间隔设置为固定的时间间隔，例如10 分钟。这样，可以避免在生存周期过长的情况下也将送信间隔设置为生 存周期的特定分数倍带来的问题。
以上描述的是设备定期发送Notify Alive消息的情况。但是本发明并 不局限于此，设备还可以随机发送Notify Alive消息，也就是Notify Alive 消息中可以不带有NOTIFY-AGAIN字段。图4是描述根据本发明的实 施例，在UPnP设备随机发送Notify Alive消息情况下的控制过程的示意 图。
如图4所示，设备的生存期间是30分钟，在登陆后的5分钟发送了 Notify Alive消息。在这种情况下，控制点在从5分钟算起过了 1/2的生 存周期后判断该设备是否异常，进而发送主动询问消息。这样，在15 分钟时拔掉了该设备的网线，就可以在20分钟后判断出该设备已经退出 网络。
同样，异常处理模块170可以判断该设备的生存周期是否大于预定 的阈值，例如12小时。如果大于12小时，则可以将判断设备是否异常 的时间设置成收到上次Notify Alive消息后的固定时间段，例如10分钟。 这样，可以避免在生存周期过长的情况下因为Notify Alive消息发送的随 机性而导致不能及时判断出该设备是否异常退出。
图5是描述根据本发明的实施例，在网络系统中控制各个设备的过 程的详细示意图。如图5所示，设备A，设备B和设备C登陆到控制点 后，以各自的间隔发送Notify Alive消息。在这种情况下，控制点以各个 设备的送信间隔判断相应的设备是否异常。例如发现设备C异常时，向 设备C发送主动询问(M-SEARCH方式)。由于没有收到来自设备C的 应答，控制点认为该设备C已经退出网络。
作为另一实施方式，在多个设备异常时，控制点按照这些设备的登 陆顺序进行主动询问，或者按照设备登陆时所赋予的优先级来对这些设 备进行主动询问。
另一方面，控制点还可以依据当前网络中的传输差错率、传输丢包 率以及网络的可用带宽来确定主动询问的频度。因为频度过高的询问会 导致网络通信能力下降。图6示出了如图5所示的各个设备启动后控制点的设备列表的示意 图。设备A，设备B和设备C分别具有各自的生存期间和送信间隔。例 如，设备A的生存期间是900秒，送信间隔是300秒。设备B的生存期 间是1800秒，送信间隔是600秒。设备C的生存期间是1800秒，送信 间隔是300秒。如图6所示，各个设备的状态是'正常'。
如图7所示，在控制点检测到设备C异常时，将设备列表160中的 设备C的状态修改为'异常(确认中)'。如图8所示，当未接收到来自 设备C的确认消息时，控制点认为该设备C已经退出网络，因此将设备 列表中设备C的信息删除，解除对设备C的控制。
在此之后，控制点收到了设备B的退出宣告消息，将其从设备列表 中删除。图9示出了如图5所示的设备B异常退出后控制点的设备列表 的示意图。此时，网络中存活的设备仅仅是设备A。
图10示出了如图5所示的各个设备在进入网络时所发送的消息的例 子。从图10中可以看出，在进入网络时，设备A， B和C以多播的方 式发送各自的Notify Alive消息。例如设备C发送的Notify Alive消息如 下
NOTIFY* HTTP/1.1
LOCATION: http:〃192.168.0.3:54759/
HOST: 239.255.255.250:1900
SERVER: Linux Fedora5 2.6, UPnPA.l， PanasonicUPnP/1.1 NTS: ssdp: alive
USN: uuid: a506343c-b214國445e-b71b-f5bc7d51f280::upnp:rootdevice CACHE-CONTROL: max-age=1800 NOTIFY-AGAIN : 600 NT: upnp: rootdevice Content-Length: 0
该消息中的NOTIFY-AGAIN字段表示该设备C的送信间隔是600秒。
图11示出了如图5所示的设备C异常时控制点对设备C的异常退 出的判断过程的例子。在送信间隔内，设备C将再次发送Notify Alive消息。如图11所示，设备c异常退出时，控制点能够在送信间隔内判 断出来。图11中下部数据为设备C应该再次发送的Notify Alive消息
NOTIFY* HTTP/1.1
LOCATION: http:〃192.168.0.3:54759/
HOST: 239.255.255.250: l卿
SEHVEIl: Linux Fedora5 16， UPnP/1.1, PanasonicUPnP/1.1 NTS: ssdp: alive
USN: uuid: a506343c陽b214-445e-b71b-f5bc7d51f280::upnp:rootdevice CACHE-CONTROL: max-age=1800 NOTIFY-AGAIN: 600 NT: upnp:rootdevice Content-Length: 0
上述消息中的NTS: ssdp: alive表明该设备仍旧存活。 图12示出了在判断设备C异常时控制点对设备C的询问的例子 (M-SEARCH方式)。设备异常发生时，UPnP控制点利用M-Search方 式对其进行主动询问，以便进行确认，该消息如下 M-SEARCH* HTTP/1.1 Host:239.255.255.250:1900
ST:uuid:a506343c画b214-445e-b71b画f5bc7d51f280::up叩:rootdevice
Man:"ssdp:discover"
MX:3
图13示出了设备C对M-SEARCH方式的询问的应答的例子。设备 从控制点收到M-Search询问消息后，应当发送HTTP应答消息。而此时， 异常退出的设备C没有应答。图13下不数据为设备C应当应答的HTTP 消息。HTTP OK消息的结构如下
HTTP/1.1 200 OK
LOCATION: http:〃192.168.0.3:54759/ EXT:
USN: uuid:a506343c-b214-445e-b71b-f5bc7d51f280::upnp:rootdevice SERVER: Linux Fedom5 2.6, UPnP/1.1, PanasonicUPnP/1.1CACHE-CONTROL: max-age=1800 NOTIFY-AGAIN : 600 ST: upnp:rootdevice Content-Length: 0
图14示出了在判断设备C异常时控制点对异常设备的询问的例子 (HTTPGET方式)。设备异常发生时，UPnP控制点利用HTTPGET方 式对其进行主动询问，以便进行确认。HTTPGET消息的格式如下 GET/HTTP/1.1
Accept: text/xml， application/xml Host: 192.168.0.3:54759 Connection: Keep-Alive Cache-Control: no-cache Pragma: no-cache
图15示出了设备C对HTTPGET方式的询问的应答的例子。控制 设备从控制点收到HTTPGET询问消息后应当发送HTTP应答消息。而 此时，异常退出的设备C没有应答。图15下不数据为设备C应当应答 的HTTPOK消息。HTTPOK消息的格式如下
HTTP/1.1 200 OK
CONTENT-TYPE: text/xml
Content-Length: 1839 「BODY (省略)」
图16示出了在判断设备C异常时控制点对异常设备的询问的例子 (POST方式)。设备异常发生时，UPnP控制点利用POST方式对其进 行主动询问，以便进行确认。POST消息的格式如下
POST /urn:schemas-upnp-org:service:ConnectionManager_control HTTP/1.1
HOST: 192.168.0.3:54759
SOAPACT薩
"urn:schemas-upnp-org:service:ConnectionManager:l#GetCurrentConnectio nlnfo"CONTENT-TYPE: text/xml; charset="utf-8" Content-Length: 379 「BODY (省略)」
图17示出了设备C对POST方式的询问的应答的例子。控制设备 从控制点收到POST询问消息后，应当发送HTTP应答消息。而此时， 异常退出的设备C没有应答。图17下不数据为设备C应当应答的HTTP 消息
HTTP/1.1 200 OK
EXT:
CONTENT-TYPE: text/xml; charset="utf-8" SERVER: Windows NT/5.0, UPnP/1.0， Intel CLR SDK/1.0 Content-Length: 924 「BODY省略」
图18示出了在判断设备C异常时控制点对设备C的询问的例子 (SUBSCRIBE方式)。设备异常发生时，UPnP控制点利用SUBSCRIBE 方式对其进行主动询问，以便进行确认。SUBSCRIBE消息的格式如下 SUBSCRIBE
/—urn:schemas-upnp-org:service:ConnectionManager_event HTTP/1.1 TIMEOUT: Second-90 HOST: 192.168.0.3:54759 CALLBACK:
<http:〃192.168.0.2:5916/d2af0858-412f-4b72-ael9-63c9000d38fO/um:sche mas-upnp-org:service:ConnectionManager>
NT: up叩:event
Content-Length: 0
图19示出了设备C对SUBSCRIBE方式的询问的应答的例子。控 制设备从控制点收到SUBSCRIBE询问消息后，应当发送HTTP应答消 息。而此时，异常退出的设备C没有应答。图19下部数据为设备C应 当应答的HTTP消息。HTTP应答消息的格式如下
HTTP/1.1 200 OKTIMEOUT: Se画d-90 SID:
uuid:a506343c-b214-445e-b71b-f5bc7d51f280-um:schemas-upnp-org:servic e: ConnectionManager-3
SERVER: Windows NT/5.0, UPnP/1.0， Intel CLR SDK/1.0
Content-Length: 0
以上所虽然以功能模块的形式描述了控制点和UPnP设备的构成及 其功能，但是这并不意味着将本发明限定于上述的形式。本领域的普通 技术人员能够将其中的一个或者多个模块进行组合，或者将其中的一个 模块的功能分别在两个或者更多个模块中实现。
另外，上述的控制点和UPnP设备中的功能模块可以由软件来实现， 也可以由硬件来实现，或者由软件和硬件一起来实现。
另外，虽然作为本发明实施例之一的控制点和UPnP设备可以作为 软件或者硬件来实现。但是在作为软件来实现的情况下，相应的程序可 被存储在记录介质上，例如光存储器件或者磁存储器器件等，通过CPU 执行该程序来实现本发明。
另外，异常处理模块170还可以按照如下方式判断设备是否异常 通过用户选择设备列表中可能异常的设备，如果该设备对用户的选择没 有应答，则认为该设备异常；或者，在设备列表中的空间不足时，判断 所控制的设备中有异常，然后选择设备列表中可能异常的设备，如果该 设备没有应答，则认为该设备异常。
上面的描述仅用于实现本发明的实施方式，本领域的技术人员应该 理解，在不脱离本发明的范围的任何修改或局部替换，均应该属于本发 明的权利要求来限定的范围，因此，本发明的保护范围应该以权利要求 书的保护范围为准。
权利要求
1、一种通过UPnP控制点控制网络中的UPnP设备的方法，包括步骤所述UPnP控制点基于预定的准则判断该UPnP设备是否异常；以及在该UPnP设备发生异常的情况下，所述UPnP控制点以主动询问的方式向该UPnP设备确认该UPnP设备是否退出了网络。
2、 如权利要求l所述的方法，所述基于预定的准则判断该UPnP设 备是否异常的步骤包括当超过规定时间未收到该UPnP设备的存活消息时，判断该UPnP 设备异常。
3、 如权利要求l所述的方法，所述基于预定的准则判断该UPnP设备是否异常的步骤包括选择设备列表中可能异常的UPnP设备；以及在该UPnP设备没有对该选择做出应答的情况下，判断该UPnP设 备异常。
4、 如权利要求l所述的方法，所述基于预定的准则判断该UPnP设 备是否异常的步骤包括如果设备列表中的空间不足，则判断所控制的UPnP设备中有异常。
5、 如权利要求2所述的方法，其中，在来自UPnP设备的存活消息 中不存在再送间隔字段时，将所述规定时间设置为该UPnP设备的生存期间的分数倍。
6、 如权利要求2所述的方法，其中，在来自UPnP设备的存活消息 中存在再送间隔字段时，将该字段的值设置为规定时间。
7、 如权利要求5或6所述的方法，其中，在UPnP设备的生存期间 大于阈值时，将该规定时间设置为一固定值。
8、 如权利要求l所述的方法，其中所述UPnP控制点以主动询问的 方式向该UPnP设备确认该UPnP设备是否退出网络的步骤包括-定期向该UPnP设备发送询问，以确定该UPnP设备是否退出网络。
9、 如权利要求1所述的方法，其中所述UPnP控制点以主动询问的 方式向该UPnP设备确认该UPnP设备是否退出网络的步骤包括一旦在规定的时间间隔中没有收到来自UPnP设备的存活消息，就 向该UPnP设备发送询问，以确定该UPnP设备是否退出网络。
10、 如权利要求8或9所述的方法，其中按照UPnP设备登陆的顺 序或者UPnP设备登陆时赋予的优先级向UPnP设备发送询问。
11、 如权利要求8或9所述的方法，其中以基于网络传输差错率、 丢包率和可用带宽至少之一的频度来向UPnP设备发送询问。
12、 如权利要求8或9所述的方法，其中所述主动询问采用如下之 一M-SEARCH， HTTPGET， POST， SUBSCRIBE。
13、 一种在网络中控制UPnP设备的UPnP控制点设备，包括 异常处理装置，基于预定的准则判断该UPnP设备是否异常；以及 询问装置，在该UPnP设备发生异常的情况下，以主动询问的方式向该UPnP设备确认是否退出网络。
14、 如权利要求13所述的UPnP控制点设备，当超过规定时间未收 到UPnP设备的存活消息时，所述异常处理装置判断该UPnP设备异常。
15、 如权利要求13所述的UPnP控制点设备，其中，用户选择设备 列表中可能异常的UPnP设备，所述异常处理装置在该UPnP设备没有 对该选择做出应答的情况下，判断该UPnP设备异常。
16、 如权利要求13所述的UPnP控制点设备，还包括进入/退出处 理装置，在未收到来自UPnP设备的对该询问的应答的情况下，将该 UPnP设备从设备列表中删除。
17、 如权利要求14所述的UPnP控制点设备，其中，在来自UPnP设备的存活消息中不存在再送间隔字段时，将所述规定时间设置为该 UPnP设备的生存期间的分数倍。
18、 如权利要求14所述的UPnP控制点设备，其中，在来自UPnP设备的存活消息中存在再送间隔字段时，将该字段的值设置为规定时间。
19、 如权利要求17或18所述的UPnP控制点设备，其中，在UPnP设备的生存期间大于阈值时，将该规定时间设置为一固定值。
20、 一种UPnP设备，包括存储装置，存储该UPnP设备的生存期间和用于发送存活信息的再 送间隔；存活通知装置，用于UPnP在设备登陆时向UPnP控制点设备发送 至少包括该UPnP设备的生存期间和再送间隔的消息；以及应答生成装置，在从UPnP控制点设备接收到询问时生成针对该询 问的应答消息，以发送给UPnP控制点设备。
21、 如权利要求19所述的UPnP设备，其中所述再送间隔被设定为 所述生存期间的分数倍。
22、 如权利要求21所述的UPnP设备，其中所述存活通知装置按照 再送间隔向UPnP控制点设备发送存活消息。
23、 一种网络系统包括至少一个UPnP控制点设备和至少一个UPnP 设备，至少一个UPnP控制点设备包括异常处理装置，基于预定的准则判断该UPnP设备是否异常；以及询问装置，在该UPnP设备发生异常的情况下，以主动询问的 方式向该UPnP设备确认该UPnP设备是否退出网络； 至少一个UPnP设备包括存储装置，存储该UPnP设备的生存期间和用于发送存活信息 的再送间隔；存活通知装置，用于在UPnP设备登陆时向UPnP控制点设备 发送至少包括该UPnP设备的生存期间和再送间隔的消息；以及应答生成装置，在从UPnP控制点设备接收到询问时生成针对 该询问的应答消息，以发送给UPnP控制点设备。
全文摘要
公开了一种通过UPnP控制点控制网络中的UPnP设备的方法、控制点设备、相应的UPnP设备和系统，方便用于尽早发现设备的异常退出。该方法包括步骤UPnP控制点基于预定的准则判断该设备是否异常；以及在该设备发生异常的情况下，UPnP控制点以主动询问的方式向该设备确认该设备是否退出网络。利用上述方案，控制点可以在设备异常退出的情况下尽早发现，进而做出正确操作。
文档编号H04L29/12GK101610293SQ200810130219
公开日2009年12月23日 申请日期2008年6月16日 优先权日2008年6月16日
发明者张东辰, 林良行, 申小虎, 石渡丰史 申请人:松下电器产业株式会社