Back

Network Architecture


Drawings

Brief Description:

Figure 1 illustrates a network architecture in which a group of mobile devices and services communicate over a network

Detailed Description:

As illustrated in Figure 1, a general network topology implemented in one embodiment of the invention can include a group of “client” or “peer” mobile computing devices A-D (mobile device A 112, mobile device B 114, mobile device C 116, mobile device D 118) respectively, communicating with one another and with one or more services (CDX service 104, matchmaker service 106, and invitation service 108) over a network 110. Although illustrated as a single network cloud in Figure 1, the network 110 can include a variety of different components including public networks such as the internet and private networks such as local Wi-Fi networks (e.g., 802.11n home wireless networks or wireless hotspots), local area Ethernet networks, cellular data networks (e.g., 3G, edge, etc), and WiMAX networks, to name a few. For example, mobile device A 112 may be connected to a home Wi-Fi network represented by network link A 120, mobile device B 114 may be connected to a 3G network (e.g., Universal Mobile Telecommunications System (“UMTS”), High-Speed Uplink Packet Access (“HSUPA”), etc) represented by network link B 122, mobile device C 116 may be connected to a WiMAX network represented by network link C 124, and mobile device D 118 may be connected to a public Wi-Fi network represented by network link D 126. Each of the local networklinks (network link A 120, network link B 122, network link C 124, network link D 126) over which the mobile devices (mobile device A 112, mobile device B 114, mobile device C 116, mobile device D 118) are connected may be coupled to a public network such as the internet through a gateway and/or NAT device (not shown in Figure 1), thereby enabling communication between the various mobile devices (mobile device A 112, mobile device B 114, mobile device C 116, mobile device D 118) over the public network. However, if two mobile devices are on the same local or private network (e.g., the same Wi-Fi network), then the two devices may communicate directly over that local/private network, bypassing the public network. It should be noted, of course, that the underlying principles of the invention are not limited to any particular set of network types or network topologies

Each of the mobile devices (mobile device A 112, mobile device B 114, mobile device C 116, mobile device D 118) illustrated in Figure 1 can communicate with a connection data exchange (CDX service 104), a matchmaker service 106, and an invitation service 108. In one embodiment, the services (CDX service 104, matchmaker service 106, and invitation service 108) can be implemented as software executed across one or more physical computing devices such as servers. As shown in Figure 1, in one embodiment, the services (CDX service 104, matchmaker service 106, and invitation service 108) may be implemented within the context of a larger data service 102 managed by the same entity (e.g., the same data service provider) and accessible by each of the mobile devices (mobile device A 112, mobile device B 114, mobile device C 116, mobile device D 118) over the network 110. The data service 102 can include a local area network (e.g., an Ethernet-based LAN) connecting various types of servers and databases. The data service 102 may also include one or more storage area networks (“SANs”) for storing data. In one embodiment, the databases store and manage data related to each of the mobile devices (mobile device A 112, mobile device B 114, mobile device C 116, mobile device D 118) and the users of those devices (e.g., user account data, device account data, user application data, . . . etc.). 

In one embodiment, matchmaker service 106 can matchtwo or more mobile devices for a collaborative P2P session based on a specified set of conditions. For example, users of two or more of the mobile devices may be interested in playing a particular multi-player game. In such a case, the matchmaker service 106 may identify a group of mobile devices to participate in the game based on variables such as each user’slevel of expertise, the age of each of the users, the timing of the match requests, the particular game for which a match is requested and various game-specific variables. By way of example, and not limitation, the matchmaker service 106 may attempt to matchusers with similar levels of expertise at playing a particular game. Additionally, adults may be matched with other adults and children may be matched with other children. Moreover, the matchmaker service 106 may prioritize user requests based on the order in which those requests are received. The underlying principles of the invention are not limited to any particular set of matching criteria or any particular type of P2P application

As described in detail below, in response to a match request, the matchmaker service 106 can coordinate with the CDX service 104 to ensure that all matched participants receive the necessary connection data for establishing P2P sessions in an efficient and secure manner

In one embodiment, the invitation service 108 also identifies mobile devices for participation in collaborative P2P sessions. However, in the case of the invitation service 108, at least one of the participants is specifically identified by another participant. For example, the user of mobile device A 112 may specifically request a collaborative session with the user of mobile device B 114 (e.g., identifying mobile device B 114 with a user ID or phone number). As with the matchmaker service 106, in response to an invitation request, the invitation service 108 can identify the set of participants and coordinate with the CDX service 104 to ensure that all participants receive the necessary connection data for establishing P2P sessions in an efficient and secure manner

As mentioned above, in one embodiment, the CDX service 104 operates as a central exchange point for connection data required to establish P2P sessions between two or more mobile devices. Specifically, one embodiment of the CDX service generates NAT traversal data (sometimes referred to as “Hole Punch” data) in response to mobile device requests to enable external services and clients to communicate through the NAT of each mobile device (i.e., to “punch a hole” through the NAT to reach the device). For example, in one embodiment, the CDX service detects the external IP address and port needed to communicate with the mobile device and provides this information to the mobile device. In one embodiment, the CDX service also receives and processes lists of mobile devices generated by the matchmaker service 106 and invitation service 108 and efficiently and securely distributes connection data to each of the mobile devices included on the lists (as described in detail below). 

In one embodiment, communication between the mobile devices and the CDX service 104 is established using a relatively lightweight network protocol such as User Datagram Protocol (“UDP”) sockets. As is known by those of skill in the art, UDP socket connections do not require hand-shaking dialogues for guaranteeing packet reliability, ordering, or data integrity and, therefore, do not consume as much packet processing overhead as TCP socket connections. Consequently, UDP’s lightweight, stateless nature is useful for servers that answer small queries from a vast number of clients. Moreover, unlike TCP, UDP is compatible with packet broadcasting (in which packets are sent to all devices on a local network) and multicasting (in which packets are sent to a subset of devices on the local network). As described below, even though UDP may be used, security can be maintained on the CDX service 104 by encrypting NAT traversal data using session keys

In contrast to the low-overhead, lightweight network protocol used by the CDX service 104, in one embodiment, communication between the mobile devices (mobile device A 112, mobile device B 114, mobile device C 116, mobile device D 118) and the matchmaker service 106 and/or invitation service 108 is established with an inherently secure network protocol such as Hypertext Transfer Protocol Secure (“HTTPS”), which relies on Secure Sockets Layer (“SSL”) or Transport Layer Security (“TLS”) connections. Details associated with these protocols are well known by those of skill in the art. 

Specific examples in which mobile devices establish primary and secondary communication channels will now be described with respect to Figure 2. It should be noted, however, that the underlying principles of the invention are not limited to the particular set of communication links and communication channels shown in Figure 2

Brief Description:

Figure 2 illustrates a group of mobile devices connected through primary and secondary communication channels

Detailed Description:

In Figure 2, mobile device A 112 is capable of connecting to a network 110 (e.g., the internet) over communication link (communication link B 210 with NAT device B 206 and over communication link A 206 with NAT device A 202. Similarly, mobile device C 116 is capable of connecting to the network 110 over communication link C 214 with NAT device C 212 and over communication link D 216 with NAT device C 212. By way of example, and not limitation, communication links (communication link B 210 and communication link C 214) may be 3 G communication links and communication links (communication link A 206 and communication link D 216) may be Wi-Fi communication links

Consequently, in this example, there are four different communication channels which may be established between mobile device A 112 and mobile device B 114: a first channel which uses links (communication link B 210 and communication link C 214); a second channel which uses links (communication link B 210 and communication link D 216); a third channel which uses links (communication link A 206 and communication link C 214); and a third channel which uses linkscommunication link A 206 and communication link D 216). In one embodiment, mobile devices A and B will select one of these channels as the primary communication channel based on a prioritization scheme and will select the three remaining channels as backup communication channels. For example, one prioritization scheme may be to select the channel with the highest bandwidth as the primarychannel and to use the remaining channels as the secondary channels. If two or more channels have comparable bandwidth, the prioritization scheme may include selecting the least expensive channel (assuming that the user pays a fee to use one or more of the channels). Alternatively, the prioritization scheme may be to select the least expensive channel as the primarychannel and, if the cost of each channel is the same, to select the highest bandwidth channel. Various different prioritization schemes may be implemented while still complying with the underlying principles of the invention

Mobile device A 112 and mobile device C 116 may utilize the techniques described above to establish the primary communication channel (e.g., by exchanging connection data via the CDX service 104). Alternatively, the mobile device A 112, and mobile device C 116 may implement standard Internet Connectivity Establishment (“ICE”) transactions to exchange the connection data. Regardless of how the primarychannel is established, once it is, the mobile device A 112 and mobile device C 116 may exchange connection data for the secondary communication channels over the primary communication channel. For example, if the primary communication channel in Figure 2 includes communication link A 206 and communication link C 214, then this connection, once established may be used to exchange connection data for secondary communication channels which include communication links (communication link B 210 and communication link C 214). In this example, the connection data exchanged over the primary communication channel may include NAT traversal data and NAT type data for NAT device B 206 and NAT device C 212, including public and private IP addresses/ports for each of the mobile devices

Once the secondary communication channels have been established, they are maintained open using heartbeat packets. For example, device A may periodically transmit a small “heartbeat” packet to device C and/or device A may periodically transmit a small “heartbeat” packet to device C to ensure that the NAT ports used for the secondary channels remain open (NATs will often close ports due to inactivity). The heartbeat packets may be UDP packets with no payload, although the underlying principles of the invention are not limited to any particular packet format. The heartbeat packets may be UDP packets with a self-identifying type field in their payload header, and may contain optional additionally-formatted information including but not limited to a channel time-to-live value

Brief Description:

Figure 3 illustrates a group of mobile devices connected through primary and secondary communication channels 

Detailed Description:

Figure 3 illustrates the same network configuration as shown in Figure 2 with the addition of mobile device B 114 connected directly to the network 110 and connected to mobile device C 116 through a private network 306 connection. The private network 306 may be, for example, a Bluetooth PAN connection between mobile device B 114 and mobile device C 116. It can be seen from this example that switching from a primarychannel to a secondary channel may dramatically alter the network topology

Brief Description:

Figure 4 illustrates the resulting network topologies from Figure 3.

Detailed Description:

For example, as shown in Figure 4, if the primary channel A 402 for the mobile devices include communication link C 214 (resulting in direct connections between devicedevices A, B and C) and the secondary channels include the private network 306, then the network topology may change as illustrated in Figure 4 because the only way for device A and device C to communicate using the private network is through device B. While this is a simplified example with only three devices, a significantly larger number of devices may be used, resulting in a variety of different network topology configurations when switching between primary and secondary communication channels

Brief Description:

Figure 5 illustrates a network architecture in which a group of mobile devices and services, including a registration /directory service 502 and a push notification service 504 communicate over a network 110

Detailed Description:

As illustrated in Figure 5, in addition to the CDX service 104, matchmaker service 106 and invitation service 108 (some embodiments of which are described above), one embodiment of the invention can include a registration /directory service 520, a push notification service 522, and a relay service 516. As mentioned above, in one embodiment, the invitation service 108 and/or the matchmaker service 106 can use the registration /directory service 520 to identify registered mobile devices and the push notification service 522 to push data to the mobile devices. In one embodiment, when a mobile device is activated on the network, it registers a “push token” (sometimes referred to as a “notification service account identifier” in the Push Notification Application) with a database maintained by the registration /directory service 520 by associating the push token with a password protected user ID or a telephone number. If the push token is identified in the registration directory (e.g., by performing a query with the user ID), the push notification service 522 can use the push token to transmit push notifications to a mobile device. In one embodiment, the push notification service is the Apple push notification service (“APNS”) designed by the assignee of the present application and described, for example, in the Push Notification Application referenced above. 


Parts List

102

data service

104

CDX service

106

matchmaker service

108

invitation service

110

network

112

mobile device A

114

mobile device B

116

mobile device C

118

mobile device D

120

122

124

126

202

NAT device A

204

NAT device D

206

NAT device B

208

210

212

NAT device C

214

216

302

private network

304

communication link E

306

communication link F

402

primary channel A

404

primary channel B

502

registration /directory service

504

push notification service

506

relay service


Terms/Definitions

device

other children

same entity

first channel

remaining channels

mobile device B

various different prioritization schemes

subset

particular device configuration

User Datagram Protocol

primary and secondary communication channels

addition

direct connections

hand-shaking dialogues

expertise

primary channel A

skill

same data service provider

Transport Layer Security

servers and databases

users

match request

network topology

case

information

wireless hotspots

standard Internet Connectivity Establishment

P2P sessions

Secure Sockets Layer

links

other adults and children

High-Speed Uplink Packet Access

private network connection

network types or network topologies

NAT traversal data

channels

conditions

invention

secondary channels

CDX service

underlying principles

communication link A

two or more channels

network link C

software

primary communication channel

mobile device A

variety

communication link C

“SANs”

backup communication channels

Ethernet-based LAN

communication channels

secondary communication channels

databases store

vast number

devices

highest bandwidth channel

participation

public network

home Wi-Fi network

phone number

user application data

P2P application

service

connection data

order

switching

security

relay service

stateless nature

game

protocols

third channel

their payload header

various mobile devices 120

general network topology

cellular data networks

802.11n home

such a case

internet

NAT device

local network

requests

network link D

matching criteria

small queries

second channel

WiMAX networks

only three devices

local area Ethernet networks

UDP socket connections

communication link B

3 G communication links

device B

payload

larger data service

mobile device C

link management module

mobile device requests

optional additionally-formatted information

lists

networks

servers

Hypertext Transfer Protocol Secure

NATs

same Wi-Fi network

public Wi-Fi network

low-overhead

NAT device B

particular game

detail

NAT ports

external IP address

channel time-to-live value

NAT device D

connection data exchange

participants

particular multi-player game

mobile devices and services

example

data integrity

various game-specific variables

various types

two or more mobile devices

specified set

clients

private network

mobile device D

response

particular packet format

limitation

small “heartbeat” packet

Universal Mobile Telecommunications System

four different communication channels

edge

collaborative P2P sessions

Bluetooth PAN connection

techniques

two devices

local/private network

timing

“UMTS”

simplified example

user requests

collaborative P2P session

packet broadcasting

network architecture

data service

inherently secure network protocol

NAT device A

similar levels

registration /directory service

external services

3G network

different network topology configurations

NAT type data

heartbeat packets

communication link D

primary

method

network link B

highest bandwidth

lightweight network protocol

invitation request

context

match

local area network

channel

communication link F

specific examples

details

primary channel B

public networks

contrast

single network cloud

group

secure manner

network

socket connections

packets

open using heartbeat packets

UDP packets

different components

bandwidth

course

two mobile devices

efficient

Wi-Fi communication links

user

user ID

matchmaker service

network link A

device C

resulting network topologies

port

user account data

prioritization scheme

relatively lightweight network protocol

collaborative session

push notification service

lightweight

central exchange point

only way

public and private IP addresses/ports

significantly larger number

local Wi-Fi networks

variables

private networks

particular set

WiMAX network

match requests

user’s

ports

invitation service

packet reliability

participant

NAT device C

three remaining channels

level

data

gateway

device account data

self-identifying type field

same network configuration

adults

communication link E

connection

session keys

least expensive channel

matched participants

secondary channel