Classifications

• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04W—WIRELESS COMMUNICATION NETWORKS
  • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
  • H04W88/08—Access point devices
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04W—WIRELESS COMMUNICATION NETWORKS
  • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
  • H04W88/12—Access point controller devices
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04W—WIRELESS COMMUNICATION NETWORKS
  • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
  • H04W88/14—Backbone network devices
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04W—WIRELESS COMMUNICATION NETWORKS
  • H04W92/00—Interfaces specially adapted for wireless communication networks
  • H04W92/04—Interfaces between hierarchically different network devices

Definitions

• the present invention relates to networks for cellular communication service. More specifically, the invention relates to methods and apparatus for implementing software in a cellular network.
• Fig. 1 is a diagram illustrating the components of a representative cellular network, including a Mobile Switching Center (MSC) 100, a Base Station Controller (BSC) 102, a Base Transceiver Station (BTS) 104, and a plurality of cellular handsets 106(a)-106(b).
• MSC Mobile Switching Center
• BSC Base Station Controller
• BTS Base Transceiver Station
• 106(a)-106(b)-106(b) The components of the representative cellular network of Fig. 1 has been discussed extensively in the aforementioned patent applications.
• each component of the cellular network i.e., MSC 100, BSC 102, and BTS 104, is implemented on a discrete chassis and housed in a discrete "box.”
• the boxes themselves are then dispersed as required in a geographic location, coupled together by trunk lines to complete the cellular network.
• each of MSC 100, BSC 102, and BTS 104 typically includes two main parts: hardware and software.
• Hardware generally includes the relatively fixed physical circuitries while software, being programmable, is generally easier than hardware to design, implement, and modify. Consequently, while a certain amount of hardware is necessary, it is generally considered desirable to implement as much of the functionalities of the cellular network in software as possible. This is particularly true in view of the availability of modern high speed processors and programmable circuitries.
• FIG. 2 is a diagram illustrating a prior art implementation of the software functional blocks for implementing components of the prior art cellular network.
• Fig. 2 there are shown three boxes: 200, 202, and 204, which contain the hardware necessary for implementing respectively the MSC, the BSC, and the BTS components.
• box 200 the software for implementing the MSC function, the A interface necessary for communicating with the software implementing the BSC in box 202, and El resources to communicate therewith across trunk line 206.
• box 202 contains the software for implementing the BSC function, the A interface to communicate with the software implementing the MSC in unit 200, and El resources for communicating therewith across trunk line 206.
• box 202 To communicate with software implementing the BTS in box 204, there is further provided in box 202 software for implementing the Abis interface and El resources for communicating across a trunk line 208.
• box 204 contains the software for implementing the BTS function, the Abis interface for communicating with the software implementing the BSC in unit 202, and El resources to facilitate the communication therewith.
• box 204 further includes the software for implementing the LAPDm facility 212, which in cooperation with software implementing TRX resources 214, permits the software implementing the BTS function in block 204 to communicate with its cellular handsets.
• each of the software implementing boxes 200, 202, and 204 is customized for a particular cellular network configuration.
• cellular network configuration refers to the MSC's, BSC's, and BTS's in a cellular network, as well as the particular manner in which they are combined, either in one chassis or across multiple chassis.
• a cellular network is initially configured as a single chassis in which the MSC, the BSC, and the BTS co-reside (as was disclosed in one embodiment of co-pending patent application WAVEP001.P, and additional remote BTS's are added to the network to expand cellular network capacity at a later date
• the prior art method of implementing its software typically requires substantial recoding of the software of the affected components, which may include the MSC, the BSC and the BTS.
• the prior art paradigm of implementing the software of the MSC, the BSC, and the BTS of the cellular network requires extensive knowledge regarding how data must be routed in a particular network configuration on the part of the application developer, i.e., those who develop the software that implements the software functional blocks such as the MSC, the BSC, or the BTS.
• the fact that the software functional blocks of the prior art must be changed to accommodate modifications to the network configuration means that relatively substantial expenditures, both in term of time and expenses, are required when the cellular network is upgraded, or scaled up or down responsive to changes in domain and capacity requirements.
• an improved method and apparatus for implementing the software of a cellular network in a manner that is as independent of cellular network configuration as possible. It is also desired that the improved method and apparatus implements the MSC, the BSC, and the BTS as substantially unchanging blocks of code irrespective of cellular network configuration. More importantly, it is desired that these substantially unchanging blocks of code, which implement the MSC, the BSC, and the BTS of the cellular network, communicate among themselves using an interface that is also substantially unchanged irrespective of changes in the configuration of the cellular network.
• the present invention relates,in one embodiment, to a configuration-independent software architecture for implementing a cellular communication network that facilitates communication among a plurality of cellular handsets.
• the architecture includes a first software functional block for implementing a first set of functions and a second software functional block for implementing a second set of functions.
• the architecture further includes a configuration-independent linkage block, which has an interface that appears consistent to both the first software functional block and the second software functional block irrespective of a relative position between the second software functional block, the first software functional block, and the configuration-independent linkage block in the cellular communication network.
• the configuration-independent linkage block facilitates communication between the first software functional block and the second software functional block via the interface utilizing configuration-independent linkage block.
• the first software functional block, the second software functional block, and the interface remain substantially unchanged when the first software functional block changes its location in the cellular communication network relative to the second software functional block.
• the first software functional block is a base transceiver station software functional block and the first set of functions is a set of base transceiver station functions
• the second software functional block is a base station controller software functional block and the second set of functions is a set of base station controller functions.
• the invention in yet another embodiment, relates to a method for facilitating communication among a plurality of software functional blocks in a cellular communication network which has a plurality of central processing units.
• the method includes the step of providing a first software functional block for implementing a first set of functions.
• the first software functional block is executed on a first central processing unit in the cellular communication network.
• the method further includes the step of providing a second software functional block for implementing a second set of functions.
• the second software functional block represents a first instantiation of a block of codes representing the second set of functions.
• the inventive method further includes the step of providing a third software functional block for implementing the second set of functions.
• This third software functional block represents a second instantiation of the block of codes representing the second set of functions.
• the inventive method includes the step of facilitating configuration-independent communication between the first software functional block and both the second and third software functional blocks using at least one configuration-independent linkage block.
• the configuration-independent linkage block has internal functions that transparently implements, from the perspectives of the first, second, and third software functional blocks, configuration-specific communication among the first, second, and third software functional blocks.
• the configuration-independent communication takes place via an interface that is substantially consistent irrespective whether the second and third software functional blocks execute on the first central processing unit or on different central processing units in the cellular communication network. Irrespective of this, the first, second, and third software functional blocks remain substantially unchanged across network configurations.
• first, second, and third software functional blocks and the interface remain substantially unchanged irrespective whether the second and third software functional blocks are executed on a second central processing unit that is different from the first central processing unit or on two different central processing units that are different from the first central processing unit.
• Fig. 1 is a diagram illustrating the components of a representative cellular network
• Fig. 2 is a diagram illustrating a prior art implementation of the software functional blocks for implementing components of the prior art cellular network
• Fig. 3 illustrates, in one aspect of the present invention, the configuration-independent architecture of the software functional blocks (SFB's), which implement the components of the cellular network;
• Fig. 4A illustrates an example of a cellular network configuration wherein the base station controller (BSC) and the mobile station controller (MSC) SFB's co-reside on a single central processing unit (CPU) in a single chassis while the base transceiver station (BTS) software functional block is remoted in a different CPU on a different chassis;
• BSC base station controller
• MSC mobile station controller
• BTS base transceiver station
• Fig. 4B illustrates an example of a cellular network configuration in which the BSC software functional block and the BTS software functional block co-reside on a single chassis while the MSC SFB is remoted on a different chassis
• Fig. 5 illustrates a BSS implementation in which a BSC software functional block and a BTS software functional block co-reside in the same CPU/chassis
• Fig. 6A is a diagram illustrating, in one embodiment, the relationship between the communication protocols between two SFB's such as a BSC SFB and a BTS SFB as well as the actual data exchange that takes place within a configuration-independent linkage block (CILB) between them;
• CILB configuration-independent linkage block
• the BSC SFB and the BTS SFB are distributed in different CPU's/chassis.
• Fig. 7 is a diagram illustrating, in one embodiment, a message passing paradigm for facilitating communication between SFB's in a configuration-independent manner
• Fig. 8 illustrates how multiple SFB's may utilize subroutines in a library of subroutines to communicate in a configuration independent manner
• Fig. 9A shows, in one embodiment, a multiple-layer communication stack for communicating among SFB's
• Fig. 9B shows the communication, using the inventive configuration independent architecture technique, between a BSC SFB and an MSC SFB;
• Fig. 10 illustrates the message passing paradigm for communicating among different SFB's
• Fig. 11 shows an example of a routing table associated with a CPU
• Fig. 12 illustrates the communication between a BSC administration SFB and an A- interface SFB when these two SFB's are remoted from one another;
• Fig. 13 illustrates the communication between a single BSC administration SFB and three BTS manager SFB's, which are implemented on three discrete cellular central processing unit (CCPU) cards.
• CCPU central processing unit
• Fig. 3 illustrates, in one aspect of the present invention, the configuration-independent architecture of the software functional blocks (SFB's), which implement the components of the cellular network.
• the three SFB's MSC 220, BSC 222, and BTS 224 are coupled together via configuration-independent linkage blocks (CILB) 226 and 228.
• CILB 226 includes an interface that appears substantially unchanged to both MSC SFB 220 and BSC SFB 222 irrespective of the configuration of the cellular network.
• MSC SFB 220 and BSC SFB 222 communicate with CILB 226 remains substantially unchanged irrespective of whether these two SFB's are executed in the same central processing unit (CPU), implemented in the same physical chassis (i.e., on the same chassis) but executed on different CPU's, or remoted in geographically dispersed chassis that are linked together via trunk lines.
• CPU central processing unit
• these two SFB's may be executing on the same CPU in that chassis or in multiple CPU's in that same chassis.
• multiple CPU's are provided in a single chassis, greater processing power can be provided on that chassis.
• Multiple CPU's may be tightly coupled, i.e., sharing memory resources and other resources, or loosely coupled, i.e., utilizing the same bus although each CPU is provided with its own memory and other resources.
• two SFB's are remoted from one another, they are executed on different CPU's in different chassis, and communication between these SFB's requires remote communication resources, e.g., El.
• the interface between CILB 228 and BSC SFB 222 (as well as between CILB 228 and BTS SFB 224) remains substantially unchanged irrespective of cellular network configuration.
• the software codes that implement these major SFB's e.g., MSC SFB 220, BSC SFB 222, BTS SFB 224, and radio-dependent SFB's (e.g., TRX SFB 230) stay substantially unchanged irrespective of cellular network configuration.
• each block of codes for implementing the cellular network components may be made modular, thereby simplifying network expansion, upgrade, and maintenance.
• the major SFB's for implementing the cellular network components may flexibly be combined, either in a single CPU/chassis or be remoted among combinations of CPU/chassis, thereby making it possible to offer custom solutions to fit particular geographic or capacity requirements in a low-cost manner.
• this aspect of the present invention advantageously simplifies network upgrade and scaling, i.e., expanding and contracting by respectively adding or removing network components to suit the changing domain or capacity requirements of a cellular network.
• the inventive configuration-independent architecture allows a cellular provider to offer a cellular network that is less expensive and possesses higher performance characteristics than possible in the prior art by using a single chassis to implement all four major components (i.e., MSC, BSC, BTS, and TRX).
• MSC mobile phone
• BSC BSC
• BTS BTS
• TRX TRX
• the use of a single chassis to implement all these four major components advantageously eliminates the costs, in terms of hardware and software, associated with implementing trunk resources.
• capacity and domain requirements increase, e.g., to handle more cellular handsets or to expand the area of coverage
• the inventive configuration-independent architecture permits scaling of the network software in a modular and configuration-independent manner. Since the major SFB's remain substantially unchanged, and the manner in which they communicate with one another is not dependent on system configuration, network upgrade and expansion are substantially simplified.
• changes in cellular network configuration impact primarily only the software functions that underlie the CILB's.
• a cellular network configuration changes from a BTS/BSC configuration (both the BTS and the BSC co-reside on the same CPU/chassis and the MSC is remoted) to a BTS/BSC/MSC configuration (all three SFB's co-reside on the same CPU/chassis)
• the CILB interfaces through which these major SFB's communicate preferably stays substantially unchanged from the perspectives of the SFB's that implement the MSC, the BSC, and the BTS.
• BTS SFB 224 also communicates with TRX SFB 230 via TRX configuration- independent linkage block (CILB) 232, which possesses an interface that appears substantially unchanged to both BTS SFB 224 and TRX SFB 230 irrespective of cellular network configuration, i.e., regardless whether they co-reside in the same CPU/chassis or are remoted among different CPU's/chassis.
• CILB TRX configuration- independent linkage block
• the term software functional block is not restricted only to blocks of codes that implement the MSC, the BSC, and the BTS. In fact, they apply to any executable block of codes that performs a particular task in the cellular network and which is substantially immune to changes in network configuration.
• Fig. 4A illustrates an example of a cellular network configuration wherein the BSC and the MSC SFB's co-reside on a single CPU in a single chassis while the BTS SFB is remoted in a different CPU on a different chassis.
• MSC SFB 220 communicates with BSC SFB 222 via CILB 226 while BSC SFB 222 communicates with BTS SFB 224 via CILB 228.
• the GSM standard is chosen for illustration purposes although it should be understood that the present inventive configuration-independent architecture is not limited to any particular protocol.
• the inventive configuration-independent architecture may be implemented using a local area network protocol, such as TCP/IP, or other cellular standards such as AMPS (Advanced Mobile Phone Services), TACS, and the like.
• a local area network protocol such as TCP/IP
• AMPS Advanced Mobile Phone Services
• TACS Transmission Control System
• CILB 226 is implemented as a local interface, and more particularly, a local interface implementing the GSM-related A interface that utilizes message passing for communication.
• the A interface implemented in the network of Fig. 4A follows, in one embodiment, the Signaling Connection Control Part-Message Transfer Part 1-3 (SCCP MTP1-3) as described in the GSM specification 08.06. Message passing will be explained later in connection with Fig. 7.
• SCCP MTP1-3 Signaling Connection Control Part-Message Transfer Part 1-3
• CILB 228 is implemented as a remote interface.
• CILB 228 is implemented as a remote interface utilizing the GSM-related Abis interface, which utilizes El trunk facilities and trunk lines to facilitate remote communication.
• MSC SFB 220, BSC SFB 222, and BTS SFB 224 stay substantially unchanged irrespective whether they all co-reside in the same CPU/chassis or are remoted in different CPU's/chassis.
• the interfaces of CILB 226 and CILB 228, as well as all CILB's implemented in accordance with the technique disclosed herein appears substantially unchanged to the SFB's with which they communicate.
• CILB 226 has an interface that appears substantially unchanged to MSC SFB 220 and BSC SFB 222 regardless whether CILB 226 is implemented as a local interface (as in the example of Fig.
• CILB 228 has an interface that appears substantially unchanged to BSC SFB 222 and BTS SFB 224 regardless whether CILB 228 is internally implemented as a local interface or as one that facilitates remote communication.
• Fig. 4B shows a cellular network configuration in which BSC SFB 222 and BTS SFB 224 co-reside on a single chassis while MSC SFB 220 is remoted on a different chassis.
• the SFB's communicate using their respective CILB's which have consistent interfaces irrespective whether they co-reside on the same chassis or are remoted from one another.
• CILB 226 implements the GSM-related A interface in a remote manner in Fig. 4B and in a local manner in Fig. 4A is also largely hidden from both BSC SFB 222 and MSC SFB 220 by the configuration-independent interface of CILB 226.
• a cellular network created in accordance with the inventive configuration-independent architecture may flexibly be reconfigured in a modular and configuration-independent manner to obtain different network configurations without requiring substantial changes to the codes of its major SFB's.
• the developers of the SFB's e.g., the MSC, the BSC, the BTS, or the TRX SFB's, to know the details regarding data routing in a specific network configuration. Since the CILB interfaces remain substantially unchanged from the perspective of the SFB's, these SFB's may be developed independent of any knowledge of network configuration.
• This inventive aspect presents a major advantage when the cellular network needs to be upgraded, maintained, scaled (up or down) to satisfy the capacity and domain requirements of a particular geographic location.
• Fig. 5 illustrates a BSS implementation in which a BSC SFB and a BTS SFB co-reside in the same CPU/chassis.
• BSC SFB 300 communicates with BTS SFB 302 through CILB 304.
• BSC SFB 300 also communicates with a CILB 306 which handles communication between BSC SFB 300 and an MSC (not shown).
• BSC SFB 300 there are shown, for illustration purposes, some of the functional blocks for implementing the BSC SFB.
• functional blocks BSC administration 320, BTS manager 322, channel manager 324, and handover manager 326 are shown.
• BTS SFB 302 BTS administration 328, dedicated channel block 330, and common channel block 332.
• Each of functional blocks 320-332 may be thought of as a SFB, i.e., they can be remoted or implemented in the same CPU/chassis without requiring substantial changes to their internal codes using the inventive CILB concept.
• radio-dependent SFB's 312 and 314 for facilitating communication between BTS SFB 302 and the cellular handsets (omitted from Fig. 5 for ease of illustration). It should be understood that a greater or fewer number of radio-dependent software function blocks (SFB's) may be provided as necessary to accommodate the number of cellular handsets in a cellular network.
• SFB's radio-dependent software function blocks
• the radio-dependent SFB performs TRX-dependent functions such as communications, LAPDm functions, and TRX administration functions, and the like.
• each radio-dependent SFB may include a LAPDm SFB, a TRX administration SFB, and a digital signal processing (DSP) management SFB.
• BTS SFB 302 communicates with a CILB 310, which handles communication between BTS SFB 302 and a plurality of cellular handsets.
• CILB 310 of Fig. 5 appears substantially unchanged to BTS SFB 302 irrespective of the number of radio- dependent SFB's in the cellular network.
• Configuration-independent communication may be accomplished in any manner.
• two main communication paradigms for implementing CILB's are discussed herein.
• configuration-independent communication to and from a SFB through a CILB may take place via message passing.
• the sending SFB sends a message to a mailbox having a well-known address. If that destination mailbox is local to the sending SFB, i.e., implemented on the same CPU/chassis, the CILB merely forwards the message to that destination mailbox to be retrieved by the one of the SFB's which monitors the mailbox. If the destination mailbox and its associated receiving SFB is remoted, i.e., implemented on a different CPU/chassis, the CILB will route the message appropriately. From the perspective of the sending SFB, the fact that the destination mailbox is implemented locally in one case and remoted in another case is substantially hidden. The actual details regarding data routing is left to the functions within the CILB.
• a CILB may facilitate communication to and from a SFB by calling on interface functions, which are basically library subroutines that can be linked, either statically or dynamically, by the SFB that requires it for communication.
• interface functions are basically library subroutines that can be linked, either statically or dynamically, by the SFB that requires it for communication.
• the CILB can either route data locally or to remote CPU/chassis while keeping such configuration-specific details from both the sending and the receiving SFB's.
• a CILB that utilizes interface functions to permit two SFB's of the cellular network to communicate in a configuration-independent manner may be seen in the communication between BTS SFB 302 of Fig. 5 and its radio-dependent SFB's.
• BTS SFB 302 wishes to communicate with any of its radio-dependent SFB's, it sends data to CELB 310 which happens to be implemented partially by a first-in-first-out stack (FIFO).
• FIFO first-in-first-out stack
• the FIFO of CILB 310 is implemented, in one embodiment, on the same CPU that executes its associated radio-dependent SFB.
• BTS SFB 302 may call, for example, a subroutine FifoSend, which is a subroutine whose implementation details are hidden from BTS SFB 302.
• FifoSend is a modular subroutine that handles the routing of data between BTS SFB 302 and the FIFO in CILB 310 in a specific network configuration. Since the implementation details regarding data routing is hidden in the subroutine FifoSend, BTS SFB 302 may be configured as local or remote with respect to the radio-dependent SFB's with which it wishes to communicate simply by modifying the codes inside the subroutine FifoSend.
• the SFB's themselves and the manner with which they interact with CILB 310 remain substantially unchanged from network configuration to network configuration. This is substantially simpler than modifying the much larger SFB's which implement, for example, the BTS and the radio- dependent blocks whenever network configuration changes, as was required in the prior art.
• a FIFO is shown herein for ease of illustration, it should be kept in mind that there exists other methods for inter-processor communication. Examples of these methods include using shared memory, mailboxes, bus protocols (serial, parallel, and other known protocols), and the like.
• An example of a CILB which facilitates communication to and from a SFB by message passing may be illustrated with reference to CILB 304.
• BTS SFB 302 wishes to communicate with BSC SFB 300, it send messages to a well-known mailbox associated with the Abis interface implemented by codes within CELB 304. If the message passing is done locally, as is the case when both BTS SFB 302 and BSC SFB 300 occupy the same CPU/chassis, functions in CILB 304 are coded to implement local message passing.
• BTS SFB 302 when BTS SFB 302 is remoted from BSC SFB 300, functions within CILB 304, whose details are hidden from both BTS SFB 302 and BSC SFB 300, utilize facilities such as LAPD to ensure that messages to and from the intended mailbox can be remotely sent or received. Note that from the perspectives of BTS SFB 302 and BSC SFB 300, their interaction with CILB 304 remains substantially unchanged irrespective whether these two SFB's are configured as remote or local in a given network.
• the interface between CILB 304 and the sending as well as the receiving SFB's, e.g., BTS SFB 302 or BSC SFB 300, remains substantially unchanged irrespective of the number of BTS SFB's 302 that are coupled to BSC SFB 300.
• the MSC (not shown) is implemented on a remote CPU/chassis from that implementing the BTS/BSC SFB's. Consequently, CILB 306 must facilitate remote communication.
• This remote communication is implemented in Fig. 5 by a remote communication SFB.
• this remote communication SFB is implemented using network interface controller (NIC) 321, which includes the A interface (SCCP MTP1-3 as described by GSM standard 08.06) and by the El SFB within NIC 321.
• NIC network interface controller
• NIC 321 may also implement the Abis protocol to function as the CILB associated with each of BSC SFB 300 amd BTS SFB 302 when the BTS SFB is remoted from the BSC SFB (via some physical trunk line). If the MSC had been implemented on the same CPU/chassis that implements the
• NIC 321 would not have been necessary and would have been replaced by other functions that facilitate local message passing between BSC SFB 300 and its associated MSC SFB. Note that the interface between CILB 306 and either BSC SFB 300 or its associated MSC SFB remains substantially unchanged regardless whether their respective communication via CILB 306 is local or remote.
• the codes which implement the functions underlying the CILB may either co-reside on the same CPU/chassis with their respective BSC/BTS SFB's or may be remoted to their own CPU/chassis as necessary to fit processing, geographic location, or domain requirements of a cellular network.
• RTP real-time processor
• Fig. 6A is a diagram illustrating the relationship between the communication protocols between two SFB's such as BSC SFB 350 and BTS SFB 352, and the actual data exchange that takes place within a CILB between them. Note that although BTS and BSC SFB's are used in the example, the inventive CELB applies to facilitate communication between any two SFB's regardless of their relative locations in the network.
• BSC SFB 350 communicates with BTS SFB 352 using the Abis protocol, which is shown diagramatically in Fig. 6A as dotted line 354. Since BTS SFB 352 and BSC SFB 350 co-reside in the same CPU/chassis in the example of Fig. 6A, data communication between these two SFB's is achieved by local software functional block (SFB) communication (herein "LSC") using primitives implemented by the CILB beneath interface line 356. This communication is shown representatively in Fig. 6 A by line 370.
• SFB software functional block
• LSC local SFB communication
• Basic functionalities of a LSC consist of, among others, passing a unit of information known as a message between two SFB's. Note that this is the case irrespective whether the SFB's reside in the same task, as separate tasks within the same CPU, as tasks within separate CPU's across a bus, or as tasks on separate CPU's connected in a local area network.
• LSC may take advantage of message passing facilities of the underlying operating system (OS) that operates the CPU on which the LSC executes. Examples of such OS's are Unix, VxWorks, and VTRX.
• OS operating system
• connection-oriented services also known in certain context as virtual circuit services, allow communicating SFB's to establish a session during which messages associated with that session may be passed among the communicating SFB's.
• LSC supports, among others, the establishment and termination of sessions as well as the association of messages with a session.
• One implementation of the primitives for implementing the A interface between the LSC's and its respective SFB's are shown, for illustration purposes, in Appendix C. It will be apparent to those skilled in the art that these primitives, which are known in the industry, vary according to the specific interface implemented (e.g., A, ISDN, or the like).
• Fig. 6A shows LSC facilities 353(a) and 353(b), which facilitates communication via line 370. Note that since the SFB's of Fig. 6A co-reside in the same
• Interface line 356 delineates the configuration- independent portion of the CILB, i.e., that portion above interface line 356 which interacts with the SFB's in a consistent manner irrespective of network configuration, and the implementation details within the CILB below interface line 356. Those implementation details may be modified to ensure proper data routing between the SFB's in a specific network configuration.
• BSC SFB 350 and BTS SFB 352 are distributed in different CPU's/chassis. Communication between these two SFB's still preferably utilizes the Abis protocol (dotted line 354).
• the primitives below CILB line 356 change to facilitate remote communication.
• primitives may be thought of as functions that facilitate communication vertically up and down the stacks.
• a protocol is defined by the message structure (syntax), semantics, and message flows, and are represented as horizontal lines in Fig. 6A and Fig. 6B.
• a protocol stack may be thought of as a layering of applications such that each application layer performs a well defined function in the context of the overall communication subsystem.
• the primitives implementing the Abis stacks 361(a) and 361(b) at layer two utilizes LAPD.
• LAPD blocks 364A and 364B are implemented as layer two and El facilities are implemented as layer one.
• message passing is the preferred communication paradigm for local communication in the configuration of Fig. 6A.
• the primitives 360A and 360B above interface line 356 remain substantially unchanged in both Figs. 6A and 6B. Only the primitives below interface line 356 change responsive to changes in network configuration to ensure proper data routing. In this manner, the details regarding the actual data routing is hidden from the receiving and sending SFB's. Such data hiding makes the SFB's modular, thereby simplifying the job of developers of these major SFB's.
• Fig. 7 is a diagram illustrating, in one embodiment, a message passing paradigm for facilitating communication between SFB's in a configuration-independent manner.
• Fig. 7 there are shown three SFB's 400, 402, and 404.
• Each of SFB's 400, 402, and 404 may be instantiated from a single task that is intended for accomplishing a certain function, e.g., a block of codes for implementing a BTS.
• a certain function e.g., a block of codes for implementing a BTS.
• multiple instantiations of the BTS task are necessary to implement the software in all the BTS's.
• software functional blocks of codes 400, 402, and 404 may also represent instantiations of different task-implementing blocks of code.
• each task there is associated with each task a mailbox whose address is well- known to all the SFB's that need to communicate with instantiations of that task.
• a mailbox represents a section of memory to which messages may be posted for forwarding or retrieval.
• all the SFB's that instantiate from a given task are associated with the one mailbox with which the task is associated.
• each SFB may have associated with it its own mailbox. Note that a mailbox is necessary for receiving messages. If a SFB only sends messages, a mailbox is not absolutely necessary.
• the sending SFB needs to know the identity of the mailbox associated with the task from which the receiving SFB instantiates in order to post a message, a request, or data in general to the receiving SFB. Note that the sending SFB does not need to know the name or the specific location in the network of the receiving SFB. This is the case even though the SFB is the entity that is executed, and there may exist more than one SFB's associated with a mailbox.
• a BTS administration SFB (328) of Fig. 5 may post a message to a particular BTS manager SFB 322 (also of Fig. 5) by sending the message to the mailbox associated with the BTS manager task.
• the destination BTS manager SFB 322 which has been monitoring this mailbox, may then pick up the posted message from the mailbox.
• the destination BTS manager SFB 322 may either forward the message to another mailbox or reply with another message by posting it to the mailbox associated with the BTS administration task.
• the pseudocodes for sending as well as retrieving and processing of messages are shown in Fig. 7.
• the CILB may also be implemented via an interface function paradigm.
• Fig. 8 illustrates how multiple SFB's may utilize subroutines in a library of subroutines 450 to communicate in a configuration independent manner.
• SFB's 452 and 454 can make calls to library of subroutines 450 to link, either dynamically or at linking time, the subroutines therein that those SFB's need to communicate among each other.
• Examples of function calls to the library of subroutine 450 include calls to subroutines for sending messages, receiving messages, timing management, network management interfaces, and the like.
• each subroutine may be utilized by multiple SFB's. For example, a subroutine that reads or writes to files may be utilized by every SFB's that interacts with the disc drive.
• the manner in which these subroutines are called preferably remain substantially unchanged regardless of network configuration.
• the implementation details of how data is routed are preferably hidden in the subroutines from both the sending and the receiving SFB's. That way, the subroutines can be utilized by, for example, application developers without requiring any knowledge of its underlying data routing details and without having to take into account network configuration.
• neither the sending or the receiving SFB's, or the manner in which they communicate with the subroutines need to be substantially changed. Only the data routing details, which are hidden in the subroutines from both the sending and the receiving SFB's, need to be modified to ensure proper data routing when network configuration changes.
• this inventive aspect advantageously simplifies upgrade, maintenance, and network expansion since the major SFB's are left essentially substantially unchanged.
• Fig. 9A shows a multiple-layer communication stack for communicating among SFB's.
• the two SFB's (BSC SFB 490 and BTS SFB 492) communicate using application layer protocol, shown representatively by dotted line 494.
• Protocols are defined by the message structure (syntax), semantics, and message flows for communicating across the stacks in Fig. 9A.
• dotted line 494 does not represent the actual data communication path between BSC SFB 490 and BTS SFB 492. Instead, these SFB's call on primitives, which are functions for communicating down the stacks.
• the primitives utilize resources in the layers below interface line 500 of the CILB to facilitate communication between the SFB's.
• Data routing beneath interface line 500 of the CILB is implemented by a multiple layer stack comprising a LAPD layer (shown representatively by dotted line 496), which facilitates communication between LAPD SFB's 502(a) and 502(b).
• LAPD layer shown representatively by dotted line 496
• LAPD SFB's 502(a) and 502(b) further employ primitives to communicate down the stack to layer one SFB's 504(a) and 504(b), which actually transmit and receive the data on a transmission medium.
• Interface line 501 represents the delineation between the LAPD layer and the physical layer, which happens to be El in the example of Fig. 9A.
• data routing beneath interface line 501 includes an El layer (shown by line 503), which facilitates communication between El SFB's. If Tl had been used as the physical layer, communication between the SFB's above interface line
• interface line 501 would preferably remain substantially unchanged. Only the data routing details beneath interface line 501 need to change below interface line 501 when Tl is used instead of El. As is apparent, there may exist within one stack well-defined interfaces between a higher layer and the next lower layer to improve modularity and to simplify implementation and changes (for example, between BTS SFB 492 and LAPD SFB 502(b) or between LAPD SFB 502(b) and layer one SFB 504(b)).
• SFB 504(a) (as well as between LAPD SFB 502(b) and layer one SFB 504(b)) utilizes the interface function paradigm for their communication.
• the communication between BSC SFB 490 and LAPD SFB 502(a) (and likewise between BTS SFB 492 and LAPD SFB 5020b)) is implemented using message passing.
• Fig. 9B shows the communication, using the inventive configuration independent architecture technique, between a BSC SFB and an MSC SFB.
• Fig. 10 illustrates the message passing paradigm for communicating among different
• the BSC SFB 300 of Fig. 5 is used as an example although it should be kept in mind that the message passing paradigm may be utilized to facilitate configuration- independent communication among any SFB that is capable of communicating by posting messages.
• communication among the BTS SFB, the MSC SFB, the radio-dependent SFB's, and the remote communication SFB's may also be implemented by message passing.
• Fig. 10 shows BSC SFB 300, CILB 306 (which implements the A interface), and CILB 304 (which implements the Abis interface).
• BSC administration SFB implements the operation, administration, and management (OA&M) functions while BTS manager SFB handles BTS dependent functions within the BSC, such as configuring the individual BTS's.
• the channel manager SFB handles, among other functions, the allocation of radio channels within the BTS's.
• Handover manager SFB maintains performance statistics of individual radio frequencies, time slots in a BTS for the purpose of handover preparation and execution.
• Each of the aforementioned SFB's is associated with a mailbox having a well-known address to which messages from other SFB's may be posted.
• CILB 304 There is shown inside CILB 304 an Abis interface SFB 600 for implementing the details necessary to route data using the Abis protocol.
• Abis SFB 600 is associated with a mailbox MBX4 whose address is also well-known.
• CILB block 306 includes an A- interface SFB 602 for implementing the details necessary to route data using the A interface.
• A-interface SFB 602 is associated with a mailbox MBX1 having a well-known address to which messages from other SFB's, e.g., SFB's inside BSC SFB 300 may be posted.
• the mailbox associated with a SFB may either be specifically associated with the SFB itself or be associated with the task underlying the SFB, and all SFB's which instantiate from that task are associated with the same mailbox.
• routing table associated with each CPU.
• the routing table furnishes information to facilitate data routing in a particular network configuration.
• the data routing information may then be used by the configuration-specific CILB codes to correctly forward messages received from the sending software function block.
• the manner in which the sending SFB sends its message preferably remains substantially unchanged across different network configurations. In particular, it is preferable that the manner in which the sending SFB addresses its messages remains substantially unchanged.
• codes in the CILB cause the CPU to first consult a routing table to determine whether it is necessary to route the message to a mailbox associated with an intermediate handler routine.
• the intermediate handler routine which is coded for a particular network configuration and whose data routing details are hidden from both the sending and receiving SFB's, is then responsible for forwarding that message to the appropriate destination mailbox in the network.
• FIG. 11 shows an example of a routing table 630 associated with a CPU in which there are two columns, 650 and 652.
• Column 650 shows the identity of the mailbox to which a sending SFB desires to post a message.
• Column 652 shows a corresponding identity of a mailbox associated with an intermediate handler routine to which the message must first be posted.
• codes in the CILB causes the CPU handling the posting of that message to first consult with routing table 630 to determine whether this message should first be routed to a mailbox associated with an intermediate handler routine.
• routing table 630 messages to mailbox MBXl should first be routed to mailbox MBYl.
• the intermediate handler routine associated with mailbox MBYl will then route the message according to its knowledge of the specific network configuration. The use of intermediate handler routines is explored in greater details in Figs. 12 and 13.
• routing tables and intermediate handler routines advantageously hides the configuration-specific data routing details from both the sending and the receiving SFB's. From the perspective of the sending SFB, all it needs to do is post a message to destination mailbox, e.g., mailbox MBXl. Knowledge regarding whether the SFB associated with that mailbox MBXl is remote or local with respect to the sending SFB and how that message should be routed in a given network configuration is hidden by the use of routing table 630 and intermediate handler functions associated with mailbox MB Y 1.
• routing table 630 for consistency. For example, those remoted from the sending SFB may have corresponding intermediate handler mailboxes while those local to the sending SFB have, as corresponding mailboxes, their own mailbox ID's. Other methods of routing may be utilized in place of routing table 630. For example, routing based on spanning tree or using the Dykstra algorithm has been contemplated as suitable alternatives.
• Fig. 12 illustrates the communication between the BSC administration SFB 700 and A- interface SFB 602 when these two SFB's are remoted from one another.
• A-interface SFB 602 is implemented on an El card 702 separate from CCPU card 704.
• CCPU cards For further information regarding CCPU cards, reference may be made to the aforementioned co- pending patent applications WAVEP001.P, 08/434,554, 08/434,598, and 08/434,597.
• FIFO block 706 is preferably implemented on El card 702 itself.
• intermediate handler function blocks 708 and 710 for facilitating remote communication across FIFO 706.
• Intermediate handler function block 708 handles the communication with CCPU card 704 while intermediate handler function block 710 facilitates communication with El card 702.
• A-interface SFB 602 wishes to post a message to BSC administration software function block 700, it sends a message to the mailbox associated with the BSC administration software function block 700, i.e., to mailbox MBX2.
• the CPU on El card 702 Before the message is routed to mailbox MBX2, the CPU on El card 702 first consults a routing table 714 to determine whether the message should first be posted to a mailbox associated with an intermediate handler function (as would be the case if the destination SFB is remoted or if there are multiple instantiations of the same task).
• Routing table 714 is typically stored in the persistent storage on the chassis, such as a hard disk, flash memory, and the like (shown by element 712 in Fig. 12). A sample routing table is shown as table 714 in Fig. 12. Routing table 714 indicates that messages posted to a mailbox MBX2 should first be posted to mailbox MBX 21 which, as shown in Fig. 12, is associated with intermediate handler function block 708. Therefore, the message will first be routed to mailbox MBX21. The message sent to mailbox MBX21 preferably includes information regarding the final destination for the message, i.e., the identity of mailbox MBX2.
• Intermediate handler function block 708, which monitors the address associated with mailbox MBX21, then retrieves the message from mailbox MBX21 and forwards it to FIFO 706 to be subsequently retrieved by intermediate handler function 710. Using the destination mailbox MBX2 in the message retrieved, intermediate handler function 710 then consults a routing table 718 to determine how to best route the message it has just retrieved from FIFO block 706. Routing table 718 is preferably kept in the persistent storage facility on CCPU card 704 (shown as element 717). Since mailbox MBX2 resides on CCPU card 704, no entry is required in routing table 718.
• intermediate handler block 710 forwards the message it retrieves from FIFO block 706 directly to mailbox MBX2 in the same CPU/chassis using local data routing to be retrieved by BSC administration SFB 700.
• BSC administration SFB 700 may send a message to mailbox MBXl associated with A-interface SFB 602 by first consulting routing table 718, which directs the message to be routed to mailbox MBX20. That message is then picked up by intermediate handler function 710 and forwarded to FIFO 706 to be retrieved by intermediate handler function 708. Using the destination mailbox MBXl in the message retrieved, intermediate handler function 708 then consults routing table 714, which reveals that messages posted to mailbox MBXl is local from the perspective of intermediate handler function 708, causing the message to be forwarded to mailbox MBXl locally by message passing.
• A-interface SFB 602 which monitors the address of mailbox MBXl, then picks up the message. Note that as far as A-interface SFB 602 and BSC administration SFB 700 are concerned, the format of the message sent and the address of the destination mailbox need not be changed to accommodate changes in network configuration.
• the internal details regarding data routing in a configuration specific manner are handled by the intermediate handler blocks 708 and 710, using their associated routing tables 714 and 718, as well as by FIFO 706.
• Fig. 13 illustrates the communication between a single BSC administration SFB 800 and three BTS manager SFB's 804, 806, and 808, which are implemented on three discrete CCPU cards.
• Multiple instantiations of the BTS manager task may exist in different CPU's to handle different subsets of BTS's to increase the total number of BTS's that a single BSC can manage.
• BTS manager SFB 804 may handle BTS's 1 through 6
• BTS manager SFB 806 may handle BTS's 7 through 12
• BTS manager SFB 808 may handle BTS's 13 through 18. Note that each instantiation of the BTS manager task is typically capable of handling a finite number of BTS's.
• BTS's are added and additional BTS manager SFB's must be added as well to facilitate scaling.
• BTS manager SFB's 804, 806, and 808, being configuration-independent, have no knowledge of each other, they all associate themselves with the same mailbox MBX6.
• BSC administration SFB 800 communicates with all BTS manager SFB's, which may be distributed across multiple CPU's/chassis. It is important, however, that messages from BSC administration SFB 800 get forwarded to the correct instantiation irrespective of network configuration. In the context of the above example, it is important that messages intended for BTS 5 is forwarded to BTS manager SFB 804 (which is implemented on CCPU2) irrespective of where in the network this BTS manager SFB is implemented.
• BTS manager SFB 800 has associated with it a mailbox MBX22, whose address is known in a routing table 820.
• BSC administration SFB 800 When BSC administration SFB 800 wishes to send a message to BTS manager SFB 806, it merely posts a message to a mailbox associated with the task that instantiates BTS manager SFB 806, i.e., mailbox MBX6. Note that BSC administration SFB 800 does not need to know the data routing details of any specific network configuration to post messages to the well-known address of mailbox MBX6.
• the CPU associated with card CCPU1 then consults routing table 820 which reveals that messages posted to mailbox MBX6 should be routed instead to mailbox MBX22, which is associated with BTS manager intermediate handler function block 810. Consequently, the message intended for mailbox MBX6 is forwarded to mailbox MBX22.
• BTS manager intermediate handler function block 810 which monitors the address associated with mailbox MBX22, then picks up the message and consults another routing table 830, which reveals that the BTS manager SFB that handles BTS 8 resides on CCPU3. BTS manager intermediate handler function 810 then forwards the message to card CCPU3, or more particularly to CCPU intermediate handler function 832 thereon.
• the CPU on CCPU3 then consults a routing table 840 which reveals that mailbox
• MBX6 is implemented on the same CCPU as intermediate handler function 832.
• the communication between CCPU intermediate handler function 832 to mailbox MBX6 is therefore local, which may be by message passing in one embodiment.
• BTS manager SFB BTS manager SFB
• a BTS manager SFB 804 wishes to send a message to BSC administration SFB 800, it sends that message to mailbox MBX2, which is associated with the BSC administration task and which has a well-known address.
• the CPU which runs BTS manager SFB 804 first consults a routing table 850, which reveals that messages intended for mailbox MBX2 should first be routed to a mailbox MBX23, which is associated with CCPU intermediate handler function 852.
• routing tables 840 and 850 are substantially similar.
• CCPU intermediate handler function 852 which monitors the address of mailbox
• MBX23 picks up the message and forwards it to BTS manager intermediate handler function 810.
• the CPU on CCPU1 card then consults its associated routing table 830, which reveals that mailbox MBX2 (it knows that the message is intended for mailbox MBX2 from the content of the message) is local to CCPU1 card. Therefore, the message is forwarded to mailbox MBX2 on CCPU card in a local manner, which may be message passing in one embodiment for retrieval by BSC administration SFB 800.
• Fig. 10 Note that the architecture model of Fig. 10 is still enforced regardless whether the BTS manager SFB's are remoted across different CCPU cards as are shown in Fig. 13, are all implemented on a remote CCPU card relative to BSC administration SFB 800, or all co-reside with the BSC administration SFB 800 on the same CPU/chassis. All BSC administration SFB 800 has to do to send messages to a particular BTS manager SFB is to post those messages to the one well-known BTS manager mailbox, i.e., MBX6.
• the internal details regarding how the data should be routed among the CCPU cards in a specific network configuration are handled by the intermediate handler functions. When the system configuration changes, it is the intermediate handler function codes that are changed.
• BSC administration SFB 800 There is no need for changes in the codes making up either the BSC administration SFB 800, BTS administration SFB's 804, 806, and 808, or the manner in which these SFB's address their messages. Further, the communication between BSC administration SFB 800 and the BTS manager SFB's is consistent from the perspective of the SFB's regardless of network configuration.
• BCF Base Station Control Function
• BSC Base station Controller
• BSS Base Station Subsystem
• BTS Base Transceiver Station
• CC Call Control Management
• CCPU Cellular CPU
• cPBX cellular Private Branch Exchange
• DSP Digital Signal Processing GMSC: Gateway for MSC
• GSM Global Systems for Mobile Communication
• HLR Home Location Registry
• LAPD-M Link Access Protocol on the Dm (control) channel
• LSC Local Software Functional Block Communication
• PSTN Public Switched Telephone Network
• PBX Private branch exchange
• SMS Short Message Services
• TDM data Time Division Multiplexed Data
• TRAU Transcoder-Rate Adapter Unit
• TRX Transceiver
• VLR Visitor Location Registry
• VME An industry standard bus for interconnecting components wPBX: wired PBX APPENDTX R
• European Telecommunications Standards Institute "European digital cellular telecommunications system (Phase 2V. Base Station Controller - Base Transceiver Station (BSC - BTS ⁇ l interface Laver 3 specification CGSM 08.58V . 1994, Valbonne - France.
• European Telecommunications Standards Institute "European digital cellular telecommunications system (Phase 2): Mobile Application Part fMAP) specification (GSM 09.02V . 1994, Valbonne - France.
• SIZE_SS7_SP_CFG sizeof(tss7_sp_cfg)
• SIZE_SS7_SP_STA_CFM sizeof(tss7_sp_sta_cfm)
• SIZE_SS7_SP_STS_CFM sizeof(tss7_sp_sts_cfm)
• SIZE_SS7_SD_STA_IND sizeof(tss7_sd_sta_ind)
• SIZE_SS7_QI_STA_REQ sizeof(tss7_qi_sta_req)
• SIZE_SS7_QI_STA_CFM sizeof(tss7_qi_sta_cfm)
• SIZE_SS7_QI_STS_CFM sizeof(tss7_qi_sts_cfm) #endif typedef struct ⁇ tlwMsgHdr Hdr; ul6 suld; ul6 spld; ul6 ssn; u8 type;
• SIZE_SS7_SP_UBND_REQ sizeof(tss7_sp_ubnd_req)
• ⁇ tss7_sp_udat_req #define SIZE_SS7_SP_UDAT_REQ(len) (sizeof(tss7_sp_udat_req) + len) typedef struct ⁇ tlwMsgHdr Hdr; ul6 Suld; u32 OPc; I* Originating Point Code */ tss7_sp_addr Cd; /* Called Address */ tss7_sp_addr Cg; /* Calling Addrress */ u 16 Len; /* Length of Data Field */ u8 Data . O]; ⁇ tss7_sp_udat_ind;

Landscapes

• Engineering & Computer Science (AREA)
• Computer Networks & Wireless Communication (AREA)
• Signal Processing (AREA)
• Mobile Radio Communication Systems (AREA)

Applications Claiming Priority (5)

Publications (1)

Family

ID=26675657

Family Applications (1)

Country Status (5)

Cited By (1)

Families Citing this family (2)

Family Cites Families (4)

• 1996
  • 1996-05-03 EP EP96920134A patent/EP0824832A1/de not_active Withdrawn
  • 1996-05-03 AU AU58534/96A patent/AU717297B2/en not_active Ceased
  • 1996-05-03 CN CN 96195052 patent/CN1092904C/zh not_active Expired - Fee Related
  • 1996-05-03 WO PCT/US1996/006306 patent/WO1996035298A1/en not_active Application Discontinuation
  • 1996-05-03 CA CA002219879A patent/CA2219879A1/en not_active Abandoned

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events