Abstract:
In existing mobile networks, users may be traced to troubleshoot problematic user connections, monitor generic network performance, and to perform root cause analysis to identify network problems. However, the existing tracing methods provide incomplete trace information. To address this and other issues, early tracing recording is enabled in which an involved trace entity starts recording the trace data when any initial activity related to the user equipment is detected. The trace entity can continue the trace if a trace trigger is later confirmed or may discard the trace data if the trigger is not confirmed.

Description:
TECHNICAL FIELD 
       [0001]    Technical field of present disclosure relates to method, apparatuses and systems for flexible user tracing in mobile networks, and in particular to enable early trace recording so that trace logs may be complete. 
       BACKGROUND 
       [0002]    Existing 3GPP systems, including 2G/3G systems and the newly emerging SAE/LTE system, support the possibility to trace a particular user throughout its lifetime in the network. Typical use of trace is to troubleshoot problematic user connections such as in response to user complaints. Another use is to monitor generic network performance and to perform root cause analysis to identify network problems. 
         [0003]    The user may be traced based on the user identity (IMSI based trace), the terminal type (IMEI based trace) or based on location (cell trace) During tracing all network activities related to the particular user can be logged and later delivered to a network management entity for evaluation. Logged network activities include signaling messages sent and/or received either on the radio interface and/or on the network node interfaces. Details of the trace functionality may be found in documents “3GPP TS 32.421 Subscriber and equipment trace: Trace concepts and requirements,” “3GPP TS 32.422 Subscriber and equipment trace: Trace control and configuration management,” and “3GPP TS 32.423 Subscriber and equipment trace: Trace data definition and management.” 
         [0004]    The trace target and the trace configuration are specified by a management entity such as an OAM (Operation &amp; Maintenance) entity, which sends the configuration to the involved network nodes. In the trace configuration there is possibility to specify the interface(s) from which the trace logs are to be collected as well. Also, the level of trace information details may be specified. For example, all message elements may be logged or only the most relevant ones may be logged. 
         [0005]    In current 3GPP systems there are two ways to activate tracing, either via “signaling based activation” or “management based activation”. In the signaling based activation, the trigger for tracing a particular user is propagated piggy-backed on the regular signaling messages sent between the network nodes which the given user flow passes through. Initially the management system configures the particular user for tracing in the HSS (Home Subscriber System) based on its IMSI (International Mobile Subscriber Identity). As soon as the user with the given IMSI appears in the system and the HSS is interrogated for user information such as security credentials at user attach, the trace trigger will be propagated to related network nodes via the invoked signaling flow. 
         [0006]    In the management based activation, the trace trigger is not propagated to other nodes. Instead, the management system configures selected network nodes to trace a particular user or set of users. When a new user appears at the given network node, it evaluates the selection criteria and starts trace recording in case the criteria is satisfied. 
         [0007]    A more recently studied use case of trace in 3GPP is the MDT (Minimization of Drive Test) measurements performed by the UE (user equipment). The MDT measurements are collected within the framework of the trace concept, where the UE is a trace entity itself that needs to be triggered for tracing just like any other network entity. 
         [0008]    One problem with existing trace method is that there can be situations when the trace trigger reaches the involved network node such as the eNB (in case of LTE) or the UE (in case of the MDT measurements) only after the first UE messages have passed through the node or after the first messages has been sent from the UE. Thereby the initial messages of a UE connection cannot be registered, which means that the trace log will be incomplete and any network analysis or root cause analysis done later based on this information will be inaccurate and problematic. Due to the incompleteness of trace logs certain network problems may remain undiscovered by the management system. 
       SUMMARY 
       [0009]    A non-limiting aspect of the disclosed subject matter is directed to a method performed by a trace entity for early trace recording in a mobile network. In the method, upon detection of invoking activity related to a user equipment, the trace entity invokes the trace data collection. At a predetermined point in time, the trace entity determines whether the tracing has been activated for the user equipment. If so, the trace entity continues the trace data collection. Otherwise, the trace entity stops the trace data collection. The trace entity invokes the trace data collection prior to determining whether or not the tracing has been activated. 
         [0010]    Another non-limiting aspect of the disclosed subject matter is directed to a trace entity arranged to perform early trace recording in a mobile network. The trace entity comprises a message transceiving unit arranged to transmit and receive messages from nodes in the mobile network, a trace data collection unit arranged to perform trace data collection upon detection of an activity related to a user equipment, and a trace activation unit arranged to determine, at a predetermined point in time, whether tracing has been activated for the user equipment. The trace data collection unit is arranged to continue the trace data collection when it is determined that the tracing has been activated, and to stop the trace data collection when it is determined that the tracing has not been activated. The trace data collection is invoked in the trace data collection unit prior to the trace activation unit determining whether the tracing has been activated. 
         [0011]    Yet another non-limiting aspect of the disclosed subject matter is directed to a mobile network that comprises one or more trace entities arranged to perform early trace recording. In the network, at least one trace entity is arranged invoke trace data collection upon detection of an activity related to a user equipment, determine at a predetermined point in time whether tracing has been activated for the user equipment, continue the trace data collection when it is determined that the tracing has been activated, and stop the trace data collection when it is determined that the tracing has not been activated. The trace entity is arranged to invoke the trace data collection prior to determining whether the tracing has been activated. 
     
    
     
       DESCRIPTION OF THE DRAWINGS 
         [0012]    The foregoing and other objects, features, and advantages of the disclosed subject matter will be apparent from the following more particular description of preferred embodiments as illustrated in the accompanying drawings in which reference characters refer to the same parts throughout the various views. The drawings are not necessarily to scale. 
           [0013]      FIG. 1  illustrates a non-limiting example of a mobile network in which early trace recording can be performed; 
           [0014]      FIG. 2  illustrates a non-limiting configuration of a trace entity capable of performing early trace recording; 
           [0015]      FIG. 3  illustrates a non-limiting example of a signaling sequence between involved trace entities in early trace recording in a mobile network; 
           [0016]      FIG. 4  illustrates a flow chart of a non-limiting example method performed at a trace entity for early trace recording in a mobile network; 
           [0017]      FIG. 5  illustrates a flow chart of a non-limiting example process performed at a trace trigger originating entity to determine whether the tracing is activated; 
           [0018]      FIG. 6  illustrates a flow chart of a non-limiting example process performed at a trace entity other than the trace trigger originating entity to determine whether the tracing is activated; 
           [0019]      FIG. 7  illustrates a non-limiting example of a signaling sequence between involved trace entities in early trace recording in LTE; and 
           [0020]      FIG. 8  illustrates a non-limiting example of a signaling sequence between involved trace entities in early trace recording in UTRAN. 
       
    
    
     DETAILED DESCRIPTION 
       [0021]    For purposes of explanation and not limitation, specific details are set forth such as particular architectures, interfaces, techniques, and so on. However, it will be apparent to those skilled in the art that the technology described herein may be practiced in other embodiments that depart from these specific details. That is, those skilled in the art will be able to devise various arrangements which, although not explicitly described or shown herein, embody the principles of the described technology. 
         [0022]    In some instances, detailed descriptions of well-known devices, circuits, and methods are omitted so as not to obscure the description with unnecessary details. All statements herein reciting principles, aspects, embodiments and examples are intended to encompass both structural and functional equivalents. Additionally, it is intended that such equivalents include both currently known equivalents as well as equivalents developed in the future, i.e., any elements developed that perform same function, regardless of structure. 
         [0023]    Thus, for example, it will be appreciated that block diagrams herein can represent conceptual views of illustrative circuitry embodying principles of the technology. Similarly, it will be appreciated that any flow charts, state transition diagrams, pseudo code, and the like represent various processes which may be substantially represented in computer readable medium and executed by a computer or processor, whether or not such computer or processor is explicitly shown. 
         [0024]    Functions of various elements including functional blocks labeled or described as “processors” or “controllers” may be provided through dedicated hardware as well as hardware capable of executing associated software. When provided by a processor, functions may be provided by a single dedicated processor, by a single shared processor, or by a plurality of individual processors, some of which may be shared or distributed. Moreover, explicit use of term “processor” or “controller” should not be construed to refer exclusively to hardware capable of executing software, and may include, without limitation, digital signal processor (shortened to “DSP”) hardware, read only memory (shortened to “ROM”) for storing software, random access memory (shortened to RAM), and non-volatile storage. 
         [0025]    In this document, 3GPP is primarily used as examples for explanation purposes. However, the scope of this disclosure is not limited to the set of 3GPP wireless network systems and can encompass many domains of wireless network systems. 
         [0026]    As noted in the background section, a problem with the existing tracing method is the incompleteness of tracing. As a result, certain network problems may remain undiscovered. To address some or all problems and difficulties associated with the existing tracing method, an “early trace recording” method is proposed in a non-limiting aspect. In this method, a network node or the UE starts recording trace data immediately when any initial activity related to the UE is detected and stores the logged information temporarily until the need for trace is confirmed by an explicit notification. If the recording entity receives a regular trace trigger related to the particular UE context later on, the entity continues with the trace data collection. Otherwise, the entity may stop tracing and discard temporarily stored trace data. The decision point to continue or stop tracing may be made at a predetermined point in the signaling sequence. The predetermined point can differ for each recording entity. 
         [0027]      FIG. 1  illustrates a non-limiting example of a mobile network in which early trace recording can be performed. The mobile network  100  includes a base station  120 , which is a network entity (NE), arranged to wirelessly communicate with a UE  110 . The base station  120  is assumed to be early trace recording capable. The network  100  also includes one or more other network entities (NE)  130  also capable of early trace recording. Non-exhaustive examples of such network entities  130  include a radio network controller (RNC) and a serving CPRS support node (SGSN), a mobility management entity (MME), and home subscriber system (HSS) among others. Note that the UE  110  may also be early trace recording capable. In this document, any entity that is early trace recording capable is generically referred to as a “trace entity.” Also note that the trace entities starting from the UE  110  to the base station  120  to the network entities  130  are in a signal path. 
         [0028]    The network  100  may further include an operation &amp; maintenance (OAM) entity  150  and a trace collection entity  140 . The operation  86  maintenance entity  150  is arranged to configure tracing for a particular UE context to some or all trace entities  110 ,  120 ,  130  in the network  100 . The trace collection entity  140  is arranged to collect the trace data recorded by the trace entities  110 ,  120 ,  130 . The dashed arrows indicate that communications take place between the trace entities  110 ,  120 ,  130  and the trace collection entity  140  and the operation &amp; maintenance entity  150 . 
         [0029]    It should be noted that  FIG. 1  is a logical view in that the entities shown need not exactly correspond physically one-to-one with actual implementation. For example, the trace collection entity  140  and the operation  86  maintenance entity  150  may be implemented as a single physical module. As another example, the functions performed by any of the entities may be implemented over several physical modules. 
         [0030]      FIG. 2  illustrates a non-limiting configuration of the trace entity capable of performing early trace recording. The trace entity  200  includes a message transceiving unit  210 , a trace data collection unit  220 , and a trace data collection unit  230 . The message transceiving unit  210  is arranged to transmit and receive messages from nodes in the mobile network  100 . The trace data collection unit  220  is arranged to perform trace data collection upon detection of an activity related to a UE  110 . The trace activation  230  unit arranged to determine, at a predetermined point in time, whether the tracing has been activated for the UE  110 . The functions performed by the units will be explained in further detail later in this document. 
         [0031]    Note that  FIG. 2  is also a logical view. It is not strictly necessary that each unit be implemented as a physically separate module. Some or all units may be combined in a physical module. Moreover, the units need not be implemented strictly in hardware. It is contemplated that the units can be implemented through a combination of hardware and software. For example, the actual trace entity  200  may include one or more central processing units executing program instructions stored in a non-transitory computer readable medium or firmware to perform the functions of the units illustrated in the figure. 
         [0032]      FIG. 3  illustrates a non-limiting example of a signaling sequence between the involved trace entities in early trace recording in the network  100 . In the figure, the involved trace entities are first, second, and third network entities NE_ 1 , NE_ 2 , and NE_ 3  and the UE. It is assumed that a signaling path exists between the UE and the first network entity NE_ 1  via the intermediate second and third network entities NE_ 2  and NE_ 3 . The signaling direction from the UE to NE_ 1  will be considered to be upstream, and the direction from NE_ 1  to UE will be considered to be downstream. 
         [0033]    Initially, the OAM entity configures tracing for a particular UE context in NE_ 1 . NE_ 1 , upon having the tracing configured, performs early trace recording to record activities related to the UE started in NE_ 1 . That is, NE_ 1  invokes trace collection upon detection of activities related to the UE occurring in NE_ 1 . NE_ 1  also originates a trace trigger for tracing of the UE related activities in the network, and propagates the trace trigger to other involved trace entities when the UE related activities appear at NE_ 1 . Typically, the network entity where the trace is configured and from which the trace trigger may originate is the entity that can identify the UE IMSI/IMEI identities e.g., by authentication at initial attach. 
         [0034]    Thus, tracing may be said to be activated for the UE at NE_ 1  when it is confirmed that the tracing requirements set forth in the tracing configuration are met by the UE. For example, the tracing configuration may specify a UE associated with a particular subscriber, may specify a UE of a particular type, may specify a particular base station to which a UE is in a radio connection, and so on. Note that NE_ 1  invokes the trace data collection prior to determining whether the tracing has been activated. 
         [0035]    As the trace trigger originating network entity, NE_ 1  allocates trace identifiers and associates any UE related trace data collected thus far with the trace identifiers such as a trace session reference and a trace recording session reference among others. NE_ 1  also associates future trace data related to the UE it collects with the trace identifiers. When the UE related trace data are associated with the trace identifiers, the trace data can be correlated with UE related trace data collected at other trace entities and reported to the trace collection entity. 
         [0036]    Conversely, if the tracing is not activated for the UE in NE_ 1 , i.e. the UE does not meet the tracing requirements, then NE_ 1  can discard the trace data related to the UE collected thus far. Note that NE_ 1  may determine whether or not the tracing is activated at a predetermined point in time. 
         [0037]    NE_ 1  propagates the trace trigger related to the UE in a trigger propagation message to a downstream network entity, which in this example is NE_ 2 . The trace identifiers are also included in the trigger propagation message. NE_ 1  can piggy-back the trigger propagation message on other signaling messages it uses for other purposes such as signaling messages used to establish data connectivity with the UE. NE_ 1  can also use dedicated signaling messages specifically for propagation. 
         [0038]    The second network entity NE_ 2 , which is downstream of NE_ 1 , performs early trace recording to record activities related to the UE started in NE_ 2 . That is, NE_ 2  invokes trace collection upon detection of activities related to the UE occurring in NE_ 2 . In a typical network entity, a network entity (NE) message received from a downstream network entity will be the detected activity that invokes the early trace recording in the network entity. For example, NE_ 2  may be a mobility management entity that receives a UE related message from an eNodeB, which sends the UE related message in response an RRC connection request from the UE. 
         [0039]    When tracing is activated in NE_ 2 , it continues the trace data collection. Since NE_ 2  is not the trace trigger originating network entity, the mechanism for determining whether the tracing is activated for the UE in NE_ 2  is different than in NE_ 1 . As noted above, NE_ 1  propagates the trace trigger related to the UE in the trigger propagation message. When NE_ 2  receives the trigger propagation message that includes the trace trigger related from NE_ 1 , it can be said that the tracing is activated in NE_ 2  for the UE. Again, note that in NE_ 2 , the trace data collection is invoked prior to determining whether the tracing has been activated. 
         [0040]    Conversely, if the trace trigger is not received, NE_ 2  determines that the tracing is not activated and discards the trace data related to the UE collected thus far. NE_ 2  may determine whether or not the tracing is activated at a predetermined point in time. For example, NE_ 2  may wait for a predetermined amount of time to receive the trace trigger from NE_ 1  after sending a UE related message to NE_ 1 . 
         [0041]    When the tracing is activated, NE_ 2  associates any UE related trace data collected thus far with the trace identifiers included in the trigger propagation message. Any future trace data collected related to the UE are also associated with the trace identifiers. NE_ 2  can propagate the trace trigger related to the UE and the trace identifiers in a trigger propagation message to a further downstream network entity, which in this example is NE_ 3 . NE_ 2  can piggy-back the trigger propagation message on signaling messages used by NE_ 2  for other purposes such or may use dedicated signaling messages. 
         [0042]    The third network entity NE_ 3  is much like NE_ 2  in that NE_ 3  is also an intermediate network entity in the signaling path between the UE and the trace trigger originating entity NE_ 1 . NE_ 3  performs early trace recording to record activities related to the UE started in NE_ 3 . That is, NE_ 3  invokes trace collection upon detection of activities related to the UE occurring in NE_ 3 . But in this instance, the detected activity that invokes the trace data recording is a UE message received from the UE. For example, NE_ 3  may be an eNodeB receiving a random access message from the UE when the UE enters the coverage area of the eNodeB. 
         [0043]    When the tracing is activated, NE_ 3  continues the trace data collection. When NE_ 3  receives the trigger propagation message that includes the trace trigger related to the UE from NE_ 2 , NE_ 3  determines that the tracing is activated in NE_ 3  for the UE. The trace data collection is invoked in NE_ 3  prior to determining whether the tracing has been activated. 
         [0044]    Conversely, if the trace trigger is not received, NE_ 3  determine that the tracing is not activated for the UE, at which point, it may discard the trace data related to the UE collected thus far. The NE_ 3  may determine whether or not the tracing is activated at a predetermined point in time. For example, NE_ 3  may wait for a predetermined amount of time to receive the trace trigger from NE_ 2  after sending a UE related message to NE_ 2 . 
         [0045]    NE_ 3  associates any UE related trace data collected thus far with the trace identifiers included in the trigger propagation message when the tracing is activated, and any future trace data collected related to the UE are also associated with the trace identifiers. NE_ 3  may propagate the trace trigger and the trace identifiers in a trigger propagation message to its downstream trace entity, which in this example is the UE. NE_ 3  can piggy-back the trigger propagation message on signaling messages used by NE_ 3  for other purposes such or may use dedicated signaling messages. 
         [0046]    It is seen that when the trace entity is a network entity (e.g. NE_ 3 ), the detected activity that invokes the trace data collection at the network entity can be a UE message initiated by the UE to the mobile network. 
         [0047]    It is also seen that when the trace entity is a network entity (e.g. NE_ 2 ), the detected activity can be a NE message related to the UE received from a downstream network entity (e.g. NE_ 3 ). The NE message can be sent from the downstream network entity in response to the downstream network entity receiving the UE message. 
         [0048]    It is further seen that when the trace entity is a network entity (e.g. NE_ 1 ), the detected activity can be a NE message can be sent from the downstream network entity (e.g. NE_ 2 ) in response to the downstream network entity receiving another NE message from a further downstream network entity (e.g. NE_ 3 ), where the another NE message is related to the UE. 
         [0049]    At the network entity, the trace data collection is invoked prior to the network entity sending the NE message to an upstream network entity. In this way, more comprehensive trace data may be collected which in turn allows for more accurate analysis to be performed. 
         [0050]    The UE, like other trace entities, can invoke trace data collection upon detection of an activity related to the UE. However, the detected activity that invokes the trace data recording can be different for the UE than for the network entities such as NE_ 3  and NE_ 2 . This is because the UE can initiate communication by sending a UE message to the mobile network. For example, when the UE enters a coverage area of a base station, it can initiate the random access process by sending a random access message. As another example, the UE can initiate a radio request connection by sending an initial RRC message to the base station. In a non-limiting aspect, UE invokes trace data collection prior to the UE initiating communication with the network, e.g., prior to the UE sending the UE message to NE_ 3 . In this way, the trace data collection can be as comprehensive as possible. 
         [0051]    When the UE receives the trigger propagation message that includes the trace trigger from NE_ 3 , the UE can determine that tracing for the UE is activated, and the UE can continue the trace data collection. It bears repeating that the trace data collection is invoked in the UE prior to determining whether the tracing has been activated. When the tracing is activated, the UE associates the trace data collected thus far with the trace identifiers included in the trigger propagation message. One typical example where the UE is involved in the trace data collection is the use case of Minimization of Drive Test (MDT) measurements. In this case the UE may receive the trigger for doing MDT measurements in the form of an RRC (Radio Resource Control) protocol message, providing the MDT measurement configuration for the UE. When the RRC measurement configuration message is used to trigger the corresponding MDT measurement trace activity in the UE, the measurement identifier may be used to identify the trace activity instead of the trace identifiers. This means that the trace identifiers are not even sent to the UE and the translation between trace identifier and measurement identifier is done by the network (e.g., by the eNodeB). 
         [0052]    Conversely, if the trace trigger is not received, NE_ 3  may determine that the tracing is not activated and discard the trace data collected thus far. The UE may determine whether or not the tracing is activated at a predetermined point in time. For example, after sending the UE message, the UE may wait for a predetermined amount of time to receive the trace trigger from NE_ 3 . 
         [0053]      FIG. 4  illustrates a flow chart of a non-limiting example method performed by the trace entity  200  for early trace recording in the mobile network  100 . The method  400  is applicable to all trace entities. That is, any of the trace entities such as the UE  110  and the network entities  120 ,  130  may perform the method  400 . 
         [0054]    In step  410 , the trace data collection performed by the trace data collection unit  220  is invoked upon detection of an activity related to the UE  110 . When the trace entity  200  is a network entity  120  such as NE_ 3  that receives messages from the UE  110 , the detected activity that invokes the trace data collection unit  220  can be a UE message from the UE  110  received by the message transceiving unit  210 . The UE message may be a random access message or an initial RRC message. 
         [0055]    When the trace entity  200  is a network entity  130  such as NE_ 2  or NE_ 1  that receives messages from a downstream network entity  120 ,  130 , the detected activity that invokes the trace data collection unit  220  can be a NE message received by the message transceiving unit  210 , where the NE message is related to the UE  110 . 
         [0056]    In step  420 , the trace data collection unit  220  stores the collected trace data. In step  430 , the trace activation unit  230  determines, at a predetermined point in time, whether tracing has been activated for the UE  110  in the trace entity  200 . If so, then the trace data collection unit  220  continues the trace data collection in step  440 , and in step  450 , the message transceiving unit  210  provides the collected trace data to the trace collection entity  140 . If the trace activation unit  230  determines that the tracing has not been activated in step  430 , then in step  460 , the trace data collection unit  220  can discard the collected trace data related to the UE. 
         [0057]    In the method  400 , the step  410  to invoke the trace data collection is performed at the trace entity  200  prior to the step  430  to determine whether the tracing has been activated. 
         [0058]    As previously mentioned, the mechanism for determining whether the tracing is activated in step  430  can differ based on whether or not the trace entity  200  is a trace trigger originating entity. The mechanism for each will be described starting with the originating entity. In one aspect, the originating entity is the network entity  130  that can identify the UE  110  for tracing. For example, the originating entity  130  can identify the UE IMSI/IMEI identities by authentication at initial attach. 
         [0059]      FIG. 5  illustrates a non-limiting example process of the step  430  to determine whether or not tracing for the UE is activated in the originating network entity  130 . In step  510 , the message transceiving unit  210  receives the trace configuration from the operation  86  management entity  150 . The tracing for a particular UE context may be configured in the trace configuration. That is, the trace configuration may specify that activities related the UE  110  be traced when the UE is associated with a particular subscriber, the UE is of a particular type, the UE is connected to a particular base station of the network, and so on. 
         [0060]    In step  520 , the trace activation unit  230  confirms whether the UE  110  meets the tracing requirements set forth in the trace configuration. If confirmed, then in step  530 , the tracing for the UE  110  is determined to be activated in the tracing entity  200 . Otherwise, the tracing is not determined to be activated in step  540 . 
         [0061]    The originating entity  130  can be assumed to propagate the trace trigger to the involved downstream trace entities  110 ,  120 ,  130  in a trigger propagation message that includes trace identifiers. Referring back to  FIG. 4 , in the step  440  of continuing the trace data collection, the trace data collection entity  220  of the originating entity  130  associates the trace data collected thus far with the trace identifiers. 
         [0062]      FIG. 6  illustrates a non-limiting example process of the step  430  to determine whether or not tracing for the UE  110  is activated in the trace entity  200  when the trace entity  200  is not the originating entity, i.e. when the trace entity  200  is the UE  110  or one of the intermediate network entities  120 ,  130 . In step  610 , the trace activation unit  230  confirms that the trigger propagation message that includes the trace trigger related to the UE  100  is received from an upstream network entity  120 ,  130 . If confirmed, then in step  620 , the tracing is determined to be activated. Otherwise, the tracing is not determined to be activated in step  630 . 
         [0063]    Referring back to  FIG. 4  again, in the step  440  of continuing the trace data collection, the trace data collection entity  220  of UE  110  or the intermediate entities  120 ,  130  associates the trace data collected thus far with the trace identifiers included in the trigger propagation message. 
         [0064]    A non-limiting implementation of the early trace recording is described in conjunction with  FIG. 7  which illustrates an example signaling sequence in a LTE network between the UE, eNodeB, and MME. Note that it is not necessary that UE, eNodeB, and MME all be involved. The particular trace configuration determines which interfaces and nodes need to be traced. However, the described process is applicable even when any of the UE, eNodeB, and MME entities are omitted from the trace. Moreover, the described process remains applicable in cases when more entities, in addition to the illustrated MME, eNodeB and UE, are involved in the trace, which can be for instance, S/PCSCF entity in the service network. Further, the described process is applicable to systems other than LTE such as WCDMA. 
         [0065]    Initially, the OAM entity configures the UE tracing in the HSS as shown in  FIG. 7 . Alternatively, the OAM can configure the trace in the MME directly. Before the UE starts any activity toward the eNodeB, it invokes the trace data collection. In this way, the messages of the random access procedure can be logged, as well as, the RRC connection establishment messages. 
         [0066]    The eNodeB invokes the trace data collection at detecting the first random access attempts from the UE, e.g. upon receiving the random access message from the UE. The MME invokes the trace data collection upon receiving the initial UE related message from the eNodeB, which includes the identity of the UE such as the UE&#39;s IMSI. Note that the MME becomes certain about the UE identity after a successful authentication is completed. 
         [0067]    After successful authentication, the early trace is confirmed in the MME, i.e., it is determined that the tracing is activated in the MME. Also, the MME triggers tracing toward the eNodeB. In this example scenario, it is assumed that the trace configuration is downloaded from the HSS to the MME. That is, the MME is the trace trigger originating entity. At this point, the MME allocates the trace identifiers for the identification of the trace session, and propagates the identifiers with the signaling message. In this illustrated sequence, the MME sends the UE context setup message to the eNodeB, which includes the trigger and the identifiers for tracing. 
         [0068]    Upon the UE context setup message, the early trace is confirmed in the eNodeB, i.e., it is determined that the tracing is activated in the eNodeB for the UE. The eNodeB continues with the trace data collection when the tracing is activated. The eNodeB associates the received trace identifiers with the trace data collected thus far, and use the identifiers in any later reporting of trace records to the trace collection entity. 
         [0069]    Note that in the conventional tracing method, the receipt of the UE context setup message is the earliest point in time in which the trace data collection can start in the eNodeB. This means that without the described early trace recording solution, all previous messages would not be recorded, which in turn means that trace data collected is much less complete. The trace trigger is propagated to the UE from the eNodeB, for example, in a RRC Connection Reconf message that also includes the trace identifiers. 
         [0070]    Upon the UE receiving the trace trigger and identifiers from the eNodeB in the form of an RRC measurement configuration message, the early trace is confirmed, i.e. it is determined that the tracing is activated in the UE, at which point, the UE continues with the tracing as specified in the received trace configuration. Again note that the described early trace recording process allows the messages sent/received by the UE prior to the UE receiving the trace trigger to be recorded, which is not possible with the conventional tracing method. 
         [0071]    We note also that the same mechanism remains applicable also in cases where one or more of the described NEs or the UE itself is omitted from the trace propagation signaling path. For example, there might be trace configurations where the UE is not required to take part in the tracing, e.g., when no MDT measurement need be collected by the UE, in which case the signaling message of trace trigger is not sent to the UE. 
         [0072]    The sequence illustrated in  FIG. 7  is an example of the signaling based trace activation. But it should be noted that the early trace recording concept is applicable also for the management based trace activation in which the trace scope is limited to the particular trace entity that has been configured for tracing from OAM, i.e. no propagation to trace trigger to other nodes. In this instance, the recording is confined to the particular trace entity, which can invoke the trace data recording even before the actual trace trigger has been generated in the trace entity. 
         [0073]    Another non-limiting implementation of the early trace recording solution is described in conjunction with  FIG. 8  which illustrates an example signaling sequence at UE attach in a UTRAN network. In this case, any of the UE, the RNC, and the SGSN may be involved. Initially, the OAM entity configures the UE tracing in the HSS. Alternatively, the OAM may configure the trace in the SGSN directly. 
         [0074]    The UE invokes the trade data collection before it initiates the random access or the RRC connection establishment procedures. The RNC invokes the trace data collection at the reception of the first RRC message from the UE. Upon receiving the first RRC message, the RNC send a UE related message, e.g. the Initial Direct Transfer message, to the SGSN. The SGSN invokes the trace data collection upon receiving the first UE related message from the RNC. The SGSN obtains security credentials from the HSS and executes authentication with the UE. 
         [0075]    After successful authentication, the early trace is confirmed in the SGSN. Similar to  FIG. 7 , it is assumed that the trace configuration is downloaded from the HSS to the SGSN. The SGSN allocates the trace identifiers, associate the trace data collected thus far with the allocated identifiers, and propagates the trigger and the identifiers in a CN invoke trace message to the RNC. Upon receiving this message, the RNC is confirmed for tracing of the UE. The RNC associates the trace data collected thus far with the identifiers received in the CN invoke trace message and continues tracing. 
         [0076]    Note that in the legacy system, i.e., without the early trace recoding, this would be the earliest point in time when tracing for the UE could have been started in the RNC. 
         [0077]    The RNC can further propagate the trigger and identifiers to the UE to allow the UE to confirm the tracing and to associate collected traced data with the identifiers. 
         [0078]    The sequence illustrated in  FIG. 8  is also an example of the signaling based trace activation. But it should be noted that the early trace recording concept is applicable also for the management based trace activation in which the trace scope is limited to the particular trace entity such as the RNC that has been configured for tracing directly from OAM. In this instance, the trace trigger may occur either in the RNC itself. In case the trace is IMEI based, the trace trigger may come from the SGSN with the CN invoke message since IMEI is available in the SGSN and not in the RNC. 
         [0079]    There are important advantages to the described early trace recording procedure. For example, the early trace recording procedure allows the first activities, e.g. initial messages, related to a particular UE context to be recorded before a trace trigger is actually received. By recording the first messages of a UE connection, it becomes possible to extend the troubleshooting and performance monitoring activities to the initial part of the connection, where performance problems often occur. Without the early trace recording, it is not possible to detect network problems that occur during the initial phase of user connection establishment 
         [0080]    Although the description above contains many specificities, these should not be construed as limiting the scope of the disclosed subject matter but as merely providing illustrations of some of the presently preferred embodiments. Therefore, it will be appreciated that the scope of the disclosed subject matter fully encompasses other embodiments which may become obvious to those skilled in the art, and that the scope is accordingly not to be limited. All structural, and functional equivalents to the elements of the above-described preferred embodiment that are known to those of ordinary skill in the art are expressly incorporated herein by reference and are intended to be encompassed hereby. Moreover, it is not necessary for a device or method to address each and every problem described herein or sought to be solved by the present technology, for it to be encompassed hereby.