Classifications

• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04W—WIRELESS COMMUNICATION NETWORKS
  • H04W36/00—Hand-off or reselection arrangements
  • H04W36/0005—Control or signalling for completing the hand-off
  • H04W36/0011—Control or signalling for completing the hand-off for data sessions of end-to-end connection
  • H04W36/0033—Control or signalling for completing the hand-off for data sessions of end-to-end connection with transfer of context information
  • H04W36/0038—Control or signalling for completing the hand-off for data sessions of end-to-end connection with transfer of context information of security context information
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04W—WIRELESS COMMUNICATION NETWORKS
  • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
  • H04W12/06—Authentication
  • H04W12/062—Pre-authentication
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04W—WIRELESS COMMUNICATION NETWORKS
  • H04W36/00—Hand-off or reselection arrangements
  • H04W36/14—Reselecting a network or an air interface
  • H04W36/144—Reselecting a network or an air interface over a different radio air interface technology
  • H04W36/1446—Reselecting a network or an air interface over a different radio air interface technology wherein at least one of the networks is unlicensed
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04W—WIRELESS COMMUNICATION NETWORKS
  • H04W84/00—Network topologies
  • H04W84/02—Hierarchically pre-organised networks, e.g. paging networks, cellular networks, WLAN [Wireless Local Area Network] or WLL [Wireless Local Loop]

Definitions

• the methods and systems described herein generally relate to wireless device network authentication and particularly relate to passive device and user identification for wireless network transition.
• MAC address 12 octet field
• Every packet that is transmitted wirelessly consists of a MAC header that includes the source and/or the intended destination device's MAC address. These packets are absorbed by all radio devices, where the MAC sub-layer checks the MAC address field and then either discards or passes the packet onto higher data link layers for further processing.
• MAC addresses are often "hard-coded" onto connectivity chips and irreversible but newer radio chips allow the MAC address to be changed through software. This has allowed use of anonymous MAC addresses for the purposes of protecting identity, to change the MAC information in packets or using a lookup table or some other method for intelligent packet routing using multiple MAC addresses, assignment of MAC addresses on a network to each device to prevent MAC address duplication and for the cloning of one device's MAC address onto another device.
• data transmitted in wireless packets may be encrypted if it is a secure network
• MAC addresses are not encrypted as they are used to filter the packet's destination before any further processing takes place.
• device driver software By modifying device driver software, it is possible to accept all incoming packets regardless of the MAC address specified in the MAC header. This allows a roaming radio device with modified device driver software to listen for wireless packets, check their MAC headers and identify the MAC addresses of other radio devices in its proximity without the knowledge or prior authorization of the device's owner.
• a voice/data payload transition (“handof ' or "handover") from a primary, automatically authenticated (no end user interaction required) wide area radio access network such as the networks of cellular towers (base transceiver stations) operated by mobile carriers to secondary, user-initiated, open/secure (free, conditional, or for- pay) destination wireless networks.
• the latter include a variety of wireless wide, regional and local area networks (WANs, WRANs and WLANs respectively) with the most commercially adopted being WLANs based on the IEEE 802.11 standards operating in unlicensed radio frequency spectrum, commonly referred to as Wi-Fi.
• the end-user often has to enter a service-set identifier or SSID (for hidden Wi-Fi networks) or pick an SSID from a list of broadcasted SSIDs. If the destination network is a secure one, the end-user may also be required to manually provide a key for authentication as well.
• SSID service-set identifier
• the end-user may also be required to manually provide a key for authentication as well.
• GAN generic access network
• Wi-Fi networks have been established to advertise information on Wi-Fi networks so that end-users can choose the networks that they have access privileges to i.e. Wi-Fi networks offered by the third-parties such as a non-primary, foreign or "roaming partner" mobile network operators.
• the methods and systems described herein may create a transformed MAC address using a remotely assigned key for the purposes of wireless packet transmission which may or may not be stored locally.
• a remotely assigned key for the purposes of wireless packet transmission which may or may not be stored locally.
• the transformed MAC address may change over time; thereby making the transmitted MAC address dynamic so that MAC addresses received by a given radio access network may be dispensable periodically (e.g. hourly, daily, etc.). Since the transformation may only be done locally at the point of transmission any other uses for the MAC address such as packet routing can still be accomplished once the MAC address in the header has been reverse transformed.
• the transformed MAC address can also be used as a device specific identifier (DSI) as described herein.
• DSI device specific identifier
• the methods and systems described herein may circumvent the need for the end-user to manually authenticate even a first connection to a new destination radio access network by causing the end-user's mobile device to automatically emit a unique device-specific identifier (DSI) that can be passively absorbed by the WLAN with software that can detect it.
• DSI device-specific identifier
• This process is also referred to as presence or passive presence herein.
• the DSI of the end-user's mobile device, along with an identifier for the WLAN is passed on to a modified Generic Access Network Controller that can seamlessly absorb this information and then authenticate the user on the WLAN operated by either the mobile network operators or their independent, third-party WLAN network operator partners.
• the proposed invention also has the additional benefit of being resistant to user-modifications on the client device since each device is uniquely identified. Additionally software placed in the modified access points can allow for simultaneous network connections using existing protocols and methods as well as existing protocols and methods for the purposes of seamless handover enabled herein.
• transitioning between mobile network operator WANs has been an easier and more consistent end-user experience due to the best practices established by large mobile network operators (i.e transitioning from a "home" cellular network to a "roaming" network).
• the methods and systems described herein may utilize automatically emitted and passively absorbed device specific identifiers to enable a simplified and seamless end-user experience for transitioning between any two incongruent radio access networks.
• the enclosed methods and systems can also be an alternative method to enable seamless transitioning between two WANs (i.e. a "home” cellular network to a "roaming" network).
• the methods and systems described herein also provide a more feasible alternative for providing network access to end-user devices in areas with low WAN signal (e.g. cellular) or no access to mobile-carrier WANs.
• the proposed invention can leverage other existing wireless network hardware where available by modifying existing software resident on said hardware.
• existing solutions such as femtocells (also commercially referred to as “small cells” and “picocells"), which are mobile network operator-specific as they utilize each mobile network operator's unique radio frequency spectrum and corresponding radio access network interface, in the proposed invention, is in many situations, a more suitable alternative as it provides access on unlicensed radio spectrums available to a wider range of end user devices and with the passive transition benefits of femtocells.
• a device transitioning from a cellular base station transceiver to a femtocell can only make the transition if the radio access network interface of the end user's mobile device and the radio access network interface of the femtocell have common hardware and software and operate on the same licensed frequency (the last being a proxy for determining the first factor of authentication for which mobile network operator the device has access rights for).
• This means the seamless handover can only be realized if the femtocell or other secondary radio access network mimic's the primary network's radio access interface.
• the proposed invention enables a mobile device belonging to a primary mobile network to seamlessly transition to a secondary mobile network that has fundamentally incongruent properties including operating on licensed/unlicensed frequencies, having a different hardware/software network interface for radio access, etc.
• the most common of this type of transition would be used to transition a mobile device from a mobile network operator's radio access network comprised largely of cellular base station transceivers over to a WLAN (Wi-Fi router)- something that is not possible with existing solutions.
• Methods and systems described herein may include a method of profile-based passive network switching, comprising receiving at a wireless access point a device specific identifier beacon transmitted from a mobile device; extracting a device specific identifier from the beacon; transmitting the device specific identifier and access point provider information to a networked server configured with presence network switching software for determining network switching requirements based on the transmitted device specific identifier; receiving mobile device network switching data from the server; transmitting local wireless network authentication and connection information from the access point to the mobile device to facilitate activating a wireless network connection between the mobile device and the access point; and processing wireless communication from the mobile device over the local wireless network.
• the beacon is transmitted over an 802.11 compliant radio frequency channel.
• the beacon comprises a recipient independent recipient address.
• the local wireless network is unknown to the mobile device prior to the local wireless network transmitting local wireless network authentication and connection information.
• processing wireless communication initiates an initial use of the local wireless network by the mobile device.
• the method may further include in response to receiving the beacon at the access point, transmitting an electronic response over a wireless signal to the mobile device.
• the method may further include determining a signal strength of a radio signal between the mobile device and the access point.
• the method may further include time stamping the received beacon prior to extracting the device specific identifier.
• the access point is adapted to receive and extract a device specific identifier from the beacon.
• the beacon is an emergency beacon based on a high priority field of the beacon being activated.
• the methods and systems described herein may include a method of transferring a call from a cellular network to an IP network based on profile-based passive network switching, comprising: receiving at a wireless access point a device specific identifier beacon from a mobile device engaged in a call over a cellular network; extracting a device specific identifier from the beacon; transmitting the device specific identifier and access point provider information to a networked server configured with presence network switching software for determining cellular network provider call switching requirements based on the transmitted device specific identifier; receiving mobile device call switching data from the server; transmitting local wireless network authentication and connection information from the access point to the mobile device to facilitate activating a local wireless connection between the access point and the mobile device; and facilitating routing of the call through the local wireless network.
• the beacon is transmitted over an 802.11 compliant radio frequency channel.
• the beacon comprises a recipient independent recipient address.
• the local wireless network is unknown to the mobile device prior to the local wireless network transmitting local wireless network authentication and connection information.
• processing wireless communication initiates an initial use of the local wireless network by the mobile device.
• the method may further include in response to receiving the beacon at the access point, transmitting an electronic response over a wireless signal to the mobile device.
• the method may further include determining a signal strength of a radio signal between the mobile device and the access point.
• the method may further include time stamping the received beacon prior to extracting the device specific identifier.
• the access point is adapted to receive and extract a device specific identifier from the beacon.
• routing of the call through the local wireless network includes ending use of the cellular network for the call.
• Methods and systems described herein may include a method of transferring a data flow from a cellular network to an IP network based on profile based passive network switching, comprising: receiving at a wireless access point a device specific identifier beacon from a mobile device using a cellular data network; extracting a device specific identifier from the beacon;
• the device specific identifier and access point provider information transmitting the device specific identifier and access point provider information to a networked server configured with presence network switching software for determining cellular network provider call switching requirements based on the transmitted device specific identifier; receiving mobile device call switching data from the server; transmitting local wireless network authentication and connection information from the access point to the mobile device to facilitate activating a local wireless connection between the access point and the mobile device; and facilitating data network connection of the mobile device via the local wireless network rather than through the cellular data network.
• the methods and systems described herein may include a wireless access point adapted to detect a device specific identifier beacon comprising; a wireless router comprising: MAC layer functionality adapted to identify presence data packets; presence functionality to interface with the adapted MAC layer functionality to send and receive presence data in the packets; and presence client functionality to interface with the presence functionality to communicate the presence data with an externally networked presence server.
• a recipient address of the presence data packets is recipient independent.
• a recipient address of the presence data packets is OxFFFFFFFFFFFFFF.
• the access point performs signal strength detection on a wireless signal comprising the presence data packets.
• the presence functionality of the access point performs signal strength detection.
• the access point timestamps identification of at least a first identified presence data packet.In the access point, the presence functionality of the access point performs the timestamping.
• the beacon is detected over an 802.11 compliant radio frequency channel.
• the methods and systems described herein may include a method of detecting a device specific identifier beacon comprising: receiving a data packet over a wireless signal at an access point, wherein a recipient address of the data packet is recipient independent; forwarding the received data packet from an adapted MAC layer facility of the access point to an presence facility of the access point; extracting, with the presence facility, a device specific identifier from the data packet; and forwarding the extracted device specific identifier along with access point identification data to an externally networked server adapted to perform presence network switching authorization.
• the radio signal is an 802.11 compliant radio frequency channel.
• the method may further include in response to receiving the beacon at the access point, transmitting an electronic response over a wireless signal to the mobile device.
• the device specific identifier comprises a transformed MAC address of a wireless-capable device from which the beacon is received.
• a recipient address of the presence data packets is OxFFFFFFFFFFFF.
• the access point performs signal strength detection on a wireless signal comprising the presence data packets.
• the presence functionality of the access point performs signal strength detection.
• the access point timestamps identification of at least a first identified presence data packet.
• the presence functionality of the access point performs the timestamping.
• the beacon comprises a device specific identifier that was not previously received by the access point.
• the methods and systems described herein may include a mobile handset adapted to generate a device specific identifier beacon comprising; MAC layer functionality adapted to transmit presence beacon packets; and presence functionality to: interface with the adapted MAC layer functionality to configure device specific identifier data into the presence beacon packets; determine a transmission channel for transmitting the beacon packets; determine a beacon transmission interval; and communicate the presence data with an externally networked presence server.
• the presence beacon packets are transmitted over an 802.11 compliant radio frequency channel.
• the device specific identifier comprises a transformed MAC address of the mobile handset.
• a recipient address of the presence data packets is OxFFFFFFFFFFFF.
• the methods and systems described herein may include a method of generating a device specific identifier beacon comprising; taking a MAC address of a mobile device; transforming the MAC address into a device specific identifier with presence firmware operating on the mobile device; determining an presence beacon transmission channel with the presence firmware; transmitting the device specific identifier and the presence beacon transmission channel to adapted MAC layer functionality operating on the mobile device; and transmitting an presence beacon comprising the device specific identifier periodically based on an presence beacon transmission interval.
• the presence transmission interval is determined based on responses to the transmitted presence beacon received by the mobile device.
• transforming the MAC address is based on a remotely assigned key.
• transforming the MAC address comprises byte shifting of the MAC address.
• transforming the MAC address is based on a DHCP lease renewal cycle.
• the methods and systems described herein may include a method of monetizing transition of wireless communication with a handset from a cellular domain to a wifi domain comprising: receiving at a networked server an indication that a mobile device is using a local wireless network as a result of presence passive network switching from a cellular network; determining a cellular network provider for the cellular network based on an analysis of the indication by the server; calculating a value for the mobile device using the local wireless network instead of the cellular network; and charging the cellular network provider for a portion of the calculated value.
• calculating the value is based on cellular network provider specific transition guidelines.
• determining a cellular network provider comprises extracting a device specific identifier of the mobile device from the indication and retrieving cellular network provider identification data from a device profile in a database of device profiles based on the extracted device specific identifier.
• Fig. 1 depicts the major components of a passive network-to-network transition solution, also referred to as the proposed invention or presence framework;
• FIG. 2 depicts elements of the presence framework deployment on a mobile device, such as a personal mobile smart phone;
• FIG. 3 depicts a remote data server for facilitating passive network-to-network transition techniques including reconciling a detected DSI with a device profile; a system that could be utilized through the proposed invention;
• Fig. 4 depicts three exemplary welcome screens showing the use of the presence framework by an application developer to add location based features to a mobile application
• Fig. 5 depicts a screen of a web based application for providing visibility to user activity in a region of presence-detection zones enabled through the proposed invention
• FIGs. 6 and 7 depict an example of a method of transformation of a MAC address and/or a DSI
• FIG. 8 depicts an embodiment of the presence framework provided by the invention.
• Fig. 9 depicts the detailed mechanics of the authentication of a user on the mobile network operator core network
• Fig. 10 shows the steps involved in the authentication of a radio device of a user by the presence framework provided by the invention;
• Fig. 11 depicts exemplary steps for installing a presence enabled application;
• Fig. 12 depicts the exchange of identifiers in the reconciliation process
• Fig. 13 shows an exemplary method used to provide passive WLAN authentication and connection capabilities to a Presence Beaconing Station once it has been identified;
• Fig. 14 shows an exemplary method used to provide passive WLAN Emergency Alert System
• Fig. 15 depicts a proposed format of the Presence Frame
• Fig. 16 depicts a proposed format of Frame Control Field in the Presence Frame Format
• Fig. 17 depicts a proposed frame format for Presence Control frames
• Fig. 18 illustrates the subfields within the Frame Control field of Presence Control frames
• Fig. 19 shows a proposed frame format for DSI Beacon Frame
• Fig. 20 shows a proposed frame format for DSI + Time Stamp Request Beacon Frame
• Fig. 21 shows a proposed frame format for WLAN SSID + Key Beacon Frame
• Fig. 22 shows a proposed frame body format for WLAN SSID + Key Frame
• Fig. 23 shows a proposed frame header format for Frame Body of WLAN SSID + Key
• Fig. 24 depicts the flowchart for SBF Implementation
• Fig. 25 illustrates the modifications needed to existing Wi-Fi Access Point architecture to derive the proposed Presence Enabled Access Point architecture
• Fig. 26 outlines a proposed basic Presence Packet Structure
• Fig. 27 illustrates subfields and possible values within the proposed Presence Frame Control
• Fig. 28 illustrates the modifications needed to existing Wi-Fi architecture on mobile handsets to derive the proposed Presence Enabled Handset Architecture.
• references to an "embodiment” or “embodiments” refer to one or more exemplary and non-limiting embodiments. Also, it is understood that, in all descriptions herein, unless otherwise specified, even when not explicitly being referenced to an "embodiment” or “embodiments” refer to one or more exemplary and non-limiting embodiments.
• Passive device/user profile identification and authentication may be facilitated by a presence platform as described herein so that devices connecting to a wireless network (i.e. Wi-Fi network) may be passively identified and authenticated, without requiring a device user to take any specific action with the mobile device.
• a Presence Enabled Access Point may use any of the methods described herein including methods and systems described herein with a device that emits a unique radio- frequency broadcast or "RF tag" in the form of a device-specific identifier (DSI) beacon.
• RF tag a device-specific identifier
• a given RF tag carrying a DSI is passively detected by such a PAP and subsequently referenced to a database or set of databases in remote servers or data stores to determine access rights for the device.
• the PAP forwards the necessary information (e.g. SSID and WPA/WPA2 authentication key) to the device for it to successfully connect to the radio access network using a proprietary packet format referred to herein as a proposed presence format.
• Techniques described in related applications as noted herein that facilitate associating a user and/or device profile with a MAC address and/or DSI may form the basis for determining access rights for the device.
• Passive transition of a mobile device from a WAN (e.g. cellular) network also may present opportunities for monetizing such a function.
• WAN service providers have a fixed spectrum and limited capacity for servicing mobile devices, yet the demand for capacity is continually increasing. Therefore, a WAN service provider may be willing to pay a fee to off-load capacity demand to another network provider.
• Enterprise-level use of mobile devices, such as for phone calls, could be enhanced by passive transition so that mobile device users may be automatically switched to an enterprise local wireless network (e.g. Wi-Fi) when a user/employee is within an enterprise facility.
• Wi-Fi enterprise local wireless network
• a local wireless network provider may be willing to adapt its networked components as described herein to support the proprietary protocol in return for payment by an enterprise and/or a WAN provider, and the like.
• Passive transition may also be controlled at least in part by a WAN provider.
• a WAN provider may make policies that determine what content or types of communication could be handed over to a local wireless network.
• Such a policy may include improving quality of service by a presence enabled device determining if a local wireless network signal presents an improvement in quality of service over a WAN network signal.
• a WAN e.g. cellular
• a policy may establish a policy that includes a passive transition signal quality threshold that can be used to evaluate a local wireless network signal and thereby determine if transition of data and/or voice is authorized.
• Techniques for transforming a networked device MAC address may benefit access points (e.g. Wi-Fi routers) as well as mobile devices in that a transformed MAC address presented as a DSI within the presence environment may reduce the likelihood that unauthorized third parties could determine physical location and/or other information about the access point and its networked environment. Because only presence enabled devices access beaconed DSI's from other presence enabled devices, security is also enhanced because the presence framework can be configured to limit the applications and/or third parties that can have access to device location-related information.
• a passive network-to-network transition solution herein referred to as the proposed presence solution
• Passive network-to-network device transition is facilitated at least in part by a Presence API (PAPI) that may provide support for software running on a mobile device and in a passive transition server, such as a remote data server.
• the PAPI may facilitate interfacing with third party applications when they are installed or uninstalled on the mobile device and when providing presence awareness to application servers.
• Each application may be identified by an ASI ("Application Specific Identifier") and each subscriber using each application may be identified using an ASUH ("Application Specific User Hash").
• ASI Application Specific Identifier
• ASUH Application Specific User Hash
• the ASUH may only be shared by the application that generated it and presence framework resources. Only presence resources may have access to a mobile device DSI ("Device Specific Identifier”) which may be beaconed by the mobile device.
• Adapted radio-chip firmware in communication with presence software running on a mobile device may enable the mobile device to support the presence platform via a beacon issued from the mobile device that may represent a unique DSI.
• a Presence Enabled Access Point may also be referred to herein as a "location server” that has been adapted to support the proprietary presence protocols and functionality described herein.
• An example presence environment may include a location server or PAP that manages a unique set of LSIs ("Location Specific Identifier") for each defined location which may be manually hard-coded based on geography.
• the location server or PAP may detect and forward detected mobile DSIs, along with the detected LSI, to a distant remote data server for reconciling the detected DSI with one or more device profiles.
• Each location server or PAP may cover an area of up to 70m or more in radius. Multiple location servers or PAPs can be used in conjunction to provide coverage for larger areas.
• Fig. 2 depicts elements of a proposed presence deployment on a mobile device, such as a personal mobile smart phone. These elements may be configured into tiers including a presence application, an application framework, libraries, operating system kernel, and device hardware.
• Fig. 3 depicts a remote data server (RDS) for facilitating passive network-to-network transition techniques described herein that may include reconciling a detected DSI with a device profile.
• the RDS may be a database server that may store and/or process all the DSIs, and the ASUHs linked to each DSI in a subscriber database.
• the RDS may forward the associated reconciled profile along with its location information (derived from the LSI) directly to an application provider server or to a presence application on the mobile device.
• the RDS may also remotely update an encryption key used to generate the DSI on the mobile device as described herein.
• a presence framework may facilitate enabling mobile application developers to passively detect the presence of mobile users through the beaconing and passive detection technique described herein.
• An exemplary use of the Presence API may be to allow mobile application developers and advertisers to bring a smarter, more focused shopping experience to consumers while they are physically present in the retail environment.
• the Presence API may be used by a third party application to retrieve an ASI ("Application Specific Identifier"), which is assigned when the third-party application registers on a remote data server (RDS).
• ASI Application Specific Identifier
• RDS remote data server
• EULA End User License Agreement
• the application may call the installation function on the PAPI and provides it with the ASI and the ASUH.
• the PAPI may then send this information along with the subscriber's mobile device DSI to the RDS.
• the PAPI may also update cached presence data on the subscriber phone with the information associated with the newly registered application and the locations from which it may be requesting or receiving presence data.
• Each application may have its own opt-in requirements allowing a variety of different application providers to gain access to presence data for their desired locations through the proposed presence framework.
• the Presence API may also be used upon application un-installation, or subsequent opt-out.
• the application may provide its ASI to the PAPI, which removes its data from the local subscriber phone cache and instructs the cloud server to remove the corresponding ASUH and ASI from the subscriber's database.
• Fig. 4 depicts three exemplary presence aware welcome screens that could be used by an application developer to add location based features to a mobile application enabled by the presence framework.
• Fig. 5 depicts a screen of a web based application for providing visibility to user activity in a region of presence enabled zones.
• the information captured to generate such a screen may be used to provide additional services enabled by presence awareness.
• the methods and systems of a presence platform may include transformations of device specific MAC addresses for the purpose of providing additional security and avoiding public detection of device physical location (e.g. geolocation) including mobile devices, routers, and the like.
• device physical location e.g. geolocation
• a transformation key is supplied to the mobile device (e.g. to the radio chip, to a processor on the mobile device, and the like) which determines the transformed MAC address being broadcast.
• the key can be used to determine the transformation method from a variety of one to one transformation functions (e.g. preloaded on the chip hardware or firmware, downloaded over the network, and the like) or as a variable for transforming the MAC address, such as by a predetermined one to one transformation function such as a byte shift.
• the transformed MAC address can be changed regularly without having to update the transform key.
• the time factor can be synced with a scheduled DHCP refresh so that all connected devices may change to the new MAC address when it is generated.
• the date can be used to generate the transformed MAC address.
• Another example of generating a transformed MAC address of a mobile phone is to perform a shift of the MAC address data.
• a radio processor chip of a mobile phone may be loaded with a right to left byte shift operation corresponding to a first transform key, a left to right byte shift operation corresponding to a second transform key, a simple byte inversion corresponding to a third transform key, etc.
• the mobile phone can be set to refresh its DHCP table every hour, so the hour of the day would be a suitable MAC address transformation variable.
• the device's MAC address is initially 01 :23:45:67:89:AB (in hexadecimal), and the transform the key is set to indicate right shifting, then from 01 :00 to 01 :59 the transformed MAC address will be B0:12:34:56:78:9A, from 02:00 to 02:59 it will be AB:01 :23:45:67:89.
• This transformation can be done using either firmware on the chip or by using pre-defined logic gates on the chip, and the like.
• Incoming packets will have a reverse transformation, in this case if the key indicates a right to left byte shift, performed on the destination MAC address in the MAC header before being processed by MAC layer provided it is not a reserved MAC header for multicast.
• a radio chip vendor or other third party may be able to accurately reconcile the transformed MAC address being broadcasted to identify the network and its inherent properties.
• the transformed MAC address can also be used as a DSI to provide added functionality to the access point.
• Fig. 8 depicts an example of a deployment environment of the presence framework.
• the presence framework enables a user to seamlessly transition between two incongruent radio access networks by utilizing a device-specific identifier (DSI) which can authenticate the user on the Core Network operated by either the mobile carriers or their independent network operator partners.
• DSI device-specific identifier
• the DSI may be emitted by the mobile device of the user and passively absorbed by the Generic Access Network Controller to authenticate the user and facilitate a connection to destination radio access network without initial user input.
• Fig. 9 depicts the detailed mechanics of the authentication of a user on the mobile network operator core network.
• the mobile device of the user automatically emits a unique device- specific identifier (DSI) that may be passively absorbed by a secondary and incongruent destination radio network access point (e.g. Wi-Fi router).
• DSI unique device-specific identifier
• the DSI of the user mobile device along with an identifier for the secondary destination radio network access point (e.g. Wi-Fi router) is passed on to a modified Generic Access Network Controller that can seamlessly absorb this information and then authenticate the user on the Mobile Network Operator Core Network.
• Fig. 10 depicts the different steps involved in authentication of a radio device of a user by the presence system provided by the invention.
• a device-specific identifier emitted by the radio device is absorbed by the Presence Enabled Access Point.
• the device specific identification request is then sent to remote servers that include collection of components in the Generic Access network controller and Core network responsible for authentication and payload routing.
• the remote servers provide device access privileges.
• SSID and authentication key is then used to provide a secure Wi-Fi authentication.
• An objective of the proposed methods and systems described herein is to first detect devices equipped with radio antennae (e.g. 2.4GHz) as they come within a detectable proximity of one another and subsequently, to facilitate providers of data services (i.e. consumer application developers) with the means of passive authentication and/or service initiation mechanisms on the devices themselves and/or on remote devices/data stores.
• radio antennae e.g. 2.4GHz
• providers of data services i.e. consumer application developers
• Also defined herein are example implementations of the various proprietary wireless frame formats needed to provide these services. This document also includes descriptions of the requirements and procedures to maintain user privacy.
• the techniques by which the proprietary presence protocol permits the operation of IEEE 802.11 compliant devices which coexist on overlapping IEEE 802.11 WLANs.
• ASI Application Specific Identifier
• ASUH Application Specific User Hash: A hash generated specifically for each application on an end user device to allow presence awareness to identify the user to the application provider.
• Beacon Detection Area The area within which two stations can successfully send and/or receive beacons between one another.
• Beaconing Schedule Interval The interval at which beacon frames are emitted from a PBS.
• DAI Device Specific Identifier
• Presence API Interface used by presence enabled applications to receive presence/location data.
• Location Server A device equipped with a Presence Enabled Access Point that has its own Location Specific Identifier (designed for retail locations). This may be an existing Wi-Fi Access Point with the proposed presence invention residing in the form of software.
• LTI Location Specific Identifier
• Presence Enabled Access Point A Wireless Local Area Network Access Point that functions as a Presence Detection Station.
• Presence Beaconing Station A station that has presence beaconing capabilities (usually an end-user device).
• RDS Remote Data Server
• Presence Detection Station Any station that has the capability to process presence beacons and transmit instructions to PBSs.
• WLAN Wireless Local Area Network [00121] WPA WLAN Protected Access
• the proposed proprietary presence wireless protocol has fundamental characteristics that distinguish it from existing wireless communication protocols, leveraging the 2.4GHz or 5GHz unlicensed spectrum such as Bluetooth® and IEEE 802.11 (marketed as Wi-Fi).
• the proposed invention and protocol utilize a very similar physical framework as IEEE 802.11 and as a result, the proposed protocol meets the various regulatory requirements (i.e. FCC) imposed on radio transmissions.
• Presence beacon frames directed to Presence Detection Stations may use a destination independent address (e.g. 00:00:00:00:00:00). This allows normal WLAN APs to ignore transmissions, while allowing any PDS with a different address to receive and process the same packet for reconciliation without and prior to any handshake between the two devices.
• Presence frames may support device-to-device (e.g. station-to-station) detection.
• the proposed presence protocol may not require a Basic Service Set (BSS) to be established for it to function. This allows presence enabled devices to work without a handshaking process and establishing a subsequent data transmission connection such as connections or associations made by Wi-Fi, Bluetooth, or any other device-to-device data transmission protocol.
• BSS Basic Service Set
• the proposed presence protocol also may not require any acknowledgement frames to check for successful data transmission. Since presence beacon frames transmitted by a Presence Beaconing Station (PBS) are not picked up by a PDS when outside of a Beacon Detection Area (BDA), requiring an acknowledgement frame would cause the PBS to transmit repeatedly in certain situations.
• PBS Presence Beaconing Station
• BDA Beacon Detection Area
• the protocol instead relies on a shorter Beaconing Schedule Interval (BSI) when inside a BDA to make up for the possible loss of packets.
• BSI Beaconing Schedule Interval
• the proposed presence protocol will not use either the Bluetooth frequency hopping schemes to avoid interference or implement the complex Carrier Sense Multiple Access/Collision Avoidance (CSMA/CA) schemes for IEEE 802.11 that are necessary for contention. Instead, to avoid interfering with existing traffic on the 2.4GHz or 5GHz frequencies, presence devices may rely on a more fundamental 1 -persistent CSMA mode with no Collision Detection/ Avoidance.
• CSMA/CA Carrier Sense Multiple Access/Collision Avoidance
• the presence framework architecture consists of several components that interact to provide a platform for presence detection and/or authentication.
• the PBS persistently emits beacon frames and when it enters a BDA the beacon frames are absorbed by a PDS.
• the PDS uses instructions it receives from the beacon frame and reconciles the received information in various processes. An overview of such reconciliation is provided here for informative purposes.
• the PDS may send instructions to the PBS to affect its transmission behavior. It may also transmit information to authenticate services on the PBS.
• a multi-layer user reconciliation process may be leveraged by the presence framework to protect a user's identity and to ensure that privacy is maintained when sharing user information.
• the presence framework uses two different layers of identification each with a different set of identifiers; an application layer and a machine-to-machine layer.
• Fig 11 depicts exemplary steps for installing a presence enabled application.
• An application layer interface called Presence API (PAPI) allows applications leveraging presence capabilities to uniquely identify each user to the application provider by generating an identifier called the Application Specific User Hash (ASUH).
• ASUH Application Specific User Hash
• Each application partner generates their own ASUH when the application is first installed and it is shared between the presence framework components and the application provider only.
• Each application provider is also provided with a unique identifier called Application Specific Identifier (ASI) that identifies them within the presence framework system.
• ASI Application Specific Identifier
• the proposed methods and systems also facilitate allowing all application partners to inform the user of the locations that they are requesting presence data for in their EULAs and subsequently this information can also be viewed and granularly adjusted in the presence settings.
• a separate machine-to-machine layer interface uses the Device Specific Interface (DSI) to uniquely identify each presence enabled device.
• the DSI may be a derivative of the MAC Address in devices with unique MAC addresses.
• a DSI is generated separately, such as through one or more of the MAC Address transformation techniques described herein, and assigned to the device.
• the DSI is known only within the presence framework system and is not shared with other entities or associated with any user data.
• the DSI is a part of all beacon frames transmitted by a PBS. Importantly, if the DSI were to be absorbed by an unauthorized entity, it cannot be reconciled with any user information or identity.
• Fig. 12 depicts the exchange of identifiers in the reconciliation process.
• the DSI is emitted by the Presence Beaconing Station (PBS) as part of its beacons.
• PBS Presence Beaconing Station
• the PDS absorbs the DSI from the beacon frame and subsequently relays it to the Remote Data Server (RDS) for processing.
• RDS queries the DSI and determines which application partners have been approved by the user to receive presence/location data for the detection site.
• the application partners who are determined to have access at the site are then sent their respective ASUHs with which they can identify the user.
• the beacon frames sent out by the PBS are only detected when the transmissions occur within a BDA. Once the PBS leaves the BDA, its beacon frames are no longer picked up by a PDS, at which point it stops receiving instructions from the PDS and switches to the default power conservation transmission mode with a longer Beaconing Schedule Interval (BSI).
• BSI Beaconing Schedule Interval
• Specialized beacon frames may be sent out by Presence Enabled APs (PAPs) to allow passive authentication of a core WLAN connection.
• PAPs can authenticate a PBS and pass hidden SSIDs and WEP/WPA/WPA2 keys directly to the PBS. This information is used to trigger an association request from the PBS.
• PAPs Presence Enabled APs
• Presence Enabled Access Points are WLAN Access Points (APs) that also act as Presence Detection Stations (PDSs) when equipped with the proposed invention in the form of software that resides in the hardware already in the WLAN Access Point.
• PDSs Presence Detection Stations
• PAPs have added functionality in that they can enable access to a wider range of services compared to a stand-alone PDS which may only detects presence.
• a PAP When a PAP detects a new PBS in its Beacon Detection Area (BDA), it first reconciles the user information as a normal PDS as described herein. Additionally if the user has access privileges to the WLAN provided by the PAP, the PAP is given instructions and an encryption key from the cloud server to provide WLAN authentication information to the PBS. The PAP encrypts the SSID and the WLAN key using the key and beacons this information to the PBS. A software client on the PBS can decrypt the SSID and WLAN key and use them to passively authenticate and connect to the WLAN provided by the PAP. These steps are outlined in Figure 13.
• BDA Beacon Detection Area
• the proposed proprietary protocol defines services that are required for the protocol to function but may not require a specific implementation of said services.
• the PBS and PDS have distinct sets of functionalities and are responsible for either initiating and/or executing certain services.
• the PBS is not required to implement the services for the PDS and the PDS is not required to implement the services for the PBS.
• the services implemented on the PBS that may be triggered by the PDS comprise:
• An PBS generates services that may affect the overall behavior of the presence architecture.
• the PBS emits the beacon frame at a fixed interval determined by the BSI. Once the beacon frames are absorbed, the PDS can initiate other services.
• the PBS transmits the beacon frame along with the time elapsed to the nearest 1.25 nanoseconds from the previous beacon.
• the PBS may emit a priority beacon frame.
• EAS Emergency Alert System
• the PDS may emit a priority beacon frame.
• the priority beacon frame may override all user privacy settings and start gathering presence information and allow access to services which may or may not be provided under normal conditions.
• the PDS When the PDS first detects an PBS in its BDA, it can direct the PBS to decrease its BSI for a set amount of time. If the PBS remains in the BDA past the time limit, it may be redirected to maintain the increased frequency. Once the PBS leaves the BDA, it may automatically revert to its default BSI in the absence of beacon frames from the PDS.
• a PAP can be directed to enable WLAN access on the PBS.
• the PBS is given the SSID and/or an encrypted key needed to establish a WLAN connection.
• the PBS Upon receiving WLAN Access information, the PBS passes the information to a software client. The software client can subsequently use this information to establish a WLAN connection.
• the PBS may be instructed by the PDS of whether or not time stamping is required for the BDA. If they are, the PBS may emit a DSI+TSR ("Time Stamp Request") Beacon instead of the regular DSI beacon. All PDSs that support time stamping for signal analysis may broadcast a TSR beacon frame when the PBS first enters the BDA and at regular intervals afterwards. In the absence of this TSR beacon frame the PBS may stop time stamping its beacons.
• TSR Time Stamp Request
• a PDS When a PDS receives a beacon frame from the PBS, it may need to route the information to the Remote Data Server (RDS).
• RDS Remote Data Server
• the PDS may monitor the signal strength of the incoming beacon frames and only route PBS data once it passes a threshold value.
• the PDS may also reconcile beacon frames depending on their priority and the order they are received in. EAS beacon frames have the highest priority and are routed on priority channels.
• the PDS may cache PBS information once the PBS enters its BDA.
• the PDS may emit a beacon frame that, once received by the PBS, will decrease the BSI of the PBS causing the PBS to emit beacon frames at smaller intervals.
• the PDS may maintain a scheduling algorithm and emit a beacon frame to notify the PBSs that they are within its BDA.
• a BDA may send out an additional beacon frame called the TSR beacon.
• This beacon notifies a PBS that it needs beacons to be time stamped.
• the PDS may need to send out this beacon frame when a PBS is first detected and also at regular intervals afterwards as in the absence of this beacon frame, a PBS may stop time stamping its beacons.
• PAPs have WLAN capabilities, and can send information needed to connect to the core WLAN network. Once the PAP has detected and reconciled the PBS, it may emit a beacon frame containing the SSID and WLAN authentication key when directed by the RDS. The PAP may also locally default to send this information out to a PBS, if the PBS is emitting a priority emergency beacon frame.
• a Station should be able to properly construct a subset of the frames and decode a different subset of the frames specified.
• the sets may be determined by whether the STA is a Presence Beaconing Station (PBS) or Presence Detection Station (PDS). All STAs should be able to validate every received frame using the frame check sequence (FCS) and to interpret certain fields from the frame headers.
• PBS Presence Beaconing Station
• PDS Presence Detection Station
• Each frame consists of the following basic components: [00164] A header, which compromises frame control and duration.
• a variable length frame body which contains information specific to the frame type.
• a FCS which contains an IEEE 32-bit C C.
• the frames are described as a sequence of fields in a predefined order.
• Each figure in Section 5 depicts the fields as they appear in the frames in the order in which they are to be emitting from the physical layer, from left to right.
• All bits within fields are numbered, from 0 to k, where the length of the field is k+1 bits.
• the octet boundaries within a field can be obtained by taking the bit numbers of the field modulo 8. Octets within numeric fields that are longer than a single octet are depicted in increasing order of significance, from lowest numbered bit to highest numbered bit. The octets in fields longer than a single octet are sent to the physical layer in order from the octet containing the lowest numbered bits to the octet containing the highest numbered bit. Any field containing a Cyclic Redundancy Code (CRC) is an exception to this convention and is transmitted commencing with the coefficient of the highest-order term.
• CRC Cyclic Redundancy Code
• the proposed presence frame format comprises a set of fields that occur in a fixed order in all frames.
• Figure 15 depicts the general presence frame format.
• the first three fields (Frame Control, Duration/ID, and Recipient Address) and the last field (FCS) in Figure 15 constitute the minimal frame format and are present in all frames.
• the fields Source Address and Frame Body are present only in certain frame types.
• the Frame body is of variable size depending on frame type.
• the Frame Control field consists of the following subfields: Protocol Version, Type, Priority, and WLAN Related Flags.
• the format of the Frame Control field is illustrated in Figure 16.
• the Protocol Version field is 2 bits in length and is invariant in size and placement across all revisions of this standard. It also reflects the Protocol Version of the 802.11 standard supported by the same radio. The version level may only be incremented once the version level of 802.11 Protocols are increased to allow cross compatibility of standards across multiple devices. Any received frames with a higher revision level should discard the frame without any indication to the STA or to Logical Link Control (LLC).
• LLC Logical Link Control
• the Type field is 6 bits in length.
• the type fields identify the function of the frame. There are two frame types: beacon and control. Each of these frame types has several defined subtypes. Table 1 defines the combinations for each subtype. (The numeric values in Table 1 are shown in binary). Type Value
• Bit 7 is set to 0 in beacon frames and to 1 in Control frames.
• Bit 6 is set to 0 in frames originating from a PBS and to 1 in frames originating from a PDS.
• the priority fields can be set to prioritize the order in which beacon frames are processed at either the (Medium Access Control) MAC or higher layers. Beacons of the same priority level are processed in a first-in, first-out basis, and higher priority levels are always cleared before lower levels.
• the combination of values and corresponding priority levels are define in table 2.
• the proposed presence header has 6 additional bits added to make it the same length as the Frame Control field specified in IEEE 802.11 MAC Header. Bits 10, 11, 13, 14 and 15 (More Fragment, Retry, More Data, Protected Frame and Order in IEEE 802.11) are all set to 0. Bit 12 (Power Management in IEEE 802.11) is set to 0 from all PDSs, but set to 1 from all PBSs.
• the Duration field is 16 bits in length.
• the duration value is used to update the Network Allocation Vector (NAV) according to the procedures defined in clause 9.2.5.4 of IEEE 802.11.
• NAV Network Allocation Vector
• the Duration field is set to the amount of time needed in microseconds to send the entire frame. Since the proposed protocol has transmissions that are at most only one frame long it will not require a device to reserve a longer time limit.
• Each Address Field contains a 48-bit address that acts as an identifier for the device. All PDSs use 00:00:00:00:00:00 (in hexadecimal) as their address while the address of a PBS called DSI is determined by additional software in the application layer of the device.
• the Frame Body is a variable length field that contains additional information specific to certain frame types.
• the minimum frame body is 0 octets as not all types need to broadcast additional information.
• the FCS field is a 32-bit field containing a 32-bit CRC.
• the FCS is calculated over all the fields of the proposed presence header and the Frame Body field.
• the FCS calculation is same as the one specified in IEEE 802.11.
• FCS is calculated using the following standard generator polynomial of degree 32:
• FCS is the ones complement of the sum (modulo 2) of the following:
• FCS field is transmitted commencing with the coefficient of the highest-order term.
• the initial remainder of the division is preset to all ones and is then modified by division of the calculation fields by the generator polynomial G(x).
• the ones complement of this remainder is transmitted, with the highest-order bit first, as the FCS field.
• the initial remainder is preset to all ones and the serial incoming bits of the calculation fields and FCS, when divided by G(x), results in the absence of transmission errors, in a unique nonzero remainder value.
• the unique remainder value is the polynomial:
• the frame format for control frames is independent of frame subtype and is defined in Figure 17.
• the recipient address is set to the DSI of the destination device.
• the duration field is set to the time interval needed to transmit the pending frame plus one Short Interframe Space (SIFS) interval.
• SIFS Short Interframe Space
• the recipient address is set to OxFFFFFFFFFF (in hexadecimal) and the source DSI is the DSI of the transmitting device.
• the duration field is set to the time required to transmit the pending frame plus one SIFS interval.
• the DSI + Time Stamp frame has the same fields as the DSI Beacon frame but also has a Time Stamp field that contains additional timing information.
• the PBS counts the time elapsed to the nearest 1.25 nanoseconds from the time when the previous beacon was transmitted. The time passed is inserted into the Time Stamp field which is 8 octets in length.
• the Recipient DSI is the DSI of the device authorized to access the WLAN.
• the source MAC is the MAC address of the WLAN AP.
• the duration field is set to the time required to transmit the pending frame plus one SIFS interval.
• the Frame body field can be 3-98 octets in length and its contents are described in section 5.3.2.
• the WLAN Frame body is a minimum of 3 octets and a maximum of 98 octets long. Its format is defined in Figure 22.
• the Frame body header is determined by the type of encryption used by the WLAN, the length of the SSID in bytes and length of the key in bytes and is defined in Figure 23.
• the SSID can be from 1 to 32 octets and the key can be 0 to 64 octets long.
• the WLAN type is set according the kind of encryption on the WLAN.
• the possible values for WLAN type are given in Table 3.
• the SSID Length is the length in octets of the SSID with a maximum value of 32 and the WLAN Key Length is the length in octets of the WLAN encryption key with a maximum value of 64.
• the proposed presence protocol is designed to utilize the same set of MAC functionalities as IEEE 802.11. Although it may not need to leverage the entire set of functionality, some of which are needed by 802.11 for frame exchanges with more than one frame involved, the protocol may use the existing contention protocols to determine when to send a packet. In addition to the existing functionality, the protocol may require additional functions which are described in this section.
• the Scheduling Beacon Function determines how frequently the PBS transmits the DSI beacons.
• the Emergency Beacon Function which is triggered on a PBS when the device has EAS mode activated.
• the SBF maintains a series of counters that determines when to transmit the next beacon. There are two predefined BSIs of 60 seconds and 15 seconds. By default the PBS uses the BSI of 60 seconds.
• the SBF should start a counter that counts down to 0 in the interval specified by the BSI. Once the counter reaches 0 the SBF should start the transmission of a beacon frame. The presence beacon frame should be sent out at the next available opportunity if there are pending frames for 802.11 or if the medium is busy. Once the beacon has been successfully transmitted (note this means the beacon was sent to the physical layer and left it successfully, not necessarily picked up by another device), the SBF resets the counter and repeats the process.
• the SBF should switch to using the BSI of 15 seconds.
• the PBS should send out the next 20 beacons using the shorter BSI (beacons for the next 5 minutes). If a DBS beacon is received during that time it restarts counting the 20 beacons at the shorter BSI. If a DBS beacon is not received then it switches back to the default BSI of 60 seconds.
• the SBF can be implemented through either physical or virtual mechanisms or through both. An example implementation is discussed here.
• the SBF is required to beacon at a default rate of once every 60 seconds.
• DBS Decrease Beaconing Schedule
• the PBS may initiate a beaconing frequency of 1 beacon every 15 seconds for a period of 5 minutes (the next 20 beacons). If another DBS Beacon is received in that time frame, the PBS may continue to transmit beacons at 15 second intervals for another 5 minutes. When a PBS loses reception of the DBS Beacon it reverts back to the default 60 second interval.
• DBS Decrease Beaconing Schedule
• Count A type: integer, min:0, max:4, (counts 4x15s intervals to send beacon every 60s)
• Count B type: integer, min: 0, max: 20 (counts 20x15s intervals to revert to default SBI)
• listener DBS_Beacon //thread listening on a port or change in event
• count B 0;
• count _B 0;
• the EBF is used on a PBS when EAS mode is activated on the device.
• the EBF sets the priority field in the presence header of all beacon frames leaving the PBS to high (see Section 5.1.3.1.3).
• the EBF overrides any other services trying to access the PHY layer.
• the ERF is used on the PDS when it receives a high priority beacon but it resides above the MAC sub-layer.
• the proposed protocol uses the same Physical (PHY) layer and frequency hopping mechanisms as IEEE 802.11 which are described in detail in the IEEE 802.11 specification clauses 12, 13, 14 and 15.
• the protocol is designed to use the 1 -persistent CSMA mode with no Collision Detection/Avoidance mechanism. Whenever a presence packet is ready to be transmitted, the medium is checked to see if there is an ongoing transmission. If the medium is free then the packet is transmitted right away. If the medium is busy, the PHY layer may wait till the medium is free before transmitting the presence packet.
• PDSs Presence Detection Stations
• the primary function of the PDS is to absorb beacon frames emitted by an PBS, and subsequently relaying the Device Specific Identifier (DSI) of the PBS along with relevant metadata identifying the PDS to the Remote Data Server (RDS). All devices acting as a PDS need an Internet connection to be able to communicate with the RDS.
• the PDS uses the TCP/IP protocol to communicate with the RDS.
• the PDS may also maintain a locally cached table of all PBSs currently in its Beacon Detection Area (BDA).
• BDA Beacon Detection Area
• the PDS may also emit beacons at regular intervals to all PBSs in its table.
• the Decrease Beaconing Schedule (DBS) Control Beacon may be sent out to each PBS to trigger shorter beacon emission interval when they are in the BDA (see section 5 for DBS format).
• RFTs radio frequency tags
• the PDS may also emit a Radio Frequency Tag Enabled Beacon Detection Area (RBDA) Beacon format.
• the PDS may maintain a schedule for sending out the above mentioned frames to all PBSs in its BDA.
• the PDS may perform signal strength analysis on all incoming beacons from the PBSs.
• PDSs may have an algorithm that allows them to filter PBSs that are emitting below a predefined threshold signal strength level.
• the PDSs may be able to communicate with each other and compare signal strength analysis data collected at each PDS to better position PBSs.
• the protocol has a built in mechanism to help Emergency Responders when a 911 call is placed on a Presence Beaconing Station (PBS) such as a mobile device.
• PBS Presence Beaconing Station
• the Emergency Beacon Function (EBF) on the PBS sets the Priority field in all Presence Beacon Frame Body headers (refer to section 5.1.3.1.3) to high.
• the EBF also decreases the Beaconing Schedule Interval (BSI) to 15 seconds.
• BSI Beaconing Schedule Interval
• a Presence Detection Station detects a high priority beacon the Emergency Response Function (ERF) is triggered on the PDS.
• the ERF may cause the PDS to process all high priority beacons before processing beacons of lower priority. If the PDS is part of a Presence Access Point (PAP), the PAP may also beacon the SSID and WLAN authentication key to the PBS.
• PDS Presence Detection Station
• PAP Presence Access Point
• the EBF on receiving the SSID and WLAN key can decide whether or not to establish a WLAN connection if there is a low or no signal strength on the cellular network. This ensures that even in areas with poor cellular reception a 911 call can still be made if there is PAP coverage.
• the ERF also ensures that all information associated with priority beacons are routed through priority channels to the Remote Data Server (RDS).
• RDS Remote Data Server
• the RDS overrides all privacy settings and may share the presence/location data with Emergency Responders even if the user has not preauthorized his presence/location data to be gathered at the specified location.
• the proposed protocol is a new protocol on the 2.4/5 GHz radio frequency. It is designed for presence detection and authentication using the same physical layer instructions of Wi-Fi but with its own proprietary packet format. Any Wi-Fi AP has the basic hardware requirements needed to support presence awareness. This description outlines the additional firmware/design modifications needed to enable existing Wi-Fi APs to become PAPs and be used as part of the presence solution.
• Figure 25 illustrates the modifications needed to existing Wi-Fi Access Point architecture.
• the MAC Layer discards all packets captured by the Physical Layer that are either invalid or meant for another destination. A modification may need to be made to the MAC Layer so that presence packets are now routed to a new presence firmware routine for processing.
• the new firmware inside the AP also has to be able to communicate with the external Remote Data Server.
• the proposed presence packets have a very similar structure to 802.11 packets with some key differences.
• the basic packet structure is outlined in Figure 26.
• Frame Control The subfields within the Frame Control are set as illustrated in Figure 27.
• the Subtype can take any value from 0x00 to OxOF while Priority can take any value from 0x00 to 0x03.
• Recipient Address The address is set to OxFFFFFFFFFF so that any PAP can receive the packet and process it.
• Source DSI can be any value from 0x01 to OxFFFFFFFFFE and is unique for each presence enabled mobile device.
• FCS The FCS field is a 32-bit field containing a 32-bit CRC.
• the FCS is calculated over the previous 16 bytes.
• the FCS calculation is same as the one specified in IEEE 802.11.
• the presence firmware routine also needs to be able to communicate with the Remote Data Server via a 4G/3G modem or some other Internet connection.
• Figure 28 illustrates the modifications needed to existing Wi-Fi architecture on mobile handsets.
• a modification may need to be made to the MAC Layer so that presence packets can be sent from the handset.
• the proposed Presence Client on the device specifies a unique 6 byte Device Specific Identifier which is part of the presence frame.
• the Presence Client also specifies the 802.11 channel on which the chip needs to transmit the presence frames and the time interval between subsequent beacons.
• the methods and systems described herein may be deployed in part or in whole through a machine that executes computer software, program codes, and/or instructions on a processor.
• the processor may be part of a server, client, network infrastructure, mobile computing platform, stationary computing platform, or other computing platform.
• a processor may be any kind of computational or processing device capable of executing program instructions, codes, binary instructions and the like.
• the processor may be or include a signal processor, digital processor, embedded processor, microprocessor or any variant such as a co-processor (math co-processor, graphic co-processor, communication co-processor and the like) and the like that may directly or indirectly facilitate execution of program code or program instructions stored thereon.
• the processor may enable execution of multiple programs, threads, and codes.
• the threads may be executed simultaneously to enhance the performance of the processor and to facilitate simultaneous operations of the application.
• methods, program codes, program instructions and the like described herein may be implemented in one or more thread.
• the thread may spawn other threads that may have assigned priorities associated with them; the processor may execute these threads based on priority or any other order based on instructions provided in the program code.
• the processor may include memory that stores methods, codes, instructions and programs as described herein and elsewhere.
• the processor may access a storage medium through an interface that may store methods, codes, and instructions as described herein and elsewhere.
• the storage medium associated with the processor for storing methods, programs, codes, program instructions or other type of instructions capable of being executed by the computing or processing device may include but may not be limited to one or more of a CD-ROM, DVD, memory, hard disk, flash drive, RAM, ROM, cache and the like.
• a processor may include one or more cores that may enhance speed and performance of a multiprocessor.
• the process may be a dual core processor, quad core processors, other chip-level multiprocessor and the like that combine two or more independent cores (called a die).
• the methods and systems described herein may be deployed in part or in whole through a machine that executes computer software on a server, client, firewall, gateway, hub, router, or other such computer and/or networking hardware.
• the software program may be associated with a server that may include a file server, print server, domain server, internet server, intranet server and other variants such as secondary server, host server, distributed server and the like.
• the server may include one or more of memories, processors, computer readable media, storage media, ports (physical and virtual), communication devices, and interfaces capable of accessing other servers, clients, machines, and devices through a wired or a wireless medium, and the like.
• the methods, programs or codes as described herein and elsewhere may be executed by the server.
• other devices required for execution of methods as described in this application may be considered as a part of the infrastructure associated with the server.
• the server may provide an interface to other devices including, without limitation, clients, other servers, printers, database servers, print servers, file servers, communication servers, distributed servers and the like. Additionally, this coupling and/or connection may facilitate remote execution of program across the network. The networking of some or all of these devices may facilitate parallel processing of a program or method at one or more location without deviating from the scope.
• any of the devices attached to the server through an interface may include at least one storage medium capable of storing methods, programs, code and/or instructions.
• a central repository may provide program instructions to be executed on different devices.
• the remote repository may act as a storage medium for program code, instructions, and programs.
• the software program may be associated with a client that may include a file client, print client, domain client, internet client, intranet client and other variants such as secondary client, host client, distributed client and the like.
• the client may include one or more of memories, processors, computer readable media, storage media, ports (physical and virtual), communication devices, and interfaces capable of accessing other clients, servers, machines, and devices through a wired or a wireless medium, and the like.
• the methods, programs or codes as described herein and elsewhere may be executed by the client.
• other devices required for execution of methods as described in this application may be considered as a part of the infrastructure associated with the client.
• the client may provide an interface to other devices including, without limitation, servers, other clients, printers, database servers, print servers, file servers, communication servers, distributed servers and the like. Additionally, this coupling and/or connection may facilitate remote execution of program across the network. The networking of some or all of these devices may facilitate parallel processing of a program or method at one or more location without deviating from the scope.
• any of the devices attached to the client through an interface may include at least one storage medium capable of storing methods, programs, applications, code and/or instructions.
• a central repository may provide program instructions to be executed on different devices.
• the remote repository may act as a storage medium for program code, instructions, and programs.
• the methods and systems described herein may be deployed in part or in whole through network infrastructures.
• the network infrastructure may include elements such as computing devices, servers, routers, hubs, firewalls, clients, personal computers, communication devices, routing devices and other active and passive devices, modules and/or components as known in the art.
• the computing and/or non-computing device(s) associated with the network infrastructure may include, apart from other components, a storage medium such as flash memory, buffer, stack, RAM, ROM and the like.
• the processes, methods, program codes, instructions described herein and elsewhere may be executed by one or more of the network infrastructural elements.
• the methods, program codes, and instructions described herein and elsewhere may be implemented on a cellular network having multiple cells.
• the cellular network may either be frequency division multiple access (FDMA) network or code division multiple access (CDMA) network.
• FDMA frequency division multiple access
• CDMA code division multiple access
• the cellular network may include mobile devices, cell sites, base stations, repeaters, antennas, towers, and the like.
• the cell network may be a GSM, GPRS, 3G, EVDO, mesh, or other networks types.
• the methods, programs codes, and instructions described herein and elsewhere may be implemented on or through mobile devices.
• the mobile devices may include navigation devices, cell phones, mobile phones, mobile personal digital assistants, laptops, palmtops, netbooks, pagers, electronic books readers, music players and the like. These devices may include, apart from other components, a storage medium such as a flash memory, buffer, RAM, ROM and one or more computing devices.
• the computing devices associated with mobile devices may be enabled to execute program codes, methods, and instructions stored thereon. Alternatively, the mobile devices may be configured to execute instructions in collaboration with other devices.
• the mobile devices may communicate with base stations interfaced with servers and configured to execute program codes.
• the mobile devices may communicate on a peer to peer network, mesh network, or other communications network.
• the program code may be stored on the storage medium associated with the server and executed by a computing device embedded within the server.
• the base station may include a computing device and a storage medium.
• the storage device may store program codes and instructions executed by the computing devices associated with the base
• the computer software, program codes, and/or instructions may be stored and/or accessed on machine readable media that may include: computer components, devices, and recording media that retain digital data used for computing for some interval of time; semiconductor storage known as random access memory (RAM); mass storage typically for more permanent storage, such as optical discs, forms of magnetic storage like hard disks, tapes, drums, cards and other types; processor registers, cache memory, volatile memory, non-volatile memory; optical storage such as CD, DVD; removable media such as flash memory (e.g.
• RAM random access memory
• mass storage typically for more permanent storage, such as optical discs, forms of magnetic storage like hard disks, tapes, drums, cards and other types
• processor registers cache memory, volatile memory, non-volatile memory
• optical storage such as CD, DVD
• removable media such as flash memory (e.g.
• USB sticks or keys floppy disks, magnetic tape, paper tape, punch cards, standalone RAM disks, Zip drives, removable mass storage, off-line, and the like; other computer memory such as dynamic memory, static memory, read/write storage, mutable storage, read only, random access, sequential access, location addressable, file addressable, content addressable, network attached storage, storage area network, bar codes, magnetic ink, and the like.
• the methods and systems described herein may transform physical and/or or intangible items from one state to another.
• the methods and systems described herein may also transform data representing physical and/or intangible items from one state to another.
• machines may include, but may not be limited to, personal digital assistants, laptops, personal computers, mobile phones, other handheld computing devices, medical equipment, wired or wireless communication devices, transducers, chips, calculators, satellites, tablet PCs, electronic books, gadgets, electronic devices, devices having artificial intelligence, computing devices, networking equipment, servers, routers and the like.
• the elements depicted in the flow chart and block diagrams or any other logical component may be implemented on a machine capable of executing program instructions.
• the methods and/or processes described above, and steps thereof, may be realized in hardware, software or any combination of hardware and software suitable for a particular application.
• the hardware may include a general purpose computer and/or dedicated computing device or specific computing device or particular aspect or component of a specific computing device.
• the processes may be realized in one or more microprocessors, microcontrollers, embedded microcontrollers, programmable digital signal processors or other programmable device, along with internal and/or external memory.
• the processes may also, or instead, be embodied in an application specific integrated circuit, a programmable gate array, programmable array logic, or any other device or combination of devices that may be configured to process electronic signals. It may further be appreciated that one or more of the processes may be realized as a computer executable code capable of being executed on a machine readable medium.
• the computer executable code may be created using a structured programming language such as C, an object oriented programming language such as C++, or any other high-level or low-level programming language (including assembly languages, hardware description languages, and database programming languages and technologies) that may be stored, compiled or interpreted to run on one of the above devices, as well as heterogeneous combinations of processors, processor architectures, or combinations of different hardware and software, or any other machine capable of executing program instructions.
• a structured programming language such as C
• an object oriented programming language such as C++
• any other high-level or low-level programming language including assembly languages, hardware description languages, and database programming languages and technologies
• each method described above and combinations thereof may be embodied in computer executable code that, when executing on one or more computing devices, performs the steps thereof.
• the methods may be embodied in systems that perform the steps thereof, and may be distributed across devices in a number of ways, or all of the functionality may be integrated into a dedicated, standalone device or other hardware.
• the means for performing the steps associated with the processes described above may include any of the hardware and/or software described above. All such permutations and combinations are intended to fall within the scope of the present disclosure.

Landscapes

• Engineering & Computer Science (AREA)
• Computer Security & Cryptography (AREA)
• Computer Networks & Wireless Communication (AREA)
• Signal Processing (AREA)
• Mobile Radio Communication Systems (AREA)

Applications Claiming Priority (2)

Publications (2)

Family

ID=48082528

Family Applications (1)

Country Status (3)

Families Citing this family (8)

Family Cites Families (11)

• 2012
  • 2012-10-12 EP EP12840465.4A patent/EP2777325A4/de not_active Withdrawn
  • 2012-10-12 WO PCT/US2012/060087 patent/WO2013056143A1/en active Application Filing
  • 2012-10-12 CN CN201280061280.6A patent/CN104255059A/zh active Pending

Also Published As

Similar Documents

Legal Events