Patent Application
20070286100
The invention is described in connection with the embodiments illustrated in the following diagrams.
In the following description of various exemplary embodiments, reference is made to the accompanying drawings that form a part hereof, and in which is shown by way of illustration various embodiments in which the invention may be practiced. It is to be understood that other embodiments may be utilized, as structural and operational changes may be made without departing from the scope of the present invention.
Generally, the present invention relates to utilizing ad-hoc, peer-to-peer discovery mechanisms to enable direct communications between mobile devices on the same segment of a mobile data network in order to provide mobile services to those devices. These discovery mechanisms can free mobile devices from having to rely on centralized, infrastructure entities for such services as presence, news, and directory services. These discovery mechanisms can also enhance services currently available on the mobile networks. For example, out-of-band communications using the peer-to-peer protocols can be used for supplementing communications sessions that use established formats and protocols of the mobile communications network.
In reference now to
As used herein, the term “local network segment” may include one or more logical or physical partitions of a communications network. For example, in Global System for Mobile Communications (GSM) using General Packet Radio Service (GPRS), a network segment may be defined by a particular Serving GPRS Support Node (SGSN). The SGSN provides conversion between radio network protocols and the Internet Protocol (IP) on the GPRS network. In wireless networks that conform to one of the 802.11 wireless local area network (WLAN) standards, a local segment may be defined by a particular service set identifier (SSID) used by one or more Access Points (AP). In yet another example, IP networks may define network segment by networks and subnetwork, as defined in the IP standards and by locally applied subnet masks. Devices that are coupled to any of these example local network segments 110 may utilize a gateway 114 or similar entity in order to access other parts of the larger network 112.
Typically, servers 116, 118, 120 reside at a fixed location on the network, therefore in order to access server 116, 118, 120, the mobile devices 102, 104, 106, 108 would need to use the gateway entity 114. However, this could be problematic in some situations. For example, where the gateway 114 is inoperative, the services 116, 118, 120 will be inaccessible. In other situations, there may be significant costs associated with using the gateway 114, particularly when compared to accessing equivalent services on the local network segment 110.
For some applications, a small number of globally accessible servers 116, 118, 120 that are located at a well-known location or address may be preferable. However, for other applications, all the needed data may be accessible via local or nearby elements of the network segment 110 from which the application operates. For example, where mobile devices 102, 104, 106, 108 on the same segment wish to intercommunicate, it may be unnecessary and inefficient to have data related to those communications remotely located on other segments of the wide area network 112. Therefore, in one embodiment of the invention, the mobile devices 102, 104, 106, 108 include ad-hoc, peer-to-peer (P2P) networking software that allows such data to be created, discovered, and applied to end devices on the local network segment 110. Such data may be later transferred to an element of the wide area network 112 when and if appropriate.
The P2P network in
There are many different peer-to-peer (P2P) paradigms and protocols used on the Internet and other networks. One commonly known P2P framework is Universal Plug and Play™ (UPnP). UPnP defines an architecture for pervasive, peer-to-peer networking between all types of consumer electronics, including intelligent appliances, wireless devices, and PCs of all form factors. UPnP technologies provide a way for disparate processing devices to exchange data via proximity or ad hoc networks. The UPnP framework is designed to bring easy-to-use, flexible, standards-based connectivity to ad-hoc or unmanaged networks whether in the home, in a small business, public spaces, or attached to the Internet. UPnP technologies provide a distributed, open networking architecture that leverages TCP/IP and the Web technologies to enable seamless proximity networking in addition to control and data transfer among networked devices.
The UPnP Device Architecture (UDA) is designed to support zero-configuration, “invisible” networking, and automatic discovery for a breadth of device categories from a wide range of vendors. This means a device can dynamically join a network, obtain an IP address, convey its capabilities, and learn about the presence and capabilities of other devices. The UPnP specification includes standards for service discovery. Various contributors publish UPnP device and service descriptions, thus creating a way to easily connect devices and simplifying the implementation of networks. The publishing and discovery of services and devices in UPnP is accomplished using the Simple Service Discovery Protocol (SSDP).
SSDP uses multicast messages allow network clients to discover network services without relying on a server or other authoritative network element. Devices advertise available services on the network by multicasting SSDP discovery messages, both when initially joining the network, and periodically thereafter. Devices can use discover network services by listening to these SSDP announcements, as well as by using SSDP search messages to query for services. The use of SSDP in advertising and discovery allows components to spontaneously interact, and do so without relying heavily on static configurations or authoritative servers.
Service discovery protocols are used to enable zero-configuration, discovery and control of networked devices. For instance, UPnP and Service Location Protocol (SLP) are examples of these kinds of protocols. These service discovery protocols are mainly intended for local discovery over a limited number of networked machines, such as a single IP subnet, although some protocols may be adapted to enable larger networks to be used. Many aspects of service discovery will be described herein in terms of UPnP and related protocols. However, those skilled in the art will appreciate the invention may be equally applicable to other ad-hoc, peer-to-peer network technologies.
Mobile device infrastructures usually rely on fixed entities (e.g., servers) to provide various services. However, the concept of service discovery embodied in UPnP can be extended to mobile devices 102, 104, 106, 108 operating on a local network segment 110 to enable those devices to use and provide services (e.g., acting as mobile servers) that were formerly provided using fixed network entities. The mobile devices 102, 104, 106, 108 may be able to establish paths 122A-F without reference to an authoritative server. For example, a device 102 may broadcast or multicast a short announcement 124 that indicates a willingness to engage in interactions on the network segment 110. This announcement 124 may be similar to an ssdp:alive message, which informs other devices 104, 106, 108 of the embedded devices and services available from the advertising device 102. Alternatively, the message 124 may be a broadcast/multicast of minimal data (e.g., an IP address/port) which may then be used to establish direct connections with the device 102. In the latter case, one or more other peers 102, 104, 106, 108 may form a mesh-type network using these announcements 124, and any further discovery data is then sent between peers using these dedicated connections 122A-F.
In another scenario, an infrastructure device, such as the gateway 114, coupled to the network segment 110 may provide certain minimal information that allows a connecting device 102 to discover other peers and services on the network segment 110. For example, as represented by path 126, the gateway 114 may inform the device 102 of a multicast channel of the local segment 110 to use for P2P interactions, such as sending and receiving of SSDP messages. Alternatively, the gateway 114 may be able to inform the device 102 of IP addresses of active peers 104, 106, 108 currently connected to the segment 110, such that the device 102 can establish its own connection with those peers 104, 106, 108 for purposes of service announcement and discovery.
After discovery of a P2P network on the network segment 110, devices 102, 104, 106, 108 can exchange data for any purpose, such as providing network services. Example services that are useful for mobile communications context are presence and news services (e.g., RSS, Internet chat). For example, devices 102, 104, 106, 108 on the segment can send out announcements that include information about the presence and news services supported by the devices 102, 104, 106, 108. The presence descriptions typically include protocol information for accessing the specific service (e.g., presence service IP address/port and/or URI). The same device can host several instances of the presence service, each service accessible using a different Uniform Resource Identifier (URI). For example, the same device 102 can host chat rooms, buddy lists, group presence service, etc., and thus a different URI could be associated with each of those applications/services. The presence subscription and notification can be implemented as known in the art, which includes using standard protocols such as the Session Initiation Protocol (SIP).
SIP is a signalling protocol for multimedia real-time communication, such as audio, video and messaging. SIP is used in providing services such as Voice Over Internet Protocol (VoIP), Push To Talk (PTT) on mobile networks, etc. SIP is a standard for initiating, modifying, and terminating interactive user sessions. Typically, SIP sessions involves multimedia elements such as video, voice, instant messaging, push-to-talk voice communications, whiteboarding, online games, virtual reality, etc. SIP peers may require the services of a location server or similar database in order to locate an end-user device, even though some negotiations of a SIP session may occur between the peers themselves.
The SIP framework was designed to provide functions analogous to those call processing functions and features present in the public switched telephone network (PSTN). As such, SIP provides features similar to those familiar to telephone users, such as dialing numbers and handling of various status tones (e.g. ringing, busy, dial-tone, etc.). SIP may also allow communications devices to use more advanced call processing features such as call-waiting, call-forwarding, caller identification, etc.
SIP works in concert with several other protocols and is only involved in the signaling portion of a communication session. SIP is generally used for setting up and tearing down voice or video calls. The media of SIP-established calls are often communicated over different protocols, such as the Real time Transport Protocol (RTP). SIP messages often encapsulate data conforming to the Session Description Protocol (SDP), which is used to describe and negotiate the media content of the session. For example, SDP can be used to describe codecs, data rates, TCP/UDP ports, and other data descriptive of the media session.
SIP provides means for SIP user agents to discover other endpoints and to negotiate the characteristics of the session media. SIP presence enables the user agents to advertise their communication capabilities and services to the other user agents in advance of the actual communication session. In the context of
A user device that includes capabilities according to embodiments of the invention is shown as a mobile computing arrangement 200 in
The processing unit 202 controls the basic functions of the arrangement 200. Those functions associated may be included as instructions stored in a program storage/memory 204. In one embodiment of the invention, the program modules associated with the storage/memory 204 are stored in non-volatile electrically-erasable, programmable read-only memory (EEPROM), flash read-only memory (ROM), hard-drive, etc. so that the information is not lost upon power down of the mobile terminal. The relevant software for carrying out conventional mobile terminal operations and operations in accordance with the present invention may also be transmitted to the mobile computing arrangement 200 via data signals, such as being downloaded electronically via one or more networks, such as the Internet and an intermediate wireless network(s).
The mobile computing arrangement 200 includes hardware and software components coupled to the processing/control unit 202 for performing network data exchanges. The mobile computing arrangement 200 may include multiple network interfaces for maintaining any combination of wired or wireless data connections. In particular, the illustrated mobile computing arrangement 200 includes wireless data transmission circuitry for performing network data exchanges.
This wireless circuitry includes a digital signal processor (DSP) 206 employed to perform a variety of functions, including analog-to-digital (A/D) conversion, digital-to-analog (D/A) conversion, speech coding/decoding, encryption/decryption, error detection and correction, bit stream translation, filtering, etc. A transceiver 208, generally coupled to an antenna 210, transmits the outgoing radio signals 212 and receives the incoming radio signals 214 associated with the wireless device.
The incoming and outgoing radio signals 212, 214 to communicate with a network segment 216 of a mobile service provider. The network segment 216 may include any voice and data communications infrastructure known in the art, including CDMA, W-CDMA, GSM, EDGE, etc. The network segment 216 typically includes a fixed component such as a gateway 215 that allows devices on the network segment 216 to access traditional landline data infrastructures, including IP networks such as the Internet 217.
The processor 202 is also coupled to user-interface elements 218 associated with the mobile terminal 200. The user-interface 218 of the mobile terminal may include, for example, a display 220 such as a liquid crystal display. Other user-interface mechanisms may be included in the interface 220, such as keypads 221, speakers, microphones, voice commands, switches, touch pad/screen, graphical user interface using a pointing device, trackball, joystick, etc. These and other user-interface components are coupled to the processor 202 as is known in the art.
The program storage/memory 204 typically includes operating systems for carrying out functions and applications associated with functions on the mobile computing arrangement 200. The program storage 204 may include one or more of read-only memory (ROM), flash ROM, programmable and/or erasable ROM, random access memory (RAM), subscriber interface module (SIM), wireless interface module (WIM), smart card, hard drive, or other removable memory device. The storage/memory 204 of the mobile computing arrangement 200 may also include software modules for performing functions according to embodiments of the present invention.
In particular, the program storage/memory 204 may include a presence server 222. The presence server 222 will receive subscriptions 224 from other users via the local network segment 216. The presence server 222 maintains a database of presence information 226 (e.g. XML documents) and can be enabled to send out notification messages 227 when the presence data 224 is updated 228. Here the presence update 228 is applied via a user interface 229, although other non-user-initiated events may also be used to change the presence data 226, such as time, terminal location, etc. In infrastructure based presence services, a central server maintains the user presence information, status, etc. Presence updates are applied at the presence server, and other users can subscribe to the presence server for receiving notification when the presence information of the user changes. In contrast, the example presence server 222 is part of a fully distributed presence service, enabling peer devices to act as presence or news servers. Other users will subscribe to those services hosted on each device. As such, the presence server 222 need not include an external protocol for presence data management (e.g., via an infrastructure-based presence server) since the data 226 is managed locally by the user. The presence server 222 typically includes or has access to the underlying protocol for subscription and notification (e.g. SIP 231).
In other arrangements, the device 200 may include a SIP discovery module 230. The SIP discovery module 230 may use UPnP protocol mechanisms and the like to locate other SIP-UPnP enabled devices on the local network segment 216. For example, the module 230 may send NOTIFY-ssdp:alive messages 232, making the device 200 visible as a SIP directory with a locally accessible address and allowing a UPnP control point 234 to start up SIP actions. The device 200 may also include a separate P2P protocol stack 238 to handle particulars of P2P communications (e.g., UPnP, SLP). The P2P and SIP stacks 238, 231 interoperate to form a P2P-SIP discovery device that discovers, for example, UPnP enabled SIP devices, and can be enabled to provide directory services for these devices, as well as for SIP-only devices. On the UPnP side 238, the device 200 can be configured to answer M-SEARCH messages 236 looking for certain kind of SIP devices, and/or provide lists of UPnP capabilites. It is also possible that SIP-only devices register directly with the SIP stack 231 through SIP actions, and UPnP-enabled devices do the same using UPnP actions with the P2P stack 238. UPnP can be used to provide a SIP service and device discovery for SIP devices in local IP networks. The benefit is that the SIP devices do not need to access a remote IP network, which may cause the user to incur extra charges, as well as decreasing service quality.
The device 200 may also include any other service modules that interact with any of the P2P and SIP modules 238, 231, as represented by service module 240. The service module 240 could provide, for example, news services such as RSS feeds, messaging such as Internet messaging, location services, etc. The service module 240 could also provide services such as buddy lists, group presence, podcasting, etc. Generally, these services may also interact with the user interface 229 for purposes such as content creation, service configuration, etc.
In reference now to
In reference now to
The first terminal 400 determines the SIP communication address and SIP VoIP service description 408A of terminal 402 based on receipt of the message 408. The VoIP service description 408A may contain SIP service capabilities using mechanisms currently known in the art, including advertising via SDP, SIP presence and/or using the SIP OPTIONS method. The service description 408A may indicate, for example, that terminal 402 is capable of engaging in full-duplex audio media and supports the SIP INVITE method. A UPnP module 412 in terminal 400 controls a SIP User Agent (UA) 414 for purposes of initiating a SIP VoIP call directed to the IP address of terminal 402. The SIP UA 414 sends an INVITE 416 to a SIP UA 418 of terminal 402. The SIP INVITE 416 includes an SDP description 416A of the audio media. From this point on, a regular SIP call is established between terminals 400, 402.
Although the example in
Terminal 420 also includes a SIP UA 428 that can provide a SIP video sharing service. This SIP video sharing service can be advertised and rendered via a UPnP module 430. In a similar way, terminal 432 coupled to network segment 434 has a UPnP module 436 and control point 438. These UPnP components 436, 438 have discovered that a TV 440 that can provide a UPnP video rendering service. Terminal 432 also includes a SIP UA 442 that can provide SIP video sharing service. The terminals 420, 432 are also able to communicate through circuit-switched (CS) channels, such as via conventional cellular infrastructure (e.g., GSM, CDMA, etc.) and/or Public Switched Telephone Networks (PSTN). Therefore, the terminals 420, 432 may at some point initiate a CS call 442.
During the CS call 442, the user of terminal 420 may want to share a music video with the user of terminal 432. The video clip resides in user's PC 426. A user utilizes the terminal control point 424 to select the video clip from the PC 426 (e.g., using a UPnP Content Directory Service residing on the network) and starts the SIP video sharing service. The control point 424 in terminal 420 also controls the SIP UA 428 to send a SIP INVITE 444 to the SIP UA 442 in terminal 432. Once the user of terminal 432 accepts the SIP session, the control point 424 in terminal 420 controls the UPnP media renderer 430 in terminal 420 to send an RTSP PLAY signal to the UPnP media server in the PC 426. The PC 426 begins to stream the video clip to the UPnP video renderer 430 in terminal 420, as indicated by path 448
The UPnP video renderer 430 in terminal 420 further sends the video stream to the SIP UA 428 in terminal 420. The SIP UA 428 also sends the video stream towards the SIP UA 442 in terminal 432, as indicated by paths 452, 454. The user of terminal 432 receives the video stream to his mobile device 432. The user of terminal 432 may also want to see the video on a bigger screen, and thus selects the UPnP video render service from the TV 440. The control point module 438 in terminal 432 controls the UPnP media render in the TV 440 and sends RTSP PLAY to the UPnP media server 436 in terminal 432. The SIP UA 442 in terminal 432 sends the stream to UPnP media server 436, which sends the video to the TV 440, as indicated by path 456.
Further examples of providing services on mobile networks using P2P according to embodiments of the invention are shown in
The first terminal 502 includes a SIP UA and UPnP module that can advertise and provide services over a local network segment. The first terminal 502 in these examples is associated with device data 510. The device data 510 has a UPnP portion 510A that is used to form UPnP service descriptions. The device data also has a SIP portion 510B that is used to engage in SIP transactions.
When first joining the network, the terminal 502 may obtain an IP address and default route via DHCP or other auto configuration protocol. The proxy/registrar 506 may act as a DHCP server, or these services may be provided by some other entity. In the illustrated example, it may be possible that the terminal 502 is not initially aware of any SIP proxies or registrars when the terminal 502 joins the network. Therefore, when the terminal 502 connects to the local network segment, it advertises its capabilities using an SSDP alive message 512. The SSDP alive message 512 may be broadcast, multicast, or unicast to any number of elements on the local segment. In response, the proxy/local registrar 506 fetches 514 the device and service description from the terminal 502. The proxy/local registrar 506 also uses UPnP protocol (or other P2P protocol) to describe its capabilities to the terminal 502 by way of a capabilities message 516 (e.g., an SSDP alive message). In response, the terminal 502 registers 518 with the proxy 506 using SIP.
The proxy/local registrar 506 then registers 520, 522 with the global registrar 508 on behalf of the terminal 502. Once the terminal 502 is registered with the proxy/local registrar 506, the terminal's SIP access data is updated in the global registrar 508. Thereafter, when the second terminal 504 wishes to contact the first terminal 502, a query 524 to the global registrar 508 results in a redirect 526 message indicating the address of the proxy 506 servicing the terminal 502. The second terminal 504 directs the query 528 to the proxy/local registrar 506. Because the first terminal 502 may be a low power, UPnP device, it may incorporate low power features defined for UPnP devices. In particular, low power features allow devices to go to sleep modes, yet still be available to provide services when requested via the network. Thus, the proxy/local registrar 506 may optionally send a UPnP wake-up 530, to which the terminal 502 responds 532 after waking up.
As a result of the first terminal 502 indicating availability 532 is that the proxy/local registrar 506 sends a message 534 containing a publicly routable IP address usable for accessing the first terminal 502. The IP address may be a globally routable address assigned to the terminal 502 itself. More commonly, however, the IP address and port will be assigned by a network entity (e.g., firewall, gateway, proxy) that acts as a Network Address Translator (NAT). The public address will be mapped to a private address by the NAT, and any connections at that address/port will be sent to the first terminal 502. As a result, the second terminal 504 may begin SIP signaling 536, 538 as known in the art in order to initiate a media session.
In reference now to
In the previous examples, the proxy/local registrar 506 responded to the SSDP broadcasts of the terminal 502 by sending service description data to the terminal 502 (e.g., message 604 in
In reference now to
In reference now to
It will be appreciated that both mobile devices and fixed infrastructure devices (e.g., proxies, registrars, gateways, firewalls, etc.) may be configured to combine traditional mobile network services with P2P discovery and application protocols. A more detailed example of a network service element 1000 according to an embodiment of the invention is shown in the block diagram of
The computing arrangement 1001 may include one or more data storage devices, including hard and floppy disk drives 1012, CD-ROM drives 1014, and other hardware capable of reading and/or storing information such as DVD, etc. In one embodiment, software for carrying out the operations in accordance with the present invention may be stored and distributed on a CD-ROM 1016, diskette 1018 or other form of media capable of portably storing information. These storage media may be inserted into, and read by, devices such as the CD-ROM drive 1014, the disk drive 1012, etc. The software may also be transmitted to computing arrangement 1001 via data signals, such as being downloaded electronically via a network, such as the Internet. The computing arrangement 1001 may be coupled to a user input/output interface 1022 for user interaction. The user input/output interface 1022 may include apparatus such as a mouse, keyboard, microphone, touch pad, touch screen, voice-recognition system, monitor, LED display, LCD display, etc.
The computing arrangement 1001 may be coupled to other computing devices via networks. In particular, the computing arrangement includes a network interface 1024, capable of interacting with one or more network segments, as represented by respective local and remote network segments 1026, 1028 that are coupled via one or more gateway devices 1029. The network interface 1024 may include a combination of hardware and software components, including media access circuitry, drivers, programs, and protocol modules. Ultimately, the computing arrangement 1001 may be configured to provide services to mobile terminals 1030, 1032 coupled to the local network segment, as well as communicating with entities of the remote network segment 1028 (e.g., server 1039).
The computing arrangement 1001 includes processor executable instructions 1034 for carrying out tasks of the computing arrangement 1001. These instructions 1034 may include a peer-to-peer connection module 1036 capable of announcing, discovering, describing, and utilizing peer-to-peer protocols on the local and/or remote network segments 1026, 1028. The peer-to-peer connection module 1036 may be capable of sending and receiving SSDP and other service related messages in conformance with the UPnP discovery protocols. The peer-to-peer connection module 1036 may also be able to utilize other P2P protocols independent of or in combination with UPnP and/or SLP. Such P2P protocols may include distributed search protocols (e.g., Gnutella, Freenet), distribute download protocols (e.g., Bittorrent) and/or distributed processing protocols (e.g., Berkeley Open Infrastructure for Network Computing, Alchemi).
The instructions 1034 also include a network services modules 1038. The network services module 1038 provides one or more services made available at least to mobile devices 1030, 1032 on the local network segment 1026. The services module 1038 typically includes a stack of processing portions to manage different protocols used in the mobile services, including SIP, SDP, HTTP, RTSP, RTP, present management, location services, directory services, buddy list management, etc. The services provided by the network services module 1038 are traditionally provided, at least in part, by a fixed, remote server, such as server 1039 on the remote network 1028. However, the network services module 1038 in this example interacts with the P2P connection module 1036 and other devices 1030, 1032 of the local network segment 1026, thus allowing such services to be provided without reliance on the central server entity 1039. As such, the network services module 1038 may interact with a database 1040 to store data related to mobile network devices 1030, 1032, such as presence state, address bindings, P2P device states, etc.
In reference now to
The foregoing description of the exemplary embodiments of the invention has been presented for the purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise form disclosed. Many modifications and variations are possible in light of the above teaching. It is intended that the scope of the invention be limited not with this detailed description, but rather determined by the claims appended hereto.
