Patent Publication Number: US-2022240362-A1

Title: Systems and methods for dynamic control and monitoring of heterogeneous smart lighting systems

Description:
BACKGROUND 
     Cities, municipalities, and the like may deploy lighting fixtures, such as street lamps, to provide lighting and safety on sidewalks, roadways, or other locations. Different types of lighting fixtures, such as fixtures of different makes and/or models, and/or using different types of bulbs, may consume different amounts of power when set to different brightness levels (e.g., sometimes referred to as “dimming”). Malfunctioning fixtures may consume more or less power than expected when set to a given brightness level, which may indicate an increase in the amount of power consumed and/or a reduction in light output. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  illustrates an example overview of one or more embodiments described herein; 
         FIG. 2  illustrates example components of a smart lighting fixture, in accordance with some embodiments; 
         FIGS. 3A and 3B  illustrate an example automatic calibration process of a smart lighting fixture, in accordance with some embodiments; 
         FIGS. 4-6  illustrate example data structures associated with one or more smart lighting fixture power consumption models, in accordance with some embodiments; 
         FIG. 7  illustrates the configuration of a given smart lighting fixture based on an evaluation of measured power consumption values associated with the smart lighting fixture and one or more smart lighting fixture power consumption models, in accordance with some embodiments; 
         FIG. 8  illustrates the example performance of one or more remedial actions based on monitoring of power consumption values associated with a smart lighting fixture, in accordance with some embodiments 
         FIG. 9  illustrates an example process for generating, refining, etc. consumption models and using such models to detect and remediate anomalous consumption with respect to one or more smart lighting fixtures, in accordance with some embodiments; 
         FIG. 10  illustrates an example environment in which one or more embodiments, described herein, may be implemented; 
         FIG. 11  illustrates an example arrangement of a radio access network (“RAN”), in accordance with some embodiments; and 
         FIG. 12  illustrates example components of one or more devices, in accordance with one or more embodiments described herein. 
     
    
    
     DETAILED DESCRIPTION OF EXAMPLE EMBODIMENTS 
     The following detailed description refers to the accompanying drawings. The same reference numbers in different drawings may identify the same or similar elements. 
     Embodiments described herein provide for the generation and/or refinement of models (e.g., using analytical techniques such as machine learning (“ML”) techniques or other suitable techniques) that reflect nominal power consumption of various types of lighting fixtures at different brightness levels. For example, a smart lighting fixture of some embodiments may be “dimmable” and/or may otherwise be configurable, such that the amount of power delivered to a light output component of the smart lighting fixture (e.g., one or more bulbs, light-emitting diode (“LED”) modules, etc.) is variable. Such “dimming” operations may be achieved by way of increasing or decreasing voltage, increasing or decreasing resistance, pulse width modulation, and/or other suitable operations. The rates of power consumed by a given lighting fixture at different brightness levels may be referred to herein as a “dimming curve.” Different types of lighting fixtures may be associated with different dimming curves. For example, one type of lighting fixture may consume 10 Watts (“W”) when set to a “10%” brightness level, while another type of lighting fixture may consume 20 W when set to the “10%” brightness level. Even among lighting fixtures of the same type, there may be variations in the performance of individual fixtures due to manufacturing variations, environmental variations, etc. 
     In accordance with some embodiments, the smart lighting fixture may perform an automatic calibration process to determine a dimming curve associated with the smart lighting fixture, which may include automatically setting a brightness level parameter associated with the smart lighting fixture to various brightness levels (e.g., 10%, 20%, 30%, etc.) and measuring respective power consumption metrics (e.g., instantaneous rate of power consumption, amount of power consumed over time, average amount or rate of power consumed in a given time period, etc.) associated with the various brightness levels. As further described herein, one or more smart fixture power consumption models (referred to herein simply as “consumption models”) may be generated based on dimming curves received from multiple smart lighting fixtures. The models may be arranged, clustered, grouped, and/or otherwise differentiated in single or multiple dimensions, such as based on lighting fixture type (e.g., make, model, bulb output power rating, bulb technology, etc.), location (e.g., latitude and longitude coordinates, city, region, province, etc.), ambient conditions (e.g., ambient temperature, ambient light levels, radio frequency (“RF”) signal levels, etc.), user or user group (e.g., an owner and/or operator associated with a given smart lighting fixture, such as a city, municipality, university, etc.), and/or other factors. 
     The consumption models may be used as predictive models to identify or categorize a given smart lighting fixture (e.g., a smart lighting fixture of unknown make, model, bulb type, etc.) based on measured consumption metrics (e.g., rates or amounts of power consumed at particular brightness levels) associated with the smart lighting fixture. In some embodiments, the consumption models may be used in system operation to analyze consumption metrics associated with a given smart lighting fixture to detect potential anomalies or other events, such as the consumption of greater or lesser amounts of power at particular brightness levels. In some embodiments, the consumption models may be used to identify particular remedial actions to perform in response to such events, such as modifying a brightness level, outputting an alert, and/or one or more other actions. The actions taken may be dependent on the amount of variation from the predicted performance of the consumption models. Accordingly, smart lighting fixtures of various types may be able to be automatically calibrated and configured in order to monitor consumption metrics, detect anomalies, and perform one or more remedial measures in response to detected anomalies. 
     As shown in  FIG. 1 , for example, a particular region  100  may include multiple smart lighting fixtures  101 . Smart lighting fixtures  101  may be, for example, permanently affixed or mounted, semi-permanently affixed or mounted, and/or mobile devices located within region  100 . Thus, while referred to herein as a “fixture,” in some embodiments smart lighting fixture  101  may be, or may include, any suitable lighting device that performs operations described herein. 
     Smart lighting fixtures  101  may communicate (e.g., via one or more wired and/or more wireless networks) with Smart Fixture Optimization System (“SFOS”)  103 , to send and/or receive information as described herein. For example, one or more smart lighting fixtures  101  may output (at  102 ) consumption information associated with respective smart lighting fixtures  101  to SFOS  103 . As discussed below, such consumption information may include rates and/or amounts of power consumption at different brightness levels, dimming curves, and/or other suitable information. In some embodiments, SFOS  103  may receive (e.g., from smart lighting fixtures  101  and/or one or more other devices or systems) attributes and/or parameters associated with smart lighting fixtures  101 , such as location, fixture type (e.g., make and/or model, bulb technology (e.g., incandescent, LED, or the like), bulb output power rating, etc.), ambient temperature corresponding to times at which consumption metrics are measured, and/or other attributes or parameters. 
     As described herein, smart lighting fixtures  101  may provide (at  102 ) consumption information as part of an automatic calibration process and/or at some other time, such as on an ongoing, continuous, periodic, intermittent, and/or event-based basis. SFOS  103  may generate, refine, and/or determine (at  104 ) one or more consumption models based on the received information. For example, SFOS  103  may perform a “training” or model generation operation, in which the received information is aggregated, clustered, categorized, etc., based on one or more attributes or parameters, and consumption models may be generated based on the aggregated, clustered, categorized, etc. information. 
     For example, as discussed below, a first consumption model may be associated with a first type of smart lighting fixture  101  (e.g., a fixture having a 100 W incandescent bulb) while a second consumption model may be associated with a second type of smart lighting fixture  101  (e.g., a fixture having a pair of 40 W LED modules). As another example, a third consumption model may be based on a particular smart lighting fixture  101  in a first set of ambient conditions (e.g., an ambient temperature of 30 degrees Fahrenheit) and a fourth consumption model may be based on the same smart lighting fixture  101  (and/or one or more other smart lighting fixtures  101  having the same or similar attributes) in a second set of ambient conditions (e.g., an ambient temperature of 70 degrees Fahrenheit). In some embodiments, the consumption models may be multi-dimension, in that a fifth example consumption model may be based on the first and third consumption models, a sixth consumption model may be based on the first and fourth consumption models, a seventh consumption model may be based on the second and third consumption models, and an eighth consumption model may be based on the second and fourth consumption models. Similarly, other consumption models may be based on one or more (e.g., a single or multiple) sets of attributes or parameters of smart lighting fixtures  101 . 
     In some embodiments, smart lighting fixture  101  may provide consumption information as part of an identification or categorization process associated with smart lighting fixture  101 . For example, smart lighting fixture  101  may provide rates and/or amounts of power consumption associated with smart lighting fixture  101  at different brightness levels to SFOS  103 , SFOS  103  may identify one or more matching consumption models (e.g., using analytical techniques such as regression, K-means clustering, and/or some other suitable similarity analysis) to determine that the consumption information associated with smart lighting fixture  101  matches (e.g., has a measure of similarity exceeding a threshold measure of similarity) a particular consumption model. 
     In some embodiments, particular consumption models may be associated with particular remedial actions for particular types of anomalies and/or events. Such actions may have been determined using AI/ML techniques (e.g., using supervised learning, unsupervised learning, and/or other suitable techniques) to identify particular remedial actions that resolved particular types of anomalies and/or events in the past. For example, one particular consumption model may be associated with a first type of anomaly (e.g., rate of power consumption at a 10% brightness level exceeds an expected rate of power consumption by 50%) and a second type of anomaly (e.g., rate of power consumption at the 10% brightness level exceeds the expected rate of power consumption by 100%). The first type of anomaly for the particular consumption model may be associated with a first remedial action (e.g., output an alert to/from SFOS  103  and/or some other device or system), while the second type of anomaly may be associated with a second remedial action (e.g., reduce the brightness level to 5%, reduce the brightness level to a level that corresponds to a particular rate or amount of power consumed, shut off power to a light output component of smart lighting fixture  101 , and/or some other suitable action). 
     In some embodiments, SFOS  103  may output (at  106 ), to each smart lighting fixture  101 , information indicating the identified consumption model and/or remedial action(s) associated with each respective smart lighting fixture  101 . Smart lighting fixtures  101  may monitor rates and/or amounts of power consumption, dimming curves, and/or other metrics based on the received consumption models. Based on the consumption models and/or actions, smart lighting fixture  101  may automatically perform (at  108 ) one or more remedial actions in situations where smart lighting fixture  101  identifies, based on the monitoring, that one or more anomalies and/or events have occurred. In some implementations, SFOS  103  may use the identified consumption model to detect anomalous conditions at fixture  101  from requested and/or periodic reporting by fixture  101  of its operational metrics. 
       FIG. 2  illustrates example components of smart lighting fixture  101 . As shown, smart lighting fixture  101  may include configurable fixture  201 , light output component  203 , interface  205 , and Fixture Optimization Component (“FOC”)  207 . Configurable fixture  201  may include and/or may receive power (e.g., electrical power) from an external source, such as a transformer, a solar panel, or the like. Configurable fixture  201  may provide power to light output component  203  and to FOC  207  (e.g., via interface  205 ). Light output component  203  may include one or more bulbs (e.g., LED bulbs, incandescent bulbs, fluorescent bulbs, etc.) or other light output components. In some embodiments, interface  205  and/or FOC  207  may include a controller, a relay, a dimmer, a switch, or some other suitable component to control (e.g., power on, power off, set brightness level, etc.) light output component  203 . For example, FOC  207  may (e.g., via interface  205 ) provide an instruction or indication of a given brightness level, and light output component  203  may increase or decrease an amount of voltage provided to a bulb, LED module, etc. of light output component  203  based on the indicated brightness level. 
     Interface  205  may include an interface that may receive control signals (e.g., to control the brightness level of light output component  203 , to perform dimmer operations with respect to light output component  203 , etc.) or other suitable types of information from FOC  207 . Further, in some embodiments, interface  205  may be or may include a physical interface, such as an American National Standards Institute (“ANSI”) C136.41 dimming receptacle and/or some other suitable type of physical interface via which FOC  207  can be communicatively coupled to light output component  203 . 
     FOC  207  may include wireless communication circuitry, such that FOC  207  may communicate wirelessly, via network  209 , with SFOS  103 . For example, network  209  may be, or may include, a radio access network (“RAN”) of a wireless network, such as a Long-Term Evolution (“LTE”) RAN, a Fifth Generation (“5G”) RAN, and/or some other suitable type of RAN. Additionally, or alternatively, FOC  207  may include wired communication circuitry to communicate with SFOS  103  via one or more wired networks (e.g., a wired portion of network  209 ). 
     In some embodiments, FOC  207  may include one or more sensors, such as an illuminance sensor, a microphone, a motion detection sensor, a pressure sensor, a particulate matter (e.g., PM2.5) sensor, a location detection component (e.g., Global Positioning System (“GPS”) circuitry), a thermometer, a barometer, and/or other suitable sensors and/or components. In the description herein, some or all of the operations discussed with respect to smart lighting fixture  101  may be performed by FOC  207 . In some embodiments, such operations may be performed by FOC  207  in conjunction with configurable fixture  201 , light output component  203 , and/or interface  205 . For example, when smart lighting fixture  101  is described herein as modifying a brightness level of smart lighting fixture  101 , such brightness level may be modified by FOC  207  outputting one or more suitable signals to or via interface  205 , in order to control a brightness level of light output component  203 . As another example, when smart lighting fixture  101  is described herein as determining a rate or amount of power consumption with respect to smart lighting fixture  101 , FOC  207  may determine such power consumption metrics based on an amount of power consumed by light output component  203  via interface  205 , and/or interface  205  may provide such power consumption metrics to FOC  207 . 
     FOC  207  may be configured to provide periodic reporting of its operations to SFOS  103  over network  209 . FOC  207  may also be configured to receive instructions from SFOS  103  over network  209  to perform various actions such as described above—adjust brightness levels, reduce power consumption—as well report its operational metrics, such as sensor readings (ambient temperature, light output component temperature, illuminance) and other status. FOC  207  may be configured to report its operational metrics as a “batch” or “aggregation” of metrics collected over time. For example, FOC  207  may collect measurements on a first periodic basis (e.g., a per-minute basis, a per-hour basis, or on some other basis), and report the collection of measurements on a second periodic basis (e.g., on a daily basis, every two days, or on some other basis) in a single reporting action. 
     As discussed above, smart lighting fixture  101  may perform an automatic calibration procedure, in order to assist in the generation of one or more consumption models, and/or to identify or categorize smart lighting fixture  101  based on one or more existing consumption models. In some implementations, the automatic calibration procedure may be triggered by SFOS  103 —for example, by sending an instruction to fixture  101  to perform the calibration procedure. For example, as shown in  FIG. 3A , smart lighting fixture  101  may set (at  302 ) a brightness level to a first brightness level (shown in the figure as x %, which may be 0%, 10%, 20%, or some other brightness level), and may measure an amount of power consumed over a given amount of time (e.g., in terms of Watt-hours or some other suitable unit), and/or may measure a rate of power consumption (e.g., in terms of Watts or some other suitable unit). For example, as mentioned above, FOC  207  may compute the consumption metrics based on signals received from interface  205 , and/or may receive the consumption metrics from interface  205 . In some embodiments, as also mentioned above, FOC  207  may determine one or more other attributes associated with smart lighting fixture  101  and/or other conditions corresponding to a time at which the consumption metrics were measured. For example, FOC  207  may determine an ambient temperature, an ambient audible sound level, an amount of RF interference or noise, a measure of detected motion, a temperature of light output component  203 , and/or other types of sensor data at the time corresponding to when the consumption metrics were measured. 
     Smart lighting fixture  101  may output (at  304 ) the consumption metrics, as well as the brightness level at which smart lighting fixture  101  was set when the consumption metrics were measured (i.e., x %, in this example), to SFOS  103 . In some embodiments, smart lighting fixture  101  may output some or all of the other sensor information measured at the time at which the consumption metrics were measured. In other embodiments, the measurements may be stored locally at the fixture  101 , and provided at a later time as part of a “batch” transmission of measurements. 
     Based on the received information, SFOS  103  may generate and/or refine (at  306 ) one or more consumption models. For example, SFOS  103  may identify whether any existing consumption models match the received consumption metrics. For example, SFOS  103  may identify whether consumption models exist for smart lighting fixtures  101  having the same or similar (e.g., within a threshold measure of similarity, using a suitable similarity or correlation analysis) attributes as smart lighting fixture  101 . In situations where SFOS  103  does not identify an existing matching consumption model, SFOS  103  may generate (at  306 ) a new consumption model for smart lighting fixture  101 , based on the attributes of smart lighting fixture  101  and the received consumption information (e.g., the rate and/or amount of consumption when smart lighting fixture  101  is set to a brightness level of x %). In situations where SFOS  103  identifies an existing matching consumption model, SFOS  103  may refine the existing consumption model based on the received consumption metrics. For example, SFOS  103  may aggregate the received consumption metrics with previously received consumption metrics associated with the matching consumption model. Such aggregation may include performing an averaging operation, generating one or more “best fit” lines or curves, performing a regression analysis, identifying and removing outliers, and/or other suitable operations. 
     Some or all of the operations shown in  FIG. 3A  may be performed repeatedly and/or iteratively, in order to identify consumption metrics at different brightness levels and/or when smart lighting fixture  101  experiences varying conditions (e.g., varying ambient temperatures, varying RF channel conditions, etc.). For example, as shown in  FIG. 3B , smart lighting fixture  101  may set (at  308 ) the brightness level of smart lighting fixture  101  to [x+y]%, which may be a different brightness level than shown in the example of  FIG. 3A . FOC  207  may determine or receive consumption metrics associated with smart lighting fixture  101  at this brightness level (as well as other suitable sensor data, as discussed above), and may output (at  310 ) the consumption metrics and sensor data, in some embodiments, to SFOS  103 . As similarly discussed above, SFOS  103  may generate and/or refine (at  312 ) one or more consumption models based on the received consumption metrics. 
     In some embodiments, similar operations as shown above with respect to  FIGS. 3A and 3B  may be iteratively performed multiple times (e.g., brightness level set to [x+2*y]%, [x+3*y]%, [x+4*y]%, and so on), in order to generate or determine a dimming curve associated with smart lighting fixture  101 . As one example, smart lighting fixture  101  may set the brightness level to 0%, then 10%, then 20%, then 30%, and so on, and measure rates and/or amounts of consumption at each of these brightness levels. As another example, smart lighting fixture  101  may gradually or continuously increase or decrease brightness levels, and may measure rates and/or amounts of consumption at varying brightness levels (e.g., on a sliding scale). In some embodiments, similar operations as shown above with respect to  FIGS. 3A and 3B  may be performed at the same brightness level, but with differing conditions (e.g., different ambient temperature, different temperature of light output component  203 , different time of day, etc.), and one or more consumption models may be generated or refined based on the additional consumption metrics. In this manner, SFOS  103  may be able to generate consumption models that model consumption at varying conditions, and/or may be able to generate multi-dimensional consumption models (e.g., as noted above). 
       FIGS. 4-6  illustrate example data structures that may correspond to particular consumption models generated, maintained, refined, etc. by SFOS  103 . For example, data structure  400  indicates rates of consumption by different fixture types at different brightness levels. That is, data structure  400  may indicate dimming curves on the basis of different fixture types, shown as example types “Fixture_A,” “Fixture_B,” and “Fixture_C.” As noted above, the different “types” may correspond to different makes and/or models of fixtures, different power output ratings of bulbs associated with such fixtures, and/or other differentiating attributes of fixtures. The values reflected in data structure  400  may be aggregated values based on values collected from multiple fixtures over time. For example, the aggregated values may be averages, means, and/or other computed values derived from raw consumption metrics. In some embodiments, the aggregated values may be generated by eliminating outliers (e.g., where outlier data may be received from malfunctioning fixtures), determining one or more “best fit” curves, and/or other suitable operations to determine the appropriate rates of consumption at varying brightness levels on a per-fixture basis. 
     While shown in the figure as single values (e.g., 0.2 W at a 0% brightness level for Fixture_A), the values in data structure  400  may in some embodiments include one or more ranges, probability curves, and/or other sets of values. For example, in practice, the values for Fixture_A at the 0% brightness level may be 0.1 W-0.2 W or some other range of values. 
       FIG. 5  illustrates an example multi-dimensional data structure  500  in accordance with some embodiments. Data structure  500  may, for example, reflect dimming curves for multiple fixture types under multiple different conditions (e.g., in different ambient temperature ranges). As shown, each example temperature range (e.g., 0-10 degrees, 11-20 degrees, etc.) may be associated with a particular instance of data structure  400 . For example, the temperature range of 0-10 degrees may be associated with a first instance  400 - 1  of data structure  400 . Thus, data structure  500  may include dimming curves for Fixture_A, Fixture_B, and Fixture_C (e.g., instance  400 - 1  of data structure  400 ) measured in ambient temperatures (e.g., as measured by respective FOCs  207  or by respective suitable devices communicatively coupled FOCs  207 ) between 0 and 10 degrees Celsius. As further shown, data structure  500  may include instance  400 - 2  of data structure  400  for another range of ambient temperatures (e.g., 11-20 degrees Celsius). Thus, data structure  500  may also include dimming curves for Fixture_A, Fixture_B, and Fixture_C (e.g., instance  400 - 2  of data structure  400 ) measured in ambient temperatures between 11 and 20 degrees Celsius. Similarly, data structure  500  may include dimming curves for these fixtures measured in ambient temperatures between 21-30 degrees Celsius, 31-40 degrees Celsius (e.g., instances  400 - 3  and  400 - 4  of data structure  400 , respectively), and so on. 
     While  FIG. 5  uses ambient temperature as an example, in practice, other types of conditions may be reflected in data structure  500  (or some other suitable data structure). For example, dimming curves for different fixtures may be reflected on a temporal basis (e.g., at different times of the day, different days of the week, etc.). As another example, dimming curves for different fixtures may be indicated based on RF metrics determined by respective FOCs  207  (e.g., Signal-to-Interference-and-Noise-Ratio (“SINR”) values, Reference Signal Received Power (“RSRP”) values, antenna received power values, and/or other RF metrics). In some embodiments, dimming curves for different fixtures may be indicated based on RF configuration parameters associated with respective FOCs  207  (e.g., power save mode, radio access technology (“RAT”), quantity of antennas, Multiple-Input Multiple-Output (“MIMO”) configuration parameters, and/or other RF configuration parameters). As yet another example, dimming curves for different fixtures may be indicated based on atmospheric pressure levels, altitude, location, ambient sound levels, ambient light levels, and/or other conditions. 
       FIG. 6  illustrates a further example of multi-dimensional modeling based on which one or more consumption models may be generated, in accordance with some embodiments. For example, data structure  600  may indicate dimming curves based on warm-up status. Fixtures may, for example, be associated with a “warm-up” procedure and/or a “warm-up” time. The warming up of a particular smart lighting fixture  101  may refer to the powering up of smart lighting fixture  101  from a “cold” status, such as the first time that smart lighting fixture  101  is powered up after having been powered off for at least a threshold amount of time (e.g., one hour, six hours, etc.). Generally, the dimming curves for various smart lighting fixtures  101  at different times in relation to the warm-up procedure (e.g., during warm-up or after warm-up) may be different. Further, the dimming curves for various smart lighting fixtures  101 , in different ambient temperatures (or other conditions) at different times in relation to the warm-up procedure (e.g., during warm-up or after warm-up) may be different. Thus, for example, a first instance  500 - 1  of data structure  500  may reflect dimming curves, on a per-temperature (and/or other conditions) and per-fixture basis while such fixtures are undergoing a warm-up procedure, while a second instance  500 - 2  of data structure  500  may reflect dimming curves, on a per-temperature and per-fixture basis after such fixtures have completed a warm-up procedure. 
     As mentioned above, consumption models (e.g., which may include and/or be based on data structures  400 ,  500 ,  600 , and/or other suitable information) may be used to identify particular fixtures or fixture types, and respective FOCs  207  may be able to be configured based on appropriate dimming curves (e.g., to detect anomalies or other events based on consumption models for the identified fixture types). For example, as shown in  FIG. 7 , smart lighting fixture  101  (e.g., FOC  207 ) may set (at  702 ) multiple brightness levels for smart lighting fixture  101 , and may measure rates and/or amounts of consumption at such brightness levels. In some embodiments, smart lighting fixture  101  (e.g., FOC  207 ) may further measure one or more other conditions (e.g., ambient temperature, ambient light, RF metrics, warm-up status, etc.), as discussed above. Smart lighting fixture  101  (e.g., FOC  207 ) may further output (at  704 ) the measured rates and/or amounts of consumption at respective brightness levels, along with any other suitable information (e.g., ambient temperature, ambient light, etc.) to SFOS  103 . 
     SFOS  103  may identify (at  706 ) a fixture type associated with smart lighting fixture  101  based on the received information. For example, SFOS  103  may compare the received information to one or more consumption models and may perform a suitable similarity or correlation analysis to identify a particular consumption model that matches the received information. For example, SFOS  103  may identify one or more dimming curves that match (e.g., exactly match, and/or have a measure of similarity that exceeds a threshold measure of similarity) a dimming curve reflected by the information received (at  704 ) from smart lighting fixture  101 . In some embodiments, as noted above, the dimming curve associated with the identified consumption model may include a range of values at one or more brightness levels, where such ranges may indicate “acceptable” or “normal” consumption at such brightness levels. As noted above, particular consumption models may be associated with particular remedial actions, which may be identified using AI/ML techniques or other suitable techniques. SFOS  103  may further identify such actions when identifying a consumption model for smart lighting fixture  101  based on received (at  704 ) consumption information from smart lighting fixture  101 . 
     In some embodiments, SFOS  103  may output (at  708 ) configuration information for smart lighting fixture  101  based on an identified fixture type and/or consumption model for smart lighting fixture  101 . For example, such configuration information may include one or more dimming curves associated with smart lighting fixture  101  (e.g., multi-dimensional dimming curves, dimming curves for different conditions, etc.). That is, while smart lighting fixture  101  may measure (at  702 ) consumption amounts or rates under one set of conditions (e.g., with a particular ambient temperature, during a particular time of day, etc.), the configuration information may include consumption models for the same fixture type, but under different conditions (e.g., different ambient temperatures, during different times of day, etc.). In some implementations, the consumption model may be output to fixture  101  for use in monitoring the performance of fixture  101 . 
     As shown in  FIG. 8 , for example, smart lighting fixture  101  may detect (at  802 ) an anomalous level (e.g., rate and/or amount of consumption) associated with smart lighting fixture  101  based on the received configuration information. As one example, smart lighting fixture  101  may detect that smart lighting fixture  101  is consuming a greater or lesser rate or amount of power than an expected rate or amount (e.g., where the “expected” rate or amount is based on values associated with a respective consumption model associated with smart lighting fixture  101 ). In some embodiments, the anomalous consumption (at  802 ) may be detected under different conditions (e.g., different ambient temperature conditions, different ambient light conditions, etc.) than consumption metrics measured by smart lighting fixture  101  (e.g., at  702 ). In this manner, the consumption models determined (e.g., at  706 ) may be used in a predictive manner, in order to identify dimming curves for smart lighting fixture  101  in conditions that differ from conditions in which smart lighting fixture  101  measured consumption metrics during an identification process (e.g., at  702 ). 
     Based on detecting (at  802 ) an anomalous condition, smart lighting fixture  101  (e.g., FOC  207 ) may output (at  804 ) an alert to SFOS  103  and/or some other device or system. The alert may indicate, for example, that smart lighting fixture  101  is consuming more power or less power than an “expected” consumption rate or amount. In some embodiments, the alert may indicate how far above or below the expected consumption is being measured by smart lighting fixture  101 . In some embodiments, the alert may indicate other information, such as an ambient temperature at the time the anomalous consumption was detected (at  802 ), an ambient light level at such time, and/or other suitable information (e.g., as measured or detected by one or more sensors or other devices or systems associated with smart lighting fixture  101 ). 
     In some embodiments, smart lighting fixture  101  may modify (at  806 ) one or more configuration parameters associated with smart lighting fixture  101  based on the detected anomalous consumption. In some embodiments, such modifications may be indicated by SFOS  103  (e.g., at  708 ). For example, smart lighting fixture  101  may modify a brightness level associated with smart lighting fixture  101  based on the detected anomalous consumption, such as by increasing or decreasing the brightness level. For example, in scenarios where smart lighting fixture  101  measures a greater consumption rate than expected for a given brightness level, smart lighting fixture  101  may reduce the brightness level. In some embodiments, smart lighting fixture  101  may identify the expected consumption rate for the brightness level associated with the anomalous consumption (e.g., as indicated by one or more consumption models), and may modify (at  806 ) the brightness level such that the actual consumption rate (after the modification at  806 ) matches (e.g., exactly matches, or matches within a threshold margin) the expected consumption rate. 
     In some embodiments, anomalous consumption may be detected and/or remediated via one or more other suitable techniques (e.g., in addition to or in lieu of the example techniques described above with respect to  FIGS. 8 and 9 ). For example, in some embodiments, SFOS  103  may monitor (e.g., from smart lighting fixture  101 , from FOC  207 , and/or one or more other devices or systems) consumption metrics associated with smart lighting fixture  101  on a periodic basis, an intermittent basis, and/or some other basis. For example, in some embodiments, smart lighting fixture  101  (e.g., FOC  207 ) may “push” consumption metrics to smart lighting fixture  101  every minute, every hour, and/or on some other basis. For example, as noted above, such consumption metrics may be sent as a “batch” or as aggregated information. Additionally, or alternatively, SFOS  103  may “pull” (e.g., request, poll, etc.) consumption metrics from smart lighting fixture  101  on a periodic basis, an intermittent basis, and/or some other basis. SFOS  103  may, based on the monitored consumption metrics (e.g., as “pushed” or “pulled” from smart lighting fixture  101  and/or FOC  207 ) detect anomalous consumption associated with smart lighting fixture  101 , may determine an appropriate action to remediate such anomalous consumption (e.g., modifying a brightness level, cutting power to light output component  203 , etc.), and may instruct smart lighting fixture  101  (e.g., FOC  207 ) to implement such action. 
     In some implementations, when anomalous consumption is detected, SFOS  103  may compare the consumption metrics to other stored consumption models, and may determine that a different consumption model is a better fit (e.g., more closely matches, has a higher measure of similarity or correlation, etc.) than the consumption model currently associated with smart lighting fixture  101 . For example, the SFOS  103  may output an alert regarding the anomalous consumption, where such alert includes an indication that the consumption metrics more closely fit a consumption model associated with a different type of smart lighting fixture  101 . 
     For example, a user may have provided information (e.g., via a configuration process, a calibration process, an installation process, etc.) that indicates that smart lighting fixture  101  is a first type (e.g., a first make and/or model), and SFOS  103  may evaluate consumption metrics associated with smart lighting fixture  101  based on a particular consumption model associated with the first type (e.g., the first make and/or model). In some scenarios, SFOS  103  may determine that the consumption metrics associated with smart lighting fixture  101  more closely match a consumption model associated with a second type (e.g., a different second make and/or model), and may output an alert, prompt, or other message indicating the second type (e.g., the second make and/or model). SFOS  103  may receive an indication confirming that smart lighting fixture  101  is the second type (e.g., not the first type, as previously indicated), and may evaluate smart lighting fixture  101  based on a consumption model associated with the second type, in lieu of evaluating smart lighting fixture  101  based on the consumption model associated with the first type. In this manner, misclassification of smart lighting fixtures  101  (e.g., based on erroneous user input or other potential errors) may be remediated in an automated fashion. 
       FIG. 9  illustrates an example process  900  for generating, refining, utilizing, etc. consumption models and using such models to detect and remediate anomalous consumption with respect to one or more smart lighting fixtures  101 . In some embodiments, some or all of process  900  may be performed by SFOS  103 . In some embodiments, one or more other devices may perform some or all of process  900  in concert with, and/or in lieu of, SFOS  103  (e.g., FOC  207 ). 
     As shown, process  900  may include determining (at  902 ) respective power consumption metrics associated with a particular smart lighting fixture  101 . For example, SFOS  103  may receive, from a particular smart lighting fixture  101  (e.g., from FOC  207 ) power consumption metrics (e.g., rates and/or amounts of power consumption) associated with smart lighting fixture  101 . For example, as discussed above, FOC  207  may set (e.g., via interface  205 ) a brightness level associated with configurable fixture  201  to affect the amount of power provided to (e.g., by way of performing a “dimming” operation) light output component  203 , which may affect the power output of smart lighting fixture  101  (e.g., amount or rate of power consumed by light output component  203 ). FOC  207  may determine the power consumption associated with smart lighting fixture  101  (e.g., the power consumed by light output component  203 ) at varying brightness levels. 
     Process  900  may further include generating, refining, and/or selecting (at  904 ) one or more power consumption models based on the power consumption metrics. For example, as discussed above, SFOS  103  may identify a previously generated power consumption model based on the received power consumption metrics. For example, SFOS  103  may identify a “matching” power consumption model, where such “match” may be determined based on a suitable similarity or correlation analysis of attributes of the power consumption metrics and attributes of the consumption models, as discussed above. 
     Process  900  may additionally include monitoring (at  906 ) power consumption metrics associated with smart lighting fixture  101 . For example, FOC  207  may monitor the metrics based on the selected model, and/or may provide such metrics to SFOS  103 . FOC  207  and/or SFOS  103  may compare the received metrics (e.g., on an ongoing basis or some other basis) to the selected consumption model. As noted above, a given consumption model may include different dimming curves or other information for varying attributes or conditions, such as different ambient temperatures, ambient lighting conditions, etc. 
     Process  900  may also include determining (at  908 ) anomalous power consumption associated with smart lighting fixture  101  based on the consumption metrics and the consumption model. For example, FOC  207  and/or SFOS  103  may determine a mismatch between the monitored consumption metrics and expected consumption metrics (e.g., where “expected” consumption metrics may correspond to metrics associated with the same fixture type, conditions, etc. associated with smart lighting fixture  101 ). A “mismatch” may refer to the monitored consumption metrics falling outside of a range of expected consumption metrics for a given scenario (e.g., for a given brightness level, in given ambient conditions, etc.), and/or deviating from an expected value by at least a threshold amount (e.g., 25% outside expected values, 50% outside expected values, etc.). 
     Process  900  may further include identifying (at  910 ) a remedial measure based on the determined anomalous consumption. For example, as discussed above, the consumption model may be associated with one or more remedial actions, which may have been determined using analytical techniques or other suitable techniques. Such remedial actions may include cutting power to light output component  203 , throttling power to light output component  203  (e.g., reducing a brightness level associated with smart lighting fixture  101 ), increasing power to light output component  203  (e.g., increasing a brightness level associated with smart lighting fixture  101 ), outputting an alert to/from SFOS  103  and/or some other device or system, or other suitable actions. 
     Process  900  may additionally include automatically performing (at  912 ) the remedial action. For example, FOC  207  may modify (e.g., via interface  205 ) a brightness level associated with light output component  203 , output an alert to/from SFOS  103 , and/or automatically perform some other remedial measure. 
       FIG. 10  illustrates an example environment  1000 , in which one or more embodiments may be implemented. In some embodiments, environment  1000  may correspond to a Fifth Generation (“5G”) network, and/or may include elements of a 5G network. In some embodiments, environment  1000  may 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, environment  1000  may include smart lighting fixture  101  (which may include and/or may be communicatively coupled to FOC  207 , such as via interface  205  or some other suitable interface), RAN  1010  (which may include one or more Next Generation Node Bs (“gNBs”)  1011 ), RAN  1012  (which may include one or more one or more evolved Node Bs (“eNBs”)  1013 ), and various network functions such as Access and Mobility Management Function (“AMF”)  1015 , Mobility Management Entity (“MME”)  1016 , Serving Gateway (“SGW”)  1017 , Session Management Function (“SMF”)/Packet Data Network (“PDN”) Gateway (“PGW”)-Control plane function (“PGW-C”)  1020 , Policy Control Function (“PCF”)/Policy Charging and Rules Function (“PCRF”)  1025 , Application Function (“AF”)  1030 , User Plane Function (“UPF”)/PGW-User plane function (“PGW-U”)  1035 , Home Subscriber Server (“HSS”)/Unified Data Management (“UDM”)  1040 , and Authentication Server Function (“AUSF”)  1045 . Environment  1000  may also include one or more networks, such as Data Network (“DN”)  1050 . In some embodiments, network  205  may include DN  1050 , may be included in DN  1050 , and/or may be communicatively coupled to DN  1050 . Environment  1000  may include one or more additional devices or systems communicatively coupled to one or more networks (e.g., DN  1050 ), such as SFOS  103 . 
     The example shown in  FIG. 10  illustrates one instance of each network component or function (e.g., one instance of SMF/PGW-C  1020 , PCF/PCRF  1025 , UPF/PGW-U  1035 , HSS/UDM  1040 , and/or  1045 ). In practice, environment  1000  may include multiple instances of such components or functions. For example, in some embodiments, environment  1000  may 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-C  1020 , PCF/PCRF  1025 , UPF/PGW-U  1035 , HSS/UDM  1040 , and/or  1045 , while another slice may include a second instance of SMF/PGW-C  1020 , PCF/PCRF  1025 , UPF/PGW-U  1035 , HSS/UDM  1040 , and/or  1045 ). 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 in  FIG. 10 , is provided for explanatory purposes only. In practice, environment  1000  may 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 in  FIG. 10 . For example, while not shown, environment  1000  may include devices that facilitate or enable communication between various components shown in environment  1000 , such as routers, modems, gateways, switches, hubs, etc. Alternatively, or additionally, one or more of the devices of environment  1000  may perform one or more network functions described as being performed by another one or more of the devices of environment  1000 . Devices of environment  1000  may 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 environment  1000  may be physically integrated in, and/or may be physically attached to, one or more other devices of environment  1000 . 
     FOC  207  may include a computation and communication device, such as a wireless communication device that is capable of communicating with RAN  1010 , RAN  1012 , and/or DN  1050 . In some embodiments, FOC  207  may be, or may include, a User Equipment (“UE”) associated with a wireless network. In some embodiments, FOC  207  may be, may include, and/or may be communicatively coupled to 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 Mobile-to-Mobile (“M2M”) device, or another type of mobile computation and communication device. FOC  207  may send traffic to and/or receive traffic (e.g., user plane traffic) from DN  1050  via RAN  1010 , RAN  1012 , and/or UPF/PGW-U  1035 . 
     RAN  1010  may be, or may include, a 5G RAN that includes one or more base stations (e.g., one or more gNBs  1011 ), via which FOC  207  may communicate with one or more other elements of environment  1000 . FOC  207  may communicate with RAN  1010  via an air interface (e.g., as provided by gNB  1011 ). For instance, RAN  1010  may receive traffic (e.g., voice call traffic, data traffic, messaging traffic, signaling traffic, etc.) from FOC  207  via the air interface, and may communicate the traffic to UPF/PGW-U  1035 , and/or one or more other devices or networks. Similarly, RAN  1010  may receive traffic intended for FOC  207  (e.g., from UPF/PGW-U  1035 , AMF  1015 , and/or one or more other devices or networks) and may communicate the traffic to FOC  207  via the air interface. 
     RAN  1012  may be, or may include, a LTE RAN that includes one or more base stations (e.g., one or more eNBs  1013 ), via which FOC  207  may communicate with one or more other elements of environment  1000 . FOC  207  may communicate with RAN  1012  via an air interface (e.g., as provided by eNB  1013 ). For instance, RAN  1010  may receive traffic (e.g., voice call traffic, data traffic, messaging traffic, signaling traffic, etc.) from FOC  207  via the air interface, and may communicate the traffic to UPF/PGW-U  1035 , and/or one or more other devices or networks. Similarly, RAN  1010  may receive traffic intended for FOC  207  (e.g., from UPF/PGW-U  1035 , SGW  1017 , and/or one or more other devices or networks) and may communicate the traffic to FOC  207  via the air interface. 
     AMF  1015  may include one or more devices, systems, Virtualized Network Functions (“VNFs”), etc., that perform operations to register FOC  207  with the 5G network, to establish bearer channels associated with a session with FOC  207 , to hand off FOC  207  from the 5G network to another network, to hand off FOC  207  from the other network to the 5G network, manage mobility of FOC  207  between RANs  1010  and/or gNBs  1011 , and/or to perform other operations. In some embodiments, the 5G network may include multiple AMFs  1015 , which communicate with each other via the N14 interface (denoted in  FIG. 10  by the line marked “N14” originating and terminating at AMF  1015 ). 
     MME  1016  may include one or more devices, systems, VNFs, etc., that perform operations to register FOC  207  with the EPC, to establish bearer channels associated with a session with FOC  207 , to hand off FOC  207  from the EPC to another network, to hand off FOC  207  from another network to the EPC, manage mobility of FOC  207  between RANs  1012  and/or eNBs  1013 , and/or to perform other operations. 
     SGW  1017  may include one or more devices, systems, VNFs, etc., that aggregate traffic received from one or more eNBs  1013  and send the aggregated traffic to an external network or device via UPF/PGW-U  1035 . Additionally, SGW  1017  may aggregate traffic received from one or more UPF/PGW-Us  1035  and may send the aggregated traffic to one or more eNBs  1013 . SGW  1017  may 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., RANs  1010  and  1012 ). 
     SMF/PGW-C  1020  may include one or more devices, systems, VNFs, etc., that gather, process, store, and/or provide information in a manner described herein. SMF/PGW-C  1020  may, for example, facilitate in the establishment of communication sessions on behalf of FOC  207 . In some embodiments, the establishment of communications sessions may be performed in accordance with one or more policies provided by PCF/PCRF  1025 . 
     PCF/PCRF  1025  may include one or more devices, systems, VNFs, etc., that aggregate information to and from the 5G network and/or other sources. PCF/PCRF  1025  may 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/PCRF  1025 ). 
     AF  1030  may 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-U  1035  may include one or more devices, systems, VNFs, etc., that receive, store, and/or provide data (e.g., user plane data). For example, UPF/PGW-U  1035  may receive user plane data (e.g., voice call traffic, data traffic, etc.), destined for FOC  207 , from DN  1050 , and may forward the user plane data toward FOC  207  (e.g., via RAN  1010 , SMF/PGW-C  1020 , and/or one or more other devices). In some embodiments, multiple UPFs  1035  may be deployed (e.g., in different geographical locations), and the delivery of content to FOC  207  may be coordinated via the N9 interface (e.g., as denoted in  FIG. 10  by the line marked “N9” originating and terminating at UPF/PGW-U  1035 ). Similarly, UPF/PGW-U  1035  may receive traffic from FOC  207  (e.g., via RAN  1010 , SMF/PGW-C  1020 , and/or one or more other devices), and may forward the traffic toward DN  1050 . In some embodiments, UPF/PGW-U  1035  may communicate (e.g., via the N4 interface) with SMF/PGW-C  1020 , regarding user plane data processed by UPF/PGW-U  1035 . 
     HSS/UDM  1040  and AUSF  1045  may include one or more devices, systems, VNFs, etc., that manage, update, and/or store, in one or more memory devices associated with AUSF  1045  and/or HSS/UDM  1040 , profile information associated with a subscriber. AUSF  1045  and/or HSS/UDM  1040  may perform authentication, authorization, and/or accounting operations associated with the subscriber and/or a communication session with FOC  207 . 
     DN  1050  may include one or more wired and/or wireless networks. For example, DN  1050  may 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. FOC  207  may communicate, through DN  1050 , with data servers, other FOCs  207 , and/or to other servers or applications that are coupled to DN  1050 . DN  1050  may 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. DN  1050  may be connected to one or more devices, such as content providers, applications, web servers, and/or other devices, with which FOC  207  may communicate. 
     SFOS  103  may include one or more devices, systems, VNFs, etc., that perform one or more operations described herein. For example, FOC  207  may generate, modify, and/or provide consumption models associated with smart lighting fixtures  101  (e.g., based on consumption metrics received from one or more FOCs  207 ). SFOS  103  may further provide such models and/or information derived from such models to FOCs  207  (e.g., via RAN  1010 , RAN  1012 , DN  1050 , and/or via some other network), such that FOCs  207  may monitor consumption metrics associated with respective smart lighting fixtures  101  and perform remedial actions when anomalous power consumption is detected. 
       FIG. 11  illustrates an example Distributed Unit (“DU”) network  1100 , which may be included in and/or implemented by one or more RANs (e.g., RAN  1010 , RAN  1012 , or some other RAN). In some embodiments, a particular RAN may include one DU network  1100 . In some embodiments, a particular RAN may include multiple DU networks  1100 . In some embodiments, DU network  1100  may correspond to a particular gNB  1011  of a 5G RAN (e.g., RAN  1010 ). In some embodiments, DU network  1100  may correspond to multiple gNBs  1011 . In some embodiments, DU network  1100  may correspond to one or more other types of base stations of one or more other types of RANs. As shown, DU network  1100  may include Central Unit (“CU”)  1105 , one or more Distributed Units (“DUs”)  1103 - 1  through  1103 -N (referred to individually as “DU  1103 ,” or collectively as “DUs  1103 ”), and one or more Radio Units (“RUs”)  1101 - 1  through  1101 -M (referred to individually as “RU  1101 ,” or collectively as “RUs  1101 ”). 
     CU  1105  may 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 to  FIG. 10 , such as AMF  1015  and/or UPF/PGW-U  1035 ). In the uplink direction (e.g., for traffic from FOCs  207  to a core network), CU  1105  may aggregate traffic from DUs  1103 , and forward the aggregated traffic to the core network. In some embodiments, CU  1105  may receive traffic according to a given protocol (e.g., Radio Link Control (“RLC”)) from DUs  1103 , 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 DUs  1103 . 
     In accordance with some embodiments, CU  1105  may receive downlink traffic (e.g., traffic from the core network) for a particular FOC  207 , and may determine which DU(s)  1103  should receive the downlink traffic. DU  1103  may include one or more devices that transmit traffic between a core network (e.g., via CU  1105 ) and FOC  207  (e.g., via a respective RU  1101 ). DU  1103  may, for example, receive traffic from RU  1101  at 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). DU  1103  may receive traffic from CU  1105  at the second layer, may process the traffic to the first layer, and provide the processed traffic to a respective RU  1101  for transmission to FOC  207 . 
     RU  1101  may 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 FOCs  207 , one or more other DUs  1103  (e.g., via RUs  1101  associated with DUs  1103 ), and/or any other suitable type of device. In the uplink direction, RU  1101  may receive traffic from FOC  207  and/or another DU  1103  via the RF interface and may provide the traffic to DU  1103 . In the downlink direction, RU  1101  may receive traffic from DU  1103 , and may provide the traffic to FOC  207  and/or another DU  1103 . 
     RUs  1101  may, in some embodiments, be communicatively coupled to one or more Multi-Access/Mobile Edge Computing (“MEC”) devices, referred to sometimes herein simply as (“MECs”)  1107 . For example, RU  1101 - 1  may be communicatively coupled to MEC  1107 - 1 , RU  1101 -M may be communicatively coupled to MEC  1107 -M, DU  1103 - 1  may be communicatively coupled to MEC  1107 - 2 , DU  1103 -N may be communicatively coupled to MEC  1107 -N, CU  1105  may be communicatively coupled to MEC  1107 - 3 , and so on. MECs  1107  may 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 FOC  207 , via a respective RU  1101 . 
     For example, RU  1101 - 1  may route some traffic, from FOC  207 , to MEC  1107 - 1  instead of to a core network (e.g., via DU  1103  and CU  1105 ). MEC  1107 - 1  may process the traffic, perform one or more computations based on the received traffic, and may provide traffic to FOC  207  via RU  1101 - 1 . In this manner, ultra-low latency services may be provided to FOC  207 , as traffic does not need to traverse DU  1103 , CU  1105 , and an intervening backhaul network between DU network  1100  and the core network. In some embodiments, MEC  1107  may include, and/or may implement, some or all of the functionality described above with respect to SFOS  103  and/or FOC  207 . 
       FIG. 12  illustrates example components of device  1200 . One or more of the devices described above may include one or more devices  1200 . Device  1200  may include bus  1210 , processor  1220 , memory  1230 , input component  1240 , output component  1250 , and communication interface  1260 . In another implementation, device  1200  may include additional, fewer, different, or differently arranged components. 
     Bus  1210  may include one or more communication paths that permit communication among the components of device  1200 . Processor  1220  may include a processor, microprocessor, or processing logic that may interpret and execute instructions. Memory  1230  may include any type of dynamic storage device that may store information and instructions for execution by processor  1220 , and/or any type of non-volatile storage device that may store information for use by processor  1220 . 
     Input component  1240  may include a mechanism that permits an operator to input information to device  1200  and/or other receives or detects input from a source external to  1240 , 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 component  1240  may 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 component  1250  may include a mechanism that outputs information to the operator, such as a display, a speaker, one or more light emitting diodes (“LEDs”), etc. 
     Communication interface  1260  may include any transceiver-like mechanism that enables device  1200  to communicate with other devices and/or systems. For example, communication interface  1260  may include an Ethernet interface, an optical interface, a coaxial interface, or the like. Communication interface  1260  may 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, device  1200  may include more than one communication interface  1260 . For instance, device  1200  may include an optical interface and an Ethernet interface. 
     Device  1200  may perform certain operations relating to one or more processes described above. Device  1200  may perform these operations in response to processor  1220  executing software instructions stored in a computer-readable medium, such as memory  1230 . A computer-readable medium may be defined as a non-transitory memory device. A memory device may include space within a single physical memory device or spread across multiple physical memory devices. The software instructions may be read into memory  1230  from another computer-readable medium or from another device. The software instructions stored in memory  1230  may cause processor  1220  to perform processes described herein. Alternatively, hardwired circuitry may be used in place of or in combination with software instructions to implement processes described herein. Thus, implementations described herein are not limited to any specific combination of hardware circuitry and software. 
     The foregoing description of implementations provides illustration and description, but is not intended to be exhaustive or to limit the possible implementations to the precise form disclosed. Modifications and variations are possible in light of the above disclosure or may be acquired from practice of the implementations. 
     For example, while series of blocks and/or signals have been described above (e.g., with regard to  FIGS. 1-9 ), the order of the blocks and/or signals may be modified in other implementations. Further, non-dependent blocks and/or signals may be performed in parallel. Additionally, while the figures have been described in the context of particular devices performing particular acts, in practice, one or more other devices may perform some or all of these acts in lieu of, or in addition to, the above-mentioned devices. 
     The actual software code or specialized control hardware used to implement an embodiment is not limiting of the embodiment. Thus, the operation and behavior of the embodiment has been described without reference to the specific software code, it being understood that software and control hardware may be designed based on the description herein. 
     In the preceding specification, various example embodiments have been described with reference to the accompanying drawings. It will, however, be evident that various modifications and changes may be made thereto, and additional embodiments may be implemented, without departing from the broader scope of the invention as set forth in the claims that follow. The specification and drawings are accordingly to be regarded in an illustrative rather than restrictive sense. 
     Even though particular combinations of features are recited in the claims and/or disclosed in the specification, these combinations are not intended to limit the disclosure of the possible implementations. In fact, many of these features may be combined in ways not specifically recited in the claims and/or disclosed in the specification. Although each dependent claim listed below may directly depend on only one other claim, the disclosure of the possible implementations includes each dependent claim in combination with every other claim in the claim set. 
     Further, while certain connections or devices are shown, in practice, additional, fewer, or different, connections or devices may be used. Furthermore, while various devices and networks are shown separately, in practice, the functionality of multiple devices may be performed by a single device, or the functionality of one device may be performed by multiple devices. Further, multiple ones of the illustrated networks may be included in a single network, or a particular network may include multiple networks. Further, while some devices are shown as communicating with a network, some such devices may be incorporated, in whole or in part, as a part of the network. 
     To the extent the aforementioned implementations collect, store, or employ personal information of individuals, groups or other entities, it should be understood that such information shall be used in accordance with all applicable laws concerning protection of personal information. Additionally, the collection, storage, and use of such information can be subject to consent of the individual to such activity, for example, through well known “opt-in” or “opt-out” processes as can be appropriate for the situation and type of information. Storage and use of personal information can be in an appropriately secure manner reflective of the type of information, for example, through various access control, encryption and anonymization techniques for particularly sensitive information. 
     No element, act, or instruction used in the present application should be construed as critical or essential unless explicitly described as such. An instance of the use of the term “and,” as used herein, does not necessarily preclude the interpretation that the phrase “and/or” was intended in that instance. Similarly, an instance of the use of the term “or,” as used herein, does not necessarily preclude the interpretation that the phrase “and/or” was intended in that instance. Also, as used herein, the article “a” is intended to include one or more items, and may be used interchangeably with the phrase “one or more.” Where only one item is intended, the terms “one,” “single,” “only,” or similar language is used. Further, the phrase “based on” is intended to mean “based, at least in part, on” unless explicitly stated otherwise.