Adjusting configurations of a network in a cell based on operational data of the network and crowdsourced data in the cell

Abstract

There is provided a method for adjusting one or more configurations of a wireless network in a cell of interest (COI). The method comprises obtaining traffic incident information related to a vehicle traffic incident within a region of interest (ROI). The method also comprises obtaining first operational data of the wireless network in the COI and adjusting said one or more configurations of the wireless network in the COI based on the traffic incident information and the first operational data of the wireless network in the COI.

Description

ADJUSTING CONFIGURATIONS OF A NETWORK IN A CELL BASED ON OPERATIONAL DATA OF THE NETWORK AND CROWDSOURCED DATA IN THE CELLTECHNICAL FIELD

[0001] This disclosure relates to adjusting configuration(s) of a network in a cell based on operational data of the network, e.g., key performance indicators of the network, and crowdsourced data, e.g., traffic incident data.BACKGROUND

[0002] Machine Learning (ML) models may be trained to predict Key Performance Indicators (KPIs) of a deployed telecommunication network based on data from Performance Management (PM) counters (a.k.a., “PM counter data”) for the deployed telecommunication network, as disclosed in references [1] and [2]. The references [1] and [2] are listed at the end of this disclosure.

[0003] Typical Managed Services for Networks (MSN) use-cases require computing various KPIs of telecommunication networks from PM counter data. The PM counter data may be provided as numeric time-series data with timestamps each of which indicates the time at which each sample of the PM counter data was acquired.

[0004] Using the counter data (after suitable pre-processing and computing KPIs), ML model(s) are trained to predict a target KPI using a set of feature KPIs. The trained model(s) are then used in an online setting to predict the target KPI from online stream(s) of counter data. Based on the model prediction(s) during configured Reporting Operating Periods (ROPs), the operator executes suitable actuation(s) to restore the target KPI, which would otherwise have caused a degradation in network performance, affecting end users. The suitable actuation(s), e.g., adjusting configurations of the network, may be executed in response to detecting anomalies in network performance. References [5], [6], and [8] disclose how to detect anomalies in network performance.

[0005] Crowdsourced reporting of incidents such as, for example, vehicular traffic congestion, involves users with User Equipments (UEs), e.g., mobile devices, to report theincidents in real-time to aggregators - e.g., third-party data providers such as Google™, Bing™, etc. - through the users’ telecommunication network operators. Exemplary use of Google™ and Bing™ are disclosed in references [3] and [4] which are listed at the end of this disclosure. In reporting the incidents, location information related to the incidents, e.g., latitude and longitude, and other attributes such as severity, impact, and / or nature of the incidents may be reported.

[0006] These reports are aggregated and made available through service endpoints by the aggregators. Then, given a location, e.g., latitude and longitude, and a radius around the location, one can use a service endpoint to obtain, in real-time, information about the incident occurred at the location or within the radius around the location within a specific time window. The information about the incident may include but are not limited to location information indicating the location of the incident and other attributes such as the ones mentioned above. Reference [7] listed below discusses a deep learning framework to automatically learn regular mobile traffic patterns along roads, detect non-recurring events and classify them by severity level.SUMMARY

[0007] Certain challenges presently exist. Anomalies in operational data, e.g., KPIs, of telecommunication networks are used to identify degradation in the performance of the telecommunication networks and / or improve the performance of the networks. However, for various reasons, such anomalies may not be correctly detected and / or the cause of the anomalies may not be correctly determined. Such various reasons are explained below in detail.

[0008] Failure to correctly detect the anomalies and / or to correctly determine the cause of the anomalies may be problematic. For example, to improve the performance of their networks, network operators may adjust the configurations of their networks based on the detection of an anomaly in the KPIs of their networks and the cause of the anomaly. However, if the anomaly is not detected correctly and / or if the cause of the anomaly is not determined correctly, the network operators cannot adjust the network configurations properly, thereby failing to improve the network performance.

[0009] Therefore, there is a need for a method to correctly and proactively detect anomalies in the operational data of telecommunication networks and to correctly determine the cause of the anomalies.

[0010] Accordingly, in one aspect of the embodiments of this disclosure, there is provideda method for adjusting one or more configurations of a wireless network in a cell of interest (COI). The method comprises obtaining traffic incident information related to a vehicle traffic incident within a region of interest (ROI). The method further comprises obtaining first operational data of the wireless network in the COI, and adjusting said one or more configurations of the wireless network in the COI based on the traffic incident information and the first operational data of the wireless network in the COI.

[0011] In another aspect, there is provided a computer program comprising instructions which when executed by processing circuitry cause the processing circuitry to perform the method of any one of the above embodiments.

[0012] In a different aspect, there is provided a carrier containing the computer program of the above embodiment. The carrier is one of an electronic signal, an optical signal, a radio signal, and a computer readable storage medium.

[0013] In a different aspect, there is provided a system for adjusting one or more configurations of a wireless network in a cell of interest (COI). The system is configured to obtain traffic incident information related to a vehicle traffic incident within a region of interest (ROI). The system is further configured to obtain first operational data of the wireless network in the COI; and adjust said one or more configurations of the wireless network in the COI based on the traffic incident information and the first operational data of the wireless network in the COI.

[0014] In a different aspect, there is provided a system comprising processing circuitry and a memory. The memory contains instructions executable by said processing circuitry. The system is operative to perform the method of any one of the above embodiments.

[0015] The embodiments of this disclosure allow correctly and proactively detecting anomalies in operational data of telecommunication networks and correctly determining the potential cause(s) of the anomalies. By correctly and proactively detecting the anomalies and determining the cause of the anomalies, the embodiments allow identifying degradation in the performance of the telecommunication networks appropriately.

[0016] Additionally, the embodiments provide the following advantages:

[0017] 1. Current KPI degradation workflow is constrained by availability of KPIs inROPs or aggregation of ROPs, and thus it is agnostic to real-time incidents. The embodiments utilize real-time incident data to determine network KPI anomalies proactively.

[0018] 2. Current approach for root-cause analysis examines KPIs for significantchanges that may have attributed to the anomalies, while being agnostic to real-time incidents. The embodiments offer a way to incorporate these incidents as an additional indicator for effective root-cause analysis.

[0019] 3. The real-time incident severity prediction model jointly leverages the crowdsourced traffic incidents data and the telecom network KPI and site databases to determine the severity of the real-time incidents. It can thus learn the correlation of telecom KPIs with such incidents over a diverse set of incident types and respective impact types, or other attributes of interest.BRIEF DESCRIPTION OF THE DRAWINGS

[0020] The accompanying drawings, which are incorporated herein and form part of the specification, illustrate various embodiments.

[0021] FIG. 1 illustrates an exemplary scenario where the embodiments of this disclosure can be applied.

[0022] FIG. 2 illustrates an exemplary scenario where the embodiments of this disclosure can be applied.

[0023] FIG. 3 shows a process according to some embodiments.

[0024] FIG. 4 shows a process according to some embodiments.

[0025] FIG. 5 shows exemplary crowdsourced data.

[0026] FIG. 6 shows an example use-case.

[0027] FIG. 7 shows an exemplary cloud implementation of the processes according to some embodiments.

[0028] FIG. 8 shows a process according to some embodiments.

[0029] FIG. 9 shows an apparatus according to some embodiments.DETAILED DESCRIPTION

[0030] FIG. 1 shows an example scenario 100 where the embodiments of this disclosure can be applied. In the scenario 100, a first base station 102 is configured to provide a cellular wireless network (hereinafter just “NW”) 112 in a cell 122, a second base station 104 isconfigured to provide a NW 114 in a cell 124, and a third base station 106 is configured to provide a NW 116 in a cell 126. Examples of the first, second, and third base stations 102, 104, and 106 include but are not limited to gNB, eNB, etc. For simple referencing purpose, the first, second, and third base stations 102, 104, and 106 are referred to as first, second, and third gNBs 102, 104, and 106 respectively. In the scenario 100, vehicles 108 are controlled by a controlling node, which is not shown in FIG. 1. Examples of the vehicles 108 include but are not limited to cars, trucks, drones, etc. For simple referencing purpose, the vehicles 108 are referred to as cars 108.

[0031] Eet’s assume that, as shown in FIG. 2, an ambulance 202 is approaching some of the cars 108. In this case, based on the locations of the cars 108 and the location of the ambulance 202, the controlling node may identify which of the cars 108 are within a preset distance from the ambulance 150, and may transmit, to those identified cars - e.g., cars 204 and 206 located in the cell 122 - control signals controlling the identified cars to move to the side roads, thereby allowing the ambulance 202 to pass through the cars without being stuck in a traffic. The control signals may be transmitted to the cars 204 and 206 via the NW 112 provided by the first gNB 102 within the cell 122. Note that the controlling node may be a single entity or may be an entity formed of multiple distributed entities. Also the controlling node may be a software entity, a hardware entity, or a mix of these two entities.

[0032] Successful transmission of the control signals from the controlling node to the cars 204 and 206 requires good network performance of the NW 112. Thus, based on current and / or future state of the NW 112, one or more configuration(s) of the NW 112 may be adjusted in order to maintain or improve the network performance. For example, in case the current state of the NW 112 indicates that the total amount of network traffic currently handled by the first gNB 102 within the cell 122 is about to exceed a preset capacity of the cell 122, the network node may control the first gNB 102 to increase the capacity of the cell 122 such that more network traffic can be handled by the first gNB 102 within the cell 122.

[0033] In order to determine the current and / or future state of the NW 112, the network node may collect operational data of the NW 112, e.g., Key Performance Indicators (KPIs) of the NW 112, and determine the current and / or future state of the NW 112 based on the collected operational data of the NW 112. The KPI of the NW 112 may be collected periodically. Morespecifically, in one example, the KPIs of the NW 112 may be collected from PM counters periodically during multiple Reporting Operating Periods (ROPs). Table 1 below illustrates how the KPIs of the NW 112 may be collected by the network node.Table 1

[0034] In the example shown in Table 1, the KPIs of the NW 112 are reported to the controlling node every 2 hours, which means that the length of the ROP is 2 hours. However, reporting, to the controlling node, the KPIs every 2 hours may result in that the controlling node fails to capture short-term real-time significant deviations in the KPIs, which may be caused by physical event(s).

[0035] For instance, as shown in FIGS. 1 and 2, let’s assume that a car accident 132 occurred within the cell 122 at 9:20 am, causing a severe vehicle traffic congestion within the cell 122 for about 20 minutes. In this case, because the drivers of the cars within the cell 122 attempt to use their mobile phones to find alternative routes or to stream music or videos, there is a sudden increase in network traffic. If this increased network traffic exceeds the capacity of the NW 112, the performance of the NW 112 would be bad and thus may not work well. However, the controlling node would not know this issue because by the time the KPIs of the NW 112 is reported at 11:00 am, the traffic congestion within the cell 122 disappears and thus the performance of the NW 112 would return to normal.

[0036] In order to solve the above-described problem, in some embodiments of this disclosure, there is provided a process 300 in FIG. 3 for determining the current state of a network, e.g., the NW 112, within a cell of interest (COI), e.g., the cell 122, and for adjusting one or more configurations of the network when needed.

[0037] The process 300 comprises a first sub-process 302 for determining whether to trigger determining the current state of the network within the COI and a second sub-process304 for determining the current state of the network within the COI and adjusting one or more configuration(s) of the network within the COI. The process 300 may be performed by a single entity or a plurality of entities, e.g., via a distributed computing, and each entity may be a software entity or a hardware entity.

[0038] One of the objectives of the process 300 is to establish a correlation between crowdsourced data for a COI, e.g., real-time traffic incident data for the COI, and operational data of a network within the COI, e.g., KPIs of the network within the COI, within a specific time interval.

[0039] The first sub-process 302 may begin with step s312. The step s312 comprises determining a location of interest (LOI), e.g., a latitude and a longitude, which defines a geographical area of interest (AOI). The AOI may be defined by a circle having the LOI as the center. Alternatively, the AOI may be defined by any geometric shape. More specifically, in some embodiments, the AOI may be represented by a polygonal region having pairs of latitude and longitude as the vertices. An AOI may also be referred to as a region of interest (ROI). Thus, in this disclosure, AOI and ROI are used interchangeably.

[0040] In FIG. 1, a point 154 is the LOI and an area 152 is the AOI. As shown in FIG. 1, the area 152 is a circle having the point 154 as its center. The AOI may correspond to an area encompassing one or more cells for which network configuration(s) may possibly need to be adjusted to maintain or improve network performance.

[0041] After determining the LOI and the AOI, the first sub-process 302 may proceed to step s314. The step s314 comprises collecting crowdsourced data for the AOI. The crowdsourced data is data which is collectively provided by a plurality of devices.

[0042] In some embodiments, the crowd sourced data corresponds to real-time traffic incidents. In these embodiments, the crowdsourced data may be obtained by a suitable service provided by aggregators such as Google™ via Google Maps™, Microsoft via Bing™, or others. In case the crowdsourced data corresponds to real-time traffic incidents, the crowdsourced data may contain traffic incident information related to a vehicle traffic incident.

[0043] The crowdsourced data may comprise various attributes represented in a structured format such as, for example, JavaScript Object Notation (JSON). The top table below showsexemplary attributes of crowdsourced data represented in JSON and the bottom table below shows definitions of some of the attributes. Note that even though JSON is used as an example in this disclosure, in some embodiments, other format may be used instead.Table 2Table 3

[0044] In the tables above, the exemplary attributes of crowdsourced data include the severity of a traffic incident, the impact of a traffic incident, the type of a traffic incident, etc. Examples of the type of a traffic incident include but are not limited to a traffic accident, a traffic congestion, presence of a disabled vehicle, mass transit, occurrence of planned event(s), road hazard(s), alert, construction work, weather related events, etc. FIG. 5 illustrates another example of the crowdsourced data.

[0045] Referring back to FIG. 3, after collecting the crowdsourced data for the AOI, e.g., the area 152, the first sub-process 302 may proceed to step s316. The step s316 comprises filtering the collected crowdsourced data based on a specific cell of interest (COI). For example, in case the COI is the cell 122 in FIG. 1, the step s316 comprises filtering the collected crowdsourced data based on the cell 122.

[0046] In FIG. 1, the AOI 152 covers the cells 122, 124, and 126. Thus, the crowdsourced data collected in the step s314 comprises crowdsourced data for the cells 122, 124, and 126. Then, in the step s316, only the crowdsourced data for the cell 122 is extracted, i.e., filtered. In this disclosure, the filtered crowdsourced data is also called correlated crowdsourced data or spatial correlated crowdsourced data because the filtered crowdsourced data is spatially correlated / mapped to the COI. In some embodiments, in addition to filtering crowdsourced data according to the COI, the crowdsourced data may be filtered based on a specific time period (i.e., a temporal window), e.g., between 1 pm and 5 pm. More specifically, in some embodiments, the crowdsourced data may be filtered according to a desired ROP. For example, if the desired ROP is between 9 am and 11 am, the filtered crowdsourced data is the crowdsourced data corresponding to the ROP between 9 am and 11 am. The crowdsourced data corresponding to other ROPs would be filtered out.

[0047] After filtering the collected crowdsourced data, i.e., after obtaining the correlatedcrowdsourced data, the first sub-process 302 may proceed to step s318. The step s318 comprises determining severity of an incident, e.g., a vehicle traffic incident, in the COI based on the correlated crowdsourced data. The incident in the COI may be an event / occurrence related to vehicle traffic of the COI. As mentioned above, examples of the type of a traffic incident include but are not limited to a traffic accident, a traffic congestion, presence of a disabled vehicle, mass transit, occurrence of planned event(s), road hazard(s), alert, construction work, weather related events, etc.

[0048] In determining the severity of an incident in the step s318, in some embodiments, a machine learning (ML) model may be used. More specifically, in some embodiments, the attributes of the correlated crowed sourced data may be provided to the ML model. The ML model may be configured to determine / predict the severity of the incident based on the attributes.

[0049] Note that the severity of an incident determined in the step s318 is different from the severity of the incident provided in the crowdsourced data shown in Table 2 provided above. More specifically, the severity of an incident determined in the step s318 may indicate a degree of the impact of the incident on network performance. Thus, for clear distinction, in the remaining disclosure, the severity of an incident provided in the crowdsourced data is referred to as “impact” of the incident.

[0050] Taking the attributes of the crowdsourced data shown in FIG. 5 as a simplified example, the severity of an incident may be determined in the step s318 using the ML model. In FIG. 5, there are at least four attributes: the type of the incident (“accident” and “congestion”), the impact level of the incident (“low” and “high”), the impact score of the incident (“100” and “28”), and the description of the incident (“Accident on NHXX” and “congestion on NHXX”). The attribute for the impact score of the incident is a numerical value while the attribute for the type of the incident is text. In some embodiments, the text indicating the type of the incident may be converted into an embedding numerical value, and the numerical values indicating the type and the impact score of the incident may be provided to the ML model as inputs. The ML model then may output a numerical value indicating the severity of the incident. Other attributes that may be used as inputs of the ML model include event identifiers, location coordinates indicating the start and end points of the event of interest, start and end timestamps of the event of interest, type of event - categorical, impact of event - categorical, score corresponding to theevent impact - categorical or numeric, and description of the event - textual description.

[0051] Referring back to FIG. 3, after determining the severity of the incident in the COI, the first sub-process 302 may proceed to step s320. The step s320 comprises determining whether a condition associated with the severity of the incident is satisfied. If the condition is satisfied, the process 300 may proceed to the second sub-process 304 for determining the current state of the network within the COI and adjusting one or more configurations of the network within the COI when needed. Otherwise, the first sub-process 302 may end. In other words, based on the satisfaction of the condition, the process 300 may trigger monitoring of the operational data of the network in the COI.

[0052] There are various ways of determining whether the condition associated with the severity of the incident is satisfied. In one example, the severity of the incident is determined as a numerical value and, in the step s320, the numerical value indicating the severity of the incident may be compared to a threshold value. In case the numerical value is greater than or equal to the threshold value, it may be determined that the condition associated with the severity of the incident is satisfied. In another example, an anomaly detection is applied to the severity of the incident. In case an anomaly is detected in the severity of the incident, it may be determined that the condition associated with the severity of the incident is satisfied.

[0053] As explained above, in case the current state of the network in the COI is determined and reported periodically, e.g., at 2 pm, 4 pm, 6 pm, etc., but an incident affecting the current state of the network occurs and disappears far before and / or after the periodic timing of determining the current state, e.g., between 3 pm and 3:20 pm, the reported current state of the network may not capture the incident occurred and disappeared far before and / or after the periodic timing of determining the current state. In the process 300, this problem is addressed by triggering to determine the current state of the network in the COI when the severity of an occurred incident is bad enough.

[0054] Referring back to FIG. 3, the second sub-process 304 is for determining the current state of the network in the COI and adjusting one or more configurations of the network in the COI when needed. The second sub-process 304 may begin with step s352. The step s352 comprises obtaining operational data of the network in the COI. The operational data of the network may be real-time data. One example of such operational data is KPI(s) of the network. The operational data of the network may be obtained and / or derived from PM counter data. Morespecifically, in one example, the KPIs of the network may be extracted from the PM counters for preceding time intervals. Examples of the operational data of the network include but are not limited to peaks in uplink (UL) volume (e.g., UL Packet Data Convergence Protocol (PDCP) volume [GB]), throughput (e.g., UL PDCP Cell Thp [Mbps]), a number of radio resource control (RRC) establishment attempts, a number of hourly RRC establishment attempts, etc.

[0055] After obtaining the operational data, the second sub-process 304 may proceed to step s354. The step s354 comprises determining the current state of the network in the COI based on the obtained operational data. One example of determining the current state of the network is detecting an anomaly in the operational data - determining that “something is wrong in the KPIs of this network.”

[0056] After determining the current state of the network in the COI, the second subprocess 304 may proceed to step s356. The step s356 comprises performing root cause analysis / issue classification to determine the cause(s) of the current state of the network. For example, in the step s356, the cause(s) of the anomaly in the operational data may be determined.

[0057] Then, in step s358, one or more configurations of the network in the COI may be adjusted to maintain or improve the performance of the network in the COI.

[0058] As explained above, in the process 300 shown in FIG. 3, the combination of the crowdsourced data for the COI and the operational data of the network in the COI is used for performing the root cause analysis / issue classification and for adjusting the configuration(s) of the network in the COI. More specifically, in the process 300, the crowdsourced data and the operational data are combined by triggering to obtain the operational data based on the crowdsourced data.

[0059] FIG. 4 shows a different way of combining the crowdsourced data and the operational data. More specifically, in the process 400, the crowdsourced data and the operational data are combined by triggering to obtain the crowdsourced data based on the operational data.

[0060] The process 400 comprises a first sub-process 402 for determining whether to trigger obtaining the crowdsourced data and a second sub-process 404 for obtaining the crowdsourced data and triggering performing root cause analysis / issue classification. The process 400 also comprises steps of performing the root cause analysis / issue classification and adjusting one or more configurations of the network in the COI. The process 400 may beperformed by a single entity or a plurality of entities, e.g., via a distributed computing, and each entity may be a software entity or a hardware entity.

[0061] The first sub-process 402 may begin with step s412. The step s412 comprises obtaining operational data of the network in the COI. The operational data of the network may be real-time data. One example of such operational data is KPI(s) of the network. The operational data of the network may be obtained and / or derived from PM counter data. More specifically, in one example, the KPIs of the network may be extracted from the PM counters for preceding time intervals. Examples of the operational data of the network include but are not limited to peaks in uplink (UL) volume (e.g., UL Packet Data Convergence Protocol (PDCP) volume [GB]), throughput (e.g., UL PDCP Cell Thp [Mbps]), a number of radio resource control (RRC) establishment attempts, a number of hourly RRC establishment attempts, etc.

[0062] After obtaining the operational data, the first sub-process 402 may proceed to step s414. The step s414 comprises determining the current state of the network in the COI based on the obtained operational data. One example of determining the current state of the network is determining whether an anomaly is detected in the operational data - i.e., determining whether “something is wrong in the KPIs of this network.”

[0063] After determining the current state of the network in the COI, the first sub-process 402 may proceed to step s416. The step s416 comprises determining whether a condition associated with the current state of the network in the COI is satisfied. In one example, the condition is detecting an anomaly in the operational data of the network - i.e., determining that “something is wrong in the KPIs of this network.” If the condition is not satisfied, the process 400 may end. On the contrary, if the condition is satisfied, the process 300 may proceed to the second sub-process 404. In other words, if the condition is satisfied, the sub-process of obtaining the crowdsourced data is triggered.

[0064] The second sub-process 404 may begin with step s452. The step s452 comprises determining a location of interest (LOI), e.g., a latitude and a longitude, which defines a geographical area of interest (AOI). The AOI may be defined by a circle having the LOI as the center. Alternatively, the AOI may be defined by any geometric shape. More specifically, in some embodiments, the AOI may be represented by a polygonal region having pairs of latitude and longitude as the vertices. As mentioned above, an AOI may also be referred to as an ROI, and thus, in this disclosure, AOI and ROI are used interchangeably.

[0065] After determining the LOI and the AOI, the second sub-process 404 may proceed to step s454. The step s454 comprises collecting crowdsourced data for the AOI. The crowdsourced data is data which is collectively provided by a plurality of devices.

[0066] In some embodiments, the crowed sourced data corresponds to real-time traffic incidents. In these embodiments, the crowdsourced data may be obtained by a suitable service provided by aggregators such as Google™ via Google Maps™, Microsoft via Bing™, or others. The crowdsourced data may comprise various attributes represented in a structured format such as, for example, JavaScript Object Notation (JSON). In case the crowdsourced data corresponds to real-time traffic incidents, the crowdsourced data may contain traffic incident information related to a vehicle traffic incident.

[0067] As shown in the tables above, the exemplary attributes of crowdsourced data include the severity of a traffic incident, the impact of a traffic incident, the type of a traffic incident, etc. Examples of the type of a traffic incident include but are not limited to a traffic accident, a traffic congestion, presence of a disabled vehicle, mass transit, occurrence of planned event(s), road hazard(s), alert, construction work, weather related events, etc. FIG. 5 illustrates another example of the crowdsourced data.

[0068] Referring back to FIG. 4, after collecting the crowdsourced data for the AOI, e.g, the area 152, the second sub-process 404 may proceed to step s456. The step s456 comprises filtering the collected crowdsourced data based on a specific cell of interest (COI). For example, in case the COI is the cell 122 in FIG. 1, the step s456 comprises filtering the collected crowdsourced data based on the cell 122.

[0069] In FIG. 1, the AOI 152 covers the cells 122, 124, and 126. Thus, the crowdsourced data collected in the step s314 comprises crowdsourced data for the cells 122, 124, and 126. Then, in the step s456, only the crowdsourced data for the cell 122 is extracted, i.e., filtered. In this disclosure, the filtered crowdsourced data is also called correlated crowdsourced data or spatial correlated crowdsourced data because the filtered crowdsourced data is spatially correlated / mapped to the COI.

[0070] After filtering the collected crowdsourced data, i.e., after obtaining the correlated crowdsourced data, the second sub-process 404 may proceed to step s458. The step s458comprises determining severity of an incident, e.g., a vehicle traffic incident, in the COI based on the correlated crowdsourced data. The incident in the COI may be an event / occurrence related to vehicle traffic of the COI. As mentioned above, examples of the type of a traffic incident include but are not limited to a traffic accident, a traffic congestion, presence of a disabled vehicle, mass transit, occurrence of planned event(s), road hazard(s), alert, construction work, weather related events, etc.

[0071] In determining the severity of an incident in the step s458, in some embodiments, a machine learning (ML) model may be used. More specifically, in some embodiments, the attributes of the correlated crowed sourced data may be provided to the ML model. The ML model may be configured to determine / predict the severity of the incident based on the attributes.

[0072] Note that the severity of an incident determined in the step s458 is different from the severity of the incident provided in the crowdsourced data shown in Table 2 provided above. More specifically, the severity of an incident determined in the step s458 may indicate a degree of the impact of the incident on network performance. Thus, for clear distinction, in the remaining disclosure, the severity of an incident provided in the crowdsourced data is referred to as “impact” of the incident.

[0073] Taking the attributes of the crowdsourced data shown in FIG. 5 as a simplified example, the severity of an incident may be determined in the step s458 using the ML model. In FIG. 5, there are at least two attributes: the type of the incident and the impact score of the incident. The impact score of the incident is a numerical value while the type of the incident is text. In some embodiments, the text indicating the type of the incident may be converted into an embedding numerical value, and the numerical values indicating the type and the impact score of the incident may be provided to the ML model as inputs. The ML model then may output a numerical value indicating the severity of the incident.

[0074] Referring back to FIG. 4, after determining the severity of the incident in the COI, the second sub-process 404 may proceed to step s460. The step s460 comprises determining whether a condition associated with the severity of the incident is satisfied. If the condition is satisfied, the process 400 may proceed to step s472. Otherwise, the second sub-process 404 may end. In other words, based on the satisfaction of the condition, the process 400 may proceed to performing the root cause analysis / issue classification.

[0075] There are various ways of determining whether the condition associated with the severity of the incident is satisfied. In one example, the severity of the incident is determined as a numerical value and, in the step s460, the numerical value indicating the severity of the incident may be compared to a threshold value. In case the numerical value is greater than or equal to the threshold value, it may be determined that the condition associated with the severity of the incident is satisfied. In another example, an anomaly detection is applied to the severity of the incident. In case an anomaly is detected in the severity of the incident, it may be determined that the condition associated with the severity of the incident is satisfied.

[0076] The step s472 comprises performing root cause analysis / issue classification to determine the cause(s) of the current state of the network. For example, in the step s472, the cause(s) of the anomaly in the operational data may be determined. Then, in step s474, one or more configurations of the network in the COI may be adjusted to maintain or improve the performance of the network in the COI.

[0077] The following is a summary of the concept behind the processes 300 and 400.

[0078] Use-Case Scenario

[0079] As 5G network provides services to mission critical applications such as ambulances, smart cities (e.g., video surveillance at traffic intersections), industrial Internet of Things (loT), vehicular communications, etc., it is important to maintain necessary Quality of Service (QoS) Service Level Agreement (SLA) requirements for the applications. Lor example, self-driving cars with the use of 5G wireless networks are not very far from reality, and thus high-performance wireless network connectivity with low latency is significant for autonomous driving. Also, in the future, cars can communicate with smart traffic signs, surrounding objects, and other vehicles on the road (V2V, V2X).

[0080] In these applications, every millisecond is important, especially for self-driving vehicles, because the decision has to be made in a split second to avoid collision and make sure passenger safety. Therefore, it should be ensured that enough capacity on the network is available to maintain, e.g., Ultra Reliable Low Latency Communications (uRLLC) connection.

[0081] The embodiments described above may be used to address the real-time congestion in the network and take necessary actuations and dynamic traffic steering to provide uRLLC, mMTC and EMBB services of various 4G & 5G use cases, as illustrated in EIG. 6.

[0082] EIG. 7 shows a system including nodes which can be used to perform the steps shown in EIGS. 3 and / or 4. The system may be a cloud, meaning that the nodes are distributed in a cloud. The system comprises Nodes 1, la, 2, 2a, and 3.

[0083] In EIG. 7, the crowdsourced real-time traffic incidents data (e.g., the data obtainedin the step s314 shown in FIG. 3 and / or in the step 454 shown in FIG. 4) along with the associated attributes are maintained at Node 1. The associated processing node is represented by Node la. Node la may be configured to perform any one or more of the steps s316, s318, and s320 shown in FIG. 3 and / or the steps 456, 458, and 460 shown in FIG. 4.

[0084] The telecom data (KPI and site databases) Node 2 - i.e., the node capable of obtaining and storing the operational data obtained in the step s352 shown in FIG. 3 and in the step s412 shown in FIG. 4) may be hosted for one or more site or operators. Associated telecom data processing node is indicated as Node 2a. Node 2a may be configured to perform any one or more of the steps s354, s356, and s358 shown in FIG. 3 and / or the steps s414 and s416 shown in FIG. 4.

[0085] Nodes 1 / 1 a may be co-located with nodes 2 / 2a respectively in one embodiment, or either of these nodes may be implemented with suitable levels of aggregation (such as cells, sites, regions etc.) in alternate embodiments. The associated spatial-temporal modeling approach (that takes inputs from nodes la and 2a) is indicated by node 3 and may be implemented in multiple embodiments based on the choice of implementing nodes 1 / 1 a and 2 / 2a.

[0086] FIG. 8 shows a process 800 for adjusting one or more configurations of a wireless network in a cell of interest, COI, according to some embodiments. The process 800 may begin with step s802.

[0087] The step s802 comprises obtaining traffic incident information related to a vehicle traffic incident within a region of interest, ROI. The step s802 may correspond to the step s314 in FIG. 3 or the step s454 shown in FIG. 4. Note that the step s802 corresponds to the step s314 in case the sub-processes 302 and 304 are performed by the same entity. Similarly, the step s802 corresponds to the step s454 in case the sub-processes 402 and 404 are performed by the same entity.

[0088] Step s804 comprises obtaining first operational data of the wireless network in the COI. The step s804 may correspond to the step s352 in FIG. 3 or the step s412 shown in FIG. 4.

[0089] Step s806 comprises adjusting said one or more configurations of the wireless network in the COI based on the traffic incident information and the first operational data of the wireless network in the COI. The step s806 may correspond to the step s358 shown in FIG. 3 or the step s474 shown in FIG. 4.

[0090] In some embodiments, the first operational data of the wireless network in the COIcomprises one or more key performance indicators, KPIs, indicating performance of the wireless network.

[0091] In some embodiments, the process 800 further comprises, based on the COI, selecting a part of the ROI, based on the selection of the part of the ROI, filtering the traffic incident information, thereby obtaining filtered traffic incident information. The filtered traffic incident information is related to a vehicle traffic incident within the selected part of the ROI. This step may correspond to the step s316 in FIG. 3 or the step s456 in FIG. 4.

[0092] In some embodiments, the selected part of the ROI at least partially overlaps the COI.

[0093] In some embodiments, the process 800 further comprises obtaining a machine learning, ML, model for determining severity of a vehicle traffic incident, and providing the filtered traffic incident information to the ML model, thereby determining severity of the vehicle traffic incident within the selected part of the ROI. This step may correspond to the step s318 in FIG. 3 or the step s458 in FIG. 4.

[0094] In some embodiments, the process 800 further comprises, based on the first operational data of the wireless network in the COI, determining state information which indicates a current state of the wireless network or a predicted future state of the wireless network in the COL This step may correspond to the step s354 in FIG. 3 or the step s414 in FIG. 4. The process 800 further comprises determining one or more causes of the current or predicted future state of the wireless network in the COL This step may correspond to the step s356 in FIG. 3 or the step s472 in FIG. 4. Said one or more configurations of the wireless network is adjusted based on said one or more causes of the current or predicted future state of the wireless network.

[0095] In some embodiments, the state information indicates one or more anomalies in the first operational data of the wireless network in the COI, and said one or more causes of the current or predicted future state of the wireless network in the COI are one or more causes of said one or more anomalies.

[0096] In some embodiments, the process 800 further comprises determining whether the severity of the vehicle traffic incident within the selected part of the ROI satisfies a condition (e.g., corresponding to the step s320 in FIG. 3), and based on determining that the severity of the vehicle traffic incident within the selected part of the ROI satisfies the condition, triggering monitoring of the first operational data of the wireless network in the COL Obtaining the first operational dataof the wireless network in the COI is performed as a result of the triggering.

[0097] In some embodiments, the first operational data of the wireless network in the COI is obtained at a first timing. The process 800 further comprises periodically obtaining operational data of the wireless network in the COI. Periodically obtaining operational data of the wireless network in the COI comprises obtaining second operational data of the wireless network in the COI at a second timing and third operational data of the wireless network in the COI at a third timing. A time interval between the second timing and the third timing is preset, and the first timing is between the second and third timings within the time interval.

[0098] In some embodiments, the process 800 further comprises determining whether the severity of the vehicle traffic incident within the part of the ROI satisfies a condition (e.g., corresponding to the step s460 in FIG. 4), and said one or more causes of the current or predicted future state of the wireless network in the COI are determined based on determining that the severity of the vehicle traffic incident within the part of the ROI satisfies the condition.

[0099] In some embodiments, the process 800 further comprises determining whether the current or predicted future state of the wireless network in the COI satisfies a condition (e.g., corresponding to the step s414 in FIG. 4), and based at least on determining that the current or predicted future state of the wireless network in the COI satisfies the condition, triggering to obtain the traffic incident information related to vehicle traffic incident within the ROI.

[0100] In some embodiments, obtaining the traffic incident information related to the vehicle traffic incident within the ROI comprises receiving the traffic incident information from a server for collecting and / or analyzing crowdsourced data related to vehicle traffic.

[0101] In some embodiments, obtaining the first operational data of the wireless network in the COI comprises receiving the first operational data of the wireless network in the COI from a base station providing the wireless network in the COI.

[0102] In a summary, some embodiments of this disclosure can be summarized as follows:

[0103] Real-time incidents reported from crowdsourced data are used to supplement KPI degradation pipelines as follows:

[0104] 1. The collected real-time traffic incidents data is used to supplement the KPI degradation prediction pipeline proactively and asynchronously. This effectively facilitates KPI degradation prediction from network data in real-time.

[0105] 2. The real time traffic incidents data can also be used to supplement the root-causeanalysis workflow for telecom KPIs by its use as a supplemental input to the root-cause analysis model. This enables Subject Matter Experts (SMEs) to better understand the root-cause and suggest remedial actuations in the network.

[0106] Table 4 provided below summarizes the proactive KPI anomaly detection and the root-cause analysis.Table 4

[0107] RAN Implementation

[0108] A non-RT RIC can make intent driven and fine-grained updates to the RAN to optimize radio resources management capabilities and addresses a new set of use-cases for RAN optimization and automation. Any one or more of the steps shown in FIGS. 3 and 4 may be performed by an rAPP for the Non-RT RIC in the O-RAN implementation.

[0109] FIG. 9 is a block diagram of a network node 900 which may be used to perform any one or a combination of the steps shown in FIGS. 3, 4, and / or 8 according to some embodiments. In case all steps shown in FIG. 3, 4, and 8 are performed by a single hardware entity, the block diagram of the network node 900 corresponds to a block diagram of a system for performing the processes shown in FIGS. 3, 4, and / or 8. On the other hand, if the steps shown in FIGS. 3, 4, and 8 are performed by different hardware entities, the system for performing the processes shown in FIGS. 3, 4, and / or 8 may comprise multiple network nodes 900 each of which is configured to perform the step(s) shown in FIGS. 3, 4, and / or 8. In one example, the system comprises a first network node capable of performing the sub-process 302 or 404 and a second network node capable of performing the sub-process 304 or 402. In thisexample, the first network node may be capable of performing the step s802 and the second network node may be capable of performing the step s804. The step s806 may be performed by the second network node or a different network node.

[0110] As shown in FIG. 9, network node 900 may comprise: processing circuitry (PC) 902, which comprises one or more processors (P) 955 (e.g., one or more general purpose microprocessors and / or one or more other processors, such as an application specific integrated circuit (ASIC), field-programmable gate arrays (FPGAs), and the like), which processors may be co-located in a single housing or in a single data center or may be geographically distributed (e.g., network node 900 may be a distributed computing apparatus comprising two or more computers or a monolithic computing apparatus consisting of a single computer); at least one network interface 948 (e.g., a physical interface or air interface) comprising a transmitter (Tx) 945 and a receiver (Rx) 947 for enabling network node 900 to transmit data to and receive data from other nodes connected to network 110 (e.g., an Internet Protocol (IP) network) to which network interface 948 is connected (physically or wirelessly) (e.g., network interface 948 may be coupled to an antenna arrangement comprising one or more antennas for enabling network node 900 to wirelessly transmit / receive data); and a storage unit (a.k.a., “data storage system”) 908, which may include one or more non-volatile storage devices and / or one or more volatile storage devices. In embodiments where PC 902 includes a programmable processor, a computer readable storage medium (CRSM) 942 may be provided. CRSM 942 may store a computer program (CP) 943 comprising computer readable instructions (CRI) 944. CRSM 942 may be a non-transitory computer readable medium, such as, magnetic media (e.g., a hard disk), optical media, memory devices (e.g., random access memory, flash memory), and the like. In some embodiments, the CRI 944 of computer program 943 is configured such that when executed by PC 902, the CRI causes network node 900 to perform steps described herein (e.g., steps described herein with reference to the flow charts). In other embodiments, network node 900 may be configured to perform steps described herein without the need for code. That is, for example, PC 902 may consist merely of one or more ASICs. Hence, the features of the embodiments described herein may be implemented in hardware and / or software.

[0111] While various embodiments are described herein, it should be understood that they have been presented by way of example only, and not limitation. Thus, the breadth and scope of this disclosure should not be limited by any of the above-described exemplary embodiments.Moreover, any combination of the above-described elements in all possible variations thereof is encompassed by the disclosure unless otherwise indicated herein or otherwise clearly contradicted by context.

[0112] As used herein transmitting a message “to” or “toward” an intended recipient encompasses transmitting the message directly to the intended recipient or transmitting the message indirectly to the intended recipient (i.e., one or more other nodes are used to relay the message from the source node to the intended recipient). Likewise, as used herein receiving a message “from” a sender encompasses receiving the message directly from the sender or indirectly from the sender (i.e., one or more nodes are used to relay the message from the sender to the receiving node). Further, as used herein “a” means “at least one” or “one or more.”

[0113] Additionally, while the processes described above and illustrated in the drawings are shown as a sequence of steps, this was done solely for the sake of illustration. Accordingly, it is contemplated that some steps may be added, some steps may be omitted, the order of the steps may be re-arranged, and some steps may be performed in parallel.

[0114] Abbreviations

[0115] Reference List

Claims

CLAIMS1. A method (800) for adjusting one or more configurations of a wireless network in a cell of interest, COI, the method comprising: obtaining (s802) traffic incident information related to a vehicle traffic incident within a region of interest, ROI; obtaining (s804) first operational data of the wireless network in the COI; and adjusting (s806) said one or more configurations of the wireless network in the COI based on the traffic incident information and the first operational data of the wireless network in the COI.

2. The method of claim 1 , wherein the first operational data of the wireless network in the COI comprises one or more key performance indicators, KPIs, indicating performance of the wireless network.

3. The method of claim 1 or 2, wherein the method further comprises: based on the COI, selecting a part of the ROI, based on the selection of the part of the ROI, filtering the traffic incident information, thereby obtaining filtered traffic incident information, and the filtered traffic incident information is related to a vehicle traffic incident within the selected part of the ROI.

4. The method of claim 3, wherein the selected part of the ROI at least partially overlaps the COI.

5. The method of claim 3 or 4, wherein the method further comprises: obtaining a machine learning, ML, model for determining severity of a vehicle traffic incident; and providing the filtered traffic incident information to the ML model, thereby determining severity of the vehicle traffic incident within the selected part of the ROI.

6. The method of any one of claims 1-5, wherein the method further comprises: based on the first operational data of the wireless network in the COI, determining state information which indicates a current state of the wireless network or a predicted future state of the wireless network in the COI; and determining one or more causes of the current or predicted future state of the wireless network in the COI, and said one or more configurations of the wireless network is adjusted based on said one or more causes of the current or predicted future state of the wireless network.

7. The method of claim 6, wherein the state information indicates one or more anomalies in the first operational data of the wireless network in the COI, and said one or more causes of the current or predicted future state of the wireless network in the COI are one or more causes of said one or more anomalies.

8. The method of any one of claims 5-7, wherein the method further comprises: determining whether the severity of the vehicle traffic incident within the selected part of the ROI satisfies a condition; and based on determining that the severity of the vehicle traffic incident within the selected part of the ROI satisfies the condition, triggering monitoring of the first operational data of the wireless network in the COI, and obtaining the first operational data of the wireless network in the COI is performed as a result of the triggering.

9. The method of claim 8, wherein the first operational data of the wireless network in the COI is obtained at a first timing, the method further comprises periodically obtaining operational data of the wireless network in the COI,periodically obtaining operational data of the wireless network in the COI comprises obtaining second operational data of the wireless network in the COI at a second timing and third operational data of the wireless network in the COI at a third timing, a time interval between the second timing and the third timing is preset, and the first timing is between the second and third timings within the time interval.

10. The method of any one of claims 5-7, wherein the method further comprises determining whether the severity of the vehicle traffic incident within the part of the ROI satisfies a condition, and said one or more causes of the current or predicted future state of the wireless network in the COI are determined based on determining that the severity of the vehicle traffic incident within the part of the ROI satisfies the condition.

11. The method of claim 10, wherein the method further comprises: determining whether the current or predicted future state of the wireless network in the COI satisfies a condition; and based at least on determining that the current or predicted future state of the wireless network in the COI satisfies the condition, triggering to obtain the traffic incident information related to vehicle traffic incident within the ROI.

12. The method of any one of claims 1-11, wherein obtaining the traffic incident information related to the vehicle traffic incident within the ROI comprises receiving the traffic incident information from a server for collecting and / or analyzing crowdsourced data related to vehicle traffic.

13. The method of any one of claims 1-12, wherein obtaining the first operational data of the wireless network in the COI comprises receiving the first operational data of the wireless network in the COI from a base station providing the wireless network in the COI.

14. A computer program (900) comprising instructions (944) which when executed by processing circuitry (902) cause the processing circuitry to perform the method of any one of claims 1-13.

15. A carrier containing the computer program of claim 14, wherein the carrier is one of an electronic signal, an optical signal, a radio signal, and a computer readable storage medium.

16. A system (900) for adjusting one or more configurations of a wireless network in a cell of interest, COI, the system being configured to: obtain (s802) traffic incident information related to a vehicle traffic incident within a region of interest, ROI; obtain (s804) first operational data of the wireless network in the COI; and adjust (s806) said one or more configurations of the wireless network in the COI based on the traffic incident information and the first operational data of the wireless network in the COI.

17. The system of claim 14, wherein the system is further configured to perform the method of any one of claims 2-13.

18. A system (900) comprising: processing circuitry (902); and a memory (941), said memory containing instructions executable by said processing circuitry, whereby the system is operative to perform the method of any one of claims 1-13.

Images