KR101277016B1 - Network discovery mechanisms - Google Patents

Abstract

In some preferred embodiments, a method for network discovery of a mobile device for using at least one of a plurality of access networks in an IP network is provided based on a set of criteria when the mobile device is connected to the IP network at any location. Acquiring the specified network information in the vicinity of.

Network discovery mechanism, access network, mobile device, IP network

Description

Network Discovery Mechanism {NETWORK DISCOVERY MECHANISMS}

The present application particularly relates to a method for a network discovery mechanism, including, for example, a method for network discovery mechanism for secure and fast handoff. This application discloses the following US patent provisional applications: 1) Application No. 60 / 625,106, filed November 5, 2004 entitled "Network Discovery Mechanism for Secure and Fast Handoff;" 2) Application No. 60 / 593,377 filed Jan. 9, 2005 entitled Network Discovery Mechanisms; 3) Application No. 60 / 670,655, filed April 13, 2005 entitled Network Discovery Mechanisms; And 4) 35 U.S.C. for each of application number 60 / 697,589, filed Jul. 11, 2005 entitled RDF Schema Update for 802.1 Baseline Document. The entire specification of each of the aforementioned four patent provisional applications, which claim priority under 119, to which priority is claimed, is incorporated herein by reference. In addition, US Patent Application No. 10 /, filed Jan. 22, 2004 entitled "Mobile Architecture with Pre-Authentication, Preconfiguration, and / or Virtual Soft Handoff," each of the following pending patent applications of this assignee: The entire specification of 761,243 is incorporated herein by reference for the background.

Network and Internet Protocol

There are many types of computer networks, the Internet being the most popular. The Internet is a worldwide network of computer networks. Today, the Internet is an open and independent network available to millions of users. The Internet connects hosts using a set of communication protocols called TCP / IP (ie, Transmission Control Protocol / Internet Protocol). The Internet has a communications infrastructure known as the Internet backbone. Access to the Internet backbone is primarily controlled by Internet Service Providers (ISPs) who resell access to organizations and individuals.

With regard to IP (Internet Protocol), this is a protocol that can transfer data from one device (eg, telephone, PDA (personal portable terminal), computer, etc.) on a network to another device. Today there are various versions of IP, including for example IPv4, IPv6, etc. Each host device on the network has at least one IP address that is its own unique identifier. IP is a connectionless protocol. Connections between endpoints during communication are not continuous. When a user sends or receives data or messages, the data or messages are divided into components known as packets. All packets are treated as independent data units.

In order to standardize the transfer between points over the Internet or similar networks, an OSI (Open System Interconnect) model has been established. The OSI model divides communication processes between two points in a network into seven stacked layers, each adding its own set of functions. Each device processes the message such that there is a downward flow through each layer at the transmitting end point and an upward flow through the layers at the receiving end point. Programming and / or hardware providing seven functional layers is generally a combination of device operating systems, application software, TCP / IP and / or other transport and network protocols, and other software and hardware.

In general, the upper four layers are used when a message is sent to or from the user, and the lower three layers are used when a message is sent through a device (eg, an IP host device). An IP host is any device on a network that can send and receive IP packets, such as servers, routers, or workstations. Messages destined for any other host are sent to other hosts rather than to higher layers. The layers of the OSI model are listed below. Layer 7 (ie, application layer) is, for example, a layer where communication partners are identified, quality of service is identified, user authentication and privacy are considered, restrictions on data syntax are identified, and the like. Layer 6 (ie, presentation layer) is a layer, for example, converting incoming and outgoing data from one presentation format to another. Layer 5 (ie, session layer) is a layer, for example, establishing, coordinating, and terminating conversations, exchanges, and dialogs between applications. Layer 4 (ie, the transport layer) is a layer, for example, for managing end-to-end control and error checking. Layer 3 (ie, network layer) is a layer, for example, handling routing and transmission. Layer 2 (ie, the data link layer) is a layer that provides, for example, synchronization for the physical level, performs bit stuffing, provides transport protocol knowledge and management, and the like. The Institute of Electrical and Electronics Engineers (IEEE) interfaces the data link layer with the media access control (MAC), which controls data transmission to two lower layers, the physical layer, and the LLC (logic, which interprets commands and performs error recovery). Link control). Layer 1 (ie, the physical layer) is a layer that transmits a bit stream over a network, for example, at the physical level. The IEEE subdivides the physical layer into a PLCP (physical layer convergence procedure) sublayer and a PMD (physical medium dependent) sublayer.

Wireless network

Wireless networks may include various types of mobile devices such as, for example, cellular and wireless telephones, PCs (personal computers), laptop computers, wearable computers, cordless telephones, pagers, headsets, printers, PDAs, and the like. For example, a mobile device may include a digital system for secure and fast wireless transmission of voice and / or data. A typical mobile device comprises the following elements: a transceiver (ie, a transmitter and receiver comprising a transmitter, a receiver, and a single chip transceiver in which other functions are integrated if desired); antenna; A processor; One or more audio transducers (eg, speakers or microphones, such as in devices for audio communication); Electromagnetic data storage (eg, ROM, RAM, digital data storage, etc., such as in a device for which data processing is provided); Memory; Flash memory; Full chip set or integrated circuit; Interfaces (e.g., USB, CODEC, UART, PCM, etc.); And / or the like in part or in whole.

Wireless LANs (WLANs) that allow a mobile device user to connect to a local area network (LAN) through a wireless connection may be used for wireless communication. Wireless communication may include, for example, communication through electromagnetic waves such as light, infrared light, wireless, microwaves. Currently, various WLAN standards exist, such as Bluetooth, IEEE 802.11, and HomeRF.

For example, a Bluetooth product may be used to provide mobile computers, mobile phones, portable handheld devices, links between personal digital assistants (PDAs) and other mobile devices, and access to the Internet. have. Bluetooth is a computing and telecommunications industry specification that details how mobile devices easily interconnect with each other and non-mobile devices use short-range wireless connections. Bluetooth addresses end-user problems arising from the proliferation of various mobile devices needed to enable equipment from different vendors to work together flawlessly by keeping data synchronized and consistent from one device to another. Create a digital radio protocol for Bluetooth devices may be named according to a common naming concept. For example, a Bluetooth device may have a name associated with a Bluetooth device name (BDN) or a unique Bluetooth device address (BDA). Bluetooth devices may also participate in an IP network. When a Bluetooth device functions on an IP network, it may have an IP address and an IP (network) name. Thus, a Bluetooth device configured to participate on an IP network may have a BDN, a BDA, an IP address and an IP name, for example. The term "IP name" denotes a name corresponding to the IP address of the interface.

IEEE Standard IEEE 802.11 specifies technologies for wireless LANs and devices. When using 802.11, wireless networking can be achieved by each single base station supporting multiple devices. In some examples, the devices may come preloaded with wireless hardware, or the user may install separate hardware such as a card that may include an antenna. For example, devices used in 802.11 generally include three notable elements: wireless transceivers, regardless of whether the device is an access point (AP), mobile station (STA), bridge, PCMCIA card or other device. An antenna, and a MAC layer that controls packet flow between points in the network.

In addition, multiple interface devices (MIDs) may be used in some wireless networks. The MID may include two independent network interfaces, such as a Bluetooth interface and an 802.11 interface, so that the MID may interface with Bluetooth devices as well as participate on two separate networks. The MID may have an IP address and a common IP (network) name associated with the IP address.

Wireless network devices include Bluetooth devices, multiple interface devices (MIDs), 802.11x devices (e.g., IEEE 802.11 devices including 802.11a, 802.11b, and 802.11g devices), HomeRF (Home Radio Frequency) devices, Wi-Fi (Wireless fidelity) devices, GPRS (Universal Packet Radio Service) devices, 3G cellular devices, 2.5G cellular devices, GSM (global system for mobile communications) devices, EDGE (reinforcement data for GSM generation) devices, time division multiple access (TDMA) It may include, but is not limited to, a CDMA (Code Division Multiple Access) type device including a type device or CDMA2000. Each network device may have various types of addresses including, but not limited to, IP address, Bluetooth device address, Bluetooth common name, Bluetooth IP address, Bluetooth IP common name, 802.11 IP address, 802.11 IP common name or IEEE MAC address. Can have

Wireless networks may also include methods and protocols found in, for example, mobile IP systems, PCS systems, and other mobile network systems. In the context of mobile IP, this includes the standard communication protocols generated by the Internet Engineering Task Force (IETF). With mobile IP, mobile device users can move between networks while maintaining their once assigned IP address. See Request for Comments (RFC) 3344. NB: RFC is the official document of the Internet Engineering Task Force (IEFT). Mobile IP enhances the Internet Protocol and adds means for sending Internet traffic to mobile devices as they connect outside their home network. Mobile IP assigns each mobile node a home address on its home network, and a care-of-address (CoA) that identifies the current location of the device in the network and its subnets. When the device moves to another network, the device receives a new care of address. A mobile agent on the home network can associate each home address with its care of address. The mobile node may send a binding update to the home agent whenever it changes its care of address, for example using the Internet Control Message Protocol (ICMP).

In basic IP routing (eg, outside a mobile IP), routing mechanisms always allow each network node to have a certain attachment point, for example to the Internet, and the IP address of each node is the network link to which each node is connected. Depends on the assumption that it identifies As used herein, the term "node" includes an access point that may include, for example, a redistribution point or endpoint for data transmission and that may recognize, process and / or transmit communications to other nodes. For example, Internet routers may see, for example, an IP address prefix that identifies the device's network. The routers may then see a set of bits at the network level, for example, identifying a particular subnet. The routers may then see a set of bits, for example, identifying the particular device at the subnet level. In the case of general mobile IP communication, if a user disconnects the mobile device from the Internet, for example, and attempts to reconnect to a new subnet, the device must be reconfigured with a new IP address, an appropriate net mask, and a default router. Otherwise, the routing protocol will not be able to deliver the packet properly.

Preferred embodiments improve the techniques described, for example, in the following references, which are incorporated by reference in their entirety.

The present invention improves these and / or other background techniques and / or problems thereof.

According to some of the preferred embodiments, a pre-handoff mechanism such as security pre-authentication, for example, to reduce delays and transient data loss in real time secure roaming / handoff between the same types or between heterogeneous access networks. This can be used. Pre-authentication includes, for example, performing authentication with the network before the mobile devices move into the network. In order to achieve secure pre-authentication with the target neighbor network, the mobile device still obtains information from the target network such as, for example, an IP address when it is still outside the target network, and then, for example, an authentication agent (e.g., Security associations with PANA authentication agents, etc.). To this end, the mobile device must be able to discover the parameters of the various network elements in the target network in advance and communicate with these network elements to establish a pre-secure association. In particular, this disclosure describes a number of approaches for discovering network elements within target networks before the mobile device moves to the target networks. The disclosure also particularly describes how network discovery can assist in providing fast handoff, for example using secure preauthentication and pre IP address acquisition.

According to some embodiments, a method of network discovery of a mobile device using at least one of a plurality of access networks in an IP network is based on the proximity of a given location based on a set of criteria when the mobile device is connected to the IP network from any location. Acquiring the network information specified in the.

In some examples, the network information includes information that the mobile device uses to access the access networks. In some examples, the information includes a network connection point identifier of the access point. In some examples, the information includes the type of security supported by the access point. In some examples, the information includes layer 3 type. In some examples, the information includes a provider name. In some examples, the information includes the address of the server or agent. In some examples, the information includes the address of the authentication agent. In some examples, the information includes the address of the access router.

According to some embodiments, a method of discovering network information of a target network by a mobile device includes a) dynamically building a discovery database of at least one network information; And b) using the at least one discovery database, providing network information for the target network before the mobile device is connected to the target network.

In some examples, this method utilizes Application-layer mechanisms for Information Services (AIS). In some examples, this method is used to discover information used by the mobile device for handoff and preauthentication. In some examples, this method uses AIS independent of layer two. In some examples, this method uses a network assisted discovery mechanism. In some examples, this method uses a mobile device assisted discovery mechanism. In some examples, this method uses a network support mechanism to build a database. In some examples, this method uses a mobile device support mechanism to build a database. In some examples, the mobile device queries the AIS server or peer mobile device to obtain information about network elements in the target network. In some examples, the method further includes obtaining information using a reporting agent (RA). In some examples, the method further includes obtaining information using the AAA server. In some examples, the method further includes obtaining information using a DNS server. In some examples, this method uses a peer-to-peer model in which mobile devices function as information servers. In some examples, this method uses a scoped multicast approach. In some examples, this method uses an iterative broadcast approach.

The above and / or other aspects, features and / or advantages of various embodiments will be further understood from the following description in conjunction with the accompanying drawings. Various embodiments may include and / or exclude other aspects, features, and / or advantages as appropriate. In addition, various embodiments may combine one or more aspect or feature of other embodiments where appropriate. Descriptions of aspects, features, and / or advantages of specific embodiments should not be construed as limiting other embodiments or claims.

In the accompanying drawings, preferred embodiments of the present invention are illustrative and not restrictive.

1 is a diagram illustrating in particular the architecture of a Jini connection technology.

2 is a diagram of a UPnP protocol stack.

3 is a diagram illustrating a model of a salation manager.

4 is a diagram illustrating joint discovery of local service and network performance.

5 is a diagram illustrating database population using a reporting agent (RA).

6 is a diagram illustrating a protocol flow for network service discovery.

7 is a diagram illustrating an example of geographical coordinate based network service discovery.

8 is a diagram illustrating an example of MAC address based network service discovery of an AP.

9 illustrates peer to peer based network discovery.

10 is a diagram illustrating range based multicast.

11 is a diagram illustrating repetitive broadcast.

12 is a diagram illustrating the integration of network discovery and security seamless handoff.

13 is a diagram illustrating an exemplary integration flow (network discovery + pre-authentication).

14 is a diagram illustrating a network discovery and pre-authentication flow chart.

15 is a diagram illustrating the interaction between different elements of database engines.

16A-16C are diagrams of a demonstration system.

17A-17J are diagrams illustrating an exemplary, non-limiting RDF schema for network discovery using the XML format.

18A-18J illustrate some exemplary embodiments and aspects of service access point (SAP) definition and call flow.

19A-19M illustrate some exemplary embodiments and aspects of MIH functions and information services as described in the Appendix of the first provisional application filed November 5, 2005. FIGS.

20 is a diagram illustrating a graphical representation of a currently defined RDF / XML schema.

21A and 21B are diagrams illustrating a basic schema expressed in RDF / XML format.

21C through 21L illustrate extension schemas expressed in an RDF / XML format.

Figure 22 shows 'network' 'L2', 'L3' 'location' 'IPv4', 'IPv6', 'link-form', 'PoA', 'Civic-address', 'Geo-Coordinates' Is represented as a class, and all others are exemplary graphical representations of the 802.21 MIIS base schema, which are attributes of the class.

Although the present invention may be embodied in many different forms, this specification is considered to provide examples of the principles of the invention, which examples limit the invention to the preferred embodiments described and / or illustrated herein. Numerous exemplary embodiments are described with the understanding that they are not.

3. Preface

In the development of wireless networking based on wireless LAN and cellular technology, and as mobile services become more widespread and people become more mobile, mobile devices meet the application requirements and characteristics of mobile devices in a timely, accurate, and efficient manner. It is even more important to be able to find the right network connection point. We refer to this function as network discovery.

The network discovery problem described herein is formulated as acquiring specified network information in the vicinity of a given location based on a set of criteria when the mobile device is connected to the IP network from any location. here,

The network information can be any information that the mobile device uses to access the network. Such information may be supported, for example, by a network connection point identifier (eg, L2 address and / or geographic address of the access point), MAC type (eg, “IEEE 802.11g”) of the access point, Type of security (eg "WPA" or "PANA and IPsec"), layer 3 type (eg "IPv4 only" or "IPv4 / v6 dual stack"), provider name, or server or agent (eg For example, PANA authentication agent, access router, SIP server and mobile IP home agent).

The location of the mobile device or the location where the mobile device wishes to find information can be identified (expressed) in different ways. For example, this may be identified by geographical location, by the identifier of the network, or by the address of a wireless access point or IP access router in the IP network.

The ability to discover network information can be used to better support mobility and mobile services. For example, to reduce interruption for on-going application sessions during handoff, the mobile device can perform preauthentication with the target network before initiating handoff to the target network. To this end, the mobile device will need information about neighboring networks, such as the address of an authentication server in the target network, before moving into the target network. We refer to the process by which a mobile device discovers information about its neighboring networks as network neighbor discovery.

An important issue in network discovery is the problem of building a discovery database, that is, how to build a database of network information in an automated, dynamic and efficient manner. Solving this problem is that a network provider provides detailed network information about his own network to his subscribers for better service, while the network provider competes with him for any network information about his own network. Not trivial in a multi-provider environment that may not disclose to other network providers. However, no real solution exists to solve this problem.

There are many protocols designed for service discovery (see Chapter 2). However, none of these protocols

Discovery of information about neighboring networks,

Dynamic construction of discovery databases,

Determining what information should be collected and provided to mobile devices

Does not provide support for

Instead, existing service discovery mechanisms focus on how to retrieve information that already exists in the database. They rely on all local network providers to implement service information servers, which are too strict to deploy in public networks.

This disclosure describes a new architecture for supporting network discovery, including a method for solving a discovery database building problem and a method for mobile devices to discover information about neighboring networks. The proposed architecture is referred to as an application layer mechanism (AIS) for information services. AIS is designed to be scalable to fully support the current and future types of network information that mobile devices may require. AIS uses as many existing protocols as possible. Although information about network elements can have many uses, we focus on finding information that mobile devices can use to enable pre-handoff and secure pre-authentication, and the information is secure and proactive. Describe how it can be used to support handoff.

4. Related Work

Today, several service discovery protocols and architectures exist, including SLP, JINI, UPnP, Introduction, and LDAP. However, they usually focus on how a user retrieves service related information, assuming that information can be obtained from a database. The service related information and thus the servers used to host this information can be hierarchized in a manner similar to, for example, the Internet Domain Naming System (DNS). The service related information may be preconfigured or dynamically configured on the server. The information can then be updated automatically by the human manager or by the servers themselves exchanging updates with each other.

As network size and user population grow, preconfiguring information to advertise will not be a scalable solution, regardless of whether service-related information or network information is advertised. Asking servers to automatically fill in and update network information also has a number of problems, including:

The network information that each mobile device wants to know can vary greatly depending on the performance and application of the mobile device. For example, some mobile devices obtain the IP address from the neighbor network before performing the handoff to the neighbor network and perform the pre-authentication with the neighbor network so that they can obtain the address of the DHCP server or the address of the authentication server in the neighbor network. You may want to know Other mobile device users may only want to know available local services. It is difficult for network providers to predict what information a large number of diversified current and future users will need. As a result, it is difficult for the network provider to decide what information to keep in the information server.

Mobile device users will need to rely on local network providers to provide information servers. It is difficult to expect every network provider anywhere in the world to provide such an information server. Moreover, different network providers may choose to provide different sets of information.

None of the many service discovery protocols available today appear to be a clear winner that is flexible enough to handle the diversified and changing services and network information that mobile device users need. As a result, different network providers may use different service discovery protocols. This means that users may have to use different service discovery protocols in different networks, which is a heavy burden for users.

Recently, some efforts have been made to design a discovery protocol, especially used to support network neighbor discovery. A representative example is the Candidate Access Router Discovery (CARD) protocol [28]. A candidate access router is an access router in a neighbor network into which a mobile device can enter. The CARD is designed so that the mobile device can use it to find a candidate access router before the mobile device performs the IP layer handoff to the neighbor network to support seamless IP layer handoff. In the case of a CARD, the mobile device listens for layer 2 identifiers, such as an IEEE 802.11 BSSID transmitted from wireless access points (APs) in neighboring networks before making a decision about IP layer handoff. The mobile device then sends these layer 2 identifiers to an access router in its current network, which maps the layer 2 identifiers to IP addresses of candidate access routers in the neighboring network, and then sends candidate router addresses to the mobile device. do. Supporting network neighbor discovery using a CARD causes the following limitations.

The CARD requires neighboring access routers to communicate with each other dynamically to exchange performance information. This is generally not possible when neighboring networks belong to different network providers.

In order to find target access routers, the mobile device must communicate with its current access router using a CARD. It is difficult to expect that all access networks in the world will implement CARD.

The information a user can find using a CARD depends on what information the local network provider configures his CARD protocol to provide, and can vary greatly from network to network. Moreover, as discussed above, network providers may not be able to easily anticipate the diversified and changing needs of networking software and applications on all mobile devices and may not be able to provide the right information that mobile devices require.

More recently, IEEE 802.11 TGu (Task Group U) has been looking for ways to provide higher layer information as part of layer 2 beacons. In this way, the mobile device can determine other layer 3 information as it passively monitors the beacons from neighboring networks. However, due to the maximum transmission unit size limitation, all layer 3 information may not be accepted as part of the layer 2 beacons. It may also be difficult to support multiple heterogeneous access technologies. Therefore, it is important to have a solution that can handle layer 2 agnostic and multiple heterogeneous accesses. As part of this proposal, we have proposed an application layer network neighbor discovery process for discovering different parameters such as IP addresses, quality of service (QoS) and security parameters of neighboring networks.

4.2 Examining Existing Service Discovery Mechanisms

With the advent of wireless ad hoc networks, specialized information organizations are taking over the technology prospects. These informational instruments are inherently born to support mobility, and therefore cooperation between them, since collaboration is an indispensable feature that complements certain missing parts in a mobile device as compared to conventional fully capable computing devices. For this collaboration, several service discovery protocols (SDPs) have been proposed as part of a coordination architecture that ensures device interaction for the ultimate purpose of simple, flawless and scalable device interoperability. Among the emerging SDPs, Genie, Universal Plug and Play, Introduction and SLP stand out.

3.3.1 Genie Connection Technology

The purpose of the Genie architecture is to unite groups of devices and software elements into a single dynamic distributed system [2]. Genie systems provide mechanisms for building, discovering, communicating, and using services in distributed systems. Examples of services include devices such as printers, displays or disks, software such as applications or utilities, information such as databases and files, and users of the system.

At the heart of the Genie system is a trio of protocols called discovery, connectivity and discovery [2]. One of these protocols, discovery and connection, occurs when the device is plugged in. Discovery occurs when a service is looking for a search service to register with. A connection occurs when a service wants to find and connect to a search service. Searching occurs when a client or user needs to find and call a service described by its interface type (written in the Java programming language) and possibly other attributes. The following steps show what interaction is required between the client, service provider, and discovery service in order to be used by the client in the Genie community [2] [1].

1) The service provider finds the search service by multicasting the request on a local network or remote search service known a priori to him.

2) The service provider registers the service object and its service attributes with the search service. This service object has a Java programming language interface to a service that includes methods that users and applications call with other other technical attributes to execute the service.

3) The client requests a service by Java type and possibly other service attributes. A copy of the service object is moved to the client and used by the client to talk to the service.

4) The client then interacts directly with the service provider through the service object.

Genie connection technology consists of an infrastructure and programming model that solves the basic problem of how devices connect to each other to form an instant community. Based on the Java technology shown in FIG. 1 [1] [2], the Genie technology uses the Java remote method invocation protocol to move code throughout the network. Network services run on top of the Genie software architecture. In this regard, Figure 1 shows the architecture of a genie connection technique.

a. Navigation service

Search services can be viewed as directory services in that services are discovered and resolved through them. In the Genie community, services register their proxy objects with a search service through a discovery and connection process, and clients query the search service to find the service they want. Genie uses three related discovery protocols that are useful in different situations [3] [4]. When an application or service is first activated and a search service is to be found nearby, the multicast request protocol is used. Multicast announcement protocols are used by search services to announce their presence to services that may be of interest to the community. Unicast discovery protocols are used to establish communication with specific discovery services that are known a priori over a wide area network.

However, the Genie search service does much more than a simple naming server. The client views the service as an interface that contains methods that the client invokes to run the service along with any other technical attributes. The search service maps the interfaces viewed by the client to a set of service proxy objects. The client downloads the service proxy, which is actually an RMI stub that can communicate with the server. This proxy object allows clients to use the service without knowing anything about the service. Thus, no device driver scenario is required. Although the service proxy object is a representative scenario of service invocation, i.e. service access via RMI method invocation, the downloaded service object may be the service itself or a smart object capable of interacting with any private communication protocol.

b. Leasing leasing )

In the Genie system, access to services is granted in a lease manner, that is, after a service is requested for a predetermined period of time, the service is granted for a period negotiated between the service user and the provider. These leases must be renewed before their expiry. Otherwise, resources associated with the service are released. For example, the search service grants a lease for service registration, and the service must continue to renew the lease. The device can suddenly fail without leaving the community or having the opportunity to unregister itself. Therefore, it is leasing to keep the Genie system robust and free from maintenance.

c. Remote events and transactions ( transaction )

In addition to basic service discovery / connection and discovery mechanisms, Genie supports remote events and transactions that help programmers write distributed programs in a reliable and scalable manner. Remote events allow objects to be notified when desired changes occur in the system. These events can be triggered by some state change of newly published services or services. For example, a Genie palmtop that has registered his interest in printers may be notified by the search service when the printer becomes available. In addition, Genie supports a two-phase commit (2PC) protocol. Inherently, Genie is used to build distributed systems where reliability and robustness are likely to be compromised by partial failure and recovery. However, Genie 2PC allows flexibility in that it does not instruct it to strictly follow this protocol. Rather, it is up to the application (transaction participant) to implement the necessary actions intended by the application logic.

3.3.1 UPnP ( Universal  Plug and play)

Universal Plug and Play (UPnP) [6] is an architecture for a wide range of peer-to-peer network connections of intelligent devices, wireless devices and PCs of all form factors. This is introduced as an extension to the plug and play peripheral model, but UPnP is more than a simple extension to it. In UPnP, a device can dynamically connect to the network, obtain an IP address, send its capabilities on demand, and learn about the presence and capabilities of other devices. Finally, the device can smoothly and automatically leave the network without leaving behind any unwanted state [6]. Universal Plug and Play uses TCP / IP and Web technologies, including IP, TCP, UDP, HTTP, and XML, to enable seamless, near-network networking in addition to control and data transfer between networked devices in homes and offices.

UPnP uses Simple Service Discovery Protocol (SSDP) [7] for service discovery. This protocol is used to announce the presence of a device to other devices as well as to discover other devices or services. Thus, SSDP is similar to a trio of Genie's protocols: discovery, connection and discovery. SSDP uses HTTP over multicast and unicast UDP, referred to as HTTPMU and HTTPU, respectively.

The connecting device sends an advertisement (ssdp: alive) multicast message to advertise its services to the control points. Control points are potential clients of services built into the device. Unlike Genie, there is no central service registry in UPnP. Another message in SSDP is a discovery (ssdp: discover) multicast message sent when a new control point is added to the network. Any device that listens to this multicast must respond with a unicast response message.

XML is used to describe device features and capabilities. The advertising message described above has a URL pointing to an XML file in the network that describes the performance of the UPnP device. Thus, other devices can search this XML file to examine the features of this device and determine whether it is suitable for their purpose. This XML technology, unlike Genie's simple service attributes, enables the description of complex and powerful device performance.

2 illustrates an example UPnP protocol stack. For communication between devices, UPnP uses the protocol stack shown in FIG. 2 [6]. According to the latest specification [6], UPnP features can be summarized in five steps below.

Discovery: The UPnP discovery protocol is based on SSDP. When a device is added to the network, the device advertises its service to the control points on the network. Similarly, when a control point is added to the network, UPnP allows the control point to search for devices of interest on the network. The basic exchange in both cases is a discovery message that includes a few basic attributes for the device or one of its services, for example its type, an identifier and a pointer to more detailed information.

Description: Even after a control point discovers a device, the control point still knows little about the device. In order for the control point to learn more about the device and its capabilities, or to interact with the device, the control point must retrieve the device's description from the URL provided by the device in the discovery message. The UPnP description for a device is expressed in XML and includes a list of any embedded devices or services, as well as URLs for control, eventing, and presentation.

Control: After the control point retrieves the description of the device, the control point can send the actions to the device's service. To this end, the control point sends an appropriate control message to the control URL for the service. Control messages are also represented in XML using Simple Object Access Protocol (SOAP). Like a function call, in response to a control message, the service returns any action specific value.

Eventing: The UPnP description for a service includes a list of actions the service responds to, and a list of variables that model the state of the service at run time. The service publishes an update when these variables change, and the control point can subscribe to receive this information. The service publishes an update by sending an event message. The event message includes the names of one or more state variables and their current values. These messages are also represented in XML and formatted using the Generic Event Notification Architecture (GENA).

Presentation: If the device has a URL for presentation, the control point can retrieve the page from this URL, load the page into the browser, and, depending on the performance of the page, the user controls the device and / or the device You can authorize to see the status.

Another important feature of UPnP is the automatic configuration of IP addresses that are plugged in. AutoIP [13], introduced for this purpose, allows devices to connect to the network without any explicit management. When the device is connected to the network, the device attempts to obtain an IP address from a DHCP server on the network. However, if no DHCP server exists, the IP address is automatically requested from the reservation range for local network use. Therefore, it is named AutoIP. The device randomly selects an address from the reservation range and then requests the address by making an ARP request to see if someone has already requested the address.

3.3.1 Introduction

Introduction is another important collaborative architecture being developed by the Introduction Consortium to address the problem of service discovery and use between a broad set of instruments and equipment and in a wide range of connectivity and mobility environments. Given other characteristics of the target devices, this is independent of the processor, operating system and communication protocol. Architecture is a standard way for applications, services and devices to describe their performance and advertise it to other applications, services and devices. The architecture also enables applications, services, and devices to search for other applications, services, or devices for specific capabilities, and to request and establish interoperable sessions with them to use their capabilities [8] [9] .

As shown in FIG. 3 [8], the opening architecture consists of two main elements: an opening manager and a transmission manager. Introduction The manager is the core of an architecture similar to Genie's search service. This is defined as a service broker. The service provider registers its capabilities with the introduction manager. When a client requests a service search from his local manager, the search is performed by coordination between the managers. The client can then use the returned service. Introduction The manager examines transport managers that provide reliable communication channels regardless of what the underlying network transport is.

The introduction manager provides a transport independent interface to server and client applications. This interface (SLM-API) includes service registration, service discovery and service access functions.

The communication protocol independence of the opening architecture is achieved by the interface between the opening manager and the transmission manager (SLMTI). A transport manager is an entity that depends on the network transports it supports. The introduction manager may have more than one transport manager when connected to multiple physically different networks. However, the introduction manager sees its subordinate transmissions through the transport independent interface (SLM-TI).

Referring to Fig. 3, this figure shows a model of an introduction manager. The main tasks provided by the Introduction Manager can be summarized as follows.

Service registry: Introduction The administrator has a registry for keeping information about services. The client registers or unregisters itself. All registrations are made to the local introductory manager or the nearest introductory manager connected to the client. This corresponds to Genie's search service.

Service Discovery: The Introduction Manager discovers other Introduction Managers and their registered services. Remote services are found by matching a set of attributes and type (s) specified by the local introduction manager. This communication protocol between the introduction managers is called the introduction manager protocol using Sun's ONC RPC. This unique feature, called performance exchange, is necessary because services are registered with the local introduction manager on the same device by default. The cooperation between these managers conceptually forms the same search service, but is distributed across the network like Genie.

Service Availability: The client application may ask the local Introduction Administrator to periodically check the availability of the services. This check is performed between the local administrator and the corresponding administrator. This is a reduced version of Genie's remote event concept.

Service session management: This session management deals with the invocation aspects of services. The service session is established when the client wants to use the service found through service discovery. The service session operates in one of three different modes: native mode, emulated mode and introductory mode. The opening manager may or may not be involved in the message exchange in the service session, depending on the mode. In native mode, messages are exchanged via native protocols, and the opening manager is not involved in message exchange. In emulated mode, the opening manager protocol is used to transfer messages between clients and services, but the opening manager does not examine the contents. In Introduction mode, the introduction managers not only deliver messages, but also define the message format to be used in the session.

The functional unit is defined as the basic building block of the opening architecture. In other words, configuring a client or service is the least meaningful feature. The set of functional units defines a service record. For example, the fax service may be defined by [Print], [Scan] and [Fax Data Send] functional units. Each functional unit consists of a description attribute record. These service / function unit / attribute records are specified by ISO 8824 ASN.1. Introduction-Lite [10] is also worth mentioning here. Introduction-Lite is a scaled-down version of the introduction architecture aimed at devices with small footprints. The opening consortium expects that the rush-right will have significant availability for small information appliances such as palm-sized and handheld computers (ie, palm and WinCE devices). Introduction-Lite also helps low bandwidth networks such as IR and Bluetooth.

3.3.1 SLP (Service Location Protocol) and others

Service Location Discovery (SLP) [17] is an IETF version of the service discovery protocol, but has a unique background, target area, and features like other service discovery protocols. SLP is an uncentralized, lightweight, scalable and extensible protocol for service discovery within sites [16]. The SLP defines a service URL that defines the service type and address for the service. For example, "service: printer: lpr: // hostname" is the service URL for the line printer service available in the host name. Based on this service URL, the user browses the services available at that site and uses the selected service to satisfy the user's needs. For example, a user (application) uses SLP to find any color printer on the same floor.

There are three agents in the SLP: user agent (UA), service agent (SA), and directory agent (DA). A UA is a software entity that sends a service discovery request on behalf of a user application. An SA is an entity advertising a service on behalf of a service. As a centralized service information repository, the DA caches advertisements from SAs and then responds to requests from UAs. The SA advertises itself by registering with the DA. This registration message includes the URL for the service being advertised, the lifetime for that service, and a set of description attributes for that service. The SA must renew the registration for the DA periodically before expiration. Lifespan is intended to prevent the network from remaining in a transitional state, and similar concepts are found in other service discovery protocols such as Genie and UPnP. The DA caches the registration and sends a confirmation message to the SA. The UA sends a service request message to the DA to request the location of the service. The DA then responds with a service response message containing the URLs of the matching services for the UA request. The UA can now access the service indicated by the returned URL. In SLP, DA is optional. DAs may not exist in small networks. In this case, the service request message of the UA is sent directly to the SA.

SLP supports service browsing and string based lookup for service attributes that enable the UA to select the most appropriate service among the services on the network. The UA may request lookup operators such as AND, OR, comparators (=, <, <=,>,> =) and substring matching. This is more powerful than others. For example, in a genie, service attribute matching can only be done for equivalence.

Finally, SLP is said to be a solution to intranet service discovery needs, but scales well for larger networks. Scalability is supported by various features such as minimal use of multicast messages, range concepts, and multiple DAs.

The Bluetooth protocol stack also includes an SDP [14] for service discovery. Bluetooth SDP is designed specifically for the Bluetooth environment, so it has limited functionality compared to other service discovery protocols. Basically, SDP supports searching by service class, searching by service attribute, and browsing service. Service browsing is used when the client does not have prior knowledge of the services available nearby. The service discovery application profile [5] defines the protocols and procedures used by the service discovery application to find services on other devices. Bluetooth SDP runs on any connection-oriented channel of the L2CAP.

Bluetooth SDP is optimized for Bluetooth devices with limited complexity. Thus, it mainly deals with service discovery issues. It does not provide access to services, mediation of services, service advertisements, as well as service registration. There is no event notification when the service becomes unavailable. Thus, other service discovery protocols can be used to compensate for this lack. For example, an introduction can be used on a Bluetooth SDP. This mapping [11] is deemed appropriate due to the introduction of transport independent architecture.

There are other players in this field, namely zeroconf networking [20], MIT's intentional naming system [21] and Berkeley service discovery service [22]. Each of these with a different purpose takes a different approach than others. As a result, they have certain strong and weak characteristics compared to other protocols.

Recently, efforts have been made to design a discovery protocol that supports network neighbor discovery. A representative example is the Candidate Access Router Discovery (CARD) [26] protocol being standardized by the IETF. Candidate access routers are access routers within a neighboring network to which the mobile device may move. CARD is a protocol that mobile devices can use to discover candidate access routers before performing IP layer handoff to neighboring networks. In the case of a CARD, the mobile device listens for a layer 2 ID from wireless access points (APs) in neighboring networks before making a decision about IP layer handoff. The mobile device then sends these Layer 2 IDs to an access router in its current network using the CARD protocol, which maps these Layer 2 IDs to IP addresses of candidate access routers in neighboring networks, and then the candidates. Send router addresses to the mobile device. CARD has the following limitations.

CARD requires neighboring access routers to exchange network information dynamically using the CARD protocol, which is generally not possible when neighboring networks belong to different network providers. As a result, CARD cannot be used to support mobility between heterogeneous wireless systems, for example between cellular networks belonging to different network providers and wireless hot spot networks.

CARD also requires that all access routers implement the CARD protocol to communicate with mobile device users, which is a difficult proposal.

The information that a mobile device can find through the CARD depends on what information each individual local network provider configures its CARD protocol to provide, which can vary greatly from network to network. The networking performance that each mobile device wants to know can vary greatly depending on the networking performance and application of the mobile device and can change over time. It is difficult for a network provider to predict what information will be required by mobile devices. For example, a mobile device with the ability to perform preauthentication would like to know the address of the authentication server in the neighboring network so that it can perform preauthentication with the neighboring network before requiring handoff to the neighboring network. can do. Other mobile devices may only want to know the address of a SIP server / proxy or DHCP server, for example in a neighboring network.

Lightweight Directory Access Protocol (LDAP) [LDAP] is a general-purpose directory search protocol and allows directory update operations and thus can be used to collect data from mobile devices. However, LDAP is not an adequate solution to the underlying network discovery problem, where (i) LDAP only supports searching of hierarchical databases, while the structure of the network information database can be more than a tree (ie, a graph), and (ii This is because LDAP does not support lookups of database schemas that are likely to change frequently as new networking technologies are deployed.

3.3.1 Globs Gloserv )

Globe [29] is a service discovery architecture that provides several types of services that can include events, location-based services, communications, and web services. The glob architecture is similar to DNS because it includes a root name server and an authentication name server that manages information services. This architecture may have certain high level categories for name servers such as events, services, people or places. The glob architecture provides a set of services, such as the ability to register to announce a service and the ability to query a local user agent for a given set of services from a server. Globe defines service sets using the RDF schema, and uses Sesame to create and store RDF records. Sesame can use HTTP, Java RMI, or SOAP as part of its lookup mechanism.

On the other hand, AIS-based information discovery mechanisms, unlike location-based services such as nearest restaurants, concerts offered by the Globe, and certain types of closest events (QoS, access point, routers, SIP servers, PANA authentication agents and Network elements in neighboring networks having the same certain type of characteristics). The information provided by the globe service architecture will not be sufficient to provide enough information to provide a fast handoff. The AIS-based service discovery scheme uses RDF as the database structure, but uses SOAP, HTTP, XML, WSDL, JENA as companion protocols, scouts, database population by reporting agents, and information by mobile devices. Provide a transport mechanism suitable for inquiry. Thus, the AID-based service discovery scheme is a mobile device that wants to establish security pre-authentication by discovering network elements such as APs, routers, SIP servers, and PANA servers in neighbors in advance that are out of scope by other discovery mechanisms such as globs. It is more suitable for users.

3.3.1 Comparison of Existing Service Discovery Mechanisms

Several service discovery protocols have been proposed to facilitate dynamic collaboration between devices / services with minimal management and human intervention. In order to be able to support an instant community, they must provide a means to announce its presence to the network, a means to discover the service in a neighboring network, and a means to access the service. Basically, Genie, UPnP, Introduction and SLP all deal with this aspect but have different perspectives. Because they give different weights to the function, direct comparisons should be avoided. Nevertheless, we attempt such a comparison here, because this helps to understand each of them. Table 1 summarizes the features of the major service discovery protocols.

Genie and UPnP envision the broadest computing environment possible with their solutions, while introductory and SLP deals primarily with service discovery issues. Note that Genie provides 2PC transactions and Javaspace to help develop network services [3]. UPnP's SSDP is only part of the UPnP specification. Genie, a good comparison between UPnP and the introduction is provided in [19].

Genie depends on Java to make all his promises possible. Although Genie proxies can be used for clusters of poorly resourced devices, they are assumed to support the Java virtual machine [3]. Moreover, Genie / RMI is not supported by the J2ME CLDC (Access Restriction Device Configuration) configuration for small information devices such as cell phones, pagers and POS [24].

Genie's concept of a service proxy is one of the most powerful features not found elsewhere. However, a scenario that is not necessary for these drivers assumes that Genie devices with a standard interface are already available in the network. This is not so simple as it means that the manufacture of all certain device types must fit a standard interface. First, standardization of printer and storage interfaces is underway by manufacturing consortiums.

UPnP relies on existing IP and Web technologies. This seems unique in his use of XML for service / device technology. XML allows for a robust description of device performance, control commands issued to the device, and events from it. UPnP introduces new features for its own configuration using AutoIP and DHCP, but these features are also found in IPv6 [19].

The introduction is well defined, but limited to service discovery protocols and session management. Thus, the introduction does not cover features such as remote event notification that are undoubtedly useful in a distributed environment. With regard to the transport protocol, IP is given the highest priority by Gini, UPnP / SSDP and SLP. The introduction may operate on any network layer protocol, such as IP, and on any physical / link layer technologies, including IP and IEEE 802.11 wireless LANs. This transmission independence is the most powerful feature of the introduction.

More than one SLP DA is likely to be deployed for the corporate network, since one DA becomes a single point of failure. These DAs can be organized in a hierarchical structure to provide better performance. In addition, there may be some overlap in the coverage of their organization / sector to provide reliability. Interaction or collaboration between these DAs for performance and reliability is being studied by the SLP association. SLPv2 can ensure completeness and authenticity of SLP messages by including authentication information in the SLP messages. It deals directly with security issues, but others must rely on different security protocols.

Major service discovery protocols and AIS Comparison table

Related Organizations: Genie, SLP, UPnP, Introduction, Globe

Genie UPnP Introduction SLP Globus AIS Web page www.sun.com/jini www.upnp.org www.saluta tion . org www / svrloc.org Initial state Ref. Mobiquitous Not yet available Main entity Navigation service, client, service Control point, devices (services) Introduction Manager, Transport Manager, Client Servers Discovery Agent, Service Agent, User Agent Local user agent, service agent AIS Server, Mobile Node (Scouts-MN) Service repository Navigation service none A set of SLMs (introduction manager) Discovery Agent (DA) Registry server AIS Server Service Notice Discovery / Connection Protocol Ad (ssdp: alive) Register with Local Introduction Manager Service registration none none Service discovery Query to navigation service Contact the control point, or listen to the advertisement Inquiry to local SLM and cooperation between SLMs Contact DA or multicast to SAs Discovery of network services within the current network Inquiry on the AIS server. (WSDL / SOAP) Four Architectures 1) End Node Support 2) Reporting Agent Support 3) AAA Support 4) Peer-to-Peer Access to services Service Proxy Object Based on RMI Invocation action (SOAP) for the service, query for available status Service Session Management Service type (service protocol) for the found service Access to global servers that may be hierarchical If authorized, the MN directly accesses the service Service technology and scope Interface type and attribute matching Description in XML FU (functional unit) and its properties Service type and attribute matching (very strong matching) Use XML / RDF format Describe in XML or its variants Service registration life Leasing Cache control header in live message none Lifetime within service registration cash cash Service group group none none range none Services accessed only by NM on AIS server Event notification Remote events Service publishes event when state variable changes (GENA) Availability checks (periodic and automatic) none has exist none  Etc Java-centric architecture Auto Configuration (AutoIP) Transmission independent Authentication Security Features Ideal for discovery of a specific set of services 1) not dependent on specific programming environments such as Genie, 2) adopting service technology advantages of SLP and UPnP, 3) easy deployment, 4) solutions can be customized for individual ISPs

5. AIS Technology

5.2 AIS Of differences between the existing and existing service discovery mechanisms

Genie, SLP, UPnP, and Introduction cannot find network neighbor information. Globe does not describe a method for discovering network elements in neighboring networks with certain service parameters.

The following features make our solution unique.

AIS provides support for discovering information about neighboring networks in addition to information about the mobile device's currently connected network.

• AIS is easy to determine what information to collect and how to provide that information (existing service discovery protocols focus on how to retrieve information that already exists in the database).

• No dependence on local network providers to implement service information servers, such dependencies can be a barrier to deployment in public networks.

AIS is layer 2 independent (independent of CDMA, IEEE 802.11, GPRS, etc.).

AIS includes both network support and mobile device support discovery mechanisms.

AIS includes both network support and mobile device support mechanisms for building network information databases.

5.3 AIS  architecture

The information building process, the information retrieval method, and the format of the information stored on the information server are some of the important design factors that must be investigated during the design of the discovery architecture.

We have designed several architectures for AIS. These can be broadly classified into two main categories: network support and mobile device support. In the next chapter, we describe how these architectures and the different functional elements can interact with each other. In each of these architectural alternatives, the mobile device queries the AIS server or peer mobile device to find information about networking elements in neighboring networks. How to build an information database is different in each different architecture. The network support architecture can follow both distributed and centralized models. The AIS server maintains information about network elements in neighboring networks and provides that information after being queried from the mobile device. In the central model, the reporting agent in each network reports information about networking elements in the network using the SNMP MIB (Simple Network Management Protocol Management Information Base). The mobile device support model is virtually always distributed, with end nodes reporting information about the networks they are currently visiting. How mobile devices retrieve information from an AIS server is common to both approaches.

The peer-to-peer based model is another mobile device support model in which mobile devices function as information servers to provide information to other mobile devices.

3.3 Information Server Based Architecture

3.3.1 Building the Discovery Database

The information server based architecture may be a mobile device support or network support architecture. In the next chapter, we describe both an end node support and a network support approach to building a network information database.

3.3.1.1 Mobile Device Support Approach

We propose a new paradigm for collecting, maintaining and discovering local services and networking capabilities. The new paradigm will overcome the limitations of the existing approaches described in the relevant chapter. The proposed approach uses the following main principles.

Each mobile device user can discover the network information available in the visited network using any suitable means available to him. Often, a user will not need any special support from the visited network solely for the purpose of discovering information that subsequent mobile devices may need in relation to the visited network. For example, when a mobile device is connected to the visited network, the mobile device will learn the addresses of access routers and authentication agents in the visited network as part of its normal process for connecting to the visited network. Such information can be reported to the AIS server of the mobile device, and the AIS server can send this information to the subsequent mobile devices before the subsequent mobile devices move to the visited network, allowing the subsequent mobile devices to retrieve the information. The discovery of available hotspot networks and their logon requirements also does not require local network providers to provide any special support.

Each mobile device user reports the information he finds in the visiting network to his AIS server. The AIS server of the mobile device does not need to have any trust relationship with the network the mobile device is currently visiting.

The mobile device user's AIS server is responsible for maintaining information about network information received from its subscribers with respect to different networks.

Subsequent mobile devices can query their AIS server with the local information he needs when moving into the visited network.

The proposed approach has the following major advantages over the existing approach.

Information retrieval and discovery does not rely on local network providers to provide information servers used to provide network information.

Regardless of where the mobile device user is and what local network he is currently using, the mobile device always communicates with its AIS server to retrieve network information using a single protocol.

The AIS server only needs to maintain information of interest to its own subscribers. Moreover, the AIS server only needs to maintain information about the locations where its own subscribers travel. This allows the proposed paradigm to be highly scalable.

The basic operation of the proposed cooperative discovery paradigm is shown in FIG. 4. This figure shows how a mobile device moves between networks and how it can update information about network elements for a location server shared by a set of networks. This information is stored on the location server using a specific format. In connection with FIG. 4, the figure illustrates a diagram illustrating cooperative discovery of local services and network capabilities.

3.3.1.2 Finding network support information

Network support information discovery defines three different or one methods.

These are

1. Reporting Agent (RA) Support

2. AAA support

3. DNS based approach.

3.3.1.2.1 Reporting Agent Support

The reporting agent (RA) is a network agent residing within each network. They are SNMP capable and have the ability to gather information about network elements by examining the SNMP MIB. These reporting agents will collect information from each domain and populate the location server database for that particular area. This information may include the capability set, the IP address, the geographical coordinates of each network element, and the like. When a particular network element is connected or operated in a domain, its information is provided to a reporting agent (RA), which sends it to the AIS server. Thus, this approach provides a semi-central way to populate the AIS server database compared to the end system support approach described above. Security issues are less important here because database updates are provided by specific networking agents, not by end clients, and there is a preset security association between the RA and the information server.

With reference to FIG. 5, this figure shows an example of populating a database using information reported by a reporting agent (RA).

3.3.1.3 AAA  Server support

Building AAA server support information is another network server support approach. The information profile of mobile devices may also be stored in the AAA server. Any AAA protocol, such as RADIUS and Diameter, can be used to populate the network discovery database in such a way that the AAA client sends a pair of mobile device addresses and AAA client addresses to the AAA server. This pair is transmitted in the calling station id and called station id attributes of the RADIUS and Diameter protocols. The AAA server collects the information reported from the AAA client, and records a list of triples for the mobile device (the address of the AAA client, the time the mobile device is connected to the AAA client, and the time the mobile device is disconnected from the AAA client). Can keep track of the movement pattern. This list is then used to build a database of neighboring networks from which mobile devices can perform handoffs.

Note that this approach may not be applicable to a multi-provider case where a service provider may not want to expose his topology database to other competing service providers.

3.3.1.4 DNS  Server-based approach

In addition, instead of using an AIS server, DNS SRV records can be used to find a list of network elements. DNS can always use the LOC record of the DNS to populate services associated with network elements (router, AP) and their associated geographic coordinates. Thus, it is possible to query a DNS server, provide a list of services and geographic coordinates for a particular domain, and obtain a list of network elements that provide these services. A general query may look like this. Given a set of geographic coordinates (R1-R2), one can find a set of servers that provide a specific set of services, such as routing, IEEE 802.11, and AAA. The combination of DNS "SRV" records and geolocation records will help determine the set of nearby servers.

Note that this approach is not intended to form any structured network information database.

3.3.2 Discovery database query

Many operations, such as secure pre-authentication, pre-IP address acquisition, may be required during the movement of mobile devices between domains, subnets within the domain. If done in advance, these actions typically performed after the mobile device has moved to the subnet help to provide a fast handoff. Performing these operations while in the previous domain / subnet requires communication with next-hop routers and servers before the end of the move. Thus, the mobile device needs to find neighbor information including several authentication agents, such as APs, routers, DHCP servers and PANA authentication agents, and in some cases SIP servers, before moving to neighboring networks. This information by network discovery helps the mobile device to perform several types of operations in advance such as pre-authentication and pre-IP address assignment. One such mechanism that helps the mobile device find neighboring network elements is described below. The DNS "SRV" mechanism provides another approach to providing a list of network elements in neighboring domains.

Initially, the mobile device boots up, obtains an IP address, and configures itself with other network parameters, such as a default gateway, various server parameters, and the like. The mobile device initiates communication with the corresponding host and determines that the mobile device is imminent at a given point in its communication based on the given policy. Thus, the mobile device initiates the AIS process in several different ways. A mobile device can always use its location information as a navigation key during a query. The location information can be the MAC address, geographic address or any other city address of the access point. When the access point's MAC address is used as the search key, the mobile device can either (i) listen to the beacon frame if the mobile device is within wireless coverage of the access point, or (ii) be known to the mobile device based on method (i). By specifying the MAC address of the access point, the MAC address can be obtained by iteratively performing an inquiry procedure that starts the repetition.

The server receives the inquiry and reports a list of requested attributes based on the inquiry type. If the client is equipped with GPS, the client can always find its own location and determine where he is going to travel, thus providing range as part of the information search and obtaining desired network information.

Referring to FIG. 6, this diagram shows a protocol exchange and sequence of operations for network discovery, inquiry and response.

7 and 8 illustrate a scenario in which a client may discover a neighboring server / router in advance so that the mobile device can obtain the addresses of neighboring servers and routers with mobility. The range of geographic coordinates of the mobile device and the MAC address of the access point are used as search keys for inquiry in FIGS. 7 and 8, respectively. The network discovery process helps to find neighboring servers, routers and access points in advance. Pre-authentication can be performed by discovering the server in advance, thus making it possible to quickly handoff on the go. The mobile device is currently connected to the access point AP0 and has three neighboring networks D1, D2 and D3 with which the mobile device is likely to move. Thus, the mobile device can query the AIS server using a specific key and provide information about neighboring APs, servers and routers in domains D1, D2 and D3 with which the mobile device can communicate to prepare for secure handoff. It can be acquired. The following paragraphs show the sequence of operations after the mobile device has booted up.

1) The mobile device boots up and is connected to a specific access point. The mobile device obtains an IP address through an IP address configuration procedure, for example via DHCP or PPP.

The DHCP server or PPP server may have a range of IP addresses. When geographic coordinates are used as search keys, a range of geographic coordinates is associated with these IP addresses and is passed to the mobile device along with the IP address in the IP address configuration procedure. It is assumed that each and every mobile device may not be equipped with GPS. If the mobile device knows its own geographic coordinates RO and the geographic coordinates are used as the navigation key, the mobile device can also use its geographic coordinates as the navigation key. The IP address of the AIS server for a particular zone may be provided during the IP address configuration procedure or using DNS.

2) Also, neighboring cells may belong to different domains. From the DHCP configuration, the mobile device can discover its current domain (eg, "att.com" or "sprint.com", etc.). The mobile device can also find the domain names of the neighboring area using reverse DNS lookup from the obtained IP addresses of the network elements.

3) The mobile device can make a request to the AIS server using the AP and access router to which it is currently connected, as shown below.

a. The request allows the mobile device to specify a condition (e.g., within geographic range [R1-R2], or "within 1 mile") to search for a specific location (e.g., geographic location R0 or MAC address of AP0). It contains a list of desired network information types (eg, Type = "PANA Authentication Server", "Router"). The condition may be determined based on the speed or movement pattern of the mobile device.

b. The AIS server returns a list of network information (eg, the IP address of the server and router, the MAC address of the AP) that meets the conditions specified in the request by querying its own individually populated database.

c. From this information, we have a list of possible networks that are more likely to move, thus performing time-bound pre-authentication and / or pre-IP address acquisition.

Referring to FIG. 7, this diagram illustrates an example of geographic coordinate-based network service discovery. Referring to FIG. 8, this diagram illustrates an example of MAC address-based network service discovery of an AP.

There are additional features to the database query that AIS can provide. For example, the criteria used to select network information to provide to the mobile device may be specified by the mobile device or by the AIS server or by both. If the AIS server specifies a criterion, the profile of the mobile device may be used as the criterion. In this case, AIS may provide detailed network information for mobile devices subscribing to higher class AIS services than mobile devices subscribing to low class AIS services.

3.3.3 Peer-to-Peer Model

Peer-to-peer models do not rely on information servers for information storage and retrieval. Instead, each mobile terminal functions as an information server. Two peer-to-peer based models, such as pre-broadcast and range multicast, are described.

In the proposed peer to peer model,

Each mobile device moving between networks keeps information about the networks just visited in its local cache for a certain duration.

Each neighboring mobile device has different information about neighboring networks.

There are two such approaches below.

Range multicast approach

Each scout announces their knowledge of the visiting networks on the local multicast address M, with a certain range and amount of time they would like to keep that knowledge in the cache.

 Based on the proximity and mobility of the network, the mobile device communicates with the designated peer to obtain the details of the network.

Note: In some instances, a scout may provide the information itself or point to another scout with the information.

Iterative Broadcast Approach

Each mobile device broadcasts repeatedly to find information about a particular network within the network.

The broadcast can be extended beyond its own subnet.

9, this diagram illustrates an example of a peer to peer based network discovery mechanism. There is no information server in this architecture, and mobile devices can find information about other networks by querying peers in the network. This is done on the assumption that the mobile device has a lot of information about other networks and keeps it in the cache for a certain period of time. The mobile device may query this information in advance when it decides to move to other networks, to obtain information about the other networks. This is done under the assumption that the mobile device has the ability to communicate with its peers to extract this information. In some cases, it may be necessary to establish some kind of security association between the mobile device and its peers.

Referring to FIG. 10, this diagram illustrates a range based multicast system. Meanwhile, referring to FIG. 11, this diagram shows a repetitive broadcast system.

3.3.4 Applicability to Security Preauthentication

The network discovery mechanism described herein can support all kinds of handovers between different access networks, including, for example, the following scenarios.

Handover between 802.11 and 802.3 networks

Handover between 802.3 and 802.16 networks

Handover between 802.11 and 802.16 networks

Handover between 802.11 and 802.11 networks via ESS

Handover between 802.3 and cellular networks

Handover and / or between 802.11 and cellular networks

Handover between 802.16 and cellular networks

In preferred embodiments, the discovery approach can apply to both heterogeneous and homogeneous handoff scenarios.

Move between homogeneous systems

Single interface (e.g. between 802.11, ESS)

Multiple interfaces (e.g. between 802.11, ESS)

Movement between heterogeneous networking systems is always in duplex mode.

802.3, 802.11

802.11, CDMA / GSM (Cellular)

Between cellular networks (CDMA, GSM)

802.11, 802.16, 802.20

802.11, circuit switched

The next chapter describes specific scenarios that show how network discovery can be integrated to support pre-handoff and secure pre-authentication mechanisms. 12 is a diagram illustrating the link between two states, namely discovery of neighboring networks and handoff without disconnection. In particular, FIG. 12 illustrates the integration of network discovery and security seamless handoff.

Integration with Preauthentication Mechanisms

Referring to FIG. 13, this figure shows an exemplary integration flow (network discovery + pre-certification).

When the mobile device moves between networks, the process of pre-handoff mainly involves two stages. The first stage includes discovering neighboring elements such as next hop routers, DHCP servers, PANA authentication agents, and AAA servers in the network to which the mobile device is going to travel, and the second stage includes security with PANA authentication agents in the neighbor network. Establishing a pre-authentication based security association. During this secure preauthentication, the mobile device may also obtain an address from a DHCP server in the next subnet (this does not mean DHCP execution on multiple IP hops). By performing security preauthentication, the mobile device does not have to spend time establishing a security association after moving to a new subnet. The mobile device can obtain all other configuration parameters using DHCP INFORM, but by having the IP address of the next subnet available locally, the mobile device also eliminates the time it takes to obtain an address using a standard DHCP process. Can be. Having a locally available IP address eliminates the time taken by the DHCP process, including ARP checking.

3.4 Network Discovery Process

This database can be centralized, distributed, or peer to peer. We are formalizing several ways to populate this database. This database structure may be in RDF format, for example. The mobile device will use the SOAP / HTTP mechanism to query the network element of some type that provides a particular service from the database. As one example, the mobile device may query to obtain a list of network elements that provide routing services or PANA services in the subnet to which a particular access point is connected. A particular access point can be identified by its MAC address. There may be other types of information such as roaming agreements that can function like the quality, protection, and index of layer 2 links. In the centralized database model, we have planned to use three different approaches: reporting agent based, AAA based and end system based. In a reporting agent-based approach, each reporting agent may use the SNMP MIB to populate the information required in a centralized database into a specific format. The AAA clients in each domain have access to the mobile device and the AAA server, so it can very well populate the database server with the required information. The end system support approach utilizes knowledge built up during the movement between networks of mobile devices. As a mobile device moves from one network to another, the mobile device collects information about networking elements and reports it to a centralized database. In the peer-to-peer model, there is no central database, but each mobile device maintains a list of network elements he has just recently visited for a certain period of time, and publishes their performance and knowledge in range-based multicast. Mobile devices in a given network can query this capability to communicate with a particular neighbor with the required information.

Security preauthentication involves establishing a security association between the mobile device and the PANA server in the next subnet and obtaining an IP address from the next subnet. 13 illustrates protocol interactions between the various elements during the transition between access networks. The mobile device moves from access network A to access network B. Access networks A and B can be in two different administrative domains. Initially, the mobile device MN has an address IP0 assigned to it. When the MN tries to move, it passively listens to several beacons from neighboring APs. The beacons of these APs have the MAC addresses of the APs in neighboring networks. The mobile device discovers network elements in neighboring access networks using the MAC address of the access point as an identifier. This is accomplished using application layer protocols, such as SOAP and HTTP, which interact with the AIS server to determine the IP addresses of network elements that the mobile device typically interacts with after moving to one of the neighboring access networks or to the target access network. do. These network elements include an access router, a PANA authentication agent, in a neighbor network. To perform secure handoff, the mobile device typically sends a PANA message to a PANA authentication agent located with a target access router (TAR) in the neighboring access network. At this point, IKE signaling occurs to establish an IPsec tunnel between the TAR and the mobile device. This tunnel is established to ensure that the data is tunneled and secure. As part of the tunnel setup, the mobile device obtains an IP address from a DHCP server residing in the target access network. The DHCP server distributes one IP address (ie IP1) from its IP address pool. The DHCP server may want to perform ARP before passing the IP address to the mobile device via IKEv2, where the TAR serves as a proxy DHCP client for the mobile device. This IP address, which is then delivered to the TAR via DHCP, is carried in the configuration payload of IKEv2 and finally assigned to the mobile device as an IPsec tunnel internal address. The mobile device now has two IP addresses, IP0 and IP1. When an IPsec tunnel is implemented as a logical tunnel interface (ie ipsec0) in a mobile device, the mobile device has two addresses: IP0 for the physical interface (ie eth0) and IP1 for the logical tunnel interface. At this time, the mobile device sends a binding update to the corresponding host (CH) or home agent. The CH or home agent sends new data to the new IP address IP1 of the mobile device. New data from the CH destined for IP1 is captured by the TAR and tunneled through the IPsec tunnel just established. Now, when the mobile device traverses and connects to the new access point AP2, the mobile device acquires an event trigger that destroys the old IPsec tunnel and assigns a new address IP1 to its physical interface (ie eth0).

Since the mobile device has acquired only IP addresses that can be assigned locally, when the mobile device moves to a new network, the mobile device can perform a DHCP INFORM in order to be able to configure other server parameters such as DNS server, DHCP server, etc. . As another option, the parameters may have been obtained via IKEv2 signaling to establish an IPsec tunnel between the mobile device and the TAR before the mobile device moves to the target access network. Another option is to get the parameters via AIS and store them in the cache of the mobile device.

Thus, when the mobile device is in the previous subnet and the tunnel is established, the mobile device

eth0: IP0;

IPsec0: IP1 (tunnel interface)

Have two assigned addresses.

If IP0 is an address in the current network, IP1 is an address in the neighbor network.

Note: If the IPsec tunnel is not implemented as a logical tunnel interface on the mobile device, IP1 will be joined to the IPsec Security Association Database (SAD).

After the mobile device moves to the target access network, the mobile device will have an address assignment such as eth0: IP1.

Thus, we use a local process to configure IP address IP1 as interface eth0.

Considerations

Based on this specification, those skilled in the art can implement the system, particularly considering the following.

1. Type of triggering mechanism required when the mobile device moves to the target address network

2. How to Detach an Existing Tunnel When a Mobile Device Moves to a Target Access Network

3. How to Handle PANA Authentication on Multiple IP Hops

a) Modify PANA to run on multiple IP hops.

b) Run PANA on an unprotected IP tunnel.

4. The time to start the network discovery process when the mobile device attempts to change the network

5. How to dynamically assign an IPsec tunnel inside address using DHCP (detailed interaction between DHCP server and IPsec gateway should be defined)

Referring to FIG. 14, this figure shows a flowchart of different modules associated with a mobile device. 14 shows a network discovery and preauthentication flow chart. In some embodiments, network discovery and pre-authentication can be effectively used for mobile devices having multiple interfaces in the following ways.

The mobile device always activates only one of the multiple interfaces. The other interfaces are not active, for example to save power. Depending on radio conditions and / or other criteria, the mobile device switches from one interface to another, which dynamically discovers layer 2 connection points for disabled interfaces that the mobile device can switch from an active interface to. Requires.

Since deactivated interfaces cannot be used to discover their Layer 2 connection points, the AIS procedure for discovering these connection points is performed via the currently active interface. Information about higher layer network elements associated with these connection points is also found in the AIS procedure.

If these connection points and the higher layer network elements associated with them are found, the mobile device shall proceed with the pre-authentication procedure for the disabled interface via the enabled interface to establish a secure association between the mobile device and the Layer 2 connection point. And preconfigure required configuration parameters such as IP address before activating the disabled interface.

When a deactivated interface is activated, the bootstrapping procedure for activating the interface is faster because most of the required bootstrapping procedures have been completed before activating the interface.

Another use of network discovery for a mobile device having multiple interfaces is described as follows.

Mobile device has a wireless LAN interface and a cellular interface. The mobile device always activates the cellular interface and has an IP connection through the cellular interface. The wireless LAN interface can always be activated or at the request of the user of the mobile device.

When the wireless LAN interface discovers the access point (s), the mobile device can perform an AIS procedure via the cellular interface to obtain detailed information about the network connected via the access point (s). The obtained information can be used to select an access point to which the mobile device will connect.

4. Schema Design

AIS provides a framework that uses existing standards for access points and routers without having to make any changes at the routers and access points. Our database schema uses XML, RDF, and SOAP. RDF databases can be built in a distributed fashion to scale to large numbers of networks. RDF can also handle arbitrary interconnected data structures, while LDAP only handles tree-based data structures. RDF can provide the data itself as well as the lookup schema.

15 illustrates the different elements and interactions between the elements of network discovery. In particular, FIG. 15 illustrates the interaction between different elements of database engines.

Referring to FIGS. 17A-17J, an example RDF schema is described for network discovery using the XML format.

5. Demo scenario

In this chapter, exemplary network assumptions and demonstration scenarios are described. The following shows only some illustrative and non-limiting test examples.

Network home

Create four different subnets (assume four different networks).

Associate four different edge routers (ER).

4 different access points (AP)

4 different PANA servers (can coexist with a router)

Define the mobility server.

Each network element has a specific geographic coordinate associated with it.

Mobility On the server  Populate Database :

Each network has an SNMP inquiry agent (RA).

Each RA queries the network elements and pushes this information to the mobility server (S).

The mobility server maintains the database in a specific format.

-Depending on the network

-Service type

-Geographical coordinate range [r1, h1]

Alternatively, the database may be populated by mobile devices previously visited in these networks.

Mobility On the server  Database lookup :

The mobile device is powered on and obtains an address from a DHCP server.

Find its own location (r0, h0) from the DHCP server.

-Update it with DNS

Learn mobility server address prepared from DHCP or in advance.

Inquiry with a given type of service and provide a range.

Obtain a list of servers and perform time constraint pre-authentication with each of the servers when the mobile device is about to move.

Fast handoff is performed properly.

With respect to FIGS. 16A-16C, these figures show an example demo setup implemented in a demo lab.

6. Conclusion

This disclosure provides, for example, some architecture and application layer schemes, particularly for the network discovery process. The present disclosure also describes in particular how these techniques can help provide pre-secure handoff during movement between heterogeneous access networks of a mobile device.

802.21 Bottoms MIH  function :

The main role of the MIH function is to facilitate handoff as described by other standards or proprietary implementations and to provide intelligence to the network selection entity or mobility management entity responsible for handover decisions. The MIH function supports network selection entities with the help of event services, command services, and information services. Network selection entities and handover policies that control handover are outside the scope of the MIH functionality. The description of specific handover policies and the details of the network selection entity are also outside the scope of the 802.21 standard.

The IEEE 802.21 specification defines a service that enhances handover between heterogeneous access links. This is accomplished through facilitating the handover processor by providing link layer intelligence related to handover detection, handover initiation and candidate link selection by the MIH user.

Media Independent Event Service (MIES) that provides event classification, event filtering, and event reporting in response to dynamic changes in link characteristics, link status, and link quality.

Media Independent Command Service (MICS), which enables MIH users to manage and control link behavior related to handover and mobility

• Media Independent Information Service (MIIS) that provides details on the features and services provided by serving and surrounding networks. The information enables effective system access and effective handover decisions.

The services are supported by the Media Independent Handover Function (MIHF) to assist the MIH user in the mobility management and handover process. The MIH function provides convergence of link layer state information from multiple heterogeneous access technologies into a unified presentation of the higher layers of the mobility-management protocol stack.

The 802.21 draft specification is based in particular on the following general design principles.

Medium Independent Handover (MIH) functionality is logically defined as a shim layer in the mobility-management protocol stack of both mobile nodes and network elements that provide mobility support. MIH is a support and assistance function that assists in handover decisions. Upper layers make handover decisions and link selection based on input and context from the MIH. Facilitating the recognition that handover should occur is one of the important goals of the MIH function. Finding information about how to make effective handover decisions is also an important factor.

MIH functionality provides abstracted services to higher layers. At that point, the MIH provides a unified interface to the higher layers. The service primitives exposed by this integration interface are independent of the technology specific protocol entities of different access networks. The MIH function communicates with lower layers of the mobility-management protocol stack via technology specific interfaces. The specification of MIH interfaces with lower layers is generally not in the range of 802.21. These interfaces are already designated as service access points (SAPs) within standards associated with individual access technologies such as IEEE 802.1, IEEE 802.3, IEEE 802.11, IEEE 802.16, 3GPP, and 3GPP2.

Media Independent Information Service (MIIS) provides a framework and corresponding mechanisms by which MIHF (Media Independent Handover Function) entities can discover and obtain network information present in the geographic area to facilitate handover. MIIS provides a set of information elements (IEs), information structures and mechanisms for representation and inquiry / response types thereof for information delivery. This is in contrast to the asynchronous push model of information delivery for event services. The information may be stored in a MIH function (MIHF) entity, or may be present in any information server to which the MIH in a communication station can access the information.

Information can be made available through both lower and upper layers. Information can be made available at L2 through both secure and non-secure ports. The structure and definition of the schema can be expressed in a high level language such as XML.

Information services also provide access to static information, such as neighbor reports. This information helps with network discovery. The service can also provide access to dynamic information that can optimize link layer connectivity with different networks. This may include link layer parameters such as channel information, MAC address, security information, and the like. Information about the available higher layer services in the network may also help the mobile terminal to make more efficient handover decisions before actually connecting to any particular network.

The media independent information service specifies a generic (or media independent) way of expressing this information among different technologies using a standardized format such as XML or ASN.1.

MIIS provides the ability to access this information for all heterogeneous networks in the geographic area from any single L2 network, depending on how the 802.11 MIIS service is implemented. MIIS relies on existing access media specific transport and security mechanisms or L3 transport and L3 security mechanisms to provide access to information. In general, in heterogeneous networks composed of multiple media types, a handover decision module or higher layer mobility management collects information from different media types and aggregates aggregate views to facilitate inter-media handover decisions.

Some networks, such as cellular networks, already have an existing means of detecting a list of neighboring base stations within a region through a broadcast control channel. Other IEEE groups define similar means and support clients detecting a list of neighboring access points in the vicinity of an area via beaconing, or via broadcast of MAC management messages. Media Independent Information Service (MIIS) provides a unified framework for assisting higher layer mobility protocol (HLMP) in heterogeneous network environments to facilitate the discovery and selection of clients of multiple types of networks residing within the geographic area. In a larger scope, a larger goal is to help the upper layer mobility protocol to obtain a global view of heterogeneous networks, facilitating seamless handover when roaming between these networks.

Service access point ( SAP Definition and call flow

Referring to FIGS. 18A-18L, these diagrams illustrate some exemplary embodiments and aspects related to service access point (SAP) definition and call flow. In this regard, Figures 18A-18L include a plurality of figures showing the following.

a) Medium Independent Handover (MIH) Operation Flow (FIG. 18A)

b) MIH functional model with SAP (FIG. 18B)

c) local triggers from the lower layer (lower SAP) (FIG. 18C)

d) Function primitives to / from the lower layer (sub SAP) (FIG. 18D)

e) Function primitives to / from the upper tier (higher SAP) (FIG. 18E)

f) remote function primitive (to / from network) (FIG. 18f)

g) Handover call flow from 802.X to 802.X (single I / F) (FIGS. 18G and 18H)

h) 802.X handover call flow to / from cellular / 802.Y (FIGS. 18I and 18J)

i) Mapping between MIH function and 3GPP primitives (FIG. 18K)

j) Mapping between MIH Function and 802.11 Primitives (Figure 18L)

Various potential modifications and / or adaptations, as well as various features and aspects of the embodiments shown in FIGS. 18A-18L, will be recognized and understood by those skilled in the art based on this specification. In addition, the entire contents of which are hereby incorporated by reference and clearly filed on November 8, 2004, IEEE 802.21 MEDIA INDEPENDENT HANDOVER, DCN: 21-04-0170-00-0000, Title: IEEE 802.21 Media Independent Handover Solution See Proposal, Yogesh Bhatt, Ajoy Singh, Nat Natarajan, Madjid Nakhjiri, Alistair Buttar, Lach Hong-Yon. In addition, the entire contents thereof are hereby incorporated by reference and are expressly filed on November 17, 2004. IEEE 802.21 MEDIA INDEPENDENT HANDOVER, DCN: 21-04-0171-01-0000, Title: Initial Proposal to IEEE 802.21 from See SAMSUNG, Xiaoyu Liu, Youn-Hee Han, Vivek Gupta, Soo-Hong Park, Sungjin Lee, Hyungkyu Lim, Chihyun Park, Chongwon Kim.

MIH  Example Suggestions for Functions and Information Services

19A-19M illustrate some exemplary embodiments and aspects of medium independent handover (MIH) functionality and information services as described in Appendix A of the above-listed provisional application filed November 5, 2005. FIGS. . In this regard, information from them is included below.

Suggested range:

19A-19M relate to partial proposals according to the 802.21 requirements document.

Covers two important functions

MIH function, and

-Information service

• Describe specific handover scenarios.

Overview of the proposal:

Bootstrapping Problem

-When the device is started

It may depend on how many interfaces the device has.

MIH Function

General purpose MIH primitives

-Primitives for security and disconnection free handover and their mapping with higher layers

Secure Handover Solution

Information Service

-Discovery, detection and selection

The information the device needs for handover optimization

Information service model

Assumptions and Scenarios:

Family

Multiple air interfaces to heterogeneous networks

Single or multiple (11a / b / g) interfaces to heterogeneous networks

The scenario covered in this example

802.11 vs cellular

802.11 vs 802.2 / WiMAX

802.11 vs 802.11

Single Air Interface Scenario:

A mobile node with a single IEEE 802.xx interface can roam between multiple subnets and multiple management domains.

MIH based on information obtained via L2 only has a limitation.

MIH may need information from higher layers.

Efficient cross-subnet and domain handoff

Single air interface roaming scenario:

Referring to FIG. 19A, a single air interface roaming scenario is shown.

Multiple air interface scenarios:

A mobile node with multiple interfaces may want to deactivate unused interfaces.

When the mobile node moves, deactivated interfaces may need to be activated according to radio conditions.

-The disabled interfaces themselves cannot find their access point / base station.

Information services that rely only on disabled interfaces have some limitations.

The MIH may also consider inactive interfaces as candidates to switch from the currently active interface.

Fast interface activation may be a requirement for MIH.

Multiple air interface roaming scenarios:

Referring to FIG. 19B, a multiple air interface roaming scenario is shown.

Bootstrapping  Scenarios, issues and requirements:

Bootstrapping  scenario:

The device is powered up and the interfaces are detecting the presence of the network.

Two different cases:

The device is booting up for the first time on the network.

The device is rebooting.

Have previously had access (previous knowledge of the network).

Presence of multiple providers

Similar networks (eg only WLAN networks);

Dissimilar networks (eg WLAN, 3G)

a few Bootstrapping  Problem:

The device may have limited information about the network if the access is not authenticated.

The device may not have any prior knowledge about the network visited.

Multiple networks may not have coverage in a particular area.

The device may not have higher layer information if it is not cached or preconfigured.

The device may not have the appropriate security parameters to connect to the network.

Bootstrapping solution  Requirements:

Architecture elements must handle bootstrapping separately.

Pros and cons of each proposal should be evaluated based on security requirements.

Present Solution  Example performance:

One example of the proposed solution does not address the bootstrapping problem.

MIH  Functions:

Network Discovery

Security

Mobility / Handover

ㆍ Quality of Service

Power Management

ㆍ Other

General purpose MIH  Functional model:

The general purpose MIH functional model is shown in FIG. 19C.

MIH  Functional Model (Information Service, Mobility, and Security):

The MIH functional model (information service, mobility and security) is shown in FIG. 19D.

General purpose MIH Primitives :

Network discovery primitives:

Network Name

IP address (network elements, DNS, SIP servers ..., location)

Network / link type

Bandwidth

Network cost

Security primitives:

Security performance

Security parameters (key, SA, ...)

Access privileges

QoS primitives:

-Link type

QoS level / mapping

Bandwidth

ㆍ Mobility / Handover Management

-Mobility features

Protocol, Speed, Real Time, Non-Real Time, ...

Handover type

Soft Handoff, Hard Handoff, ...

Power Management

-Sleep time, wake type, ...

-Power budget

MIH  Motion flow

The MIH operational flow is shown in FIG. 19E.

MIH  Functions: One example:

Network Discovery

getNetworkName ()

getIPaddress ()

gettypeof server ()

getBandwidth ()

Security

getkeyinformation ()

getsecurityprotocol ()

getauthenticationserver ()

Security and disconnection Handover solution :

The solution is based on the concept of pre-authentication (PA) and can be defined as follows, for example.

Mobile device support authentication scheme that a priori obtains upper layer information to perform authentication and authorization before session and service handover

The MIH function performs this process on behalf of mobile users.

MIH  Pre-authentication ( MPA ):

ㆍ MIH pre-certification

-Provides security and seamless mobility optimization that works for:

ㆍ Handoff between subnets

Cross domain handoff

ㆍ Inter-Tech Handoff

-Use of multiple interfaces

Define a new mechanism at the upper layer (eg network).

• Supports IP address change (different from Layer 2 (L2) pre-authentication where the MAC address does not change).

MPA The functional elements of:

1) Pre-certification

Used to establish a security association (SA) between a mobile device and a network to which the mobile device can move.

L2 pre-authentication may also be enabled based on the established SA.

2) prior authorization

Used to set a context unique to the network the mobile device will travel to.

The SA created in (1) is used to secure the authorization procedure.

3) Virtual Soft Handoff ( VSH )

Used to send and receive IP packets based on a pre-authorized context using the context of the current network.

Expected results:

A diagram showing exemplary expected results in accordance with some embodiments is shown in FIG. 19F.

Pre-certification:

19G is a schematic diagram illustrating pre-authentication in some example embodiments.

Prior authorization:

19H is a schematic diagram illustrating prior authorization in some exemplary embodiments.

Virtual soft handoff ( VSH ): Initial stage:

19I is a schematic diagram illustrating an initial stage of a virtual soft handoff in some example embodiments.

VSH : Tunneling  Phase

19J is a schematic diagram illustrating the tunneling step of virtual soft handoff in some example embodiments.

VSH Steps to complete:

19K is a schematic diagram illustrating a completion phase of a virtual soft handoff in some example embodiments.

Information service:

What is an information service?

The information service may be defined as follows, for example.

Network Discovery:

The process by which the device collects information about the network (s)

Network detection

The process by which a device connects to a network and collects information

Network selection

The process by which the device selects the appropriate network (eg from information collected by discovery and detection);

Information service solution :

Application layer mechanism (AIS) for information services

Network discovery is defined using XML-based technology.

-Flexible way to retrieve L2 and L3 topology information

For information services Application layer  mechanism( AIS ):

Application layer protocol to help provide information about networking elements of neighboring networks

The information may include parameters for various layers of networking elements, for example:

It may consist of the MAC address of the access point, the IP address of the access router, the security model, and the QoS.

Information can be queried using location information as a search key.

The location information may be an access point identifier, a geographical address, a city address and the like.

Information may enhance MIH pre-authentication (MPA).

• Provide a link layer agnostic solution.

• Provide the ability to move between administrative domains.

• Provide a framework that uses existing standards for access points and routers without any changes.

Provides a modular and flexible database using XML, RDF, and SOAP.

The RDF database can be built in a distributed fashion to be scaled over multiple networks.

RDF can handle arbitrary interconnected data structures, while LDAP only handles tree-based structures.

RDF provides the lookup schema as well as the data itself.

Network information can change its data structure frequently as networking technology advances.

Two basic approaches to building information service databases

Network Support Database Deployment Model

-Mobile Device Support Database Deployment Model

AIS Wow L2  Comparison of Information Services:

Information service in L2 is needed for initial network connection where IP connection is not available initially.

Information service in L2 has some limitations.

If the information is broadcast in a beacon, the information consumes a lot of bandwidth.

The mobile device must be within wireless coverage of the IPs providing the information service.

Mobile devices moving at high speeds may need information before entering wireless coverage of the network.

Multi-interface mobile device may want to discover APs for an interface deactivated via an active interface.

In some Link 2 protocols (eg 802.3), the lack of fragmentation makes it difficult to process large data.

AIS can overcome this limitation.

AIS  Support security Unbreakable  Handoff:

Secure seamless handoff using MPA is based on information retrieved from neighboring networking elements such as routers, SIP servers, PANA authentication agents, and the like.

See also FIG. 12, which illustrates the integration of network discovery and security seamless handoff.

Example information lookup:

See FIG. 12, which shows an exemplary information query example.

AIS for RDF  Schema (partial view):

19L illustrates an example graphical view of a schema.

AIS for RDF  Schema (detail):

19M shows an exemplary detailed graphical view of the schema.

Handover  scenario:

Handover from 802.11 to Cellular Networks

Handover from 802.11 to 802.11 network

Handover from 802.11 to 802.3 Network

Introduction to Information Services Schema

The schema defines the structure of the information. The schema is used to define the structure of each information element in the 802.21 information service as well as the relationships between the different information elements supported. The 802.21 information service schema needs to be supported by all MIH functions that implement MIIS to support flexible and efficient information retrieval. 802.21 Information services define various information elements and their structures. Various IEs represent lower layers of the network stack as well as higher layer services available in different access networks. The schema is defined by one language and can be expressed in various ways. Examples include XML, ASN.1 used in the 802 MIB, resource description framework (RDF) based on variations of simple information elements or simple TLV representations.

The MIIS schema is divided into two main categories. The base schema is essential to support an extension schema where all MIHs are optional and may be vendor specific.

RDF  Schema Representation:

This chapter provides an example of a schema using RDF. See "3GPP system to Wireless Local Area Network (WLAN) interworking; System description" (reference [8]). The RDF uses SPARQL (see 3GPP TS 23.060, "General Packet Radio Service (GPRS); Service Description; Stage2" (see [7])) as an inquiry language for information inquiry. Both RDF Schema and SPARQL are represented in XML. The RDF schema defines the structure of a set of representations, where the substructure of any representation is a set of triples, each consisting of a subject, predicate and object. RDF's XML syntax, called RDF / XML, is defined in GPP TR 43.901 "Feasibility Study on Generic Access to A / Gb Interface" (see [9]).

RDF has the following advantages, for example.

Support both hierarchical and non-hierarchical information structures.

Allow flexible data lookup.

Allow distributed schema definition.

It is easier to change the schema definition.

As described below, the RDF schema definition for MIIS has two parts, the base and extension schemas. The default schema should not be updated. MIH entities typically have a base schema pre-built for easy implementation of schema-based queries. In scenarios where the base schema is not pre-equipped, methods such as DNS lookup can be used to access the location of the base schema (FQDN).

Unlike the base schema, the extension schema is expected to be updated periodically, for example when new link layer technologies are introduced. Extension schemas can be retrieved from specified URLs via the IEEE 802.21 Information Service using the schema lookup capability described in section 8.5.3 of IEEE 802.21 Media Independent Handover Services 21-05-xxxx-00-0000-One_Protocol_Draft_Text without any prior advance of such extension schemas. Can be. The URL of the extension schema can also be obtained through the schema URL lookup capability described in section 8.5.3 above. Alternatively, DNS lookups can be used to find the location (FQDN part) of the extension schema. An extension schema is defined as an extension of the base schema and contains data structures and relationships of media specific or higher layer information. In that sense, the extension schema is a complement to the base schema.

IEEE  802.21 Information Services RDF Of XML  Schema support

1. Preface

This chapter of this specification refers to (1) RDF / XML Schema Definition of IEEE 802.21 Information Services, and (2) to support RDF / XML-based IEEE 802.21 Information Services [1] (the above priority filed April 13, 2005). Changes required for the information service primitives described in Provisional Application) and (3) examples of the use of primitives using RDF / XML-based IEEE 802.21 information service.

2. IEEE  802.21 Information Services RDF Of XML  Schema Definition

The RDF / XML schema definition of the IEEE 802.21 Information Service has two parts, the base schema and the extension schema. Every MIH entity must have a base schema in advance. The default schema should not be updated. The rest of the RDF / XML schema is an extension schema. Unlike the base schema, the extension schema must be updated, for example when a new link layer technology is introduced, and the MIH entity does not need to have an extension schema in advance. Instead, the extended schema can be retrieved through an information service using, for example, the schema lookup capability described in Part 3 below.

20 shows a graphical representation of the currently defined RDF / XML schema.

2.1 basic schema

The base schema is represented in RDF / XML format as shown in FIGS. 21A and 21B.

2.2 Extension Schema

The extension schema is represented in RDF / XML format as shown in Figs. 21C-21L.

3. RDF Of XML  Information Services Supporting Schemas Primitive

In [1], two primitives, MIH_information.request and MIH_information.response, are defined for the IEEE 802.21 information service as follows.

MIH_information.request

(

InfoQueryFilter,

InfoQueryParameters,

QueryID

)

designation type Effective range Explanation InfoQueryFilter Combination of lookup filter type flags N / A A set of query filters that control the type and amount of information retrieved InfoQueryParameters N / A Lookup filter specific parameters that indicate the type of information the client may be interested in QueryID essence N / A Unique query ID to help match request and response

MIH_information.response

(

InfoQueryFilter,

MIH_REPORT,

QueryID,

status

)

designation type Effective range Explanation InfoQueryFilter Combination of lookup filter type flags N / A A set of query filters that control the type and amount of information retrieved MIH_REPORT N / A Reporting consists of information requested by L3MP or MIH QueryID essence N / A Used to match response and request. Status Success / failure N / A Specifies whether the information was retrieved successfully.

In order to support information services based on the RDF / XML schema, the following changes are made to the information service primitives.

3.1 Neighbor Graph Lookup

A new information query filter type "FILTER_INFO_NEIGHBOR_NETWORKS" is defined. When this information query filter type is specified, the information query parameter must be a string containing a SPARQL query [2], which must include an appropriate query to obtain a neighbor graph. MIH_REPORT in the corresponding MIH_information.response must be a string containing the SPARQL query result [3].

An example query request and response when FILTER_INFO_NEIGHBOR_NETWORKS is specified as an information query filter are shown below.

3.2 General Purpose RDF Of XML  Data lookup

A new information inquiry filter type "FILTER_INFO_DATA" is defined. When this information query filter type is specified, the information query parameter must be a string containing a SPARQL query [2], which must contain the appropriate query to obtain the expected RDF / XML data. MIH_REPORT in the corresponding MIH_information.response must be a string containing the SPARQL query result [3].

Example query requests and responses when FILTER_INFO_DATA are specified as an information query filter are shown below.

3.3 RDF Of XML  Schema URL  Lookup

A new information inquiry filter type "FILTER_INFO_SCHEMA_URL" is defined. When this information inquiry filter type is specified, the information inquiry parameter must be a null string. The MIH_REPORT in the corresponding MIH_information.response must be a string containing the URL for the extension schema. The implementation remains the way to retrieve the extension schema from the obtained URL.

An example inquiry request and response when FILTER_INFO_SCHEMA_URL is specified as an information inquiry filter are shown below.

3.4 RDF Of XML  Schema Lookup

A new information inquiry filter type "FILTER_INFO_SCHEMA" is defined. When this information lookup filter type is specified, the information lookup parameter must be a string containing the XML format RDF subject and, optionally, an integer specifying the depth of the search in the schema graph. The default depth value is zero, indicating that there is no limit to the depth of the search. When a depth parameter is specified in addition to the RDF subject parameter, a comma (",") is used as the delimiter character of the two parameters. MIH_REPORT in the corresponding MIH_information.response must be a string containing the obtained RDF / XML schema.

An example inquiry request and response when FILTER_INFO_SCHEMA is specified as an information inquiry filter are shown below.

4. Reference

The following references are incorporated herein by reference in their entirety.

Of 802.21 standard document RDF  Schema Update

1. Preface

This chapter of the present specification includes the proposed modification of the RDF schema as defined in 21-05-0271-00-0000-One_Proposal_Draft_Text (802.21 reference document), and the aforementioned patent provisional application filed July 11, 2005 in Appendix A. See.

In the base document, the RDF schema defines the classes, properties, and relationships between them. However, concentrations, as well as detailed data types, are missing from each characteristic. Without the definition of these levels of detail, the features used by the 802.21 information service are likely to be encoded differently by different implementations.

This chapter, in particular in conjunction with the RDF and RDF schemas, defines the detailed data types as well as the concentrations for each characteristic of the 802.21 base schema and extended schema using the OWL (Web Ontology Language) defined in the World Wide Web Consortium.

In order to strictly define each information element in the RDF schema, the schema is enhanced by the Web Ontology Language (OWL) [14].

OWL is a web ontology language. OWL uses both the URL for naming and the technical framework provided by RDF to add the following capabilities to the ontology.

Ability to be distributed among many systems

Scalability

Compatibility with other web standards for accessibility and internationalization

Openness and Extensibility

OWL is built on RDF and RDF schemas, and properties and classes, especially relationships between classes (eg dismantling), concentration (eg "exactly one"), quality, richer typing of attributes, attributes Add more idioms to describe their features (eg symmetry) and enumerated classes.

Figure 22 shows' network ',' L2, 'L3', 'location', 'IPv4', 'IPv6', 'link-form', 'PoA', 'Civic-address' and' geographic-coordinate 'as a class While all others represent an exemplary graphical representation of the 802.21 MIIS base schema, which is an attribute of a class. The lines represent a range of attributes or a subclass of a domain or class. In particular, 'r' represents a range of attributes and 'd' represents a domain of attributes. 'Domain' defines the class to which a particular attribute belongs, and 'Scope' defines the type of that particular attribute. Another instance of the 'network' class is assigned for each PoA.

Wide range of invention

Although exemplary implementations of the invention have been described herein, the invention is not limited to the various preferred embodiments described in this specification, but equivalent elements, modifications as would be appreciated by those skilled in the art based on this specification. , Any and all embodiments having omissions, combinations (eg, aspects of various embodiments), adaptations, and / or changes. The limitations in the claims (including those added later) should be interpreted broadly based on the expressions used in the claims and should not be limited to the examples described herein or during the continuation of this application, which examples are exclusive Should be interpreted as not. For example, in this specification, the term "preferably" is not exclusive and means "preferably but not limited to". Functional limitations herein and during the continuation of this application are expressly set forth with respect to the specific claims limitations in which all of the following conditions, i.e. "a- means for-" or "steps for-" And b) the function is explicitly described, and c) a condition that does not describe the structure, material, or operation that supports that structure is to be used only within the scope of the present specification and of this application. The term “invention” or “invention” may be used as a reference to one or more aspects within this specification .. Expressions in which the present invention or invention should not be improperly interpreted as critical identifications are used in all aspects or embodiments. It should not be improperly interpreted as being applied (ie, it should be understood that the invention has many aspects and examples) and is not intended to limit the scope of the specification or claims. In this specification and during the continuation of this application, the term "embodiments" shall not be construed as referring to any aspect, feature, process or step, any combination thereof, and / or portions thereof. In some instances, various embodiments may include overlapping features In this specification, the abbreviation “eg” meaning “for example” and “NB” meaning “note”. (note well) "may be used.

Claims (32)

A network discovery method of a mobile device for using at least one of a plurality of access networks in an IP network, the mobile device comprising: When the mobile device is connected to an IP network at any location, obtaining specified network information from an information server in the vicinity of a given location based on a set of geographic criteria including location, movement, speed and / or movement pattern , Sending a query to the information server via the access point or access router to which the mobile device is currently connected, for the designated network information based on at least one preference of the mobile device, Receiving network information belonging to the designated network information from the information server based on the query, wherein the network information includes information used by the mobile device to access the access network. delete The method of claim 1, wherein the network information comprises an identification of a network attachment point of an access point. The method of claim 1, wherein the network information comprises a security type supported by an access point. The method of claim 1, wherein the network information comprises a layer 3 type. The method of claim 1 wherein the network information comprises a provider name. The method of claim 1, wherein the network information comprises an address of a server or an agent. The method of claim 1 wherein the network information comprises an address of an authentication agent. The method of claim 1 wherein the network information comprises an address of an access router. A discovery method of network information of a target network by a mobile device, a) dynamically populating at least one discovery database of network information of the information server; And b) the mobile device from the at least one discovery database before being connected to the target network in response to a query from the mobile device sent to the information server via an currently connected access point or access router. Sending network information for the target network to a device, the network information being used by the mobile device for handoff and preauthentication; &Lt; / RTI &gt; 11. The method of claim 10, further comprising using a resource description framework (RDF) as a database structure. 11. The method of claim 10, further comprising dividing a media independent information service schema into a base schema and extended schema categories, the base schema being necessary for supporting media independent handover and wherein the extension is supported. Schema is optional for supporting media independent handovers. The method of claim 10, wherein the method utilizes Application-layer mechanisms for Information Service (AIS). delete 11. The method of claim 10, wherein the method uses AIS independent of layer 2. The method of claim 10, wherein the method uses a network assisted discovery mechanism. The method of claim 10, wherein the method uses a mobile device support discovery mechanism. The method of claim 10, wherein the method uses a network support mechanism to build the database. The method of claim 10, wherein the method uses a mobile device support mechanism to build the database. The method of claim 10, wherein the mobile device queries an AIS server or peer mobile device to obtain information about networking elements in the target network. 21. The method of claim 20, further comprising obtaining the information using a reporting agent (RA). 21. The method of claim 20, further comprising obtaining the information using an AAA server. 21. The method of claim 20, further comprising obtaining the information using a DNS server. 21. The method of claim 20, wherein the method uses a peer-to-peer model in which mobile devices function as information servers. 25. The method of claim 24, wherein the method employs a scoped multicast approach. 25. The method of claim 24, wherein the method employs an iterative broadcast approach. A medium independent handover function entity for discovering and obtaining network information present in a geographic area to facilitate handover, the method comprising: Using an application layer mechanism (AIS) based service discovery scheme for information services using a resource description framework (RDF) as a database structure to maintain information regarding a plurality of locations or networks; Providing network information to the mobile node via an access point or access router to which the mobile node is currently connected based on an inquiry of an application layer mechanism of the information server of the mobile node; Prediscovering one or more of the network elements AP, router, SIP server and PANA server, and using the network information to establish security pre-authentication for the mobile node by prediscovering the network element in a neighboring network. Steps to &Lt; / RTI &gt; 28. The method of claim 27, using SOAP, HTTP, XML, WSDL and / or JENA as companion protocols to provide a transport mechanism for scouting, database population by reporting agents and / or information lookup by mobile nodes. The method further comprises the step. delete delete A method of defining the structure of an information element for network discovery of a mobile device, Providing an information server using an information database that partitions a media independent information service schema into a base schema and an extended schema category, wherein the base schema is essential for supporting media independent handover, and the extended schema supports media independent handover Optional on-; Providing, by the mobile device, a base schema or an extension schema to the mobile device based on a query from the mobile device to the information server via an currently connected access point or access router-the base schema or the extension The schema relates to a plurality of networks or locations. 32. The method of claim 31, further comprising providing a vendor specific extension schema.

Images