WO2014093734A1 - Expanded wi-fi coverage for vehicular telematics - Google Patents

Expanded wi-fi coverage for vehicular telematics Download PDF

Info

Publication number
WO2014093734A1
WO2014093734A1 PCT/US2013/074844 US2013074844W WO2014093734A1 WO 2014093734 A1 WO2014093734 A1 WO 2014093734A1 US 2013074844 W US2013074844 W US 2013074844W WO 2014093734 A1 WO2014093734 A1 WO 2014093734A1
Authority
WO
WIPO (PCT)
Prior art keywords
device
wi
fi
internet
node
Prior art date
Application number
PCT/US2013/074844
Other languages
French (fr)
Inventor
David Warren SCHMIDT
Kenneth A. Wiesner
William James NORTHRUP
Original Assignee
Schmidt David Warren
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority to US201261797736P priority Critical
Priority to US61/797,736 priority
Priority to US201361785005P priority
Priority to US61/785,005 priority
Application filed by Schmidt David Warren filed Critical Schmidt David Warren
Publication of WO2014093734A1 publication Critical patent/WO2014093734A1/en

Links

Classifications

    • GPHYSICS
    • G01MEASURING; TESTING
    • G01NINVESTIGATING OR ANALYSING MATERIALS BY DETERMINING THEIR CHEMICAL OR PHYSICAL PROPERTIES
    • G01N33/00Investigating or analysing materials by specific methods not covered by groups G01N1/00 - G01N31/00
    • G01N33/0004Gaseous mixtures, e.g. polluted air
    • G01N33/0009General constructional details of gas analysers, e.g. portable test equipment
    • G01N33/0073Control unit therefor
    • G01N33/0075Control unit therefor for multiple spatially distributed sensors, e.g. for environmental monitoring

Abstract

An electronic device containing a Wi-Fi transceiver is installed in a vehicle. The device selects nearby Wi-Fi nodes and identifies which nodes are compatible for sending and receiving messages to a central server. A compatible Wi-Fi node is a standard Internet access point, a second installed device, or some relaying computer.such as a smartphone. The compatible Wi-Fi node may be connected to the Internet through one of several types of portals including an open portal, a captive portal, a limited application-specific portal, or an asynchronous portal. The first device forwards messages through the compatible node's Internet portal and the messages are eventually received at a central server and stored in a central database. The information is then available for a remote user. Because the device operates with various types of compatible nodes and Internet portals, the total Wi-Fi coverage area is maximized.

Description

Expanded Wi-Fi Coverage for Vehicular Telematics

CROSS-REFERENCES TO RELATED APPLICATIONS The present application claims the benefit of U.S. Provisional Application No.61/797,736 entitled "Service Notification utilizing open Networks" filed on December 14, 2012 and U.S. Provisional Application No.61/785,005 entitled "Expanded Wi-Fi Coverage for Remote Vehicles" filed on March 14, 2013. FIELD OF THE INVENTION

The present invention relates to monitoring conditions associated with a vehicle and, more specifically, to wirelessly transmitting such conditions so that they are accessible by remote users. BACKGROUND OF THE INVENTION

Many in-vehicle telematics applications operate today on proprietary, commercial networks such as cellular or satellite. Such networks have the advantage of near real-time communications, widespread coverage areas, and no additional equipment required by the end-user. However, they have the significant disadvantage of cost; access to these networks comes with recurring per-device fees and usage fees that can be significant barriers in some markets.

Other telematics applications have proposed to get around these cost barriers by connecting to a user's cellular phone via Bluetooth, and piggybacking on the user's cell-phone subscription. These approaches require the user to own a capable phone that has a suitable airtime plan, is correctly paired to the device, is running suitable software, and is in close proximity to the vehicle. In certain markets, these requirements can be hurdles to user convenience or limits to overall performance.

SUMMARY OF THE INVENTION

In the present invention, an electronic device containing a Wi-Fi transceiver is installed in a vehicle. The device monitors conditions associated with the vehicle using internal and external sensors and generates messages based on the data from these sensors. The device also continuously or periodically finds other Wi-Fi nodes that are within range. For each node that is found, the device determines whether or not that node is compatible for communicating over the Internet with a central computer server. A compatible node type could be a typical Internet access point such as a standard Wi-Fi router, a second installed device which forwards messages for a first device, or a relaying computer. Relaying computers are intermediate nodes that are not installed in vehicles; they run software which allows their Wi-Fi transceivers to transfer data between installed devices and Internet access points. Examples of relaying computers can thus include phones, tablets, laptops, televisions, and other Wi-Fi capable appliances and computers.

A compatible node may operate in a limited subset of the standard Wi-Fi modes such as infrastructure access point mode, infrastructure client station mode, ad-hoc mode, or Wi-Fi Direct mode. It may or may not require authentication from the device before a Wi-Fi link can be formed, and it may or may not require the device to use encryption on the formed link. The installed device is capable of operating in these various Wi-Fi modes and performing authentication and encryption as required by the compatible node. A compatible node contains, or is associated with, an Internet portal through which it sends data toward or onto the Internet. This Internet portal may be an Open Internet Portal which allows realtime access to the general Internet; a Captive Internet Portal which also allows real-time access to the general Internet, but only after certain actions are completed or conditions are met; a Limited Internet Portal which can forward certain information in real-time to the Internet, but does not provide general Internet access with standard Internet routing implementations; or an Asynchronous Internet Portal which is not simultaneously connected to the upstream and downstream links, and operates by storing messages and forwarding them to the Internet at a later time. These different types of Internet portals are further described and differentiated below. The installed device is capable of identifying and operating with these various types of Internet portals.

The device also contains its own Limited Internet Portal, and can forward messages received from second devices or relaying computers that come within its wireless range. This can be done even if the device has no current connection to the Internet, in which case the device operates an

Asynchronous Internet Portal.

When possible, a device or relaying computer will forward messages over the Internet to a central server. Once a central server receives the message, it stores a representation of the information contained in that message in a database where it can be accessed by allowed users over the Internet. The central server responds to the message with a second message which is destined for the originating device and which contains an acknowledgment. Optionally, the second message also contains additional commands for the originating device. The second message may traverse to the destination device through nodes which are different from the nodes through which the first message passed. Optionally, the central server may respond with additional messages containing commands for nodes which participated in the forwarding of the first message, or for nodes known to be in communication with those nodes.

The ability of the installed device to operate with multiple node types, Wi-Fi modes, public/private link settings, and Internet portal types is particularly advantageous because it can overcome deficiencies that exist in each individual method of operation.

For example, the installed device is capable of using existing public Wi-Fi Internet hotspots, and thus does not require a user to purchase any additional equipment. However, depending on geographical area, the limited range of Wi-Fi communications and the gaps in public Wi-Fi coverage can make public Wi-Fi infrastructure incompatible with a widespread, low-latency solution for mobile vehicles. To connect to a Wi-Fi access point, a vehicle must be within range of the access point for a minimum period of time, something which is complicated if the vehicle is moving. Furthermore, public Wi-Fi Internet hotspots are controlled by numerous third parties who run different configurations and enforce different access rules. For example, Open Internet Portals are often found in residential and commercial areas whereas Captive Internet Portals are found mainly in retail areas. Depending on the habits of the drivers and vehicles, one or more options may not be available. To provide maximum coverage, the device is capable of operating with both Open Internet Portals and Captive Internet Portals. The installed device can also use private Wi-Fi Internet access points such as a driver's password- protected home or office Wi-Fi network. However, implementation of this method requires convincing the access point owners to give their permission or take their own action to program the needed passwords, and requires the vehicle to return regularly and reliably to within range of the programmed access points.

The device is also capable of communicating over Wi-Fi with relaying computers such as a driver's phone, tablet, laptop, television, or other computer. These relaying computers may contain Limited Internet Portals or Asynchronous Internet Portals or both. However, implementation of this method requires that the driver manages and monitors additional equipment, ensuring that the needed software applications remain installed in the relaying computer and the relaying computer is regularly located in wireless range of the vehicle.

The device is also capable of relaying messages via Wi-Fi through other devices installed in nearby vehicles. However, implementation of this method requires that the vehicle operates in geographical areas where a certain device deployment saturation threshold has been met.

Each method, of and by itself, has complications which limit performance. However, because the device combines multiple methods, the limitations of any one individual method are eliminated and total coverage area is greatly expanded. This moves Wi-Fi connectivity between a mobile vehicle and a central Internet server closer to real-time.

BRIEF DESCRIPTION OF THE DRAWINGS The features of the present invention will become apparent upon reference to the drawings wherein:

FIG. 1 is a block diagram containing an overview of communications of an installed device, including communications via Wi-Fi to a remote user and a local user. FIG. 2 is a block diagram showing how data messages are relayed between an installed device, through intermediate nodes and Internet access points, and finally to central servers on the Internet.

FIG. 3 is a block diagram of the Wi-Fi communication modes used to discover nearby nodes and establish data links to those nodes.

FIG. 4 is a flow diagram of the steps taken to choose which Wi-Fi nodes to communicate with from a list of Wi-Fi nodes that are within wireless range.

FIG. 5 is a flow diagram of the steps taken to send data through a suspected compatible Internet access point which runs an Open Internet Portal or a Captive Internet Portal.

FIG. 6 is a flow diagram of the steps taken to send data through a suspected compatible intermediate node, such as a second installed device or relaying computer, which runs a Limited Internet Portal or an Asynchronous Internet Portal. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

The following general definitions are useful when describing the present invention.

"Wi-Fi" refers to any one or more of the IEEE (Institute of Electrical and Electronics Engineers) 802.11 (Wi-Fi) standards and/or amendments.

"Public Wi-Fi node" refers to a Wi-Fi node that will allow a Wi-Fi link without authentication or other restriction based on the identity of the peer node (a public link). It does not imply that the Internet or any other network service is available once the link is established.

"Private Wi-Fi node" refers to a Wi-Fi node that requires various authentication objects in order to restrict which peers are allowed to form a Wi-Fi link (a private link). Examples of such

authentication objects include passwords, passphrases, keys, certificates, peer MAC addresses, and/or other credentials.

"Open Internet Portal" refers to a type of Internet portal which provides general Internet access to a client after the client establishes a data link to its associated node and joins the node's local network. This type of portal is designed to maintain simultaneous active connections to both its upstream and downstream links, thus providing real-time or near real-time connectivity. Wi-Fi nodes operating in association with an Open Internet Portal usually operate in the Wi-Fi infrastructure access point mode. They may be public or private. A Wi-Fi client seeking Internet access through an Open Internet Portal does not need to make a specific request for Internet access once the Wi-Fi link is established. However, the client may still need to engage in additional communications with network servers using specific, standard protocols (such as DHCP) prior to realizing any Internet access, if such steps are necessary for the client to properly join the Wi-Fi access point's local area network. The general Internet access allowed by an Open Internet Portal may possibly still contain some restrictions or limitations. For example, an Open Internet Portal may impose some address blacklists, port and protocol restrictions, bandwidth limitations, or time-based restrictions. Private Wi-Fi nodes with Open Internet Portals are commonly found in residences and offices, and public Wi-Fi nodes with Open Internet Portals are often found in retail establishments and public areas.

"Captive Internet Portal" refers to a type of Internet portal that does not allow general Internet access immediately after the client establishes a data link to its associated node and joins the node's local network. However a Captive Internet Portal may provide general Internet access at a later time after a client engages in additional communications. Like Open Internet Portals, Captive Internet Portals are also designed to maintain simultaneous active connections to both upstream and downstream links, thus providing real-time or near real-time connectivity to the Internet. Wi-Fi nodes operating in association with a Captive Internet Portal also usually operate in the Wi-Fi infrastructure access point mode. However, these Wi-Fi nodes typically are public and not private. This is because if peer identification and/or authentication steps are required, they can be performed by the Captive Internet Portal itself during the additional communications phase. Prior to allowing general Internet access, a Captive Internet Portal may still offer some limited Internet access; such limited access would typically only include affiliated websites and other Internet-located services which participate in the additional communications phase. The additional communications are commonly performed using the human-friendly HTTP protocol, but other protocols, such as XML, may also be used for the purpose of making the process more automated. Captive Internet Portals may be implemented for the purpose of user/client authentication, user/client identification, acquiring user/client acceptance of service terms, and/or presenting a notice or advertisement to the user/client. They may utilize a variety of means to accomplish this, such as HTTP -based redirection, IP-based redirection, and DNS-based redirection or poisoning. Captive Internet Portals are often found in retail establishments.

"Limited Internet Portal" refers to a type of Internet portal that does not provide general Internet access, but still provides a means of relaying certain, limited data to the Internet. Like Open Internet Portals and Captive Internet Portals, this type of portal is also designed to maintain simultaneous active connections to both its upstream and downstream links, thus providing real-time or near real- time connectivity. Limited Internet Portals can be implemented for the purpose of allowing information generated by a specific application or source to reach the Internet, or for avoiding limitations inherent in the hardware or operating system on which the portal is operating. For example, a smartphone that monitors a nearby installed device over one data link and relays that received data to the Internet over a second data link would be a Limited Internet Portal so long as both data links are simultaneously active and the smartphone is not merely providing an Internet hotspot functionality. In this example, the smartphone is assuming a specialized role in deciding when to retrieve data and how to package or re-send the data in an Internet-ready format; such a role could not be performed by a typical Internet access point. "Asynchronous Internet Portal" refers to a type of Internet portal that will accept messages from other nodes, hold those messages until later when a path to the Internet becomes available, and then forward those messages toward the Internet when such a path materializes. It does not maintain simultaneous connections to both its upstream and downstream links nor does it provide real-time connectivity. An Asynchronous Internet Portal is typically expected to have sporadic, non-real-time, or non-continuous access to the Internet. For example, a computer would be an Asynchronous Internet Portal if the computer accepts messages from a device, stores these messages in its internal memory until it arrives within range of an Internet access point, and then forwards these messages to the Internet. Another example of an Asynchronous Internet Portal would be a relaying computer that cannot simultaneously connect to both an installed device and a Wi-Fi Internet access point at the same time, and so the relaying computer briefly stores messages that it intends to relay while it temporarily drops a connection to one and establishes a connection to the other.

Referring to the drawings that are for illustrating a preferred embodiment of the present invention only, and not for purposes of limiting the present invention, FIGS. 1, 2, 3, 4, 5, and 6 illustrate methods of communicating via Wi-Fi links from installed devices to remote users through intermediate relaying computers and Internet access points.

Fig. 1 illustrates a high-level overview of external communications of the device used in the present invention. A device 110 is installed in a vehicle. Preferably, the device has an OBD-II connector so that the device can both draw power and communicate with sensors through the same connector. Alternatively, the device may simply have power and ground wires that can provide power when attached to appropriate locations inside the vehicle. It is contemplated that some users may want to decrease the possibility that the device is removed without their knowledge, and thus the device may be installed behind the dashboard, adhered, fastened, tied, crimped, soldered or otherwise affixed to the vehicle in a manner that is not easily or properly removed by hand.

The installed device 110 is capable of gathering information from one or more external sensors 101- 103 via an external sensor communication link 104. External sensors may be present on a vehicle bus, or they may be connected to the device directly. Other sensors may be physically located inside the device (internal sensors). The device uses the input from all available sensors and other criteria to determine if and when a message should be transmitted to a user.

The device's Wi-Fi communications are split into two categories: local Wi-Fi communication links 111 and remote Wi-Fi communication links 112. This is not a distinction in the effective range of each Wi-Fi link, because the device is using the same Wi-Fi transceiver and the wireless range is limited in both cases. Instead, the categories refer to the relative location of the user that the message is intended for; the distinction is useful for a conceptual understanding of the system. In a local Wi-Fi communication link, the eventual local user 171 is within range of the Wi-Fi transmissions of the device; whereas in a remote Wi-Fi communication link, the transmissions of the device are relayed through the Internet 150 to central servers 160, and the eventual remote user 172 could be anywhere in the world. The local Wi-Fi communication link 111 is a direct link between the device 110 and a local Wi-Fi interface 120. Preferably, this is a private Wi-Fi link, but alternatively could be a public link because authentication and encryption could be performed at the application level. The actual local Wi-Fi interface could be a phone, tablet, laptop, television, or other computer. The purpose of the local Wi-Fi interface is to communicate with the installed device using Wi-Fi, provide information about the device and its sensors to the local user 171, and to allow the local user to further configure the device.

Unlike the local Wi-Fi communication link 111, the remote Wi-Fi communication link 112 is part of an indirect link between the installed device 110 and a central server 160 on the Internet 150. The device is scanning for compatible Wi-Fi nodes 130-131 which come into wireless range, so that the device may forward messages from its queue to a compatible node and eventually a central server. The compatible Wi-Fi node could be either a public Wi-Fi node 130 or a private Wi-Fi node 131. In either case, the compatible node is associated with an Internet portal 140-143 that provides access to the Internet. If the compatible node is private 131, then the device 110 must know the correct authentication object prior to using this node. The device can obtain the authentication object in advance either when the device is programmed via a local Wi-Fi node 120, or remotely via the central server 160 while the device is communicating with the central server over a different remote link. The authentication object is required during the formation of the remote link. For example, if the authentication object is a password, the device would present the password when required during link formation. Similarly, if the authentication object is a specific MAC address, then the device would switch to the correct MAC address prior to communicating with this node.

The Internet portals 140-143 can be classified as one of the four types defined above: an Open Internet Portal, a Captive Internet Portal, a Limited Internet Portal, or an Asynchronous Internet Portal. The device 110 has mechanisms for dealing with each of these kinds of portals, which are described later. A remote Wi-Fi node 130-131 and Internet portal 140-143 are often contained in the same physical package, a common example of which is a standard Wi-Fi router. Fig. 2 illustrates an alternative view of the possible communication links within the system, specifically showing how messages are forwarded and relayed between an installed device 211 and a central server 250. Since the messages will pass through untrusted third party nodes

210,220,221,230,231 and the open Internet 240, all remote data is preferably encrypted and authenticated based on a unique key that is shared between the device and the central server.

Alternatively, the authentication and encryption steps could be skipped, or they could use two different keys, or less securely, non-unique keys that are known by other elements in the system. As contemplated earlier, some users may wish to validate that the device has not been removed or tampered without their knowledge. Therefore, the messages also preferably contain information indicating whether the installed device is communicating with its sensors. The central servers can then use the decrypted messages, in conjunction with a maximum expected interval between received messages, to remotely verify that a given device is properly installed and properly monitoring the vehicle at any given time. The device may optionally be equipped with a backup battery, in which case the device can actively generate a message if it is disconnected from the vehicle.

A local Wi-Fi interface 201 is shown for the viewer's orientation. The local Wi-Fi interface can be used to interact with the installed device 211 over a local Wi-Fi link as previously described.

A second installed device 210 is present; each device is installed in its own, separate vehicle. In this diagram, the first device 211 sends messages destined for the central server to the second device 210. Each device contains a Wi-Fi node to establish the Wi-Fi link and an Internet portal that forwards the messages toward the Internet. Since messages are preferably end-to-end encrypted between the originating device and central server, these Wi-Fi nodes may be public. Although not pictured, the second device might also forward these messages to a third device which might forward them to a fourth device and so on. If a device can forward these messages immediately, it will do so. Otherwise, the device will hold messages until they can be forwarded, or until they are discarded because a time-to-live has expired.

At some point, an installed device 210 may forward messages to a relaying computer 220, 221. Relaying computers are not installed in vehicles like installed devices, but each relaying computer contains a Wi-Fi node for communicating with installed devices. Since messages are preferably end- to-end encrypted between the originating device and central server, these Wi-Fi nodes may also be public. A relaying computer contains a Limited Internet Portal or an Asynchronous Internet Portal, and thus, unlike an Internet access point, does not provide a real-time general connection to the

Internet. Similar to a device, a relaying computer can forward messages immediately, or it may hold messages until it forwards them later or until it discards them because a time-to-live has expired.

Note that a first relaying computer 220 might forward the message to a second relaying computer 221, which may be of a different type and capabilities than the first. Although not pictured, the second relaying computer might also forward these messages to a third relaying computer which might forward them to a fourth relaying computer and so on.

At some point, a relaying computer 220, 221 will forward messages to an Internet access point 230, 231. Depending on the type and capabilities of the relaying computer, one or more types of Internet access points may be used. Some relaying computers 220 use a Wi-Fi link to communicate with a Wi-Fi Internet access point 230, whereas other relaying computers 221 can use a cellular connection to communicate with a cellular Internet access point 231. In any case, the relaying computer uses Wi-Fi when communicating with other installed devices and other relaying computers. Some relaying computers can use multiple types of access points. For example, a smartphone may be able to use either Wi-Fi or cellular to access the Internet, and it may even switch between one type or the other based on prevailing conditions and user settings. It is apparent that there are other possible means for relaying computers to connect to Internet access points, such as via satellite, via wired connection, or other possibilities.

At some point, the forwarded message will reach an Internet access point 230, 231. Internet access points are associated with Open Internet Portals or Captive Internet Portals, and are thus capable of providing real-time, general Internet access. Both relaying computers 220 and installed devices 210 can connect directly to a Wi-Fi Internet access point 230 and forward messages onto the Internet 240. These Wi-Fi Internet access points may have Wi-Fi links which are either public or private. If the Wi-Fi access point's link is private, then the device or relaying computers must have the required authentication object in advance.

Fig. 3. illustrates the Wi-Fi modes and initial communications that are used by a first node 310 communicating with a nearby node 320,330,340,350 over a Wi-Fi link. The first node 310 may be either an installed device or a relaying computer. However, when the nearby node is a local Wi-Fi interface 350, then the first node 310 is most likely an installed device. There are several steps that occur prior to exchanging actual data between the nodes. First, one node broadcasts its presence so that the other node can discover it. Second, the two nodes enter compatible Wi-Fi modes. Third, a Wi-Fi link between the nodes is established. Finally, the nodes engage, if needed, in any other setup communications over the Wi-Fi link to decide items like network address assignment and message routing direction.

If the nearby node is a typical wireless Internet access point 320, then it will operate in

infrastructure access point mode and broadcast 321 an available Wi-Fi access point. The first node sees this, places itself into the compatible client station mode, and connects to the access point. Once connected, the first node runs a DHCP client to request 322 an IP address from the Internet access point's DHCP server. After retrieving an IP address, the first node attempts to send its data 323 to a central server using standard Internet protocols. More details on the interaction between a first node and an Internet access point are presented in Fig. 5.

If the nearby node is a second device 330 then the two nodes automatically form a mesh network when in vicinity of each other by participating in the same Wi-Fi ad-hoc network. In ad-hoc mode, all nodes broadcast 331 the availability of the ad-hoc network. The first node recognizes the nearby node as a second device and places itself in ad-hoc mode as well, such that it is able to join the same ad-hoc network. Ad-hoc mode is convenient because as a peer-based, master-less network, it is less susceptible to the disappearance of a single node. In an alternative embodiment, nodes may communicate in a different mode and the first node would then place itself in a corresponding compatible mode to enable communication. In any case, once a Wi-Fi link is formed the nodes exchange 332 quality of service information so they can each determine their counterpart's suitability for relaying messages. This quality of service information includes whether a node has a current path to the Internet, the wireless signal strengths between nodes in that path, how much time has elapsed since a current path was available, or other such relevant information. The data messages can then be sent 333 to the best node in either direction.

If the nearby node is a relaying computer 340, then the capabilities of the relaying computer can become a limiting factor. Some relaying computers are limited to supporting only certain Wi-Fi modes. For example, many smartphones are not capable of joining an ad-hoc network or forming an access point. Other times these modes are allowed, but are partially crippled. For example, some smartphones can create and broadcast an access point, but cannot modify the SS ID (broadcast name), or can choose a broadcast name, but cannot exchange any data with client stations even if they connect. Some recent smartphones have the ability to form an access point when operating in Wi-Fi Direct mode, however, they may do so in a manner that is not conducive to automatic operation. For example, they may require a user to accept system pop-ups or other intrusive alerts every time before a Wi-Fi link is established or re-established. Since the relaying computer is most likely to most fully support client station mode, the first node 310 preferably enters access point mode and broadcasts 341 an access point. The relaying computer joins the broadcast access point and makes a DHCP request 342 for a local address to a DHCP server running on the first node. After sending the assigned IP address, the first node can then forward 343 message data to the relaying computer using any agreed upon protocol. The relaying computer may even poll the first node for available messages.

The above preferred approach requires the first node to initiate the process by broadcasting its access point to check for available relaying devices, either periodically or based on conditions such as vehicle ignition state. However, sometimes it is desirable for the relaying computer to initiate the process and signal the first node that the relaying computer is present, or sometimes the first mode is itself a relaying computer that is incapable of adequately broadcasting the access point. In these situations, alternative Wi-Fi modes such as a Wi-Fi Direct negotiation may be used if they are supported by both nodes. A local Wi-Fi interface 350 often has the same capability limitations as a relaying computer with regard to the Wi-Fi modes it can support. For example, the same smartphone may be both a relaying computer and a local Wi-Fi interface, depending on the software installed or the functionality selected by the owner. However, with a local Wi-Fi interface, there is usually a person present who can initiate the process. This person can press a physical button on the first node, or if the first node is an installed device that is not easily accessible, the person can change the ignition or key-on state of the vehicle according to a specific pattern.

This initiation causes the first node to broadcast 351 an access point to which the local Wi-Fi interface 350 connects. The local Wi-Fi interface then requests an IP address by sending 352 a DHCP request to a DHCP server on the first node. The DHCP response also includes the address for a DNS server that is running on the first node. Using a standard web-browser on the local Wi-Fi interface, the user can navigate to URL, which results in a DNS request being sent 353 to the first node. The first node responds with its own IP address. The browser software then makes 354 an HTTP request to an HTTP server running on the first node and retrieves a web page for display to the user. The use of DNS and HTTP allows a highly universal solution since many potential local Wi-Fi interfaces have pre-installed web browsers and are optimized for web-based access.

Obviously, if a user enters an IP address for the URL, then the DNS component is not needed, although entering an IP address is less convenient for the user. For even more convenience, the user might also run a custom application on the local Wi-Fi interface which could centralize and automate certain tasks.

Fig. 4 illustrates a flow diagram of steps implemented inside an installed device or relaying computer to identify and choose compatible Wi-Fi nodes to communicate with. A compatible Wi-Fi node may be either an Internet access point, or an intermediate node like another installed device or another relaying computer. The steps described in Figure 4 may be performed equally well by either an installed device or a relaying computer, however, for the sake of clarity, they will be described here as if they are performed by a device. First, the device scans for Wi-Fi nodes that are available within wireless range. These Wi-Fi nodes may be broadcasting an infrastructure access point, an ad-hoc network, or a Wi-Fi Direct capability. After scanning for Wi-Fi nodes, the device first checks each scanned node 401 to determine 410 if it represents a potential installed device. In the preferred embodiment, this determination is based on whether the scanned node is an ad-hoc network of a known name. Alternatively, if devices communicate with each other in a mode other than ad-hoc mode, then this determination could be made based on an advertised Wi-Fi Direct services or, based on matching all or part of the SS id (name) or BSS id of a broadcast Wi-Fi access point. If the scanned node does not appear to be an installed device, then the device will check the scanned node to determine 411 if it represents a potential relaying computer. This is preferably done in a manner similarly to the installed device check 410, by comparing the scanned node's access point or ad-hoc network name to a known pattern, or by examining advertised Wi-Fi Direct services.

If the first device suspects that the scanned node represents an intermediate node (either an installed device or a relaying computer), then the first device will consider 420 whether or not it needs to change its own mode in order to communicate with the intermediate node. Changing modes too often can be detrimental since it could interrupt the device's capability to communicate with other nodes. For example, a device may already be a member of the same ad-hoc network and may not need to make any mode changes to communicate with an intermediate node. In this case 440, the device would choose it 450, since no mode changes need be taken. In other cases a device may be in a different mode and will consider whether 441 it has recently communicated with the intermediate node. If there was no recent communication, then the device would chose 450 to connect to the intermediate node now, otherwise, it may decide to ignore this scanned node for now and consider 480 the next scanned node.

If the scanned node 401 was not recognized 410 as a potential installed device, and was not recognized 411 as a potential relaying computer, then the device will determine whether it is a potentially compatible Internet access point by first checking 412 whether the node is broadcasting in Wi-Fi access point mode. If it is, then the device checks 460 whether the device has any pending server-terminated messages (messages that need to be sent to the central servers). If not, then the device may ignore this scanned node and proceed 480 to the next one. Unlike an intermediate node, an Internet access point will not itself have any messages for the device that need to be forwarded to the central servers, and so a device only needs to communicate with this type of node when the device wants to communicate with the central servers. Of course, a device will usually try to communicate with the central servers regularly to let the servers know it is functioning properly and check for any commands the servers may have for it.

If the scanned node is a Wi-Fi access point and the device does have messages to send, then the device will use 461 the node's broadcast SS id (name) and BSS id to look up the node in a list. This list contains the authentication objects and instructions for obtaining Internet access from a Captive Internet Portal, if any, for each listed node. In any case, if the access point appears in the known list, then the device assumes that the Wi-Fi access point is a compatible Internet access point and chooses it 470. Otherwise, the device checks 462 if the scanned node appears to be a public Wi-Fi access point. If it appears public, then the Wi-Fi access point still potentially represents a compatible Internet access point and the device chooses it 470. Otherwise the device ignores this scanned node and considers 480 the next one. In the preferred embodiment, there are other considerations not illustrated that can also prevent a device from choosing a Wi-Fi access point, such as a minimum signal strength threshold, and a back-off algorithm to enforce a minimum time between attempts. Fig. 5 illustrates a flow diagram of steps implemented inside an installed device or relaying computer once it chooses to attempt communication with a central server over a potential Internet access point. The chosen Wi-Fi access point node may be public or private. The associated Internet portal may be an Open Internet Portal or a Captive Internet Portal. The steps described in Fig. 5 may be performed equally well by either an installed device or a relaying computer, however, for the sake of clarity, they will be described here as if they are performed by a device.

The device has at this point chosen 501 a Wi-Fi access point to attempt from the nodes which are within wireless range. The access point may have been chosen because it was successfully used in the past, or because it appears on a user furnished list, or because it is a public Wi-Fi access point that might provide Internet access. The device does not yet know, and so will attempt to determine, whether the access point is associated with an Open Internet Portal, a Captive Internet Portal, or has no discernible Internet portal. To do so, first the device determines 502 if an authentication object is required. It determines this based on what the access point is advertising, as well as from matching access point identifying characteristics such as the BSS id and SS id, to an internal list. Note that the list must be consulted, because some authentication objects, like specific MAC addresses on the client, may be required even if the access point is advertising as public. If no authentication is required, then the device just associates 503 to the access point, otherwise it associates and authenticates 504 with the authentication object from the internal list. If the Wi-Fi access point was advertising that it requires authentication and no authentication object was present in the internal list, then the device would not have chosen the access point.

The device then checks 510 if the association was successful. If not, then the device is finished 570 with the attempt. In this case, the access point is added to a list that makes another attempt less likely, and other available access points will be favored in the future. For certain types of failures, the device will preferably remember it and later notify the central server of the failure. For instance, if a user-entered password for the Wi-Fi access point was incorrect, then the device will notify a central server at the next opportunity, so a user could be informed and correct it. If, however, the association was successful, then the device will try to send 520 a message to a central server. If the device receives a response and can verify 521 that the response is from the server, then the device will process 565 the response. At this point the message will be marked or removed so that the same message is not sent again, the access point will be remembered on an internal list, and any embedded commands in the response from the server will be executed. The device may then send additional messages using this access point, or it may finish 570 this attempt. If, however, a response 521 was never received from the central server, then the device will next check to see if this access point is running a Captive Internet Portal that is blocking general Internet access.

Captive Internet Portals may operate is several ways. To release from the Captive Internet Portal and obtain general Internet access, the node might need to supply a password, supply user contact information, wait a period of time, or acknowledge agreement to terms of service. The device first must recognize that it is talking to a Captive Internet Portal, and second, identifies and performs the correct release procedure. In the preferred implementation, when the device sends a message to the central server 520 over a new Wi-Fi access point, it tries to send the message using HTTP to port 80 on the central server. This will engage the Captive Internet Portal to deliver a response.

Alternatively, if a different protocol or port was used, the device may attempt to connect using HTTP to port 80 now. In any case, if the device is behind a Captive Internet Portal, the device will not be able to verify a response 521 as originating from the central server until after the release procedure is performed.

If the device receives an HTTP redirect 522, it is likely talking to a Captive Internet Portal which uses HTTP redirection, since the real central servers preferably will not ever send redirects. The device can follow the redirect 541 to obtain a response, which may help identify the Captive Internet Portal and the required release procedure. If no HTTP redirect is received, then the device checks if it received some other, unanticipated HTTP response which does not appear to be the central server 523. Again, preferably, the central server plainly identifies itself in every response to make this distinction straightforward. If the device received any response, then it is likely talking to a Captive Internet Portal which uses IP redirection and the device will use this response to help identify the Captive Internet Portal. If no response of any kind is received, then the device will check for DNS poisoning by performing 530 a DNS lookup on an address that should always return an expected response. If a different response is obtained from the DNS lookup than that which is expected, then the DNS has been poisoned 531, and the device can follow the results of the DNS lookup by making an HTTP request to the returned DNS address on port 80 to receive a response that will help identify the Captive Internet Portal. If no DNS lookup results are obtained, then the device is finished with this attempt, having been unable to communicate with the server through an Open Internet Portal and unable to retrieve a response from a Captive Internet Portal. There may be other ways that Captive Internet Portals might operate now or in the future, and one skilled in the art will see that similarly fashioned additional tests may be added to accommodate such Captive Internet Portals. At this point, if the device has obtained, by any of the above means, a response that it believes is from a Captive Internet Portal, then it will check the response to see if it can recognize 550 the portal and identify a known release procedure. Recognition could occur by keyword search in the response, by a hash of the response, by looking up the BSS id or SS id of the Wi-Fi network in an internal table, or by another method. If the Captive Internet Portal response is not recognized, the response is saved 551 and will be returned to the central server at a later time, where it can be reviewed. If the Captive Internet Portal is recognized and a release procedure is known, then the release procedure is performed 560 now. The release procedure may be multiple steps and may involve verifying terms of service has not changed and accepting said terms of service, submitting authentication credentials, submitting user contact information, following specific URL links, waiting a specified time before making another request, or some combination thereof. Part of the release procedure also indicates the expected results at each step, so that the device can confirm 561 it is being performed properly. If at any point an unexpected response it returned, then the device will save 551 the response and the attempt is finished 570. In this way, release procedure instructions can be sent to the device one step at a time, each time the device will move one step further and save the result, returning the results to the central server at some point later and receiving the next step after the result is reviewed. Once the release procedure is confirmed by the device to have been performed correctly, the device will have access to the general Internet, and will attempt to send 520 the message to the central server again. If no response is received from the central server, then the access point will preferably be placed on a list which imposes time-limits or other conditions before the access point may be attempted again.

Fig. 6 illustrates a flow diagram of steps implemented inside an installed device or relaying computer once it chooses to attempt communication with a potential intermediate node. An intermediate node may be a second device or second relaying computer. The intermediate node's associated Internet portal may be a Limited Internet Portal or an Asynchronous Internet Portal. The steps described in Fig. 6 may be performed equally well by either an installed device or a relaying computer, however, for the sake of clarity, they will be described here as if they are performed by a device.

After an intermediate node is chosen 601, the device will either associate 610 to the Wi-Fi access point, join 611 an ad-hoc network, start 612 its own Wi-Fi access point, or negotiate 613 with the intermediate node for Wi-Fi direct access. The precise action taken depends on what mode the intermediate node is broadcasting in; or may also include a preferred mode that is encoded within the name of the broadcast access point, network, or service. Some nodes may not be capable of any broadcasts prior to associating to an existing access point, in which case the device will start 612 its own access point as a default.

The intermediate node then responds, if needed depending on the mode, by associating, joining or negotiating. Once completed, a Wi-Fi link will have been established between the device and the intermediate node, and they can exchange 620 quality of service information. The quality of service information will tell the receiving node whether or not the transmitting node is running a Limited Internet Portal with a real-time path to the Internet, or is running an Asynchronous Internet Portal without a current Internet path. It also contains additional information about the quality or history of these paths which enables each receiving node to compare the transmitting node's path to the receiving node's own path and independently decide whether a threshold is met for forwarding its held messages.

Once sufficient quality of service information is received, the device will then check 630 if it has any pending messages which are destined for a central server (server-terminated messages). These server-terminated messages may have been generated by the current device, or they may have originated from other devices having been subsequently forwarded to this current device. If such messages exist, the device will consider 640 whether the intermediate node is advertising a live path to the Internet. If a live path exists, then the device will send 650 its messages to the intermediate node for immediate relaying to the central servers, and wait to process 660 a response from the servers. If the response is successful, the messages will be marked or removed so that they will not be attempted again, and the device may attempt additional pending server-terminated messages now. If the response was not successful, the device implements a back-off algorithm so messages will not be attempted again right away unless there is a noticeable improvement in the quality of service information received.

If no live path to the Internet existed, then the intermediate node may still be running an

Asynchronous Internet Portal, which means it is offering to hold the device's messages and forward them to the Internet later on the device's behalf. The device determines whether or not to accept this offer based on the quality of service information it received. If 641 the intermediate node has a reasonable likelihood of accessing the Internet before the device does, as determined by the intermediate node having a sufficiently higher rating on the quality of service information, then the device will attempt to forward 651 its pending server-terminated messages to the other node.

Because there is no live path to the Internet, the device only expects a response from the other node, and not from a central server. When processing 661 this acknowledgment, a back-off algorithm is still implemented if an unexpected response, or lack of a response, is detected. However, the pending messages are not removed and are still stored so they may be sent again later if needed, perhaps to different intermediate nodes. After the device has finished handling server terminated messages 660, 661, or, if there was no nodes available with a sufficiently higher rated path 641 to the Internet , then the device will consider 631 if it has pending mobile-terminated messages. Mobile-terminated messages are destined for other devices, and may be commands or acknowledgments from the central servers. The device checks 642 for a known path to the destination devices, which it garners based on the quality of service information it received. If a path is found, the device attempts to forward pending messages to the other device now, and will process 662 the acknowledgment from the other device. Again, if a failure is detected or no acknowledgment is received, then a back-off algorithm is entered. On the other hand, if delivery was successful then the mobile terminated messages is marked and removed accordingly. If the time-to-live expires and the device has still not delivered the mobile terminated messages, then it is removed.

If the device does not have 631 any mobile terminated messages to send, or does not have 642 any known path to the destination devices of those messages, then it waits 670 a predetermined amount of time to receive server-terminated or mobile-terminated messages from other devices, before completing 671 communications with the chosen node.

Additional modifications and improvements of the present invention may also be apparent to those of ordinary skill in the art. The particular combination of parts described and illustrated here is intended to represent only one embodiment of the present invention, and is not intended to serve as limitations of alternatives within the spirit and scope of the invention and the claims.

Claims

What is claimed is:
1. A method for using Wi-Fi to remotely monitor conditions associated with a vehicle, the method comprising the steps of:
a) installing an electronic device into a vehicle such that the vehicle provides the primary source of power for the device;
b) receiving data from a sensor that monitors a condition associated with the vehicle;
c) establishing a first Wi-Fi link between the device and a first Wi-Fi node that is within wireless range of the device;
d) sending data through the first Wi-Fi node's associated Internet portal to a publicly routable Internet address, wherein the sent data is derived from the sensor and the type of the first Wi-Fi node's associated Internet portal is one from the group consisting of an Open Internet Portal, a Captive Internet Portal, a Limited Internet Portal, and an Asynchronous Internet Portal;
e) establishing a second Wi-Fi link between the device and a second Wi-Fi node that is within wireless range of the device;
f) sending data through the second Wi-Fi node's associated Internet portal to a publicly routable Internet address, wherein the sent data is derived from the sensor and the type of the second Wi-Fi node's associated Internet portal is different than the type of the first Wi-Fi node's associated Internet portal and the type of the second Wi-Fi node's associated Internet portal is one from the group consisting of an Open Internet Portal, a Captive Internet Portal, a Limited Internet Portal, and an Asynchronous Internet Portal.
2. The method of claim 1 further comprising the additional step of affixing the device to the vehicle such that the device cannot properly be removed without the use of a tool.
3. The method of claim 1 wherein the installing of the electronic device is effectuated during the vehicle manufacturing process.
4. The method of claim 1 further comprising the additional step of remotely determining whether the device has, subsequent to the installation, stopped receiving data from the sensor.
5. The method of claim 1 further comprising the additional step of remotely determining whether the device has, subsequent to the installation, stopped sending sensor-derived data through the Internet.
1
6. The method of claim 1 further comprising the additional step of encrypting sensor-derived data with a secret key that is not publicly available.
7. The method of claim 1 further comprising the additional step of creating authentication information for sensor-derived data wherein the authentication information makes use of a secret key which is not publicly available and wherein the authentication information enables verification of the source and integrity of the sensor-derived data.
8. The method of claim 1 further comprising the additional steps of:
a) establishing a third Wi-Fi link between the device and a third Wi-Fi node that is within wireless range of the device;
b) sending data through the third Wi-Fi node's associated Internet portal to a publicly routable Internet address, wherein the sent data is derived from the sensor and the type of the third
Wi-Fi node's associated Internet portal is different than the type of both the first and second Wi-Fi nodes' associated Internet portals and the type of the third Wi-Fi node's associated Internet portal is one from the group consisting of an Open Internet Portal, a Captive Internet Portal, a Limited
Internet Portal, and an Asynchronous Internet Portal.
9. The method of claim 8 further comprising the additional steps of:
a) establishing a fourth Wi-Fi link between the device and a fourth Wi-Fi node that is within wireless range of the device;
b) sending data through the fourth Wi-Fi node's associated Internet portal to a publicly routable Internet address, wherein the sent data is derived from the sensor and the type of the fourth Wi-Fi node's associated Internet portal is different than the type of the first, second, and third Wi-Fi nodes' associated Internet portals.
10. A method for using Wi-Fi to remotely monitor conditions associated with a vehicle, the method comprising the steps of:
a) installing a first electronic device into a vehicle such that the vehicle provides the primary source of power for the device;
b) receiving data from a sensor that monitors a condition associated with the vehicle;
c) establishing a first Wi-Fi link between the first device and a first node that is within wireless range of the first device, wherein the type of the first node is selected one from the group consisting of an installed device, a relaying computer, and an Internet access point;
2 d) sending sensor-derived data through the first node to a publicly routable Internet address; e) establishing a second Wi-Fi link between the first device and a second node that is within wireless range of the first device, wherein the type of the second node is different than the type of the first node, and the type of the second node is selected one from the group consisting of a an installed device, a relaying computer, and an Internet access point;
f) sending sensor-derived data through the second node to a publicly routable Internet address.
11. The method of claim 10 further comprising the additional step of affixing the device to the vehicle such that the device cannot properly be removed without the use of a tool.
12. The method of claim 10 wherein the installing of the electronic device is effectuated during the vehicle manufacturing process.
13. The method of claim 10 further comprising the additional step of remotely determining whether the device has, subsequent to the installation, stopped receiving data from the sensor.
14. The method of claim 10 further comprising the additional step of remotely determining whether the device has, subsequent to the installation, stopped sending sensor-derived data through the Internet.
15. The method of claim 10 further comprising the additional step of encrypting sensor-derived data with a secret key that is not publicly available.
16. The method of claim 10 further comprising the additional step of creating authentication information for sensor-derived data wherein the authentication information makes use of a secret key which is not publicly available and wherein the authentication information enables verification of the source and integrity of the sensor-derived data.
17. The method of claim 10 further comprising the additional steps of:
a) establishing a third Wi-Fi link between the first device and a third node that is within wireless range of the first device, wherein the type of the third node is different than the types of the first and second nodes;
b) sending sensor-derived data through the third node to a publicly routable Internet address.
3
18. A system for remotely monitoring conditions associated with a vehicle and relaying said conditions over Wi-Fi to the Internet, comprising:
a) a plurality of vehicles;
b) a plurality of sensors, wherein each sensor monitors a condition associated with a vehicle; c) a plurality of installed devices, wherein each installed device incorporates a Wi-Fi transceiver and each installed device is installed in a vehicle and each installed device receives power primarily from the vehicle in which it is installed and each installed device receives data from at least one sensor and each installed device is not an Internet access point;
d) a plurality of relaying computers, wherein each relaying computer incorporates a Wi-Fi transceiver and each relaying computer is not primarily powered by a vehicle and each relaying computer is not an Internet access point;
e) a plurality of Internet access points;
wherein an installed device is capable of using its Wi-Fi transceiver to transmit sensor- derived data through an Internet access point to a publicly routable Internet address;
wherein an installed device is capable of using its Wi-Fi transceiver to transmit sensor- derived data to a relaying computer;
wherein a relaying computer is capable of receiving data from an installed device and sending the received data through an Internet access point to a publicly routable Internet address.
19. The system of claim 18 wherein an installed device is capable of using its Wi-Fi transceiver to transmit sensor-derived data to installed devices and to receive sensor-derived data from installed devices.
20. The system of claim 18 wherein a relaying computer is capable of using its Wi-Fi transceiver to transmit data received from an installed device to other relaying computers.
4
PCT/US2013/074844 2012-12-14 2013-12-13 Expanded wi-fi coverage for vehicular telematics WO2014093734A1 (en)

Priority Applications (4)

Application Number Priority Date Filing Date Title
US201261797736P true 2012-12-14 2012-12-14
US61/797,736 2012-12-14
US201361785005P true 2013-03-14 2013-03-14
US61/785,005 2013-03-14

Publications (1)

Publication Number Publication Date
WO2014093734A1 true WO2014093734A1 (en) 2014-06-19

Family

ID=50934975

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2013/074844 WO2014093734A1 (en) 2012-12-14 2013-12-13 Expanded wi-fi coverage for vehicular telematics

Country Status (1)

Country Link
WO (1) WO2014093734A1 (en)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080214179A1 (en) * 2002-05-16 2008-09-04 Tolhurst William A System and method for dynamically configuring wireless network geographic coverage or service levels
US20110231546A1 (en) * 1997-08-26 2011-09-22 Nathanson Martin D Automotive telemetry protocol
US20120089299A1 (en) * 1999-12-15 2012-04-12 Automotive Technologies International, Inc. Wireless transmission system for vehicular component control and monitoring
US20120209634A1 (en) * 1996-01-29 2012-08-16 Progressive Casualty Insurance Company Vehicle monitoring system
US20120244883A1 (en) * 2009-07-21 2012-09-27 Scott Ferrill Tibbitts Method and system for controlling a mobile communication device in a moving vehicle

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120209634A1 (en) * 1996-01-29 2012-08-16 Progressive Casualty Insurance Company Vehicle monitoring system
US20110231546A1 (en) * 1997-08-26 2011-09-22 Nathanson Martin D Automotive telemetry protocol
US20120089299A1 (en) * 1999-12-15 2012-04-12 Automotive Technologies International, Inc. Wireless transmission system for vehicular component control and monitoring
US20080214179A1 (en) * 2002-05-16 2008-09-04 Tolhurst William A System and method for dynamically configuring wireless network geographic coverage or service levels
US20120244883A1 (en) * 2009-07-21 2012-09-27 Scott Ferrill Tibbitts Method and system for controlling a mobile communication device in a moving vehicle

Similar Documents

Publication Publication Date Title
US10327228B2 (en) Scalable WLAN gateway
US8825767B2 (en) Scalable secure wireless interaction enabling methods, system and framework
KR101323358B1 (en) Methods and apparatus to register with external networks in wireless network environments
JP4878717B2 (en) Selectively method and apparatus for accessing a network
US9036603B2 (en) Network assistance for device-to-device discovery
RU2513677C1 (en) Communication device, communication method therefor and computer-readable data storage
US6879584B2 (en) Communication services through multiple service providers
US8625461B2 (en) Mobile WLAN gateway
CA2530340C (en) Server for routing connection to client machine
CN1802839B (en) Method and apparatus for providing network service information to a mobile station by a wireless local area network
JP5208520B2 (en) Voice channel control of a wireless packet data communication
KR101586089B1 (en) A wireless network connection system and method and that device using the close range communications
KR101120628B1 (en) Method, system, and apparatus for processing service message with a plurality of terminals
RU2304856C2 (en) Method and system, meant for setting up a connection via access network
US7386296B2 (en) Controlling and enhancing handoff between wireless access points
EP2304902B1 (en) Network discovery and selection
RU2406252C2 (en) Method and system for providing secure communication using cellular network for multiple special communication devices
US7693516B2 (en) Method and system for enhanced communications between a wireless terminal and access point
KR101005212B1 (en) Support for integrated wlan hotspot clients
KR100695242B1 (en) The method for connecting devices in dynamic family networking
KR101697414B1 (en) Shared network access via a peer-to-peer link
KR100711957B1 (en) Radio terminal session control and interface set up method
US20040059914A1 (en) Using signal-generated location information to identify and authenticate available devices
US7218930B2 (en) Automatic recognition system for use in a wireless local area network (LAN)
WO2007044969A2 (en) Architecture that manages access between a mobile communications device and an ip network

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 13862399

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase in:

Ref country code: DE

122 Ep: pct app. not ent. europ. phase

Ref document number: 13862399

Country of ref document: EP

Kind code of ref document: A1