Classifications

• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L63/00—Network architectures or network communication protocols for network security
  • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
  • H04L63/029—Firewall traversal, e.g. tunnelling or, creating pinholes
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L63/00—Network architectures or network communication protocols for network security
  • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04M—TELEPHONIC COMMUNICATION
  • H04M9/00—Arrangements for interconnection not involving centralised switching
  • H04M9/08—Two-way loud-speaking telephone systems with means for conditioning the signal, e.g. for suppressing echoes for one or both directions of traffic
  • H04M9/082—Two-way loud-speaking telephone systems with means for conditioning the signal, e.g. for suppressing echoes for one or both directions of traffic using echo cancellers
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04W—WIRELESS COMMUNICATION NETWORKS
  • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
  • H04W12/06—Authentication
  • H04W12/062—Pre-authentication
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04W—WIRELESS COMMUNICATION NETWORKS
  • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
  • H04W12/06—Authentication
  • H04W12/069—Authentication using certificates or pre-shared keys

Definitions

• GSM Global Systems for Mobile
• WiFi Wireless Fidelity
• Next generation platforms may be designed to permit mobile users to move between cellular and WtFt networks and include an Unlicensed Mobile Access (UMA) standard thai may provide a switch controller for carriers to permit users to transcend between cellular and WiFi networks and vice-versa.
• UMA Unlicensed Mobile Access
• the UMA standard may have disadvantages including that carriers generally control calls and decide if and when to switch users between networks.
• An advanced mobile communication platform may be needed to provide enterprise level communication and control over users and the networks such that enterprises (instead of carriers) may select networks and/or control calls based on enterprise driven criteria rather than carrier driven criteria.
• echo cancellation (FX) technology has been widely used to improve quality of service (QoS) for end-users.
• FX echo cancellation
• LEC line or network echo canceller
• AEC acoustic echo canceller
• AEC is generally used to remove acoustic echoes caused by acoustic sound feedbacks from a speaker to a microphone on a hand- free speaker phone, mobile phone, or conference phone.
• LEC implementing an AEC may be more challenging due to some of the following factors: longer echo tail since the sound speed is much slower than the light (or election) speed, and accordingly the echo canceller is required to have more processing power and more memory; more dynamic change of the acoustic echo characteristics because of movement of the phone or talker and changes »1 the environment, and accordingly the echo canceller may he required to track and catch up changes in the echo characteristics more quickly; and multiple echo paths due to multiple reflections from different objects with different distances and/or orientations.
• Current acoustic echo cancellation technologies generally have Ii nutations. Acoustic echo cancellation technology may have been invented and used for at least 40 years so far.
• a typical AEC * utilizes an adaptive filter to model one or more echo path transfer functions and try to produce a replica of the echoes. The AEC may then subtract this replica from the near-end input signal to form a supposedly final echo- free far-end signal output [0008]
• Most of acoustic echo cancellation technology advancements so far are to employ different kinds of filters such as a FlR or HR filter, single band or multiple bands filter, or time-domain or frequency-domain filter.
• filters such as a FlR or HR filter, single band or multiple bands filter, or time-domain or frequency-domain filter.
• different algorithms such as LMS, RLS, APA, and so on have been used to improve filter efficiency.
• voice and or video media contents may need to be transferred from the transmitter to the receiver in real-time, while the underlying IP network was originally designed for non real-time date communications. Accordingly, providing and maintaining the quality of service (QoS) to the end-users may become a very challenging task.
• QoS quality of service
• the packet delay, the packet delay variation (packet jitter) and the packet loss from end-to-end may be considered three important QoS parameters which affect the quality and performance of the voice and video Communications over IP network.
• a jitter buffer scheme which may also be called de-jitter buffer scheme is usually employed on the receiver side to compensate or remove the network packet jitter. Basically, the scheme may not play out the packet as soon as the packet ts received Instead, the scheme may queue up the incoming packets and play out the queued packets at even intervals. In effect, the packet queuing may represent inserting a delay before the play-out happens. The inserted delay is usually called play-out delay. [0012 ⁇ There may he at least two issues on the current jitter buffer designs and implementations. The first issue may pertain to how much the play-out delay needs to be inserted. There may be a tradeoff on the amount of the play-out delay.
• a receiver may estimate the network packet jitter based on the timestamp of the RFP header of the incoming packets and the receiver local time. The receiver may then insert the minimal delay just enough to compensate the network packet jitter.
• the second issue on the jitter buffer design may pertain to when Io insert the play-out delay.
• the play-out delay can be inserted at. the beginning of each talk spurt.
• each talk spurt may be played out at even intervals, but. only the silence periods between talk spurts are expanded or compressed.
• the packets coming in the receiver may ideally have gaps between talk spurts such that a device may be implemented to identify the beginning of the each talk spurt based on the timestamp and the sequence number on the RTP headers of the incoming packets
• Hardware or software platform dependency may cause interoperability and/or configuration problems.
• a light weight protocol over a communication protocol such as, for example.
• Session Initiation Protocol (SlP ) that can efficiently transport information between a server and a client and can work independently of hardware and software platforms, a control plane protocol in use between the server and the client, and an underlying transport layer or the medium over which the server and the client communicate.
• a protocol that is fast enough to support critical real time control messages and is flexible enough for large-volume data transfer with minimal delay.
• prior -art protocols such as UMA are generally complex and difficult to establish interoperability.
• VoIP Voice over IP
• the applications may include one or more of Presence/Instant Messaging, Intranet web resources, CRJvI 5 Support database, etc. If the clients for one or more the above applications on the mobile phones access the enterprise resources directly, enterprise firewalls may need to be opened for multiple protocols, and opening the enterprise firewalls may cause security problems.
• the invention relates., in an embodiment, to a mobility architectural arrangement for managing telecommunication mobility for a handset.
• the arrangement includes a DiVitas protocol proxy (DPP), which is configured to manage connectivity between a mobility client of the handset and a mobility server within an enterprise.
• the DPP includes a client DPP being configured to manage the connectivity for the mobility client of the handset.
• the client DPP receives a plurality of client connectivity requests from a plurality' of application clients.
• the server DPP is configured to manage the connectivity for the mobility server.
• the server DPP receives a plurality of server connectivity requests from a plurality of application servers.
• the client DPP and the server DPP is configured to interact with one another to establish a secure channel.
• Fig. I depicts a system network according to one or more embodiments of the present invention.
• FIGs. 2A-C depict a mobility server according to one or more embodiments of the present invention.
• FIG. 3 depicts a mobile equipment client according one or more embodiments of the present invention.
• Fig. 4 depicts a block diagram of a codec based echo canceller in accordance with one or more embodiments of the present invention.
• Fig. 5 A depicts a voice jitter buffer scheme in accordance with one or more embodiments of the present invention
• Fig. SB depicts a video jitter buffer scheme in accordance with one or more embodiments of the present invention
• Fig. 6A depicts an overview of a DDP architecture in accordance with one or more embodiments of the present invention.
• Fig. 6B depicts a DDP message exchange in accordance with one or more embodiments of the present invention.
• Fig. 7A depicts a network architecture which includes two network interfaces per host and is fabricated in accordance with one or more embodiments of the present invention.
• Fig. 7B depicts a network architecture in accordance with one or more embodiments of the present invention.
• FIG. 7C depicts a network architecture in accordance with one or more embodiments of the present invention.
• FIG. 7D depicts a network architecture in accordance with one or more embodiments of the present invention.
• Fig. SA shows a block diagram of an example prior art communication device including a filter for echo cancellation.
• Fig. SB shows a flowchart of an example prior art method utilized, for example, in the example prior an communication device shown in Fig. 8A, for cancelling echoes.
• Fig. Q A shows, in accordance with one or more embodiments of the present invention, a block diagram of a communication device (or system or arrangement) that may cancel echoes without relying on a filter.
• Fig. 9B shows, in accordance with one or more embodiments of the present invention, a block diagram of an ID code generator employed in the communication devsee (or system or arrangement) shown in Fig. 9A.
• Fig. 9C shows, in accordance with one or more embodiments of the present invention, a flowchart of a method for cancelling echoes, for example, in the communication device (or system or arrangement) shown in Fig. 9A
• Fig. 1OA shows a block diagram of * a first example prior art packet voice communication system (first prior art arrangement) with an adaptive jitter buffer scheme
• Fig. 1 OB shows a flowchart of a transmitter -side process of a prior ail jitter buffer scheme utilized, for example, m the first prior art arrangement shown m the example of Fig. 1OA
• Fig. 1OC shows a flowchart of a prior art delay calculation process.
• Fig. 1OD shows a flowchart of a prior art packet play-out control process
• Fig. 1 OE shows a schematic representation of received packet flow ai a packet piay- oiit control when a transmitter-side voice activity detector (VAD) is turned on.
• Fig. 10F shows a schematic representation of received packet flow at the packet play- out control when the transmitter-side VAD is turned off.
• Fig I I ⁇ shows a biock diagtam of a r ecei ⁇ es -side device of a second puoi asi packet
• Fig 11 B shows a flowchart of a silence detection process utilized, for example, in the ieceu er-side ice shown HI the example of Fig I 1 ⁇
• Fig I IV shows a flowchau of a buffei o ⁇ eiflow control pioces-s utilised foi example, m the teceiv ei-side device shown in the example of Fig 1 1 A
• Fig 12A shows, in accordance with one oi moie embodiments of the present sin ention a block diagram of a receivet-side see of a packet ⁇ o ⁇ ce communication sv stem with adaptive jUtei handling
• Hg 12B shows, in accordance with one ei more embodiments of the present invention, a dela> insertion control ptoces ⁇ utiU ⁇ sed for adaptive jitter handling utilized, foi example, m the rece ⁇ vcr-tjidc ice shown in the example of F?g 12 ⁇
• Fig I > shows, in accordance with one or mote embodiments of the present im ention, a biock diagram of a recctvei -side device of a packet ⁇ idco communication sj stcm with adaptive j ⁇ ttei handling
• F ig 14 shows a p ⁇ oi art example of a call flow for establishing a connection between an application client and an application serv er
• FIG. 5 shows, in an embodiment of the .mention, a simple architectural diagram of the DDP in ⁇ cntjon
• Fig 16 A shows m an embodiment, an example of how data withm a archifectuml arrangement vuth DDP may ⁇ ow between an apphcatson client located withtn a client device and an application sen ei, which is managed by an enterprise
• FIG. 6B shows, in an embodiment, a code example of an encapsulated RlP notifv message
• [0056J Hg 1 7 shows, in au embodiment an example of a call flow- illustrating how a secure chaii ⁇ el mav be established ⁇ ei ⁇ er
• iegistration ma> occur
• Fig IS shov ⁇ in an embodiment a simple call flow dlusuatsog a situation in which a large file mav e to be sent
• Fig. 19 shows, in an embodiment of the invention, a simple call How illustrating a situation in which small control messages, such as those sent by control applications, may be sent.
• Fig. 20 is a prior art example of an architectural arrangement m which each application on a handset is connected individually to a corresponding application server within an enterprise.
• Fig. 21 is a prior art flow chart illustrating the method for enabling an application client to communicate with an application server in an !P Security VPN environment.
• Fig. 22 shows, in an embodiment of the invention, a simple block diagram of a mobility architectural arrangement.
• Fig. 23 shows, in an embodiment of the invention, a biock diagram illustrating the mobility architectural arrangement as a rich client.
• Fig. 24 shows, in an embodiment of the invention, a simple flow chart illustrating an example of a method for employing a mobility architectural arrangement.
• Fig. 25 shows, in an embodiment, of the invention, a mobility architectural arrangement implemented as a thin client.
• DDP D Divitas Description Protocol
• the invention might also cover an article of manufacture that includes a computer readable medium on which computer-readable instructions for carrying out embodiments of the inventive technique are stored.
• the computer readable medium may include, for example, semiconductor, magnetic, opto-magnetic, optical, or other forms of computer readable medium for storing computer readable code.
• the invention may also cover apparatuses for practicing embodiments of the invention
• apparatus may include circuits, dedicated and/or programmable, to cany out operations pertaining to embodiments of the invention
• Examples of such apparatus include a general purpose computer and/or a dedicated computing device when appropriately programmed and may include a combination of a computer/computing device and dedicated/programmable circuits adapted for the various operations pertaining to embodiments of the invention.
• Fig. 1 depicts a system network 100 according to an embodiment of the invention.
• Mobile equipment (ME) 102 is provided that communicates with the network in a number of possible ways.
• ME 102 can communicate with a cellular network 110 that includes a Base Transceiver Station (BTS) 1 12, a BTS Switching Center (BSC) 114 and Mobile Switching Center (MSC) 1 16.
• BTS Base Transceiver Station
• BSC BTS Switching Center
• MSC Mobile Switching Center
• the MSC is coupled to a Media Gateway 120 that is coupled to a public switched telephone network (PSTN) 122.
• PSTN public switched telephone network
• PSTN public switched telephone network
• Other conventional public and private telephones 124 are also coupled to the PSTN.
• a PBX 130 is coupled to the PSTM and serves an enterprise for purposes of making and receiving calls, for example, via telephone 136.
• Mobility server 150 is coupled to the PBX as well as other networks
• mobility server ' ! 50 is coupled via router 132 to an. Internet Protocol Wide Area. Network (WAN) ⁇ 38.
• the mobility server 150 is also coupled via router 140 and firewall 142 to the Internet 144.
• the mobility server is also coupled to a local area network (LAN) with wireless access point 160.
• LAN local area network
• One access point is depicted while the invention anticipates multiple access points as well.
• the access point I 60 permits a user with ME 102 to wander in the enterprise and stay connected to the PSTN through the mobility server 150 and FBX 130. ⁇ f the user wanders beyond the boundary of the LAN. the user will be connected to an alternate network (e.g. the cellular network) as described below in detail.
• an access point 180 that is coupled to the internet for access under certain conditions as described herein.
• Figs. 2A-C depict a mobility server according to an embodiment of the invention.
• Security 1 Manager The definition of security 1 when two or more entities axe communicating involves the following aspects;
• DiVitas mobility solution there are three distinct communicating entities: DiVitas Client, DiVi (as Server and external VoIP GW. And there are two distinct types of paths between these entities- SlP signaling path and Media path
• DMM User/Device Manager/Mobility Controller
• the device and mobility Manager (hereby referred to as DMM) is a module that handles device configuration and status as well as the mobility aspects while there is an active cal! on a device.
• the following sections capture the functional and design specifications of the DiVIM along with the public interfaces that the DMM supports [0075J
• DMM User/Device Manager/Mobility Controller
• Control Plane/Call Control - Call control is the primary control plane module responsible for the following functions:
• Call control, module resides oti the DN media switch.
• the call control module interfaces with the SlP stack and Asterisk (or any other) PBX module to provide the above mentioned functionality.
• SIP stock for UA, CCM, and Asterisk etc: SIP stack is mainly used as protocol message decode/encode engine SlP stack also performs basic protocol specific tasks, like standards based message parsing and validation, retransmissions, proprietary message validation etc. For most of the proxy and B2BUA tasks, SIP stack relies on CC for decision-making. Interactions between CC and Asterisk as well as CX? and CCM are through standards based SlP messages.
• Proxy Agent/Configuration Manager acts as a configuration manager for all the applications. Call control related information is downloaded by PA at the time of provisioning or after the disk DB is read following a system bring up. CC stores the data in RAM for local/faster access, CC also updates PA of any dynamic information ⁇ e.g. call going active or down), or on demand information (e.g. SNMP GET)
• Resource Manager provides logical map of the physical/network resources. These resources include GE port, DSP resources, sockets, CDP TCP ports etc and mav iiof include system resources l ⁇ kc memorv, butter pool timers, queues etc The iesourccs max not include sockets used for interna! IPC communication CC uses.
• MSA Media Su itch Application
• the ⁇ »S 4 software needs to support encoding /decoding of different speech codecs ⁇ he type of algorithm and channel can change during run time i e , a design to support multi-channel multi- algo ⁇ thm is needed Each codec algo ⁇ thm needs to be reentrant, and the program as well as data needs to be fully ielcasabic In order to support various codecs the following needs to taken into account a Since the DSP has limited on chip data mernotx not all data can be placed on-chip all the time in multi-channel, multi-algo ⁇ thm application This requites all data (context and tables) »i each algo ⁇ thm to be le-locatable (between on olTcliip mcmoiv) durmg context switching This lequires a need to Hud out the memoiv stack size as well as XT(PS requuement for each supported codec b ⁇ mechanism to exchange messaging between host and DSP ptocess
• the DSP processor allows the external host to access the USP external
• the DSP has 16Kb ⁇ tes of first le ⁇ el program as wel 1 as data memory I he program as well as data memory share the second level memory of 2 ⁇ 6kbvtes
• the 16Mb ⁇ tes of externa! memory (SDRAM) is available
• SDRAM 16Mb ⁇ tes of externa! memory
• the DSP At boot up once the software is downloaded to DSP (the DSP will indicate the same by writing a predetermined value at a fixed memory location to indicate to host that the software is downloaded). b Upon successful download of software, the DSP vuli run an interna! tinier of l ⁇ msec At this time the DSP is polling for channel state to change to process, which is set by the host once the packet arrives. c. A start call or open channel command from the host indicating codec type, data-read> ss well as call type (initially only voice) is sent for RX as well as TX direction d Based on channel opened the DSP picks up the RTP data from the external buffers and performs the DSP related functionality on those e. On the TX side the DSP places encoded data on the external buffers to be picked up by the TX agent.
• Fig 3 depicts a mobile equipment client according to an embodiment of the invention
• the client software or handset software runs on the handsets that are compatible with the Divttas Server Typically these are dual-mode handsets that have the capability to piovide telephony connection on the cellular network (CDMA or GSM) as well as IP connection on the LAN network (wired LAN or wireless LAN)
• the software can be also be compiled for a desktops/laptops or a PDAs which have a microphone and a speaker to function as a softphonc [0084] L ' ser Interface [0085J
• the client user- interface provides the following functionality
• Disable/inhibit client softwaie ISP application is used to make/receive ceHulat calls Cail-contTol and
• ⁇ oice Engine fos mailing ⁇ oiP calls on LiVN inteiface includes codecs echo-cancellation, jitter control, etioi concealment
• the software may need to be designed in such a way that most of the code is shared across handsets Therefore, the code has to be divided into platform dependent part and platform independent part.
• Most, m fact all of the Divitas cote value should be m platform independent part of the software, which should be easily portable from one platform to another
• the platform dependent part should be only the functional adaptation layers (particularly Telephony, LAN, S02 1 1, Audio and Display adaptation layers). Whenever the code is ported to a new platform, only these adaptation layers need to be modified or rewritten, while providing a uniform APT to the platform independent part.
• the client software wtll run on multiple handset platforms.
• the most prevalent handset platforms are Windows CP., Syrnbian and Linux.
• the client application is designed to work on 802 1 1 phones, PDAs or laptops/desktops which do not have a cellular telephony interface. On these platforms, a subset of features is available to the user. Basically, the call handoff from VoIP to cellular will not be possible. [009 Ij Theory of Operations [0092] Startup and Security Operations
• the client application looks for the available resources on the handset.
• the client application first checks for presence of wired network. If not present, then the client application checks for the presence of an 802.11 network.
• the wired or wireless medium authentication is done depending on the enterprise security policy.
• the handset client shall support the security mechanism employed in the enterprise. The most common security mechanism is VVPA (WiFi Protected Access) Once the authentication is done successfully, the wireless client gets the IP address for the IP interface using DHCP
• the application gets the Divitas server URL and DNS TP addresses from persistent database and tries to register with a Divitas server [0095]
• the client application could be running on a handset; which is inside the enterprise network
• the client can reach the Divitas server without any other security blankets.
• the client In case the client is in a public network, say a coffee shop or an airport with WiFi Internet access, typically the user sets up a VPN connection to the enterprise. The client can reach the Divitas server only after the
• VPN tunnel is setup.
• the client application software authenticates the handset with the server by sending an encrypted certificate ⁇ installed by Enterprise IT) to the server.
• the client gets the login/password from the user or stored in the handset, encrypts the iogtn/password and sends the encrypted login/password to the server for user authentication.
• the server replies by sending the enterprise phone number.
• the client sends the cellular phone number to the server.
• the server binds the two for all future handoff scenarios.
• the signaling and media stream are secured using SIP/TLS for signaling and SRTP for media stream.
• SIP/TLS for signaling and SRTP for media stream.
• client need not add another level of encryption.
• Sf P is used for signaling and RTP/RTCP for media stream.
• the user can choose to be INVISIBLE or AVAILABLE at startup by configuring on the
• GUI GUI and saving that configuration in the persistent database.
• the client updates the user's presence information to the server.
• the user can also enter frequently called buddies within the enterprise and save that configuration in the persistent database on the handset.
• the client gets the presence information (in bulk) of these buddies whether they are INVISIBLE, AVAILABLE or CALL-IN-PROGRESS
• the server updates the presence information of these buddies to the clients as and when the event occurs.
• the client sends the network status to the server periodically. If the client is on an 802.1 1 wireless network, the client sends the SSID, signal-strength and bandwidth of the associated access point (AP) to the server. If there is a call in progress, Ui e client sends the SSlD as part of in- band
• the client sends out-of-band keepalive messages.
• the pieferred mode of making and receiving calls to the client is on the network interface. However, the user can choose to ovemde the pieferred mode and make the outgoing calls on the cellular network This selection is not communicated to the server and may not affect the incoming calls This selection is also not stored in persistent database. The user has to explicitly make the selection every time the user makes an outgoing call.
• a user has access to all the enterprise features as long as the client has a session established to the server.
• the client GUI is used to pro ⁇ ide access to these enterprise features to the user.
• Sl P stgnal mg is used to establ ish voice calls between the client and the sei v er Voice from the audio receiver is encoded into one of the codecs supported by GlPS Voice Engine (VE), encapsulated into RTP packets, encrypted if needed, and sent on the IP interface to the serser
• VE GlPS Voice Engine
• RTP packets tccened from server is decrypted if needed, decoded using one of the codecs and played out Speech decoding, jitter control and error concealment are done by GIPS VE on the receive side.
• [001 1 1 ] ⁇ handset client is a mobile device, unlike the portable laptops.
• Intra- WLAN handoff When a user is in an 802.1 I network having a phone conversation and walks across the building, an AP handoff could occur viz. the handset of the user is now associated with a different AP than the one the handset was previously associated with The AP handoff could occur without IP address change if the handoff is within the same subnet or to another subnet, in which case the IP address of the handset changes. If the IP address changes, then the client needs to register with the server again. The established calls continue to flow in the meantime using the ok! flow information until the Voice-Engine (VE) is communicated of the new IP address. Voice-engine ensures that the RTP streams going out of the client will have the new IP address.
• VE Voice-Engine
• the wireless client As a wireless client roams from one wireless AP to another, the wireless client must perform a full 802. IX authentication with each wireless AP. WPA allows the wireless client and the wireless AP to cache the results of a full 802. 1 X authentication so that if a client roams back to a wireless AP with which the wireless client has previously authenticated, the wireless client needs to perform only the 4- way handshake and determine new pairwise transient keys
• the wireless client includes a PMK identifier that was determined during the initial authentication and stored with both the wireless client and wireless AP's PMK cache entries. PMK cache entries are stored for a finite amount of time, as configured on the wireless client and the wireless AP.
• the WPA/WPS IE Update calculates the PMK identifier so that the PMR as determined by the 802. IX authentication with the switch can be reused when roaming between wireless APs that are attached to the same switch. This practice is known as opportunistic PMK caching.
• Preauthentication [00! 1.9] With preauthentication, a WPA wireless client can optionally perform 802, IX authentications with other wireless APs within its range, while connected to its current wireless AP.
• the wireless client sends preauthenti cation traffic to the additional wireless AP over its existing wireless connection.
• a wireless client that connects to a wireless AP with which the wireless client has preauthenticated needs to perform only the 4-way handshake.
• the decision to handoff the call is made by the client.
• the decision is based on 802.1 1 signal -strength, channel loading arid voice-quality thresholds. Once the decision is made, the decision is communicated to the server, which initiates a call to the client on the cellular network.
• the client checks the caller-id of the incoming call, compares to the 802.11 caller-id, and if there is a match, accepts the cellular call and drops the 802, 1 1 call leg. Qn the server side, the server drops the
• 802.1 1 call leg to the client patches the cellular call leg to the other talking party.
• the decision to handoff the call is made by the client.
• the decision is based on availability of sufficient 802,1 1 signal-strength, channel loading and voice quality.
• the decision is communicated to the server, which initiates a call to the client on the 802.1 1 network.
• the client checks the caller-id of the incoming call, compares to the cellular ca ⁇ ier-id, and if there is a match, accepts the 802.1 1 call and drops the cellular call leg.
• the server drops the cellular call leg to the client, patches the 802.1 1 call leg to the other talking party.
• the handset Before going to sleep the handset tells the AP that the handset wishes to go to sleep by setting the power save bit in the 802.1 1 header of every frame.
• the AP receives the frame, and notices the client ' s wish to enter power save mode.
• the AP begins buffering the packets for the client while the client's 802.1 S. miniport is asleep.
• the miniport consumes very little power while asleep.
• the mimport wakes up periodically to receive regular beacon transmissions coming from the access point.
• the power-saving clients need to wake up at the right time when the beacons are transmitted to receive the beacons.
• TSF Transiming Synchronization Function
• TSF timer keeps running when stations are sleeping.
• the 802. i i miniport When there are no incoming beacons for an extended period of time, the 802. i i miniport is put to sleep. The miniport periodically wakes up, probes the air for APs, if there are none present, miniport goes back to sleep, In this case, the miniport sleeps for longer duration than previous case. [00130] B. Codec Based Acoustic Echo Cancellation
• the apparatus may include an identification code (ID code) generator configured to generate an TD code.
• the apparatus may also include an ID code injector configured to inject the ID code into at least one of the signal and a processed signal to produce a convolved signal.
• the processed signal may be resulted from a processing of the signal.
• the apparatus may further include an ID code detector configured to detect at least one of the convolved signals, a transformed signal, and a transformation of the convolved signal, the transformed signal resulting from the transformation of the convolved signal.
• the apparatus may further include an arithmetic function configured to remove at least one of the convolved signal and the transformed signal.
• Fig. 4 depicts a method for codec based acoustic echo canceller in accordance with one or more embodiments of the present invention.
• One embodiment of the present invention is a method for canceling echo during a communication between a first node and a second node. The method includes injecting a secret code to a signal input of the first node.
• the first node is a network device used by a far-end user
• the second node is a network device used by a near-end user
• the first node is a network device used by a near-end user
• the second node is a network device used by a far-end user
• a secret code is injected into the far-end signal input So a single or multiple echoes of the far-end signal will carry on this secret code and arrive at the near-end signal input.
• the near-end signal also includes the near- end speaker voice. Since the secret code is carried only on the echoes of the far-end signal but not on the near-end talker's voice, the secrete code may serve as the identities of those echoes, and help us to differentiate them from the near-end speaker voice.
• Some kinds of the matching filters can be employed like the correlation or other means to identify the echoes of the far-end signal from the near-end speaker voice by the secret code and to remove them.
• a final echo-free signal will be generated on the far-end signal output.
• the secret code can be transformed into a pseudo random noise called "secret code random noise”. Subsequently, the existing background noise is removed from the fax-end signal input, and the secret code random noise is inserted into the far-end signal input. As Soog as the new SNR is kept above certain threshold, the near-end listener should not heat- any difference, In accordance with one or more embodiments of the present invention, the injector shown in Fig. 4 scrambles the secret code to a pseudo random noise, removes the existing background noise in the far-end signal input, and then inserts the secret code random noise. [00!
• the fat-end signal defectoi will detect the far-end signal presence and trigger the secret code generator since the echoes will be present only when the tar-end talker is speaking.
• the secret code ptlot can include the secret code timing and the phase
• the secret code pilot detecioi is used to detect the secret code pilot carried on the echoes of the far-end signal and to adjust the secret code delay to the matching filter because of the variable echo paths. The unscrambling process will be needed in the secret code pilot detector
• the secret code and the secret code pilot may be designed so that the secret code detector and the matching filter can easily identify the echoes of the far-end signal, which carry this secret code and its pilot and then remove these echoes ⁇ n addition, a non-linear processor may be used after the matching filter to further reduce the residue echo and improve AEC performance.
• Echoes have been a significant problem m communication.
• a filter or echo canceller
• a filter or echo canceller
• Fig, 8 A shows a block diagram of an example prior-art communication device 800 (prior- art device 800) including a filter 814 (or echo canceller 814) for echo cancellation,
• prior-art device 800 may include a signal receiver 802 for receiving far-end signals (e.g , signal y") from a remote (or far-end) party and a signal transmitter 818 for sending signals (c.g , signal z) to the remote party
• far-end signals e.g , signal y
• signal transmitter 818 for sending signals (c.g , signal z) to the remote party
• Prior-art device 800 may also include a speaker 806 for playing out the received signals to a user of prior-art device 800 (i e , a local or near-end party) and a microphone 810 for collecting near-end signals ⁇ e g , signal ⁇ , which may include voice of the local party and background noises)
• Prior-art dev see 800 may also include buffer Sl 2 for buffering signals received from signal receiver 802 and filter 814 for modeling an echo path 808 between speaker 806 and microphone 810 and for processing signals buffered m buffer 812 Echo path 808 may represent multiple paths of delay, attenuation, reverberations, etc., transforming signal y" into signal y 1 , for example
• Prior-art device 800 may further include summation function 816 for subtracting outputs of filter i 14 from outputs of microphone 810.
• Prior-art device 800 may further include a signal feedback path for feeding outputs of the summation function 8i ⁇ back to filter 814,
• a signal (e.g., signal y s ) received by signal receiver 802 may be forwarded to both speaker 806 and buffer 812.
• Filter 814 may receive the signal from buffer 812, process the signal with a model of echo path 808 to generate a cancelling signal (e.g., x2, a function of y ' ) 5 and send the cancelling signal to a summation function 816.
• summation function 816 may subtract the cancelling signal (e.g., x2 ::: f(y ?
• the output of summation function 816 may be fed back to the fi lter 814 for updating and improving the echo path mode! in filter 814,
• Fig, 8B shows a flowchart of an example prior art method utilized, for example, in prior- art device 800 (shown in Fig. SA), for cancelling echoes, As shown in the example of Fig. 8B, the method starts with step 85O 5 at which signal receiver 802 (shown in Fig. 8A) may send a signal y ⁇ Then, control may be transferred to step 852 and 854,
• speaker 806 may receive signal y'
• microphone 810 may receive a signal yl plus near-end signal x.
• Signal yl may represent a transformed signal of signal y " because of delay, attenuation, reverberations, etc. The delay, attenuation, reverberations, etc. may be caused by echo path 808 between speaker 806 and microphone 808 (shown in Fig. 8A)
• Signal x may include the local party's voice plus local surrounding background noises picked up by microphone 810.
• Signal xl that represents a combination of signal y 1 and signal x may then be sent to summation function 816 (shown in Fig. 8A).
• buffer 812 may also receive signal y ⁇
• filter 814 may process signal y * with a model of echo path 808 to produce signal x2, a function of y ⁇ e.g , f(y " ), which is then sent to summation function 816 (shown in Fig. 8A).
• summation function SI 6 may subtract signal x.2 from signal xi to produce a signal z Ideally, if f(y') equals to yi , then z will equal to x, the near-end signal that is of interest to the remote patty with echo (represented by yi ) removed.
• the model of echo path 808 implemented in filter 814 may not be accurate, and typically z may not be equal to x.
• summation function 816 may send signal z to signal transmitter Sl 8 for z to be transmitted the remote party.
• summation function 816 may feed signal z back to filter 814, for updating and improving the echo path model utilized at the step 858,
• the feedback of signal z and associated calculations and updates may cause filter 814 to require additional processing time or processing power.
• the quality of signal z (i.e., the error of signal z with respect to signal x) may depend on algorithms and echo path modeling implemented in filter 814 as well as the processing power and memory of the computing device implementing filter 814.
• prior art devices, arrangements, and methods as illustrated by prior-art device 800 of Fig. 8 A and the method of Fig. 8B, correct modeling of echo path SOS, as performed by filter 814, may be crucial for effectively cancelling echoes.
• echo path 808 may be dynamic and therefore may be difficult to model correctly.
• the prior art devices, arrangements, and methods may not be able to effectively cancel the echoes.
• the prior art devices, arrangements, and methods may face further challenges in double- talk scenarios, in which the local ⁇ or near-end) party and the remote ⁇ or far-end) party are talking at the same time. Since the local party ' s voice and the remote party's voice may have similar human voice characteristics, filter 814 may be unable to correctly identify which signals to be input into the model of echo path 808 As a result part, of the local party's voice may be cancelled, and part of echoes may not be cancelled, and the error of the echo path model in filter 854 may become divergent instead of converging, resulting in undesirable quality of communication.
• filter 1 14 may require a large amount of data memory and may require a CPU(s) with high processing power As a result, a high cost for implementing echo cancellation may be incurred.
• one or more embodiments of the present invention involve art apparatus for canceling a signal even if a filter is not provided.
• the signal may represent a digital signal.
• the apparatus may include an identification code ( ⁇ D cade) generator configured to generate an ID code.
• the apparatus may also include an ID code injector configured to inject the ID code into at least one of the signal and a processed signal to produce a convolved signal.
• the processed signal may be resulted from a processing, such as background noise removal of the signal.
• the apparatus may further include an ID code detector configured to detect at least one of the convolved signal, a transformed signal, and a transformation of the convolved signal, wherein the transformed signal may be resulted from the transformation of the convohed signal.
• the transformation of the convolved signal may he caused by the configuration and/or environment of the apparatus.
• the transformation of the convolved signal may represent the delay caused by one or more echo paths between the speaker and the microphone of the apparatus; the transformed signal may represent a delayed signal given the existence of the delay.
• the apparatus may further include an arithmetic function configured to remove at least one of the convolved signal and the transformed signal.
• Fig, 9 A shows, in accordance with one or more embodiments of the present invention, a block diagram of a communication device SK)O (device 900) that may cancel echoes even if a filter is not provided.
• the block diagram may also represent a communication system or arrangement with the components shown in Fig. 9A implemented in one or more devices.
• 6S j Device 900 may include input/output components such as a signal receiver 904 (for receiving a far-end signals from a remote party), a signal transmitter 932 (for sending signals to the remote party), a speaker 914, and a microphone 916 (local microphone 916) An echo path 90S that travels from speaker 914 to microphone 916 may exist
• Device 900 may also include a signal-processing module such as a background-noise remover 906
• Background-noise remover 906 may be configured to remove background noise from signals received from signal receiver 904, Background-noise remover 906 may be implemented utilizing one or more well-known algorithms such as spectral subtraction for removing the background noise,
• De ⁇ ice 900 mav also include modules for canceling echoes
• the modules ma) include identification code generatos 922 (ID code generate! 922), identification code injector 910 (ID code injector 9S0) identification code detector 924 (ID code detectot 924) and buffci 926
• the modules mav also include a tta ⁇ sfoiraation module such as, tbi example, deia> 928 for transfoiming signals such as, for example mtiod ⁇ cmg a deiay
• the modules mav also include an aiuhmetic function such as, ⁇ n example summation function 930
• the ID code mav iepiesent a pseudoiando ⁇ i code that ma ⁇ simulate a backgiou ⁇ d noise ot conifoit noise ID code geneiator 922 mav include a linear feedback shift tegtster fot genetating a pseudotandom nojse sequence to be utilized as the ID code
• the ID code mav include a high frequency & low-fiequency signal that is unpercervable to human eats
• the sampling tate of mieiophone 916 ma> be configuied to process the high frequency or low-fiequency signal for example, through configuring hardware and oi softwaie ⁇ ot dmer) of microphone ⁇ Ib
• device 900 not include remoter 906
• ID code iiijcctoi 910 ma ⁇ be configuied to inject the 11) code generated b ⁇ ID code genet ator 422 into a signal
• ID code injector 910 ma ⁇ be implemented by some well-known algorithms such as digital correlation fot mseitmg the ID code into the signal, for example, by com oh nig the ID code with the signal to produce a con ⁇ olved signal
• ID code detector 924 mav be configuied to detect the ID code w ithm the com signal for example, m a mixed superimposed and/or futther convoked signal iinolvmg one or more other signals
• ID code detector V24 ma> be configured to detect a transfotmed signal tesulted from a transfosmation of the convohed signal and/or the ID code, the tianstoi matron ma ⁇ be caused for example, the configutation and-'or emironnicrst of device 900 Additionallv oi additional h ID eode detectoi 924 raav be configui ⁇ i to detect the transformation
• the nansfoimation ma> include a delay aisd a .signal level attenuation ID code delecloi ⁇ 24 mav implement one or more well kii ⁇ wn algorithm such as digital correlation or match filter for detecting the ID.
• Delay 928 may be configured to introduce a delay itito a signal.
• the delay may be employed in simulating the transformation
• Delay 928 may be implemented by a simple delay line shift register for introducing the delay
• Each of noise remover 906, ID code generator 922, ID code injector 910, ID code detector 924, and delay 928 may be included in software that may be downloaded to a user device such as, for example, a telephone, a mobile phone, a teleconference device, etc, (e.g., for acoustic echo cancellation) and/or a server device (e.g ., for line or network echo cancellation).
• a user device such as, for example, a telephone, a mobile phone, a teleconference device, etc, (e.g., for acoustic echo cancellation) and/or a server device (e.g ., for line or network echo cancellation).
• Fig. 9B shows, in accordance with one or more embodiments of the present invention, a block diagram of 3D code generator 922 employed in device 900 (shown in Fig. 9A)
• ID code generator 922 may only include a code generator 921 which will generate a random code directly.
• the code generator 921 may be implemented by some well-known algorithms, such as linear feedback shift register with carefully selecting an appropriate feedback function.
• ID code generator 922 may include a code generator 921 followed by a randomizer 923.
• the code generator 921 can generate an appropriate identification code first without worrying about the randomization. Then this identification code is fed to the randomizer 923 to become a pseudorandom noise sequence as the output of 922.
• the randomizer 923 could be implemented by a modified liner feedback shift register with its feedback function controlled by the code generator 921.
• Fig. 9C shows, in accordance with one or more embodiments of the present invention, a flowchart of a method for cancelling echoes, for example, in device 900 (shown in Fig. 9A).
• the method starts with step 952, at which the signal receiver 904 (shown in Fig, 9A) may receive a signal y'(n) from the remote party.
• noise remover 906 may remove background noise from y'(n), resulting in a signal y(n).
• the background noise may be removed m order to make room for an ID code that includes a random noise. Accordingly, the local party may not receive excessive noise,
• ID code generator 922 may generate an ID code c(.n)
• the ID code e(n) may represent a known and controllable function.
• ID code injector 9! 0 may injects the ID code c(n) into signal y(n)
• a convolution of c ⁇ .n) and y(n) may be generated.
• the convolution of c(n) and y(n) may be a convolved signal c(n)*y(n).
• control may be transferred to step 962 and step 980.
• speaker 914 may receive the convolved signal c(n)*y(n)
• microphone 916 may receive a delayed signal from speaker 914, i.e., signal c(n-d)*y(n-d).
• Microphone 916 may also pick up another input signal x(n), which may include voice of a local party (e.g., in a double-talk scenario) and/or background noise surrounding microphone 916.
• Microphone 916 may then output a combined signal x(n) + c ⁇ n-d)*y(n-d) to ID code detector 924 (shown in Fig. 9A) and summation function 930 (shown in Fig. 9A) .
• buffer 926 may buffer a copy of convolved signal c(n)*y(n) and output the copy of the convolved signal to delay 928.
• ID code detector 924 may detect the ID code c(n-d) in the combined signal x(n) t c(n-d)*y(n-d) and may determine a delay amount d by comparing c(n-d) with c(n) received from ⁇ D code generator 922 given that c(n) is a known and controllable function. The delay amount d may be fed into delay 928 (shown in Fig. 9A).
• delay 928 may introduce the delay amount d into the output of buffer 926 from step 980, i.e., a copy of c(n)*y(n), resulting in a copy of c(n-d)*y(n-d).
• sum mation function 930 may subtract the output of step 982, i.e., the copy of signal c(n-d)*y(n-d), from the output of step 964, i.e., signal x(n) + c(n-d)*y(n- d).
• summation function 930 calculates signal x(n) -f c(n-d)*y(n-d) - c(rs- d)*y ⁇ n-d) to obtain signal x(n), which may represent the input signal picked up by receiver microphone 916 (shown in Fig.
• Signal x ⁇ n may include voice of a local party, e.g., in a double-talk scenario, and/or background noise surrounding microphone 916
• signal ⁇ (n) including voice of a local party, e.g., in a double-talk scenario, and/or background noise surrounding microphone 916 and containing no echo, may be sent to signal transmitter 932.
• echoes may be effectively canceled in both signal-talk and double-talk scenarios.
• embodiments of the present invention may effectively cancel echoes without the need of a filter (or echo canceller) that is requited in a prior art device, arrangement, or method. Being immune to possible errors in echo path modeling that the filter may rely on, embodiments of the present invention may provide more accurate echo cancellation and faster cancellation, and therefore better quality of service. Further, the embodiments of the present invention may effectively cancel echoes in double-talk scenarios where conventional filters may usually perform poorly.
• embodiments of the present invention may also advantageously eliminate the need for high CPU processing power and large data memory that may be required by the filter, thereby reducing the cost in implementing echo cancellation.
• One or more embodiments of the present invention provide a mechanism to handle excessive WIAN jitter using VAD and jitter compensation for audio.
• One or mote embodiments of the present invention work also for video where lack of motion or no motion is used in conjunction with packet jitter
• the packet communication device may include a detector configured to detect a characterized content in incoming packets received by the packet communication device.
• the packet communication device may further include a play-out control configured to perform an adjustment of the incoming packets to produce adjusted packets and output the adjusted packets, if the detector has detected the characterized content in the incoming packets.
• a new jitter buffer scheme called content-based jitter buffer is proposed to overcome the current jitter buffer technology limitation.
• not only the KIT header information of the incoming packets, but also their RTF pay load contents to identify the silences and talk spurts on the incoming packets are observed. Then based on this silence or talk spurt cue to decide when the play-out delay can be inserted to compensate the network packet jitter.
• the jitter buffer on the receiver side will no longer depend on the transmitter's silence suppression any more.
• the aim here is mtioduee an adaptive de- ⁇ ttei contioISet to e ⁇ e ⁇ out plavout ⁇ similai scheme may be used to handle ⁇ ideo utter
• the silence or tali sputt cue is> uhu ⁇ to flush the mtet buffei when the silence or talk spurt cue reaches the maximum length I he differences of the new scheme from the pt ⁇ oi att design include that the silence ot talk spurt cue is used to eontiol when the play-out deiav can be inserted to compensate the netwoik packet jittei So, m accoi dance with one or moie embodiments of the present imention, the silence or talk spun detection will become a key part of the pttei buffei scheme Cndei some circumstances it be too late to make anv adjustment when the jitter buffer becomes
• [UUl 92 j Pig ⁇ B shows a block diagram of a ⁇ ideo ⁇ ttei buffet ni accoi dance with one or moie embodiments of lhe psesent imemiou
• the coie ⁇ ttei buffet is snntlat to ⁇ otce " s one except the delay will be nisei ted w hen there is no motion OJ ⁇ ety low mouon oii tbe frames liere aftei the decoder, tiie motion estimation and the motion compensation will geneiate a jesidue fiame ⁇ no- ⁇ iouon indicator can be founed fmm this iestdue fianie plus some specific threshold
• the no-moaon mdtcatoi then fed back to the jitter compensation pan and used to decide when to insert the pla>-out silence to compensate the network packet jittei In insert!
• ny the play-out silence is act ⁇ alh to stop plaung out the new frame while repeating the previous ⁇ tdeo frame [00193]
• piobiems such as packet dela> s ( ⁇ e , Sate arm a ⁇ s of packets), packet delay and packet loss mav ha ⁇ e negative effects on qualit> of service (QoS) m packet communication
• Packet delays and packet delay variation may also be known as jitter.
• a fixed de-jsfter buffer scheme may be employed to compensate the late ar ⁇ vals of packets by periodically inserting delays (e g., m the form of silence packets or comfort noise packets) when playing out packets from a packet buffer.
• delays e g., m the form of silence packets or comfort noise packets
• a transmitter-side voice activity detector may also be emplos ed for adaptively inserting delays, thereby compensating packet delays and packet delay variations.
• the transmitter-side VAD may not be supported by some user devices.
• the transmitter-side VAD may cause undesirable noise or choppy voice, for example, when a transmitting party is performing music playback, because pauses in music may be treated as silence and inappropriately handled.
• the transmitting party uses G.729AB codec with the transmitter-side VAD turned on to play out some music, the user in the receiver side may perceive distorted music.
• the transmitter-side VAD may be commonly turned off by packet communication ice providers and may not be able to compensate packet delays and packet delay variations.
• fixed de-jitter buffer scheme may still be employed, and the quality of service may still be undesirable to a receiving party.
• a receiver-side si fence detector may be employed for controlling packet buffer overflow, for preventing packet loss.
• packets may be discarded and therefore lost when the packet buffer is nearly full or is full, and the quality of service may be undesirable to the receiving party
• embodiments of the present invention may employ a receiver-side silence detector for timely compensating delays and delay variations and adaptively playing out packets from the packet buffer.
• the transmitter-side VAD is not needed, and desirable quality of sen ice may be pros ided.
• one or more embodiments of the present invention may employ a receiver-side video detector, thereby adaptively handling jitter in video communication
• the present invention relates, m one or more embodiments, to a packet communication device that may include a detector configured to detect a characterized content m incoming packets received by the packet communication device
• the characterized content may represent silence (e.g., a time period with no voice packets received) in voice communication
• the characterized content may represent at least one of no motion and an amount of motion thai is lower than a threshold
• the threshold of a no-motion or stilt picture may be selected to be 10% to 15% (in terras of date volume) of the full active picture in video communication.
• the packet communication device may further include a play-out control configured to perform an adjustment of Use incoming packets to produce adjusted packets and output the adjusted packets, if the detector has detected the characterized content in the incoming packets.
• the adjustment may include insertion of a delay, for example, in the form of silence packets or comfort noise packets.
• the adjustment may include repeating playing out packets that have been previously played out. As a result, the delays and delay variations of the incoming packets received at the packet buffer may be timely compensated, and the adjusted packets may be of acceptable quality to the receiving party.
• Fig, 1OA shows a block diagram of a first example prior art packet voice communication arrangement ⁇ first prior art arrangement) with an adaptive jitter buffer scheme.
• the first prior art arrangement includes a transmitter-side device 1091 and a receiver-side device 1092, connected through network 1003.
• transmitter-side device 109] and receiver-side device 1092 may represent a telephone, a mobile phone, or a teleconference device
• Transmitter-side device 1091 may include the following components: speech buffer 1000, voice activity detector 1001 (VAD KXH ), and transmitter 1002. These components may be described as follows:
• Speech buffer 1000 may be configured to receive voice packets (packets) from a microphone, buffer the packets, and then transmit the buffered packets to VAD 1001
• VAD 100! may be configured to insert a silence descriptor (SID) when there is silence (t.e., a period of ttroe between voice packets) in the packets received from speech buffer 1000.
• SID silence descriptor
• Transmitter 1002 may be configured to receive the packets from VAD 1001 and transmit the packets to network 1003.
• Receiver-side destee I 002 ma> include the following components packet buffer 1004 packet pla ⁇ -out oonttol 100S dela> insertion contiol 1 GG6, delaj- mfoimatJon module 1007, jittei calculator 10OS, and pla> -out delay calculates ! 0 ⁇ 9
• packet buffer 1004 packet pla ⁇ -out oonttol 100S dela> insertion contiol 1 GG6, delaj- mfoimatJon module 1007, jittei calculator 10OS, and pla> -out delay calculates ! 0 ⁇ 9
• [UtCO 7 I Packet huHet 1004 may he configured Io iecene the packets from network 1003 buffei the packets and then send the packets to pttet calculator 1008, delay insertion contiol 1006 and packet pla ⁇ -out control 100 ⁇
• httei calculator 1008 mav be configured to calculate the size oj tiUet m the packets I he ptter ma> iepiesent silence i e , a time pe ⁇ od between atmals ⁇ t tvvo ⁇ oice packet., with n ⁇ data
• Delav insertion c ⁇ utiol 1000 mav be configuietl to determine when to inseii dela ⁇ s based on SIOs insetted in ⁇ he packets * bs V AD 1001 of tunsnuttei-side deuce JO 0 M Deia> inseHion contio ⁇ 1006 mav teceive jitter size information fiem irttet calculator 1008 and mav ieceise packets ftom picket buffer 1004
• Pia ⁇ -ou. delas calculator 1009 mav be configured to tecene ⁇ tter sue mloimation from jitter calculate! 1008 Based on the ⁇ tter size mfoimation, pla ⁇ -out de!a> calculatoj 100 c > raa> calculate sizes of delavs to be insetted into the packets
• Delay mfoimation module 100 7 ma ⁇ be configuied to consolidate lnfoimatjon fiom dela ⁇ uisettion control 1006 regatding timing for insetting the dela ⁇ s and infounatio ⁇ from plav-out dela ⁇ calculator 1009 tegai ding the sizes of the delays
• dela ⁇ information module i 007 ma ⁇ build the consolidated information into a data structiue and send the data stmcture to packet pla> -out control 100 ⁇
• Packet pla ⁇ -out contsol IOCS ma ⁇ be configured to receixe packets ttom packet butter 100 i and insert dela ⁇ s into the packets according to the data structure received from dela ⁇ information module 100 7
• [0021 >j Jr tg !OB shows a flowchart of a transmittei-side process of a ptior ait jitter buffei scheme utilized foi example in the fust prior art arrangement jshown in the example of Fig 104
• the transmitter-side process starts with step 1060, at which speech buffei 1000 (shown in Fig 104) mav recci ⁇ e packets toi example from the microphone used bv a transmitting pat tj Speech buffer 1000 itunv then buffer the packets [002 S.4 j
• speech buffer ' ! 000 may set the marker bit of each packet to 0 by default.
• the marker hit of the packet may be set to 1 if the packet is the first voice packet of a talk spurt. Otherwise, the marker bit may he kept to 0.
• VAD 1001 may determine whether the packets contain one or more silence periods (i.e., one or more time periods with no data between packets). If the packets contain one or more silence periods, control may be transferred to step 1074; if not, control may be transferred to step 1066.
• silence periods i.e., one or more time periods with no data between packets.
• VAD 1001 may determine whether a SID(s) have been set in the packets.
• a SlD silence descriptor
• a SlD is configured to mark the beginning of a silence period. If the S ⁇ D(s) have been set for a silence pe ⁇ od(s) in the packets, control may be directly transferred back to 1072; if not, control may be transferred to step 1076 before being transferred to step 1072,
• VAD HX)I may generate the SlD(s) for the packets.
• transmitter 1002 shown in Fig. 10A
• VAD 1001 may determine whether the packets contain a first voice packet(s) after a silence pe ⁇ odfs). If the packets contain a first voice packet(s), control may be transferred to 1068, at which VA ⁇ 1001 may set the marker bit(s) for the first voice packet(s) to 1. If the packets contain no first voice pack ⁇ tCs), control may be transferred to step 1072, at which transmitter 1002 may transmit the packets to network 1003.
• Fig. 1 OC shows a flowchart of a prior art delay calculation process.
• the delay calculation process may be part of the receiver skfe process utilized, for example, in receiver-side device 1092 of the first prior art arrangement shown in Fig IC)A.
• the delay calculation process may be performed involving packet buffer 1004, delay insertion control 1006, jitter calculator K)OS, play-out delay calculator ⁇ 009, and delay information module 1007 of receiver-side device 1092 shown in the example of Fig. 10A .
• the delay calculation process may start at step 1022, at which packet buffer 1004 may receive packets from network .1003 and buffer the packets
• the packets may represent packets transmitted by transmitter 1002 (shown in Fig. H)A) at step 1072 (shown in Fig, 10B).
• j itter calculator 1008 may calculate an average jitter j [00221 ]
• j itter calculator 1008 may calculate jitter deviation v .
• play-out delay calculator 1009 may calculate a play-out delay using j and v and based on a network model represented by f(j, v), i.e., delay d ⁇ f(j, v).
• delay insertion control 1006 may determine whether packet buffer 1004 is empty. If packet buffer 5004 is empty, control may be transferred to step 1038; if not, control may be transferred to step ! 032.
• delay insertion control 1006 may determine whether marker bit(s) of value 1 have been set. If the mark bitf s) of vai ⁇ e 1 have been set., control may be transferred to step 1038; if not, control may be transferred to 1034.
• delay insertion control 1006 may determine whether there is a SlD(s) in the packets. If there is a SiD(Sh control may be transferred to step 1038; if not, control may be transferred to step 1036.
• delay insertion control 1006 may determine whether the average jitter j is greater than a predetermined threshold.
• the threshold here may be the length of packet buffer 1004.
• control may be transferred to step 1038; if not, control may be directly transferred to step 1040,
• delay information module J007 may consolidate size and timing information for inserting delays, then control may be transferred to step 1040.
• step 1040 information pertaining to inserting delays may be output to play-out control 1005.
• Fig. 1 OD shows a flowchart of a prior art packet play-out control process.
• the packet play-out control process may be part of a receiver side process utilized, for example, in receiver-side device 1092 of the first prior art arrangement shown in Fig, 1 OA.
• the packet play-out control process may be performed by packet play-out control 1005 shown m Fig. I OA.
• the packet play-out control process starts at step 1042, at which packet play-out control 1005 may receive packets from packet buffer 1004 (shown in Fig I OA) and may receive the information pertaining to inserting delay as a result of step 1040 (shown in Fig. H)C) from delay information module 1007 (shown in Fig I OA). [00232 j At step 1044, packet play-out control 1005 may determine whether enough delays have been inserted. If enough delays have been inserted, control may be transferred to step 1048: if not, control may be transferred to step 1046.
• packet play-out control 1005 may insert delays (e.g., in the form of silence packets or comfort noise packets) into the packets received from packet buffer 1004,
• packet play-out control 1005 may retrieve packets from packet buffer 1004.
• packet play-out control 1004 may play out packets resulted from steps 1046 and 1048.
• Fig. 1 OE shows a schematic representation of received packet flow at packet buffer 1004 (shown in Fig. 10A) when the transmitter-side VAD 1001 (shown in Fig. 1 OA) is turned OIL AS shown in the example of Fig. 1OE, the received packet flow may include voice packets 1080, silence 1084 following voice packets 1080, voice packets 1086 following silence 1084.. silence 188 following voice packets 1086, etc. Silence 1084 and silence 1088 represent time periods during which no voice packets are received at packet piay-out control 1005. Since VAD 1001 is turned on, VAD 1001 may have set marker bits of first voice packets such as packets 1080a and 1086a to I. The marker bits of value 1 may be utilized at step 1032 shown in Fig. 1 OC for determining when to msert delay.
• VAD 1001 may have inserted SlD 1082 at the beginning of silence 1084 and SlD 1090 at the beginning of silence 1088.
• SID 1082 and SlD 1090 may also be utilized at step 1034 shown in Fig 1 OC to determine when to insert the delay.
• Fig. 1 OF shows a schematic representation of received packet flow at packet buffer 1004 (shown in Fig. 10A) when transmitter-side VAD 1001 (shown in Fig. 10A) is turned off. Because existing algorithms employed in VAD 1001 may cause undesirable noise or choppy voice, for example, in music playback, VAD 1001 may commonly be turned off by packet communication service providers and therefore may not be able to provide information related to voice activity.
• the received packet flow may include voice packets 1092, silence packets 1094 following voice packets 1092, voice packets 1096 following silence packets 1094, silence packets 198 following voice packets 1096. etc. Because VAD 1001 is turned off, there may be no SlD inserted for the silence periods represented, for example, by silence packets ! 094 and silence packets ⁇ 098 ⁇ s a result, step 1034 (i e , detecting SlDs) shown m Fig 1 OC ma ⁇ not be performed
• F ⁇ rthct although % oice packet 1092a roav have a maikcr bit value of K ail of the rest of the j ccen cd packets may ha% e a marker bu value of 0 Tha efbic, step 1032 ( ⁇ e , determining whether mark hit ⁇ aiues foi fust packets are set to U shown m Fig i OC mav not be performtjd
• I- ig 1 1 4 shows a block diagram of a reccis er-side I I fK ) of a second poor art packet voice communication arrangement (second prior art arrangement), which includes adaptive buffer control
• second prior art arrangement which includes adaptive buffer control
• tig 1 I A, iee 1 HW includes the components of leceiver-side de ⁇ tec 1092 in the first prior art arrangement shown in Fig 1 OA
• car-side device 1 100 includes additional components 1 180
• the additional components 1 180 roav include decodct 1 1 18, silence detector H 16, and buffer ov ctflovv conttol 1 1 14, described as follows
• Decoder H IS mav be configured to decompress voice packets
• Silence detector 1 1 16 may be configured to detect silence in the packets received from decoder 1118 If there is silence, then silence detector 1116 may set a silence flag value to 1. If there is no silence, silence detector 1116 may set the silence flag value to 0.
• Buffer overflow control H 14 may be configured to monitor the status of packet buffer ! 102. According to Use status of packet buffer 1 102, buffer overflow control i 1 14 may determine whether to drop or to keep next packets received at packet buffer 1 102
• Pig. 1 1 B shows a flowchart of a silence detection process utilized, for example, in receiver-side device 1 100 shown m the example of Fig. 1 1 A.
• the silence detection process starts at step 1 120. at which decoder 1 1 18 (shown in Fig, HA) may decompress voice packets (packets) received from packet play-out control 1 104 (shown in Fig, 1 1 A).
• silence detector 1 1 16 may determine whether there is silence in the received packets. If there is silence, control may be transferred to 1 130, at which silence detector 1 1 16 sets the silence flag value to 1. If there is no silence, control may be transferred to step i 126, at which silence detector 1116 sets the silence flag value to 0.
• silence detector 1 j j 6 may output the silence flag value.
• Fig, 11C shows a flowchart of a buffer overflow control process utilized, for example, in receiver-side device 1100 shown in the example of Fig. HA,
• the buffer overflow control process may be performed by buffer overflow control 1 1 14 shown in Fig. 11 A.
• the buffer overflow control process starts at step 1 132, at which buffer overflow control 11 14 receives the silence flay value from silence detector 1 1 16 (shown in Fig 11 A).
• buffer overflow controi 1 1 14 may determine whether packet buffer 1 102 (shown in Fig. 2A) has reached a first threshold such as, for example, 100% full. If packet buffer 1 102 has reached the first threshold, control may be transferred to step 1 144; if not, control may be transferred to step U 36.
• a first threshold such as, for example, 100% full.
• buffer overflow control 1114 may command packet buffer 1102 to discard newly received packets, regardless of whether the newly receive packets represent voice packets. Buffer overflow control 1 1 14 may also command packet buffer 1102 to provide packets to be played out. [00254] At step 1136, buffer overflow control 1 1 14 may determine whether packet buffer i 102 has reached a second threshold such as, for example. 80% full. If packet buffer i 102 has reached the second threshold, control may be transferred to step ⁇ ⁇ 40, if not, control may be transferred to step 1 138.
• a second threshold such as, for example. 80% full. If packet buffer i 102 has reached the second threshold, control may be transferred to step ⁇ ⁇ 40, if not, control may be transferred to step 1 138.
• buffer overflow control 1 1 14 may determine whether the silence flag value received from silence detector I U 6 is 1. If the silence flag value is 1 , control may be transferred to step 1142; if not, control may be transferred to step 1138.
• buffer overflow control 1 1 14 may command packet buffer 1 102 to discard newly received packets since the newly received packets may represent silence
• Buffer overflow control 1114 may also command packet buffer 1 102 to provide packets to be played out Control may then be transferred to step 1 138.
• packet buffer 1 102 may receive and buffer packets.
• the buffer overflow control process shown in the example of Fig 11C may not be effective in maintaining quality of service.
• the first threshold e.g., 100% full voice packets may be discarded according to step 1 144. Therefore, choppy voice may be resulted.
• packet buffer 1 102 may still receive bursts of voice- packets which are greater than the remaining capacity of the packet buffer 1 102 Consequently, overflow may still occur, and packets ⁇ including voice packets) that exceed the capacity of packet buffer 1 102 may still be lost. As ⁇ result, quality of service may be undesirable to a receiving party.
• Fig, 12 A shows, in accordance with one or more embodiments of the present invention, a block diagram of a receiver-side device 1200 of a packet, voice communication system with adaptive jitter handling
• Receiver-side device I 200 may represent a user device such as, for example, a telephone, a mobile phone, a teleconference device, an audio player, or a video phone.
• receiver-side device 1200 may represent a server device in a packet communication network
• receiver -side device 1200 may include one or more of the following components: packet buffer 1202, packet play-out control 1208, decoder f 210, delay insertion control S 214, delay information module 1216, jitter calculator 1204, and play-out delay calculator ⁇ 206.
• Receiver-side device 1200 may further include a detector configured to detect a characterized content such as silence detector 1212 for detecting silence.
• Silence detector 1212 may be configured to receive decompressed packets from decoder 1210.
• Silence detector 1212 may further be configured to process the decompressed packets and provide a silence flag (but not the decompressed packets) to delay insertion control 1214 through link 1299.
• One or more of the components may he included in software that may be downloaded into receiver-side device 1200.
• receiver-side device 1200 may have capabilities similar to capabilities of components of receiver-side device 1 100 shown in Fig. 1 1 A. However., in contrast with silence detector 1 1 16 of receiver-side device 1100, silence detector 1212 may be configured determine when to insert delays for handling jitters instead of or in addition to controlling packet buffer overflow.
• delay insertion control 1214 may receive information from silence detector 1212.
• Delay insertion control 1214 may be directly coupled to silence detector 1212 through link 1299.
• Link 1299 may represent a direct logical link or physical link. There may be no direct logical or physical connection between jitter calculation 1204 and delay insertion control 1214, in contrast with link 1 199 between jitter calculator 1 1 10 and delay insertion control i i 08 shown in the example of Fig 1 i A and link 1099 between jitter calculator 1008 and delay insertion control 1006 shown in the example of Fig I OA.
• Fig. 12B shows, in accordance with one or more embodiments of the present invention, a delay insertion control process utilized for adaptive jitter handling utilized, for example, in receiver- side device ! 200 shown in the example of Fig. 12 A.
• the delay insertion control process starts with step 1220, at which delay insertion control 1214 (shown in Fig. 12A) may determine whether packet buffer 1202 (shown in Fig. 12A) is empty, i.e., containing no packets for playing out. If packet buffer 1202 ts empty, control may be transferred to step 1228, if not, control may be transferred to [00266]
• delay insertion control 1214 may determine whether the marker bit(s) of value ! are set in incoming packets that are received through packet buffer 1202. ⁇ f the mark bit(s) of value 1 are set, control may be transferred to step 1228; if not, control may be transferred to 1224.
• delay insertion control 1.214 may determine whether there is a SlD(S ) m the incoming packets. If there is a SID(S K control may be transferred to step 1228; if not, control may be transferred to step 1226.
• delay insertion control S 214 may determine whether the silence flag value received from silence detector 1212 (shown in Fig. 12A) is 1. If the silence flag value is 1 , control may be transferred to step 1228, if not, control may be transferred to step 1230.
• packet play-out control 1208 may insert delays (e.g., silence packets or comfort noise packets) into the incoming packets according to information received from delay information module 1216 (shown in Fig. 12A) to generate adjusted packets.
• the delay information includes size information provided by play -out delay calculator 1206 (shown in Fig, 3A) and timing information provided by delay insertion control 1214,
• packet play-out control 120S may play out the adjust packets.
• the adjusted packets may he decompressed by decoder 1210 and then be played out by receiver-side device 1200
• delay insertion control 1214 may determine the timing for inserting delays based on silence flag value received from silence detector 1212 (at step 1226) even if no information is received from jitter calculator 1204.
• Fig. 13 shows, in accordance with one or more embodiments of the present invention, a block diagram of a receiver-side device 1300 of a packet video communication system with adaptive jitter handling.
• Receiver-side device ⁇ 300 may represent at least one of a telephone, a mobile phone, a teleconference device, a videophone, and a video player.
• receiver- side device 1 300 may represent a server device in a packet communication network.
• Receiver-side device i 300 may include components performing functions similar to functions of components of receiver-side device 1200 shown in the example of Fig 3A.
• Receiver- side device 1300 may include one or more of a picket buffer 1302. a jitter calculator 1304, a compensation contio! J 314, a compensation calculator 1306. a compensation information module 1 3 Ib, a packet pia>-out corttiol 1 308, decoclei HI O, and a video dctectoi HI 2
• v jdco detectot Hl 2 mav be e-otifigiaed to detect no motion or low motion in video packets, instead of silence Furthet , instead of being configuicd to calculate and consolidate mfon nation foi deSav insettsou
• compensation 130o compensation control 1314, and compensation uifoimation module 1316 may be configured to calculate and consolidate information for video compensation
• the ⁇ ⁇ ieo compensation mav include stopping placing new ⁇ ideo Dames and mav be peifotmed by packet piav-o ⁇ t control 1308
• One or moie embodiments of the piesent imeutmn mav im oKe a receivei-side device that includes a config ⁇ tatson similar the coufigmatio ⁇ of tecener-side de ⁇ tee 1300 and is configured to handle jUtei in multimedia communication that includes ⁇ oice and ⁇ ideo Fuitlier, one oi mote embodiments of the present imention ma> imoKe a dela> insertion control and video compensation control process that is similar to the delay insertion cont ⁇ ot process shown m the example of Fig 12B
• embodiments of the present imention may activity detector (VAD) or a fixed jitter buffer scheme
• VAD activity detector
• a receix er-side silence detector foi dela> insertion conttol instead of onlv for buffer contiol
• embodiments of the present invention may accurate!) insert delay-!, without unnecessarily inserting dcla> s into ⁇ oice packets ⁇ dvantageoubiv, choppv voice may be seduced, and voice quality ma ⁇ be cnsuicd
• embodiments of the present in ⁇ ention mav be utilized m video communication and/oi multimedia communication
• D Di vitas Description Ptotocol (DDP) [0028Oj
• DDP Di vitas Description Ptotocol
• DDP has been architeeted takmg the following factors into consideration.
• DDP independent of server and client hardware and OS
• the structure and format of the protocol is such that DDP us agnostic of the server or handset hardware platform as well as the operating system running on both of the platforms.
• the protocol is architeeted and designed to run on any server or handset hardware platform and is independent of the Operating System/SW platform running as well.
• DDP may run on Linux, Symbian, Windows Mobile 5.0, etc.
• no special adapter layer needs to designed or developed time this module has to be ported on to a new- hardware or software platform
• DDP Decoupled from control plane protocol
• DDP has been architeeted such that is can be used with any of the control plane technologies that is use on a given platform - i e , SIP, H 323 etc
• DDP Independent of transport protocol; Designed to be efficient when used over both UDP and TCP.
• This reliability module removes the burden on higher layer application to worry about guaranteed delivery especially in environments with high packet Joss.
• DDP will be used for a wide range of application ranging from critical control plane messages with strict real time requirements to application that need to transfer large amounts of data between the server and the client
• Optional module within DDP enables the application to transfer files and buffers between the server and client
• the protocol also does not care about the type of the application data - i.e. binary, text,
• the protocol Independent of the medium: The protocol ss independent of the medium over which the client is connected to the server.
• the session could be over WiFi, cellular data channel or wired
• Fig. 6A shows an overview of a DDP architecture that is fabricated in accordance with one or more embodiments of the present invention.
• DDP is a session layer application that runs over SiP protocol.
• the encrypted application layer information that is transmitted between client and server is used to affect handoff decisions, provide session persistence for data applications such as, for example and without limitation, email or SMTP.
• Fig, 6A gives a high level view of the different modules that make up DDP.
• DD ⁇ in accordance with one or more embodiments of the present invention:
• Session Management An inbuilt mechanism to evaluate the health of the DDF session between two peers and mechanisms for informing the registered applications if the session fails.
• DDP Scheduler Provision for having different priority levels for DDP messages based on the application requirements.
• Reliable DDP module Support for guaranteeing reliable delivery of DDP messages depending on the application requirements.
• DDX Divitas Data Transfer
• the DDX module will work independent of the file format or the buffer contents and has mechanisms for error checking and confirmation of delivery.
• DDPS The module in DDP that encrypts and decrypts the DDP contents before they are inserted in the signaling packets.
• DDP has a protocol for establishing the secure DDP tunnel between 2 Divitas peers.
• F ⁇ g 6B shows the exchange of DDP messages du ⁇ ng the initialization of a chent when a user logs on to one of the devices m accoi dance one or mose embodiments of the ps esent invention
• DDP is a La>er 4 oi an application la> er pioloco! DDP can use TCP, L DP O ⁇ TLS ft « transpo ⁇ Similar to SlP or
• a DDP message comprises a sequence of lines O ⁇ fields wherem each hue of field begins w ith a single lower case letter which denotes the t ⁇ pe of infoimation that is being conveyed, the rest of the line oi field contains pieces of mfomiatjo ⁇ associated w ith, a function or method in accordance with one oi more embodiments of the present invention, theie can be multiple lines oi fields with the same staitmg name or type
• each DD ⁇ message comprises a set of raandatoiy lines oi fields and optional lines oi field, depending on the specific type of DDP message bcmg sent If any of the mandatory lines are missing, a parser will reject the DPP message Optional lines that the parser cannot understand are skipped o ⁇ ei
• the DlW message is then added as a message body in a SiP message with a message type of "application ddp" or "application/ddps"
• the DDP body can also be sent with othei signaling protocols if lequired
• DDP Voice mobility depends on a lot of factors - the primary one being the WiFi quality experienced by the client.
• DDP is used to send the WiFi report in real time with information about the AP that the handset is currently associated with to make mobility decisions.
• the WiFi report can also optionally contain information about the neighboring APs so that the mobility server can use this information to take preemptive mobility decisions based on the predicting the movement of the handset.
• DDP is also used for user initiated mobility decisions.
• DDP is used extensively in managing the client and the user experience on the handset. Here are some of the different way in winch ODP based control and bulk transfer messages are used for managing the client: a. Device Configuration: Sending device specific configuration to the device during initialization once the device-'user have been authenticated, fa. Mobility Thresholds: WiFi thresholds based on administrator settings for the client to initiate mobility' actions, e. User Information: When a user logs on to one of the clients, the server pushes the user specific information (like extensions, preferences etc.) over DDP. d. Device Image Management; Ability to upgrade the handset software over the air is achieved using DDP bulk transfer capability.
• Voicemail/Email download to handset One of the key differentiator of the Divitas solution is the ability to download voicemails to the handset and manage them at a time of your convenience. The ability to manage voicemails without IVR is possible by proprietary control messages that interface with the Voicemail system as well the bulk transfer capability in DDP to transfer the germanemaiis to the handset A similar functionality can also be achieved for Email system where an adapter module can be built to interface with the Email system of choice.
• User Presence Management DDF messages with the user's preference for voice and text over the different medium is communicated to the server for presence management This is a key piece of functionality that allows the support of Presence aware calling.
• the architecture and design of Rendezvous calling is also based on enhanced presence and user preferences all communicated over DDP to provide the service Rendezvous calling is designed to provide.
• Instant Messaging The messages for IM are tunneled over a DDP session. This allows the IM client on the handset to be unaware of the medium/protocol in which the device is operating.
• S ⁇ j F ⁇ g 14 shows a p ⁇ or ait example of a call flow t ' oi establishing a connection between an application client and an application sct ⁇ cr Constda the situation wherein, foi example, a user of a handset wants to employ an application client 1404 to request for a software download 1406 ⁇ ia a web htowser thiough a ⁇ !TTP (hypestext tiansfer protocol) connection
• application client 1404 may ⁇ smd a ICP ACK to application 1402
• step J4J4 application client 1404 may send an HTTP Get to application server 1402
• application client 1404 JS sending the usci 's request for a software download 1406 to application sen, er 1402
• L pon receiving the H I FP Get application scner 1402 may perform a search to locate the requested download, at a next step 1416
• application sen er 1402 may begin sending the icquested softwase as data packets ⁇ e g , TCP data segments) to application client
• the software file mav be broken into a plurality of data packets in otdoi to facilitate the psocess of sending the softwaie file through the netwosk
• application client 1404 may send a TCP ACK to application senei 1402
• Steps 1418 and 1420 may he iepeated until all of the data packets foi the requested softvsate download been sent by application senet 1402 to application client 1404
• application senei 1402 ma> send au I ⁇ TFP 200 OK to application client 1404
• application seuei 1402 is notifying application client 1404 that all data packets i elated to the softwaie download request been sent
• each application client on a handsel may send a notification 1424 to the uset informing the user that the download has been completed [00325]
• the method described in the call How of Fig, I may have to be performed by each application client.
• the handset includes multiple application clients (e.g , video application client, voice application client, instant messaging application client, game application client, virtual reality application client, etc. k an independent channel may have to be established between each application client and its corresponding application server before interaction between the application client and the application server may commence.
• communication between the different applications is not guaranteed, As a result, an application running on a given client may be unaware of the data exchange that may be happening for another application on the same client.
• the method described in Pig. 1 is a cumbersome method that may require each application on a client to be properly configured m order to assure that the application may successfully interact with its corresponding application on a given server within an enterprise. This method could create both security risks and increased complexity by requiring that a separate network session be allowed for each of the applications that communicate between a client and a server
• a single protocol that is independent of hardware (e g., handset) and software (e.g., video application client, voice application client, instant messaging application client, game application client, sirtual reality application client, etc. ) may be employed to consolidate all of the applications network sessions
• software e.g., video application client, voice application client, instant messaging application client, game application client, sirtual reality application client, etc.
• a protocol may be implemented that takes advantage of existing control and transport protocols but is hardware and software independent, thereby allowing a plurality of application clients to interact with its corresponding plurality of application servers.
• the DDP may include a DDP client and a UDP server.
• Embodiments of the invention enable the DDP to efficiently transport data packets between a plurality of application clients on a handset and a plurality of application an enterprise.
• Embodiments of the im ention also enable DDP to be implemented independent of the hardware and software platforms.
• the DDP ⁇ S independent of the hardware platform.
• the DPP may be implemented on dual-mode handsets, personal digital assistants (PDAs). 802 1 1 telephones, and the hke.
• the DPP is also independent of the software platform.
• the UPP may be run on a Linux ® system, a Symbian ® system, a Window i M Mobile 5.0 system, and the like.
• DDP may be implemented to establish a single secure channel through which interaction between application clients on a handset and application servers within an enterprise may be conducted [00331 1 With a single secure channel from which a plurality of data traffic may be exchanged, the information that is downloaded onto the handset may be managed by the application client. Thus, an application client that may require the utilization of information that has already been downloaded does not have to request for the date to be downloaded again.
• the mobility client with DDP may be able to direct the application client to the storage location of the requested data.
• the DDP may be independent of the network in an example, the secure channel established by the DDP may be through Wi-Fi network or a cellular data network, for example. This enables DDP to ensure that a network session can be handed off to a separate network, when a user on a client device roams.
• the DDP is built on top of a control protocol and a transport protocol.
• the DDP may be implemented with any available control protocol (e g., SlP, H.323, etc.).
• the DDP may be implemented with any available transport protocol, such as a user datagram protocol (UDP), a transmission control protocol (TCP), or a transport layer security (TLSK for example.
• UDP user datagram protocol
• TCP transmission control protocol
• TLSK transport layer security
• the DDP is able to efficiently route data packets and manage connectivity without having to be concerned about the control and/or transport protocol that may be available.
• the DDP may include a reliability module (RDDP), which may ensure a level of reliability for the delivery of the data traffic.
• RDDP reliability module
• This module is useful when utilizing a transport protocol such as UDP, that does not provide reliability.
• UDP transport protocol
• DDP may provide assurance of a successful transfer and remove the burden of monitoring the data traffic (TORI the application clients.
• the DDP may be implemented for a plurality of applications (i.e., application clients and their corresponding application servers), hi an example, the DDP may be employed by a simple application thai may not require real time exchange of data. In another example, the DDP may be employed by an application that has real time requirements for the exchange of data. Due to the DDP adaptability, applications may be added or removed without impacting the capability and versatility of the DDP.
• DDP may include a priority message scheduler module which may be configured to schedule and queue data traffic.
• the DDP may employ the priority message scheduler module to automate the plurality of downloads and uploads that the plurality of applications may need or require.
• Fig. 15 shows, in an embodiment of the invention, a simple architectural diagram of the DDP invention
• DDP 1536 is independent of hardware and/or software platforms
• DDP 1536 may be implemented on a plurality of client devices, including, but are not limited to, dual-mode handsets, PDAs, laptops, and the like
• DDP 1536 may be implemented with different operating systems, such as. a Linux® system, a SyrabianCl 1 system, a Window TM Mobile 5.0 system, and the like.
• DDP 1536 may be loaded onto different hardware and/or software platform with minimal modification.
• DDP 1536 may be built on top of a control protocol and a transport protocol.
• DDP 1 536 may be used with different type of control protocols (e.g., SlP 1 532 and other control protocols 1524) and different type of transport protocols (e.g., UDP 1534, DDP J 528, TCP 1530, TCP 1526, etc. ⁇ .
• control protocols e.g., SlP 1 532 and other control protocols 1524
• transport protocols e.g., UDP 1534, DDP J 528, TCP 1530, TCP 1526, etc. ⁇ .
• the type of control protocol and/or transport protocol that may be employed by DDP 1536 in order to perform its function may be easily adapted by DDP Thus, if the control protocol and/or the transport protocol change, DDP 1536 will adapt itself to utilize any combination of available transport and control protocols as required.
• DDP 1536 in an embodiment, that ⁇ S capable of determining the preferred transport protocol to provide the best performance and reliability.
• DDP 1536 the responsibility of identifying the correct transport protocol may be centralized and moved from the plurality of applications to DDP 1536. Since ail the data traffic between a DDP client and server is now handled by DDP 1536. DDP 1536 may be able to determine the best transport protocol for routing data traffic while minimizing the possibility of data packet loss,
• DDP 1536 may include one or mote modules, such as a DDP with security extension module (DDPS module 1 522), a priority message scheduler module 1518, a reliable DDP module (RDDF module 1 516), a built-in session management module 1520, and a DiVitas data exchange module (DDX module 1514).
• DDPS module 1 522 DDP with security extension module
• RDDF module 1 516 reliable DDP module
• DDX module 1514 DiVitas data exchange module
• DDPS module 1522 may provide security functionality to DDP 1536.
• DDPS module 1522 may enable a secure channel to be established between a mobility client of a handset and a mobility server within an enterprise. With a secure channel, ail incoming and outgoing data traffic from the plurality of applications may be routed through a single secure channel,
• DPPS module 1522 may include a database, which may include the authentication data required for establishing a connection between an application client and an application server.
• DDPS module 1 522 may provide encryption/decryption functionality, thus enabling DDP 1536 to provide security for applications thai may require the functionality.
• an important e-mail from application client 1508 is routed from an email server to an email application client on the handset
• DDPS module 1522 may encrypt the DDP data packets before sending the packets to the corresponding application server.
• an instant message between two 1 M clients may be sent in a non-secure manner.
• DDP 1 536 may route the instant message without employing the DDPS module 1522 to encrypt the data packets sent between the IM clients.
• DDP 1536 may include priority message scheduler module 1518, which may be configured to schedule and queue data packets
• priority message scheduler module 1518 may be responsible for managing the plurality of different data packets that may be serviced by DDP 1536.
• priority message scheduler module 1518 may establish a policy for handling the incoming and outgoing data packets.
• priority message scheduler module 1518 may have different priority levels depending upon the originating application.
• application A e g., email
• application B e.g..
• priority message scheduler module 1 518 may be an optional DDP module. In an example, if DDP 1536 is currently only handling data traffic for one application, then DDl* 1536 may not have to employ priority message scheduler module 1518 to handle the scheduling of the data packets
• DDP 1536 may include a reliable module (RDDP 1516), which may provide a level of assurance for the delivery of the plurality of data packets.
• RDDP 1516 has mechanism to retransmit packets that do not successfully reach their destination within a specified time interval.
• the packet will be retransmitted The packet may be retransmitted a specified number of times before notifying the application that the transfer of the packet has failed.
• DDP 1536 may provide assurance that data packets are being sent and/or received in the order in which the application requires [00347]
• DDP 1536 may include a DDX module 1514, which may be employed to transport large amounts of data. (e.g. image files, log files, etc..) between the mobility client and the mobility server.
• DDX module 1514 includes mechanisms to ensure the data integrity of the data transfers between the mobility client and mobility server,
• DDX module 1514 may include mechanisms for confirming completion of the data transfer to the applications..
• DDP 1536 may be implemented for a plurality of applications including, but are not limited to, voice mobility control application 1 506, device management application 1504, project management application 1502, voicemail/email transfer application 1508, device image management application 1510, instant messaging application 1 512, and the like.
• the plurality of applications may be divided into two groups.
• DDP 1 536 may employ DUX module 1514 to convert the files into smaller data packets that can utilize any of the other modules within DDP 1 536, including 1516, 151 S 5 1522, and provide assurance that the data file has been successfully transmitted and that the application has been notified of the completed transfer.
• the plurality of applications (voice mobility control application
• voice mobility control 1506 may enable the mobility client and the mobility server to share mobility status, which may be sent in a single DDP packet.
• Fig. 16A shows, in an embodiment, an example of how data within a mobility architectural arrangement with DDP may flow between an application client located within a client device and an application server, which is managed by an enterprise.
• a user on a client device wants to employ a votcemail client 1602 to retrieve a voicemai! from a voicemail server 1604.
• voicemail server 1604 may initiate a file transfer.
• Voicemail server 1604 may send the file along a path 1650.
• the mobility server may prepare the file to be sent through a secure channel to a mobility client on the client device.
• a server DDX module 1608 which is within the mobility server, may be employed to convert the file into a format that is compatible with the control and transport protocol of the secure channel.
• server DDX module 1608 may convert the file, which may be in a binary format into a format that can be transported over the SiP protocol.
• server DDX module 160S may break the file into a plurality of data packets in order to ensure the effectiveness of routing the plurality of data packets through the secure channel.
• server DDX module 1608 may send a first data packet to a server DDP 1616.
• Server DDP J 616 may include a server RDDP 1614, which rnay provide a level of assurance for the delivery of the first data packet.
• server DDP 1616 may include a DDPS module, which may encrypt the data packets as required by the application.
• simple data packets e.g., mstant messages
• important data packets may be encrypted before being routed to the requestor, [00356] from server DDI* 1616, the first data packet may be encapsulated as a SlP notify message (as shown in a code example 370 of Fig. 16B) and sent via the secure channel through a network 1624 to the client device.
• the first date packet may be sent through the secure channel by using a server SSP control protocol 1620 and a server UDP transport protocol 1622.
• the first data packet may be received securely by the mobility client of the client device, which may receive data packets through a client UDP transport protocol 1626 and a client SlP control protocol 1628
• a client DDP 1632 may receive the first data packet.
• a client RDDP ] 634 may perform a similar check as that performed by server RDDP 1614, Also, client RDDP 1634 may send a SlP Notify Message with a DDP acknowledgment along a path 1652 through the secure channel to server DDX module 1608. By sending the DDP acknowledgement, client RDDP 1634 may send an assurance from the mobility client to the mobility server that data packet has been received.
• server RDDP module 1614 will retransmit the data packet until the packet has been successfully acknowledged or the maximum number of retries is exhausted.
• a data packet may be sent and the next data packet may not be sent until a DDP acknowledgement has been received, ⁇ n an example, server DDX module 1608 may not send a second data packet until a DDP acknowledgement has been received.
• a fixed number of data packets may be sent and the sending of additional packets would not occur until an acknowledgement is received for one or more of the initial data packets.
• server DDX module 1608 may send a group of 10 data packets and will be required to wait until at least one acknowledgment is received before it is allowed to transmit an additional data packet.
• client DDX module 1636 may hold the data packets until al! data packets have been received.
• server DDX module 1608 may send a message indicating that each of the data packets for the requested file has been sent and that no additional data packet for the file will be forthcoming. Once al! of the data packets have been received, then client DDX module 1636 will reassemble the file and notify the vote-email client 1602 that the voicemail file is available.
• the architecture of the DDP may provide a single secure channel from which a plurality of application clients may interact with a plurality of application servers.
• the architecture of the DDP may provide control by assuring that the data packets are being received, that proper verification has been done in order to acknowledge that all data packets have been received, and that there are no missing data packets.
• the architecture of the DDP may enable large files to be broken up into smaller data packets, which may be sent with the assurance that the acknowledgement may be sent by the receiving side.
• FIG. 17 shows, in an embodiment of the invention, an example of a call flow illustrating how a secure channel, may be established between a client, device and a mobility server. Jn an embodiment, to establish a secure channel, registration may occur.
• registration may occur.
• a SlP registration must first be established.
• a client SIP 1716 may send a S ⁇ P registration request through a client UDP 1714.
• the SlP registration request may be received by a server SIP 1710 through a server UDP 1712.
• server SIP 1710 may send a S ⁇ P registration response 1726 via server UDP 1712 and client UDP 1714 to client SlP 1716.
• steps to establish a secure DDP channel are initiated.
• a client DDPS module 1718 a module of a client DDP 1720, will send a DDPS session request to a server DDPS module 1708.
• the DDPS session request may be routed through client SiP 1716, client UDP 1714, server UDP 1712, server Sf P 1710 to server DDPS module 1708.
• server DDPS module 1708 Upon receiving the DDPS session request, at a next step 1730, server DDPS module 1708 will send a DDPS session, response 1730 to client DDPS module 1718 via server SIP 1710, server UDP ⁇ 712, chent UDP $ 714, and ciiem SlP 17 I 6 Otico the sec ⁇ io channel has been established, the user may have to iegister with the mobility serx er To notify the user, client DDPS 175 S may forwatd the DDPS session response to an application client 1722
• application client 1 722 may send a DDP registiaU ⁇ n request to a user ice manager 1704
• application client 1722 may send the registration information to a client DDP 1 720
• Client DDP 1 720 may send the registration information through the established secure channel (s e , thiough client DDPS module 1718, client SIP 1 716.
• DDP 1706 may then route the registration information to user ⁇ ce manager 1704 [00367]
• user device manager 1704 ma> Upon receiving the registration information, user device manager 1704 ma> send a DDP registration iesponse to application chent 1 732.
• user device manager 1704 ma ⁇ send the DDP registration tesponse to sen ex DDP 1706
• Servei DDP 170b may send the registration information through the established secure channel (i e . through sener DDPS 1708, sen er SIP 1710, server UDP I 7i ⁇ cliem UDP 1714, chent SIP 1716, and chent DDPS I Ti SI to DDP 1720.
• which ma> then, route the DDP registration response to the user of application chent ! 722
• registration may be a one-time e ⁇ ent
• client ice will register with the mobilit) server when the client device is initialized foi the first time
• the usct of the chent device may be assuicd that the sensitive DDP registration information is being sent encrypted and through a secuic channel
• no additional DDP registration may need to occur as long as the secure channel between the client device and the mobility server is maintained 1 « an embodiment, interaction between application clients on a client device and application servei s» managed an enterprise may now be conducted securely thiough a single secure channel
• Fig 18 and 19 show, m an embodiment, examples of how DDP may handle interaction between applications clients on a client device and application sen ers managed by an enterprise
• t-ig I S shows, in an embodiment, a simple call flow illustrating a situation m which a large file may ha ⁇ e to be sent
• a situation wheiem for example, a chent deuce ma> need to download the latest softwaie upgrade
• an application chent 1814 may send a request ! 81.6 for software upgrade to an image manager 1802, which may be responsible for managing the different software images on the server side.
• application client 1 S! 4 may send a new image request to image manager 1802, ⁇ n an example, the new image request may first be sent from client application 1814 to a client DDP 5.85.0. After receiving the new image request, DDP 1810 may send the request through a secure channel to a server DDP ! 808, Before being sent to image manager 1802, the new image request may be routed to a device/ user manager 1804, which may be responsible for determining which software may need to be upgraded. After device user/manager 1804 has determined which software upgrades the client device may need, device user/manager i 804 may route the new image request to image manager 1802.
• the image manager 1802 may then send the requested software upgrade (e.g., requested data 1820) to a server DDX module 1806.
• server DDX module 1806 may convert the file into a format that is capable of being sent through the secure channel established between the client device and the mobility server, In an embodiment, server DDX module 1806 will break the large file into a plurality of data packets in order to transport the file through the secure channel
• server DDX module 1806 may send a DDX file transfer start to a client DDX module 1 Si 2 via server DDP 1808 and client DDP 1810
• a DDX file transfer start refers to a notification between a server DDX and a client DDX that a file is about to be sent.
• the DDX file transfer start may include basic information about the incoming file such as, for example, name of the file, file size, number of data packets that may be sent, the application that is requesting for the file, and the like.
• client DDP 1810 may send a DDX start response to server DDX
• an RDDP module within the DO ⁇ may be sending the DDX start response.
• server DDX module 1806 may send a first DDX data packet to client
• the DDX data message may first be sent to server DDP
• the DDX data message will be encapsulated as a SlP notify message, in an embodiment, and sent through the secure channel over a SIP control protocol and a UDP transport protocol.
• the DDX data message may be received by a client DDl 5 1810, which may then route the DDX data message to client DDX module 1812, [00375]
• a DDP aeknow lodgement will be sent by chent DDP 18 ⁇ 0
• the RDDP module wtthm client DDP 1850 will send the DDP acknow lodgement to snfoini ses ⁇ ct DDX module i 8()6 that the incoming DDX data message has been tecei ⁇ ed successful !v
• Steps 1826 and 1828 may be iteiatn e steps that may be jepeaied until all DDX data packets and acknowledgements e been exchanged between the seiser and client DDX module
• DDX module 1806 will send a DDX file transfer end, at a next step 1830, to application client 1814 to notifv the application chent that all DDX data messages have been sent
• the DDX file tiansfer end may be sent fio ⁇ i ei DDX module 1806 to seivei UDP 1808 to the client device
• RDDP of chent DDF 1810 mav send a DDP acknowledgement to image manage t 1802, at a next step 1 832
• client DDP 1810 may route the DDX file transfer end to chent DDX module
• Fig 18 shows how the architecture of the DDP may he employed to send data traffic in a secure and tebable mannci that ma ⁇ enable the .sendes and the sequester the assurance that all data packets lot a requested file has e been successfully received
• Pig 1 Q shows, in an embodiment of the inv ention, a simple call flow illustrating a situation in w hich small contiol messages, such as those sent bv conliol applications, ma ⁇ be sent
• chent presence manager 1910 ma ⁇ send a caravannce preference setting (as a single DDP data packet) to a client DDP ! 908, which may then send the presence preference setting through a secure channel to a server DDP
• server DDP 1906 may send a DDP acknowledgement, at a next step 1918.
• a RDDP module within the DDP may be sending the DDP acknowledgement.
• server DDP 1906 will notify the server presence manager 1902 of the presence preference setting through the device/user manager 1904.
• client presence manager 1910 may send a presence query 1920 to client DDP 1908, which may send the presence query through the established secure channel to server DDP 1906.
• server DDP 1906 Upon receiving the presence query, server DDP 1906 will forward the query through device/user manager 1904 to server presence manager 1902, winch may perform the requested query to retrieve the requested information.
• server presence manager i 902 may send a presence response (e.g., requested status data) to client presence manager 1910.
• a presence response e.g., requested status data
• the presence response may be sent from server presence manager 1902 through device/ user manager 1904 to server DDP 1906.
• the presence response may be sent through the secure channel to client DDP 1908, which may then route the presence response to client presence manager 1910
• FIG. 18 and 19 show different examples of how DDP may be employed to manage the interaction between a plurality of data applications on a client device and a plurality of application servers managed by an enterprise.
• DDP establishes a single channel from which each of the application clients and the application servers may interact with one another. Also, the architecture of DDP may be employed to send data traffic in a secure and reliable manner that may enable the sender and the requestor the assurance that ail data packets for a requested file have been successfully received.
• Fig. 1 S shows how DDP may be employed in managing the user's experience on the client device including, but are not limited to, software upgrade, device configuration, and user information management.
• the DDF* may manage a user's presence (as seen in Fig.
• DDP may manage mobility by allowing the mer to roam from one data netwoik to another without having to vxo ⁇ y about session management
• ⁇ s can be appie ⁇ ated bv the embodiment of the indention a mobility architectural arrangement wuh DDP i educes the security risk by piowdmg a single seeuie channel fioni which inuUiple applications on a client device raav be able to communicate with a plutablv of applications on an enteipitse implemented independent of haidware a ⁇ 01 software limitations Also.
• DDP is an adaptable protocol that may be manipulated to take acKantage of a plurality of contiol and 'or transport piotocols
• enterp ⁇ se firewall needs to be opened for multiple piotocois
• a method which is fabricated in accordance with one or moic embodiment of the present indention, allows the handset based enterp ⁇ se applications to make use of existing ⁇ olP related connection m a secure mannet
• the handset based VoIP client acts as a sc ⁇ ci for the different applications sunning on the handset This component makes use of existing VoI? related connection
• the server side pio ⁇ component is responsible for stripping the pa ⁇ ioad and making connection to the actual cnteipusc servers
• the client and sei ⁇ et stde pio ⁇ y componenLs rnav furthei be sub-div ided into multiple subcomponents
• Pig 7 ⁇ shows a network architect me m accoi dance with one oi mote embodiments of the present invention and includes two network mtei faces pei host Iuo paths are pjovided through the independent oetwoiks. one fjom iineiface CO to S(S and anothet fioni Cl to Sl In S( ⁇ TJ*, these two paths would be collected into an association
• Failover can also be used to maintain network application connectivity. For example. consider a laptop that includes a wireless S02.11 interface and an Ethernet interface. When the laptop is in its docking station, the higher-speed Ethernet interface would be preferred; but upon loss of connection ⁇ removal from the docking station), connections would be failed over to the wireless interface. Upon return to the docking station, the Ethernet connection would be detected and communication resumed over this interface. This is a powerful mechanism for providing high availability and increased reliability.
• a multi-homing scheme is implemented which provides applications with higher availability than those that use TCP.
• a multi-homed host is one that has more than one network interface and therefore more than one IP address for which the multi-homed host can be addressed.
• a connection refers to a channel between two endpoints ⁇ in this case, a socket between the interfaces of two hosts).
• Figs 7B-D show how a thin client along with a counterpart of the thin client on the server has in affect created an efficient transport mechanism for conveying state information between handset and the server in accordance with one or more embodiments of the present invention.
• An example of an e-maii application ⁇ i.e , SMTP) is shown that uses the SIP - NOTIFY method to tunnel application layer packets without the knowledge of the SiVfFP application. This has advantages where the presentation layer application on the client does not have to be changed to provide session persistence.
• the enterprises may achieve a more secure and easy to manage enterprise mobility This method also enables VoIP vendors to extend their mobility solution to different enterprise applications.
• Fig. 20 is a prior art example of an architectural arrangement in which each application on a handset is connected individually to a corresponding application server within an enterprise.
• ⁇ handset 2000 may include a plurality of application clients including, but are not limited to, a
• Di Vitas client 2002 Di Vitas client 2002, a CRM (customer relationship management) application client 2006, and a mail application client 2008
• the application clients may be independent of one another or may interact with one another via application protocol interfaces (APIs),
• application clients 2006 and 2008 may be interacting with DiVitas client 2002 via an API 2010 and an API 2012, respectively.
• the application clients in handset 2000 may interact with application servers within an enterprise 2090.
• Enterprise 2090 may include a plurality of application servers including, but are not limited to, a Di Vitas server 2022, a CRM application server 2026, and a mail application server 2028.
• the application servers may be independent of one another or may interact with one another via APIs, ⁇ n an example, application servers 2026 and 2028 may be interacting with OiVitas server 2022 via an API 2030 and an API 2032, respectively Note that the purpose of the APIs is to enable the application to interact with one another. However, since each application is independent of one another, the interaction via the APIs is optional.
• a stockbroker on handset 2000 may be communicating with his client via DiVitas client 2002. While conversing with his client, the stockbroker may want to have his client's portfolio readily available. In this example, the stockbroker may have to establish two different sessions. The stockbroker may establish a first session to enable him to converse with his client via DiVitas client 2002. To bring up the portfolio, the stockbroker may establish a second session by employing CRM application client 2006 to interact with CRM application server 2026, which is located behind a firewall 2040 within an enterprise 2090.
• SSI. secure sockets layer
• VPN virtual private network
• a network administrator may have to establish different configuration.
• two separate secure channels may have to be established.
• a new mail application client has been added to a handset
• the network administrator may have to create a new secure channel.
• a user may have to establish multiple sessions, which may require multiple sign-on and may cause the enterprise to be more susceptible to security risk.
• IP Internet Protocol
• one or more application clients on a handset may interact with application servers via one secure channel by t ⁇ a ⁇ ctsHig through an IP Security Client 2014 and an IP Security Gateway 2030
• To establish the secure channel the usei ma ⁇ first ha ⁇ e to pro ⁇ ⁇ lc authentication data (c g , us»er name, password, etc )
• the user may also be burdened with the responsibility of authenticating each time a different application chent is utilized in other words, each application client raa> he indiv idually eonfiguied to communicate with its eon expanding application sen ei v ia a diffeteni.
• CRM application client 2006 wants to mtetact with application server
• the usei may to first ptmide authentication data Once secuie channel 2084 has been established the usei may then e to provide additional authentication data in oidet to enable CRM application chent 2006 to internet with CRM application sen er 2026
• a new secuie channel and te-authenUeation may have to occur each time a session it * dropped
• tf a user is mobile whrle in a session, the user may encounter a risk of being accidentally dropped from a session if the connection is lost
• a usei may be a risk of being accidentally dropped from a session if the connection is lost.
• the session may be dropped and the user ma> ha ⁇ e to establish another session, such as a cellular connection, for example ⁇ s a result, the user ma ⁇ become burdened with the incoiix enience of establishing a new session and also may become ftustrated with the limited mobmt)
• Fig 21 is a prior art How chart illustrating the method foi enabling an application client to communicate with an application sen ei m an IP Security VPN environment Fig 21 is» discussed in i elation to Fig 20
• step 2102 emaii data tiaffic is sent to the appl ication set ⁇ ei In an tjxaniple.
• mail application client 2008 mav send email data packets to mail application sener 2028 withm ente ⁇ se 2090
• the email data traffic is iecen ed by the IP Sec ⁇ rm Chent 2014. winch may perform a check to deteimine how to ioute Oi e traffic In other words.
• IP Security Client 2014 may analyze each packet to deteimine if the packet is intended for enteipnse 2CKK) IP Security Client 2014 identify the recipient of the packet by analv/nig the IP address and the port number that is located within the packet
• Oo IP Secuntv Client 2014 raav either drop the ttaffic oi rnav dnect the email traffic to a server, which i.s not located inside enteipitse 2090
• How an email tea flic that is not intended fot an application senei within euleip ⁇ se 2090 is handled mav depend upon Client 2014 mav have been confrguied to handle the ⁇ o ⁇ -enferp ⁇ se data teaffic
• IP Secu ⁇ t ⁇ Client 2Oi 4 detei mines that the data Uaffte is intended for an application senei that is located with in entei prise 20 1 X)
• the requirement that each data packet be enciypted in an TP Seeuntv VPN environment mav cause latency issue m a soice communication situation, such as a Voice o ⁇ ei IP (VoIP) telecommunication session
• VoIP Voice o ⁇ ei IP
• voice quality dui ing the voice communication session may be hcvcrel) degraded resulting in a bad voice communication experience ⁇ e g , echo in the background, inaudible conversation etc )
• IP Security Client 2014 ma> then send the encnpted traffic to the intended application seise? along secuie channel 2084 As mentioned abose. a secure channel has to be Ci eated each time a new application is being empio ⁇ eci
• IP Secui it ⁇ Client 2014 ma) send the cncispted traffic thiough network 2050 and firewall 2040 to IP Secuurv Gatevvas 2030 of entci prise 2090
• IP Secu ⁇ iv Gatewav 2010 mav peifoim a check to detennme how to route the Uaffic Similai to IP Sec ⁇ utv Cheat 2014, IP Security Gatevva ⁇ 2030 ma> anal> ⁇ e each packet to deteimme if the packet is intended fot e ⁇ te ⁇ utie 2090
• Secu ⁇ t ⁇ Gateway 2030 may de ⁇ ypt tiie traffic
• W Secutity 2030 may forward the data packet to the appropriate application server
• steps 2102 through 21 i 8 is a continual process and may be performed for each packet that is being sent by an application client.
• IP Security VPN environment is diminished by requiring data traffic to be encrypted resulting in an increase cost in hardware (e.g., handset has to have sufficient CPU processing power) and increased latency.
• the user may become frustrated with the limited mobility that may be provided each time a session is lost and the user has to re-establish the connection and re-authenticate.
• each application to direct its data traffic through a single application (e.g., DiVitas client) and a single server (e g., DiVitas server), daia traffic from a plurality of applications may be sent via a single secure channel without requiring the user to perform multiple authentications.
• session loss may be substantially reduced without sacrificing mobility.
• a mobility architectural arrangement is provided by implementing a DiVitas protocol proxy (DPP),
• DPP DiVitas protocol proxy
• DPP may include a client DPP and a server DPP.
• Ui e handset may include a mobility client (e.g.,
• DiVitas client which may include a client DPP to manage the connectivity between the handset and the mobility server (e.g., DiVitas server ⁇ .
• the mobility server mav include a server DI 5 P to manage the connectivity between the mobility server and the handset.
• the client and server DPP may include a plurality of sub- client/server DPPs for managing different types of protocols (e.g., SIP. SMTP, etc.).
• T ⁇ T an embodiment of the invention, a DPP enables the establishment of a single secure channel from which each application client may interact with its corresponding application server.
• Connectivity information may include establishing a secure channel between the handset and the mobility server via a control protocol, such as SiP (session initiation protocol). Connectivity information may be employed to determine when and how to connect the handset. In addition, connectivity information may also include when to perform a handoff from one network to another network (e.g., from a Wi-Fi network to a cellular network), thereby enabling a seamless transition between different networks.
• SiP session initiation protocol
• connectivity information may also include when to perform a handoff from one network to another network (e.g., from a Wi-Fi network to a cellular network), thereby enabling a seamless transition between different networks.
• Fig. 22 shows, in an embodiment of the invention, a simple block diagram of a mobility architectural arrangement.
• a handset 2202 is interacting with a Di Vitas server 221 S (e.g., mobility server) within an enterprise 2216.
• Di Vitas server 221 S e.g., mobility server
• Handset 2202 may include a Di Vitas client 2204 (e.g., mobility client) and a plurality of application clients (2206 and 2208)
• DiVi tas client 2204 may include a client DPP to manage the connectivity between the handset and the mobility server
• application client 2206 and application client 2208 are not configured to directly interact with their corresponding application servers (2220 and 2222), Instead, the various different configurations for each of the application clients may be simplified, in an embodiment, to direct all data traffic to a single local IP host 2210 (e.g., IF address of 127.0,0.1 ) that is associated with DiVi tas client 2204.
• a single local IP host 2210 e.g., IF address of 127.0,0.1
• DiVitas server 221 S may include a server DPP to manage the connectivity between the handset and the mobility server.
• DiVitas server 2218 may then route the traffic appropriately to the corresponding application server (2220 and 2222) via an API (2232 and 2234).
• the DDX refeis to a protocol tbi transpoiting data packets between a handset and a sen ei
• the DDX add a new tag which add mfoimation about the application client that is sending the data traffic
• Di Vitas sener 2218 ma> employ the DDX tag to ret ⁇ ie ⁇ e the location of the application server
• the DDX tag rnav include an identification n ⁇ mbei (e g , MAC address, port address), which mav indicate which application ser ⁇ c ⁇ (e g , application ses ⁇ et 2220) within the entetp ⁇ sc is the intended recipient of the data packet
• a mobiht> architectuial arrangement mav manage the connectivity between the handset and the mobility .server
• the mobihtv architectural arrangement may employ a control protocol that LS common!) utilized bv a handset, such as SlP foi example
• the mobility architectural arrangement may also include a database, which may include authentication data for each application client
• the mobility architectural arrangement may utilizes the authentication data that is specific to the application, which may be stored m the database, to automatically authenticate the user. From the perspective of the user, the mobility architectural arrangement is essentially a single sign-on environment.
• the mobility architectural arrangement substantially streamlines the time and effort a network administrator may have to spend in configuring each application client.
• the network administrator may substantially eliminate this process by just configuring each of the application clients to interact with a local host. Further, with a single sign-on, the network administrator may be able to substantially reduce the time and cost associated with managing security.
• the mobility architectural arrangement may be implemented as a rich or thin client.
• Fig. 23 shows, in an embodiment of the invention, a block diagram illustrating the mobility architectural arrangement, as a rich client.
• a rich client refers to a mobility architectural arrangement in which the client DPP and server DPP not only manage the various different applications but may also provide support for at least one or more application client functionality (e.g.. a voice application client, an instant messaging application client, email application client, etc. ⁇ .
• a mail application client 2310 e.g., Microsoft® Outlook, etc.
• a mail application server 2326 e.g., Microsoft® Exchange Server, etc.
• Fig. 23 will be discussed in conjunction with Fig. 24.
• Fig. 24 shows, in an embodiment of the invention, a simple flow chart illustrating an example of a method for employing a mobility archi tectural arrangement.
• application client may send data traffic to a local host of a Di Vitas client.
• application client 2310 has been configured to route its data traffic through a local host 2308, which is located within a Di Vitas client 2304.
• application client 2310 may send an SMTP (simple mail transfer protocol) data packet 23 ! 2 over TCP-IP to DiVitas client 2304.
• SMTP data packet 2312 may be received by au SMTP proxy client 2306 (e.g , sub-client DPP), which is located atDi.Vi.tas client 2304.
• a client DPP may include a plurality of sub-client DPPs.
• the data packet may include a port number, which is unique to an application client, ⁇ n an example, SM TP data packet 2312 includes the following data ⁇ ••• 127.0,0.1/25. in this example, the number 127.0.0.1 is an ⁇ P address, which is specific to local host 2308 and the number 25 refers to a port number, which in this example is associated with SMTP proxy client 2306.
• the data traffic may be encapsulated as a SlP Notify Message with a DDX tag.
• DiVitas client 2304 may reformat SMTP data packet 23] 2 into a SJP data packet 2330 (such as a SIP Notify Message) that is transferable over the handset's control protocol such as STP.
• SIP data packet 2330 may include the original data packet (e.g., data packet 2312) with a DDX header 2330a and a SlP header 2330b.
• the ODX header may include a unique identification number that is unique to an application server, In an embodiment of the invention, the unique identification number may be generated based on the port number that was included in the SMTP data packet. In an embodiment of the invention, an additional tag may be included in the formatted data packet to identify how the formatted data packet may be transported, In an example, transport protocol tag 2330c may be a UDP-IP transport tag.
• one or more parts of SIP data packet 2330 may be encrypted, In an embodiment, the DDX part is encrypted even if the rest of the data packet is not.
• the DiVitas client may send the data packet to the DiVitas server.
• SiP data packet 2330 may be sent via a secure channel 2350 through a network 2314 and/or a firewall 2316 to a Di Vitas server 2320.
• the DiVitas server may check to determine if the incoming data packet is a SiP Notify Message. If the incoming data packet is not a Sip Notify Message, then at a next step 2410, the data packet may be dropped.
• the DiVitas server may identify the intended proxy server by checking the DDX tag. In an embodiment, the DiVitas server may have to decrypt the DDX packet in order to read the information stored m the DDX packet. In an example, based on the unique identification number in the DDX tag., DiVitas server 2320 knows to route data packet 2330 to SMTP proxy server 2322.
• a server DPP may include a plurality of sub-server DPPs In an embodiment of the invention, the type of proxy server that may handle the incoming traffic may depend upon the type of data traffic,
• the data packet may be routed to the proxy server. Since S ⁇ P data packet 2330 is an SMlT data packet, formatted data packet is handled by SMTP proxy server 2322 (e.g., sub-server DPP), which is located inside Di Vitas server 2320.
• SMTP proxy server 2322 e.g., sub-server DPP
• SMTP proxy server 2322 may convert SIP data packet 2330 into a format that is acceptable by the receiving application server.
• SiP data packet 2330 may be converted from a SIP notify message into an SMTP data packet 2328.
• the DDX part may be dropped
• the transport protocol may be changed from UDP-IP to TCP-IP, which may be better employed to deploy email data traffic to the respective application server (e.g., mail application server 2326) via API 2332.
• the method steps described in Fig. 24 does not show the encryption and/or decryption of a data packet.
• the data packet may be sent without being encrypted
• the requirement for encryption may be optional and may depend upon the user's requirement.
• part or the entire data packet may be encrypted.
• the DDX part may be encrypted but the rest of the data packet may remain unencrypted.
• the optional encryption enables less processing power to be utilized and a decrease in latency that is usually associated with encrypted data packets.
• the rich mobility architectural arrangement may act as a mobility manager enabling application clients of a handset to interact with application servers within a single sign-on environment. Further, the rich mobility architectural arrangement may include functionality for converting data packets from a variety of applications into data packets that are capable of being transported by the control protocol and transport protocol that is specific to the secure channel that has been established,
• the mobility architectural arrangement may be implemented as a thin client, as shown in Fig. 25
• the client DPP and the server DPP may be employed only as mobility managers ⁇ e.g., manage the connectivity for the applications) and may not provide support for at least one or more application functionalities.
• a user of a handset 2500 wants to call a f ⁇ end.
• the user may employ a telephone application client 2508 (e.g., VoIP, etc.) to make his telephone call.
• a secure channel 2550 has already been established between a DiVitas client 2502 and a Di Vitas server 251 S, which is located within enterprise 2530.
• telephone application client 2508 may send a data packet 2512 (e.g., S ⁇ P/UD-IP) to a local host 2510 within DiVitas client 2502.
• a data packet 2512 e.g., S ⁇ P/UD-IP
• a plurality of proxy clients may reside within DiVitas client 2502 to support the various different application clients,
• a SlP proxy client 2504 may be located within DiVitas client 2502 to handle data packets from telephone application client 2508.
• SlP proxy client 2504 may analyze the data packet to determine how to route the packet.
• the date packet that may be sent to a DiVitas client may include a port number (e.g.. 5060, etc.) that may be unique to an application server.
• DiVitas client 2502 may route data packet 2512 through network 2514 and firewall 2528 to DiVitas server 2518,
• a data packet does not have to be converted if the data packet is already in a format that is mutable by a DiVitas client.
• data packet 2512 is in a SfP/UDP- ⁇ P format, which is the format that OiVitas client 2502 may employ to route its data traffic.
• a plurality of proxy server may reside within a DiVitas server.
• a STP proxy server 2532 may reside within DiVitas server 2518 to manage the incoming data traffic from telephone application client 2508. Since data packet 2512 has been sent from telephone application client 2508, the data packet is handled by SIP proxy server 2532.
• SiP proxy server 2532 may forward data packet 2512 along a path 2522 to a destination telecommunication device (e.g., telephone, etc.) via a telephone gateway 2520 (e.g.. PSTN, GSM, CDMA, etc.).
• a destination telecommunication device e.g., telephone, etc.
• a telephone gateway 2520 e.g. PSTN, GSM, CDMA, etc.
• the other data packets 2530 (e.g., RTP data packets, etc.) that may be sent by telephone application client may be sent along path 2560 through secure channel 2550 to DiVitas server 2518 without having to go through DiVitas client 2502.
• the purpose of establishing a telecommunication session with the aid of a DtVitas client is to enable the application client to fake advantage of the mobility functionality of the DiVitas client.
• a control center lias been established between the DiVitas client and the Di Vitas server to monitor the connectivity of the application client.
• the DiVitas client and the Di Vitas server may be able to share its connectivity status and be able to seamlessly handle roaming when the situation arises.
• the user in the above situation is currently connected through a Wi-Fi network.
• the user may roam outside of the Wi-Fi network.
• the connection may be dropped and the user may have to rediai.
• the connectivity status of the user's handset has been monitored and the DiVitas cheat and DiVitas server may perform a seamless network switch (e.g , from Wi-Fi to a cellular network) without the user being aware of the change.
• a thin mobility' architectural arrangement may be implemented by an enterprise that may have already invested a large sum of money into a plurality of application and may only need a mobility manager.
• the enterprise may be able to take advantage of the mobility manager capability of the mobility architectural arrangement without having to restructure tts telecommunication infrastructure
• the mobility architectural arrangement with DPP provides a mobility manager capable of streamlining the telecommunication infrastructure
• the mobility architectural arrangement provides a single sign-on environment.
• the same functionality may be achieved with a single secure channel.
• the cost and effort of managing the telecommunication infrastructure may be substantially reduced.
• the mobility architectural arrangement enables connectivity to be monitored and seamlessly handled without negatively impacting the user's telecommunication experience.

Landscapes

• Engineering & Computer Science (AREA)
• Signal Processing (AREA)
• Computer Security & Cryptography (AREA)
• Computer Networks & Wireless Communication (AREA)
• Computer Hardware Design (AREA)
• Computing Systems (AREA)
• General Engineering & Computer Science (AREA)
• Mobile Radio Communication Systems (AREA)
• Telephonic Communication Services (AREA)

Applications Claiming Priority (13)

Publications (1)

Family

ID=42312713

Family Applications (1)

Country Status (2)

Families Citing this family (1)

Family Cites Families (6)

• 2007
  • 2007-06-14 EP EP07798546A patent/EP2033408A2/de not_active Withdrawn
  • 2007-06-14 WO PCT/US2007/071186 patent/WO2007147037A2/en not_active Ceased

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events