WO2002039304A1

WO2002039304A1 - Wireless access gateway system for ip networks

Info

Publication number: WO2002039304A1
Application number: PCT/US2001/049894
Authority: WO
Inventors: Hoon Shin Jong; Yeon Won Chan
Original assignee: Halfdome Systems, Inc.
Priority date: 2000-11-13
Filing date: 2001-11-09
Publication date: 2002-05-16
Also published as: AU2002234088A1

Abstract

A method of communicating a packet of information in a wireless IP network (100) comprising receiving a packet of information in a wireless gateway module (400) and transmitting the packet of information to a base transceiver station (300) using IP protocol, wherein the base transceiver station (300) communicates the packet of information as a signal to a mobile station (200). A wireless IP communication network (100) comprising a wireless gateway module for handling a call, wherein the call includes a packet of information and a base transceiver station (300) in communication with the wireless gateway module (400), wherein the wireless gateway module (400) communicates the call to the base transceiver station (300) via IP protocol.

Description

WIRELESS ACCESS GATEWAY SYSTEM FOR IP NETWORKS

Related Applications

This Patent Application claims priority under 35 U.S.C. 119 (e) of the co-pending U.S. Provisional Patent Application, Serial No. 60/248,207 filed November 13, 2000, and entitled "STAND-ALONE SYSTEM SOFTWARE ARCHITECTURE ON ETHERNET LINK". The Provisional Patent Application, Serial No. 60/248,207 filed November 13, 2000, and entitled "STAND-ALONE SYSTEM SOFTWARE ARCHITECTURE ON ETHERNET LINK" is also hereby incorporated by reference.

Field of the Invention

The present invention relates to a system of wireless telecommunications systems and method thereof, in general, and in particular, a system for and method of concerning communications between components in the system being performed over an IP protocol.

Background of the Invention

Existing routers that are software only implementations of switches and routers are flexible but do not have adequate performance. Particularly when it comes to implementing advanced features such as QoS and CoS. Hard-wired ASIC implementations provide very high performance, but do not provide flexibility in a wireless IP network.

Currently the 3^rd Generation Partnership Project 1 and 2 (3GPP1 and 3GPP2) are developing the next generation CDMA wireless IP architectures. The existing connection and communication between the base transceiver station and the wireless gateway (HWG) is a time division multiplex access (TDMA). Thus the existing connection and communication between the base transceiver station and the wireless gateway does not use IP protocol.

In existing networks, such as CDMA 2000 networks, the wireless IP gateway system components are physically separated into different hardware components. Some of these components include the base transceiver station, the base station controller, the radio network controller and the packet control function module. In addition, each component in the existing wireless IP gateway system uses TDMA to communicate with one another and to communicate with the core IP network. Since the core IP network uses IP protocol to handle and route information packets between the callers or end users, the core IP network does not handle TDMA or ATM protocols. Thus, a substantial amount data must be translated between the components in the wireless IP gateway system and the core IP network so that the call may be routed between the end users. However, such a translation of data between the wireless IP gateway and the core IP network causes delay and inefficiency in handling and routing calls throughout the overall IP system.

Thus, what is needed is a wireless IP gateway system in which the components in the wireless IP gateway communicate with one another using IP protocol, instead of ATM, TDMA or CDMA.

Summary of the Invention

A method of communicating a packet of information in a wireless IP network. The method comprises receiving a packet of information in a wireless gateway module. The method comprises transmitting the packet of information to a base transceiver station using

IP protocol. The base transceiver station communicates the packet of information as a signal to a mobile station.

A wireless IP communication network comprises a wireless gateway module for handling a call, wherein the call includes a packet of information. The network comprises a base transceiver station in communication with the wireless gateway module. The wireless gateway module communicates the call to the base transceiver station via IP protocol.

Other features and advantages of the present invention will become apparent after reviewing the detailed description of the preferred embodiments set forth below.

Brief Description of the Drawings

Figure 1 illustrates a general diagram of the overall network architecture in accordance with the present invention.

Figure 2 illustrates a block diagram of the wireless IP gateway system in accordance with the present invention. Figure 3 illustrates a block diagram of the components in the wireless IP gateway system in accordance with the present invention.

Figure 4 illustrates a general overview diagram of the software structure utilized by the HWG in accordance with the present invention.

Figure 5 illustrates a general overview diagram of the software structure with respect to a signaling module in accordance with the present invention.

Figure 6 illustrates a wireless IP network protocol stack for voice-based calls in accordance with the present invention.

Figure 7 illustrates a wireless IP network protocol stack for data-based calls in accordance with the present invention. Figure 8 illustrates a detailed origination call flow diagram in accordance with the present invention.

Figure 9 illustrates an IP format for a packet of data in accordance with the present invention.

Detailed Description of the Preferred Embodiment

Reference will now be made in detail to the preferred and alternative embodiments of the invention, examples of which are illustrated in the accompanying drawings. While the invention will be described in conjunction with the preferred embodiments, it will be understood that they are not intended to limit the invention to these embodiments. On the contrary, the invention is intended to cover alternatives, modifications and equivalents, which may be included within the spirit and scope of the invention as defined by the appended claims. Furthermore, in the following detailed description of the present invention, numerous specific details are set forth in order to provide a thorough understanding of the present invention. However, it should be noted that the present invention may be practiced without these specific details. In other instances, well known methods, procedures, components, and circuits have not been described in detail as not to unnecessarily obscure aspects of the present invention.

Figure 1 illustrates an overview of the wireless IP Network Architecture Model 100 in accordance with the present invention. The architecture model 100 of the present invention is preferably for code division multiple access (CDMA) air interfaces between the mobile station (MS) 200 and the base transceiver station (BTS) 300. The architecture model 100 of the present invention preferably supports voice and data services. However, it is apparent that the architecture may support other services. The architecture of the present invention shown in Figure 1 preferably services mobile devices or mobile stations (MS) 20 that utilize the current air interface signaling protocols, such as IS-95 and IS-2000. However, the architecture 100 of the present invention may also utilize IP based communication protocols to the mobile stations 200.

The wireless IP network architecture model 100 shown in Figure 1 preferably includes several internet protocol base transceiver stations (BTS) 300, several wireless gateways (HWG) 400, one or more mobility control function (MCF) modules 500, one or more Call Agent modules 600, one or more subscriber databases (SDB) 700 including several feature servers (702, 704). The architecture 100 includes one or more media gateway controllers (MGC) 800 and one or more SS7 signaling gateways (SS7 GW) 900. The architecture 100 also includes a public switched telephone network gateway (PSTN GW) 1000, a PSTN Network 1100, one or more packet gateways (Packet GW) 1200, the Internet

1400, a packet data service node (PDSN) 1300 within a managed IP or "core" network 99. In the architecture 100 each mobile station 200 preferably communicates voice packets with the PSTN network 1100 through the PSTN GW 1000 or SS7 GW 900. In addition, the mobile station 200 is preferably communicates data packets with the Internet 1300 through the Packet GW 1200.

In general, when a call is placed by the MS 200, wherein the call is a voice call, the MS 200 transmits the voice packets to the geographically closest BTS 300 preferably via CDMA protocol. Once the BTS 300 receives the voice packet, the BTS 300 converts the voice packet into the IP protocol. The BTS 300 then routes the voice packet to the HWG 400. The voice packet is then transferred to the core IP network 99, in which the network 99 is able to properly route the voice call from processing the destination address contained within the IP voice packet. In addition, various other signals contained within the voice packet, such as control signals for voice call signaling, are communicated to other modules, such as the MCF 500, the SDB 700, the CA 600 and the MGC 800. The voice packet is then communicated either through the PSTN GW 100 or the SS7 GW 900, whereby the appropriate gateway routes the call to the PSTN network 1100. A substantially similar process occurs when a call is received at the MS 200.

When a call is placed by the MS 200, wherein the call is a data call, the MS 200 transmits the data packets to the geographically closest BTS 300 preferably via CDMA protocol. Once the BTS 300 receives the data packet, the BTS 300 converts the data packet into the IP protocol. The BTS 300 then routes the data packet to the HWG 400. The data packet is then transferred to the PDSN 1300 and the core IP network 99, in which the network 99 is able to properly route the data call from processing the destination address contained within the IP data packet. In addition, various other signals contained within the data packet, such as control messages for data call signaling, are communicated to other modules, such as the MCF 500, the SDB 700, the CA 600 and the MGC 800. The data packet is then communicated from the IP network 99 to the Packet GW 1200, whereby the Packet GW 1200 routes the data to the Internet 1400. A substantially similar process occurs when a call is received at the MS 200. The BTS 300 shown in Figure 1 is a circuit-switched base transceiver station 300 which is adapted to include IP-based application binary interfaces (ABIs) for communicating with the HWG 400. The BTS 300 is a remote radiomultiplexer /demultiplexer that provides physical and link layer functions between the mobile station 200 and the wireless gateway (HWG) 400. Likewise, the BTS 300 may provide physical and link layer functions to other BTS 300 geographically placed in the network 100, whereby the BTS 300 serves as a medium access control (MAC) layer repeater. The BTS 300 transports traffic and control signals in addition to information packets over the network 100, wherein the BTS 300 communicates with the HWG 400 using an IP protocol, instead of conventional asynchronous transfer mode (ATM) or TDMA protocol. After a call is placed to or from the mobile station 200, the BTS 300 is responsible for maintaining a reliable radio link with the mobile station 200. This responsibility requires that the BTS 300 supervise and manage the radio channel as well as initiate and execute handoffs when the mobile station 200 travels from one cell to another. This is termed a soft handoff in accordance with the present invention. The soft handoff process and method is described in detail in co-pending U.S. Patent Application, Ser. No.09/825,254, Atty. Docket. No. HALF-00200, filed April 2, 2001 , entitled "Soft Handoff Method in a Wireless Gateway IP Network System," which is hereby incorporated by reference.

The mobility control function (MCF) module 500, shown in Figure 1, supports a signaling interface, such as IS-634/IP, that is call controlled with a radio network control server (RNCS). The MCF 500 also controls the registration and deregisfration of the mobile station 200 within the system 100. The MCF preferably supports an IS-41/IP interface with the SDB 700, in which the SDB 700 incorporates feature servers, such as a Home Location Register (HLR) 702 and an authentication server (AuC) 704. The SDB 700 preferably includes other database servers for the subscribers using the network, such as SMS, Billing, WAP, and so on (not shown). The protocols used in the network 100 of the present invention may be different according to the particular features of the network's server. The HLR 702 is a master database for mobile subscribers who are communicating through their mobile stations 200. The HLR 702 is also responsible for keeping a master list of all feature servers associated with each subscriber as well as location services of each MS 200. Feature servers provide special services within the network using control traffic and bearer traffic paths. The feature servers preferably communicate control traffic with the Call Agent 600 and also communicate bearer path traffic with the HWG 400. The AuC 704 is a database for containing the security data for each mobile station 200. The AuC 704 generates and provides key data for security algorithms. The AuC 704 also provides procedures for securely transferring security information between the mobile station 200 and the HWG 400. The AuC 704 also preferably stores and administrates subscriber security data as well as generates security sets for each transfer.

The Call Agent 600 shown in Figure 1 manages the allocation of required resources that support supplementary services, such as Call Waiting, Conference Call and Three-way Calling. The Call Agent 600 also monitors call states and subscriber service states. The media gateway controller (MGC) 800 shown in Figure 1 translates signals between the Call Agent 600 and the ISDN User Port (ISUP) (not shown) based on signaling of the PSTN 1100. The MGC 800 preferably communicates with the SS7 gateway 900 over the IP network 99 and communicates with the public switched telephone network media gateway (PSTN GW) 1000 using a media gateway control protocol (MGCP). The MGC 800 preferably communicates with the Call Agent 600 using standard protocols such as session initiation protocol (SIP).

The SS7 Signaling Gateway 900 in Figure 1 works between the IP network 99 and the circuit switched PSTN Network 1100. The SS7 GW 900 supports the protocol conversion functions such as MTP1, 2,3 to M3UA, SCTP, IP and vice versa. The SS7 GW 900 encapsulates the SS7 packets received from the PSTN Network 1100 into the appropriate IP packets and forwards the converted packets to the MGC 800 for further processing. The PSTN GW 1000 shown in Figure 1 provides an interface between the IP network

99 and the circuit switched environment of the PSTN 1100. The PSTN GW 1000 preferably provides vocoding and/or transcoding functions to the bearer traffic. Since the PSTN GW 1000 has an ability to connect to the IP Network 99 and circuit-based PSTN environment 1100, the resources provided by the PSTN GW 1200, including transcoding resources, can be used to support bearer channels that are contained entirely within the IP network 99.

The PSTN GW 1000 supports the signaling and communication with the MGC 800 by using MGCP. Alternatively, the MGC 800 and PSTN GW 1000 are included within one entity. The Packet Gateway (GW) 1200 and PDSN 1300, shown in Figure 1, generally provide the interworkings between components in the IP network 99. The Packet GW 1200 preferably handles the bearer path traffic signals as well as control signals or messages and delivers the bearer path traffic signals between separate packet switched IP networks. The Packet GW 1200 also provides a secure ingress/egress point for entering or leaving the IP network 99 and facilitates the connection to the Internet 1400 or other IP networks. The Packet GW 1200 or PDSN 1300 alternatively serves as a Border Router that supports the firewall functions.

Figure 2 illustrates a block diagram the wireless IP gateway system 102 in accordance with the present invention. The wireless IP network 102 includes one or more BTS 300 and the HWG 400. The mobile station 200 (Figure 1) communicates a signal with the BTS 300 via an air interface, whereby the BTS 300 communicates IP packets with the HWG 400 via IP protocol. The BTS 300 also communicates via IP protocol with other base transceiver stations 300 (Figure 1) located in different geographic regions. The BTS 300 can thereby perform a soft handoff via communicating via IP to a BTS 300 in another cell, when the MS 200 travels from one cell to another. The HWG 400 shown in Figure 2 preferably includes a Base Station Controller (BSC) 402, a Radio Network Control Server (RNCS) 404 and a Packet Control Function (PCF) module or element 406. The HWG 400 shown in Figure 2 also includes a mobility manager (MM) 408 and a PSDN. However, the PDSN 1300 is alternatively configured as a separate component from the HWG 400, as shown in Figure 1.

As shown in Figure 2, the BTS 300 communicates the IP packets to and from the BSC 402, RNCS 404 and PCF 406. The BSC 402, RNCS 404 and PCF 406 communicate the traffic and control signals in the IP packets to the MM 408, whereby the MM 408 and the PDSN 1300 also communicate the control and traffic signals to one another for voice calls. If the call that is being handled by the MS 200 is a voice call, the BSC 402, RNC 404 and PCF 406 communicate the IP packets, including the control and traffic signals as well as the bearer traffic, with the PSTN network 1000. If the call being handled by the MS 200 is a data call the BSC 402, RNCS 404 and PCF 406 communicate the data IP packets with the PDSN 1300, whereby the PDSN 1300 communicate the control and traffic packets in the data IP packets with the SDB 700. In addition, PDSN 1300 communicates the bearer traffic with the corre IP network 99. Each of the above elements 402-414 within the HWG 400 are preferably coupled to one another and are router-based.

The HWG 400 preferably incorporates software elements coupled with the HWG's 400 hardware to allow the HWG 400 to communicate via IP protocol with the BTS 300 and other components in the current and future wireless IP networks. The HWG 400 preferably supports all existing 2G and 3G CDMA mobile stations. However, it is apparent that the HWG 400 will also support IP Multimedia-based mobile stations. The HWG 400 shown in Figure 2 acts as the gateway for interfacing the radio access network (RAN) to the IP network. The HWG 400 preferably has a Frame Selector Function that is used to select a better connection for Soft Handoff supports. The HWG 400 also preferably supports transcoding functions from an Enhanced Variable Rate Coder (ENRC) to a Pulse Code Modulator (PCM) and vice versa. However, the HWG 400 may be configured to support transcoding functions through the PSTN GW. The HWG 400 of the present invention preferably has 10 slots for interfacing with 10 other modules. Of the 10 slots in the HWG 400, 2 slots are preferably coupled to the MCU active/standby. The remaining 8 slots are preferably for subscriber interface units, such as a fast ethernet unit (FEU), a SDU, a Tl/El Interface Unit (T1 E1U), a Giga Ethernet Unit (GEU), and a Packet Over Sonet Unit (POS). The HWG 400 will preferably support various combinations of subscriber interface units. For instance, a T1U module (not shown) may be configured to use 4 slots that support 32 physical ports. The SDU module 414 may be configured to use 3 slots that would support approximately 700 simultaneous voice-based calls. Thus, the HWG 400 may be configured such that 32 Tl physical ports, 8 Fast Ethernet ports, and approximately 700 simultaneous calls for voice traffic in the SDU module 414 will be supported. Therefore, the HWG 400 will support the data traffic and media gateway function such as ENRC to PCM and vice versa, to reduce 700 simultaneous calls through the network.

Figure 3 illustrates a block diagram of the wireless gateway system in accordance with the present invention. Specifically, Figure 3 illustrates how voice or data packets are communicated between the BTS 300 and the HWG 400. Several communication elements are passed between the BTS 300 and HWG 400, such as voice packets, designated as 1, data packets 2, control packets or messages 3 and power signals or messages 4. The voice packets 1 travel that are eventually transmitted to or received from the MS 200 pass through the BTS 300. The BTS 300 communicates the voice packet 1 with the Packet over Sonet (POS) module 416, whereby the POS 416 communicates the voice packet 1 with the Voice Selection and Distribution Unit Manager (NSDUM) 414A. The NSDUM 414A communicates the voice packet 1 with the Giga Ethernet (GE) 420, whereby the GE 420 communicates the voice packet 1 with the IP network 99.

For a data call, a data packet, designated as 2, is communicated from and to the MS 200. The BTS 300 communicates the data packet 2 with the MS 200. The BTS 300 communicates the data packet 2 with the POS 416. The POS 416 communicates the data packet 2 with the Data Selection and Distribution Unit Manager (DSDUM) 414B. The DSDUM 414B communicates the data packet 1 with the GE 420, whereby the GE 420 communicates the data packet 2 with the IP network 99. In addition to the voice packets 1 and data packets 2, the control signals 3 and power signals 4 are passed through the wireless IP network of the present invention. Control signals

3 are used to control and manipulate the voice packet 1 or data packet 2 such that each component in the system 100 can effectively handle and route the packet. The power signal

4 is typically generated by the MS 200 and is used to drive the packet through the system 100.

According to Figure 3, the control signal 3 is passed from and to the MS 200. The BTS 300 passes the control signal 3 to and from the POS 416. The POS 416 passes the control signal 3 to and from the Main Computer Unit (MCU) 418, whereby the MCU 418 passes the control signal 3 to and from the GE 420. The GE 420 thereby passes the control signal 3 to and from the IP network 99. Power signals 4 received from the MS 200 at the BTS 200 is passed from the BTS to the POS 416. The POS 416 communicates the power signal 4 with the NSDUM 414A or the DSDUM 414B, depending on which type of packet is being communicated. Thus, if a voice packet 1 is being communicated, the power signal 4 will be handled by the NDSUM 414A. If a data packet 2 is communicated with the MS 200, the power signal 4 will be handled by the SDSUM 414B. Depending on the type of packet being passed through the system, either the NSDUM 414A or DSDUM 414B will communicate the power signal to the GE 420. The GE 420 also communicates the power signal 4 to the IP network 99. In addition, either the NSDUM 414A or DSDUM 414B will also communicate the power signal 4 to the MCU 418. In addition, the HWG 400 of the present invention has a scalable bandwidth which supports high density and high speed POS. The HWG 400 preferably offers congestion management as well as multicast, Class of Service (CoS), Quality of Service (QoS), Differentiated Services (DiffServ), propriety Queue Algorithm for QoS, such as SP and WRR, and Hybrid Queuing. The HWG 400 will also preferably support selection and distribution units for CDMA as well as perform media gateway functions, such as transcoding and synchronization.

Figure 4 illustrates a general diagram of the HWG's 400 software system in accordance with the present invention. The software system of the HWG 400 includes a Signaling Module 1500, a Firmware Module 1600, an Internet Protocol Module 1700 and a Management Module 1800. The signaling module 1500 in the HWG 400, shown in Figures 4

& 5, preferably includes a mobile call control manager (MCCM) 1502, an A 1 interface manager (IS634M) 1504, a media gateway control protocol manager (MGCPM) 1506, a session initiation protocol manager (SIP) 1508, a PCF element 1510 and a SDU/Vocoder 1512. The management module 1800 of the HWG 400 shown in Figures 4 and 5 preferably includes a command line interface (CLI) 1802. The management module 1800 also includes a configuration manager (CM) 1804 (Figure 5) which provides control over the system components and protocol layer entities as well as collects and disseminates data related to the current state of resources in the HWG 400. The HWG 400 also includes a performance manager (PM) 1806 (Figure 5) which provides the ability to monitor and evaluate the performance of the system components and protocol layers as well as summarizes the collected performance data. The HWG 400 also includes a fault manager (FM) 1810 (Figure 5) which detects and reports faults in the system components and protocol layer entities. A SΝMP manager 1812 and a SΝMP agent 1814 are also included in the management module 1800 of the HWG 400. In addition, the management module 1800 includes an operation, administration and maintenance function module (OAM &P) 1816. The signal network management protocol (SΝMP) manager 1812 sub-module is shown located within the management module 1800 in Figure 4. However, the SΝMP manager 1812 may be located outside the management module, as shown in Figure 4. The internet protocol module 1700 of the HWG 400, as shown in Figure 4, preferably includes a TCP/IP interface 1702 for handling layers 4-7, one or more routing information protocols (RIP) 1704 and 1706, an open shortest path first protocol (OSPF) (not shown) ans well as other various IP Applications (not shown). The firmware module 1600 of the HWG 400 serves as the CPU interface and preferably includes several Device Drivers (DD) 1604 as

5 well as operating system (OS) software 1602.

Figure 5 illustrates the software structure of the signaling module 1500 in accordance with the present invention. When a call is connected between the MS 200 and either the PSTN Network 1100 or the Internet 1400, the IP packets are transferred from either the VSDUM 414A or the DSDUM 414B to the Tl Unit Manager (T1UM) 422. The T1UM 422

_0 then routes the IP packet to the Channel Manager (CHM) 426, whereby the CHM 426 routes the IP packet to the MCCM 1502 of the signaling module 1500. The MCCM communicates the messages within the IP packet to the IS634M 1504 and the MGCPM 1506, whereby the IS634M 1504 and the MGCPM 1506 communicate with the MCF 500 and CA 600. Within the HWG 400 is an Inter-Processor Communication (IPC) 424 which handles OS message

_5 and queue services and allows all the other software elements to communicate control messages with one another. The IPC 424 allows the HWG 400 to communicate with other CPUs since each CPU has a unique IP address for routing between modules. Each communication that is made between the software components shown in Figure 5 is sent to the IPC.

JO The Internet protocol (IP) which the wireless IP gateway of the present invention uses to communicate with each other is shown in Figure 9. The IP protocol is a network layer in Layer 3 that contains addressing information and control information that enables packets of information to be routed between the BTS 300 and the HWG 400. The IP layer in the present invention provides connectionless delivery of datagrams between the BTS 300 and HWG 400

J5 as well as provides fragmentation and reassembly of datagrams to support data links which have different maximum-transmission unit (MTU) sizes. The IP layer is responsible for moving the packets of data from the BTS 300 to the HWG 400, whereby the IP layer forwards each packet based on a four-byte destination address.

Figure 9 illustrates an IP format for a packet of data in accordance with the present

\0 invention. As shown in Figure 9, the Version indicates the version of IP that is currently being used. The IP Header Length (IHL) indicates the datagram header length in 32-bit words. The Type of Service specifies how an upper layer protocol would like the current datagram to be handled and assigns datagrams based on various levels of importance. The Total Length field specifies the length, in bytes, of the entire IP packet including the data and

55 header. The Identification heading contains data that identifies the current datagram and is used to piece together datagram fragments. The Flags field is a 3 bit field, wherein two least significant or low-order bits control fragmentation. The low- order bit specifies whether the packet can be fragmented. The middle bit specifies whether the packet is the last fragment in a series of fragmented packets. The Fragment Offset field indicates the position of the fragment's data relative to the beginning of the data in the original datagram, which allows the destination IP process to properly reconstruct the original datagram. The Time to Live field maintains a counter that gradually decrements down to zero. When the Time to Live field reaches zero, the datagram is discarded, which prevents the packets from looping. The Protocol field indicates which upper-layer protocol receives the incoming packets after processing of the packet is complete. The Header Checksum field aids in ensure IP header integrity. The Source Address field and the Destination Address field specifies the address of the sending and receiving node, respectively. The Options field allows the nodes to support various options, for example security options. The Data field includes the upper-layer information which is transmitted in the packet.

Calls which are communicated through the architecture 100 of the present invention may include packets of information or protocol stacks that are in different forms. There are roughly two kinds of protocol stacks in the Wireless IP Network of the present invention. One protocol stack is for voice calls and circuit data calls, such as G3 FAX. The other protocol stack is for packet data calls, which is related to data sent over the Internet. Figure 6 illustrates the wireless IP network protocol stack for voice calls in accordance with the present invention. Figure 6 illustrates five different protocol stacks: an MS stack 2000, a BTS stack 2100, a HWG stack 2200, a MCF+CA stack 2300 and a PSTN GW stack 2400. The MS stack 2000 includes a supplementary service block 2202. The MS stack

2000 also includes a MM/CC/Voice block 2004, which is a voice call mobility manager. The MS stack 2000 includes an IP based on Layer 3 protocol (L3) 2006 as well as an airlink physical interface, which is designated as Layer 1 (LI) 2010. The MS stack 2000 also includes a Link Access Control (LAC) and Media Access Control (MAC) block based on Layer 2 protocol 2008.

The BTS IP protocol stack 2100 includes a relay block 2102 which is a voice control function. The BTS stack 2100 also includes a LAC/MAC block 2104 as well as a TCP/UDP session protocol block 2106 based on Layer 3 protocol. The BTS stack 2100 includes an IP block 2108 which is internet protocol based on Layer 3 protocol. The Layer 2 block (L2) 2110 in the BTS stack 2100 is the 802.3 Layer 2 protocol. The Layer 1 (LI) 2112 is the ethernet physical interface whereas the LI 2114 is the airlink physical interface.

The HWG IP protocol stack 2200 includes a MM/CC voice call mobility manager block 2202. The HWG stack 2200 also includes a Relay/IOS/RTP block 2204 which serves as the real time voice control function. The LAC/MAC block 2206 is also included in the HWG stack 2200 as well as the IP block 2210 and L2 block 2212. The LI block in the HWG stack 2200 is an ethernet physical interface.

The MCF+CA stack 2300 includes a supplementary services block 2302, a MM/CC block 2304, an IOS/MGCP block 2306. The MCF+CA stack 2300 also includes a TCP/UDP 2308 block, an IP block 2310, a L2 block 2312 and a LI block 2314. The PSTN GW stack 2400 shown in Figure 6 includes a relay block 2400 and a MGCP/RTP block 2404. The PSTN stack 2400 also includes a PSTN signaling and voice block 2406 which serves as the interface between the voice and signaling functions. The PSTN stack 2400 includes an IP block, 2410, a L2 block 2412 and a LI block 2414.

The details of a call being placed will now be discussed in view of the IP protocol stacks shown in Figure 6. In the instance when the MS 2000 places a call to a PSTN subscriber, the MS 2000 sends signaling data to the BTS 2100. This process begins at the supplementary services block 2002 through the MM/CC/Voice block 2004 and proceeds down to the airlink physical interface, LI 2010. Once the BTS 2100 receives the signaling packet, the BTS 2100 encapsulates the signaling data into an IP packet having a specific UDP port number and relays the signaling packet to the MCCM 1502 (Figure 4) of the HWG

400. The MCCM 1502 (Figure 4) instructs the MCF+CA 2300 via IS-634 and MGCP 1506 (Figure 4) that a call is requested from the BTS 2100. Once the MCF+CA 2300 approves the request, the MCCM 1502 (Figure 4) accepts the call that is requested from the BTS 2100 and sends the signaling packet to the BTS 2100 using IP packets including the UDP port number that was already supplied by the BTS 2100. The BTS 2100 sends this acceptance signal to the MS 2000, whereby the MS 2000 then sends the voice packet or bearer data to the BTS 2100. The BTS 2100 encapsulates the bearer data into IP packets which include the specific UDP port number already assigned and sends the encapsulated bearer IP packet to the LAC/MAC block 2206 of the HWG 2200. The LAC/MAC 2206 receives the IP voice packet and forwards the IP voice packet to the RTP 2204 block of the HWG 2200, whereby the RTP block 2204 sends the IP voice packet to the PSTN GW 2400.

In the instance when the MS 2000 places a call to another MS 2000' (not shown), the MS 2000 sends signaling data to the BTS 2100. This process begins at the supplementary services block 2002 through the MM/CC/Voice block 2002 and proceeds to layer 1 (LI) 2010. Once the BTS 2100 receives the signaling packet, the BTS 2100 encapsulates the signaling data into an IP packet having a specific UDP port number and relays the signaling packet to the MCCM 1502 (Figure 4) of the HWG 400. The MCCM 1502 (Figure 4) instructs the MCF+CA 2300 via IS-634 and MGCP 1506 (Figure 4) that a call is requested from the BTS 2100. Once the MCF+CA 2300 approves the request, the MCCM 1502 (Figure 4) accepts the call that is requested from the BTS 2100 and sends the signaling packet to the BTS 2100 using IP packets including the UDP port number that was already supplied by the BTS 2100. The BTS 2100 sends this acceptance signal to the MS 2000, whereby the MS 2000 then sends the voice packet or bearer data to the BTS 2100. The BTS 2100 encapsulates the bearer data into IP packets which include the specific UDP port number already assigned and sends the encapsulated bearer IP packet to the LAC/MAC block 2206 of the HWG 2200. The LAC/MAC 2206 receives the IP voice packet and forwards the IP voice packet to the LAC/MAC 2206' (not shown) of the HWG 2200' (not shown) of the receiving MS 2000' (not shown). The RTP 2204' (not shown) block of the receiving HWG 2200' (not shown) send the IP voice packet to the BTS 2100' (not shown) closest to the receiving MS 2000' (not shown). The BTS 2100' (not shown) receiving the IP voice packet from the HWG 2200' (not shown) then de-encapsulates the IP voice packet such that the receiving MS 2000' can receive the voice signal via air interface.

Figure 7 illustrates the wireless IP network protocol stack for data calls in accordance with the present invention. Figure 7 illustrates five different protocol stacks: an MS stack 2500, a BTS stack 2600, a HWG stack 2700, a MCF+CA stack 2800 and a PDSN stack 2900.

The MS stack 2500 includes a mobile IP (MIP) block 2502. The MS stack 2500 also includes a TCP/UDP 2504, which works in a Layer 4 protocol. The MS stack 2500 includes an IP based on Layer 3 protocol (IP) 2506 as well as a Point to Point Protocol based on Layer 2 (PPP) 2508. The MS stack 2500 also includes Link Access Control (LAC) and Media

Access Control (MAC) block 2510 based on Layer 2 protocol as well as an airlink physical interface, which is designated as Layer 1 (LI) 2512.

The BTS IP protocol stack 2600 includes a relay block 2602 which is a voice control function. The BTS stack 2600 also includes a LAC/MAC block 2604 as well as a TCP/UDP session protocol block 2606 based on Layer 3 protocol. The BTS stack 2600 includes an IP block 2608 which is internet protocol based on Layer 3 protocol. The Layer 2 block (L2) 2610 in the BTS stack 2600 is the 802.3 Layer 2 protocol. The Layer 1 (LI) 2612 is the ethernet physical interface whereas the LI 2614 is the airlink physical interface.

The HWG IP protocol stack 2700 includes a MM/CC voice call mobility manager block 2702. The HWG stack 2200 also includes a GRE with PDUM session control function block 2704. The LAC/MAC block 2706 is also included in the HWG stack 2700 as well as the TCP/UDP block 2708, IP block 2710 and L2 block 2712. The LI block 2714 in the HWG stack 2700 is an ethernet physical interface. The MCF+CA stack 2800 includes a MM/CC block 2802, a TCP/UDP 2804 block, an IP block 2806, a L2 block 2308 and a LI block 2310. The PDSN stack 2900 shown in Figure 7 includes a MIP block 2902 and a

TCP/UDP block 2904. The PDSN stack 2900 also includes An IP/NAT block 2906, which is an Internet protocol with network address translation function in layer 3. The PDSN stack 2900 also has a PPP block 2908, a PDUM session control function block 2910 and TCP/UDP block 2912. In addition, the PDSN stack 2900 includes a L2 lock 2914 and a LI block 2416. In the instance that the MS 2500 places a call for accessing the Internet, the MS 2500 calls a specific phone number. The BTS 2600 receives a signaling packet from the MS 2500 indicating that a data call has been placed. The BTS 2600 encapsulates the signaling data into IP packets including a specific UDP port number. The BTS 2600 then sends the encapsulated IP packet to the MCCM 1502 (Figure 4) of the HWG 2700. The MCCM 1502 (Figure 4) instructs the MCF 2800 that a call is requested from the BTS 300. Once the

MCCM 1502 (Figure 4) accepts the call, it sends the signaling packet back to the BTS 2600 using the IP packet having the UDP port number that was originally sent by the BTS 2600. The BTS 2600 sends the acceptance signal to the MS 2500 and the MS 2500 sends a negotiation packet of PPP 2508, wherein the PPP 2508 block includes authentication information for requesting a private IP address, to the BTS 2600. The BTS 2600 receives this information and sends the negotiation packet to the LAC/MAC 2706 of the HWG 2700, wherein the IP packets include the specific UDP port number. The LAC/MAC 2706 receives the IP packets and sends the negotiation packet to the PPP block 2908 according to session control key that is managed by the PDUM 2704 in the HWG 2700. The HWG 2700 sends the authentication information coming from the MS 2500 to the PDUM 2704, wherein the

PDUM 2704 sends the authentication information to the AAA server (not shown). Once the PDUM 2704 receives an acceptance signal from the AAA server, it will accept the call requested from the MS 2500. The PPP 2508 then sends a negotiation packet including the private IP address to the BTS 2600 having the IP packet and specific UDP port number. The BTS 2600 then sends the negotiation packets including the private IP address to the MS

2500. The MS 2500 sends a data packet that is encapsulated by its own PPP 2508 to the BTS 2600 using the private IP address. Once received, the data packet, with the specific UDP port number, is sent from the BTS 2600 to the LAC/MAC block 2706 of the HWG 2700. The LAC/MAC 2706 of the HWG 2700 forwards the data packet to the HWG 2700. The HWG 2700 then sends the data packet to the upper IP stack after de-encapsulating the PPP header from the data packet of the HWG 2700. The upper IP stack then translates the private IP address to a public IP address and sends the data packet to the Internet 1400 using the NAT 2906.

In a simple IP application, the MS 200 needs only the private IP address. For a mobile IP application, the MS needs the mobile IP address in addition to the private IP address for security reasons. Alternatively, the MS 200 requests the mobile IP address from the mobile IP block in the HWG 400.

As stated above, the BTS 300 communicates with the HWG 400 via an ABI interface. The packet control function manager (PCF) (Figures 4 and 5) within the signaling module 1500 of the HWG 400 executes commands and messages to the all components. The MS initiates packet data call by sending an Origination Message to the BTS. Normal voice service authentication procedures are followed for the subscriber, and a traffic channel is established between the MS and BTS. After packet data service options are connected, RLP synchronization is executed between the MS and the DSDUM of HWG. Calls that are transmitted over IP are subject to delays when passed through the system of the present invention. Since data packets are usually in the form of text, a delay in time between the transmission and receipt of the data packet is a small inconvenience. However, a delay in time for a voice packet to reach the intended recipient is a substantial problem, since voice conversation between persons would be hindered. Therefore, the system of the present invention preferably utilizes a screening method in which the system determines whether the packet being transmitted is a data or voice. Specifically, the system determines which calls being transmitted through the system are voice or data. Once the system determines this, it assigns a priority to the voice calls over the data calls. The voice calls are then first routed to the appropriate MS 200, whereas the calls having data packets are routed thereafter.

Preferably, the HWG 400 of the present invention determines whether the packet is data or voice. However, it is apparent that other components in the system can perform this task. Specifically, a call that is placed by a MS 200 is communicated to the appropriate BTS 300. In the preferred embodiment, the BTS 300 does not have the capability to determine whether the call contains a voice packet or a data packet. Thus, the BTS 300 routes the call, via IP to the HWG 400, which determines whether the call contains voice or data packets. Once the HWG 400 determines the type of call, it assigns a higher priority to the call if the call is voice. Otherwise, the HWG 400 assigns a lower priority to the call if the call is data. Following, the HWG 400 routes the call, with the priority assigned to it, back to the appropriate BTS 300. The BTS 300, upon receiving the call from the HWG 400, will then be able to sort which MS 200 will have their call routed first.

In the event that a call that is to be received by the MS 200, the call is preferably first routed to the HWG 400. The HWG 400 determines whether the call contains voice or data packets. Once the HWG 400 determines the type of call, it assigns a higher priority to the call if the call is voice. Otherwise, the HWG 400 assigns a lower priority to the call if the call is data. Following, the HWG 400 routes the call, with the priority assigned to it, to the appropriate BTS 300. The BTS 300, upon receiving the call from the HWG 400, will then be able to sort which MS 200 will be allowed to handle their call first. As stated above, it is preferred that the HWG 400 determines and assigns the priority based on whether the packet is data or voice. However, it is apparent that any of the other components in the system may perform this task, including the BTS 300.

Now, the details of the call flow process, as shown in Figure 8, will be discussed. When the user inputs a telephone number into the MS and enters 'Send', the MS requests service from the network by transmitting an Origination Message over an air interface to the

BTS 300, as shown in Figure 8. The Channel Element Manager (CEM) of the BTS 300 processes the Origination Message and sends an OrgMsg_B message to the BCM of the BTS 300. Once the BCM receives this message, the BCM sends an Originaation_B2C message using UDP/IP stacks to the MCCM of the HWG 400. The IS634M of the HWG 400 then sends a configuration management (CM) service request message to the MCF module of the

HWG 400. The MCF checks the location and validation of the user and mobile station and then sends back an Assign Request message to the RNCS or MCCM. If the validation is successfully completed from the Assign Request message, the MCCM sends an Assign_Req_C2B message to the BCM in the BTS 300. Once the BCM receives the AssignReqC2B message from the MCCM, the BCM allocates a traffic channel, a code channel and frame offset for the traffic channel allocation.

The CEM sends null data as Teh NULL through a traffic channel to the mobile station. At this point, a traffic channel has been assigned and allocated to the MS. After, the BCM sends a TC_Assign_B2C message to the MCCM to inform the HWG 400 that the traffic channel has been allocated. The BCM also sends a PCAssign_B message to the CEM. The CEM thereby sends a Channel Assignment Message over the radio interface (with the mobile station's 200 address) to initiate the establishment of a radio traffic channel, if there is not already one on a traffic channel. Meanwhile, upon receiving a TCAssign_B2C message from the BCM, the MCCM sets a link activation between the HWG 400 and the BTS 300 by sending a SDUSetup_S message to the SDU of the HWG. Upon setting the link activation, the SDU of the HWG 400 is thereby able to send and receive LINK_ACT messages with the CEM.

After completing synchronization with the MS 200, the CEM sends a MobAckCtrl_B2C message to the SDU. Once the SDU receives the MobAckCtrl_B2C signal, the SDU sends a BS Ack Order message to the mobile station over the forward traffic channel. Once the MS acknowledges the reception of the BS Ack Order message, it transmits a MS Ack Order message back to the SDU and sends null traffic channel data (Null TCH Data) over the reverse traffic channel (not shown). The SDU then sends a Service Connect Message to the mobile station, which specifies the service configuration for the call. The mobile station thereby begins transmitting and receiving call traffic in accordance with the specified service configuration. On receipt of the Service Connect Message from the SDU, the MS responds with sending a Service Connect Completion Message to the SDU to confirm receipt of the message. The SDU then sends an AssignCom_S message to the MCCM of the HWG 400, and the IS634M sends an Assignment Complete message to the MCF to setup a termination side of the call. When the IS634M receives an Alerting message that indicates the telephone is ringing, the IS634M sends an Alert_S message to the SDU. When the called party has answered the call, the 1S634M receives a Connect message from the MCF. The IS634M then sends a Connect Ack message that acknowledges connection of the message. The IS634M then sends a Connet_S message to the SDU to stop the ringing of the calling party.

The present invention has been described in terms of specific embodiments incorporating details to facilitate the understanding of the principles of construction and operation of the invention. Such reference herein to specific embodiments and details thereof is not intended to limit the scope of the claims appended hereto. It will be apparent to those skilled in the art that modification s may be made in the embodiment chosen for illustration without departing from the spirit and scope of the invention.

Claims

What is claimed is: 1. A method of communicating a packet of information in a wireless IP network comprising: a. receiving a packet of information in a wireless gateway module; and b. transmitting the packet of information to a base transceiver station using IP protocol, wherein the base transceiver station communicates the packet of information as a signal to a mobile station.

2. A wireless IP communication network comprising: a. a wireless gateway module for handling a call, wherein the call includes a packet of information; and b. a base transceiver station in communication with the wireless gateway module, wherein the wireless gateway module communicates the call to the base transceiver station via IP protocol.