System and method of group calling in mobile communications

SYSTEM AND METHOD OF GROUP CALLING IN MOBILE COMMUNICATIONS

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to mobile communications, and more particularly, to a system and method for group calling in mobile communications.

All modern mobile communication systems have a hierarchical organization in which a geographic "coverage area" is divided into a number of smaller geographic areas referred to as "cells". Referring to Figure 1, each cell is preferably served by a BTS (Base Transceiver Station) 102a. Several BTSs 102a-n are aggregated to a Base Station Controller (BSC) 106a via fixed links 104a-n. Sometimes, the BTSs and the BSC are collectively referred to as a Base Station Subsystem (BS) 107 . Several BSCs 106a-n may converge to a Mobile Switching Center (MSC) 110 via fixed links 108a-n.

MSC 110 acts as a local switching exchange (with additional functions for handling mobility management requirements, described below), and via a trunk group a telephone network ("PSTN") ) to communicate with Under the US mobile network, there is a concept of a home MSC and a serving MSC. The home MSC is an MSC corresponding to an exchange associated with a mobile station (MS), and this association is based on a phone number of the MS, for example, an area code. (The home MSC is responsible for the HLR, discussed below.) On the other hand, the serving MSC is the switch used to connect the MS call to the PSTN (if the subscriber roams within the area covered by the service provider, other MSCs perform the functions of the serving MSC). Thus, in some cases the home MSC and the serving MSC are the same entity, but in other cases they are not (eg, when the MS roams). Typically, a Visiting Location Register (VLR) 116 is co-located with the MSC 110, and a logically singular HLR is used in a mobile network. As described below, HLRs and VLRs are used to store many types of subscriber information and profiles.

Briefly, one or more radio channels 112 are associated with the entire coverage area. The radio channels are divided into groups of channels assigned to individual cells. Channels are used to transmit signaling information to establish a paging connection, etc., so as to transmit voice or data information once a paging connection is established.

At a relatively high level of abstraction, mobile network signaling involves at least two main aspects. One aspect includes a signaling scheme between the MS and the remainder of the network. According to 2G ("2G" is an industry term used for "second generation") and later technologies, this signaling scheme is the access method used by the MS (e.g., time division multiple access ( time-division multiple access (TDMA), code-division multiple access (CDMA), radio channel allocation, authentication, and the like. A second aspect includes signaling schemes between various entities in a mobile network, eg, signaling schemes between MSCs, VLRs, HLRs, and the like. This second part is sometimes specifically called the signal scheme No. When used in the context of 7 ("SS7"), it is referred to as a MAP (Mobile Application Part).

Various types of signaling methods (as well as data and voice communications) are transmitted and received according to various standards. For example, the Electronics Industries Association (EIA) and the Telecommunications Industry Association (TIA) help define a number of US standards, such as the MAP standard IS-41. Similarly, CCITT and ITU help define international standards such as GSM-MAP, which is an international MAP standard. Information on these standards is well known and is available from the literature as well as from relevant organizations, see, for example, Bosse, SIGNALING IN TELECOMMUNICATIONS NETWORKS (Wiley 1998).

To send a call from MS 114, the user dials the number to the cellular phone or other MS and presses "send". MS 114 transmits to MSC 110 via BS 107 the dialed number indicating the service requested. The MSC 110 checks with the associated VLR 116 (below) to determine whether it is possible for the MS 114 to receive the requested service. The serving MSC routes the call to the dialed user's local exchange on the PSTN 120 . The local exchange alerts the called user terminal, and an answer back signal is routed to the MS 114 via the serving MSC 110, which then completes the voice path to the MS. Once the setup is complete, the call can proceed.

To transfer a call to MS 114 (assuming the call originates from PSTN 120), the PSTN user dials the MS's associated phone number. At least according to US standards, the PSTN 120 routes the call to the MS's home MSC (which may or may not be serving the MS). The MSC then queries the HLR 118 to determine which MSC is currently servicing the MS. This query also serves to inform the serving MSC that a call is imminent. The home MSC then routes the call to the serving MSC. The serving MSC performs paging to the MSC through the appropriate BS. The MS responds and an appropriate signaling link is established.

During a call, BS 107 and MS 114 may cooperate to change channels or BTS 102 if necessary due to, for example, signal conditions. These changes are known as "handoffs," and these changes involve known messaging and signaling schemes of their own type.

One aspect of MAP includes "mobility management". Briefly, because MS 114 roams to different locations, other BSs and MSCs are needed and may be used to service the MS. Mobility management allows the serving MSC to obtain the subscriber profile and other information that the MSC needs to reliably service (and charge) the calls correctly. To do this, MSCs use a Visiting Location Register (VLR) 116 and a Home Location Register (HLR) 118 . HLR is used to store and retrieve, among other things, mobile identification number (MIN), electronic serial number (ESN), MS status and MS service profile. The VLR stores similar information in addition to storing the MSC identification that identifies the (home) MSC. Also, under the appropriate MAP protocol, location update procedures (or registration notifications) are performed so that the mobile subscriber's home MSC knows the location of its users. These procedures are used when the MS roams from one location to another, or when the MS powers on and registers itself to access the network. For example, the location update procedure may proceed by MS 114 sending a location update request to VLR 116 via BS 107 and MSC 110 . VLR 116 sends a location update message to HLR 118 serving MS 114 , and the subscriber profile is downloaded from HLR 118 to VLR 116 . An acknowledgment of successful location update is sent to MS 114 . The HLR 118 requests the profile data it previously held on the VLR (if any) to delete data related to the relocated MS 114.

2 shows in more detail the signaling scheme and user traffic interfaces between BS 107 and MSC 110 in a CDMA mobile network. BS 107 communicates signal information using the A1 interface. The A2 interface carries user traffic (eg, voice signals) between the switch component 204 of the MSC and the BS 107 . The A5 interface is used to provide a path for user traffic for circuit switched data calls (as opposed to voice calls) between the source BS and MSC.

In addition, subscribers are demanding newer services such as, for example, "data calls" to the Internet. For some of these services, MSCs are not cost effective because they are primarily designed for voice calls. The integration of new services into MSC is complex or impractical because many MSC software architectures use proprietary and closed designs. That is, it is not easy to add software logic necessary for providing a service to the MSC 110 . Often, a switch adjunct is used to provide this service. For example, an Inter-Working Function (IWF) is an adjunct for routing data calls to the Internet. Either way of integrating functions within the MSC or adding trunk-side adjuncts involves the MSC in the transmission of services. Because new services are expected to spur demand, integrating new services through MSC design changes or trunk-side adjuncts is likely to exacerbate network congestion at the MSC and require expensive MSC resources.

In the context of the Internet, multicast communication refers to the transmission of identical data packets to a plurality of selected destinations on an Internet Protocol network. (In contrast, broadcast communication means indiscriminately sending data packets to all destinations, and unicast communication means sending data packets to a single destination.)

Each participant in the multicast receives information transmitted by any other participant in the multicast. Users connected to the network, other than participants in a particular multicast, do not receive information transmitted by participants in the multicast. In this way, multicast communication uses only those network components (eg, switches and trunks) that are actually necessary for multicast transmission.

In multicast processing, when a potential participant ("host") is designated to join a particular IP multicast group, the host sends a "request to join" message to the nearest multicast-capable router to that multicast group. Requests participation in a cast group and receives information sent to this group. For example, host A sends a message to join multicast group Y, and host B sends a message to join multicast group X. Router R propagates the request to the multicast source if the data path has not yet been established.

For example, upon receiving an IP packet for group X, router R maps the IP multicast group address to an Ethernet multicast address, and sends the resulting Ethernet packet to the appropriate switch or switches.

According to the current Internet Group Management Protocol (IGMP), a host's membership in a multicast group expires when the router does not receive a periodic membership report from the host.

Regarding the interaction between MSs, the Nextel service with two versions (known as Nextel Direct Connect®, using Specialized Mobile Radio technology) has been proposed for special connection calls between MSs. have. Both versions of the special connection call require that all members be located in the same area provided by one BSC. In a first version, a one-to-one conversation is allowed between two mobile phone subscribers, for example A and B. When A wants to have a special connection communication with B, A enters B's personal identification number, presses and holds the push to talk (PTT) button, and sends an audible alert indicating that B is ready to receive Wait, and start speaking. To listen, A releases the PTT button. If B wants to speak, B presses and holds the PTT button and waits for an audible confirmation that A is ready to receive. This service allows subscribers to select a personal identification number from a scrollable list displayed on a mobile phone handset or retrieve a pre-stored list of subscribers' names.

In a second version, conversation is allowed between members of a predetermined group of subscribers, known as Talkgroups, identified by numbers. The mobile phone handset allows talk group numbers to be retrieved through the handset's control plane. To make a group call, the initiating subscriber, e.g., A, can find the talk group number in the handset, press and hold the PTT button, and start speaking when receiving an audible acknowledgment such as a chirp. have. All other talk group members on the group call can only listen as long as A holds down the PTT button. When A releases the PTT button, other members on that group call can start speaking by holding down the PTT button and acquiring control signaling by an audible confirmation.

<b>summary</b>

SUMMARY OF THE INVENTION The present invention generally provides systems and methods for mobile communications, and more particularly, systems and methods for group calls. The information is retrieved from the list of members of the group calling group. Based on the retrieved information, a group call is established between the first and second mobile stations MS. The first MS is served by a first base station controller (BSC), and the second MS is served by a second BSC. Voice data for group calls is transmitted in a multicast session. Based on the history of the group call between two points in the mobile communication network, for example, in anticipation of a future group call, a decision is made as to whether to establish a multicast session between the two points.

By initiating a single call, a member of a group may enable a group call to be established among all reachable members of the group. A group call may be established between members who may be located in different regions served by different BSCs and possibly by different access methods (eg, TDMA or CDMA). Inter-BSC voice traffic between members in a group call may be carried by an alternative communication network, such as an Internet Protocol network.

1 is a system block diagram of a prior art mobile network.

2 shows a prior art interface between a BS and a mobile switching center in a prior art mobile network.

3 shows a block diagram of a system including group call logic.

Figures 4 and 5 show arbitrary deployments and proxy switches in a mobile network.

6 shows an exemplary data plane of a proxy switch according to a preferred embodiment of the present invention.

7, 9 and 16 to 17 show the architecture of a group communication system.

8A-8C and 11-15 are call flow diagrams for use of a group communication system.

10 shows a flow diagram of group call logic.

3, a system and method for establishing a call between members of a predefined group of mobile phone users is provided. As described in more detail below, a proxy switch or other device implementing group call logic 1010 detects a group call initiation by member 1012A of group 1014, and in the group call, the members of that group ( 1012A, 1012B, and 1012C) are automatically attempted. In certain implementations, communication in a group call is half duplex (ie, only one member can speak at a time), and the group's voice traffic is carried over an Internet Protocol (IP) network in a multicast session.

With respect to the case where the group call logic is implemented by a proxy switch, the proxy switch is referred to as "System and Method of Servicing Mobile Communications with a Proxy Switch", filed November 22, 2000, which is incorporated herein by reference. may operate as described in U.S. copending application Ser. No. 09/721,329, entitled 4 , a switching 1034 operation is performed between at least one MSC 1030 and at least one base station subsystem (BS) 1032 , as described in this co-operative application and shown in FIG. 4 . This switching allows communication traffic to be siphoned to or from an alternative network 1036 , such as an IP network. Because the switching is transparent, neither the MSC nor the BS require any modifications to work with the switching of the present invention.

The proxy switch described in the aforementioned co-pending application includes signaling message processing logic 1038 for receiving signaling messages from the MSC and the BS in accordance with a mobile signaling protocol. The message interception logic 1040, in cooperation with the signaling message processing logic, sends an acknowledgment message to the MSC or BS that sent the signaling message. The message waterproofing logic also prevents signaling messages from being sent to the other of the BS and MSC respectively. Message transformation logic 1042 cooperates with signaling message processing logic to transform signaling messages from one of the MSC and BS into transformed signaling messages for transmission to the other of the BS and MSC, respectively. Message transfer logic 1044 cooperates with signaling message processing logic to transfer signaling messages from one of the MSC and BS to the other of the BS and MSC, respectively.

A set of bearer circuits 1046 from the BS are assigned to the proxy switch. It receives and analyzes signaling messages between the MSC and the BS to determine whether these messages correspond to the set of assigned bearer circuits. If so, the control information in the signaling message is forwarded to the alternate communication network, and the information carried on the set of bearer circuits is siphoned to the alternate network.

5 shows one preferred arrangement of a proxy switch 300 , in which the proxy switch 300 is located between the BS 107 and the MSC 110 . Only a subset of trunks 306 carrying user traffic need to terminate on the proxy switch, and other trunks 308 may directly connect MSC 110 and BS 107 . All control links 312 from BS 107 terminate at proxy switch 300 . The proxy switch includes a control plane 302 and a data plane 304 (also known as a "bearer plane"). The control plane 302 handles all signaling traffic, and the data plane 304 handles all user traffic for trunks connected to the proxy switch.

In some embodiments, there is a one-to-one correspondence between the MSC and the proxy switch. Several BSs can operate with a single proxy switch.

The proxy switch 300 includes software that accepts all signal messages, and performs at least one of the following according to the status and message of the system.

One. Send the unaltered message to the MSC or BS addressed in the message.

2. It seals messages between MSC and BS.

3. For some waterproofed messages, it converts the waterproofed messages into different messages and sends the converted message to the MSC or BS addressed in the waterproofed message instead of the original waterproofed message.

4. Siphon messages from mobile-based and PSTN-based networks to alternative networks such as IP networks.

The type of action performed in each case together with the triggering event is described below.

In many cases, proxy switch 300 may act as MSC 110 , particularly when messages from MS 114 are siphoned and traffic is directed to an alternative network. For these roles, the proxy switch carries out the responsibilities and roles that a normal MSC performs. Some of these functions and roles relate to mobility management. Considering the case of a roaming MS, when the MS moves from one cell to another, a handoff is required between the source MSC and the target MSC because it may roam to a cell served by a different MSC. If the proxy switch 300 siphons the message and the call/session is directed to an alternate network, then the handoff is managed by the proxy switch similar to how handoffs were managed by conventional MSCs. The proxy switch causes the appropriate database to be updated with the MS's new location.

Another function of the proxy switch relates to the allocation of resources. In particular, if the MS initiates a message requesting a new call/session, it will need to allocate an appropriate line (channel) for this session. Depending on the system configuration and system state, the proxy switch allocates circuits in a manner similar to that of a conventional MSC.

6 is an exemplary diagram in which proxy switch 300 is connected to several alternative networks, such as, for example, an IP backbone 412 or an alternative circuit-based network 414 on different carriers, etc. indicates the arrangement. These alternative networks may be used to deliver voice and/or data traffic to a desired destination while avoiding all or part of the PSTN 120 along with the expensive resources of the MSC 110 . Alternatively, these arrangements can be used to allow line traffic to be backhauled to another network, for example line traffic from the city of Nashua, New Hampshire, It can be returned to MSC in Waltham, Massachusetts. Alternatively, these arrangements may be used to connect to other networks. For example, IP backbone 412 may communicate with IP voice network 418 or Internet 416 . When siphoning traffic to an alternative network, as described in the aforementioned co-pending application, both voice or data from the bearer circuit on link 306 and control information (eg, from signaling messages) are alternatively It can be transmitted over a hostile network.

In certain implementations of the group communication system described above, mobile communication users ("users") belonging to a closed user group (CUG, or "group") are provided with the ability to quickly and easily contact each other and , so that we can start talking to each other. Each group contains two or more users ("members"), and a user may belong to multiple CUGs. A conversation can take place between two members of a group ("private mode") or between all available members of a CUG ("public mode"). Group communication systems use conventional mobile communication devices such as cellular telephones and mobile PDAs.

In a particular embodiment, the group communication system implements the group call logic in proxy switches that are logically placed between the MSC and the BSC as described above to prevent group call initiation and bypass the MSC and the PSTN. ) and implements a group call as an IP multicast session that performs Voice over IP (VoIP). Users in a group may have multiple spanning aggregate networks that rely on one or more radio technologies, for example, CDMA, TDMA (including IS-136 and GSM), GPRS and 3rd generation technologies. You can receive service from a geographically distant location by the MSC of For example, among group members participating in any one group call, one or more users may be roaming in a GSM network while one or more users are roaming in a CDMA network. Control information pertaining to a group call may be made available to one or more users while the group call is in progress, such as presentation participants of the group call. The group call list can be dynamically created and modified by the group call user using standard numbering schemes such as MIN, IMSI and ESN.

A general architecture for an exemplary embodiment of a group communication system is shown by way of example in FIG. 7 . 7 shows four users in a group call using wireless devices 1060A-1060D connected to different BTS systems 1062A-1062D. For the purposes of the following description, it is assumed that wireless devices have both voice and text display capabilities. The BTSs are coupled to BSCs 1064A-1064D, which are coupled to proxy switches implementing group call logic ("group call switch") 1066A-1066C. Each group call switch is connected to an MSC, such as MSC 1068A, 1068B, or 1068C. At least one group call switch is provided for every MSC in a group call service enabled network. With respect to signaling information, each group call switch is logically located between a corresponding BSC and a corresponding MSC. The group call switch receives signals and data from the MSC and in the reverse direction via the BTS and BSC from the wireless device. Each group call switch operates as if neither the BSC nor the MSC were aware of the group call switch located between the BSC and the MSC. Signaling and control information from the MSC and BSC is sealed by the group call switch and is passed seamlessly to the relevant components as needed without any identifiable changes.

The MSCs connect to a Public Land Mobile Network (PLMN) 1070 , and the group call switches connect to a backbone multicast-enabled IP network ("backbone network") 1072 , so the backbone network 1072 is connected to the CUG Active Directory 1074 and enhanced HLR 1076.

As described above with respect to the proxy switch of the aforementioned co-pending application, the group call switch includes a control plane and a data plane. The function on the control side is the termination of signaling messages from either the BSC or the MSC or both. For example, in CDMA networks, signaling messages are defined in the IS-634 protocol specification. The control plane terminates the incoming signal and generates a new signal message for forward transmission to the MSC or other component. The control plane also supports the multicast function described below.

In one particular embodiment, the data side of the group call switch receives TDM traffic from either the BSC or the MSC or both, and receives the incoming traffic to the outgoing destination using a TDM cross connection ("DACS") (FIG. 5). interface with In other embodiments, the data plane also receives input IP traffic from a Base Station Complex (also known as a Radio Access Network or "RAN") and switches the input IP traffic to output IP traffic. can do. The programming control at the control plane determines the cross connections between the input TDM traffic and the output destinations, in particular the typical MSC and/or destinations on the IP network.

In the case of the MSC acting as the destination for the output from the DASC, the group call switch is essentially transparent to the network, and traffic and control flows seamlessly from the BSC to the MSC and from the MSC to the BSC. When the output destination is on behalf of the IP network, a Media Gateway (described in the co-incidental application described above) on the data side diverts a selected portion of the input TDM traffic from the MSC, and the input TDM traffic converts RTP/UD/IP traffic into RTP/UD/IP traffic and inserts RTP/UD/IP traffic into the backbone IP network.

The CUG Active Directory ("CUG AD") 1074, also known as the Group Call Registry ("GCR"), is a database system that contains CUG data. In a specific implementation, the CUG AD of FIG. 15 is implemented as a distributed database system for scalability. The CUG AD contains the definitions of all CUGs within the group call network. An inquiry to a CUG AD specifies the identifier of the CUG, that is, the inquiry requires the definition of a specific CUG, and the result is a list of group user IDs for all members of a specific CUG. For example, a query specifying CUG ID 2347 results in CUG AD identifying the Mobile Identification Number ("MIN") xxx, yyy, zzz and www for the four users in the CUG. can do. In certain embodiments, a MIN number is assigned to a user of a GIR service by a service provider.

Each CUG is identified to the system by a unique identifier ID derived from a CUG namespace that is partitioned such that different partitions are assigned to different distributed parts of the CUG AD. A partition index is made available to all group call switches. When a group call switch needs to retrieve the definition of a CUG, the group call switch uses this index to determine which component of the CUG AD to be queried.

Enhanced HLR 1076 is an enhanced version of the standard HLR database ("standard HLR") used in cellular telephones. Standard HLR field positions are updated from roaming mobile users. A typical path traversed by this update is from the mobile phone to the BTS, from the BTS to the BSC, and then to the MSC, sending an update message to the HLR. In a particular implementation of the group call network, the group call switch is located between the BSC and the MSC, so that all location updates are made visible to the group call switch. For users subscribed to the group call service, the group call switch blocks the location update message and replicates them to the HLR'. In addition to storing the cellular location of the group calling users, the HLR' stores a list of all CUGs to which each group calling user belongs. A query to the HLR' specifies a MIN that identifies the group calling user and generates a response containing a list of CUGs of which the group calling user is a member.

In a particular implementation, HLR' is a distributed database in which the distribution of data is based on a MIN hierarchy. Alternatively, the HLR' may also be based on an International Mobile Subscriber ID ("IMSI") or Equipment Serial Number ("ESN"). By an index similar to the partition index described above with respect to the CUG namespace, the group call switch can determine the HLR' partition to be queried when processing an input request.

In the following example for a family, a CUG can be defined to include users of dad, mom, and teenager, each carrying a cellular phone. By pressing a special set of keys on the cellular phone (or one special key if provided on the phone), Dad locates Mom and Teenagers and initiates a group call that invites them to join the group call. process can be run. In the half-duplex implementation described below, when the group communication system confirms that at least one member of the CUG has joined the group call, speaking control is assigned to the father as the initiating participating member, so that the other participating members or members You can start speaking while listening. If the father relinquishes speech control, any member of the other participating members of the CUG (eg, a teenager if a teenager has joined the call) can acquire speech control and speak. Thus, in the half-duplex implementation, only participating members assigned speech control can speak, and other participating members cannot speak until speech control is relinquished and reassigned. As will be described in detail below, in order to request speech control, a user on a group call can press a standard number key on the phone, or a special key if provided by the phone manufacturer, or the phone can send a text message function In this case, it is possible to send a text message requesting to speak next to the speaker. If at any point in time the call talk control remains unassigned for a predetermined period of time (i.e., the conversation is over), the call is terminated.

A group call can be configured when all members of a CUG are in the same switching area, ie a geographic area controlled by a single MSC or proxy switch, or are in different switching areas. For example, in the case of a CUG containing users of A, B, C and D, A and B currently roam in switching region S1, C roams in switching region S2, and D roams in switching region S3. may be doing If the S1, S2, S3 and S4 switching areas are all operated by the same service provider or managed by operators who agree to cooperate with each other to provide group call services, A group call may be established. In this case, individuals may be widely distributed in terms of physical location, for example, A and B are in Boston, C is in Texas, and D is in California.

A group communication system provides interoperability of calls across different kinds of network technologies, i.e., whether members of a CUG are roaming across networks based on different technologies or not. Allows the call to be built. For example, User A roams on a CDMA-based network in Boston and User B roams on a GSM-based network in the United Kingdom ("UK") (GSM uses Time Division Multiple Access ("TDMA") technology). there is A group call may be established between A and B if A and B belong to the same CUG, and the CDMA and GSM operators agree to cooperate in providing the group call service.

The system may include one or more of the following enhancements, described in more detail below. As is apparent from the foregoing, a group call can be established regardless of which members of the CUG are participating in the call. If some members of the CUG are unable to participate in the group call, the system may create and log an exception list listing the missing members. If one or more members of the CUG have a phone with a display screen, an exception list may be displayed on the display screen. Actions may also be taken based on the exception list. For example, during or after a call, a voice mail message may be sent to members listed on the exception list, such as the voice mail message being logged once by the call initiator, and by the group communication system to members on the exception list. Voicemails can be forwarded to the voicemail box of the previously specified voicemail phone number. Instead or in addition to, the CUG members participating in a particular group call are listed on the available display screens of all participating members' phones during the call, informing each participating member which other members are on the call. A visual indication may be provided on an available display screen to identify the member who currently has speech control.

A user of the group communication system can establish a dedicated call with other users of the group communication system, so that the users can discuss confidential or private information outside the group call. Thus, two participants in an ongoing group call can temporarily place a dedicated call and then return to the ongoing group call.

A user of a group communication system may request a list of ongoing group calls ("active group calls") to a CUG of which the user is a member, and participate in one of these calls. A user of the group communication system may initiate or participate in a public group call, ie a group call to a CUG that includes all users of the group communication system. An operator may define any number of public user groups ("PUGs"). Each user of the group communication system automatically becomes a member of all PUGs. To join an active public group call, the user requests a list of active public group calls and selects the call to join.

When the user of the group communication system has a call waiting function, the user can put the group call on hold and respond to the input call signal. A user who does not wish to accept any incoming call signals, including those for group calls, can also activate Call Forwarding or Call Blocking. The user may choose to block only incoming call signals for group calls, private calls, or both.

Group communication systems may incorporate voice-to-text conversion within group calls for the convenience of users in noisy environments, users in public places where use of audible phones is limited, and users with hearing impairments, and language conversion (eg, , English to French).

The user of the group communication system identifies a special group communication system that the service provider can assign during group service sign-up based on the user's mobile phone number or contact information stored in the phone directory of the user's phone. You may be contacted using a number ("Group User ID"). The group user ID may be self set up ("self-supplied") instead of or in addition to using the web-based provisioning system described below.

As noted above, the group communication system provides three modes of operation: a Closed User Group ("CUG") mode, a dedicated mode, and a Public User Group ("PUG") mode. do. Except in the case of user-controlled calls described below, the user presses a number key (or a special phone key, if provided) to speak and waits to hear a tone indicating that the user has been granted speech control. . When the user has finished speaking, the user presses a key, causing other participating users to hear a tone indicating that speech control is enabled. Then another participating user can press a key, hear a tone, and start speaking. The initiator initiates speech control after at least one other user has joined the call as indicated by the tone. A call ends when all participating users have hung up or when no one has requested speech control for a predetermined period of time as described above. The system resolves any conflicts between requests if there are concurrent requests from users for speech control. For example, if a full duplex mode is possible for a conversation, a "human protocol" may be used. In this case, control may be transferred to multiple users, eventually all but one user being silenced, and speaking control transferred to a non-silent user.

In CUG mode, group call users form a closed user group by creating a unique group ID for the list and assigning members to the list using the member's group call ID and their mobile phone number. As signaled by the radio access network ("RAN") to the handset under the direction of the proxy switch, and the RAN uses the mobile phone number to validate this signaling, the CUG information includes the mobile phone number. Each CUG optionally contains two or more users of the maximum size imposed by the service provider.

In certain implementations, if a group call user wants to contact a group of users in the user community (ie CUG mode), the user can key in ("enter") the call initiation sequence, for example, * After 4, press the send key followed by the CUG ID. (Call initiation sequences can also be stored in and dialed from the user's phone's speed dialing directory.) Members of the CUG who were not able to join the call when initially notified, the call is still If active, you can join the call later by entering the call initiation sequence and pressing the transmit key.

In CUG mode, the call initiator has the option to request a user-controlled call, which is a call with a "barge-in" function. According to the barge-in function, the listening user may issue a warning message by pressing keys in a service configurable DTMF sequence to indicate to the speaking user that the listening user wants to obtain speech control. It can be sent to the user who is speaking. At that point, the speaking user may press a key to relinquish utterance control, or continue speaking. Thus, the barge-in function provides an audible notification to the speaking user that the listening user wants to speak, and in the case of phones with a text display, sends out a barge-in message. You can provide a text message indicating the name of the user who is listening. Thus, the speaking user is not forced to assume that the listening user intends to speak. If the user speaking does not want to be interrupted (eg, while making an announcement to a large group of people), the barge-in function may be disabled.

As mentioned above, the CUG mode may also provide speaker identification capability for participation reports and broadcast capability for join exceptions.

To transcribe group calls in real time using speech-to-text technology, a call transcription function may be provided in CUG mode. A group member having a text display phone and being notified of a group call may request that the call be muted and receive a text transcription instead. In certain embodiments, a phone without a text display transmits and receives only audio tones, a text-only device, such as a text pager, receives the text, and the text-only device is not notified of a group call unless the call transcription function is turned on. does not A full transcript of the call is available at the end of the call and can be sent to all members of the CUG, CUG members not participating in the call (based on the join exception list), or the call initiator. This functionality can be extended to translation services using the preferred language indicator available with IS-41-C. A preferred language indicator is an information element included in the subscriber's profile and stored in the HLR database for indicating the subscriber's preference for the language in which announcements and other reports should be presented. The switch uses the preferred language indicator when playing pre-stored announcements. Additional resources, such as people or automatic translation devices, may be provided by the service provider.

The group call ID and associated member list may be established using a web-based provisioning application from a personal computer or WAP-enabled device. The user can also set up the list from the user's mobile phone. The service provider specifies limits on the number of members on the list, the network or networks to which the members belong, and the number of lists a group calling user can maintain.

In the dedicated mode, the group call user enters the group call start sequence followed by the group call ID of the intended receiving member after, for example, *4, and presses transmit to the group of users connected to the group call enable network. You can quickly make a call to any member. The intended recipient member is notified of the call from the user, and in certain embodiments, the user hears a chirp when the intended recipient member answers the call.

In PUG mode, the group call user can view the list of groups currently chatting with, and decide to join the chat group. A group call user can create a new chat group available to any group call user by specifying a unique group call ID and the subject of that group providing a brief text description. Subscribers may optionally associate a text name with a group call ID, as long as the text name is unique across chat groups that are currently active.

The group call function does not override existing mobile phone functions such as call forwarding, do not disturb, and call blocking. If call waiting is available, the caller on the group call can switch to the incoming call. For security reasons, three way calling, call conferencing and call transfer are not possible during a group call, again at the peak of the group call.

The group call service supports conversation encryption using the IS-41-C Voice Privacy ("VP") function as required by the mobile phone if the corresponding base station supports VP.

In a specific implementation, described in more detail below, the group call service operates in an IP network using IP multicast. As mentioned above, IP multicast allows a source to broadcast a single copy of a stream of VoIP packets received by multiple recipients explicitly registered to receive the stream. Multicast is a receiver-based concept that allows a receiver to join a particular multicast session group and a stream is delivered by the network infrastructure to all members of that group. Only one copy of the multicast stream is delivered over any link in the IP network, and copies are formed only at the IP multicast-enabled media gateway if necessary.

In a wireless network, a service has some characteristics of any conventional wireless call. As described above, the group call initiator may use a DTMF feature escape sequence followed by the ID of the group call list of the user the initiator wishes to contact (eg, "*4" followed by the user group ID). Initiate a group call by sending The function escape sequence detects that the call is a group call and queries the Global Call Registry ("GCR" or "CUG AD") to retrieve a list of mobile phones to contact and their current locations. used by proxy switches for The current location information determines which media gateways and BSCs will be involved in the group call. A bearer channel is established between each such BSC and the corresponding media gateway through the group call switch data plane. Group calls are provided to each BSC as having a traditional point-to-point call setup and tear down feature, not to the MSC.

An exemplary call flow diagram for a basic service in a wireless network is shown in Figures 8A-8C, where WCS-1 and WCS-2 represent group call switches. Referring also to FIGS. 9 and 10 , the main entities in the flowchart are group call switches WCS-1, WCS-2 with respective media gateways MG1, MG2, a GCR accessible by WCS-2, and BSCs which are BSCs. -1, BSC-2, and mobile stations (eg, telephones) MS-A and MS-B. In the case of this example, MS-A and MS-B are covered by the same group call switch WCS-1, but the procedure is the same if MS-A and MS-B are covered by different group call switches.

Fig. 10 is a group call logic flow diagram summarizing the call flow diagrams of Figs. 8A-8C for establishing a group call. The sharing of logic handled by WCS-1 is shown on the left, and the sharing of logic handled by WCS-2 is shown on the right. WCS-1 detects that MS-A has requested a group call (step 3010), and notifies WCS-2 (group call coordinator) of it (step 3020). WCS-2 consults the GCR to determine other members of MS-A's CUG and their last known locations (step 3030). (In this simple example, MS-B just represents another member). WCS-2 creates a media gateway connection with WCS-1 (group call switch for MS-A) (step 3040). WCS-1 acquires a radio channel for MS-A (step 3050). WCS-2 tells WCS-1 (group call switch for MS-B) to page MS-B (step 3060). WCS-1 pages MS-B (step 3070), and then notifies WCS-2 that MS-B has been found (step 3080). WCS-2 creates a media gateway connection with WCS-1 (group call switch for MS-B) (step 3090). WCS-1 acquires a radio channel for MS-B (step 4000), and notifies WCS-2 that the acquisition has ended (step 4010). WCS-2 informs WCS-1 to indicate to MS-A that MS-B has arrived (step 4020), and then causes a tone to be played to MS-A via the media gateway (step 4030). ).

In addition, an example of a call flow will be described below with reference to FIGS. 12 to 15 .

As described above, in group calls, only one participating user is allowed to speak at a time, and the participating user with speech control is such Control may be relinquished, and another participating user may then request utterance control by sending a DTMF digit (eg, "8"). A participating user with speech control hears a success tone that is played when the transmission path is established, as shown in FIG. 11 .

Prior to the group call, the group call user may choose to enable or disable one or more of the following functions described above: join exception report, join report, call transcription, and barge-in function.

In a web-based setup system available to end users to build their GCR lists, the web server connects to the GCR via an IP link to enable real-time updating of the user's group call list. The setup system supports the standard industrial browser as well as the WAP protocol.

For billing and network engineering purposes, call logs are collected for all participants in a group call.

12 shows an example of an application of a group call service, which is now described. According to this example, CUG1 is a CUG with 4 users A, B, C, and D. Users A and B are currently served by the group call switch G1, C is served by the group call switch G2, and D is served by the group call switch G3. Users are assigned a unique MIN by the group call service provider. For simplicity, unique MINs are referred to herein as A, B, C, D. CUG1 is assigned by a service provider and has a unique identifier expressed as CUG1 in this specification. The definition of CUG1, i.e., a list of CUG1 memberships, is maintained within a distributed component of CUG AD called AD1.

In the first example, a group call is initiated by A to group CUG1, namely B, C, D. 12 is a call flow diagram of a group call.

A initiates a group call request to the closed user group CUG1. In the IS634 interface, the request is marked as CM_service_request with CUG1. In the case of a radio access network ("RAN"), the request is very similar to any other call request. The IS634 command and related information elements include, among other items of information, a called number and a called number (eg CUG1 is assumed in the present example). In at least some cases, the RAN does not have logic to distinguish a valid numbering plan from an invalid numbering plan, and this logic may be implemented within the MSC. In this case, the RAN sends the number information to the MSC as part of the IS634 message set. Because the proxy switch seals these messages, the number information is made available to the proxy switch. Because the proxy switch can function as an MSC in at least some way, the proxy switch can determine that the incoming call request is not a conventional call request, but is a group call request for a closed user group. In this example, the proxy switch assumes the role of the group call switch and initiates the procedure for the group call.

The group call switch G1 again issues a channel assignment request to A. G1 also initiates a directory transaction to retrieve the definition of group CUG1 from CUG AD component AD1. The response from AD1 is expected to include a list of MINs corresponding to members of group CUG1, namely B, C, D. When the response is received, G1 gets the following information.

CUG1 contains (in addition to A) members B, C, and D

MIN B is responsible for switch G1 (ie itself)

MIN C is the responsibility of switch G2

MIN D is the responsibility of switch G3

G1 initiates a call setup request to B (which is G1's own responsibility) and sends a call setup request to G2 and G3 for C and D, respectively. Thus, G2 and G3 function as proxy switches for G1 for this particular group call. G1 also ensures the creation of a new context where TDM traffic is sent from RAN to media gateway, which media gateway converts TDM traffic to RTP/UDP/IP packets, sending RTP/UDP/IP packets to multicast router do. The multicast router receives the packet, adds A to the multicast group, and is instructed to multicast the packet to a specific multicast group. In the call flow diagram of Fig. 18, the instructions are collectively shown as "Join Multicast Group (TDM A)".

G1 then waits for connection messages from B, G2 and G3. Any of these three messages may be received in any order, and it is possible that only a subset of them is received. In this example, G1 first receives a connect message from B, and then receives a connect message from G2 and G3. Upon receiving the connect message from B, G1 causes Media Gate A to accept RTP/UDP/IP traffic from multicast router, convert RTP/UDP/IP traffic to TDM, TDM, TDM to BSC and It transmits "Join Multicast Group (TDM B)" which is transmitted to switch G1 to be transmitted to B via the BTS. The multicast router is instructed to add B to the current multicast group. Thus, for current group call purposes, switch G1 functions as a source of TDM traffic and switch G2 functions as a sink for TDM traffic.

In this example, C sends a connect message to G2 (ie the switch responsible for C), and G2 sends a connect message to G1. G1 then sends a "Join Multicast Group (TDM C)" message that allows C to join the group call in RECEIVE mode. Similarly, the connect message from D to G3 is relayed to G1 which causes D to be added to the multicast group.

The media gateway is instructed by the control plane to send and receive packets on specific RTP ports only in a specific context. Packets are multicast to the members of the multicast group by the router.

At this point, since G1 has received at least one confirmation of the user participating in the group call, G1 sends a success tone to A indicating that the group call can now proceed. A is in the sending (SEND) mode, B, C, and D are in the receiving mode, and the multicast router can multicast to B, C, and D.

In another example, as shown in the call flow diagram of Fig. 13, transfer of speech control is performed. Specifically, A relinquishes speech control, and C acquires it.

To relinquish speech control, A signals G1, putting the current group call into INACTIVE mode. (As described above, if the user fails to acquire speech control within a predetermined time measured by the system timer, the group call is terminated.) C issues an Acquire Talk command to its responsible switch G2. For the purpose of the current group call, since switches G2 and G3 are proxies to the control switch G1, the torque acquisition command is relayed to G1. G1 issues a MODIFY CONTEXT command to the media gateway so that the media gateway associated with switch G2 accepts input TDM traffic from C, converts TDM traffic to RTP/UDP/IP, and RTP/UDP/IP to the multicast router. The media gateway is instructed to stop receiving TDM traffic from A. The multicast router is instructed to change the mode of A to the receive mode and change the mode of C to the transmit mode. G1 issues a Grant Talk message to G2, so G2 sends C a success tone indicating that C can now proceed to speak. A multicast session can now proceed as shown, with C as the speaker and A, B, and D as listeners.

For example, if B issues a talk get message, and speech control is with C, then the message is B's responsibility to deny the request (because C has not relinquished speech control) and send a fail tone message to B. is sent to switch G1.

As another example, the group call has two participants A and B, and the situation is simplified such that A has speech control. The network includes a single group call switch G1 that controls the two media gateways MG1 and MG2, including the control plane CS. As shown in the call flow diagram of Fig. 14, traffic from A and to A travels through MG1, and traffic from B and to B travels through MG2.

Since A has speech control, the system responds only to the Relinquish Control command from A. This command is received by control plane CS of G1 which issues a context modification command to MG1 instructing MG1 to modify the context of the call by prohibiting TDM traffic from A. The system enters an inactive state waiting for a take control command. If such a command is not received within a certain period of time as measured by the inactivity timer, a call release request is issued from CS to A and MS B. Also, a destroy context command is sent to MG1 and MG2. When a Release Complete message is received from A and B and a Destroy Context Complete message is received from MG1 and MG2, the group call release sequence is completed.

Fig. 15 shows an example of a call flow for a database record maintained in the case of roaming, i.e. location update.

Three mobile stations A, B and C are involved. A and B are responsible for the control surface CS1 of the group call switch, and C is responsible for the control surface CS2 of the other group call switch. A roams and issues a location update which is received by CS1 via BS and BSC. CS1 consults the index based on IMSI/MIN/ESN to determine the appropriate HLR for A, ie, HLR'1, and issues a location update request to HLR'1. HLR'1 determines by its database all CUGs to which A belongs. With this information, HLR'1 issues a location update request to CUG AD. Thus, the CUG AD contains the updated position of A within the CUGs to which A belongs.

While roaming, B also issues a location update that is sent to CS1. Based on IMSI/MIN/ESN, CS1 determines the appropriate HLR for B, ie HLR'2. CS1 issues a location update request to HLR'2 that finds all CUGs to which B belongs. HLR'2 issues a location update request to CUG AD, requesting CUG AD to update all CUGs to which B belongs, for B's new location.

The location update from C is received at CS2. CS2 determines the appropriate HLR', ie HLR'2, and sends a location update to HLR'2 requesting the CUG AD to update the corresponding CUG for C.

<u>Variant</u>

All of the above-described embodiments facilitate the realization of the group call of the present invention. However, a subset of functions still provides advantages for the state of the art. For example, group calls using techniques other than multicasting over IP networks still provide many of the advantages described above. In particular, a standard dial-up connection using the PSTN may be used instead of an IP multicast connection.

In another example, the group call switch may be located on the trunk ("back") side of the MSC. In this embodiment, the group call function operates as described below.

Figure 16 shows a group call switch disposed on the backside of the MSC, including a fixed link using the standard ISUP (ISDN User Part) landline signaling scheme. The MSC connects to the HLR using the IS-41 (also known as MAP) protocol. The group call switch and MSC are also interconnected with a bearer trunk that carries voice traffic between the two switches. A group call switch includes an IP connection from its data side (also known as a media gateway) to an IP network and a TDM connection to the PSTN. The group call switch may also query the HLR using IS-41. (FIG. 16 shows two MSC switches connected independently of the PSTN, but both switches can be connected to the same PSTN.) Both group call switches are connected to Active Directory (CUG-AD) via the IP network. have access

The arrangement shown in Fig. 16 can be used for group calls. For example, mobile station (MS) A may be connected to MSC-1 via RAN-1, and two mobile stations B and C may be connected to MSC-2 via RAN-2. Subscriber A may have a CUG comprising B and C as members. As mentioned above, A may use a special group call initiation sequence to inform the MSC that it wants to make a group call. The logic of MSC-1 determines that the incoming call request is a group call, and switches the call request to the group call switch GCS-1 using the ISUP protocol. The group call switch GCS-1 accesses the Active Directory CUG-AD using its internal logic to determine which member of the CGU is called.

In this embodiment, the query yields the MIN numbers of members B and C. In this case, which is placed on the backside of the MSC, the group call switch does not have access to the location update, and thus the HLR' does not contain the current location of the called mobile station. However, the HLR contains this information. Thus, the group call switch GCS-1 makes an IS-41 query ("request for location") to the HLR, querying the locations of mobile stations B and C. For the purposes of this example, mobile stations B and C may currently be located in a switching area controlled by MSC-2. In accordance with standard mobile phone practice, this information is included in the HLR database, and the HLR now contacts MSC-2 (via a "route request"). As long as MSC-2 uses GCS-2 on the trunk side, the route request from the HLR is received by GCS-2. GCS-2 returns a Temporary Local Directory Number (TLDN) to the HLR that conveys this information to the originator of the location request (GCS-1). GCS-1 determines that the TLDN belongs to GCS-2, and notifies GCS-2 about the group call. GCS-2 instructs MSC-2 to establish group calls to mobile stations B and C. Also, for non-backside cases, the interaction proceeds as described above, and MSC-1 and MSC-2 are effectively transparent to the purpose of the group call.

The back side of the switch arrangement for a group call has an attendant advantage which is evident from FIG. 16 . For this arrangement, a conventional landline telephone such as telephone D shown in FIG. 16 may also be involved in the group call. Thus, a CUG member can register a landline phone number as a "reach" number in the CUG Active Directory. If such a subscriber, such as D, needs to be included in the group call, the associated group call switch may request the serving MSC to terminate the PSTN call to D using the subscriber's stored arrival number.

As described above, the IP multicast technique can be used as a basic transport technique for group calls. However, in at least some cases, standard implementations of IP multicast technology may prove inefficient in meeting the needs of widely distributed CUG members. Dynamic call-by-call setup of a multicast tunnel to transmit traffic between multicast-enabled routers may take an excessively long time. Subscribers who experience long group call setup times either pick up the phone or retry the call, resulting in an unsatisfactory user experience. Long delays in call setup times also result in inefficient signaling network utilization.

For example, as shown in FIG. 17 , a plurality of multicast-enabled routers, for example, MCR-1, MCR-2, and MCR-3, may exist in an IP network. In this example, the location of these routers is fixed and does not change. The multicast routers are connected to group call switches (in the front of the MSC on the back side of the MSC as described above), and thus to the mobile phones via corresponding Radio Access Networks (RANs). (Although Figure 17 shows each multicast router connected to a single group call switch, multiple group call switches may be connected to a single router.) A subscriber makes a group call based on the members of the associated CUG. , more than one multicast router may be involved in the call. In particular, tunnels are established between corresponding multicast routers as described above. If the establishment of these tunnels is delayed excessively, the quality of the group call deteriorates as a result.

As mentioned above, IP tunnels can be pre-established in such a way that multiple group call initiation requests arriving later can be serviced by these tunnels. In anticipation of future group call requests, as long as the tunnels are established in advance, the setup delay after initiation is thereby reduced or eliminated. Relevant tasks include predicting the demand for group calls that are expected to arrive in the future, and determining the topology of the IP tunnels that need to be established to satisfy the predicted demand.

Demand forecasting relies on historical information in the form of group call logs. The history of group calls is partitioned into a series of windows, each of which ranges from minutes to tens of minutes and is defined through a length of time known as the "window size" that is proportional to the average holding time of the group call. . The actual window size used in demand forecasting may vary based on the accuracy of the desired forecast and the computational resources used to derive the forecast. In general, the shorter the window size, the more accurate the prediction than the larger window size, but the waste of computational resources increases. Also, shorter window sizes tend to be more responsive to bursty traffic and less likely to smooth out aberrations. Each window contains a number of group call requests with parameters describing the call, ie the number of GIR calls between any two multicast routers. As explained below, X(I,J,N) specifies the number of group calls between routers I and J in window N.

The following example illustrates the prediction of future demand for group calls. In this example, the history of group calls is divided into four windows, with Window 1 being the earliest in time, and Window 4 being the slowest in time (ie, the current window). To calculate the demand in the next (future) window, i.e., window 5, the following smoothing formula is used.

<img file="KR100614541B1_D0001.tif" />

In this equation, α (alpha) is an a priori determined weight factor having a value between 0 and 1. As expressed in this equation, the prediction of traffic for the next window of time is based on giving preference to the recent window more than the previous window. This preference is clear if this formula is rewritten in a more general recursive form as follows:

<img file="KR100614541B1_D0002.tif" />

where X'(I,J,N-1) is a smoothed estimate encapsulating the past history up to N-1.

In this formula, "current" refers to the most recent window in the time sequence. Based on this formula and a given history of demand (windows 1 to N), as illustrated by the values of parameter X(I,J,N), a table of values T(I,J) ("demand matrix") ) may be computed for the next window such that the value in row I and column J represents the number of group calls predicted in the upcoming window between multicast routers I and J.

Regarding determining the topology of the tunnel to satisfy the demand, the following information is used as input. This information includes a point-to-point demand matrix for a group call between any two multicast routers, the cost structure of the tunnel by the service provider, i.e. the specific capacity ( capacity), the service provider's guarantee of delay, i.e. the maximum delay in the IP transport network between any two specific multicast routers, and the quality of service (QoS) that needs to be satisfied by the group call. ) is limited.

Taking this input into consideration, the topology of tunnels between multicast routers, that is, the topology of which tunnels of which capacity will connect to which multicast routers, is determined in such a way as to satisfy the following constraint. This constraint is that the tunnels from each multicast do not exceed the router's total output capacity (bits per second), and the number of tunnels from each multicast does not exceed the router's internal limit on the number of tunnels. .

As described below, the following points, where the mathematical optimization technique of ILP (Integer Linear Programming) is described below, i.e. the recognition of when "NP-hard", and which one can be solved using the ILP technique It is used to determine the least cost topology, taking into account the formulation of the task as a degree-limited multi-commodity flow.

According to the theory of NP-hardness, a case that can be represented as NP-hard is not expected to have an efficient algorithmic solution. In a given case, e.g., X can be shown to be NP-hard, e.g., by considering the case where it has already been taken as Y, and also by showing that Y is reduced to X in the time transform of the polynomial. have. The case of the tunnel topology design can be shown to be NP-hard by observing that it generalizes the problem of multi-commodity flow that cannot be split (J. Kleinberg, "Single source unsplittable flow," Proc. of the 37th IEEE Symposium on Foundations of Computer Science, 1996).

Thus, the tunnel topology case can be rewritten in the form, shown below, suitable for the application of the ILP approximation technique.

input

Let N denote the number of multicast routers in the network.

Let D(max,I) represent the maximum number of tunnels in which the router I can be set.

Let P(t,I) denote the unit cost of tunnel I for a trunk of type t. where "I" is the pair of nodes for multicast-enabled router (MCR) i and j = (i, j).

Let τ (tau) represent a set of all possible types of trunks (DS0, DS1, OC3, etc.).

Let T(I,J) denote the demand matrix, ie, the predicted group call traffic between routers I and J for a given future time period.

Let C(I) represent the capacity of the router I in bits per second.

Let R(I,J) be the set of all feasible routes for routing traffic between routers I and J. (This is a pre-processing step that results in all feasible qualities of the service path between MCRs I and J.)

Output Determining Variables

Y(t,I): number of units of type t trunk allocated on link I

X(p): amount of traffic flow on path p

z<sb>I</sb>: A binary valued variable having the value 1 if link I is assigned to a non-zero capacity, and 0 otherwise.

ILP formulation

minimization

<img file="KR100614541B1_D0003.tif" />

Subject to the following:

Satisfaction of demand (tunnel topology satisfies the demand matrix):

<img file="KR100614541B1_D0004.tif" />

Sufficient tunnel capacity (total flow on all paths can be regulated by the capacity of the selected trunk):

<img file="KR100614541B1_D0005.tif" />

Port constraints (the number of tunnels coming out of and terminating from the router does not exceed the router's internally configured maximum):

<img file="KR100614541B1_D0006.tif" />

The above analysis is formulated as follows.

<u>input</u>

N: number of routers

D<sb>It's</sb><sp>max</sp> : the maximum number of tunnels that router i can establish

p<sb>l</sb><sp>t</sp> : Unit cost of tunnel I for type t trunk

τ: set of all possible trunk types

T<sb>(I, J)</sb>: demand matrix (T(I,J)

C<sb>It's</sb>: Capacity of router i (bits/sec)

R<sb>ij</sb> : set of all feasible routes for routing traffic between routers i and j

<u>output determinant</u>

y<sb>l</sb><sp>t</sp> : Number of units of trunk of type t allocated to link I

x<sb>p</sb> : amount of flow on path p (traffic volume)

z<sb>I</sb> : = 1 if link I is assigned to a non-zero capacity

= 0 otherwise

<u>ILP formulation</u>

minimization

<img file="KR100614541B1_D0007.tif" />

Subject to the following:

· Satisfaction of demand

<img file="KR100614541B1_D0008.tif" />

· Sufficient tunnel capacity

<img file="KR100614541B1_D0009.tif" />

.Port restrictions

<img file="KR100614541B1_D0010.tif" />

Tunnel Existence Restriction

<img file="KR100614541B1_D0011.tif" />

Here, a damping coefficient ε is a parameter given to a user having a value greater than zero.

Further, in that the embodiments have been described with respect to a specific radio technology, such as a TDMA or CDMA protocol, the embodiments may also include one or more of TDMA, CDMA, GSM, IS-136, and other 2G and 3G protocols. It can be modified to work with wireless technology.

Although exemplary embodiments have been described, it will be understood by those skilled in the art that modifications may be made to these embodiments without departing from the spirit and scope of the invention.