Classifications

• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04W—WIRELESS COMMUNICATION NETWORKS
  • H04W24/00—Supervisory, monitoring or testing arrangements
  • H04W24/08—Testing, supervising or monitoring using real traffic
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04W—WIRELESS COMMUNICATION NETWORKS
  • H04W36/00—Hand-off or reselection arrangements
  • H04W36/0005—Control or signalling for completing the hand-off
  • H04W36/0011—Control or signalling for completing the hand-off for data sessions of end-to-end connection
  • H04W36/0022—Control or signalling for completing the hand-off for data sessions of end-to-end connection for transferring data sessions between adjacent core network technologies
  • H04W36/00224—Control or signalling for completing the hand-off for data sessions of end-to-end connection for transferring data sessions between adjacent core network technologies between packet switched [PS] and circuit switched [CS] network technologies, e.g. circuit switched fallback [CSFB]
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04W—WIRELESS COMMUNICATION NETWORKS
  • H04W24/00—Supervisory, monitoring or testing arrangements

Definitions

• the present invention relates to a method, an apparatus, and a computer program for determining inter-technology circuit-switched fallback (CSFB) performance indicators (metrics). More particularly, the present invention relates to using call trace data of both the source and the target (legacy) communication network to determine an improved inter- technology CSFB metrics.
• CSFB circuit-switched fallback
• LTE Long Term Evolution
• GSM Global System for Mobile communications
• UMTS Universal Mobile Broadband
• the CS-domain services may be realized by reuse of CS infrastructure (radio and core network), and by CSFB is meant that a user equipment (UE) camps on a Packet-Switched (PS) system but switches over to a CS system to establish, for example, an originating CS call.
• PS Packet-Switched
• the UE may be paged in the PS system, but may respond to the page in the CS system.
• the UE may thus, within CSFB, perform a registration, while in the PS- domain (e.g., LTE), to the CS domain.
• PS- domain e.g., LTE
• the UE Once the UE then wants to make a CS voice call, or receives an incoming paging for a CS voice call, it will leave the PS-domain (LTE) and switches over to the CS radio access network and initiates the call setup in the CS network.
• LTE PS-domain
• the first procedure is used when the user Is in an area where the LTE voice service has not been deployed yet and redirects/transfers the outgoing or incoming call towards a legacy technology during the call setup.
• This procedure is currently responsible for the voice traffic during the first phase of VoLTE (Voice over LTE) deployment.
• the second phase of the complete VoLTE deployment is based on the SRVCC mechanism. It consists of handing over a VoLTE call towards a legacy technology once the voice connection between both users has been established.
• This procedure is basically an inter-system handover from a Packet-Switched (PS) domain to a CS domain.
• PS Packet-Switched
• a CSFB transfer comprises more than one stage, and the conventional mechanism to compute an inter-technology performance indicator is limited to the stage of calf release towards the target (legacy) communication network, while the stage of call initiation in the target communication network and the successful establishment of a voice path in the target communication network is not considered.
• a suitable method, an apparatus, and a computer program are defined in the independent claims. Advantageous embodiments are defined in the dependent claims.
• a technology hop such as CSFB enters, i.e. initiates, and successfully establishes a voice path
• a packet-switched subsystem such as LTE
• a circuit-switched subsystem of any of the legacy technologies such as UMTS or GSM
• CSFB Circuit-Switched Fallback
• a method is defined according to an embodiment for tracking a transfer of voice calls from a source mobile communication network to a target mobile communication network when a circuit-switched fallback, CSFB, procedure is performed for the voice calls, the method comprising the steps of: acquiring trace data of the voice calls in both the source mobile communication network and the target communication network; and calculating at least one CSFB performance indicator based on the acquired call trace data.
• CSFB circuit-switched fallback
• an apparatus is defined according to an embodiment, and the apparatus is for tracking a transfer of voice calls from a source mobile communication network to a target mobile communication network when a circuit-switched fallback, CSFB, procedure is performed for the voice calls, the apparatus comprising an acquiring module configured to acquiring trace data of the voice calls in both the source mobile communication network and the target communication network; and a processing module configured to calculate at least one CSFB performance indicator based on the acquired call trace data.
• CSFB circuit-switched fallback
• a corresponding computer program is defined.
• the inter-technology CSFB-specific performance indicators such as the CSFB success or failure rate, will be used to validate the CSFB mechanism as a reliable gateway for the voice traffic in the way of the complete VoLTE deployment.
• the proposed mechanism thus enables an inter-technology call follow-up.
• a call is transferred from one technology to another it is advantageous to be able to follow it up in its path (based on the acquired call trace data), so that its end-to-end event flow and cause of termination in the destination and source technologies are known.
• the proposed mechanism provides a method to follow up CSFB calls from an LTE network (source network) to a legacy environment (target network).
• the proposed mechanism relies on the information contained in the call trace data and thus provided by the event flows given by the same call from both source and target technologies.
• the event flow messages may allow the user to obtain an in- depth knowledge of the processes related to the ongoing call and thus, to define very specific and more accurate and reliable metrics, such as those defined herein.
• the proposed metrics provide scalability as they may be used on a user- defined area, this is, a group of cells, one or more MME/RNC/BSC, or entire networks.
• the proposed metrics only use sums, products and divisions, and thus have low computational costs.
• most of the registered events in the call trace data may be geo-localized.
• a handover-related procedure such as CSFB, it is advantageous to be able to find both the source (LTE) and the target legacy networks call locations so that VoLTE geographical deployment issues can be studied in depth.
• the embodiments disclosed herein provide information beyond the one disclosed by the prior art on that a CSFB has failed based on network counters. Instead, the embodiments disclosed herein provide, e.g. to any of the managing system of a telecommunications network, information resulting of an evaluating all the relevant stages of the CSFB call transfer, and that additionally can provide a cause as to why, or at what event, in which network domain a transfer of a service has failed.
• the information can be utilized, for example, by the one or more apparatuses managing a telecommunications network to, for example, identify the particular traffic cases where a transfer of a communication between a source and a target network trend to fail, and to take the necessary management measures such as: increasing some network node's resources, modifying some network node's parameters, etc.
• the proposed mechanism contribute to centralized, end-to-end intelligent platform to assist network operators in the efficient monitoring, design, optimization and troubleshooting of multi-vendor, multi-technology networks.
• Fig. 1 is a schematic flow diagram illustrating an embodiment of a method for tracking a transfer of voice calls when a CSFB procedure is performed.
• Fig. 2 is a schematic diagram illustrating an embodiment of an apparatus for tracking a transfer of voice calls when a CSFB procedure is performed.
• Fig. 3 is a schematic flow diagram illustrating another embodiment of a method for tracking a transfer of voice calls when a CSFB procedure is performed.
• Fig. 4 is a schematic flow diagram illustrating another embodiment of a method for tracking a transfer of voice calls when a CSFB procedure is performed.
• Fig. 5 is a schematic flow diagram illustrating another embodiment of a method for tracking a transfer of voice calls when a CSFB procedure is performed.
• Fig. 6 is a schematic flow diagram illustrating a general overview of another embodiment of a method for tracking a transfer of voice calls when a CSFB procedure is performed.
• Fig. 7 is a schematic flow diagram illustrating another embodiment of a method for filtering call trace data to determine calls that have been successfully released from the source communication network.
• Fig. 8 is a schematic diagram illustrating an inter-technology overlapping area according to another embodiment.
• Fig. 9 is a schematic diagram illustrating LTE and UMTS cell selection and the control of an inter-technology overlapping area according to another embodiment.
• Fig. 10 is a schematic flow diagram illustrating another embodiment of a method for filtering call trace data to determine calls that have been successfully initiated in the target communication network.
• Fig. 11 is a schematic flow diagram illustrating another embodiment of a method for filtering call trace data to determine calls for which a voice path has been successfully established in the target communication network.
• Fig. 12 is a schematic flow diagram illustrating another embodiment of a method for using respecting call groups to determine one or more inter-technology performance indicators.
• Fig. 13 is a schematic flow diagram illustrating another embodiment of a method for determining a signal condition in failed CSFB.
• Fig. 14 is a schematic flow diagram illustrating another embodiment of a method for inter- technology call tracking. DESCRIPTION OF THE EMBODIMENTS
• the following proposes a mechanism for tracking voice calls from a source mobile communication network to a target communication network when a circuit-switched fallback, CSFB, procedure is performed for the voice calls. More specifically, the following describes the example of a CSFB procedure from LTE, as an example of a source mobile communication network, to another legacy technology, such as GSM or UMTS, as an example of a target mobile communication network, and its end-to-end performance metrics.
• Figure 1 illustrates an embodiment of a method for tracking a transfer of voice calls from a source mobile communication network 10 to a target mobile communication network 20 when a circuit-switched fallback, CSFB, procedure is performed for the voice calls.
• the voice calls may be ongoing voice calls that are outgoing from a UE or incoming at a UE.
• the CSFB procedure may thus be performed from a PS domain (e.g., LTE) having a source RAT to a CS domain (e.g., UMTS, GSM) having a different, target RAT.
• the method illustrated in Figure 1 and further described below may be performed an apparatus 100 as illustrated in Figure 2.
• the source mobile communication network 10 (comprising respective eNBs) and the target mobile communication network 20 (comprising respective RNCs/BSCs) generate respective call trace data (as further described below), and the respective call trace data are acquired by an acquiring module 110 of the apparatus 100 that is in communicative interaction with both networks.
• the apparatus 100 may be an integral part of the packet-switched source communication network 10 or it may be located outside of it
• the respective call trace data may be stored in call trace databases of the respective communication networks, and the acquiring module 110 acquires the call trace data by accessing those databases and collecting the call trace data.
• a corresponding database may be provided in the apparatus 100 Itself, where the call trace data may be appropriately gathered, parsed and processed.
• the apparatus 100 is further provided with a processing module 120 that is configured to calculate one or more CSFB performance indicator based on the acquired call trace data, as will be further described below.
• the method comprises a first step S110 of acquiring trace data of the voice calls in both the source mobile communication network 10 and the target communication network 20.
• the call trace data may be acquired or collected by or from the respective eNBs in the source domain (LTE) and the respective RNCs/BSCs to track an end-to-end flow being related to a transfer of a voice call path.
• the method further comprises a second step S140 of calculating at least one CSFB performance indicator based on the acquired call trace data.
• Respective CSFB performance indicators refers to inter-technology performance indicators that require the analysis of call trace data with regard to both the source and target communication network. Such inter-technology performance indicators may thus be used to quantify how well the underlying CS-based voice traffic network supports the voice traffic deployment in LTE. For example, a CSFB end-to-end success rate and/or a CSFB end-to-end failure rate may be used to fully validate the CSFB procedure (mechanism) as a reliable gateway. The mechanism and metrics proposed herein are thus based on acquiring and analyzing of call trace data to determine one or more inter-technology performance indicators.
• the call trace data may comprise at least one of control information (and/or identification information) of the voice calls, voice call events, and a content of messages.
• control information may refer to at least one of a subscriber identity (I MSI), a mobile device identity (IMEI), a voice call identification, a voice call start time, and a voice call end time.
• the information with regard to voice call events may include at least one of a number of events being related to the voice call (identified by the voice call identification), an event identification, an event time, and an event description.
• a content of messages exchanged between the mobile network elements as part of the calls relates to messages of the events, and may, for example, include parameter values, data values, or the like.
• Acquiring the thus defined voice call trace data may thus include call trace data gathering and processing, for example in respective databases being related to the source mobile communication network 10 and the target communication network 20.
• These respective databases may contain a list of calls with their relevant parameters, the sequence of events that took place for each one of these calls and the messages contained in these events, which are basically the information and commands the different entities in the cellular network send and receive in order to communicate with other network entities.
• TABLE 1 illustrates a sample list of calls with their relevant information contained in columns; some of these columns are IMSI and IMEI (as part of the control information), which identify the mobile user and the mobile device, respectively, others refer to the call identification, the call start and end times, and the number of related events.
• TABLE 2 shows some of the events that compose the call with CALL ID - 0 from TABLE 1, including an event identifier, event time, a short description and the content of a message it carries. Both tables would be part of the respective LTE and UMTS/GSM call databases.
• a further embodiment may include the step S120 of collecting the call trace data in respective databases of the source mobile communication network 10 and the target communication network 20.
• the respective call trace data may thus be collected in respective databases of the source and target domain or a single database for both the source and target domain, and are then acquired for parsing the collected call trace data for further processing/analysis (e.g., to calculate one or more inter-technology performance indicators) by accessing the respective database.
• the step of collecting and further processing of the call trace data may be performed by the management apparatus, which e.g. can be located in the PS source domain (e.g., LTE).
• the databases may be provided externally to the management apparatus which is provided with an interface to perform accesses to it.
• a further embodiment may include the step S130 of filtering the acquired trace data to determine a group of voice calls related to a release from the source mobile communication network 10, a group of voice calls related to an initiation of voice calls in the target mobile communication network 20, and a group of voice calls related to an establishment of a voice path in the target mobile communication network 20.
• the step S 130 of filtering may include a filtering of the trace data in/of the source mobile communication network 10 to determine a first group of voice calls for which a CSFB attempt has been triggered.
• the filtering may include the step of determining, from the first group, a second group of voice calls that have been successfully released from the source mobile communication network 10 and a third group of voice calls that have failed to be released from the source mobile communication network 10.
• the filtering may be performed based on an iterative process that successively takes trace data, for example from the database related to the source network, and applies specific conditions to be met in order to sort the trace data in appropriate groups of voice calls, here a first group being related to CSFB attempts, a second group being related to a successful CSFB release toward the legacy domain, and a third group being related to failed CSFB attempts in the source domain.
• the step of filtering S130 may comprise a step of setting an inter- technology overlapping area and determining whether a cell that serves the voice call in the source mobile communication network 10 is within the inter-technology overlapping area.
• the overlapping coverage area may be defined as an overlap of a coverage area of the source mobile communication technology and a coverage area of the target mobile communication technology for which call trace data have been collected in respective target cells of the target mobile communication technology.
• This overlapping coverage area is referred to as a call area constraint (which will be further described below). This means that only voice calls are used for determining the one or more inter- technology CSFB performance indicator (metrics) which have their origin in the overlapping coverage area. This is to distinguish from other calls that cannot be tracked in their target domain.
• the step of filtering S130 as illustrated in Figure 3 may further comprise the step of determining from the trace data in the source mobile communication network 10 whether the voice calls have an I MSI and/or an lMEI that is no null (non-zero) and whether, the voice calls have a CSFB triggering event.
• This filter condition corresponds to a notification that those voice calls are, in fact, to be redirected to the target domain (UMTS/GSM), and determines the first group of voice calls, i.e. the CSFB attempts.
• the step of filtering S130 as illustrated in Figure 3 may further comprise the step of determining from the trace data in the source mobile communication network 10 whether the voice calls have been registered with more than a predetermined number of events, for example more than one event. Those calls with no more than a predetermined number of events are referred herein as spurious (e.g., the start and end time are the same) and are not further considered. On the other hand, the calls with more than a predetermined number of events have been properly registered in the call database(s), e.g. a call with more than one registered event. This also determines the first group of voice calls. This particular filter processing is performed in order to avoid LTE calls whose start and end cannot be found, as these instants are given by the first and last registered call event respectively.
• the step of filtering S130 as illustrated in Figure 3 may further comprise the step of determining from the trace data in the source mobile communication network 10 whether the voice calls have a CSFB release-notifying event.
• CSFB release-notifying event In the case of LTE, for example, there are some release-related events. For example, as described in Section 5.3.5 from 36PP TS 23.401 (V13.4.0, 2015), the resources-releasing procedure ends with the following events: -
• the MME releases the S1 interface by sending the S1 UE Context Release
• the eNodeB confirms the S1 Release by returning an S1 UE Context Release Complete message to the MME by means of the S1AP protocol.
• the last is an example of a release-related event that confirms the release of the resources in LTE.
• This filter condition is applied in order to distinguish between just a release attempt and an actual successful release toward the target (legacy) domain.
• the respective call is either added to the second group of voice calls or the third group of voice calls.
• the step of filtering S 130 as illustrated in Figure 3 may further comprise the step of using the second group of voice calls, as determined above, and the trace data in the target mobile communication network 20 to determine a fourth group of voice calls that have been successfully initiated in the target mobile communication network 20. This may be achieved by comparing an IMSI and/or IMEl of the second group of voice calls with an IMSI and/or IMEl of the trace data of the voice calls in the target mobile communication network 20 and determining whether the voice calls in the target mobile communication network 20 start between a start time and an end time of the voice calls of the second group plus a time window ⁇ .
• the time window ⁇ is a short time window of, for example 1 second, and may account for signaling delays and/or processing delays, tf there is a match, i.e. if the voice call in the target mobile communication network 20 start between a start time and an end time of the voice calls of the second group plus a time window ⁇ , then this voice call is considered trackable and is added to the fourth group of voice calls (being classified as successfully Initiated in the target domain). If there is no match, on the other hand, then the calls are classified as not trackable.
• the step of filtering S130 as Illustrated in Figure 3 may further determine a fifth group of voice calls for which a predetermined event has been registered, for example sent or received, in the trace data of the voice calls in the target mobile communication network 20 and sixth group of voice calls for which a predetermined event has not been registered in the trace data of the voice calls in the target mobile communication network 20.
• fifth group of voice calls are voice calls for which the network setup for the voice link is successfully established.
• the sixth group of voice calls refers to voice calls which are classified as failed CSFB calls in the target network.
• step of calculating S140 as illustrated in Figure 1 may further comprise the step of using at least one of the determined first group, third group, fifth group, and sixth group of voice calls to calculate the at least one CSFB performance indicator. This will be described in further detail below with regard to Eq. (3) - (11) that provide specific inter- technology performance indicators that depend on the voice call data of both the source and target network.
• a further embodiment may further comprise the step S150 of acquiring a measurement of a signal quality and/or signal level provided by the serving cell In the target communication network 20.
• This step S150 may be performed for the sixth group of voice calls, i.e. the group of voice calls that are associated with a failed CSFB in the target domain (UMTS/GSM).
• the measurement result may be taken from the last event in the call trace data that has reported a measurement of the signal quality and/or signal level.
• the measurement time should be preferably within a time window T that is defined between the last registered event and a user-defined time (as will be described in more detail later).
• the acquired measurement result may be listed/displayed for the user to evaluate/troubleshoot the result. More specifically, the listed/displayed event flows messages allow the user to obtain an in-depth knowledge of the processes related to the ongoing call, in particular with regard to specific reasons as to the stage at which the CSFB call transfer has failed.
• the further embodiment may also include the step S160 of selecting a voice call from a group of voice calls that have been successfully initiated in the target mobile communication network 20 and chronologically ordering events of the respective voice call data.
• This step S160 may be performed for the fourth group of voice calls, i.e. the group of voice calls that are associated with a successful initiation in the target (legacy) network.
• the selecting may be based on voice call identifications, such as IMSI, IMEI, call ID, as included in the call trace data.
• This procedure defines the complete inter-technology event flow, and provides the user with the capability to study in- depth the event flows from both network sides. This enables failure identification, e.g. the failure identification in the authentication process or the like.
• the further embodiment may also include the step S170 of geographically localizing call trace data, in particular geographically localizing respective registered events.
• the geolocation may be done by using certain information contained within the trace events, like measured cells, measured signal level, propagation delay and time delay measurements, along with the known geographic position of the cells. Based on this procedure, in a handover-related procedure such as CSFB, it becomes possible to find both the source LTE and the destination legacy call locations so that VoLTE geographical deployment issues may be studied in depth.
• these call trace data are first gathered by/from the eNBs (eNB 1( .... eNB N ) in the LTE communication network (source mobile communication network) 10 and by/from the RNCs (RNC ?
• the respective data may be collected in one or more databases (files) in their respective OSS.
• the acquired call trace data may thus comprise logs of the control information, events and messages exchanged between the mobile network elements as part of the calls.
• a lot of useful technical information may be obtained or derived from the acquired call trace data, for example to monitor, troubleshoot and optimize the mobile networks, as will be further described below.
• the call trace data may be gathered, parsed and processed, preferably by the apparatus 100 as illustrated in Figure 2, so that two call databases may be generated: one for the source technology (e.g., LTE), and one for the target technology (e.g., UMTS/GSM). These databases are further used as input for a further processing (by the processing module 120 of the apparatus 100 in Figure 2) that generated the inter-technology CSFB metrics (i.e. at least one CSFB performance indicator) and/or the capability of tracking calls between technologies, given as a set of pairwise LTE-legacy technology calls.
• the source technology e.g., LTE
• target technology e.g., UMTS/GSM
• the main step in the call tracking procedure is identifying which call from the source technology corresponds to which call from the target technology in terms of their call identifier in their respective databases, so both sides of the call event flows can be matched afterwards.
• a set of pairwise LTE- legacy technology calls therefore refers to the pair of call identifiers (one for the call in the source technology and one for the call in the target technology) that allows the user to put together the two halves of the end-to-end call.
• Figure 6 shows a block diagram that summarizes the proposed embodiments described above, in particular in the context of classifying the voice calls into the respective first to sixth group (G1 - G6). In Figure 6, the blocks for data gathering and processing can be seen at the top for both technologies, followed by their respective call databases.
• call trace data in particular a list of calls with their more relevant parameters, the sequence of events that took place for each one of these calls and the messages contained in these events, which are basically the information and commands the different entities in the cellular network send and receive in order to communicate with other network entities, for example eNB, with eNB N (as described above in Tables 1 and 2).
• FIG. 6 the block named Further Processing is shown after being broken down into a set of processes. They have been named PROCESS 1 to 6 and are shown in grey in Figure 6. This block diagram also shows in white the groups of calls handled by the before mentioned processes.
• PROCESS 1 - LTE CSFB OK identifies, based on an access to the LTE all database, the Mobile Originated/Mobile Terminated (MO/MT) LTE calls that start within the coverage area of the considered destination cells, i.e., the destination cells are those cells from the legacy technologies for which call trace data have been stored.
• the UMTS call database has to be accessed only once in order to determine the location of the farthest UMTS sectors for which call trace data have been registered (which, eventually will allow the user to compute the upper limit of the inter-technology overlapping area, as described below).
• the box "Take one call (call attempt) from the LTE call database” is executed for every iteration of the loop and represents the step in which the LTE call database is accessed.
• This process is done to ensure the legacy (destination) network has a coverage area completely surrounded by the coverage area of the LTE (source) network.
• an LTE call area constraint is set, i.e. an inter-technology area is set. This is shown in Figure 8, which illustrates an overlapping of the LTE and legacy technology coverage areas, in particular, where the LTE coverage area is shaded in light grey and the UMTS/GSM is shaded in medium grey. Within this area there is a section where the call trace data has been stored.
• the LTE CSFB calls are represented as arrows, whose tails (the source of the calls) come from the LTE coverage area and whose heads (the destination of the calls) point to the underlying UMTS/GSM coverage area. Only the LTE CSFB calls which have their origin inside the intersection (shaded in dark grey) of this last area and the LTE coverage area are to be considered to compute the proposed metrics.
• the arrows representing these calls are continuous, while the others are dashed. It is noted that not all the continuous arrows point inside the dark grey region; those calls which despite starting inside the dark grey region point outside it will account as unknown CSFB calls, since they cannot be tracked in their destination technology.
• Figure 9 shows an example of LTE and UMTS cell location and the control of the inter- technology overlapping area using UMTS as the destination technology, according to the location of the farthest legacy sectors and the reduction control parameter k.
• the coverage area for LTE exceeds the region shown in Figure 9 so that the overlapping areas coincide with the shadowed regions.
• a first filtering process it is determined whether the cell that serves the LTE call is within the inter-technology overlapping area (as a first condition to be met). If this is not the case (No), then the next call is retrieved from the LTE call database. On the other hand, if the cell that serves the LTE call is within the inter-technology overlapping area (Yes), then another filtering process is performed to determine whether the call has a non-zero !MSI or IMEI (as a second condition to be met). In addition, it may be determined from the call trace data whether the LTE call has a CSFB-triggering event.
• PROCESS 1 keeps only (filters out) those calls with a no-null IMSI or IMEI and a CSFB triggering event which notifies that those calls are to be redirected to UMTS/GSM.
• Those calls are being added to a CSFB ATTEMPTS group, i.e. a first group of voice calls for which a CSFB attempt has been triggered.
• PROCESS 1 may apply two more filter processes, as illustrated in Figure 7.
• a filter processing is performed to select only those calls that are not considered as spurious.
• a call may be considered as spurious if its events have not been properly registered in the call database, e.g., a call with only a limited (pre-determined) number of events in the call trace data, for example with only one event (e.g. as illustrated in Figure 7). Accordingly, only the calls with more than one event registered pass this filter to determine the first group of voice calls.
• another filter process may be performed to check which calls perform a successful LTE release towards the legacy technology. This may be notified by means of one or more events in their event flow, i.e.
• the LTE call is considered as successfully released and is added to a second group of calls named SUCCESSFUL CSFB RELEASE FROM LTE. If they are not (No), then the call is added to the third group of calls named FAILED CSFB IN LTE, as there was a CSFB attempt but not a release.
• PROCESS 2 of Figure 10 determines a fourth group of voice calls that have been successfully initiated in the target mobile communication network, as will be described below.
• PROCESS: 2 - Identify LTE-UMTS/GSM CSFB includes a comparison of the IMSIs and/or IMEIs from the SUCCESSFUL CSFB RELEASE FROM LTE calls (second group of voice calls) and those corresponding to respective calls from the UMTS/GSM CALL DATABASE. If they match and the UMTS/GSM (legacy) call starts at a time between the start time and the
• the UMTS/GSM call is redirected to a fourth group of voice calls named CSFB CALLS.
• the fourth group of voice calls may be in a specific database, or the respective calls may be appropriately associated (e.g., flagged, linked, etc.) in their respective databases.
• the time window is preferably short enough to ensure the delay is due to signal propagation or a message processing and registering time issue and not because of a voluntary call retry performed by the calling user. This is given by (2):
• PROCESS: 3 - UMTS/GSM successful and failed CSFB calls includes an identification of the CSFB failures and successes in the UMTS/GSM environment (target domain).
• a CSFB is considered as end-to-end successful and therefore, labeled as SUCCESSFUL CSFB in a fifth group of voice calls, once the network setup for the voice link is established.
• PROCESS: 3 - UMTS/GSM successful and failed CSFB calls Figure 11 which takes respective calls (call trace data) from the fourth group of voice calls, and looks therein for messages of Alert, Connect, Call Progress or Disconnect (with a cause for disconnection not related to admission control or traffic issues) sent or received by the UE, depending on the case.
• the UMTS/GSM call (of the fourth group) registered (send or received) such an event (Yes)
• the UMTS/GSM call is added to the fifth group of voice calls (SUCCESSFUL CSFB) indicating that a network setup for the voice link is successfully established.
• the UMTS/GSM call is added to the sixth group of voice calls (FAILED CSFB in UMTS/GSM).
• This message is sent in the RNC/BSC - CN direction in the MO side and in the opposite direction in the MT side. It is used to notify that the ongoing call has reached the stage where the destination UE begins to ring. At this point, the Core Network in the MT side has accepted the incoming call and a voice Radio Access Bearer has been set up.
• the call may leave the PLMN/ISDN environment; e.g., because of interworking with another network, with a non-PLMN/ISDN user, or with non-PLMN/ISDN equipment within the called user's premises; the call may also return to a PLMN/ISDN environment.
• the network sends a progress indicator information element to the calling mobile station either (a) in an appropriate call control message, if a state change is required (e.g. Alert or Connect), (b) in the Progress message, if no state change is appropriate.
• Connect The call is automatically accepted and the UE receives a Connect message with no Alert message preceding it.
• Disconnect/Call Clearing The network initiates the call clearing at the radio interface to the mobile which originated the call. Under normal conditions, the call control entity of the mobile station or of the network initiates call clearing by sending a Disconnect message to its peer entity. To prevent considering disconnections related to the lack of network resources or protocol errors, only disconnections with normal causes are commonly considered, these are "user busy", "no user responding", etc. A Disconnect message can also be sent in the UE-CN direction. This means the UE wants to end the call and, therefore, that there was a voice call, which means the CSFB was also successful.
• PROCESS: 4 - CSFB Metrics uses four groups of calls, corresponding to SUCCESSFUL CSFB (fifth group), FAILED CSFB IN LTE (third group), FAILED CSFB IN UMTS/GSM (sixth group) and CSFB ATTEMPTS (first group) to compute at least one of the following inter-technology performance parameters/metrics (3) to (11). It is noted that the operator
• the defined inter-technology performance parameters/metrics are derived based on information (call trace data) from both the source and target communication network.
• the first mechanism contained in PROCESS: 5 Signal condition for "FAILED CSFB IN UMTS/GSM CALLS' and further illustrated in Figure 13, consists of listing the last measurement of the signal quality and/or signal level provided by the serving cell in the legacy technology, within a time window T defined between the last registered event and a user-defined time.
• an event for example the last event reporting the measurement of the signal quality provided by the serving legacy cell is taken, and it is determined whether the quality signal is measured at a time point (tm ⁇ ,) in the interval defined by the last registered event (tcan end) and the time window T. If this is the case, then this last measurement is listed/displayed, for example at a corresponding user display of the apparatus (management system).
• the second optional mechanism consists of listing chronologically the sequence of end- to-end events and their parameters for a single problematic call.
• This proposal is contained in PROCESS: 6 - Call Inter-Tech Eventflow. More specifically, according to Figure 14 which shows the flow diagram for PROCESS 6, by taking respective calls from the fourth group of voice calls ("CSFB CALLS") and by taking LTE and UMTS/GSM identification numbers, the respective LTE calls database and UMTS/GSM calls database is accessed, the respective events acquired in the call trace data are taken with the selected call IDs (compare with Tables 1 and 2) and the events are put together in a chronological order, i.e. a set of pairwise LTE-legacy technology calls as described above.
• This enables failure identification, for example the identification of a failure in the authentication process.
• the respective call databases from two live time and space co-located LTE and UMTS networks have been used.
• the considered LTE network comprises 19879 ceils
• the UMTS network, for which only a RNC has been considered comprises 4515 cells. This highlights again the importance of setting an inter-technology overlapping area to avoid considering those CSFB attempts that came from LTE cells which are far from the observed legacy sectors and which will contribute to increase the number of untraceable or unknown CSFB calls.
• TABLES 4 and 5 below show the result of executing PROCESS 5 and 6 (described above in Figures 13 - 14) over the dataset above. In both cases, k and ⁇ were set to 0.3 and 1.5 s respectively.
• two failed CSFB calls in UMTS are listed in the first fifteen-minute period of time and only one per period is shown for 16:15-16:30 and 16:45-17:00.
• the number of failed CSFB calls for these periods, (4) is 2, 2 and 3.
• TABLE 5 shows a piece of the end-to-end call event flow for the failed CSFB call from period 16:15 to 16:30 from TABLE 4.
• a thick black line delimits the end of the LTE event flow and the start of the UMTS one.
• the above respective modules may be implemented by a processing unit that include one or a plurality of processors, a microprocessor or other processing logic that interprets and executes instructions stored in a main memory.
• the main memory may include a RAM or other type of dynamic storage device that may store information and instructions for execution by the respective modules/units.
• the acquiring module 110 and/or the processing module 120 discussed above with respect to Figure 2 may be realized by the processing unit
• the ROM may include a ROM device or another type of static storage device that may store static information and instructions for use by the processing unit.
• the apparatus 100 may perform certain operations or processes (filtering, acquiring, parsing, collecting, etc.) described herein.
• the apparatus 100 may perform these operations in response to the processing unit executing software instructions contained in a computer-readable medium, such as the main memory, ROM and/or storage device.
• a computer-readable medium may be defined as a physical or a logical memory device.
• a logical memory device may include memories within a single physical memory device or distributed across multiple physical memory devices.
• Each of the main memory, ROM and storage device may include computer- readable media with instructions as program code.
• the software instructions may be read into the main memory for another computer-readable medium, such as a storage device or from another device via the communication interface.
• the software instructions contained in the main memory may cause the processing unit(s) including a data processor, when executed on the processing unit to cause the data processor to perform operations or processes described herein.
• hard-wired circuitry may be used in place or on In combination with the software instructions to implement processes and/or operations described herein.
• implementations described herein are not limited to any specific combination of hardware and software.
• the physical entities according to the different embodiments of the invention, including the elements, units, modules, nodes and systems may comprise or store computer programs including software instructions such that, when the computer programs are executed on the physical entities, steps and operations according to the embodiments of the invention are carried out, i.e. cause data processing means to cany out the operations.
• embodiments of the invention also relate to computer programs for carrying out the operations/steps according to the embodiments of the invention, and to any computer- readable medium storing the computer programs for carrying out the above-mentioned methods.
• the constituent elements/modules/units of the apparatus 100 may be distributed in different software and hardware components or other devices for bringing about the intended function. A plurality of distinct elements/modules may also be gathered for providing the intended functionality.
• the elements/modules/functions of the UE/nodes may be realized by a microprocessor and a memory similar to the above node including a bus, a processing unit, a main memory, ROM, etc.
• the microprocessor may be programmed such that the above-mentioned operation, which may be stored as instructions in the memory, are carried out.
• the elements/modules/units of the apparatus may be implemented in hardware, software, Field Programmable Gate Arrays (FPGAs), Application-Specific Integrated Circuits (ASICs), firmware or the like.

Landscapes

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

Priority Applications (3)

Applications Claiming Priority (1)

Publications (1)

Family

ID=54330757

Family Applications (1)

Country Status (3)

Citations (2)

Family Cites Families (13)

• 2015
  • 2015-10-15 WO PCT/EP2015/073866 patent/WO2017063700A1/en active Application Filing
  • 2015-10-15 US US15/766,569 patent/US20180302812A1/en not_active Abandoned
  • 2015-10-15 EP EP15781636.4A patent/EP3363228A1/en not_active Withdrawn

Patent Citations (2)

Non-Patent Citations (3)

Also Published As

Similar Documents

Legal Events