Enhancing user experience during handoffs in wireless communication

Method and system for enhancing user experience when changing hands in wireless communication

The present invention relates to a method and system for enhancing user experience when changing hands in wireless communication.

Conventional mobile communication platforms include cellular communication, such as Global Mobile Communication System (GSM). Other conventional platforms that support limited mobility include Wi-Fi based on the IEEE 802.11 standard. These are well-known and established platforms.

The next-generation platform is designed to allow mobile users to move between cellular and Wi-Fi networks, and includes the Unauthorized Mobile Access (UMA) standard that provides carrier switching controllers to allow users to move between cellular and Wi-Fi networks. Passing between Wi-Fi networks, and vice versa. However, the UMA standard has disadvantages, including carrier-controlled phones and determining whether and when users exchange between networks.

What is needed is an advanced mobile communication platform that provides users with enterprise-level communication and control, and their choice of networks based on enterprise-driven criteria rather than carrier-driven criteria.

In one embodiment, the invention relates to a method for performing handover of a mobile device from a first radio station to a second radio station. The method includes buffering a first set of media data received via a first radio station. The method further includes, if the second media data group is received via the second radio station, cross-correlating the tail part of the first media data group and the header part of the second media data group to generate a cross-related media data group . The method additionally includes outputting the associated media data set if the associated media data set is generated. The method further includes using the modeled part of the first media data group to synthesize a composite media data group if the media data is not received by the second radio station within the threshold. The criticality includes at least one of time criticality and data volume criticality. The method additionally includes outputting the synthesized media data set if a synthesized media data set is synthesized. The method further includes extending at least a part of the first media data set to generate an extended media data set if the media data is not received by the second radio station within the threshold. The method additionally includes outputting the extended media data set if the extended media data set is generated.

In one or more embodiments, the present invention relates to a system for performing handover of mobile devices from a first radio station to a second radio station. The system includes a buffer configured to buffer a first set of media data received via a first radio station. The system further includes a cross-correlation module, which is configured to make the tail part of the first media data group and the information of the second media data group if the second media data group is received via the second radio station. The first part is cross-linked to generate a cross-linked set of media data. The system additionally includes a synthesizer module, the synthesizer module is configured to use the modeled part of the first media data group to synthesize a synthetic media data group if the media data is not received by the second radio station within the limit . The criticality includes at least one of time criticality and data volume criticality. The system further includes an extension module configured to extend at least a part of the first media data set to generate an extended media data set if the media data is not received by the second radio station within a critical range.

These and other features of the present invention will be described in detail below along with the accompanying drawings and a detailed description of the present invention.

content

A. Architecture B. Enhance the user experience of media handover C. Use manager and user control rules and preferences (conference calls) to automatically establish point-to-point and point-to-multipoint multimedia conference calls D. Call routing through receiving authentication E .Reduce the data loss of media delivery.F.Select the network stacking function in the hardware for the media stream processing and distribution system.G.Secure media communication between enterprise gateways (NAT/firmware).H.Conclusion

The invention is described with reference to specific devices and embodiments. Those skilled in the art should understand that the description is only used to illustrate and provide the best mode for implementing the present invention. For example, although referring to a specific communication protocol, the present invention can also consider other protocols. For example, although Wi-Fi (IEEE 802.11) is described as a protocol for wireless communication, the present invention can also implement other protocols. The mobile user, user device, and mobile equipment (ME) mentioned in this article are the same.

Various embodiments, including methods and techniques, will be described below in this article. It should be understood that the present invention also covers manufactured objects, including computer-readable media storing computer-readable instructions for implementing embodiments of the technology of the present invention. The computer-readable medium may include, for example, a semiconductor, magnetic, opto-magnetic, optical, or other type of computer-readable medium for storing computer-readable codes. In addition, the present invention also covers devices for implementing the embodiments of the present invention. Such devices may include dedicated and/or programmable circuits for performing operations related to the embodiments of the present invention. Examples of such devices include universal computers and/or dedicated computing devices when properly programmed, and may include computers/computing devices and dedicated/programmable circuits for various operations related to the embodiments of the present invention The combination.

A. Architecture

FIG. 1 illustrates a system network 100 according to an embodiment of the present invention. A mobile device (ME) 102 that uses some possible ways to communicate with the network is provided. The ME 102 can communicate with a cellular network 110 including a base transceiver station (BTS) 112, a BTS switching center (BSC) 114, and a mobile switching center (MSC) 116. The MSC is coupled to the media gateway 120, and the media gateway 120 is coupled to the public switched telephone network (PSTN) 122. Other conventional public and private telephones 124 are also coupled to the PSTN. The PBX 130 is coupled to the PSTN, and makes and receives calls for the enterprise via the telephone 136, for example. The mobile server 150 is coupled to the PBX and other networks. For example, the mobile server 150 is coupled to the Internet Protocol Wide Area Network (WAN) 138 via the router 132. The mobile server 150 is coupled to the Internet 144 via the router 140 and the firewall 142. The mobile server uses the wireless access point 160 to couple to a local area network (LAN). Although only one access point is drawn, the present invention can also consider multiple access points. Access point 160 allows users with ME 102 to roam in the enterprise, and via mobile server 150 and PBX 130 remains connected to PSTN. If the user is roaming outside the boundary of the LAN, connect the user to another network (e.g., a cellular network) as described in detail below. In addition, only one access point 180 is drawn, and the access point 180 is coupled to the Internet for access under the following conditions.

2A-C illustrate a mobile server according to an embodiment of the invention.

Security Manager-When two or more entities are communicating, the security definition includes the following types: 1. Mutual authentication of communicating entities 2. Privacy of communication channels 3. Integrity of exchanged messages 4. Identification of messages

In the mobile solution according to one or more embodiments of the present invention, there are three clear communication entities: mobile users, mobile servers, and external VoIP GWs. Moreover, there are two clear path types between these entities: SIP signaling path and media path.

As explained in the architecture specification [1], the following mechanisms are used to achieve the above-mentioned security mode between the user, server, and external gateway and data path for sending messages: 1. SIP between the user and the server TLS conversation layer 2. Use SIP notification for user authentication after SIP TLS is established 3. Use server to authenticate users 4. SIP TLS conversation layer between server and external VoIP gateway 5. Use external VoIP gateway to authenticate server 6. Secure media path 7. Export requirements

User/Device Manager/Mobility Controller-Device and Mobility Manager (called DMM) are modules that have ongoing calls on the device that simultaneously process device configuration and status and mobility forms. The following sections capture the functions and design specifications of the DMM along with the public interface it supports.

1. Here is a summary of the roles and tasks of the DMM 2. The device configuration controlled by the enterprise administrator 3. Reporting the status of the device 4. The image management of the device 5. Maintaining and implementing actions for the handset with the phone in progress Sexual logic-that is to handle the handover from Wi-Fi to cellular and vice versa.

Handle device initialization and configuration requests from users.

Control Plane/Phone Control-Phone Control (CC) is the main control plane module responsible for the following functions: 1. Internet phone processing 2. SIP proxy server and B2BUA 3. PSTN phone management via PSTN GWs 4. Via Asterisk PBX feature management 5. Resource and connection management

The telephone control module resides on the DN media switch. It interfaces with SIP stack and Asterisk (or any other) PBX to provide the aforementioned functions.

1. SIP stack (used in UA, CCM, and Asterisk, etc.): SIP stack is mainly used as a protocol message decoding/encoding engine. The SIP stack performs basic protocol-specific work. Such as standard-based message analysis and confirmation, forwarding, and ownership message confirmation. As far as most agent and B2BUA work is concerned, SIP stacking relies on the CC used to make decisions. The interaction between CC and Asterisk and CC and CCM is through standard-based SIP messages.

2. Agent/Configuration Manager (PA/CM): The agent acts as a configuration manager for all applications. After reading the disc DB at the time of supply or after the system is started, the PA downloads the telephone control related information. CC stores data in RAM for local/faster access. CC also updates any dynamic information PA (for example, call in progress or hang up), or on-demand information (for example, SNMP GET).

3. Resource Manager (RM): Resource Manager provides logical mapping of physical/network resources. These resources include GE ports, DSP resources, sockets, UDP/TCP ports, etc., but do not include system resources such as memory, data buffers, timers, and queues. It also does not include sockets for internal IPC communication. CC uses RM for resource CAC, resource reservation, and submission. RM tells the media switch to design the hardware program to enable the media to progress.

Media Exchange Application (MSA)-MSA will be designed to be partially executed on Linux, and the rest will be on the TMS320DM64x DSP processor. The application will perform the following functions: RTP packet processing.

exchange.

Code conversion.

Meeting.

Suitable jitter buffer.

The packet loss is hidden.

Including VAD/CNG and AGC mail processing.

MSA software needs to support encoding/decoding of codes at different speeds. The type of algorithm and channel can be changed during execution, that is, it needs to support multi-channel and multi-algorithm design. Each encoder/decoder algorithm needs to be reentrant, and the program and data needs to be fully released. In order to support various encoders/decoders, the following needs to be considered: a. Because DSP has limited the on-chip data memory, it is not possible to place all data on the chip at all times in multi-channel and multi-algorithm applications. . This requires that all data (text and tables) in each algorithm during the text exchange can be relocated (between on-chip/off-chip memory). This requires finding out the memory, stack size, and MIPS requirements for each supported codec/decoder.

b. The mechanism for exchanging messages between the host and the DSP processing that represents the number of channels along with any other features and the type of encoder/decoder. The channel configuration manager needs to open the channel on the DSP that represents the required function type. Need to implement periodic messages that indicate the status of the DSP.

The DSP processor enables the external host to access the DSP external memory. DSP has 16K bytes of first-level program and data memory. Program and data memory share 256K bytes of second-level memory. 16M bytes of external memory (SDRAM) can be used. The shared memory between the two processors stores incoming and outgoing RTP data. Because the DSP needs to support N number of channels, this memory will contain N reception and transmission buffers each with a length of 320 bytes (for video, these buffers need to be 1500 bytes). The data structure for the message between the host and the DSP and the required information on a per-phone basis need to be defined. The following steps define the DSP function: a. Once the software is downloaded to the DSP, turn it on (the DSP points out the same by writing a predetermined value in a fixed memory location to indicate the host that downloads the software).

b. When the software is successfully downloaded, the DSP will execute an internal timer of 10msec.

At this time, the DSP will poll the channel status to change to the process established by the host once the packet arrives.

c. Start the call or open the channel command from the host that indicates the type of codec/decoder, and send the RX and TX direction data and the type of phone (initially only voice).

d. According to the opened channel, the DSP obtains the RTP data from the external buffer, and performs DSP related functions here.

e. On the TX side, the DSP places the encoded data on the external buffer to be picked up by the TX agent.

Figure 3 illustrates a mobile device user according to an embodiment of the present invention.

Run user software or phone handset software on a handset compatible with the mobile server. Typically, these are dual-mode telephone handsets with the ability to provide telephone connections on cellular networks (CDMA or GSM) and IP connections on LAN networks (wired LAN or wireless LAN).

It can also compile software for desktop/laptop or PDAs with microphones or speakers used as softphones.

User interface The user interface provides the following functions:. Create boot configuration-DSN IP address, mobile server URL, boot user status (INVIBILE/AVAILABLE), security settings. Change user status (INVIBILE/AVAILABLE). Add company "good friends" and get their attendance information (INVIBILE/AVAILABLE/CAII-IN-PROGRESS). Show the availability status of the company's "good friends" and connect to them. User interface to general corporate phone features. Call up. Answer the phone. Waiting. Forward the call. Forward the phone. Multi-party meetings. Voice mail notification. Notification of missed calls. Notification of received calls. Location phone notification. Number lookup and call by name. Manual cancellation to replace Wi-Fi network with cellular network. The display version is misplaced. Upgrade request/status. Cancel/Prohibit User Software-ISP application software is used to perform/receive cellular phone call control and voice. Perform telephone control of VoIP phones on the LAN interface. The voice engine for VoIP calls on the LAN interface-including encoder/decoder, echo cancellation, tremor control, and error concealment. From cellular phone to VoIP phone handover. Handover from VoIP to cellular phone. 802.11. Decide which IP networks are available and their signal strength and pass that information to the server. AP users. Power management of 802.11 miniport-Whenever the signal strength of 802.11 is lower than the acceptable threshold, put it to sleep and poll at rare intervals to save power. If the call is in progress or the call is not in progress but the communication to the server is maintained, the signal strength and voice quality information are packaged into RTCP packets. Whenever the signal strength drops below the acceptable threshold or the voice quality degrades, the server will decide to switch the phone from VoIP to a cellular network.

Platform Because there are many phone receivers on the market and many of them provide dual-mode phone receivers, the software must be designed in a way that most of the codes are shared between the phone receivers. Therefore, the code must be divided into a platform-dependent part and a platform-independent part. Most, in fact, all Divitas core values should be in a platform-independent part of the software that is easy to carry from one platform to another. The platform-dependent part should only be the function adaptation layer (especially the Telephony, LAN, 802.11, Audio and Display adaptation layer). Whenever the code is transferred to a new platform, while providing a unified API to the independent parts of the platform, only these adaptation layers must be revised and rewritten.

User software will be executed on multiple phone handset platforms. The most common phone handset platform is Windows<img file="TW200733763A_D0001.tif" />CE, Linux<img file="TW200733763A_D0002.tif" />, And Symbian<img file="TW200733763A_D0003.tif" />。

In addition to dual-mode phone handsets, user applications are designed to operate on 802.11 phones, PDAs, or laptop/desktop models that do not have a cellular phone interface. On these platforms, a subset of features are available to users. Basically, from VoIP to cellular telephone handover is impossible.

Theory of operation Boot and safe operation When booting, the user should look for available resources on the telephone receiver. First check the existence of the wired network. If it does not exist, check the existence of the 802.11 network. Wired or wireless media authentication should be carried out in accordance with corporate security policies. The user of the telephone receiver should support the security agency used by the enterprise. The most common security mechanism is WPA (Wi-Fi Protected Access). Once successfully authenticated, the wireless user obtains an IP address for the IP interface using DHCP.

The application obtains the mobile server URL and DNSIP address from the persistent database and attempts to register with the mobile server.

The user application should be operated on the telephone receiver inside the corporate network. At that time, the user can reach the mobile server without any other security coverage. In an example where the user is accessing a public network such as a coffee shop or airport with a Wi-Fi Internet deposit, the user typically establishes a VPN connection to the enterprise. Only after the VPN tunnel is established, the user can reach the mobile server.

The user application software authenticates the handset and the server by sending an encrypted digital visa (installed by the corporate IT) to the server. Once authenticated, the user obtains the login/password from the user or stored in the phone handset, encrypts it and sends it to the server for user authentication. Upon successful authentication, the server responds by sending the company phone number. In response, the user sends a cellular phone number to the server. The server combines the two for all further handover solutions.

Use SIP/TLS for sending and SRTP for media streaming to ensure the security of sending and media streaming. However, if the user is on a VPN connection, the user does not need to add other encryption. Adding other encryption to those that may produce degraded voice quality. At that time, SIP was used for sending and RTP/RTCP for media streaming.

Each time the user obtains connectivity with the server again, the above process is repeated.

The stable state operation is configured on the GUI and stored in the persistent database. The user can choose to be INVIBILE or AVAILABLE at boot time. Whether it is INVISUBLE, AVAILABLE, or CALL-IN-PROGRESSS, users get the presence information of these friends (in huge amounts). When an event occurs, the server updates the presence information of these friends to the user.

Whenever the call is not in progress, the user and the server periodically exchange to keep alive.

The user periodically sends the network status to the server. If it is on an 802.11 wireless network, send the SSID, signal strength and bandwidth of the relevant access point (AP) to the server. If the call is in progress, it is sent as part of the in-band RTCP packet. If no call is in progress, send it in the out-of-band keep-alive message.

Whenever the network period is available from the user to the server, the best way to make and receive calls to the user is on the network interface. However, this option does not communicate to the server and does not affect incoming calls. This selection is also not stored in the persistent database. The user must make a clear choice every time an outgoing call is made.

Whenever the Internet cannot be used from the user to the server, the only way to make and receive calls is through the cellular interface. The user does not have access to all corporate features. Does Wurun user software only provide a subset of service provider features? Users can use the user software UI to make and receive calls. For all the features of the cellular service provider network, the user must terminate (or prohibit) the user software and use the cellular service provider dialer application. If the service provider application is used to make and receive calls, the handover described in Section 3.4.2 below will not be possible.

As long as the user has a session established to the server, the user has access to all corporate features. The user GUI is used to provide users with access to these enterprise features.

Voice SIP messaging is used to establish a voice call between the user and the server. The voice from the audio receiver is encoded into one of the codecs/decoders supported by the voice engine (VE), compressed into RTP packets, encrypted if necessary, and sent to the server on the IP interface. Similarly, the RTP packet received from the server is decrypted if necessary, decoded using one of the encoders/decoders, and broadcast. Speech decoding, tremor control, and error concealment are performed by the VE on the receiving side.

In addition to encryption/decryption and speech encoding/decoding, the voice engine performs error concealment, tremor control, appropriate packet buffering, sound echo cancellation and suppression, noise concealment and suppression, automatic gain control, voice activity detection, and command People are comfortable noise.

Roaming phone handset users are mobile devices, not like portable laptop computers.

Handover in WLAN When the user is in an 802.11 network with telephone conversation and talking across buildings, AP handover may occur, that is, the user's phone handset is now connected to an AP that is different from the previous one. . In the example of changing the IP address of the telephone receiver, if the handover is within the same subnet or to another subnet, then AP handover may occur without the need for an IP address change. If the IP address changes, the user needs to register with the server again. The phone established while using the old mobile information continues to flow until the voice engine (VE) exchanges the new IP address. The speech engine determines that the RTP stream from the user will have a new IP address when it gets the event.

When a wireless user uses 802.1X authentication, a series of messages are sent between the wireless user and the wireless access point (AP) to exchange certificates. This exchange of messages causes delays in connection processing. When a wireless user roams from one wireless AP to another wireless AP, the delay in performing 802.1X authentication may cause a significant interruption of network connectivity, especially for time-dependent traffic, such as voice or voice-based data streams. . To minimize the delay associated with roaming to another wireless AP, the wireless device can support PMK caching and pre-authentication.

PMK cache When a wireless user roams from one wireless AP to another wireless AP, it must be authenticated with the complete 802.1X of each wireless AP. WPA enables wireless users and wireless APs to cache the results of complete 802.1X authentication, so that if the user roams back to the previously authenticated wireless AP, the wireless user only needs to perform a four-way handshake and determine a new pairing transient key. In the related request box, the wireless user includes the PMK identification symbol determined during the initial authentication and stored in the PMK cache entry of the wireless user and the wireless AP. When combined with wireless users and wireless APs, PMK cache entries are stored for a limited amount of time.

In order to make the transformation of wireless network infrastructure using switches acting as 802.1X discriminators faster, WPA/WPS IE Update calculates the value of PMK identification symbols so that when roaming between wireless APs attached to the same switch , It is possible to reuse the PMK determined by the 802.1X authentication of the switch. This implementation is considered a speculative PMK cache.

Pre-authentication uses pre-authentication. While connecting to its current wireless AP, WPA wireless users can arbitrarily perform 802.1X authentication with other wireless APs within its range. Wireless users send pre-authenticated traffic to additional wireless APs via their existing wireless connections. After authenticating with the wireless AP and storing PMK and its related information in the PMK cache, wireless users connected to the pre-authenticated wireless AP only need to perform a four-way handshake.

WPA users who support pre-authentication can only pre-authenticate with wireless APs that declare their capabilities in the Beacon and Probe Response boxes.

Wi-Fi-Cellular Handover When a user in an 802.11 network with telephone conversations speaks outside a building with no or insufficient 802.11 connectivity, the call is handed over to the cellular network.

The user decides to hand over the phone. The decision is based on 802.11 signal strength, channel load, and voice quality criticality. Once the decision is made, the initiating call is notified to the user's server on the cellular network. The user checks the caller id of the incoming call, compares the 802.11 caller id, and if there is a match, receives the cellular call and drops the 802.11 call process. On the server side, the server lowers the 802.11 phone process to the user, and repairs the cellular phone process to the other talking party.

Cellular-Wi-Fi Handover When a user who has a telephone conversation on a cellular network speaks to the 802.11 network, and the handset/user can integrate himself with the mobile server, if the user is connected to the 802.11 network Another user on the road talks and hands the phone to the 802.11 network.

The user decides to hand over the phone. The decision is based on the availability of sufficient 802.11 signal strength, channel load, and voice quality. Once the decision is made, the initiating call is notified to the user's server on the 802.11 network. The user checks the caller id of the incoming call, compares the 802.11 caller id, and if there is a match, receives the cellular call and drops the 802.11 call process. The server drops the 802.11 phone process to the user, and repairs the cellular phone process to the other talking party.

Power saving When the user of the phone handset is idle on the 802.11 network, the 802.11 mini port goes to sleep. Before going to sleep, it informs the AP that it wants to go to sleep by setting the power saving bit in the 802.11 header of each frame. The AP receives the box and informs the user of the desire to enter the power saving mode. While the user's 802.11 mini port is asleep, the AP begins to buffer packets for the user. The mini port consumes very little power when sleeping. It wakes up periodically to receive regular distress transmissions from the access point. The power saving user needs to wake up at the correct time when the distress is transmitted to receive the distress. TSF (Timing Synchronization Function) ensures synchronization between AP and power saving users. When the base station is asleep, the TSF timer keeps operating. These distress calls identify whether the sleeping base stations have packets buffered in the AP and are waiting to be delivered to their respective destinations.

When there is no incoming call for help for an extended period of time, the 802.11 miniport goes to sleep. The miniport wakes up periodically to detect air for APs, and if nothing is present, it goes back to sleep. At this time, you will sleep for a longer duration than the last time.

The features and advantages of the present invention can be better understood by referring to the drawings and careful and complicated discussion. The hope of staying connected has enabled various telecommunications services (e.g., cellular services, Wi-Fi services, VoIP services, landline services, etc.) and devices (e.g., mobile phones, multi-mode phones, desktop phones, IP phones, etc.) ) Surge. Generally, in order to provide their employees with flexibility and mobility, companies have implemented a combination of these telecommunication services and devices to promote business and handle daily activities.

In a typical enterprise, employees have desktop phones with associated extension numbers, which are connected to the public switched telephone network (PSTN) through the enterprise's private branch exchange (PBX). Furthermore, some employees may also have cellular phones, which can perform voice and/or data communications via cellular networks such as GSM, CDMA, or UMTS networks. In addition, some employees can use IP phones, which can connect to the Internet via a wireless local area network (such as a wireless LAN based on one or more IEEE 802.11 standards) to perform voice and/or data communications. In addition, some employees may also have multi-mode phones that can perform voice and/or data communication via two or more communication networks. In one example, a multi-mode phone may have the ability to connect via both a cellular network and the Internet (through wireless access points).

Enterprises can implement this type of multi-network configuration when trying to increase their influence with employees, which facilitates communication with internal and third parties. Unfortunately, the differences and even incompatibility between different networks and devices cause new problems for enterprises.

Imagine, for example, a situation where a company employee might leave his desktop phone. In this way, the employee cannot be reached via his desktop phone extension number, and incoming calls are routed to his voice mailbox. As a result, the caller can choose to leave a message in the employee's voice mailbox, redial the phone number later, and/or try to find the employee on another number. Failure to contact the employee may cause great inconvenience to the caller, lead to unsatisfactory telephone experience, and even cause business losses to the enterprise.

In an attempt to solve difficult-to-reach problems, companies can implement multiple network configurations. In the implementation of a multi-network configuration, employees with desktop phone extension numbers can have the option of forwarding incoming calls to a specific phone number. In this way, even if the incoming call can be a call forwarded to a multi-mode phone associated with a multi-network service, the incoming call can only be a call forwarded via a specific network specified by a specific phone number provided. Such modules cannot be quantified for large deployments. In the example, if a specific phone number is associated with a cellular phone number, even if a less expensive Wi-Fi network is available, call forwarding will still be performed via the cellular network. Similarly, if a specific phone number is connected to a Wi-Fi phone number, the call will be forwarded via the Wi-Fi network. However, if the Wi-Fi network is not available or the employee is not currently connected to the Wi-Fi network, the employee may still not be reachable. In this way, even if more expensive cellular phones can be used, incoming calls forwarded to Wi-Fi phone numbers still cannot enjoy the advantages of cellular networks.

In addition to call forwarding, companies can also incorporate next-generation mobile communications standards that enable multi-mode phone users to move between cellular and Wi-Fi networks. The standards include the Unauthorized Mobile Access (UMA) standard, which specifies the exchange control plan for the carrier of the cellular network, so that multi-mode phone users can roam between cellular and Wi-Fi networks .

Generally, the implementation of equipment based on UMA standards (such as network equipment and multi-mode phones) can vary greatly from one vendor to another. In this way, the UMA server operated by the carrier is compatible with a limited set of device branches and/or modules. As a result, companies implementing UMA solutions provided by carriers face limited options for selective network equipment and multi-mode phones. In addition, changing the flexibility of the carrier now depends on the willingness of enterprises to spend additional resources to purchase new equipment (such as network equipment and multi-mode phones). Voice operation control only in the carrier space is not ideal for enterprises.

Because the carrier provides UMA solutions, companies must rely on the carrier of the cellular network to manage cellular phone usage, and have little or no direct control over related policies, services, usage, security, and/or privacy. In one example, the carrier controls the phone call and decides if and when switching between networks takes place. In this way, even if the user has access to the Wi-Fi network, the enterprise still cannot use the more expensive cellular service to the less expensive Wi-Fi service.

According to an embodiment of the present invention, a wireless communication system solution implemented by an enterprise is provided. According to an aspect of the present invention, the inventor here understands that although different solutions can meet the communication needs of enterprises, no enterprise still retains an integrated approach to control of its telecommunications solutions. The embodiments of the present invention enable the wireless communication system to provide an integrated solution by including a mobile server internally managed by an enterprise and mobile users interacting with the mobile server.

In this document, the voice and communication request/talk layer is used as an example to discuss various implementations. However, the present invention is not limited to the voice communication request/talk layer, and can be used in the communication request/talk layer related to instant media transfer. Examples of real-time media may include telephone calls, immediate messages, emails, voice telegrams, etc., but are not limited to these.

As discussed herein, a mobile server refers to a computer system that can manage and/or control both incoming and outgoing media traffic through an enterprise. In the embodiment of the present invention, the mobile server can be connected to a plurality of networks. Multiple networks can be implemented according to different communication standards, and can include wireless local area networks (wireless LANs) managed by enterprises. The plural network can be additionally expanded to include one or more cellular networks operated by a carrier and wireless LANs managed by a third party. In addition, the mobile server can be independent of the hardware platform implemented by the plural network.

In the embodiment of the present invention, the mobile server can interact with mobile users configured to operate in a plurality of networks. As discussed in this article, mobile users refer to electronic communication devices that include mobile user software. Pad communication devices (eg, mobile phones, multi-mode phones, desktop phones, IP phones, etc.) can be different branches and/or modules. In an embodiment, the mobile user may be a multi-mode electrical communication device capable of operating on multiple networks.

In the embodiment, the wireless communication system can also work with a single-mode electrical communication device. For a single-mode electrical communication device, the electrical communication device may have mobile user software downloaded to the electrical communication device, so that the mobile-enabled electrical communication device can interact with the mobile server. In other words, even if single-mode telecommunications devices cannot roam between networks, single-mode telecommunications can still benefit from the advantages provided by wireless communication system solutions, such as smoother transfer between access points (if IP Phone), better voice quality experience, and call forwarding.

In an embodiment, mobile users can be configured to be associated with a contact number, such as the extension number of the main telecommunication line of the enterprise. Mobile users may include user function modules that interact with server function modules. User function modules for mobile users can be implemented on the application layer of the Open System Interconnection (OSI) architecture. Therefore, the user function module can be independent of the mobile user's operating system. For example, the operating system of a mobile user can be Windows<img file="TW200733763A_D0004.tif" />CE, Windows<img file="TW200733763A_D0005.tif" />Mobile, Linux<img file="TW200733763A_D0006.tif" />, Or Symbian<img file="TW200733763A_D0007.tif" />。

In an embodiment of the present invention, the mobile server may include mobile server software, which may include a plurality of server function modules, such as a mobile manager server module, a call control server module, and attendance management Server module, server management module, database manager module, policy manager module, proxy protocol server module, PBX interface module, resource manager module, data protocol/data transaction server Adapter module, SIP stack module, socket module, media manager module, voice quality engine module, etc. In the embodiment of the present invention, the mobile user may include mobile user software, which may include multiple user function software, such as user interface module, natural application module, mobile manager user module, call control User module, attendance manager user module, proxy protocol server module, data protocol/data change user module, voice engine module, and wrapper module, etc. The mobile server application can interact with the mobile user application to handle different telecom functions, such as managing telecom requests, enabling users, performing handovers between multiple networks during roaming, and adjusting real-time media quality (Eg, voice quality, data transfer, etc.) etc.

In an embodiment of the present invention, the mobile server can be configured to store network connectivity information about mobile users. By using the network connectivity of mobile users, mobile servers can be configured to route incoming telecom requests to mobile users. The mobile server can be configured to use the network connection communication information of the mobile user to establish an outgoing call communication request from the mobile user. Incoming and outgoing telecom requests may include voice and/or data requests.

By interacting with mobile servers, mobile users can now access multiple networks (e.g., cellular networks) almost without interruption (e.g., interrupted calls, loss of voice quality, background noise, echo, etc.) , Wi-Fi network, PSTN, etc.) roam seamlessly. Therefore, the employees of the company can be easily reached via mobile users. In this way, companies can solve their accessibility issues without having to implement third-party solutions such as UMA servers.

Because all incoming and outgoing telecom requests can now be routed through internal mobile servers, companies can now control their telecom functions. With control, companies can ensure safe and legal access to their data. In addition, because of control, companies can increase the user experience by routing the communication layer through one or more available multiple networks, thereby preventing interrupted communication layer, preventing data loss, and/or minimizing Degradation of data quality. In addition, with control, companies can control their telecom usage costs by routing the telecom conversation layer through a less expensive available network. Therefore, while providing mobile communication system solutions, companies can now balance cost, quality, and safety.

In an embodiment, multiple mobile servers can be deployed at multiple locations in the enterprise to reduce back-and-forth expansion, or incoming calls are requested by telecommunication. Multiple mobile servers can be connected via a virtual private network managed by the enterprise. The benefits of multiple mobile servers can include the reduction of unnecessary communication layer delays and inefficient use of network resources.

The features and advantages of the present invention can be better understood with reference to the drawings and the following discussion.

FIG. 8 illustrates an electronic communication conversation layer established between an external electronic communication device and a mobile user in an enterprise in an embodiment of the present invention. As discussed herein, an electrical communication device refers to a device that can be used to send media packets. Examples of electrical communication devices include cellular phones, desktop phones, multi-mode phones, IP phones, etc., but are not limited to these. As discussed in this article, mobile users refer to telecommunications devices that have installed mobile user applications.

Imagine, for example, a situation where an individual on an external phone is trying to establish a communication layer with an individual on a mobile user. Unlike conventional technologies, the user of the external telephone 802 does not have to know multiple telephone numbers in order to contact the recipient of the desired telecom request. Instead, the user of the outside telephone 802 dials the main line and extension number of the enterprise 800 to reach the desired recipient.

The electrical communication request of the user of the external telephone 802 traverses through the carrier network 860 (as shown in the process 830) to connect to the user of the mobile user 816 in the enterprise 800.

The enterprise 800 may have a wireless communication system including at least a mobile server 818 and a mobile user 816. Via an IP network 812 such as a corporate intranet, the mobile server 818 can be connected to a wireless local area network represented by the Wi-Fi network 814 (or access point 814). Furthermore, via the IP network 812 and the private branch exchange (PBX 810), the mobile server 818 can be connected to the carrier network 860 and/or the cellular network 862, which can be connected to external electronic communication devices, such as in the enterprise 800 outside the firewall 820 outside the phone 802 and so on. In addition, through the firewall 820, the mobile server 818 can be connected to the Internet 850 connected to various other networks. Enterprise 800 manages mobile server 818, IP network 812, firewall 820, PBX 810, and Wi-Fi network 814.

As mentioned above, the wireless communication system may additionally include mobile users 816 used by employees of the enterprise 800. The mobile user 816 can be combined with a group of contact numbers including at least one contact number (eg, landline phone number, IP address, extension number, cellular phone number, etc.). The method of combining the mobile user 816 to a set of contact numbers can be performed by some methods such as a subscriber identification module (SIM), which is well-known in the art.

In an embodiment, the PBX 810 (as shown in the process 832) may first receive the electrical communication request within the enterprise 800. Then, the PBX 810 routes the telecom request to the mobile server 818 via the internal IP network 812 (eg, corporate intranet) (as shown in process 834). In an embodiment, the communication between the PBX 810 and the mobile server 818 may be packet-based communication.

In an embodiment, the mobile user 816 may first register with the mobile server 818 when acting. In this solution, because the mobile user 816 is currently located in the enterprise 800, the mobile user 816 has been registered by the Wi-Fi network 814 and the mobile server. Once the mobile server 818 has received the registration information from the mobile user 816, and has verified that the mobile user 816 is valid and a subscription device, the mobile server 816 can enter and exit the mobile user 816 to receive incoming and outgoing communications. ask.

It should be that the mobile user 816 has been registered by the Wi-Fi network 814 and the mobile server 818, so the mobile server 818 knows to forward incoming telecom requests via the IP network 812 to the Wi-Fi access point In 814 (shown in process 836), the mobile user 816 is reached.

Because the telecommunications request is routed through the mobile server 818, the enterprise 800 can manage its telecommunications infrastructure. For example, the enterprise 800 can review incoming telecom requests, verify and validate user access, monitor the duration of the telecom conversation layer, and so on.

In the embodiment, the mobile server 818 is a server that manages all incoming and outgoing telecom conversation layers. In other words, media traffic (e.g., media packets) can be routed to the mobile server 818 before forwarding to the final destination (e.g., mobile user 816 or outside phone 802). The mobile server 818 may include a mobile server application program, and the application program may include a plurality of server function modules. With the mobile server application, the mobile server 818 can now manage the enterprise's telecommunications infrastructure.

FIG. 9 is an example diagram of a server function module that can be implemented in the mobile server 818 of FIG. 8 according to one or more embodiments of the present invention. Server function modules may include server management module 906, database manager module 908, policy manager module 910, attendance manager server module 912, PP server module 914, PBXI/F module 918, call control server module 920, mobility manager server module 922, resource manager module 924, DP/DX server module 926, SIP server module 930, socket server module 932, And media server and voice quality engine module 934.

The server management module 906 can be configured to provide a user interface to manage and/or monitor communication media traffic, users, communication services, and telecommunications devices (such as the mobile user 816 in FIG. 8 ). The user interface may include a web-based interface.

The database (DB) manager module 908 can be configured to manage one or more databases stored in the mobile server 818 while storing data and/or retrieving data. In one example, the mobile server 818 can use the database 908 to compare the contact number in the telecommunication request with a list of contact numbers to determine which mobile user is associated with the incoming contact number. In addition, the DB manager module 908 can perform other database management tasks, such as data backup, data recovery, and database update.

The policy manager module 910 can be configured to execute policies defined by the enterprise 800. The policy may include the priority of the telecommunication conversation layer, the roaming ability, the availability of the communication service feature, etc., but it is not limited to this.

The presence manager server module 912 may be configured to receive and store the user's presence status from mobile users such as the mobile user 816 of FIG. 8 and/or the mobile manager server module 922. Examples of the user's presence status may include online, idle, busy, offline, receiving, text only, voice only, voice message only, etc., but it is not limited to this. The user's presence status can be viewed by other parties. The user's presence status can be used to establish the willingness to participate in the incoming telecom request. In this way, the user's presence status can be used by the call control server module 920 to determine whether to establish an electrical communication conversation layer between the mobile user 816 of FIG. 8 and another electrical communication device.

The PP server module 914 can represent proxy protocol software for interacting with the application server 904 (which can be outside the mobile server 818) and translating between intelligent data applications across different platforms.

The PBX I/F module 918 or the PBX interface module 918 can be configured to enable the mobile server 818 to interface with the PBX 810.

The call control server module 920 may be responsible for the function of establishing related data communication (for example, voice call or audio/video/information streaming). Functions may include VoIP call processing, SIP (Talk Layer Initialization Protocol) proxy server and back-to-back SIP user agent (B2BUA), PSTN call management via PSTN gateway, PBX feature management, and resource and connection management.

The mobile manager server module 922 can be configured to receive and store connectivity information from mobile users such as mobile user 816 (shown in FIG. 8) when the communication layer is established. The connectivity information may include the signal strength received by the mobile user. Connected communication information can be used to determine when and how to connect to mobile users. The mobile manager server module 922 can maintain the mobile logic for determining whether to allow the mobile user to perform the handover.

The resource manager module 924 can be configured to communicate with the media server and the voice quality engine module 934 to determine whether there are sufficient resources for establishing data communication (eg, voice calls or audio/video/information streaming). Furthermore, the resource manager module 924 can forward to the mobility manager server module 922 the status data about the quality of the communication layer received from the media server and the voice quality engine module 934.

The DP/DX server module 926 can represent a data protocol/data transaction function for secure communication between the mobile server 818 and the mobile user 816 in FIG. 8. For example, the secure communication may include the transmission of the user's presence status and network communication information from the mobile user 816 of FIG. 8 to the server presence manager server module 912 and the mobile manager server module 922, respectively. . Security communication can also include the transmission of mobile users' registration information, communication status, and handover signals.

The SIP server module 930 may represent a protocol message decoding/encoding engine. The SIP server module 930 can also perform basic protocol specific tasks, such as standard-based message analysis and confirmation, forwarding, and ownership message confirmation.

The socket server module 932 can provide an interface for communication between various modules, and is a typical part of the operating system that can execute the mobile server 818. In FIG. 9, the server function modules shown above the socket server module 932 can be assembled to send messages; the server function modules shown below the socket server module 932, That is, the media server and the voice quality engine module 934 can be configured to manage voice and data traffic.

The media server and voice quality engine module 934 can be configured to monitor and process IP packets (eg, voice packets), decode and encode data (eg, voice), and encrypt and decrypt data securely. In one embodiment, the media server and voice quality engine module 934 can be implemented on separate hardware. In one embodiment, the media server and the voice quality engine module 934 can be configured to detect the impending delivery to the cellular network based on the non-arrival of many continuous IP packets.

In an embodiment, the media server and voice quality engine module 934 may include a transcoder. As discussed in this article, transcoder refers to software that can encode and/or decode data packets into different media data formats (eg, GSM, G.711, G.729, etc.). In the prior art, the code conversion can be performed by a gateway or an electrical communication device managed by a carrier. If the gateway managed by the carrier performs code conversion, network resources may be used inefficiently. In one example, the cellular data packet (eg, GSM) sent to the telecommunication device in an IP network (eg, Wi-Fi) must first be converted into an IP-enabled format (eg, G.711). Because G.711 format files are low-compressed, G.711 format files require a higher bandwidth. If the code conversion is performed by an electrical communication device that needs to have code conversion capabilities, the configuration requirements of the user of the electrical communication device will be burdened.

However, by integrating the transcoder into the media server and voice quality engine module 934, communication is not restricted by the media data format. Instead, mobile servers can now receive different media data formats and convert data packets into a format that can be received by telecommunications devices. As a result, highly compressed data formats can now be used more extensively to promote effective use of network resources. In addition, the burden of code conversion is no longer the responsibility of the telecommunications device.

Referring back to FIG. 8, the mobile user 816 may include a mobile user application. In one embodiment, the application may include a plurality of user function modules. The mobile user application can be downloaded to the mobile user 816 so that the mobile user 816 can manage their own telecommunication needs. The mobile user application can be downloaded to the mobile user 816 by the user of the mobile user 816 via well-known media such as the Internet or optical storage media. In addition, in order to create an environment that meets the telecommunications requirements of the mobile user 816, the mobile user application allows the mobile user 816 to interact with the mobile server 818.

FIG. 10 is an example diagram of a user function module that can be a part of a mobile user application according to one or more embodiments of the present invention. The mobile user 816 may include both a device specific module and a user function module. The device specific module is an operating system function module provided by the operating system of the mobile user 816. Operating system functional modules can include socket user module 1004, TAPI (Telephone Application Programming Interface) module 1060, WLAN (Wireless Local Area Network) manager module 1006, cell data manager module 1008, and GUI (Graphic User Interface) Tool program module 1010. User function modules can include user interface module 1082, natural application 1094, mobility manager user module 1096, call control user module 1098, attendance manager user module 1050, PP user module 1052, DP/ DX user module 1054, packaging program module 1056, SIP user module 1068, voice engine module 1070, and XMPP (expandable message and presence protocol) analysis module 1072.

The user interface module 1082 can be configured to display features and configuration options to the user and receive user input. The user interface module 1082 can be configured to interact with other user function modules such as the mobility manager user module 1096 and the call control user module 1098.

The natural application module 1094 may include applications that can take advantage of connectivity but will need to be unaware of the connectivity method used, such as CRM applications or database users.

The mobile manager user module 1096 can be configured to receive and use information such as signal strength data and other parameters to evaluate the current state of connectivity to make transaction decisions. When the mobile user 816 registers with the mobile server 818 (shown in FIG. 8), the criteria for the handover decision can be received and stored in the mobile manager user module 1096. The criterion may be related to signal strength, channel load, voice quality, and/or data transmission quality.

The call control user module 1098 can be configured to interact with the user interface module 1082 and manage the outgoing and incoming data of the mobile user 816 (including outgoing and incoming voice calls). In terms of outgoing data, the user interface module 1082 can provide instructions to the call control user module 1098, and then the call control user module 1098 can manage other user function modules to initialize the outgoing data. In terms of incoming data, the call control user module 1098 can instruct the user interface module 1082 to notify the mobile user 816 of the incoming data. In response, through the user interface 1082, the user can provide instructions to the call control user module 1098 regarding incoming data such as incoming calls or forwarding incoming calls.

The presence manager user module 1050 can be configured to indicate the user's presence status, wherein the presence manager server module 912 of the mobile server 818 (shown in FIG. 8) can be used to manage incoming calls. The user of the mobile user 816 can use the user interface module 1082 to configure the user presence status. Examples of the user's presence status may include online, idle, busy, offline, receiving, text only, voice only, voice message only, etc., but it is not limited to this.

The PP user module 1052 may represent a proxy protocol used to communicate with the PP server module 914 of the mobile server 818 (shown in FIG. 8).

The DP/DX user module 1054 can represent a data protocol/data transaction function for secure communication with the DP/DX server module 926 of the mobile server 818 (shown in FIG. 8).

The wrapper module 1056 can represent an application programming interface (API), which enables the mobile user 816's user function module to interact with operating systems such as the telephone application programming interface protocol 1060 (TAPI 1060) for telephone services Functional module interaction. As mentioned above, the operating system function module is a device-specific module that can be pre-existed in the operating system of the mobile user 816. The wrapper module 1056 enables the above user function modules to be independent of the operating system of the mobile user 816 (e.g., Windows<img file="TW200733763A_D0008.tif" />CE, Windows<img file="TW200733763A_D0009.tif" />Mobile,Linux<img file="TW200733763A_D0010.tif" />, Or Symbian<img file="TW200733763A_D0011.tif" />). Unlike conventional technologies, the user function module does not depend on the operating system, because the user function module can be implemented on the application layer of the OSI architecture.

In one or more embodiments, possible user function modules additionally include one or more SIP user modules 1068, a voice engine module 1070, and an XMPP parser module 1072.

The SIP user module 1068 can be configured to interact with the SIP server module 930 of the mobile server 818 (shown in FIG. 8) for communication between the mobile user 816 and the mobile server 818 in FIG. Invite, OK, and inform call sending.

The speech engine module 1070 can be configured to provide one or more of encoding, decoding, echo cancellation, tremor control, and error concealment.

The XMPP parser module 1072 can be configured to serve as a message service.

Referring back to FIG. 8, when the user of the mobile user 816 starts to implement an electrical communication request, the mobile server 818 can perform a similar connection type. First, an electrical communication request can be sent to the mobile server 818 via the Wi-Fi network 814 and the IP network 812. The mobile server 818 can first check the legitimacy of the user making the telecom request. If the user is not a registered user, the mobile server 818 can terminate the request. If the user is a registered user, the mobile server 818 can then check the contact number. When the contact number is identified as a foreign number, the mobile server 818 can forward the telecom request to the PBX 810. When receiving the request, the PBX 810 can dial the contact number to request the carrier network 860 to contact the user in the external telephone 802.

In order to make the solution better illustrated, FIG. 11 is a simplified call flow chart of the mobile user 816 starting to implement the establishment of the electrical connection request in an embodiment. Figure 11 will be discussed together with Figures 8, 9, and 10.

In the first step 1100, the user of the mobile user 816 can send a SIP invitation to the mobile server 818. In one embodiment, in order to send the SIP invitation, the user of the mobile user 816 can use the user interface module 1082 to input the contact number of the external phone 802. Once the electrical communication request has been input, the call control user module 1098 is implemented. The call control user module 1098 can interact with the mobile manager user module 1096 to determine the best method to reach the mobile server 818. The mobility manager user module 1096 can check the user's connectivity status and determine the network that can be connected. In one example, because the mobile user 816 has been registered through the Wi-Fi network 814 and the mobile server 818, the mobile manager user module 1096 can determine that the user is currently on the Wi-Fi network based on the registration information. And it is determined that the call control user module 1098 can request Wi-Fi connection. Because the call control user module 1098 knows that the Wi-Fi connection can be made through SIP, the call control user module 1098 can access the SIP user (library) module 1068 through the packaging program module 1056. The SIP user module 1068 can send SIP invitations to the mobile server 818 via the socket user module 1004.

If the mobile manager 1096 determines that the user of the mobile user 816 has not been registered, it sends an electrical communication request to the TAPI module 1060 via the wrapper module 1056. Then, the TAPI module 1060 can forward the telecom request to the PBX 810 via the cellular network 862. The PBX 810 can then forward the telecom request to the mobile server 818 via the IP network.

It should be noted that if the user of the mobile user 816 is in the enterprise environment, the mobile user 816 has been automatically registered with the mobile server 818. The situation that the mobile user 816 is not registered usually occurs when the user of the mobile user 816 is outside the enterprise 800 while requesting the telecommunication conversation layer.

When receiving the SIP invitation, the mobile server 818 can check the contact number. In order to perform the check of the contact number, the SIP invitation is forwarded to the call control server module 920 via the socket server module 932 and the SIP server module 930. When receiving the contact number, the call control server module 920 interacts with the resource manager module 924 of the mobile server 818 to confirm whether there are enough network resources (such as radio frequency resources, traffic channels, etc.) to support the call .

In addition, the call control server 920 can then be matched with the DB manager module 908 to determine how to handle the contact number. The DB manager module 908 can determine that the contact number associated with the external phone 802 is not registered with the mobile server 818.

Referring back to FIG. 11, in the next step 1102, the call control server module 920 of the mobile server 818 can send the SIP invitation to the PBX 810 via the PBX interface module 918. In response, in the next step 1104, the PBX 810 can send a callback call signal to the mobile server 818, and the mobile server 818 then forwards the signal to the mobile user 816, so in the next step 1106, the mobile user 816 Can call back to the user.

In addition, in the next step 1108, the PBX 810 can translate the SIP invitation into a dialing request, and dial the contact number associated with the outside telephone 802 to reach the carrier network 860. In the next step 1110, the carrier network 860 can perform an exchange to forward the communication request to the outside phone 802.

When responding to the incoming telecom request, the user of the outside phone 802 can pick up the outside phone 802. In the next step 1112, the outside phone 802 may send a message indicating that the outside phone 802 has been picked up and return to the carrier network 860.

Once a connection has been established between the carrier network and the outside telephone 802, in the next step 1114, the carrier network 860 can send a message to the PBX 810. Then, in the next step 1116, the PBX 810 can translate the message into a SIP OK message, and can send the SIP OK message to the call control server module 920 of the mobile server 818 via the PBX interface module 918. Before forwarding the SIP OK message to the mobile user 816, the call control server module 920 can interact with the resource manager module 924 to request resource allocation. The resource manager module 924 can interact with the media server of the mobile server 818 and the voice quality engine module 934 to determine the amount of resources that need to be allocated. In one embodiment, resource allocation may be determined based on the media requirements of the telecommunication conversation layer (eg, text, voice, video, etc.).

In the next step 1118, the mobile server 818 can forward the SIP OK message to the mobile user 816. In one example, the call control server module 920 can forward the SIP OK message to the mobile user 816 via the SIP server module 930 and the socket server module 932. In the mobile user 816, the received SIP OK message can flow from the socket user module 1004 to the SIP user module 1068 via the wrapper module 1056 to the call control user module 1098.

When receiving the SIP OK message, in the next step 1120, the call control user module 1098 of the mobile user 816 can send a SIP ACK message to the mobile server 818. The SIP ACK message can be sent along the same path as the SIP invitation message. In the next step 1122, the call control server module 920 of the mobile server 818 can send a SIP ACK message to the PBX 810. In the final step 1124, an electrical communication conversation layer can be established between the mobile user 816 and the outside phone 802. The telecom conversation layer includes two connections (for example, process 1126 and process 1128). The process 1126 can be located between the external telephone 802 and the mobile server 818 through the carrier network 860, the PBX 810, and the IP network 812. The process 1128 can be located between the mobile user 816 and the mobile server 818 via the IP network 812 and the Wi-Fi network 814. Using this method, the mobile server 818 handles all the electrical communication traffic between the mobile user 816 and the outside telephone 802.

Referring back to FIG. 8, the electrical conversation layer is active between the user of the external telephone 802 and the user of the mobile user 816. FIG. 12 is an example of a roaming scheme in which a user of the mobile user 816 roams from the Wi-Fi network 814 to the cellular network 862 according to one or more embodiments of the present invention.

During the telecommunication conversation layer, the user of the mobile user 816 can start moving away from the enterprise 800 (as shown by the path 1202), and when the user of the mobile user 816 moves away from the Wi-Fi network 814, the signal level And voice quality will start to decline. Furthermore, the user of the mobile user 816 can roam into the area supported by the cellular network 862.

During the transition period, the mobile server 818 and the mobile user 816 can monitor the signal strength received from the Wi-Fi network 814. In one embodiment, the signal level quality can be monitored by the mobile manager user module 1096 in the mobile user 816. By sending data to the mobile manager server module 922 in the mobile server 818 through the DP/DX user module 1054 and the DP/DX server module 926, the mobile manager user module 1096 can be continuously shared Signal level data. When the signal strength drops, the mobility manager server module 922 and the mobility manager user module 1096 notify the call control server module 920 and the call control user module 1098, respectively, in anticipation of a new network connection. In one example, a new connection between the mobile user 816 and the cellular network 862 can be established. In one embodiment, the current connection between the mobile user 816 and the Wi-Fi network 814 can be maintained for a temporary period until a handover has occurred.

Once the signal strength of the Wi-Fi network 814 has dropped below the predetermined threshold established by the enterprise 800, the connection with the Wi-Fi network 814 will be stopped, and the cellular network 862 can replace the Wi-Fi network 814. As the main network. Media traffic can now flow from outside phone 802 to carrier network 860 (process 830) to PBX 810 (process 832). Then, the PBX 810 may forward the media traffic to the mobile server 818 via the IP network 812 (process 834). Then, the mobile server 818 forwards the media traffic via the IP network 812 to the PBX 810 to the carrier network 860 (process 1206). Media traffic from the carrier network 860 may be forwarded to the cellular network 862 (process 1208) to reach the mobile user 816 (process 1210).

Fig. 13 is a call flow chart of the roaming solution of Fig. 12 according to an embodiment of the present invention. There may be a connection 1302 established between the outside phone 802 and the mobile user 816 through the mobile server 818. The established connection 1302 may include two processes 1304 and 1306. The process 1304 is related to the connection between the outside telephone 802 and the mobile server 818. In one example, the outside telephone 802 can be connected to the mobile server 818 through the carrier network 860 and the PBX 810. The process 1306 is associated with the connection between the mobile user 816 and the mobile server 818. In one example, the mobile user 816 connects to the mobile server 818 through the Wi-Fi network 814.

In the next step 1308, data about the connectivity status of the mobile user 816 can be continuously transmitted to the mobile server 818. When the user of the mobile user 816 starts roaming away from the Wi-Fi network 814, at point 1310, one or more criteria for handover are met, and at least one of the mobile user 816 and the mobile server 818 One can decide that the handover must be executed. One or more criteria can be configured by the enterprise 800, and can be stored in the mobile user 816 and/or the mobile server 818. The criteria may include signal strength, channel load, and communication quality, but are not limited to these.

In the next step 1312, the mobile server 818 can establish a connection with the PBX 810 to start the handover. When preparing for handover, the mobile server 818 can also start to buffer the media packets from the mobile user 816 and the external phone 802. Buffering can occur when the packet is not expected to be received by another party. During the transition period, the process 1304 and process 1306 of the established connection 1302 are still maintained, and the media packet is still sent to both parties (ie, the mobile user 816 and the outside phone 802).

In the next step 1314, the mobile server 818 sends a SIP invitation message to the PBX 810. The SIP invitation message includes a cellular number associated with the mobile user 816. In the next step 1316, the PBX 810 can translate the SIP invitation message into a cellular call to the cellular network 862. In the next step 1318, the PBX 810 sends the mobile phone ringtone back to the mobile server 818.

In the next step 1320, the cellular network can connect with the mobile user 816. At this time, two connections have been established between the mobile user 816 and the mobile server 818. In order to notify the mobile server 818 that the second connection has been established by the cellular network 862, in one embodiment, the mobile user 816 sends various signals via various network connections (ie, cellular network and Wi-Fi network) . In one embodiment, two signals may be sent to ensure that the mobile server 818 receives the request to exchange in a timely manner. In one example, the mobile user 816 sends a first signal via a Wi-Fi connection (path 1322) and a second signal via a cellular network to the mobile server 818 (path 1324). In response, the mobile server 818 can send a confirmation signal to the mobile user 816 via the two network connections.

In one embodiment (point 1326), the mobile server 818 and/or the mobile user 816 can perform a new cellular connection exchange. Therefore, the connection between the mobile user 816 and the external phone 802 is replacing the Wi-Fi network via a cellular network. In an embodiment, a new connection 1328 between the outside phone 802 and the mobile user 816 may be established. The new connection 1328 may include an existing process 1304 and a newly established process 1330 via the cellular network 862. In one embodiment, after a new connection 1328 has been established, the mobile server 818 can separate the mobile user 816 from the Wi-Fi network 814. In another embodiment, the mobile user 816 can be separated from the Wi-Fi network 814 while a new connection 1328 is being established.

12 and 13 are diagrams that can seamlessly transfer from Wi-Fi network to cellular network for both the mobile user 816 user and the external telephone 802 user. No matter how complicated the steps that take place to exchange the user of the mobile user 816 to a better connection, when the mobile user 816 displays a message on the user interface module 1082 to inform the user that a new connection is in progress, the mobile user 816 users only know the network changes. For all general purposes, the switch from Wi-Fi network to cellular network is a seamless transition that does not negatively affect the telecommunications experience of the two callers.

Similarly, as shown in FIGS. 14A and 14B generally, the exchange occurs when the user of the mobile user 816 roams from the cellular network back to the Wi-Fi environment 814.

FIG. 14A is an example diagram of a call roaming solution in which the mobile user 816 roams from the cellular network 862 back to the Wi-Fi network 814 according to one or more embodiments of the present invention. Imagine that the mobile user 816 in Figure 12 who is currently communicating with an outside telephone 802 through the cellular network 862 (via the PBX 810) has roamed back to the corporate Wi-Fi network 814 (path 1490). When the mobile user 816 roams from the cellular network 862 to the Wi-Fi network 814, the mobile user 816 starts to register via the Wi-Fi network 814 and the mobile server 818. The registration packet is sent from the mobile user 816 to the mobile server 818 via the Wi-Fi network 814 via the IP network 812.

Once the registration has been completed and one or more criteria for the handover (eg, signal strength, channel load, and/or communication quality) have been met, the handover can begin. The mobile user 816 sends two signals indicating the ready state to the mobile server 818. As mentioned above, signals are sent via various available networks to ensure that the mobile server 818 receives the signals in a timely manner.

When receiving one of the signals, the mobile server 818 can switch the mobile user to the Wi-Fi network 814. In another embodiment, the mobile user 816 can perform the exchange and then notify the mobile server 818.

Once a connection has been established between the mobile user 816 and the mobile server 818 via the Wi-Fi network, the cellular connection can be separated. In one embodiment, the mobile server 818 sends a separate message to the PBX 810. Then, the PBX 810 sends a command to the cellular network 862 to end the connection.

Media traffic can now flow from outside phone 802 to carrier network 860 (process 830) to PBX 810 (process 832). Then, the PBX 810 forwards the media traffic to the mobile server 818 via the IP network 812 (process 834). Then, the mobile server 818 forwards the media traffic to the Wi-Fi network 814 to the mobile user 816 via the IP network 812 (process 1492).

FIG. 14B is a call flow chart that provides steps for the occurrence of a handover according to an embodiment of the present invention. There may be a connection 1402 established between the outside phone 802 and the mobile user 816 through the mobile server 818. The established connection 1402 includes two processes 1404 and 1406. The process 1404 is related to the connection between the outside telephone 802 and the mobile server 818. In one example, the outside telephone is connected to the mobile server 818 through the carrier network 860 and the PBX 810. The process 1406 is associated with the connection between the mobile user 816 and the mobile server 818. In one example, the mobile user 816 connects to the mobile server 818 through the cellular network 862 and the PBX 810.

The user of the mobile user 816 roams from the cellular network back to the Wi-Fi network within the enterprise 800 (eg, Wi-Fi network 814). In the next step 1408, the mobile user 816 can register via the Wi-Fi network 814 and the mobile server 818. During the registration process, the authentication of the mobile user 816 (including the user identity) may be performed for security considerations. In addition, information for performing handover can be exchanged between the mobile user 816 and the mobile server 818.

In the next step 1410, one or more criteria for handover are met, and at least one of the mobile user 816 and the mobile server 818 may determine that the handover needs to be performed. As described above, one or more criteria (eg, signal strength, channel load, and/or communication quality) can be configured by the enterprise 800, and can be stored in the mobile user 816 and/or the mobile server 818.

In the next step 1412, at least one of the mobile user 816 and the mobile server 818 can determine that the current communication layer between the user of the mobile user 816 and the outside phone 802 is best to continue to communicate with Wi-Fi The connection via the network 814 replaces the connection via the cellular network 862.

In the next step 1414, the mobile server 818 sends a SIP invitation message to the mobile user 816. In response, in the next step 1416, the mobile user 816 sends a SIP OK message back to the mobile server 818.

In the next step 1418, at least one of the mobile user 816 and the mobile server 818 can perform the exchange from the cellular network 862 to the Wi-Fi network 814, thus completing the handover. Therefore, a connection 1420 between the mobile user 816 and the mobile server 818 via the Wi-Fi network 814 can be established.

In the next step 1422, the mobile server 818 can send a separate message to the cellular network 862 to stop the connection between the cellular network 862 and the mobile user 816. In one embodiment, the mobile server 818 sends a separate message to the PBX 810. The PBX 810 can interpret the split messages and send commands to the cellular network 862 to interrupt the cellular connection 1406.

After the roaming transition has been completed, a connection 1424 may be established between the outside phone 802 and the mobile user 816. As you can see, the connection 1424 includes a process 1404 and a process 1424. As mentioned above, the process 1404 is the process between the external phone 802 and the mobile server 818. Although roaming has occurred, process 1404 is not affected. Regarding process 1424, this process replaces process 1406 and represents a new connection between mobile user 816 and mobile server 818 via Wi-Fi network 814.

Similarly, as shown in FIGS. 15A and 15B, the exchange occurs when the mobile user 816 roams from the cellular network back to the hotspot W-Fi environment (eg, coffee shop).

15A is an example diagram of a call roaming solution in which the mobile user 816 roams from the cellular network 862 back to the hotspot W-Fi network 1502 according to one or more embodiments of the present invention.

Imagine, for example, that the mobile user 816 of FIG. 12, who is currently communicating with the outside telephone 802 through the cellular network 862, has roamed into the hotspot Wi-Fi hotspot 1502 (path 1504). When the mobile user 816 roams from the cellular network 862 to the Wi-Fi network 1506, the mobile user 816 can start to register via the Wi-Fi network 1506 and the mobile server 818. The registration packet is sent from the mobile user 816 through the Wi-Fi network 1506 through the Internet 850, the firewall 820, and the IP network 812 to reach the mobile server 818.

Once the registration is completed and one or more criteria for handover are met (eg, signal strength, channel load, and/or communication quality), the handover begins. The mobile user 816 can send two signals to the mobile server 818 indicating its ready state. As mentioned above, signals are sent via various available networks to ensure that the mobile server 818 receives the signals in a timely manner.

When receiving one of the signals, the mobile server 818 can switch the mobile user to the Wi-Fi network 1506. In another embodiment, the mobile user 816 performs the exchange and then informs the mobile server 818.

Once a connection has been established between the mobile user 816 and the mobile server by the Wi-Fi network 1506, the cellular connection can be separated. In one embodiment, the mobile server 818 sends a separate message to the PBX 810. The PBX 810 sends a command to the cellular network 862 to end the connection.

Media traffic can now flow from outside phone 802 to carrier network 860 (process 830) to PBX 810 (process 832). Then, the PBX 810 forwards the media traffic to the mobile server 818 via the IP network 812 (process 834). Then, the mobile server 818 forwards the media traffic to the Wi-Fi network 1506 to the mobile user 816 via the IP network 812, the firewall 820, and the Internet 850 (process 1508).

Fig. 15B is a telephone flow chart of the steps of providing a handover according to an embodiment of the present invention. Similar to FIG. 14B, the established connection 1522 can exist between the external phone 802 and the mobile user 816 through the mobile server 818. The established connection 1522 includes two processes 1524 (the cellular connection between the external phone 802 and the mobile server 818) and 1526 (the cellular connection between the mobile user 816 and the mobile server 818).

When the user of the mobile user 816 roams into the Wi-Fi network 1506, in the next step 1528, the mobile user 816 will identify whether there is a FW (firewall) or firewall between its connection point and the mobile server 818 NAT (Network Address Translation) device. Once the connectivity method has been identified, it can be registered with the mobile server 818 via Wi-Fi 1506. After the registration and authentication have been performed, in the next step 1503, one or more criteria of the handover (such as signal strength, channel load, and/or communication quality) are met, and the mobile user 816 and/or mobility The server 818 decides to hand over. In the next step 1532, the handover starts.

In the next step 1534, the mobile server 818 sends a SIP invitation message to the mobile user 816 through the IP network 812, the firewall 820, and the Internet 850 in the Wi-Fi network 1506. In response, in the next step 1536, the mobile user 816 in the Wi-Fi network 1506 can send a SIP OK message back to the mobile server 818 through the Internet 850, the firewall 820, and the IP network 812.

In the next step 1538, an exchange can be performed to move media traffic from the cellular network 862 to the Wi-Fi network 1506 to complete the handover and establish a mobile user 816 and a mobile server 818 via the Wi-Fi network 1506 The connection between 1540.

In the next step 1542, the mobile server 818 sends a separation message to the PBX 810. The PBX 810 interprets the split message and sends a command to the cellular network 862 to interrupt the cellular connection 1526.

After the roaming transition has been completed, a connection 1544 can be established between the outside phone 802 and the mobile user 816. As you can see, the connection 1544 includes the process 1524 (the process between the external phone 802 and the mobile server 818) and the process 1540 (the new connection between the mobile user 816 and the mobile server 818 via Wi-Fi 1506). process).

Figures 14A, 14B, 15A, and 15B illustrate the use of wireless communication system solutions, the enterprise 800 can control when the handover from the more expensive cellular network to the less expensive IP network (such as Wi-Fi) takes place . In the conventional technology, the enterprise 800 relies on the cellular network to make exchange decisions. Enterprise 800 generally has little or no control over when exchanges occur. As a result, the enterprise 800 may not have the opportunity to take advantage of the cost savings generated by switching to a less expensive network.

Similar to the exchange from Wi-Fi network to cellular network, the handover from cellular network to Wi-Fi network can be seamless to users of mobile users 816 and users of outside telephone 802 happen. No one knows the steps taken to switch the users of mobile users 816 whose connections are down to a network that is not only cheaper but also prevents the communication layer between the users of mobile users 816 and the outside telephone 802 from being interrupted.

FIG. 16A is a diagram of call establishment between two mobile users according to one or more embodiments of the present invention. The mobile user 816 wants to connect with the mobile user 1602. Both mobile users 816 and 1602 are located in the enterprise 800. The electrical communication request from the mobile user 816 can be routed to the mobile server 818 via the Wi-Fi network 814 and the IP network 812 (process 1604). After confirming the mobile user 816, the mobile server 818 recognizes that the recipient of the electrical communication request (the mobile user 1602) is a registered device. Then, the mobile server 818 routes the electrical communication request to the mobile user 1602 via the IP network 812 and the Wi-Fi network 1608 (process 1606) to establish an electrical communication conversation layer between the mobile user 816 and the mobile user 1602 .

Fig. 16B is a call flow chart of Fig. 16A according to an embodiment of the present invention. In the first step 1622, the mobile user 816 sends a SIP invitation message to the mobile server 818 via the Wi-Fi network 814 and the IP network 812.

In one embodiment, in order to send the SIP invitation, the user of the mobile user 816 can use the user interface module 1802 to input the contact number for the mobile user 1602. Once the electrical communication request has been input, the call control user module 1098 can be implemented.

Because the call control user module 1098 knows the Wi-Fi connection through SIP, the call control user module 1098 can access the SIP user module 1068 through the wrapper module 1056. The SIP user module 1068 sends a SIP invitation to the mobile server 818 via the socket user module 1004.

When receiving the SIP invitation, the mobile server 818 checks the contact number. In order to perform the contact number check, the SIP invitation is forwarded to the call control server module 920 through the socket server module 932 and the SIP server module 930. When receiving the SIP invitation, the call control server module 920 can interact with the resource manager module 924 of the mobile server 818 to confirm whether sufficient network resources can be used to support the communication request. Because the recipient is also a registered device, the call control server module 930 can match the presence manager server module 912 to determine the status of the mobile user 1602. By matching the presence manager server module 912, the outgoing telecom request can be better directed.

If the attendance manager server module 912 indicates that the user of the mobile user 1602 is accepting the communication request, then in the next step 1624, the call control server module 930 guides through the Wi-Fi network 1608 and the IP network 812 Call to mobile users. In one example, the mobile user 1602 can ring the phone.

In the mobile user 1602, the received SIP invitation message can flow from the socket user module 1004 to the SIP user module 1068 via the wrapper module 1056 to the call control user module 1098.

When receiving the SIP invitation message, in the next step 1626, the call control user module 1098 of the mobile user 816 sends a SIP OK message to the mobile server 818 through the Wi-Fi network 1608 and the IP network 812 to receive Telecom request (eg, answering a phone call). In the mobile server 818, the received SIP OK message can flow from the socket server module 932 to the SIP server module 930 until the call control server module 920 is reached.

In the next step 1628, the mobile server 818 forwards the SIP OK message to the mobile user 816 through the Wi-Fi network 814 and the IP network 812. In the mobile user 816, the received SIP OK message can flow from the socket server module 932 to the SIP server module 930 until the call control server module 920 is reached. In response, in the next step 1630, the mobile user 816 can send a SIP ACK message to the mobile server 818 via the Wi-Fi network 814 and the IP network 812 to confirm the receipt of the SIP OK message.

In the next step 1632, the mobile server 818 forwards the SIP ACK message to the mobile user 1602 through the Wi-Fi network 1608 and the IP network 812. Once the SIP ACK message has been received, the mobile server 818 can connect to the process 1636 (that is, the connection between the mobile user 816 and the mobile server 818 through the Wi-Fi network 1608 and the IP network 812) and the process 1638 (That is, the connection between the mobile user 1602 and the mobile server 818 through the Wi-Fi network 1608 and the IP network 812) to form a new connection 1634.

In one embodiment, in order to increase the efficiency of mobile media traffic, the transcoder can be integrated into the mobile server. In the prior art, the gateway is managed by the carrier or the transcoder is executed by the electrical communication device. To help the discussion, FIG. 17 is a block diagram of the conventional technology of the transcoder in the carrier management gateway.

Imagine, for example, a situation where a cellular phone is communicating with mobile users. When the cellular phone 1701 communicates with the mobile user 116 via the cellular network 162 and the Wi-Fi network 114, the transcoder 1749 in the carrier management gateway 1799 transcodes the media data. Therefore, cellular phone 1701 can transmit and receive media data in cellular network standardized formats (e.g., GSM on process 1771), and mobile users 116 can use wireless LAN standardized formats (e.g., G.711 on process 1791) The media data is transmitted and received so that both the cellular phone 1701 and the mobile user 116 can correctly encode and/or decode the media data.

The carrier management gateway 1799 is usually located in the carrier base (eg, in the base carrier network 160 or the cellular network 112). Therefore, the link 1789 between the carrier management gateway 1799 and the IP network 112 represents an important part of the entire network resources. For its part, the effective use of link 1789 is important. However, compared with GSM, G.711 is a low compression (that is, high data size) transcoding standard. With the code conversion performed by the carrier management gateway 1799 and the media data in G.711 transmitted on the link 1789, the link 1789 is used inefficiently.

Imagine another situation where, for example, an IP telecom device is communicating with a mobile user. When the IP device 1703 communicates with the mobile user 116 via the Internet 150, the IP network 112, and the Wi-Fi network 114, even if the IP device 1703 has the ability to use the G.729 format with low bandwidth, the IP device 1703 The G.711 format with high bandwidth must still be used to communicate with the wireless LAN mobile user 116 that normally uses the G.711 format. In other words, in order for the IP device to communicate with the mobile device, the media packet sent from the IP device must be of an acceptable standard to the mobile device. In this way, even if the IP device can transmit media packets in a high compression format, the IP device cannot take advantage of this capability because the mobile device cannot receive high compression files. As a result, more bandwidth is required to transmit media packets between the IP device 1703 and the mobile user 116.

In addition, the requirement of the IP device 1703 that sends media packets in a low compression format (eg, G.711) requires the user of the IP device 1703 to configure the transcoder 1743 to form a transcoder 1743 to perform the transcoding correctly. This proof is inconvenient for the user, especially if the user is not "technical". In addition, if the IP device 1703 cannot perform code conversion, the IP device 1703 cannot communicate with the mobile user 116.

The conventional technical method of placing the transcoder in the carrier management gateway and/or the telecommunications device limits the types of telecommunications devices that can be purchased. In addition, routing data packets in a low-compression format creates a burden on network traffic, leading to higher costs and even lower traffic.

In one embodiment, the transcoder can be placed in an enterprise (eg, a mobile server) to process multiple types of media data formats. FIG. 18 is a block diagram of the configuration of code conversion in an embodiment.

The transcoder 1858 can be implemented in the media server and voice quality engine 934 of the mobile server 118. Therefore, with the code conversion performed by the code converter 1858, the communication between the cellular phone 1701 and the mobile user 116 can be represented by the process 1872 in the GSM format and by the process 1892 in the G.711 format. For its part, the media data transmitted on Link 1789 is now in high-compression formats such as GSM instead of low-compression formats such as G.711. As a result, network resources can be used more effectively.

In addition, through the code conversion performed by the transcoder 1858, the communication between the IP device 1703 and the mobile user 116 can be represented by the process 1882 in the G.729 format and by the process 1892 in the G.711 format. For its part, users of IP device 1703 are now sending highly compressed media packets, with the result that lower cost bandwidth is utilized. In this way, users of the IP device 1703 no longer need to assemble their electrical communication devices to perform code conversion. As a result, the types of telecommunications devices that can be purchased are no longer limited to only those telecommunications devices that have code conversion capabilities.

As can be understood from the foregoing, one or more embodiments of the present invention provide a wireless communication system that utilizes multiple network configurations that can be managed by an enterprise to meet its basic construction requirements. Furthermore, wireless communication systems give enterprises the flexibility to establish, implement, manage, and strengthen their own communication policies. In addition, by being independent of operating systems, branches, and/or modules, the wireless communication system reduces the costs associated with changing equipment (such as network equipment and electrical communication devices). Because further cost savings can be obtained through wireless communication networks, when lower-cost networks are available, companies modify mobile servers to use lower-cost networks.

One or more embodiments are capable of seamless roaming and smooth handover between multiple mobile/wireless networks. Therefore, the employees of the enterprise have the connectivity and proximity that are actually widespread. As a result, companies increase customer satisfaction and avoid missing business opportunities.

One or more embodiments can be configured with mobile server software and user software that can be implemented independently of the operating system and hardware. Therefore, the cost of exchanging carriers and changing the communication configuration can be minimized.

In addition, one or more embodiments include multiple mobile servers connected via a virtual private network and deployed in multiple locations of an enterprise, such as multiple international locations. Therefore, the use of network resources can be optimized, and the cost of communication can be reduced.

B. Enhance user experience in media delivery

Figure 4A-E illustrates the method and structure of fast media handover between Wi-Fi and cellular networks.

1. The present invention sets a mechanism to seamlessly exchange media connections between Wi-Fi inside or outside the door controlled by the enterprise to the cellular network controlled by the operator. This mechanism will compensate for different loss characteristics on different networks and achieve cost savings for telephone users.

2. VQE design considerations: The criteria for successful voice delivery in the same and different networks include: the number of deliveries; and the voice quality.

Several factors determine the acceptable user experience of voice handover performance, such as codecs/decoders, number of code translations, jitter, streaming switching effects, and end-to-end delay including cellular/Wi-Fi delay differences Wait. Some of these parameters that cause unique challenges in cross-species delivery are discussed in detail below.

3. Encoder/decoder and transcoding G.711, G.729, GSM and the new UMTS encoder/decoder are some of the common voice transcoding standards. The overall performance is affected not only by the bandwidth requirements of the encoding but also by the transcoding delay on the established MAC layer and the number of transcoding in the end-to-end call.

4. End-to-end delay and echo. The end delay of the cellular network may be 300-500 ms in terms of the tail path that generates the echo. In order to account for the auditory echo of the telephone receiver, the carrier wave limits the volume level of the mobile user. This solution reduces the establishment of the PSTN side where cellular telephone users cannot hear the call. It should be noted that this effect is outside the control of the enterprise, and the different volume may exist due to the way cellular networks implement their voice networks.

Traditional echo cancellers are limited to a 128 ms tail length, mostly due to cost. The processing delay in the tail circuit of the mobile system (between the MSC and the handset) will result in a tail length of nearly 300 ms. Because of the potential unpredictability of the telephone receiver's auditory echo return loss (AERL) and the variability of the caller's environment, it is impractical to place the canceller in the circuit only when conditions require it. As far as the delay from the corporate Wi-Fi network to the PSTN is concerned, the scheme and the delay budget of approximately 125 ms are described below.

5. Switching media stream connection Although the delay of switching the encoder/decoder and the stream increases more than just reconnecting the stream, the full use of G.711 eliminates the encoder/decoder change.

6. Use silent and old packets In order to compensate for the delay difference during handover, it is recommended to use pre-stored silent packets. The automatic association of the two streams together with the silent packet insertion helps a smoother transition.

<tables><img file="TW200733763A_D0012.tif" /></tables>

The above table represents a minimum set of procedures for delivery. Most of the handover can be allocated to scans for available access points. If passive scanning is used, the time is longer. After eliminating the scan, then by sending out the address configuration and pre-processing at the time of provision, and then replacing the full DHCP processing waiting to be completed with SIP messages, reducing the impact of DHCP by 10 ms. After receiving the SIP request, the address must first be pre-processed to ensure any changes in the IP address and subsequent impact and traffic flow on the NAT. If the handover occurs after NAT and a new IP address is allocated, it needs to be pre-processed with the address used to obtain it. For example, this requires notification to the pre-processing server to reconfigure a new address and port for identification of the new conversation layer. Then a SIP-based recombination can be issued to redirect traffic. After these control messages, the proxy or the end device redirects the traffic to the new IP address. It takes 30-35 ms from combining to completion.

The features and advantages of the present invention can be better understood with reference to the drawings and the following discussion.

The problems faced by users in the prior art are related to user experience during handover in wireless communication. When the electric communication device performs handover between the transmitters, the two transmitters can send data streams at the same time. However, the media stream is not synchronized. In one example, the gap exists. In another example, the media streams overlap. As a result, two parties on the telecommunications conversation layer experience silence, noise, artifacts, and/or echo (eg, prominent language in a voice call or interrupted viewing of streaming video).

Conventional Technology FIG. 43 illustrates an example of an arrangement for processing media data during handover in wireless communication. Imagine, for example, a situation where the user of the mobile telecommunication device 4316 is talking with the user of the external telephone 4302. During the telecommunications conversation layer, the user of the mobile telecommunications device 4316 leaves the Wi-Fi network 4314 and roams toward the cellular network 4362, resulting in a handover between the two networks. During the handover, the server 4398 can be used to process the media data stream sent by the mobile telecommunication device. In one example, the first media data stream 4350 can be transmitted from the Wi-Fi network 4314, and the second media data stream 4304 can come in from the cellular network 4362. In addition, the server includes a mute module 4390 configured to shield noise and media data during handover.

Conventional Technology FIGS. 44A and 44B illustrate a conventional example of a method for processing a media data stream during handover in wireless communication. Conventional Technology Figures 44A and 44B will discuss the conventional technology Figure 43.

Conventional Technology FIG. 44A illustrates a handover scheme in which there is a gap in the media data streams sent by two networks. Figure 4400 includes illustrations of media data streams 4302 and 4304. During the handover period 4406, a gap 4410 exists. The gap 4410 represents the time interval during which neither the first media stream 4350 nor the second media stream 4304 is active. In one example, the signal level from the Wi-Fi network 4314 has become weak and the first media data stream 4302 cannot be transmitted. Furthermore, the connectivity with the cellular network 4362 is still weak, so the second media data stream 4304 has not been transmitted yet. As a result, the telecom conversation layer appears as if the connectivity between the two parties has been lost. In addition, random noise (eg, static noise) becomes annoying and obvious to all parties in the telecommunication conversation layer.

The conventional technical solution used to handle the gap is to use the silent module 4390. In one example, the mute module 4390 provides a mask 4408 during the handover 4406 to cover the gap 4410 to eliminate noise. The mask 4408 includes a silent data packet that provides low and pre-recorded background noise so that all parties in the telecommunication conversation layer know that the telecommunication conversation layer has not stopped. In addition, the mask 4408 protects all parties in the communication layer from random noise. Unfortunately, the mute method still presents a noticeable interruption in the telecom conversation layer. In addition, the parties involved in the telecommunication conversation layer are not sure of the length of the interruption. As a result, the mute method cannot provide a seamless transition to the parties involved.

The prior art FIG. 44B illustrates a handover scheme in which there is overlap between the media data streams sent by two networks. Figure 4450 includes illustrations of media data streams 4302 and 4304. During the handover period 4416, an overlap 4420 exists between the first media data stream 4350 and the second media data stream 4304. Overlap 4420 represents the time interval during which both media stream 4350 and media stream 4304 are active.

In one example, the signal level from the W-Fi network 4314 is still strong enough to transmit the media data stream 4302. At the same time, the signal strength from the cellular network 4362 also becomes stronger, and as a result, the media data stream 4304 is transmitted. During the overlap 4420, due to the cancellation and accumulation of signals, the parties in the telecommunications conversation layer experience unsatisfactory communication quality, such as silence, noise, defects, and/or echo.

In the prior art, the mute method can be used to deal with overlap. In one example, the mute module 4390 can be used to provide a mask 4418 during the handover 4416 to cover the overlap 4420 to eliminate noise, artifacts, and/or echo. Once again, the mute method presents an obvious interruption in the telecommunication conversation layer, and the parties included in the telecommunication conversation layer are not sure of the length of the interruption. Therefore, the mute method cannot provide a smooth and seamless transition to the parties involved.

Another method implemented in the prior art to handle overlap 4420 is to use a mixer such as that used by conference phones. In other words, the mixer can mix the overlapping parts of the first media data stream 4350 and the second media data stream 4304 during the handover 4416. Although the users of both the electric communication devices receive data from both the first media data 4302 and the second media data 4304, the users experience reverberations and artifacts due to, for example, transmission delays or auditory delays. In addition, the noise can also be mixed with data from the first media material 4302 and the second media material 4304. As a result, the quality of the communication layer during the handover 4416 is degraded.

Another user experience problem in the prior art is related to unpleasant signal level changes during handover in wireless communications. The signal level may change when the telecommunications device is transferred from one network to another network. In one example, to reduce echo, the cellular network 4362 is configured to provide voice signal gain, which is lower than the voice signal gain typically implemented in wireless LAN networks. As shown in FIGS. 44A and 44B, the signal level of the second media data stream 4304 (transmitted via the cellular network 4362) is lower than the signal level of the first media data stream 4350 (transmitted via the Wi-Fi network 4314).

When the mobile telecommunication device 4316 performs handover from the Wi-Fi network 4314 to the cellular network 4362, the user of the mobile telecommunication device 4316 experiences a drop in voice volume. As a result, the user misses a part of the conversation, and it is inconvenient to readjust the speaker of the mobile telecommunication device 4316 during the phone call.

On the other hand, when the mobile communication device 4316 performs handover from the cellular network 4362 to the Wi-Fi network 4314, the user experiences an increase in voice volume, resulting in an unexpected or even unpleasant experience. As a result, the user not only feels uncomfortable but also has the inconvenience of re-adjusting the speaker of the telecommunications device.

According to an embodiment of the present invention, a wireless communication system solution is provided, which can improve the electric communication experience of the user of the electric communication device when the handover occurs. The embodiments of the present invention enable the wireless communication system to provide an integrated solution by including a mobile server. The embodiment of the present invention enables the mobile server to include at least one of a buffer system, a cross-correlation module, a server module, an extension module, an overlap and add module, and a signal level control module.

In this document, various implementations can be discussed using examples of handovers that occur between networks. However, the present invention is not limited to handovers between networks, but can also include handovers within the same network. Furthermore, in this document, examples of voice media can be used to discuss various implementations. However, the present invention is not limited to voice media, but can include different instant media, such as video streams, audio streams, and so on. The discussion is meant to be an example, and the invention is not limited to the examples presented.

Imagine, for example, a situation where a handover occurs between a Wi-Fi network and a cellular network. During the handover, the user of the mobile user can send media streams via two different connections. In an embodiment of the present invention, the mobile server may include a buffer system configured to buffer the media data stream (eg, audio or video data packets) received by the mobile system during the handover period. Using the buffer system, the mobile server can prevent the incoming media data stream from being forwarded to the destination device until the mobile server has a chance to modulate the media data stream.

In the embodiment of the present invention, the mobile server may also include a cross-correlation module. Using the cross-correlation module, the mobile server can handle the overlap of media data streams that occur during the handover. In one embodiment, by overlapping, the cross-correlation module can perform automatic correlation to determine the basic match between the packet's first media data group and the packet's second media data group. A group of packets may include at least one or more packets.

Once the match has been determined, in one embodiment, the cross-correlation module generates the media data group of the cross-associated packet by including a part of the first media data group of the packet and the second group of the media data packet. In one example, the tail part of the first media data set of the packet coming from a Wi-Fi network connection and the head part of the second media data set of the packet coming from the cellular network can be combined to generate The media data group of the cross-associated packet.

By using cross-correlation modules and overlapping and adding modules, mobile servers can generate packets of transformed media data sets, so that by minimizing or removing problems related to media stream overlap such as echo and noise, Provide the user's positive telecommunication experience of the destination device.

In one embodiment, the mobile server may further include a server module, which is used to process the gap between the two media data streams. Using the device module, the mobile server can model a portion of the buffered first media data set of the packet to cover the gap between the first and second media data streams during the handover. In one example, the gap (ie, time interval) exists between the reception of the first media data group of the packet from the Wi-Fi network and the reception of the second media data group of the packet from the cellular network. In one embodiment, in order to handle the gap, the mobile server may use a part of the first media data group packaged by the device module to generate the packaged media data group.

In one embodiment, the mobile server may also include an extension module, which is also used to process the gap between the two media data streams. Using the extension module, the mobile server can extend a part of the packet's media data set to create a new packet-extended media data set. In an embodiment, the silent group of packets may be (periodically) inserted between data packets of at least a part of the first media data group of the packet.

In one embodiment, the extension module can be used together with the device module to treat the gap. In one example, the mobile server first uses the first media data group packaged by the device module. However, if the gap is too large, the mobile server can use the extension module to extend a part of the first media data set of the packet.

In an embodiment of the present invention, the mobile server may include an overlap and add module, which is configured to generate a packetized converted media data set. The converted media data set may include cross-related packet media data sets, At least one of the media data group of the data package and the media data group of the extended package, so as to correct the overlap of the media data or fill the gaps between the media data during delivery. The overlap and increase modules can execute one or more well-known pattern matching algorithms to smoothly modify the media data stream.

In one embodiment, the mobile system may further include a signal level control module, which is configured to adjust the signal level of the packet's transforming media data group. The transformed media data group may include at least one of a cross-related packaged media data group, a packaged media data group, and an extended packaged media data group. The converted media data set of the packet may additionally include data packets that the mobile system can receive via a new connection (eg, a cellular network) after the handover. The signal level can be adjusted to be approximately the signal level of the first media data group of the packet. As a result, unexpected and unpleasant changes in the voice volume can be substantially eliminated, so that users of mobile telecommunication devices such as mobile users can continue to have the same telecommunication experience as between handovers.

By using the combination of cross-correlation modules, device modules, extension modules, overlap and add modules, and signal control level modules, by minimizing or eliminating the problems encountered during the handover in the past, The mobile server can generate enhanced media data that provide the user of the destination device with a positive telecom experience. In this way, the user now has a positive telecom experience substantially free of silence, noise, blemishes, and echo, or reverberation.

The further features and advantages of the present invention can be better understood with reference to the drawings and the following discussion.

FIG. 45 is a configuration diagram for processing media data during handover in wireless communication according to one or more embodiments of the present invention. In the configuration, both the outgoing media data and the incoming media data of the mobile user 4516 are routed through the mobile server 4518. During an electrical communication conversation layer with another party such as an outside telephone 4502 or a streaming media server, the mobile user 4516 may perform handover from the Wi-Fi network 4514 to the cellular network 4562, for example. The mobile server 4518 includes a media server and a voice engine module 4500, which can be used to modulate the media data stream (eg, the first media data 4506 transmitted via Wi-Fi 4514 and via the cellular network) during the handover. The second media data 4504 transmitted by the road 4562).

FIG. 46A is a block diagram of the architecture of the media server and the voice quality engine module 4500 according to one or more embodiments of the present invention. Figure 46A will be discussed with respect to Figure 45. The mobile server 4518 can use the media server and the voice quality engine module 4500 to process media data during the handover. When the mobile user 4516 performs handover between networks, the media server and voice quality engine module 4500 can process the first media data 4506 received from the Wi-Fi network 4514 and the first media data 4506 received from the cellular network 4562. The second media material 4504 is used to improve the telecommunications experience of the two parties.

Imagine, for example, a situation where the first media data group from the packet of the first media data 4506 and the second media data group from the packet of the second media data 4504 have been received by the media server and the voice quality engine module 4500.

In an embodiment, the media server and voice quality engine module 4500 may include a media data buffer 4602. During the handover, the media data buffer 4602 can be configured to receive and buffer media data input (eg, the packaged first media data group and the packaged second media data group) for subsequent processing. The media data input can include a set of data packets. The data packet may include text, audio, image, and/or video signals, but is not limited to this.

In an embodiment, the media server and voice quality engine module 4500 may include a cross-correlation module 4604. If the packetized first media data group and the packetized second media data group are received during the handover, the cross-correlation module 4604 can perform cross-correlation. The cross-correlation module 4604 can perform cross-correlation to determine the basic match between the packet's first media data group and the packet's second media data group.

In an example, the first media data group of the packet includes 5 data packets and the second media data group of the packet includes 1 data packet. By using cross-correlation, the cross-correlation module 4604 determines that the packet in the second media data group of the packet matches with the fifth data packet of the first media data group of the packet. In addition, assuming that the two packets are 100 bytes, the cross-correlation module 4604 can determine the best match at a hysteresis value of 50.

With the matching and hysteresis value, the cross-correlation module 4604 generates the media data group of the cross-correlated packet. FIG. 46 illustrates a block diagram of an example of a method for generating media data sets of cross-associated packets in an embodiment. The first data packet 4650 represents the fifth data packet from the first media data group of the packet. The second data packet 4652 represents the data packet from the second media data group of the packet. By using cross-correlation, the cross-correlation module 4604 has determined that the second data packet 4652 and the first data packet 4650 are the best match at point 4654, which represents a lag value of 50. In other words, from point 4654 onwards, while the quality of the data packet 4652 is improved, the quality of the data packet 4650 is reduced. Thus, the last 50 bytes represented by the block 4656 of the first data packet 4650 (assuming that there are 100 bytes in each of the two data packets in this example) and the first 50 bytes represented by the block 4658 of the second data packet 4652 The bytes are combined to form a new block 4660 on the new data packet 4662. The second block 4664 of the new data packet 4662 can be formed from the block 4666 of the second data packet 4650. In this way, the new data packet 4662 can now replace the fifth data packet of the buffered first media data set of the packet to be sent to the destination device.

Imagine, for example, a gap between the reception of the first media data group of the packet and the reception of the second media data group of the packet. In one embodiment, the media server and voice quality engine module 4500 includes a device module 4606 that can be used to process gaps. The processor module 4606 can be assembled as a part of the first media data set of the packet to generate the media data set of the packet. In one embodiment, if no media data is received from the new network (eg, cellular network 4562) within the threshold, a packetized media data set is generated. The threshold indicates the time limit or the maximum count of missing data packets. Beyond this threshold, the media data set cannot effectively and/or sufficiently fill the gap to provide a satisfactory user experience. In one embodiment, the media server and voice quality engine module 4500 includes a timer and/or a data packet counter to determine whether the threshold is met.

In one embodiment, the media server and voice quality engine module 4500 includes an extension module 4608 that can also be used to handle gaps. The extension module 4608 can be configured to extend at least a part of the first media data group of the extended packet to generate an extended media data group. In one embodiment, the extended media data group may include a data packet and a silent data packet of at least a part of the first media data group of the packet. If the media data is not received via the second network (for example, the cellular network 4562) within the threshold, an extended media data group is generated.

In an embodiment, the extension module 4608 can be implemented in combination with the device module 4606. In one example, the gap may be large. In order to handle the gap, the mobile server 4518 can first use the device module 4606 to generate one or more packetized media groups to handle the gap. If the threshold of the module 4606 has been met and the gap has not been fully processed, the mobile server 4518 can use the extension module 4608 to create one or more packetized extended media data sets to handle the gap.

In one embodiment, the media server and voice quality engine module 4500 includes an overlap and add module 4612. By including at least one of a cross-associated media data group, a media data group, and an extended media data group, the The module 4612 can be used to generate the converted media data set of the packet. In one embodiment, by including a part of the first media data group that cross-correlates the media data group and the packet, the overlap and add module 4612 can generate a new packet's transformed media data group. Referring back to FIG. 46B, the previous 4 packets from the first media data group of the packet and the newly created data packet 4662 can be combined to create a new packet of transformed media data group.

In another embodiment, by including the packaged media data group and/or the packaged extended media data group, the overlap and add module 4612 can create a new packaged conversion data group.

In addition, the overlap and increase module 4612 may include one or more well-known smoothing algorithms such as linear increase and decrease, which can be used to smooth the transition media data set of the new packet.

In one embodiment, the media server and voice quality engine module 4500 may include a signal level control module 4614, which can be configured to adjust the signal level of the packet's transformed media data group to generate a proportional 'S media information group. The signal level control module 4614 can also be configured to adjust the signal level of the second media data stream. In one or more embodiments, the signal level control module 4614 executes a well-known automatic gain control algorithm.

In one embodiment, the media server and voice quality engine module 4500 may further include a media data switcher 4616, which is assembled into a proportional media data group that outputs packets.

FIG. 47 is a flowchart of a method for processing media data during handover of mobile telecommunication devices between networks according to one or more embodiments of the present invention. Figure 47 will discuss about Figures 45 and 46. Imagine, for example, a mobile user user 4516 roaming from the coverage area supported by the Wi-Fi 4514 to the coverage area supported by the cellular network 4562. The method is implemented by implementing a media server and voice quality engine module 4500 (Figure 45).

In the first step 4702, the media server and the voice quality engine module 4500 can receive the first media data set of the packet through the Wi-Fi network 4514. In the next step 4704, the media data buffer 4704 buffers the first set of media data of the packet. In one or more embodiments, the media server and the voice quality engine module 4500 can start buffering the first media data set when the handover is urgent. In one embodiment, the urgency of handover can be detected by the mobile telecommunication device and/or the mobile server. In one or more embodiments, the media server and the voice quality engine module 4500 may begin to buffer the first media data set when the handover starts.

Once the first media data set of the packet has been received and buffered, the media server and voice quality engine module 4500 can start a timer and/or counter when the second media data set of the packet is expected to be received from the cellular network 4562 .

In the next step 4712, the media server and the voice quality engine module 4500 can determine whether the packetized second media data set has been received. The second media data group may include silent data packets and data packets containing text, audio, and/or video signals. If the second media data group of the packet has been received, the overlap has occurred, and the method can proceed to the next step 4714.

In the next step 4714, the media server and the voice quality engine module 4500 can be used to cross-correlate the two media data sets of the packet to determine the match between the two media data sets of the packet. In one embodiment, the cross-correlation module 4604 can perform automatic correlation to determine the matching between the first and second media data sets of the packet. In one embodiment, the end of the packet's first media data group and the header of the packet's second media data group can be used to generate cross-correlated media data groups. In an embodiment, the tail of the first media data group and the head of the second media data group may have the same byte size, and the size is determined by the match between the first media data group and the second media data group . One or more well-known methods such as character spacing detection can be used to determine the hysteresis value of the defined size.

In the next step 4750, by modifying the first media data set of the packet into a cross-correlated media data set including the packet, the mobile server 4518 can use the overlap and add module 4612 to create a new transformed media data packet. In one or more embodiments, the media server and the voice quality engine module 4500 can replace at least a part of the overlap of the media data with cross-correlated media data sets. In one embodiment, one or more well-known algorithms such as linear increase and decrease can be used to smooth the correction.

In the next step 4770, the signal level of the converted media data group of the packet can be adjusted to account for the signal level change that occurred during the handover. In one example, when a user on a mobile telecommunication device roams from a W-Fi network to a cellular network, the signal level can be reduced. By using the signal level control module, the signal level from the new connection can be adjusted to substantially match the signal level before the handover. Refer to Figure 48 for a discussion on how to adjust the signal level.

Once the signal level has been adjusted, a new packetized proportional media data set can be generated. In the next step 4790, the packet's proportional media data set can be forwarded to the destination device through the media switch.

Returning to the next step 4712, if the mobile server 4518 does not receive the second media data set of the packet, then in the next step 4724, the media server and the voice quality engine module 4500 can use the first media data set of the packet The modeled part is used to generate the media data set. In one embodiment, the modeled part represents the last few data packets of the first media group of the packet. One or more well-known methods such as character spacing detection can be used to select the modeled part according to the characteristics of the data packet in the first media data group of the packet. One or more well-known methods such as linear prediction models can be used to generate the media data set.

Referring back to the next step 4724, if the threshold has been reached, then in the next step 4736, the media server and the voice quality engine module 4500 can use the extension module 4608 to generate the packetized extended media data set. One or more well-known methods can be used to generate the extended media data group of the packet, such as periodically inserting one or more silent data packets into at least a part of the first media data group of the packet.

In one embodiment, when the gap is so large that one or more media data cannot effectively and/or sufficiently fill the gap generated during the delivery to provide a satisfactory user experience, an extension module can be used.

In the next step 4760, by using at least one of the media data group and/or the extended media data group to create a new packetized converted media data group, the overlap and increase module 4612 can manage the gap during the delivery period. The overlap and increase module 4612 can perform one or more well-known smoothing designs such as linear gradual increase and gradual decrease to smooth the correction. By using the packaged media data set and/or the packaged extended media data set, one or more silences and noises generated by the gap can be substantially reduced or eliminated.

In the next step 4770 again, the signal level control 4614 can adjust the signal level of the converted media data group of the packet to generate a proportional media data group. By adjusting the signal level, the user can experience a substantially consistent signal level (eg, voice volume) during the handover.

In step 4790, the media server and voice quality engine module 4500 may output the proportional media data set sent to the destination device.

FIG. 48 is a flowchart of a method for controlling the signal level of a mobile telecommunication device during a handover period according to one or more embodiments of the present invention. This method may represent step 4770 shown in FIG. 47, and may be executed by a signal level control module such as the signal level control module 4614 shown in FIG. 46a.

In the first step 4800, the signal level control module 4614 can receive the packetized media data set. In one embodiment, the packaged media data group represents the transformed media data group of the package generated by the overlap and add module 4612. In another embodiment, the packaged media data group represents a second media data group from a second media data stream.

In the next step 4806, the signal level control module 4614 can calculate the energy of the media data group by, for example, adding up the absolute value of the signal amplitude of the media data group. In one embodiment, the square value can be used instead of the absolute value.

In the next step 4808, the signal level control module 4614 can determine whether the energy of the media data set is greater than the noise bottom layer. If the energy is not greater than the noise bottom layer, the media data set can be regarded as background noise, and control can be transferred to step 4828, in which the media data set is transmitted as the output of the signal level control module 4614.

However, if the energy is greater than the noise bottom layer, in the next step 4810, the signal level control module 4614 can adjust the energy ratio of the media data group. In one example, the energy ratio is adjusted by averaging the energy signal level in the media data set to generate proportional energy.

In the next step 4812, the signal level control module 4614 determines whether the proportional energy is greater than the high energy. In one embodiment, the high energy may indicate the upper limit of the energy range of the first media data group of the packet. In one embodiment, the energy range of each electrical communication device can be determined empirically.

If the proportional energy is greater than the high energy, then in the next step 4814, the signal level control module 4614 can provide a reduced gain to reduce the energy of the media data set. In one example, the packet transition media data group is louder than the upper limit; in this way, in order to eliminate the unexpected and unpleasant volume increase that the user will experience on the destination device when receiving media data, the packet transition media can be reduced The volume of the data set.

If in the next step 4812, the proportional energy is lower than the high energy, then in the next step 4824, the signal level control module 4614 additionally determines whether the proportional energy is lower than the low energy. In one embodiment, the low energy indicates the depression of the energy range of the first media data group of the aforementioned packet. If the proportional energy is lower than the low energy, then in the next step 4836, the signal level control module 4614 can provide increased gain to increase the energy of the media data set. In one example, the packet conversion media data set is softer than the minimum limit. Therefore, in order to eliminate the inconvenience of increasing the speaker volume in order to hear the incoming media data on the destination device, the packet conversion media data set can be increased The volume.

In the next step 4826, the signal level control module 4614 can generate a proportional media data set having a signal level comparable to the range of the first media data stream.

In the next step 4828, the signal level control module 4614 may output the proportional media data set, for example, to the media data exchange 4616 (as shown in FIG. 46A), which then routes the media data to the destination device.

As can be understood from the foregoing, one or more embodiments of the present invention provide a wireless communication system capable of handling overlaps and gaps that occur during handover. By implementing various methods such as cross-correlation and extension, the wireless communication system improves the user's telecommunications experience by substantially eliminating noise, defects, and echo. In addition, the wireless communication system adjusts the signal level change that occurs when the handover occurs, so as to substantially eliminate the unpleasant experience that occurs when the signal level changes unexpectedly.

C. Use the control rules and preferences of managers and users to automatically establish point-to-point and point-to-multipoint multimedia conference phones (conference phones)

1. The present invention can be applied to the field of point-to-point and point-to-multipoint multimedia conferences using media communication servers. Figure 5A-B depicts the method used in the media communication server to automatically establish point-to-point and point-to-multipoint multimedia conference calls using the control rules and preferences of managers and users.

2. The current organization used to create PP or PMP media phones is not driven by any user status or preference. If one or more participants are not available, the media server will make the chairman leave a voice mail. The only course of action for the chairperson is to keep trying until all participants are available or rely on one or more participants to be able to call back, and then try the meeting in time at the last point. This process is inefficient and takes up time and resources and is often difficult to manage. The only organization is to plan and schedule the meeting schedule in advance of time so that all participants are available-however, there is no guarantee that they will be available at the time of the call. The above-mentioned problems are caused by the lack of coordination and information between the presence server and the media communication server in the enterprise.

3. The conference phone (RC) allows users to establish point-to-point (PP) or point-to-multipoint (PMP) media phones (voice, video, or multimedia) without specifying the time-according to all participants involved The availability (determined by various factors including presence information, network availability, etc.), the media communication server determines the call establishment time, and prompts all participants before establishing a request call. Significantly strengthen the concept of availability to take some user-driven parameters into consideration, so that the media communication server can make more precise decisions about when to call based on the preferences of all participants. Some of these additional preferences and rules include network manager control rules based on user preferences such as time, media selection, call participants, call priority, etc.

4. The advantages of the present invention include the establishment of PP and PMP conference calls that take all corporate rules, participant preferences, and availability into consideration to be automatically scheduled.

Since the call is established at the right time to replace the voice mail that relies on priority-based communication, it can communicate effectively and competently within the enterprise.

6. Overall architecture Figure 5A is a high-level overview of the RC architecture. The RC framework has components of a media communication server and an RC user. The users in this example can be telephone receivers, softphones, PDAs, etc. RC users are responsible for managing users and the user interface used to make RC requests. If one or more participants are considered "unavailable," it then allows the user to convert a normal PP or PMP call into an RC request. Similarly, when the server does establish an RC call, the user will prompt the user and respond based on the user's feedback. On the server side, the RC logic includes the collection and correlation of information from the attending server, the applicable rules of the enterprise configured by the administrator, and the preferences of the user configured by the individual user.

When the user makes a PP or PMP call from the user, the user software will check the availability of the participants and will prompt the user if one or more participants are not available and whether they are willing to make an RC request. The user can also specify how long he/she will keep this request. The media communication server will track the RC request. When the server determines that all participants are available, it will prompt everyone if they are speaking to the call. If all participants successfully confirm the reception, the call is made. If every participant rejects the request, the RC call will fail and all participants will be notified of the result. Users can also ask for a list of pending RC calls (their initiator and they are participants), and cancel any requests they initiate. The server will also use corporate and user-defined rules to determine the best time to talk to the call.

7. The rules and preferences of managers and participants for RC availability and RC establishment decisions are based on the rules and preferences controlled by various users and managers.

The following rules and preferences can be used to determine participant availability before proceeding with RC.

. No preference for participating in any RC service participant. Participants may not participate at all or specify the time period during which participants do (or do not) wish to receive RC calls.

. Participant preference-based on RC priority, RC owner, participant list, date, network preference (enterprise Wi-Fi, public Wi-Fi, cellular, etc.), Outlook calendar timetable, etc.

. The users personal "permitted" and "blocked" user lists are used to restrict the RC calls they want to participate in.

. The RC chairman's time preference for when to make a call.

. Manager controller corporate rules-RC honeycomb privileges, user RC privileges, etc.

8. The logic of scheduling and performing RC calls in the media communication server.

Various factors control the logic used by the media communication server to process and build.

. Integrate the presence server in the media communication server with the corporate and participant-driven rules and preferences used to determine the availability and time of participants for RC.

. Support RC's mandatory and random participant list.

. The participants ability to accept or reject RC early. Even before the RC is established by the media communication server, the user can still unconditionally accept or reject the RC request.

. Integrate the Outlook program to use its calendar as the input to the availability decision logic, and integrate the participants calendar to reflect the status of RC calls and any pending RC requests.

. In addition to the availability and time of the request, the ability to perform RC based on the priority of the request.

. When a particular participant is busy, let random RC calls can be made-use call waiting to inform and invite them to the RC.

When the server receives the RC request, it performs a confirmation check to make sure that all participants included have signed the RC service. In addition, the server checks to make sure that the critical performance is not missed. If there is a valid RC request, the server will put it in the queue and send an RC response of the RC Id and status associated with that request. If the RC request is found to be illegal or unacceptable, the server will send an RC response with the reason for the failure back to the initiator.

In the event that all participants are available, the server will generally handle this request to any other PP or PMP call-it will establish a media path and send a successful RC response message with this status to the initiator.

The RC server will periodically discuss a list of important RC requests to determine if any of them are ready for call establishment. The flowchart of Figure 2 captures the logic used by the media communication server to select an RC request suitable for establishment.

Once a list of RC requests is determined to be suitable for establishment, the RC-enabled communication server will start the process of establishing individual media paths. Send an RC reminder message to all participants included in the call. The RC reminder will include details about the chairperson, participant list, call summary, etc. The server will collect the RC prompt response from the user. The server will also keep track of any messages sent by participants. If any participant has rejected the RC prompt or there is a pause (no response from the user), the server will determine that it is a failed RC call attempt, and will send the canceled call and, if any, the response from the user. RC cancel notification to all participants who responded and the chairman informed them. In the event that all participants accept the call, the RC server puts the PP/PMP request together with all the information, and the media exchange layer needs and forwards this request to the media exchange layer to establish the call. The RC server will also send a notification that the call is established to all participants in the RC process.

9. Conclusion The services provided by the RC media server will make the communication within the enterprise more effective and save time for employees who must rely less on voice mail. It is especially suitable for employees who are mobile and cannot be tied to a desktop phone. When deciding the best time to conduct a conference call, the media communication server takes the action point of view into consideration.

10. The advantages of the present invention include: Efficiently establish automatically scheduled PP and PMP conference phones that take all corporate rules, participant preferences and availability into consideration.

. Effective and capable communication in the enterprise, because the call is established at the right time instead of relying on voice mail to get calls back and forth and regularly to check availability. This is particularly suitable for mobile work that cannot be tied to a desktop phone.

. In addition to the standard voice mail service, if one or more participants are not available at that time, the user provides the ability to convert simple PP and PMP calls into RC requests.

. Integrate the corporate presence server in the media communication server with corporate rules and user preferences.

. Integrate Outlook and other business processes to allow the media communication server to manage conference calls like a conference.

11. Adjusting the conference while citing logic in the media communication server to adopt user availability and preferences will generate fewer failed call attempts, and will also ensure that the calls made meet what all participants want. the goal of. This method enables the media communication server to associate the presence information from the presence server with the manager-controlled corporate rules and user-controlled user preferences to provide the best time for PP or PMP conference calls. This logic of determining the best time produces effective meetings within the organization and will also save time and money spent on providing this service.

12. RC User Technical Specifications The diagram in FIG. 5B is a very high-level timeline diagram of the message exchange between the user and the media communication server during the establishment of the RC request and the subsequent RC establishment progress. The following activities will be supported on RC users for RC capabilities.

a. RC request processing b. RC response processing c. listing and correction/cancellation of important RC requests d. early response (acceptance/rejection) of important RC requests e. RC notification message processing f. RC in progress and RC cancellation notice Message processing

13. RC Server Technical Specifications The diagram in Figure 5C captures the core logic of the RC server to support this function.

a. RC request processing b. Automatic conversion from standard PP and PMP to RC request based on participant availability and preference c. Periodic RC request processing-timer and RC request established according to all criteria specified previously d. Present RC prompts and collect responses as part of RC phone establishment e. RC media path establishment

For detailed description, the embodiments of the present invention are related to teletype conference management. In conventional technology, the establishment of teleconferences is a tedious, manual, and time-consuming work that requires people's participation and a lot of patience. For example, if there are five participants, one of the participants or his/her assistant (referred to as the "helper" in this article) must use e-mail or IM or another communication such as telephone before establishing a teleconference The organization or personally contact the participants to obtain an agreement on the telex conference and method.

For example, a human helper can use an email program to access the calendar of each participant (if such a calendar is available). The helper must then establish an appointment for each participant and obtain their agreement regarding the time and method of the telex meeting. Once all parties agree, the helper will establish teleconference equipment, typically with a telephone service provider or one of the designated participants as the teleconference leader who is responsible for teleconducting the teleconference held by others When the specified time arrives.

When the time to implement the teleconference arrives, each participant is responsible for calling in to the designated telephone number that the helper has established so that he/she can participate in the teleconference. If a participant does not know how to call in and/or is not familiar with the procedure of entering the necessary user id/password, more time is wasted to help that participant make a teleconference call. This is usually an example when one of the participants is calling from another country and a special dialing sequence is required. In the designated teletype meeting time, if one of the participants cannot attend and that participant is required for the teletype meeting, the teletype meeting must be rescheduled so that all necessary participants can participate.

Moreover, the conventional technical method of establishing teleconference calls does not take into account the preferences of individual participants, such as their preferred communication mode or their time-dependent communication mode (e.g., mobile phones from 7 am to 10 am, from 12 am to 12 am). IM from pm to 1 pm, office phone at other times). In the conventional technology, when a human helper writes a letter electronically or makes a phone call to try to establish a teleconference, this type of coordination must be handled manually and individual participants individually.

According to the embodiments of the present invention, a computer-implemented method and device are provided to automatically establish a telex conference between a plurality of telex participants. The embodiments of the present invention automatically determine the availability and preferences of each participant. If it is found that all participants are available during the specified time in the allowable telex window, the implementation of the present invention utilizes the conference phone (RC) server to use the better communication mode of individual participants at the time of inquiry The availability of all participants is automatically confirmed. If all required participants agree to implement the conference, the embodiment of the present invention connects the carrier channel to each participant so that the telex conference can continue.

When the term is used here, the conference call means a conference call that is automatically established and started based on the parameters entered by the helper in advance. The establishment is partly automatic, because the RC server monitors the attendance status of the participants, and uses the preferences and preferred communication modes of the participants to implement the teleconference. The initiation part is automatic, because if the parameters of the teleconference have been completed, when the RC server decides that the teleconference can be implemented, the RC server will call each participant.

In one embodiment, enterprise-wide RC rules may be applied to modify the preference settings that have been set by some users. For example, if a senior manager wants to establish a conference call at a specified time, the corporate RC rule can ignore the preference settings that have been set by lower-level employees and not hold a teleconference at that time. Enterprise RC rules can also be used to strengthen other RC policies, such as the authorization level for each invited participant, whether to allow long-distance telex meetings, and what to do when certain participants partially overlap or conflict with telex meetings or are unavailable. Enterprise RC rules may be simple or complex depending on the needs of the designated enterprise.

Users can also indicate preferences regarding their general availability and preferred communication mode, for example. In some instances, users can block or permanently decline specific types of teleconference requests. The user can also specify time-dependent communication preferences, so that if RC occurs in the morning, for example, the user can be contacted on the user's desktop phone, so that the RC at night should be routed to the user's cellular phone .

The presence server tracks the availability of users to determine whether all users who need it are free to implement RC. Using the presence server, the embodiment of the present invention can track whether the participant is powered on and/or has a specific location and/or communication method specified by the participant. If everyone is available, and their availability is consistent with the window that the helper has instructed to implement the appropriate window of the RC, the embodiment of the present invention automatically asks the participants and confirms their availability for the conference call. If all parties confirm, the embodiment of the present invention establishes a carrier channel to each participant, connects the carrier channel together to establish an RC, and the RC can continue.

The features and advantages of the present invention will be better understood with reference to the drawings and the following discussion.

FIG. 19 is a high-level logic block diagram of an automatic conference phone environment 1902 according to an embodiment of the present invention. In FIG. 19, a mobile server 1904 is shown, which represents the physical hardware implementing the RC server module 1906. Those skilled in the art should understand that if desired, the RC server module 1906 can be implemented on a separate bracket.

The figure shows multiple RC users 1908, 1910, 1912, and 1914. Conference phone user 1908 represents a mobile phone handset; RC user 1910 represents a PDA; RC user 1912 represents a wired IP phone; and RC user 1914 represents a software user running as a softphone on a laptop or desktop computer. Each RC user 1908, 1910, 1912, and 1914 can run together with the RC server module 1906 the RC user software that can be used to create a conference call to indicate their preferences. The RC server module will process and/repost this presence information to one or both of the applicable internal presence server and external presence server. The RC user's preference can also be set in the user preference database 1924 through the RC server module.

Appropriately authorized users can also use their RC users to set corporate RC rules (in the corporate rules database 1926). Those skilled in the art will understand that any computing device that can execute the RC user software used to interact with the RC server module 1906 can be used. In addition, the enterprise administrator can use the management interface provided by the RC server module to set the enterprise RC rules in the enterprise rule database 1926.

When the RC user 1908 wishes to establish an RC, the RC user 1908 communicates with the RC server module 1906 to indicate the time block of the rectangular telex conference (for example, from 8 am to 12 pm on Thursday, December 1, 2007, and Thursday). Communicate the duration of the meeting (for example, 30 minutes), the required participants, and the subject of the RC (optional). If desired, the RC user 1908 can specify the identities of necessary participants and random participants. In one embodiment, the request of the RC user 1908 can be automatically communicated to all necessary participants, so that such necessary participants are aware of the pending request. In another embodiment, the request can be automatically inserted into the electronic calendar (for example, via email or IM calendar event request), so that the requested RC can be posted to the participants calendar, and the participant knows the pending ask. If you want, you can ask the participants for their opinions or the RC that accepts or rejects the proposal.

At the beginning of a specific RC window (for example, from 8 am to 12 pm in the above-mentioned 2007, 12, and 1), the RC server module 1906 queries all through one or both of the internal attendance server 1920 and the external attendance server 1922 Whether the participant is available. The availability of designated participants can be inferred from the participants calendar and/or log-in activities or by applying corporate conference call rules/user preferences. If all participants are not available, the RC server module 1906 continues to monitor one or two of the attending servers to detect when all participants are available.

When all participants are available, use the RC server module 1906 of the rules and preferences established in the corporate RC rule database 1926 and/or the user preference database 1924 to send notifications to each participant (e.g., PDA 1910, wired IP phone 1912, and soft phone 1914) to confirm that RC has arrived and RC is about to start. If all participants agree, the RC server module 1906 uses the media signaling layer 1930 and the media exchange layer 1934 to complete the carrier channel connection between the participants. For example, the RC server module 1906 can use the switching module in the mobile server 1904 to establish a call between each participant to the media server 1904 or to the enterprise PBX, wherein individual carrier channels can be interconnected to establish an RC. After that, RC can start.

On the other hand, if one or more participants decline, the RC server module 1906 returns to the monitoring state to continue to monitor the next opportunity to establish an RC with the participant when it is found that all participants are free. In one embodiment, the RC server module 1906 inquires the declined user about the time when the declined user wishes to implement the RC, and uses that time to re-create the RC. If the participant continues to decline, if necessary, the manual helper can be selectively notified of manual interference to help the start of the telex conference.

FIG. 20 is a diagram of the steps adopted by the RC server module 1906 when setting the RC phone according to the embodiment.

In step 2002, the RC server module 1906 queries one or both of the internal presence server 1920 and the external corporate presence server 1922 to determine whether all participants are available.

If all participants are not available (the no branch of 2002), the method proceeds to step 2004 to inquire whether the RC period expires. If the RC period has not expired, the method returns to step 2002 to continue to monitor whether all participants are available.

On the other hand, if the RC period has expired (the 2004 branch of yes), the RC cancellation process (2050) is initiated, in which the helper informs that the RC request has expired. Due to the unavailability of participants during the RC request period, Unable to create RC.

If all participants are available according to the presence server (the yes branch of step 2002), the method proceeds to step 2010 to add the currently pending RC requests to the qualified RC request list.

The difference between a pending RC request and a qualified RC request is that a pending request is a request that has not yet confirmed the availability of all participants, while a qualified RC request is a request that has confirmed that all participants are available.

For each qualified RC request, the processing proceeds as follows. Make the same decision for all eligible RC requests. In addition, identify overlapping participants. When this term is used here, overlapping participants refer to participants with overlapping eligible RC requests. For example, if a designated participant is included in two different qualified RC requests, then the two qualified RC requests have overlapping RC request cycles. Because a designated participant cannot be in two different RCs at the same time, it will happen Potential conflict. Therefore, the overlapping participants are identified and thus the RC request subgroup is established.

In one embodiment, each participant is only assigned to a single subgroup. That is, no single participant is assigned to two different subgroups. Therefore, the RC associated with each subgroup can be performed independently of other RCs associated with another subgroup. For example, suppose there are four qualified RC requests that are qualified to establish a teleconference (that is, all participants have confirmed their availability). Assume RC1, the participants are A, B, and C; for RC2, the participants are A, C, and D; for RC3, the participants are W, X, and Y; and for RC4, participate Those are D, E, and F.

In this example, two subgroups can be established. The first subgroup includes RC1, RC2, and RC4 (including participants A, B, C, D, E, and F), and the second subgroup includes the third teletype conference. RC3 (including participants W, X, and Y).

In step 2024, for each qualified RC request, it is determined whether any participant is included in multiple qualified RC requests. If not, the method proceeds to block 2026, where RCs for those qualified requests are established, that is, those RCs that include participants not included in any other qualified RC requests. In this example, a third RC including participants W, X, and Y can be established in step 2026.

On the other hand, if the participant is included in multiple RC requests (as in the example of RC1, RC2, and RC4), the method proceeds to step 2030 to classify and identify the best non-overlapping RC request subgroup. For example, referring to the example here, because RC1, RC2, and RC4 are identified as including overlapping participants, an algorithm can be established to determine whether some RCs have higher priority than other RCs, and whether they are specific in subgroups The RC does not have overlapping participants etc.

In this example, it is determined that RC2 and RC4 do not have overlapping participants. However, the first teletype conference RC1 (including participants A, B, and C) and the second teletype conference RC2 (including participants A, C, and D) and the fourth teletype conference RC4 (including participants D, E, and F) have conflicting participants. Exemplary algorithms can vote to recommend implementing RC2 and RC4 to maximize the number of telex conferences that can be implemented simultaneously.

However, if another algorithm can determine that RC1 contains more urgent topics or more important participants or group of participants, it will take priority. These different algorithms for resolving conflicts are just examples, and can be simplified or complicated depending on the needs of the specified enterprise.

After this example, the method proceeds to step 2032, where RC phone establishment processing for RC requests from non-overlapping subgroups is performed. In this example, the RC phone establishment process for RC2 and RC4 is started, and then the RC phone establishment process for these two telex conferences is directed to 2026. RCs that cannot be established can be returned to the list of pending RC requests or can still be treated as qualified RC requests if desired.

Fig. 21 is a flow chart of a simple telephone call including two teletype conference participants according to an embodiment. In this example, user A and user B are requested to participate in RC through the pending RC request, and the RC request cycle has started. Moreover, for the purpose of this example, the starting state of user A is available, and the starting state of user B is not available. As shown in FIG. 21, user A makes an RC request to the mobile server for RC (2102). The mobile server 2102 responds with a conference call ID (RCID) at 2104, for example, 1900 in this example.

Cycle 2106 usually deals with RC request processing. Cycle 2108 deals with the processing of pending RC requests. Therefore, user A asks that user A has specified a list of pending RC requests to a participant. Assuming that no other user requests user A to participate in another RC, the mobile server returns that user A is one of the requested participants in the teleconference (2110). Cycle 2112 is related to the confirmation cycle, where the attendance server has indicated that the participant has become available, and the RC server module confirms whether the participant wishes to implement the teleconference. Therefore, the availability of user B is updated with the presence server in the mobile server (2120).

Indicate the availability of the two users A and B, and then the mobile server 2102 sends a prompt confirming whether the user A and the user B wish to implement the teleconference at this time. Give this icon to user B and user A with reference numbers 2122 and 2124, respectively. Then, user B responds (2126) and user A also responds (2128). If the two users accept the teleconference request, the processing is performed according to the steps shown in cycle 2140. If one or both of the participants decline, the processing is performed according to the steps shown in cycle 2150. In cycle 2150, if one or both of user A and user B are rejected by the conference call server module (implemented in the mobile server in this example), then the mobile server sends The cancellation notice (2152/2154) instructing to reject the request is given to one or both of user A and user B. If the pending request has been suspended, that is, the RC request period has expired, a notification will also be sent.

On the other hand, if the two participants A and B agree to implement the teleconference, the mobile server 2102 sends notifications (respectively 2142 and 2144) to the user B and the user A to indicate that the teleconference is to be established.

Except that the mobile server is now shown as including the presence server, phone control, and RC server as constituent components, FIG. 22 is the establishment of the parameters specified in the example of FIG. 21 according to the embodiment of the present invention. The telephone flow chart of telex conference. Therefore, in the RC request processing cycle 2206, the user A indicates its availability status to the presence server and the RC request, and the RC request is communicated between the RC server and the user A. During the query pending RC request cycle 2220, as shown in the figure, the communication between user A and the RC server includes a request for user A's pending RC list and a response with an RC list that includes user A . During the reminder period 2240, this period is a period during which the RC server is trying to confirm with all participants who are now available and that the teleconference should be implemented. Therefore, the availability of the communication user B between the user B and the presence server, and the current status of the communication user B of the presence server to the RC server. Confirm the prompts of the telex conference are communicated from the RC server to users A and B respectively, and the responses from each user are communicated back to the RC server. In response, one or two users can accept or reject the requested teleconference. If one or two users reject the requested meeting from the RC server, the RC server respectively sends a cancellation notice to the user (if rejected).

On the other hand, if the two participants accept, during the accepting RC call period 2270, the RC server respectively sends the notification in progress to the two participants. After that, the RC server instructs participants A and B to now establish the teleconference call control message and call control communication. Then, the phone control uses, for example, the SIP invitation message of the participant to enable the communication device for the user A and user B meeting to start establishing a teleconference.

As can be understood from the above, the embodiments of the present invention eliminate manual and time-consuming steps, including manually confirming the time and availability of the telex conference with each participant through a communication mode (e.g., Outlook, IM, In person, prior e-mail, or prior telephone) to establish a teleconference. The embodiments of the present invention also eliminate the need for manual helpers who manually connect with each participant or make a manual call for the participant, and also eliminate possible errors or omissions. By using a combination of presence server, corporate RC rules, and user preferences, using a communication mode that is better for users and business rules established by the company, during the RC request cycle, users can communicate when they are free user. In this way, the teleconference can be established in an effective and automatic manner, eliminating the wasted time and trouble and/or frustration on the part of the helpers and/or participants of the teleconference.

D. Call routing through recipient identification

1. More and more companies allow their employees to use their cellular phones for business. Employees use their cellular phones to put calls into the enterprise to access enterprise voice features, such as checking voice mail, setting call forwarding numbers, and so on. In these examples, the enterprise server authenticates the caller via IVR (Interactive Voice Response). This is an example of an employee extracting employee-specific information from the company.

2. In the future, many corporate features will be pushed to cellular phones such as personal information management (PIM) via voice, e-mail voice via phone, etc. In order to push all these features to the cellular phone, the enterprise server needs to establish a connection to the employee's cellular phone by initiating a call from the enterprise. This type of connection assumes that employees of the company have their cellular phones. In the case where employees of a company do not own their cellular phone or have started using another cellular phone (borrowed, substituted, or replaced phone), the mobile application software creates the following problems: a. The company risks releasing ownership/personal The risk of information to unauthorized persons. This information includes phone calls to employees, e-mails via voice mail, PIM information, etc.

b. Furthermore, in the example of a telephone call initiated by an employee without returning a call to the enterprise server, the cellular operator voice mail will return the call and record the enterprise email and voice mail in his mail box.

3. Method-implement the present invention by designing a cellular phone handset application program that authenticates users. The authentication logic is summarized as follows: a. At the beginning of the application, it reminds employees of authentication information such as user name and password. This information can be stored in the app for a limited period of time as a cache. The cache will expire after the configured time period.

b. When the corporate server calls an employee, the application will call back before the phone rings. If the user's logical information has expired, the application will get the user's attention (for example, by ringing a bell) and ask the user to authenticate again. If the users logical information has not yet expired, its cached authentication information is used. The application uses DTMF to transmit a series of (reversed caller ID-RID) numbers to the server to identify the user who is using its cellular phone. Use the user name and password entered by the employee to derive this sequence.

c. The server uses the same user name and password prepared on the server to calculate RID to authenticate employees.

d. If the RID matches, the server is assumed to be an authenticated employee using a cellular phone and starts mobile applications such as phone calls, phone calls, email voice, voice mail, etc.

e. If the server does not receive the RID within a predetermined interval after receiving the call (OFF-HOOK equivalent), or if the RID does not match, it can be assumed that it is not an authenticated user on the cellular phone. At this stage, in the case of a single voice mail application, the phone call is either terminated or routed to the voice mail system.

4. Advantages-Using the above-mentioned mobile application method, the enterprise server can achieve the following advantages: a. Enterprise information protection-the enterprise server can distinguish between authorized users who use cellular phones and unauthorized use by using RID Voice mail of the operator or operator. For example-i. Transparent phone routing-users have dual modes (Wi-Fi and cellular phones) with Internet phones. In terms of incoming call routing, if the server decides that it cannot reach the user via VoIP, it can choose to connect via a cellular network. This method will ensure reachability to authorized users ii. VoIP to cellular delivery-this method ensures that they are the same employee who is connected via VoIP.

b. Single voice mail-if the employee chooses not to call the incoming cellular phone from the corporate server-this method ensures that the voice mail will not be left by the cellular operator voice mail system. Because the server can determine that the operator's voice mail system has answered the call that was not indicated by the RID at the beginning of the connection, the server chooses to hang up the cellular phone or route the call to the internal voice mail, thus enabling a single voice mail.

As mentioned above, in order to be more detailed, as in the process of specifying a phone call, regardless of whether the caller has placed a call to the employees extension number in the enterprise to replace the employees mobile user, the mobile server is in the public cellular network. The ability to seamlessly connect from mobile servers to employees' mobile users. For example, if a call has been placed on the extension number of an employee in the company, and the employee registers its mobile user (for example, registering its public mobile user number) as a call that can be forwarded to the extension number of the employee in the company If the call is made, the call from the caller can be connected to the mobile server from the callers telephone receiver as a process of the call. As another process of the call, the mobile server can use its own switch or the switching capability of the PBX to connect back to the public cellular telephone network, and to the employees mobile users through the public cellular telephone network. This is true even if the call is made to the extension number of the support worker in the enterprise.

As another example, employees can have dual-mode phones and roam away from Wi-Fi areas, such as going out from the business area of a company to areas that are not covered by Wi-Fi but are covered by the public cellular telephone network. In this example, in the middle of the call, a handover will occur. The mobile server and/or the employee's dual-mode phone can be used to realize that the employee's dual-mode phone has roamed outside the W-Fi coverage, and the call needs to be through a public cellular phone. The network continues to the employee's dual-mode phone (now operating in cellular mode).

Although this ability represents a significant increase in convenience and ease of managing employee phone attendance, it still creates some interesting challenges. One of the challenges is related to the security of voice and/or data that may or may not be in the actual possession of the employee. For example, if the mobile server is stolen or if the mobile user has lent it to other people such as an employees friend or relative, the voice and data transmitted to the mobile user poses a security risk. Although based on past experience and conditions, the caller has called the employee's corporate extension number and expects to terminate the call within the company, the risk is increased because the caller may not end the call outside the company.

Another challenge is related to voice mail management. Because the caller makes a call to the employee's corporate extension number, the typical expectation is that if the employee does not answer the call, the corporate voice mail system will pick up and be used to store the voice mail that the caller wishes to leave. In some cases, the employee may not answer the call because, for example, the phone is not turned on or there is no connectivity to the cellular network or the employee simply cannot hear the ringing to answer the call. Moreover, because the mobile server is transparently and seamlessly delivered, if the employee cannot answer the call or has roamed away, it will call to the public mobile user number to terminate the call through the cellular telephone network. Instead, the public The cellular voice mail mailbox of the cellular service provider picks up the message.

According to an embodiment of the present invention, a Cellular Receiver Authentication (CRA) technology is provided to authenticate the identity of the called party before completing the call between a mobile server operating in a public cellular network and a mobile user . In the context of this technology, mobile user refers to only cellular phones that operate mobile software so that mobile users can connect through the mobile server, or refers to dual Wi-Fi that has roamed out of Wi-Fi range /Honeycomb mode phone.

According to the embodiment of the present invention, before completing the call process between the mobile server (which may represent the mobile server switching function or the combination of the mobile server and the enterprise PBX according to the implementation), the cellular receiver is identified. During the authentication period, the recipient is assigned a fixed amount of time to provide satisfactory authentication information to the mobile server.

If the authentication information provided by the recipient is unsatisfactory, or if the appropriate authentication is not reached within the specified authentication time, the mobile server does not establish a transmission channel between itself and the mobile user through the public network connect. For its part, even if the employees mobile user is not seen/stolen, or if the employee lent someone elses mobile user, without proper identification information, the establishment of a transmission channel between the mobile server and the mobile user will be prohibited . In this way, voice/data security can be ensured.

In addition, if the employee does not answer the cellular phone, the mobile server will not receive the authentication information during the specified authentication period. In this example, no carrier channel is established between the mobile server and the mobile user, so voice/data calls will not be stored in the voice mail mailbox of the public network. Instead, if the employee is unable to answer the cellular phone (that is, unable to answer the call), the mobile server logic will instead complete the data transmission connection to the employees corporate voice mail box, so that the caller can be in the corporate voice mail box. Leave a message.

In one embodiment, the employee has previously entered and cached information (eg, launching the user application for the first time). In this way, even if the employee has not answered the cellular phone, the identification information about the recipient of the call will still be sent to the mobile server. In this way, the authentication will be performed and the mobile server will still establish a carrier channel to connect the voice/data call to the voice mail mailbox of the public network.

In one embodiment, the cached authentication information can be set to a periodic expiration (for example, every 24 hours, every hour, a time configurable by the user). For its part, even if the employees mobile user is lost/stolen, or if the employee lends the mobile user to others, unauthorized third parties cannot establish a connection with the mobile server. In addition, once the cache has expired, the next time the employee wants to establish a connection with the mobile server, the employee must re-enter the authentication information.

In one embodiment, an embedded coding technique is used to provide authentication from the mobile user to the mobile server. Such coding techniques may include, for example, DTMP (Dual Modulation Multiple Frequency) signaling. In one example, the employee can use the small keyboard of the mobile user to enter the required authentication information. In another embodiment, the user may provide the authentication information verbally, so that the authentication information is processed by voice recognition technology. As long as the necessary authentication data can be satisfactorily transmitted by the user through the mobile user and received by the mobile server during the specified authentication period, it can also be used such as GPRS (Global Wireless Packet Service), GSM (Global mobile phone system), CDMA (Code Sector Multiple Access) and other encoding types.

In one embodiment, both the mobile user of the employee and the software running on the mobile server implement the same mathematical function to calculate the authentication result. For example, the software on the employee's mobile user can calculate the sector result as a function of the user ID, password, and/or any other authentication data that the recipient has previously created with the mobile server. The mobile server can also calculate the same mathematical function operating with the same parameters.

When the mobile server receives the authentication result calculated by the mobile user software (it will be transmitted to the mobile server in encrypted or unencrypted form), the mobile server compares the received authentication result with the mobile server internally The calculated authentication result. If the two authentication results match, the authentication is regarded as successful, and a carrier channel between the mobile server and the mobile user can be established.

In one embodiment, the mathematical function used to calculate the authentication result may also use temporary values. For example, mobile servers can provide temporary values to mobile users as part of the authentication process. The use of temporary values further enhances data security because such use helps minimize the impact of replay attacks.

The specific authentication techniques discussed above are just examples. However, it should be remembered that authentication can be done in any reasonable way, and not all situations require the use of user ID, password, and/or the aforementioned temporary values. The most important thing is that before the mobile server establishes a transmission channel between itself and the mobile user through the public cellular telephone network, the mobile server confirms the cellular receiver (instead of or in addition to the identity of the mobile user) Outside) identity.

The features and advantages of various embodiments of the present invention can be better understood with reference to the drawings and the following discussion. FIG. 23 is a telephone flow chart of a cellular receiver identification procedure that occurs when a caller makes a new telephone call to the receiver through the receiver's enterprise extension number according to an embodiment of the present invention. In this example in Figure 23, the recipient has roamed outside the Wi-Fi coverage area (in the case of dual-mode Wi-Fi/cellular mobile users), or the recipient is not at his desk and has designated a call forwarding To its mobile users.

Referring to FIG. 23, caller A informs mobile server 2320 that caller A wants to connect to the extension phone associated with receiver B by using a signaling protocol. For example, caller A can call the phone number 111-222-3333 associated with the enterprise, and further enter the extension number associated with the recipient (such as 4444). In FIG. 23, the reference number 2302 is used to illustrate the sending.

The mobile server 2320, which must terminate the call through the public network, reaches the mobile user of the recipient B via the mobile user network and contacts the mobile user of the recipient B through the sending paths 2304 and 2306.

Moreover, the attempt to establish with the recipient B also starts the authentication cycle, as shown by the reference number 2314 in FIG. 23. If appropriate authentication is received within the designated authentication period 2314, the mobile server 2320 establishes a mobile user carrying a channel to the recipient B through the cellular network. In one embodiment, the authentication requires active participation by the user to provide confidential information to the mobile server (through the mobile user). For its part, it is the individual who authenticates the call, not just the telephone receiver.

In FIG. 23, the carrier channel is shown with reference number 2310, which depicts the connection between the mobile server 2320 to the public network and to the mobile user of the recipient B. The establishment of the carrier channel between the mobile server 2320 and the mobile user of the receiver B completes the end-to-end carrier channel from the caller A to the receiver B.

When the call (which can be a data call or a voice call) is completed, the caller A or the recipient B can provide a hang-up signal (caller A in the example of Figure 23 provides a hang-up signal 2312) to terminate the call ( 2314). It should be noted that in this example, unless proper authentication 2308 is received within the designated authentication period 2314, the carrier channel between caller A and receiver B is not completed. If desired, provisional values can be provided as part of the authentication process (e.g., as part of sending 2306).

FIG. 24 is a flowchart of a call that occurs when the recipient does not answer the cellular call according to an embodiment of the present invention. It happens when the cellular receiver has no coverage (Wi-Fi or cellular) or if the mobile user is turned off or if the receiver simply cannot answer the call.

In this example, the corporate voice mail mailbox is used to replace the voice mail mailbox of the public cellular system to leave a voice mail message from caller A, thereby simplifying voice mail management and reducing the troubles of both callers and receivers. Referring to FIG. 24, caller A informs mobile server 2320 that it wants to establish a call to recipient B by dialing the company's phone number and then the recipient's extension number. This is illustrated by the reference number 2402 in FIG. 24.

Then, the mobile server 2320 realizes that it must complete the call to the recipient B through the cellular network (for example, when the mobile server 2320 knows that the recipient B has roamed outside the Wi-Fi coverage area). Then, the mobile server 2320 makes a call to the cellular network (2404), and because the recipient did not answer, as shown by the reference number 2406, after some time, the sending part of the call is established in the cellular network .

When the mobile server 2320 attempts to contact the recipient, it also starts the authentication cycle 2314 and waits for proper authentication from the recipient. During this period, caller A did not send the channel end-to-end to the voice mail box of the public cellular telephone network, and therefore, did not even know that the voice mail contained the public cellular network. During this authentication period, caller A can, for example, hear a pre-recorded message from the mobile server 2320, and request caller A to wait while trying to find receiver B.

Because recipient B did not answer the call, the mobile server 2320 did not receive proper authentication within the authentication period 2314. Therefore, the mobile server 2320 has not completed the process of transmitting the channel between itself and the voice mail mailbox in the public cellular network. Instead, the mobile server 2320 uses the enterprise voice communication between itself and the recipient. A carrier channel is established between mail mailboxes, and an end-to-end carrier channel between the caller A and the recipient's enterprise voice mail mailbox is generated to complete the call. This is illustrated by the reference number 2412 in FIG. 24. Caller A can now start recording voice mail messages in recipient Bs corporate voice mail mailbox.

At some point in time, caller A completes the call and instructs it to hang up to the mobile server 2320 (2414), causing the mobile server 2320 to terminate the call.

As can be understood from Figure 24, in the example where the recipient does not answer the cellular phone, even if the mobile server 2320 has tried to complete the call via the public network, the call to the recipients corporate extension will still generate a voice mail message. In the recipients corporate voice mail mailbox. From the user's point of view, the voice mail messages are left in the appropriate voice mail mailbox (ie, recipient B's corporate voice mail mailbox) associated with the dialed phone number, thereby reducing confusion and simplifying voice mail management.

In some cases, the mobile server itself initiates the call to the recipient's mobile user. For example, if the recipient is one of the parties to a previously established conference call, and when the time to establish the conference call comes, the mobile server is trying to establish contact with all conference participants. Moreover, if the cellular receiver cannot be identified, the mobile server 2320 does not allow the receiver's mobile user to complete the transmission channel, thereby protecting the confidentiality of the information.

Referring to Figure 25, by calling the public cellular network to try to establish a call to recipient B through the public cellular network (2504), the mobile server 2320 starts as an attempt to establish contact with recipient B In one part, the mobile server 2320 starts the countdown for authentication. This is illustrated by the reference number 2314 in FIG. 25.

If the recipient is successfully authenticated during the designated authentication period 2320, the carrier channel to the recipient B is established through the cellular network. This carrier channel is illustrated by the reference number 2510 in FIG. 25. After that, a call (voice or data) can be made between the mobile server 2320 and the recipient B.

When the call is completed, the mobile server 2320 or recipient B can hang up the call to terminate the call. This is illustrated by the reference number 2512 in FIG. 25.

As can be understood from FIG. 25, if recipient B cannot be authenticated within the designated authentication period 2314, the call to recipient B will not proceed to protect the data and voice security. In one embodiment, if the authentication does not arrive within the authentication period 2314, the mobile server 2320 may connect the carrier channel to the recipient's enterprise voice mail mailbox. However, this is an implementation option.

As can be understood from the foregoing, the embodiments of the present invention enable the mobile server to determine the identity of the cellular receiver before the call proceeds to the mobile user of the receiver. In this way, even if the recipient's mobile user is lost or stolen, or loaned to others, the security of voice calls or data calls can still be ensured. In other words, unless proper authentication is received from the recipient, an unauthorized third party actually answering the call will not automatically generate the receipt of confidential voice/data information.

Moreover, the cellular recipient authentication procedure ensures that if the recipient does not answer his cellular phone, the voice mail message is left in the appropriate voice mail box associated with the phone number of the caller. In this way, if the caller dials the recipients corporate extension number, even if the mobile server 2320 contacts the recipients mobile user through the public mobile users voice mail box as an attempt to complete the call, the recipient will still be called Voice mail messages are left in the corporate voice mail mailbox, which improves voice mail management and reduces users troubles.

E. Reduce data loss during media delivery

1. Background: Due to the emergence and deployment of Wi-Fi networks, people are using their Wi-Fi enabled devices for data applications such as e-mail, Internet usage, IM and other data applications. At the same time, after years of experimentation and training, VoIP is maturing as a viable alternative to antique phones. The confluence of these two events is making VOWI-FI (or VOFI) a very inspiring suggestion. One of the main requirements of VOFI is similar to that it can be used in a cellular network to seamlessly handover when moving across a WLAN. When the device is in dual mode (capable of cellular and Wi-Fi), handovers may occur between Wi-Fi and cellular networks.

2. Summary: Currently, there is no precise standard for handover between APs in Wi-Fi networks, and no deployed product is providing equipment. Furthermore, since different entities manage the WLAN and the cellular network, there is no mechanism for handover between the two.

The present invention provides mechanisms for roaming/handover within Wi-Fi networks and handover between cellular and Wi-Fi networks for voice calls. It is assumed that the call on the Wi-Fi network is a VoIP call using SIP, but it does not prevent the use of any other control plane protocols. It is also assumed that in a typical VoIP network, there is a SIP proxy server for all processing and a voice/media exchange engine for RTP packet processing. For simplicity, it is assumed that both components reside in a single server box.

3. Elaboration: The following important criteria are used to make handover decisions; as far as possible, the least expensive network should be used to make, maintain, and exchange voice calls. In most cases, Wi-Fi network is the better choice for this requirement.

When the handover situation arrives, the time taken for the handover should actually be very small. This requires very early detection to trigger handover and very fast exchange.

4. Handover scheme: a. Handover in Wi-Fi network. When mobile users roam in the Wi-Fi network, they are only attached to one AP at a time. When it moves out of the range of that AP, it attaches another AP. If the voice call is active when roaming occurs, there will be some packet loss because of the additional time it takes. This is mainly because the device obtains a new IP, which causes the loss of RTP packets. This in turn leads to the loss of the SIP conversation layer maintained by the SIP proxy server. The IEEE standard 802.11r specifies the fastest roaming mechanism that allows the device to pre-identify all APs with proximity detection. However, this cannot avoid the configuration of a new IP address.

In order to avoid the problem of losing the RTP packet stream, the voice/media switching device is notified of the impending roaming situation. While the device is attached to the new AP, the voice/media switch can buffer some RTP packets. This notification also prepares a media exchange in anticipation of the exchange of the source address of the RTP packets from the device. This source address can be stored for a short period of time and used to send RTP packets from other devices where the call is active. In order to prevent any security breaches caused by address spoofing or DOS-type attacks, the voice exchange starts a timer for about 30 seconds. Within 30 seconds, the device needs to register the same IP address with the SIP server as part of the security authentication. Send this IP address to the voice/media switch. Then, the voice/media switch stops the timer and continues to deliver voice packets until the end of the call. Assuming that after attaching to the new AP, the time it takes to obtain the new IP address is in small print and there is no obvious flaw in the voice stream for the listening user.

There are two methods for notification/detection of AP-to-AP roaming.

If the device pre-identifies one or more APs, it will be sent to the server along with their SSIDs, signal strength, and other information along with APs information. This will prepare the server for impending handover situations. Immediately before attaching to the new AP, the device can send a quick notification to the server.

If the device moves to an area where the signal strength suddenly drops to zero and the device cannot send any notifications, the device/media switch detects the loss of periodic RTP traffic and starts buffering the packets intended for the roaming device. When the device is detected again, the buffered voice will be played to it while the above IP address confirmation continues. This buffered voice cannot be longer than 150-200 ms, and if it takes a long time to obtain a new IP address, it will be discarded.

Another mechanism for seamless handover when going from one AP to another AP is by first performing the handover to the PSTN and then back to Wi-Fi. This method determines that when the call process returns from PSTN to Wi-Fi, there is no potential flaw in the situation where the device does not obtain an IP address from the AP/WLAN switch or router within a short period of time. The next paragraph will explain the handover mechanism between Wi-Fi network and PSTN network.

b. Handover between Wi-Fi and cellular network When the device moves outside the Wi-Fi range while continuing in the cellular range, the main reason to perform handover from Wi-Fi to PSTN. When the device returns to Wi-Fi range and stays there for a certain amount of time, a handover occurs from PSTN to Wi-Fi. In order to meet these requirements, mobile devices continue to monitor Wi-Fi signal strength and keep track of all APs that may be attached. When one or two of these data sets determine that there is no good Wi-Fi network available for voice calls, the device and server need to be put together to start handover to the PSTN network. In a specific example, even if the Wi-Fi network is perfect, the L3 network (in this case, IP) may still be in a bad shape and cannot properly forward high priority/time and delay sensitive traffic, such as voice (RTP) )Wait. The periodic L3 QOS test performed between the device and the server provides this data set. Based on L2 and L3 capabilities, the handover decision is made.

There are two possible examples of Wi-Fi signal exhaustion and/or loss.

In one example, there is a steady decline when the mobile user moves away from the access point, and in another example, the signal drops to zero because the user has moved to an unreachable area (e.g., elevator).

In the second example, the signal may drop to zero suddenly or it may drop to zero very quickly.

In order for the server to detect the need for handover, it needs to deal with the above two situations. In the first example, when the device detects a slow drop, it notifies the server once it reaches the low signal threshold. This notification will continue to the Wi-Fi network via the control plane used by SIP. Once the server receives this notification, it starts the handover and establishes the call process via the PSTN and cellular network.

In the second example, when the signal strength just drops to zero, the device cannot obtain an opportunity to send any notification to the server to start handover. In this case, the server relies on the data/media plane to determine the loss of Wi-Fi. When the voice call is active, the server receives periodic RTP packets. When there is no Wi-Fi signal, the server will not receive RTP packets. The arrival of consecutive packets without a wired number triggers the handover initialization to the PSTN process. Even though endpoints typically send less silence, this is also the case in the case of infrequent packets during sustained silence. In this proposal, silent suppression is not used, but VAD/CNG packets are sent out in the same period as regular voice packets.

When the mobile device roams back to the Wi-Fi network and attaches to the AP and obtains an IP address, it contacts the SIP server REGISTERS and starts sending periodic keep-alive (KA) messages. When the KA message is received for a certain amount of time (assuming 60 seconds), the handover from PSTN to Wi-Fi begins. Assuming that the information on L2 and L3 is deemed worthy of delivery, then do so.

The features and advantages of the present invention will be better understood with reference to the drawings and the following discussion.

As mentioned above, in the conventional technology, the problem faced by users is the interruption that may occur during wireless communication, during the conversation layer of telecommunications (eg, voice communication, audio streaming, video streaming, and/or financial information streaming, etc.) , Unwanted interruption may occur, resulting in data loss. Generally, when the telecommunications device used is not moving, the interruption is not obvious. However, when the electric communication device moves from one coverage area to another coverage area, the signal level will deteriorate and cause the communication layer of the electric communication to be interrupted, resulting in a negative electric communication experience.

Imagine, for example, a situation where a user of a mobile telecommunications device is participating in the telecommunications conversation layer. During the telecommunications conversation layer, the user of the mobile telecommunications device may roam outside the wireless coverage area (e.g., wireless access point).

To help the discussion, Fig. 26 schematically shows a simplified block diagram of a conventional technique connected to the access points of different controllers. In the prior art, each coverage area can be managed by an independent wireless LAN controller. In an example, the first access point 2602 can be connected to the controller 2604 and the second access point 106 can be connected to a different controller 2608. The controller 2604 and the controller 2608 are independent of each other, and even if the mobile telecommunication device 2610 can communicate with two access points (access point 2602 and access point 2606), they are still not configured to communicate with each other.

When the user of the mobile telecommunication device 2610 moves from the coverage area supported by the first access point 2602 to the coverage area supported by the second access point 2606 (shown by path 2612), the mobile telecommunication device 2610 must be in Separate from the first access point 2602 before establishing a new connection with the second access point 2606. In one example, the user of the mobile telecommunication device 2610 must be separated from the first access point 2602 (e.g., hang up) (through the IP address from the IP address space 2614), and must make a new call to pass the first access point 2602. The second access point 2602 reconnects with the recipient (via the IP address from the IP address space 2616).

The situation that the two controllers of the two access points cannot communicate with each other and can seamlessly handover will cause an interruption to the electric communication conversation layer, and cause the two parties of the electric communication conversation layer to have a negative electric communication experience.

Fig. 27 is a simplified conventional technology block diagram of the access point of the interconnection group linked to the controller. A set of access points (2702 and 2704) are connected to the controller 2706. Even though the access points may be of different standards and may not directly communicate with each other, the controller 2706 still has a transcoder that enables the two access points (2702 and 2704) to communicate with each other. In one example, when the user of the mobile telecommunication device 2708 roams from the access point 2702 to the access point 2704 (as shown by path 220), the controller 2706 can transfer the mobile telecommunication without changing the IP address Device 2708 to access point 2704.

In addition, if the mobile telecommunication device 2708 is provided with only one transceiver, the mobile telecommunication device 2708 can only be connected to one access point at a time. Therefore, the electrical communication device 2708 must be separated from the access point 2702 before connecting to the access point 2704, creating a gap in the communication layer of the electrical communication. During the gap, the IP packets that have been sent can be discarded because the destination may not be reached (eg, mobile communications 2708). As a result, the mobile telecommunication device 2708 cannot receive all incoming IP packets. Although the gap during handover between access points of the same controller is usually not large, the loss of IP packets may cause some interruptions in the communication layer of the electrical communication. In one example, during a telephone conversation, interruptions may result in "abrupt" voice quality.

In another example, if the user of the telecommunication device 2708 continues to roam (as shown by the path 2722) and enters the coverage area supported by the access point 2710 managed by the controller 2712, the controller 2706 can execute to the controller 2712 Handover. Although the handover may be between two interconnected controllers, interruptions generally still occur. In an example, the controller 2706 is associated with an IP address from the IP address space 2714, and the controller 2712 is associated with an IP address from the IP address space 2716. Therefore, when the handover occurs, the connection with the IP address from the IP address space 2714 will be separated, and another connection with the IP address from the IP address space 2716 will be established, resulting in the loss of IP packets (e.g., data loss).

Even if a group of controllers is configured to perform handover without establishing a communication layer with a new IP address, there will still be potential factors during the handover between two access points on different controllers. It is greater than the potential factor that exists in the transfer between two access points on the same controller. One of the reasons is that the transfer tendency between the two controllers passes through the two controllers.

In one example, the user is roaming while watching a boxing match on his Wi-Fi mobile phone. While roaming, users can move from one access point to another. Every time a user moves to a coverage area supported by an access point managed by a different controller, the user must reconnect with the new IP address. Although it can be handed over, because the IP address changes, more potential factors usually occur. Therefore, every time a user loses a connection, the user usually cannot receive the lost IP packet that has been sent while the user is not connected. As a result, the telecommunications conversation layer may be unclear and/or distorted during the handover.

In addition, this method of interconnecting controllers is usually implemented using private agreements. Therefore, as far as the handover is to be performed, the mobile communication device, access point, and even the controller need to be provided by the same supplier or co-supplier. Hardware limitations will limit the options that can be used by companies that want to deploy wireless communication systems with handover capabilities. In addition, the cost associated with the exchange of hardware is one of the obvious factors that further limit the flexibility of enterprises to update their telecommunications infrastructure.

According to an embodiment of the present invention, a wireless communication system method is provided, and the method includes seamless handover that can be implemented by an enterprise. According to an aspect of the present invention, the inventor realizes that by buffering the IP packets transmitted during the handover, the data loss that occurs during the handover between two wireless access points can be substantially eliminated. The embodiments of the present invention enable a wireless communication system to incorporate such a buffer system. Embodiments of the present invention additionally include implementing a buffer system on mobile users and mobile servers.

It is a situation where, for example, a user who is a mobile user is communicating with a user on an external telecommunication device through a wireless access point. During the telecom conversation layer, users of mobile users will roam.

In the embodiment of the present invention, the mobile user may include a mobile manager user module, which can communicate with the mobile manager server module located on the mobile server. When the user of the mobile user is roaming, the mobile manager user module can detect (through the detection mechanism) that the signal strength is degrading and can use another access point that can provide a stronger signal. In addition, when the handover is about to come, the mobile manager user module can notify the mobile manager server module.

In one embodiment, the wireless communication system may include a voice engine module, a media server, and a voice quality engine module capable of buffering IP packets. The purpose of the buffer system is to prepare for possible IP packet loss when the user roams from one access point to another.

In one embodiment, after a new connection has been established with an access point that does not require an IP address change, the voice engine module and the media server and voice quality engine module can remove the buffer system and start forwarding and synchronization Convert incoming IP packets. As a result, a seamless transition can occur with substantially no IP packet loss.

In another embodiment, if the IP address change has occurred, the media server and the voice quality engine module can buffer the incoming IP packets until the mobile user has completed the registration process. In addition, the mobile server can start an authentication timer. The authentication timer can be configured to provide a predetermined time limit to the owner (mobile user) of the IP packet to register with the mobile server.

In one embodiment, if the registration and authentication process occurs in a timely manner (within a predetermined time limit), the voice engine module of the mobile server and the media server and voice quality engine module can synchronize incoming IP packets and Continue their function of exchanging IP packets. If the registration and authentication process does not occur within the preset time limit, the mobile server can reject the IP packet from the new access point. Additional registration and authentication processing provides protection for the wireless communication system from possible attacks such as spoofing.

In one embodiment, when the registration and authentication process is unsuccessful, in order to avoid interruption of the communication layer, the mobile server can be connected via a cellular network.

The features and advantages of the present invention can be better understood with reference to the drawings and the following discussion.

FIG. 28 is a block diagram of a user roaming on a mobile user between two access points managed by a single controller according to an embodiment of the present invention. For example, consider the situation where the user of the mobile user 2816 is talking with the user of the outside telephone 2802. IP packets (eg, voice packets) traverse the carrier network 2860 to connect with users on mobile users 2816 in the enterprise 2800. The PBX 2810 can receive the IP packet first. Then, the PBX 2810 routes the IP packets to the mobile server 2818 via the internal IP network 2812 (corporate intranet). From the mobile server 2818, IP packets can be sent to the mobile user 2816 through the IP network 2812 and the access point 2862 (as shown by path 2890).

During the telecommunication conversation layer, the user of the mobile user 2816 can roam from the access point 2862 to the access point 2861 (as shown by the path 2890). In this example, the access point 2862 and the access point 2861 can be managed by the same controller. Therefore, two access points can share the same IP address space without requiring a new IP address for mobile users.

When the user of the mobile user 2816 moves toward the access point 2861, the mobile manager user module 2874 in the mobile user 2816 is monitoring the signal level, and the communication signal level changes to the mobile server 2818 Mobility Manager Server Module 2884. In one embodiment, the mobility manager user module 2874 can be configured to receive and use information such as signal strength data and detection of the urgency of handover and other parameters that determine the handover to evaluate the current connectivity status. In the embodiment of the present invention, the mobile manager server module 2884 of the mobile server 2818 can be configured to receive and store the communication information of the mobile user 2816.

Because the mobile manager user module 2874 knows the Wi-Fi infrastructure, the mobile manager user module 2874 can realize possible handover in order to receive better connectivity. In one example, while the signal level provided by the access point 2861 is becoming stronger, the signal level provided by the access point 2862 is becoming weaker. As a result, both the mobile user 2816 and the mobile server 2818 begin to prepare for a possible handover.

In order to prepare for the handover, the mobile manager user module 2874 notifies the call control user module 2872 that the handover is possible. As shown in FIG. 10, the call control user module 2872 can be configured to manage the outgoing data and incoming data of the mobile user 2816. The call control user module 2872 can notify the voice engine module 2870 to start buffering the IP packets sent to the mobile server 2818.

In one embodiment, in order to perform buffering, the voice engine module 2870 may include a user data storage 2878 and a user buffer timer 2876. The user data storage 2878 can be configured to buffer the IP packets sent by the mobile user 2816 when the handover is urgent. The user buffer timer 2876 can be configured for the user data storage 2878 to buffer the duration of the IP packets. If the duration exceeds the predetermined duration, in one embodiment, the user data storage 2878 may discard the buffered IP packets to avoid transmitting widely delayed data. The predetermined duration depends on the characteristics of the outgoing IP packet. In an example, if the outgoing IP packet is voice data, the length of the predetermined duration can be 200 ms or less.

At the same time, the mobile manager server module 2884 can notify the call control server module 2882, which is configured to perform functions related to establishing a communication layer, that a handover is possible. In one embodiment, the call control server module 2882 can notify the media server and voice quality engine module 2880 via the resource manager module 2886 to start buffering the IP packets received from the external phone 2802.

In an embodiment, the media server and voice quality engine module 2880 may include a server data storage 2888 and a server buffer timer 2892. The server data storage 2888 can be configured to buffer the IP packets out of the mobile user 2816 when the handover is about to come. The server buffer timer 2892 can be configured for the duration of the IP packets that the server data storage 2888 has buffered to the mobile user 2816 outgoing. If the duration reaches the predetermined duration, in one embodiment, the server data storage 2888 may discard the buffered IP packets to avoid transmitting widely delayed data.

Once one or more criteria (eg, signal strength, channel load, and/or communication quality) have been met, the mobile user 2816 can be separated from the access point 2862 and establish a connection with the access point 2861. The mobile server 2818 can now route the communication layer via the IP network 2812 and the access point 2861 to the mobile user 2816 (as shown by path 2894), thereby establishing the electronic communication between the mobile user 2816 and the outside telephone 2802 Conversation layer.

After determining that the handover has been completed, the mobile manager user module 2874 notifies the mobile manager server module 2884. When receiving the notification, the mobile server 2818 can start sending buffered IP packets to the mobile user 2816. At the same time, mobile user 2816 also started to send its buffered IP packets. When receiving an IP packet, both the mobile server 2818 and the mobile user 2816 perform synchronization to determine which incoming IP packet has not been received previously.

Although the IP address has changed during the handover (because the two access points 2861 and 2862 are managed by the same controller), there is a gap while the handover occurs. In order to solve the gap problem, the synchronization of the IP packets by the mobile server 2818 and the mobile user 2816 can ensure that no IP packets are lost during the handover. Therefore, the transition seems seamless to both parties.

FIG. 29 is a block diagram of a user roaming on a mobile user between two access points managed by two different controllers according to an embodiment of the present invention. The embodiment illustrated in FIG. 29 is similar to the embodiment illustrated in FIG. 28 except that the change of the IP address requires the mobile user to register via the new access point and the mobile server.

Imagine, for example, a situation where a mobile user 2816 connected to the access point 2861 starts to roam towards the access point 2902 outside the enterprise 2800 (as shown by the path 2900). In this example, the access point 2902 and the access point 2861 can be managed by different controllers. In this way, access points do not share the same IP address space, and mobile users will be forced to change their IP addresses.

As mentioned above, the mobility manager user module 2874 and the mobility manager server module 2884 share connectivity status data. When the user of the mobile user 2816 leaves the access point 2861 and roams towards the access point 2902, the mobile manager user module 2874 notifies the mobile manager server module 2884 of the urgent handover. Therefore, both the mobile user 2816 and the mobile server 2818 begin to prepare for a possible handover. Once one or more criteria (such as signal strength, channel load, and/or communication quality) have been met, the voice engine module 2870 and the media server and voice product engine module 2880 begin to buffer out the IP packets.

Once the mobile user 2816 separates from the access point 2861 and establishes a connection with the access point 2902. At this point, the mobile manager user module 2874 notifies the mobile manager server module 2884 that a connection with the access point 2884 has been established. In addition, the voice engine 2870 can end its buffer timer and start sending buffered IP packets to the mobile server 2818.

In one embodiment, if the new connection with the access point 2902 requires a new IP address, the mobile user 2816 must re-register through the new access point and the mobile server 2818. In one embodiment, the mobile server 318 buffers the incoming IP packets from the mobile user 2816 until the registration process is completed.

The media server and voice quality engine module 2880 of the mobile server 2818 includes an authentication timer 2990. When an IP address change has occurred, the authentication timer 2990 can be configured to measure the amount of time it takes for the mobile user 2816 to register with the mobile server 2818. If the mobile user 2816 is not registered within the allowed authentication time limit, the mobile server 2818 rejects the handover to prevent possible security problems.

If registration and authentication occur within the time limit, the mobile server 2818 allows the buffered IP packets to flow to the designated party. In the conventional technology, the change of the IP address usually results in a significant gap where data loss occurs. In order to solve the gap problem, the synchronization of the IP packets of the mobile server 2818 and the mobile user 2816 can ensure that no IP packets are lost during the handover. Therefore, the transition seems to be seamless for both parties.

The mobile server 2818 now routes the telecom conversation layer to the mobile user 2816 via the IP network 2812, the firewall 2920, the Internet 2950, and the access point 2902, thereby establishing a connection between the mobile user 2816 and the external phone 2802. Communication and conversation layer.

In one embodiment, if the user of the mobile user 2816 cannot be identified within the predetermined time limit, the mobile server 2818 and the mobile user 2816 are connected via a cellular network 2962 through a cellular connection (as shown in FIG. 12 and The general description in 13 can be established to prevent the interruption of the communication layer. The exchange of cellular connections can provide enough time for the mobile user 2816 to try another authentication/registration.

FIG. 30 is a telephone flow chart of a roaming solution that does not include an IP address change (as discussed in FIG. 28) according to one or more embodiments of the present invention.

The establishment of a connection 3002 between the external phone 2802 and the mobile user 2816 through the mobile server 2818 may exist. The established connection 3002 may include two processes 3004 and 3006. The process 3004 is associated with the connection between the outside telephone 2802 and the mobile server 2818. In one example, the outside telephone 2802 can be connected to the mobile server 2818 through the carrier network 2860, the PBX 2810, and the IP network 2812. The process 3006 is associated with the connection between the mobile user 2816 and the mobile server 2818. In one example, a mobile user via IP network 2816 paths 2812 and 2862 connected to the access point server 2818 of action.

During the telecommunication conversation layer, data about the connectivity status of the mobile user 2816 is continuously communicated to the mobile server 2818. When the user of the mobile user 2816 roams from the access point 2862 to another access point 2861, the mobile manager user module 2874 sends a notification to the mobile manager server module 2884 that it may be handed over (step 3010) . In the next step 3012, the mobility manager server module 2884 forwards the notification to the call control server module 2882. The call control server module 2882 forwards the notification call to the media server and voice quality engine module 2880 through the resource manager 2886 (steps 3014 and 3016).

In the next step 3018, when receiving the notification, the media server and the voice quality engine module 2880 start to buffer the IP packets coming in from the external phone 2802. At the same time, the mobility manager user module 2874 notifies the voice engine module 2870 to start buffering the IP packets through the call control user module 2872 (step 3020). Throughout this transition, the voice engine module 2870 and the media server and voice quality engine module 2880 still send IP packets. However, in order to ensure that the weakened signal level does not inadvertently cause IP packet loss, IP packets are buffered for later synchronization.

Once one or more criteria (eg, signal strength, channel load, and/or communication quality) have been met, the call control user module 2872 will confirm receipt of the connection with the access point 2861 (step 3024). At about the same time, the call control user module 2872 notifies the mobility manager user module 2874 that the roaming period has ended. In the next step 3030, the mobile manager user module 2874 forwards the notification (ie, roaming to terminate) to the mobile manager server module 2884. When receiving the notification, the mobility manager server module 2884 notifies the call control server module 2882 that the roaming has been completed (step 3032). When receiving the notification, the call control server module 2882 informs the media server and the voice quality engine module 2880 that the roaming has been completed through the resource manager module 2886 (steps 3034 and 3036). In the next step 3026, the voice engine module 2870 of the mobile user 2816 starts to send the buffered IP packets to the media server and the voice quality engine module 2880 via the new access point 2861. When receiving IP packets, the media server and voice quality engine module 2880 sequentially send the buffered IP packets to the voice engine module 2870 (3028). In one embodiment, the voice engine module 2870, the media server and the voice quality engine module 2880 can first compare the received IP packet to synchronize the IP packet, so as to ensure that the IP packet is not lost.

The new connection 3038 now includes processes 3004 and 3040. The process 3004 has not changed and still includes the media traffic from the external telephone 2802 to the mobile server 2818 via the carrier network 2860, the PBX 2810, and the IP network 2812. Process 3040 has replaced process 3006 and now includes media traffic flowing from mobile server 2818 to mobile user 2816 via IP network 2812 and access point 2861.

FIG. 31 is a telephone flow chart of a roaming solution including IP address changes (as discussed in FIG. 29) according to one or more embodiments of the present invention.

The establishment of a connection 3102 between the external phone 2802 and the mobile user 2816 through the mobile server 2818 may exist. The established connection 3102 may include two processes 3104 and 3106. The process 3104 may be the same connection as the process 3004 and is associated with the outside phone 2802 and the mobile server 2818. The process 3006 may be associated with the connection between the mobile user 2816 and the mobile server 2818 through the access point 2861.

Steps 3108 to 3120 are similar to steps 3008 to 3020 of FIG. 30. In other words, the mobile server 2816 that has communicated its connectivity status with the mobile server 2818 notifies that the signal level from the access point 2861 is becoming weaker and the signal level from the access point 2902 is becoming stronger. The mobile user 2816 notifies the mobile server 2818 to prepare for handover (steps 3110, 3112, 3114, and 3116). Both the mobile user 2816 and the mobile server 2818 start to buffer out the IP packets (steps 3118 and 3120).

Once one or more criteria (eg, signal strength, channel load, and/or communication quality) have been met, the call control user module 2872 will confirm the connection to the access point 2902 (step 3122). Because the access point 2861 and the access point 2902 are associated with different controllers, the new connection may include an IP address change.

In the next step 3124, the voice engine module 2870 starts to send the buffered IP packets to the media server and the voice quality engine module 2880 through the Internet 2950, the firewall 2920, and the IP network 2812 via the new access point 2902. When receiving the IP packet, the media server and the voice quality engine module 2880 start to identify the timer and buffer the IP packet coming in from the voice engine module 2870 (step 3126).

At about the same time, the call control user module 2872 notifies the mobility manager user module 2874 of the end of the roaming cycle via the new access point 2902. Then, the mobile manager user module 2874 forwards the notification to the mobile manager server module 2884.

At the same time, in the next step 3134, the mobile manager user module 2874 is registered via the new access point 2902 and the mobile manager server module 2884. When receiving the registration, the mobile manager server module 2884 performs authentication. If the registration and authentication process is not completed in a timely manner (that is, within the allowed authentication time limit), the mobile server 2818 rejects the handover.

However, if registration and authentication occur within the time limit, the mobile manager server module 2884 notifies the call control server module 2882 that the roaming has been completed (step 3138). When receiving the notification, the call control server module 2882 informs the media server and the voice quality engine module 2880 that the roaming has been completed through the resource manager module 2886 (steps 3140 and 3142). In the next step 3144, when receiving the notification, before forwarding the IP packet to the external phone 2802, the media server and the voice quality engine module 2880 compare the received IP packet to synchronize the IP packet from the mobile user 2816. At about the same time, the voice engine 2870 performs similar synchronization for the IP packets coming in from the mobile server 2818.

The new connection 3148 now includes processes 3104 and 3146. The process 3104 has not changed and still includes the media traffic from the external telephone 2802 to the mobile server 2818 via the carrier network 2860, the PBX 2810, and the IP network 2812. Process 3146 has replaced process 3106 and now includes media traffic flowing from mobile server 2818 to mobile user 2816 through IP network 2812, firewall 2920, Internet 2950, and access point 2902.

Figure 32 is a buffer plan according to one or more embodiments of the present invention.

Imagine, for example, a situation where the mobile user 2816 has established an electronic communication conversation layer with another electronic communication device. The telecommunications conversation layer includes audio streams, video streams, and data streams, but is not limited to this. In one embodiment, the mobile user 2816 connects to the electrical communication through the mobile server 2818. During the telecom conversation layer, mobile users are communicating their connectivity status with mobile servers through Wi-Fi access points.

In the first step 3202, the voice engine module 2870 of the mobile user 2816 is exchanging IP packets with the media server and the voice quality engine module 2880 of the mobile server 2818.

During the telecommunication conversation layer, the mobile manager user module 2874 is communicating with the mobile manager server module 2884. If one or more criteria (eg, signal strength, channel load, and/or communication quality) are met and the handover is coming, then in the next step 3204, the mobile users mobile manager user module 2874 notifies the mobile server The mobile manager server module 2884 of the server may be handed over (e.g., another access point and/or cellular network). When receiving the notification, the mobility manager server module 2884 notifies the media server and the voice quality engine module 2880 (through the call control server module 2882 and the resource manager module 2886) to prepare for handover (step 3206). At the same time, the mobile manager user module 2874 notifies the voice engine module 2870 to prepare for handover (step 3208). When receiving the notification, the voice engine module 2870 and both the media server and the voice quality engine module 2880 buffer the incoming IP packets (steps 3210 and 3212). In one embodiment, a buffer timer is started to measure the duration for buffering IP packets. In one embodiment, if the IP packet is sent in only one direction, the mobile user and/or the mobile server do not need to perform buffering. In one example, if a mobile user is receiving a video transmission from a mobile server, only the mobile server must perform buffering. In another example, if the mobile user is sending a data transmission (eg, email), the mobile server does not need to perform buffering.

In one embodiment, if the predetermined time period has expired, the buffer timer expires. In one example, if the incoming data is associated with a voice call, the length of the predetermined duration may be 200 ms or less. If the buffer timer has expired, the buffered IP packets can be discarded to prevent the transmission of widely delayed data that may cause trouble.

At the same time, if the handover is urgent, the mobile user 2816 separates from the first access point 2861 and establishes a new connection with the new access point 2902. In the next step 3214, the voice engine 2870 of the mobile user 2816 starts to send the buffered IP packets to the media server and the voice quality engine 2880 of the mobile server 2818 through the access point 2902.

However, if the method determines that the incoming IP packet is being sent by the unregistered mobility, the media server and voice quality engine 2880 buffer the incoming IP packet until the registration is completed. In addition, in one embodiment, the media server and the voice quality engine 2880 start the authentication timer, which is configured to measure the time it takes for the mobility manager user module 2874 to register (step 3216).

At about the same time, in the next step 3218, the mobile manager user module 2874 is registered with the mobile manager server module 2884 of the mobile server 2818. When receiving the registration, the mobile manager server module 2884 performs authentication. If the registration is completed within the predetermined time limit, in the next step 3220, the mobility manager server module 2884 notifies the media server and the voice quality engine 2880 that the registration is completed. When receiving the notification, the media server and voice quality engine 2880 start to receive the incoming IP packets from the voice engine module 2870.

At about the same time, in the next step 3222, the mobility manager user module 2816 notifies the voice engine module 2870 that the registration has been successfully completed.

In the next step 3224, the IP packets are exchanged and synchronized, and the electronic communication conversation layer between the mobile user and other electronic communication devices can continue.

Referring back to step 3216, if the registration and authentication cannot be completed in a timely manner (eg, at a predetermined time), the authentication timer expires and the mobile server 2818 refuses to hand over, so as to prevent security problems such as address spoofing.

The method illustrated in Figure 26-32 is not limited to W-Fi to W-Fi handover. Instead, the discussion is merely an example, and the invention is not limited to the specific application presented. In the embodiment of the present invention, the method can also be applied to other handover solutions, including from Wi-Fi network to cellular network, from cellular network to Wi-Fi network, and from a cellular network. Network to another cellular network, but not limited to this.

As can be understood from the foregoing, one or more embodiments of the present invention provide a wireless communication system that utilizes a multi-network configuration that can be managed by an enterprise to provide seamless transition between wireless access points. Furthermore, the wireless communication system includes mobile users and mobile servers, and they can interact with each other to determine when a handover is possible, so that both the mobile server and the mobile user can prepare for change. In addition, the wireless communication system can implement a buffer system to prevent IP packet loss during the handover, so that the communication layer of the electric communication is not interrupted. In addition, the wireless communication system is independent of operating systems, branches, and/or models to reduce costs related to changing equipment (such as network equipment and electrical communication devices). Moreover, when handover between two wireless access points is not possible, the wireless communication system can additionally smooth the transition between networks.

F. Select the network stacking function in the hardware for the media stream processing distribution system

1. In terms of background knowledge, the distributed system includes a software network stack used to process all received and transmitted packets on the network interface. The received packet must be classified by checking the header field and processed according to any rules associated with the classification. The transmitted packet must be processed to ensure that the packet header field is accurately set. Perform these functions in one layer larger than the network stack. Processing classified packets includes applying filter rules to drop or receive packets, performing interpretation, and destination applications or routing rules through internal message routing to allocate packets to the processing engine. The network stacking function must be fully implemented to handle both control and media packets.

When using universal processors or specific network processors to perform network stacking functions for distributed systems, issues related to performance and cost are common. When a universal processor is designed, the high-speed processor needs to meet performance requirements, and typically still cannot achieve linear rate performance. When a network processor is designed, a distribution system that meets the performance requirements but is small in scale, has the most multimedia processing engine that is currently not available, and is borne by the high initial cost. When the system requires a lengthy interface, the cost issue is multi-faceted. Therefore, system network access is not transparent to application software, but requires a private network access interface. This significantly increases the complexity (ie cost) of the software and limits portability.

The better network interface method is one that can easily perform the function of selecting network stacking in low-cost hardware, which is used to classify, filter, and deploy the received Ethernet packets to the processing engine for specific purposes, as well as the Ethernet packets in transmission Select the final operation of the header field. Packets that are not classified by the hardware are forwarded to the control processing engine used to perform non-time critical network stacking processing. The Ethernet packet interface is used between the hardware and the processing engine. This method is transparent to the software, allowing applications to use common POSIX standard networks and maintain portability to other systems. The system network stack logically performs some performance-critical functions for media streaming in the network interface hardware, and performs all other network stacking functions for a small percentage of packets that are not media packets in the software on the universal processor.

2. Summary The use of low-cost hardware to implement a distributed multi-processor system design that selects the IP stacking function can achieve high-level system performance and scalability at the lowest cost and software complexity. This method provides packet identification based on UDP and TCP transmission types and port numbers, filters and discards unwanted packets, and forwards the required packets to one of several processing engines. The packet classification information written by the hardware classifier is used to explicitly combine the received packet with the registered application software on the processing engine; this enables the processing engine to avoid calling the IP stacking function already implemented in the hardware.

The optimal design of a distributed system for media stream processing requires specific purpose network interface hardware. This hardware downloads and receives and transmits packet processing from the control processing engine, media processing engine, and digital signal processor (DSP), making it possible to select cost-effective processors and DSP devices. The purpose of the hardware is to directly transport to the media processing engine to classify media stream packets, and to transport all other control traffic to the control processor. For transmitting packets, the hardware performs the final packet header processing and sets the system value in the selected header field. Logically, the system network stack function is allocated or separated among the hardware, control processor, and media processing engine. The hardware is flexible enough to perform additional specific and detailed filtering to effectively provide a hardware firewall.

The advantages of the present invention include low cost, high performance, and maintaining the POSIX standard interface for application programming. These advantages enable the design of the distribution system to meet the cost of goods (COGs) objectives, system performance, and scalability requirements. By using the POSIX standard network interface, the initial and ongoing engineering cost and resource requirements will not increase. If high-complex and cost-intensive software is developed, and the high cost of providing quality, and the release of defect-free software, the present invention provides significant benefits far higher than complex choices.

3. Overall architecture In a cost-sensitive market, the hardware design of the network interface for distributed systems presents obvious challenges. The biggest challenge is cost. Everyone knows that if the cost causes the selling price to be significantly higher than the market demand, even a functionally completed system with excellent flexibility or performance characteristics is still not feasible. When two network interfaces are required, regardless of whether 802.1D/w Spanning Tree Protocol or 802.3ad Multi-Link Trunking is used, the redundancy requirement doubles the cost.

The FPGA-based design meets low-cost requirements, provides enough flexibility to select IP functions for each system design, allows future requirements, and provides linear rate performance. Once the FPGA hardware has classified packets and performed a predetermined IP function, when it is deployed or assigned to a specific processing engine, the decision information is provided with the classified packets. When this activity is necessary, the Ethernet type field is set to indicate the IP functions that have been executed, and those IPs that need to be executed next time. When receiving a classified packet, the processing engine skips the IP classification function including the executed filter activity, and inserts the packet into the network stack at the indicated point.

The system architecture consists of several blocks, each with one or more internal blocks. The hardware of the system network interface requires one or more Ethernet interfaces depending on the redundancy requirements. Packet deployment hardware interconnects all control and media processing engines and system network interfaces. The control processing engine is designed to provide system management and control service access points. The media processing engine is designed to provide low-latency, high-capacity media processing, and includes several DSPs or security auxiliary arithmetic units as needed to meet performance specifications.

4. Receiving media packet processing When the packet data starts to enter the system, the system network interface hardware executes the receiving packet header processing. The destination MAC is checked to verify that the packet is assigned to this system. Because the system operates in a shortcut mode, the MAC box CRC is not checked next time. When receiving packet data and calling additional network stacking functions, the MAC sum check is assumed to be a legal sum check. The Ethernet type is checked, and non-IP packets are processed by the control packet processing.

As far as IP packets are concerned, processing is performed to distinguish between media packets and control packets. First, the destination IP address is checked to verify that the packet is designated for regional transportation. IP packets that are not assigned to this system or that match the input of the drop filter are counted and discarded. The IP transport protocol type is checked as TCP or UDP. After compensating for the length variable due to the IP header selection and, if necessary, the TCP header selection, the transport protocol destination port information is initially used for streaming demultiplexing. This port is used as the index or key of the media stream table. This media stream table only contains the media stream port definitions for the single purpose of separating media packets and controlling packets. If the packet is not classified as a media packet, it is forwarded to the control processor as the remainder of the network stack processing. If no further de-multiplexing is required, each media flow table matches and processes media packets in a regular manner. These rules indicate counting and down, forwarding to the media processing engine, or demultiplexing of each media service access point (MSAP) service rule.

Use the synchronization source (SSRC) field in the real-time transfer (RTP) or secure real-time transfer (SRTP) header to demultiplex the MSAP media stream. When the network interface hardware matches the number of MSAP ports to classify media packets, the hardware additionally recognizes the selected sub-fields in the RTP/SRTP SSRC. This SSRC subfield is used as an index or key to the media stream table. Regarding non-MSAP media streams, these rules indicate counting and down or forwarding to the media processing engine.

The final processing of the media stream is used to modify the packets to be transported to the destination, and to provide information that explains the implementation of network functions. This requires changing the selection fields, including MAC destination and MAC Ethernet type fields.

5. Receiving control packet processing Any packet that is not matched by the hardware media stream classifier is directed to the system control processor. By definition, the control processor only handles management and control traffic, not media traffic.

The features and advantages of the present invention can be better understood with reference to the drawings and the following discussion.

Figure 33 shows that the host processor 3302 is used not only to perform classification and packet forwarding tasks, but also to perform other host processing tasks, such as establishing media streams, serving file transfer protocols (FTP), ensuring shell (shell) requests, and The logical block diagram of the conventional technology for managing the hardware box itself. The host processor 3302 receives packets from one or two physical interfaces 3304 and 3306. According to the header information in the received packet, the host processor 3302 determines the destination MAC address by looking up the table, for example, and then updates the destination MAC address by modifying the packet so that the received packet can be forwarded to its destination To perform classification work.

Once updated, the host processor 3302 forwards the packet to the Ethernet switch 3308 so that the packet can be forwarded to one of the media processing CPUs 3310a, 3310b, 3310c, and 3310d. Generally speaking, the media processing CPUs 3310a-3310d perform digital signal processing (DSP) functions for media streams. Media processing functions may include, for example, encoding, decoding, mixing, echo cancellation, and so on.

In addition to performing the above-mentioned classification and packet forwarding work for media stream packets, the host processor 3302 also processes control packets that are received, for example, to establish and tear down calls. Moreover, the host processor 3302 also handles other processing tasks that are typically expected as a host processor. Therefore, only a portion of the processing power of the host processor 3302 is used to perform classification and packet forwarding tasks.

As far as the media stream packets are highly sensitive to delay, the host processor 3302 cannot process the media stream packets at a high speed is a hindrance. E.g. For streaming audio, streaming video, and Internet telephony or video conferencing applications, media stream packets are highly delay-sensitive and need to be forwarded in real time. In order to achieve the high performance required for media stream packets, designers must turn to high-power host processors. As far as we know, these high-power host processors tend to be expensive, which tends to increase the cost of the entire system.

FIG. 34 is a simple logic block diagram of a conventional technology implementation in which a network processor is used to download some work previously performed by the host processor 3302 of FIG. 33. Generally speaking, network processors 3402 and 3404 are set by network processor vendors who design their network processors to handle a wide range of packets encountered by routers, for example. Therefore, the network processors 3402 and 3404 tend to be ASIC (application specific integrated circuit) chips designed to operate at extremely high speeds.

In a typical network processor, in addition to classification tasks, multiple additional tasks are also provided and enabled. As far as the universal router is concerned, the use of a network processor is an improvement over the only method of the host processor of the prior art Figure 33. However, the network processor method of FIG. 34 in the prior art produces complex and cost disadvantageous results.

The network processors 3402 and 3404, which are general network processors, tend to include highly complex functions, enabling the network processors 3402 and 3404 to handle the needs of universal routers that handle a wide range of traffic in addition to media traffic. Moreover, the network processors 3402 and 3404 typically handle layer 3 traffic, which also increases the complexity and cost of the network processors. Due to redundancy requirements, two or more network processors 3402 and 3404 are typically utilized as shown.

For media stream packets, the network processors 3402 and 3404 perform classification work, if necessary, update the MAC address to the (new) destination address, and forward the media stream packet to the media processing unit 3310a, 3310b, 3310c , And one of 3310d. For packets that require the attention of the host CPU, at least one of the network processors 3402 and 3404 will forward these packets to the host CPU 3406 via the Ethernet switch 3410 for processing. Examples of packets processed by the host CPU 3406 include, for example, control packets for establishing and tearing down calls, status update messages from users, and so on.

Not only is the network processor expensive, but it also has a certain amount of configuration time required to build the network processors 3402 and 3404 when it is turned on. Before the system of FIG. 34 of the prior art can become operational, the configuration for network processors, which tends to be complex circuits, requires that a limited delay be added to the required configuration time. When each network processor needs to meet the redundancy requirements of some Ethernet applications, the cost is doubled.

According to an aspect of the present invention, the inventor realizes that for VoIP (Internet telephony) applications, a large number of packets processed by the classification engine will be media stream packets. In one embodiment, a router or another device may be configured in front of the VoIP gateway to ensure that most or all of the traffic received by the VoIP gateway is related to VoIP traffic. However, these non-media packets tend to constitute a small portion of the packets received and processed by the VoIP gateway. Therefore, the inventor realizes that if many functions not related to VoIP processing can be removed from the function group of the FPGA, the classification engine can be implemented on a low-cost FPGA. Therefore, if a low-cost FPGA is configured to process almost the smallest set of functions required to process most media stream packets, it is now possible to achieve low-cost processing of media stream packets at a linear rate.

Generally speaking, media stream packets are of UDP type. Each packet received by the VoIP gateway must be inspected to determine what action the FPGA should take on the packet. When a packet is received in the FPGA, the IP header is checked, and when the call is established and torn down, the UDP port number is used to perform a lookup in the internal table of the FPGA created by the host processor. The FPGA's internal table contains a serial port currently configured for media stream packets. For each port in the table, the programmed field includes the destination MAC address of one of the media processing CPUs, a flag indicating whether the packet should be discarded by the FPGA, and can be used to determine the packet Whether the counter is still discarded. If the port of the incoming media stream packet matches the port in the FPGA's internal table, the packet is not updated to include the MAC address of the destination media processing CPU and forwarded for DSP processing (e.g., echo cancellation, Encoding, decoding, etc.), that is, if the discard flag is set for that port, the packet is discarded and the discard counter is incremented.

After the media stream packet is processed by the appropriate media processing CPU, the media stream packet is then returned to the switch to be sent to the appropriate Ethernet physical interface on the next process of the journey.

35 is a high-level logic block diagram of a VoIP gateway 3500 that uses FPGAs 3502 and 3504 to provide a redundant Ethernet processing path through the VoIP gateway 3500 according to an embodiment of the present invention. Unlike the implementation of Figure 34 in the prior art, the large number of packets processed by the VoIP gateway 3500 are related to the small and limited processing functions required for the service and the media stream packets that must be processed with high priority and minimal delay. The implementation results in a greatly simplified implementation of a set of functions within each FPGA 3502 and 3504 (in order to meet the redundancy requirements of specific Ethernet applications, it is actually mutual redundancy).

For example, FPGA 3502 is designed to only look for UDP media stream packets and only process UDP media stream packets. For all other packet types, the FPGA 3502 passes those packets to the host CPU 3506 for processing. Moreover, for UDP media stream data packets, FPGA 3502 uses its internal UDP port table to perform a quick lookup to determine whether the packet matches one of the entries in the UDP port table. Each entry in the UDP port table reflects the media stream established by the host CPU 3506. If there is a match, FPGA 3502 quickly executes to determine whether the packet should be discarded.

If the packet is dropped, no further action is required. If the packet is not discarded, the FPGA 3502 obtains the corresponding media processing CPU module ID from a table that can be used to formulate a new MAC destination address for the received packet.

Check the media processing CPU module ID and use part of the UDP destination port number obtained from the header of the incoming packet. Incoming packets use part of the UDP destination port number as an index to the UDP port table. If there is a matching entry in the UDP port table, the destination media processing CPU module ID is obtained, and the destination MAC address is formulated and updated in the packet header.

After that, the FPGA 3502 sends the packet to the Ethernet switch 3510 to be sent to one of the media processing CPUs 3512a, 3512b, 3512c, and 3512d. After the appropriate media processing CPU (such as 3512a, 3512b, 3512c, 3512d) performs media processing (such as the above encoding, decoding, echo cancellation, etc.), the packet is converted into a transmission packet and sent back to the Ethernet 3510. FPGAs (serving as pass) on the next process.

It should be noted that the processing of the aforementioned media stream packets represents the type of processing that needs to be performed for a large number of packets passing through the VoIP gateway 3500. Therefore, by simplifying a set of functions that FPGAs 3502 and 3504 must perform for a large number of media streams traversing the VoIP gateway 3500, linear rate performance can be achieved at low cost, while maintaining the necessary performance while lowering the overall system cost It simplifies the FPGA.

FIG. 36 shows the steps taken by the VoIP gateway 3500 when processing the received packet according to an embodiment of the present invention. The packet is received by block 3602 and processed in block 3604 by referring to the UDP port in the UDP port table.

The UDP port information can be obtained by checking the packet header. It should be noted that for all packets except UDP packets, no lookup action is required, and the control is passed to block 3606, where the packet is forwarded to the host CPU 3506 for processing. For example, if the packet is related to the call setup message and the call is ready to connect, the host CPU will update the FPGA's UDP port table with the UDP port, so that the RTP (Real Time Transport Protocol) stream will be used and the programmed packet should be forwarded to the specified Media processing CPU. In addition to control packets, other packets that cannot be matched in the UDP port table are also forwarded to the host CPU for processing. On the other hand, if the UDP port in the UDP port table is looked up to produce a match, then control is passed to block 3608 to first determine whether the packet is discarded. If the host processor has indicated that the packet is to be discarded, no further processing is required and the packet is discarded at block 3610.

On the other hand, if the packet is not discarded, control is passed to block 3612. In block 3612, the forwarding logic in FPGA obtains the media processing CPU module ID, and according to the obtained media processing CPU module ID (from the UDP port table) Obtained in Figure 5, discussed in Figure 5) formulate the MAC address. The destination MAC address of the received packet is updated to the packet of the media processing CPU block 3612. In block 3614, the media stream packet is forwarded to the media processing CPU via the Ethernet switch for general processing as described above.

FIG. 37 is an example diagram of the UDP port lookup step 3604 of FIG. 36 according to an embodiment of the present invention. In the embodiment of the present invention, the reference has been simplified to obtain the media processing CPU module ID and formulating the destination MAC address to ensure that the received packet can be forwarded to the appropriate media processing CPU (e.g., the media processing CPU in Figure 35). One of CPUs 3512a-3512d).

As mentioned above, each received media stream packet has a UDP destination port in its header (which is 16 bits). The first 6 bits (3702) of the UDP destination port number are input to the comparator 3704 for comparison. The UDP port base of the valid UDP port range is loaded into the base register 3706 for comparison. Because the number of supported media streams is limited, the entire range of valid UDP ports does not need to be checked. When comparing with the base register, if the UDP port does not match, the packet is forwarded to the host CPU for processing, because it does not exist in the FPGA's internal UDP port table. However, if the result of the comparator 3704 is a positive number (that is, there is a match between the first 6 bits of the UDP destination port number obtained from the header of the received media stream packet and the UDP port base), then the lower UDP destination port A 10-bit (3708) is used as an index to the UDP port table 514 to obtain information about the destination to which the packet should be forwarded, and whether the packet associated with this media stream should be discarded. In addition, if the packet is not discarded, the destination media processing CPU module ID is obtained to provide the purpose and pass to the packet. If the destination media processing CPU module ID has not been initialized (that is, it is still set to 0x0), the packet will not be modified and will be forwarded to the host CPU for processing. Therefore, as seen in FIG. 37, the positive number from the comparator 3704 determines that the next 10 bits of the UDP port number can be used (3712) as an index to the UDP port table 3714. The 10-bit pattern 3708 will match one of the entries 3716, 3718, and 3720 in the UDP port table 3714.

For matching, the method first checks the discard bit to determine whether the host CPU 3506 has marked the bit so that the packet associated with this media stream should be discarded. Referring to Figure 37, suppose that the number of 10-bit UDP destination ports used as the UDP port table 3714 is 00-0000-0001 (entry 3718). In this example, the method pays attention to the bits in field 3720 to determine whether the discard bit has been set. If the discard bit has been set by the host CPU 3506, the FPGA processing is performed and the packet is completely discarded.

If the discard bit 3720 is not set, the FPGA uses to formulate the destination MAC address and updates the destination MAC address in the received UDP media stream packet so that the received UDP media stream packet can be forwarded To the appropriate media processing CPU.

The field 3724 is a two-bit field, which displays the discarding status and can include values to four different values to indicate various discarding statuses (eg, discarded, never discarded, etc.). Once the received UDP media stream packet is updated with the destination MAC address associated with one of the media processing CPUs, the FPGA transfers the received packet to the Ethernet switch 3510 (see Figure 35), as described above, making the Ethernet switch The device 3510 can exchange the received UDP media stream packets to the media processing CPU for processing.

In one embodiment, the media processing CPUs are required to be implemented in the same rack as the FPGAs, thereby simplifying the implementation of the control part required to forward UDP media stream packets from the FPGA to the appropriate media processing CPU on a large scale. If the media processing CPUs have been implemented outside the rack, the forwarding work should be more complicated, making the FPGA more complex and reducing performance, which is disadvantageous for processing linear media stream packets.

As can be understood from the above, due to the implementation of VoIP gateways, a large number of functions provided by typical off-the-shelf network processing units are not needed. From a cost point of view and a complexity point of view, the inclusion of these additional functions does have a negative impact For the entire system, the inventor was able to identify the minimum set of functions required to perform a large number of UDP media stream packets in a typical VoIP gateway.

By refining the functions typically set in a typical network processor into a set of minimum functions implemented in FPGAs, using these minimum functions designed to meet the requirements of a large number of packets received and processed by a VoIP gateway , Now it is possible to use a small and inexpensive FPGA to perform classification functions and process UDP media stream packets that constitute most of the packets processed by the VoIP gateway.

It should be noted that this approach has never been an option or does not seem to be practical for universal routers or gateways, because such devices need to handle a wide range of packets, and when they have the burden of processing various packet types. When it comes to complex processing tasks, FPGAs can no longer handle high linear speeds. Because the gateway here is configured to only receive VoIP traffic or most of the VoIP traffic, it can still achieve high performance, while the method can simplify the classification function and can be implemented through FPGAs. The embodiment of the present invention simplifies the design of the VoIP gateway on a large scale and reduces the cost of the VoIP gateway. Even if multiple FPGAs are required to meet redundant Ethernet requirements, the use of two inexpensive FPGAs still typically cuts off the cost of a single network processor. By removing the network processor, the total cost of VoIP can be greatly reduced, thereby increasing the market penetration and market acceptance of VoIP solutions.

In addition to financial considerations, the use of FPGAs to implement these simple classification functions has great flexibility for system designers to deal with additional media types that may be encountered in the future. Because network processors tend to be based on ASICs, they are quite inflexible. Therefore, new media packet types can prevent some network processors from processing these new media packet types, making the replacement of VoIP gateways necessary.

Because FPGAs are agile and reprogrammable, they are inherently more flexible, giving system designers the flexibility to modify FPGA programs to handle new or changed media packet types. Moreover, by only requiring FPGAs to perform relatively simple lookup functions, it is easy to reprogram FPGAs to handle future changes, thereby eliminating the need for expensive hardware upgrades and/or minimizing network downtime.

Although the VoIP application is described as an illustrative example, according to the method, server, and/or system of one or more embodiments of the present invention, it can be applied to the communication of text, image, video, and/or other audio data. For example, the above description of VoIP gateways, such as VoIP gateway 3500 (shown in FIG. 35), can also be applied to media gateways that process text, images, videos, and/or other audio data.

Conclusion By using network interface hardware to execute the function of selective network stacking software, the distribution system for media processing can not only achieve obvious cost and performance advantages, but also achieve obvious technical advantages, including higher system availability, etc. . In particular, the network interface hardware exhibits a performance equivalent to that of a network processor with less potential factors generated by shortcut operations. System availability is usually dominated by software failures. Because this distribution system uses hardware to process media streams in and out of a single processing engine, it requires less network interface software, resulting in higher system availability.

G. Secure media communication across enterprise gateways (NAT/firewall)

Due to the convergence of fixed actions, people are using their Wi-Fi enabled devices from the Internet for data connectivity and voice. One of the important requirements of voice is to transmit via secure network packets. The mechanism described in this paragraph provides secure communication and easy traversal via any type of NAT/firewall gateway.

Currently, there is no recognized standard for traversing corporate VoIP across the Internet securely on NAT and firewalls. Furthermore, since the phone and call manager do not provide the ability to control this VoIP access in a single media service access point (MSAP) for easy provisioning and monitoring, there is no organization to enable enterprise VoIP users to "roam" from the Internet to Cellular network.

The present invention provides a mechanism for transmitting voice and related signaling in a generally end-to-end manner as shown in FIG. 7. The challenge of designing enterprise VoIP has increased exponentially with convergence {data &amp; voice}. With convergence, VoIP networks are being exposed to conventional VoIP threats and data traffic threats. The challenges involved in establishing a good VoIP network that can communicate across corporate gateways to the Internet can be categorized into four categories and discussed in detail below.

a) Secure voice traffic b) NAT traversal (both within the enterprise and remote users on the Internet) c) Firewall traversal (corporate firewall) d) Secure or rugged telephone handset and media switch

Consolidate the security of voice traffic. When they travel via the Internet, the voice traffic is actually visible and usable by any hacker on the network. Any hacker in the middle can hear the ongoing conversation, which is the least threat. In enterprise applications, these calls (at least one end) are initiated/designated out/into the enterprise. In that example, corporate networks or devices in the network may be subject to various attacks, such as Replay attacks, Dos attacks, and so on.

By making the voice secure, the advantage is that a) the privacy of the call is maintained and b) as far as the user is concerned, if the access to the network is wireless, it is even more important to consolidate the security of the voice traffic, even within the enterprise.

c) The possibility of the corporate network being exposed to various attacks is greatly reduced (although it cannot be completely eliminated), thus making the network more secure.

There are multiple ways to consolidate the security of data traffic. Most or all of these methods can also be applied to voice traffic. However, due to the time sensitivity of voice traffic, it is desirable to have a mechanism that is not very processor-important that can be easily installed into even a small VoIP phone handset. Voice traffic uses RTP (via UDP) for end-to-end communication that is currently insecure. SRTP (Secure RTP) is another option for making end-to-end voice traffic completely secure.

With SRTP, because the voice is encrypted in the source user, anyone who does not know the proper key (even from within the network) cannot get anything from the voice packet, so secure communication is established. This organization will be less processor important than VPN solutions.

NAT runs across the corporate gateway. For users residing in the internal corporate network, NAT translates IP addresses from regional IP domains to global IP domains. The existence of NAT in the traffic path will affect the function of some protocols that communicate their IP addresses to their peers on the payload (because the payload will carry the untranslated IP address instead of the translated one, which results in no connection). SIP is one of the protocols that obtain its functions affected by the intermediate NAT gateway.

These NAT translations are of four types: a) full clone b) restricted clone c) port restricted clone d) symmetric NAT

This is the standard implementation to overcome all these NAT types. Of course, symmetric NAT is the most difficult to traverse. TURN (traversal using forwarding NAT) is a standard solution for traversal symmetric NAT. STUN (Simple Traversal of UDP via NAT) is another solution to help traverse the remaining NAT. As far as a solution is concerned, in order not to be affected by any NAT in their path, both STUN and TURN must be implemented. In this solution, there is another new server to add more than one device, thus complicating the solution. For obvious reasons such as management and safety, it is not ideal to introduce more devices.

By effectively designing corporate networks and locating media gateways, any type of NAT can be effectively traversed without introducing any new entity-to-voice solutions.

The solution is designed so that any voice traffic between two users always passes through the intermediate media switch. Notify remote users that their translating information organization is embedded in the media switch that resides inside the corporate network. This ensures that end users always know their translation information and can be effectively used in the sending protocol. Furthermore, configure the global IP address and port (Media Server Access Point-MSAP) forwarding rules on the corporate firewall, and the corporate firewall will forward the traffic received by that MSAP to the media switch. This makes the media switch accessible from any external IP network. Because the media switch that helps NAT traverse is also the other end of any user, this design can be used to traverse any NAT type (including symmetric NAT).

The firewall traverses the firewall and can reside on both ends of the voice communication (enterprise and remote). For VoIP calls, at least two ports (one for RTP and one for RTCP) need to open the firewall. In this way, for n calls that occur simultaneously, 2*n ports need to be opened. Opening more ports causes increased network security threats, so it is not applicable to corporate firewalls.

By designing a solution where the remote user initiates the first UDP communication to the media switch, the firewall can be traversed remotely. By starting the first communication remotely, the remote firewall opens the corresponding port by default.

Crossing the firewall on the enterprise side is a challenge. MSAP provides global accessibility from the external IP network to the media switch. This MSAP is well used for NAT traversal. With effective use of MSAP, it can traverse corporate firewalls without opening new ports for voice communications.

All remote users are designed to communicate with the media switch via the same MSAP. Therefore, all voice traffic from remote users ends in the same port (MSAP) in the media switch. The organization is established such that call recognition is embedded in each and every voice packet. When the MSAP in the media switch receives the packet, it exchanges the packet appropriately according to the call ID embedded in the voice packet. This ensures that although all voice traffic from the outside world is assigned to the same port (MSAP), the exchange of voice traffic occurs properly.

Secure media exchange is currently designed to force the media exchange to receive all media traffic from remote users, thus exposing it to all attacks from outside networks. With the current design, media traffic always uses secure RTP (SRTP) with encryption. As mentioned above, by encrypting and securing media traffic, the solution is more robust and secure. Automatically, the STRP protocol provides the authentication of the remote caller, provides confidentiality through encryption, provides the integrity of the packet, and protects it from answer attacks.

In addition, large-scale access filters are also implemented in the media switch to filter incoming packets.

The features and advantages of the present invention can be better understood with reference to the drawings and the following discussion.

FIG. 38 is a diagram showing the conventional technology used by the STUN server to help NAT traverse (network address translation) in a Voice over Internet Protocol (VoIP) environment. As mentioned above, in order for most devices associated with private networks to communicate with the outside world using a small number of publicly accessible IP addresses, network address translation (NAT) is required.

This is because publicly accessible IP addresses are precious resources and very expensive to obtain. Therefore, most ISPs typically only provide some publicly pathable IP addresses for designated companies to share among many internal users. Therefore, each internal user is provided with an internally pathable IP address known only by the company. In order to be able to access internal devices globally, NAT devices should exist on the internal network to translate from internal IP port pairs to globally pathable IP address port pairs, or vice versa.

NAT traversal is used because specific protocols used for Internet telephony or other types of media applications are sensitive to the effects of NAT. For example, SIP (Talk Layer Initialization Protocol) is one of the protocols whose functions can be affected by the intermediate NAT gateway. Traversal enables internal user devices to obtain the translation design performed by the NAT gateway and communicate the translation design to the destination application server, so that the application server can resolve the gap between the untranslated internal IP address and the translated IP address Is not connected.

Generally speaking, NAT traversal includes communication between the user device and the NAT traversal server, where the user device sends sample packets to the NAT traversal server. Then, the NAT responds across the server, and by responding, informs the user device of the publicly pathable IP address that has been used by the packet originating from the user device. This publicly pathable IP address represents the IP address that has been translated by the NAT gateway.

By knowing its own internal IP address and publicly pathable IP address obtained from the response by the NAT traversal server, the internal user device can forward the NAT translation design to the application server, making the application server usable Knowledge related to the design of NAT translation in order to resolve the difference between the internally pathable IP address and the externally pathable IP address of any particular received packet.

However, as mentioned above, there are four types of NAT translation: full clone, restricted clone, port restricted clone, and symmetric NAT. In symmetric NAT, the translation design can be based on the destination port and destination IP address. For example, for the communication between the user device and the NAT traversal server, the translation of the same internal user device used to communicate with the application server can be different global IP address port pairs, and the internal The IP address port pair of the user device is treated as a global IP address port pair. Therefore, obtaining information related to the translation design between the user device and the NAT traversal server may not provide useful information to the application server related to the translation design between the user device and the application server itself.

In terms of NAT traversal solutions that satisfy all four types of NAT translation, smart NAT solutions must be provided. In the prior art, TURN (traversal using forwarding NAT) and STUN (simple traversal of UDP via NAT) are standard solutions to traverse symmetric NAT and other types of NAT translation. In order to solve all possible NAT designs, both STUN and TURN must be implemented.

FIG. 38 is a schematic diagram of a network environment 3800 in which the conventional STUN NAT traversal server is implemented to handle some NAT translation designs (eg, full clone, restricted clone, and port restricted clone). It should be noted that FIG. 38 is used to illustrate the operation of the conventional STUN NAT traversal server, but the inventor does not consider all the components and/or configurations of FIG. 38 to be conventional technology, because the mobile server 3812 ( The server 3812) and at least the specific point of view and certain method steps of the server 3812 to help VoIP are regarded as invented. Those skilled in the art should understand that many other diagrams here should be understood as well whether they are called conventional technology or not, because some inventive components and/or configurations can be combined with conventional technology components and/or configurations. Include to provide context and help meaningful discussions.

As shown in Figure 38, there is a corporate network 3802 coupled to the Internet 3808 and corporate gateway/firewall 3810. The enterprise network 3802 includes a plurality of Wi-Fi users 3804 and 3822 coupled to an access point (AP) 3806. The mobile server 3812 (server 3812) representing the media application server is also coupled to the Internet 3808 through the switch 3814.

Also shown are the existing PBX 3816 and the existing VoIP system 3818, both of which are connected to the switch 3814 through the intermediate switch 3820. Via AP3806, switch 114, and switch 3820, internal communications within the corporate network 3802 can be made between Wi-Fi users 3804 and 3822, server 3812, existing PBX 3816, and existing Internet phone system 3818. In order to communicate to devices outside the corporate network 3802, the packet traverses the corporate gateway/firewall 3810 to the Internet 3808.

FIG. 38 also illustrates a diagram of an exemplary SOHO network 3840 including an exemplary external user device 3842 representing a VoIP-enabled phone. The external user device 3842 communicates with the Internet 3808 through an access point (AP) 3844 and a broadband router/modem 3846. Figure 38 also shows an exemplary public hotspot network 3860. It includes an external user device 3862 that represents another VoIP-enabled phone. The external user device 3862 communicates with an access point (AP) 3864 to access the Internet 3808 via a broadband router/modem 3866.

In order to be able to use external user device 3862 and devices managed by enterprise network 3802 such as Wi-Fi user 3804 (or if the external user device 3842 is a VoIP phone registered with the server 3812 associated with the internal extension managed by the existing PBX 3816 If the external user device 3842) can make VoIP calls, the VoIP call control protocol needs to be used to establish and manage the media stream between the user external device 3862 and the user device on the other end of the call.

For illustration purposes, assume that the external user device 3862 is trying to establish communication with the W-Fi user 3804. Because the VoIP protocol is sensitive to the NAT translation design implemented by the broadband router/modem 3866, the external user device 3862 first needs to obtain information about the NAT translation implemented by the broadband router/modem 3866. In the STUN example, the STUN solution can be applied to full clone, restricted clone, and port restricted clone types of traversal NAT translation. In this example, the external user device 3862 first sends a NAT traversal request 3880 to the STUN server 3882. Then, STUN server 3882 responded with NAT traversal response 3884. The NAT Transverse Response 3884 informs the external user device 3862 broadband router/modem 3866 of the specific NAT translation design implemented. For example, by including the publicly pathable IP address in the payload of the response packet sent to the external user device 3862, this information can be communicated to the external user device 3862. In order to simplify the illustration, the NAT traverse response 3880 and the NAT traverse response 3884 are shown by the dotted lines directly between the external user device 3862 and the STUN server 3882. In fact, these communications occur via AP 3864, broadband router/modem 3866, Internet 3808, and communication path 3886.

The external user device 3862 obtains the specific NAT translation design implemented by the broadband router/modem 3866 through the information provided in the NAT traversal response 3884. Then external user device 3862 sends NAT translation design information to server 3812 through AP 3864, broadband router/modem 3866, Internet 3808, enterprise gateway/firewall 3810, and switch 3814. Using the knowledge of the NAT translation design implemented by the broadband router/modem 3866, the server 3812 can then establish a VoIP call between the Wi-Fi user 3804 and the external user device 3862 with the external user device 3862. Regarding the internal pathable IP address used by the external user device 3862 in the hotspot network 3860 between the broadband router/modem 3866 and the enterprise gateway/firewall 3810 through the Internet 3808 and used for transmission Any unconnected publicly accessible IP address of the information can be used to obtain knowledge about the NAT translation design that has been forwarded by the external user device 3862, which is resolved by the server 3812.

As explained, this STUN NAT traversal type solution works well for at least three NAT translation types such as full clone, restricted clone, and port restricted clone. As far as symmetric NAT is concerned, the NAT translation design implemented by the broadband router/modem 3866 for communication between the external user device 3862 and the STUN server 3882 is different from that used for communication between the external user device 3862 and the server 3812 NAT translation design. Therefore, the knowledge about the NAT translation design implemented between the STUN server 3882 and the external user device 4862 cannot be applied to solve the NAT translation problem encountered by the server 3812 when the external user device 3862 then communicates with the server 3812.

FIG. 39 is a conventional technology implementation diagram of STUN/TURN (simple traversal of UDP via NAT/traversal using forwarding NAT) NAT traversal implementation that implements secure tunneling between the STUN/TURN server 3890 and the server 3812. As shown in FIG. 39, the secure tunneling 3902 is used to help the communication between the external user device 3862 and the server 3812, at least for the part between the STUN/TURN server 3890 and the server 3812. Therefore, via AP 3864, Broadband router/modem 3866, Internet 3808, TURN server 3890 From external user device 3862, through enterprise gateway/firewall 3810, switch 3814, back to Internet 3808, and reach server 3812 for transmission VoIP media packets (such as voice packets, etc.). In other words, the STUN/TURN server 3890 not only provides information about NAT translation to the external user device, but also acts as an actual VoIP packet that helps to transmit the voice information carried between the external user device 3862 and the server 3812. Because the same communication path between the external user device 3862 and the STUN/TURN server 3890 is used for NAT traversal and for actual media packet transfer, it is the external user device 3862 during the NAT traversal request/NAT traversal response conversation layer. The communication with the STUN/TURN server 3890 and the subsequent communication between the external user device 3862 and the server 3812 perform the same NAT translation while the STUN/TURN server 3890 acts as an intermediate transfer station.

However, the inventor understands that including the STUN/TURN server 3890 to handle the symmetric NAT situation involves several disadvantages. For example, STUN/TURN server 3890 must be managed by corporate IT staff, which increases the complexity of VoIP implementation and maintenance. In addition, the STUN/TURN server 3890 needs to be implemented outside the corporate gateway/firewall 3810 and related firewalls, so opening the STUN/TURN server 3890 is a security risk. The introduction of another entity in the communication path for the media packet between the external user device 3862 and the server 3812 also causes reliability risks and additional delays. For delay-sensitive applications such as real-time voice conversations, this delay is quite obvious to some users but cannot be tolerated by some users. In addition, the STUN/TURN server 3890 acts as an intermediate transfer point for all external user devices communicating with user devices in the corporate network 3802. Therefore, when the number of user VoIP devices handled by the server 3812 increases, the STUN/TURN server 3890 suffers from scalability problems.

FIG. 40 is a diagram illustrating an embodiment of the present invention while removing the requirement that the external NAT traversal server (such as the TURN server 3890 or STUN server 3882 of the prior art FIG. 39 and FIG. 38, respectively, etc.) maintains outside the corporate firewall, according to an embodiment of the present invention , Can traverse all four types of NAT translation, generalized NAT traverse configuration 4000 map. In FIG. 40, the STUN/TURN server function is implemented in the same rack as the mobile server represented by the mobile server-STUN/TURN server 4092 (server 4092).

Moreover, because in order to complete NAT traversal, NAT traversal requires that the STUN/TURN server can be accessed from external user devices, so the embodiment of the present invention uses known techniques such as port forwarding, in which the enterprise gateway 4010 is provided as Any traffic that is designated to itself by the number of ports such as SIP ports or MSAP (Media Service Access Point) ports should be forwarded directly to the server 4092, so that the server 4092 can pass through the network associated with the corporate network 4002 Public addressable IP address (and specific port number, such as MSAP port number or SIP port number, etc.) access to the outside world.

It should be noted that the embodiment of the present invention requires an internal implementation server 4092 or a mobile server and a STUN-like server and port forwarding to ensure that the STUN/TURN server or the STUN/TURN server can be accessed by external user devices for NAT traversal purposes. STUN-like server. When the external user device 3862 wants to communicate with the enterprise network 4002, such as Wi-Fi support 3804 or Wi-Fi user 3822 (or if the external user device 3842 is registered to be managed by the server 4092, then the external user device 3842) is managed by the enterprise network 4002 When one of the devices communicates, by sending a NAT traversal request 4080 to the server 4092 and receiving a NAT traversal response 4012, the external user device 3862 performs NAT traversal first. As mentioned above, the NAT traverse request and the NAT traverse response actually traverse AP 3864, broadband router/modem 3866, Internet 3808, enterprise gateway 4010, switch 3814, and server 4092. Because the STUN/TURN server in the server 4092 communicates with the Internet 3808 through the port forwarding mechanism, the server 4092 looks like an outdoor access device to the external user device 3862, so the external user device 3862 can directly Use the publicly accessible IP address of the corporate network 4002 and the desired number of ports on the server 4092 to address STUN to be used in the server 4092.

Then, the knowledge about the NAT translation design implemented by the broadband router/modem 3866 is communicated to the server 4092 to help the subsequent call establishment between the external user device 3862 and the server 4092 (e.g., in the embodiment, through SIP Protocol) and the actual two-way transmission of media packets (for example, through the MSAP port of the server 4092). In other words, the server 4092 can then use a signaling protocol such as SIP to establish a call path between the external calling device 3862 and the Wi-Fi user 3804 through the server 4092. In addition, the media packet communication between the external user device 3862 and the W-Fi user 3804 is exchanged along the communication path between which the server 4092 is configured.

It should be noted that because the actual media exchange of the server 4092 is also implemented in the same rack as the STUN server, the implementation of Figure 40 can be used to complete any type of NAT (including symmetric NAT) traversal, because the same translation can It is used for communication between the external user device 3862 and the server 4092, which are used for NAT traversing the conversation layer and the call establishment conversation layer, and the actual transmission of media VoIP packets.

As can be understood from the above, the embodiment of the present invention removes the requirement of an external STUN/TURN server (such as STUN/TURN server 3890 or STUN server 3882 in the prior art FIGS. 39 and 38, respectively). This eliminates the security risks associated with maintaining servers outside the corporate firewall. As the intermediate transfer point is eliminated, the delay associated with the transmission of media packets between the external user device and the user device managed by the enterprise network 4002 via the secure tunnel is reduced.

The inventor observes that the MSAP port used for NAT traversal can also be used to reduce the number of ports open in the conversation layer between any N user devices. Referring to FIG. 41, for example, without using the MSAP port, the media stream between the external user device 3862 and the external user device 3842 requires two ports to serve the two processes 4102 and 4104 of the communication path. This is because traditional VoIP is established on the server 4106 with two ports open, and through the corporate gateway/firewall 3810, and using one port for bidirectional streaming from each user device 3842 and 3862.

According to the embodiment of the present invention, regardless of the number of processes of each call, the MSAP port is used to serve the media stream for the user device. Referring to FIG. 42, for example, a single MSAP port 4200 on the server 4202 is used to service media streams in and out of the external user device 3862 and the external user device 3842. By using a single MSAP port for the two processes of the call, the number of ports opened by the enterprise gateway/firewall 3810 is reduced, thus reducing the management time and security risks associated with multiple ports that are open at the same time.

Recall from the discussion associated with the use of the combination of the IP address and the number of ports on the server 4202 section to route the port forwarding of VoIP packets, another organization must now be used to combine voice packets with their conversation, because there is only a single The MSAP port is used for all media streams entering and leaving the user's device. According to the embodiment of the present invention, the solution not only includes using a single MSAP port on the server 4202 for all media communication streams entering and leaving the user device, but also includes combining media stream packets and sessions for routing purposes based on information other than the number of ports ( Because using the approach in Figure 42, there is only one MSAP port for all media streams). In one embodiment, each packet is checked for its media stream ID, and the media stream ID is used to combine the packet and the media stream to determine the destination device to which a specific media (such as voice) packet must be forwarded.

In the embodiment of the present invention, the combination between the packet and its media stream for the purpose of packet routing includes using the server 4202 to quickly glance at the header of the voice packet to determine the media stream ID. Because it does not include in-depth analysis or data manipulation, the delay associated with obtaining the media stream ID and combining the media stream ID with a specific session is greatly reduced.

Once the media stream ID is determined, the packet can be combined with a specific media stream and a specific destination user device (for example, information stored in a call table in RAM), and the packet can be appropriately routed to the destination user device. In this method, the number of ports open through the enterprise gateway/firewall 3810 in Figure 42 is greatly reduced. The MSAP port is leveraged not only for NAT traversal but also for firewall traversing MSAP ports.

It can be understood from the above that the embodiment of the present invention reduces the number of ports in the open corporate firewall by using a single MSAP port to serve all media streams entering and leaving the user's device, while also completing the firewall traversal for VoIP calls. The reduction in the number of ports also reduces the security risks of the enterprise, making the internal network more resistant to attacks originating from the outside.

Although the VoIP application is illustrated as an illustrative example, the method, server, and/or system according to one or more embodiments of the present invention can also be applied to the communication of text, image, video, and/or other audio data.

H. Conclusion

Although the present invention has been described using several implementations, other changes, modifications, and equivalents can be made as long as it falls within the scope of the present invention. It should be noted that there are many other ways to implement the method and apparatus of the present invention. Moreover, the embodiments of the present invention can be used in other applications. The abstract paragraphs provided here are for convenience, and due to the limitation of the number of words, and for the convenience of reading, it should not be used to limit the scope of the patent application. Therefore, the scope of patent application in the appendix below should be interpreted as including all such changes, alterations, and equivalents falling within the true spirit and scope of the present invention.

<p>100. . . System network</p><p>102. . . Mobile device</p><p>110. . . Cellular network</p><p>112. . . Base transceiver station</p><p>114. . . Base Transceiver Station Exchange Center</p><p>116. . . Mobile switching center</p><p>120. . . Media gateway</p><p>122. . . Public switched telephone network</p><p>124. . . Public and private calls</p><p>130. . . Private branch exchange</p><p>132. . . router</p><p>136. . . Telephone</p><p>138. . . Internet Protocol Wide Area Network</p><p>140. . . router</p><p>142. . . Firewall</p><p>144. . . Internet</p><p>150. . . Mobile server</p><p>160. . . Access point</p><p>180. . . Access point</p><p>800. . . enterprise</p><p>802. . . Outside phone</p><p>810. . . Private branch exchange</p><p>812. . . Internet Protocol Network</p><p>814. . . Wi-Fi network</p><p>814. . . Access point</p><p>816. . . Mobile user</p><p>818. . . Mobile server</p><p>820. . . Firewall</p><p>830. . . process</p><p>832. . . process</p><p>834. . . process</p><p>836. . . process</p><p>850. . . Internet</p><p>860. . . Carrier network</p><p>862. . . Cellular network</p><p>904. . . Application server</p><p>906. . . Server Management Module</p><p>908. . . Database Manager Module</p><p>910. . . Policy Manager Module</p><p>912. . . Attendance Manager Server Module</p><p>914. . . PP server module</p><p>918. . . PBX I/F module</p><p>920. . . Call control server module</p><p>922. . . Mobility Manager Server Module</p><p>924. . . Resource Manager Module</p><p>926. . . DP/DX server module</p><p>930. . . SIP server module</p><p>932. . . Socket server module</p><p>934. . . Media server and voice quality engine module</p><p>1004. . . Socket user module</p><p>1006. . . Wireless LAN Manager Module</p><p>1008. . . Cell Data Manager Module</p><p>1010. . . Graphical User Interface Tool Program Module</p><p>1050. . . Attendance Manager User Module</p><p>1052. . . PP user module</p><p>1054. . . DP/DX user module</p><p>1056. . . Wrapper module</p><p>1060. . . Phone application programming interface module</p><p>1068. . . SIP User Module</p><p>1070. . . Speech engine module</p><p>1072. . . Expandable display message and presence agreement analysis module</p><p>1082. . . User interface module</p><p>1094. . . Natural application</p><p>1096. . . Mobility Manager User Module</p><p>1098. . . Call control user module</p><p>1202. . . path</p><p>1206. . . process</p><p>1208. . . process</p><p>1210. . . process</p><p>1490. . . path</p><p>1492. . . process</p><p>1502. . . Hotspot W-Fi network</p><p>1504. . . path</p><p>1506. . . W-Fi network</p><p>1508. . . process</p><p>1602. . . Mobile user</p><p>1604. . . process</p><p>1606. . . process</p><p>1608. . . W-Fi network</p><p>1701. . . Cellular phone</p><p>1703. . . Internet Protocol Device</p><p>1743. . . Code converter</p><p>1771. . . process</p><p>1789. . . link</p><p>1791. . . process</p><p>1799. . . Carrier management gateway</p><p>1858. . . Code converter</p><p>1872. . . process</p><p>1892. . . process</p><p>1902. . . Automatic conference call environment</p><p>1904. . . Mobile server</p><p>1906. . . Conference phone server module</p><p>1908. . . Conference phone users</p><p>1910. . . Conference phone users</p><p>1912. . . Conference phone users</p><p>1914. . . Conference phone users</p><p>1920. . . Internal attendance server</p><p>1922. . . External presence server</p><p>1924. . . User preference database</p><p>1926. . . Enterprise RC rules database</p><p>1930. . . Media sending layer</p><p>1934. . . Media exchange layer</p><p>2302. . . Send letter</p><p>2304. . . Sending path</p><p>2306. . . Sending path</p><p>2308. . . Identify</p><p>2310. . . Carrying channels</p><p>2312. . . Hang up signal</p><p>2314. . . Specify the authentication period</p><p>2320. . . Mobile server</p><p>2602. . . Access point</p><p>2604. . . Controller</p><p>2606. . . Access point</p><p>2608. . . Controller</p><p>2610. . . Mobile communication device</p><p>2612. . . path</p><p>2614. . . Internet address space</p><p>2616. . . Internet address space</p><p>2702. . . Access point</p><p>2704. . . Access point</p><p>2706. . . Controller</p><p>2708. . . Mobile communication device</p><p>2710. . . Access point</p><p>2712. . . Controller</p><p>2714. . . Internet address space</p><p>2716. . . Internet address space</p><p>2722. . . path</p><p>2800. . . enterprise</p><p>2802. . . Outside phone</p><p>2810. . . Private branch exchange</p><p>2812. . . Intranet</p><p>2816. . . Mobile user</p><p>2818. . . Mobile server</p><p>2860. . . Carrier network</p><p>2861. . . Access point</p><p>2862. . . Access point</p><p>2870. . . Speech engine module</p><p>2872. . . Call control user module</p><p>2874. . . Mobility Manager User Module</p><p>2876. . . User buffer timer</p><p>2878. . . User data storage</p><p>2880. . . Media server and voice quality engine module</p><p>2882. . . Call control server module</p><p>2884. . . Mobility Manager Server Module</p><p>2886. . . Resource Manager Module</p><p>2888. . . Server data storage</p><p>2890. . . path</p><p>2892. . . Server buffer timer</p><p>2894. . . path</p><p>2900. . . path</p><p>2902. . . Access point</p><p>2920. . . Firewall</p><p>2950. . . Internet</p><p>2962. . . Cellular network</p><p>2990. . . Identification timer</p><p>3302. . . Host processor</p><p>3304. . . Physical interface</p><p>3306. . . Physical interface</p><p>3308. . . Ethernet switch</p><p>3310a. . . Media Processing Central Processing Unit</p><p>3310b. . . Media Processing Central Processing Unit</p><p>3310c. . . Media Processing Central Processing Unit</p><p>3310d. . . Media Processing Central Processing Unit</p><p>3402. . . Network processor</p><p>3404. . . Network processor</p><p>3406. . . Host central processing unit</p><p>3410. . . Ethernet switch</p><p>3500. . . Internet phone gateway</p><p>3502. . . Field programmable gate array</p><p>3504. . . Field programmable gate array</p><p>3506. . . Host central processing unit</p><p>3510. . . Ethernet switch</p><p>3512a. . . Media Processing Central Processing Unit</p><p>3512b. . . Media Processing Central Processing Unit</p><p>3512c. . . Media Processing Central Processing Unit</p><p>3512d. . . Media Processing Central Processing Unit</p><p>3702. . . Number of destination ports for user data block protocol</p><p>3704. . . Comparators</p><p>3706. . . Base register</p><p>3708. . . 10-bit pattern</p><p>3712. . . Next 10 bits</p><p>3714. . . User Data Block Protocol Port Table</p><p>3716. . . entry</p><p>3718. . . entry</p><p>3720. . . entry</p><p>3722. . . Destination media processing central processing unit module ID</p><p>3724. . . Field</p><p>3800. . . Network environment</p><p>3802. . . Corporate network</p><p>3804. . . Wi-Fi users</p><p>3806. . . Wi-Fi users</p><p>3808. . . Internet</p><p>3810. . . Enterprise Gateway/Firewall</p><p>3812. . . Mobile server</p><p>3814. . . Switch</p><p>3816. . . Private branch exchange</p><p>3818. . . Internet phone system</p><p>3820. . . Intermediate switch</p><p>3822. . . Wi-Fi users</p><p>3840. . . SOHO network</p><p>3842. . . External user device</p><p>3844. . . Access point</p><p>3846. . . Broadband router/modem</p><p>3860. . . Public hotspot network</p><p>3862. . . External user device</p><p>3864. . . Access point</p><p>3866. . . Broadband router/modem</p><p>3880. . . Network address translation traversal request</p><p>3882. . . STUN server</p><p>3884. . . Network address translation cross response</p><p>3886. . . Communication path</p><p>3890. . . STUN/TURN server</p><p>3900. . . Simple traversal of user data blocking protocol via network address translation/transverse network address translation traverse implementation using forwarding network address translation</p><p>3902. . . Safe tunneling</p><p>4000. . . Translate configuration of generalized network address translation</p><p>4002. . . Corporate network</p><p>4010. . . Enterprise Gateway</p><p>4012. . . Network address translation cross response</p><p>4080. . . Network address translation traversal request</p><p>4092. . . Mobile server</p><p>4102. . . process</p><p>4104. . . process</p><p>4106. . . server</p><p>4200. . . Single media service access point port</p><p>4202. . . server</p><p>4302. . . Outside phone</p><p>4304. . . Second media stream</p><p>4314. . . Wi-Fi network</p><p>4316. . . Mobile communication device</p><p>4350. . . The first media stream</p><p>4362. . . Cellular network</p><p>4390. . . Mute module</p><p>4398. . . server</p><p>4400. . . picture</p><p>4406. . . Handover cycle</p><p>4408. . . Mask</p><p>4410. . . gap</p><p>4416. . . Handover</p><p>4418. . . Mask</p><p>4420. . . overlapping</p><p>4450. . . picture</p><p>4500. . . Media server and voice engine module</p><p>4502. . . Outside phone</p><p>4504. . . Second media information</p><p>4506. . . First media information</p><p>4514. . . Wi-Fi network</p><p>4516. . . Mobile user</p><p>4518. . . Mobile server</p><p>4562. . . Cellular network</p><p>4602. . . Media buffer</p><p>4604. . . Cross-correlation module</p><p>4650. . . First data packet</p><p>4652. . . Second data packet</p><p>4654. . . point</p><p>4656. . . Cube</p><p>4658. . . Cube</p><p>4660. . . New cube</p><p>4662. . . New data packet</p><p>4664. . . Second square</p><p>4666. . . Cube</p>

The present invention will be explained with reference to the following drawings.

Fig. 1 is a system network diagram according to an embodiment of the present invention.

2A-C are diagrams of a mobile server according to an embodiment of the present invention.

Fig. 3 is a diagram of a mobile user according to an embodiment of the present invention.

Figure 4A-E shows the method and structure diagram of fast media handover between Wi-Fi and cellular network.

Figure 5A is a schematic diagram of the conference phone (RC) architecture.

Figure 5B is a message exchange diagram between the RS user and the RC capable media communication server.

Figure 5C is a flow chart of the logic of the media communication server for RC processing.

FIG. 6A is a system block diagram for explaining network stacking according to an embodiment of the present invention.

Fig. 6B is a stacking diagram of a system network according to an embodiment of the present invention.

Figure 7 is a schematic diagram of a secure VoIP (Internet telephony) deployment for corporate communications.

FIG. 8 is a layer diagram of an electric communication conversation established between an external electric communication device and a mobile user in an enterprise according to an embodiment of the present invention.

FIG. 9 is an example diagram of a server function module that can be implemented in a mobile server according to one or more embodiments of the present invention.

FIG. 10 is an example diagram of a user function module that can be a mobile user application according to one or more embodiments of the present invention.

FIG. 11 is a simplified telephone flow chart of the establishment of a telecommunication request initiated by a mobile user in an enterprise according to an embodiment.

FIG. 12 is an example diagram of a phone roaming solution in which mobile users roam from a Wi-Fi network to a cellular network according to one or more embodiments of the present invention.

FIG. 13 is a telephone flow chart of the roaming solution of FIG. 12 according to an embodiment of the present invention.

FIG. 14A is an example diagram of a phone roaming solution in which mobile users roam from a cellular network back to a Wi-Fi network managed by an enterprise according to one or more embodiments of the present invention.

FIG. 14B is a telephone flow chart for providing possible handover steps according to an embodiment of the present invention.

15A is an example diagram of a phone roaming solution for mobile users roaming from a cellular network to a third-party Wi-Fi network according to one or more embodiments of the present invention.

FIG. 15B is a telephone flow chart for providing possible handover steps according to an embodiment of the present invention.

FIG. 16A is a diagram of establishing a phone call between two mobile users according to one or more embodiments of the present invention.

Fig. 16B is a flowchart of the telephone of Fig. 16A according to an embodiment of the present invention.

FIG. 17 is a block diagram of the conventional technology of the transcoder in the carrier management gateway.

Fig. 18 is a block diagram of a configuration for code conversion according to an embodiment.

FIG. 19 is a high-level logic block diagram of an automated conference phone environment according to an embodiment of the present invention.

20 is a diagram of steps taken by the RC server module when establishing an RC (conference call) phone according to an embodiment.

Fig. 21 is a simple telephone flow chart including two teletype conference participants according to an embodiment.

Fig. 22 is a diagram showing the establishment of a teleconference using the parameters specified in Fig. 21 according to an embodiment of the present invention, except that the mobile server is now illustrated as including the presence server, telephone control, and RC server as constituent components Phone flowchart.

FIG. 23 is a call flow chart of the cellular receiver authentication process that occurs when the caller makes a new call to the receiver via the receiver's enterprise extension number according to an embodiment of the present invention.

FIG. 24 is a flowchart of a call that occurs when the receiver does not answer the cellular phone according to an embodiment of the present invention.

FIG. 25 is a telephone flow chart of a cellular receiver authentication procedure with an allotted authentication period according to an embodiment of the present invention.

Fig. 26 is a simplified block diagram of a conventional technique of access points connected to different controllers.

Fig. 27 is a simplified block diagram of the conventional technology of the access point of the interconnection group linked to the controller.

FIG. 28 is a block diagram of a user roaming on a mobile user between two access points managed by a single controller according to an embodiment of the present invention.

FIG. 29 is a block diagram of a user roaming on a mobile user between two access points managed by two different controllers according to an embodiment of the present invention.

FIG. 30 is a telephone flow chart of a roaming solution that does not include an IP address change according to one or more embodiments of the present invention (as discussed in FIG. 28).

FIG. 31 is a telephone flow chart of a roaming solution including an IP address change according to one or more embodiments of the present invention.

Figure 32 is a buffer plan according to one or more embodiments of the present invention.

FIG. 33 is a logical block diagram of a conventional technology in which the host processor is used not only to perform classification and packet forwarding tasks, but also to perform other host processing tasks.

FIG. 34 is a simple logic block diagram of a conventional technology implementation in which a network processor is used to offload some tasks previously performed by the host processor of FIG. 33.

35 is a high-level logic block diagram of a VoIP gateway using FPGAs to provide a redundant Ethernet processing path through the VoIP gateway according to an embodiment of the present invention.

FIG. 36 is a diagram of steps taken by the VoIP gateway of FIG. 35 when processing packet reception according to an embodiment of the present invention.

FIG. 37 is a diagram showing an example of the UDP port lookup step of FIG. 36 according to an embodiment of the present invention.

Figure 38 shows the conventional technology representation of the Voice-Over-IP (VoIP) environment where STUN (Simple Traversal of UDP via NAT) server is used to help NAT (Network Address Translation) traverse.

Figure 39 is an implementation diagram of the conventional technology implementation of STUN/TURN (simple traversal of UDP via NAT/traversal using forwarding NAT) NAT traversal implementation that implements a secure channel between the STUN/TURN server and the media server.

40 is a generalized NAT traversal configuration diagram that can traverse all four types of NAT translation while removing the requirement to maintain the external NAT traversal server outside the enterprise firmware according to an embodiment of the present invention.

FIG. 41 is a NAT traversal configuration diagram of two ports on a media server used to serve media streaming in and out of two external user devices according to an embodiment of the present invention.

42 is a NAT traversal configuration diagram in which a single MSAP port on a media server is used to serve media streams in and out of two external user devices according to an embodiment of the present invention.

FIG. 43 is a configuration diagram of an exemplary conventional technology for processing media data during unloading by wireless communication.

FIG. 44A is a diagram of an exemplary conventional technology removal scheme in which gaps may exist in the media data streams sent by the two networks.

FIG. 44B is a diagram of an exemplary conventional technology removal scheme in which an overlap may exist between media data streams sent by two networks.

FIG. 45 is a configuration diagram of media data during removal by wireless communication according to one or more embodiments of the present invention.

FIG. 46A is an architectural block diagram of a media server and a voice quality engine module according to one or more embodiments of the present invention.

FIG. 46B is a block diagram of an example of a method for generating cross-related media data sets of a packet in an embodiment.

FIG. 47 is a flowchart of a method for processing media data during the disconnection of mobile telecommunication devices between networks according to one or more embodiments of the present invention.

FIG. 48 is a flowchart of a method for controlling the signal level of a mobile telecommunication device during a disconnection period according to one or more embodiments of the present invention.