CN101176293A - 网络发现机制 - Google Patents
网络发现机制 Download PDFInfo
- Publication number
- CN101176293A CN101176293A CNA2005800434029A CN200580043402A CN101176293A CN 101176293 A CN101176293 A CN 101176293A CN A2005800434029 A CNA2005800434029 A CN A2005800434029A CN 200580043402 A CN200580043402 A CN 200580043402A CN 101176293 A CN101176293 A CN 101176293A
- Authority
- CN
- China
- Prior art keywords
- network
- information
- service
- mobile device
- server
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Abstract
本发明涉及一种用于移动设备的网络发现从而使用IP网络内大量接入网络中的至少一个的方法,包括:当移动设备从任何位置连接到IP网络时,基于一套标准来获取给定位置附近的特定网络信息。
Description
技术领域
本申请涉及网络发现机制的方法,其包括例如用于安全快速切换的网络发现机制的方法等等。根据35 U.S.C.119本申请要求以下每一个美国临时专利申请的优先权:1)序列号60/625,106,提交于2004年11月5日,发明名称为“用于安全快速切换的网络发现机制”;2)序列号60/593,377,提交于2005年1月9日,发明名称为“网络发现机制”;3)序列号60/670,655,提交于2005年4月13日,发明名称为“网络发现机制”;4)序列号60/697,589,提交于2005年7月11日,发明名称为“针对802.1基准文档的RDF模式更新”。上述四个临时专利申请中的每一个的全部公开内容通过全文引用包括在此。另外,本受让人申请的以下未决的专利申请通过引用包括在此作为背景技术:美国专利申请序列号10/761,243,发明名称为“使用预鉴定、预配置和/或虚拟软切换的移动架构”,提交于2004年1月22日。
背景技术
网络和互联网协议:
现在有许多类型的计算机网络,其中互联网具有最高的知名度。互联网是全世界的计算机网络。当今,互联网是对数已百万计的用户可用的,公共的自立网络。互联网使用一套称为TCP/IP(也就是传输控制协议/互联网协议)的通信协议来连接主机。互联网具有通信基础架构,即人们所知的互连网主干。对互联网主干的访问权大部分被互联网服务提供商(ISP)控制,他们将访问权重新销售给企业或个人。
关于IP(互联网协议),这是一种协议,通过它,数据可以在网络上从一个设备(例如,电话、PDA(个人数字助理)、计算机等)发送到另一个设备。当今有多种IP版本,包括,例如IPv4,IPv6,等等。网络上的每台主机至少拥有一个IP地址,这是其自身的唯一标识。IP是一种无连接协议。终点之间的连接在通信期间不是连续性的。当用户发送或接收数据或消息时,数据或消息被分割为单元,也就是人们所知的包。每个包作为一个独立的数据单元来处理。
为使互联网或类似网络上的点之间的传输标准化,OSI(开放系统互联)模型建立起来。OSI模型将网络上两点之间的通信过程划分为七个栈层,每一层添加其自己的功能集。每个设备都对消息进行处理,这样在发送终点有向下的流程穿越每一层而在接收终点有向上的流程穿越每一层。提供七层功能的程序和/或硬件通常是设备操作系统、应用软件、TCP/IP和/或其他传输和网络协议、以及其他软件和硬件的结合。
通常,顶部的四层在从或向用户传递消息时使用,而底部的三层在通过设备(例如IP主机设备)传递消息时使用。IP主机是指网络上的能够发送和接收IP包的设备,例如服务器、路由器或工作站。去往其他主机的消息不被传递到上层而是转发到其他主机。OSI模型的层次在下面列出。第7层(也就是应用层)举例来说是,识别通信伙伴,识别服务质量,考虑用户身份鉴定及隐私、识别数据语法限制等的层次。第6层(也就是表示层)举例来说是,将输入和输出数据从一种表示格式转化为另一种格式等的层次。第5层(也就是会话层),举例来说是,设置、调整以及终止应用功能程序之间的会话、交换和对话等的层次。第4层(也就是传输层)举例来说是管理端到端的控制和误差校验等的层次。第3层(也就是网络层)举例来说是处理路由和转发等的层次。第2层(也就是数据链路层)举例来说是为物理层提供同步,进行位填充并且提供传输协议知识和管理等的层次。电气电子工程师协会(IEEE)将数据链路层进一步划分为两个子层,控制来自和去向物理层的数据传输的MAC(媒体访问控制)层,以及与网络层连接并解释命令并进行错误恢复的LCC(逻辑链路控制)层。第1层(也就是物理层)举例来说是在物理级别上通过网络传送比特流的层次。IEEE将物理层进一步划分为PLCP(物理层会聚协议)子层和PMD(物理介质相关)子层。
无线网络:
无线网络可以合并多种类型的移动设备,诸如举例来说蜂窝和无线电话、PC(个人计算机)、膝上计算机、可佩戴计算机、无绳电话、寻呼机、耳机、打印机、PDA等等。例如,移动设备可以包括用于安全快速的无线传输语音和/或数据的数字系统。典型的移动设备包括下列部件中的一些或全部:收发器(也就是发送器和接收器,包括例如具有集成的发送器和接收器以及,如果需要的话,其他功能的单片收发器);天线;处理器;一个或多个音频变换器(例如,音频通信设备中的扬声器、麦克风);电磁数据存储器(诸如举例来说,在提供数据处理的设备中的ROM、RAM、数字数据存储器等等);内存;闪存;全芯片组或集成电路;接口(诸如举例来说,USB、CODEC、UART、PCM等的功能);和/或其他。
移动用户可以通过无线连接而连接到局域网(LAN)的无线LAN(WLAN)可以被用于无线通信。无线通信可包括,例如,通过诸如光、红外线、射频、微波等电磁波传播的通信。现存有多种WLAN标准,诸如举例来说,蓝牙、IEEE 802.11以及HomeRF。
举例来说,蓝牙产品可以用于提供移动计算机、移动电话、便携式手持设备、个人数字助理(PDA)以及其他移动设备之间链接以及与互联网的连接。蓝牙是一种计算和电信工业规范,详细描述了移动设备如何能够使用短距离无线连接,容易地与彼此以及与非移动设备互联。蓝牙建立了数字无线协议以解决需要彼此保持数据同步和一致的多个移动设备的扩散所产生的终端用户的问题,从而允许来自不同供应商的设备一起无缝的工作。蓝牙设备可根据常规命名概念来命名。例如,蓝牙设备可以拥有蓝牙设备名称(BDN)或与唯一的蓝牙设备地址(BDA)相关联的名称。蓝牙设备也可以参与互联网协议(IP)网络。如果蓝牙设备在IP网络上运行,将为它提供IP地址和IP(网络)名称。因而,配置为参与IP网络的蓝牙设备可包含例如BDN、BDA、IP地址和IP名称。术语“IP名称”是指与接口的IP地址相应的名称。
IEEE的标准IEEE 802.11规定了用于无线LAN和设备的技术。使用802.11,无线组网可以由支持多个设备的每个基站来实现。在某些例子中,设备可能预先装配了无线硬件或者用户可以安装独立的硬件,例如包括天线的卡。举例来说,802.11中使用的设备,无论该设备是接入点(AP)、移动站(STA)、网桥、PCMCIA卡或其它设备,都包括三个显著的元件:射频收发器;天线;以及控制着网络上点之间的包流的MAC(媒体访问控制)层。
另外,多接口设备(MID)可以在某些无线网络中被利用。MID可包含两个独立的网络接口,例如蓝牙接口和802.11接口,从而允许MID参与两个隔离的网络,也可以与蓝牙设备交互。MID可以具有IP地址和与该IP地址相关联的普通IP(网络)名称。
无线网络设备可以包括,但不限于蓝牙设备、多接口设备(MID)、802.11x设备(包括例如802.11a、802.11b和802.11g设备在内的IEEE802.11设备)、HomeRF(家庭射频)设备、Wi-Fi(无线保真)设备、GPRS(通用分组无线业务)设备、3G蜂窝设备、2.5G蜂窝设备、GSM(全球移动通信系统)设备、EDGE(增强数据率GSM演进)设备、TDMA型(时分多址)设备、或包括CDMA2000在内的CDMA型(码分多址)设备。每个网络设备可包含不同类型的地址,包括但不限于IP地址、蓝牙设备地址、蓝牙常规名称、蓝牙IP地址、蓝牙IP常规名称、802.11 IP地址、802.11 IP常规名称或IEEE MAC地址。
无线网络也可以包括在例如移动IP(互联网协议)系统、PCS系统以及其他移动网络系统中建立的方法和协议。关于移动IP,其包括由互联网工程工作小组建立的标准通信协议。使用移动IP,移动设备用户能跨越网络移动而保持他们一次性分配的IP地址。见请求评论(RFC)3344。NB:RFC是互联网工程工作小组的正式文档。移动IP增强了互联网协议(IP)并添加了移动设备在本地网络外面连接时向其转发互联网业务的方法。移动IP向每个移动节点分配本地网络上的本地地址、以及用于在网络及其子网中识别设备当前位置的转交地址(CoA)。当设备被移动到不同的网络中,它将收到新的转交地址。本地网络上的移动代理能将每个本地地址与其转交地址相关联。移动节点可以在它每次更改其转交地址的时候使用例如互联网控制消息协议(ICMP)向本地代理发送绑定更新。
在基本IP路由(例如外部移动IP)中,路由机制依赖于每个网络节点始终具有不变的到例如互联网的连接点,以及每个节点的IP地址识别其连接到的网络。在本文档中,术语“节点”,包括连接点,其可以包括例如重新分配点或数据传输的终点,并且其可以识别、处理和/或向其他节点转发通信。例如,互联网路由器可以查看例如标识设备的网络的IP地址前缀等等。然后,在网络级别,路由器可以查看例如标识某一特定子网的比特集。然后,在子网级别,路由器可以查看例如标识某一特定设备的比特集。使用典型的移动IP通信,如果用户将移动设备从例如互联网断开并尝试将其重新连接到新的子网,那么该设备必须重新配置新的IP地址、合适的网络掩码和默认路由器。否则,路由协议将无法正确的传递包。
优选实施例改进了在例如下列参考文献中所描述的技术,这些参考文献中的每一个通过全文引用包括在此:
[1]Sun Microsystems,.Jini Connection Technology,.
http://www.sun.com/jinni.
[2]Sun Microsystems,.Jini Community Resources:Jini TechnologyArchitectural Overview,.January 1999.
http://www.sun.com/jini/whitepapers/architecture.html
[3]Sun Microsystems,.Jini Community Resources:Jini Specificationv1.0.1,.www.sun.com/jini/specs.
[4]W.Keith Edwards,Core JINI,The Sun Microsystems Press JavaSeries,Prentice Hall,1999.
[5]Microsoft Corporation,.Universal Plug and Play:Background,
http://www.upnp.org/resources/UpnPbkgnd.htm.
[6]Microsoft Corporation,.Universal Plug and Play Device ArchitectureVersion 1.0,.June 8,2000.
http://www.upnp.org/UpnPDevice Architecture 1.0.htm
[7]Yaron Y.Goland,Ting Cai,Paul Leach,Ye Gu,and Shivaun Albright,.Simple Service Discovery Protocol,.IETF Draft draft-cai-ssdp-v1-03.txt,Oct 28,1999.http://www.ietf.org/internetdrafts/draft-cai-ssdp-v1-03.txt
[8]Salutation Consortiuim,.Salutation Architecture Specification Version2.0c.Part 1,.The Salutation Consortium,June 1,1999.
http://www.salutation.org
[9]Salutation Consortium,.Salutation Architecture Specification Version2.0c.Part 2,.The Salutation Consortium,June 1,1999.
http://www.salutation.org
[10]Bob Pascoe,.Salutation-Lite:Find-and-Bind Technologies for MobileDevices,.Salutation Consortium,June 6,1999.
http://www.salutation.org/whitepaper/Sal-Lite.PDF
[11]Brent Miller,.Mapping Salutation Architecture APIs to BluetoothService Discovery Layer.Bluetooth Consortium 1.C.118/1.0,July 1,1999
[12]Bob Pascoe,.Salutation Architectures and the newly defined servicediscovery protocols from Microsoft and Sun,Salutation Consortium,June 6,1999.http://www.salutation.org/whitepaper/Jini-UPnP.PDF
[13]Ryan Troll,.Automatically Choosing an IP Address in an Ad-HocIPv4 Network,.IETF Draft draftietf-dhc-ipv4-autoconfig-05.txt,March 2,2000.
http://www.ietf.org/internet-drafts/draft-ietf-dhcipv4-autoconfig-05.txt.
[14]Bluetooth Consortium,.Specification of the Bluetooth System CoreVersion 1.0B:Part E,Service Discovery Protocol(SDP),Nov 29,1999.
http://www.bluetooth.com/developer/specification/specification.asp
[15]Bluetooth Consortium,.Specification of the Bluetooth System CoreVersion 1.0B:Part K:2,Service Discovery Application Profile,.Dec 1,1999.http://www.bluetooth.com/developer/specification/specification.asp.
[16]IETF SVRLOC Working Group,.Service Location Protocol HomePage,.http://www.srvloc.org.
[17]E.Guttman,C.Perkins,J.Veizades, and M.Day,.Service LocationProtocol,Version 2,.IETF RFC 2608,June 1999.
http://www.ietf.org/rfc/rfc2608.txt.
[18]E.Guttman,C.Perkins,and J.Kempf,.Service Templates andService:Schemes,.IETF RFC 2609,June 1999,
http://www.ietf.org/rfc/rfc2609.txt
[19]Rekesh John,.UPnP,Jini and Salutation.A look at some popularcoordination frameworks for future networked devices,CaliforniaSoftware Labs,June 17,1999.
http://www.cswl.com/whiteppr/tech/upnp.html
[20]IETF ZEROCONF Working Group,.Zero ConfigurationNetworking(zeroconf),
http://www.ietf.org/html.charters/zeroconf-charter.html.
[21]INS:Intentional Naming System,
http://wind.lcs.mit.edu/projects/ins.
[22]The Berkeley Service Discovery Service,
http://www.cs.berkeley.edu/~caerwin/sds-project.html.
[23]R.Droms,.Dynamic Host Configuration Protocol,.IETF RFC 2131,March 1997.http://www.ietf.org/rfc/rfc2131.txt.
[24]Sun Microsystems,.Java 2 Platform Midcro Edition(J2ME)Technology for Creating Mobile Devices,White Paper,May 19,2000.
http://java.sun.com/products/cldc/wp/KVMwp.pdf
[25]World Wide Web Consortium,.Extensible Markup Language(XML).,http://www.w3.org/XML
[26]Marco Liebsch and Ajoy Singh(editors),“Candidate Access RouterDiscovery”,Internet Draft draft-ietf-seamoby-card-protocol-06.txt,Internet Engineering Task Force,June 2004.
[27]J.Hodges and R.Morgan,“Lightweight Directory Access Protocol(v3):Technical Specification”,IETF RFC 3377,September 2002.
[28]M.Liebsch,A.Singh,H.Chaskar,D.Funato and E.Shim,“Candidate Access Router Discovery,”Internet-Draft,work in progress,June 2004.
[29]K.Arabshian and H.Schulzrinne,“GloServ:Global ServiceDiscovery Architecture,”First International Conference on Mobile andUbiquitous Systems:Networking and Services.
发明内容
本发明在以上和/或其他背景技术和/或其中的问题上做了改进。
根据某些优选实施例,对于例如,在同类或异种接入网络之间的实时地安全漫游/切换中减少延迟和瞬时数据丢失,可以使用诸如安全预鉴定之类的主动式切换机制。预鉴定包括,例如,在移动设备移动到网络中之前与该网络进行鉴定。为了获得与目标邻近网络的预鉴定,移动设备应在该设备仍在目标网络之外的时候从目标网络获得信息,例如,IP地址,然后应该与例如目标网络中的鉴定代理(诸如,举例来说,PANA鉴定代理)建立安全关联。为了做到这一点,移动设备应该事先发现目标网络中的各种网络元素的参数,这样该移动设备能够与这些网络元素通信从而建立主动式安全关联。本文尤其描述了多种用于移动设备在移动到目标网络之前发现目标网络中的网络元素的方法。本文尤其还描述了例如网络发现如何能帮助提供使用了安全预鉴定和主动式IP地址获取的快速切换。
根据某些实施例,用于移动设备的网络发现从而使用IP网络中大量接入网络的至少其中之一的方法包括:当移动设备从任意位置连接到IP网络的时候,在给定位置的附近区域基于一系列标准获取具体网络信息。
在某些实例中,网络信息包括移动设备使用的用于访问接入网络的信息。在某些实例中,该信息包括接入点的网络连接点标识。在某些实例中,该信息包括接入点支持的安全类型。在某些实例中,该信息包括第3层类型。在某些实例中,该信息包括供应商名称。在某些实例中,该信息包括服务器或代理的地址。在某些实例中,该信息包括鉴定代理的地址。在某些实例中,该信息包括接入路由器的地址。
根据某些实施例,用于移动设备发现目标网络的网络信息的方法包括:a)动态建立网络信息的至少一个发现数据库;以及b)在移动设备连接到目标网络之前,使用至少一个发现数据库来提供关于目标网络的网络信息。
在某些实例中,该方法使用一种用于信息服务的应用层机制(AIS)。在某些实例中,该方法用于发现移动设备用来进行切换和预鉴定的信息。在某些实例中,该方法使用独立于第2层的AIS。在某些实例中,该方法使用网络辅助的发现机制。在某些实例中,该方法使用移动辅助的发现机制。在某些实例中,该方法使用网络辅助的机制来建立数据库。在某些实例中,该方法使用移动辅助的机制来建立数据库。在某些实例中,移动设备查询AIS服务器或同级移动设备来获取关于目标网络中的网络元素的信息。在某些实施例中,该方法进一步包括使用报告代理(RA)来获取信息。在某些实例中,该方法进一步包括使用AAA服务器来获取信息。在某些实例中,该方法进一步包括使用DNS服务器来获取信息。在某些实例中,该方法使用移动设备作为信息服务器的对等模型。在某些实例中,该方法使用限定范围组播的方法。在某些实例中,该方法使用循环广播的方法。
多个实施例的以上和/或其他方面、特性和/或优点将从结合附图对的以下描述中被进一步了解。多个实施例可以在适用的情况下包括和/或排斥不同的方面、特性和/或优点。另外,多个实施例可以在适用的情况下将其它实施例的一个或多个方面或特性进行结合。对特定实施例的方面、特性和/或优点的描述不应被认为是对其他实施例或权利要求的限制。
附图说明
本发明的优选实施例以示例而非限制的方式在附图中示出,其中:
图1是其中示出了Jini连接技术的架构的视图;
图2是UPnP协议栈的视图;
图3是示出了Salutation管理器模型的视图;
图4是示出了本地服务和网络功能的协同发现的视图;
图5是示出了使用功能报告代理(RA)来填充数据库的视图;
图6是示出了网络服务发现的协议流的视图;
图7是示出了基于地理坐标的网络服务发现的示例视图;
图8是示出了基于AP的MAC地址的网络服务发现的示例的视图;
图9是示出了基于对等的网络发现的视图;
图10是示出了基于范围的组播的视图;
图11是示出了循环广播的视图;
图12是示出了网络发现和安全无缝切换的集成的视图;
图13是示出了示例集成流程(网络发现+预鉴定)的视图;
图14是示出了网络发现和预鉴定流程图的视图;
图15是示出了数据库引擎的不同组件之间交互的视图;
图16(A)-(C)是示出了相关的演示系统的视图;
图17(1)-17(10)是示出了用于网络发现的使用了XML格式的示意性且非限制性的RDF方法的视图;
图18(1)-18(10)是示出了与服务接入点(SAP)定义和调用流程有关的示范实施例和方面的视图;
图19(1)-19(13)是示出了与附件A中对以上列出的提交于2005年11月5日的第一个临时申请所作的阐述的MIH功能和信息服务相关的示范实施例和方面的视图;
图20示出了当前定义的RDF/XML模式的图形表示;
图21(1)-21(2)示出了RDF/XML格式中表示的基本模式;
图21(3)-21(12)示出了RDF/XML格式中表示的扩展模式;
图22示出了802.21 MIIS基本模式的图形表示示例,其中“网络”、“L2”、“L3”、“位置”、“IPv4”、“IPv6”、“连接类型”、“PoA”、“成员地址”、“地理坐标”表示为类,其他则为类的属性。
具体实施方式
本发明可以以很多不同的形式来实施,在此对多个示范实施例进行描述,应理解为这些内容应被当作是为本发明的原理提供示例,并且这些示例并不试图将本发明限制在此处描述或示出的优选实施例。
3引言
在基于无线LAN(局域网)和蜂窝技术的无线联网技术发展过程中,随着移动服务的流行以及人们变得更具移动性,对于移动设备来说更加重要的是能够用及时、精确和有效的方式,找到合适的满足应用需求和移动特性的网络连接点。我们将这种功能称为网络发现。
本文中讨论的网络发现问题定形为:当移动设备从任意位置连接到IP网络时,在给定位置的附近区域基于一系列标准获取具体网络信息。其中:
●网络信息可以是移动设备用于接入网络的任何信息。这些信息包括,例如,网络连接点标识(例如L2地址和/或接入点的地理地址)、接入点的MAC类型(例如,“802.11g”)、接入点支持的安全类型(例如,“WPA”或“PANA和IPsec”)、第3层类型(例如“仅IPv4”或“IPv4/v6双栈”)、供应商名称、或服务器或代理(例如,PANA鉴定代理、接入路由器、SIP服务器和移动IP本地代理)的地址。
●移动设备的位置或移动设备要寻找其信息的位置可以用不同的方式来标识(表示)。例如,其可以由地理位置、由网络标识符、或者由网络中的无线接入点或IP接入路由器的地址来标识。
发现网络信息的功能能够用来更好的支持迁移和移动服务。例如,为了减少切换过程中对正在进行的应用进程的中断,移动设备可以在其开始切换进入目标网络之前,与目标网络进行预鉴定。为了做到这一点,移动设备在移动到目标网络中之前将需要关于邻近网络的信息,例如目标网络中的鉴定服务器的地址。我们将把移动设备发现关于其邻近网络的信息的过程,称为网络邻居发现。
网络发现中的一个重要问题是发现数据库建立的问题:如何以自动、动态和有效的方式建立网络信息的数据库?在多供应商的环境中解决这个问题不是微不足道的,在这种环境中某个网络供应商可能不愿意向与它竞争的其他网络供应商公开其自身网络的任何网络信息,而它可能会为了更好的服务而向它的用户提供其网络的详细网络信息。无论如何,对这个问题还没有可行的解决方案。
现在有许多为服务发现而设计的协议(见第2部分)。然而,这些协议中没有一个为下列功能提供支持:
●发现关于邻近网络的信息
●动态建立发现数据库
●确定将什么信息收集并发送给移动设备
作为替代,现有的服务发现机制关注于如何检索数据库中已经存在的信息。它们依赖所有的本地网络提供商实现服务信息服务器,这过于严格而无法在公共网络中配置。
本文描述了一种支持网络发现的新架构,其包括解决发现数据库建立问题的方法和移动设备发现关于邻近网络信息的方法。这种架构称为用于信息服务的应用层机制(AIS)。AIS被设计为可扩展从而足以支持移动设备可能需要的当前和未来的网络信息类型。AIS尽可能的均衡现有的协议。尽管关于网络元素的信息可能有多种用途,我们关注于发现移动设备可用的信息从而实现主动式的切换和安全的预鉴定,并且讨论这些信息可以如何使用,从而支持安全和主动的切换。
4相关工作
当今存在多种服务发现协议和架构,包括SLP、JINI、UPnP、Salutation以及LDAP。然而,它们大多数关注于信息已经在数据库中可用的假设下,用户如何检索服务相关信息。服务相关信息以及因此用于储存信息的服务器可以组织成一种层状结构,例如,以一种类似于互联网域名系统(DNS)的方式。服务相关信息在服务器上可以是预先配置的或动态的。然后该信息可以被人类管理员更新或彼此交换更新的服务器本身自动的更新。
当网络尺寸和用户数量增长的时候,要发布的预先配置信息将不是可扩展的解决方案,无论发布的是服务相关信息还是网络信息。要求服务器自动的填充和更新网络信息同样有许多限制,包括以下:
●每个移动设备希望知道的网络信息会依赖移动设备的能力和应用而显著的不同。例如,某些移动设备可能希望知道邻近网络中DHCP服务器的地址或鉴定服务器的地址,这样该移动设备可以在其需要切换到邻近网络之前,从邻近网络获取IP地址并与邻近网络进行预鉴定。其他移动用户可能只希望知道可用的本地服务。对于网络提供商很难预见到什么信息将会被大量各种各样的当前或未来的用户所需要。结果,对于网络提供商来说很难确定在信息服务器中维护什么信息。
●移动用户将需要依赖本地网络提供商来提供信息服务器。很难期待全世界任何地方的所有的网络提供商都将提供此种信息服务器。更进一步说,不同网络提供商可能选择提供不同的信息集。
●当今可用的多种服务发现协议中没有一种似乎是显著的胜者而足够的灵活从而处理各种各样的以及不停变化的服务和移动用户所需的网络信息。结果,不同的网络供应商可能会使用不同的服务发现协议。这意味着用户可能不得不在不同的网络中使用不同的服务发现协议,这对用户是沉重的负担。
最近,设计特别用于支持网络邻居发现的发现协议的一些努力正在进行当中。代表性的例子是备选接入路由器发现(CARD)协议[28]。备选接入路由器是移动设备将要进入的邻近网络中的接入路由器。CARD被设计为在该移动设备进行IP层切换进入邻近网络之前,被移动设备用来发现备选接入路由器,其目的是支持无缝的IP层切换。使用CARD,移动设备在做出关于IP层切换的决定之前,监听来自邻近网络中的接入点的第2层标识符,例如IEEE 802.11 BSSID广播。该移动设备然后将这些第2层标识符发送到其当前网络中的接入路由器,该路由器又映射邻近网络中的备选接入路由器的第2层标识符和IP地址,然后将备选接入路由器地址发送到移动设备。使用CARD来支持网络邻居发现带来了以下限制:
●CARD要求邻近接入路由器彼此动态的通信以交换功能信息。当邻近网络属于不同的网络提供商的时候,这一般是不可能的。
●为了发现目标接入路由器,移动设备需要使用CARD与其当前的接入路由器通信。很难期待全世界所有的接入网络都实现了CARD。
●用户使用CARD可以发现的信息依赖于本地网络提供商配置其CARD协议提供什么信息,并且可能在不同的网络显著的不同。此外,如上面讨论的,网络提供商可能未提供移动设备所需要的正确的信息,因为网络提供商不容易预见每个移动设备上的联网软件和应用的各种各样且不断变化的需求。
最近,IEEE 802.11 TGu(任务小组U)开始考察通过何种方法能够提供更高层次的信息作为第2层的信号的一部分。用这种方式,移动设备被动的监控来自邻近网络的信号;其可以决定其他第3层信息。但是由于最大传输单元尺寸限制了所有的第3层信息无法提供为第2层信号的一部分。而且可能也很难支持多种异种接入技术。因此,拥有一种对于第2层不可知而且能够跨越多种异种接入工作的解决方案是很重要的。作为本提议的一部分,我们提出了一种应用层网络邻居发现过程以发现诸如邻近网络的IP地址、QoS(服务质量)和安全参数之类的不同参数。
4.2关于现有服务发现机制的调查
随着无线ad-hoc网络的出现,专门的信息设备正在接管此技术区域。这些信息设备为了支持迁移而产生,本质上,并且从而在它们之间进行合作,因为合作是补充移动设备与传统的全能计算设备相比缺少的某些部分的不可或缺的特性。为了这种合作,提出了多种服务发现协议(SDP)作为确保以简单、无缝和可扩展的设备互操作性为最终目的的设备交互的合作架构的一部分。在新兴的SDP中,Jini,通用即插即用,Salutation以及SLP是比较突出的。
3.3.1 JINI连接技术
Jini架构的目的是将设备和软件部件联合成为单个动态的分布式系统[2]。Jini系统提供用于在分布式系统中服务的建立、查找、通信以及使用的机制。服务的示例包括诸如打印机、显示器或磁盘的设备;诸如应用程序或实用组件的软件;诸如数据库和文件的信息;以及系统用户。
Jini系统的中心是称为发现、加入和查询的三重协议[2]。这些协议中的一对,也就是发现和加入,在设备插入的时候发生。发现在服务寻找用于注册的查找服务的时候发生。加入在服务定位到查找服务并且希望加入它的时候发生。查找在客户端或用户需要定位并且调用由其接口类型(用Java编程语言写成)和可能的其他特征描述的服务的时候发生。以下步骤表示在Jini群落中客户端使用的服务需要在客户端、服务提供商和查找服务之间的交互[2][1]。
1)服务提供商通过在本地网络或它事先已知的远程查找服务上组播一个服务请求来定位查找服务。
2)服务提供商向查找服务注册服务对象及其服务属性。服务对象包含服务的Java编程语言接口,其包括用户和应用为执行服务而将调用的方法,以及任何其他描述性属性。
3)客户端用Java类型以及,可能,其他服务属性来请求服务。服务对象的拷贝移动到客户端,并被客户端用于与服务对话。
4)然后,客户端通过服务对象直接与服务提供商交互。
Jini连接技术包括解决设备如何彼此连接从而形成即兴群体的基本问题的基础架构和编程模型。基于图1所示[1][2]的Java技术,Jini技术使用Java远程方法调用协议在网络中移动代码。网络服务运行在Jini软件架构的顶部。关于这部分,图1示出了Jini连接技术的架构。
a.查找服务
查找服务可以看成是一种目录服务,服务在其中通过它被发现和解决。在Jini群体中,服务通过发现和加入过程向查找服务注册它们的代理对象,用户查询查找服务从而找到他们想要的服务。Jini使用三种适用于不同情况的相关的发现协议[3][4]。组播请求协议用于应用或服务第一次成为活动的,并且需要在附近找到查找服务的时候。组播声明协议被查找服务用来向可能会对群体感兴趣的服务声明它们的存在。单播发现协议用于跨广域网与其预先已知的具体查找服务建立通信。
但是Jini查找服务所作的远比简单的名称服务器多。客户端将服务看成一种接口,其包含着客户端为了执行服务而将调用的方法,以及其他描述性属性。查询服务将客户端所见的接口与服务代理对象集建立映射。客户端下载服务代理,其实际上是能够传达回服务器的RMI存根。该代理对象使客户端可以在对其一无所知的情况下使用该服务。因此,无需设备驱动的情况。尽管服务代理对象是服务调用的典型情况,也就是,通过RMI方法调用来访问服务,然而下载的服务对象可以是服务本身或能够表达任何专用通信协议的智能对象。
b.租借
在Jini系统中对服务的访问是在租借的基础上被允许的:服务被请求了一个时间段,然后,在服务用户和提供商之间的协商的时间段内被允许。这种租借必须在其过期之前进行更新。否则,与服务相关联的资源将被释放。例如,查询服务允许对某服务注册的租借并且服务需要不断的更新该租借。设备可能会突然离开群体或出现故障,而没有机会来将自己注销。因此,正是租借使Jini系统保持健壮而且免维护。
c.远程事件和交易
除了基础的服务发现/加入和查找机制之外,Jini还支持远程事件和交易,其帮助编程者以可靠和可扩展的方式来编写分布式程序。远程事件使对象能在所需的变化在系统中发生的时候得到通知。这些事件可以被新发布的服务或某些服务状态的改变来触发。例如,注册了其感兴趣的打印机的Jini掌上型电脑,可以在该打印机变得可用时得到查找服务的提醒。同样,Jini支持两阶段提交(2PC)协议。Jini生来就是用于建立分布式系统的,在这样的系统中可靠性和健壮性可能会被局部的故障和恢复所削弱。但是Jini 2PC具有灵活性,在其中它没有规定本协议被严格的遵守。而是将它留给了应用(交易参与者)以执行应用逻辑所希望的必要的动作。
3.3.1 UPnP(通用即插即用)
通用即插即用(UPnP)[6]是用于所有形式因素的智能仪表、无线设备以及PC的普遍的对等(peer-to-peer)网络连接性的架构。尽管引进它是作为一种即插即用外围设备模型的扩展,但UPnP不仅仅是简单的扩展。在UPnP中,设备可以动态的加入网络,获取IP地址,根据请求传送其功能,以及了解其他设备的存在及其功能。最终,设备可以平稳并且自动地离开网络,而不留下任何不期望的状态[6]。通用即插即用影响了TCP/IP和网络技术,其中包括IP、TCP、UDP、HTTP和XML,从而除了实现在家庭和办公室的联网的设备中的控制和数据传输之外,还实现了无缝的邻近联网。
UPnP使用简单服务发现协议(SSDP)[7]用于服务发现。该协议用于向其他设备声明设备的存在,以及发现其他设备或服务。因此,SSDP类似于Jini中的三重协议:发现、加入和查找。SSDP在组播上和单播UDP上使用HTTP,分别称为HTTPMU和HTTPU。
要加入的设备发出广告(ssdp:alive)组播消息从而向控制点宣告其服务。这些控制点是嵌入该设备的服务的潜在客户。与Jini不同,在UPnP中没有中央服务注册。其他的SSDP信息是当新的控制点加入网络时所发送的搜索(ssdp:discover)组播消息。任何听到此组播的设备应当用单播响应消息对其做出响应。
XML用于描述设备的特性和功能。上述广告消息包含指向网络中的一个描述UPnP设备功能的XML文件的URL。因此其他设备,通过重新获得此XML文件,可以查看这个设备的特性并且决定是否其符合它们的目的。与Jini的简单服务属性相反,此XML描述允许对设备功能的复杂、强大的描述。
图2示出了示范性的UPnP协议栈。为设备之间的通信,UPnP使用图2中所示的协议栈[6]。根据最新的规范[6],UPnP可以概括为以下5个步骤。
发现:UPnP的发现协议基于SSDP。当设备加入网络时,该设备向网络上的控制点广告它的服务。相似地,当控制点加入网络时,UPnP允许控制点在网络上搜索感兴趣的设备。在两种情况中基本交换的是一种发现消息,其包括设备或其服务之一的一些本质规定,例如其类型、标识符以及指向更详细信息的指针。
描述:当控制点发现了设备之后,控制点仍然几乎不了解该设备。为了使控制点更多的了解该设备及其功能,或与其进行交互,控制点必须从设备在发现消息中提供的URL检索设备的描述。UPnP对设备的描述以XML来表示,并且包括任何嵌入式设备或服务的列表,以及用于控制、事件和表述的URL。
控制:当控制点检索到设备的描述之后,该控制点可以向设备的服务发送动作。为了做到这一点,控制点向服务的控制URL发送合适的控制消息。控制消息也用简单对象访问协议(SOAP)以XML来表示。像函数调用一样,在对控制消息的响应中,服务返回动作指定的值。
事件:UPnP对服务的描述包括服务响应的动作列表和模拟服务在运行时的状态的变量列表。当这些变量变化的时候服务将会发布更新,并且控制点可以预订接收这些信息。服务通过发送事件消息来发布更新。事件消息包含一个或多个状态变量的名称以及这些变量的当前值。这些消息也以XML表示并且使用通用事件提醒架构(GENA)进行格式化。
表述:如果设备有用于表述的URL,那么控制点可以从该URL重新获取一页,将该页载入浏览器,并且依赖于该页的功能,允许用户控制设备和/或查看设备状态。
UPnP的另一个重要特性是自动配置插入的IP地址。为此目的而引进的AutoIP[13]使设备能加入网络而无需任何外部的管理。当设备连接到网络的时候,它尝试从网络上的DHCP服务器获取IP地址。但是在没有DHCP服务器时,IP地址被自动地从为本地网络使用而保留的范围内进行请求。因此,称为AutoIP。设备通过在保留范围内随机选择地址然后产生APP请求来查看是否其他设备已经请求了该地址,来请求地址。
3.3.1 Salutation
Salutation是另一种主要的合作架构,由Salutation Consortium开发,用于在大量的设备和仪器以及具有广泛的连通性和移动性的环境中解决服务发现和利用的问题。给出目标设备的不同性质,该架构是与处理器、操作系统和通信协议独立的。该架构为应用、服务和设备提供标准的方法,来向其他应用、服务和设备描述并发布他们的功能。该架构还使应用、服务和设备能够向其他应用、服务或设备搜索特定功能,以及请求并且与其建立互操作会话从而利用它们的功能[8][9]。
如图3所示[8],Salutation架构由两个主要部件组成:Salutation管理器和传输管理器。Salutation管理器是架构的核心,与Jini中的查找服务相似。它被定义为一种服务调度器:服务提供商向Salutation管理器注册其功能。当客户端向其本地的Salutation管理器请求服务搜索的时候,该搜索由Salutation管理器之间的合作来完成。然后,客户端可以使用所返回的服务。Salutation管理器位于传输管理器上,无论下层的网络传输如何,都提供可靠的通信信道。
Salutation管理器向服务器和客户端应用提供与传输无关的接口。该接口(SLM-API)包括服务注册、服务发现以及服务访问功能。
Salutation架构的通信协议独立性是通过Salutation管理器和传输管理器之间的接口(SLMTI)实现的。传输管理器是依赖于其支持的网络传输的实体。Salutation管理器可以有多于一个的传输管理器,如果它连接到多种物理方面不同的网络。但是Salutation管理器通过与传输无关的接口(SLM-TI)来看到其下层的传输。
参考图3,此图示出了描述Salutation管理器的模型的视图。Salutation管理器所提供的主要任务可以概括如下。
服务注册:Salutation管理器包含了用于保存关于服务的信息的注册信息。客户端自行注册或注销。所有的注册都与本地Salutation管理器或与客户端连接的接近的一个管理器完成。这与Jini中的查找服务对应。
服务发现:Salutation管理器发现其他的Salutation管理器以及在那里注册的服务。通过对本地Salutation管理器指定的类型和属性集进行匹配来发现远程服务。这种Salutation之间的通信协议称为使用Sun的ONC RPC的Salutation管理器协议。这种称为功能交换的唯一的特性是必须的,因为服务基本都是在相同设备中与本地Salutation管理器进行注册的。Salutation管理器之间的合作形成了概念上相同的查找服务,但却是分布于网络上的,与Jini类似。
服务可用性:客户端应用可以请求本地Salutation服务器周期性的检查服务的可用性。该检查在本地管理器和相应的管理器之间完成。这是狭义版本的Jini远程事件的概念。
服务会话管理:会话管理从事Salutation的服务调用的方面。服务会话在客户端需要使用通过服务发现所发现的服务的时候建立。服务会话工作在3个不同的模式之一:本地模式、模拟模式以及salutation模式。依赖于工作模式,服务会话的消息交换中可能涉及Salutation管理器,也可能不涉及。在本地模式,消息通过本地协议进行交换而不会在消息交换中涉及Salutation管理器。在模拟模式,Salutation管理器被用于在客户和服务之间传送消息,但Salutation管理器不检查其内容。在salutation模式,Salutation管理器不仅传送消息,而且定义会话中使用的消息的格式。
功能单元定义为Salutation架构中的基本构成块。换言之,它是组成客户端或服务的最小的有意义的功能。功能单元的集合定义服务记录。例如,传真服务可以由[打印]、[扫描]和[传真数据发送]功能单元来定义。每个功能单元都包括描述性属性记录。这些服务/功能单元/属性记录由ISO8824 ASN.1做出规定。Salutation-Lite[10]也值得在此一提。Salutation-Lite是Salutation架构面向小覆盖区域的设备的精简版。Salutation Consortium预想到Salutation-Lite对于诸如掌上尺寸和手持电脑(也就是Palm和WinCE设备)的小型信息设备具有极大的适用性。Salutation-Lite还很好的将自己用于诸如IR和蓝牙的低带宽网络。
3.3.1 SLP(服务位置协议)及其它
服务位置发现(SLP)[17]是IETF版本的服务发现协议,但其与其它服务发现协议一样,具有唯一的背景、目标领域和特性。SLP是一种用于站点内的服务发现的分散式、轻量级的可扩展的协议[16]。SLP定义了服务URL,其为服务定义了服务类型和地址。例如,“service:printer:lpr://hostname”是hostname处可用的行式打印机服务的服务URL。基于该URL,用户浏览其站点中的可用的服务,并且利用所选服务来满足用户需求。例如,用户(应用)使用SLP来找出同一层上的任意彩色打印机。
SLP中有三个代理:用户代理(UA)、服务代理(SA)以及目录代理(DA)。UA是一种代表用户应用发送服务发现请求的软件实体。SA是代表服务发布服务的实体。作为集中的服务信息仓库,DA缓存来自于SA的公告,然后对来自UA的请求做出响应。SA通过向DA注册来发布自己。此注册消息包含所发布的服务的URL,服务的寿命以及服务的描述性属性集。SA应当在注册信息过期之前向DA周期性的更新。此寿命是为了防止网络留在过渡状态,并且在诸如Jini和UPnP的其它服务发现协议中也可以找到相似的概念。DA缓存注册信息并向SA发送肯定消息。UA向DA发送服务请求消息来请求服务的位置。然后,DA用包含了与UA的需求相符的服务的URL的服务应答消息做出响应。现在,UA就可以访问返回的URL所指向的服务了。在SLP中,DA是可选的。在小型网络中可以没有DA。在这种情况下,UA的服务请求消息被直接发送到SA。
SLP支持服务浏览和基于字符串的服务属性查询,这允许UA从网络上的服务中选则最合适的服务。UA可以请求查询运算符,例如AND、OR、比较算符(=、<、<=、>、>=)以及子字符串匹配。这比其它的都更加强大。例如,在Jini中,只能针对等式来进行服务属性匹配。
最终,SLP被称为是内联网服务发现需求的解决方案,但它能够很好的扩展到更大的网络。这种可扩展性被诸如尽可能少的使用组播消息、范围概念以及多DA等多种特性所支持。
蓝牙协议栈也包含用于服务发现的SDP[14]。由于蓝牙SDP是专门为蓝牙环境而设计,与其它服务发现协议相比,它支持有限的功能。基本上,SDP支持按照服务类搜索,按照服务属性搜索以及服务浏览。服务浏览在客户端对于客户附近区域可用的服务没有预先知识的时候使用。服务发现应用资料[15]定义了服务发现应用所使用的协议和步骤以定位其它设备中的服务。蓝牙SDP运行在预先设定的面向连接的L2CAP信道上。
为具有有限复杂度的蓝牙设备优化蓝牙SDP。因此,它解决了主要的服务发现问题。它既不提供对服务的访问、对服务的调度、服务发布,也不提供服务注册。当服务变为不可用的时候也没有事件通知。因此,其它服务发现协议可能可以用于完善这些缺陷。例如,Salutation可以用于上述蓝牙SDP。由于Salutation的与传输无关的架构,这种映射[11]看上去是灵巧的。
在这个领域中还有其它技术:零配置网络(zeroconf)[20],MIT的INS(互联网命名系统)[21]以及伯克利服务发现服务[22]。出于不同的目的,它们中的每一个都使用了与其它技术不同的方法。结果,与其它协议相比,它们具有某些强大和薄弱的特性。
最近,为了支持网络邻居发现而设计发现协议的努力正在进行当中。代表性的例子是被IETF标准化的备选接入路由器发现(CARD)[26]协议。备选接入路由器是移动设备将要进入的邻近网络中的接入路由器。CARD是一种协议,其能够被移动设备用于在移动设备进行IP层切换进入邻近网络之前发现备选接入路由器。使用CARD,移动设备在做出关于IP层切换的决定之前,监听来自邻近网络中的射频接入点(AP)的第2层ID。移动设备可以使用CARD协议来将这些第2层ID发送到其当前网络中的接入路由器,该路由器将依次把第2层ID映射到邻近网络中的备选接入路由器的IP地址,然后将备选路由器地址发送回移动设备。CARD具有以下限制:
●它要求邻近的接入路由器使用CARD协议来动态的交换网络信息,当邻近的网络属于不同的网络供应商时,这通常是不可能的。结果,CARD无法用于支持跨异种射频网络的迁移,举例来说,在属于不同网络供应商的蜂窝网络和无线热点网络之间。
●CARD还要求所有的接入路由器都实施CARD协议来与移动用户进行通信,这是一个很难的提议。
移动设备通过CARD所能够发现的信息依赖于每个独立的本地网络供应商配置其CARD协议提供什么信息,而这在不同的网络之间可能显著不同。每个移动设备希望知道的网络功能可能依赖移动设备的联网功能和应用而显著的改变,并且随时间变化。网络供应商很难预见到什么信息将是移动设备需要的。例如,具有进行预鉴定的功能的移动设备可能希望知道邻近网络中的鉴定服务器的地址,这样移动设备可以在其需要切换到邻近网络之前,与邻近网络进行预鉴定。其它移动设备可能只想知道,例如,邻近网络中SIP服务器/代理或DHCP服务器的地址。
LDAP(轻量级目录访问协议)[LDAP]是一种通用目录查找协议,并且它允许目录更新操作从而可被用于从移动设备收集数据。然而,LDAP对于基本网络发现问题不是合适的解决方案,因为(i)LDAP只支持对分层构建的数据库进行查询,而网络信息数据库的结构可能超出树状(也就是图)并且(ii)LDAP不支持对可能在配置新的网络技术时频繁改变的数据库大纲进行查询。
3.3.1 Gloserv
Gloserv[29]是一种服务发现架构,其提供了多种类型的服务,其中包括事件、基于位置的服务、通信和web服务。Gloserv架构与DNS类似,其包含管理服务信息的根名称服务器和权威名称服务器。其可以具有名称服务器的一些高级别的范畴,例如事件、服务、人员或地点。Gloserv架构提供了成套的服务,诸如用于声明某服务的注册能力、用本地用户代理从服务器查询某个服务集的能力。Gloserv使用RDF模式来定义服务的集合,并且使用Sesame来建立和存储RDF记录。Sesame可以使用HTTP、Java RMI或SOAP作为其查询机制的一部分。
基于AIS的信息发现机制另一方面被用于发现临近网络中的具有特定类型的性质的网络元素,例如(QoS、接入点、路由器、SIP服务器、PANA鉴定代理),而不像Gloserv提供的基于位置的服务例如最近的饭店、最近的某种特定类型的事件例如音乐会等。Gloserv服务架构所提供的信息不足以提供足够的信息从而提供快速切换。基于AIS的服务发现模式使用RDF作为数据库结构,但使用SOAP、HTTP、XML、WSDL、JENA作为伴随的协议从而为移动设备的搜索、报告代理和信息查询进行的数据库填充提供合适的传输机制。因此,基于AIS的服务发现模式更适合于,希望通过预先发现邻近网络元素中诸如AP、路由器、SIP服务器、PANA服务器的网络元素来建立安全的预鉴定的移动用户,而另一方面这超出了诸如Gloserv之类的其它发现机制的范畴。
3.3.1现有服务发现机制之间的比较
很多服务发现协议被提出用来实现设备/服务之间的具有少管理和人为干涉的动态协作。为了能够支持即兴的群组,它们应该提供向网络发布其存在、在邻居中发现服务并且访问服务的方法。基本上,Jini、UPnP、Salutation和SLP都实现了这些方面,但是角度不同。直接的比较必须避免,因为它们在上述功能上放置了不同的权重。然而,此处尝试进行了这种比较,因为这将有助于理解它们中的每一个。表1概括了主要服务发现协议的特性。
Jini和UPnP预见了它们的解决方案实现的普遍计算环境,然而Salutation和SLP则主要处理服务发现的问题。请注意Jini提供2PC交易和JavaSpace来帮助开发网络服务[3]。UPnP的SSDP只是UPnP规范的一部分。[19]中介绍了在Jini、UPnP和Salutation之间的很好的比较。
Jini依赖于Java来实现它所有的承诺。它假设设备支持Java虚拟机,即使Jini代理可以用来作为资源少的设备的集群[3]。而且,Jini/RMI不被诸如手机、寻呼机和POS之类的小型信息设备的J2ME CLDC(连接受限设备配置)配置所支持[24]。
Jini的服务代理概念是在其它协议中没有的最强的特性之一。但是这种无需驱动的方案假定具有标准接口的Jini设备已经在网络中可用。这不像听上去那么简单,因为这意味着某种设备类型的所有生产商都必须同意标准接口。首先,打印机和存储设备的接口的标准正在生产商工会的制定当中。
UPnP依赖于现有的IP和Web技术。它在为服务/设备的描述使用XML方面似乎是独一无二的。XML允许对设备功能、发布到设备的控制命令、以及来自它的事件的强大的描述。UPnP引进了采用AutoIP和DHCP的自我配置的新特性,但这些特性在IPv6中也有[19]。
Salutation得到很好的定义,但却限制于服务发现协议和会话管理。因此Salutation没有实现远程事件提醒之类的特性,该特性在分布式环境中显然是有用的。至于传输协议,IP被Jini、UPnP/SSDP和SLP给予了最高的优先级。Salutation能够在诸如IP的任何网络层协议以及包括IR和IEEE 802.11无线LAN的任何物理/链路层技术上运行。这种传输独立性是Salutation最强大的特性。
很可能为整个网络装置超过一个SLP DA,因为单个DA成为单一故障点。这些DA可以分层组织从而提供更好的性能。而且,在它们的组织/体系的覆盖范围中可以有一定的重叠从而提供可靠性。这种为了性能和可靠性的DA之间的交互或协作正在由SLP协会开发。SLPv2能够通过在SLP消息中包括鉴定信息来确保SLP消息的完整性和真实性。它直接处理安全问题,而其它协议则需要依赖于其它安全协议。
主要服务发现协议与AIS的比较表
相关工作:Jini、SLP、UPnP、Salutation、Gloserv
Jini | UPnP | salutation | SLP | Gloserv | AIS | |
Web页面 | www.sun.com/jini | www.upnp.org | www.salutation.org | www.svrloc.org | 早期阶段,参考Mobiquitous | 尚不可用 |
主要实体 | 查找服务,客户端,服务 | 控制点,设备(服务) | Salutation管理器,传输管理器,客户服务器 | 发现代理,服务代理,用户代理 | 本地用户代理,服务代理 | AIS服务器,移动节点(侦听器-MN) |
服务仓库 | 查找服务 | 无 | 一系列SLM(Salutation管理器) | DA(发现代理) | 注册服务器 | AIS服务器 |
服务公告 | 发现/加入协议 | 公告(ssdp:存活) | 向本地Salutation管理器注册 | 服务注册 | 无 | 无 |
服务发现 | 对查找服务进行查询 | 联系控制点或监听公告 | 对本地SLM以及SLM间的协作进行查询 | 联系DA或向SA进行组播 | 在当前网络中发现网络服务 | 查询AIS服务器(WSDL/SOAP)四种架构1)终端节点辅助。2)报告代理辅助。3)AAA辅助。4)对等。 |
接入服务 | 基于RMI的服务代理对象 | 向服务(SOAP)调用动作,查询变量状态 | 服务会话管理 | 被发现的服务的服务类型(服务协议) | 连接到也可分级的全球服务器 | 如果允许,MN直接访问服务 |
服务描述和范围 | 接口类型和属性匹配 | 以XML描述 | FU(功能单元)及其属性 | 服务类型以及属性匹配(相当强大的匹配) | 使用XML/RDF格式 | 以XML或其变种描述 |
服务注册寿命 | 租借 | 在活动的消息中的缓存控制报头 | 无 | 服务注册中的寿命 | 缓存 | 缓存 |
服务组 | 组 | 无 | 无 | 范围 | 无 | 只被AIS服务器的MN访问的服务 |
事件提醒 | 远程事件 | 当状态变量改变时服务发布事件(GENA) | 可用性检查(周期性的且自动的) | 无 | 有 | 无 |
其他 | 以Java为中心的架构 | 自动配置(AutoIP) | 与传输无关 | 鉴定安全性特性 | 适合发现特定的服务集 | 1)不依赖于像JINI的特定的编程环境。2)采用了SLP和UPnP的服务描述的优点。3)易于配置。4)解决方案可以为单独的ISP定制 |
5AIS的描述
5.2AIS与现有服务发现机制之间的差别概述
Jini、SLP、UPnP和Salutation无法发现网络邻居的信息。Gloserv没有描述用于发现邻近网络中具有某些服务参数的网络元素的方法。
以下特性使我们的解决方案独一无二:
●AIS除发现移动设备当前连接的网络的信息之外还为发现邻近网络的信息提供了支持。
●AIS容易确定收集什么信息以及如何提供它。(现有服务发现协议关注于如何检索数据库中已经存在的信息。)
●不依靠本地网络供应商来实现服务信息服务器,这种服务器在公共网络中配置的时候可能成为一种障碍。
●AIS与第2层无关(独立于CDMA、IEEE 802.11、GPRS等等)
●AIS既包括网络辅助也包括移动设备辅助的发现机制。
●AIS包括用于建立网络信息数据库的网络辅助和移动设备辅助的机制。
5.3 AIS架构
信息构建流程、信息检索的方法、信息在信息服务器上存储的格式是设计发现架构的时候需要察看的关键设计要素。
我们为AIS设计了多种架构。它们可以大体上分为两大类:网络辅助和移动设备辅助。以下章节我们将对这些架构以及不同的功能元素如何能够彼此交互进行描述。在这些架构可选项的每一个当中,移动设备将查询AIS服务器或对端移动设备来找出关于邻近网络中的网络元素的信息。构建信息数据库的方法在每个不同的架构中都不同。网络辅助机构既可以遵循分布式模型也可以遵循集中式模型。AIS服务器保存关于邻近网络中的网络元素的信息,并且将在接收到来自移动设备的查询之后提供该信息。在集中式模型中,每个网络中的报告代理将使用SNMP MIB(简单网络管理协议管理信息库)来报告关于网络中的网络元素的信息。移动设备辅助模型本质上永远是分布式的,其终端节点报告关于它们正在访问的网络的信息。移动设备从AIS服务器检索信息的方式对于两种方法都是共同的。
基于对等的模型是另一种移动设备辅助模型,其中移动设备担当信息服务器的角色并且向其他移动设备提供信息。
3.3基于信息服务器的架构
3.3.1发现数据库的构建
基于信息服务器的架构可以是移动设备辅助的或网络辅助的。在以下章节中我们将描述用于构建网络信息数据库的终端节点辅助和网络辅助方法。
3.3.1.1移动辅助的方法
我们为收集、维护和发现本地服务和网络功能提出了新的范例。新的范例将克服在背景技术章节中描述的现有方法的限制。所提出的方法使用了以下主要原理:
●每个移动用户可以使用任何对他/她可用的合适的方法来发现被访问的网络中可用的网络信息。单独为了发现随后的移动设备可能需要的关于被访问网络的信息的目的,用户常常不需要任何来自被访问的网络的特别辅助。例如,当移动设备连接到被访问网络的时候,作为连接到被访问网络的正常过程的一部分,它将了解被访问的网络中的接入路由器和鉴定代理的地址。这些信息可被报告给移动设备的AIS服务器,然后又将在移动设备进入被访问网络之前,将该信息提供给随后的移动设备,这样随后的移动设备可以检索该信息。对可用的热点网络的发现及其登录要求,同样不需要本地网络供应商提供任何特殊辅助。
●每个移动设备用户将他在被访问网络中发现的信息报告给他的AIS服务器。移动设备的AIS服务器不必与移动设备当前正在访问的网络有任何信任关系。
●移动设备用户的AIS服务器负责维护从其用户接收的关于不同网络的相关网络信息。
●当随后的移动设备进入被访问网络时,它将向它的AIS服务器查询它需要的本地信息。
所提出的方法与现有方法相比具有以下主要优点:
●信息挖掘和发现将不依赖于本地网络提供商提供用于提供网络信息的信息服务器。
●无论移动设备用户在何处和它当前使用哪个本地网络,移动设备始终使用单一协议与其AIS服务器通信从而检索网络信息。
●AIS服务器只需要维护它自己的用户感兴趣的信息。更进一步,AIS服务器只需要维护关于它自己的用户移动到的位置的信息。
这使所提出的范例成为高度可扩展的。
所提出的协作式发现范例的基本操作如图4所示。该图示出了移动设备如何在网络间移动并能够将关于网络元素的信息更新到通常被一系列网络共享的位置服务器。该信息用特殊的格式存储在位置服务器中。关于图4,该图示出了本地服务和网络功能的协作式发现的示意图。
3.3.1.2网络辅助的信息发现
网络辅助的信息发现定义了三种不同的方法:
它们是:
1.报告代理辅助;
2.AAA辅助;
3.基于DNS的方法。
3.3.1.2.1报告代理辅助
报告代理(RA)是处于每个网络中的网络代理。它们兼容SNMP并且具有通过探测SNMP MIB来收集关于网络元素的信息的能力。这些报告代理(RA)将在各自的域中收集信息并填充针对特定区域的位置服务器数据库。该信息可包括各自网络元素的功能集、IP地址、位置坐标等等。当特定网络元素在域中被连接或变为可运行,其信息将被推送到报告代理(RA),然后又被发送到AIS服务器。因此,与前面所描述的终端系统辅助的方法相比,这种方法提供了填充AIS服务器数据库的半中心化的方式。在此安全性考虑不成为一个问题,因为数据库更新是由特定网络代理提供的,而不是由终端客户端,而且在RA和信息服务器之间有预先建立的安全关联。
关于图5,该图示出了用报告代理(RA)报告的信息来填充数据库的示例。
3.3.1.3 AAA服务器辅助
AAA服务器辅助的信息建立是另一种网络服务器辅助方法。移动设备的信息资料也可以被保存在AAA服务器中。诸如RADIUS和Diameter之类的任何AAA协议都可以用于以AAA客户端向AAA服务器发送一对移动设备地址和AAA客户端地址的方式,来填充网络发现数据库。这对地址在RADIUS和Diameter协议的Calling-Station-ID和Called-Station-ID属性中携带。AAA服务器可以收集从AAA客户端报告的信息并且通过为移动设备记录其(AAA客户端地址、移动设备与AAA客户端关联的时间、移动设备与AAA客户端取消关联的时间)元组的列表,而了解移动设备的移动模式。然后该列表用于构建移动设备在其中能够进行切换的邻近网络的数据库。
值得注意的是,这种方法可能不能应用于服务提供者可能不想向其他竞争的服务提供者公开其拓扑数据库的多供应商的情况。
3.3.1.4基于DNS服务器的方法
用户也可以使用DNS SRV记录取代使用AIS服务器,来找出这些网络元素的列表。DNS始终可以使用DNS的LOC记录来填充与网络元素(路由器、AP)相关联的服务以及它们相关联的位置坐标。因此,用户可以查询DNS服务器,给出特定域和位置坐标范围的服务的列表,并且得到提供这些服务的网络元素的列表。通常的查询看上去像这样。给定一组位置坐标(R1-R2),找出提供诸如路由、802.11和AAA的特定服务集的一组服务器。DNS“SRV”记录和地理位置记录的联合将有助于在附近确定一组服务器。
注意,本方法不是规定形成随意组织的网络信息数据库。
3.3.2对发现数据库进行查询
可能在移动设备在域、域内的子网之间移动过程中请求诸如安全预鉴定、主动式IP地址获取的多种操作。这些通常在移动设备移动到子网之后才完成的操作如果在该时间之前完成,将有助于提供快速切换。为了在处于先前的域/子网中的时候进行这些操作,将需要在移动结束之前与下一跳的路由器和服务器进行通信。因此移动设备将需要在移动到邻近网络之前发现邻居的信息,该信息包括AP、路由器、DHCP服务器以及诸如PANA鉴定代理和某些情况下SIP服务器的多个鉴定代理。该信息依靠网络发现将帮助移动设备预先进行多种操作,例如预鉴定和主动式IP地址分配。以下描述了这样一种帮助移动设备发现邻近网络元素的机制。DNS“SRV”机制提供了另一种提供邻近域中这些网络元素的列表的方法。
最初,移动设备启动,获取IP地址并且用诸如默认网关以及多种服务器参数等网络参数来配置自己,它开始与相应的主机进行通信并且在其基于某种策略的通信过程中的某个点,它确定移动设备即将移动。因此移动设备用多种不同的方式发起AIS流程。它可以始终使用其位置信息作为进行查询时的查找密钥。位置信息可以是接入点的MAC地址、地理地址或任何其他的公民地址。当用接入点的MAC地址作为查找密钥的时候,移动设备可以(i)如果移动设备在接入点的无线电覆盖范围内,通过监听信标帧或(ii)循环执行查询步骤,其中循环开始于移动设备基于方法(i)已知的指定的接入点MAC地址,来获得MAC地址。
服务器接收到查询并且基于查询类型回复报告所询问的属性的列表。如果客户端配备了GPS,它可以始终得到其自身的位置并且确定它计划向何处移动,并因此提供范围作为所查找信息的一部分,并获取所需的网络信息。
关于图6,该图示出了网络发现、查询和响应的操作的协议交换和次序。
图7和8示出了客户端事先发现邻近的服务器/路由器,因而它能够获得移动设备具有移动可能性的邻近的服务器和路由器的地址的情形。移动设备的位置坐标范围和接入点的MAC地址在图7和图8中分别被用作查询的查找密钥。网络发现过程将帮助事先发现邻近的服务器、路由器和接入点。通过事先发现服务器,能够进行预鉴定从而加速了移动过程中的切换时间。移动设备当前连接到接入点AP0并且有三个有可能移入的邻近网络D1、D2和D3。因此移动设备可以用特定的密钥查询AIS服务器并且获得关于D1、D2和D3域中的邻近的AP、服务器和路由器的信息,它可以与这些进行通信从而为安全的切换做准备。以下段落说明了移动设备启动之后的操作顺序:
1)移动设备启动并且连接到特定的接入点。它通过例如DHCP或PPP的IP地址配置步骤获得IP地址。DHCP服务器或PPP服务器可以拥有IP地址的范围。当位置坐标被用作查找密钥的时候,位置坐标范围与那些IP地址进行关联,并且在IP地址配置步骤中与IP地址一起被传递给移动设备。它假设并非每个移动设备都配备GPS。如果移动设备知道自身的位置坐标(R0)并且位置坐标被用为查找密钥,它也可以使用其位置坐标作为查找密钥。特定区域的AIS服务器的IP地址可以通过在IP地址配置步骤中或者通过使用DNS提供。
2)邻近单元属于不同的域的情况也可能发生。从DHCP的配置,移动设备可以找出其当前的域(例如“att.com”或“sprint.com”等等)。它还可以用从获得的网络元素的IP地址反向DNS查询找出邻近区域的域名。
3)移动设备使用其当前连接的AP和接入路由器,向AIS服务器发出请求,如下:
a)请求包含移动设备希望以指定的条件(例如在地理范围[R1-R2]或“1英里之内”)为特定的位置(例如地理位置R0或AP0的MAC地址)检索的网络信息类型(例如,类型=“PANA鉴定服务器”,,“路由器”)的列表。条件可以基于移动设备的速率或移动模式来确定。
b)AIS服务器通过查询自己的已经被单独填充的数据库,返回例如服务器和路由器的IP地址、AP的MAC地址等满足请求中指定的条件的网络信息列表。
c)从这些信息,我拥有了我可能进入的可能的网络列表,并因此进行限定时间的预鉴定和/或主动式IP地址获取。
关于图7,该图示出了基于位置坐标的网络服务发现的示例,而关于图8,该图示出了基于AP的MAC地址的网络服务发现的示例。
对于数据库查询,AIS还可以提供另外的特性。例如,用于为移动设备选择要提供的网络信息的标准,可以是由移动设备或AIS服务器或两个实体共同指定的。当AIS服务器指定该标准的时候,移动设备的资料可以作为标准使用。在这种情况下,AIS可以为定购高级别AIS服务的移动设备提供比定购低级别AIS服务的移动设备更详细的网络信息。
3.3.3对等模型
对等模型不依赖于信息服务器进行信息存储和检索。取而代之的,每个移动终端将作为信息服务器。我们描述了两个基于对等的模型,例如主动式广播和限定范围的组播。
在提出的对等模型中:
●在网络之间移动的每个移动设备,在其本地缓存中将关于刚访问过的网络的信息保存指定期限;
●移动设备的每个邻居将具有关于邻近网络的不同信息。
以下是两种方法:
·限定范围的组播方法
-每个侦测者将它们对于被访问的网络的知识用一定的范围和它们将在缓存中保存它的时间量发布到本地组播地址M上。
-基于网络的接近程度和移动的可能性,移动设备与指定的端点通信以获得网络的细节。
注:在某些示例中,侦测者可能自己提供信息或指向其他拥有信息的侦测者。
·循环广播的方法
-每个移动设备循环地广播从而发现网络中特定网络的信息。
-广播可以跨域超出它本身的子网。
参照图9,该图示出了基于对等的网络发现机制的实例。在此架构中没有信息服务器,并且移动设备可以通过在网络中查询对端来发现其他网络。该机制在移动设备携带大量关于其他网络的信息并且在指定的时间周期内将其保存在缓存中的假设下工作。移动设备在其决定移动到其它网络的时候可以主动的查询此信息,并获得关于其它网络的信息。这在移动设备有能力与其对端通信并且提取该信息的假设下工作。在某些情况中可能有在移动设备和其端点之间建立某种安全关联的需求。
关于图10,该图示出了基于范围的组播系统。另一方面,关于图11,该图示出了循环广播系统。
3.3.4安全的预鉴定的适用性
此处描述的网络发现机制能帮助所有这些不同接入网络之间的切换,包括,例如以下情形:
·802.11和802.3网络之间的切换;
·802.3和802.16网络之间的切换;
·802.11和802.16网络之间的切换;
·802.11和802.11网络之间跨越ESS的切换;
·802.3和蜂窝网络之间的切换;
·802.11和蜂窝网络之间的切换;和/或
·802.16和蜂窝网络之间的切换。
在优选实施例中,发现方法可以适用于异种和同种切换的情形。
·同种系统之间的移动
-单接口(例如802.11,在ESS之间)
-多接口(例如802.11,在ESS之间)
·异种网络系统之间的移动始终是双重模式
-802.3,802.11
-802.11,CDMA/GSM(蜂窝)
-蜂窝网络之间(CDMA,GSM)
-802.11,802.16,802.20
-802.11,电路交换
以下章节讨论特定的情形来说明网络发现如何能被集成从而帮助主动式切换和安全预鉴定机制。图12示出了展示两种状态,也就是邻近网络的发现和无缝切换之间的联系的示意图。特别的,图12示出了网络发现和安全无缝切换的集成。
与预鉴定机制的集成:
关于图13,该图示出了:一个示例集成流程(网络发现+预鉴定)。
当移动设备在网络之间移动时,主动式切换的过程将主要包括两个步骤。第一步包含发现诸如下一跳路由器、DHCP服务器、PANA鉴定代理和AAA服务器之类的移动设备即将移动到的网络中的邻近元素,而第二步包含与邻近网络中的PANA鉴定代理建立基于安全预鉴定的安全关联。在安全与鉴定的过程中,移动设备还可以从下一个子网的DHCP服务器获取一个地址(这不意味着跨多IP跳而运行DHCP)。通过进行安全预鉴定,移动设备在移动到新的子网之后将不需要在建立安全关联中花费时间。通过具有本地可用的下一子网的IP地址,移动设备还消除了为使用标准DHCP流程获得地址而花费的时间,尽管它可以使用DHCPINFORM来获取所有其它的配置参数。通过具有本地可用的IP地址,消除了包括ARP检查在内的DHCP流程所花费的时间。
3.4网络发现过程
数据库可以是集中式、分布式或对等的。我们将对填充此数据库的多种方式进行阐述。此数据库的结构可能是,例如,RDF格式。移动设备将使用SOAP/HTTP机制来从数据库查询提供了特定服务的特定类型的网络元素。举例来说,移动设备可以进行查询从而获得在连接了特定接入点的子网中提供路由服务或PANA服务的网络元素的列表。该特定接入点可以通过其MAC地址来识别。还有其它信息,诸如第2层链路的质量、保护功能、漫游协议等,可以用作索引。在集中式数据库模型中,我们计划使用三种不同的方法,例如基于报告代理、基于AAA和基于终端系统。在基于报告代理的方法中,每个报告代理可以使用SNMP MIB来以特定格式将所需信息填充到集中式数据库中。由于每个域中的AAA客户端能够访问移动设备和AAA服务器,它可以很好地用所需信息来填充数据库服务器。终端系统辅助的方法利用了在移动设备在网络之间移动期间所建立的知识。当移动设备从一个网络移动到另一个时,它收集关于联网元素的信息并向集中式数据库报告。对等模型中没有集中式数据库,但是每个移动设备将它刚访问过的网络元素列表保留一段特定的时间,并且在基于范围的组播中发布它们的功能和知识。某个网络中的移动设备可以查询此功能并且与具有所需信息的特定的邻居进行通信。
安全预鉴定包含在移动设备和下一个子网的PANA服务器之间建立安全关联并且从下一个子网获取IP地址。图13示出了在接入网络转换过程中的多种元素之间的协议交互。移动设备从接入网络A移动到接入网络B。接入网络A和B可以处于两个不同的管理域中。最初,移动设备MN有分配给它的地址IP0。当它即将移动的时候,它被动地听从来自于邻近AP的多个信标。这些AP的信标包含邻近网络中的AP的MAC地址。移动设备使用接入点的MAC地址作为发现邻近接入网络中的网络元素的标识符。这一点是通过使用诸如SOAP和HTTP之类的与AIS服务器交互的应用层协议来确定移动设备移动到邻近接入网络或目标接入网络之后,将要经常与之交互的网络元素的IP地址来实现的。这些网络元素包括邻近网络中的接入路由器、PANA鉴定代理。为了进行安全切换,移动设备向PANA鉴定代理发送PANA消息,该代理通常在邻近网络中与目标接入路由器(TAR)共同定位。此外,发出IKE信令,从而在TAR和移动设备之间建立IPsec隧道。该隧道的建立是为了确保数据被保护并且通过隧道。作为建立隧道的一部分,它从处于目标接入网络的DHCP服务器获取IP地址。DHCP服务器将从它的IP地址池中分配IP地址(称为IP1)。DHCP服务器可能会在将IP地址通过IKEv2交给移动设备之前执行ARP,其中TAR作为移动设备的代理DHCP客户端。通过DHCP传送到TAR的IP地址被配置载荷IKEv2所携带,并最终分配给移动设备作为IPsec隧道内部地址。移动设备这时就有了两个IP地址,也就是,IP0和IP1。移动设备中实现了IPsec隧道作为逻辑隧道接口(即ipsec0),并且移动设备具有两个地址,也就是用于物理接口(即eth0)的IP0和用于逻辑隧道接口的IP1。此时,移动设备向相应的主机(CH)或本地代理发送一条绑定更新。CH或本地代理将新的数据发送到移动设备的新IP地址IP1。来自于CH去往IP1的数据将被TAR捕获并将通过刚建立的IPsec隧道传输。现在,当移动设备跨区并且连接到新的接入点AP2,它将获得一个事件触发打破旧的IPsec隧道并将新地址IP1分配给其物理接口(即eth0)。
由于移动设备获取了只能被本地分配的IP地址,当移动设备移动到新的网络时,它可以执行DHCP INFORM从而能配置诸如DNS服务器、DHCP服务器等的其他服务器参数。作为另一个选项,这些参数可以通过用于在移动设备移动到目标接入网络之前在移动设备和TAR之间建立IPsec隧道的IKEv2信令获取。另一个选项将是通过AIS获取该参数并将其存储在移动设备的缓存中。
因此当移动设备位于之前的子网中并且隧道已经建立时,它有两个分配的地址,比如:
eth0:IP0;
Ipsec0:IP1(隧道接口)
其中IP0是当前网络中的地址,IP1是来自邻近网络的地址。
注:当IPsec隧道没有被作为逻辑隧道接口实现在移动设备中时,IP1将被绑定到IPsec SAD(安全关联数据库)。
在移动设备移动到目标接入网络之后,它将具有一个分配的地址如下:
eth0:IP1。
因此,我们是用本地过程将IP地址IP1配置给接口eth0。
需要考虑的事项:
基于本发明,本领域技术人员实现系统时需要在众多因素中着重考虑的因素:
1、当移动设备移动到目标接入网络时所需的触发机制的类型。
2、当移动设备移动到目标接入网络时如何取消已有的隧道关联。
3、如何跨多IP跳来维护PANA鉴定;
a)修改PANA从而使其跨多IP跳运行;
b)在未受保护的IP隧道上运行PANA;
4、当其即将改变网络的时候移动设备应该何时开始网络发现进程。
5、如何动态的使用DHCP来分配IPsec隧道内部地址(必需对DHCP服务器和IPsec网关之间的详细交互进行定义)。
关于图14,该图示出了与移动设备相关联的不同模块的流程图。图14描述了网络发现和预鉴定流程图。在某些实施例中,网络发现和预鉴定能够被有效的用于具有多个接口的移动设备,以如下的方式:
·移动设备永远只激活多个接口之中的一个。其他接口为了例如节省电池之类的目的而被关闭。取决于信号状态和/或其他的标准,移动设备从某个接口切换到另一个,这需要动态的发现用于移动设备可以从活动接口切换到的被关闭接口的第2层连接点。
·由于关闭的接口不能被用于发现其第2层连接点,用于发现那些连接点的AIS过程通过当前激活的接口来执行。更高层次的网络元素上的与那些连接点相关联的信息也是在AIS过程中被发现的。
·一旦那些连接点以及相关联的更高层次的网络元素被发现,移动设备就可以通过激活的接口为关闭的接口执行预鉴定过程从而在移动设备和第2层连接点之间建立安全关联,并且在激活关闭的接口之前,预配置其所需的配置参数,例如IP地址。
·当关闭的端口被激活,用于激活接口的引导过程将更快,因为大部分所需的引导过程在激活接口之前已经完成。
用于具有多接口的移动设备的网络发现的另外一个用途,描述如下:
·移动设备具有无线LAN接口和蜂窝接口。它总是激活蜂窝接口并且通过蜂窝接口具有IP连接。无线LAN接口可以被一直激活或由移动设备的用户在需要的时候激活。
·当无线LAN接口发现(一个或多个)接入点。它可以通过蜂窝接口执行AIS过程从而获取关于通过接入点连接的网络的详细信息。所获取的信息可以被移动设备用于选择接入点进行连接。
4.模型设计
AIS提供了一种为接入点和路由器使用现有标准而无须在接入点和路由器中作任何改变的框架。我们的数据库模型将使用XML、RDF和SOAP。RDF数据库能够以分布式的方式构建从而可以扩展到大数量的网络。RDF还可以处理任意的互联数据结构,而LDAP只能处理基于树的数据结构。RDF可以提供查询模型以及数据本身。
图15示出了网络发现的不同组件以及各组件之间的交互。特别是,图15示出了数据库引擎的不同组件之间的交互。
参考图17(1)到17(10),RDF示意模型示出了使用XML格式的网络发现。
5.演示情形
在本节中,描述了示例性网络的假设和一种演示情形。以下仅描述了示意性并且非限制性的测试实例。
·网络假设
·建立4个不同的子网(假设4个不同的网络);
·关联4个不同的边缘路由器(ER);
·四个不同的接入点(AP);
·四个不同的PANA服务器(可以与路由器共存);
·定义迁移服务器;
·每个网络元素具有详细的与其相关联的位置坐标。
在迁移服务器上填充数据库:
-在每个网络中有一个SNMP查询代理(RA);
-每个RA查询网络元素并且将这些信息推送到迁移服务器:
-迁移服务器以特定格式维护数据库:
-根据网络;
-服务类型;
-位置坐标范围[r1,h1];
-或者数据库可以被之前访问这些网络的移动设备填充
查询迁移服务器上的数据库:
-移动设备打开电源,从DHCP服务器获取一个地址;
-从DHCP服务器发现其自身的位置(r0,h0);
-将其更新到DNS;
-从DHCP或预定的信息获取迁移服务器地址;
-用特定类型服务进行查询并且提供一个范围;
-获取服务器列表,并且与其即将移动到的每一个服务器进行限时预鉴定;
-从而快速切换将被执行。
关于图16(A)-(C),这些图示范了这个在演示实验室中建立的示意性演示设置。
6.结论
本发明通过实例的方式着重介绍了一些架构以及一种用于网络发现过程的应用层模型。本发明还着重描述了这些技术如何可以在移动设备在异种接入网络之间的移动过程中,帮助提供主动的安全切换。
802.21下的MIH功能:
MIH功能的主要角色是实现切换,并且向如其他标准或实施专利所描述的负责切换决定的网络选择实体或迁移管理实体提供情报。MIH功能在事件服务、命令服务和信息服务的帮助下来辅助网络选择实体。网络选择实体和控制切换的切换策略超出了MIH功能的范畴。对具体切换策略的描述和网络选择实体的细节也超出了802.21标准的范畴。
IEEE802.11规范定义了强化异种接入连接之间的切换的服务。通过在MIH用户进行的切换探测、切换发起以及备选链路选择中提供相关的链路层情报而实现切换过程,而达到这一点。
·媒体独立事件服务(MIES),其提供了与链路特性、链路状态和链路质量的动态改变相应的事件分类、事件过滤以及事件报告。
·媒体独立命令服务(MICS),其使MIH用户可以管理和控制与切换和移动相关的链路行为。
·媒体独立信息服务(MIIS),其提供了关于正在服务的和周围的网络所提供的特性和服务的详细信息。该信息实现了有效的系统访问和有效的切换决定。
·上述服务被媒体独立切换功能(MIHF)支持从而在移动管理和切换过程中帮助MIH用户。MIH功能提供将链路层状态信息从多个异种接入技术聚集成对上层移动管理协议栈的统一的表示形式。
802.21规范草案主要基于以下通用设计原则:
·媒体独立切换(MIH)功能在逻辑上定义为提供移动支持的网络元素和移动节点的移动管理协议栈中的一个薄层。MIH是在做出切换决定的过程中提供帮助的助手和帮助功能。上面的层次基于来自MIH的输入和上下文来做出切换决定和链路选择。实现对于切换应该发生的识别是MIH功能的关键目的之一。而发现关于如何进行有效的切换决定的信息也是一个关键组件。
·MIH功能向更高层次提供抽象的服务。从那个角度,MIH向上层提供了统一的接口。被这个统一接口所实现的原始的服务是独立于不同接入网络的具体技术协议实体的。MIH功能通过特定技术的接口与下层的移动管理协议栈进行通信。MIH与下层的接口的规范通常不在802.21的范畴中。这些接口已经在分别属于诸如IEEE802.1、IEEE 802.3、IEEE 802.11、IEEE 802.16、3GPP和3GPP2之类的接入技术中,作为服务接入点(SAP)而进行了规定。
媒体独立信息服务(MIIS)提供了一种框架以及相应的机制,MIHF(媒体独立切换功能)实体通过它可以发现并且获取在地理区域内存在的网络信息从而帮助切换。MIIS首先提供一组信息元素(IE)、信息结构及其表示,以及查询/响应类型的信息传输机制。这与用于事件服务的信息传输的异步推送模型形成了对照。信息可以存储在MIH功能实体(MIHF)中或在该站中的MIH可以对其进行访问的某种信息服务器中出现。
可以通过更低层次或更高层次使该信息可用。在L2可以通过安全和不安全的端口使该信息可用。模型的结构和定义可以用诸如XML的高级语言进行表示。
信息服务也提供了对诸如邻居报告的静态信息的访问。该信息有助于网络发现。该服务也可以提供对动态信息的访问,而这可以优化与不同网络的链路层连通性。这可以包括诸如通道信息、MAC地址、安全信息等链路层参数。关于网络中可用的高层次服务的信息也可以有助于在移动终端实际连接到任何特定网络之前,做出更有效的切换决定。
媒体独立信息服务指定了一种通过使用诸如XML或ASN.1的标准格式从而跨不同技术表示此信息的通用(或媒体独立)方式。
MIIS提供了从任何单一的L2网络访问关于某一地理区域内的所有异种网络的信息的能力,其依赖于802.21 MIIS服务是如何实施的。MIIS依靠已有的访问媒体特定的传输和安全机制,或者L3传输和L3安全机制来提供对该信息的访问。通常,在由多种媒体类型组成的异种网络中,切换决定模块或更高层次的迁移管理将从不同的媒体类型收集信息,并且聚集成统一的观点从而帮助其作媒体间的切换决定。
诸如蜂窝网络之类的某些网络已经具备了通过广播控制频道来探测某区域附近的临近基站列表的现有方法。其他IEEE小组定义了相似的方法,并且支持客户通过信标或通过MAC管理消息广播来探测某一区域附近的临近接入点列表。媒体独立信息服务(MIIS)提供了统一的框架来帮助跨异种网络环境的更高层次的移动协议(HLMP),从而促进在某一地理区域内的客户端发现和多网络类型选择。在更大的范畴下,宏观目标是帮助更高层次的移动协议获取异种网络的全局视图,从而促进跨越这些网络漫游时的无缝切换。
服务接入点(SAP)定义和访问流程:
参考图18(1)到18(12),这些图示出了一些示范实施例和与服务接入点(SAP)定义和访问流程相关的方面。在这点上,图18(1)到18(12)包括了大量描述以下内容的图:
a)媒体独立切换(MIH)的操作流程(图18(1));
b)具有SAP的MIH功能模型(图18(2));
c)来自于较低层次(较低SAP)的本地触发(图18(3));
d)去往/来自较低层次(较低SAP)的功能基元(图18(4));
e)去往/来自较高层次(较高SAP)的功能基元(图18(5));
f)远程功能基元(去往和来自网络)(图18(6));
g)802.X到802.X(单一I/F)的切换访问流程(图18(7)到18(8));
h)蜂窝/802.Y向/从802.X的切换访问流程(图18(9)到18(10));
i)MIH功能与3GPP基元之间的映射(图18(11));以及
j)MIH功能与802.11基元之间的映射(图18(12))。
本领域普通技术人员将根据本公开而理解和意识到图18(1)到18(12)中描述的本实施例的多种特性和方面、以及多种潜在的更改和改编。另见IEEE 802.21媒体独立切换,DCN:21-04-0170-00-0000,标题:IEEE802.21媒体独立切换解决方案建议,明确提交于2004年11月8日,YogeshBhatt,Ajoy Singh,Nat Natarajan,Madjid Nakhjiri,Alistair Buttar,Lah Hong-Yon,通过以全文引用的方式将其全部内容包括在此。另见IEEE 802.21媒体独立切换,DCN:21-04-0171-01-0000,标题:来自SAMSUNG的对IEEE 802.21的初始建议,明确提交于2004年11月17日,Xiaoyu Liu,Youn-Hee Han,Vivek Gupta,Soo-Hong Park,Sungjin Lee,Hyungkyu Lim,Chihyun Park,Chongwon Kim,通过引用将其全部内容包括在此。
对MIH功能和信息服务的示范性建议:
图19(1)-19(13)是示出了一些示范实施例和与媒体独立切换(MIH)功能和信息服务相关的方面,作为附件A中对上面列出的2005年11月5日所提交的临时申请的阐述。在这点上,以下包括此处的信息。
建议范畴:
·图19(1)-19(13)与根据802.21要求文档的部分建议有关。
·覆盖了两个重要功能:
-MIH功能,以及
-信息服务。
·描述了具体的切换情形。
建议概要:
·引导问题:
-设备何时启动
●可能取决于设备具有多少接口。
·MIH功能:
-通用MIH基元
-用于安全和无缝切换的基元及其与上层的映射
-安全切换解决方案
·信息服务:
-发现、探测和选择:
●设备为了切换优化所需要的信息。
-信息服务模型
假定和情形
·假定:
-用于异种网络的多种射频接口
-用于同种网络的单一或多种接口(11a/b/g)
·本例中提出的情形:
-802.11到蜂窝
-802.11到802.3/WiMAX
-802.11到802.11
单射频接口的情形:
·具有单个IEEE 802.xx接口的移动节点可以在多个子网和多个管理域中漫游。
-基于仅通过L2获得的信息的MIH有局限性。
-MIH可能需要来自更高层次的信息:
●有效的跨子网和跨域切换成为可能。
单射频接口移动的情形:
参考图19(1),描述了一种单射频接口漫游的情形。
多射频接口的情形:
·具有多个接口的移动节点可能想要关闭不用的接口。
·当移动节点移动时,根据无线条件,关闭的接口可能需要被激活。
-关闭的接口自己无法发现他们的接入点/基站。
-仅仅依赖于关闭的接口的信息服务具有局限性。
·MIH可以进一步考虑将关闭的接口作为从当前激活的接口切换的备选者。
-快速接口激活将成为MIH的要求。
多射频接口漫游的情形:
参考图19(2),描述了一种多无线接口漫游的情形。
引导情形、问题和要求:
引导情形:
·设备启动并且接口正在探测网络的存在
·两种不同的情况:
-设备在被访问网络中第一次启动
-设备重启
●之前已经有连接(网络的先验知识)
·多个供应商的存在:
-相似网络(例如,仅有WLAN网络)
-不相似的网络(例如,WLAN、3G)
一些引导问题:
·设备可能具有关于网络的有限的信息,除非访问是经过授权的。
·设备可能不具有被访问网络的任何先验知识。
·多种网络可能在某个特定区域没有覆盖。
·设备可能没有更高层次的信息,除非其已经被缓存或预设置。
·设备可能没有合适的安全参数用以连接到网络。
引导解决方案的要求:
·架构部件应该分别解决引导。
·每个建议的正反面的争论应基于安全要求进行评估。
当前解决方案的实例的功能:
·建议的解决方案的实例没有解决引导问题。
MIH功能:
·网络发现
·安全
·迁移/切换
·服务质量
·电源管理
·其他
通用MIH功能模型:
通用MIH功能模型在图19(3)中示出。
MIH功能模型(信息服务、迁移和安全):
MIH功能模型(信息服务、迁移和安全)在图19(4)中示出。
通用MIH基元:
·网络发现基元:
-网络名称
-IP地址(网络元素、DNS、SIP服务器...、位置)
-网络/链路类型
-带宽
-使用网络的成本
·安全基元:
-安全功能
-安全参数(密钥、SA...)
-访问特权
·QoS基元:
-链路类型
-QoS级别/映射
-带宽
·迁移/切换管理:
-所支持的迁移特性
●协议、速度、实时非实时...
-切换类型
●软切换、硬切换...
·电源管理。
-休眠时间,唤醒时间
-电源预算
MIH操作流程:
MIH操作流程在图19(5)中示出。
MIH功能:一个实例:
·网络发现:
-getNetworkName().
-getIPaddress().
-gettypeofserver().
-getBandwidth().
·安全:
-getkeyinformation().
-getsecurityprotocol().
-getauthenticationserver().
安全和无缝切换解决方案:
·该解决方案基于预鉴定(PA)的概念,并且可以如下定义:
-移动设备辅助的鉴定方法,其在会话和服务切换之前先于鉴定和授权而获取更高层次的信息。
·MIH功能代表用户执行此过程。
MIH预鉴定(MPA):
·MIH预鉴定。
-提供安全和无缝移动优化,其工作于:
●跨子网切换
●跨域切换
●跨技术切换
-多接口的使用
-在更高层次(例如网络)定义一种新的机制
●支持IP地址变化(不像MAC地址保持不变的第
2层(L2)预鉴定)
MPA的功能部件:
1)预鉴定
-用于在移动设备与移动设备可能移入的网络之间建立安全关联。
-L2预鉴定还能够基于已建立的SA来实现。
2)预授权
-用于建立移动设备可能移入的网络的特定上下文。
-在(1)中建立的SA被用于保护授权过程。
3)虚拟软切换(VSH)
-用于通过使用当前网络的上下文来发送/接收基于预授权的上下文的IP包。
预期结果:
描述了根据某些实施例的示范性的预期结果的图在图19(6)中示出。
预鉴定:
图19(7)是示出了某些示范实施例中的预鉴定的示意图。
预授权:
图19(8)是示出了某些示范实施例中的预授权的示意图。
虚拟软切换(VSH):初始化阶段:
图19(9)是示出了某些示范实施例中的虚拟软切换的初始化阶段的示意图。
VSH:建立隧道阶段
图19(10)是示出了某些示范实施例中的虚拟软切换的建立隧道阶段的示意图。
VSH:完成阶段
图19(11)是示出了某些示范实施例中的虚拟软切换的完成阶段的示意图。
信息服务:
信息服务是什么?
·信息服务可以定义为,例如:
-网络发现:
●设备收集关于网络信息的过程
-网络探测:
●设备连接网络并收集信息的过程
-网络选择:
●设备选择合适的网络的过程(例如,从发现和探测中收集到的信息中选择)
信息服务解决方案:
·用于信息服务的应用层机制(AIS)。
-网络发现定义为使用基于XML的技术。
-检索L2和L3拓扑信息的灵活的方式。
用于信息服务的应用层机制(AIS):
·一种帮助提供关于临近网络的联网元素的信息的应用层协议。
·该信息可以包括关于多层次的联网元素的参数,例如:
-接入点的MAC地址、接入路由器的IP地址、安全模型、QoS。
·该信息可以使用位置信息作为查询关键词进行查询:
-位置信息可以是接入点标识符、地理地址、公民地址等等。
·该信息将会增强MIH预鉴定(MPA)。
·提供链路层不可知的解决方案。
·提供在管理域之间移动的能力。
·提供一种为接入点和路由器使用现有标准而不做任何改变的框架。
·提供使用XML、RDF、SOAP的模块化并且灵活的数据库。
-RDF数据库能够以分布式的方式来构建从而扩展到大量网络。
-RDF能够处理任意互连的数据结构而LDAP只能处理基于树的数据结构。
-RDF提供查询方法以及数据本身。
●网络信息可以随网络技术发展频繁的改变其数据结构。
·建立信息服务数据库的两种基本方法:
-网络辅助的数据库构建模型
-移动设备辅助的数据库构建模型。
AIS与L2信息服务的比较:
·初始的网络连接需要在L2的信息服务,因为在开始的时候没有IP连接是可用的。
·在L2的信息服务具有某些限制。
-如果在信标内对信息进行广播,其将消耗大量带宽。
-移动设备需要处于提供信息服务的AP的无线覆盖范围内。
●高速移动的移动设备可能在进入网络的无线覆盖区域之前就需要该信息。
●多接口移动设备可能想要通过活动的接口来发现关闭的接口的AP。
-由于在某些链路-2协议(例如802.3)中缺乏分段,因而很难处理大尺寸数据。
·AIS可以克服这些限制。
AIS帮助下的安全无缝切换:
·具有MPA的安全无缝切换是基于从邻近的联网元素检索信息,例如:
-路由器、SIP服务器、PANA鉴定代理等等
另见图12,其描述了网络发现和安全无缝切换的集成。
信息查询实例:
见图12,其描述了示范性的信息查询实例。
用于AIS的RDF模式(局部视图):
图19(12)示出了该模式的示范性图示。
用于AIS的RDF模式(详细视图):
图19(13)示出了该模式的详细示范图示。
切换情形:
·从802.11到蜂窝网络的切换。
·从802.11到802.11网络的切换。
·从802.11到802.3网络的切换。
信息服务模式介绍:
该模式定义了信息的结构。该模式用于在802.21信息服务中定义每个信息元素的结构以及所支持的不同信息元素之间的关系。802.21信息服务模式需要被每个实现了MIIS的MIH功能支持从而支持灵活和有效的信息查询。802.21信息服务定义了各种信息元素及其结构。各种IE表示关于不同接入网络中可用的网络栈较低层和较高层服务的信息。该模式通过语言来定义并且可以用多种方式来表达。实例包括资源描述框架(RDF),其基于例如XML、802MIB中使用的ASN.1、不同信息元素的变体或简单TLV表示。
MIIS模式可以分为两大类。每个MIH都支持的基本模式和可选的、可由厂商指定的扩展模式。
RDF模式表示法:
本节给出了使用资源描述框架(RDF)的模式的实例。见3GPP TS23.234,“3GPP系统到无线局域网络(WLAN)的交互工作;系统描述”(参考文献[8])。RDF使用SPARQL(见3GPP TS 23.060,“通用分组无线业务;服务描述;第二章”(参考文献[7]))作为查询信息的查询语言。RDF模式和SPARQL都以XML来表示。RDF模式定义了表示集的结构,其任何表示的下层结构都是三元组的集合,由主题、谓词和对象组成。称为RDF/XML的用于RDF的XML语法在GPP TR 43.901“对A/Gb接口的通用访问的可行性研究”(参考文献[9])中做了定义。
举例来说,RDF具有以下优势:
·既支持分层的信息结构也支持部分层的信息结构
·允许灵活的数据查询
·允许分布式的模式定义
·更容易的方式来改变模式定义
如以下所讨论的,为MIIS所定义的RDF模式有两部分:基本模式和扩展模式。基本模式假设不支持更新。MIH实体通常为了易于实现基于模式的查询而预先提供了基本模式。在没有预先提供基本模式的情形中,诸如DNS查询的方法可以用于访问基本模式的位置(FQDN)。
不像基本模式,扩展模式预期可以被周期性更新,例如,当新的链路层技术出现的时候。扩展模式可以从特定URL通过IEEE 802.21信息服务,使用IEEE 802.2 1媒体独立切换服务21-05-xxxx-00-0000-提议草案文本的第8.5.3节中描述的模式查询功能来检索,而不需要预先提供这种扩展模式。扩展模式的URL也可以通过上述8.5.3节中描述的模式URL查询功能来获取。另外,DNS查询可以用于发现扩展模式的位置(FQDN部分)。扩展模式定义为基本模式的扩展并且包括数据结构以及媒体专用的或更高层次信息的关系。在这个意义上,扩展模式是对基本模式的完善。
IEEE 802.21信息服务中对RDF/XML的支持:
1.介绍
本文的本节包含(1)用于IEEE 802.21信息服务的RDF/XML模式定义,(2)为了支持基于RDF/XML的IEEE 802.21信息服务,所需要对参考文献[1]中描述的信息服务基元做出的改变,以及(3)使用基于RDF/XML的IEEE 802.21信息服务的基元的实例用法。
2.用于IEEE 802.21信息服务的RDF/XML模式定义
用于IEEE 802.21信息服务的RDF/XML模式定义有两部分,即,基本模式和扩展模式。每个MIH实体必须预先提供其本模式。基本模式假定不支持更新。剩余的RDF/XML模式是扩展模式。不像基本模式,扩展模式假定能够被更新,例如,当新的链路层技术出现时,并且MIH实体不需要预先提供扩展模式。取而代之的是,扩展模式可以通过使用例如在以下第3部分描述的模式查询功能的信息服务来获取。
图20示出了当前定义的RDF/XML模式的图形表示。
2.1.基本模式
如图21(1)-21(2)所示,基本模式以RDF/XML的格式表示。
2.2.扩展模式
如图21(3)-21(12)所示,扩展模式以RDF/XML的格式表示。
3.支持RDF/XML模式的信息服务基元
[1]中,为IEEE 802.21信息服务定义了两种基元,即MIH_information.request和MIH_information.response如下。
MIH_Information.request
(
InfoQueryFilter,
InfoQueryParameters,
QueryID
)
名称 | 类型 | 有效范围 | 描述 |
InfoQueryFilter | QueryFilterType标志的结合 | N/A | 控制所获取的信息的类型和数量的查询过滤器的集合 |
InfoQueryParameters | N/A | 指示客户可能感兴趣的信息类型的查询过滤器专用参数 | |
QueryId | 整型 | N/A | 帮助将请求与响应进行匹配的唯一的QueryId |
MIH_Information.response
(
InfoQueryFilter,
MIH_REPORT,
QueryID,
Status
)
名称 | 类型 | 有效范围 | 描述 |
InfoQueryFilter | QueryFilterType标志的结合 | N/A | 控制所获取的信息的类型和数量的查询过滤器的集合 |
MIH_REPORT | N/A | 由L3MP或MIH请求的信息所组成的报告 | |
QueryId | 整型 | N/A | 用于将请求与响应进行匹配 |
Status | 成功/失败 | N/A | 表明信息是否成功的获取 |
为了支持基于RDF/XML模式的信息服务,对信息服务基元做了以下更改。
3.1邻居图表查询
定义了一种新的InfoQueryFilter类型“FILTER_INFO_NEIGHBOR_NETWORKS”。当指定了这种InfoQueryFilter类型时,InfoQueryParameters必须是包含SPARQL查询[2]的字符串,其中SPARQL查询假定包含合适的用于获取邻居图表的查询。相应的MIH_information.response的MIH_REPORT必须为包含SPARQL查询结果[3]的字符串。
当FILTER_INFO_NEIGHBOR_NETWORKS被指定为InfoQueryFilter时的查询请求和响应的实例,如下示出:
MIH_Information.request(FILTER_INFO_NEIGHBOR_NETWORKS,
“PREFIX ndext:
<http://www.networkdiscovery.org/2005/04/rdf-extended-schema/>
SELECT?z1
WHERE(?x1 ndext:802.11-neighboring-bssid?z1)
(?x1 ndext:802.11-bssid,“12:34:56:78:9a:bc”)”,123)
MIH_Information.response(FILTER_INFO_NEIGHBOR_NETWORKS
,“<?xml version=“1.0”?>
<sparql xmlns=“http://www.w3.org/2001/sw/DataAccess/rf1/result”>
<head>
<variable name=“802.11-neighboring-bassid”/>
</head>
<results>
<result>
<802.11-neighboring-bssid>aa:bb:cc:dd:ee:ff</802.11-neighboring-
bssid>
</result>
<result>
<802.11-neighboring-bssid>00:11:22:33:44:55</802.11-neighboring-
bssid>
</result>
<result>
<802.11-neighboring-bssid>01:23:45:67:89:ab</802.11-neighboring-
bssid>
</result>
</results>
</sparql>”,
123)
3.2通用RDF/XML数据查询
定义了一种新的InfoQueryFilter类型“FILTER_INFO_DATA”。当此InfoQueryFilter类型被指定时,InfoQueryParameters必须为包含SPARQL查询[2]的字符串,其中SPARQL查询假定包含用于获取期望的RDF/XML数据的合适的查询。相应的MIH_information.response的MIH_REPORT必须为包含SPARQL查询结果[3]的字符串。
当FILTER_INFO_DATA被指定为InfoQueryFilter时的查询请求和响应的实例,如下示出:
MIH_Information.request(FILTER_INFO_DATA,
“PREFIX
ndext:<http://www/networkdiscovery.org/2005/04/rdf-extended-schema/>
SELECT?z
WHERE(?x,ndext:dhcp_server_address,?z)
(?x ndext:router_address,12.34.56.1)”,
123)
MIH_Information.response(FILTER_INFO_DATA
“<?xml version=“1.0”?>
<sparql xmlns=“http://www.w3.org/2001/sw/DataAccess/rf1/result”>
<head>
<variable name=“dhcp_server_address”/>
</head>
<results>
<result>
<dhcp_server_address>12.34.56.78</dhcp_server_address>
</result>
</results>
</sparql>”,
123)
3.3 RDM/XML模式URL查询
定义了一种新的InfoQueryFilter类型“FILTER_INFO_SCHEMA_URL”。当这种InfoQueryFilter类型被指定时,InfoQueryParameters必须为空字符串。相应的MIH_information.response的MIH_REPORT必须为包含扩展模式的URL的字符串。而如何从获取的URL检索扩展模式则留给了实施情况。
当FILTER_INFO_SCHEMA_URL被指定为InfoQueryFilter时的查询请求和响应的实例,如下示出:
MIH_Information.request(FILTER_INFO_SCHEMA_URL,“”,123)
MIH_Information.response(FILTER_INFO_SCHEMA_URL,
“http://www.networkdiscovery.org/2005/04/rdf-extended-schema/”,123)
3.4 RDF/XML模式查询
定义了一种新的InfoQueryFilter类型“FILTER_INFO_SCHEMA”。当此InfoQueryFilter类型被指定时,InfoQueryParameters必须为在问题中包含XML格式的RDF主题,以及可选的指定了在模式图表中搜索深度的整数的字符串。默认的深度值为零(0),其表示在搜索深度中没有限制。当除了RDF主题参数之外指定了深度参数时,逗号(“,”)被用作为两个参数的分隔符。相应的MIH_information.response的MIH_REPORT必须为包含所获取的RDF/XML模式的字符串。
当FILTER_INFO_SCHEMA被指定为InfoQueryFilter时的查询请求和响应的实例,如下示出:
MIH_Information.request(FILTER_INFO_SCHEMA,
“<rdfs:Class
rdf:about=“http://www.networkdiscovery.org/2005/04/rdf-basic-schema/
Network”>,0”,123)
MIH_Information.response(FILTER_INFO_SCHEMA,
“<rdf.:RDF xml:lang=“en”
xmlns:rdf=“http://www.w3.org/1999/02/22-rdf-syntax-ns#”
xmlns:rdfs=“http://www.w3.org/2000/01/rdf-schema#”
xmlns:nd=“http://www.networkdiscovery.org/2005/04/rdf-basic-schema/”
>
<rdfs:Class
rdf:about=“http://www.networkdiscovery.org/2005/04/rdf-basic-schema/Network”>
<rdfs:subClassOf
rdf:resource=“http://www.w3.org/2000/01/rdf-schema#Resource”/>
</rdfs:Class>
<rdfs:Class
rdf:about=“http://www.networkdiscovery.org/2005/04/rdf-basic-schema/
L2info”>
<rdfs:subClassOf
rdf:resource=“http://www.networkdiscovery.org/2005/04/rdf-basic-schem
a/Network”/>
</rdfs:Class>
…
<rdfs:Class
rdf:about=“http://www.networkdiscovery.org/2005/04/rdf-basic-schema/I
Pv4”>
<rdfs:subClassOf
rdf:resource=“http://www.networkdiscovery.org/2005/04/rdf-schema/L3i
nfo”/>
</rdfs:Class>
<rdfs:Class
rdf:about=“http://www.networkdiscovery.org/2005/04/rdf-basic-schema/I
Pv6”>
<rdfs:subClassOf
rdf:resource=“http://www.networkdiscovery.org/2005/04/rdf
-schema/L3info”/>
</rdfs:Class>
</rdf:RDF>”,123)
4.参考文献
以下参考文献通过全文引用而包括在此。
[1]“MEDIA INDEPENDENT HANDOVER”,
21-05-0240-01-0000-Joint_MIH_Proposal_Draft_Text-07(见附件A,以上列出的提交于2005年4月13日的临时专利申请,通过全文引用而包括在此)
[2]“SPARQL Query Language for RDF”,
http://www.w3.org/TR/rdf-sparql-query/.
[3]“SPARQL Variable Binding Results XML Format”,
http://www.w3.org/TR/2004/WD-rdf-sparql-XMLres-20041221/.
用于802.21基本文档的RDF模式更新:
1.介绍
本申请的本小节包含了在21-05-0271-00-0000-One_Proposal_Draft_Text(802.21基准文档)中定义的RDF模式中建议的更改,见以上参考的附件A中的提交于2005年7月11日的临时专利申请。
基本文档中的RDF模式定义了类和属性以及它们之间的关系。然而,在每个属性中都缺少详细的数据类型以及备选值。不定义这个级别的详细信息,有可能造成802.21信息服务所使用的属性被不同的实现形式进行不同的编码。
本申请的本小节特别为802.21基本模式的每一项属性定义了详细的数据类型以及备选值,并且通过使用万维网联盟中与RDF和RDF模式一同定义的OWL(网络实体语言)定义了一种扩展模式。
“为了严格定义RDF模式中的每个信息元素,该模式被网络实体语言(OWL)增强了[14]。
OWL是一种网络实体语言。OWL既使用URI(统一资源标识符)来命名,又使用由RDF(资源描述框架)提供的描述框架,从而将以下功能添加到实体中:
·跨多个系统分布的能力
·可伸缩性
·为了可及性和国际化而与其它Web标准的兼容性
·开放性和可扩展性
OWL构建在RDF和RDF模式之上并且添加了更多的用于描述属性和类的词汇,其中,类之间关系(例如,不相交性)、基数(例如,“刚好一个”)、等价性、属性的更丰富类型、属性特征(例如对称性)、以及枚举类。”
图22示出了802.21 MIIS基本模式的图形表示实例,其中‘网络’‘L2’、‘L3’‘位置’‘IPv4’、‘IPv6’、‘链路类型’、‘PoA’、‘公民地址’、‘位置坐标’表示为类,而所有其他的都是类的属性。线指示属性或类的子类的范围或者域。特别的,‘r’表示属性的范围而‘d’表示属性的域。‘域’定义了特定属性所属于的类而‘范围’定义了特定属性的类型。‘网络’类的独特的实例被分配给每个PoA。
本发明的广泛范围:
虽然在此处描述了本发明的示范实施例,但本发明不限于此处描述的多个优选实施例,而是包括了任意的以及所有的具有相同的元素、修改、删节、合并(例如跨多个实施例的情形)、调整和/或变更的实施例,本领域技术人员应基于本发明而能够理解。权利要求中的限制(例如包括以后添加的要求)应根据权利要求中使用的语言而广泛的解释,而且不限于本说明书或申请进行的过程中所描述的实例,其中实例应被解释为非排他性的。例如,在本文中,术语“优选”为非排他性的并且意味着“优选,但不限于”。在本文以及申请进行的过程中,方法+功能或步骤+功能的限制仅被用于具体的权利要求限制,其中以下的所有情况都出现在该限制中:a)“方法用于”或“步骤用于”被明确的陈述;b)相应的功能被明确的陈述;以及c)结构、材料或支持该结构的行为没有被陈述。在本文以及申请进行的过程中,术语“本发明”或“发明”可以被用作本文中一个或多个方面的参考。术语本发明或发明不应被不恰当的解释为重要程度的鉴定,不应被不恰当的解释为应用于所有的方面或实施例(即,应理解本发明具有很多方面和实施例),并且不应被不恰当的解释为限制了申请或权利要求的范畴。在本文以及申请进行的过程中,术语“实施例”可被用于描述任何的方面、特性、流程或步骤、任何它们的组合、和/或它们的任何部分,等等。在某些实例中,多个实施例可能包括重叠的特性。在本文中,以下缩写术语可以被使用:“e.g.”意思是“例如”以及“NB”意思是“注意”。
Claims (32)
1.一种用于移动设备的网络发现从而使用IP网络中大量接入网络中的至少一个的方法,其包含:当移动设备从任何位置连接到IP网络时,基于一套标准来获取给定位置附近的特定网络信息。
2.如权利要求1所述的方法,其中所述的网络信息包括被移动设备用于接入所述接入网络的信息。
3.如权利要求2所述的方法,其中所述信息包括接入点的网络连接点标识。
4.如权利要求2所述的方法,其中所述信息包括被接入点支持的安全类型。
5.如权利要求2所述的方法,其中所述信息包括第3层类型。
6.如权利要求2所述的方法,其中所述信息包括供应商名称。
7.如权利要求2所述的方法,其中所述信息包括服务器或代理的地址。
8.如权利要求2所述的方法,其中所述信息包括鉴定代理的地址。
9.如权利要求2所述的方法,其中所述信息包括接入路由器的地址。
10.一种由移动设备发现目标网络的网络信息的方法,其包含:
a)动态构建网络信息的至少一个发现数据库,以及
b)使用至少一个发现数据库从而在移动设备连接到目标网络之前提供关于目标网络的网络信息。
11.如权利要求10所述的方法,其进一步包括使用RDF作为数据库结构。
12.如权利要求10所述的方法,其进一步包括将媒体独立信息服务模式划分为基本模式和扩展模式类型,其中基本模式是媒体独立切换要支持的基本元素并且扩展模式是媒体独立切换要支持的可选元素。
13.如权利要求10所述的方法,其中所述方法使用了用于信息服务的应用层机制(AIS)。
14.如权利要求10所述的方法,其中所述方法被用于发现移动设备为了切换和预鉴定而使用的信息。
15.如权利要求10所述的方法,其中所述方法使用了独立于第2层的AIS。
16.如权利要求10所述的方法,其中所述方法使用网络辅助的发现机制。
17.如权利要求10所述的方法,其中所述方法使用移动设备辅助的发现机制。
18.如权利要求10所述的方法,其中所述方法为构建所述数据库使用网络辅助的发现机制。
19.如权利要求10所述的方法,其中所述方法为构建所述数据库使用移动设备辅助的发现机制。
20.如权利要求10所述的方法,其中移动设备查询AIS服务器或对端移动设备从而获取关于目标网络中的网络元素的信息。
21.如权利要求20所述的方法,其进一步包括使用报告代理(RA)以获取信息。
22.如权利要求20所述的方法,其中进一步包括使用AAA服务器以获取信息。
23.如权利要求20所述的方法,其中进一步包括使用DNS服务器以获取信息。
24.如权利要求20所述的方法,其中该方法使用移动设备作为信息服务器的对等模型。
25.如权利要求24所述的方法,其中该方法使用限定范围的组播方法。
26.如权利要求24所述的方法,其中该方法使用循环广播的方法。
27.一种用于媒体独立切换功能实体发现和获取存在于地理区域内的网络信息从而实现切换的方法,其包含:使用一种基于用于信息服务的应用层机制(AIS)的使用RDF作为数据库结构的服务发现模式。
28.如权利要求27所述的方法,其进一步包括使用SOAP、HTTP、XML、WSDL和/或JENA作为附随的协议从而为由监听器、报告代理进行的数据库填充和/或移动设备进行的信息查询提供合适的传输机制。
29.如权利要求27所述的方法,其进一步包括通过预先发现临近元素中的网络元素从而为用户建立安全预鉴定。
30.如权利要求29所述的方法,其进一步包括预先发现一个或多个以下网络元素:AP、路由器、SIP服务器、和/或PANA服务器。
31.一种用于为移动设备的网络发现定义信息元素的结构的方法,其包含:将媒体独立信息服务模式划分为基本模式和扩展模式类型,其中基本模式是媒体独立切换要支持的基本元素并且扩展模式是媒体独立切换要支持的可选元素。
32.如权利要求31所述的方法,其进一步包括提供厂商特定的扩展模式。
Applications Claiming Priority (5)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US62510604P | 2004-11-05 | 2004-11-05 | |
US60/625,106 | 2004-11-05 | ||
US60/593,377 | 2005-01-09 | ||
US60/670,655 | 2005-04-13 | ||
US60/697,589 | 2005-07-11 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN101176293A true CN101176293A (zh) | 2008-05-07 |
Family
ID=39423683
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CNA2005800434029A Pending CN101176293A (zh) | 2004-11-05 | 2005-11-05 | 网络发现机制 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN101176293A (zh) |
Cited By (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101902442A (zh) * | 2009-05-25 | 2010-12-01 | 中国科学院计算机网络信息中心 | 获取ip地理位置信息的方法、系统及位置信息服务器 |
CN102356668A (zh) * | 2009-03-18 | 2012-02-15 | 诺基亚西门子通信公司 | 用于通信网络中的拓扑信息的分发的方法和设备 |
CN102450056A (zh) * | 2009-06-04 | 2012-05-09 | 捷讯研究有限公司 | 在使用radius兼容协议促进向移动终端传送相邻网络信息中使用的方法和装置 |
CN102629937A (zh) * | 2012-03-13 | 2012-08-08 | 广州华多网络科技有限公司 | 一种用于群体通信的全球服务系统 |
CN106465239A (zh) * | 2014-05-07 | 2017-02-22 | Lg电子株式会社 | 在无线通信系统中由nan设备接收信号的方法和装置 |
CN107040580A (zh) * | 2016-02-04 | 2017-08-11 | 佳能株式会社 | 管理服务器系统、系统以及系统的方法 |
CN110278238A (zh) * | 2018-03-14 | 2019-09-24 | 许昌许继软件技术有限公司 | 一种变电站二次设备、监控后台及网络地址的部署方法 |
CN111046636A (zh) * | 2019-12-12 | 2020-04-21 | 深圳前海环融联易信息科技服务有限公司 | 筛选pdf文件信息的方法、装置、计算机设备及存储介质 |
CN111095992A (zh) * | 2017-07-27 | 2020-05-01 | 萨兰达有限公司 | 带信标的无线网络 |
CN111225037A (zh) * | 2019-12-20 | 2020-06-02 | 语联网(武汉)信息技术有限公司 | 术语语料库的分享方法、终端及服务器 |
CN113039752A (zh) * | 2018-11-15 | 2021-06-25 | 华为技术有限公司 | 用于支持基于服务的架构的网络节点和方法 |
CN114079981A (zh) * | 2020-08-06 | 2022-02-22 | 北京佰才邦技术股份有限公司 | 一种网络设备切换方法及网络设备 |
-
2005
- 2005-11-05 CN CNA2005800434029A patent/CN101176293A/zh active Pending
Cited By (20)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102356668B (zh) * | 2009-03-18 | 2014-12-03 | 诺基亚通信公司 | 用于通信网络中的拓扑信息的分发的方法和设备 |
CN102356668A (zh) * | 2009-03-18 | 2012-02-15 | 诺基亚西门子通信公司 | 用于通信网络中的拓扑信息的分发的方法和设备 |
CN101902442A (zh) * | 2009-05-25 | 2010-12-01 | 中国科学院计算机网络信息中心 | 获取ip地理位置信息的方法、系统及位置信息服务器 |
CN101902442B (zh) * | 2009-05-25 | 2014-03-05 | 中国科学院计算机网络信息中心 | 获取ip地理位置信息的方法、系统及位置信息服务器 |
CN102450056A (zh) * | 2009-06-04 | 2012-05-09 | 捷讯研究有限公司 | 在使用radius兼容协议促进向移动终端传送相邻网络信息中使用的方法和装置 |
US9629038B2 (en) | 2009-06-04 | 2017-04-18 | Blackberry Limited | Methods and apparatus for use in facilitating the communication of neighboring network information to a mobile terminal with use of a radius compatible protocol |
CN102629937A (zh) * | 2012-03-13 | 2012-08-08 | 广州华多网络科技有限公司 | 一种用于群体通信的全球服务系统 |
CN102629937B (zh) * | 2012-03-13 | 2014-08-13 | 广州华多网络科技有限公司 | 一种用于群体通信的全球服务系统 |
CN106465239A (zh) * | 2014-05-07 | 2017-02-22 | Lg电子株式会社 | 在无线通信系统中由nan设备接收信号的方法和装置 |
CN107040580A (zh) * | 2016-02-04 | 2017-08-11 | 佳能株式会社 | 管理服务器系统、系统以及系统的方法 |
CN107040580B (zh) * | 2016-02-04 | 2019-10-22 | 佳能株式会社 | 管理服务器系统、升级系统以及升级系统的方法 |
CN111095992A (zh) * | 2017-07-27 | 2020-05-01 | 萨兰达有限公司 | 带信标的无线网络 |
CN111095992B (zh) * | 2017-07-27 | 2023-07-11 | 萨兰达有限公司 | 带信标的无线网络 |
CN110278238A (zh) * | 2018-03-14 | 2019-09-24 | 许昌许继软件技术有限公司 | 一种变电站二次设备、监控后台及网络地址的部署方法 |
CN113039752A (zh) * | 2018-11-15 | 2021-06-25 | 华为技术有限公司 | 用于支持基于服务的架构的网络节点和方法 |
CN111046636A (zh) * | 2019-12-12 | 2020-04-21 | 深圳前海环融联易信息科技服务有限公司 | 筛选pdf文件信息的方法、装置、计算机设备及存储介质 |
CN111046636B (zh) * | 2019-12-12 | 2024-04-12 | 深圳前海环融联易信息科技服务有限公司 | 筛选pdf文件信息的方法、装置、计算机设备及存储介质 |
CN111225037A (zh) * | 2019-12-20 | 2020-06-02 | 语联网(武汉)信息技术有限公司 | 术语语料库的分享方法、终端及服务器 |
CN114079981A (zh) * | 2020-08-06 | 2022-02-22 | 北京佰才邦技术股份有限公司 | 一种网络设备切换方法及网络设备 |
CN114079981B (zh) * | 2020-08-06 | 2024-02-02 | 北京佰才邦技术股份有限公司 | 一种网络设备切换方法及网络设备 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US8929330B2 (en) | Network discovery mechanisms | |
CN101176293A (zh) | 网络发现机制 | |
CN103503487B (zh) | 用于接入隶属于所发现的服务供应商的服务的方法和装置 | |
US20070136412A1 (en) | Integration of xml and tlv for query and/or responses in network discovery for mobile devices | |
US7254405B2 (en) | System and method for providing location information to applications | |
CN100551145C (zh) | 提供用户可编程、个性化的位置感知业务的方法和装置 | |
CN101036353B (zh) | 用于把鉴权、授权和/或计帐消息通过多个中间网络从归属服务网络路由到漫游网络的方法、设备及系统 | |
CN101690317B (zh) | 用于介质无关切换的数据类型编码 | |
CN102025700B (zh) | 面向用户的通信方法和路由注册方法及设备及通信系统 | |
CN106797409A (zh) | 用于在物联网(iot)中的设备位置注册的服务器 | |
KR100901872B1 (ko) | 그리드 서비스를 이용한 이종 노매딕/이동 통신 네트워크간 협업 시스템 및 그 방법 | |
JP5629790B2 (ja) | 通貨問い合わせシステムおよび方法 | |
Dutta et al. | Network discovery mechanisms for fast-handoff | |
Ma et al. | RFID-based mobility for seamless personal communication system in cloud computing | |
Schott et al. | e-SENSE protocol stack architecture for wireless sensor networks | |
EP1269716B1 (en) | Method and apparatus for managing a plurality of mobile nodes in a network | |
Philippopoulos et al. | NOMAD: Integrated Networks for Seamless and Transparent Service Discovery | |
Bayomock Linwa et al. | A geo-located web services architecture for next generation mobile networks | |
Rodríguez-Martínez et al. | Registration and discovery of services in the netTraveler integration system for mobile devices | |
JP2003051842A (ja) | 通信システム管理サーバ | |
Maaß | Open Mobility Platform based on Dynamic Directory Services |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C12 | Rejection of a patent application after its publication | ||
RJ01 | Rejection of invention patent application after publication |
Application publication date: 20080507 |