Abstract:
System and method for correlating multiple frames of data associated with a single call into a call record. One embodiment comprises correlating data in a radio access network by capturing data passing to and from a radio network controller, identifying ATM Adaptation Layer type 5 (AAL5) frames within the data, assigning a first call identifier to the AAL5 frames, identifying ATM Adaptation Layer type 2 (AAL2) frames within the data, assigning a second call identifier to the AAL2 frames, and combining AAL2 frames and AAL5 frames having a same first call identifier and a same second call identifier into a call record. The data passing to and from the first radio network controller may be data passing over an Iub interface between a Node B and the radio network controller or data passing over an Iur interface between two radio network controllers.

Description:
[0001]    This application claims the benefit of U.S. Provisional Application No. 60/909,295, filed on Mar. 30, 2007, entitled System and Method for Real-Time Correlation of AAL2 and AAL5 Messages for Calls in UTRAN, which application is hereby incorporated herein by reference. 
     
    
     TECHNICAL FIELD 
       [0002]    The present invention relates generally to a system and method for monitoring messages in a wireless system, and more particularly to a system and method for capturing and correlating related messages captured from the Iub and Iur interfaces of a UTRAN. 
       BACKGROUND 
       [0003]    The Universal Mobile Telecommunications System (UMTS) is a third-generation (3G) mobile phone technology standardized first by the European Telecommunications Standards Institute (ETSI) and now by the 3rd Generation Partnership Project (3GPP). UMTS carries both circuit switched (CS) and packet switched (PS) traffic using Wideband Code Division Multiple Access (W-CDMA) as its air interface. The description of the network components and protocols used in UMTS are well known to those of ordinary skill in the art and are available to the public from 3GPP, ETSI, and other sources. The UMTS network architecture consists of three domains: Core Network (CN), UMTS Terrestrial Radio Access Network (UTRAN), and User Equipment (UE). 
         [0004]    The Core Network provides switching and routing for user traffic and provides network management functions. The Core Network architecture is based on the GSM network with GPRS. The UTRAN provides the air interface access to subscribers&#39; UE. Base stations in the UTRAN are referred as Node-Bs, and the control equipment for the Node-Bs is called a Radio Network Controller (RNC). The UMTS User Equipment communicates via the WCDMA air interface to the Node-Bs. The UE may be attached to either the PS domain or CS domain or both. The UE is capable of simultaneously using PS services and CS services. 
         [0005]    The Asynchronous Transfer Mode (ATM) is used for data transmission in UMTS. The ATM layer multiplexes and demultiplexes and routes ATM cells, and ensures their sequence from end to end. The ATM Adaptation Layers (AAL) are responsible for the creation and reception of payloads through the lower layers of ATM on behalf of different applications. ATM Adaptation Layer type 2 (AAL2) handles circuit-switched connections and packet connection protocol AAL5 is designed for data delivery. 
         [0006]    One disadvantage of the prior art is the difficulty in evaluating service levels for individual subscribers. Because multiple UEs are communicating with Node Bs and RNCs at the same time, thousands of data and control messages per second can be passed between a Node B and an RNC and between RNCs. These messages follow several different protocol formats depending upon the purpose of the message. As a result, the messages passing on interfaces in the UTRAN do not provide sufficient information to determine which messages are related to the same subscriber. 
         [0007]    A second disadvantage of the prior art is the lack of a capability to compile messages for a specific UE call into a single call record in real-time or near real-time. 
       SUMMARY OF THE INVENTION 
       [0008]    These and other problems are generally solved or circumvented, and technical advantages are generally achieved, by embodiments of the present invention which provides a system and method for capturing messages from the Iur and Iub interfaces in a UTRAN and correlating the messages into call records for each user. 
         [0009]    In accordance with an embodiment of the present invention, a method for correlating data in a radio access network comprises capturing data passing to and from a first radio network controller, identifying ATM Adaptation Layer type 5 (AAL5) frames within the data, assigning a first call identifier to the AAL5 frames, identifying ATM Adaptation Layer type 2 (AAL2) frames within the data, assigning a second call identifier to the AAL2 frames, and combining AAL2 frames and AAL5 frames having a same first call identifier and a same second call identifier into a call record. The data passing to and from the first radio network controller may comprise data passing over an Iub interface between a Node B and the first radio network controller or data passing over an Iur interface between the first radio network controller and a second radio network controller. The call record comprises service data units (SDUs) associated with a single call. The method may further comprise deciphering the AAL2 frames, and reassembling service data units (SDUs) carried in the AAL2 frames. Capturing data passing to and from a first radio network controller may further comprise capturing data passing from the first radio network controller to a first base station that is in communication with user equipment, and capturing data passing from the first radio network controller to a second base station that is in communication with the user equipment, wherein the first radio base station and the second radio base station are in communication with the user equipment at the same time. 
         [0010]    In accordance with another embodiment of the present invention, a system for correlating data in a radio access network comprises a first correlation engine coupled to interfaces between components of the radio access network, wherein the first correlation engine receives ATM Adaptation Layer type 2 (AAL2) frames and ATM Adaptation Layer type 5 (AAL5) frames from the interfaces, a second correlation engine coupled to the first correlation engine, wherein the second correlation engine receives AAL2 frames from the first correlation engine, and a third correlation engine coupled to both the first and second correlation engines, wherein the third correlation engine receives AAL5 frames mapped to a first call identifier from the first correlation engine and receives AAL2 frames mapped to a second call identifier from the second correlation engine. The second correlation engine may further comprise a decipher engine, wherein the decipher engine decodes and deciphers the AAL2 frames, and a reassembly engine, wherein the reassembly engine assembles data carried in the AAL2 frames into service data units (SDUs). The first correlation engine maps parameters of a Node B Application Part (NBAP) protocol, a Access Link Control Application Part (ALCAP) protocol, and/or a Radio Network Subsystem Application Part (RNSAP) protocol to the first call identifier. The second correlation engine maps parameters of a Radio Resource Control (RRC) protocol to the second call identifier. The first correlation engine may be coupled to Iub and Iur interfaces in a UTRAN. 
         [0011]    In accordance with another embodiment of the present invention, one or more processors running software applications may be used to correlate data frames in a radio access network The system comprises computer-readable medium having computer-executable instructions for combing data associated with calls in a radio access network, said computer-executable instructions comprising means for capturing data from the radio access network, means for identifying ATM Adaptation Layer type 5 (AAL5) frames within the data, means for assigning a first call identifier to the AAL5 frames, means for identifying ATM Adaptation Layer type 2 (AAL2) frames within the data, means for assigning a second call identifier to the AAL2 frames, and means for combining AAL2 frames and AAL5 frames having a same first call identifier and a same second call identifier into a call record. The computer-readable medium further has computer-executable instructions comprising means for capturing data passing to and from a radio network controller over one or more Iub interfaces and one or more Iur interfaces in the radio access network. The computer-executable instructions further comprise means for deciphering the AAL2 frames, and means for reassembling service data units (SDUs) carried in the AAL2 frames. The computer-executable instructions may further comprises means for capturing data passing from a first base station in the radio access network to user equipment, and means for capturing data passing from second base station in the radio access network to the user equipment. 
         [0012]    The present invention allows a system to analyze network performance on a real-time or near real-time basis for specific calls and specific users. The present invention also captures messages for a single call from multiple interfaces and compiles the messages having different protocols and formats into a call record for a specific user. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0013]    For a more complete understanding of the present invention, and the advantages thereof, reference is now made to the following descriptions taken in conjunction with the accompanying drawings, in which: 
           [0014]      FIG. 1  illustrates monitoring equipment coupled to UMTS network interfaces according to embodiments of the invention; 
           [0015]      FIG. 2  is a protocol stack for an Iub interface; 
           [0016]      FIG. 3  is a protocol stack for an Iur interface; 
           [0017]      FIG. 4  illustrates the relationship among different correlation engines according to embodiments of the invention; 
           [0018]      FIG. 5  illustrates a class diagram of an embodiment of a UTRAN RRC Manager according to embodiments of the invention; 
           [0019]      FIG. 6  illustrates the relationship between an RLC/MAC Reassembly Engine and correlation engines according to embodiments of the invention; 
           [0020]      FIG. 7  illustrates the architecture of an RLC/MAC Reassembly Engine according to embodiments of the invention; 
           [0021]      FIG. 8  is a class diagram of a RLC/MAC Reassembly Engine according to embodiments of the invention; and 
           [0022]      FIG. 9  is a block diagram illustrating tracking of messages according to one embodiment of the invention. 
       
    
    
     DETAILED DESCRIPTION 
       [0023]    The present invention provides many applicable inventive concepts that can be embodied in a wide variety of specific contexts. The specific embodiments discussed are merely illustrative of specific ways to make and use the invention, and do not limit the scope of the invention. 
         [0024]      FIG. 1  illustrates a portion of UTRAN  100  comprising Node B  101  and Radio Network Controllers (RNC)  102  and  103 . Node B  101  communicates with RNC  102  via Iub interface  104 . RNCs  102  and  103  communicate with each other via Iur interface  105 . Node B  101  is in communication with User Equipment (UE)  106 . Whenever UE  106  makes or receives a call, signaling messages are exchanged between Node B  101  and RNC  102  over Iub interface  104  and between RNCs  102  and  103  over Iur interface  105 . The present invention tracks protocol messages carried on interfaces  104  and  105  using UTRAN monitoring equipment  107 , which is non-intrusively coupled to the interfaces to capture substantially all of the protocol messages traveling across the interfaces. UTRAN monitoring equipment  107  identifies the messages belonging to a single call and correlates those messages into one call record for each call it detects. 
         [0025]      FIG. 2  illustrates the protocol stack used on the Iub interface in a UTRAN network.  FIG. 3  illustrates the protocol stack used on the Iur interface in a UTRAN network. UTRAN implements an ATM infrastructure for the Iub and Iur interfaces. UTRAN uses both AAL2 and AAL5 adaptations on top of the ATM layer. Node B Application Part (NBAP), Access Link Control Application Part (ALCAP) and Radio Network Subsystem Application Part (RNSAP) protocol messages are carried over AAL5 channels, and (Radio Resource Control) RRC protocol messages are carried over AAL2 channels. 
         [0026]    In one embodiment of the invention, two correlation engines running in UTRAN monitoring equipment  107  correlate messages into call records. They are the UTRAN Call Id (CID) engine, an AAL5 correlator, and the UTRAN RRC manager, AAL2 correlator. The correlation engines may be, for example, software applications running on a processor in monitoring equipment  107 . 
         [0027]    UTRAN CID Engine—Call Correlation 
         [0028]    The UTRAN CID Engine assigns a unique call identifier (Call Id) to every AAL5 message captured by UTRAN monitoring equipment  107 . The Call Id is derived from the RNC identifier and the uplink scrambling code assigned to UE  106 . The format of the AAL Call Id is as follows: 
         [0000]    
       
         
               
             
               
               
               
             
           
               
                   
               
               
                 AAL5 Call Id format 
               
             
          
           
               
                   
                 RNC Id 
                 Uplink Scrambling Code 
               
               
                   
                   
               
               
                   
                 4 bytes 
                 4 bytes 
               
               
                   
                   
               
             
          
         
       
     
         [0029]    All AAL5 messages belonging to the same call are associated to the same uplink scrambling code and, therefore, will have the same AAL5 Call Id. Accordingly, all NBAP, ALCAP, and RNSAP protocol messages for a single call will have the same AAL5 Call Id. The UTRAN CID Engine correlates the various AAL5 protocols as follows. 
         [0030]    NBAP Protocol Correlation 
         [0031]    All call-based NBAP signaling begins with a NBAP Radio Link (RL) Setup Request message, which is sent from RNC  102  to Node B  101 . This message includes the uplink scrambling code assigned to UE  106 . An AAL5 Call Id is generated and assigned to the NBAP RL Setup Request message. The NBAP RL Setup Request message also includes a Controlling RNC (CRNC) Communication Context Id (CCID) that Node B  101  should use in its response to the NBAP RL Setup Request. The UTRAN CID Engine maintains a map that links the CCID to the AAL5 Call Id: 
         [0000]    
       
         
               
             
               
               
               
             
           
               
                   
               
               
                 CCID-Call Id Map 
               
             
          
           
               
                   
                 CCID 
                 AAL5 Call Id 
               
               
                   
                   
               
               
                   
                 4 bytes 
                 8 bytes 
               
               
                   
                   
               
             
          
         
       
     
         [0032]    Node B  101  responds to the NBAP RL Setup Request with a NBAP RL Setup Response message, which includes the CCID and a Node B Communication Context Id (NBId). From that point on, the NBId is used by RNC  102  in all communication with Node B  101  for this call. Using the CCID, UTRAN CID Engine does a lookup in the CCID-Call Id Map to identify the AAL5 Call Id for the call. The AAL5 Call Id found in the CCID-Call Id Map is assigned to the NBAP RL Setup Response message. The UTRAN CID Engine also maintains a map that links the NBId to the AAL5 Call Id: 
         [0000]    
       
         
               
             
               
               
               
             
           
               
                   
               
               
                 NBId-Call Id Map 
               
             
          
           
               
                   
                 NBId 
                 AAL5 Call Id 
               
               
                   
                   
               
               
                   
                 4 bytes 
                 8 bytes 
               
               
                   
                   
               
             
          
         
       
     
         [0033]    With the aid of the CCID and NBAP Call Id maps, all NBAP messages from NBAP RL Setup to NBAP RL deletion will be assigned to the same AAL5 Call Id. NBId and CCID are unique only per Node B, so a separate NBId-Call Id map is maintained for each Node B. 
         [0034]    Macro-Diversity and Micro-Diversity Handling 
         [0035]    Micro-diversity is the addition of a radio link in the same Node B. This procedure is initiated by a NBAP RL Addition Request, which includes the same NBId as in the NBAP RL Setup Response message. So the UTRAN CID Engine again uses the NBId to assign the AAL5 Call Id to the NBAP RL Addition Request messages. NBAP RL Addition Response messages have the same CCID as in the NBAP RL Setup Request message and, therefore, are correlated in a similar fashion. 
         [0036]    Macro-diversity is the addition of a radio link in a different Node B. This procedure is initiated by a NBAP RL Setup Request message. From the UTRAN CID Engine point of view, there is no difference between the addition of the first radio link versus the addition of a 2 nd  or N th  radio link because the signaling flow is exactly the same. Since the CCID-Call Id map and NBId-Call Id map are maintained per Node B, any new radio link in a different Node B would involve adding new entries to the CCID-Call Id and NBId-Call Id maps maintained for that Node B. Since the uplink scrambling code is still the same, the UTRAN CID Engine will assign the same AAL5 Call Id in all macro-diversity and micro-diversity scenarios. 
         [0037]    Change of Uplink Scrambling Code 
         [0038]    UE  106  operates in various service states depending on the type of physical channel that the UTRAN network has allocated. Transitions between different states are based on inactivity timers and the amount of traffic that UE  106  or the UTRAN network wants to send. UE  106  operates in Cell-DCH (Dedicated Channel) state to exchange relatively large amounts of data. In Cell-DCH state, a dedicated channel with an individual code is assigned to UE  106 . Data can be sent to and from UE  106  without prior reservation of resources. For transmission of relatively small amounts of data, UE  106  transitions to Cell-FACH state, in which UE  106  sends receives data via the Random Access Channel (RACH) and Forward Access Channel (FACH). The RACH and FACH channels are shared between several devices. 
         [0039]    The NBAP procedures are used by RNC  102  to setup radio links and put UE  106  into CELL-DCH state. Based on RRC measurement reports, the RNC may delete all radio links and set UE  106  in CELL-FACH state. After a period of time, RNC  102  may setup new radio links and UE  106  will be back in CELL-DCH state. This pattern of toggling back and forth between CELL-DCH and CELL-FACH state can happen very frequently when UE  106  is making a PS call. Every time UE  106  goes back to CELL-DCH state, it may be assigned a uplink scrambling code that is different than the last uplink scrambling code it used. Because the AAL5 Call Id is based on the uplink scrambling code, it is possible during a single PS call to have several NBAP legs with each leg carrying a unique uplink scrambling code and, therefore, a unique AAL5 Call Id for each NBAP leg. 
         [0040]    The UTRAN CID Engine only guarantees unique a AAL5 Call Id for the AAL5 messages between the establishment of the first radio link and the termination of the last radio link. Since the RRC leg of a call will contain the uplink scrambling code changes, the UTRAN RRC manager—the AAL2 correlator—will provide information to combine all the legs of a PS call into a single call record. 
         [0041]    ALCAP Protocol Correlation 
         [0042]    ALCAP signaling begins with an Establishment Request (ERQ) message followed by an Establishment Response (ECF) message by the receiver. Certain NBAP messages that establish a DCH-Id, such as the NBAP RL Setup Response message, will have a Binding Id parameter for every DCH-Id being established. For every DCH-Id that is established, an ALCAP ERQ message is sent with a Served User Generated Reference (SUGR) parameter that exactly equals the Binding Id in the NBAP message for that DCH-Id. The ERQ message also has a Path Id/Channel Id combination that translates to a unique VPI/VCI/CID channel. This is the channel that will receive the AAL2 frames for that DCH-Id. This allows the present invention to established a correlation from the NBAP message that initiates the ALCAP to the various ALCAP messages and the AAL2 channels that have been setup. All of these may be tied to the same AAL5 Call Id using a map. 
         [0043]    The ALCAP protocol has two parameters, Originating Signaling Association Id (OSAId) and Destination Signaling Association Id (DSAId), that are similar to the NBId and CCID parameters in the NBAP protocol. Accordingly, similar OSAId-AAL5 Call Id maps and DSAId-AAL5 Call Id maps are setup per Node B. A mapping is also setup between the identified VPI/VCI/CID and the associated AAL5 Call Id. Any AAL2 frame on that VPI/VCI/CID will be tagged with the associated AAL5 Call Id (or the uplink scrambling code) and the DCH-Id. The OSAId, DSAId, and VPI/VCI/CID maps are set up as follows: 
         [0000]    
       
         
               
             
               
               
               
             
           
               
                   
               
               
                 OSAId-Call Id Map 
               
             
          
           
               
                   
                 OSAId 
                 AAL5 Call Id 
               
               
                   
                   
               
               
                   
                 4 bytes 
                 8 bytes 
               
               
                   
                   
               
             
          
         
       
     
         [0000]    
       
         
               
             
               
               
               
             
           
               
                   
               
               
                 DSAId-Call Id Map 
               
             
          
           
               
                   
                 DSAId 
                 AAL5 Call Id 
               
               
                   
                   
               
               
                   
                 4 bytes 
                 8 bytes 
               
               
                   
                   
               
             
          
         
       
     
         [0000]                                          VPI/VCI/CID - Call Id - DCH-Id Map            VPI/VCI/CID   AAL5 Call Id   DCH-Id               8 bytes   8 bytes   2 bytes                    
With the help of these maps the ALCAP legs and the established DCH channels can be tied to a AAL5 Call Id.
 
         [0044]    RNSAP Protocol Correlation 
         [0045]    RNSAP is transported via connection-oriented SCCP on IuR interface  105 . The SCCP connection begins with SCCP Connection Request (CR) and SCCP Connection Confirmed (CC) messages followed by DT1 messages 
       IuR: SCCP CR (Source Local Reference=x); 
     IuR: SCCP CC (Source Local Reference=y, Destination Local Reference=x); 
       [0046]    IuR: SCCP DT1 (Destination Local Reference=y)-RNSAP Radio Link Setup Request. 
         [0047]    The messages in the RNSAP protocol are often the same as the NBAP protocol messages, such as Radio Link Setup Request and Response. The RNSAP Radio Link (RL) Setup Request message contains an uplink-scrambling code like the NBAP RL Setup Request message from which the AAL5 Call Id is generated. A map is then created which maintains the mapping between the source local reference and the AAL5 Call Id as well as the destination local reference and the AAL5 Call Id. This mapping is maintained per RNC using the RNC point code (PC) that is present in the SCCP message. 
         [0000]    
       
         
               
             
               
               
               
             
           
               
                   
               
               
                 Source Reference-Call Id Map 
               
             
          
           
               
                   
                 RNC PC + Source Reference 
                 AAL5 Call Id 
               
               
                   
                   
               
               
                   
                 8 bytes 
                 8 bytes 
               
               
                   
                   
               
             
          
         
       
     
         [0000]    
       
         
               
             
               
               
               
             
           
               
                   
               
               
                 Dest Reference-Call Id Map 
               
             
          
           
               
                   
                 RNC PC + Dest Reference 
                 AAL5 Call Id 
               
               
                   
                   
               
               
                   
                 8 bytes 
                 8 bytes 
               
               
                   
                   
               
             
          
         
       
     
         [0048]    The RNSAP RL Setup Response message contains DCH-Id and Binding Id as in the NBAP RL Setup Response message. This is used to correlate the ALCAP protocol messages and the dedicated AAL2 channels on IuR interface  105 . 
         [0049]    Data transmissions between Node B  101  and RNC  102  are defined by dedicated transport channel (DCH) frame protocol (FP) procedures on Iub interface  104 . In particular, the FP procedures define uplink (from a Node B to an RNC) and downlink (from an RNC to a Node B) data frames. Each uplink or downlink data frame comprises a header portion and a payload portion, which is also referred to as a protocol data unit (PDU), and supports multiplexing a number of DCHs in the payload portion. Each DCH comprises Transport Blocks (TBs), which are the basic units used to convey data. The size and number of TBs in each DCH of a data frame is identified by an associated transport format indicator (TFI) in the header portion of the data frame. The DCH FP procedures also apply to communications between RNCs  102  and  103  across Iur interface  105 . 
         [0050]    Using the mappings illustrated above, the UTRAN CID Engine correlates all NBAP, ALCAP and RNSAP messages that cross Iub and Iur interfaces  104  and  105 . The UTRAN CID Engine also associates every FP Data Frame on DCH to a AAL5 Call Id (or uplink scrambling code) and DCH-Id. 
         [0051]    UTRAN RRC Manager—Call Correlation 
         [0052]      FIG. 4  illustrates the relationship between UTRAN CID Engine  401 , the AAL5 correlator, and UTRAN RRC Manager  402 , the AAL2 correlator. UTRAN RRC Manager  402  tracks the entire RRC leg of a call. It receives the raw AAL2 FP DATA frames from UTRAN CID Engine  401 , which, as described above, will contain an AAL5 Call Id and DCH-Id if the frame was received on a DCH. UTRAN RRC Manager  402  performs the following functions:
       Assign a unique Primary Call Id to every Transport Block that is present in an AAL2 frame;   Associate every Transport Block to its corresponding Radio Bearer Id (RB Id) with the help of DCH-Id;   Decipher the AAL2 frame with the assigned Primary Call Id and RB Id;   Reassemble the AAL2 frame with the assigned Primary Call Id and RB Id; and   Deliver the reassembled RRC Message with the Primary Call Id and the optional AAL5 Call Id.
 
An AAL5 Call Id will be present if the FP DATA frame was transmitted on a DCH. The AAL5 Call Id will be the Secondary Call Id in the context of the UTRAN RRC Manager.
         
         [0058]    UTRAN RRC Manager  402  then forwards the RRC messages with Call Id to Master Call Correlator  403 . AAL5 messages are directly forwarded by UTRAN CID Engine  401  to Master Call Correlator  403 . The Master Call Correlation engine  403  then links the AAL2 and AAL5 legs together using the supplied Call Id information. UTRAN CID Engine  401 , UTRAN RRC Manager  402 , and Master Call Correlator  403  are software applications that may run on separate processors or on the same processor in monitoring equipment  107 . For example, monitoring equipment  107  may comprise multiple blades, wherein each blade has a processor that is capable of running one or more software applications, such as an AAL5 correlation application, an AAL2 correlation application, and/or a master call correlation application. 
         [0059]    Primary Call Id Assignment 
         [0060]    A Primary Call Id is assigned when UTRAN RRC Manager  402  receives an RRC Connection Request message in case of a mobile-originated call or receives a paging message in case of a mobile-terminated call. UE  106  is identified by means of the UE-Id that is present in both these messages. The Primary Call Id is generated for either of these messages using the RNC-Id and the time when that message was received. The format of the Primary Call Id is as follows: 
         [0000]    
       
         
               
             
               
               
               
             
           
               
                   
               
               
                 Primary Call Id Structure 
               
             
          
           
               
                 RNC-Id 
                 Current Time Stamp (Seconds) 
                 Sequence Number (0-65535) 
               
               
                   
               
               
                 4 bytes 
                 4 bytes 
                 2 bytes 
               
               
                   
               
             
          
         
       
     
         [0061]    The two-byte Sequence Number is simply a running counter that is incremented by 1 every time a Call Id is assigned and wraps back to 0 when it reaches 65535. This means that as many as 65536 calls can be handled per second by UTRAN RRC Manager  402  by assigning each of them a unique Primary Call Id. 
         [0062]    UTRAN RRC Manager  402  tracks a call by maintaining several keys in a map or hash table. For every call, the following identifiers must be tracked and associated with the call:
       Uplink Scrambling Code—may change during a call, so specific RRC messages are analyzed to see if such a change is present;   Control Radio Network Temporary Identity (CRNTI)—can change during a call and the changes are tracked continuously; and   UTRAN Radio Network Temporary Identity (URNTI).       
 
         [0066]    UTRAN RRC Manager  402  takes the following actions to assign the Primary Call Id upon receiving various RRC messages. 
         [0067]    Upon receipt of an RRC Connection Request message, UTRAN RRC Manager  402  creates a Primary Call Id and associates it with the UE-Id in the message by creating a UEId-Call Id Map as follows: 
         [0000]    
       
         
               
             
               
               
               
             
           
               
                   
               
               
                 UEId-Primary Call Id Map 
               
             
          
           
               
                 UE-Id Type 
                 UE-Id 
                 Primary Call Id 
               
               
                   
               
               
                 2 bytes 
                 8 bytes 
                 10 bytes 
               
               
                   
               
             
          
         
       
     
         [0068]    Upon receipt of an RRC Connection Setup message, using the UE-Id in the message, UTRAN RRC Manager  402  gets the Primary Call Id from the UEId-Primary Call Id Map. UTRAN RRC Manager  402  also extracts other parameters from the message, such as a URNTI, CRNTI, and the uplink scrambling code and creates a URNTI-Call Id Map, CRNTI-Call Id Map, and Uplink Scrambling Code (ULS)-Call Id Map as follows: 
         [0000]    
       
         
               
             
               
               
               
             
           
               
                   
               
               
                 ULS-Primary Call Id Map 
               
             
          
           
               
                 RNC-Id 
                 Uplink Scrambling Code (ULS) 
                 Primary Call Id 
               
               
                   
               
               
                 4 bytes 
                 4 bytes 
                 10 bytes 
               
               
                   
               
             
          
         
       
     
         [0000]    
       
         
               
             
               
               
               
             
           
               
                   
               
               
                 CRNTI-Primary Call Id Map 
               
             
          
           
               
                 Cell Id 
                 CRNTI 
                 Primary Call Id 
               
               
                   
               
               
                 4 bytes 
                 4 bytes 
                 10 bytes 
               
               
                   
               
             
          
         
       
     
         [0000]    
       
         
               
             
               
               
               
             
           
               
                   
               
               
                 URNTI-Primary Call Id Map 
               
             
          
           
               
                   
                 URNTI 
                 Primary Call Id 
               
               
                   
                   
               
               
                   
                 4 bytes 
                 10 bytes 
               
               
                   
                   
               
             
          
         
       
     
         [0069]    For AAL2 frames on a DCH channel, UTRAN RRC Manager  402  uses the Uplink Scrambling Code or AAL5 Call Id in the message to lookup the Primary Call Id in the ULS-Call Id Map. 
         [0070]    For RRC messages that transition UE  106  from Cell-DCH state to Cell-FACH state, UTRAN RRC Manager  402  gets the Primary Call Id from the ULS-Primary Call Id Map and deletes that ULS entry from the map since UE  106  is now in CELL_FACH state. Using the CRNTI in the message, UTRAN RRC Manager  402  adds an entry to the CRNTI-Primary Call Id Map. Since CRNTI is unique only per cell, the Cell Id is included as a key with CRNTI. The Cell Id is derived from the primary scrambling code in the message. 
         [0071]    For RRC messages that transition UE  106  from Cell-FACH state to Cell-DCH state, UTRAN RRC Manager  402  gets the Primary Call Id using the CRNTI or URNTI in the message and by doing a look up into the appropriate map. UTRAN RRC Manager  402  also invalidates the CRNTI entry and adds an entry to the ULS-Primary Call Id Map. The message will contain a new uplink scrambling code since it transitioned to Cell-DCH mode. 
         [0072]    Upon receiving an RRC Connection Release Complete message, UTRAN RRC Manager  402  invalidates and deletes all entries related to the call. Accordingly, UTRAN RRC Manager  402  handles the following scenarios in call tracking and assigns the same unique Primary Call Id until UE  106  terminates the call:
       Cell-DCH to Cell-FACH transition with Cell update;   Cell-DCH to Cell-FACH transition without Cell update;   Cell-DCH to Cell-FACH and back to Cell-DCH transition with the same uplink scrambling code;   Cell-DCH to Cell-FACH and back to Cell-DCH transition with a different uplink scrambling code; and   Cell-FACH to Cell-DCH transition.       
 
         [0078]    A class diagram for an embodiment of UTRAN RCC Manager  402  is illustrated in  FIG. 5 , which shows examples of the software modules and data structures that can be used to implement an AAL2 correlation engine. 
         [0079]    Radio Bearer Id (RB Id) Assignment 
         [0080]    An RB Id needs to be assigned to each transport block (TB) that is transmitted on a DCCH or DTCH channel to identify the logical channel to which the TB belongs. In addition, a Primary Call Id needs to be assigned to the TB. The primary reason for assigning an RB Id is because the RB-Id is used as a parameter to decipher the signal unit, if ciphering is enabled, and to reassemble the deciphered signal unit since RLC reassembly is done per UE per RB Id per direction. The RB Id mapping is obtained from the RRC Connection Setup, Radio Bearer Setup, and Radio Bearer Reconfiguration messages. Once this mapping is stored, the RB-Id for each TB can be determined using the DCH-Id that it carries if the TB is on a DCH channel. If the TB is on a RACH or FACH channel, the C/T field in the MAC header is used to get the RB Id. 
         [0081]    Deciphering 
         [0082]    To decipher AAL2 Transport Blocks on the IuB and IuR interfaces, the deciphering key (CK) needs to be associated with the Primary Call Id. The CK is obtained from the IuCs or IuPs interfaces depending on whether the call established in the CS Domain or PS Domain. The IuCs and IuPs interfaces connect the RNCs to the UMTS Core Network. The CK can also be tied to UE-Id, because the UE-Id parameter is present when a call is established on the IuPs or IuCs interface. 
         [0083]    Once the UTRAN RRC Manager receives the CK along with the UE-Id, the CK can be tied to a Primary Call Id using the UEId-Primary Call Id Map. Accordingly, for any AAL2 Transport Block that carries a Primary Call Id, the UTRAN RRC Manager can obtain the corresponding CK to use for deciphering the TB. 
         [0084]    RLC/MAC Reassembly Engine 
         [0085]    The Radio Link Control/Medium Access Control (RLC/MAC) protocol Reassembly Engine reassembles FP Transport Blocks received from the UTRAN CID Engine into RLC service data units (SDUs) in three RLC Modes: Transparent, Acknowledged, and Unacknowledged mode.  FIG. 6  illustrates how RLC/MAC Reassembly Engine  601  and decipher application  602  fits into the packet processing flow of the UTRAN monitoring equipment. RLC/MAC Reassembly Engine  601  and decipher application  602  may be embodied as separate applications within UTRAN RRC Manager  402 . 
         [0086]    AAL2 frame  61  includes Transport Blocks that have been sent over different logical channels, DCH 1  and DCH 2 , by the UE. The blocks from channels DCH 1  and DCH 2  are combined into FP frame  61  by UTRAN CID Engine  401  and sent to UTRAN RRX Manager  402 . Decipher application  602  deciphers FP frame  61  into deciphered frame  62 . The Transport Blocks of frame  62  comprise MAC PDUs  63 , which in turn comprise RLC PDUs  64 . RLC/MAC Reassembly Engine  601  processes and reassembles the data in RLC PDUs  64  into SDUs  65 . When a complete SDU  65  is reassembled, RLC/MAC Reassembly Engine  601  and UTRAN RRC Manager  402  sends the SDU for further processing by Master Call Correlator. RLC/MAC Reassembly Engine  107  provides the following functions:
       Tracking the RLC reassembly process for individual logical channel instances, which are identified by RB Id, for different UEs, which are identified by the Primary Call Id, and tracking the RLC reassembly process for common logical channel instances;   Reassembly in RLC Transparent Mode, segmented and non-segmented;   Reassembly in RLC Unacknowledged and Acknowledged Mode, with the handling of segmentation, concatenation, and padding, and out-of-sequence arrival;   Handling missing fragment detection via sequence number check, in Unacknowledged mode;   Handling missing fragment detection, duplicate detection, out-of-window size arrival in Acknowledged mode;   Handling RLC RESET and STATUS protocol control in Acknowledged mode;   Handling macro-diversity or soft handover in which duplicate frames are received on multiple IuB/IuR connections; and   Handling channel type switching, in which case the RLC Packet Data Units (PDUs) that make up an RLC SDU could come from different transport channels, such as RACH, FACH, and DCH.
 
RLC/MAC Reassembly Engine  601  is independent of the transport channel since every frame has a Primary Call Id and the RB Id assigned to it.
       
 
         [0095]      FIG. 7  illustrates the static data architecture of RLC/MAC Reassembly Engine  601 . RLC/MAC Reassembly Engine  601  uses hierarchical data structures to keep track of RLC PDUs arriving on different channels for multiple users. RLC Reassembly Engine  701  is an instance of the RLC Reassembly Engine software. Each instance of RLC Reassembly Engine  701  has multiple instances of UE Reassembly  702  to keep track of individual active users. Each instance of UE Reassembly  702  is identified by a unique Primary Call Id. Each UE Reassembly instance  702  has multiple instances of ChannelReasmProcess  703  to keep track of the RLC reassembly processes for different logical channel instances for that user. Each instance of ChannelReasmProcess  703  is identified by a logical channel key, which consists of two elements: (1) Direction (i.e. uplink or downlink), and (2) RB Id, which may be a signaling Radio Bearer Id or logical channel instance Id. Each ChannelReasmProcess  703  has multiple instances of PDU Buffer  704  to keep track of the PDU fragments for a particular logical channel&#39;s RLC reassembly process. Each PDU Buffer  704  is identified by a Sequence Number (SN) of a PDU. 
         [0096]    A class diagram of RLC/MAC Reassembly Engine  601  is illustrated in  FIG. 8 , which shows examples of the software modules and data structures that can be used to reassemble SDUs. 
         [0097]    Macro-Diversity Handling of IuB/IuR Soft Handover 
         [0098]    In the soft handover scenario illustrated in  FIG. 9 , the same frame is sent by UE  901  on multiple radio links. At position  1 , frame  91  is communicated between UE  901  and RNC  902  only via Node B  903  and Iub interface  904 . As UE  901  moves to position  2 , it begins a soft handover operation from Node B  903  to Node B  905 . At position  2 , frame  92  is communicated between UE  901  and RNC both via Node B  903  and Iub interface  904  and via Node B  905  and Tub interface  906 . As the soft handover is completed, UE  901 &#39;s only radio link is with Node B  905  at position  3 . Accordingly, at position  3 , frame  93  is communicated between UE  901  and RNC  902  only via Node B  905  and Iub interface  906 . 
         [0099]    As a result of this handover, frames  92  for the same call on UE  901  may be captured by monitoring equipment from two routes at the same time. UTRAN RRC Manager  402  eliminates these duplicates by assigning the same Primary Call Id and RB Id to these duplicate frames  92 . When multiple frames  92  reach RLC Reassembly Engine  601 , they each go into the same PDU Buffer  704  because each of the duplicate frames have the same the RLC sequence number. RLC Reassembly Engine  601  takes the first error-free frame and discards the rest as duplicates. UTRAN RRC Manager  402  is able to handle IuB/IuR Soft Handover using its Primary Call Id and RB-Id tracking logic. 
         [0100]    Monitoring equipment  107  captures all messages for all UEs and uses the Primary Call Id and the AAL5 Call Id (or Secondary Call Id) to identify messages belonging to each call for the UEs. Monitoring equipment  107  combines messages having the same Primary Call Id and AAL5 Call Id into call records per UE per call. The call records contain the SDUs for the call and allow an operator to evaluate the call for quality of service, call type, call length and other performance indicators. 
         [0101]    Although the present invention and its advantages have been described in detail, it should be understood that various changes, substitutions and alterations can be made herein without departing from the spirit and scope of the invention as defined by the appended claims. For example, many of the features and functions discussed above can be implemented in software, hardware, or firmware, or a combination thereof. As another example, it will be readily understood by those skilled in the art that the format of the various mappings and identifiers described herein may be varied while remaining within the scope of the present invention. 
         [0102]    Moreover, the scope of the present application is not intended to be limited to the particular embodiments of the process, machine, manufacture, composition of matter, means, methods and steps described in the specification. As one of ordinary skill in the art will readily appreciate from the disclosure of the present invention, processes, machines, manufacture, compositions of matter, means, methods, or steps, presently existing or later to be developed, that perform substantially the same function or achieve substantially the same result as the corresponding embodiments described herein may be utilized according to the present invention. Accordingly, the appended claims are intended to include within their scope such processes, machines, manufacture, compositions of matter, means, methods, or steps.