EP1135901A2 - System and method for providing mobile switching and multi-party services over a packet-switched network - Google Patents

Abstract

A system and method of providing an integrated wireless packet-switched network system (100, 1202) which includes IP-based switching (207) in a gateway (250) associated therewith. A cellular network portion (102) of the integrated network system comprises a radio network controller (130) for providing radio access services to mobile stations (103). A packet-switched network portion (206) is provided for transporting cellular communication traffic. An interface provided between the gateway and radio network controller includes a first protocol translator (304) for converting Transaction Capability Application Part (TCAP) messaging into IP messaging and a second protocol translator (306) for converting Integrated Services Digital Network (ISDN) User Part (ISUP) messaging into Primary Rate Interface (PRI) messaging. In some exemplary embodiments, either or both of the translators may be integrated within the IP gateway. In a further embodiment, a flash proxy agent (203) is disposed between the gateway and a Multipoint Control Unit (1302) for facilitating multi-party conferences involving ANSI-53 or proprietary flash messaging.

Description

SYSTEM AND METHOD FOR PROVIDING

MOBILE SWITCHING AND MULTI-PARTY SERVICES OVER A

PACKET-SWITCHED NETWORK

PRIORITY STATEMENT UNDER 35 U.S.C §119(e) & 37 C.F.R. §1.78

This nonprovisional application claims priority based upon the following prior U.S. provisional patent application entitled: "System and Method for Providing Mobile Stations in a Radio Telecommunications Network with Multimedia Services over Packet-Based Networks," Ser. No. 60/110,811 (Attorney Docket Number 1000-

0136), filed December 3, 1998, in the names of: Hung Tran, Kim Vo, Bartosz Balazinski, Jean-Francois Bertrand, Laura Hernandez, and Suhail Hasan.

CROSS-REFERENCE TO RELATED APPLICATIONS This application discloses subj ect matter related to the subj ect matter disclosed in the following co-assigned patent applications: (1) "System and Method for Providing Wireless Telephony over a Packet-Switched Network," filed October 26,

1999, Ser. No. (Attorney Docket Number 1000-144), in the names of: Kim

Vo, George Foti, Hung Tran, Jean-Francois Bertrand, Bartosz Balazinski, Francis Lupien, Zeng-Jun Xiang, and Yang Lu; (2) "System and Method for Mobile Terminal

Registration in an Integrated Wireless Packet-Switched Network," filed October 26,

1999, Ser. No. (Attorney Docket Number 1000-154), in the names of:

Hung Tran, Laura Hernandez, Jean-Francois Bertrand, and Bartosz Balazinski.

BACKGROUND OF THE INVENTION

Technical Field of the Invention

The present invention relates to telecommunication systems and, more particularly, to a system and method for providing mobile switching and multi-party services over a packet-switched network such as, for example, a network using the Internet Protocol (IP). Description of Related Art

Coupled with the phenomenal growth in popularity of the Internet, there has been a tremendous interest in using packet-switched network infrastructures (e.g., those based on IP addressing) as a replacement for the existing circuit-switched network infrastructures used in today's telephony. From the network operators' perspective, the inherent traffic aggregation in packet-switched infrastructures allows for a reduction in the cost of transmission and the infrastructure cost per end-user. Ultimately, such cost reductions enable the network operators to pass on the concomitant cost savings to the end-users. The existing Noice-over-IP (NoIP) networks implement communications infrastructures that are typically based on multiple protocols which include, for example, the well-known H.323 protocol. These protocols are primarily oriented to operating with fixed-network-based telecommunications protocols and are designed to provide such services as call control, et cetera, for wireline subscribers. Current NoIP systems, accordingly, cannot be used advantageously in wireless environments, although some NoIP systems may support rudimentary location management services.

There exist several inadequacies in the Plain Old Cellular System (POCS) with respect to supporting IP-based infrastructures and services. Also, there exist deficiencies and shortcomings in the existing IP -based NoIP systems in terms of supporting wireless access technology such as for example, ANSI- 136, Global System for Mobile communications (GSM), IS-95, et cetera. Some of the more significant of these inadequacies and shortcomings are summarized below.

First, current POCS systems and technology infrastructures are not compatible with communications infrastructures as required by the VoIP standards. The operation, maintenance, and the connection management required by the traditional

POCS systems are based on switched physical trunk connections. These mechanisms are not compatible with the packet switching/routing mechanisms such as, e.g., Domain Name System (DNS), Dynamic Host Configuration Protocol (DHCP), etc. required for managing device/host addressing and configuration. Incompatibilities also exist between POCS protocols and communications protocols of the existing VoIP applications. The POCS systems cannot support aPlain Old Telephone System (POTS) or Integrated Services Digital Network (ISDN) client in the Internet context. The Internet "client" is typically required to handle Internet- based protocols such as, e.g., Real-time Transfer Protocol (RTP), Resource Reservation Protocol (RSNP), etc. which are not in the definition or domain of the POCS systems.

Another important disparity which should be noted is that the POCS signaling and user data planes use distinct physical transport and network facilities, whereas the same physical network facilities are used to route signaling and user data information in the Internet domain. With respect to the inadequacies of the existing NoIP systems, it should be appreciated that current VoIP clients and infrastructure can handle neither the wireless access-side technology nor the basic network-side functional signaling plane which enables mobility management, authentication/security, service definition, service mitigation and execution, et cetera. Clearly, the provision of such advancements in the POCS as Wireless Intelligent Network (WIN) services, can only magnify these and other disparities and incompatibilities between the POCS and VoIP infrastructures. Based on the foregoing, it is apparent that in order to address these and other problems of the current technologies set forth above, what is needed is a seamless integration between the existing POCS and VoIP infrastructures so that the numerous advantages, known and hitherto unknown, of packet-based networks may be realized within the context of wireless telecommunications. However, as those of ordinary skill in the art should readily appreciate, critical to implementing mobile network infrastructures within a VoIP system is providing end-user switching services on an IP -based core network in an economical way. In addition, it should be further appreciated that in an integrated network that supports both mobile stations and IP terminals, it would be very advantageous if the IP entity that facilitates multi-party services such as, e.g., a three-party conference, in accordance with a current protocol, e.g., the H.323 standard, can still be used for such services regardless of the access. However, it is well-known that the current procedures for setting up a three-party conference using the H.323 protocol do not support call enquiry, call waiting, or three-party conferencing as defined by the mobile communications standard ANSI-53 or certain proprietary flash messaging schemes. Thus, it would be of significant benefit to provide a system and method for supporting the ANSI-53 or proprietary flash messaging within the context of an integrated VoIP system.

SUMMARY OF THE INVENTION

In one aspect, the present invention is directed to an integrated wireless packet- switched network for providing telecommunications services to a mobile subscriber. The network comprises an IP -based network portion for transporting communication traffic relating to the mobile subscriber. A radio network controller is provided for controlling radio access for the mobile subscriber. A gateway is disposed between the packet-switched network (IP-based) portion and the radio network controller. Further, the gateway includes means for switching the communication traffic relating to the mobile subscriber. The interface between the gateway and radio network controller includes a first protocol translator for converting Transaction Capability Application Part (TCAP) messaging into IP messaging and a second protocol translator for converting Integrated Services Digital Network (ISDN) User Part (ISUP) messaging into Primary Rate Interface (PRI) messaging. In some exemplary embodiments, either or both of the translators may be integrated within the IP gateway.

In another aspect, the present invention is directed to a method of registering a mobile terminal in an integrated wireless packet-switched network which includes a cellular network portion and a packet-switched network portion. The cellular network portion comprises a serving radio network controller (RNC) for providing radio access services for the mobile terminal. The packet-switched network portion includes a gatekeeper and a gateway, wherein the gateway comprises an IP stack for switching cellular traffic related to the mobile terminal. The method begins by determining, in the serving RNC, that the mobile terminal is located in a service area associated with the serving RNC. Responsive to the determining step, an Invoke message is sent from the serving RNC to the gateway, wherein a Registration Update signal is encapsulated in the Invoke message. Upon receiving the Invoke message, a Registration Request message is then sent from the gateway to the gatekeeper, the Registration Request message including a terminalAlias parameter. Responsive thereto, a Registration Confirm message is sent from the gatekeeper to the gateway if the mobile terminal is successfully registered at the gatekeeper. Otherwise, a Registration Reject message is sent from the gatekeeper to the gateway. Thereafter, responsive to receiving either the Registration Confirm message or the Registration Reject message, a registration status of the mobile terminal is reported via a Return Result message sent by the gateway to the RNC.

In a further aspect, the present invention is related to a method of de-registering a mobile terminal in an integrated wireless packet-switched network system which includes a cellular network portion and a packet-switched network portion. The cellular and packet-switched network portions include components as set forth above. The method begins by first determining, in the serving RNC, that the mobile terminal located in a service area associated with the serving RNC has powered down. Responsive to the determining step, an Invoke message is sent from the serving RNC to the gateway, wherein a Registration Update signal is encapsulated in the Invoke message. Upon receiving the Invoke message, an Unregistration Request message is sent from the gateway to the gatekeeper, the Unregistration Request message including an endpointAlias parameter. Responsive thereto, an Unregistration Confirm message is sent from the gatekeeper to the gateway if the mobile terminal is successfully unregistered at the gatekeeper. Otherwise, an Unregistration Reject message is sent from the gatekeeper to the gateway. Subsequently, responsive to receiving one of the Unregistration Confirm and Unregistration Reject messages, a registration status of the mobile terminal is reported via a Return Result message sent from the gateway to the RNC.

In a still further aspect, the present invention is directed to an integrated wireless packet-switched network having a wireless portion and an Internet Protocol (IP) portion. The IP portion preferably includes a gateway for interfacing with the wireless portion. The network system comprises a radio network controller for providing radio access services to a mobile subscriber. The gateway includes means for switching communication traffic relating to the mobile subscriber. The network system further includes one or more protocol translators disposed between the gateway and the radio network controller.

In yet another aspect, the present invention provides an integrated Voice over

IP (VoIP) network that is capable of supporting multi-party services involving ANSI- 53 messaging or proprietary flash messaging. The VoIP network preferably comprises a radio network controller that provides radio access services to one or more mobile subscribers. A gateway is operably coupled to the radio network controller for combining a packet-switched portion and a circuit-switched cellular portion of the integrated VoIP network. A Multipoint Control Unit (MCU) for setting up multi-party services is connected to the packet-switched portion. A flash proxy agent is disposed between the MCU and the gateway for mapping ANSI-53 or proprietary flash messages relating to the multi-party services into messages compatible with the MCU.

In alternative embodiments, the flash proxy agent may be integrated within suitable

H.323 components such as, e.g., the MCU or the gateway.

BRIEF DESCRIPTION OF THE DRAWINGS

A more complete understanding of the present invention may be had by reference to the following Detailed Description when taken in conjunction with the accompanying drawings wherein: FIG. 1 depicts a functional block diagram of a wireless IP (WLIP) network in accordance with the teachings of the present invention;

FIG .2 depicts a functional block diagram of a portion of the exemplary WLIP network with additional components for providing IP -based switching;

FIG. 3 depicts a functional block diagram of an addressing scheme for use in the WLIP network;

FIGS. 4 A and 4B depict, respectively, control message pathways for registration and de-registration of a mobile station in the WLIP network;

FIG. 5 depicts a control message pathway for placing a call from a mobile station in the WLIP network; FIG. 6 depicts a control message pathway for placing a call to a mobile station in the WLIP network; FIG. 7 depicts a control message pathway for an exemplary embodiment of a call waiting scenario in the WLIP network;

FIG. 8 depicts a control message pathway for an exemplary embodiment of a call enquiry scenario in the WLIP network; FIG. 9 depicts a control message pathway for supporting an exemplary embodiment of a multi-party conference in the WLIP network;

FIG. 10 depicts a functional block diagram of another view of the WLIP network portion for supporting multi-party services using a Multipoint Control Unit (MCU); FIG. 11 depicts a functional block diagram of the WLIP network portion with the MCU for supporting multi-party services using a flash agent provided in accordance with the teachings of the present invention;

FIGS. 12-14 depict control message pathways for additional embodiments of a multi-party conference using the flash agent; and FIGS. 15 and 16 depict control message pathways for additional exemplary embodiments of call waiting scenarios in the WLIP network portion having the flash agent.

DETAILED DESCRIPTION OF EMBODIMENTS FIG. 1 depicts a functional block diagram of a WLIP network system 100 for providing H.323-based mobile switching in accordance with the teachings of the present invention. A legacy PSTN/PLMN network portion 102 is connected to a Home Location Register (HLR) 160 via a Signaling System No. 7 (SS7) path 257. An H.323-based VoIP portion 206 comprises an IP network 207 disposed among a plurality of H.323-compliant components such as, for example, a gatekeeper 200, one or more terminals (e.g., terminal 203), one or more PCS (e.g., PC 202), a Multipoint Conference Unit (MCU) 204, et cetera.

In order to integrate the VoIP network portion 206 with the POCS infrastructure, a conventional Mobile Switching Center (MSC) of the POCS network is modified in accordance with the teachings of the present invention to provide only radio services. Accordingly, the switching functionality of the MSC is removed therefrom such that it becomes a Radio Network Controller (RNC), for example, RNC 130 shown in FIG. 1. An IP or RNC gateway 250 is provided preferably as an interface between the IP network 207 and the RNC 130. The IP/RNC gateway 250 is an H.323-compliant gateway that is suitably modified to support the communication between the H.323 network and the RNC 130. An SS7/ANSI-41 path 210 is used between the RNC 130 and the IP gateway 250 during call setup. An ISDN User Part (ISUP) signaling path 208 is also provided between the RNC 130 and the IP gateway 250 in order to establish trunk connections for voice transferring during the call.

The gatekeeper (GK) 200 operates as a mobility server for keeping track of various call clients and servers. In addition, the gatekeeper 200 maintains registration and status information with respect to mobile stations (for example, MS 103) and

H.323 clients in general. Preferably, the gatekeeper 200 is provided as an H.323 entity on the IP network 207 (which may comprise a Local Area Network) that provides address translation and controls access to the network for the other H.323 components. The H.323 terminals (e.g., terminal 203) are preferably provided as IP clients that may transfer voice, video, and multimedia data. The MCU 204 is preferably provided for establishing conference calls and multi-party services. Although not specifically shown in this FIG., a Multipoint Controller (MC) may also be provided as part of the

VoIP portion 206. Furthermore, a "plain" PSTN gateway 249 may be provided between the VoIP network portion 206 and the legacy PSTN/PLMN network portion

102 with a connection 253. Alternatively, the legacy PSTN/PLMN network portion

102 is coupled to the IP network 207 via the IP RNC gateway 250. Accordingly, it should be realized that the GK 200 may decide to route a call to the external network

(i.e., the PSTN/PLMN portion 102) via either the IP/RNC GW 250 or the PSTN GW 249, using their respective paths alternatively (i.e., path 255 or path 253 , respectively).

The GK may also perform a load balancing or bandwidth control function with respect to such routing to the external network portion.

FIG. 2 illustrates a functional diagram of a relevant portion 202 of the exemplary WLIP network system 100 shown in FIG. 1, with additional details provided for the gateway-RNC interface pathway. A first protocol translator (Tl) 304 is preferably provided as an SS7 stack on the path 210 for converting Transaction Capability Application Part (TC AP) messaging into suitable IP messaging. A second protocol translator (T2) 306 is provided on the path 208 for performing the translation between ISUP messaging and Primary Rate Interface (PRI) messaging. Those of ordinary skill in the art should readily understand that either or both of the translators provided in accordance herewith may be integrated within the IP/RNC gateway 250 in some implementations. Further, although not shown in FIG. 1 or FIG.2, cellular entities such as, for example, a Visitor Location Register (VLR), one or more base stations, an Authentication Center (AC), Service Control Points (SCPs), et cetera, may be included within the WLIP network system 100. Referring now to FIG. 3, shown therein is a functional block diagram of an exemplary addressing scheme for use in the WLIP network 100. Preferably, the address translation between the Location Area (LA) and the RNC is performed only when the IP gateway 250 supports more than one RNC. An RNC, e.g., RNC 130, may control one or more base stations (BSs). For example, BS 140A and BS140B are shown in this FIG. Translation between Mobile Identification Number (MIN) and LA is preferably performed only when the LA information is to be maintained within an access network instead of the gatekeeper 200. The LA information may be transmitted to the gatekeeper 200 as a terminalAlias parameter in a Registration Request (RRQ) message and may be returned as a destinationlnfo or srclnfo parameter in an Admission Confirm (ACF) message. It should be appreciated that the LA information may also be sent as nonStandardData in the RR and ACF messages. In a presently preferred exemplary embodiment of the present invention, a mobile station (MS) may be paged globally.

Referring now to FIG. 4A, a control message pathway is illustrated therein for registering an MS (e.g., MS 103) disposed in the WLIP network 100. After determining that the MS 103 is located within its serving area, the serving RNC 130 sends an ANSI-41 private message, e.g., H323 Invoke message 602 to the RNC gateway 250. The MSS-MRS RegUpdate signal is encapsulated within the H323 Invoke message 602. Upon receiving the Invoke message 602, the RNC gateway 250 sends a RAS RRQ message 604 to the gatekeeper 200.

If the MS has previously registered with a gateway within the domain of the JO- gatekeeper 200, the gatekeeper 200 simply returns a RASACF message. Otherwise, it stores the MIN as an alias of the gateway and returns a RAS Registration Confirm (RCF) message 606. If the MS has failed the registration process, a RJS Registration Reject (RRJ) return message (also labeled as message 606) may be sent. Upon receiving either the RJS RCF or RRJ message 606, the JP RNC gateway 250 constructs an ANSI-41 private message, H323 Return Result (RR) response message 616, by wrapping the MSS-MRS RegUpdateR signal and returns it to the RNC 130.

FIG.4B depicts a control message pathway for de-registering an MS (e.g., MS 103) in the WLIP network 100 provided in accordance with the teachings of the present invention. The RNC 130 sends an ANSI-41 H323 Invoke message 610 (with encapsulated MSS-MRS RegUpdate signal) to the IP/RNC gateway 250 to inform the H.323 IP network 206 that the MS 103 has powered down. Upon receiving the H323 Invoke message 610, the gateway 250 sends a RJS Unregistration Request (URQ) message 612 to the gatekeeper 200 to remove the MS from its registry. An endpointAlias parameter is provided within the RJS URQ message 612. After determining that the registration of the MS can be revoked, the gatekeeper 200 updates its registry appropriately and sends aRJS Unregistration Confirm ( UCF) message 614 to the IP/RNC gateway 250. If the registration of the MS cannot be revoked for some reason, the gatekeeper 200 transmits &RAS Unregistration Reject (URJ) message (also denoted as message 614) to the gateway. Thereafter, responsive to the UCF or URJ message 614, the IP/RNC gateway 250 sends an ANSI-41 H323 RR response message 616 to the RNC 130, including the encapsulated RegUpdateR signal therein.

Referring to FIG. 5, depicted therein is a control message pathway for placing a call from an MS to a terminal (e.g., terminal 203 shown in FIG. 1 or FIG.2) disposed in the WLIP network 100. An ANSI-41 H323 Invoke message 702 (with an encapsulated SeizeTCIl signal) is sent from the RNC 130 to the IP/RNC gateway 250. Responsive thereto, a RAS Admission Request (ARQ) message 704 which includes the calling and called parties' numbers (A# and B#, respectively) is sent from the IP/RNC gateway 250 to the gatekeeper 200. A RASACF message 706 is then returned from the gatekeeper 200. After receiving the A CF message 706, the IP/RNC gateway 250 determines if the call can be handled. If not, an ANSI-41 H323 RR message 708 including suitable parametric information, e.g., CallCong parameter, is returned to the RNC 130. Otherwise, the IP/RNC gateway 250 returns an ANSI-41 H323 Invoke message 710 with a ConnectMS2 parameter to the RNC 130. In response thereto, an ANSI-41 H323

RR message 712 including a MSConnected parameter is returned to the gateway 250. Subsequently, a trunk connection 714 is established between the gateway 250 and RNC 130 using the B# and a suffix received in the MSConnected parameter.

Thereafter, a Q.931 SetUp message 716 with appropriate parametric information is sent from the IP/RNC gateway 250 to the terminal 203. In response, a Q.931 Call Proceeding message 718 is returned from the terminal 203 to the gateway 250. The terminal 203 also engages in RJS messaging with the gatekeeper 200 as shown by the RASARQ and ACF messages 720 and 722, respectively. After completing the RJS messaging, the terminal 203 sends a Q.931 Alerting message 724 to the IP/RNC gateway 250. After a ringback tone 726 from the gateway 250 to the

RNC 130, a Q.931 Connect message 728 is sent by the terminal 203 to the gateway 250. Thereafter, an H.245 phase 730 is established between the RNC 130 and the terminal 203.

Referring now to FIG. 6, illustrated therein is a control flow pathway for placing a call to an MS from a terminal or a wireline phone. A voice gateway (GW)

152 is provided as a media gateway, preferably for interfacing between the VoIP network portion and the PSTN (not shown). Pursuant to the call to be placed to the MS, the voice GW 152 first engages in RJS messaging with the gatekeeper 200 as exemplified by ARQ and ACF messages 802 and 804, respectively. Thereafter, a Q.931 SetUp message 806 with appropriate parametric information is sent from the voice GW to the IP/RNC gateway 250. Responsive thereto, the IP/RNC gateway 250 sends a Call Proceeding message 808 to the voice GW 152.

The IP/RNC gateway 250 then engages in its own RJS messaging with the gatekeeper 200 as depicted by ARQ and A CF messages 810 and 812, respectively. Subsequently, the IP/RNC gateway 250 sends an ANSI-41 H323 Invoke message 814 to the RNC 130 with a FindMSposl signal encapsulated therein. After successfully finding the MS' location, the RNC 130 responds by returning an ANSI-41 H323 RR message 816 with the encapsulated MSposfoundl signal. Thereafter, a trunk connection 822 is established between the RNC 130 and the IP/RNC gateway 250, pursuant to the H323 Invoke and RR messages 818 and 820, respectively. These messages include, respectively, ConnectMS2 and MSConnected parameters.

Subsequent to additional ANSI-41 H323 Invoke and RR messages (messages 824 and 826, which include AlertWinfo and Alert WinfoR parameters, respectively) between the RNC 130 and the IP/RNC gateway 250, a Q.931 Alerting message 828 is propagated from the IP/RNC gateway 250 to the voice GW 152. Thereafter, additional ANSI-41 H323 Invoke and RR messages (messages 830 and 832, respectively) between the RNC 130 and the IP/RNC gateway 250 give rise to a Q.931 Connect message 834 that is propagated from the IP/RNC gateway 250 to the voice GW 152. An H.245 phase 730 is then established between the RNC 130 and voice GW 152. FIGS .7 through 9 depict control message pathways for multi-party transactions involving proprietary flash messages which are converted or mapped to appropriate

H.323 messages by a flash proxy agent that is described in greater detail hereinbelow.

Referring now to FIG. 7, a control message pathway for a call waiting scenario involving a Private Branch Exchange (PBX) 1002 in the WLIP network 100 is shown therein. A two-party call (designated as the A-B call) 1004 is first established preferably in a manner set forth above. When a third party caller (C) attempts to reach the B party, a number of Q.931 and RJS messages (messages 1006 - 1020) similar to those described hereinabove are propagated among the PBX 1002, voice GW 152, IP/RNC gateway 250 and, the gatekeeper 200. Thereafter, a CαllWαiting tone 1022 is issued from the IP/RNC gateway 250 to the RNC 130 serving the MS. After a

Q.931 Alerting message 1024 is sent from the gateway 250 to the PBX 1002, a flαshwinfo message 1026 is sent by the RNC 130 to the IP/RNC gateway 250. Responsive thereto, a hold message 1028 is issued by the JP/RNC gateway 250 to the voice GW 152 for holding the A-B call. A hold αck message is returned from the voice GW 152 thereafter. Subsequently, a Q.931 Connect message 1032 is sent by the

IP/RNC gateway 250 to the PBX 1002 for effectuating the C-B call. FIG. 8 depicts a control message pathway for an exemplary call enquiry scenario in the WLIP network 100 of the present invention. It should be readily appreciated that the establishment of a two-party call 1102 and subsequent control messages 1104 - 1128 are similar to those described in greater detail in the foregoing sections. Accordingly, it is believed that the exemplary call enquiry method is readily apparent from FIG. 8 and the description above taken in conjunction herewith.

Referring now to FIG. 9, depicted therein is a control message pathway for supporting a three-party conference in the WLIP network 100. Preferably, a 3-party state 1202 is established with decentralized control, for example, in a multicast manner, of the parties involved. Aflashwinfo message 1204 is sent from the RNC 130 to the IP/RNC gateway 250 after a two-party call (e.g., A-B call) has been put on hold. Responsive to theflashwinfo message 1204, the IP/RNC gateway 250 sends a retrieve message 1206 to the voice GW 152 in order to effectuate the retrieval of the held A-B call. A retrieve ack response message 1208 is returned from the voice GW 152 to the IP/RNC gateway 250. It should be realized by those of ordinary skill in the art that the decentralized multipoint conference method of the present invention may not involve a point-to-point call setup of the participating terminals/clients with the MCU.

Based on the foregoing, it should be appreciated that the present invention advantageously provides an integrated wireless IP network solution for realizing end- user switching services on a packet-based network. Furthermore, the present invention provides an inexpensive way to integrate IP -based switching with cellular networks because of the ease of the provision of an IP switching stack in a gateway and removing the costly MSC components from the network. Accordingly, it should be further appreciated that by using the present invention, operators can quickly and cost- effectively provide IP-based cellular telephony solutions within compact LAN architectures.

In the following portions of the Detailed Description, a system and method is provided for supporting multi-party services in an integrated network using the MCU wherein conventional ANSI-53 messaging is appropriately mapped to suitable H.323 procedures. FIG. 10 depicts a functional block diagram of another view of the WLIP network portion 1202 for supporting multi-party conferences using an MCU 1302. Because the teachings of the present invention are exemplified using an H.323-based network, a brief description of the H.323 entities is provided hereinbelow. The H.323 standard defines four major types of components for forming an inter-operable network: terminals, gateways, gatekeepers and multipoint control units (MCUs). In general, terminals, gateways and MCUs of an H.323-based network are referred to as "endpoints." Gateways are typically provided between networks (or network portions) that operate based on different standards or protocols. For example, one or more gateways may be provided between a packet-switched network portion and a circuit-switched network portion. Terminals are employed by end-users for accessing the network or portions thereof, for example, for placing or receiving a call, or for accessing multimedia content at a remote site.

The gatekeeper is typically defined as the entity on the network that provides address translation and controls access to the network for other H.323 components.

Usually, a gatekeeper is provided with the address translation capability for a specified portion of the network called a "zone." Accordingly, a plurality of gatekeepers may be provided for carrying out address translation that is necessary for the entire network, each gatekeeper being responsible for a particular zone. In addition, gatekeepers may also provide other services to the terminals, gateways, and MCUs such as bandwidth management and gateway location.

The H.323 standard defines multiple types of addresses associated with each endpoint such as, for example, a transport address (which, for example, corresponds to the IP address and the port address of a terminal operated by the end-user) and an alias address. An endpoint may have one or more aliases associated with it.

Exemplary aliases may include the well-known EJ64 telephone numbers, H.323 IDs (such as names, email-like addresses, etc.), and so on. The address translation service of the gatekeeper provides an alternative method of addressing an endpoint wherein a user-friendly alias (e.g., the EJ64 telephone number) associated therewith may be translated into its appropriate transport address used by the protocol.

Continuing to refer to FIG. 10, the exemplary VoIP core network 206 comprises one or more gatekeepers (e.g., gatekeepers 200A and 200B), one or more terminals (e.g., VCONl terminal 1304 and VCON2 terminal 1306), et cetera, in addition to the MCU 1302. Further, the gateway 250 is preferably provided for interfacing with a radio network controller (e.g., RNC 130) as described hereinabove. One or more base stations, for example, BS 1204, and associated MSs (e.g., MSI

103 A and MS2 103B) are preferably disposed in the cellular network portion of the WLIP network 100 as described hereinabove.

Conventionally, the MCU 1302 is provided within the H.323-based VoIP core 206 as an endpoint for providing the capability for three or more terminals and gateways to participate in a multipoint conference. While the MCU 1302 is capable of supporting a conference involving the H.323 entities, it is well-known that the current procedures used in setting up an H.323 conference do not support multi-party services such as call enquiry, call waiting, or 3-party conferences, as defined by the mobile communications standard ANSI-53. FIG. 11 depicts a functional block diagram of yet another view of the WLIP network portion 1203 for supporting multi-party services using a flash agent 203 provided in accordance with the teachings of the present invention. Only relevant portions of the overall network architecture are depicted in this FIGURE. The flash agent 203 is preferably provided as a proxy device disposed between the gateway 250 and the MCU 1302. Accordingly, the flash agent 203 maps an ANSI-53 flash, or such other proprietary flash messages as maybe appropriate (e.g., the flash messages shown in FIGS. 7 through 9) to a suitable H.323 procedure for creating a conference or effectuating a multi-party service. FIGS. 12-14 depict control message pathways for additional exemplary embodiments of a three-party conference service in accordance with the teachings of the present invention. FIGS. 15 and 16 depict control message pathways for two additional exemplary call waiting scenarios, respectively. It should be understood that in each of these FIGURES described immediately hereinbelow the flash agent 203 is advantageously utilized between the gateway 250 and MCU 1302 for mapping ANSI-53 messages. The scenario where an H.323 terminal (e.g., VCONl 1304) is the creator of a multi-party conference is exemplified in FIG. 12. Initially Jhe VCONl terminal 1304 creates a two-party conference with an MS by sending a Create message 1402 to the MCU 1302. The Create message 1402 preferably includes a conference password (e.g., 8711), a separator (which may be provided as a sequence of special characters, e.g., **), and the MS' telephone number (e.g., 888-555-0001). In response, the MCU 1302 sends an Invite message 1404 which contains the password and telephone number information received from the VCONl terminal 1304 to the gateway 250. A Call 1406 is then placed by the gateway 250 to the MS using this information which is routed via the RNC 130.

An ANSI-53 Flash message 1408 containing the third party's telephone number, for example, the telephone number 777-555-0002 which belongs to the

VCON2 terminal 1306, is sent from the RNC 130 to the gateway 250, responsive to the data entered at the MS pursuant to a second conference password. When the Flash message 1408 is received at the gateway 250, the first conference password (i.e., 8711) is preferably stored, and the LAN connection is put on hold (i.e., the RTP speech handler and a call handler associated with the initial two-party conference are disassociated). A Create message 1412 is generated by the gateway 250 which includes the second conference password (e.g., 8712), a separator (which may again be provided as a sequence of special characters, e.g., **), and the telephone number for the VCON2 terminal 1306. This message 1412 is sent from the gateway 250 to the MCU 1302.

Responsive to the Create message 1412, the MCU 1302 sends an Invite message 1414 to the VCON2 terminal 1306, including the password and telephone number information, for connecting the terminal with the MS. Thereafter, the MS toggles between the original MS-VCON1 connection and the MS- VCON2 connection until a three-party state is achieved. The toggling between the connections is preferably effectuated by sending Flash messages with embedded codes (e.g., messages 1418, 1422, and 1426) and propagating Release messages (e.g., messages 1416 and 1418) between the gateway 250 and the VCON terminals. After establishing the three-party state pursuant to the Flash message 1434, a Release message 1436 is propagated between the gateway 250 and the MCU 1302. Subsequently, the three parties, i.e., the MS and the two VCON terminals are engaged in a phone conference. FIG. 13 depicts the control message pathway for the situation where the MS is the creator of the original two-party conference with a VCON terminal. The control messages 1502 - 1536 are substantially similar to those described above in reference to FIG. 12 and accordingly, only the salient features with respect to this exemplary call scenario are described herein. The MS creates and invites the VCONl terminal 1304 to the first conference connection via dialing a conference password (e.g., 8711), a separator, and the terminal's telephone number (e.g., 777-555-0001) (control messages 1502, 1506, and 1508). Subsequently, after sending a Flash message 1504, the MS creates and invites the VCON2 terminal 1306 to the second conference connection via dialing another conference password (e.g., 8712), a separator, and the second terminal's telephone number (e.g., 777-555-0002) (control messages 1512-1514).

FIG. 14 depicts the conference scenario where two MSs, e.g., MSI 103 A and MS2 103B, are involved in the call connections. Again, only the salient features of this callflow are set forth. MS 1 103 A is provided to be the creator of the original two- party call. MS2 103B is the creator of the enquiry two-party conference connection. MSI creates and invites MS2 to the first conference via dialing in the data as exemplified above. The control messages 1604-1608 illustrate this callflow portion. MS2 creates and invites a terminal (e.g., the VCON2 terminal 1306) to the second conference by dialing in the requisite data as shown by messages 1614-1616. After a three-party state is achieved as explained in the foregoing, a Release message 1638 is propagated between the gateway 250 and MCU 1302.

FIG. 15 depicts a control message pathway for an exemplary embodiment of a call waiting scenario in the WLIP network portion 1203 provided in accordance with the teachings of the present invention. In this embodiment, MSI 103 A receives a call from the VCONl terminal 1304 while engaged in a two-party conference with MS2 103B, as shown by control messages 1702-1708. The call from the VCONl terminal 1304 is preferably effectuated in the same manner as described hereinabove. After receiving an Invite message 1712 from the MCU 1302, an H.323 Admission Request (ARQ) message is sent from the gateway 250 to the gatekeeper (not shown in this

FIG.). Upon receiving anAdmission Confirm (ACF) response message therefrom, the gateway 250 stores the ID of the call handler associated with the two-party conference and issues a Call Waiting tone 1716 to the RNC 130. Depending upon the dial input at the MSI, three exemplary events may then take place. For example, by inputting a "0" (message 1718), a Release 1720 of the Call Waiting leg is effectuated between the gateway 250 and the VCONl terminal 1304. By inputting a "1" (message 1722), the original two-party connection is terminated (Release message 1726) and the MSI 142A may then answer the waiting call (Connect messagel728). By inputting a "2", the original call is put on hold and the MS answers the waiting call (Connect message 1734). FIG. 16 depicts yet another exemplary embodiment of a call waiting scenario in the WLIP network portion 1203 wherein MS 1 103 A receives a call from MS2 103B while in a two-party conference with a terminal, e.g., the VCONl terminal 1304. The establishment of the original two-party conference is exemplified by messages 1802- 1806. WhenMS2 103B places a call, the RNC 130 sends a Call From message 1808 to the gateway 250. Responsive thereto, a Call Waiting tone 1812 is issued from the gateway 250 to MSI. Thereafter, an ARQ- ACF messaging session is established between the gateway 250 and the gatekeeper (not shown in this FIG.) so that the gateway 250 stores the ID of the call handler associated with the original two-party conference. Subsequently, similar to the call waiting events described above, multiple call events may be effectuated in this exemplary embodiment by inputting appropriate information at MSI 103 A.

It should be appreciated by those skilled in the art that the flash agent 203 provided in accordance with the teachings herein advantageously converts legacy ANSI-53 messaging used for establishing multi-party services into appropriate H.323 messaging usable in a host of VoIP implementations. It should further be appreciated that the flash agent functionality, which may be suitably integrated within a gateway or other H.323 components of the network, may also be provided in conjunction with the RNC 130 disposed in the WLIP network portion 202 that includes suitable protocol translators as disclosed herein with respect to FIG. 2. Although the systems and methods of the various aspects of the present invention have been described in particular reference to the H.323 protocol and ANSI- 41 standards, it should be realized upon reference hereto that the innovative teachings contained herein are not necessarily limited thereto and may be implemented advantageously with any applicable packet-switching protocols and radio telecommunications standards. Furthermore, it is believed that the operation and construction of the various aspects of the present invention will be apparent from the foregoing description. While the method and system shown and described have been characterized as being preferred, it will be readily apparent that various changes and modifications could be made therein without departing from the scope of the present invention as set forth in the following claims.

Claims

WHAT IS CLAIMED IS:

1. An integrated wireless packet-switched network for providing telecommunications services to a mobile subscriber, comprising: a packet-switched network portion for transporting communication traffic, wherein the communication traffic comprises traffic relating to the mobile subscriber; a radio network controller that controls radio access for the mobile subscriber; and a gateway disposed between the packet-switched network portion and the radio network controller, the gateway including means for switching the communication traffic relating to the mobile subscriber.

2. The integrated wireless packet-switched network as set forth in claim 1, further comprising at least one protocol translator disposed between the radio network controller and the gateway.

3. The integrated wireless packet-switched network as set forth in claim 1, wherein the packet-switched network portion operates based on Internet Protocol (IP), and the network further comprises a first protocol translator for converting

Transaction Capability Application Part (TCAP) messaging into IP messaging and a second protocol translator for converting Integrated Services Digital Network (ISDN) User Part (ISUP) messaging into Primary Rate Interface (PRI) messaging, the translators being disposed between the gateway and the radio network controller.

4. The integrated wireless packet-switched network as set forth in claim 3, wherein the first protocol translator is integrated within the gateway.

5. The integrated wireless packet-switched network as set forth in claim 3, wherein the second protocol translator is integrated within the gateway.

6. The integrated wireless packet-switched network as set forth in claim 1, further comprising: a Multipoint Control Unit (MCU) for facilitating a multi-party service involving the mobile subscriber; and a flash proxy agent disposed between the MCU and the gateway for mapping ANSI-53 messages relating to the multi-party service into messages compatible with the MCU.

7. The integrated wireless packet-switched network as set forth in claim 1, further comprising: a Multipoint Control Unit (MCU) for facilitating a multi-party service involving the mobile subscriber; and a flash proxy agent disposed between the MCU and the gateway for mapping proprietary flash messages relating to the multi-party service into messages compatible with the MCU.

8. A method of registering a mobile terminal in an integrated wireless packet-switched network which includes a cellular network portion and a packet- switched network portion, the cellular network portion including a serving radio network controller (RNC), and the packet-switched network portion including a gatekeeper and a gateway, wherein the gateway includes an Internet Protocol (IP) stack for switching cellular traffic related to the mobile terminal, the method comprising the steps of: determining, in the serving RNC, that the mobile terminal is located in a service area associated with the serving RNC; responsive to the determining step, sending an Invoke message from the serving RNC to the gateway, wherein a Registration Update signal is encapsulated in the Invoke message; upon receiving the Invoke message, sending a Registration Request message from the gateway to the gatekeeper, the Registration Request message including a terminalAlias parameter; responsive thereto, sending a Registration Confirm message from the gatekeeper to the gateway if the mobile terminal is successfully registered at the gatekeeper; sending a Registration Reject message from the gatekeeper to the gateway if the mobile terminal is not successfully registered at the gatekeeper; and responsive to receiving one of the Registration Confirm and Registration Reject messages, reporting by the gateway, a registration status of the mobile terminal to the RNC.

9. The method of registering a mobile terminal as set forth in claim 8, further comprising the steps of determining, in the gatekeeper, if the mobile terminal has previously registered with the gateway and if so, returning an Admission Confirm message from the gatekeeper to the gateway.

10. The method of registering a mobile terminal as set forth in claim 8, wherein the Return Result message sent from the gateway to the RNC includes a Registration Update Result signal encapsulated therein.

11. A method of de-registering a mobile terminal in an integrated wireless packet-switched network which includes a cellular network portion and a packet- switched network portion, the cellular network portion including a serving radio network controller (RNC), and the packet-switched network portion including a gatekeeper and a gateway, wherein the gateway includes an Internet Protocol (IP) stack for switching cellular traffic related to the mobile terminal, the method comprising the steps of: determining, in the serving RNC, that the mobile terminal located in a service area associated with the serving RNC has powered down; responsive to the determining step, sending an Invoke message from the serving RNC to the gateway, wherein a Registration Update signal is encapsulated in the Invoke message; upon receiving the Invoke message, sending an Unregistration Request message from the gateway to the gatekeeper, the Unregistration Request message including an endpointAlias parameter; responsive thereto, sending an Unregistration Confirm message from the gatekeeper to the gateway if the mobile terminal is successfully unregistered at the gatekeeper; sending an Unregistration Reject message from the gatekeeper to the gateway if the mobile terminal is not successfully unregistered at the gatekeeper; and responsive to receiving one of the Unregistration Confirm and Unregistration Reject messages, reporting by the gateway, a registration status of the mobile terminal to the RNC.

12. The method of de-registering a mobile terminal as set forth in claim 11 , wherein the Return Result message sent from the gateway to the RNC includes a Registration Update Result signal encapsulated therein.

13. An integrated wireless packet-switched network having a wireless portion and an Internet Protocol (IP) portion, wherein the IP portion includes a gateway, the network comprising: a radio network controller providing radio access services to a mobile subscriber; means within the gateway for switching communication traffic relating to the mobile subscriber; and a protocol translator disposed between the gateway and the radio network controller.

14. The integrated wireless packet-switched network as set forth in claim 13, further comprising: a Multipoint Control Unit (MCU) for facilitating a multi-party service involving the mobile subscriber; and a flash proxy agent disposed between the MCU and the gateway for mapping ANSI-53 messages relating to the multi-party service into messages compatible with the MCU.

15. The integrated wireless packet-switched network as set forth in claim 13, further comprising: a Multipoint Control Unit (MCU) for facilitating a multi-party service involving the mobile subscriber; and a flash proxy agent disposed between the MCU and the gateway for mapping proprietary flash messages relating to the multi-party service into messages compatible with the MCU.

16. An integrated Voice over IP (VoIP) network having at least one IP terminal, comprising: a radio network controller providing radio access services to one or more mobile subscribers; a gateway operably coupled to the radio network controller for combining a packet-switched portion and a circuit-switched cellular portion; a Multipoint Control Unit (MCU) for facilitating a ulti -party service involving at least one mobile subscriber; and a flash proxy agent disposed between the MCU and the gateway for mapping flash messages relating to the multi-party service into messages compatible with the MCU.

17. The integrated VoIP network as set forth in claim 16, wherein the packet-switched portion operates based on Internet Protocol (IP), and the VoIP network further comprises a first protocol translator for converting Transaction

Capability Application Part (TCAP) messaging into IP messaging and a second protocol translator for converting Integrated Services Digital Network (ISDN) User Part (ISUP) messaging into Primary Rate Interface (PRI) messaging, the translators being disposed between the gateway and the radio network controller.

18. The integrated VoIP network as set forth in claim 16, wherein the gateway includes means for switching the communication traffic relating to at least one mobile subscriber.

19. The integrated VoIP network as set forth in claim 16, wherein the flash proxy agent is co-located with the MCU.

20. The integrated VoIP network as set forth in claim 16 , wherein the flash proxy agent is co-located with the gateway.

21. A method for providing a multi -party conference involving a mobile subscriber, a first Internet Protocol (IP) terminal, and a second IP terminal in an integrated wireless packet-switched network having a gateway and a Multipoint Control Unit (MCU), wherein a flash proxy agent is disposed between the gateway and the MCU for mapping ANSI-53 or proprietary flash messages into messages compatible with the MCU, the method comprising the steps of: creating, by the first IP terminal, a first conference connection with the mobile subscriber by dialing a first conference password, a first separator and the mobile subscriber's telephone number; inviting, by the MCU, the mobile subscriber to the first conference connection; creating, by the mobile subscriber, a second call connection with the second IP terminal by dialing a second conference password, a second separator and the second IP terminal's telephone number; inviting, by the MCU, the second IP terminal to the second conference connection; thereafter, releasing the second conference connection between the second IP terminal and the gateway; and toggling between the first and second conference connections by the mobile subscriber until a three-party state is achieved.

22. A method for providing a multi-party conference involving a mobile subscriber, a first Internet Protocol (IP) terminal, and a second IP terminal in an integrated wireless packet-switched network having a gateway and a Multipoint Control Unit (MCU), wherein a flash proxy agent is disposed between the gateway and the MCU for mapping ANSI-53 or proprietary flash messages into messages compatible with the MCU, the method comprising the steps of: creating, by the mobile subscriber, a first conference connection with the first IP terminal by dialing a first conference password, a first separator and the first IP terminal's telephone number; inviting, by the MCU, the first IP terminal to the first conference connection; creating, by the mobile subscriber, a second call connection with the second IP terminal by dialing a second conference password, a second separator and the second IP terminal's telephone number; inviting, by the MCU, the second IP terminal to the second conference connection; thereafter, releasing the second conference connection between the second IP terminal and the gateway; and toggling between the first and second conference connections by the mobile subscriber until a three-party state is achieved.

23. A method for providing a multi-party conference involving a first mobile subscriber, a second mobile subscriber, and an Internet Protocol (IP) terminal in an integrated wireless packet-switched network having a gateway and a Multipoint Control Unit (MCU), wherein a flash proxy agent is disposed between the gateway and the MCU for mapping ANSI-53 or proprietary flash messages into messages compatible with the MCU, the method comprising the steps of: creating, by the first mobile subscriber, a first conference connection with the second mobile subscriber by dialing a first conference password, a first separator and the second mobile subscriber's telephone number; inviting, by the MCU, the second mobile subscriber to the first conference connection; creating, by the second mobile subscriber, a second call connection with the IP terminal by dialing a second conference password, a second separator and the second IP terminal's telephone number; inviting, by the MCU, the second IP terminal to the second conference connection; thereafter, releasing the second conference connection between the second IP terminal and the gateway; and toggling between the first and second conference connections by the second mobile subscriber until a three-party state is achieved.