US20170171073A1 - Internet routing over a service-oriented architecture bus - Google Patents
Internet routing over a service-oriented architecture bus Download PDFInfo
- Publication number
- US20170171073A1 US20170171073A1 US15/445,801 US201715445801A US2017171073A1 US 20170171073 A1 US20170171073 A1 US 20170171073A1 US 201715445801 A US201715445801 A US 201715445801A US 2017171073 A1 US2017171073 A1 US 2017171073A1
- Authority
- US
- United States
- Prior art keywords
- gateway
- address
- gateway node
- service
- internet
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W40/00—Communication routing or communication path finding
- H04W40/02—Communication route or path selection, e.g. power-based or shortest path routing
- H04W40/22—Communication route or path selection, e.g. power-based or shortest path routing using selective relaying for reaching a BTS [Base Transceiver Station] or an access point
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/74—Address processing for routing
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/66—Arrangements for connecting between networks having differing types of switching systems, e.g. gateways
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/104—Peer-to-peer [P2P] networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W40/00—Communication routing or communication path finding
- H04W40/24—Connectivity information management, e.g. connectivity discovery or connectivity update
- H04W40/246—Connectivity information discovery
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W40/00—Communication routing or communication path finding
- H04W40/24—Connectivity information management, e.g. connectivity discovery or connectivity update
- H04W40/28—Connectivity information management, e.g. connectivity discovery or connectivity update for reactive routing
Definitions
- SOAs service-oriented architectures
- the following relates generally to service-oriented architectures (SOAs), and in particular to the implementation of Internet routing over an SOA bus.
- a service In a service-oriented architecture, one or more nodes may communicate with each other to offer each other interoperable services.
- a service can be thought of as an autonomous unit of functionality implemented by self-contained software.
- a typical implementation of service-oriented architecture functionality may include a number of computer nodes interconnected by a computer network. Each node may communicate with the other nodes to identify services offered by the other nodes. Each node may also advertise one or more services to the other nodes.
- the first node may transmit a remote procedure call to the second node, the remote procedure call being supported by the selected service.
- the remote procedure call may include one or more arguments or other parameters provided by the first node.
- the second node may respond to the remote procedure call by executing one or more software functions based on the type of call and/or the parameters provided. In some examples, the second node may provide a result of the remote procedure call to the first node.
- Service-oriented architecture buses also known as service buses
- Service-oriented architecture buses facilitate communication between mutually interacting software applications to allow the applications to invoke each other's services.
- service-oriented architecture buses grows, new uses of these buses continue to develop.
- a method for routing in an ad hoc peer-to-peer network includes transmitting, from a non-gateway node, an internet route request for an indefinite destination to one or more neighbor nodes on the network.
- the method also includes receiving, at the non-gateway node, a response message from at least one gateway node on the network, wherein the response message includes an address of the at least one gateway node and a gateway indicator.
- the method additionally includes setting, at the non-gateway node, a gateway pointer equal to the address of the at least one gateway node.
- a method for routing in an ad hoc peer-to-peer network includes receiving, at a gateway node, an internet route request from one or more neighbor nodes on the network. The method also includes transmitting, from the gateway node, a response message to the one or more neighbor nodes, wherein the response message includes an address of the gateway node and a gateway indicator.
- a method for routing in an ad hoc peer-to-peer network includes receiving, at a non-gateway node, an announcement of internet connectivity from one or more gateway nodes on the network, wherein the announcement includes an address of the one or more gateway nodes.
- the method also includes storing, at the non-gateway node, the address of the one or more gateway nodes to a list of potential gateways.
- the method additionally includes receiving packets for transmission to an internet destination.
- the method further includes selecting a gateway address from the list of potential gateways.
- the method still further includes transmitting the packets to a destination gateway associated with the gateway address.
- an apparatus for routing in an ad hoc peer-to-peer network includes means for transmitting, from a non-gateway node, an internet route request for an indefinite destination to one or more neighbor nodes on the network.
- the apparatus also includes means for receiving, at the non-gateway node, a response message from at least one gateway node on the network, wherein the response message includes an address of the at least one gateway node and a gateway indicator.
- the apparatus additionally includes means for setting, at the non-gateway node, a gateway pointer equal to the address of the at least one gateway node.
- an apparatus for routing in an ad hoc peer-to-peer network includes means for receiving, at a gateway node, an internet route request from one or more neighbor nodes on the network.
- the apparatus also includes means for transmitting, from the gateway node, a response message to the one or more neighbor nodes, wherein the response message includes an address of the gateway node and a gateway indicator.
- an apparatus for routing in an ad hoc peer-to-peer network includes means for receiving, at a non-gateway node, an announcement of internet connectivity from one or more gateway nodes on the network, wherein the announcement includes an address of the one or more gateway nodes.
- the apparatus also includes means for storing, at the non-gateway node, the address of the one or more gateway nodes to a list of potential gateways.
- the apparatus additionally includes means for receiving packets for transmission to an internet destination.
- the apparatus further includes means for selecting a gateway address from the list of potential gateways.
- the apparatus still further includes means for transmitting the packets to a destination gateway associated with the gateway address.
- a computer program product includes a non-transitory computer-readable medium.
- the non-transitory computer-readable medium includes code for transmitting, from a non-gateway node, an internet route request for an indefinite destination to one or more neighbor nodes in an ad hoc peer-to-peer network.
- the non-transitory computer-readable medium also includes code for receiving, at the non-gateway node, a response message from at least one gateway node on the network, wherein the response message includes an address of the at least one gateway node and a gateway indicator.
- the non-transitory computer-readable medium additionally includes code for setting, at the non-gateway node, a gateway pointer equal to the address of the at least one gateway node.
- a computer program product includes a non-transitory computer-readable medium.
- the non-transitory computer-readable medium includes code for receiving, at a gateway node, an internet route request from one or more neighbor nodes on an ad hoc peer-to-peer network.
- the non-transitory computer-readable medium also includes code for transmitting, from the gateway node, a response message to the one or more neighbor nodes, wherein the response message includes an address of the gateway node and a gateway indicator.
- a computer program product includes a non-transitory computer-readable medium.
- the non-transitory computer-readable medium includes code for receiving, at a non-gateway node, an announcement of internet connectivity from one or more gateway nodes on an ad hoc peer-to-peer network, wherein the announcement includes an address of the one or more gateway nodes.
- the non-transitory computer-readable medium also includes code for storing, at the non-gateway node, the address of the one or more gateway nodes to a list of potential gateways.
- the non-transitory computer-readable medium additionally includes code for receiving packets for transmission to an internet destination.
- the non-transitory computer-readable medium further includes code for selecting a gateway address from the list of potential gateways.
- the non-transitory computer-readable medium still further includes code for transmitting the packets to a destination gateway associated with the gateway address.
- a non-gateway node in an ad hoc peer-to-peer network includes one or more processors and a memory coupled to the one or more processors.
- the one or more processors are configured to transmit, from the non-gateway node, an internet route request for an indefinite destination to one or more neighbor nodes on the network.
- the one or more processors are also configured to receive, at the non-gateway node, a response message from one or more gateway nodes on the network, wherein the response message includes an address of the one or more gateway nodes and a gateway indicator.
- the one or more processors are configured to set, at the non-gateway node, a gateway pointer equal to the address of the one or more gateway nodes.
- a non-gateway node in an ad hoc peer-to-peer network includes one or more processors and a memory coupled to the one or more processors.
- the one or more processors are configured to receive, at a gateway node, an internet route request from one or more neighbor nodes on an ad hoc peer-to-peer network.
- the one or more processors are additionally configured to transmit, from the gateway node, a response message to the one or more neighbor nodes, wherein the response message includes an address of the gateway node and a gateway indicator.
- a non-gateway node in an ad hoc peer-to-peer network includes one or more processors and a memory coupled to the one or more processors.
- the one or more processors are configured to receive, at the non-gateway node, an announcement of internet connectivity from one or more gateway nodes on the network, wherein the announcement includes an address of the one or more gateway nodes.
- the one or more processors are also configured to store, at the non-gateway node, the address of the one or more gateway nodes to a list of potential gateways.
- the one or more processors is additionally configured to receive packets for transmission to an internet destination.
- the one or more processors are further configured to select a gateway address from the list of potential gateways.
- the one or more processors are configured to transmit the packets to a destination gateway associated with the gateway address.
- FIG. 1 shows a block diagram of an example system for implementing Internet Protocol (IP) connectivity over a Service-Oriented Architecture (SOA) bus;
- IP Internet Protocol
- SOA Service-Oriented Architecture
- FIG. 2 shows a block diagram of a wireless communications system
- FIG. 3 shows a block diagram of an example system for implementing IP connectivity over an SOA bus
- FIG. 4 shows a block diagram of example communication signals between a first IP service of a first device and a second IP service of a second device over an SOA bus;
- FIG. 5 shows a block diagram of an example device configured to transmit and receive IP packets over an SOA bus
- FIG. 6 shows a block diagram of an example device configured to transmit and receive IP packets over an SOA bus
- FIG. 7 shows a flowchart of an example method for implementing IP connectivity over an SOA bus
- FIG. 8 shows a flowchart of an example method for implementing IP connectivity over an SOA bus
- FIG. 9 shows a flowchart of an example method for implementing IP connectivity over an SOA bus
- FIG. 10 shows a flowchart of an example method for implementing IP connectivity over an SOA bus
- FIG. 11 shows a flowchart of an example method for generating an IP address for use in IP communications over an SOA bus
- FIG. 12 shows a flowchart of an example method for discovering IP services for implementing IP connectivity over an SOA bus
- FIG. 13 shows an ad hoc peer-to-peer network including gateway nodes and non-gateway nodes in accordance with the present disclosure
- FIG. 14 shows a functional block diagram conceptually illustrating example blocks executed by gateway and non-gateway nodes to implement one aspect of the disclosure
- FIG. 15 shows a data flow diagram conceptually illustrating an example of message exchanges executed by gateway and non-gateway nodes to implement one aspect of the disclosure
- FIG. 16 shows a functional block diagram conceptually illustrating example blocks executed by gateway and non-gateway nodes to implement one aspect of the disclosure
- FIG. 17 shows a data flow diagram conceptually illustrating an example of message exchanges executed by gateway and non-gateway nodes to implement one aspect of the disclosure
- FIG. 18 shows a functional block diagram conceptually illustrating example blocks executed by non-gateway nodes to implement one aspect of the disclosure
- FIG. 19 shows a functional block diagram conceptually illustrating example blocks executed by gateway nodes to implement one aspect of the disclosure
- FIG. 20 shows a functional block diagram conceptually illustrating example blocks executed by non-gateway nodes to implement one aspect of the disclosure
- IP communications over an SOA bus may advertise and implement separate instances of an IP service.
- Each IP service may have an IP address in an IP subnet associated with the SOA bus.
- Each IP service advertised may have a name that includes a service descriptor uniformly associated with IP connectivity. Additionally, the name of each IP service may include the IP address for that particular service.
- a first device may transmit an IP packet to a second device over the SOA bus by remotely invoking the IP service advertised by the second device and passing the IP packet to the IP service of the second device as a parameter of invocation.
- Implementations are also described regarding multi-hop Internet routing over a service oriented architecture bus. For example, some implementations involve modification of existing routing mechanisms in the ad hoc on-demand distance vector (AODV) routing standards in order to provide Internet-informed routing. Alternative implementations involve maintenance of lists, by non-gateway nodes, of potential gateway nodes based on SOA bus announcements of gateway node capabilities, and utilization of the unmodified AODV routing mechanisms to send and/or forward IP packets to a gateway node selected from a list. In alternative aspects of either of the aforementioned implementations, the Internet-destined packets may either be tunneled (i.e., the actual Internet destination being masked) or non-tunneled (i.e., no masking of the Internet destination).
- AODV ad hoc on-demand distance vector
- FIG. 1 illustrates an example a system 100 in which various devices 115 (e.g., personal computer 115 - a , smartphone 115 - b , tablet computer 115 - c , and printer 115 - d ) communicate with each other at a peer-to-peer level.
- devices 115 e.g., personal computer 115 - a , smartphone 115 - b , tablet computer 115 - c , and printer 115 - d
- devices 115 e.g., personal computer 115 - a , smartphone 115 - b , tablet computer 115 - c , and printer 115 - d
- the devices 115 may communicate with each other over different access technologies.
- personal computer 115 - a communicates with smartphone 115 - b over a wireless local area network (WLAN) connection (e.g., as an ad-hoc WLAN connection and/or through a WLAN switch, access point, or router).
- WLAN wireless local area network
- personal computer 115 - a also communicates with printer 115 - d over a Universal Serial Bus (USB) connection.
- Smartphone 115 - b also communicates with the table computer 115 - c over a Bluetooth wireless connection.
- WLAN wireless local area network
- USB Universal Serial Bus
- SOA bus refers broadly to any communication architecture providing a logical infrastructure for distributed nodes to advertise services to each other and remotely invoke each other's advertised services.
- service refers broadly to an autonomous unit of software functionality which can be remotely invoked or called by a device or application separate from the device or application implementing the service.
- SOA buses 105 in FIG. 2 and throughout the specification are given within the context of an AllJoyn bus implementing the open-source AllJoyn bus functionality.
- the principles of the present specification may be broadly applied to other types of SOA buses, including, but not limited to, Enterprise Service Buses (ESBs), Windows service buses, Simple Service Buses (SSBs), D-Bus, and/or other service buses.
- ESDs Enterprise Service Buses
- SSBs Simple Service Buses
- D-Bus D-Bus
- each of the devices 115 may run a separate instance of an SOA bus daemon.
- the SOA bus daemon running on each device 115 of the system 300 may communicate with the SOA bus daemons running on other devices 115 of the system 300 to establish a logical SOA bus 105 over the peer-to-peer network such that each of the devices 115 may communicate with any of the other devices 115 in the system 100 over the logical SOA bus 105 , regardless of the access technologies used by the devices 115 to communicate with their peers.
- Each of the devices 115 may be configured to provide a number of services over the SOA bus 105 .
- personal computer 115 - a may provide a chat service, a streaming media service, and an Internet Protocol (IP) service.
- Smartphone 115 - b may provide a chat service, a Global Positioning System (GPS) service, and an IP service.
- Tablet computer 115 - c may provide a dictionary service and an IP service.
- Printer 115 - d may provide a chat service, a streaming media service, and an IP service.
- Each service offered at each device 115 may be assigned a logical location or address on the SOA bus 105 .
- the chat service of personal computer 115 - a is given the address of :1.1 on the SOA bus 105
- the streaming media service of the personal computer 115 - a is given the address of :1.2 on the SOA bus 105
- the IP service of the personal computer 115 - a is given the address of :1.3 on the SOA bus 105 .
- Internet Protocol or “IP” refers to any version of the Internet Protocol, including IPv4, IPv6, and/or any other past or future version.
- Each of the devices 115 on the SOA bus 105 may have access to a list of services advertised by other devices 115 .
- a client process on one of the devices 115 may remotely invoke an advertised service offered by another device 115 by establishing a session on the SOA bus 105 with the address of the advertised service on the SOA bus. For instance, if a client process of smartphone 115 - b desired to access the streaming media service of printer 115 - d , the client process may establish a session with address :1.9 on the SOA bus 105 and remotely invoke a method or procedure associated with the streaming media service through the session.
- a client process may be another service advertised on the SOA bus. Additionally or alternatively, a client process may be an application or other unit of software functionality with a separate address on the SOA bus 105 which offers no publicly advertised services over the SOA bus 105 .
- each of the devices 115 in the system 100 may offer an IP service over the SOA bus 105 .
- the IP services may cooperate with each other to implement one or more IP subnets over the SOA bus 105 .
- This IP subnet may be separate and independent from any other IP subnet outside of the SOA bus.
- personal computer 115 - a and smartphone 115 - b may be part of a first IP subnet by virtue of their WLAN connection, the first IP subnet may be separate and distinct from a second IP subnet implemented over the SOA bus 105 .
- each of the IP services may have a unique name that is advertised over the SOA bus 105 .
- Each unique name may include a service descriptor uniformly associated with IP service (e.g., “org.alljoyn.ipservice”) and an appended indicator of an IP address assigned to that device within the IP subnet implemented by the SOA bus 105 (e.g., “s192_168_0_4” indicating an IP address of 192.168.0.4).
- s192_168_0_4 indicating an IP address of 192.168.0.4
- each device 115 offering an IP service on the SOA bus 105 may maintain a record of the IP address of each other known device 115 offering an IP service on the SOA bus 105 .
- IP packets may be exchanged between devices 115 on the SOA bus 105 through the remote invocation of the advertised IP services.
- personal computer 115 - a may transmit an IP packet addressed to 192.168.0.21 (the IP address associated with smartphone 115 - b ) by establishing a session between addresses :1.3 and :1.6 on the SOA bus 105 , remotely invoking a method or function associated with the IP service associated with the smartphone 115 - b (i.e. “org.alljoyn.ipservice.s192_168_0_21”), and passing the IP packet to the IP service associated with the smartphone 115 - b over the SOA bus 105 .
- the IP packet may be passed to the IP service associated with the smartphone 115 - b as an argument or other parameter in the syntax of the remotely invoked method or function.
- the IP packet may be treated as an object rather than a packet by the IP services.
- IP subnets may be implemented over the SOA bus 105 .
- the IP services may enforce rules that allow for the transfer of packets only between IP addresses associated with the same IP subnet.
- the IP subnet of an IP service may, in some examples, be included in the name of that IP service.
- an IP service name of “org.alljoyn.ipservice.weather.s192_168_0_21” may refer to an IP service associated with IP address 192.168.0.21 on a first subnet
- an IP service name of “org.alljoyn.ipservice.sports.s192_168_0_21” may refer to the same IP address on an entirely separate, independent subnet.
- a device 115 may have multiple IP addresses for multiple IP subnets implemented by the SOA bus 105 .
- the device 115 may run multiple IP services, each IP service being associated with a separate subnet, and/or allow a single IP service to handle multiple subnets. If a single IP service handles multiple subnets, the name of the IP service may reflect each IP address and subnet associated with the device 115 . In certain examples, multiple subnets may be discovered. For example, a user may desire to find ad hoc subnets related to weather reports.
- the user may search the SOA bus 105 for services with names beginning with “org.alljoyn.ipservice.weather.”
- the user may advertise an IP address for his or her device 115 on one or more of the subnets using the same preamble with a unique IP address.
- one or more of the IP services may include Domain Name Service (DNS) functionality.
- DNS Domain Name Service
- an application running on personal computer 115 _ a may attempt to access a file from the domain hostname “magellan.ion.local”.
- the IP service running on the personal computer 115 _ a may be configured to translate the provided domain into an IP service running on one of the other devices 115 connected to the SOA bus 105 .
- the name of one or more IP services may include an indicator of any domain hostnames associated with that IP service.
- the name of an IP service advertised by a device 115 may be “org.alljoyn.ipservice.s192_168_0_21_2356_magellan”.
- the “Magellan” component of the service name refers to the domain hostname associated with that the IP address “192.168.0.21.”
- a predetermined domain name, such as “.ion.local” or another suffix may be appended to the hostname component of the service name (e.g., to arrive at the hostname of “magellan.ion.local”).
- the entire domain name may be included as part of the advertised service name.
- a service associated with a resolved hostname name may be used as a subdomain under the hostname. For example, if a service named “weather” on the SOA bus is associated with a “voyager” hostname on the SOA bus, DNS functionality on one of the devices 115 may allow for the DNS lookup of the “weather” service as “weather.voyager.ion.local.”
- IP services may discover and track the domain hostnames names associated with each other IP service on the SOA bus 105 by discovering the name given to the other IP services on the SOA bus 105 .
- This DNS functionality may allow the personal computer 115 _ a or another device 115 to provide effective DNS resolution to its applications and users without contacting a DNS server. Once a hostname for a neighboring service on the SOA bus is resolved to an IP address at a device 115 , the hostname and resolved IP address may be added to a hosts file of the operating system of the device 115 (e.g., at “/etc/hosts” in UNIX or UNIX-like systems).
- any DNS query from an application to the known hostname may automatically be resolved by the operating system to the correct address on an IP subnet associated with the SOA bus.
- the operating system resolver of the device 115 need not be modified to accommodate hostnames associated with advertised services on the SOA bus.
- one or more of the IP services may be configured to implement various additional routing protocols (e.g., multi-path routing) and Quality-of-Service (QoS) functionality to achieve efficient and effective IP packet routing between the IP services.
- additional routing protocols e.g., multi-path routing
- QoS Quality-of-Service
- the “2356” in the advertised service name corresponds to a unique ID generated by the device 115 to distinguish between different devices 115 advertising the same service.
- IP address conflicts between advertised services may be detected by determining if another service or device with the same IP address has the same or a different unique ID. If the IP address has the same unique ID, no conflict exists. Otherwise, an IP address conflict to be resolved may be detected.
- FIG. 2 a block diagram illustrates one example of a wireless communications system 200 in which IP service may be implemented over an SOA bus as described above in FIG. 1 .
- the system 200 includes base stations 205 (or cells), devices 115 , a base station controller 220 , and a core network 225 (the controller 220 may be integrated into the core network 225 ).
- the system 200 may support operation on multiple carriers (waveform signals of different frequencies).
- various devices 115 may communicate with the core network 225 through one or more base stations 205 . Additionally, certain devices 115 may establish peer-to-peer communications with each other. A group of such devices 115 may cooperate with each other to establish a peer-to-peer network. For example, device 115 - e , device 115 - f , and device 115 - g may leverage a peer-to-peer connection between device 115 - e and device 115 - f and the peer-to-peer connection between device 115 - f and device 115 - g to establish a peer-to-peer network between the three devices 115 .
- the devices 115 may further cooperate to implement an SOA bus (e.g., SOA bus 105 of FIG. 1 ) over the peer-to-peer network, and implement IP communications over the SOA bus, as described above with respect to FIG. 1 .
- SOA bus e.g., SOA bus 105 of FIG. 1
- IP communications over the SOA bus, as described above with respect to FIG. 1 .
- an independent IP subnet may be established among devices 115 - e , 115 - f without reliance on base station 205 or core network 225 .
- one or more of the devices 115 may advertise a service over the SOA bus which makes use of a connection to the core network 225 through a base station 205 .
- device 115 - e may download a file from the core network 225 and stream the file to device 115 - g over the IP subnet implemented over the SOA bus between device 115 - e , device 115 - f , and device 115 - g.
- a device need not be in communication with a base station 205 to join a peer-to-peer network that provides IP services over an SOA bus.
- device 115 - i and device 115 - j may each implement peer-to-peer connections with other devices 115 without communicating with a base station 205 .
- an SOA bus may be implemented among device 115 - h , device 115 - i , device 115 - j , and device 115 - k .
- the SOA bus may be used to implement a private IP subnet among the four devices 115 connected to the SOA bus.
- the base stations 205 may wirelessly communicate with the devices 115 via a base station antenna (not shown).
- the base stations 205 may communicate with the devices 115 under the control of the base station controller 220 via multiple carriers.
- Each of the base station 205 sites may provide communication coverage for a respective geographic area.
- the coverage area for each base station 205 here is identified as 210 - a , 210 - b , or 210 - c .
- the coverage area for a base station may be divided into sectors (not shown, but making up only a portion of the coverage area).
- the system 200 may include base stations 205 of different types (e.g., macro, micro, and/or pico base stations). There may be overlapping coverage areas for different technologies.
- the devices 115 may be dispersed throughout the coverage areas 210 .
- the devices 115 may be referred to as mobile stations, mobile devices, access terminals (ATs), user equipments (UEs), subscriber stations (SSs), subscriber units, in addition to stationary devices.
- the devices 115 may include, but are not limited to, cellular phones and wireless communications devices, but may also include desktop computers, printers, servers, set-top boxes, televisions and other media players, personal digital assistants (PDAs), other handheld devices, netbooks, notebook computers, etc. In some examples, certain of the devices may be
- certain devices 115 may not directly communicate with a base station.
- various devices 115 are shown which do not have an established wireless connection to the base station 205 .
- certain devices 115 may communicate directly with each other without routing messages through a base station 205 .
- the devices may cooperate to establish a service-oriented architecture (SOA) bus, in which devices 115 are able to advertise software services to other devices on the bus, and discover and invoke each other's services over the bus.
- SOA service-oriented architecture
- communications between devices 115 over the implemented SOA bus may occur independent of the base stations 205 or their associated core network 225 .
- one or more communications over the SOA bus may occur through a base station 205 .
- FIG. 3 is a block diagram of an example system 300 for implementing IP connectivity over an SOA bus.
- the system 300 includes a first device 115 - l and a second device 115 - m .
- the first device 115 - l and the second device 115 - m communicate with each other over a logical SOA bus 105 - a .
- the first device 115 - l and the second device 115 - m may be examples of the devices 115 described above with reference to FIG. 1 or FIG. 2 .
- the SOA bus 105 - a may be an example of the SOA bus 105 described above with reference to FIG. 1 .
- Each device 115 of the present example includes a hardware platform of one or more processors 305 , main memory 310 , local storage 315 , and one or more input/output (I/O) devices 320 .
- the processor(s) 305 of each device 115 may execute code loaded into the main memory 310 from local storage 315 to execute various units of functionality in kernel space and user space of an operating system.
- each device 115 shown in the example of FIG. 3 includes a Bluetooth interface 325 for sending and receiving Bluetooth communications, a WLAN interface 330 for sending and receiving WLAN communications, and a virtual network interface 335 .
- the virtual network interface may route packets between the IP layer processing 340 in the network stack and an IP service 355 executing in user space to implement IP communications over an SOA bus 105 - a .
- the virtual network interface 335 may implement a TUN/TAP program or module according to known specifications.
- the virtual network interface 335 may simulate a network layer device.
- the IP layer processing 340 and UDP/TCP layer processing 345 may perform the traditional functions associated with packet processing in layer 3 and layer 4 of a network stack.
- each device 115 shown in the example of FIG. 3 includes an IP application 350 configured to transmit and receive data over an IP network, an IP service 355 configured to implement IP connectivity over the SOA bus 105 - a , and an SOA bus daemon 360 configured to implement the SOA bus 105 - a .
- the IP service 355 and the SOA bus daemon 360 may be examples of the IP services and SOA bus daemons described above with reference to the SOA bus 105 of FIG. 1 .
- IP application 350 - a of the first device 115 - l transmitting an IP packet to the second device 115 - m .
- IP application 350 - a generates data which is assembled into an IP application by the UDP/TCP layer processing 345 - a and the IP layer processing 340 - a .
- the assembled IP packet may have as the destination address an IP address associated with the IP service 355 - b of the second device 155 - f .
- the IP address associated with the IP service 355 - b of the second device 155 - f may be determined by the IP Service 355 - a of the first device 115 - l based on an advertised name of the IP service 355 - b of the second device 155 - f.
- the IP packet received at the IP service 355 - b of the second device 115 - m is then forwarded to the virtual network interface 335 - b of the second device, which places the IP packet into the IP layer processing 340 - b and UDP/TCP layer processing 345 - b of the network stack.
- the data from the IP packet may be provided to the IP application 350 - b of the second device 115 - m.
- FIG. 4 is a block diagram of example communication signals over an SOA bus 105 - b between a first IP service 355 - c implemented by a first device and a second IP service 355 - d implemented by a second device.
- the IP services 355 may be examples of the IP service 355 described above with reference to FIG. 3 .
- the first and second device may be examples of a device 115 described above with reference to FIG. 1 , FIG. 2 , or FIG. 3 .
- the SOA bus 105 - b may be an example of the SOA bus 105 described above with reference to FIG. 1 or FIG. 3 .
- Each of the IP services 355 may have a unique address on the SOA bus 105 - b .
- the first IP service 355 - c has an address of :1.3 on the SOA bus 105 - b
- the second IP service 355 - d has an address of :1.6 on the SOA bus 105 - b
- each IP service 355 has a name that is advertised on the SOA bus and discoverable to other services.
- the name of each IP service 355 of the present example includes a service descriptor (i.e., “org.alljoyn.ipservice”) uniformly associated with IP services 355 in a contiguous namespace of the SOA bus 105 - b .
- Each name additionally has an indicator of an IP address associated with an IP subnet implemented over the SOA bus 105 - b .
- the first IP service 355 - c has a name of “org.alljoyn.ipservice.s192_168_0_4,” indicating an IP service 355 with an IP address of 192.168.0.4
- the second IP service 355 - d has a name of “org.alljoyn.ipservice.s192_168_0_21,” indicating an IP service 355 with an IP address of 192.168.0.21.
- the first IP service 355 - c first initiates 405 a session between :1.3 and :1.6 on the SOA bus 105 - b .
- the second IP service 355 - d confirms 410 the session between :1.3 and :1.6.
- the first IP service 355 - c may then transmit a first IP packet addressed to the IP address of the second IP service 355 - d by remotely invoking 415 a method named “org.alljoyn.ipservice.s192_168_0_21.transmit” at the second IP service 355 - d over the SOA bus 105 - b .
- the first IP service passes the first IP packet to the invoked method as an argument or other parameter for the function.
- the function may be one of a known set of functions implemented by all IP services to implement IP communication.
- the IP packet may be treated as an object parameter between the two IP services 355 .
- the second IP service 355 - d may send the first IP service 355 - c a second packet by remotely invoking 420 a method named “org.alljoyn.ipservice.s192_168_0_4.transmit” at the first IP service 355 - c over the SOA bus 105 - b , passing the second IP packet to the method as an argument or other parameter to the invoked method.
- FIG. 5 illustrates a block diagram of an example device 115 - n .
- the device 115 - n may be an example of the devices 115 described above with reference to FIG. 1 , FIG. 2 , or FIG. 3 .
- the device 115 - n may be implemented, for example, entirely in hardware, or as a combination of hardware and software.
- the device 115 - n includes an IP service module 505 , an IP service advertising module 510 , an IP service discovery module 515 , a transmitter module 520 , and a receiver module 525 .
- the IP service advertising module 510 may advertise the IP service implemented by the IP service module 505 over the SOA bus to other devices and services.
- the IP service advertising module 510 may advertise the name of the IP service, the IP address associated with the IP service, a Media Access Control (MAC) address, a globally unique identifier (GUID), a universally unique identifier (UUID), and/or any other information about the IP service that may suit a particular implementation of these principles.
- the IP service advertising module 510 may also advertise subnet and/or DNS resolution data associated with the first IP service.
- the receiver module 525 may be configured to receive at least a second IP packet from the second device over the SOA bus through the IP service implemented by the IP service module 505 of the device 115 - n .
- the second device may transmit the second IP packet to the IP service by remotely invoking the IP service over the SOA bus and passing the second IP packet to the IP service as an argument or parameter associated with invoking the IP service.
- FIG. 6 illustrates a block diagram of an example device 115 - o .
- the device 115 - o may be an example of the devices 115 described above with reference to FIG. 1 , FIG. 2 , FIG. 3 , or FIG. 5 .
- the device 115 - o may be implemented, for example, entirely in hardware, or as a combination of hardware and software. Similar to the device 115 - n of FIG. 5 , the device 115 - o of FIG. 6 includes an IP service module 505 - a , an IP service advertising module 510 - a , an IP service discovery module 515 - a , a transmitter module 520 - a , and a receiver module 525 - a . Additionally, the device 115 - o of FIG. 6 includes an SOA bus daemon module 605 , an IP application 615 , and an IP address assignment module 620 .
- the SOA bus daemon module 605 may implement an SOA bus daemon that establishes peer-to-peer connections with neighboring devices. In this way, multiple devices may establish a peer-to-peer network that implements an SOA bus, as described above. Because the SOA bus daemon module 605 logically implements the SOA bus functionality on the device 115 - o , the IP service module 505 - a may communicate with the SOA bus through the SOA bus daemon module 605 .
- the SOA bus daemon module 605 may include a session management submodule 610 configured to establish, maintain, and terminate sessions with services offered on the SOA bus.
- the IP application 615 may include an application executed in user space that produces and receives data sent over an IP subnet implemented over the SOA bus. Thus, data in IP packets sent by the transmitter module 520 - a may originate from the IP application 615 , and data in IP packets received by the receiver module 525 - a may ultimately be forwarded to the IP application 615 .
- FIG. 7 illustrates an example of a method 700 of enabling IP connectivity over an SOA bus implemented by a peer-to-peer network, according to the principles of the present disclosure.
- the method 700 of FIG. 7 may be performed, for example, by one or more of the devices 115 described above with reference to FIGS. 1-6 .
- a first IP service at a first device is advertised over an SOA bus implemented by a peer-to-peer network.
- the SOA bus may include an ALLJOYN service bus, an Enterprise Service Bus (ESB), a MICROSOFT WINDOWS Service Bus, a Simple Service Bus (SSB), and/or any other applicable type of service bus.
- the first IP service may be advertised using a service name associated with the first IP service, the service name associated with the first service including a service descriptor (e.g., “org.alljoyn.ipservice”) uniformly associated with IP service at the SOA bus.
- a service descriptor e.g., “org.alljoyn.ipservice”
- a second IP service advertised by a second device over the SOA bus is discovered.
- the second IP service may be discovered based a service name associated with the second IP service.
- the service name associated with the second IP service may include the same service descriptor for IP service as the service name associated with the first IP service.
- Each of the IP service names may also include an indication of a unique IP address associated with the respective device implementing the IP service within an IP subnet implemented by the SOA bus.
- the service names for the first IP service and the second IP service may also be implemented within a contiguous namespace implemented by the SOA bus.
- the first device transmits at least a first IP packet to the second device by remotely invoking the second IP service over the SOA bus.
- the first device may remotely call a function associated with the second IP service over the SOA bus, passing the first IP packet to the second IP service as an argument or parameter of the function.
- the first IP packet may be addressed to the unique IP address associated with the second device within the IP subnet implemented by the SOA bus.
- FIG. 8 is a flowchart illustrating another example of a method 800 of enabling IP connectivity over an SOA bus implemented by a peer-to-peer network, according to the principles of the present disclosure.
- the method 800 of FIG. 8 may be performed, for example, by one or more of the devices 115 described above with reference to FIGS. 1-6 .
- a new session is generated between the first and second IP services over the SOA bus at block 825 .
- the first IP service may remotely invoke the second IP service over the SOA bus at block 830 , passing the IP packet to the second IP service as a parameter or argument of a function or procedure of the second IP service.
- the first and second IP services may treat the IP packet as an object rather than a routable packet.
- FIG. 9 illustrates another example of a method 900 of enabling IP connectivity over an SOA bus implemented by a peer-to-peer network, according to the principles of the present disclosure.
- the method 900 of FIG. 9 may be performed, for example, by one or more of the devices 115 described above with reference to FIGS. 1-6 .
- the received IP packet is forwarded from the first IP service to a virtual network interface implemented at the first device.
- the virtual network interface may treat the IP packet as if the IP packet had been received as a conventional packet over a conventional network connection.
- the virtual network interface may initiate processing of the received IP packet at the IP layer.
- a TCP or UDP datagram may be extracted from the IP packet during IP layer processing. Data from the TCP or UDP datagram may be forwarded to the application layer based on the results of TCP or UDP processing. Additionally or alternatively, data from the TCP or UDP datagram may be used to update the status of a TCP or UDP socket.
- FIG. 10 is a flowchart illustrating another example of a method 1000 of enabling IP connectivity over an SOA bus implemented by a peer-to-peer network, according to the principles of the present disclosure.
- the method 1000 of FIG. 10 may be performed, for example, by one or more of the devices 115 described above with reference to FIGS. 1-6 .
- a second IP service associated with a second device connected to the SOA bus may be discovered.
- the SOA bus daemon running on the first device may receive a broadcast from an SOA bus daemon running on the second device which includes the name of the second IP service.
- the SOA bus daemon running on the first device may determine from the name of the second IP service that the second IP service is for IP communications, and forward the name of the second IP service to the first IP service.
- an IP packet addressed to the IP address associated with the second IP service is generated at the first device.
- the IP packet may be generated by an IP application at the first device.
- the IP packet is transmitted to the second device by remotely invoking the second IP service over the SOA bus and passing the IP packet to the second IP service as a parameter of invoking the second IP service.
- the IP packet may be an object associated with the syntax of a procedure or other function associated with the second IP service and remotely called by the first IP service.
- a permissible range of IP addresses in a current IP subnet implemented by the SOA bus is determined.
- one or more applications connected to the SOA bus may advertise the permissible range of IP addresses. Additionally or alternatively, the permissible range of IP addresses may be deterministically identified based on properties of the SOA bus.
- the SOA bus is queried for IP service name conflicts.
- the generated IP service name may be transmitted from an SOA bus daemon running on the first device to SOA bus daemons running on other devices connected to the SOA bus. If another device connected to the SOA bus is already using the IP service name generated for the first device (block 1125 , Yes), flow returns to block 1110 , where a new IP address is generated at the first device. Otherwise (block 1125 , No), the IP service name and IP address generated at the first device are assigned to the first device at block 1130 .
- FIG. 12 is a flowchart illustrating an example of a method 1200 of discovering IP services on an SOA bus, according to the principles of the present disclosure.
- the method 1200 of FIG. 12 may be performed, for example, by one or more of the devices 115 described above with reference to FIGS. 1-6 .
- an SOA bus daemon running on a device connected to the SOA bus receives the instruction to notify a first IP service running on the device of new IP services connecting to the SOA bus.
- an express instruction from the first IP service may be received at the SOA bus daemon. Additionally or alternatively, the instruction may be inherently provided to the SOA bus daemon as part of the underlying code of the SOA bus daemon.
- the first IP service receives notification of a new second IP service on the SOA bus.
- the first IP service receives a name of the second IP service and a location or address of the second IP service on the SOA bus.
- an IP address of the second IP service is identified based on the name associated with the second IP service.
- the IP address of the second IP service may be different from the location or address of the second IP service on the SOA bus.
- the IP address of the second IP service may be “192.168.0.12”
- the location of the second IP service on the SOA bus may be “:1.3”.
- the IP address of the second IP service is associated with the location of the second IP service on the SOA bus in a mapping table or other data structure maintained by the first IP service.
- FIG. 13 is a graphical representation of an ad hoc peer-to-peer (P2P) network defined using an SOA bus that provides networking between mobile devices.
- P2P peer-to-peer
- the multiple nodes that make up the ad hoc SOA bus network may not all have Internet access availability.
- gateway nodes 1300 and 1302 may be connected to the Internet 1304
- non-gateway nodes 1306 - 1314 may not be connected to the Internet 1304 .
- difficulties may arise in routing Internet traffic from a network node that does not have an Internet connection (a non-gateway node) to a network node that has such Internet connection (a gateway node).
- gateway node services of the adjacent gateway node may be utilized in the manner described above.
- multi-hop scenarios involving non-gateway nodes that are not adjacent to gateway nodes require additional solutions described below with reference to FIGS. 13-20 .
- FIG. 14 illustrates example blocks executed by gateway and non-gateway nodes to implement Internet-informed routing by modification of existing routing mechanisms in the ad hoc on-demand distance vector (AODV) routing standards.
- AODV routing provides for routing mechanisms for in-subnet routing.
- an indefinite destination is added to the destination field of the AODV internet route request message packets.
- a non-gateway node sends out the internet route request message to its neighbor nodes.
- the gateway node responds with its own address and a gateway flag.
- Each node that forwards the gateway node's response from the gateway node to the non-gateway node, from which the request originated, will update its gateway pointer to the address of the gateway node. Accordingly, when internet access is desired at a non-gateway node, the non-gateway node will have the appropriate routing information to obtain an access path to the Internet through the gateway node associated with its gateway pointer.
- the nodes of the ad hoc peer-to-peer network may be adapted to implement different procedures according to their respective roles in a given Internet routing procedure.
- Such a node may be adapted to operate in one of multiple different modes, as at block 1400 , depending on whether its role in the Internet routing procedure is to operate as a source non-gateway node, an intermediate non-gateway node, or a gateway node. For example, if the node wishes to transmit Internet packets over the Internet, but lacks an Internet connection, then the node may operate in a source non-gateway node mode, in which case processing may begin at block 1402 .
- the node may operate in an intermediate non-gateway node mode, in which case processing may begin at block 1404 . Further, if the node has received an Internet route request from a neighbor node, and if it does have an Internet connection, then the node may operate in a gateway node mode, in which case processing may begin at block 1406 .
- a source non-gateway node may transmit IP packets based on that information. However, if the source non-gateway node does not have such information, or if an attempt to use a gateway node fails or is unsatisfactory, then the source non-gateway node may send an Internet route request (I-RREQ).
- the source non-gateway node may send the I-RREQ to a destination IN_ADDR_ANY (e.g., all zeros), which may be defined in the modified AODV protocol as a non-specific address that triggers sending of I-RREQ message over the network by a flooding technique.
- the non-gateway nodes may be adapted to transmit and forward a route request message having the non-specific destination address to all neighbor nodes, excepting those neighbor nodes from which it receive the I-RREQ, or from which it received an identical I-RREQ.
- the I-RREQ message may be identical to a typical AODV route request message (RREQ), excepting that the destination address is IN-ADDR_ANY (all zeros).
- the network nodes and/or gateway nodes may further be adapted to distinguish an I-RREQ from an RREQ based partly or entirely on the IN_ADDR_ANY destination address. Processing at the source non-gateway node may proceed from block 1402 to 1418 .
- the intermediate non-gateway node may receive the I-RREQ that was sent by the source non-gateway node at block 1402 . If the intermediate non-gateway node is a neighbor of the source non-gateway node, then the intermediate non-gateway node may receive the I-RREQ directly from the source non-gateway node. Alternatively or additionally, the intermediate non-gateway node may receive the I-RREQ from another non-gateway node. It is envisioned that the intermediate non-gateway node may receive multiple copies of the I-RREQ from multiple, different neighbor nodes. Processing at the intermediate non-gateway node may proceed from block 1404 to block 1408 .
- the intermediate non-gateway node may update and relay the I-RREQ to other neighbor nodes according to the flooding technique, as previously described. It is envisioned that, in the event that multiple copies of the I-RREQ were received from multiple, different neighbor nodes, the intermediate non-gateway node may selectively update and relay the I-RREQ to other neighbor nodes based on one or more predefined criteria, such as first I-RREQ received, lowest hop count, shortest relay path, or combination thereof. It is alternatively or additionally envisioned that the intermediate node may edit, update, and forward the I-RREQ in the same manner defined for RREQ in the existing AODV standard, excepting for the forwarding according to the flooding technique, as described above. Processing at the intermediate non-gateway node may proceed from block 1408 to block 1412 .
- the gateway node may receive the I-RREQ from one or more neighbor nodes. It is envisioned that the gateway node may distinguish the I-RREQ from a typical AODV RREQ by the non-specific destination address. Processing at the gateway node may proceed from block 1406 to block 1410 .
- the gateway node may respond to a received I-RREQ by sending an Internet route reply message (I-RREP) to the neighbor node from which it received the I-RREQ.
- I-RREP Internet route reply message
- the gateway node may respond to all of the I-RREQs.
- the gateway node may preferentially respond to less than all copies of an I-RREQ based on one or more predefined criteria, such as first I-RREQ received, lowest hop count, shortest relay path, or combination thereof.
- the I-RREP may have a destination address of the gateway node and a gateway indicator, such as a set gateway flag.
- the gateway indicator may be defined in the modified AODV protocol as a flag, field, hash, encryption, mask, or any other type of distinguishing characteristic that permits nodes of the network to distinguish the I-RREP from a typical AODV route reply message (RREP). Stated differently, it is envisioned that the I-RREP may be identical to a typical AODV RREP, excepting that the I-RREP has the gateway indicator. Processing at the gateway node may proceed from block 1410 to block 1426 .
- the intermediate non-gateway node may receive the I-RREP having the destination address of the gateway node and the gateway indicator, as described above.
- the I-RREP may also have a hop count, relay path, and other information typical of an RREP of the AODV protocol.
- the intermediate non-gateway node may distinguish the I-RREP from a typical AODV RREP based on the gateway indicator, and may proceed from block 1412 to block 1414 on that basis.
- the intermediate non-gateway node may receive multiple I-RREPs in response to the same I-RREQ, and that originate from multiple, different gateway nodes.
- the intermediate non-gateway node may make a determination whether to respond to such an I-RREP based on one or more predefined criteria, such as first I-RREP received, lowest hop count, shortest relay path, or combination thereof.
- the source non-gateway node may process all I-RREPs received.
- the intermediate non-gateway node may update its gateway pointer to the destination address of the gateway node contained in the I-RREP. It is envisioned that the intermediate non-gateway network node may have one or multiple gateway pointers, and may instantiate new gateway pointers, update or expire existing gateway pointers, and/or prioritize gateway pointers based on one or more predefined criteria. Example criteria may include most recent I-RREP received, lowest hop count, shortest relay path, presence or lack thereof of low mobility nodes in the relay path, quality of service of an Internet connection via the gateway node, or combinations thereof. Processing at the intermediate non-gateway node may proceed from block 1414 to block 1416 .
- the intermediate non-gateway node may relay the I-RREP to the neighbor node specified in the relay path of the I-RREP. Before doing so, the intermediate non-gateway node may edit and update the I-RREP in the same manner as a typical AODV RREP is processed, such as updating the hop count, and other procedures as will be readily apparent to one skilled in the art. Processing at the intermediate non-gateway node may proceed from block 1416 to block 1424 .
- the source non-gateway node may receive the Internet route response (I-RREP) from a neighbor node.
- the source non-gateway node may distinguish the I-RREP from a typical AODV RREP based on the gateway indicator, and may proceed from block 1418 to block 1420 on that basis.
- the source non-gateway node may receive multiple I-RREPs in response to the same I-RREQ, and that originate from multiple, different gateway nodes.
- the intermediate non-gateway node may make a determination whether to respond to such an I-RREP based on one or more predefined criteria, such as first I-RREP received, lowest hop count, shortest relay path, or combination thereof.
- the source non-gateway node may process all I-RREPs received.
- the source non-gateway node may update its gateway pointer to the destination address of the gateway node contained in the I-RREP. It is envisioned that the source non-gateway network node may have one or multiple gateway pointers, and may instantiate new gateway pointers, update or expire existing gateway pointers, and/or prioritize gateway pointers based on one or more predefined criteria. Example criteria may include most recent I-RREP received, lowest hop count, shortest relay path, presence or lack thereof of low mobility nodes in the relay path, quality of service of an Internet connection via the gateway node, or combinations thereof. Processing at the source non-gateway node may proceed from block 1420 to block 1422 .
- the intermediate non-gateway node may perform routing operations to relay IP packets between source non-gateway nodes and a gateway node.
- the intermediate non-gateway node may receive tunneled IP packets having a destination address of a particular gateway node. In this case, the intermediate non-gateway node may simply forward the IP packets to the destination address of the particular gateway node.
- the intermediate non-gateway node may receive IP packets that are not tunneled, and that therefore have an Internet destination. When IP packets are received that have an Internet destination, the intermediate non-gateway node may check its own gateway pointer or pointers for a more desirable gateway than the originally-addressed gateway node.
- the intermediate non-gateway node may perform routing operations to forward the IP packets to an address associated with its own gateway pointer.
- the intermediate non-gateway node may potentially reroute received IP packets having an Internet destination to a different gateway node.
- Tunneling Internet-destined packets allows for greater use of existing AODV routing mechanisms, as the transmitted packets appear to be specifically addressed to nodes within the subnet. However, while the packets are masked from any intermediate nodes along the transmission route, tunneled packets may not benefit from potential gateway re-routing during the journey.
- the gateway node may perform routing operations to receive IP packets from the source non-gateway node.
- Block 1426 may include receiving tunneled or non-tunneled IP packets directly from the source non-gateway node, and/or receiving tunneled or non-tunneled packets from an intermediate non-gateway node. If the IP packets are tunneled, then the gateway node may un-tunnel the IP packets by unmasking the destination address of the IP packets, thereby obtaining the Internet destination of the received IP packets. Processing at the gateway node may proceed from block 1426 to block 1428 .
- the gateway node may transmit and receive IP packets over the Internet.
- the gateway node may obtain or assign an IP address for receiving IP packets intended for the source non-gateway node, and may use the Internet destination and the obtained or assigned IP address to transmit the IP packets over the Internet, and receive IP packets over the Internet that are intended for the source non-gateway node.
- the gateway node may distinguish these IP packets from other received IP packets on the basis of the destination address corresponding to the IP address obtained or assigned for receiving IP packets intended for the source non-gateway node. Processing at the gateway node may proceed from block 1428 to block 1430 .
- the gateway node may perform routing operations to send IP packets, to the source non-gateway node, that were received over the Internet and intended for the source non-gateway node. It is envisioned that the gateway node may use tunneling to send the IP packets to the source non-gateway node by masking the destination address of the received IP packets with the destination address of the source non-gateway node. As mentioned above, tunneling IP packets received over the Internet allows for greater use of existing AODV routing mechanisms, as the transmitted packets appear to be specifically addressed to nodes within the subnet. Accordingly, the source non-gateway node may, at block 1422 , receive the IP packets either directly or indirectly from the gateway node.
- the source non-gateway node may receive the IP packets from a neighbor node that did not participate as an intermediate non-gateway node in relay of the I-RREQ, I-RREP, and IP packets destined for the Internet or gateway node. It is also envisioned that intermediate non-gateway node may, at block 1424 , receive the IP packets and relay the IP packets to the source non-gateway node.
- FIG. 15 illustrates an example of operation of ad hoc peer-to-peer network nodes according to the modified AODV implementation.
- three non-gateway nodes 1500 , 1502 , and 1504 exchange messages with one another. These non-gateway nodes also exchange messages with gateway nodes 1506 and 1508 . These message exchanges are performed in order to carry out Internet informed routing of Internet-destined IP packets according to this aspect of the disclosure.
- non-gateway node 1500 wishing to transmit IP packets to the Internet, and not already knowing a suitable Gateway node destination address, may generate a I-RREQ as described above, and transmit the I-RREQ to its neighbor nodes at 1510 .
- Non-gateway node 1502 may receive the I-RREQ from non-gateway node 1500 , and may forward the I-RREQ to all other neighbors at 1512 .
- non-gateway node 1504 may receive the I-RREQ from non-gateway node 1502 , and may forward the I-RREQ to all other neighbors at 1514 .
- gateway node 1506 may receive the I-RREQ from non-gateway node 1514 , and may respond by transmitting, at 1516 , an I-RREP to a neighbor node in the relay path.
- non-gateway node 1500 upon receiving the I-RREP from non-gateway node 1502 , may update its gateway pointer to the destination address of the gateway node. Accordingly, all of the non-gateway nodes 1500 , 1502 , and 1504 in the relay path may have pointers updated to the destination address of gateway node 1506 .
- non-gateway nodes 1500 , 1502 , and 1504 may utilize their respective gateway pointers to attempt to route received IP packets to the gateway node 1506 .
- non-gateway node 1500 may use its gateway pointer to send and receive IP packets to and from the gateway node 1506 , with or without tunneling. If tunneling is not employed, then the non-gateway nodes 1502 and 1504 may utilize their respective gateway pointers to forward the IP packets to the gateway node 1506 .
- non-gateway node 1502 may also wish to send IP packets to gateway node 1506 , and may use its gateway pointer to attempt to do so at 1524 .
- This attempt may fail for any one of various reasons, such as gateway node 1506 going offline, leaving the area, losing its Internet connection, or failing to provide sufficient quality of service.
- the non-gateway node 1502 may respond to failure of the attempt at 1526 by sending an I-RREQ to all neighbors at 1526 and 1528 .
- the non-gateway node 1504 may receive the I-RREQ from non-gateway node 1504 , and relay the I-RREQ, at 1530 , to a new neighbor gateway node 1508 .
- the new neighbor gateway node 1508 may receive the I-RREQ and respond by transmitting, at 1532 , an I-RREP to non-gateway node 1504 .
- Non-gateway node 1504 may update its gateway pointer to the destination address of the gateway node 1508 , and may forward the I-RREP, at 1534 , to non-gateway node 1502 .
- Non-gateway node 1502 may then update its own gateway pointer to the destination address of the gateway node 1508 , and use the updated gateway pointer, at 1536 , to send Internet-destined IP packets to gateway node 1508 , either with or without tunneling.
- non-gateway node 1502 does not forward the I-RREP to non-gateway node 1500 , because non-gateway node 1502 is at the end of the relay path. Also, non-gateway node 1500 merely discarded the I-RREQ that it received from non-gateway node 1502 because it has no other neighbor nodes. Accordingly, non-gateway node 1500 never received any I-RREP except for the I-RREP it received at 1520 from gateway node 1506 . Therefore, the gateway pointer of non-gateway node 1500 may still point to gateway node 1506 .
- non-gateway node 1500 may use its updated pointer to reroute the IP packets, at 1540 , to gateway node 1508 , with or without tunneling.
- non-gateway node 1500 may update its gateway pointer to the destination address of gateway node 1508 , and continue to send and receive IP packets, at 1542 , to and from gateway node 1508 .
- FIG. 16 illustrates example blocks executed by gateway and non-gateway nodes to implement Internet-informed routing by using the unmodified AODV routing and lists of potential gateway nodes. These lists are maintained and updated at non-gateway nodes in response to SOA bus announcements of gateway node capabilities. As a gateway node joins the SOA bus, it broadcasts an announcement of its capabilities as a gateway node. Each non-gateway node on the SOA bus creates a list of potential gateways based on the announcement. When the non-gateway node desires to establish an Internet connection, one of the gateway nodes is selected from the maintained list of potential gateways. Because the non-gateway node has the definite address information in the list, it may follow the typical AODV routing mechanism in order to route to the specific gateway node.
- the nodes of the ad hoc peer-to-peer network may be adapted to implement different procedures according to their respective roles in a given Internet routing procedure.
- Such a node may be adapted to operate in one of multiple different modes, as at block 1600 , depending on whether its role in the Internet routing procedure is to operate as a source non-gateway node, an intermediate non-gateway node, or a gateway node. For example, if the node wishes to transmit Internet packets over the Internet, but lacks an Internet connection, then the node may operate in a source non-gateway node mode, in which case processing may begin at block 1602 .
- the node may operate in an intermediate non-gateway node mode, in which case processing may begin at block 1604 . Further, if the node has received an Internet route request from a neighbor node, and if it does have an Internet connection, then the node may operate in a gateway node mode, in which case processing may begin at block 1606 .
- the gateway node may announce Internet connectivity as a service on the SOA bus. This announcement may be accomplished in the manner previously described. Processing at the gateway node may proceed from block 1606 to block 1608 .
- the intermediate non-gateway node may receive the SOA bus messages regarding Internet connectivity.
- the receipt of the SOA bus messages may be accomplished in the manner previously described. Processing at the intermediate non-gateway node may proceed from block 1604 to block 1610 .
- the source non-gateway node may receive the SOA bus messages regarding Internet connectivity.
- the receipt of the SOA bus messages may be accomplished in the manner previously described. Processing at the source non-gateway node may proceed from block 1602 to block 1612 .
- the intermediate non-gateway node may update its list of potential gateway nodes based on the SOA bus messages. It is envisioned that the intermediate non-gateway node may instantiate new gateway pointers, update or expire existing gateway pointers, and/or prioritize gateway pointers based on one or more predefined criteria. Example criteria may include lowest hop count, presence or lack thereof of low mobility nodes in the relay path, quality of service of an Internet connection via the gateway node, or combinations thereof. Processing at the intermediate non-gateway node may proceed from block 1610 to block 1614 .
- the source non-gateway node may update its list of potential gateway nodes based on the SOA bus messages. It is envisioned that the source non-gateway node may instantiate new gateway pointers, update or expire existing gateway pointers, and/or prioritize gateway pointers based on one or more predefined criteria. Example criteria may include lowest hop count, presence or lack thereof of low mobility nodes in the relay path, quality of service of an Internet connection via the gateway node, or combinations thereof. Processing at the source non-gateway node may proceed from block 1612 to block 1616 .
- the source non-gateway node may perform routing operations to send and receive IP packets to and from a destination address selected from its list of potential gateway nodes.
- the routing may be accomplished, with or without tunneling, in the manner previously described.
- the intermediate non-gateway node may perform routing operations to relay IP packets between a source non-gateway node and a gateway node.
- the routing may be accomplished, with or without tunneling, in the manner previously described.
- the intermediate non-gateway node may select a destination address from its own list of potential gateway nodes, thus giving rise to potential rerouting of the IP packets.
- the gateway node may perform routing operations to receive Internet-destined IP packets from the source non-gateway node.
- the routing may be accomplished with or without tunneling, in the manner previously described. Processing at the gateway node may proceed from block 1608 to block 1618 .
- the gateway node may transmit and receive IP packets over the Internet.
- the transmission and receipt of IP packets of the Internet may be accomplished in the manner previously described. Processing at the gateway node may proceed from block 1618 to block 1620 .
- the gateway node may perform routing operations to route IP packets received from the Internet to the source non-gateway node.
- the routing may be accomplished, with or without tunneling, in the manner previously described.
- FIG. 17 illustrates an example of operation of ad hoc peer-to-peer network nodes according to the unmodified AODV implementation.
- three non-gateway nodes 1700 , 1702 , and 1704 exchange messages with one another.
- These non-gateway nodes also exchange messages with gateway nodes 1706 and 1708 .
- These message exchanges are performed in order to carry out Internet informed routing of Internet-destined IP packets according to this aspect of the disclosure.
- gateway node 1706 may, via the SOA bus, broadcast SOA announcements 1710 , 1712 , and 1714 of its gateway capabilities to non-gateway nodes 1700 , 1702 , and 1704 , respectively.
- Each of non-gateway nodes 1700 , 1702 , and 1704 may update their respective lists of potential gateway nodes in response to the SOA bus announcements 1710 , 1712 , and 1714 . Thereafter, any of these non-gateway nodes 1700 , 1702 , and 1704 may select the destination address of gateway node 1706 from their respective lists, and route IP packets 1716 to gateway node 1706 , with or without tunneling.
- Non-gateway nodes 1700 , 1702 , and 1704 may update their lists based on various criteria, such as quality of service of an Internet connection provided by gateway node 1706 . It should be understood that non-gateway node 1700 may not be privy to information regarding quality of service of such a connection that may be observed by another non-gateway node, such as non-gateway node 1702 . Additionally, further SOA bus announcements 1718 , 1720 , and 1722 , may commission new gateway nodes, such as gateway node 1708 , and decommission existing gateway nodes, such as gateway node 1706 . It should be understood that some non-gateway nodes may receive SOA bus announcements more quickly than other nodes.
- non-gateway nodes 1700 and 1702 may have different lists, and non-gateway node 1702 may have reason to regard its list as better informed than the list of non-gateway node 1700 . Therefore, when non-gateway node attempts, at 1724 , to send Internet-destined IP packets to gateway node 1706 , non-gateway node 1702 may use its more reliable list to reroute the IP packets, at 1726 , to gateway node 1708 .
- non-gateway node 1700 may update its list to add the destination address of gateway node 1708 , and remove, expire, or demote the destination address of gateway node 1706 . It should be readily appreciated that, since non-gateway node 1702 may sometimes reroute received IP packets based on quality of service information that may not be appreciated by downstream non-gateway node 1704 , non-gateway node 1702 may use tunneling to direct the rerouted IP packets to gateway node 1708 . For the same reasons, non-gateway node 1700 may additionally switch to a tunneling mode for sending packets to gateway node 1708 .
- FIG. 18 illustrates example blocks executed by non-gateway nodes to implement Internet-informed routing by modification of existing routing mechanisms in the AODV routing standards.
- the non-gateway node may transmit an Internet route request for an indefinite destination to one or more neighbor nodes in the network.
- processors 305 FIG. 3
- main memory 310 and/or local storage 315 may be used to operate I/O devices 320 , Bluetooth interface 325 , WLAN interface 330 , and virtual network interface 335 , to generate the Internet route request and send the Internet route request to neighbor nodes according to the process described above with reference to FIG. 14 and FIG. 15 .
- Processing at the non-gateway node may proceed from block 1800 to block 1802 .
- the combination of such acts and components may comprise means for transmitting, by the non-gateway node, an Internet route request for an indefinite destination to one or more neighbor nodes in the network.
- the non-gateway node may receive a response message from at least one gateway node on the network, wherein the response message includes an address of the at least one gateway node and a gateway indicator.
- processors 305 FIG. 3
- main memory 310 and/or local storage 315 may access instructions stored in main memory 310 and/or local storage 315 to operate I/O devices 320 , Bluetooth interface 325 , WLAN interface 330 , and virtual network interface 335 , to receive the Internet route response according to the process described above with reference to FIG. 14 and FIG. 15 .
- Processing at the non-gateway node may proceed from block 1802 to block 1804 .
- the combination of such acts and components may comprise means for receiving, at the non-gateway node, a response message from at least one gateway node on the network, wherein the response message includes an address of the at least one gateway node and a gateway indicator.
- the non-gateway node may set, at the non-gateway node, a gateway pointer equal to the address of the at least one gateway node.
- processors 305 FIG. 3
- the combination of such acts and components may comprise means for setting, at the non-gateway node, a gateway pointer equal to the address of the at least one gateway node.
- FIG. 19 illustrates example blocks executed by gateway nodes to implement Internet-informed routing by modification of existing routing mechanisms in the ad hoc on-demand distance vector (AODV) routing standards.
- the gateway node may receive an Internet route request from one or more neighbor nodes in the network.
- processors 305 FIG. 3
- main memory 310 and/or local storage 315 may be used to operate I/O devices 320 , Bluetooth interface 325 , WLAN interface 330 , and virtual network interface 335 , to receive the Internet route request according to the process described above with reference to FIG. 14 and FIG. 15 .
- Processing at the gateway node may proceed from block 1900 to block 1902 .
- the combination of such acts and components may comprise means for receiving, at a gateway node, an Internet route request from one or more neighbor nodes in the network.
- the gateway node may transmit a response message to the one or more neighbor nodes, wherein the response message includes an address of the gateway node and a gateway indicator.
- processors 305 FIG. 3
- the combination of such acts and components may comprise means for transmitting, from a gateway node, a response message to the one or more neighbor nodes, wherein the response message includes an address of the gateway node and a gateway indicator.
- FIG. 20 illustrates example blocks executed by non-gateway nodes to implement Internet-informed routing by using the unmodified AODV routing and lists of potential gateway nodes.
- the non-gateway node may receive an announcement of Internet connectivity from one or more gateway nodes on the network, wherein the announcement includes an address of the one or more neighbor nodes.
- processors 305 FIG.
- Processing at the non-gateway node may proceed from block 2000 to block 2002 .
- the combination of such acts and components may comprise means for receiving, at a non-gateway node, an announcement of Internet connectivity from one or more gateway nodes on the network, wherein the announcement includes an address of the one or more neighbor nodes.
- the non-gateway node may store the address of the one or more gateway nodes to a list of potential gateways.
- processors 305 FIG. 3
- Processing at the non-gateway node may proceed from block 2002 to block 2004 .
- the combination of such acts and components may comprise means for storing, at a non-gateway node, the address of the one or more gateway nodes to a list of potential gateways.
- the non-gateway node may receive packets for transmission to an Internet destination.
- processors 305 FIG. 3
- Processing at the non-gateway node may proceed from block 2004 to block 2006 .
- the combination of such acts and components may comprise means for receiving packets for transmission to an Internet destination.
- the non-gateway node may select a gateway address from the list of potential gateways.
- processors 305 FIG. 3
- Processing at the non-gateway node may proceed from block 2006 to block 2008 .
- the combination of such acts and components may comprise means for selecting a gateway address from the list of potential gateways.
- the non-gateway node may transmit the packets to a destination gateway associated with the gateway address.
- processors 305 FIG. 3
- the combination of such acts and components may comprise means for to transmitting the packets to a destination gateway associated with the gateway address
- a CDMA system may implement a radio technology such as CDMA2000, Universal Terrestrial Radio Access (UTRA), etc.
- CDMA2000 covers IS-2000, IS-95, and IS-856 standards.
- IS-2000 Releases 0 and A are commonly referred to as CDMA2000 1 ⁇ , 1 ⁇ , etc.
- IS-856 (TIA-856) is commonly referred to as CDMA2000 1 ⁇ EV-DO, High Rate Packet Data (HRPD), etc.
- UTRA includes Wideband CDMA (WCDMA) and other variants of CDMA.
- a TDMA system may implement a radio technology such as Global System for Mobile Communications (GSM).
- GSM Global System for Mobile Communications
- An OFDMA system may implement a radio technology such as Ultra Mobile Broadband (UMB), Evolved UTRA (E-UTRA), IEEE 802.11 (Wi-Fi), IEEE 802.16 (WiMAX), IEEE 802.20, Flash-OFDMA, etc.
- UMB Ultra Mobile Broadband
- E-UTRA Evolved UTRA
- Wi-Fi Wi-Fi
- WiMAX IEEE 802.16
- IEEE 802.20 Flash-OFDMA
- UTRA and E-UTRA are part of Universal Mobile Telecommunication System (UMTS).
- 3GPP Long Term Evolution (LTE) and LTE-Advanced (LTE-A) are new releases of UMTS that use E-UTRA.
- UTRA, E-UTRA, UMTS, LTE, LTE-A, and GSM are described in documents from an organization named “3rd Generation Partnership Project” (3GPP).
- Information and signals may be represented using any of a variety of different technologies and techniques.
- data, instructions, commands, information, signals, bits, symbols, and chips that may be referenced throughout the above description may be represented by voltages, currents, electromagnetic waves, magnetic fields or particles, optical fields or particles, or any combination thereof.
- DSP digital signal processor
- ASIC application specific integrated circuit
- FPGA field programmable gate array
- a general-purpose processor may be a microprocessor, but in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine.
- a processor may also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, multiple microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration.
- the functions described herein may be implemented in hardware, software executed by a processor, firmware, or any combination thereof. If implemented in software executed by a processor, the functions may be stored on or transmitted over as one or more instructions or code on a computer-readable medium. Other examples and implementations are within the scope and spirit of the disclosure and appended claims. For example, due to the nature of software, functions described above can be implemented using software executed by a processor, hardware, firmware, hardwiring, or combinations of any of these. Features implementing functions may also be physically located at various positions, including being distributed such that portions of functions are implemented at different physical locations.
- Computer-readable media includes both computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another.
- a storage medium may be any available medium that can be accessed by a general purpose or special purpose computer.
- computer-readable media can comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to carry or store desired program code means in the form of instructions or data structures and that can be accessed by a general-purpose or special-purpose computer, or a general-purpose or special-purpose processor.
- any connection is properly termed a computer-readable medium.
- Disk and disc include compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk and blu-ray disc where disks usually reproduce data magnetically, while discs reproduce data optically with lasers. Combinations of the above are also included within the scope of computer-readable media.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Mobile Radio Communication Systems (AREA)
- Small-Scale Networks (AREA)
Abstract
In some aspects, a non-gateway node transmits an internet route request to neighbor nodes and receives, from a gateway node, a response message including an address of the gateway node and a gateway indicator. The non-gateway node sets a gateway pointer equal to this address. In other aspects, a gateway node receives an internet route request from neighbor nodes and transmits, to the neighbor nodes, a response message including an address of the gateway node and a gateway indicator. In additional aspects, a non-gateway node receives, from gateway nodes on the network, an announcement of internet connectivity that includes address of the gateway nodes. The non-gateway node adds these addresses to a list of potential gateways. When the non-gateway nodes receives packets for transmission to an internet destination, it selects a gateway address from the list, and transmits the packets to a destination gateway associated with the gateway address.
Description
- This application is a division of U.S. patent application Ser. No. 13/786,376, entitled “INTERNET ROUTING OVER A SERVICE-ORIENTED ARCHITECTURE BUS,” filed on Mar. 5, 2013, which is a continuation in part of U.S. patent application Ser. No. 13/400,889, entitled, “INTERNET PROTOCOL CONNECTIVITY OVER A SERVICE-ORIENTED ARCHITECTURE BUS”, filed on Feb. 21, 2012, the disclosures of which are expressly incorporated by reference herein in their entirety.
- The following relates generally to service-oriented architectures (SOAs), and in particular to the implementation of Internet routing over an SOA bus.
- In a service-oriented architecture, one or more nodes may communicate with each other to offer each other interoperable services. In this context, a service can be thought of as an autonomous unit of functionality implemented by self-contained software. A typical implementation of service-oriented architecture functionality may include a number of computer nodes interconnected by a computer network. Each node may communicate with the other nodes to identify services offered by the other nodes. Each node may also advertise one or more services to the other nodes.
- For a first node to invoke a service offered by a second node in a service-oriented architecture, the first node may transmit a remote procedure call to the second node, the remote procedure call being supported by the selected service. The remote procedure call may include one or more arguments or other parameters provided by the first node. The second node may respond to the remote procedure call by executing one or more software functions based on the type of call and/or the parameters provided. In some examples, the second node may provide a result of the remote procedure call to the first node.
- Recently, the use of service-oriented architecture buses (also known as service buses) has increased. Service-oriented architecture buses facilitate communication between mutually interacting software applications to allow the applications to invoke each other's services. As the use of service-oriented architecture buses grows, new uses of these buses continue to develop.
- In some aspects, a method for routing in an ad hoc peer-to-peer network, includes transmitting, from a non-gateway node, an internet route request for an indefinite destination to one or more neighbor nodes on the network. The method also includes receiving, at the non-gateway node, a response message from at least one gateway node on the network, wherein the response message includes an address of the at least one gateway node and a gateway indicator. The method additionally includes setting, at the non-gateway node, a gateway pointer equal to the address of the at least one gateway node.
- In other aspects, a method for routing in an ad hoc peer-to-peer network, includes receiving, at a gateway node, an internet route request from one or more neighbor nodes on the network. The method also includes transmitting, from the gateway node, a response message to the one or more neighbor nodes, wherein the response message includes an address of the gateway node and a gateway indicator.
- In additional aspects, a method for routing in an ad hoc peer-to-peer network, includes receiving, at a non-gateway node, an announcement of internet connectivity from one or more gateway nodes on the network, wherein the announcement includes an address of the one or more gateway nodes. The method also includes storing, at the non-gateway node, the address of the one or more gateway nodes to a list of potential gateways. The method additionally includes receiving packets for transmission to an internet destination. The method further includes selecting a gateway address from the list of potential gateways. The method still further includes transmitting the packets to a destination gateway associated with the gateway address.
- In further aspects, an apparatus for routing in an ad hoc peer-to-peer network includes means for transmitting, from a non-gateway node, an internet route request for an indefinite destination to one or more neighbor nodes on the network. The apparatus also includes means for receiving, at the non-gateway node, a response message from at least one gateway node on the network, wherein the response message includes an address of the at least one gateway node and a gateway indicator. The apparatus additionally includes means for setting, at the non-gateway node, a gateway pointer equal to the address of the at least one gateway node.
- In still other aspects, an apparatus for routing in an ad hoc peer-to-peer network includes means for receiving, at a gateway node, an internet route request from one or more neighbor nodes on the network. The apparatus also includes means for transmitting, from the gateway node, a response message to the one or more neighbor nodes, wherein the response message includes an address of the gateway node and a gateway indicator.
- In still additional aspects, an apparatus for routing in an ad hoc peer-to-peer network includes means for receiving, at a non-gateway node, an announcement of internet connectivity from one or more gateway nodes on the network, wherein the announcement includes an address of the one or more gateway nodes. The apparatus also includes means for storing, at the non-gateway node, the address of the one or more gateway nodes to a list of potential gateways. The apparatus additionally includes means for receiving packets for transmission to an internet destination. The apparatus further includes means for selecting a gateway address from the list of potential gateways. The apparatus still further includes means for transmitting the packets to a destination gateway associated with the gateway address.
- In still further aspects a computer program product includes a non-transitory computer-readable medium. The non-transitory computer-readable medium includes code for transmitting, from a non-gateway node, an internet route request for an indefinite destination to one or more neighbor nodes in an ad hoc peer-to-peer network. The non-transitory computer-readable medium also includes code for receiving, at the non-gateway node, a response message from at least one gateway node on the network, wherein the response message includes an address of the at least one gateway node and a gateway indicator. The non-transitory computer-readable medium additionally includes code for setting, at the non-gateway node, a gateway pointer equal to the address of the at least one gateway node.
- In yet other aspects, a computer program product includes a non-transitory computer-readable medium. The non-transitory computer-readable medium includes code for receiving, at a gateway node, an internet route request from one or more neighbor nodes on an ad hoc peer-to-peer network. The non-transitory computer-readable medium also includes code for transmitting, from the gateway node, a response message to the one or more neighbor nodes, wherein the response message includes an address of the gateway node and a gateway indicator.
- In yet additional embodiments, a computer program product includes a non-transitory computer-readable medium. The non-transitory computer-readable medium includes code for receiving, at a non-gateway node, an announcement of internet connectivity from one or more gateway nodes on an ad hoc peer-to-peer network, wherein the announcement includes an address of the one or more gateway nodes. The non-transitory computer-readable medium also includes code for storing, at the non-gateway node, the address of the one or more gateway nodes to a list of potential gateways. The non-transitory computer-readable medium additionally includes code for receiving packets for transmission to an internet destination. The non-transitory computer-readable medium further includes code for selecting a gateway address from the list of potential gateways. The non-transitory computer-readable medium still further includes code for transmitting the packets to a destination gateway associated with the gateway address.
- In yet further embodiments, a non-gateway node in an ad hoc peer-to-peer network includes one or more processors and a memory coupled to the one or more processors. The one or more processors are configured to transmit, from the non-gateway node, an internet route request for an indefinite destination to one or more neighbor nodes on the network. The one or more processors are also configured to receive, at the non-gateway node, a response message from one or more gateway nodes on the network, wherein the response message includes an address of the one or more gateway nodes and a gateway indicator. The one or more processors are configured to set, at the non-gateway node, a gateway pointer equal to the address of the one or more gateway nodes.
- In other embodiments, a non-gateway node in an ad hoc peer-to-peer network, includes one or more processors and a memory coupled to the one or more processors. The one or more processors are configured to receive, at a gateway node, an internet route request from one or more neighbor nodes on an ad hoc peer-to-peer network. The one or more processors are additionally configured to transmit, from the gateway node, a response message to the one or more neighbor nodes, wherein the response message includes an address of the gateway node and a gateway indicator.
- In additional embodiments, a non-gateway node in an ad hoc peer-to-peer network includes one or more processors and a memory coupled to the one or more processors. The one or more processors are configured to receive, at the non-gateway node, an announcement of internet connectivity from one or more gateway nodes on the network, wherein the announcement includes an address of the one or more gateway nodes. The one or more processors are also configured to store, at the non-gateway node, the address of the one or more gateway nodes to a list of potential gateways. The one or more processors is additionally configured to receive packets for transmission to an internet destination. The one or more processors are further configured to select a gateway address from the list of potential gateways. The one or more processors are configured to transmit the packets to a destination gateway associated with the gateway address.
- A further understanding of the nature and advantages of the present invention may be realized by reference to the following drawings. In the appended figures, similar components or features may have the same reference label. Further, various components of the same type may be distinguished by following the reference label by a dash and a second label that distinguishes among the similar components. If only the first reference label is used in the specification, the description is applicable to any one of the similar components having the same first reference label irrespective of the second reference label.
-
FIG. 1 shows a block diagram of an example system for implementing Internet Protocol (IP) connectivity over a Service-Oriented Architecture (SOA) bus; -
FIG. 2 shows a block diagram of a wireless communications system; -
FIG. 3 shows a block diagram of an example system for implementing IP connectivity over an SOA bus; -
FIG. 4 shows a block diagram of example communication signals between a first IP service of a first device and a second IP service of a second device over an SOA bus; -
FIG. 5 shows a block diagram of an example device configured to transmit and receive IP packets over an SOA bus; -
FIG. 6 shows a block diagram of an example device configured to transmit and receive IP packets over an SOA bus; -
FIG. 7 shows a flowchart of an example method for implementing IP connectivity over an SOA bus; -
FIG. 8 shows a flowchart of an example method for implementing IP connectivity over an SOA bus; -
FIG. 9 shows a flowchart of an example method for implementing IP connectivity over an SOA bus; -
FIG. 10 shows a flowchart of an example method for implementing IP connectivity over an SOA bus; -
FIG. 11 shows a flowchart of an example method for generating an IP address for use in IP communications over an SOA bus; -
FIG. 12 shows a flowchart of an example method for discovering IP services for implementing IP connectivity over an SOA bus; -
FIG. 13 shows an ad hoc peer-to-peer network including gateway nodes and non-gateway nodes in accordance with the present disclosure; -
FIG. 14 shows a functional block diagram conceptually illustrating example blocks executed by gateway and non-gateway nodes to implement one aspect of the disclosure; -
FIG. 15 shows a data flow diagram conceptually illustrating an example of message exchanges executed by gateway and non-gateway nodes to implement one aspect of the disclosure; -
FIG. 16 shows a functional block diagram conceptually illustrating example blocks executed by gateway and non-gateway nodes to implement one aspect of the disclosure; -
FIG. 17 shows a data flow diagram conceptually illustrating an example of message exchanges executed by gateway and non-gateway nodes to implement one aspect of the disclosure; -
FIG. 18 shows a functional block diagram conceptually illustrating example blocks executed by non-gateway nodes to implement one aspect of the disclosure; -
FIG. 19 shows a functional block diagram conceptually illustrating example blocks executed by gateway nodes to implement one aspect of the disclosure; -
FIG. 20 shows a functional block diagram conceptually illustrating example blocks executed by non-gateway nodes to implement one aspect of the disclosure; - The implementation of IP communications over an SOA bus is described. Devices coupled with the SOA bus may advertise and implement separate instances of an IP service. Each IP service may have an IP address in an IP subnet associated with the SOA bus. Each IP service advertised may have a name that includes a service descriptor uniformly associated with IP connectivity. Additionally, the name of each IP service may include the IP address for that particular service. A first device may transmit an IP packet to a second device over the SOA bus by remotely invoking the IP service advertised by the second device and passing the IP packet to the IP service of the second device as a parameter of invocation.
- Implementations are also described regarding multi-hop Internet routing over a service oriented architecture bus. For example, some implementations involve modification of existing routing mechanisms in the ad hoc on-demand distance vector (AODV) routing standards in order to provide Internet-informed routing. Alternative implementations involve maintenance of lists, by non-gateway nodes, of potential gateway nodes based on SOA bus announcements of gateway node capabilities, and utilization of the unmodified AODV routing mechanisms to send and/or forward IP packets to a gateway node selected from a list. In alternative aspects of either of the aforementioned implementations, the Internet-destined packets may either be tunneled (i.e., the actual Internet destination being masked) or non-tunneled (i.e., no masking of the Internet destination).
- Thus, the following description provides examples, and is not limiting of the scope, applicability, or configuration set forth in the claims. Changes may be made in the function and arrangement of elements discussed without departing from the spirit and scope of the disclosure. Various embodiments may omit, substitute, or add various procedures or components as appropriate. For instance, the methods described may be performed in an order different from that described, and various steps may be added, omitted, or combined. Also, features described with respect to certain embodiments may be combined in other embodiments.
-
FIG. 1 illustrates an example asystem 100 in which various devices 115 (e.g., personal computer 115-a, smartphone 115-b, tablet computer 115-c, and printer 115-d) communicate with each other at a peer-to-peer level. - As shown in
FIG. 1 , thedevices 115 may communicate with each other over different access technologies. In the present example, personal computer 115-a communicates with smartphone 115-b over a wireless local area network (WLAN) connection (e.g., as an ad-hoc WLAN connection and/or through a WLAN switch, access point, or router). Personal computer 115-a also communicates with printer 115-d over a Universal Serial Bus (USB) connection. Smartphone 115-b also communicates with the table computer 115-c over a Bluetooth wireless connection. - While no
single device 115 of the present example is in direct communication with each of thedevices 115 in the system, thedevices 115 may cooperate with each other to implement anSOA bus 105 over a peer-to-peer network. As used in the present specification and appended claims, the term “SOA bus” refers broadly to any communication architecture providing a logical infrastructure for distributed nodes to advertise services to each other and remotely invoke each other's advertised services. Additionally, the term “service” refers broadly to an autonomous unit of software functionality which can be remotely invoked or called by a device or application separate from the device or application implementing the service. - For the purposes of clarity in explanation, the description of
SOA buses 105 inFIG. 2 and throughout the specification are given within the context of an AllJoyn bus implementing the open-source AllJoyn bus functionality. However, the principles of the present specification may be broadly applied to other types of SOA buses, including, but not limited to, Enterprise Service Buses (ESBs), Windows service buses, Simple Service Buses (SSBs), D-Bus, and/or other service buses. - In the system of
FIG. 1 , to implement theSOA bus 105, each of thedevices 115 may run a separate instance of an SOA bus daemon. The SOA bus daemon running on eachdevice 115 of thesystem 300 may communicate with the SOA bus daemons running onother devices 115 of thesystem 300 to establish alogical SOA bus 105 over the peer-to-peer network such that each of thedevices 115 may communicate with any of theother devices 115 in thesystem 100 over thelogical SOA bus 105, regardless of the access technologies used by thedevices 115 to communicate with their peers. - Each of the
devices 115 may be configured to provide a number of services over theSOA bus 105. For example, personal computer 115-a may provide a chat service, a streaming media service, and an Internet Protocol (IP) service. Smartphone 115-b may provide a chat service, a Global Positioning System (GPS) service, and an IP service. Tablet computer 115-c may provide a dictionary service and an IP service. Printer 115-d may provide a chat service, a streaming media service, and an IP service. Each service offered at eachdevice 115 may be assigned a logical location or address on theSOA bus 105. For example, the chat service of personal computer 115-a is given the address of :1.1 on theSOA bus 105, the streaming media service of the personal computer 115-a is given the address of :1.2 on theSOA bus 105, and the IP service of the personal computer 115-a is given the address of :1.3 on theSOA bus 105. For the purposes of the present specification and the appended claims, the term “Internet Protocol” or “IP” refers to any version of the Internet Protocol, including IPv4, IPv6, and/or any other past or future version. - Each of the
devices 115 on theSOA bus 105 may have access to a list of services advertised byother devices 115. A client process on one of thedevices 115 may remotely invoke an advertised service offered by anotherdevice 115 by establishing a session on theSOA bus 105 with the address of the advertised service on the SOA bus. For instance, if a client process of smartphone 115-b desired to access the streaming media service of printer 115-d, the client process may establish a session with address :1.9 on theSOA bus 105 and remotely invoke a method or procedure associated with the streaming media service through the session. In certain examples, a client process may be another service advertised on the SOA bus. Additionally or alternatively, a client process may be an application or other unit of software functionality with a separate address on theSOA bus 105 which offers no publicly advertised services over theSOA bus 105. - As shown in
FIG. 1 , each of thedevices 115 in thesystem 100 may offer an IP service over theSOA bus 105. In alternate examples, only a subset ofdevices 115 in asystem 100 may offer an IP service over the SOA bus. The IP services may cooperate with each other to implement one or more IP subnets over theSOA bus 105. This IP subnet may be separate and independent from any other IP subnet outside of the SOA bus. Thus, even though personal computer 115-a and smartphone 115-b may be part of a first IP subnet by virtue of their WLAN connection, the first IP subnet may be separate and distinct from a second IP subnet implemented over theSOA bus 105. - As further shown in
FIG. 1 , each of the IP services may have a unique name that is advertised over theSOA bus 105. Each unique name may include a service descriptor uniformly associated with IP service (e.g., “org.alljoyn.ipservice”) and an appended indicator of an IP address assigned to that device within the IP subnet implemented by the SOA bus 105 (e.g., “s192_168_0_4” indicating an IP address of 192.168.0.4). With the uniform service descriptor, each IP service may be quickly identified as such by other devices on theSOA bus 105. Additionally, by indicating the IP address in the name of the IP service advertised over theSOA bus 105, no additional discovery steps are necessary to determine the IP address of adevice 115 in the IP subnet implemented over theSOA bus 105. - By virtue of the peer-to-peer architecture of the
SOA bus 105, no separate router or switch is available (or needed) to route IP packets betweendevices 115 connected to theSOA bus 105. Instead, eachdevice 115 offering an IP service on theSOA bus 105 may maintain a record of the IP address of each other knowndevice 115 offering an IP service on theSOA bus 105. IP packets may be exchanged betweendevices 115 on theSOA bus 105 through the remote invocation of the advertised IP services. For example, personal computer 115-a (IP address 192.168.0.4) may transmit an IP packet addressed to 192.168.0.21 (the IP address associated with smartphone 115-b) by establishing a session between addresses :1.3 and :1.6 on theSOA bus 105, remotely invoking a method or function associated with the IP service associated with the smartphone 115-b (i.e. “org.alljoyn.ipservice.s192_168_0_21”), and passing the IP packet to the IP service associated with the smartphone 115-b over theSOA bus 105. The IP packet may be passed to the IP service associated with the smartphone 115-b as an argument or other parameter in the syntax of the remotely invoked method or function. In certain examples, the IP packet may be treated as an object rather than a packet by the IP services. - In certain examples, multiple IP subnets may be implemented over the
SOA bus 105. In such examples, the IP services may enforce rules that allow for the transfer of packets only between IP addresses associated with the same IP subnet. The IP subnet of an IP service may, in some examples, be included in the name of that IP service. For example, an IP service name of “org.alljoyn.ipservice.weather.s192_168_0_21” may refer to an IP service associated with IP address 192.168.0.21 on a first subnet, whereas an IP service name of “org.alljoyn.ipservice.sports.s192_168_0_21” may refer to the same IP address on an entirely separate, independent subnet. Adevice 115 may have multiple IP addresses for multiple IP subnets implemented by theSOA bus 105. In this case, thedevice 115 may run multiple IP services, each IP service being associated with a separate subnet, and/or allow a single IP service to handle multiple subnets. If a single IP service handles multiple subnets, the name of the IP service may reflect each IP address and subnet associated with thedevice 115. In certain examples, multiple subnets may be discovered. For example, a user may desire to find ad hoc subnets related to weather reports. In this example, the user may search theSOA bus 105 for services with names beginning with “org.alljoyn.ipservice.weather.” The user may advertise an IP address for his or herdevice 115 on one or more of the subnets using the same preamble with a unique IP address. - Additionally, in certain examples one or more of the IP services may include Domain Name Service (DNS) functionality. For example, an application running on personal computer 115_a may attempt to access a file from the domain hostname “magellan.ion.local”. The IP service running on the personal computer 115_a may be configured to translate the provided domain into an IP service running on one of the
other devices 115 connected to theSOA bus 105. - In certain examples, the name of one or more IP services may include an indicator of any domain hostnames associated with that IP service. For example, the name of an IP service advertised by a
device 115 may be “org.alljoyn.ipservice.s192_168_0_21_2356_magellan”. In this example, the “Magellan” component of the service name refers to the domain hostname associated with that the IP address “192.168.0.21.” A predetermined domain name, such as “.ion.local” or another suffix may be appended to the hostname component of the service name (e.g., to arrive at the hostname of “magellan.ion.local”). Additionally or alternatively, the entire domain name may be included as part of the advertised service name. It is further contemplated that a service associated with a resolved hostname name may be used as a subdomain under the hostname. For example, if a service named “weather” on the SOA bus is associated with a “voyager” hostname on the SOA bus, DNS functionality on one of thedevices 115 may allow for the DNS lookup of the “weather” service as “weather.voyager.ion.local.” - In this way, other IP services may discover and track the domain hostnames names associated with each other IP service on the
SOA bus 105 by discovering the name given to the other IP services on theSOA bus 105. This DNS functionality may allow the personal computer 115_a or anotherdevice 115 to provide effective DNS resolution to its applications and users without contacting a DNS server. Once a hostname for a neighboring service on the SOA bus is resolved to an IP address at adevice 115, the hostname and resolved IP address may be added to a hosts file of the operating system of the device 115 (e.g., at “/etc/hosts” in UNIX or UNIX-like systems). In this way, any DNS query from an application to the known hostname may automatically be resolved by the operating system to the correct address on an IP subnet associated with the SOA bus. The operating system resolver of thedevice 115 need not be modified to accommodate hostnames associated with advertised services on the SOA bus. - It is further contemplated that in certain examples, one or more of the IP services may be configured to implement various additional routing protocols (e.g., multi-path routing) and Quality-of-Service (QoS) functionality to achieve efficient and effective IP packet routing between the IP services.
- Referring back to the example of the service named “org.alljoyn.ipservice.s192_168_0_21_2356_magellan”, the “2356” in the advertised service name corresponds to a unique ID generated by the
device 115 to distinguish betweendifferent devices 115 advertising the same service. Thus, IP address conflicts between advertised services may be detected by determining if another service or device with the same IP address has the same or a different unique ID. If the IP address has the same unique ID, no conflict exists. Otherwise, an IP address conflict to be resolved may be detected. - Referring next to
FIG. 2 , a block diagram illustrates one example of awireless communications system 200 in which IP service may be implemented over an SOA bus as described above inFIG. 1 . Thesystem 200 includes base stations 205 (or cells),devices 115, abase station controller 220, and a core network 225 (thecontroller 220 may be integrated into the core network 225). Thesystem 200 may support operation on multiple carriers (waveform signals of different frequencies). - In the example of
FIG. 2 ,various devices 115 may communicate with the core network 225 through one ormore base stations 205. Additionally,certain devices 115 may establish peer-to-peer communications with each other. A group ofsuch devices 115 may cooperate with each other to establish a peer-to-peer network. For example, device 115-e, device 115-f, and device 115-g may leverage a peer-to-peer connection between device 115-e and device 115-f and the peer-to-peer connection between device 115-f and device 115-g to establish a peer-to-peer network between the threedevices 115. - The
devices 115 may further cooperate to implement an SOA bus (e.g.,SOA bus 105 ofFIG. 1 ) over the peer-to-peer network, and implement IP communications over the SOA bus, as described above with respect toFIG. 1 . In this way, an independent IP subnet may be established among devices 115-e, 115-f without reliance onbase station 205 or core network 225. However, in certain examples, one or more of thedevices 115 may advertise a service over the SOA bus which makes use of a connection to the core network 225 through abase station 205. For example, device 115-e may download a file from the core network 225 and stream the file to device 115-g over the IP subnet implemented over the SOA bus between device 115-e, device 115-f, and device 115-g. - A device need not be in communication with a
base station 205 to join a peer-to-peer network that provides IP services over an SOA bus. As shown inFIG. 2 , device 115-i and device 115-j may each implement peer-to-peer connections withother devices 115 without communicating with abase station 205. Using these peer-to-peer connections, an SOA bus may be implemented among device 115-h, device 115-i, device 115-j, and device 115-k. As described above, the SOA bus may be used to implement a private IP subnet among the fourdevices 115 connected to the SOA bus. - The
base stations 205 may wirelessly communicate with thedevices 115 via a base station antenna (not shown). Thebase stations 205 may communicate with thedevices 115 under the control of thebase station controller 220 via multiple carriers. Each of thebase station 205 sites may provide communication coverage for a respective geographic area. The coverage area for eachbase station 205 here is identified as 210-a, 210-b, or 210-c. The coverage area for a base station may be divided into sectors (not shown, but making up only a portion of the coverage area). Thesystem 200 may includebase stations 205 of different types (e.g., macro, micro, and/or pico base stations). There may be overlapping coverage areas for different technologies. - The
devices 115 may be dispersed throughout thecoverage areas 210. Thedevices 115 may be referred to as mobile stations, mobile devices, access terminals (ATs), user equipments (UEs), subscriber stations (SSs), subscriber units, in addition to stationary devices. Thedevices 115 may include, but are not limited to, cellular phones and wireless communications devices, but may also include desktop computers, printers, servers, set-top boxes, televisions and other media players, personal digital assistants (PDAs), other handheld devices, netbooks, notebook computers, etc. In some examples, certain of the devices may be - As shown in
FIG. 1 ,certain devices 115 may not directly communicate with a base station. For example, in cell 210-c,various devices 115 are shown which do not have an established wireless connection to thebase station 205. As further shown inFIG. 1 ,certain devices 115 may communicate directly with each other without routing messages through abase station 205. By communicating with each other, either directly or indirectly, the devices may cooperate to establish a service-oriented architecture (SOA) bus, in whichdevices 115 are able to advertise software services to other devices on the bus, and discover and invoke each other's services over the bus. In certain examples, communications betweendevices 115 over the implemented SOA bus may occur independent of thebase stations 205 or their associated core network 225. Alternatively, one or more communications over the SOA bus may occur through abase station 205. -
FIG. 3 is a block diagram of anexample system 300 for implementing IP connectivity over an SOA bus. Thesystem 300 includes a first device 115-l and a second device 115-m. The first device 115-l and the second device 115-m communicate with each other over a logical SOA bus 105-a. The first device 115-l and the second device 115-m may be examples of thedevices 115 described above with reference toFIG. 1 orFIG. 2 . The SOA bus 105-a may be an example of theSOA bus 105 described above with reference toFIG. 1 . - Each
device 115 of the present example includes a hardware platform of one ormore processors 305,main memory 310,local storage 315, and one or more input/output (I/O)devices 320. The processor(s) 305 of eachdevice 115 may execute code loaded into themain memory 310 fromlocal storage 315 to execute various units of functionality in kernel space and user space of an operating system. - In kernel space, each
device 115 shown in the example ofFIG. 3 includes aBluetooth interface 325 for sending and receiving Bluetooth communications, aWLAN interface 330 for sending and receiving WLAN communications, and avirtual network interface 335. The virtual network interface may route packets between theIP layer processing 340 in the network stack and anIP service 355 executing in user space to implement IP communications over an SOA bus 105-a. In certain examples, thevirtual network interface 335 may implement a TUN/TAP program or module according to known specifications. Thevirtual network interface 335 may simulate a network layer device. TheIP layer processing 340 and UDP/TCP layer processing 345 may perform the traditional functions associated with packet processing inlayer 3 andlayer 4 of a network stack. - In user space, each
device 115 shown in the example ofFIG. 3 includes anIP application 350 configured to transmit and receive data over an IP network, anIP service 355 configured to implement IP connectivity over the SOA bus 105-a, and anSOA bus daemon 360 configured to implement the SOA bus 105-a. TheIP service 355 and theSOA bus daemon 360 may be examples of the IP services and SOA bus daemons described above with reference to theSOA bus 105 ofFIG. 1 . - To illustrate IP communications between the
devices 115 over the SOA bus 105-a, consider the example of the IP application 350-a of the first device 115-l transmitting an IP packet to the second device 115-m. In this example, IP application 350-a generates data which is assembled into an IP application by the UDP/TCP layer processing 345-a and the IP layer processing 340-a. The assembled IP packet may have as the destination address an IP address associated with the IP service 355-b of the second device 155-f. As described above with reference toFIG. 2 , the IP address associated with the IP service 355-b of the second device 155-f may be determined by the IP Service 355-a of the first device 115-l based on an advertised name of the IP service 355-b of the second device 155-f. - The virtual network interface 335-a may receive or intercept the constructed IP packet and forward the IP packet to the IP service 335-a of the first device. The IP service 355-a of the first device may then remotely invoke a method or procedure associated with the IP service 355-b of the second device 115-m to pass the IP packet to the IP service 355-b of the second device 115-m over the SOA bus 105-a. For example, the IP packet may be passed to the IP service 355-b of the second device 115-m as an argument or other parameter associated with the syntax of the invoked method or procedure. The IP packet may be treated by the
IP services 355 as a software object rather than a packet. - The IP packet received at the IP service 355-b of the second device 115-m is then forwarded to the virtual network interface 335-b of the second device, which places the IP packet into the IP layer processing 340-b and UDP/TCP layer processing 345-b of the network stack. Once UDP/
TCP layer processing 345 has completed on the IP packet, the data from the IP packet may be provided to the IP application 350-b of the second device 115-m. -
FIG. 4 is a block diagram of example communication signals over an SOA bus 105-b between a first IP service 355-c implemented by a first device and a second IP service 355-d implemented by a second device. TheIP services 355 may be examples of theIP service 355 described above with reference toFIG. 3 . The first and second device may be examples of adevice 115 described above with reference toFIG. 1 ,FIG. 2 , orFIG. 3 . The SOA bus 105-b may be an example of theSOA bus 105 described above with reference toFIG. 1 orFIG. 3 . - Each of the
IP services 355 may have a unique address on the SOA bus 105-b. In the present example, the first IP service 355-c has an address of :1.3 on the SOA bus 105-b, and the second IP service 355-d has an address of :1.6 on the SOA bus 105-b. Additionally, eachIP service 355 has a name that is advertised on the SOA bus and discoverable to other services. The name of eachIP service 355 of the present example includes a service descriptor (i.e., “org.alljoyn.ipservice”) uniformly associated withIP services 355 in a contiguous namespace of the SOA bus 105-b. Each name additionally has an indicator of an IP address associated with an IP subnet implemented over the SOA bus 105-b. Thus, the first IP service 355-c has a name of “org.alljoyn.ipservice.s192_168_0_4,” indicating anIP service 355 with an IP address of 192.168.0.4, and the second IP service 355-d has a name of “org.alljoyn.ipservice.s192_168_0_21,” indicating anIP service 355 with an IP address of 192.168.0.21. - For the first and
second IP services 355 to exchange IP packets, the first IP service 355-c first initiates 405 a session between :1.3 and :1.6 on the SOA bus 105-b. The second IP service 355-d confirms 410 the session between :1.3 and :1.6. The first IP service 355-c may then transmit a first IP packet addressed to the IP address of the second IP service 355-d by remotely invoking 415 a method named “org.alljoyn.ipservice.s192_168_0_21.transmit” at the second IP service 355-d over the SOA bus 105-b. The first IP service passes the first IP packet to the invoked method as an argument or other parameter for the function. The function may be one of a known set of functions implemented by all IP services to implement IP communication. The IP packet may be treated as an object parameter between the twoIP services 355. The second IP service 355-d may send the first IP service 355-c a second packet by remotely invoking 420 a method named “org.alljoyn.ipservice.s192_168_0_4.transmit” at the first IP service 355-c over the SOA bus 105-b, passing the second IP packet to the method as an argument or other parameter to the invoked method. -
FIG. 5 illustrates a block diagram of an example device 115-n. The device 115-n may be an example of thedevices 115 described above with reference toFIG. 1 ,FIG. 2 , orFIG. 3 . The device 115-n may be implemented, for example, entirely in hardware, or as a combination of hardware and software. The device 115-n includes anIP service module 505, an IPservice advertising module 510, an IPservice discovery module 515, atransmitter module 520, and areceiver module 525. - The
IP service module 505 may be configured to implement an IP service (e.g.,IP service 355 ofFIG. 3 orFIG. 4 ) over an SOA bus implemented by a peer-to-peer network (e.g.,SOA bus 105 ofFIG. 1 ,FIG. 3 , orFIG. 4 ). The IP service implemented by theIP service module 505 may be associated with an IP address within an IP subnet implemented over the SOA bus. The IP service may be configured to communicate with other IP services associated with different IP addresses in the subnet over the SOA bus. - The IP
service advertising module 510 may advertise the IP service implemented by theIP service module 505 over the SOA bus to other devices and services. The IPservice advertising module 510 may advertise the name of the IP service, the IP address associated with the IP service, a Media Access Control (MAC) address, a globally unique identifier (GUID), a universally unique identifier (UUID), and/or any other information about the IP service that may suit a particular implementation of these principles. In certain examples, the IPservice advertising module 510 may also advertise subnet and/or DNS resolution data associated with the first IP service. - The IP
service discovery module 515 may discover a second IP service advertised by a second device over the SOA bus. As described in more detail elsewhere in this description, the second IP service may be discovered based on a uniform IP service descriptor contained in an advertised name of the second IP service. The IPservice discovery module 515 may also discover an IP address associated with the second IP service from the advertised name, or by some other method. In certain examples, theIP discovery module 515 may also discover a MAC address, a GUID, a UUID, and/or any other information about the second IP service that may suit a particular implementation of these principles. In additional or alternative examples, the IP service discovery module subnet and/or DNS resolution data associated with the second IP service. - The
transmitter module 520 may be configured to transmit at least a first IP packet to the second device by causing theIP service module 505 to remotely invoke the second IP service over the SOA bus, passing the first IP packet to the second IP service as an argument or other parameter associated with invoking the second IP service. - The
receiver module 525 may be configured to receive at least a second IP packet from the second device over the SOA bus through the IP service implemented by theIP service module 505 of the device 115-n. The second device may transmit the second IP packet to the IP service by remotely invoking the IP service over the SOA bus and passing the second IP packet to the IP service as an argument or parameter associated with invoking the IP service. -
FIG. 6 illustrates a block diagram of an example device 115-o. The device 115-o may be an example of thedevices 115 described above with reference toFIG. 1 ,FIG. 2 ,FIG. 3 , orFIG. 5 . The device 115-o may be implemented, for example, entirely in hardware, or as a combination of hardware and software. Similar to the device 115-n ofFIG. 5 , the device 115-o ofFIG. 6 includes an IP service module 505-a, an IP service advertising module 510-a, an IP service discovery module 515-a, a transmitter module 520-a, and a receiver module 525-a. Additionally, the device 115-o ofFIG. 6 includes an SOAbus daemon module 605, anIP application 615, and an IPaddress assignment module 620. - The SOA
bus daemon module 605 may implement an SOA bus daemon that establishes peer-to-peer connections with neighboring devices. In this way, multiple devices may establish a peer-to-peer network that implements an SOA bus, as described above. Because the SOAbus daemon module 605 logically implements the SOA bus functionality on the device 115-o, the IP service module 505-a may communicate with the SOA bus through the SOAbus daemon module 605. The SOAbus daemon module 605 may include asession management submodule 610 configured to establish, maintain, and terminate sessions with services offered on the SOA bus. - The
IP application 615 may include an application executed in user space that produces and receives data sent over an IP subnet implemented over the SOA bus. Thus, data in IP packets sent by the transmitter module 520-a may originate from theIP application 615, and data in IP packets received by the receiver module 525-a may ultimately be forwarded to theIP application 615. - The IP
address assignment module 620 may be configured to generate the IP address associated with the IP service module 505-a. As described above with respect to previous Figures, the IPaddress assignment module 620 may randomly generate an IP address within a permissible range associated with the IP subnet of the SOA bus, check the SOA bus for conflicts, and assign the IP address to the IP service module 505-a if no conflicts are found. -
FIG. 7 illustrates an example of amethod 700 of enabling IP connectivity over an SOA bus implemented by a peer-to-peer network, according to the principles of the present disclosure. Themethod 700 ofFIG. 7 may be performed, for example, by one or more of thedevices 115 described above with reference toFIGS. 1-6 . - At
block 705, a first IP service at a first device is advertised over an SOA bus implemented by a peer-to-peer network. As described above, the SOA bus may include an ALLJOYN service bus, an Enterprise Service Bus (ESB), a MICROSOFT WINDOWS Service Bus, a Simple Service Bus (SSB), and/or any other applicable type of service bus. The first IP service may be advertised using a service name associated with the first IP service, the service name associated with the first service including a service descriptor (e.g., “org.alljoyn.ipservice”) uniformly associated with IP service at the SOA bus. - At
block 710, a second IP service advertised by a second device over the SOA bus is discovered. The second IP service may be discovered based a service name associated with the second IP service. The service name associated with the second IP service may include the same service descriptor for IP service as the service name associated with the first IP service. Each of the IP service names may also include an indication of a unique IP address associated with the respective device implementing the IP service within an IP subnet implemented by the SOA bus. The service names for the first IP service and the second IP service may also be implemented within a contiguous namespace implemented by the SOA bus. - At
bloc k 715, the first device transmits at least a first IP packet to the second device by remotely invoking the second IP service over the SOA bus. For example, the first device may remotely call a function associated with the second IP service over the SOA bus, passing the first IP packet to the second IP service as an argument or parameter of the function. The first IP packet may be addressed to the unique IP address associated with the second device within the IP subnet implemented by the SOA bus. - At
block 720, the first device receives at least a second IP packet from the second device over the SOA bus through the first advertised service. For example, the second device may remotely call a function associated with the first IP service over the SOA bus, passing the second IP packet to the first IP service as an argument or parameter of the function. The second IP packet may be addressed to the unique IP address associated with the first device within the IP subnet implemented by the SOA bus. -
FIG. 8 is a flowchart illustrating another example of amethod 800 of enabling IP connectivity over an SOA bus implemented by a peer-to-peer network, according to the principles of the present disclosure. Themethod 800 ofFIG. 8 may be performed, for example, by one or more of thedevices 115 described above with reference toFIGS. 1-6 . - At
block 805, an IP packet is received from an IP application at a virtual network interface of a first device, the IP packet being addressed to the second device. The virtual network interface may receive IP packets addressed to IP addresses associated with an IP subnet implemented by an SOA bus. In certain examples, IP packets addressed to an IP address on the SOA bus may be forwarded directly to the virtual network interface from IP applications. Additionally or alternatively, the virtual network interface may intercept IP packets addressed to IP addresses on the SOA bus. - At
block 810, the IP packet received at the virtual network interface is forwarded to a first IP service executed at the first device. The first IP service may be a service advertised on the SOA bus to other devices. The first IP service may be configured to transmit and receive IP packets as objects of remote function or procedure calls made over the SOA bus. - At
block 815, a second IP service executed at the second device may be identified from a destination address of the IP packet. For example, the second IP service may have a name, advertised on the SOA bus, which includes the IP address associated with the second IP service. Thus, the second IP service may be identified by searching a list of names of services advertised over the SOA bus for an IP service which includes the destination IP address of the IP packet. - At
block 820, a determination is made as to whether a session currently exists between the first and second IP services over the SOA bus. This determination may be made using one or more tables or other data structures which track the progress of sessions between the services or applications of the first device and services or applications of external devices over the SOA bus. - If a service does not currently exist between the first and second IP services over the SOA bus (block 820, No), a new session is generated between the first and second IP services over the SOA bus at
block 825. When a session exists between the first and second IP services over the SOA bus, the first IP service may remotely invoke the second IP service over the SOA bus atblock 830, passing the IP packet to the second IP service as a parameter or argument of a function or procedure of the second IP service. In certain examples, the first and second IP services may treat the IP packet as an object rather than a routable packet. -
FIG. 9 illustrates another example of amethod 900 of enabling IP connectivity over an SOA bus implemented by a peer-to-peer network, according to the principles of the present disclosure. Themethod 900 ofFIG. 9 may be performed, for example, by one or more of thedevices 115 described above with reference toFIGS. 1-6 . - At
block 905, a determination is made that a first IP service at a first device has been remotely invoked by a second IP service at a second device over an SOA bus. For example, it may be determined at the first device that the second IP service has remotely called a function associated with the first IP service over the SOA bus. - At
block 910, an IP packet addressed to an IP address associated with the first IP service is received as a parameter associated with invoking the first IP service. For example, the first IP service may receive the IP packet as an object parameter or argument within the syntax of function remotely called by the second IP service. - At
block 915, the received IP packet is forwarded from the first IP service to a virtual network interface implemented at the first device. The virtual network interface may treat the IP packet as if the IP packet had been received as a conventional packet over a conventional network connection. Atblock 920, the virtual network interface may initiate processing of the received IP packet at the IP layer. In certain examples, a TCP or UDP datagram may be extracted from the IP packet during IP layer processing. Data from the TCP or UDP datagram may be forwarded to the application layer based on the results of TCP or UDP processing. Additionally or alternatively, data from the TCP or UDP datagram may be used to update the status of a TCP or UDP socket. -
FIG. 10 is a flowchart illustrating another example of amethod 1000 of enabling IP connectivity over an SOA bus implemented by a peer-to-peer network, according to the principles of the present disclosure. Themethod 1000 ofFIG. 10 may be performed, for example, by one or more of thedevices 115 described above with reference toFIGS. 1-6 . - At
block 1005, a first device connects to an SOA bus. The SOA bus may include, for example, an ALLJOYN service bus, an ESB, a MICROSOFT WINDOWS service bus, an SSB, and/or any other suitable SOA bus. - At
block 1010, an IP address for IP communication is assigned to the first device. The IP address may be assigned to the first device by randomly generating an IP address within a subnet implemented by the SOA bus, and checking for IP address conflicts on the SOA bus. - At
block 1015, a name for a first IP service associated with the first device is generated. The name may include a service descriptor uniformly associated with IP service at the SOA bus and the assigned IP address. For example, if the service descriptor uniformly associated with IP service is “org.alljoyn.ipservice”, and the IP address assigned to the first device for IP communication over the SOA is 192.168.0.4, the name for the first IP service may be generated by appending the assigned IP address to the service descriptor to create the name of “org.alljoyn.ipservice.s192_168_0_4” for the first IP service. - At
block 1020, the first device advertises the name of the first IP service using a contiguous namespace implemented by the SOA bus. For example, an SOA bus daemon running on the first device may broadcast the name of the first IP service to other SOA bus daemons running on other devices connected to the SOA bus. - At
block 1025, a second IP service associated with a second device connected to the SOA bus may be discovered. For example, the SOA bus daemon running on the first device may receive a broadcast from an SOA bus daemon running on the second device which includes the name of the second IP service. The SOA bus daemon running on the first device may determine from the name of the second IP service that the second IP service is for IP communications, and forward the name of the second IP service to the first IP service. - At
block 1030, an IP address associated with the second IP service is determined based on the name of the second IP service. For example, if the name of the second IP service is “org.alljoyn.ipservice.s192_168_0_22”, the first IP service may determine the IP address associated with the second IP service to be 192.168.0.22. - At
block 1035, an IP packet addressed to the IP address associated with the second IP service is generated at the first device. The IP packet may be generated by an IP application at the first device. - At
block 1040, the IP packet is transmitted to the second device by remotely invoking the second IP service over the SOA bus and passing the IP packet to the second IP service as a parameter of invoking the second IP service. In certain examples, the IP packet may be an object associated with the syntax of a procedure or other function associated with the second IP service and remotely called by the first IP service. -
FIG. 11 is a flowchart illustrating an example of amethod 1100 of generating an IP address for use in IP communications over an SOA bus, according to the principles of the present disclosure. Themethod 1100 ofFIG. 11 may be performed, for example, by one or more of thedevices 115 described above with reference toFIGS. 1-6 . - At
block 1105, a permissible range of IP addresses in a current IP subnet implemented by the SOA bus is determined. In certain examples, one or more applications connected to the SOA bus may advertise the permissible range of IP addresses. Additionally or alternatively, the permissible range of IP addresses may be deterministically identified based on properties of the SOA bus. - At
block 1110, an IP address within the permissible range of IP addresses for the subnet is generated at a first device. In certain examples, the IP address may be generated using a random generator and a mask that keeps the generated IP address within the permissible range for the subnet. - At
block 1115, an IP service name is generated for the first device for use on the SOA bus. The IP service name is generated by appending the generated IP address to a known service descriptor associated with IP service on the SOA bus. The generated IP service name may comply with the syntax of a contiguous namespace implemented by the SOA bus. - At
block 1120, the SOA bus is queried for IP service name conflicts. For example, the generated IP service name may be transmitted from an SOA bus daemon running on the first device to SOA bus daemons running on other devices connected to the SOA bus. If another device connected to the SOA bus is already using the IP service name generated for the first device (block 1125, Yes), flow returns to block 1110, where a new IP address is generated at the first device. Otherwise (block 1125, No), the IP service name and IP address generated at the first device are assigned to the first device atblock 1130. -
FIG. 12 is a flowchart illustrating an example of amethod 1200 of discovering IP services on an SOA bus, according to the principles of the present disclosure. Themethod 1200 ofFIG. 12 may be performed, for example, by one or more of thedevices 115 described above with reference toFIGS. 1-6 . - At
block 1205, an SOA bus daemon running on a device connected to the SOA bus receives the instruction to notify a first IP service running on the device of new IP services connecting to the SOA bus. In certain examples, an express instruction from the first IP service may be received at the SOA bus daemon. Additionally or alternatively, the instruction may be inherently provided to the SOA bus daemon as part of the underlying code of the SOA bus daemon. - At
block 1210, the first IP service receives notification of a new second IP service on the SOA bus. The first IP service receives a name of the second IP service and a location or address of the second IP service on the SOA bus. - At
block 1215, an IP address of the second IP service is identified based on the name associated with the second IP service. The IP address of the second IP service may be different from the location or address of the second IP service on the SOA bus. For example, the IP address of the second IP service may be “192.168.0.12”, and the location of the second IP service on the SOA bus may be “:1.3”. - At
block 1220, the IP address of the second IP service is associated with the location of the second IP service on the SOA bus in a mapping table or other data structure maintained by the first IP service. -
FIG. 13 is a graphical representation of an ad hoc peer-to-peer (P2P) network defined using an SOA bus that provides networking between mobile devices. However, the multiple nodes that make up the ad hoc SOA bus network may not all have Internet access availability. For example,gateway nodes Internet 1304, whereas non-gateway nodes 1306-1314 may not be connected to theInternet 1304. In such a circumstance, difficulties may arise in routing Internet traffic from a network node that does not have an Internet connection (a non-gateway node) to a network node that has such Internet connection (a gateway node). For non-gateway nodes adjacent to gateway nodes, gateway node services of the adjacent gateway node may be utilized in the manner described above. However, multi-hop scenarios involving non-gateway nodes that are not adjacent to gateway nodes require additional solutions described below with reference toFIGS. 13-20 . -
FIG. 14 illustrates example blocks executed by gateway and non-gateway nodes to implement Internet-informed routing by modification of existing routing mechanisms in the ad hoc on-demand distance vector (AODV) routing standards. Typical AODV routing provides for routing mechanisms for in-subnet routing. To extend AODV-type routing outside of the subnet, an indefinite destination is added to the destination field of the AODV internet route request message packets. A non-gateway node sends out the internet route request message to its neighbor nodes. When the internet route request message with the indefinite destination is received by a gateway node, the gateway node responds with its own address and a gateway flag. Each node that forwards the gateway node's response from the gateway node to the non-gateway node, from which the request originated, will update its gateway pointer to the address of the gateway node. Accordingly, when internet access is desired at a non-gateway node, the non-gateway node will have the appropriate routing information to obtain an access path to the Internet through the gateway node associated with its gateway pointer. - It is envisioned that the nodes of the ad hoc peer-to-peer network may be adapted to implement different procedures according to their respective roles in a given Internet routing procedure. Such a node may be adapted to operate in one of multiple different modes, as at
block 1400, depending on whether its role in the Internet routing procedure is to operate as a source non-gateway node, an intermediate non-gateway node, or a gateway node. For example, if the node wishes to transmit Internet packets over the Internet, but lacks an Internet connection, then the node may operate in a source non-gateway node mode, in which case processing may begin atblock 1402. Additionally, if the node has received an Internet route request from a neighbor node, and if it does not have an Internet connection, then the node may operate in an intermediate non-gateway node mode, in which case processing may begin atblock 1404. Further, if the node has received an Internet route request from a neighbor node, and if it does have an Internet connection, then the node may operate in a gateway node mode, in which case processing may begin atblock 1406. - At
block 1402, if a source non-gateway node already knows a suitable destination address for a gateway node, then the source gateway node may transmit IP packets based on that information. However, if the source non-gateway node does not have such information, or if an attempt to use a gateway node fails or is unsatisfactory, then the source non-gateway node may send an Internet route request (I-RREQ). The source non-gateway node may send the I-RREQ to a destination IN_ADDR_ANY (e.g., all zeros), which may be defined in the modified AODV protocol as a non-specific address that triggers sending of I-RREQ message over the network by a flooding technique. Stated differently, the non-gateway nodes may be adapted to transmit and forward a route request message having the non-specific destination address to all neighbor nodes, excepting those neighbor nodes from which it receive the I-RREQ, or from which it received an identical I-RREQ. It is envisioned that the I-RREQ message may be identical to a typical AODV route request message (RREQ), excepting that the destination address is IN-ADDR_ANY (all zeros). Stated differently, the network nodes and/or gateway nodes may further be adapted to distinguish an I-RREQ from an RREQ based partly or entirely on the IN_ADDR_ANY destination address. Processing at the source non-gateway node may proceed fromblock 1402 to 1418. - At
block 1404, the intermediate non-gateway node may receive the I-RREQ that was sent by the source non-gateway node atblock 1402. If the intermediate non-gateway node is a neighbor of the source non-gateway node, then the intermediate non-gateway node may receive the I-RREQ directly from the source non-gateway node. Alternatively or additionally, the intermediate non-gateway node may receive the I-RREQ from another non-gateway node. It is envisioned that the intermediate non-gateway node may receive multiple copies of the I-RREQ from multiple, different neighbor nodes. Processing at the intermediate non-gateway node may proceed fromblock 1404 to block 1408. - At
block 1408, the intermediate non-gateway node may update and relay the I-RREQ to other neighbor nodes according to the flooding technique, as previously described. It is envisioned that, in the event that multiple copies of the I-RREQ were received from multiple, different neighbor nodes, the intermediate non-gateway node may selectively update and relay the I-RREQ to other neighbor nodes based on one or more predefined criteria, such as first I-RREQ received, lowest hop count, shortest relay path, or combination thereof. It is alternatively or additionally envisioned that the intermediate node may edit, update, and forward the I-RREQ in the same manner defined for RREQ in the existing AODV standard, excepting for the forwarding according to the flooding technique, as described above. Processing at the intermediate non-gateway node may proceed fromblock 1408 to block 1412. - At
block 1406, the gateway node may receive the I-RREQ from one or more neighbor nodes. It is envisioned that the gateway node may distinguish the I-RREQ from a typical AODV RREQ by the non-specific destination address. Processing at the gateway node may proceed fromblock 1406 to block 1410. - At
block 1410, the gateway node may respond to a received I-RREQ by sending an Internet route reply message (I-RREP) to the neighbor node from which it received the I-RREQ. In the event that multiple copies of the I-RREQ are received from multiple, different neighbor nodes, it is envisioned that the gateway node may respond to all of the I-RREQs. Alternatively, it is envisioned that the gateway node may preferentially respond to less than all copies of an I-RREQ based on one or more predefined criteria, such as first I-RREQ received, lowest hop count, shortest relay path, or combination thereof. The I-RREP may have a destination address of the gateway node and a gateway indicator, such as a set gateway flag. The gateway indicator may be defined in the modified AODV protocol as a flag, field, hash, encryption, mask, or any other type of distinguishing characteristic that permits nodes of the network to distinguish the I-RREP from a typical AODV route reply message (RREP). Stated differently, it is envisioned that the I-RREP may be identical to a typical AODV RREP, excepting that the I-RREP has the gateway indicator. Processing at the gateway node may proceed fromblock 1410 to block 1426. - At
block 1412, the intermediate non-gateway node may receive the I-RREP having the destination address of the gateway node and the gateway indicator, as described above. The I-RREP may also have a hop count, relay path, and other information typical of an RREP of the AODV protocol. The intermediate non-gateway node may distinguish the I-RREP from a typical AODV RREP based on the gateway indicator, and may proceed fromblock 1412 to block 1414 on that basis. However, it is envisioned that the intermediate non-gateway node may receive multiple I-RREPs in response to the same I-RREQ, and that originate from multiple, different gateway nodes. In this case, the intermediate non-gateway node may make a determination whether to respond to such an I-RREP based on one or more predefined criteria, such as first I-RREP received, lowest hop count, shortest relay path, or combination thereof. Alternatively, the source non-gateway node may process all I-RREPs received. - At
block 1414, the intermediate non-gateway node may update its gateway pointer to the destination address of the gateway node contained in the I-RREP. It is envisioned that the intermediate non-gateway network node may have one or multiple gateway pointers, and may instantiate new gateway pointers, update or expire existing gateway pointers, and/or prioritize gateway pointers based on one or more predefined criteria. Example criteria may include most recent I-RREP received, lowest hop count, shortest relay path, presence or lack thereof of low mobility nodes in the relay path, quality of service of an Internet connection via the gateway node, or combinations thereof. Processing at the intermediate non-gateway node may proceed fromblock 1414 to block 1416. - At
block 1416, the intermediate non-gateway node may relay the I-RREP to the neighbor node specified in the relay path of the I-RREP. Before doing so, the intermediate non-gateway node may edit and update the I-RREP in the same manner as a typical AODV RREP is processed, such as updating the hop count, and other procedures as will be readily apparent to one skilled in the art. Processing at the intermediate non-gateway node may proceed fromblock 1416 to block 1424. - At block 1418, the source non-gateway node may receive the Internet route response (I-RREP) from a neighbor node. The source non-gateway node may distinguish the I-RREP from a typical AODV RREP based on the gateway indicator, and may proceed from block 1418 to block 1420 on that basis. However, it is envisioned that the source non-gateway node may receive multiple I-RREPs in response to the same I-RREQ, and that originate from multiple, different gateway nodes. In this case, the intermediate non-gateway node may make a determination whether to respond to such an I-RREP based on one or more predefined criteria, such as first I-RREP received, lowest hop count, shortest relay path, or combination thereof. Alternatively, the source non-gateway node may process all I-RREPs received.
- At block 1420, the source non-gateway node may update its gateway pointer to the destination address of the gateway node contained in the I-RREP. It is envisioned that the source non-gateway network node may have one or multiple gateway pointers, and may instantiate new gateway pointers, update or expire existing gateway pointers, and/or prioritize gateway pointers based on one or more predefined criteria. Example criteria may include most recent I-RREP received, lowest hop count, shortest relay path, presence or lack thereof of low mobility nodes in the relay path, quality of service of an Internet connection via the gateway node, or combinations thereof. Processing at the source non-gateway node may proceed from block 1420 to block 1422.
- At
block 1422, the source non-gateway node may perform routing operations to send and receive IP packets to and from the address associated with its gateway pointer. In some implementations, the source non-gateway node may use tunneling to mask the actual Internet destination of transmitted IP packets with the destination address of its gateway pointer. When the IP packets are tunneled, the transmission is addressed to a specific gateway node. In other implementations, the source non-gateway node may send the IP packets toward the destination address associated with the gateway pointer, and do so without tunneling. When the IP packets are sent without tunneling, the source non-gateway node may send the IP packets to its neighbor in the path associated with the destination address of its gateway pointer, but allow the IP packets have an Internet destination. - At
block 1424, the intermediate non-gateway node may perform routing operations to relay IP packets between source non-gateway nodes and a gateway node. In some implementations, the intermediate non-gateway node may receive tunneled IP packets having a destination address of a particular gateway node. In this case, the intermediate non-gateway node may simply forward the IP packets to the destination address of the particular gateway node. In other implementations, the intermediate non-gateway node may receive IP packets that are not tunneled, and that therefore have an Internet destination. When IP packets are received that have an Internet destination, the intermediate non-gateway node may check its own gateway pointer or pointers for a more desirable gateway than the originally-addressed gateway node. Accordingly, the intermediate non-gateway node may perform routing operations to forward the IP packets to an address associated with its own gateway pointer. Thus, the intermediate non-gateway node may potentially reroute received IP packets having an Internet destination to a different gateway node. Tunneling Internet-destined packets allows for greater use of existing AODV routing mechanisms, as the transmitted packets appear to be specifically addressed to nodes within the subnet. However, while the packets are masked from any intermediate nodes along the transmission route, tunneled packets may not benefit from potential gateway re-routing during the journey. - At
block 1426, the gateway node may perform routing operations to receive IP packets from the source non-gateway node.Block 1426 may include receiving tunneled or non-tunneled IP packets directly from the source non-gateway node, and/or receiving tunneled or non-tunneled packets from an intermediate non-gateway node. If the IP packets are tunneled, then the gateway node may un-tunnel the IP packets by unmasking the destination address of the IP packets, thereby obtaining the Internet destination of the received IP packets. Processing at the gateway node may proceed fromblock 1426 to block 1428. - At
block 1428, the gateway node may transmit and receive IP packets over the Internet. The gateway node may obtain or assign an IP address for receiving IP packets intended for the source non-gateway node, and may use the Internet destination and the obtained or assigned IP address to transmit the IP packets over the Internet, and receive IP packets over the Internet that are intended for the source non-gateway node. When the gateway node receives an IP packet over the Internet that has a destination address corresponding to the IP address obtained or assigned for receiving IP packets intended for the source non-gateway node, the gateway node may distinguish these IP packets from other received IP packets on the basis of the destination address corresponding to the IP address obtained or assigned for receiving IP packets intended for the source non-gateway node. Processing at the gateway node may proceed fromblock 1428 to block 1430. - At
block 1430, the gateway node may perform routing operations to send IP packets, to the source non-gateway node, that were received over the Internet and intended for the source non-gateway node. It is envisioned that the gateway node may use tunneling to send the IP packets to the source non-gateway node by masking the destination address of the received IP packets with the destination address of the source non-gateway node. As mentioned above, tunneling IP packets received over the Internet allows for greater use of existing AODV routing mechanisms, as the transmitted packets appear to be specifically addressed to nodes within the subnet. Accordingly, the source non-gateway node may, atblock 1422, receive the IP packets either directly or indirectly from the gateway node. It is envisioned that the source non-gateway node may receive the IP packets from a neighbor node that did not participate as an intermediate non-gateway node in relay of the I-RREQ, I-RREP, and IP packets destined for the Internet or gateway node. It is also envisioned that intermediate non-gateway node may, atblock 1424, receive the IP packets and relay the IP packets to the source non-gateway node. -
FIG. 15 illustrates an example of operation of ad hoc peer-to-peer network nodes according to the modified AODV implementation. In this example, threenon-gateway nodes gateway nodes non-gateway node 1500, wishing to transmit IP packets to the Internet, and not already knowing a suitable Gateway node destination address, may generate a I-RREQ as described above, and transmit the I-RREQ to its neighbor nodes at 1510. Non-gateway node 1502 may receive the I-RREQ fromnon-gateway node 1500, and may forward the I-RREQ to all other neighbors at 1512. In turn,non-gateway node 1504 may receive the I-RREQ from non-gateway node 1502, and may forward the I-RREQ to all other neighbors at 1514. Finally,gateway node 1506 may receive the I-RREQ fromnon-gateway node 1514, and may respond by transmitting, at 1516, an I-RREP to a neighbor node in the relay path. - Nodes in the relay path may relay the I-RREP while updating their gateway pointers to the destination address of the
gateway 1506. For example, upon receiving the I-RREP fromgateway node 1506, thenon-gateway node 1504 may update its gateway pointer to the destination address of thegateway node 1506, and forward, at 1518, the I-RREP to the next neighbor node in the relay path. Additionally, non-gateway node 1502, upon receiving the I-RREP fromnon-gateway node 1504, may update its gateway pointer to the destination address of the gateway node, and forward, at 1520, the I-RREP to the next neighbor node in the relay path. Also,non-gateway node 1500, upon receiving the I-RREP from non-gateway node 1502, may update its gateway pointer to the destination address of the gateway node. Accordingly, all of thenon-gateway nodes gateway node 1506. - Once the
non-gateway nodes gateway node 1506. For example, at 1522,non-gateway node 1500 may use its gateway pointer to send and receive IP packets to and from thegateway node 1506, with or without tunneling. If tunneling is not employed, then thenon-gateway nodes 1502 and 1504 may utilize their respective gateway pointers to forward the IP packets to thegateway node 1506. Thereafter, non-gateway node 1502 may also wish to send IP packets togateway node 1506, and may use its gateway pointer to attempt to do so at 1524. This attempt may fail for any one of various reasons, such asgateway node 1506 going offline, leaving the area, losing its Internet connection, or failing to provide sufficient quality of service. - The non-gateway node 1502 may respond to failure of the attempt at 1526 by sending an I-RREQ to all neighbors at 1526 and 1528. The
non-gateway node 1504 may receive the I-RREQ fromnon-gateway node 1504, and relay the I-RREQ, at 1530, to a newneighbor gateway node 1508. The newneighbor gateway node 1508 may receive the I-RREQ and respond by transmitting, at 1532, an I-RREP tonon-gateway node 1504.Non-gateway node 1504 may update its gateway pointer to the destination address of thegateway node 1508, and may forward the I-RREP, at 1534, to non-gateway node 1502. Non-gateway node 1502 may then update its own gateway pointer to the destination address of thegateway node 1508, and use the updated gateway pointer, at 1536, to send Internet-destined IP packets togateway node 1508, either with or without tunneling. - In the example thus described, it should be noted that non-gateway node 1502 does not forward the I-RREP to
non-gateway node 1500, because non-gateway node 1502 is at the end of the relay path. Also,non-gateway node 1500 merely discarded the I-RREQ that it received from non-gateway node 1502 because it has no other neighbor nodes. Accordingly,non-gateway node 1500 never received any I-RREP except for the I-RREP it received at 1520 fromgateway node 1506. Therefore, the gateway pointer ofnon-gateway node 1500 may still point togateway node 1506. As a result, whennon-gateway node 1500 attempts, at 1538, to use its gateway pointer to send Internet destined IP packets togateway node 1506, use of tunneling would result in another failure. However, if tunneling is not used, non-gateway node 1502 may use its updated pointer to reroute the IP packets, at 1540, togateway node 1508, with or without tunneling. Upon receiving IP packets, at 1542, fromgateway node 1508,non-gateway node 1500 may update its gateway pointer to the destination address ofgateway node 1508, and continue to send and receive IP packets, at 1542, to and fromgateway node 1508. -
FIG. 16 illustrates example blocks executed by gateway and non-gateway nodes to implement Internet-informed routing by using the unmodified AODV routing and lists of potential gateway nodes. These lists are maintained and updated at non-gateway nodes in response to SOA bus announcements of gateway node capabilities. As a gateway node joins the SOA bus, it broadcasts an announcement of its capabilities as a gateway node. Each non-gateway node on the SOA bus creates a list of potential gateways based on the announcement. When the non-gateway node desires to establish an Internet connection, one of the gateway nodes is selected from the maintained list of potential gateways. Because the non-gateway node has the definite address information in the list, it may follow the typical AODV routing mechanism in order to route to the specific gateway node. - It is envisioned that the nodes of the ad hoc peer-to-peer network may be adapted to implement different procedures according to their respective roles in a given Internet routing procedure. Such a node may be adapted to operate in one of multiple different modes, as at
block 1600, depending on whether its role in the Internet routing procedure is to operate as a source non-gateway node, an intermediate non-gateway node, or a gateway node. For example, if the node wishes to transmit Internet packets over the Internet, but lacks an Internet connection, then the node may operate in a source non-gateway node mode, in which case processing may begin at block 1602. Additionally, if the node has received an Internet route request from a neighbor node, and if it does not have an Internet connection, then the node may operate in an intermediate non-gateway node mode, in which case processing may begin atblock 1604. Further, if the node has received an Internet route request from a neighbor node, and if it does have an Internet connection, then the node may operate in a gateway node mode, in which case processing may begin atblock 1606. - At
block 1606, the gateway node may announce Internet connectivity as a service on the SOA bus. This announcement may be accomplished in the manner previously described. Processing at the gateway node may proceed fromblock 1606 to block 1608. - At
block 1604, the intermediate non-gateway node may receive the SOA bus messages regarding Internet connectivity. The receipt of the SOA bus messages may be accomplished in the manner previously described. Processing at the intermediate non-gateway node may proceed fromblock 1604 to block 1610. - At block 1602, the source non-gateway node may receive the SOA bus messages regarding Internet connectivity. The receipt of the SOA bus messages may be accomplished in the manner previously described. Processing at the source non-gateway node may proceed from block 1602 to block 1612.
- At
block 1610, the intermediate non-gateway node may update its list of potential gateway nodes based on the SOA bus messages. It is envisioned that the intermediate non-gateway node may instantiate new gateway pointers, update or expire existing gateway pointers, and/or prioritize gateway pointers based on one or more predefined criteria. Example criteria may include lowest hop count, presence or lack thereof of low mobility nodes in the relay path, quality of service of an Internet connection via the gateway node, or combinations thereof. Processing at the intermediate non-gateway node may proceed fromblock 1610 to block 1614. - At
block 1612, the source non-gateway node may update its list of potential gateway nodes based on the SOA bus messages. It is envisioned that the source non-gateway node may instantiate new gateway pointers, update or expire existing gateway pointers, and/or prioritize gateway pointers based on one or more predefined criteria. Example criteria may include lowest hop count, presence or lack thereof of low mobility nodes in the relay path, quality of service of an Internet connection via the gateway node, or combinations thereof. Processing at the source non-gateway node may proceed fromblock 1612 to block 1616. - At
block 1616, the source non-gateway node may perform routing operations to send and receive IP packets to and from a destination address selected from its list of potential gateway nodes. The routing may be accomplished, with or without tunneling, in the manner previously described. - At
block 1614, the intermediate non-gateway node may perform routing operations to relay IP packets between a source non-gateway node and a gateway node. The routing may be accomplished, with or without tunneling, in the manner previously described. When routing non-tunneled IP packets, the intermediate non-gateway node may select a destination address from its own list of potential gateway nodes, thus giving rise to potential rerouting of the IP packets. - At
block 1608, the gateway node may perform routing operations to receive Internet-destined IP packets from the source non-gateway node. The routing may be accomplished with or without tunneling, in the manner previously described. Processing at the gateway node may proceed fromblock 1608 to block 1618. - At
block 1618, the gateway node may transmit and receive IP packets over the Internet. The transmission and receipt of IP packets of the Internet may be accomplished in the manner previously described. Processing at the gateway node may proceed fromblock 1618 to block 1620. - At
block 1620, the gateway node may perform routing operations to route IP packets received from the Internet to the source non-gateway node. The routing may be accomplished, with or without tunneling, in the manner previously described. -
FIG. 17 illustrates an example of operation of ad hoc peer-to-peer network nodes according to the unmodified AODV implementation. In this example, threenon-gateway nodes gateway nodes gateway node 1706 may, via the SOA bus, broadcastSOA announcements non-gateway nodes non-gateway nodes SOA bus announcements non-gateway nodes gateway node 1706 from their respective lists, androute IP packets 1716 togateway node 1706, with or without tunneling. -
Non-gateway nodes gateway node 1706. It should be understood thatnon-gateway node 1700 may not be privy to information regarding quality of service of such a connection that may be observed by another non-gateway node, such asnon-gateway node 1702. Additionally, furtherSOA bus announcements gateway node 1708, and decommission existing gateway nodes, such asgateway node 1706. It should be understood that some non-gateway nodes may receive SOA bus announcements more quickly than other nodes. Thus,non-gateway nodes non-gateway node 1702 may have reason to regard its list as better informed than the list ofnon-gateway node 1700. Therefore, when non-gateway node attempts, at 1724, to send Internet-destined IP packets togateway node 1706,non-gateway node 1702 may use its more reliable list to reroute the IP packets, at 1726, togateway node 1708. Whennon-gateway node 1700 receives IP packets fromgateway node 1708 instead of from gateway node, 1706 as expected,non-gateway node 1700 may update its list to add the destination address ofgateway node 1708, and remove, expire, or demote the destination address ofgateway node 1706. It should be readily appreciated that, sincenon-gateway node 1702 may sometimes reroute received IP packets based on quality of service information that may not be appreciated by downstreamnon-gateway node 1704,non-gateway node 1702 may use tunneling to direct the rerouted IP packets togateway node 1708. For the same reasons,non-gateway node 1700 may additionally switch to a tunneling mode for sending packets togateway node 1708. -
FIG. 18 illustrates example blocks executed by non-gateway nodes to implement Internet-informed routing by modification of existing routing mechanisms in the AODV routing standards. Atblock 1800, the non-gateway node may transmit an Internet route request for an indefinite destination to one or more neighbor nodes in the network. For example, processors 305 (FIG. 3 ) may access instructions stored inmain memory 310 and/orlocal storage 315 to operate I/O devices 320,Bluetooth interface 325,WLAN interface 330, andvirtual network interface 335, to generate the Internet route request and send the Internet route request to neighbor nodes according to the process described above with reference toFIG. 14 andFIG. 15 . Processing at the non-gateway node may proceed fromblock 1800 to block 1802. The combination of such acts and components may comprise means for transmitting, by the non-gateway node, an Internet route request for an indefinite destination to one or more neighbor nodes in the network. - At
block 1802, the non-gateway node may receive a response message from at least one gateway node on the network, wherein the response message includes an address of the at least one gateway node and a gateway indicator. For example, processors 305 (FIG. 3 ) may access instructions stored inmain memory 310 and/orlocal storage 315 to operate I/O devices 320,Bluetooth interface 325,WLAN interface 330, andvirtual network interface 335, to receive the Internet route response according to the process described above with reference toFIG. 14 andFIG. 15 . Processing at the non-gateway node may proceed fromblock 1802 to block 1804. The combination of such acts and components may comprise means for receiving, at the non-gateway node, a response message from at least one gateway node on the network, wherein the response message includes an address of the at least one gateway node and a gateway indicator. - At
block 1804, the non-gateway node may set, at the non-gateway node, a gateway pointer equal to the address of the at least one gateway node. For example, processors 305 (FIG. 3 ) may, according to the process described above with reference toFIG. 14 andFIG. 15 , access instructions stored inmain memory 310 and/orlocal storage 315 to read the destination address of the Internet route reply, access one or more memory locations inmain memory 310 and/orlocal storage 315, and record the destination address in memory in association with a gateway pointer. The combination of such acts and components may comprise means for setting, at the non-gateway node, a gateway pointer equal to the address of the at least one gateway node. -
FIG. 19 illustrates example blocks executed by gateway nodes to implement Internet-informed routing by modification of existing routing mechanisms in the ad hoc on-demand distance vector (AODV) routing standards. Atblock 1900, the gateway node may receive an Internet route request from one or more neighbor nodes in the network. For example, processors 305 (FIG. 3 ) may access instructions stored inmain memory 310 and/orlocal storage 315 to operate I/O devices 320,Bluetooth interface 325,WLAN interface 330, andvirtual network interface 335, to receive the Internet route request according to the process described above with reference toFIG. 14 andFIG. 15 . Processing at the gateway node may proceed fromblock 1900 to block 1902. The combination of such acts and components may comprise means for receiving, at a gateway node, an Internet route request from one or more neighbor nodes in the network. - At
block 1902, the gateway node may transmit a response message to the one or more neighbor nodes, wherein the response message includes an address of the gateway node and a gateway indicator. For example, processors 305 (FIG. 3 ) may access instructions stored inmain memory 310 and/orlocal storage 315 to operate I/O devices 320,Bluetooth interface 325,WLAN interface 330, andvirtual network interface 335, to generate the response message and send the response message to neighbor nodes according to the process described above with reference toFIG. 14 andFIG. 15 . The combination of such acts and components may comprise means for transmitting, from a gateway node, a response message to the one or more neighbor nodes, wherein the response message includes an address of the gateway node and a gateway indicator. -
FIG. 20 illustrates example blocks executed by non-gateway nodes to implement Internet-informed routing by using the unmodified AODV routing and lists of potential gateway nodes. Atblock 2000, the non-gateway node may receive an announcement of Internet connectivity from one or more gateway nodes on the network, wherein the announcement includes an address of the one or more neighbor nodes. For example, processors 305 (FIG. 3 ) may access instructions stored inmain memory 310 and/orlocal storage 315 to operate I/O devices 320,Bluetooth interface 325,WLAN interface 330,virtual network interface 335,IP layer processing 340, UDP/TCP layer processing 345,IP application 350,IP service 355, andSOA bus daemon 360, to receive the announcement over the SOA bus according to the process described above with reference toFIG. 16 andFIG. 17 . Processing at the non-gateway node may proceed fromblock 2000 to block 2002. The combination of such acts and components may comprise means for receiving, at a non-gateway node, an announcement of Internet connectivity from one or more gateway nodes on the network, wherein the announcement includes an address of the one or more neighbor nodes. - At
block 2002, the non-gateway node may store the address of the one or more gateway nodes to a list of potential gateways. For example, processors 305 (FIG. 3 ) may, according to the process described above with reference toFIG. 16 andFIG. 17 , access instructions stored inmain memory 310 and/orlocal storage 315 to read the destination address of the Internet route reply, access one or more memory locations inmain memory 310 and/orlocal storage 315, and record the address in memory in association with a list of potential gateways. Processing at the non-gateway node may proceed fromblock 2002 to block 2004. The combination of such acts and components may comprise means for storing, at a non-gateway node, the address of the one or more gateway nodes to a list of potential gateways. - At
block 2004, the non-gateway node may receive packets for transmission to an Internet destination. For example, processors 305 (FIG. 3 ) may access instructions stored inmain memory 310 and/orlocal storage 315 to operate I/O devices 320,Bluetooth interface 325,WLAN interface 330,virtual network interface 335,IP layer processing 340, UDP/TCP layer processing 345,IP application 350,IP service 355, andSOA bus daemon 360, to receive IP packets either from a neighbor node or from a locally executed application. Processing at the non-gateway node may proceed fromblock 2004 to block 2006. The combination of such acts and components may comprise means for receiving packets for transmission to an Internet destination. - At
block 2006, the non-gateway node may select a gateway address from the list of potential gateways. For example, processors 305 (FIG. 3 ) may, according to the process described above with reference toFIG. 16 andFIG. 17 , access instructions stored inmain memory 310 and/orlocal storage 315 to access one or more memory locations inmain memory 310 and/orlocal storage 315, and read an address in memory in association with a list of potential gateways. Processing at the non-gateway node may proceed fromblock 2006 to block 2008. The combination of such acts and components may comprise means for selecting a gateway address from the list of potential gateways. - At
block 2008, the non-gateway node may transmit the packets to a destination gateway associated with the gateway address. For example, processors 305 (FIG. 3 ) may access instructions stored inmain memory 310 and/orlocal storage 315 to operate I/O devices 320,Bluetooth interface 325,WLAN interface 330,virtual network interface 335,IP layer processing 340, UDP/TCP layer processing 345,IP application 350,IP service 355, andSOA bus daemon 360, to transmit the packets to a destination gateway associated with the gateway address. The combination of such acts and components may comprise means for to transmitting the packets to a destination gateway associated with the gateway address - The detailed description set forth above in connection with the appended drawings describes exemplary embodiments and does not represent the only embodiments that may be implemented or that are within the scope of the claims. The term “exemplary” used throughout this description means “serving as an example, instance, or illustration,” and not “preferred” or “advantageous over other embodiments.” The detailed description includes specific details for the purpose of providing an understanding of the described techniques. These techniques, however, may be practiced without these specific details. In some instances, well-known structures and devices are shown in block diagram form in order to avoid obscuring the concepts of the described embodiments.
- Techniques described herein may be used for various wireless communications systems such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and other systems. The terms “system” and “network” are often used interchangeably. A CDMA system may implement a radio technology such as CDMA2000, Universal Terrestrial Radio Access (UTRA), etc. CDMA2000 covers IS-2000, IS-95, and IS-856 standards. IS-2000 Releases 0 and A are commonly referred to as
CDMA2000 1×, 1×, etc. IS-856 (TIA-856) is commonly referred to asCDMA2000 1×EV-DO, High Rate Packet Data (HRPD), etc. UTRA includes Wideband CDMA (WCDMA) and other variants of CDMA. A TDMA system may implement a radio technology such as Global System for Mobile Communications (GSM). An OFDMA system may implement a radio technology such as Ultra Mobile Broadband (UMB), Evolved UTRA (E-UTRA), IEEE 802.11 (Wi-Fi), IEEE 802.16 (WiMAX), IEEE 802.20, Flash-OFDMA, etc. UTRA and E-UTRA are part of Universal Mobile Telecommunication System (UMTS). 3GPP Long Term Evolution (LTE) and LTE-Advanced (LTE-A) are new releases of UMTS that use E-UTRA. UTRA, E-UTRA, UMTS, LTE, LTE-A, and GSM are described in documents from an organization named “3rd Generation Partnership Project” (3GPP). CDMA2000 and UMB are described in documents from an organization named “3rdGeneration Partnership Project 2” (3GPP2). The techniques described herein may be used for the systems and radio technologies mentioned above as well as other systems and radio technologies. - Information and signals may be represented using any of a variety of different technologies and techniques. For example, data, instructions, commands, information, signals, bits, symbols, and chips that may be referenced throughout the above description may be represented by voltages, currents, electromagnetic waves, magnetic fields or particles, optical fields or particles, or any combination thereof.
- The various illustrative blocks and modules described in connection with the disclosure herein may be implemented or performed with a general-purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general-purpose processor may be a microprocessor, but in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, multiple microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration.
- The functions described herein may be implemented in hardware, software executed by a processor, firmware, or any combination thereof. If implemented in software executed by a processor, the functions may be stored on or transmitted over as one or more instructions or code on a computer-readable medium. Other examples and implementations are within the scope and spirit of the disclosure and appended claims. For example, due to the nature of software, functions described above can be implemented using software executed by a processor, hardware, firmware, hardwiring, or combinations of any of these. Features implementing functions may also be physically located at various positions, including being distributed such that portions of functions are implemented at different physical locations. Also, as used herein, including in the claims, “or” as used in a list of items prefaced by “at least one of” indicates a disjunctive list such that, for example, a list of “at least one of A, B, or C” means A or B or C or AB or AC or BC or ABC (i.e., A and B and C).
- Computer-readable media includes both computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another. A storage medium may be any available medium that can be accessed by a general purpose or special purpose computer. By way of example, and not limitation, computer-readable media can comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to carry or store desired program code means in the form of instructions or data structures and that can be accessed by a general-purpose or special-purpose computer, or a general-purpose or special-purpose processor. Also, any connection is properly termed a computer-readable medium. For example, if the software is transmitted from a website, server, or other remote source using a coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwave, then the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of medium. Disk and disc, as used herein, include compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk and blu-ray disc where disks usually reproduce data magnetically, while discs reproduce data optically with lasers. Combinations of the above are also included within the scope of computer-readable media.
- The previous description of the disclosure is provided to enable a person skilled in the art to make or use the disclosure. Various modifications to the disclosure will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other variations without departing from the spirit or scope of the disclosure. Throughout this disclosure the term “example” or “exemplary” indicates an example or instance and does not imply or require any preference for the noted example. Thus, the disclosure is not to be limited to the examples and designs described herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.
Claims (16)
1. A method for routing in an ad hoc peer-to-peer network, comprising:
receiving, at a non-gateway node, an announcement of internet connectivity from one or more gateway nodes on the network, wherein the announcement includes an address of the one or more gateway nodes;
storing, at the non-gateway node, the address of the one or more gateway nodes to a list of potential gateways;
receiving packets for transmission to an internet destination;
selecting a gateway address from the list of potential gateways; and
transmitting the packets to a destination gateway associated with the gateway address.
2. The method of claim 1 , further comprising:
masking the internet destination from the packets prior to the transmitting.
3. The method of claim 1 , wherein the received announcement of internet connectivity includes a plurality of response messages, each of the plurality of response messages received from a different gateway node of the one or more gateway nodes on the network in response to an internet route request, wherein each of the plurality of response messages includes an address for a corresponding one of the one or more gateway nodes and a gateway indicator.
4. The method of claim 1 , further comprising:
implementing a Service Oriented Architecture (SOA) bus over the ad hoc peer-to-peer network.
5. An apparatus for routing in an ad hoc peer-to-peer network, said apparatus comprising:
means for receiving, at a non-gateway node, an announcement of internet connectivity from one or more gateway nodes on the network, wherein the announcement includes an address of the one or more gateway nodes;
means for storing, at the non-gateway node, the address of the one or more gateway nodes to a list of potential gateways;
means for receiving packets for transmission to an internet destination;
means for selecting a gateway address from the list of potential gateways; and
means for transmitting the packets to a destination gateway associated with the gateway address.
6. The apparatus of claim 5 , further comprising:
means for masking the internet destination from the packets prior to the transmitting.
7. The apparatus of claim 5 , wherein the received announcement of internet connectivity includes a plurality of response messages, each of the plurality of response messages received from a different gateway node of the one or more gateway nodes on the network in response to an internet route request, wherein each of the plurality of response messages includes an address for a corresponding one of the one or more gateway nodes and a gateway indicator.
8. The apparatus of claim 5 , further comprising:
means for implementing a Service Oriented Architecture (SOA) bus over the ad hoc peer-to-peer network.
9. A computer program product comprising:
a non-transitory computer-readable medium including:
code for receiving, at a non-gateway node, an announcement of internet connectivity from one or more gateway nodes on an ad hoc peer-to-peer network, wherein the announcement includes an address of the one or more gateway nodes;
code for storing, at the non-gateway node, the address of the one or more gateway nodes to a list of potential gateways;
code for receiving packets for transmission to an internet destination;
code for selecting a gateway address from the list of potential gateways; and
code for transmitting the packets to a destination gateway associated with the gateway address.
10. The computer program product of claim 9 , wherein the non-transitory computer-readable medium further includes:
code for masking the internet destination from the packets prior to the transmitting.
11. The computer program product of claim 9 , wherein the received announcement of internet connectivity includes a plurality of response messages, each of the plurality of response messages received from a different gateway node of the one or more gateway nodes on the network in response to an internet route request, wherein each of the plurality of response messages includes an address for a corresponding one of the one or more gateway nodes and a gateway indicator.
12. The computer program product of claim 9 , wherein the non-transitory computer-readable medium further includes:
code for implementing a Service Oriented Architecture (SOA) bus over the ad hoc peer-to-peer network.
13. A non-gateway node in an ad hoc peer-to-peer network, the network node comprising:
at least one processor; and
a memory coupled to said at least one processor,
wherein said at least one processor is configured to:
receive, at the non-gateway node, an announcement of internet connectivity from one or more gateway nodes on the network, wherein the announcement includes an address of the one or more gateway nodes;
store, at the non-gateway node, the address of the one or more gateway nodes to a list of potential gateways;
receive packets for transmission to an internet destination;
select a gateway address from the list of potential gateways; and
transmit the packets to a destination gateway associated with the gateway address.
14. The non-gateway node of claim 13 , wherein said at least one processor is further configured to:
mask the internet destination from the packets prior to the transmitting.
15. The non-gateway node of claim 13 , wherein the received announcement of internet connectivity includes a plurality of response messages, each of the plurality of response messages received from a different gateway node of the one or more gateway nodes on the network in response to an internet route request, wherein each of the plurality of response messages includes an address for a corresponding one of the one or more gateway nodes and a gateway indicator.
16. The non-gateway node of claim 13 , wherein said at least one processor is further configured to:
implement a Service Oriented Architecture (SOA) bus over the ad hoc peer-to-peer network.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US15/445,801 US20170171073A1 (en) | 2012-02-21 | 2017-02-28 | Internet routing over a service-oriented architecture bus |
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US13/400,889 US9350814B2 (en) | 2012-02-21 | 2012-02-21 | Internet protocol connectivity over a service-oriented architecture bus |
US13/786,376 US9621458B2 (en) | 2012-02-21 | 2013-03-05 | Internet routing over a service-oriented architecture bus |
US15/445,801 US20170171073A1 (en) | 2012-02-21 | 2017-02-28 | Internet routing over a service-oriented architecture bus |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US13/786,376 Division US9621458B2 (en) | 2012-02-21 | 2013-03-05 | Internet routing over a service-oriented architecture bus |
Publications (1)
Publication Number | Publication Date |
---|---|
US20170171073A1 true US20170171073A1 (en) | 2017-06-15 |
Family
ID=50336584
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US13/786,376 Expired - Fee Related US9621458B2 (en) | 2012-02-21 | 2013-03-05 | Internet routing over a service-oriented architecture bus |
US15/445,801 Abandoned US20170171073A1 (en) | 2012-02-21 | 2017-02-28 | Internet routing over a service-oriented architecture bus |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US13/786,376 Expired - Fee Related US9621458B2 (en) | 2012-02-21 | 2013-03-05 | Internet routing over a service-oriented architecture bus |
Country Status (6)
Country | Link |
---|---|
US (2) | US9621458B2 (en) |
EP (1) | EP2965561A2 (en) |
JP (1) | JP2016515339A (en) |
KR (1) | KR20150129308A (en) |
CN (1) | CN105009643B (en) |
WO (1) | WO2014138265A2 (en) |
Families Citing this family (89)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9456054B2 (en) | 2008-05-16 | 2016-09-27 | Palo Alto Research Center Incorporated | Controlling the spread of interests and content in a content centric network |
US8923293B2 (en) | 2009-10-21 | 2014-12-30 | Palo Alto Research Center Incorporated | Adaptive multi-interface use for content networking |
US9350814B2 (en) | 2012-02-21 | 2016-05-24 | Qualcomm Incorporated | Internet protocol connectivity over a service-oriented architecture bus |
WO2015083320A1 (en) * | 2013-12-06 | 2015-06-11 | 日本電気株式会社 | Communication terminal, communication method, and communication program |
US10098051B2 (en) * | 2014-01-22 | 2018-10-09 | Cisco Technology, Inc. | Gateways and routing in software-defined manets |
US9954678B2 (en) | 2014-02-06 | 2018-04-24 | Cisco Technology, Inc. | Content-based transport security |
US9836540B2 (en) | 2014-03-04 | 2017-12-05 | Cisco Technology, Inc. | System and method for direct storage access in a content-centric network |
US9626413B2 (en) | 2014-03-10 | 2017-04-18 | Cisco Systems, Inc. | System and method for ranking content popularity in a content-centric network |
US9716622B2 (en) | 2014-04-01 | 2017-07-25 | Cisco Technology, Inc. | System and method for dynamic name configuration in content-centric networks |
US9473576B2 (en) | 2014-04-07 | 2016-10-18 | Palo Alto Research Center Incorporated | Service discovery using collection synchronization with exact names |
US9992281B2 (en) | 2014-05-01 | 2018-06-05 | Cisco Technology, Inc. | Accountable content stores for information centric networks |
US9609014B2 (en) | 2014-05-22 | 2017-03-28 | Cisco Systems, Inc. | Method and apparatus for preventing insertion of malicious content at a named data network router |
US9699198B2 (en) | 2014-07-07 | 2017-07-04 | Cisco Technology, Inc. | System and method for parallel secure content bootstrapping in content-centric networks |
US9621354B2 (en) | 2014-07-17 | 2017-04-11 | Cisco Systems, Inc. | Reconstructable content objects |
US9590887B2 (en) | 2014-07-18 | 2017-03-07 | Cisco Systems, Inc. | Method and system for keeping interest alive in a content centric network |
US9729616B2 (en) | 2014-07-18 | 2017-08-08 | Cisco Technology, Inc. | Reputation-based strategy for forwarding and responding to interests over a content centric network |
US9882964B2 (en) | 2014-08-08 | 2018-01-30 | Cisco Technology, Inc. | Explicit strategy feedback in name-based forwarding |
US9729662B2 (en) | 2014-08-11 | 2017-08-08 | Cisco Technology, Inc. | Probabilistic lazy-forwarding technique without validation in a content centric network |
US9800637B2 (en) | 2014-08-19 | 2017-10-24 | Cisco Technology, Inc. | System and method for all-in-one content stream in content-centric networks |
US10069933B2 (en) | 2014-10-23 | 2018-09-04 | Cisco Technology, Inc. | System and method for creating virtual interfaces based on network characteristics |
US9590948B2 (en) | 2014-12-15 | 2017-03-07 | Cisco Systems, Inc. | CCN routing using hardware-assisted hash tables |
US10237189B2 (en) | 2014-12-16 | 2019-03-19 | Cisco Technology, Inc. | System and method for distance-based interest forwarding |
US10003520B2 (en) | 2014-12-22 | 2018-06-19 | Cisco Technology, Inc. | System and method for efficient name-based content routing using link-state information in information-centric networks |
US9660825B2 (en) | 2014-12-24 | 2017-05-23 | Cisco Technology, Inc. | System and method for multi-source multicasting in content-centric networks |
US20160192403A1 (en) * | 2014-12-30 | 2016-06-30 | Qualcomm Incorporated | Mechanism to provide lte voice, internet and embms services over ethernet for connected home architecture |
US9916457B2 (en) | 2015-01-12 | 2018-03-13 | Cisco Technology, Inc. | Decoupled name security binding for CCN objects |
US9954795B2 (en) | 2015-01-12 | 2018-04-24 | Cisco Technology, Inc. | Resource allocation using CCN manifests |
US9946743B2 (en) | 2015-01-12 | 2018-04-17 | Cisco Technology, Inc. | Order encoded manifests in a content centric network |
US9832291B2 (en) | 2015-01-12 | 2017-11-28 | Cisco Technology, Inc. | Auto-configurable transport stack |
US10333840B2 (en) | 2015-02-06 | 2019-06-25 | Cisco Technology, Inc. | System and method for on-demand content exchange with adaptive naming in information-centric networks |
US10075401B2 (en) | 2015-03-18 | 2018-09-11 | Cisco Technology, Inc. | Pending interest table behavior |
US10616177B2 (en) | 2015-03-31 | 2020-04-07 | Willie L. Donaldson | Secure dynamic address resolution and communication system, method, and device |
WO2016172252A1 (en) * | 2015-04-20 | 2016-10-27 | Shoelace Wireless, Inc. | Systems for improved mobile internet speed and security |
WO2016202381A1 (en) * | 2015-06-17 | 2016-12-22 | Telefonaktiebolaget Lm Ericsson (Publ) | Path setup in a mesh network |
US10075402B2 (en) | 2015-06-24 | 2018-09-11 | Cisco Technology, Inc. | Flexible command and control in content centric networks |
US10701038B2 (en) | 2015-07-27 | 2020-06-30 | Cisco Technology, Inc. | Content negotiation in a content centric network |
US9986034B2 (en) | 2015-08-03 | 2018-05-29 | Cisco Technology, Inc. | Transferring state in content centric network stacks |
US9832123B2 (en) | 2015-09-11 | 2017-11-28 | Cisco Technology, Inc. | Network named fragments in a content centric network |
US10355999B2 (en) | 2015-09-23 | 2019-07-16 | Cisco Technology, Inc. | Flow control with network named fragments |
US9977809B2 (en) | 2015-09-24 | 2018-05-22 | Cisco Technology, Inc. | Information and data framework in a content centric network |
US10313227B2 (en) | 2015-09-24 | 2019-06-04 | Cisco Technology, Inc. | System and method for eliminating undetected interest looping in information-centric networks |
US10454820B2 (en) | 2015-09-29 | 2019-10-22 | Cisco Technology, Inc. | System and method for stateless information-centric networking |
US10263965B2 (en) | 2015-10-16 | 2019-04-16 | Cisco Technology, Inc. | Encrypted CCNx |
US9794238B2 (en) | 2015-10-29 | 2017-10-17 | Cisco Technology, Inc. | System for key exchange in a content centric network |
US9807205B2 (en) | 2015-11-02 | 2017-10-31 | Cisco Technology, Inc. | Header compression for CCN messages using dictionary |
US9912776B2 (en) | 2015-12-02 | 2018-03-06 | Cisco Technology, Inc. | Explicit content deletion commands in a content centric network |
US10097346B2 (en) | 2015-12-09 | 2018-10-09 | Cisco Technology, Inc. | Key catalogs in a content centric network |
US10078062B2 (en) | 2015-12-15 | 2018-09-18 | Palo Alto Research Center Incorporated | Device health estimation by combining contextual information with sensor data |
US10257271B2 (en) | 2016-01-11 | 2019-04-09 | Cisco Technology, Inc. | Chandra-Toueg consensus in a content centric network |
US9949301B2 (en) | 2016-01-20 | 2018-04-17 | Palo Alto Research Center Incorporated | Methods for fast, secure and privacy-friendly internet connection discovery in wireless networks |
US10305864B2 (en) | 2016-01-25 | 2019-05-28 | Cisco Technology, Inc. | Method and system for interest encryption in a content centric network |
US10043016B2 (en) | 2016-02-29 | 2018-08-07 | Cisco Technology, Inc. | Method and system for name encryption agreement in a content centric network |
US10742596B2 (en) | 2016-03-04 | 2020-08-11 | Cisco Technology, Inc. | Method and system for reducing a collision probability of hash-based names using a publisher identifier |
US10051071B2 (en) | 2016-03-04 | 2018-08-14 | Cisco Technology, Inc. | Method and system for collecting historical network information in a content centric network |
US10038633B2 (en) | 2016-03-04 | 2018-07-31 | Cisco Technology, Inc. | Protocol to query for historical network information in a content centric network |
US10003507B2 (en) | 2016-03-04 | 2018-06-19 | Cisco Technology, Inc. | Transport session state protocol |
US9832116B2 (en) | 2016-03-14 | 2017-11-28 | Cisco Technology, Inc. | Adjusting entries in a forwarding information base in a content centric network |
US10212196B2 (en) | 2016-03-16 | 2019-02-19 | Cisco Technology, Inc. | Interface discovery and authentication in a name-based network |
US11436656B2 (en) | 2016-03-18 | 2022-09-06 | Palo Alto Research Center Incorporated | System and method for a real-time egocentric collaborative filter on large datasets |
US10067948B2 (en) | 2016-03-18 | 2018-09-04 | Cisco Technology, Inc. | Data deduping in content centric networking manifests |
US10091330B2 (en) | 2016-03-23 | 2018-10-02 | Cisco Technology, Inc. | Interest scheduling by an information and data framework in a content centric network |
US10033639B2 (en) | 2016-03-25 | 2018-07-24 | Cisco Technology, Inc. | System and method for routing packets in a content centric network using anonymous datagrams |
US10320760B2 (en) | 2016-04-01 | 2019-06-11 | Cisco Technology, Inc. | Method and system for mutating and caching content in a content centric network |
US9930146B2 (en) | 2016-04-04 | 2018-03-27 | Cisco Technology, Inc. | System and method for compressing content centric networking messages |
US10425503B2 (en) | 2016-04-07 | 2019-09-24 | Cisco Technology, Inc. | Shared pending interest table in a content centric network |
US10027578B2 (en) | 2016-04-11 | 2018-07-17 | Cisco Technology, Inc. | Method and system for routable prefix queries in a content centric network |
US10404450B2 (en) | 2016-05-02 | 2019-09-03 | Cisco Technology, Inc. | Schematized access control in a content centric network |
US10320675B2 (en) | 2016-05-04 | 2019-06-11 | Cisco Technology, Inc. | System and method for routing packets in a stateless content centric network |
US10547589B2 (en) | 2016-05-09 | 2020-01-28 | Cisco Technology, Inc. | System for implementing a small computer systems interface protocol over a content centric network |
US10063414B2 (en) | 2016-05-13 | 2018-08-28 | Cisco Technology, Inc. | Updating a transport stack in a content centric network |
US10084764B2 (en) | 2016-05-13 | 2018-09-25 | Cisco Technology, Inc. | System for a secure encryption proxy in a content centric network |
US10103989B2 (en) | 2016-06-13 | 2018-10-16 | Cisco Technology, Inc. | Content object return messages in a content centric network |
US10305865B2 (en) | 2016-06-21 | 2019-05-28 | Cisco Technology, Inc. | Permutation-based content encryption with manifests in a content centric network |
US10148572B2 (en) | 2016-06-27 | 2018-12-04 | Cisco Technology, Inc. | Method and system for interest groups in a content centric network |
US10009266B2 (en) | 2016-07-05 | 2018-06-26 | Cisco Technology, Inc. | Method and system for reference counted pending interest tables in a content centric network |
US9992097B2 (en) | 2016-07-11 | 2018-06-05 | Cisco Technology, Inc. | System and method for piggybacking routing information in interests in a content centric network |
US10122624B2 (en) | 2016-07-25 | 2018-11-06 | Cisco Technology, Inc. | System and method for ephemeral entries in a forwarding information base in a content centric network |
US10069729B2 (en) | 2016-08-08 | 2018-09-04 | Cisco Technology, Inc. | System and method for throttling traffic based on a forwarding information base in a content centric network |
US10956412B2 (en) | 2016-08-09 | 2021-03-23 | Cisco Technology, Inc. | Method and system for conjunctive normal form attribute matching in a content centric network |
US10033642B2 (en) | 2016-09-19 | 2018-07-24 | Cisco Technology, Inc. | System and method for making optimal routing decisions based on device-specific parameters in a content centric network |
US10212248B2 (en) | 2016-10-03 | 2019-02-19 | Cisco Technology, Inc. | Cache management on high availability routers in a content centric network |
US10447805B2 (en) | 2016-10-10 | 2019-10-15 | Cisco Technology, Inc. | Distributed consensus in a content centric network |
US10135948B2 (en) | 2016-10-31 | 2018-11-20 | Cisco Technology, Inc. | System and method for process migration in a content centric network |
US10243851B2 (en) | 2016-11-21 | 2019-03-26 | Cisco Technology, Inc. | System and method for forwarder connection information in a content centric network |
US10171343B2 (en) * | 2016-12-21 | 2019-01-01 | Sony Corporation | Routing multiple data streams simultaneously in wireless networks |
EP3831021A1 (en) | 2018-07-27 | 2021-06-09 | Gotenna Inc. | VINEtm ZERO-CONTROL ROUTING USING DATA PACKET INSPECTION FOR WIRELESS MESH NETWORKS |
US10805384B1 (en) * | 2018-09-13 | 2020-10-13 | Parallels International Gmbh | Systems and methods for load balancing server infrastructure |
CN111314341B (en) * | 2020-02-14 | 2022-05-13 | 烽火通信科技股份有限公司 | Method and device for realizing authentication of Internet of things terminal equipment in multi-Internet of things gateway scene |
US12034570B2 (en) | 2022-03-14 | 2024-07-09 | T-Mobile Usa, Inc. | Multi-element routing system for mobile communications |
Family Cites Families (38)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5781550A (en) | 1996-02-02 | 1998-07-14 | Digital Equipment Corporation | Transparent and secure network gateway |
NZ337772A (en) * | 1997-03-12 | 2001-09-28 | Nomadix Inc | Nomadic translator or router |
US6101499A (en) | 1998-04-08 | 2000-08-08 | Microsoft Corporation | Method and computer program product for automatically generating an internet protocol (IP) address |
US6892230B1 (en) | 1999-06-11 | 2005-05-10 | Microsoft Corporation | Dynamic self-configuration for ad hoc peer networking using mark-up language formated description messages |
US7072650B2 (en) | 2000-11-13 | 2006-07-04 | Meshnetworks, Inc. | Ad hoc peer-to-peer mobile radio access system interfaced to the PSTN and cellular networks |
US7697504B2 (en) | 2000-12-29 | 2010-04-13 | Tropos Networks, Inc. | Mesh network that includes fixed and mobile access nodes |
US7174363B1 (en) | 2001-02-22 | 2007-02-06 | Charles Schwab & Co., Inc. | Distributed computing system architecture |
US8266212B2 (en) | 2001-11-23 | 2012-09-11 | Igt | Game talk service bus |
US7280519B1 (en) * | 2002-01-08 | 2007-10-09 | Darrell Harvey Shane | Dynamic metropolitan area mobile network |
CN103001923B (en) * | 2003-06-05 | 2016-03-30 | 英特特拉斯特技术公司 | For controlling the method and system of the access to digital content fragment on the computer systems |
US7142866B2 (en) * | 2003-09-09 | 2006-11-28 | Harris Corporation | Load leveling in mobile ad-hoc networks to support end-to-end delay reduction, QoS and energy leveling |
US7937088B2 (en) * | 2004-03-26 | 2011-05-03 | Qualcomm Incorporated | Routing communications in an ad hoc network |
GB2416958A (en) * | 2004-07-30 | 2006-02-08 | Orange Personal Comm Serv Ltd | Communicating internet packet data over a packet radio network |
US7468954B2 (en) * | 2004-12-14 | 2008-12-23 | Harris Corporation | Mobile ad-hoc network providing expedited conglomerated broadcast message reply features and related methods |
US7920549B2 (en) | 2005-07-20 | 2011-04-05 | Verizon Business Global Llc | Method and system for providing secure media gateways to support interdomain traversal |
US20070070959A1 (en) * | 2005-09-23 | 2007-03-29 | Almeroth Kevin C | Infrastructure mesh networks |
AU2005338057B2 (en) * | 2005-11-09 | 2011-04-21 | Interdigital Ce Patent Holdings | Route selection in wireless networks |
US7808960B1 (en) * | 2006-05-25 | 2010-10-05 | The Hong Kong University Of Science And Technology | Wireless infrastructure and ad hoc network integration |
JP4680866B2 (en) * | 2006-10-31 | 2011-05-11 | 株式会社日立製作所 | Packet transfer device with gateway load balancing function |
KR101203461B1 (en) * | 2006-11-10 | 2012-11-21 | 삼성전자주식회사 | Routing method in multi-hop cellular system and the multi-hop cellular system |
US8489701B2 (en) | 2007-01-30 | 2013-07-16 | Microsoft Corporation | Private virtual LAN spanning a public network for connection of arbitrary hosts |
US7873019B2 (en) | 2007-05-31 | 2011-01-18 | International Business Machines Corporation | Systems and methods for establishing gateway bandwidth sharing ad-hoc networks |
CN101388831B (en) * | 2007-09-14 | 2011-09-21 | 华为技术有限公司 | Data transmission method, node and gateway |
US8880567B2 (en) | 2007-12-18 | 2014-11-04 | International Business Machines Corporation | Discovery and management of configuration data contained within mashups |
CN101540714B (en) * | 2008-03-21 | 2012-02-01 | 华为技术有限公司 | Method for establishing network path and transmitting data and network nodes |
US20090248793A1 (en) | 2008-03-25 | 2009-10-01 | Contribio Ab | Providing Content In a Network |
WO2010013153A1 (en) * | 2008-07-30 | 2010-02-04 | Koninklijke Philips Electronics, N.V. | A method for discovering paths with sufficient medium time in wireless mesh networks |
KR20100040658A (en) | 2008-10-10 | 2010-04-20 | 삼성전자주식회사 | Method and apparatus for preventing ip address conflict in remote access service of upnp network |
KR101085629B1 (en) | 2009-03-16 | 2011-11-22 | 삼성전자주식회사 | Method and apparatus for setting of internet protocol communication network in mobile communication terminal |
CN101888681B (en) * | 2009-05-12 | 2013-02-27 | 华为技术有限公司 | Method, device and system for creating route |
US9307393B2 (en) | 2009-05-15 | 2016-04-05 | Telcordia Technologies, Inc. | Peer-to-peer mobility management in heterogeneous IPV4 networks |
CN102291795B (en) * | 2010-06-21 | 2014-02-19 | 富士通株式会社 | Wireless communication device, wireless communication network and control router selection method |
JP5323020B2 (en) * | 2010-09-29 | 2013-10-23 | 三菱電機株式会社 | Communication system, communication method, and handy terminal |
JP5542028B2 (en) * | 2010-10-28 | 2014-07-09 | 三菱電機株式会社 | Node station and redundant path control method |
US8352491B2 (en) | 2010-11-12 | 2013-01-08 | International Business Machines Corporation | Service oriented architecture (SOA) service registry system with enhanced search capability |
CN102404739B (en) * | 2011-09-26 | 2014-03-19 | 苏州大学 | Detection method for wormhole attacks in Ad Hoc network |
US9350814B2 (en) | 2012-02-21 | 2016-05-24 | Qualcomm Incorporated | Internet protocol connectivity over a service-oriented architecture bus |
CN102833803B (en) * | 2012-08-20 | 2015-10-28 | 北京交通大学 | A kind of wireless sensor network structure based on IPv6 and subnet switching method inside |
-
2013
- 2013-03-05 US US13/786,376 patent/US9621458B2/en not_active Expired - Fee Related
-
2014
- 2014-03-05 CN CN201480011845.9A patent/CN105009643B/en not_active Expired - Fee Related
- 2014-03-05 WO PCT/US2014/020815 patent/WO2014138265A2/en active Application Filing
- 2014-03-05 KR KR1020157027354A patent/KR20150129308A/en active IP Right Grant
- 2014-03-05 EP EP14711426.8A patent/EP2965561A2/en not_active Withdrawn
- 2014-03-05 JP JP2015561615A patent/JP2016515339A/en active Pending
-
2017
- 2017-02-28 US US15/445,801 patent/US20170171073A1/en not_active Abandoned
Also Published As
Publication number | Publication date |
---|---|
WO2014138265A2 (en) | 2014-09-12 |
JP2016515339A (en) | 2016-05-26 |
CN105009643A (en) | 2015-10-28 |
US9621458B2 (en) | 2017-04-11 |
CN105009643B (en) | 2018-11-13 |
US20140254595A1 (en) | 2014-09-11 |
KR20150129308A (en) | 2015-11-19 |
EP2965561A2 (en) | 2016-01-13 |
WO2014138265A3 (en) | 2014-11-06 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US9621458B2 (en) | Internet routing over a service-oriented architecture bus | |
US9350814B2 (en) | Internet protocol connectivity over a service-oriented architecture bus | |
US10057342B2 (en) | Infrastructure access via neighbor awareness networking data path | |
JP5485398B2 (en) | Method and system for service discovery management in a peer-to-peer network | |
JP5805813B2 (en) | Method and system for peer-to-peer network discovery using multi-user diversity | |
US10863422B2 (en) | Mechanisms for ad hoc service discovery | |
US8724513B2 (en) | Methods and apparatus for distribution of IP layer routing information in peer-to-peer overlay networks | |
KR100679037B1 (en) | Method and apparatus for performing fast handover in wireless Networks | |
US8693372B2 (en) | Methods and apparatus for forming, maintaining and/or using overlapping networks | |
JP2019525518A (en) | Method for establishing a network cluster between networked devices | |
US20170332439A1 (en) | Extending the range of mesh networks | |
JP2018526923A (en) | Enhanced neighborhood discovery for communication networks | |
Jung et al. | IDNet: beyond all‐IP network | |
US20240214301A1 (en) | Packet processing method and related apparatus | |
US20150098457A1 (en) | Enabling internet protocol connectivity across multi-hop mobile wireless networks via a service oriented architecture | |
JP5944496B2 (en) | Method and apparatus for advanced discovery in peer-to-peer networks with synchronous discovery wake-up | |
WO2013127879A1 (en) | Management of the mobility of a mobile network | |
US20240259342A1 (en) | Apparatus and method for providing basic support for ipv6 networks operating over 5g vehicle-to-everything communications | |
Sadio et al. | Improving security and mobility for remote access: a wireless sensor network case | |
CN115022232A (en) | Multicast group management method, device, equipment and storage medium |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: QUALCOMM INCORPORATED, CALIFORNIA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:LUO, XUN;MAHENDRAN, ARUNGUNDRAM CHANDRASEKARAN;REEL/FRAME:041404/0371 Effective date: 20130507 |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |