Self-organizing devices

Abstract

The present disclosure relates to self-organizing devices. A self-organizing device may include a recovery control module that can detect different events from various domains (e.g., from different layers of a software stack associated with wireless communications of the device). When a specific condition is identified based on the monitored information, the device may execute a corresponding automatic recovery mechanism to mitigate the adverse effects of the condition experienced by the device. The device may provide monitoring information to a server (e.g., a cloud server), which may use an expert system to analyze information collected from multiple devices (e.g., from globally dispersed devices) and may define mitigation action responses corresponding to specific situations or conditions including device-specific considerations. The mitigation action response may be deployed by the server to the device as an expert system rule in the form of uncompiled code or hot patch code, which may later use the code as needed to implement the necessary mitigation actions.

Description

[0001] Priority claim

[0002] This patent application claims the benefit of priority to U.S. Provisional Patent Application Serial No. 62 / 849,022, filed on May 16, 2019, and entitled “Self-Organizing Device,” which is hereby incorporated by reference as if fully and entirely set forth herein. Technical Field

[0003] The present patent application relates to wireless communications, and more particularly, to self-organizing devices for wireless communications (e.g., 3GPP LTE and / or 5G / NR communications). Background Art

[0004] The use of wireless communication systems is growing rapidly. In recent years, wireless devices such as smart phones and tablets have become increasingly sophisticated. In addition to supporting phone calls, many mobile devices (i.e., user equipment devices or UEs) now also provide access to the Internet, email, text messaging, and navigation using a global positioning system (GPS), and are capable of operating complex and sophisticated applications that utilize these functions. In addition, there are many different wireless communication technologies and wireless communication standards. Some examples of wireless communication standards include GSM, UMTS (WCDMA, TDS-CDMA), LTE, LTEAdvanced (LTE-A), HSPA, 3GPP2 CDMA2000 (e.g., 1xRTT, 1xEV-DO, HRPD, eHRPD), IEEE 802.11 (WLAN or WiFi), IEEE 802.16 (WiMAX), BLUETOOTH TM etc. The next telecommunication standard beyond the current International Mobile Telecommunications Advanced (IMT-Advanced) standard is known as the 5th generation mobile network or 5th generation wireless system, called 3GPP NR (also known as 5G-NR for 5G New Radio, and also simply NR). NR is designed to provide higher capacity for a higher density of mobile broadband users, support device-to-device, ultra-reliable and massive machine communications, and achieve lower latency and lower battery consumption than the current LTE standard.

[0005] The introduction of an ever-increasing number of features and functions in wireless communication devices also requires continuous improvements in wireless communication and improvements in wireless communication devices. It is particularly important to ensure the accuracy of signals transmitted and received by user equipment (UE) devices (e.g., by wireless devices such as cellular phones, base stations and relay stations used in wireless cellular communications). A UE can be a mobile phone or smart phone, a portable gaming device, a laptop, a wearable device, a PDA, a tablet computer, a portable Internet device, a music player, a data storage device or other handheld device, etc., and can have multiple radio interfaces that enable support for various wireless communication standards (LTE, LTE-A, WiFi, BLUETOOTH, etc.). TM The radio interface may be used by various applications, and the presence of multiple radio interfaces may require the UE to implement a mobile solution to simultaneously operate on multiple radio interfaces (e.g., LTE and / or LTE-A and BLUETOOTH). TM In addition, the UE often implements algorithms and / or policies for switching between various wireless interfaces for certain applications (e.g., for streaming data or for making audio and / or voice calls). For example, VoLTE allows the UE to make audio calls over LTE in addition to the ability to make voice calls over a circuit switched (CS) network.

[0006] In order to improve wireless communications, the concept of self-organizing networks (SON) has been introduced. SON represents an automated technology designed to facilitate simpler and faster planning, configuration, management, optimization and healing of mobile radio access networks. The functions and behaviors of SON have been specified according to various mobile industry recommendations, for example, as outlined by standard organizations such as 3GPP (3rd Generation Partnership Project) and NGMN (Next Generation Mobile Networks). SON enables cellular networks to self-optimize their performance based on observed failures. Although SON helps to solve the end-to-end performance of wireless networks, it cannot solve device-specific problems that affect mobile devices. In other words, when the problems that affect mobile devices are not completely specific to the network, SON cannot solve these problems.

[0007] Other related deficiencies of the prior art will become apparent to those skilled in the art after comparing such prior art with the disclosed embodiments described herein. Summary of the invention

[0008] In particular, embodiments of methods and processes for supporting various devices (e.g., wireless communication devices and (cloud) servers) to utilize crowd-sourced data to design and / or define and implement mitigation techniques to achieve improved device operation, thereby enabling mobile devices to operate as self-organizing devices are described herein. Embodiments of a wireless communication system are further described herein, which includes wireless communication devices (UEs), cloud servers, and / or base stations and access points (APs) that communicate with each other within the wireless communication system according to the various methods and processes disclosed herein.

[0009] As mentioned previously, the concept of Self-Organizing Networks (SON) was introduced as a set of standardized technologies that enable cellular networks to optimize their performance based on observed failures. Some of the key features supported by (or within) SON include:

[0010] Mobility Robustness Optimization (MRO), which helps address coverage enhancement;

[0011] Mobility Load Balancing (MLB) optimization, which helps address capacity enhancement;

[0012] Random Access Procedure (RACH) optimization, which helps optimize call setup delay, data recovery delay from uplink (UL) out-of-sync state, handover delay, etc.; and

[0013] Automatic or Automated Neighbor Relation (ANR) optimization, which automates the maintenance of Neighbor Relation (NR) lists, a task that had to be performed manually before the introduction of SON.

[0014] Although SON helps to solve the end-to-end performance of wireless networks, it cannot solve device-specific problems that are not only related to the network. For example, SON cannot provide support for a mechanism that can change the WiFi calling strategy for a specific device (e.g., a device associated with a specific user) based on the detection of poor coverage and call failure rate of a specific device. SON also cannot provide a mechanism for recovering from baseband failures and / or devices staying in poor coverage areas, and cannot be used to solve device-specific problems by dynamically installing software patches without providing air (OTA) updates (e.g., global software updates) for all devices to install. Generally speaking, even when configured for each carrier at a macro level, mechanisms and operating strategies may not provide the desired results, for example, meeting certain previously determined performance standards and / or expected results. Based on the behavior of other devices, such as problems experienced by other devices similar to the device to be updated, it can be beneficial to adjust and / or modify these calling strategies and mechanisms to adapt to the updates of each device.

[0015] Therefore, in order to improve the operation of the device, the principle of self-organization can be implemented in the device (e.g., a mobile device such as a device associated with a specific user). Accordingly, the device can be designed to operate as a self-organizing device. Such a self-organizing device (SOD) may include a centralized "listener" module or a recovery control module (RCM), which can monitor different events from various different operating domains associated with the wireless communication of the device (e.g., from different layers of the software stack), and based on the information collected as a result of the monitoring, an automatic recovery mechanism is executed when applicable. The device can provide the monitored information to a server (e.g., a cloud server), which can use an expert system to analyze the information collected from multiple devices, in many cases, analyze the information collected from devices scattered around the world, and design and / or define mitigation action responses corresponding to specific situations or conditions including device-specific considerations. The mitigation action response can be provided to the device by the server (e.g., from a cloud container) as an expert system rule in the form of uncompiled code, and the device can use the code to implement the necessary mitigation actions as needed. The RCM of the SOD can compare the monitored situations and / or conditions with previously identified situations and / or conditions, and can determine whether there is a corresponding mitigation action, for example, a mitigation action corresponding to the identified situation and / or condition. In response to identifying that such a mitigation action is available, the device can perform the mitigation action, thereby improving the operation of the device. In this way, for example, crowd-sourced information from globally dispersed devices can be utilized and / or used to design mitigation actions customized for specific conditions and / or situations (e.g., conditions specific to certain devices) without requiring global software updates.

[0016] In some embodiments, the device (e.g., mobile device) can periodically query the server (e.g., cloud server) to access the latest expert system rules. That is, the device can periodically query one or more servers or check with one or more servers--for example, to query or check the cloud container storing the expert system rules (including the list of conditions and corresponding mitigation actions)--thereby retrieving the updated expert system rules or updating the expert system rules on the device when applicable. This provides flexibility for the device to adapt to the changing conditions in the operating field. Therefore, when the public source data changes and / or accumulates, the expert system rules transmitted to the device can be automatically and / or dynamically changed and updated. According to this strategy, the device can be operated according to the "exploration and utilization" method. A certain number of devices (e.g., a certain percentage of devices) can continuously execute the mitigation (mitigation action) received from the server (e.g., from the expert system and / or cloud container in the server). Such devices can be considered as "utilization devices". The remaining devices may then operate in a "no mitigation" mode, performing no mitigation actions, but instead collecting the latest data points (e.g., current or present data points) from the operational domain for transmission to one or more servers to better reflect current operational conditions. Such devices may be considered "exploration devices." In some embodiments, a device may be both an exploitation device and an exploration device.

[0017] In some cases where multiple mitigation actions are possible, the server may provide various different mitigation (action) options corresponding to the same situation and / or condition (e.g., corresponding to the same anomaly) to different devices or different groups of devices, thereby establishing a feedback loop for each device to apply different mitigations and / or mitigation actions, and transmit information indicating the corresponding results of the mitigation and / or mitigation action (e.g., success and failure) back to the server. Based on the feedback loop, the best (e.g., successful) one or more mitigation actions corresponding to a given condition and / or anomaly may be established and selected as the mitigation and / or mitigation action to be universally (e.g., globally) applied by the device for the corresponding condition and / or anomaly type.

[0018] According to the above, in some embodiments, the device may monitor first wireless diagnostic information, which includes corresponding information corresponding to different operating domains associated with the wireless communication of the device (e.g., corresponding to different layers of the software stack associated with the wireless communication of the device). The device may identify the operating condition currently experienced by the device based on the monitored diagnostic information, and in response may perform a mitigation action corresponding to the operating condition, wherein the mitigation action will mitigate or eliminate the adverse effects of the operating condition experienced by the device. The device may receive a mitigation action in the form of code, and the device may use the code to implement the mitigation action. In some embodiments, the code may include uncompiled code, and in some embodiments, the code may include binary code that can be used by the device to hot-patch the device (e.g., by hot-patching the operating system of the device).

[0019] In some embodiments, a server (e.g., a cloud server) may analyze crowd-sourced wireless diagnostic information received from a large number of dispersed devices (e.g., from globally dispersed devices). The crowd-sourced wireless diagnostic information may include device-specific information corresponding to dispersed (or globally dispersed) devices. The server may identify a specific operating condition based on the analysis of the crowd-sourced wireless diagnostic information, and may define one or more mitigation actions corresponding to the operating condition. In the case where more than one mitigation action is defined, the server may transmit information representing different mitigation actions to devices of different corresponding groups for each different mitigation action. The server may receive corresponding results corresponding to each different mitigation action that has been performed, and may analyze the corresponding results. Thereafter, the server may select a mitigation action from the one or more mitigation actions as a preferred mitigation action based on the analysis of the corresponding results. The server may transmit the preferred mitigation action to a subgroup of dispersed devices, the subgroup including devices that have been affected by the operating condition.

[0020] It should be noted that the techniques described herein may be implemented in and / or used with a number of different types of devices, including but not limited to base stations, access points, cellular telephones, portable media players, tablet computers, wearable devices, and various other computing devices.

[0021] The present invention is intended to provide a brief overview of some of the themes described in this document. Therefore, it should be understood that the above features are only examples and should not be interpreted as narrowing the scope or essence of the themes described in this invention in any way. Other features, aspects and advantages of the themes described herein will become apparent through the following detailed description, drawings and claims. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] Figure 1An exemplary (and simplified) wireless communication system according to some embodiments is shown;

[0023] Figure 2 illustrates an exemplary base station in communication with an exemplary wireless user equipment (UE) device in accordance with some embodiments;

[0024] Figure 3 shows an exemplary block diagram of a UE according to some embodiments;

[0025] Figure 4 shows an exemplary block diagram of a base station according to some embodiments;

[0026] Figure 5 shows an exemplary simplified block diagram of an exemplary cellular communication circuit according to some embodiments;

[0027] Figure 6 An exemplary wireless communication system providing cellular and WiFi coverage is shown according to some embodiments;

[0028] Figure 7 An exemplary flow chart illustrating device and / or server interactions for implementing and integrating mitigation actions corresponding to specific conditions and / or situations (including device-specific considerations) according to some embodiments is shown;

[0029] Figure 8 shows an exemplary flow chart illustrating a reverse analysis pipeline for a self-organizing device according to some embodiments;

[0030] Fig. 9 shows a simplified block diagram of an exemplary architecture for self-organizing devices according to some embodiments;

[0031] Fig.10 shows an exemplary code segment of uncompiled code implementing expert system rules for performing one or more mitigation actions by a self-organizing device according to some embodiments;

[0032] Fig.11 showing a selected row of an exemplary table storing operational condition information for designing one or more mitigation actions for a dynamic WiFi calling policy for an ad hoc device according to some embodiments;

[0033] Fig.12 An exemplary block diagram representing the operation of an ad hoc device to implement one or more mitigation actions for a dynamic WiFi calling policy according to some embodiments is shown;

[0034] Fig.13shows a selected row of an exemplary table storing operating condition information for designing one or more mitigation actions for radio access technology and carrier aggregation based modem stability according to some embodiments;

[0035] Fig.14 An exemplary block diagram representing the operation of a self-organizing device to implement one or more mitigation actions for radio access technology and carrier aggregation based modem stability according to some embodiments is shown;

[0036] Fig.15 shows a selected row of an exemplary table storing operating condition information for designing one or more mitigation actions for cell barring based on anomaly signatures according to some embodiments;

[0037] Fig.16 An exemplary block diagram illustrating operation of a self-organizing device to implement one or more mitigation actions for cell barring based on anomaly signatures according to some embodiments is shown; and

[0038] Although the features described herein are susceptible to various modifications and alternative forms, specific embodiments thereof are shown by way of example in the drawings and described in detail herein. However, it should be understood that the drawings and detailed description thereof are not intended to limit this document to the specific forms disclosed, but on the contrary, their purpose is to cover all modifications, equivalents and alternatives that fall within the spirit and scope of the subject matter as defined by the appended claims. DETAILED DESCRIPTION

[0039] Acronyms

[0040] Various acronyms are used throughout this application. The definitions of the most prominent acronyms used that may appear throughout this application are as follows:

[0041] AMR: Adaptive Multi-Rate

[0042] AP: Access Point

[0043] APN: Access Point Name

[0044] APR: Application Processor

[0045] BS: Base Station

[0046] BSR: Buffer Size Report

[0047] BSS: Basic Service Set

[0048] CBRS: Citizens Broadband Radio Service

[0049] CBSD: Citizens Broadband Radio Service Device

[0050] CCA: Clear Channel Assessment

[0051] CID: Country Identifier

[0052] CMR: Change Mode Request

[0053] CS: Circuit Switching

[0054] DL: Downlink (from BS to UE)

[0055] DSDS: Dual SIM Dual Standby

[0056] DYN: Dynamic

[0057] EDCF: Enhanced Distributed Coordination Function ETL: Extract, Transform, Load

[0058] FDD: Frequency Division Duplex

[0059] FO: First-order state

[0060] FT: frame type

[0061] GAA: General Authorization Access

[0062] GPRS: General Packet Radio Service GSM: Global System for Mobile Communications

[0063] GTP: GPRS Tunneling Protocol

[0064] ·IMS: Internet Protocol Multimedia Subsystem ·IP: Internet Protocol

[0065] IPsec: Internet Protocol Security

[0066] IR: Initialization and refresh status

[0067] KPI: Key Performance Indicator

[0068] LAN: Local Area Network

[0069] LBT: Listen before speaking

[0070] LQM: Link Quality Metric

[0071] LTE: Long Term Evolution

[0072] MNO: Mobile Network Operator

[0073] MT: Mobile station called

[0074] NB: Narrow Band

[0075] NID: Network Identifier

[0076] OOS: Out of sync

[0077] OUI: Organizational Unit Identifier

[0078] PAL: Priority Access Licensee

[0079] PDCP: Packet Data Convergence Protocol

[0080] PDN: Packet Data Network

[0081] PDU: Protocol Data Unit

[0082] PGW: PDN Gateway

[0083] PLMN: Public Land Mobile Network

[0084] PSD: Power Spectral Density

[0085] PSS: Primary Synchronization Signal

[0086] PT: Payload Type

[0087] QBSS: Basic Service Set with enhanced quality of service

[0088] QI: Quality Indicator

[0089] RAT: Radio Access Technology

[0090] RF: Radio Frequency

[0091] ROHC: Robust Header Compression

[0092] RTP: Real-time Transport Protocol

[0093] RTT: Round Trip Time

[0094] RX: Receive / Receive

[0095] SAS: Spectrum Allocation Server

[0096] SID: System Identification Number

[0097] SIM: Subscriber Identity Module

[0098] SGW: Service Gateway

[0099] SMB: Small and medium-sized business

[0100] SSS: Secondary synchronization signal

[0101] TBS: Transport Block Size

[0102] TCP: Transmission Control Protocol

[0103] TDD: Time Division Duplex

[0104] TX: Transmit / Transmit

[0105] UE: User Equipment

[0106] UL: Uplink (from UE to BS)

[0107] UMTS: Universal Mobile Telecommunications System

[0108] USIM: UMTS User Identity Module

[0109] ·WB:Broadband

[0110] WD: Wireless Diagnostics

[0111] WiFi: Wireless local area network (WLAN) RAT based on the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standard

[0112] WLAN: Wireless Local Area Network

[0113] the term

[0114] The following is a glossary of terms that may appear in this application:

[0115] Memory medium – Any of various types of memory devices or storage devices. The term “memory medium” is intended to include installation media, such as CD-ROM, floppy disk, or tape device; computer system memory or random access memory such as DRAM, DDR RAM, SRAM, EDO RAM, Rambus RAM, etc.; non-volatile memory such as flash memory, magnetic media, such as hard disk drive or optical storage device; registers, or other similar types of memory elements, etc. The memory medium may also include other types of memory or combinations thereof. In addition, the memory medium may be located in a first computer system executing a program, or may be located in a different second computer system connected to the first computer system via a network such as the Internet. In the latter example, the second computer system may provide program instructions to the first computer system for execution. The term “memory medium” may include two or more memory media that may reside in different locations in different computer systems connected, for example, via a network.

[0116] Carrier Medium—storage media as described above, and physical transmission media such as a bus, network, and / or other physical transmission media that transport signals such as electrical, electromagnetic or digital signals.

[0117] Programmable hardware element - includes various hardware devices that include multiple programmable function blocks connected via programmable interconnects. Examples include FPGA (field programmable gate array), PLD (programmable logic device), FPOA (field programmable object array), and CPLD (complex PLD). Programmable function blocks can vary from fine-grained (combinational logic unit or lookup table) to coarse-grained (arithmetic logic unit or processor core). Programmable hardware elements may also be referred to as "reconfigurable logic units".

[0118] Computer System (or Computer) - Any of various types of computing or processing systems, including a personal computer system (PC), a mainframe computer system, a workstation, a network appliance, an Internet appliance, a personal digital assistant (PDA), a television system, a grid computing system, or other devices or combinations of devices. In general, the term "computer system" may be broadly defined as any device (or combination of devices) that includes at least one processor that executes instructions from a memory medium.

[0119] User Equipment (UE) (or "UE device") - Any of various types of computer system devices that perform wireless communications. Also referred to as wireless communication devices, many of which may be mobile and / or portable. Examples of UE devices include mobile phones or smartphones (e.g., iPhones). TM , based on Android TM phones) and tablets such as iPads TM 、Samsung Galaxy TM etc., gaming devices (such as Sony PlayStation TM , Microsoft Xbox TM etc.), portable gaming devices (e.g., Nintendo DS TM , PlayStation Portable TM 、Gameboy Advance TM , iPod TM ), laptops, wearable devices (e.g., Apple Watch TM , Google Glass TM ), PDAs, portable Internet devices, music players, data storage devices or other handheld devices, unmanned aerial vehicles (e.g., drones) and drone controllers, etc. Various other types of devices that include WiFi communication capabilities or both cellular and WiFi communication capabilities and / or other wireless communication capabilities (e.g., via short-range radio access technologies (SRAT) such as BLUETOOTH TMIn general, the term "UE" or "UE device" may be broadly defined to cover any electronic device, computing device and / or telecommunication device (or combination of devices) capable of wireless communication and may also be portable and / or mobile.

[0120] Wireless device (or wireless communication device) – Any of various types of computer system devices that perform wireless communication using WLAN communication, SRAT communication, WiFi communication, etc. As used herein, the term “wireless device” may refer to a UE device as defined above or a fixed device such as a fixed wireless client or a wireless base station. For example, a wireless device may be a wireless station of any type of 802.11 system, such as an access point (AP) or a client station (UE), or a wireless station of any type of cellular communication system that communicates according to a cellular radio access technology (e.g., LTE, CDMA, GSM), such as a base station or a cellular phone.

[0121] Communication device - any of various types of computer systems or devices that perform communication, where the communication may be wired or wireless. A communication device may be portable (or mobile), or may be stationary or fixed at a location. A wireless device is an example of a communication device. A UE is another example of a communication device.

[0122] Base Station (BS)—The term "base station" has the full breadth of its ordinary meaning and includes at least a wireless communication station installed at a fixed location and used to communicate as part of a wireless telephone system or radio system.

[0123] Camping on a network and / or cell - means that a device (e.g., a mobile device (UE)) has completed a network and / or cell selection and / or reselection process and has selected a network and / or cell. As part of camping on a network and / or cell, the UE may monitor system information and (in most cases) paging information on the network and / or cell.

[0124] Barred networks and / or cells—refers to networks and / or cells that a given mobile device is not allowed to camp on. In some cases, specific networks and / or cells may be barred for a given device (e.g., the device itself may bar specific networks and / or cells). Barring may be for a specified duration or a period of time of a specified duration, meaning that the device is not allowed to camp on the specific network and / or cell for at least the specified duration and / or a period of time of a specified duration from the point in time when the specific network and / or cell is barred.

[0125] Processor—refers to various elements (e.g., circuits) or combinations of elements that are capable of performing functions in a device (e.g., a user equipment device or a cellular network device). Processors may include, for example: general purpose processors and associated memory, portions or circuits of individual processor cores, entire processor cores or processing circuit cores, processing circuit arrays or processor arrays, circuits such as ASICs (application specific integrated circuits), programmable hardware elements such as field programmable gate arrays (FPGAs), and any various combinations of the foregoing.

[0126] Expert System - refers to a variety of systems that use artificial intelligence techniques and databases of expert knowledge to provide information used in decision making. Typically, an expert system may combine a knowledge base containing accumulated experience and a reasoning or rules engine that defines a set of rules for applying the knowledge base to each specific situation described to the system. The capabilities of the system may be enhanced through additions to the knowledge base or the set of rules. Expert systems may include machine learning capabilities that allow them to improve their performance based on experience, similar to human learning.

[0127] Channel - a medium used to transmit information from a sender (transmitter) to a receiver. It should be noted that since the characteristics of the term "channel" may vary according to different wireless protocols, the term "channel" used herein may be considered to be used in a manner that conforms to the standards of the type of device to which the term is used. In some standards, the channel width may be variable (e.g., depending on device capabilities, frequency band conditions, etc.). For example, LTE may support scalable channel bandwidths of 1.4 MHz to 20 MHz. In contrast, a WLAN channel may be 22 MHz wide, while a Bluetooth channel may be 1 MHz wide. Other protocols and standards may include different definitions of channels. In addition, some standards may define and use multiple types of channels, such as different channels for uplink or downlink and / or different channels for different purposes such as data, control information, etc.

[0128] Band—The term “band” has the full breadth of its ordinary meaning and includes at least a segment of the spectrum (eg, radio frequency spectrum) in which channels are used or set aside for the same purpose.

[0129] WiFi—The term "WiFi" has the full scope of its usual meaning and includes at least wireless communication networks or RATs that are served by wireless LAN (WLAN) access points and provide connectivity to the Internet through these access points. Most modern WiFi networks (or WLAN networks) are based on the IEEE 802.11 standard and are marketed under the name "WiFi". WiFi (WLAN) networks are different from cellular networks.

[0130] Automatic—refers to an action or operation performed by a computer system (e.g., software executed by a computer system) or a device (e.g., a circuit, a programmable hardware element, an ASIC, etc.) without the need for user input to directly specify or perform the action or operation. Thus, the term "automatic" is in contrast to an operation manually performed or specified by a user, where the user provides input to directly perform the operation. An automatic process may be initiated by input provided by a user, but subsequent actions performed "automatically" are not specified by the user, i.e., are not performed "manually," where the user specifies each action to be performed. For example, a user filling out an electronic form by selecting each field and providing input specifying information (e.g., by typing in information, selecting check boxes, radio selections, etc.) is manually filling out the form, even though the computer system must update the form in response to user actions. The form may be automatically filled out by a computer system, where the computer system (e.g., software executed on the computer system) analyzes the fields of the form and fills out the form without any user input specifying the answers to the fields. As indicated above, a user may invoke automatic filling out of a form, but not participate in the actual filling out of the form (e.g., the user does not manually specify the answers to the fields but rather they are automatically completed). This specification provides various examples of operations that are automatically performed in response to actions taken by a user.

[0131] Approximately - refers to a value that is almost correct or exact. For example, approximately can refer to a value that is within 1% to 10% of an exact (or desired) value. However, it should be noted that the actual threshold (or tolerance) may depend on the application. For example, in some embodiments, "approximately" may mean within 0.1% of some specified or desired value, while in various other embodiments, the threshold may be, for example, 2%, 3%, 5%, etc., depending on the desires or requirements of a particular application.

[0132] Concurrency - refers to parallel execution or implementation, where tasks, processes, or programs are executed in an at least partially overlapping manner. For example, concurrency can be achieved using "strong" or strict parallelism, where tasks are executed (at least partially) in parallel on respective computing elements, or using "weak parallelism", where tasks are executed in an interleaved manner (e.g., by time multiplexing of execution threads).

[0133] Station (STA) - The term "station" herein refers to any device that has the ability to communicate wirelessly (e.g., using 802.11 protocols). A station may be a laptop, desktop PC, PDA, access point, or WiFi phone, or any type of device similar to a UE. A STA may be fixed, mobile, portable, or wearable. Generally speaking, in wireless networking terminology, a station (STA) broadly encompasses any device that has wireless communication capabilities, and the terms station (STA), wireless client (UE), and node (BS) are therefore often used interchangeably.

[0134] Configured to - Various components may be described as being "configured to" perform one or more tasks. In such environments, "configured to" is a broad statement that generally means "having a structure" that performs one or more tasks during operation. Thus, a component can be configured to perform a task even when the component is not currently performing the task (e.g., a set of electrical conductors can be configured to electrically connect a module to another module even when the two modules are not connected). In some environments, "configured to" can be a broad statement that generally means "having circuitry that performs one or more tasks during operation." Thus, the component can be configured to perform a task even when the component is not currently turned on. Typically, the circuitry that forms the structure corresponding to "configured to" may include hardware circuitry.

[0135] Transmission Scheduling - refers to the scheduling of transmissions (such as wireless transmissions). In cellular radio communications, signals and data transmissions can be organized according to designated time units of a specific duration for transmission. For example, in LTE, transmissions are divided into radio frames, each of which has an equal (time) duration (e.g., each radio frame can be 10ms). The radio frames in LTE can be further divided into ten subframes, each of which has an equal duration, and the subframes are designated as the minimum (shortest) scheduling unit, or a designated time unit for transmission. Similarly, the minimum (or shortest) scheduling unit for 5G NR (or simply NR) transmission is called a time slot. Therefore, as used herein, the term "time slot" is used to refer to the minimum (or shortest) scheduling time unit of wireless communication described as performing NR communication. However, as described above, in different communication protocols, such scheduling time units may be named differently, for example, they are named "subframes" in LTE, and so on.

[0136] For ease of description, various components may be described as performing one or more tasks. Such descriptions should be interpreted as including the phrase "configured to". The description of a component being configured to perform one or more tasks is expressly intended to not invoke the interpretation of the sixth paragraph of Section 112 of Title 35 of the United States Code on that component.

[0137] Figure 1 and Figure 2 -Exemplary Communication System

[0138] Figure 1 An exemplary (and simplified) wireless communication system according to some embodiments is shown. Note that Figure 1 The system is only an example of one possible system, and the embodiments may be implemented in any of a variety of systems as desired.

[0139] As shown, an exemplary wireless communication system includes a base station 102 that communicates with one or more user devices 106A to 106N via a transmission medium. Each user device may be referred to herein as a "user equipment" (UE) or UE device. Therefore, user device 106 is referred to as a UE or UE device. According to various embodiments disclosed herein, a variety of UE devices may operate in response to encountering specific operating conditions that take into account device-specific considerations to implement mitigation actions.

[0140] Base station 102 may be a base transceiver station (BTS) or a cell site, and may include hardware for enabling wireless communications with UEs 106A to 106N. Base station 102 may also be equipped to communicate with network 100 (e.g., a core network of a cellular service provider, a telecommunications network such as a public switched telephone network (PSTN), and / or the Internet, a neutral host or various CBRS deployments, and various possibilities). Therefore, base station 102 may facilitate communication between user devices and / or between user devices and network 100. The communication area (or coverage area) of a base station may be referred to as a "cell". It should also be noted that a "cell" may also refer to a logical identity for a given coverage area at a given frequency. In general, any independent cellular wireless coverage area may be referred to as a "cell". In such a case, a base station may be located at a specific intersection of three cells. In this uniform topology, a base station may serve three 120-degree beam width areas called cells. Moreover, for carrier aggregation, small cells, relays, etc. may all represent cells. Thus, particularly in carrier aggregation, there may be primary cells and secondary cells that may serve at least partially overlapping coverage areas but on different respective frequencies. For example, a base station may serve any number of cells, and the cells served by a base station may or may not be collocated (e.g., a remote radio head). Also as used herein, with respect to a UE, a base station may sometimes be considered to represent a network in light of uplink and downlink communications of the UE. Thus, a UE that communicates with one or more base stations in a network may also be understood as a UE that communicates with the network.

[0141] The base station 102 and the user equipment may be configured to communicate over a transmission medium using any of a variety of radio access technologies (RATs), also referred to as wireless communication technologies or telecommunication standards, such as GSM, UMTS (WCDMA), LTE, LTE-Advanced (LTE-A), LAA / LTE-U, 5G-NR (abbreviated as NR), 3GPP2 CDMA2000 (e.g., 1xRTT, 1xEV-DO, HRPD, eHRPD), WiFi, WiMAX, etc. It is noted that if the base station 102 is implemented in the context of LTE, it may alternatively be referred to as an "eNodeB" or "eNB". It is noted that if the base station 102 is implemented in the context of 5G NR, it may alternatively be referred to as a 'gNodeB' or a 'gNB'. In some embodiments, the base station 102 (e.g., an eNB in ​​an LTE network or a gNB in ​​an NR network) may communicate with at least one UE having the capability to implement mitigation actions in response to encountering a specific operating condition taking into account device-specific considerations, as described herein. Depending on a given application or specific considerations, for convenience, some different RATs may be functionally grouped according to overall defining features. For example, all cellular RATs may be collectively considered to represent a first (form and / or type) RAT, while WiFi communications may be considered to represent a second RAT. In other cases, individual cellular RATs may be individually considered to be different RATs. For example, when distinguishing between cellular communications and WiFi communications, "first RAT" may collectively refer to all cellular RATs considered, while "second RAT" may refer to WiFi. Similarly, when applicable, different forms of WiFi communications (e.g., over 2.4 GHz and over 5 GHz) may be considered to correspond to different RATs. In addition, cellular communications performed according to a given RAT (e.g., LTE or NR) may be distinguished from each other based on the spectrum in which those communications are performed. For example, LTE or NR communications may be performed on a primary licensed spectrum and on an auxiliary spectrum of an unlicensed spectrum and / or spectrum assigned to a Citizen Broadband Radio Service (CBRS). In general, the use of various terms and expressions will always be clearly indicated relative to the environment of the various applications and / or implementations considered and within that environment.

[0142] As shown, the base station 102 may also be equipped to communicate with the network 100 (e.g., in various possibilities, a core network of a cellular service provider, a telecommunications network such as a public switched telephone network (PSTN) and / or the Internet). Thus, the base station 102 may facilitate communication between user devices and / or between user devices and the network 100. In particular, the cellular base station 102 may provide a UE 106 with various telecommunication capabilities such as voice, short message service (SMS) and / or data services. The UE 106 may be capable of communicating using multiple wireless communication standards. For example, the UE 106 may be configured to communicate using any or all of a 3GPP cellular communication standard (such as LTE or NR) or a 3GPP2 cellular communication standard (such as a cellular communication standard in the CDMA2000 family of cellular communication standards). Base station 102 and other similar base stations (such as base stations 102B...102N) operating according to the same or different cellular communication standards can therefore be provided as one or more cell networks that can provide continuous or nearly continuous overlapping services to UE 106 and similar devices over a wide geographic area via one or more cellular communication standards.

[0143] Thus, although base station 102 may function as Figure 1 In the illustrated "serving cell" of UEs 106A-106N, each UE 106 may also be able to receive signals from (and possibly be within communication range of) one or more other cells (which may be provided by base stations 102B-N and / or any other base stations), which may be referred to as "neighboring cells." Such cells may also be able to facilitate communications between user devices and / or between user devices and network 100. Such cells may include "macro" cells, "micro" cells, "pico" cells, and / or any other variety of other granularity of cells providing service area sizes. For example, in Figure 1 Base stations 102 and 102B shown in FIG. 1 may be macro cells, while base station 102N may be a micro cell. Other configurations are also possible.

[0144] In some embodiments, base station 102 may be a next generation base station, e.g., a 5G New Radio (5G NR) base station, or "gNB". In some embodiments, a gNB may be connected to a legacy Evolved Packet Core (EPC) network and / or to a New Radio Core (NRC) network. In addition, a gNB cell may include one or more transmission and reception points (TRPs). In addition, a UE capable of operating in accordance with 5G NR may be connected to one or more TRPs within one or more gNBs.

[0145] UE 106 may also or alternatively be configured to use WLAN, BLUETOOTH TM 、BLUETOOTHTM The UE 106 may be a wireless communication system that is configured to communicate with the network 100 via one or more base stations, or other devices, stations, or any other apparatus that is not explicitly shown but is considered to be part of the network 100. Therefore, a UE 106 communicating with the network may be interpreted as a UE 106 communicating with one or more network nodes that are considered to be part of the network, and may interact with the UE 106 to communicate with the UE 106, and in some cases affect at least some communication parameters and / or the use of communication resources of the UE 106.

[0146] In addition, for example Figure 1 As shown in , at least some UEs (e.g., UE 106D and 106E) may represent vehicles that communicate with each other and with base station 102, for example, via cellular communications such as 3GPP LTE and / or 5G-NR communications. Additionally, UE 106F may represent pedestrians that are communicating and / or interacting with the vehicles represented by UE 106D and 106E in a similar manner. In the context of vehicle-to-everything (V2X) communications (such as communications specified by 3GPP TS 22.185 V 14.3.0, etc.), disclosed in Figure 1 Various aspects of a vehicle communicating in a network illustrated in FIG.

[0147] Figure 2 An exemplary user equipment 106 (e.g., one of devices 106A to 106N) is shown communicating with a base station 102 and an access point 112 according to some embodiments. The UE 106 may be a device having cellular communication capabilities and non-cellular communication capabilities (e.g., BLUETOOTH TM, WiFi, etc.), such as a mobile phone, a handheld device, a computer or a tablet computer, or almost any type of wireless device. UE 106 may include a processor configured to execute program instructions stored in a memory. UE 106 may execute any of the method embodiments described herein by executing such stored instructions. Alternatively or in addition, UE 106 may include a programmable hardware element, such as a field programmable gate array (FPGA) configured to execute any of the method embodiments described herein or any part of any of the method embodiments described herein. UE 106 may be configured to communicate using any one of a plurality of wireless communication protocols. For example, UE 106 may be configured to communicate using two or more of CDMA 2000, LTE, LTE-A, NR, WLAN, or GNSS. Other combinations of wireless communication standards are also possible.

[0148] UE 106 may include one or more antennas for communicating using one or more wireless communication protocols according to one or more RAT standards, such as those previously described above. In some embodiments, UE 106 may share one or more parts of a receive chain and / or transmit chain between multiple wireless communication standards. The shared radio component may include a single antenna, or may include multiple antennas for performing wireless communication (e.g., for MIMO). Alternatively, UE 106 may include an independent transmit chain and / or receive chain (e.g., including independent antennas and other radio components) for each wireless communication protocol configured to communicate with it. As another alternative, UE 106 may include one or more radio components or radio circuits shared between multiple wireless communication protocols, as well as one or more radio components used exclusively by a single wireless communication protocol. For example, UE 106 may include a radio for communicating using any one of LTE or CDMA2000 1xRTT or NR and / or using WiFi and BLUETOOTH TM Each of the radio circuits for communicating. Other configurations are also possible.

[0149] Figure 3 - Block diagram of an exemplary UE

[0150] Figure 3A block diagram of an exemplary UE 106 according to some embodiments is shown. As shown, the UE 106 may include a system on chip (SOC) 300, which may include parts for various purposes. For example, as shown, the SOC 300 may include one or more processors 302 that can execute program instructions for the UE 106, and a display circuit 304 that can perform graphics processing and provide display signals to a display 360. The processor 302 may also be coupled to a memory management unit (MMU) 340, and / or other circuits or devices (such as display circuit 304, radio circuit 330, connector I / F 320 and / or display 360), which may be configured to receive addresses from the processor 302 and convert those addresses into locations in a memory (e.g., memory 306, read-only memory (ROM) 350, NAND flash memory 310). The MMU 340 may be configured to perform memory protection and page table conversion or setting. In some embodiments, the MMU 340 may be included as part of the processor 302.

[0151] As shown, SOC 300 may be coupled to various other circuits of UE 106. For example, UE 106 may include various types of memory (e.g., including NAND flash memory 310), a connector interface 320 (e.g., for coupling to a computer system), a display 360, and wireless communication circuits (e.g., for LTE, LTE-A, NR, CDMA2000, BLUETOOTH TM , WiFi, GPS, etc.). The UE device 106 may include at least one antenna (e.g., 335a), and may include multiple antennas (e.g., as shown by antennas 335a and 335b) for performing wireless communications with base stations and / or other devices. Antennas 335a and 335b are shown by way of example, and the UE device 106 may include fewer or more antennas. In general, one or more antennas are collectively referred to as antennas 335. For example, the UE device 106 may use antenna 335 to perform wireless communications with the aid of radio circuitry 330. As described above, in some embodiments, the UE may be configured to perform wireless communications using multiple wireless communication standards.

[0152] As further described herein, the UE 106 may include hardware and software components to implement at least a method for the UE 106 to implement mitigation actions in response to encountering a specific operating condition that takes into account device-specific considerations, as further described herein. One or more processors 302 of the UE device 106 may be configured to implement a portion or all of the methods described herein, for example by executing program instructions stored on a memory medium (e.g., a non-transitory computer-readable memory medium). In other embodiments, one or more processors 302 may be configured as a programmable hardware element, such as an FPGA (field programmable gate array) or as an ASIC (application-specific integrated circuit). In addition, according to various embodiments disclosed herein, the processor 302 may be coupled to and / or may be connected to Figure 3 The other components shown in 106 interoperate to implement communications performed by UE 106, which is combined with performing mitigation actions in response to encountering specific operating conditions taking into account device-specific considerations. The one or more processors 302 can also implement various other applications and / or end-user applications running on UE 106.

[0153] In some embodiments, the radio circuit 330 may include a separate controller dedicated to controlling communications for each respective RAT standard. Figure 3 As shown, the radio circuit 330 may include a WiFi controller 356, a cellular controller (eg, LTE and / or NR controller) 352, and a BLUETOOTH controller. TM Controller 354, and in at least some embodiments, one or more or all of these controllers may be implemented as respective integrated circuits (referred to as ICs or chips) that communicate with each other and with SOC 300 (more specifically, with processor 302). For example, WiFi controller 356 may communicate with cellular controller 352 via a cell-ISM link or WCI interface, and / or BLUETOOTH TM Controller 354 may communicate with cellular controller 352 via a cell-ISM link or the like. Although three separate controllers are shown within radio circuitry 330, other embodiments have fewer or more similar controllers for various different RATs that may be implemented in UE device 106. For example, in Figure 5 At least one exemplary block diagram illustrating some embodiments of the cellular controller 352 is shown in FIG. 1 and will be described below.

[0154] Figure 4 - Block diagram of an exemplary base station

[0155] Figure 4 1 shows a block diagram of an exemplary base station 102 according to some embodiments. Note that Figure 4The base station of is only one example of a possible base station. As shown, the base station 102 may include a processor 404 that may execute program instructions for the base station 102. The processor 404 may also be coupled to a memory management unit (MMU) 440 or other circuit or device, which may be configured to receive addresses from the processor 404 and convert these addresses to locations in memory (e.g., memory 460 and read-only memory (ROM) 450).

[0156] Base station 102 may include at least one network port 470. Network port 470 may be configured to couple to a telephone network and provide access to the telephone network described above. Figure 1 and Figure 2 The network port 470 may be configured to couple to a plurality of devices such as the UE device 106 of the telephone network described in the embodiment of the present invention. The network port 470 (or an additional network port) may also be configured or alternatively configured to couple to a cellular network, such as a core network of a cellular service provider. The core network may provide mobility-related services and / or other services to a plurality of devices such as the UE device 106. In some cases, the network port 470 may be coupled to the telephone network via the core network, and / or the core network may provide the telephone network (e.g., in other UE devices served by the cellular service provider).

[0157] The base station 102 may include at least one antenna 434a, and may include multiple antennas (e.g., as shown by antennas 434a and 434b) for performing wireless communications with mobile devices and / or other devices. Antennas 434a and 434b are shown as examples, and the base station 102 may include fewer or more antennas. Generally speaking, one or more antennas are collectively referred to as antennas 434. Antenna 434 may be configured to operate as a wireless transceiver, and may be further configured to communicate with UE device 106 via radio circuit 430. Antenna 434 communicates with radio component 430 via communication chain 432. Communication chain 432 may be a receiving chain, a transmitting chain, or both. Radio circuit 430 may be designed to communicate via various wireless telecommunication standards, including but not limited to LTE, LTE-A, 5G-NR (NR) WCDMA, CDMA2000, etc. The processor 404 of the base station 102 may be configured to implement some or all of the methods described herein, for example, by executing program instructions stored on a storage medium (e.g., a non-transitory computer-readable storage medium) for the base station 102 to communicate with a UE device capable of implementing mitigation actions in response to encountering a specific operating condition that takes into account device-specific considerations. Alternatively, the processor 404 may be configured as a programmable hardware element such as an FPGA (field programmable gate array) or as an ASIC (application-specific integrated circuit) or a combination thereof. In the case of certain RATs (e.g., WiFi), the base station 102 may be designed as an access point (AP), in which case the network port 470 may be implemented to provide access to a wide area network and / or one or more local area networks, for example, it may include at least one Ethernet port, and the radio component 430 may be designed to communicate according to the WiFi standard. According to various embodiments described herein, the base station 102 may operate according to the various methods disclosed herein, thereby communicating with a mobile device capable of performing mitigation actions in response to encountering a specific operating condition that takes into account device-specific considerations.

[0158] Figure 5 —Exemplary Cellular Communications Circuit

[0159] Figure 5 An exemplary simplified block diagram of an exemplary cellular controller 352 according to some embodiments is shown. Note that Figure 5The block diagram of the cellular communication circuitry of is only one example of possible cellular communication circuitry; other circuitry, such as circuitry that includes or is coupled to sufficient antennas for different RATs to perform uplink activities using separate antennas, or circuitry that includes or is coupled to fewer antennas, such as circuitry that can be shared between multiple RATs, is also possible. According to some embodiments, the cellular communication circuitry 352 may be included in a communication device such as the communication device 106 described above. As described above, the communication device 106 may be a user equipment (UE) device, a mobile device or mobile station, a wireless device or wireless station, a desktop computer or computing device, a mobile computing device (e.g., a laptop, notebook, or portable computing device), a tablet computer, and / or a combination of devices, among other devices.

[0160] Cellular communication circuitry 352 may be (e.g., communicatively; directly or indirectly) coupled to one or more antennas, such as antennas 335a-b and 336 as shown. In some embodiments, cellular communication circuitry 352 may include dedicated receive chains (including and / or (e.g., communicatively; directly or indirectly) coupled to dedicated processors and / or radio components) for multiple RATs (e.g., a first receive chain for LTE and a second receive chain for 5G NR). For example, Figure 5 As shown, the cellular communication circuit 352 may include a first modem 510 and a second modem 520. The first modem 510 may be configured for communication according to a first RAT (e.g., such as LTE or LTE-A), and the second modem 520 may be configured for communication according to a second RAT (e.g., such as 5GNR).

[0161] As shown, the first modem 510 may include one or more processors 512 and a memory 516 in communication with the processor 512. The modem 510 may communicate with a radio frequency (RF) front end 530. The RF front end 530 may include circuits for transmitting and receiving radio signals. For example, the RF front end 530 may include a receiving circuit (RX) 532 and a transmitting circuit (TX) 534. In some embodiments, the receiving circuit 532 may communicate with a downlink (DL) front end 550, which may include circuits for receiving radio signals via an antenna 335a.

[0162] Similarly, the second modem 520 may include one or more processors 522 and a memory 526 in communication with the processor 522. The modem 520 may communicate with the RF front end 540. The RF front end 540 may include circuits for transmitting and receiving radio signals. For example, the RF front end 540 may include a receiving circuit 542 and a transmitting circuit 544. In some embodiments, the receiving circuit 542 may communicate with the DL front end 560, which may include circuits for receiving radio signals via the antenna 335b.

[0163] In some embodiments, the switch 570 may couple the transmit circuit 534 to an uplink (UL) front end 572. In addition, the switch 570 may couple the transmit circuit 544 to the UL front end 572. The UL front end 572 may include circuitry for transmitting radio signals via the antenna 336. Thus, when the cellular communication circuit 352 receives an instruction to transmit according to a first RAT (e.g., via a transmit chain including the transmit circuit 534 and the UL front end 572) supported by the first modem 510, the switch 570 may be switched to a first state that allows the first modem 510 to transmit signals according to the first RAT (e.g., via a transmit chain including the transmit circuit 534 and the UL front end 572). Similarly, when the cellular communication circuit 352 receives an instruction to transmit according to a second RAT (e.g., via a transmit chain including the transmit circuit 544 and the UL front end 572) supported by the second modem 520, the switch 570 may be switched to a second state that allows the second modem 520 to transmit signals according to the second RAT (e.g., via a transmit chain including the transmit circuit 544 and the UL front end 572).

[0164] As described herein, the first modem 510 and / or the second modem 520 may include hardware and software components for implementing any of the various features and techniques described herein. For example, by executing program instructions stored on a memory medium (e.g., a non-transitory computer-readable memory medium), the processors 512, 522 may be configured to implement part or all of the features described herein. Alternatively (or in addition), the processors 512, 522 may be configured as programmable hardware elements, such as an FPGA (field programmable gate array) or as an ASIC (application-specific integrated circuit). Alternatively (or in addition), in combination with one or more of the other components 530, 532, 534, 540, 542, 544, 550, 570, 572, 335, and 336, the processors 512, 522 may be configured to implement part or all of the features described herein.

[0165] In addition, as described herein, the processors 512, 522 may include one or more processing elements. Thus, the processors 512, 522 may include one or more integrated circuits (ICs) configured to perform the functions of the processors 512, 522. In addition, each integrated circuit may include circuits (e.g., first circuits, second circuits, etc.) configured to perform the functions of the processors 512, 522.

[0166] In some embodiments, the cellular communication circuit 352 may include only one transmit chain / receive chain. For example, the cellular communication circuit 352 may not include the modem 520, the RF front end 540, the DL front end 560, and / or the antenna 335b. As another example, the cellular communication circuit 352 may not include the modem 510, the RF front end 530, the DL front end 550, and / or the antenna 335a. In some embodiments, the cellular communication circuit 352 may also not include the switch 570, and the RF front end 530 or the RF front end 540 may communicate with the UL front end 572, for example, directly.

[0167] Figure 6 —Exemplary Communication System

[0168] Figure 6 An exemplary wireless communication system 600 is shown in which a device can communicate in accordance with multiple radio access technologies (RATs) using different corresponding radio circuits for each RAT. System 600 is a system that implements an LTE (or NR) access network and a WiFi radio access network. System 600 may include UE 106 and an LTE (or NR) network 604 and a WiFi network 606.

[0169] LTE (or NR) access network 604 represents some embodiments of first RAT access, and WiFi access network 606 represents some embodiments of second RAT access. LTE (or NR) access network 604 can interact with a wider cellular network (e.g., LTE or NR), and WiFi access network 606 can interact with the Internet 614. More specifically, LTE (or NR) access network 504 can interact with a serving base station (BS) 608, which in turn can provide access to a wider cellular network 616. WiFi access network 606 can interact with an access point (AP) 610, which in turn can provide access to the Internet 614. Thus, UE 106 can access the Internet 614 via AP 610, and can access the cellular network 616 via LTE access network 604. In some embodiments (not shown), UE 106 can also access the Internet 614 via LTE (or NR) access network 604. More specifically, the LTE (or NR) access network 604 may interact with a serving gateway, which in turn may interact with a packet data network (PDN) gateway. The PDN gateway may in turn interact with the Internet 614. Thus, the UE 106 may access the Internet 614 via one or both of the LTE (or NR) access network 604 and the WiFi access network 606. While interacting with the Internet 614, the UE 106 may interact with various devices that also interact with the Internet 614, for example, these devices may be servers such as cloud servers, etc. Thus, the UE 106 may perform various communications, such as data transmission or audio voice calls, via either or both of the LTE (or NR) access network 604 and the WiFi access network 606. In addition, although Figure 6 An LTE (or NR) access network is shown, but the UE 106 can also access other cellular networks (not shown, such as a CBRS network) in a manner similar to accessing the LTE (or NR) access network 604.

[0170] Self-organizing network

[0171] As previously noted, a self-organizing network (SON) is an automated technology designed to make planning, configuration, management, optimization, and fault recovery of mobile radio access networks simpler and faster. SON functions and behaviors have been defined and specified in recognized mobile industry recommendations developed by organizations such as 3GPP (3rd Generation Partnership Project) and NGMN (Next Generation Mobile Networks). SON technical features were first deployed in Long Term Evolution (LTE) networks, but the technology has also been adapted for use in older radio access technologies such as Universal Mobile Telecommunications System (UMTS). For example, the LTE specification inherently supports SON features such as automatic neighbor relation (ANR) detection. Newly added base stations self-configure according to a "plug and play" paradigm, while all operational base stations periodically self-optimize parameters and algorithm behaviors in response to observed network performance and radio conditions. In addition, self-healing mechanisms can be triggered to temporarily compensate for detected equipment outages while waiting for a more permanent solution. SON architecture types include distributed, centralized, and hybrid. In addition, self-organizing network functions are generally divided into three main sub-functional groups, each of which contains a wide range of decomposed use cases. These groups include self-configuring functions, self-optimizing functions, and self-healing functions.

[0172] Self-configuration involves the automatic configuration of new base stations and their integration into the network, where the establishment of connections and the downloading of configuration parameters are implemented by software. Self-configuration is usually provided by equipment suppliers as part of the software delivery accompanying each radio cell. When a new base station is introduced into the network and powered on, it can be immediately recognized and registered by the network, and neighboring base stations can automatically adjust their technical parameters (such as transmit power, antenna tilt, etc.) to provide the required coverage and capacity and avoid interference.

[0173] Base stations can be implemented with the help of configuration parameters that control various aspects of the cell site. Each of these parameters can then be changed based on observations of both the base station itself and measurements at the mobile station or handheld terminal to change the network behavior. For example, one SON feature establishes an automatic neighbor relationship (ANR), while other SON features optimize random access parameters or mobile robustness in terms of switching oscillations. ANR automatically generates relationships between radio network entities, which may be required for features such as active mode mobility, load balancing, and dual connectivity. One use case for the self-optimization function is to automatically deactivate a certain percentage of cell nodes (e.g., base stations) during off-peak periods (e.g., nighttime operating hours), thereby achieving significant energy savings for service operators. Neighboring base stations can reconfigure their parameters to provide coverage for the entire signal area. In the event of a sudden increase in connection demand, the deactivated base station can be reactivated almost instantly.

[0174] When some nodes in the network become non-functional, self-healing mechanisms can (for example) promote neighboring cells to support users previously supported by the failed node by adjusting parameters and algorithms in neighboring cells, thereby reducing the impact of the failure. In traditional networks, a failed base station may be difficult to identify and may require a lot of time and resources to repair. The self-healing function of SON provides almost immediate identification of a failed base station and the implementation of measures that will ensure that the service to the user is not degraded (or not significantly degraded).

[0175] Self-organizing devices

[0176] Although the SON function improves wireless network performance, for example, the end-to-end performance of the wireless network, it does not provide any mechanism or remedy for device failures including one or more problems specific to the device itself. However, the network itself collects data from different nodes and different layers of the network infrastructure and adjusts its operation based on the observed failures. Although there is no similar process for devices, the devices can be configured to perform pattern matching and adjust their operations based on anomalies identified by a larger device group or a larger device group (ranging from a small device group to a large device group) including a large number of devices. For example, if a certain number of devices encounter problems or experience similar failures, other devices can avoid similar or identical failures by receiving and utilizing information indicating these failures and / or involving these failures. To achieve this purpose, a server can collect data from each device, identify global trends and local anomalies, and establish expert system rules that can be transmitted back to other devices based on these trends and local anomalies. In response to receiving such information, when encountering similar or identical anomalies, the device can recover from the problem or alleviate the problem. In this way, at least some of the principles of SON can be extended to mobile devices, for example, devices associated with a specific user, to allow these devices to operate as self-organizing devices.

[0177] A self-organizing device (SOD) (which may be at least Figures 1 to 3 and Figure 6The device shown in , such as device 106) may include a "symptom" module or recovery control module (RCM) for monitoring events from various different operating domains (e.g., from different software (SW) layers or different layers of the SW stack), and performing an automatic recovery mechanism based on the collected information as needed. SOD can provide monitoring information to a server (e.g., a cloud server), which can use an expert system analysis of information collected from multiple devices (e.g., from globally dispersed devices) and design a mitigation action response strategy corresponding to a specific situation or condition including device-specific considerations. Compared with SON, these situations and / or conditions explain device-specific problems, such as problems that may be specific to certain devices or groups of devices determined by analysis of crowd-source data and / or information. The mitigation action response designed by the expert system (e.g., in the server) can then be provided to the device by the server (e.g., from a cloud container in the server) as an expert system rule in the form of uncompiled code, and the device can use the code as needed to implement the necessary mitigation actions. The RCM of the SOD can compare the monitored situations and / or conditions with previously identified situations and / or conditions, and can determine whether the corresponding mitigation action (e.g., mitigation action corresponding to the identified situation and / or condition) is available. In response to determining that such mitigation action is available and has been identified, the device can perform the mitigation action, thereby improving the operation of the device. Therefore, crowd-source information, such as information collected from decentralized devices (e.g., from globally decentralized devices), can be utilized and used to design mitigation actions customized for specific conditions and / or situations (e.g., conditions specific to certain devices) without the need for global software updates. It should be noted that it is also possible and conceivable that the device itself can use expert system analysis to determine the implementation scheme of the mitigation action related to the device.

[0178] Therefore, in some embodiments, the SOD may support monitoring of faults on a specific device and automatically running recovery mechanisms to resolve device-specific issues. The recovery mechanism may include, but is not limited to, one or more of the following combinations: airplane mode switching, baseband operating mode changes, cell blocking based on certain signatures, changes in WiFi calling policies based on per-device anomalies (WiFi calling policies specify whether the device supports WiFi calling or cellular calling under certain radio conditions), adjustments to system selection preferences and device capability messages (to recover from and / or avoid service interruptions and / or limited services caused at least in part by modem stability issues), reset of certain modules in the SW stack (to recover from anomalies (e.g., data stall issues: reset TCP stack, application and / or baseband driver, change data interface)), and / or installation of one or more software patches (to resolve device-specific issues).

[0179] In some embodiments, SOD can periodically query one or more servers, to access the latest information related to the tracked condition and the corresponding mitigation action stored on the server, for example, it is according to the condition and corresponding mitigation defined by the expert system on the one or more servers. For example, when applicable, SOD can periodically check with one or more servers storing expert system rules (comprising the list of condition and corresponding mitigation action), to retrieve the information corresponding to the expert system rules of update, so as to update the expert system rules on SOD. SOD can thus adapt to the changing conditions in the operating field. In this way, when the public source data changes and / or accumulates, the expert system rules transferred to SOD can automatically and / or dynamically change and update. SOD can therefore operate according to "exploration and utilization" strategy. Some equipment (for example, a certain number or percentage of SOD in a group of deployed SOD) can perform the mitigation (mitigation action) received from the server, and therefore can be considered as "utilization equipment". Some devices (e.g., the remaining SODs in the SOD group deployed by the group) may not perform mitigation actions, but may continue to collect the latest (e.g., current) data points from the operating field, thereby transmitting them to one or more servers to better reflect the current operating conditions. Such SODs may be considered "exploration devices." In some embodiments, the device may operate both as an exploration device and as an utilization device, depending on given circumstances and / or requirements.

[0180] Figure 7

[0181] Figure 7 An exemplary flowchart according to some embodiments is shown, which illustrates device and server interactions for implementing and integrating mitigation actions corresponding to specific conditions and / or situations (including device-specific considerations). The flowchart includes a device component 702 for functions and / or operations performed by the device and a server component 704 for functions and / or operations performed by a server (e.g., a cloud server). The RCM 708 can be an RCM that receives information from different operating domains (e.g., different SW layers) through wireless diagnostic (WD) monitoring 706. Operational domain examples include WiFi, IPSec, baseband, BLUETOOTH TM, mobility, motion sensors, etc. WD information can be provided to RCM 708 (714) via WD event callback. RCM 708 can detect specific event signatures and capture debug logs (716), and can provide event signatures (or information corresponding to given conditions and / or situations, such as domains, types, subtypes, contexts, etc.) to server 704 for use by expert system server 712 (718). WD 706 may also include providing metric logs and push notification keys to server 704 for use by WD server 710 (722). In response to receiving the push notification key, WD server 710 can pull logs (724), automatically detect devices and signatures (726), and push notification keys and signatures to expert system server 712 (728). Based on the information in WD server 710, expert system server 712 can provide expert system rules, where these rules are defined based on signatures (720). The expert system server 712 may send a push notification to the RCM 708, causing the captured logs to be pulled (730), and pull the device-side logs corresponding to the WD-based signature and uploaded by the RCM 708 (732). The WD server 710 may push the new rules and thresholds to the WD 706 within the device 702 (734), which in turn may update the rules for use by the RCM 708 (736). Figure 7 As shown, expert system rules may include two parts, namely, detection of signatures or patterns corresponding to specific situations and / or conditions, and mitigation actions that may be performed in response to detection of specific signatures and / or patterns. RCM 708 may execute and / or enforce expert system rules. Figure 7 As shown, server component 704 facilitates propagation of mitigation and / or action responses to (other) devices. For example, one of the expert system rules may be an enabling action based on a mitigation technique that has been identified. Figure 7 A push notification system is shown, but alternative embodiments may employ a device retrieval system by which a device can retrieve expert system rules from a cloud container (e.g., from a server 712 operating as part of the cloud). Figure 8 The following example of such a system is given in .

[0182] Figure 8

[0183] Figure 8 An exemplary flow diagram illustrating a reverse analysis pipeline for a self-organizing device 802 is shown according to some embodiments. Figure 8 The device 802 is shown transmitting all data points, wireless diagnostic (WD) metrics to the server 804 (814). Within the server 804, the data may be analyzed. Figure 8As shown, server 804 analyzes data using Vertica database software 806, which is an analytical database management software. It should be noted that the column-oriented Vertica analytical platform is designed to manage rapidly increasing amounts of data and provide very fast query performance when used for data warehouses and other query-intensive applications. Software such as Vertica can be used to improve query performance relative to traditional relational database systems and provide high availability and exabyte scalability on commercial enterprise servers. Vertica is independent of infrastructure, thereby supporting deployment on multiple cloud platforms. Its Figure 8 is provided as an example of an efficient data analysis database (software). However, alternative embodiments may use different analysis software.

[0184] The server 804 then performs anomaly detection (808) and identifies recovery strategies and / or actions for the anomaly (e.g., how to recover from the anomaly), and based on the anomaly (830) identified by the server 804, a mitigation technique (832) may be defined via the self-organizing device service 810. The mitigation technique may be implemented and / or converted into CLIPS code (834), which may then be stored in a dedicated server container (e.g., cloud container 812). The dedicated server container 812 may include an anomaly log list and corresponding self-organizing device mitigation actions and / or rules (818). The device 802 may periodically (e.g., daily) query the server 804 to collect applicable new mitigation actions and / or techniques (838), at which point the CLIPS code generated at 834 may be provided to the device 802 (along with others). It should be noted that CLIPS is a public domain software tool for building expert systems. CLIPS stands for "C Language Integrated Production System" and is a widely used expert system tool that incorporates a complete object-oriented language (COOL) for writing expert systems. COOL combines the programming paradigms of procedural languages, object-oriented languages, and logic (theorem proving) languages. Figure 8 CLIPS is shown by way of example as one possible type of code that may be generated and provided to device 802.

[0185] Thus, the next time the device 802 encounters a given situation (e.g., a signature) indicated by the server 804, the device 802 has the ability to perform the corresponding mitigation action that has also been transmitted to the device 802 by the server 804. For example, the device 802 may transmit an event log to the server 804 as part of the WD metric. The event log may include information indicating the operation of the device 802. For example, the device 802 may indicate that it performed a voice call under certain conditions and the call failed, and / or it may indicate that it performed RAT selection under certain conditions and failed, and so on. The server 804 may then process the aggregated data set (816) received from all the different devices, and may design and / or define anomaly recovery strategies (820, 822, 824, 826, 828, 830, 832, 834) based on the received information and / or the aggregated data set. This allows device 802 to leverage (learn from) the operation of other devices with which the device is not in direct communication, and to avoid operational failures and / or impaired operation when encountering conditions that are similar or identical to those conditions reported by other devices as causing some type or kind of operational failure of these other devices. Thus, crowd-sourced data points can be used as the basis for device-specific mitigation actions that can be provided to the device. Server container 812 can retrieve the new mitigation 836 and provide information describing and / or implementing the mitigation (e.g., as uncompiled CLIPS code) to device 802 via reverse analysis pipeline 838 (840).

[0186] Fig. 9

[0187] Fig. 9 A simplified block diagram of an exemplary architecture for a self-organizing device 900 according to some embodiments is shown. Figure 8As shown, for example, one or more devices that transmit information to the server can indirectly assist other devices to mitigate the impact of adverse operating conditions. The uncompiled code for implementing the mitigation mechanism can be pushed to the device by the server or can be taken out by the device. Generally speaking, the principle of SOD can be further summarized as follows. The crowd-source data analysis done by machine intelligence (e.g., expert system software) can be used to identify anomalies. In response to the analysis, a mitigation action can be formed and / or defined, and the mitigation action can be converted into an appropriate mode (e.g., software such as CLIPS) and / or the mitigation action can be implemented using the appropriate mode. SOD can pull reverse analysis configuration (e.g., as uncompiled code when using CLIPS for implementation), and can apply abnormal mitigation without updating its software version and / or compiled code. This concept can be further extended to hot patches, thereby solving device-specific anomalies without transmitting world-wide software changes. As described above, mitigation actions can be converted into suitable software languages ​​or codes (such as CLIPS) and / or implemented using suitable software languages ​​or codes. The device that identifies the designated signature identified by the expert system and has defined mitigation actions for it can apply matching mitigation techniques.

[0188] like Fig. 9 As shown, the device 900 may include means for collecting wireless diagnostic (WD) information 920, which is, for example, a diagnosis related to WiFi operation 928, phone operation 930, cellular modem operation 932, HomeKit operation 934, and / or networking operation 936 (to name just a few examples). Additional or fewer types of diagnostic information may be collected according to the expected specification. In addition to cross-layer monitoring information 918 related to power and / or battery analysis 922 and motion and / or mobility statistics 924, and further in addition to device usage status information 926, RCM 916 may also receive diagnostic information 920. The proposed mitigation action (914) may be performed by calling a specific service provider interface (SPI) corresponding to various different functions and / or modules involved in the mitigation action, and the various different functions and / or modules are, for example, WiFi 904, phone 906, cellular modem (e.g., baseband processor) 908, HomeKit 910, and / or networking 912, etc. In some embodiments, WD information 920 may be collected by an analysis daemon (background process).

[0189] Fig.10

[0190] Fig.10 An exemplary code segment of uncompiled code implementing expert system rules for performing one or more mitigation actions by a self-organizing device according to some embodiments is shown. Fig.10The sample code segment shown is used to mitigate the impact of certain conditions on the operation of the device. As shown in the figure and mentioned previously, the rule may include two sections. The first section (or portion) is a "condition match", which identifies an operating condition or situation for which a mitigation can be sought and ultimately performed. The second section (or portion) is a "mitigation" (action) that can be performed in response to identifying the condition. The action can be obtained from an action catalog or a collection (table) of different mitigation actions available to the device. The action can have a corresponding SPI used by the device to perform the mitigation action, for example, Fig. 9 shown. Fig.10 Two different conditions and corresponding mitigating actions 1002 and 1004 are shown.

[0191] Example 1002 relates to cellular service conditions. For example, if the device is out of service for a period of at least a specified duration, the baseband processor (e.g., a modem) may be restarted. Example 1004 relates to WiFi calling. When a WiFi call is made and the WiFi call fails, one or more mitigation actions may be taken. In response to the cellular signal strength meeting or exceeding a specified threshold (e.g., reaching at least a specified number of signal strength bars displayed on the device screen), the same call may be retried over cellular (e.g., VoLTE or VoNR). Again, an important advantage worth noting is the ability to assign and / or receive mitigation action recommendations and / or rules without requiring any compiled code changes.

[0192] Fig.11

[0193] Fig.11A selected row of an exemplary table 1102 according to some embodiments is shown, which stores operating condition information for designing one or more mitigation actions for dynamic WiFi calling strategies for self-organizing devices. Only a single row is shown for illustrative purposes, but it should be understood that table 1102 may include additional rows, all of which represent data and / or information collected from globally dispersed devices to achieve the purpose of analyzing and / or designing and / or defining corresponding mitigation actions. As previously mentioned, identifying local anomalies or conditions and providing corresponding mitigation actions helps to improve device operation, and these anomalies are not diluted in all anomalies collected globally. A goal can be to identify devices that are adversely affected by specific conditions (which may include device-specific problems) and can benefit from quick solutions to address the adverse effects of these conditions. Thus, as shown in Table 1102, the collected WD information may include call direction, basic service set (BSS) load, adaptive multi-rate (AMR) codec, country of operation, call type, local area network (LAN) status, access point organizational unit identifier (AP OUI), Internet Protocol Security (IPsec) usage, transmission control protocol (TCP) usage, network identifier, call drop rate, and the number of devices experiencing the conditions defined by the previous / corresponding value appearing in the row. As shown in Table 1102, devices operating in a specific country (CID 15) and a specific coverage area (NID 15-2) using IPsec instead of TCP are shown to have historically dropped calls approximately 25% (25.525%) of the time. In other words, under the above conditions, the device has a 25% chance of experiencing a call drop. In today's systems, all policies are typically defined globally at the carrier level. For example, the identified carrier network NID 15-2 may be WiFi-preferred, while other carrier networks may be cellular-preferred. However, in this case, a possible mitigation for the problem would not be to employ a globally defined policy, but rather would include identifying local anomalies for a specific carrier (NID 15-2) and generating expert system rules that would specify how the device operates the next time it encounters these specific conditions. For example, the device could be instructed to prefer a cellular interface (e.g., LTE or NR) over a WiFi interface. It should be noted that IPsec (IP Security) refers to an Internet Engineering Task Force (IETF) standard protocol set that provides data authentication, integrity, and confidentiality between two communication points across an IP network, and also defines encryption packets, decryption packets, and authentication packets. It should also be noted that a BSS refers to a collection of stations that can communicate together within an 802.11 network, and may not include APs that provide connections to fixed distribution systems such as Ethernet.

[0194] Fig.12

[0195] Fig.12 An exemplary block diagram showing the operation of a self-organizing device 1200 according to some embodiments is shown, the operation being based on (for example) Fig.11 The collected information shown implements mitigation actions for dynamic WiFi calling policies. Fig.12 Shown for Fig.11 For the use case shown, various operational domains and / or SW layers that can be used to manage expert system rules can be received from many different operational domains and / or SW layers. Information monitored by RCM 1236 can be received from many different operational domains and / or SW layers, including SIP stack indication 1204 (corresponding to the call direction and country in table 1102, as well as network information), RTP stack indication 1206 (corresponding to the AMR codec information in table 1102), WiFi chip indication 1208 (corresponding to the BSS load information in table 1102), WiFi controller indication 1210 (corresponding to the AP OUI in table 1102), and networking indication 1212 (corresponding to the IPsec usage and TCP usage information in table 1102). Therefore, SIP stack indication 1204 provides information indicating the call direction, country, and network (1214), which in this example is MT (for mobile station called) and NID 15-2 (1224). RTP stack indication 1206 provides information indicating the AMR codec (1216), which has a value of 2 (1226) in this example. The WiFi chip indication 1208 provides information indicating the BSS payload (1218), which in this example has a value of 0 (1228). The WiFi controller indication 1210 provides information indicating the AP OUI (1220), which in this example is APID 23 (1230). The networking indication 1212 provides information indicating the use of IPsec for TCP and UDP (1222), which in this example is UDP IPsec (1232). In general, there are five different operational domains, such as Fig.12 The different layers of the SW or SW stack are shown. Fig.12 In the example shown, mitigation includes changing the WiFi policy to prefer cellular (1238) when the conditions of the identified device are matched (1234). The RCM 1236 may indicate this to the RAT manager 1240.

[0196] Fig.13

[0197] Fig.13Selected rows of an exemplary table storing operating condition (e.g., wireless diagnostic) information for defining one or more mitigation actions for radio access technology and carrier aggregation-based modem stability are shown in accordance with some embodiments. Three rows are shown for illustrative purposes, but it should be understood that table 1302 may include additional rows, all of which represent data and / or information collected from dispersed devices (e.g., from globally dispersed devices) for the purpose of analyzing and / or designing and / or defining corresponding mitigation actions. Fig.13 As shown, the table stores information indicating the number of modem failures that occurred for each device during each specific duration period (e.g., each week). In addition, because the data in the table represents global data, it provides an indication of how many modem failures occur worldwide. In today's systems, even with the help of SON, it may take up to a month for a device to receive a SW update to resolve modem failure issues and achieve modem stability. This may lead to an undesirable negative user experience during this waiting period. To mitigate this problem, mitigations can be designed based on the collected data as crowd-source data analysis is performed. Therefore, as shown in table 1302, the collected WD information may include the device model, the baseband (or modem) version of the device, the country of operation, the network identifier, the roaming indication, the cause of the modem and / or baseband failure, the location latitude, the location longitude, the bandwidth CA combination, and the number of failures experienced by the device within a specified duration under the conditions defined by the previous values ​​appearing in each corresponding row. As shown Fig.13 As shown in the use case in Figure 1, a specific device model (M10) experienced a modem failure in a specific location (specific latitude indicated by LaNUM and specific longitude indicated by LoNUM) on a specific network (NID 13-5). As shown in the table, the failure occurred at a specific location (latitude LaNUM and longitude LoNUM) on the same network (NID13-5) while operating at a specific bandwidth and / or CA combination (10MHz+10MHz). Based on this information, expert system designed and / or defined mitigation actions can be provided to the device. Therefore, when the device encounters a modem failure such as Fig.13 , it can indicate to the network that it does not support a particular CA bandwidth combination for which modem failures have been historically documented when those conditions are defined by the values ​​shown in the corresponding rows in . More generally, a device can indicate that it does not support a particular feature known to be associated with high modem (baseband) failures based on crowd-sourced data collected for a particular device model.

[0198] Fig.14

[0199] Fig.14 An exemplary block diagram showing the operation of a self-organizing device 1400 is shown, the operation being based on Fig.13The collected information shown is used to implement one or more mitigation actions for radio access technology and carrier aggregation-based modem stability. Fig.14 Shown for Fig.13 The various operational domains and / or SW layers involved in managing expert system rules for the use case shown. Information monitored by the RCM 1430 may be received from many different operational domains and / or SW layers, including a cellular modem indication 1404 (corresponding to the baseband version and bandwidth CA combination information in table 1302), a system setting indication 1406 (corresponding to the model information in table 1302), a core location indication 1408 (corresponding to the country, latitude and longitude information in table 1302), and a phone indication 1410 (corresponding to the roaming information and network information in table 1302). The cellular modem indication 1404 thus provides information indicating the CA combination and baseband version (1412), which in this example is 10MHz+10MHz and the baseband version is BB 10 (1420). The system setting indication 1406 provides information indicating the device model (1414), which in this example is M10 (1422). The core location indication 1408 provides information indicating the country geographic location (1416), which in this example is country code CID 13 (1424) with latitude LaNUM and longitude LoNUM. The phone indication 1410 provides information indicating the RAT roaming and network (1418), which in this example is LTE non-roaming (1426) on provider ID NID 13-5. In general, there are four different operating domains, such as, Fig.14 The different layers of the SW and / or SW stack are shown. Fig.14 In the example shown, mitigation includes adjusting device capabilities to avoid problematic carrier aggregation bandwidth combinations for that particular geographic location (1436) when a condition match for the device is identified (1428). The RCM 1430 can indicate this to the core telephony module 1432, which can control the baseband 1434 accordingly. In general, the UE 1400 can communicate cellularly with and via the base station 1440.

[0200] Fig.15

[0201] Fig.15A selected row of an exemplary table according to some embodiments is shown, which stores operating condition information for designing one or more mitigation actions for cell blocking based on abnormal signatures. Two rows are shown for illustrative purposes, but it should be understood that table 1502 may include additional rows, all of which represent data and / or information collected from decentralized devices (e.g., from globally decentralized devices) to achieve the purpose of analyzing and / or designing and / or defining corresponding mitigation actions. As shown in table 1502, the collected WD information may include the cell ID or global cell ID of a specific service provider, the device model, the wireless technology used, the call establishment direction (mobile station called and mobile station initiated), the frequency band used, the total number of attempted calls, and the percentage of attempted calls that failed to be established by the device under the conditions defined by the values ​​appearing in the corresponding rows. The data in table 1502 show that certain specific device models (M10 and M 08) operating according to specific technologies (WCDMA) in specific corresponding frequency bands (WCDMA_2000 and WCDMA_900, respectively) experience abnormally high call failure rates. In other words, the data for each respective row relates to an identified condition and / or anomaly indicating that a particular device model (indicated in that row) operating according to a particular cellular technology in an area served by a particular cell (having a particular cell ID) failed to receive nearly 100% of (mobile called voice) calls placed to that device. For example, when device model M10 was operating on cell CPCID 45 using WCDMA technology on frequency band WCDMA_2000, the device failed to receive 99.8% of calls placed to that device. Assuming that the condition indicated in that row corresponds to device M 08, then a similar situation applies to device model M 08.

[0202] Fig.16

[0203] Fig.16 An exemplary block diagram showing the operation of a self-organizing device 1600 is shown, the operation being based on Fig.15 The collected information shown is used to implement mitigation actions for cell barring based on abnormal signatures. Fig.16 Shown for Fig.151502 ), system settings indication 1606 (corresponding to the device model information in table 1502), and phone indication 1608 (corresponding to the call establishment and radio technology information in table 1502). The cellular modem indication 1604 thus provides information indicating the frequency band and global cell identification (1612), which in this example is the WCDMA_2000 band (1620) on the identified cell CPCID 45 of the specific provider. The system settings indication 1606 provides information indicating the device model (1614), which in this example is M10 (1622). Telephone indication 1608 provides information indicating the calling location (1616) and the radio technology (1618), which in this example are the mobile station being called (1624) and WCDMA (1626), respectively. Generally speaking, there are four different operating domains, for example, Fig.16 The different layers of the SW or SW stack shown. Fig.16 Mitigation actions 1636 are shown, instead of considering only link conditions for making cell selection decisions, mitigation based on crowdsourced data (matching condition 1628) may result in improved operation of a particular device. Fig.15 and Fig.16 In the case shown, the cell measurements may provide an indication that cell 1640 is favorable. However, for some reasons, other factors may cause the above-mentioned call failure for a particular device operating according to a particular cellular technology in the coverage area of ​​cell 1640, such as Fig.15 Thus, the device may utilize this crowd-sourced data information to reselect to a different cell 1642, even though cell 1640 (which may even be the current serving cell) may be considered the best candidate cell to serve the device based on all other considerations. Fig.15 When the corresponding row of the crowd-sourced data in table 1502 of FIG. 1504 illustrates a specific condition, the device can block cell 1640 regardless of the RF conditions corresponding to cell 1640. RCM 1630 can indicate the mitigation action to core telephony module 1632, which can control baseband 1634 accordingly.

[0204] It should be noted that the various values ​​of the WD information shown in tables 1102 , 1302 , and 1502 are to be interpreted as exemplary substitute values ​​provided for the purpose of illustration.

[0205] Crowd-sourced mitigations and hotfixes

[0206] For further improvement, the results of the attempted mitigation and / or mitigation actions can be classified. Different mitigation actions can be evaluated to determine whether mitigation helps recovery. In some embodiments, different mitigation actions can be provided for the equipment of each subgroup of the equipment of multiple subgroups, and these different mitigation actions correspond to the same conditions and / or situations defined by the collected crowd-source data. The corresponding results of the equipment from each subgroup of the mitigation action can be analyzed to determine which mitigation actions in many different mitigation / mitigation actions are most successful in solving or alleviating the problem of a given condition and / or situation. The most successful mitigation can then be deployed to the affected equipment. For example, the most successful mitigation can be deployed globally. For example, when determining and / or identifying mitigation techniques (e.g., global mitigation techniques and / or actions) from a variety of mitigation techniques and / or actions, this approach can be helpful.

[0207] For example, a predefined set of possible mitigation / mitigation actions may be defined for (or may be defined to correspond to) each anomaly domain (e.g., each condition and / or situation identified from crowd-sourced data). Based on the anomaly domain, all possible mitigations and / or mitigation actions may be deployed to the devices of the corresponding randomly selected subgroups. For example, a first mitigation (action) may be deployed to a first group of devices, a second mitigation (action) may be deployed to a second group of devices, a third mitigation (action) may be deployed to a third group of devices, and so on. Devices of different groups may be mutually exclusive, as defined by which mitigation (action) is deployed to which device. The impact of each mitigation (action) may be classified as "helpful for recovery" and "not helpful for recovery." Based on the crowd-sourced performance of each mitigation technique according to the device, a successful mitigation method may be pushed and / or deployed to all devices that have been identified as having experienced a target anomaly.

[0208] Thus, where multiple mitigation actions are possible, the server may provide various mitigation (action) options corresponding to the same situation and / or condition (e.g., corresponding to the same anomaly) to different devices or different groups of devices, thereby establishing a feedback loop in which each device applies different mitigations and / or mitigation actions corresponding to the same condition and / or anomaly, and transmits information indicating the corresponding results of the mitigation and / or mitigation action (e.g., success and failure) back to the server. Based on the feedback loop, the best one or more mitigation actions corresponding to a given condition and / or anomaly may be established and identified as preferred mitigation and / or mitigation actions that are universally (e.g., globally) applied by devices when encountering the corresponding condition and / or anomaly.

[0209] In some embodiments, hot patching can be used to enable operating system (OS) updates without requiring a device reboot. Hot patching can enable a server (e.g., a cloud server) to push critical software fixes to target devices that have been severely affected by a software bug without having to release remote radio unit fixes for all devices running a given OS. Hot patching can use dynamic software update (DSU) technology, which allows a device to modify the currently running binary code and at the same time ensure that the correct operation of the system is maintained after the patch is applied. For example, examples of hot patching technologies that can be used to provide mitigation and / or mitigation actions include, but are not limited to:

[0210] · replacing the current function implementation with the new function implementation made via binary code; and

[0211] Once the new binary is ready to be used, the new daemon code is loaded and control is transferred from the old binary to the new one. This technique may require the daemon implementation to adopt the new framework to enable hot patching.

[0212] Privacy and Data Collected

[0213] As above Said One aspect of the present technology is the collection and use of data available from specific and legitimate sources to improve the operation of a mobile device (often a mobile device that is different from the mobile device from which the data may have been collected). The present disclosure contemplates that in some instances, the collected data may include personal information data that uniquely identifies or can be used to identify a specific person. Such personal information data may include demographic data, location-based data, online identifiers, phone numbers, email addresses, home addresses, data or records related to a user's health or fitness level (e.g., vital sign measurements, medication information, and exercise information), date of birth, or any other personal information.

[0214] The present disclosure recognizes that the use of such personal information data in the present technology can be used to benefit users. For example, the personal information data can be used by multiple user devices to monitor failures and run automatic operation recovery mechanisms to solve user-specific problems. Therefore, the use of such personal information data enables users to improve the operation of their devices.

[0215] The present disclosure envisions that entities responsible for collecting, analyzing, disclosing, transmitting, storing or otherwise using such personal information data will comply with established privacy policies and / or privacy practices. Specifically, such entities will be expected to implement and consistently apply privacy practices that are generally recognized as meeting or exceeding the requirements of the industry or government that maintain user privacy. Such information about the use of personal data should be highlighted and easily accessible to users, and should be updated as the collection and / or use of data changes. The user's personal information should be collected only for legitimate use. In addition, such collection and / or sharing should only occur after receiving user consent or other legal basis specified in applicable law. In addition, such entities should consider taking any necessary steps to defend and safeguard access to such personal information data and ensure that others who have access to personal information data comply with their privacy policies and processes. In addition, such entities may subject themselves to third-party assessments to demonstrate that they comply with widely accepted privacy policies and practices. In addition, policies and practices should be adjusted for specific types of personal information data collected and / or accessed, and applied to applicable laws and standards, including considerations that are exclusive to jurisdictions that can be used to impose higher standards. For example, in the United States, collection of or access to certain health data may be governed by federal and / or state law, such as the Health Insurance Portability and Accountability Act (HIPAA); while health data in other countries may be subject to other regulations and policies and should be handled accordingly.

[0216] Regardless of the foregoing, the present disclosure also contemplates implementation schemes that provide users with the ability to selectively block the use or access of personal information data. That is, the present disclosure contemplates that hardware elements and / or software elements may be provided to prevent or block access to such personal information data in situations where the user does not wish to share such personal information data. For example, the present technology may be configured to allow users to “opt in” or “opt out” of participating in the collection of personal information data at any time during or after registration for a service. In addition to providing “opt in” and “opt out” options, the present disclosure contemplates providing notifications related to access or use of personal information. For example, a user may be notified that their personal information data will be accessed when downloading an application, and then reminded again just before the personal information data is accessed by the application.

[0217] In addition, it is an object of the present disclosure that personal information data should be managed and processed to minimize the risk of unintentional or unauthorized access or use. Risks can be minimized by limiting data collection and deleting data once it is no longer needed. In addition, and when applicable, including in certain health-related applications, data de-identification can be used to protect the privacy of users. De-identification can be facilitated by removing identifiers, controlling the amount or specificity of stored data (e.g., collecting location data at a city level rather than at an address level), controlling how data is stored (e.g., aggregating data across users), and / or other methods such as differential privacy, when appropriate.

[0218] Thus, while the present disclosure broadly covers the use of personal information data to implement one or more of the various disclosed embodiments, the present disclosure also contemplates that various embodiments may also be implemented without access to such personal information data. That is, various embodiments of the present technology will not fail to function properly due to the lack of all or a portion of such personal information data. For example, information may be delivered to a user based on aggregated non-personal information data or an absolute minimum amount of personal information, such as content processed only on the user's device or other non-personal information that may be used for content delivery services.

[0219] Embodiments of the present invention may be implemented in any of a variety of forms. For example, in some embodiments, the present invention may be implemented as a computer-implemented method, a computer-readable storage medium, or a computer system. In other embodiments, one or more custom-designed hardware devices such as ASICs may be used to implement the present invention. In other embodiments, one or more programmable hardware elements such as FPGAs may be used to implement the present invention.

[0220] In some embodiments, a non-transitory computer-readable storage medium (e.g., a non-transitory storage element) may be configured to store program instructions and / or data, wherein if the program instructions are executed by a computer system, the computer system is caused to perform a method, such as any of the method embodiments described herein, or any combination of the method embodiments described herein, or any subset of any method embodiments described herein, or any combination of such subsets.

[0221] In some embodiments, a device (e.g., a UE) may be configured to include a processor (or a group of processors) and a memory medium (or a memory element), wherein the memory medium stores program instructions, wherein the processor is configured to read and execute the program instructions from the memory medium, wherein the program instructions are executable to implement any of the various method implementations described herein (or any combination of the method implementations described herein, or any subset of any method implementations described herein or any combination of such subsets). The device can be implemented in any of various forms.

[0222] By interpreting each message and / or signal X received by a user equipment (UE) and / or device in the downlink as a message and / or signal X transmitted by the base station, and interpreting each message and / or signal Y transmitted by the UE and / or device in the uplink as a message and / or signal Y received by the base station, any of the methods for operating a UE and / or device described herein may become the basis for the corresponding method for operating a base station.

[0223] Although the above embodiments have been described in considerable detail, numerous variations and modifications will become apparent to those skilled in the art once the above disclosure is fully appreciated. It is intended that the following claims be interpreted to encompass all such variations and modifications.

Claims

1. An electronic device, comprising: A processor configured to cause the device to: monitoring first wireless diagnostic information from a plurality of different software layers corresponding to different operating domains associated with wireless communications of the device; identifying an operating condition of the wireless communication of the device currently being experienced by the device based on the monitored diagnostic information; as well as In response to identifying the operating condition, the mitigation action is performed by calling a specific service provider interface SPI involved in the mitigation action, wherein the specific SPI is included in a plurality of SPIs corresponding to the different operating domains, and wherein the mitigation action mitigates an adverse effect of the operating condition on the wireless communication of the device.

2. The electronic device of claim 1, wherein the processor is configured to further cause the device to: receiving code for implementing the mitigation action; and The mitigation action is performed according to the received code.

3. The electronic device according to claim 2, wherein: The code includes one of the following: The code is not compiled; or A binary code, wherein the binary code can be used to hot-patch the operating system of the device.

4. The electronic device according to claim 1, wherein: The plurality of different software layers comprises different layers of a software stack.

5. The electronic device according to claim 1, wherein: The mitigation action is defined to correspond to the operating condition based on analysis of crowd-sourced wireless diagnostic information from a plurality of devices.

6. The electronic device according to claim 5, wherein: The crowd-sourced wireless diagnostic information includes one or more items of device-specific information corresponding to respective devices of the plurality of devices.

7. The electronic device according to claim 5, wherein: The mitigation action is one mitigation action of a plurality of different mitigation actions that all correspond to the operating condition.

8. The electronic device according to claim 7, wherein: The mitigation action is selected from the plurality of different mitigation actions based on a respective result of performing each of the plurality of mitigation actions.

9. An electronic device, comprising: a radio circuit configured to facilitate wireless communications of the electronic device; and a processor communicatively coupled to the radio circuitry and configured to cause the electronic device to: monitoring first wireless diagnostic information from a plurality of different software layers corresponding to different operating domains associated with wireless communications of the electronic device; identifying an operating condition of the wireless communication of the electronic device currently being experienced by the electronic device based on the monitored diagnostic information; as well as In response to identifying the operating condition, the mitigation action is performed by calling a specific service provider interface SPI involved in the mitigation action, wherein the specific SPI is included in a plurality of SPIs corresponding to the different operating domains, and wherein the mitigation action mitigates the adverse effects of the operating condition on the wireless communication of the electronic device.

10. The electronic device according to claim 9, wherein: The processor is configured to further cause the electronic device to: receiving code for implementing the mitigation action; and The mitigation action is performed according to the received code.

11. The electronic device according to claim 10, wherein: The code includes one of the following: The code is not compiled; or The binary code can be used to hot-patch the operating system of the electronic device.

12. The electronic device according to claim 9, wherein: The plurality of different software layers comprises different layers of a software stack.

13. The electronic device according to claim 9, wherein: The mitigation action is defined to correspond to the operating condition based on analysis of crowd-sourced wireless diagnostic information from a plurality of devices.

14. The electronic device according to claim 13, wherein: The crowd-sourced wireless diagnostic information includes one or more items of device-specific information corresponding to respective devices of the plurality of devices.

15. The electronic device according to claim 12, wherein: The mitigation action is one mitigation action of a plurality of different mitigation actions that all correspond to the operating condition.

16. The electronic device according to claim 15, wherein: The mitigation action is selected from the plurality of different mitigation actions based on a respective result of performing each of the plurality of mitigation actions.

17. A non-transitory memory element storing instructions executable by a processor to cause a central control device to: analyzing crowd-sourced wireless diagnostic information received from a plurality of devices, wherein the wireless diagnostic information is from a plurality of different software layers corresponding to different operating domains associated with wireless communications of the plurality of devices; identifying an operating condition based on said analysis of said crowd-sourced wireless diagnostic information; defining mitigation actions corresponding to the operating conditions; as well as Information representing the mitigation action is transmitted to the device, wherein the information can be used by the device to perform the mitigation action by invoking a service provider interface SPI corresponding to the different operating domain when the device experiences the operating condition to mitigate the adverse effects of the operating condition.

18. The non-transitory memory element according to claim 17, wherein: The instructions are executable to further cause the centralized control device to: defining a plurality of mitigation actions corresponding to the operating condition, wherein the mitigation action is included in the plurality of mitigation actions; and For each different mitigation action among the multiple mitigation actions, corresponding information representing the different mitigation actions among the multiple mitigation actions is transmitted to devices of different corresponding groups, wherein the corresponding information can be used by each device in the devices of the corresponding receiving group to perform the mitigation action represented by the information when the device in the devices of the corresponding receiving group experiences the operating condition, so as to mitigate the adverse effects of the operating condition.

19. The non-transitory memory element according to claim 18, wherein: The instructions are executable to further cause the centralized control device to: receiving a respective result corresponding to each different mitigation action that has been performed; analyzing the corresponding results; and Based on the analysis of the corresponding results, a mitigation action is selected from the plurality of mitigation actions as a preferred mitigation action.

20. The non-transitory memory element according to claim 19, wherein: The instructions are executable to further cause the centralized control device to: Information indicative of the preferred mitigation action is transmitted to a subset of the plurality of devices, the subset including devices that have been affected by the operating condition.

21. A method performed by a device, comprising: monitoring first wireless diagnostic information from a plurality of different software layers, the plurality of different software layers corresponding to respective information for different operational domains associated with wireless communications of the device; identifying an operating condition of the wireless communication of the device currently being experienced by the device based on the monitored diagnostic information; as well as In response to identifying the operating condition, the mitigation action is performed by calling a specific service provider interface SPI involved in the mitigation action, wherein the specific SPI is included in a plurality of SPIs corresponding to the different operating domains, and wherein the mitigation action mitigates an adverse effect of the operating condition on the wireless communication of the device.

22. The method according to claim 21, further comprising: receiving a code for implementing the mitigation action; as well as The mitigation action is performed according to the received code.

23. The method according to claim 22, wherein: The code includes one of the following: The code is not compiled; or A binary code, wherein the binary code can be used to hot-patch the operating system of the device.

24. The method according to claim 21, wherein: The plurality of different software layers comprises different layers of a software stack.

25. The method according to claim 21, wherein: The mitigation action is defined to correspond to the operating condition based on analysis of crowd-sourced wireless diagnostic information from a plurality of devices.

26. The method according to claim 25, wherein: The crowd-sourced wireless diagnostic information includes one or more items of device-specific information corresponding to respective devices of the plurality of devices.

27. The method according to claim 25, wherein: The mitigation action is one mitigation action of a plurality of different mitigation actions that all correspond to the operating condition.

28. The method according to claim 27, wherein: The mitigation action is selected from the plurality of different mitigation actions based on a respective result of performing each of the plurality of mitigation actions.

29. A non-transitory memory element storing instructions executable by a processor to cause a device to: monitoring first wireless diagnostic information from a plurality of different software layers corresponding to respective information of different operating domains associated with wireless communications of the device; identifying an operating condition of the wireless communication of the device currently being experienced by the device based on the monitored diagnostic information; as well as In response to identifying the operating condition, the mitigation action is performed by calling a specific service provider interface SPI involved in the mitigation action, wherein the specific SPI is included in a plurality of SPIs corresponding to the different operating domains, and wherein the mitigation action mitigates an adverse effect of the operating condition on the wireless communication of the device.

30. The non-transitory memory element according to claim 29, wherein: The instructions are executable to further cause the device to: receiving code for implementing the mitigation action; and The mitigation action is performed according to the received code.

31. The non-transitory memory element according to claim 30, wherein: The code includes one of the following: The code is not compiled; or A binary code, wherein the binary code can be used to hot-patch the operating system of the device.

32. The non-transitory memory element according to claim 29, wherein: The plurality of different software layers comprises different layers of a software stack.

33. The non-transitory memory element according to claim 29, wherein: The mitigation action is defined to correspond to the operating condition based on analysis of crowd-sourced wireless diagnostic information from a plurality of devices.

34. The non-transitory memory element according to claim 33, wherein: The crowd-sourced wireless diagnostic information includes one or more items of device-specific information corresponding to respective devices of the plurality of devices.

35. The non-transitory memory element according to claim 33, wherein: The mitigation action is one mitigation action of a plurality of different mitigation actions that all correspond to the operating condition.

36. The non-transitory memory element according to claim 35, wherein: The mitigation action is selected from the plurality of different mitigation actions based on a respective result of performing each of the plurality of mitigation actions.

37. A method performed by a centralized control device, comprising: analyzing crowd-sourced wireless diagnostic information received from a plurality of devices, wherein the wireless diagnostic information is from a plurality of different software layers corresponding to different operating domains associated with wireless communications of the plurality of devices; identifying an operating condition based on said analysis of said crowd-sourced wireless diagnostic information; defining mitigation actions corresponding to the operating conditions; as well as Information representing the mitigation action is transmitted to the device, wherein the information can be used by the device to perform the mitigation action by invoking a service provider interface SPI corresponding to the different operating domain when the device experiences the operating condition to mitigate the adverse effects of the operating condition.

38. The method of claim 37, further comprising: defining a plurality of mitigation actions corresponding to the operating condition, wherein the mitigation action is included in the plurality of mitigation actions; and For each different mitigation action among the multiple mitigation actions, corresponding information representing the different mitigation actions among the multiple mitigation actions is transmitted to devices of different corresponding groups, wherein the corresponding information can be used by each device in the devices of the corresponding receiving group to perform the mitigation action represented by the information when the device in the devices of the corresponding receiving group experiences the operating condition, so as to mitigate the adverse effects of the operating condition.

39. The method of claim 38, further comprising: receiving a respective result corresponding to each different mitigation action that has been performed; analyzing the corresponding results; as well as Based on the analysis of the corresponding results, a mitigation action is selected from the plurality of mitigation actions as a preferred mitigation action.

40. The method of claim 39, further comprising: Information indicative of the preferred mitigation action is transmitted to a subset of the plurality of devices, the subset including devices that have been affected by the operating condition.

41. A centralized control device, comprising: A processor, wherein the processor is configured to enable the centralized control device to: analyzing crowd-sourced wireless diagnostic information received from a plurality of devices, wherein the wireless diagnostic information is from a plurality of different software layers corresponding to different operating domains associated with wireless communications of the plurality of devices; identifying an operating condition based on said analysis of said crowd-sourced wireless diagnostic information; defining mitigation actions corresponding to the operating conditions; as well as Information representing the mitigation action is transmitted to the device, wherein the information can be used by the device to perform the mitigation action by invoking a service provider interface SPI corresponding to the different operating domain when the device experiences the operating condition to mitigate the adverse effects of the operating condition.

42. The centralized control device according to claim 41, wherein the processor is configured to further cause the centralized control device to: A plurality of mitigation actions corresponding to the operating condition are defined, wherein: The mitigation action is included in the plurality of mitigation actions; as well as For each different mitigation action among the multiple mitigation actions, corresponding information representing the different mitigation actions among the multiple mitigation actions is transmitted to devices of different corresponding groups, wherein the corresponding information can be used by each device in the devices of the corresponding receiving group to perform the mitigation action represented by the information when the device in the devices of the corresponding receiving group experiences the operating condition, so as to mitigate the adverse effects of the operating condition.

43. The centralized control device according to claim 42, wherein the processor is configured to further cause the centralized control device to: receiving a respective result corresponding to each different mitigation action that has been performed; analyzing the corresponding results; and Based on the analysis of the corresponding results, a mitigation action is selected from the plurality of mitigation actions as a preferred mitigation action.

44. The centralized control device according to claim 43, wherein the processor is configured to further cause the centralized control device to: Information indicative of the preferred mitigation action is transmitted to a subset of the plurality of devices, the subset including devices that have been affected by the operating condition.

Images