Systems and methods for AI/machine learning-based blockchain validation and remediation

A system described herein may utilize artificial intelligence/machine learning (“AI/ML”) or other suitable techniques to automatically identify blocks added to or proposed to be added to a blockchain, with conflicting and/or otherwise incompatible information, and to automatically remediate the blockchain based on the identified conflict and/or incompatibility. The model may associate different types of conflicts and/or incompatibilities with different types of remedial measures. The remedial measures may include the rejection of a proposed block, recording a new block that takes precedence or priority over a previously recorded block, or other suitable remedial measures.

BACKGROUND

Blockchains provide a secure, decentralized, immutable mechanism by which information may be recorded by and accessible to authorized entities, such as nodes or other devices or systems that have access to such blockchains. Some blockchains may offer the opportunity for multiple different entities, organizations, individual users, etc. to record information to the blockchains.

DETAILED DESCRIPTION OF EXAMPLE EMBODIMENTS

Some blockchains may offer the opportunity for multiple different entities, organizations, individual users, etc. to record information to the blockchains. In some scenarios, different values for the same attributes, parameters, etc. may be provided, which may result in a mismatch or other type of incompatibility. In such scenarios, an entity that accesses the blockchain may receive or identify incorrect or ambiguous information for a given attribute, parameter, etc. For example, two different entities may record different values for a particular block recorded to a given blockchain, such as different telematics information for the same autonomous vehicle over the same time period, different values for sensor readings associated with the same set of Internet of Things (“IoT”) devices in the same location, different prices for the same transaction, different statuses for a particular transaction (e.g., “in process,” “shipped,” “returned,” etc.), and/or other types of mismatching or otherwise incompatible values for the same information.

Embodiments described herein provide for a system that utilizes artificial intelligence/machine learning (“AI/ML”) or other suitable techniques to automatically identify blocks with conflicting and/or otherwise incompatible information (e.g., blocks that have been recorded to a blockchain and/or blocks that are proposed to be recorded to the blockchain), and to automatically remediate the blockchain based on the identified conflict and/or incompatibility. As discussed herein, different types of conflicts and/or incompatibilities may be associated with different types of remedial measures. For example, some types of conflicts and/or incompatibilities may be associated with a determination that information in a block received from a first entity is valid as compared to information in a block received from a second entity. On the other hand, other types of conflicts and/or incompatibilities may be associated with a determination that information in a block received from the second entity is valid as compared to information in a block received from the first entity. The remedial measures may include the rejection of a proposed block (e.g., which includes conflicting and/or incompatible information) prior to recording the proposed block to the blockchain, recording a new block that takes precedence or priority over a previously recorded block, or other suitable remedial measures. As the particular types of remedial measures based on different types of conflicts and/or incompatibilities may be determined using AI/ML techniques, manual intervention may not be needed to remediate such conflicts and/or incompatibilities. Further, the information stored within the blockchain may be made more reliable based on the remedial measures identified and performed in accordance with some embodiments.

As shown inFIG.1A, for example, blockchain100may include an example set of blocks101-A through101-E. Block101-F may be a block that is proposed to be added to blockchain100, such as upon validation, verification, approval, etc. by one or more nodes or other entities associated with blockchain100that add blocks to blockchain100and/or validate the addition of such blocks to blockchain100.

In the examples described herein, each block101is described as including a “key” and a set of “values.” In some situations, the key for a given block101may be or may include a subset of values of the block. Generally, the same key used in multiple different blocks101may indicate that these different blocks101pertain to the same item(s), object(s), set(s) of data, etc. Thus, while a key may include one or more values, “keys” and “values” are described separately herein, as mismatches and/or incompatibilities may be detected for blocks having the same key and one or more different values.

FIGS.1B and1Cillustrate examples of keys and/or values associated with example blocks101-C and101-F (e.g., blocks associated with the same key). As shown inFIG.1B, for example, blocks101-C and101-F may each be associated with a set of values for a set of parameters. The parameters in this example are “Block source,” “Vehicle ID,” “Vehicle make,” “Vehicle model,” “Timestamp,” “Avg. [average] speed,” “Avg. acceleration,” and “Collision events.” The “Block source” parameter may refer to a device, system, entity, etc. from which a given block was received (and/or from which the information recorded in the block was received). For example, inFIG.1B, blocks101-C and101-F may include vehicle telematics information, and block101-C may have been received from a system of the vehicle while block101-F may have been received from a mobile phone associated with (e.g., located in, affixed to, etc.) the vehicle. The key for blocks101-C and101-F may be the values for the “Vehicle ID,” “Vehicle make,” “Vehicle model,” and “Timestamp” attributes. In some embodiments, different keys (e.g., different attributes or combinations of attributes) may be identified via AI/ML techniques or other suitable techniques. Keys may also be or may include a hash (or other type of derived or computed value) of some or all of the values.

As further shown, the “Avg. speed” and “Avg. acceleration” parameters may be associated with mismatching values. For example, block101-C may indicate a value of “127 Km/h” for “Avg. speed” while block101-F may indicate a value of “125 Km/h” for “Avg. speed.” Further, block101-C may indicate a value of “0.1 G” for “Avg. acceleration” while block101-F may indicate a value of “0.07 G” for “Avg. acceleration.” In other words, a vehicle system and mobile phone, reporting vehicle telematics information for the same vehicle at the same time (or over the same time period), may provide mismatching and/or conflicting information.

In the example shown inFIG.1C, blocks101-C and101-F may include information regarding a particular User Equipment (“UE”), such as a mobile phone, an IoT device, a mobile hotspot, etc. Blocks101-C and101-F may further include a “UE ID [identifier]” parameter, which may include an International Mobile Subscriber Identity (“IMSI”), International Mobile Station Equipment Identity (“IMEI”), Internet Protocol (“IP”) address, Media Access Control (“MAC”) address, Subscription Permanent Identifier (“SUPI”), Globally Unique Temporary Identifier (“GUTI”), and/or other suitable identifier. In this example, the “UE ID” parameter may be the key based on which blocks101-C and101-F may be identified as pertaining to the same object, item, etc. (e.g., the particular UE having the UE ID “UE_9876” in this example).

As further shown, blocks101-C and101-F may include different sets of parameters and values which may be incompatible. For example, block101-F, associated with a wireless provider that may provide wireless service to the UE, includes a set of network parameters or policies, which may include provisioning information, a set of Quality of Service (“QoS”) policies, information indicating a particular wireless plan, etc. On the other hand, block101-C may include information indicating that this phone has been returned (e.g., “Order status: Returned”). These values may be incompatible, as block101-F may indicate that a wireless provider has allocated and/or is otherwise consuming resources for the mobile phone, while block101-C may indicate that a manufacturer has received the phone back as a return. Thus, an incompatibility may be detected based on values for different parameters that may logically be impossible or otherwise incompatible, even if the values are not a direct mismatch of the same parameter.

Returning toFIG.1A, Blockchain Reconciliation Node (“BRN”)103may identify (at102) that block101-F is proposed to be added to blockchain100. For example, BRN103may be, may implement, or may be communicatively coupled to a node associated with blockchain100. In some embodiments, BRN103may include an event listener, block explorer, or may implement some other type of technique by which BRN103identifies or receives notifications of new blocks added to blockchain100(or proposed to be added to blockchain100).

BRN103may, in some embodiments, validate blocks (e.g., “proposed” blocks) prior to addition of the such blocks to blockchain100, and/or may evaluate or otherwise perform operations described herein on blocks that have been added to blockchain100. For example, in some embodiments, BRN103may identify (at104) mismatches, conflicts, incompatibilities, and/or other types of inconsistencies between information included in different blocks and may determine and/or perform (at106) one or more remedial measures to reconcile and/or otherwise remediate such mismatches, conflicts, incompatibilities, inconsistencies, etc. As discussed herein, BRN103may generate, modify, and/or otherwise maintain one or more models (e.g., AI/ML models or other suitable types of models) that associate particular types of identified mismatches, conflicts, incompatibilities, inconsistencies, etc. (hereinafter referred to simply as “mismatches”) identified in different blocks to particular remedial measures to take with respect to such mismatches. In some embodiments, the AI/ML models may further specify keys based on which blocks may be compared and mismatches identified, and/or BRN103may determine keys in some other manner (e.g., keys may be indicated in blocks themselves, BRN103may receive or maintain configuration information specifying keys, etc.).

In the example ofFIG.1A, blocks101-A,101-C, and101-F may be associated with the same key (“Key_A”). As noted above, a key may include one or more particular values for one or more parameters specified by information within respective blocks101. Referring to the example ofFIG.1B, Key_A (e.g., as present in blocks101-A,101-C, and101-F) may include the same (e.g., matching) values for “Vehicle ID,” “Vehicle make,” and “Vehicle model” parameters. Referring to the example ofFIG.1C, Key_A may include a matching value for a “UE ID” parameter. In other examples, other types of information or parameters within blocks101may be used to specify keys associated with the blocks101.

In some embodiments, blockchain100may be arranged such that the latest block (e.g., the most recently recorded block) having a given key is a “correct” or “authoritative” block for that key. For example, block101-A may include a set of values (“{Values A}”) that may be old, outdated, etc. with respect to Values_C that are included in block101-C with the same Key_A. Thus, BRN103and/or some other device or system that access blockchain100may search for blocks that include Key_A, and may identify the values present in block101-C. For example, such a search may be performed in reverse order on blockchain100, from the most recently recorded block to the oldest block. Additionally, or alternatively, BRN103and/or some other device or system may identify multiple or all blocks that match the same Key_A, and may utilize the information therein for any suitable purpose. In any event, scenarios may arise in which the recordation of a block with the same key as other blocks that are already in blockchain100may result in a mismatch that may be detected and remediated (at106) by BRN103, as noted above.

Assume in this example that the proposed recordation of block101-F (including {Values_F}) to blockchain100may result in a mismatch of values, based on Values_C included in block101-C with the same key (Key_A) as block101-F. For example, the mismatch may be based on different values for the same parameters, values for parameters that create one or more logical inconsistencies, values for parameters that do not satisfy a specified pattern or set of constraints, etc. Performing the remedial measures may include reconciling differences between the values included in the different blocks101-C and101-F, such as selecting a particular block as “authoritative,” generating a new set of values based on a combination of values present in blocks101-C and101-F, and/or performing one or more other remedial measures.

As shown inFIG.2A, for example, BRN103may determine (at202) that the values of block101-F are valid, and that the values of block101-C are invalid. As such, the remedial measures taken by BRN103may include recording (at204) proposed block101-F to blockchain100. Additionally, or alternatively, BRN103may perform one or more actions to facilitate the recordation of block101-F to blockchain100, such as participating in a consensus procedure with one or more other nodes (e.g., “voting” or otherwise indicating that block101-F is valid and/or should otherwise be included in blockchain100).

As another example, as shown inFIG.2B, block101-F may be recorded (at210) prior to BRN103identifying (at102) new block101-F. BRN103may, for example, receive a notification of the recordation (at210) of block101-F, may “crawl” or search blockchain100and identify newly recorded block101-F, and/or may otherwise identify that block101-F has been recorded (at210) to blockchain100. After block101-F has been recorded to blockchain100, BRN103may compare values of block101-F to the values of block101-C (and/or to one or more other blocks that include the same Key_A, such as block101-A), and may determine (at212) that the values of block101-F are valid (and/or that the values of block101-C and/or block101-A are invalid). BRN103may accordingly validate (at214) block101-F (e.g., indicate validity of block101-F to one or more nodes associated with blockchain100) and/or may perform no additional action, as block101-F has been recorded (at210) to blockchain100. In some embodiments, BRN103may maintain a record that block101-F has been validated, and/or that values of block101-C and/or block101-C (with the same Key_A as block101-F) are invalid and/or outdated.

On the other hand, as shown inFIG.3A, BRN103may determine (at302) that the values in proposed block101-F are invalid (e.g., the values of block101-C and/or101-A, with the same Key_A as block101-F, are valid). For example, based on the particular type of mismatch between the values of block101-F and block101-C, BRN103may determine that block101-C is “authoritative” as compared to block101-F. As such, BRN103may determine that block101-F should accordingly not be recorded to block101-F. BRN103may therefore reject (at304) the recordation of block101-F to blockchain100. For example, BRN103may discard block101-F without recording block101-F to blockchain100, may “vote” or otherwise participate in a consensus procedure with one or more nodes associated with blockchain100to indicate that block101-F should not be recorded, etc.

In some embodiments, as shown inFIG.3B, in situations where block101-F is recorded (at310) to blockchain100prior to analysis by BRN103(e.g., a determination (at312) that block101-F includes invalid values and/or that block101-C includes values that are valid and/or authoritative with respect to the values of block101-F), BRN103may record (at314) a new block101-F to blockchain100. The new block101-G may include the same values as block101-C, which were identified (at312) by BRN103as being valid or authoritative. This type of operation may be performed in embodiments where blocks may be added to blockchain100without a consensus mechanism, and/or in which blocks may otherwise be added to blockchain100prior to analysis and remediation by BRN103.

For example, multiple nodes, participants, etc. may have access to and/or may otherwise be capable of recording blocks to blockchain100, and BRN103may perform one or more reconciliation and/or other remedial measures for blocks associated with the same keys that have mismatching values. As shown inFIG.4, for example, a first blockchain participant401-1(e.g., a node or other type of device or system) may be authorized to and/or otherwise may be capable of recording and/or proposing (at402) blocks to blockchain100, and a second blockchain participant401-1may also be authorized to and/or otherwise may be capable of recording and/or proposing (at404) blocks to blockchain100. As similarly discussed above, BRN103may validate, invalidate, reconcile, and/or perform one or more other remedial measures based on the blocks recorded to and/or proposed by (at402and/or404) blockchain participants401-1and401-2. BRN103may perform such operations based on one or more models that associate particular types of value mismatches to particular remedial actions, such as determining whether particular values and/or blocks are valid and/or invalid with respect to other values and/or blocks sharing the same key.

In some embodiments, the models used by BRN103may be generated, modified, maintained by BRN103and/or by one or more other devices or systems. For example, as shown inFIG.5, AI/ML Blockchain Remediation Modeling System (“ABRMS”)501may receive a set of blocks503, which may include blocks recorded to one or more blockchains100and/or information stored within such blocks. Blocks503-1and503-2may, for example, include information (e.g., parameters, values, etc.) recorded to one or more blockchains100, and/or proposed to be added to one or more blockchains100. In this example, blocks503-1and503-2may be associated with the same key. For example, blocks503-1and503-2may include an indication of a particular key, and/or ABRMS501may identify the key using feature extraction, feature importance, and/or one or more other AI/ML techniques.

ABRMS501may further identify (at504) mismatching values in blocks503-1and503-2(e.g., one or more values for attributes other than the identified key). For example, as discussed in the example ofFIG.1B, the mismatching values may relate to different vehicle telematics information for the same vehicle over the same time period. As discussed in the example ofFIG.1C, the mismatching values may include a determination that one or more values of block503-1may not be possible or may otherwise be incompatible with one or more values of block503-2, even if such values are associated with different parameters. For example, block503-1may indicate that a mobile phone has been returned to a vendor or manufacturer, while block503-2may indicate (and/or it may be inferred or determined based on the information included in block503-2) that a wireless network has allocated resources to providing wireless service to the mobile phone. In some embodiments, such incompatibilities between values of different parameters may be determined based on rules, constraints, logic, etc. provided to ABRMS501. Additionally, or alternatively, ABRMS501may identify such incompatibilities using AI/ML techniques, which may include receiving feedback or identifying the performance of remedial operations when particular sets of values for a first set of parameters are present in one block, while other sets of values for a second set of different parameters are present in another block.

In some embodiments, for example, ABRMS501may output (at506) an indication of a mismatch or incompatibility to Remediation System505, which may be a device or system associated with performing or identifying remedial measures based on identified mismatches in different blocks. In some embodiments, an operator, administrator, etc. associated with Remediation System505may select or identify a particular remedial measure to perform based on the indicated mismatch of values associated with different blocks503-1and503-2associated with the same key. Additionally, or alternatively, one or more automated processes (e.g., AI/ML processes or other suitable processes) may be used to simulate, test, or otherwise identify a particular remedial measure to take with respect to the identified mismatch. As discussed above, the remedial measure may include determining that values of a particular one of block503-1and/or block503-2is valid, and suitable recording such information in blockchain100. In some embodiments, the remedial measures may include determining that some values of block503-1are valid (e.g., supersede one or more values of block503-2), and that some other values of block503-2are valid (e.g., supersede one or more values of block503-1). In such scenarios, the remedial measures may include recording a new block, with some values of block503-1and some values of block503-2. In some situations, Remediation System505may determine (or receive an indication) that one or more values should be computed and/or derived from the values of block503-1and/or block503-2(e.g., an average, median, or other suitable function), and such computed and/or derived values should be recorded to blockchain100.

Remediation System505may indicate (at508) remedial measures that were performed based on particular mismatches, such that different types of mismatches may be associated with different remedial measures. ABRMS501may generate and/or modify (at510) one or more blockchain remediation models associating respective mismatches with particular remedial measures.

For example, if ABRMS501receives (at508) an indication that the same type of mismatch was remediated in the same way, ABRMS501may perform a feature extraction, feature importance analysis, or other suitable procedure to identify how particular types of mismatches are remediated, reconciled, etc. Referring to the example information inFIG.1B, ABRMS501may receive (at508) multiple instances of information indicating that vehicle telematics data was received from vehicle systems and mobile phones, where such information included mismatches in speed values, acceleration values, etc. ABRMS501may identify features, trends, patterns, etc. with how such mismatches were handled by Remediation System505. In some embodiments, ABRMS501may identify that Remediation System505tended to select values from blocks with an information source of “Vehicle system” (e.g., instead of an information source of “Mobile phone”). Additionally, or alternatively, ABRMS501may identify that Remediation System505tended to select higher values of the mismatching attributes. As another example, ABRMS501may identify that Remediation System505tended to select the “Avg. speed” value associated with the “Vehicle system” information source and tended to select the “Avg. acceleration” value associated with the “Mobile phone” information source.

As another example, referring to the example ofFIG.1C, ABRMS501may identify that when an order status of “Returned” was associated with a particular UE ID, Remediation System505modified or deleted parameters associated with a different block (e.g., and the same key, such as the same UE ID) associated with network parameters and/or policies associated with the UE ID. In some embodiments, Remediation System505may generate or provide one or more rules, constraints, etc. between different parameters and/or values for such parameters, that indicate incompatibilities. In some embodiments, ABRMS501may utilize one or more AI/ML techniques or other suitable techniques to generate such rules, constraints, etc., which may be incorporated into the blockchain remediation model(s) generated and/or modified by ABRMS501.

In some embodiments, different keys or types of keys may be associated with different remedial measures for the same types of mismatches. Referring to the example of vehicle telematics, some makes and/or models of vehicles may be associated with different measures of accuracy or precision, such that vehicle telematics associated with one type of vehicle may be identified as being more precise, reliable, accurate, etc. than vehicle telematics associated with another type of vehicle. Thus, in some scenarios, a mismatch between a first block that includes vehicle telematics received from a vehicle system and a second block that includes vehicle telematics (e.g., for the same vehicle over the same time period) received from another device, such as a mobile phone located within the vehicle, may be associated with a remedial action of selecting the first block for validation, recordation, etc. to blockchain100. For example, the first block may be associated with a vehicle system that has been determined (e.g., via AI/ML techniques or other suitable techniques) as being associated with a relatively high measure of accuracy, reliability, precision, etc., and/or the second block may be associated with a mobile phone that has been determined (e.g., via AI/ML techniques or other suitable techniques) as being associated with a relatively low measure of accuracy, reliability, precision, etc. (e.g., as compared to the accuracy, reliability, etc. of the vehicle system). In other scenarios, the same type of mismatch may be associated with a remedial action of selecting the second block (e.g., including the vehicle telematics received from the mobile phone) for validation, recordation, etc. to blockchain100. In such scenarios, the mobile phone may be associated with a higher measure of reliability, accuracy, precision, etc. than the vehicle system.

ABRMS501may further provide (at512) the one or more blockchain remediation models to BRN103, which may utilize such models to validate, invalidate, and/or otherwise remediate blocks that are added to, or are proposed to be added to, blockchain100, as discussed above. In this manner, the accuracy and reliability of information stored in blockchain100may be enhanced through automated mechanisms, thereby reducing or eliminating the need for manual remediation to be performed when inconsistent, incompatible, mismatching, etc. information is recorded to blockchain100for the same key (e.g., the same item, object, timeframe, etc.).

FIG.6illustrates an example process600for using blockchain remediation models to validate and/or perform remedial actions with respect to blocks proposed or added to a blockchain. In some embodiments, some or all of process600may be performed by BRN103. In some embodiments, one or more other devices may perform some or all of process600in concert with, and/or in lieu of, BRN103, such as ABRMS501and/or Remediation System505. For example, while process600is described below as being performed by BRN103, one or more of the operations of process600may be performed by ABRMS501, Remediation System505, and/or some other device or system.

As shown, process600may include generating and/or modifying (at602) one or more blockchain remediation models. As discussed above, such models may associate particular types of mismatches, incompatibilities, inconsistencies, etc., between particular sets of attributes and/or values for such attributes, with particular remedial actions. The mismatches may include mismatches between values of the same sets of attributes (e.g., different values for the same attributes), mismatches between values of different attributes (e.g., where the values for the different attributes do not meet particular criteria, constraints, thresholds, etc.), and/or other types of mismatches. The remedial actions may include and/or may be based on selecting a particular set of values as valid, selecting a particular set of values as invalid, selecting a subset of a first set of values as valid and a subset of a second set of values as valid, generating a third set of values based on the first and second sets of values (e.g., by performing one or more operations, functions, etc. on the first and second sets of values), or other suitable remedial actions. As discussed above, the one or more blockchain remedial models may be performed using one or more AI/ML techniques or other suitable techniques based on simulations and/or real-world performance of the remedial actions with respect to particular types of mismatches.

Process600may further include identifying (at604) blocks of a blockchain with the same key and with mismatching values. For example, BRN103may identify one or more records, blocks, etc. associated with blockchain100that are associated with the same key (e.g., the same particular set of values for the same particular set of attributes), and with mismatching values for other attributes. The identified (at604) blocks may be blocks that are already included in blockchain100, blocks that are proposed to be added to blockchain100, and/or a combination of a first block that is already included in blockchain100and a second block that is proposed to be added to blockchain100. In some embodiments, BRN103may identify the mismatching values by performing a direct comparison of the values associated with the blocks and identifying one or more values in one block that are not present and/or are different in the other block. In some embodiments, BRN103may identify the mismatching values by performing one or more operations, functions, etc. on the values included in the blocks and determining that a result of the operations, functions, etc. do not satisfy a given set of criteria, constraints, thresholds, etc.

Process600may additionally include identifying (at606), based on the one or more blockchain remediation models, a particular remedial action to perform with respect to blockchain100based on the mismatching values of the identified blocks. For example, as discussed above, the one or more blockchain remediation models may indicate how to select which set of values are valid, may indicate that one or more operations should be performed on the values of the blocks (e.g., to generate a third set of values), and/or may specify one or more other remedial actions.

Process600may also include performing (at608) the identified remedial action. For example, as discussed above, BRN103may select a particular block as “valid” or “authoritative” (e.g., with respect to the other block), may select the values of one block as valid and/or may select the values of the other block as invalid, may compute one or more values based on values present in both blocks, etc. BRN103may further add one or more blocks to blockchain100based on the determination of which block includes valid values. In some embodiments, BRN103may add a third block that includes the values of one of the identified blocks, and/or that includes values computed based on values included in both of the identified blocks. In some embodiments, BRN103may add a “corrective” block that refers to one or more of the identified blocks and includes one or more values for the attribute(s) that were identified as having a mismatch.

Process600may further include identifying (at610) subsequent blockchain events associated with the same key. For example, after the remedial action is performed (at608), BRN103may identify subsequent blocks that are recorded to blockchain100with the same key as the identified blocks. Such events may include the recording of new values for the same attributes that were identified (at604) as having a mismatch and were remediated (at608). This type of event may indicate that the remedial action that was performed (at608) should be modified or replaced based on the subsequent action. In this manner, the one or more blockchain remediation models may continue to be refined in an iterative process, thus improving the predictive accuracy of the models.

FIG.7illustrates an example environment700, in which one or more embodiments may be implemented. In some embodiments, environment700may correspond to a Fifth Generation (“5G”) network, and/or may include elements of a 5G network. In some embodiments, environment700may correspond to a 5G Non-Standalone (“NSA”) architecture, in which a 5G radio access technology (“RAT”) may be used in conjunction with one or more other RATs (e.g., a Long-Term Evolution (“LTE”) RAT), and/or in which elements of a 5G core network may be implemented by, may be communicatively coupled with, and/or may include elements of another type of core network (e.g., an evolved packet core (“EPC”)). As shown, environment700may include UE701, RAN710(which may include one or more Next Generation Node Bs (“gNBs”)711), RAN712(which may include one or more one or more evolved Node Bs (“eNBs”)713), and various network functions such as Access and Mobility Management Function (“AMF”)715, Mobility Management Entity (“MME”)716, Serving Gateway (“SGW”)717, Session Management Function (“SMF”)/Packet Data Network (“PDN”) Gateway (“PGW”)-Control plane function (“PGW-C”)720, Policy Control Function (“PCF”)/Policy Charging and Rules Function (“PCRF”)725, Application Function (“AF”)730, User Plane Function (“UPF”)/PGW-User plane function (“PGW-U”)735, Home Subscriber Server (“HSS”)/Unified Data Management (“UDM”)740, and Authentication Server Function (“AUSF”)745. Environment700may also include one or more networks, such as Data Network (“DN”)750.

Environment700may include one or more additional devices or systems communicatively coupled to one or more networks (e.g., DN750), such as BRN103, ABRMS501, and/or Remediation System505. While shown as separate elements, in some embodiments, one or more of BRN103, ABRMS501, and/or Remediation System505may be implemented by the same device or system, and/or by the same set of devices.

The example shown inFIG.7illustrates one instance of each network component or function (e.g., one instance of SMF/PGW-C720, PCF/PCRF725, UPF/PGW-U735, HSS/UDM740, and/or AUSF745). In practice, environment700may include multiple instances of such components or functions. For example, in some embodiments, environment700may include multiple “slices” of a core network, where each slice includes a discrete set of network functions (e.g., one slice may include a first instance of SMF/PGW-C720, PCF/PCRF725, UPF/PGW-U735, HSS/UDM740, and/or AUSF745, while another slice may include a second instance of SMF/PGW-C720, PCF/PCRF725, UPF/PGW-U735, HSS/UDM740, and/or AUSF745). The different slices may provide differentiated levels of service, such as service in accordance with different Quality of Service (“QoS”) parameters.

The quantity of devices and/or networks, illustrated inFIG.7, is provided for explanatory purposes only. In practice, environment700may include additional devices and/or networks, fewer devices and/or networks, different devices and/or networks, or differently arranged devices and/or networks than illustrated inFIG.7. For example, while not shown, environment700may include devices that facilitate or enable communication between various components shown in environment700, such as routers, modems, gateways, switches, hubs, etc. Alternatively, or additionally, one or more of the devices of environment700may perform one or more network functions described as being performed by another one or more of the devices of environment700. Devices of environment700may interconnect with each other and/or other devices via wired connections, wireless connections, or a combination of wired and wireless connections. In some implementations, one or more devices of environment700may be physically integrated in, and/or may be physically attached to, one or more other devices of environment700.

UE701may include a computation and communication device, such as a wireless mobile communication device that is capable of communicating with RAN710, RAN712, and/or DN750. UE701may be, or may include, a radiotelephone, a personal communications system (“PCS”) terminal (e.g., a device that combines a cellular radiotelephone with data processing and data communications capabilities), a personal digital assistant (“PDA”) (e.g., a device that may include a radiotelephone, a pager, Internet/intranet access, etc.), a smart phone, a laptop computer, a tablet computer, a camera, a personal gaming system, an IoT device (e.g., a sensor, a smart home appliance, or the like), a wearable device, an Internet of Things (“IoT”) device, a Machine-to-Machine (“M2M”) device, or another type of mobile computation and communication device. UE701may send traffic to and/or receive traffic (e.g., user plane traffic) from DN750via RAN710, RAN712, and/or UPF/PGW-U735.

RAN710may be, or may include, a 5G RAN that includes one or more base stations (e.g., one or more gNBs711), via which UE701may communicate with one or more other elements of environment700. UE701may communicate with RAN710via an air interface (e.g., as provided by gNB711). For instance, RAN710may receive traffic (e.g., voice call traffic, data traffic, messaging traffic, signaling traffic, etc.) from UE701via the air interface, and may communicate the traffic to UPF/PGW-U735, and/or one or more other devices or networks. Similarly, RAN710may receive traffic intended for UE701(e.g., from UPF/PGW-U735, AMF715, and/or one or more other devices or networks) and may communicate the traffic to UE701via the air interface.

RAN712may be, or may include, a LTE RAN that includes one or more base stations (e.g., one or more eNBs713), via which UE701may communicate with one or more other elements of environment700. UE701may communicate with RAN712via an air interface (e.g., as provided by eNB713). For instance, RAN710may receive traffic (e.g., voice call traffic, data traffic, messaging traffic, signaling traffic, etc.) from UE701via the air interface, and may communicate the traffic to UPF/PGW-U735, and/or one or more other devices or networks. Similarly, RAN710may receive traffic intended for UE701(e.g., from UPF/PGW-U735, SGW717, and/or one or more other devices or networks) and may communicate the traffic to UE701via the air interface.

AMF715may include one or more devices, systems, Virtualized Network Functions (“VNFs”), etc., that perform operations to register UE701with the 5G network, to establish bearer channels associated with a session with UE701, to hand off UE701from the 5G network to another network, to hand off UE701from the other network to the 5G network, manage mobility of UE701between RANs710and/or gNBs711, and/or to perform other operations. In some embodiments, the 5G network may include multiple AMFs715, which communicate with each other via the N14 interface (denoted inFIG.7by the line marked “N14” originating and terminating at AMF715).

MME716may include one or more devices, systems, VNFs, etc., that perform operations to register UE701with the EPC, to establish bearer channels associated with a session with UE701, to hand off UE701from the EPC to another network, to hand off UE701from another network to the EPC, manage mobility of UE701between RANs712and/or eNBs713, and/or to perform other operations.

SGW717may include one or more devices, systems, VNFs, etc., that aggregate traffic received from one or more eNBs713and send the aggregated traffic to an external network or device via UPF/PGW-U735. Additionally, SGW717may aggregate traffic received from one or more UPF/PGW-Us735and may send the aggregated traffic to one or more eNBs713. SGW717may operate as an anchor for the user plane during inter-eNB handovers and as an anchor for mobility between different telecommunication networks or RANs (e.g., RANs710and712).

SMF/PGW-C720may include one or more devices, systems, VNFs, etc., that gather, process, store, and/or provide information in a manner described herein. SMF/PGW-C720may, for example, facilitate the establishment of communication sessions on behalf of UE701. In some embodiments, the establishment of communications sessions may be performed in accordance with one or more policies provided by PCF/PCRF725.

PCF/PCRF725may include one or more devices, systems, VNFs, etc., that aggregate information to and from the 5G network and/or other sources. PCF/PCRF725may receive information regarding policies and/or subscriptions from one or more sources, such as subscriber databases and/or from one or more users (such as, for example, an administrator associated with PCF/PCRF725).

AF730may include one or more devices, systems, VNFs, etc., that receive, store, and/or provide information that may be used in determining parameters (e.g., quality of service parameters, charging parameters, or the like) for certain applications.

UPF/PGW-U735may include one or more devices, systems, VNFs, etc., that receive, store, and/or provide data (e.g., user plane data). For example, UPF/PGW-U735may receive user plane data (e.g., voice call traffic, data traffic, etc.), destined for UE701, from DN750, and may forward the user plane data toward UE701(e.g., via RAN710, SMF/PGW-C720, and/or one or more other devices). In some embodiments, multiple UPFs735may be deployed (e.g., in different geographical locations), and the delivery of content to UE701may be coordinated via the N9 interface (e.g., as denoted inFIG.7by the line marked “N9” originating and terminating at UPF/PGW-U735). Similarly, UPF/PGW-U735may receive traffic from UE701(e.g., via RAN710, SMF/PGW-C720, and/or one or more other devices), and may forward the traffic toward DN750. In some embodiments, UPF/PGW-U735may communicate (e.g., via the N4 interface) with SMF/PGW-C720, regarding user plane data processed by UPF/PGW-U735.

HSS/UDM740and AUSF745may include one or more devices, systems, VNFs, etc., that manage, update, and/or store, in one or more memory devices associated with AUSF745and/or HSS/UDM740, profile information associated with a subscriber. AUSF745and/or HSS/UDM740may perform authentication, authorization, and/or accounting operations associated with the subscriber and/or a communication session with UE701.

DN750may include one or more wired and/or wireless networks. For example, DN750may include an Internet Protocol (“IP”)-based PDN, a wide area network (“WAN”) such as the Internet, a private enterprise network, and/or one or more other networks. UE701may communicate, through DN750, with data servers, other UEs701, and/or to other servers or applications that are coupled to DN750. DN750may be connected to one or more other networks, such as a public switched telephone network (“PSTN”), a public land mobile network (“PLMN”), and/or another network. DN750may be connected to one or more devices, such as content providers, applications, web servers, and/or other devices, with which UE701may communicate.

FIG.8illustrates an example Distributed Unit (“DU”) network800, which may be included in and/or implemented by one or more RANs (e.g., RAN710, RAN712, or some other RAN). In some embodiments, a particular RAN may include one DU network800. In some embodiments, a particular RAN may include multiple DU networks800. In some embodiments, DU network800may correspond to a particular gNB711of a 5G RAN (e.g., RAN710). In some embodiments, DU network800may correspond to multiple gNBs711. In some embodiments, DU network800may correspond to one or more other types of base stations of one or more other types of RANs. As shown, DU network800may include Central Unit (“CU”)805, one or more Distributed Units (“DUs”)803-1through803-N (referred to individually as “DU803,” or collectively as “DUs803”), and one or more Radio Units (“RUs”)801-1through801-M (referred to individually as “RU801,” or collectively as “RUs801”).

CU805may communicate with a core of a wireless network (e.g., may communicate with one or more of the devices or systems described above with respect toFIG.7, such as AMF715and/or UPF/PGW-U735). In the uplink direction (e.g., for traffic from UEs701to a core network), CU805may aggregate traffic from DUs803, and forward the aggregated traffic to the core network. In some embodiments, CU805may receive traffic according to a given protocol (e.g., Radio Link Control (“RLC”)) from DUs803, and may perform higher-layer processing (e.g., may aggregate/process RLC packets and generate Packet Data Convergence Protocol (“PDCP”) packets based on the RLC packets) on the traffic received from DUs803.

In accordance with some embodiments, CU805may receive downlink traffic (e.g., traffic from the core network) for a particular UE701, and may determine which DU(s)803should receive the downlink traffic. DU803may include one or more devices that transmit traffic between a core network (e.g., via CU805) and UE701(e.g., via a respective RU801). DU803may, for example, receive traffic from RU801at a first layer (e.g., physical (“PHY”) layer traffic, or lower PHY layer traffic), and may process/aggregate the traffic to a second layer (e.g., upper PHY and/or RLC). DU803may receive traffic from CU805at the second layer, may process the traffic to the first layer, and provide the processed traffic to a respective RU801for transmission to UE701.

RU801may include hardware circuitry (e.g., one or more RF transceivers, antennas, radios, and/or other suitable hardware) to communicate wirelessly (e.g., via an RF interface) with one or more UEs701, one or more other DUs803(e.g., via RUs801associated with DUs803), and/or any other suitable type of device. In the uplink direction, RU801may receive traffic from UE701and/or another DU803via the RF interface and may provide the traffic to DU803. In the downlink direction, RU801may receive traffic from DU803, and may provide the traffic to UE701and/or another DU803.

RUs801may, in some embodiments, be communicatively coupled to one or more Multi-Access/Mobile Edge Computing (“MEC”) devices, referred to sometimes herein simply as “MECs”807. For example, RU801-1may be communicatively coupled to MEC807-1, RU801-M may be communicatively coupled to MEC807-M, DU803-1may be communicatively coupled to MEC807-2, DU803-N may be communicatively coupled to MEC807-N, CU805may be communicatively coupled to MEC807-3, and so on. MECs807may include hardware resources (e.g., configurable or provisionable hardware resources) that may be configured to provide services and/or otherwise process traffic to and/or from UE701, via a respective RU801.

For example, RU801-1may route some traffic, from UE701, to MEC807-1instead of to a core network (e.g., via DU803and CU805). MEC807-1may process the traffic, perform one or more computations based on the received traffic, and may provide traffic to UE701via RU801-1. In this manner, ultra-low latency services may be provided to UE701, as traffic does not need to traverse DU803, CU805, and an intervening backhaul network between DU network800and the core network. In some embodiments, MEC807may include, and/or may implement, some or all of the functionality described above with respect to BRN103, ABRMS501, and/or Remediation System505.

FIG.9illustrates example components of device900. One or more of the devices described above may include one or more devices900. Device900may include bus910, processor920, memory930, input component940, output component950, and communication interface960. In another implementation, device900may include additional, fewer, different, or differently arranged components.

Bus910may include one or more communication paths that permit communication among the components of device900. Processor920may include a processor, microprocessor, or processing logic that may interpret and execute instructions. In some embodiments, processor920may be or may include one or more hardware processors. Memory930may include any type of dynamic storage device that may store information and instructions for execution by processor920, and/or any type of non-volatile storage device that may store information for use by processor920.

Input component940may include a mechanism that permits an operator to input information to device900and/or other receives or detects input from a source external to940, such as a touchpad, a touchscreen, a keyboard, a keypad, a button, a switch, a microphone or other audio input component, etc. In some embodiments, input component940may include, or may be communicatively coupled to, one or more sensors, such as a motion sensor (e.g., which may be or may include a gyroscope, accelerometer, or the like), a location sensor (e.g., a Global Positioning System (“GPS”)-based location sensor or some other suitable type of location sensor or location determination component), a thermometer, a barometer, and/or some other type of sensor. Output component950may include a mechanism that outputs information to the operator, such as a display, a speaker, one or more light emitting diodes (“LEDs”), etc.

Communication interface960may include any transceiver-like mechanism that enables device900to communicate with other devices and/or systems. For example, communication interface960may include an Ethernet interface, an optical interface, a coaxial interface, or the like. Communication interface960may include a wireless communication device, such as an infrared (“IR”) receiver, a Bluetooth® radio, or the like. The wireless communication device may be coupled to an external device, such as a remote control, a wireless keyboard, a mobile telephone, etc. In some embodiments, device900may include more than one communication interface960. For instance, device900may include an optical interface and an Ethernet interface.