CA2219885A1

CA2219885A1 - Methods and apparatuses for an intelligent switch

Info

Publication number: CA2219885A1
Application number: CA002219885A
Authority: CA
Inventors: Priscilla Marilyn Lu; Timothy R. White
Original assignee: Individual
Current assignee: Alvarion Mobile Inc
Priority date: 1995-05-04
Filing date: 1996-05-03
Publication date: 1996-11-07
Also published as: CN1179599C; WO1996035311A1; CN1196156A; AU5675496A; EP0829178A1; US5577029A; AU717237B2; US5761195A; IN185828B; TW293216B

Abstract

An apparatus for cross-connecting an end-to-end connection between an origination mobile station and a destination mobile station in a network of cross-connect nodes, which includes a call control circuit. The call control circuit includes a first circuit portion for receiving call control information from the origination mobile station and the destination mobile station and a second circuit portion for determining, responsive to receiving the call control information from the origination mobile station and the destination mobile station, an optimum end-to-end connection for cross-connecting the end-to-end connection through the network of cross-connect nodes. The optimum end-to-end connection represents a computed shortest communication route between the origination mobile station and the destination mobile station that statisfies resource requirements for cross-connecting the end-to-end connection.

Description

WO 9613!i311 ~ 3l4 ~IETHODS AND APPARATUSES FOR AN rNTELLIGENT SWITCH
For ease of l~;Çtlcllce, a glossary of terms and abbreviations is provided hc.c;wiLIl as Appendix A.

S BACKGROUND OF THE INVENTION
T~e present invention relates to ~ tl~ceC and methods for cellular ~o---------,i~-ation.
More ~l~el irrAlly, the present invention relates to ~y~dlaLu~es and m~tho~ls for intt~.lligently cross-cnn~ l;--g bearer data paths l~Lw~;en two cellular h~ntlcetc at lower levels of a cellular neLw~Jlh hierarchy.
In the tra~liti~n~l cellular c~.. i~tion system, such as one lltili7in~ the Global Systems for Mobile G.............. -i-~tion (GSM) protocol, the mobility m~n~gçmP.nt function (MM) is typically c~ntr~li7~d at the Mobile-services Switching Center (MSC). It in turn provides a packet c~.. ;r~tinnC path b~lweell call control (CC), supplem~.nt~l services (SS), short m~.cc~ services (SMS) and the mobile stations (MS units), also known as the cellular 1 5 h~nrl~Ptc The call control (CC) fi-nr.tion typically pel~,l,ls the call setup, which in-~hlrles call :,wiLcl~lg, and the suppl~omr-nt~l services (SS) function provides suppl~m.ont~l services to the MS units. As the name imrli~s, the short mtoss~e services (SMS) provides short message services to the MS units.
The L~ uil:~l GSM network typically provides a public MSC for controlling a large 20 geographical area. MS units within this geo~r~rhi~l area connect to the public MSC for their mobility m~n~gem~nt, call control, suppl~m~-nt~l services, and short message services needs.
In the prior art, the bearer data channel path that makes up part of the actual call path from each MS unit is b~LI. ~.lPd all the way up to the public MSC. At the public MSC, it either enters the public wired network or is cross-cf-nn~ct~-d with another bearer data channel 25 path from another MS unit for the purpose of cc~ g an end-to-end c~ li.." This is because the public MSC of the prior art both has access to subscriber information and cont:linc the actual call ~wiL~hillg circuit for eff~cting the re~uired cross-connection when an MS unit dials a telephone number ~ccoci~t~-l with another MS unit. The functions of the call ~wiL~;hing circuit in~.hldes, for çx~mple7 routing based on lthe t~l~phnnt- number dialed.
3 0 To f~rilit~tto discussion, Fig. 1 shows in a ~implifi~.d format a tr~-lition~l GSM cellular c~.. ".lir~tion network in(~ tling public MSC' 200, BSC's 202 and 204, and BTS's 206, 208, and 210. BSC 202 controls BTS 206, while BSC 204 controls BTS's 208 and 210. Fig. 1 also shows a plurality of MS units 220, 222, 224, 226, and 228. MS units 220 and ''22 are controlled by BTS 206, MS units 224 and 226 by BTS 208, and MS unit 228 by BTS 210.

CA 0221988~ 1997 - 10 - 30 When MS unit 220 wants to build a call to MS unit 228 in the prior art, the mobility management session is built from MS unit 220 to public MSC 200 via BTS 206 and BSC 202.
The ~lestin~tion phone number supplied by MS unit 220 enables public MSC 200 to locate MS
228 and then build a mobility management (MM) session to MS unit 228 via BSC 204 and S BTS 210. Thc~carL~l, the outgoing call path is built from MS unit 220 to public MSC 200 while the incoming call path is built from public MSC 200 to MS unit 228. The incoming and outgoing call paths are then cross-connected at public MSC 200 to complete the end-to-end connection.
When MS unit 220 desires to call MS unit 222 in the prior art, both the MM sessions 1 0 and the call paths associated with these two MS units are built all the way to public MSC 200, where the connection cross-connect between the incoming and the outgoing paths occur.
Likewise, when MS unit 224 wishes to call MS unit 228, both the MM sessions and the call paths associated with these two MS units are also built all the way to public MSC 200 to be cross-connected therein. In sum, the prior art requires that both the MM sessions and the call 1 5 paths from MS units that participate in a call be built all the way to the public MSC in order for the call paths to be cross-conn~ct~l, thereby completing the end-to-end connectit-n As is a~c;nt from Fig. 1, neither of the above-~ cnc~ed end-to-end connection via public MSC
200 le~lcsents the shortest route between the MS units particip~ting in the call.
As the term is used herein, a cross-connect represents the creation of a data path across one node which allows data to flow from one end, e.g., from an input source, to another end, e.g. to an output source. The data path may optionally pass through resources. For example, the data path in a GSM implement:ltion may pass through a TRAU. Further, the term end-to-end connPction represents the connection of one phone to another, inrlllrling all cross-connections within nodes that the end-to-end connPction traverses as well as intervening 2 5 f~riliti~ A path, on the other hand, ~ SellL~ a piece of an end-to-end connection. Examples of paths include incoming telephone paths, outgoing telephone paths, upstream paths, and downstream paths.
As the term is used herein, a downstream path is defined from the perspective of the "current node" and refers to the piece of the path through the current node and all other nodes 3 0 and facilities in the path from that node to the MS. Conversely, the upstream path refers to the piece of the path through the current node and all other nodes and facilities in the path from that node to the node which performs the cross connect between the incoming and outgoing call paths.
A path cross-connect refers to all the nodal cross-connects and the intervening facilities 3 5 in the path. In contrast, a connection cross-connect refers to the cross-connection between the hlcolllillg call path and the outgoing call path across a single node.

CA 0221988~ 1997-10-30 The use of a public MSC to cross-connect bearer data circuits among MS units for the purpose of building calls has certain disadvantages. For ç~mrl~, the prior art public MSC, due to the prior art centralized ~witcllillg approach, typically has a large domain and controls the cross-cnnnectin~ of MS units in a wide geogr~rllir~l area. By way of çx~mple7 it is not 5 unheard of for an MSC to be located hundreds of miles from a BTS within its domain while bearing the sole responsibility for cross--;u~ i"g through it all calls involving MS units in its domain.
It has been recognized, however, that a large ~c~ccllt~ge, up to 50-75% in some cases, of calls made by an average user typically involves a clestin~tion MS unit located a short 10 ~lict:~nrç away from the caller. In some market, such as remote villages in developing countries or isolated comml~niti~c or f~tories, for example, it has been de.t~rminecl that most calls alre typically made to shops, homes, and f:~ilitiPc within a small radius of the calling unit, with a rather small ~cl~;ell~ge of calls being made over any appreciable distance (over 50 miles).
Consequently, the prior art re4uilclllellt of barkh~niing bearer data ch~nn~lc from MS units all 15 the way back to a public MSC for cross-connection represents a wasteful use of the network bandwidth. This is çsreci~lly true when an MS unit, which is located some distance away from the prior art public MSC, wishes to call a clestin~tion MS unit located nearby, which destination MS unit is also in the domain of the same public MSC. In this case, the prior art disadvantageously requires the bearer data paths to be b~t~kh~nl~l all the way back to the central 20 public MSC for cross-cnnn~ctic~n- Because of the prior art ccntr~li7tocl ~witcl-illg ~p~,oacll, which cçntr~li7--c the connectiQn cross-connect function at the public MSC, the number of calls that can be handled by the prior art network is n-~cecc~rily limited by the number of calls that can be cross-connected simnlt~n~.ously by the prior art central ~wil(;hillg public MSC and by the capacity of the f~cilitiec to that MSC.
Further, current imr]ern.~.nt~tions of MS units may send and receive data at dirrclcnt rates, say 8 Kbits, 16 Kbits or even 32 Kbits. As is well known to those of skill in the art, the bandwidth and voice or data encoding of MS units that co.. ~ic~t~ at dirr~;lcllt rates must be harmonized before their call paths can be cross-cnnn~-cte~l Fullhcllllore, current implem.ont~tions of the public network, whether Public Switched Telephonl- Network (PSTN) 30 or Public Land-based Mobile Network (PLMN), typically send and receive time division mnltirl~xed data (TDM) at a fixed rate, say 64 Kbits. To accomplish end-to-end conn~-ctinn cross-connect, the prior art GSM system pelÇc,lllls rate conversions (typically using a Transcoder Rate Adapter Unit, hence the name TRAU) on data from all MS units, whether or not they cn.~.. -ic:lte at the same or dirrcl.,l-t rates, by converting them to 64k bits. After the 3 5 conversion, the 64 Kbits TDM data may be b~cl~h~ cl to the public MSC, using the network resources, for cross-connection therein.

CA 0221988~ 1997-10-30 It is known that TRAUing to perform rate conversions degrades co.. l.. ir~tion quality and increases the network c(....~ ion~l overhead. As mentioned before, TRAUing is pe~fu~ ed in the prior art on data from and to MS units regardless whether they c~.. ic~te at the same or dirrt;.c~ilt rates. It is recognized, however, that ~ignifir~nt illl~)lUVC~lllen~ on 5 co..,....-..ir~ti~ n quality and o~l;lll;~.;llg of network colllL,uLdLional resources may be achieved when nnnçcçsc~ry TRAUing, e.g. for calls between MS units that comm--nir~te at the same rate, can be eliminzltr.fl Consequently, what is desired is a method and aL~a,dtus for reducing the amount of b~rkh~nling required in the prior art cellular commlmir:ltion system for cross-connecting call 10 paths. In accordance with one aspect of the present invention, the inventive a~a.~us and method intelligently ~letermin~s an oL~li...u--- end-to-end c-)nnrction and preferably accomplishes connection cross-connects of call paths at downstream nodes, i.e. lower levels in the network hierarchy, thereby reducing the distance by which data from MS units must be carried for completing the end-to-end cross-connection. In accordance with a further aspect of 15 the present invention, the inventive appa dLus and method preferably eli...i.~;.lrc nnn~crSS~ry usage of resources, such as TRAU, for the completion of end-to-end connections when those resources are not needed. When those Icsou~ues are required, however, the inventive ~ ~dtUS
and method preferably switches them in as n.-eçc~:~ry at ~L,.u~..ate locations along the optimum end-to-end c(--~ ul;on in order to ~.u~e.ly complete the connection between MS
2 0 units.
SUMMARY OF THE INVENTION
The present invention relates to, in one embodiment, a method of cross-connecting an end-to-end connrction between an origination mobile station and a destin~tion mobile station in a system having a plurality of cross-connect nodes for f~rilit~ting cellular comm-mication 2 5 among a plurality of mobile stations.
The method inrln~lrc receiving call control information from the origin~tion mobile station, receiving call control information from the destin:lti~n mobile station, and co.ll~uling, responsive to the call control information received from the origin~tir/n mobile station and the call control information received from the ~lectin~tion mobile station, an optimum end-to-end 3 0 connection for cross-connPcting the end-to-end c- nnrcti~ n.
Further, the optimum end-to-end connection has a first optimum cross connect point and l~lesent~ a co---puL~d shortest cr,mmlmication route between the r~rigin~tir,n mobile station and the destin~tion mobile station that satisfies resource requirements for cross-connecting the end-to-end connection The method further inrlnries the step of cross-3 5 connreting the end-to-end connection through the first u~li...u... cross-connect point.

CA 0221988~ 1997-10-30 WO 96/35311 PCI~/US96/06314 In another embodiment, the invention relates to an a~dldLus for cross-connecting an end-to-end cu~ ion bcLween an ori~inAtion mobile station and a ~l~stinAtion mobile station in a network of cross-connect nodes, which inrlll~lec a call control circuit.
The call control circuit in~]nrl~-s a first circuit portion for receiving call control 5 information from the (~ri~inAtion mobile station and the destinAtion mobile station and a second circuit portion for dt;lr..llli~ g, responsive to receiving the call control information from the ~riginAtion mobile station and the destinAtion mobile station, an Vl~illllllll end-to-end ~;v"~ ;Lion for cross-conn~-cting the end-to-end connection through the network of cross-connect nodes. Further, the O~J~illlUlll end-to-end cu~ inn represents a co.ll~u~d shortest 10 cv''''''''~ Ation route between the originAtion mobile station and the ~l~stinAtinn mobile station that sAti~fi~c resource re4uhl;lllt;"L~ for cross-c~nn~cting the end-to-end connection.

In yet another embodiment, the invention relates to an a~l~ald~us for f~ilit-Atin~ ce]lular comml-nication b~weell an r~tiginAtion mobile station and a desrinAtion mobile station, which 15 inr l~ldl-s a mobile services :,wiLcl..llg center, the mobile services center having a first switching circuit for ~ilrollllhlg conn~ction cross-connects for calls between the ~riginAti~n mobile station and the (l~.stin~Ation mobile station.
The ~p~us further in( lu~l~oc a call control circuit coupled to the mobile services ~wi~clli~lg center, the call control circuit receiving call control information from the originAtion 20 mobile station and the ~ A~ion mobile station. Moreover, the ~pA d~US in~ s a base station controller coupled to the mobile services ~wi~chillg center, the base station controller having a second ~wi~cllillg circuit for ~e~Ço..~ ing conn.oction cross-connects for calls between the originAtion mobile station and the de~tinAtic n rnobile station.
Furthermore, there is in-lnded a base transceiver station coupled to the base station 25 controller, the base transceiver station having a third ~wi~chh.g circuit for pe-rvll-lillg conn.oction cross-connects for calls between the nrigin~Ation mobile station and the d~stin~Ation mobile station, wherein the call conbrol circuit dett-rrnin. c, responsive to the call control information received from the nriginAtion mobile station and the d.octinAtion mobile station, at which of the mobile services ~wi~cl hlg center, base station controller, and base transceiver 3 0 station an u~Lhllulll cross connect point for cross-c- nnPcting an end-to-end connection between the ~rigin~Ation mobile station and the dt-stinAtion mobile station resides.

These and other features of the present invention will be presented in more detail in the following specific-Atinn of the invention, the figures, and the appended claims.

CA 0221988~ 1997-10-30 BRIEF DESCRIPTION OF THE DRAWINGS
Additional advantages of the invention will become ap~ upon reading the following detailed description and upon reference to the drawings, in which:
Fig. 1 shows in a simplified format a traditional GSM cellular col l ll l .l .. l i- :-tion network 5 including a public MSC, a plurality of BSC's, and a plurality of BTS's;
Fig. 2A shows in a simplified format the MM sessions and the possible end-to-endconnections in accol-lanct; with one aspect of the present invention;
Figs. 2B shows in a high level flowchart format the steps involved in performing the int-~.lligent Cross-cnnnl~-cting in accordance with one aspect of the present invention;
Fig. 2C shows in a .cimrlifi~-cl format the steps involved in p~lrull~fi-lg the end-to-end connection step of block 408 of Fig. 2B;
Fig. 2D shows in a ~imrlifiçd format the steps involved in cross-connecting the end-to-end connection through an OCP that is not an MSC;
Fig. 3A shows in a simplified format various steps taken by the call control (CC) circuit 15 within the controlling MSC to direct the call setup in accordance with one aspect of the intelligent switch of the present invention;
Fig. 3B is a continuation of Fig. 3A;
Fig. 4A shows in a ~imrlified flowchart format the steps taken by nodes other than the controlling MSC to effect the ~ trihllt~l int~.lligenf e. that f~nilit~tP the connection cross-connect 2 0 between the incoming and the outgoing paths at a lower level cross-connect node in the private network hierarchy;
Fig. 4B is a continl-~tion of Fig. 4A;
Fig. 4C is also a continuation of Fig. 4A;
Fig. 5 shows in a ~imrlifiecl flowchart format the steps taken by the controlling MSC in 2 5 c~lnlll~lting the optimal cross-connect point (OCP);
Fig. 6 shows in a simplified flowchart format the steps involved in using the optimal end-to-end connection discovered to pick the OCP;
Fig. 7 shows in a simplified format the steps involved in p~lrulll~ing the end-to-end connection cross-connect;

~ ig. 8 shows in a simplified flowchan format t'ne steps involved in ~elrc.lllul,g a connrctiQn cross-connect between the incoming and outgoing paths;
Fig. 9 shows in a simplified flowchart forrnat the steps involved in building both the incoming and outgoing paths from a node to an u~ .lGal~ node;
Fig. 10 shows in a simrlified format the steps involved in I~GIrulll~ing the connection cross-connect across an OCP; and Fig. 11 shows in a simplified forrnat the steps involved in cross-connecting a call path.

DESCRIPTION OF THE PREFERRED EMBODIMENT
Fig. 2A shows in a simplifled forrnat the MM sessions and the possible end-to-end connections in accordance with one aspect of the present invention. Referring now to Fig. ZA, there is shown a plurality of MS units 300, 302, 3C)4, 306, 308, 310, 312, and 314. The eight MS units shown lc~csent only a small subset of the MS units that may be controlled by MSC' s 320, 322, and 324. MSC' s 320, 322, and 324 are shown in Fig. 2A to 'oe hllGIcl~llnected in a network of MSC's although such is not a requirement, and in accul-lallce with one aspect of the present invention, the present inventive method and dl)p~dLUS works equa'lly well with a standalone MSC subnetwork. In one embodiment, each of MSC's 320, 322, and 324 may represent a private MSC for irnpl~m~ntin~ a private cellular network. For further inforrnation regarding private cellular nGLwc"h~s"efe,~l1ce may be made to a commonly 2 0 ~scignP~l, co-pending patent apr)lic~tion entitled "Cellular Private Branch Exchanges" (Attorney Docket No. WAVEP001.P) filed as an intt~ tion~l application under the PCT in the U.S.
receiving office on May 3, 1996 and incu,lJo,dLGd herein by reference for all purposes.
In Fig. 2A, MSC 320 is further shown controlling two BSC's 326 and 328. BSC 326 in turn controls three BTS's 330, 332, and 334. BTS 330 controls MS units 300 and 302 2 5 while BTS unit 334 controls MS unit 304.
BSC 328 controls BTS 338, which in turn controls MS units 306 and 308. MSC 322 controls a BSC 340, which in turns control a BTS 342. Further, as shown in Fig. 2A, BTS
342 contrûls MS unit 310. MSC 324 is shown to be in control of base station subsystem (BSS) units 344 and 346. In accordance with one aspect of the present invention, e~h ûf the 3 0 BTS, BSC, BSS, and MSC sub~.y~.Le1lls ~G~IGSG~It a cross-connect node, potentially capable of pGlrolll-hlg either the path cross-connect task or the connection cross-connect task.
A base station subsystem, such as BSS 344, incl~ s one BSC and all the BTS's that it controls. BSS 344 controls MS unit 312 while BSS 346 controls MS unit 314 as shown in CA 0221988~ lss7-l0-30 Fig. 2A. When MS unit 300 wishes to call MS unit 302, the mobility m~n~gemt?nt (MM) session is plcfcl~bly built all the way to the MSC that controls it, i.e. MSC 320. The MM
session between MS unit 300 and MSC unit 320 is shown lcpl'cscl~ ely by a dashed line 350. Once MSC 320 receives the c~estin~tion phone number supplied by MS unit 300, it builds S an MM session all the way to the ~l~stin~tion phone, i.e. MS unit 302, via BSC 326 and BTS
330. The MM session from MSC 320 and MS unit 302 is shown representatively by dashed line 352.
However, in accordance with one aspect of the present invention, the connection cross-connect between the outgoing path (from MS unit 300) and the incoming path (to MS unit 302) 1 0 is cross-connected at BTS 330, which is a lower level in the hierarchy than MSC 320.
Similarly, calls from MS unit 300 to MS unit 304 have their call paths cross-connected at BSC
326, representing a connection cross-connect node which is lower in the hierarchy than MSC
320 although the MM sessions to and from these MS units are preferably built all the way to MSC 320.
1 5 For the sake of discussion, assume that MS unit 306 and MS unit 308 commnni~t~ at dirrclcll~ rates. Further, assume for the purpose of discussion that the rate conversion resources are not available at BTS unit 338. Instead, they are provided at BSC unit 328. In this case, the MM sessions to and from MS units 306 and 308 are still preferably built all the way to the MSC that controls them, i.e. MSC 320. In a~colddllce with one aspect of the invention, 20 however, the actual cross-connection between the incoming path and the outgoing path is not made along the shortest end-to-end connection (e.g. connection cross-connect via BTS 338).
Instead the present invention, in one embodiment, preferably cross-connects the incoming and the outgoing call paths at a cross-c-)nnecti-)n node where the resources are available, i.e. at BSC
328.
MSC 320 and MSC 322 are hltclc~-~n~-ctec~ in a multi-site overlay network. When an MS unit 300 wishes to call MS unit 310, it builds an MM session to MSC 320 via the aforementioned path 350. MSC 320 then forwards the call information to MSC 322,1 n~hling MSC 322 to build an MM session to MS unit 310 via a path 360. The actual cross-connect between the incoming path and the outgoing path is now made via MSC 320 and MSC 322.
3 0 In accordance with one aspect of the present invention, the int~llig~nt switching apparatus and method of the present invention applies to both the hierarchical network as well as the mesh-type network. Consider, for example, BSS 344 and BSS 346. BSS 344 iscoupled to BSS 346 via a link 362. When an MS unit 312 wishes to call MS unit 314, the MM
session from MS unit 312 is again preferably built all the way to the MSC unit that controls it, 3 5 i.e. MSC 324 (via path 366). MSC 324, responsive to the telephone number supplied by MS
unit 312, then builds an MM session to MS unit 314 via path 368. However, if resources are available, the actual cross-connection between the incoming path and the outgoing path between CA 0221988~ 1997-10-30 MS units 312 and 314 may be made not through MSC 324 but via BSS 344 and BSS 346using a path 370 as shown. In this manner, cross-connection between the incoming and outgoing call paths at a lower level of the hierarchy may be accomrli~h~cl in a mesh-type network. It should be noted that the present invention, in accordance with a preferred aspect, S advantageously f~rilit~tPc intPIligent cross-connection whether the mesh-type network is formed via direct connections among MSC's, among BSC's, or among BTS's.
It should be noted that although the terms MSC, BSC, BTS, and BSS are used herein to describe functional blocks of the present invention for ease of reading for those of skill in the art to whom this invention disclosure most nearly pertains, those terms do not connote the 10 MSC, BSC, BTS, and BSS respectively of the prior art. By way of example, each of the MSC, BSC, and BTS of the present invention, unlike the prior art, inclnrlPs ch~ ly which is capable of ~e~r~,l.l..,lg a connrctinn cross connect between the inco~ning path and the outgoing path of a call. This aspect of the invention is discussed extensively in, for example, the afolc:lllelltioned co-pending patent application entitled "Cellular Private Branch Exchanges" (Attorney Docket 15 Number WAVEPOOl.P) and "Cellular Base stati~Dn with Tntrlligent Call Routing" filed as a U.S. patent application in the U.S. PTO on May 4, 1995, S/N 08/434,598, Attorney's Docket No: A-61115 (hereinafter U.S. StN 08t434,598)., which are incc,l~o.~t~d herein by reference for all purposes. As a further exarnple, each of the MSC, BSC, and BTS of the present invention, unlike the prior art, may include certain resources which may be required for 20 properly cross-ct-nnrcting some calls, e.g. TRAU resources, echo c~nreling, and the like.
These resources, when available, may be switched in when required to f~rilh~te calls between MS units that require them for a proper completion of the end-to-end connPction Moreover, it should be noted that these terrns do not connote a physical entity. Rather, each describes a functional block. In one embodirnent, the functional block making up each of 25 the MSC, BSC, and BTS is formed by prul)elly populating a highly configurable chassis with various circuit "c,arcls." For further details regarding the inventive configurable chassis, reference may be made to, for example, the above-mPntinnrd co-pending patent application entitled "Cellular Private Branch Exchanges" (Attorney Docket Number WAVEPOOl.P).
In accordance with one aspect of the invention, some or all of the cross-connect nodes, 30 i.e. the functional blocks referred to herein as MSC, BSC, and BTS, may be provided with resources, e.g. rate adaptation, echo r~nreling, ;md the like. Since resources are distributed among the nodes of the inventive network, it is possible to complete an end-to-end connrction bt;lw~en two MS units using only nodes at lower levels of the network hierarchy while still satisfying any resource re~luhc;l~ ts. Rate ad,aptation (TRAU) resources may be required 3 ~ when, for example, a 8 Kbps MS unit desires to establish commnnir~tion with a 16 Kbps MS
unit. In this example, the present invention advantageously perrnits sub-64 Kbps switching at lower levels, i.e. without utili7ing the MSC, if there is a 8 Kbps - 16 Kbps TRAU resource at a CA 0221988~ 1997-10-30 lower level of the neLwl~lh hierarchy. In this manner, bearer data paths do not always have to be barkh~--l.od to the MSC for the purpose of cr~mrleting the end-to-end cross-connection.
It should be noted that ~Ithol~gh resources are distributed, it is not required that there must be resources at every node of the network, or that the resources at nodes that have them 5 must be irlenti(~l The present invention can still perform its intelligent cross-connection aspect while p~ll iuillg the network ~ L,dtol to distribute resources any desired manner. As will be ~liccucced later, the intelligent switching aspect of the present invention dyn~mirzllly selects, in one embo-limrnt, the optimum end-to-end cross-connection for any two MS units wishing to çst~hlich cnmmllnic~tion based on, among others, 1) the topology data, e.g. the nodes 10 available as well as the resources on e~h node, (2) the coll''''''''ic~tion cha~ L~ irs of each MS unit, e.g. its commnnir~ti~ n rate, and (3) the type of call, e.g. data, voice, fax, or the like.
The intt-lligt?nt switching aspect further dyn~mi~lly modifies the co,ll~,uL~d optimum end-to-end cross-connection if, for exampe, it turns out that the topology data is erroneous in order to attempt to cross-connect the MS units in the most (J~tilllUlll manner givent the resources that 15 are actually available.
Further, the f~t that the present invention permits sub-64 Kbps ~wil~;llillg advantageously reduces the amount of TRAUing that must be done when MS units commnnir~t~. with one another. When two MS units having the same col~r~n~ication rate, e.g.
8 Kbps - 8 Kbps, 16 Kbps - 16 Kbps, or 32 Kbps - 32 Kbps, co~ ir:~t~ with one another, 20 TRAUing is advantageously omitted in one embodiment. In this case, resources at nodes through which the end-to-end connrctiQn Lldv~.~es are simply not utilized or switched in. On the other hand, when two MS units having dirr~ t col""~ ir:ltion rates, e.g. 8 Kbps - 16 Kbps, 8 Kbps - 32 Kbps, 16 Kbps - 32 Kbps, wish to establish co~ l'''ir~tion with one another, the present invention advantageously avoids a rate a(l~rt:ltit)n to 64 Kbps. For 25 example, when a 8 Kbps MS unit wishes to cnmmnnir~tr with a 16 Kbps MS unit, one embodiment provides direct TRAUing from 8 Kbps - 16 Kbps without requiring an int~rmr~ tt~ 64 Kbps TRAUing step. In other words, it is not n~cess~ry to require TRAUing from 8 Kbps - 64 Kbps - 16 Kbps In this manner, the present invention advantageously reduces the amount of TRAUing that must be done when calls are cross-cnnn~ct~rl thereby 3 0 reducing the overhead associated with TRAUing while improving c-,l"""~,ic~tion quality.
It should be noted that this disclosure (lescrih~c in detail the intt-llig~nt switching required to accomplish call setup (CC). However, the technique rlesrrihed herein also applies to ~wiLchillg functions associated with SS services. By way of example, short message service (SMS) and suppl~mlontzll service (SS) requests are still handled by the MSC in one 3 5 embodiment and conveyed over the MM session between the hzln-lcetc the MSC.

CA 0221988~ 1997-10-30 WO 9613~i311 PCTJUS96/06314 As a further çx~mrlf~, tn,ese services somPtimf ~ just require mf ss~ging across the MM
session such as the delivery of a SMS short message. In this case the MSC handles th,e mf.~cs~ging over the MM session in the manner typic;ally performed in a cellular network.
Often, SS services require that the end-to-encl connection be rebuilt such as when a caU
5 is to be forwarded or a three-way co.lr~,~el,ee bridge is to be built. The techniques .If ccri't)ed in this disclosure apply to building these connections as well. Further, the MSC ~e.rol..ls call clearing function of any path rendered llnnf cecs~ry 'oy, for example, a forwarding action.
In some cases, a connection already made ilnternal to the mobile network may need to be rerouted through to an external netwu.~, as in the case when a call is forwarded to the public network, or when an intfrn:ltinrl~l handover occurs. In this case, the MSC builds the corlnf.ction to itself before procee-ling in the manner typically performed in a cellular nelw~lk in setting up the connection with the external networl;. Furthermore, it is also possible that the service requests simply modify the current c~mnf ction such as call hold or mute. In these cases, the MSC simply directs the proper cross-cormect node of the mobile network to handl,e 1 5 the morlific~tion Figs. 2B, 2C and 2D show in a high level flowchart format the steps involved in ~elrulll~llg insf lligf nt cross-c-~nnf cting in accordan,ce with one aspect of the present invention.
The blocks of Figs. 2B, 2C, and 2D are described in a high level manner, the details of which should be apparent upon a review of the rem~ining figures of the present disclosure. Fig. 2B
2 0 starts at block 400. From block 400, the method proceeds to block 402 whelt;ill the controlling MSC, e.g. the MSC associated with the cal~ing or ~rigin~tion MS unit, receives from the origination MS unit call control h~follllalion that i~dentifies itself and the resources it needs for communication. From block 402, the method proceeds to block 404 wherein the controlling MSC receives from the ~lçstin~ltion MS unit call control information that itlf-ntifif s the 2 5 destination MS unit and the resources it needs for comml-ni~ting with the ~rigin~tion MS unit.
From block 404, the method proceeds to step 406 wherein the controlling MSC utilizes the call control information received from the ~rigin~tion MS unit and the l1estin~tion MS unit to c~ tf the ~Lhllulll cross-connect point (C)CP) in the network. From block 406, the method proceeds to block 408 wherein the nodes of the network are utilized to build the end-to-3 0 end connf cfion between the origination and the riestin~tion MS units. As will be ~ cucce~i later in connection with Figs. 3A,3B, 4A, 4B, and 4C, the end-to-end connf ction preferably, but not n.ocçc~rily, utilizes the OCP clf tf~~minf cl in block 406 to cross connect the incoming and the outgoing paths.
From block 408, the method proceeds to block 410 where the steps of Fig. 2B end. At 3 ~ block 408, the end-to-end conn~ction between t'he MS unit is either s~lccec~fully made or the method has failed to establish the desired col~ne~;l.ion.

CA 0221988~ 1997-10-30 W O 96/35311 PCTrUS96/06314 Fig. 2C shows in a cimplifi~rl format the steps involved in p~lrc)ll~ g the end-to-end c~ ioll step of block 408 of Fig. 2B. Fig. 2C starts at block 412. From block 412, the method proceeds to block 414 wherein the method ascertains whether the MSC itself is the ~lecign~t~d OCP (as c~lrul~t~cl in block 406). If the MSC itself is the OCP (as detennin~d in Sblock 414), the method proceeds to block 416 wherein the end-to-end conn~ctil)n is cross-connected using the MSC as the OCP. However, if the MSC itself is not the clecign~t~d OCP
(as ~let~rmin~d in block 414), the method proceeds to block 418 wherein the method performs the end-to-end c--nnPction cross-connect using a dirr~ lt node as OCP (as dt:tc~lllhled from the information from the origin~tion and the ~lPstin~tion MS units). In block 418, the method 1 0~ L~, as will be t-~pl~in-orl later in greater details in connection with Figs. 4A,4B, and 4C, to use the ~ cign~t~d OCP as the site at which the connection cross-connect belw~ll the incoming and outgoing paths is pell~l,lled. From either blocks 416 or block 418, the method proceeds to block 420 wherein the steps of Fig. 2C end.
Fig. 2D shows in a simplified format the steps involved in cross-connecting the end-to-1 5end connection through an OCP that is not an MSC. Fig. 2D starts at block 430. From block 430, the method proceeds to block 432 wherein the method checks wh~lllel the ~l~cign~t~d OCP has all the required resources (e.g. TRAU, echo c~n~.oling, and the like) on node to properly complete the end-to-end c~-nn~ctil~n- If there are snfficient resources on node, the method proceeds to block 434 wherein the end-to-end co~n~ction is cross-cnnn~ct~d between 20the ~rigin~tion MS unit and the ~stin~tinn MS unit using the resources of the rll~ci~n~t~cl OCP.
From block 434, the method proceeds to block 436 where the steps of Fig. 2D end.
On the other hand, if it is determin~cl that the rl( cignzlt~cl OCP has incnffici~nt resources on node to properly complete the end-to-end connt~ction, the method proceeds from block 432 to block 438 wherein the method ciet~rrnin~oc whether there are s-lfficient resources at 2 5downstream nodes (both the incoming and the outgoing paths) to properly complete the end-to-end connection. If the use of resources found downstream satisfies the resource requirement of the end-to-end connection, the method proceeds from block 438 to block 440 wherein the end-to-end conntoction is cross-connlocte~l using the resources found at downstream nodes to satisfy the resource requi~ of the end-to-end col~l-P~Iion. In block 440, the cross-connection 30between the incoming and the outgoing paths is preferably perform through the decign~t~d OCP. From block 440, the method proceeds to block 436 where the steps of Fig. 2D end.
If the use of resources found downstream fails to satisfy the resource requirement of the end-to-end connection, the method connects upward from the OCP to a node upstream of it in order to attempt to find resources there to complete the end-to-end connection. In this case, 3 5the method proceeds to block from block 438 to block 442 wherein the upstream node is now ~l~cign~t~d the OCP.

CA 022l988~ l997-lO-30 WO 96~3~i311 PCT/US96/06314 If there are resources at this u~ anl node (alone or in combination with nodes downstream of it in the end-to-end connection route), the method proceeds from block 444 to block 446 to perform tlhe end-to-end connection through the newly ~ n~ttod OCP, using resources of that OCP to satisfy the resource 1~4uil~:lllent of the end-to-end connection. From block 446, the method proceeds to block 436 wherein, as mentioned earlier, the steps of Fig.
2D end.
If it is detennin~d in block ~'11 that the use of resources at the newly deci~n~t~d OCP
still does not satisfy the resource requirements of the end-to-end connection, the method will attempt to find resources at even more upstream node. In this case, the method proceeds to 1 0 block 445 wherein the method ~l.ot.orrnin~s if an ~ l,eall~ node exists. If there exists an upstream node, the method proceeds to block 442 to check for resources on that node. If the check in block 445 fails, e.g. when the MSC is the current OCP, the method proceeds to block 448 wherein the connection is cleared. At block 448, the attempt to complete the end-to-end connection cross-connect has failed. Following tlhe clearing of the conn~oction, the method 1 5 proceeds to block 436 where, as mentioned earlier, the steps of Fig. 2D end.
Figs. 3-l l show in greater details the steps involved in the int~ llig~nt cross-connf cring technique in accol.l;~lc~ with one aspect of the present invention. Figs. 3A-B show in a simplified format various steps taken by the call control (CC) circuit within the controlling MSC to direct the call setup in acconlallce with one aspect of the int~-lli~ent switch of the present invention. Fig. 3A starts at block 500. From block 500, the Initial Address Message (IAM) may be received in either block 502 from eilher outside of the private network, from the MM circuit for calls ori~in~tin~ locally, or in block 503 from another MSC within the private network. In block 502, the Initial Address Message (IAM) is received from a telephone set in the public network. The IAM may also come in from an MS unit locally controlled by this MSC. From step 502, the method proceeds to step 504 to route the call to the ~lu~lestin~tion phone set.
In one embodiment, step 504 involves ~he CC function in the MSC de~ inhlg whether the destin~tion for the call is an MS unit in the private network. If it is deterrnin~ ~1 that the ~ stin~tion for the call is an MS unit in the plivate network, the CC function in the MSC
3 0 then sends tne private HLR/VLR registry a locate request. By sending the locate request to the HLR/VLR registry, the CC function in the MS( takes the dialed phone number, which it receives in block 502, and consults the HLR/VLR registry for the location of the dc.stin:-tion MS unit. The HLR/VLR registry then sends a L,ocate Response message to the MSC which pinpoints the location of the destin~tion MS unit. The det.Qrmin~tion of the location of the 3 5 destination MS unit is illlpoll~lt in, for e~c~mrle, a multi-site/overlay private network wherein mtlltiple MSC's may be hlL~;renln~t--cted and ~/[S units may roam among location areas controlled by the interconnected MSC's.

CA 0221988~ 1997-10-30 W O96/35311 PCTrUS96/06314 In block 506, the method tl~lr,l Illill~S whether both the incoming and the outgoing paths are internal to the private network. If either the incoming or the outgoing path ~ermin~trc at a telephone set that is external to the private network, e.g., in the public net, the method proceeds to block 508 to t~"lli~ the call at the a~plupliate external rlestinz~tion phone set. When the S call is b~Lw~ the external network and an internal MS unit, the CC circuit within the MSC
~;r~;lal~ly ~elrulllls no intelligent cross-connection and simply allows the call to pass through.
In one embodiment, however, the CC circuit within the MSC may switch in the nrcf cc7,ry resources (e.g. TRAU, packet servers for data calls, or the like) for p~.llll;llillg the call to proceed. For further information regarding call trrmin~tion, reference may be made to the 10 aforementioned co-pending "Cellular Private Branch Exchanges" patent applir~ti- n (Attorney Docket No. WAVEP001.P) and the GSM references of Appendix B of the present disclosure, all of which are incol~Ju-d~ed by ~;ferellce herein for all purposes.
On the other hand, if both the incoming and t'ne outgoing call paths are internal to the private network, the method proceeds to block 510 wherein an Initial Address Message (IAM
15 ') with deferred :lccignmrnt is sent from the CC circuit within the MSC that receives the IAM
message in block 502 to the ~ stin~tion MSC associated with the incoming call (where the destin~tion MS unit is located). In block 510, the ~lf stin~ti~n MSC may be the MSC that receives the IAM message in block 502 (if it is rleterminr-l in block 504 that the ~iPstin~ti~n MS
unit is located in the location area controlled by that MSC). However, the rlr.5tin~tinn MSC in 2 0 block 510 may also be another MSC in the private network where the destin~tion MS unit has roamed to. Viewed another way, the destin:-tion MSC may be the sarne as the MSC that receives the IAM message in block 502 or another MSC in the private network.
The actual ~ccignmrnt of bearer data channel may be deferred until more inft-rm~ti-~n is received regarding the destin~tion phone and the a nnrction path thereto (e.g. what resources 25 are required). Instead of ~ccigning bearer data channel resources early on in the cign~ling (MM) session, the ~ccignmrnt of the bearer data channel is deferred, in one embodiment, until it is ascellailled that there is a phone at the ~ 5tin~tion and it can be ringed. Deferred ~ccignmrnt is optional and represents a method to saves resources of the network and to improve its bandwidth if the rlrstinz~tion MS unit happens to be turned off or when a bad 30 number is dialed. The Initial Address Message sent in block 510 iS an IAM ' message, indicating that this message is an on-net type of message. The IAM ' message is different from the standard GSM IAM message in that it in~ flrc additional information to f;~rilit~rt- intelligent cross-connection. For example, an IAM ' may include information regarding the nri~in~ting MS unit, e.g. its commnnic~tion rate, the resources it requires for a proper cross-connection, or 3 5 the like.
Block 503 represents the situation where a CC function ~ccori~t~d with a controlling MSC has sent an IAM ' message as described above. The IAM ' message is received in block CA 0221988~ 1997-10-30 WO 9613!i311 ~ PCT/US96/06314 503 by the CC circuit within the neighboring MSC'. The CC circuit within the neighboring MSC that received the IAM ' m~sc~ge in block 503 may be thought of as a forwarder for rulw~dirlg the received IAM ' message in block 503 to the MM circuit associated with it (block 512). Thel~lei, all messages are forwarded h~Lwe~ll the CC circuit within the 5 neighboring MSC that sent the IAM ' message (which is received in block 503) and the MM
circuit where the destin:-ti~n MS unit has roamed to.
At any rate, the ~lestin~tion MM circuit receives the IAM ' message, in either block 510 or block 512 of Fig. 3A. In block 514, the CC function associated with the controlling MSC
waits for the response from the ~lPstin~tion MM circ uit. In block 516, the CC circuit within the 1 0 MSC that sent out the IAM ' in block 510 (and for~arded via a neighboring MSC, e.g., the CC
circuit within the neighboring MSC, if the tl~stin~tion MS unit has roamed away from its home MSC location area as ~liccucsed in blocks 503 and 512) receives from the rlestin~tion MM
circuit, i.e., the MM circuit that directly comml-ni~t~ c with the flestinzltion MS unit, an Address Complete Message (ACM ').
1 5 The ACM ' message signifi~-~ that the ~I~-ctill~tion phone is found. Further, the ACM ' message is an on-net message, which differs from the standard GSM ACM m.oc~ge in that it further contains inforrnation nt-cçcczlry to c~ te in a s--hsequent block 518 the optimum cross-connect point. In one embo~limt-nt~ the ACM ' may include information such as the rate of co",l",l"i~tion of the destination MS unit (the rate of co~.. "ic~tion of the ori~in~tit)n MS
20 unit is cont~int-d in the IAM mesc~Ee received from an on-net MS unit) and any other information regarding the resources that are required to establish c.."",..-..ir~tinn with the origin~ting MS unit, e.g. TRAU, echo c~n~eling, proper packet server resources if the call is a data call, and other inter-working functions (rWF's).
In block 518, the CC circuit within the con,trolling MSC ç~ t~c the o~li"lul,l cross-2 5 connect point (OCP) by first finding the optimum end-to-end comle.;lion given the parameters defined by, among others, the network topology, the information cont:~int-d in the IAM
message received in block 502 and the ACM ' message received in block 516. The optimum cross-connection point det~-rmint~d in block 518 may be the controlling MSC itself, may involve another MSC (for calls bclweell MS unil:s controlled by different MSC's in a private 3 0 network), or, as is often the case, a subsystem at a lower level in the private network hierarchy, e.g. a BSC or a BTS subsystem.
Fig. 3B is a continuation of Fig. 3A. In block 520 of Fig. 3B, the method ~l~tt-rmin~c whether the OCP c~lrul~t~-cl in block 518 is the same as the MSC that receives the IAM
message in block 502, i.e. the controlling MSC. In one embodiment, the clt~lr.llli,~ion in 3 5 block 520 may be as simple as a comparison between the node number of the OCP with the node number of the MSC that receives the IAM rnessage in block 502. If it is, the controlling MSC itself is the O~linlulll cross-connection point, and the method proceeds to block 522 to CA 0221988~ 1997-10-30 execute the ac.cignmrnt that was deferred in block 510 using normal GSM procedures for cross-connection of the incoming and the outgoing call paths at the MSC level. The above mentioned normal GSM procedures are known in the art and reference may be made to, for example, the GSM l~;fe:lCllCeS mentioned herein for ~rltlition~l background information.
5 Tlle~arLei, the method proceeds to block 537, representing the normal call set up. In block 537, the call setup proceeds in a normal fashion.
On the other hand, if the MSC that receives the IAM message in block 502 is not itself the OCP, the method proceeds to delegate the actual task of connection cross-connecting to another cross-connection node, typically dowllw~d toward a subsystem at a lower level of the 1 0 private network hierarchy, e.g. a BSS, a BSC, or a BTS. In block 524, the controlling MSC
that receives the IAM message in block 502 (and as (1r(~.~ " ~i"r~l in block 520 as not the OCP) sends the CROSS-CONNECT REQUEST to the OCP, which is ~lrtrrmined in block 518. At this point, the OCP is no longer the controlling MSC and may represent a subsystem at a lower level in the neLw~lh hierarchy.
1 5 In block 526, the method waits for the cross-connection nodes of the private network, inrllltling the OCP, to attempt to make the end-to-end connection cross-connect. The message returned to the controlling MSC is either a CROSS-CONNECT ACKNOWLEDGE (received from the OCP in block 530), a CROSS-CONNECT PARTIAL (received in block 532 from a downstream OCP that tried to complete the end-to-end connection cross-connect and failed and 20 ~ccigning the controlling MSC as the OCP) or a CROSS-CONNECT REJECT (received in block 534 from an OCP that tried to complete the end-to-end connection cross-connect and failed).
It should be noted that the messages received in blocks 530, 532, and 534 may come from a node in the private network, ~;ull~l~lly ~lecign~t( -l the OCP, that may be different from 25 the node nrigin~lly ~lecign~tt-~ the OCP in block 518. This case happens, for example, when there are incnffiriçnt resources in the nodes of the origin:-lly clçcign~trd optimum end-to-end connPcti~n to properly complete the end-to-end conn~ction. When this happens, a node higher in the private network hierarchy may be used in the cross-comleuLion, and the messages received in blocks 530, 532, and 534 may come therefrom. For a simplified, visual illustration 3 0 of this case, reference may be made to, for cex~ml l~, Fig. 2A and particularly the call between MS units 306 and 308.
A CROSS-CONNECT ACKNOWLEDGE (block 530) in-lir~lrc to the MSC that the connection is succc.ccfully completed. Following the receipt of a CROSS-CONNECT
ACKNOWLEDGE message in block 530, the method proceeds to block 531 to store the 3 5 connl ction result. In one embodiment, the sequence of connection nodes through which the end-to-end connrction traverses and an itlr.ntifirr associating the call with that sequence of nodes for the duration of the call are stored. Storage of both the sequence of nodes l~plr~se~ g CA 0221988~ 1997-10-30 WO 96/3S311 PCr/US96/06314 the end-to-end conn-oction and the i~lentifi~r for the call permits the network to keep track of the end-to-end connection, to relate the MM session to the call path, and to clear the end-to-end conn~ction (or part of it) when the call is ended, eith~er normally or nnl-xpect~lly.
- In block 533, the CC function in the contro]ling MSC sends out an Address Complete 5 Message (ACM), ~ ollsiv~; to a received ACM' mLessage in block 516, to the MM circuit that controls the nriginz3ti-)n MS unit, acknowledging that the complete telerhon~ number dialed has been received and that a successful cross-connect has been pclr~ ed. Thereafter, the method proceeds to block 537, repr~sçntin~ the normal call set up.
A CROSS-CONNECT PARTIAL message (block 532) in~ trc that the proper 10 resources were not available at nodes downstream from the controlling MSC to complete the end-to-end conn~ctic~n. This situation may occur since the topology information known to the routing agent, e.g. the CC circuit of the controlling MSC that determines the optimum end-to-end connection in block 518, may be dirÇclcilt from the actual state of the system. By way of example, a required TRAU resource that the routing agent thought exists on a node may in 15 reality be dcrc(;Livc or removed ~lt~gçth~r since information regarding that resource was last updated in the topology inf~rm~tiQn ~l~t:lbace. As .mother ~ mple, haldwale/software failures of some resources may not have been timely updated with the topology inforrnation ~ t~hz~ce, thereby causing the routing agent to specify an o~lilllulll end-to-end ct)nnection that in reality is unrealizable.
As will be seen in Figs. 4A, 4B, and 4C, an OCP will try to get resources from downstream nodes in the outgoing and incoming paths to properly complete the end-to-end co~ e~;Lion if resources are not available right at that OCP node. If there are incnfficirnt resources at both that OCP node and at nodes downstream from it in the outgoing and incoming paths, that OCP will try to use resources of a node upstream from it to complete the end-to-end conn~-cti-)n When that OCP signals lo the upstream node that it needs to use the resources of the upstream node to comrl~-te the end-to-end connection, it sends a CROSS-CONNECT PARTIAL message to the upstream node. The upstream node then becomes thenew OCP. In some cases, the upstream node m'ay not have the required resources and must try to find resources at a still more upstream node. The process may continue if resources continue to be unavailable until the u~Llealll node is the MSC itself. When this happens, all nodes below the MSC has failed to find the required resources to complete the end-to-end connection, and the MSC, using its resources, represents the last chance to complete the connection.
In block 535, the controlling MSC itself ~u~ to complete the end-to-end connection 3 5 cross-connect using the resources available to it. If the end-to-end connrctinn cross-connect attempt is successful (as ~ termin~tl in block 536) the method proceeds to block 531 to store the results and then to block 533 to send out the ACM message to the MSC in the manner -CA 0221988~ 1997-10-30 ~iccncced earlier. On the other hand, if the end-to-end connection cross-connect is nn.cllrceccfill (as ~lel~.. ",i,~l~d in block 536), the method proceeds to block 538 wherein the MM
sessions associated with both the origination MS unit and the destin~tion MS unit are cleared.
In block 538, the call has failed.
S In block 534, a CROSS-CONNECT REJECT message inflir~t~c to the controlling MSC that there has been a total failure of cross-connection. A cross-connect reject situation may occur when, due to events beyond the control of the nelwvlk~ the end-to-end connection is simply unrçSIli7:~hlt-. F~mples include unavailable bandwidth at one of the cross-connect nodes along the end-to-end connection, hardware or software failures, or unavailability of 1 0 resources. From block 534, the method proceeds to block 538 wherein the cnnn~ction is cleared ac described above.
Figs. 4A, 4B, and 4C, which are cn"l;"n;~ ns of one another, show in a cimplifi~d flowchart format the steps taken by nodes other than the controlling MSC, i.e. one that det~rrnin.-s the u~lilllulll end-to-end connection in Fig. 3A, to effect the distributed int~llig~.nre 1 5 that f~rilit:lt~ the connection cross-connect between the incoming and the outgoing paths at a lower level cross-connect node in the private network hierarchy. In Figs. 4A, 4B, and 4C, the node ~rigin~lly ~l~cign~tl cl the OCP first tries to use resources available on node to complete the end-to-end conn~ctinn If there are insufficient resources right on node, the nrigin~lly ~l~5igns~ttod OCP will try to get resources from downstream nodes in the outgoing and incoming paths to ~lv~lly complete the end-to-end conn~ction If there are incnfficiP.nt resources at both the origin~lly ~l~cign:~t~d OCP and at nodes downstream from it in the outgoing and incoming paths, the ~lrigin~lly rlecign~t~od OCP will try to use resources of a node upstream from it to complete the end-to-end co,,,,~.li(m When this happens, the end-to-end cross-connection will occur through the node u~Llca ll from the ~rigin~lly ~l~cign~t~d OCP.
Further, the upstream node now represents the OCP where the cross-conn~cting between the incoming path and the outgoing path occurs.
To illustrate, consider the call between MS units 306 and 308 of Fig. 2A. For the purpose of illustrating the present point, assume that the call between MS units 306 and 308 requires rate adaptation from 8 Kbits 16 Kbits. When BTS 338 of Fig. 2A which for the 3 0 purpose of illustrating the present point represents the originally ~ cign~t~d OCP, realizes that it does not have the required 8 Kbits - 16 Kbits TRAU circuit on node to complete the end-to-end connection, it first ~u~;lllL)L~ to look downstream to find this required resource. Since there are no resources downstream in this case, BTS 338, reprçst~.nting the ~rigin~lly clecign~t~d OCP, then ~llelll~ls to find resources at a node upstream, i.e. BSC 328, to complete the connection.
3 5 If there is a 8 Kbits - 16 Kbits TRAU circuit at BSC 328, BSC 328 becomes the new OCP for compl~oting the end-to-end c- nn~ction through which the conn~-ctinn cross-connect between the incoming and outgoing paths occurs.

CA 0221988~ 1997-10-30 In implemlontin~ int~ ent ~wilcl~illg, the procedure shown in Figs. 4A, 4B, and 4C
replaces the sending of the .Accignm~nt Request message to the BSC from the MSC for the both incoming and the outgoing call paths. Fig. 4A starts at block 600 wherein all nodes are idle with respect to cross-conn~cting the voice/data path through their nodes.
Block 606 represents one of the possible messages involved in building the voice/data ~ path. In block 606, it is determin~d that the MSC is the proper point to p~lrc,.lll the connection cross-connect, i.e. bc~Lwet;ll the incoming path and the outgoing path, and that no int~ nt delegation of the cross-connect task to a cross-connect node lower in the private network hierarchy is needed. In blocks 608-610, the normal GSM late ~ccignm~ nt and end-to-end cross-connection is ~elrul-lled. For rx~mplt~7 block 606 receives the late zlccignm~nt request from the CC function in the controlling MSC. The cross-connect of the downstream path in accordance with conventional GSM downstrearn path cross-connect is ~clrulllled at block 608, and the Acknowledge ~Csignm~nt message is sent to the CC circuit ~ccori~ted with the controlling MSC block 610. Tht;~c;ar~-, the method proceeds to block 612 where the nodes are done cross-connecting for the connection.
Block 614 also l~)leSc;lll~ one other possible message involved in the intellig~nt cross-cnnn~-cting process. In block 614, the CROSS-CC)NNECT REQUEST message is l~:ceivt;d by the OCP from the controlling MSC, requesting the OCP to p~lrc,llll the end-to-end connection cross-connect. In block 618, the OCP obtains, if possible, the nPcecs~ry resources on node for p~lrulllli~lg the cross-connect, e.g. TRAU l~suulces and other inter-working functions (IWF's) as ~lu~liate. In block 620 the method ascertains whether the OCP has available on node all the resources required to pelr( lll- the end-to-end cv~ ion cross-connect. In one embodiment, block 620 involves a check of the resources that are available at the OCP. If the required resources are available alt the OCP (as cl~t~ Tnint-cd in block 620) the 2 5 method proceeds to block 622 where the full duple:c cross-connection between the MS units via the OCP (the end-to-end connPction cross-connecl:) is pelru~lled. The end-to-end connt-ction cross-connect between the origin~ti~n MS unit and the ~l~ostin~ti~n MS unit is çxrl~in~d in greater detail in, for example, Fig. 7. If resources are required, the present invention, in accordance with a plefell~d aspect, advantageously switches them in as nl cesc~ry. For further 3 0 information regarding the hlvt;llliv~ switching in of resources when required at cross-connect nodes, reference may be made to, for example, the above-mentioned commonly ~ccign( ~1, co-pending patent application entitled "Cellular Private Branch Fxch~nges" (Attorney Docket No.
WAVEP001.P) and "Cellular Base Station with Tn~.-lligent Call Routing" filed as a U.S. patent application in the U.S. PTO on May 4, 1995, S/N 08/434,598, Attorney's Docket No: A-61115 3 5 (hereinafter U.S. S/N 08/434,598).. Thereafter, the method proceeds to block 624 wherein the OCP sends a CROSS-CONNECT ACKNOWLE,DGE message back to the MSC to indicate that the end-to-end connrction has been successfully cross-connected at the OCP. From block CA 0221988~ 1997 - 10 - 30 624 of Fig. 4A, the method proceeds to block 612 of Fig. 4B where the nodes are done cross-Cr~ g for the conn~cti-m On the other hand, if there are incllffici~nt resources available at the OCP (asdetermined in block 620) the method proceeds to block 630 to ascertain whether there is a 5 cross-connect node downstream (at a lower level in the network hierarchy) in either the incoming or the outgoing call path. In one embodiment, the incoming call path is first checked for availability of downstream nodes. If there are none downstream in the incoming path direction or if those nodes have in.cllffi~i~.nt resources, the method then proceeds to check the outgoing path for availability of nodes and resources. Only when there are in.cllffiri~nt 1 0 resources in the nodes of both the incoming call path and the outgoing call path does the method conclude that there are incllfficitont resources downstream of the OCP to L~ elly complete the end-to-end connection.
If there is a cross-connect node downstream (as deterrninP~ in block 630) the method proceeds to block 632 wherein the OCP requests resources from the cross-connect node 1 5 downstream. The REQUEST RESOURCES message requests the node downstream from the OCP to ascertain whether the required resources are available downstream to complete the required end-to-end connection cross-connect. In block 634, the method waits for the response from the node downstream from the OCP to which it has just sent the REQUEST
RESOURCES message.
Depending on the resources available downstream, one of following three responses may return from the node downstream of the OCP: resources available (RESOURCES
ACK), resources only partially available (RESOURCES PARTIAL) and no resources available (RESOURCES NACK).
In block 636, the method receives, l~pollsive to a REQUEST RESOURCES message 2 5 sent at block 632 (to a downstream node), a RESOURCES ACK message. The RESOURCES ACK message in~ t~c that the required resources for completing the end-to-end connt ction are available at nodes downstream from the node that sends out the REQUEST
RESOURCES message at block 632 and receives the RESOURCES ACK message at block 636.
3 0 From block 636 of Fig. 4A, the method proceeds to block 638 Fig. 4B. The response of the method in subsequent blocks 638-646 of Fig. 4B dc.p~n~lc on what has happened thus far. If the node that sends out the REQUEST RESOURCES message at block 632 and receives the RESOURCES ACK message at block 636 is the same as the node that receives the CROSS-CONNECT REQUEST in block 614, the method, responsive to block 638 proceeds to block 640. On the other hand, if the node that sends out the REQUESTRESOURCES message at block 632 and receives the RESOURCES ACK message at block WO 96135311 PCT/U~IC~14 636 is a node that has responded to a received REQUEST RESOURCES mecclge (block 670), the method proceeds to block 644 from block 1538.
In block 640, the method completes the end-to-end cnnnPction cross-connect by cross-- co,~ g the incoming call path with the outgoimg call path. In one embodiment, if the S incoming and the outgoing paths are not akeacly built, the method further directs the downstream nodes to build them as well. For furlher illro~ aLion regarding the building of incoming and outgoing paths, ,crcltll~c may be made to, for example, Fig. 11. Following block 640, the method proceeds to block 643 where it returns a CROSS-CONNECT ACKm.osc~ge to the controlling MSC. In one embodiment~ the CROSS-CONNECT ACK mec~ge1 0 sent in block 643 may be received in, for ~x~mple, block 530 of Fig. 3B. Further, the method proceeds to block 612 where the steps of Figs. 4A, 4B, and 4C end for this node.
In block 644, however, the method has a~ce~L~ Ied that the node that sends out the REQUEST RESOURCES message at block 632 and receives the RESOURCES ACK
message at block 636 is a downstream node that has responded to a received REQUEST
RESOURCES message (block 670). In this case, the method proceeds from block 638 to block 644 wherein the method cross-connects the downstream path between the MS unit and the f~rilitit-c going to the upstream node that sent it the RESOURCES ACK mrcs~ge.
Thereafter, the method proceeds to block 646 wherein it returns a RESOURCES ACK to the upstream node (which is received in block 636).
As is ~ ;nt, the RESOURCES ACK m~cc~Eeis passed from a downstream node to an u~sl~ea~l~ node and the incoming or outgoing path is cross-connt-ctrd between the d~w~ calll node and the uy~LIc~ node until the u~sLrea~ node is the same as the node that receives the CROSS-CONNECT REQUEST in block 614, sends out the REQUEST
RESOURCES mecc~ge at block 632, and ~cceivcs the RESOURCES ACK message at block 2 5 636. When this happens, the method branches from block 638 to blocks 640 and 643, where the incoming and outgoing paths are cross-c~ ed Logclhcr and a CROSS-CONNECT
ACK mrss~ge is sent to the controlling MSC (which is received in block 530 of Fig. 3B).
Further, the method proceeds to block 612 where the steps of Figs. 4A, 4B, and 4C end for this node.
3 0 In block 642 of Fig. 4A, a node rnay receive, responsive to a REQUEST
RESOURCES message that it sent to a downstream node in block 632, a RESOURCES
PARTIAL mr.cc~g~. The RESOURCES PA]RTIAL mPCC~ge infiir~trs that the required resources are not available at the downstream node. From block 642 of Fig. 4A, the method ~ proceeds to block 648 of Fig. 4B.
3 5 Once again, the response of the method in subsequent blocks 648-659 depends on what has happened thus far. If the node that sends out the REQUEST RESOURCES message at 2]

CA 0221988~ 1997-10-30 WO 96/3~;311 PCTtUS96/06314 block 632 and receives the RESOURCES PARTIAL message at block 642 is the same as the node that receives the CROSS-CONNECT REQUEST in block 614, the method, responsive to bloek 648 proceeds to block 655. On the other hand, if the node that sends out the REQUEST RESOURCES message at block 632 and receives the RESOURCES PARTIAL
5 m~sc~ge at block 642 is a do~l-sllealll node that has responded to a received REQUEST
RESOURCES message (block 670), the method proceeds to block 651 from block 648.
In block 655, the node that sends out the REQUEST RESOURCES message at block 632 and receives the RESOURCES PARTIAL message at block 642 is the same as the node that receives the CROSS-CONNECT REQUEST in block 614, and the method now needs to 10 aseertain that all nodes downstream, both in the incoming path and the outgoing path, have been çhrrLrd for resource availability. Consequently, the method proceeds to block 655 wherein it cletçrminec whether both incoming path and outgoing path have been checked for resouree availability. This ~etrrmin~tion is nrcçcs~ry because at the point where the method branches from block 648 to block 655 for the first time, it is possible that only nodes 15 dowll~kcam of one (not both) of the incoming and the outgoing paths have been ehrckr~l If it is determined in block 655 that there is one more path to check for resource availability, the method branches from block 655 to block 657 wherein, as shown in Fig. 4B, the method begins to check the other path for resource availability. To do so, the method returns, as shown by the action in-lir~trd in block 659, to block 630 where the path that has not 2 0 been çhecke-l hGIGtufulG is cherkrd for resources.
On the other hand, if it is rl~lr.lllil,rd (via block 655) that both the incoming and the outgoing paths have been rhrrked for resource availability, the method proceeds to block 650 wherein it cross-connects both the incoming and the outgoing paths to the llp~l.G~Il node. The upstream node that was cross-connected to in block 650 becomes the new OCP. In this 2 5 manner, the method rlrtPrminrc that downstream nodes in the ~etrrmined optimum end-to-end colllle.;kon have incnffiriçnt resources to properly complete the end-to-end connection and attempts to use resources at an U~IIG~ull node to complete the task.
The method then proceeds to block 653 where it sends out a CROSS-CONNECT
PARTIAL mrss~ge to the upstream node. It should be noted that the upstream node that was 3 0 cross-connected to in block 650 is, up to this point, uninvolved in the building of the end-to-end connection. Now, the upstream node receives the CROSS-CONNECT PARTIAL message inblock 680.
After the incoming and outgoing paths are built to the ~ lGalll node and the CROSS-CONNECT PARTLAL message is sent out, the method proceeds to block 612, where the steps 3 5 of Figs. 4A, 4B, and 4C end for this node.

In block 651, however, the method has a~.ct;~ ed that the node that sends out the REQUEST RESOURCES m~ss~e at block 632 and receives the RESOURCES PARTIAL
mPcs~ge at block 642 is a downstream node that has responded to a received REQUEST
RESOURCES. message (block 670). In this case, the method proceeds from block 648 to 5 block 651 Wh~;lC;ill the method cross-connects the downstream node to an u~ t;all- node.
Thelc~a~L~l, the method proceeds to block 654 wherein it returns a RESOURCES PARTIAL
message to the upstream node (which is received irl block 642).
As is a~y~c:llL, the RESOURCES PART]AL message is passed from a downstrearn node to an upstream node and the method cross-ccnnects the downstrearn node to the ~.llc;
1 0 node until the ~ .lrt;alll node is the same as the node that receives the CROSS-CONNECT
REQUEST in block 614, sends out the REQUEST RESOURCES message at block 632, and receives the RESOURCES PARTIAL mt~.CC~ge. at block 642. When this h~ens, the method branches from block 648 to blocks 650 and 653, wherein the method cross-connects both the incoming and the outgoing paths to an upstream node and a CROSS-CONNECT PARTIAL
1 5 message is sent to an upstrearn node (which is n ceived in block 680). Further, the method proceeds to block 612, where the steps of Figs. 4A, 4B, and 4C end for this node.
In block 656 of Fig. 4A, the method may receive, responsive to a REQUEST
RESOURCES message that it sent to a downstrearn node in block 632, a RESOURCES
NACK message. The RESOURCES NACK m~.sC~ge. in~ c that an error condition has 20 occurred and that it is impossible to build either the incoming or the outgoing call path. It should be noted that it is always possible in any system to have nn:~nti~ir~t~l error conditions.
One source of lln~nt~ pated error conditions may involve a cross-connect failure due to limited resources, bandwidth, hal-lw~/software failures, and the like.
When a RESOURCES NACK message is received in block 656, the required 25 resources are not available to rea'~ize the call. Once again, the response of the method in subsequent blocks 671-678 (see Fig. 4B) depends on what has happened thus far. If the node that sends out the REQUEST RESOURCE'i message at block 632 and receives the RESOURCES NACK message at block 656 is the same as the node that receives the CROSS-CONNECT REQUEST in block 614, the method, responsive to block 671 proceeds to block 3 0 673. On the other hand, if the node that sends out the REQUEST RESOURCES message at block 632 and receives the RESOURCES NACK message at block 656 is a dowllsll~alll node that has responded to a received REQUEST RESOURCES message (block 670), the method proceeds to block 674 from block 671.
In block 673, the method clears both the in~ oming and the outgoing call paths. In other 3 5 words, there is no way to complete the end-to-end connection and the method is clearing the end-to-end connection. The method then proceeds to block 676 where it sends out a CROSS-CA 0221988~ 1997 - 10 - 30 CONNECT NACK m~c.s~ge to the controlling MSC. Thereafter, the method proceeds to block 652 where the nodes return to their idle state.
In block 674, however, the method has ~sct;lL~.l,ed that the node that sends out the REQUEST RESOURCES message at block 632 and receives the RESOURCES NACK
message at block 656 is a downstream node that has responded to a received REQUEST
RESOURCES message (block 670). In this case, the method clears the downstream path. In other words, there is no way to complete the end-to-end connection and the method is clearing its part of the connt~-ctinn in block 674. The method then proceeds to block 678 where it sends out a RESOURCES NACK message to the upstream node. The RESOURCES NACK
1 0 message sent in block 678 may be received, for example, in block 656. Thereafter, the method proceeds to block 652 where the nodes return to their idle state.
As is apparent, the RESOURCES NACK message is passed from a downstream node to an upstream node (block 678 to 656), and the method clears the paths downstream until the u~ alll node is the same as the node that receives the CROSS-CONNECT REQUEST in 1 5 block 614, sends out the REQUEST RESOURCES message at block 632, and receives the RESOURCES NACK message at block 656. When this happens, the method branches fromblock 671 to blocks 673 and 676, wherein the method clears the connection leading to it and a CROSS-CONNECT NACK message is sent to the controlling MSC. In one embodiment, a version of the CROSS-CONNECT NACK message sent to the controlling MSC is received 2 0 in, for example, block 534 of Fig. 3B. Further, the method proceeds to block 652, where the nodes return to their idle state.
As mentioned earlier, the REQUEST RESOURCES message sent in block 632 is received by a downstream node in block 670. At block 672, the downstream node from the upstream node that sent the REQUEST RESOURCES message in block 632 ~Uelll~ls to get resources on node to satisfy the resources re(luhc~lllenl of the end-to-end connection. The process of atlelll~ling to get resources in block 672 involves, in one embodiment, of chlo~king whether the resources on node satisfies the resources re~luilc;lll~llL sent via the REQUEST
RESOURCES message.
From block 672, the method proceeds to block 685 wherein the method checks whether 3 0 all resources required for a proper end-to-end connection cross-connect is s~ti.cfi~o~l, either by the downstream node alone or by a combination of nodes that in~lnfif~.~ the downstream node.
If there are in~l-ffir.i~.nt resources still, the method proceeds from block 685 to block 630 to ascertain whether there are ~ liti~n:~l nodes downstream so that the method may additionally check those additional downstream nodes for possible resources availability. From block 630, 3 5 the method proceeds as earlier (li~cus~ecl CA 0221988~ 1997-10-30 WO 96/3!j311 PCT/US96/06314 On the other hand, if there are cllffi~ient resources to complete the end-to-endconnection cross-connect (as ~lPtennin~ in block 6~5), the method proceeds from block 685 to block 687 where the downstream node is c~ nnPcte-l to the upstream node. The;rt;~fl~., the method proceeds to block 689 where it returns a RE,SOURCES ACK message to the u~ ;an S node. The RESOURCES ACK m~.sc~e sent in block 689 is received, in one embodiment, in block 636 by the upstream node. Thereafter, the method proceeds from block 636 in the manner earlier ~liccu$sel1 On the other hand, the downstream node proceeds, from block 689 to block 612 where the steps of Figs. 4A,4B, and 4IC end for the downstream node.
As mentioned earlier, the CROSS-CONNECT PARTIAL message sent in block 653 is 1 0 received by an u~LI~;a.. l node in block 680. In block 680, the method proceeds to block 684 where the node ~L~em~l~ to get the needed resources. The process of obtaining resources in block 684 is analogous to that pe-r~---led in block 618. From block 684, the method proceeds to block 686 wherein the method ascertains whether. the resources required are available on this node. If there are resources to properly comple:te the end-to-end connection, the method 1 5 proceeds to block 692 where the connection cross-connect, i.e. cross-conn.-cting the incoming path with the outgoing path is ~ Çu~ ed. Thereafter, the method proceeds to block 694 to send a CROSS-CONNECT ACK m~.cc:~g~. to the controlling MSC to inform the controlling MSC that the end-to-end connrcti--n has been bui]t. The method then proceeds to block 612, where the steps of Figs. 4A, 4B, and 4C end for this node.
On the other hand, if there are incllfficj~ont resources (as ~let~rmint-d in block 686), the method proceeds to block 688 wherein both the incoming and the outgoing paths are again cross-connected to a more u~slrea"l node. In block 690, the node sends a CROSS-CONNECT PARTIAL to the u~LIcal~l node to inform the u~LIGal~ node that there areinsufficient IGso~ ;es at lower levels of the hierarchy to complete the end-to-end connection and that the upstream node should get resources to attempt the cross-connect. The CROSS-CONNECT PARTIAL sent in block 690 may be received by the upstream node in, for ç~c~m~ , block 680.
As is aL~p~uclll~ the CROSS-CONNECT PARTIAL message is passed from a downstream node to an uL~:,Lleal" node where the llpsLIeal~ node ~LLe",~L~ to complete the end-3 0 to-end connection (in blocks 684-694). The passing and ~L~ Lhlg to complete the end-to-end c~".l,el;Lion by the nodes below the controlling MSC cc,lllillue~ until the up~Lleal~ node is the same as the controlling MSC. When this happens, the controlling MSC receives the CROSS-CONNECT PARTIAL message in block 532 oi~ Fig. 3B where it makes an attempt to finish the cross-connect at block 535. Meanwhile, however, the method proceeds to block 612, 3 5 where the steps of Figs. 4A, 4B, and 4C end for this node.
Fig. 5 shows in a cimplifi~cl flowchart fo]mat the steps taken by the controlling MSC in c~lr~ ting the o~lh~ulll cross-connect point (O~CP) of block 518 of Fig. 3A. Fig. S starts at CA 0221988~ 1997-10-30 WO 96/35311 PCI~/US96/06314 block 700. In block 702, the MSC that is associated with the MM session for the outgoing call compares the bandwidth of the incoming path with the bandwidth of the outgoing path. The comparison in block 702 is made, in one embodiment, using the information from the outgoing call Initial Address Message (IAM) and the incoming call Address Complete Message (ACM '). The cc~ afison carried out in block 702 may reveal, in one embodiment ~tili7ing the GSM protocol, one of the following results: l) a 16 Kbits to 16 Kbits call, 2) a 16 Kbits to 8 Kbits call,3) a 8 Kbits to 16 Kbits call, or 4) a 8 Kbits to 8 Kbits call.
If both the incoming call and the outgoing call are at 16 Kbits, the method proceeds to block 704. It should be noted that when both the incoming path and the outgoing path are at 16 1 0 Kbits, the present invention advantageously utilizes no TRAU resources in one embodiment.
For further information regarding the illV~llLiVe TRAU avoidance aspect, l~r~lt;llce may be made to a co-pending, commonly ~ignPfi patent applir~tion entitled "Cellular Base Station with Tnt~lligent Call Routing" (U.S. S/N 08/434,598). In this situation, the present invention, in accor~ lce to a preferred aspect, advantageously avoids TRAUing the incoming and the l 5 outgoing paths to 64 Kbits before cross-connection. In contrast, the prior art TRAUs up both the incoming and the outgoing paths to 64 Kbits even for calls among 16 Kbits MS units.
Thel~arlel-, the method proceeds to block 706 to find the shortest 16 Kbits end-to-end ctnn~cti~ n between end points, i.e. between the c-rigin~tion MS unit and the fiestin~tion MS
unit. In one embodiment, the (ietermin~tion of the shortest 16 Kbits end-to-end connection b~lw~ell the two end points of block 706 is performed using an algorithm by Dijkstra, discussed on, for example, pages 492 et seq. of Data Commnnic~tions. Colll~uler Networks~
and Qpen Systems by Fred Halsall (Addison Wesley, 1992).
If the comparison in block 702 reveals that the incoming bandwidth is at 16 Kbits and the outgoing bandwidth is at 8 Kbits, the method proceeds to block 708, signifying that a 16 Kbits to an 8 Kbits TRAU is needed. From block 708, the method proceeds to block 710 wherein the method ~L~ to find the shortest end-to-end connrction between the end points (the MS units) that involves a 16 Kbits to 8 Kbits TRAU resource. In one embodiment, the det~ min~tion in block 710 also uses the search algorithm disclosed by the above-mentioned Halsall reference.
3 0 If the comparison in block 702 reveals that the incoming bandwidth is at 8 Kbits and the outgoing bandwidth is at 16 Kbits, the method proceeds to block 712, signifying that a TRAU resource for converting 8 Kbits to 16 Kbits is needed. In one embodiment, the resources used in blocks 708 and 712 ieplc;St~llL the same circuitry, albeit using different inputs and outputs parameters. From block 712, the method proceeds to block 714 to find the 3 5 shortest end-to-end connection between end points (the MS units) involving a 8 Kbits to 16 Kbits TRAU resources. In some cases, the rate conversion from 8 Kbits to 16 Kbits or vise versa may involve the conversion to 64 Kbits as an intt-rmPrli~t~ step. In one embodiment, the CA 0221988~ 1997-10-30 det~ormin~tion of the shortest end-to-end connection in block 714 utilized the above-mP.ntion.od Dijkstra search algorithm.
If the co~ a ison in block 702 reveals that the incoming bandwidth is at 8 Kbits and - the outgoing bandwidth is also at 8 Kbits, the method proceeds to block 716 to find the shortest S end-to-end connection between the end points (MS units). Typically, when both the incoming path and the outgoing path are at 8 Kbits, no TRAU is needed. In some cit~l~tionc, however, if the bandwidth is asymmetrical, ~ iti~n~l resources may be required for the h~rrnQni7~tion of bandwidth as is known to those of skill in the art.
In one embodiment, the dt~.lr~ ",;"~tion of l;he shortest end-to-end connection between 1 0 end points in block 716 is perFormed using the ~CulenlGnLioned Dijkstra algorithm. It should benotedthatthe search algorithm used in blocks 706, 710, 714 and 716 preferably takes into account both the topology of the network (e.g., what cross-connect nodes are available in the network), as well as the resources that are available at each cross-connect node. Alternatively, any of the routing algorithm ~ cl~ssed in the Following lcrcrt;llces may be used herein:
1 5 Perlman, R. "T~ cv..n~-ction Bridges and Router,", Addison-Wesley, Reading, MA, (1992);
Deering S.E. "Multicast Routing in Internetworks and Extended LANs," Proc. SIGCOMM
'88, Stanford, CA (August, 1988); Estrin, D. "Policy requirements for inter ~-1mini~tr~tive Domain Routing: F FC-1125," Internet Request for Comments, No. 1125, Network Information Center, November 1989. As mP~tion.od earlier in connection with, for ~ mpl~, 20 Figs. 4A, 4B, and 4C, the present inventive rnethod and apparatus, in one embodiment, advantageously includes techniques for dealing with inromrl~-t~ or erroneous topological information. In one embodiment, the technique robustly searches for lcsull~ces at nodes other than the origin~lly d~cign~t~d OCP in order to attempt to complete the end-to-end conn~--ction cross-connect task.
From block 706, 710, 714 or 716, the method proceeds to block 718 wherein the method uses the end-to-end connection discovered via the above-mentioned blocks to pick the uL~ cross-connect point (OCP). From block 718, the method proceeds to block 720, c~lcse~ g the end of the steps of Fig. S.
Fig. 6 shows in a simplified flowchart format the steps involved in using the optimum 3 0 end-to-end connection discovered to pick the OC'P of block 718 of Fig. 5. Fig. 6 starts at block 750. From block 750, the method proceeds to block 752 wherein for every node in the theoretically deterrnin~d end-to-end cU~ n from the origination MS unit to the c~cstin~tion MS unit, the method gets its node type in block '754. In block 754, the node type may be one of a BTS, a BSC, a BSS, or a MSC.
3 5 In block 756, method determines whclllel the node chosen for ~ min:~tion in block 752 is the highest node in the end-to-end connection thus far. In block 756, the upstream-most CA 0221988~ 1997-10-30 node is considered the highest node (e.g. an MSC is considered higher than a BSC or a BSS, which is in turn considered higher than a BTS). If the node chosen for f~Y~min~tion in this iteration is the highest node, the method proceeds to block 758 to t~ uldlily save the highest node. On the other hand, if the node chosen for çx~min~tion in this i~r~tinn is not the highest node or after the highest node has been saved in block 758, the method proceeds to block 752 to continue with the next node in the end-to-end connection. The method continues until every node in the entire end-to-end connection is traversed. After the last cross-connect node is e~c~min~-l, the method proceeds to block 76û wherein the highest node that was telll~oldlily saved in block 758 is decign~tl~(l the optimum cross-connect point (OCP). It should be noted 1 0 that the OCP determined in block 758 is only theoretically determin.od based on topology data known to the MSC. As mentioned earlier, the method advantageously m~-(lifiec in one embodiment, the OCP if it turns out that the theoretically ~letl~rmin~od OCP is ina~.~,~liate for the end-to-end c~ nnloction task.
It should be noted that if the network is a mesh-type network, there may be more than 1 5 one single highest node. For example, if two BSC's are directly interconnected and they represent the highest cross-connect nodes that the end-to-end conn.~cfi-)n traverses, both BSC's are techni~lly highest in the end-to-end connection. In this case, the method only saves the firstBSC in one embodiment (if the comparison in block 756 is greater than) or the second BSC in another embodiment (if the comparison in block 756 is greater than or equal). In acc-,-.i~-ce with one aspect of the present invention, he inventive method applies regardless wh~lllel the first or the second BSC is considered the OCP. The OCP is det~rmin~.d to be the highest node along the theoretically determined (JptilllL~ end-to-end c- nn~cti--n in a hieia~.;l,ical network or one of the highest nodes along that theoretically de.termin~d optimum end-to-end connection in a mesh-type network. From block 760, the method proceeds to block 2 5 762, represP.nting the end of the steps of Fig. 6.
Fig. 7 shows in a cimplirlefl format the steps involved in the end-to-end connection cross-connect, which is shown at, for t-~mplt- block 622 of Fig. 4A. It should be noted that the connection cross-connect point where c-~nn~-c~inn cross-connect between the incoming and outgoing paths occurs is typically, but not n.-ce~ , ;ly pelrolllled at the r~rigin~lly tlecign:lt~d OCP. This is because if the required resources are not available at both the originally tl~cign~t~i OCP and at cross-connect nodes downstream of it, the method may bridge both the incoming and outgoing paths from the nriginsllly rl~cign~cl OCP to an upstream node (as tli.ccuccecl in connection with, for example, blocks 650 of Fig. 4B and 688 of Fig. 4C) to attempt the conn~ction cross-connect at this new OCP. In block 622, it is n~ocecc~ry to 3 5 complete the call path from the ~rigin~tion MS unit to the actual conn~ctinn cross-connect point (which may or may not be the nrigin~lly deci~n~t~(l OCP) and down to the destin~tion MS
unit.

CA 0221988~ 1997-10-30 WO 96/35311 PCr/US96/06314 Fig. 7 starts at block 780. From block 780, the method proceeds to block 782 to complete the hlcoll~llg path cross-connect, i.e. bt;~wGell the ~lestin~tion MS unit and the OCP
(node where the incoming and the outgoing paths are actually cross-conn.-cte~l). Thwcarlc~l, the method proceeds to block 784 to complete the outgoing path cross-connect, i.e. between the 5OCP and the origin~tion MS unit. The method then proceeds to block 786 to perform the connection cross-connect between the incoming path (connected in block 782) and the outgoing path (connected in block 784) across the OCP. Thereafter, the method proceeds to block 788, represçnting the end of the steps of Fig.7.
Fig. 8 shows in a cimrlifit-cl flowchart format the steps involved in ~elrollllillg a 1 0col-"~ ion cross-connect between the incoming and outgoing paths (shown in, for ~-Y~mrle7 block 640 of Fig. 4B or block 692 of Fig. 4C). Fig 8 starts at block 800. From block 800, the method proceeds to block 802 wherein it performs the connection cross-connect across the OCP, i.e. the actual cross-connection point between the incorning path and the outgoing path.
Block 802 represents the co,)l~ licn cross-conn~cting bc;~wcen the incoming path and the 1 5outgoing path across the OCP although some or all of the required resources may be switched in at a duwll~llcam cross-connect node in the paths. This is because in Figs. 4A, 4B, and 4C, the method may have found (via block 620) that it has inc~lffi~ nt resources at the ~l~cign~tt~l OCP to complete the end-to-end conn~oction, and it may have requested resources from a downstream node (block 632) to ~ pclly complete the end-to-end connPction (block 636 and 20subsequent blocks). In one embodiment, both the incoming path and the outgoing path are already completed and available for connection cross-connecting, e.g. prior to block 640 of Fig.
4B. From block 802, the method proceeds to block 804, reprçs~nting the end of the steps of Fig. 8.
Fig. 9 shows in a simplified flowchart format the steps involved in building both the 25incoming and outgoing paths from a node to an upstream node, e.g. shown in block 650 of Fig. 4B and block 688 of Fig. 4C. In Fig. 9, the OCP that realizes it needs to connect upstream for the purpose of using the resources at a upstream node to complet~- the end-to-end C~ nnpction Fig. 9 starts at block 850. From block 850, the method proceeds to block 852 wherein 3 0the outgoing side path is cross-conn~ct~cl In block 852, the method builds the path on the outgoing side b~;~weell the facility to the upstream node and the downstream facility. The downstream facility may be either a facility to a downstream node, e.g. a BTS, or a facility to an MS unit, e.g. the transceiver itself. In block 854, the method builds the path on the incoming side b~;Lw~ell the facility to the upstream node and the downstream facility. From 3 5block 854, the method proceeds to block 856, representing the end of the steps of Fig. 9.
Fig. 10 shows in a simplified format the steps involved in p~lrOll~ lg the conn~-ction cross-connect across the OCP (shown in, e.g. block 786 and block 802). Fig. 10 starts at block CA 0221988~ 1997-10-30 W O 96/35311 PCTrUS96/06314 900. From block 900, the method proceeds to block 910 wherein the method obtains the string of required resources to be switched in at the OCP to plu~clly complete the end-to-end connection. As mentioned previously, the resources that may be required include TRAU, echo c~n~PI~ r, certain packet servers for data calls, and the like.
From block 910, the method proceeds to block 912 wherein two temporary variablesX 1 and X2 are used to accomplish the connection cross-connect between the incoming call path and the outgoing call path across the OCP. In block 912, Xl is set to be equal to the end point of the incoming path while X2 represents the next resource in the connection through the OCP
between the incoming path and the outgoing path. In block 914, the portion of the end-to-end 1 0 connection that traverses through the OCP is c-)nn~ctcrl from the point ~ esellt~d by te~ uldly variable Xl to the point l~lesellt~d by telllpuldly variable X2.
In block 916, the method checks to see whether X2 has reached EP2, repres~-nting the point where the outgoing path couples with the OCP. If X2 is not equal to EP2 (as ~leterminpcl in block 916) the method proceeds to block 918 wherein the point previously represented by 1 5 temporary variable X2 is accigntod to temporary variable Xl, and X2 is now ~ccignPd to the point representing the next resource in the cnnnloction between the incoming path and the outgoing path across the OCP. Thereafter, the method returns to block 914 wherein it continll~s to connect between points Xl and X2.
If it is ~le~ermint~l in block 916 that X2 now lt;~lt;senl~. point EP2 (the point where the outgoing call path couples with the OCP), the portion of the end-to-end connection across the OCP from the incoming call path to the outgoing call path is now completely connt-ct.o~l, and the method proceeds to block 920, lGplc;selllillg the end of the steps of Fig. 10.
Fig. 11 shows in a cim~plifi~.d format the steps involved in cross-connecting a call path, e.g. shown in either block 644, 651, 782 784, 852, and 854. Fig. 11 applies whether the path cross-connection involves the incoming or the outgoing path. Fig. 11 covers the .chll~tion where a path needs to be built belw~ell either the nrigin~tion MS unit or the destination MS unit and the current node.
Fig. 11 starts at block 940. From block 940, the method proceeds to block 942 toobtain the string of required resources, if any, on a cross-connect node along the call path 3 0 (whether incoming or outgoing). As mentioned previously, the resources that may be required include TRAU, echo canceler, certain packet servers for data calls, and the like for the proper comple.tion of the end-to-end connection.
From block 942, the method proceeds to block 944 wherein two ttlllpUldly variables Xl and X2 are used to accomplish the path cross-connection between two end points across a 3 5 cross-connect node along the call path. In the specific embodiment of Fig. 11, tne downstream W O96/35311 PCTrUS96/06314 end of the node is connected to the u~ alll end although this is arbitrary. In block 944, Xl is set to be equal to the dow.lsl~ea,.. end of the node while X2 represents the next resource in the call path toward the u~aL~t;anl end of the node. In block 946, the call path is cc-nn.oct~rl from the point l~pl~st;llL~d by telll~olo~y variable Xl to the point lc~leaent~d by ~elll~olO~y variable X2.
In block 948, the method checks to see whether X2 has reached EP2, ~~ s~ g the end of the string of resources within a cross-connect node in the call path. If X2 is not equal to EP2 (as (leterrnin~d in block 948), the method proceeds to block 950 wherein the point previously represented by telll~ol~y variable X2 is ~ccigned to te~ old~y variable Xl, and X2 is now ~ssi~nP~l to the point leplr. Sr..~ g the next resource in the call path portion across a node 1 0 from the downstream end to the u~aLl~:a..~ end. ~l~el~ar~r, the method retums to block 946 wherein it continlles to connect between points X]. and X2. As is ~a t;llt, blocks 942-950 leL~Icsellts the steps taken to cross-connect across one cross-connect node, in~ ling any resources utilized therein, in the call path.
If it is r1.otermin~cl in block 948 that X2 now le~ e.lla point EP2, the path across one 1 5 cross-connect node in the call path, though whatever resources required, is connPc~ l The method then proceeds to block 954 to rl~.t~ .",i"t~. whether the downstrearn node in the path is also conn~ct~fl If the downstream node is alreacLy conn.-ct~--l the method proceeds to block 962, representin~ the end of the steps of Fig. 11.
On the other hand, if it is d~-termin( cl in block 954 that the duw--aL-~a ll node in the path 20 is not co,~ td, the method proceeds to block 956 to send a PATH CROSS-CONNECTREQUEST mP.ss~ge downstream to the downstream node. In one embo~iimpnt~ the PATHCROSS-CONNECT REQUEST message is received by a node downstream at block 611 of Fig. 4A from the node that sends it. From block 611, the method proceeds to block 613 wherein the downstream node that receives the PATH CROSS-CONNECT REQUEST
25 message at block 611 aue.llp~a to cross-conDIect at its dow..aL.ea... location. In one embo-lim~--nt, the steps ~elrol.l.ed in block 613 involves invoking the method of Fig. 11 again for the downstream node. Once the portion of the call path through that node has been conn~oct~tl the node will send out a PATH CROSS-CONNECT ACK message at block 615.
In this manner, the method iteratively builds a path by connP.cting through each node in the path 3 0 starting from the upstream most node in a path and working its way dowllw~d toward the MS
unit.
In block 960, the downstream nodes return a PATH CROSS-CONNECT ACK
message in(l~ ting that the desired path, all the way down to the MS unit, has been cross-conn~cterl In block 962, the steps of Fig. 11 end.
3 5 Although the foregoing invention has bee:n dl-scrihed in some detail for purposes of clarity of underst:~n-ling, it will be a~ that certain changes and modifications may be CA 0221988~ 1997-10-30 WO 96/3~i311 PCTIUS96106314 rr~rtirc~l within the scope of the appended claims. By way of e x~mrle, although the invention is ~ cu~.se~ herein with ~cr~lc;lellce primarily to a GSM system, it should be noted that the present invention is not so limiting. It is .~peçifi~z~lly co"l~"~ t~l that the cellular private branch çx~h:~ngP~ disclosed herein may be imrlçm~nt~d in systems using 5 other specific protocols.
Further, although the invention is described using flowcllall~ as an illustration aid, it should be noted that the methods and d~dLus of the present invention may be event-driven, capable of eYt~cuting multiple processes at the same time. As such, dirr~ t processes and process tasks do not nPcecs~rily have to be p~-rolllled in the specific 10 sequential order chosen for illustration, and a colll~uLel and/or software program implçmlonting the illvt;llLiv~ method may be çY~oC~ting other tasks while executing the inventive method disclosed herein.
Further, although the present invention uses comm--nie~tion between two MS unitsto illustrate the inventive concept, it should be noted that cc,llrelellce calls may be made 15 among more than two MS units, e.g. among 3, 4 or more MS units. The adaptation of the disclosed a~al~Lusses and methods to achieve that end is well within the abilities of one skilled in the art. Given this disclosure, it will be aLJ~ llL to those of ordinary skills in the art that combinations and ~ub~LiLuLions may be made without depareing from the scope and the spirit of the present invention. Consequently, the scope of the invention is not limited to 2 0 the specific examples given herein but is set forth in the appended claims.

CA 022l9885 l997-lO-30 APPENDI'~ A
GLOSSARY OF TERMS AND ABBREVIATIONS

Abis: Protocol stack b~lweell a BTS and a. BSC
ACM: Address Complete Message ANM: Answer Message BCF: Base Station Control Function BSC; Base station Controller BSS: Base Station Subsystem BTS: Base Transceiver Station CC; Call Control M~n~gement CCPU: Cellular CPU
cPBX: cellular Private Branch T~.xc~h~nge DSP: Digital Signal Processing GMSC: Gateway for MSC
GSM: Global Systems for Mobile Commllniçz-tiQn HLR: Home Location Registry IAM: Initial Address Message ISDN: Integrated Services Digital Network 2 0 IWF: Inter-Working Functions LAPD-M: Link Access Protocol on the Dm (control) channel MM: Mobility M~n~gem.-.nt MS: Mobile Stations MSC Mobile-Services Switching Center PSTN: PublicSwitchedTelephoneNetwork RF: module Radio Frequency module RL: Radio Link RR: Radio Resource Management SCCP: .Sign~lling Connection Control Part SMS: ShortMessage Services SS: Supplem~nt~l Services TDM data: Time Division Multiplexed Data TRAU: Transcoder-Rate Adapter Unit TRX: Transceiver VLR: VisitorT oc~tion Registry VME: An industry standard bus for interconnrcting components wPBX: wired PBX

CA 0221988~ 1997 - 10 - 30 WO 96/3~311 PCTIUS96/06314 APPENDIX B

Mouly, Miehel & Pautet, Marie-Rerna~l~.tte, "The GSM System for Mobile Comml-nir:ltions". Mouly, Miehel & Pautet, Marie-Bçrna~lettP 1992.

European Telecul " ~ . " " ~ ;c~tinns Standards Institute, "European digital cellular telecommunications system (Phase 2): Mobile radio intl-.rfare .~ignzlling layer 3 General aspects (GSM 04.07)". 1994, Valbonne - Franee.

European Telecol-l",-l-lie~tions Standards Tn~titntt~ "European digital tçleeo~ ullieations system (Phase 2): Mobile radio interface layer 3 spe~ification (GSM
04.08)" . 1994, Valbonne - Franee.

European Telecommllnirations Standards Tn~titnte7 "European digital cellular telecommnnieations system (Phase 2): Mobile-services Switchin~ Centre - Base Station System (MSC - BBS) int~rfare Layer 3 speeifieation (GSM 08.08)" . 1994, Valbonne -2 0 Franee.

European Telee~l""~"l"i~atinn~ Standards Tn~titntt- "European digital cellular teleeommunieations system (Phase 2): Signaling transport mechanism speeifieation for the 25 Base Station System - Mobile-services Switching Centre (BBS - MSC) int~r~are (GSM
08.06)" . 1994, Valbonne - Franee.

European Telecommllnications Standards Tn~titlltl- "European digital cellular 30 telecommunications system (Phase 2): Base Station Controller - Base Transeeiver Station (BSC - BTS) interfaee Layer 3 sperifi~ ation (GSM 08.58)" . 1994, Valbonne - Franee.

European Teleco..l.lllll.ications Standards Tn~titllt~ "European digital cellular 35 telecommunications system (Phase 2): Mobile Application Part (MAP) spe~ifi~zltion (GSM
09.02)" . 1994, Valbonne - France.

-European Telecomm-lnic ~ri~ nc Standards Tn~tit~ltc "European digital cellular teleco""llll"ications system (Phase 2): Si~n~lin~ n~quirements on intern~;Lw~Jlkillg heLw~ell the Integrated Services Digital Network (ISDN) or PLIblic Switched Telephone Network (PSTN) and the Public Land Mobile Network (PLMN) (GSM 09.03)". 1994, Valbonne - France.

Claims

2. In a system having a plurality of cross-connect nodes for facilitating cellular communication among a plurality of mobile stations, a method of cross-connecting an end-to-end connection between an origination mobile station and a destination mobile station, comprising:
receiving call control information from. said origination mobile station;
receiving call control information from. said destination mobile station;
computing, responsive to said call control information received from said origination mobile station and said call control information received from said destination mobile station, an optimum end-to-end connection for cross-connecting said end-to-end connection, said optimum end-to-end connection having a first optimumcross connect point and representing a computed shortest communication route between said origination mobile station and said destination mobile station that satisfies resource requirements for cross-connecting said end-to-end connection; and cross-connecting said end-to-end connection through said first optimum cross-connect point, including:
determining whether said first optimum cross-connect point has on node resources to satisfy said resource requirements for cross-connecting said end-to-end connection; and if said first optimum cross-connect point has on node said resources to satisfy said resource requirements for cross-connecting said end-to-end connection, cross-connecting said end-to-end connection along said optimum end-to-end connection using said first optimum cross connect point as a connection cross-connect point.

3. The method of claim 2 wherein said step of cross-connecting said end-to-end connection through said first optimum cross-connect point further comprising:
determining, if said first optimum cross-connect point does not have on node said resources to satisfy said resource requirements for cross-connecting said end-to-end connection, whether said resource requirements for cross-connecting said end-to-end connection are satisfied by a usage of resources at nodes downstream from said first optimum cross-connect point; and if said first optimum cross-connect point does not have on node said resources to satisfy said resource requirements for cross-connecting said end-to-end connection and said resource requirements for cross-connecting said end-to-end connection are satisfied by said usage of resources at nodes downstream from said first optimum cross-connect point, cross-connecting using resources available at said nodes downstream from said first optimum cross-connect point said end-to-end connection, and using said first optimum cross connect point as a connection cross-connect point.

4. The method of claim 3 wherein said step of determining whether resources requirements for cross-connecting said end-to-end connection satisfied by said usage of resources at nodes downstream from said first optimum cross-connect point comprises the step of checking resources on nodes in an incoming call path between said destination mobile station and said first optimum cross connect point prior to checking resources on nodes in an outgoing call path between said origination mobile station and said first optimum cross connect point.

5. The method of claim 3 wherein said step of cross-connecting said end-to-end connection through said first optimum cross-connect point further comprising:
designating an upstream node from said first optimum cross-connect point a second optimum cross-connect point if resource requirements for cross-connecting said end-to-end connection are not satisfied by said usage of resources at nodes downstream from said first optimum cross-connect point and a usage of n-sources at said first optimum cross-connect point;
determining whether a usage of resources at said second optimum cross-connect point satisfies said resource requirements for cross-connecting said end-to-end connection; and cross-connecting, using said second optimum cross-connect point as a connection cross-connect point and using resources available at said second optimum cross-connect point, an outgoing call path from said origination mobile station with an incoming call path to said destination mobile station, if said usage of resources in said second optimum cross-connect point satisfies said resource requirement for cross-connecting said end-to-end connection.

6. The method of claim 5 wherein said resources comprises rate conversion resources.

7. An apparatus for cross-connecting an end-to-end connection between an origination mobile station and a destination mobile station in a network of cross-connect nodes, comprising:
a call control circuit including:
a first circuit portion for receiving call control information from said origination mobile station and said destination mobile station; and a second circuit portion for determining, responsive to receiving said call control information from said origination mobile station and said destination mobile station, an optimum end-to-end connection for cross-connecting said end-to-end connection through said network of cross-connect nodes, said optimum end-to-end connection representing a computed shortest communication route between said origination mobile station and said destination mobile station that satisfies resource requirements for cross-connecting said end-to-end connection.

8. The apparatus of claim 7 wherein said resource requirements for cross-connecting said end-to-end connection include a transcoder rate adapter unit.

9. The apparatus of claim 7 wherein said network of cross-connect nodes comprises a mobile-services switching center, a base station controller, and a base transceiver station.

10. The apparatus of claim 9 wherein each of said cross-connect nodes includes circuitry for checking resource availability downstream of said each of said cross-connect node.

11. The apparatus of claim 10 wherein each of said cross-connect nodes further includes circuitry for checking resource availability upstream of said each of said cross-connect node.

12. The apparatus of claim 11 wherein said resource requirements for cross-connecting said end-to-end connection include a transcoder rate adapter unit.

14. An apparatus for facilitating cellular communication between an origination mobile station and a destination mobile station, comprising:
a mobile services switching center, said mobile services center having a first switching circuit for performing connection cross-connects for calls between said origination mobile station and said destination mobile station;
a call control circuit coupled to said mobile services switching center, said call control circuit receiving call control information from said origination mobile station and said destination mobile station, said call control information from said origination mobile station comprises a rate at which said origination mobile station communicates and said control information from said destination mobile station comprises a rate at which said destination mobile station communicates;
a base station controller coupled to said mobile services switching center, saidbase station controller having a second switching circuit for performing connection cross-connects for calls between said origination mobile station and said destination mobile station; and a base transceiver station coupled to said base station controller, said base transceiver station having a third switching circuit for performing connection cross-connects for calls between said origination mobile station and said destination mobile station, wherein said call control circuit determines, responsive to said call control information received from said origination mobile station and said destination mobile station, at which of said mobile services switching center, base station controller, and base transceiver station an optimum cross connect point for cross-connecting an end-to-end connection between said origination mobile station and said destination mobile station resides.

15. The apparatus of claim 14 wherein each of said mobile services switching center, base station controller, and base transceiver station includes a circuit for switching in resources required for cross-connecting said end-to-end connection between said origination mobile station and said destination mobile station.

16. The apparatus of claim 15 further comprising a topology information database, wherein said optimum cross connect point is determined based on data in said topology information database.

17. The apparatus of claim 16 wherein said origination mobile station and said destination mobile station communicate using a Global Systems for Mobile Communication protocol.

19. An apparatus for cross-connecting an end-to-end connection between an origination mobile station and a destination mobile station via a network of cross-connect nodes, comprising:
means for receiving call control information relating to said origination mobilestation and said destination mobile station, said call control information from said origination mobile station comprises a rate at which said origination mobile station communicates and said control information from said destination mobile station comprises a rate at which said destination mobile station communicates; and means for determining, responsive to said call control information from said origination mobile station and said destination mobile station, an optimum end-to-end connection, said optimum end-to-end connection representing a computed shortest route through said cross-connect nodes for properly cross-connecting said end-to-end connection between said origination mobile station and said destination mobile station.

20. The apparatus of claim 19 wherein said origination mobile station and said destination mobile station communicate using a Global Systems for Mobile Communication protocol.