Patent Publication Number: US-11644829-B2

Title: Remote provisioning of a drone resource

Description:
RELATED APPLICATIONS 
     The subject application is a continuation of, and claims priority to each of, U.S. patent application Ser. No. 16/177,270 (now U.S. Pat. No. 11,144,048), filed 31 Oct. 2018, and entitled “REMOTE PROVISIONING OF A DRONE RESOURCE,” which is a continuation of, and claims priority to, U.S. patent application Ser. No. 14/732,626 (now U.S. Pat. No. 10,162,351), filed 5 Jun. 2015, and entitled “REMOTE PROVISIONING OF A DRONE RESOURCE,” the entireties of which applications are hereby incorporated by reference herein. 
    
    
     TECHNICAL FIELD 
     The disclosed subject matter relates to remotely controlled vehicles, including land, air, water, and space vehicles, e.g., drones for terrestrial, aerial, aquatic, or space use. 
     BACKGROUND 
     By way of brief background, conventional remotely controlled land, air, water, or space vehicles, often referred to as drones or unmanned aerial vehicles (UAVs), generally employ remote control operation and/or remote activation of vehicular self-control, e.g., autopilot, self-organized motion, self-implemented missions, etc. As an example, a consumer drone product, such as a quad-copter, can be operated via a remote control device. As another example, a military drone, such as a predator, global hawk, etc., can be operated from a control center located remotely from the drone and can include instructions that direct the drone to operate in an autonomous or semi-autonomous mode, such as self-guided flight between designated way points. As drones, for land, sea, air, and/or space operation, become more ubiquitous, intelligent allocation of drone resources can become increasingly significant. 
    
    
     
       BRIEF DESCRIPTION OF DRAWINGS 
         FIG.  1    is an illustration of an example system that facilitates remote provisioning of drone resources in accordance with aspects of the subject disclosure. 
         FIG.  2    is a depiction of an example system that facilitates remote provisioning of drone resources via a remotely located drone allocation component in accordance with aspects of the subject disclosure. 
         FIG.  3    illustrates an example system that facilitates remote provisioning of drone resources via a locally located drone allocation component in accordance with aspects of the subject disclosure. 
         FIG.  4    illustrates an example system that facilitates remote provisioning of drone resources organized in a tiered environment in accordance with aspects of the subject disclosure. 
         FIG.  5    illustrates an example system facilitating remote provisioning of drone resources based on user-centric information components in accordance with aspects of the subject disclosure. 
         FIG.  6    illustrates an example method facilitating remote provisioning of drone resources in accordance with aspects of the subject disclosure. 
         FIG.  7    depicts an example method facilitating remote provisioning of drone resources based on drone information in accordance with aspects of the subject disclosure. 
         FIG.  8    illustrates an example method facilitating remote provisioning of drone resources organized in a tiered environment in accordance with aspects of the subject disclosure. 
         FIG.  9    depicts an example schematic block diagram of a computing environment with which the disclosed subject matter can interact. 
         FIG.  10    illustrates an example block diagram of a computing system operable to execute the disclosed systems and methods in accordance with an embodiment. 
     
    
    
     DETAILED DESCRIPTION 
     The subject disclosure is now described with reference to the drawings, wherein like reference numerals are used to refer to like elements throughout. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the subject disclosure. It may be evident, however, that the subject disclosure may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form in order to facilitate describing the subject disclosure. 
     Conventional remotely controlled land, air, water, and/or space vehicles, hereinafter collectively referred to as drones, generally employ remote control operation and/or remote activation of vehicular self-control, in a generally closed system. The closed system can be expressed as ownership, e.g., a consumer can own a drone and operate the drone as their own, much as a car can be owned by a consumer and the car can be operated by the consumer. As an example, a consumer drone product, such as a model submarine, can be operated via a remote control device by the consumer. In an aspect, the consumer can cede control to another user typically in a real-time manner, such as by physically transferring the remote controller to another user to allow them to control the drone. As another example, a military drone can be operated from a control center located remotely from the drone for operation by designated military personnel, such as members of a drone pilot corps. As drones, for land, sea, air, and/or space operation, become increasingly ubiquitous, intelligent allocation of drone resources can become increasingly significant. 
     The instant disclosure seeks, in an aspect, to allocate drone resources intelligently in a shared manner, generally in the absence of physical transfer of a remote controller device between users. In an embodiment, remote provisioning of drone resources, e.g., allocating use of a drone to different sets of users, typically in a serial manner, can allow for improved access to drone resources. As an example, a first user can be allocated drone use via a drone allocation component for a first time period, and then a second user can be allocated use of the drone via the drone allocation component for a second time period. In this example, neither the first user, nor the second user, needs to actually own the drone, rather they can be accorded temporary use of the drone that can be owned by another entity, such as a drone rental company. This can be similar to reserving use of a shared automobile, where the first and second users may not own the car, but are allowed to use the car according to an agreement between the car owner and the intended users. However, unlike the shared car example, the use of the drone can be abstracted further, for example, a user can designate a drone mission, generally intended to mean a set of operations or goals for the drone to achieve, from a remote device, which the drone can then execute. In the context of the shared car example, this could be akin to requesting, at 8 am, that a shared car autonomously go buy a gallon of milk and deliver it to the user&#39;s house between 3 pm and 3:15 pm, and then having the shared car arrive at the user&#39;s house at 3:10 pm with the milk. Numerous other examples within the scope of the instant disclosure can readily be appreciated despite only a non-exhaustive handful of examples being disclosed herein for the sake of clarity and brevity. Failure to recite a particular example situation is not intended to exclude said particular example from the scope of the subject matter disclosed herein. 
     It will be noted that as drones become more pervasive and increasingly ubiquitous, remote provisioning of drone resources can be effective for efficient distribution of drone resources. As an example, rather than every news channel in a region owning and operating a separate drone for monitoring traffic, wherein the separate drones are to a large degree redundant, fewer traffic drones can be owned and the costs shared among the several news channels. In this example, the news channels could participate in an auction to reserve a drone for a particular use and can also participate in shared use, such as several news channels each contributing to the cost of the drone monitoring a regional roadway during rush hour. As such, when the drone is not monitoring the regional roadway, the drone could be reserved for use by other news channels, such as for aerial photography of a festival, monitoring of an evolving local news story, etc., without the need for the news channel to directly own the drone. In another example, even where a news channel does own a drone, use of that drone can be reserved for high priority uses, where more pedestrian uses can be allocated to shared drones that can be remotely provisioned, e.g., the regional traffic drone can provide traffic information to one or more news channels so that the other individually owned drone is unfettered and available for coverage of breaking news. 
     In effect, drones can become a more widely accessible resource that can be remotely provisioned. As such, drones can take on a communal character, a rented or leased character, a gift character, a benefit character, etc. In an aspect, privately owned drones can be made available to others, e.g., publically available, such as to anyone, semi-publically available, such as to members of a group meeting determined criteria, or shareable, such as to one or more specifically designated people. Moreover, publically owned drone resources can be deployed, e.g., publically owned drone resources can be deployed for public use. Additionally, white-list and black-list filtering can be employed to include or exclude users, or users associated with determined characteristics, histories, uses, etc. 
     Provisioning of the drone resource can include autonomous and/or semi-autonomous mission parameters. As an example, a drone can be remotely provisioned to monitor activity related to a curfew by flying a determined region in an autonomous manner. As another example, a drone can be remotely provisioned to arrive and remain proximate to a location in an autonomous manner where it will receive further instructions for operation from a user remote controller, such as via a smart phone touch interface, via a voice interface, via monitoring visual cues, such as hand signals, presented by a user or users, in the area of operation, etc. Expanding on the example, a dog trainer can request a drone arrive proximate to a dog park at a designated time, where it will circle until it receives voice commands from the user via a phone call from the user, whereupon the user can instruct the drone to track an identified dog with video feedback to the user&#39;s mobile device. This can allow the dog trainer to view the tracked dog via the drone, wherein the drone can keep the dog in view and provide the images to the trainer, even when the trainer does not have a sight line to the dog directly. In a similar example, a parent can request a drone ‘walk their child to school’ in the morning, wherein the drone can be provisioned to arrive and then track the child as they walk or ride a bike to school, providing images periodically unless the child departs from a determined route, wherein the drone can capture video, audio, location information, an audible alarm, etc. This could allow a parent to see that their child is taking unsafe shortcuts on their way to school, could capture valuable video imagery, such as a license plate number, in the case of an abduction, etc. Moreover, drones regularly operate with sensors that provide improved capture of information, which could allow the drone to capture audio from a scene, track a thermal image of the child through fog, rain, clouds, or darkness, etc., capturing RFIDs, SIM identifiers, etc., from devices proximate to the child, etc., which in an abduction situation could be immensely useful to law enforcement, such as getting a plate number of a van, video of the abduction even at night, and capturing the SIM identifier of a mobile device of the abductor contemporaneous with the abduction, all without the parent ever purchasing a drone, or physically renting and controlling the drone in an active manner. Remote provisioning of drone resources can have a definitive impact on access to drone resources in a manner that can reduce the consumption of user resources. 
     In an aspect, remote provisioning of drone resources can determine allocation of a drone according to parameters of drone request information. A drone can then be provisioned in accord with the determined allocation. A request response can then be generated. As an example, a drone request can be employed to determine drone request information, which can be received by a drone allocation component. The drone allocation component can then determine drone-provisioning information based on the drone request information. The drone provisioning information can be employed to provision the drone and, in response, an acknowledgement that the drone is provisioned can be returned to the user via a generated response comprising request response information. In an embodiment, the drone allocation component can employ the drone request information to select an appropriate drone from a set of one or more drones. 
     Selection can be based on parameters such as, but not limited to, a type of drone, a drone specification, an mission operating environment, drone availability, price, proximity, rules or laws, user profile, scheduling, a control interface or feature thereof, prior use of drones by the user, insurance features, intended use characteristics, certification, training, geographical or political boundaries, etc. As an example, parameters for remote provision of a drone can be very different where the drone in one case is to be used to film a back yard birthday party for a user&#39;s 10 year old son, and in another case, is to be used to monitor surfing conditions in front of an incoming weather system for a large surfing competition. However, a drone allocation component can determine what, if any, drone in one or more sets of available drones satisfy drone allocation parameters based on the drone request information. 
     It will be noted that the drone request information can be used to determine and/or infer values that can be employed in determining satisfaction of a drone allocation parameter, for example, the drone request information can comprise a designation that the drone have video capability which can be used to filter out drones without video. Further, the drone request information can comprise requestor income information that can be used to infer drones in a probably use cost/price range, allowing the drone allocation component to select a drone that meets designated parameters and is more likely to be ‘affordable’ to the requestor. It will be noted that many information vectors can be employed in inferring values that can be employed in determining satisfaction of a drone allocation parameter and that all such inferences are within the scope of the instant subject matter even where not explicitly disclosed for the sake of clarity and brevity. As another example, an inference can be made by the drone allocation component based on the requestor&#39;s usage history, drone operation certifications associated with the requestor, weather conditions, operational characteristics of one or more drones, etc., such that a drone can be allocated that is most likely to be comfortably usable by the requestor, e.g., analogously it can be inferred that it would be less likely for a 90-year old man would like to rent a landscaping truck with manual steering and without a tilt-bed, and more likely to want to rent a compact truck with power steering and a dump-bed, even though both would be effective at delivering one cubic yard of beauty bark to his home, even where the landscaping truck might be located closer and be available for the same cost. 
     Further, remote provisioning can interact with one or more sets or groups of drones. In some embodiments, these sets can be tiered, e.g., hierarchically tiered. Tiers of drone sets can be associated with different drone factors, for example, actual, anticipated, or estimated usage of drones or drone resources, ownership of drones or drone resources, organizational structures, regional proximities, etc. As an example, a first set of drones, comprising one or more drones, can be associated with private drones made available to users other than the private owners, such as drones owned by one or more persons in a neighborhood being made available for provisioning to the general public, other members of the neighborhood but not the general public, to members of a club or determined group, etc. As such, where the private drones are made available to the general public, then John Q. Public can request a drone that can be allocated from this first set of drones. Further, where a second set of drones can be associated with a corporation, this second set can be designated as at another tier, for example, where a satisfactory drone from the first set cannot be found, the second set can be searched for an appropriate drone. This hierarchical tier scheme can enable drones in different tiers to be identified based on criteria associated with the distinction between the tiers. As an example, where a corporation has three tiers of drone sets, the first tier can comprise older drones, the second tier can comprise newer drones that have already been amortized, and the third tier can comprise newer drones that have not yet been fully amortized. As such, request for a drone can first be searched against the first tier, then the second tier, then the third tier, wherein each tier can be associated with rules pertaining to the provisioning of a drone from that tier. Thus, where a satisfactory first tier drone is found, it can be provisioned in lieu of another satisfactory drone from the second or third tier drone sets. 
     Of note, the present disclosure is different from, and an improvement over, current ‘drone sharing’ techniques that generally rely heavily on human interaction. An example of a conventional drone rental technique involves an online reservation that can be made for a drone from a rental group, to which the renter must then travel to pick up the drone for use and must return it to after use. In contrast, the instant disclosure can provide for direct provisioning of an appropriate drone such that the drone arrives where/when needed and can operate in an autonomous or semi-autonomous mode, e.g., getting itself to the desired location and then taking commands, receiving a mission package and executing the mission autonomously, etc. As an example of another conventional system, higher end drones can be ‘rented’ online, wherein the renter discusses a mission with a human operator and the human operator coordinates execution of the mission for the renter. These types of services can be, for example, associated with a corporate user requesting a drone service provider to fly a mission over an oil field half a world away. The instant disclosure again differs from, and can be an improvement over, such technologies in that the drone typically can be automatically provisioned to execute the mission half a world away without generally needing to interact with the human operator. Of course, in some instances, especially where the mission is highly complex, inclusion of human operators or planners can be employed without departing from the scope of the present disclosure while still maintaining a differential improvement over those systems either in the reduction in human interaction over conventional systems, or for other reason elucidated herein. Remote provisioning of drone resources in a more automated manner is generally distinct from conventional techniques. Further, the ability to provision from different sets of drones, typically owned by different entities, and/or different tiers of drones, is substantially different from conventional technologies, more so in that, where drone sets comprise large numbers of drones, a drone allocation component can improve provisioning of an appropriate or satisfactory drone over conventional techniques. As an example, rather than having to manually select from a handful of drones via a website or with a human operator, the instant disclosure can enable searching across large numbers of drones based on parameters, characteristics, history, intended use, schedules, locations, interface features, a user profile, etc., in a manner that is far faster and typically more accurate than a manual search. This can facilitate efficient allocation of drones and associated resources, such that, for example, a drone can be provisioned from company B that is farther away, rather than company A that is closer, based on the drone from B just meeting the drone request parameters in contrast to the drone from A far exceeding the drone request parameters. Numerous other distinctions over conventional techniques are further expressly and inherently illustrated herein and are to be considered within the scope of the instant disclosure. 
     In an embodiment, a system can comprise a processor and a memory allowing execution of stored instructions to enable the processor to receive a request for allocation of a drone and determining a metric value associated with the request based on a rule related to scoring a set of requests against a set of drones associated with the drone resource. Provisioning the drone can be based on the request for allocation of the drone resource. This can enable access to the drone resource associated with the drone in accord with the request. 
     In another embodiment, a method can comprise receiving, by a system comprising a processor, a request for allocation of a drone resource via a communications framework. The method can further comprise determining, by the system, a ranking of a drone associated with the drone resource from a set of drones, wherein the ranking is based on a parameter determined from the request and a characteristic of the drone. Moreover, the method can comprise provisioning the drone by the system, based on the request for allocation of the drone resource based on the ranking. 
     In a further embodiment, a computer readable medium can comprise instructions that can cause a system comprising a processor to receive a request for allocation of a drone resource via a wireless communications framework and determine a ranking score of a drone associated with the drone resource. The ranking score can be based on a parameter determined from the request and a characteristic of the drone resource. Further, the processor can select the drone based on the ranking score and provision the drone based on the request for allocation of the drone resource. 
     To the accomplishment of the foregoing and related ends, the disclosed subject matter, then, comprises one or more of the features hereinafter more fully described. The following description and the annexed drawings set forth in detail certain illustrative aspects of the subject matter. However, these aspects are indicative of but a few of the various ways in which the principles of the subject matter can be employed. Other aspects, advantages and novel features of the disclosed subject matter will become apparent from the following detailed description when considered in conjunction with the provided drawings. 
       FIG.  1    is an illustration of a system  100 , which facilitates remote provisioning of drone resources in accordance with aspects of the subject disclosure. System  100  can include drone allocation component (DAC)  110  that can facilitate remote provisioning of drone resources. DAC  110  can receive drone request information  120 . Drone request information  120  can comprise information related to requesting provisioning of a drone or drone related resource. Drone request information  120  can comprise name, address, phone number, identification information, account information, profile information, certifications information, logged hours or other training, mission parameters, such as, but not limited to, mission location, mission time, mission duration, mission type, mission payload, mission controller or interaction devices/services, level of autonomy, other drones/devices associated with the mission, etc., clearances, permits, approvals, waivers, mission path, mission locus resources available, e.g., power, fuel, internet connectivity, etc., historical drone use, additional operators/controllers, etc. It will be noted that nearly any pertinent information can be included in drone request information  120 . In an embodiment, drone request information  120  can be generated by a mobile device, a desktop computer, a laptop computer, a wearable computing device, etc. Moreover, drone request information  120  can be originated by a first device, e.g., a mobile device, and can be supplemented with associated information from other devices. As an example, where a dad regularly monitors his daughter&#39;s little league game, a request for a drone can be originated by the dad for that afternoon&#39;s game while he is on the bus to work that morning. This request can indicate that historically similar missions have been executed and relevant information can be received in relation to those historically similar missions and with regard to the dad&#39;s profile and historical use of drones from cloud server devices to supplement drone request information  120  generated for that days game. Even where that afternoon&#39;s game is to be held at a different field, other mission parameters related to the type of mission, e.g., monitoring a baseball game, are relevant and can be captured in drone request information  120 . 
     Further, drone request information  120  can comprise information that can be used to infer parameters, allowing DAC  110  to determine a drone that meets explicit and inferred parameters. It will be noted that nearly any information vector can be employed in inferring values that can be employed in determining satisfaction of a drone allocation parameter. As an example, an inference can be made by DAC  120  based on predicted weather that certain drone parameters are likely important. Where a drone request is made, for example, four months in advance of the mission date, the weather can be inferred initially for provisioning, and additional drones or associated resources can be earmarked where the inference is weak due to the long lead up time to the mission. As such, the inference can be revisited as the example weather information changes as the mission date approaches such that the provisioning of the drone can be updated and remain correspondingly more relevant. 
     DAC  120  can determine drone provisioning information  130 . Drone provisioning information can include selection parameters. Selection parameters can include, but are not limited to, a type of drone, a drone specification, a mission operating environment, drone availability, price, proximity, rules or laws, user profile, scheduling, a control interface or feature thereof, prior use of drones by the user, insurance features, intended use characteristics, certification, training, geographical or political boundaries, etc. Selection parameters can be based on drone request information  120 . Further, selection parameters can be based on other information, for example, drone set information, drone information for drones comprising a drone set, weather information, schedule information related to persons related to the mission event, etc., As an example, drone request information  120  can indicate both mom and dad will be at the little league game and direct mission operations via smartphones, this can trigger capture of the type of smartphone used by both mom and dad to be a parameter in selecting a drone that can interact with both types of phone. Drone allocation component  120  can determine what, if any, drone in one or more sets of available drones satisfy drone allocation parameters based on drone request information  120  and other related information. Additionally, selection parameters can identify a drone, a set of drones, multiple sets of drones, tiers of drones, etc. This information can be employed in determining, in conjunction with the selection information, a drone to provision. 
     Drone provision information  130  can be made accessible by DAC  110 . As such, a selected drone can receive drone provisioning information  130 . The drone can then indicate, either affirmatively, by absence of a refusal, etc., that it accepts being provisioned. In response, DAC  110  can generate request response information  140 . Request response information  140  can indicate that provisioning was successful, that selection of a drone was made but provisioning failed, that a drone could not be selected that met the parameters, alternate drones available and information on what parameters are not satisfied, etc. Request response information  140  functions to provide information back to the requestor about the state of fulfilling a drone request, including information related to the provisioning of a drone. In some embodiments, request response information  140  can further comprise a request for additional parameter information where a large set of drones meet the parameters. In further embodiments, request response information  140  can comprise information related to user selection of an available drone, for example, where two drones are available and meet the parameters, the selection choice can be left to the user. 
     In an aspect, rather than provisioning a single drone, multiple drones can be provisioned and request response information  140  can reflect information related to the provisioning of multiple drones. Moreover, where only one drone is needed from the set of provisioned drones, provisioned drones can be released from the provisioning according to one or more rules. As an example, three drones can be initially provisioned, at mission time, one drone can experience a mechanical failure such that the second provisioned drone acts as a fail over and assumes the mission. Where the second drone assumes the mission and undertakes execution of the mission, the third provisioned drone can be released and made available in to satisfy other incoming drone requests via system  100 . In some embodiments, drone provisioning can occur in one drone set, in multiple drone sets, in one tier, or in multiple tiers. 
       FIG.  2    is a depiction of a system  200  that can facilitate remote provisioning of drone resources via a remotely located drone allocation component in accordance with aspects of the subject disclosure. System  200  can include DAC  210  that can facilitate remote provisioning of drone resources. DAC  210  can receive drone request information  220  from user equipment (UE)  250  via communication framework  260 . Drone request information  220  can comprise information related to requesting provisioning of a drone or drone related resource. Drone request information  220  can comprise name, address, phone number, identification information, account information, profile information, certifications information, logged hours or other training, mission parameters, such as, but not limited to, mission location, mission time, mission duration, mission type, mission payload, mission controller or interaction devices/services, level of autonomy, other drones/devices associated with the mission, etc., clearances, permits, approvals, waivers, mission path, mission locus resources available, e.g., power, fuel, internet connectivity, etc., historical drone use, additional operators/controllers, etc. It will be noted that nearly any pertinent information can be included in drone request information  220 . Done request information  220  can be generated by UE  250 , for example, a mobile device, a desktop computer, a laptop computer, a wearable computing device, etc. Moreover, drone request information  220  can be originated by a first UE  250  and can be supplemented with associated information from other UEs (not illustrated). 
     UE  250  can comprise or execute a user interface (not illustrated) that can allow input of information related to remote provisioning of a drone resource. In an embodiment, UE  250  can execute an application that can include a user interface, such as a graphical user interface (GUI), which can allow input of information related to remote provisioning of a drone resource. Information related to remote provisioning of a drone resource can include, but is not limited to, a date, a time, or other temporal or scheduling information, a location, drone mission parameters, specification of a drone type, drone model, etc., specification of drone mission payload or mission related equipment, such as image capture devices, speakers, radar devices, sonar devices, audio capture devices, laser range finders, or nearly any other type of sensor, instrument, or detector, for example, LiDAR, mass spectrometers, thermocouples, biological or chemical sensors, FLIR-type devices, communications equipment, Wi-Fi access points, cellular access points, LTE access points, femtocells, etc. Of note, information related to remote provisioning of a drone resource can also include mission parameters, such as, but not limited to, waypoints, mission paths, designated operator(s) information, etc., related to execution of a mission, scheduling a mission, planning a mission, altering a mission, autonomous actions, semi-autonomous action, manual control of a drone, etc. Further, drone request information  220  can comprise information that can be used to infer parameters, allowing DAC  210  to determine a drone that meets explicit and inferred parameters. It will be noted that nearly any information vector can be employed in inferring values that can be employed in determining satisfaction of a drone allocation parameter. 
     DAC  220  can determine drone provisioning information  230 . Drone provisioning information can include drone selection parameters. Selection parameters can include, but are not limited to, a type of drone, a drone specification, a mission operating environment, drone availability, price, proximity, rules or laws, user profile, scheduling, a control interface or feature thereof, prior use of drones by the user, insurance features, intended use characteristics, certification, training, geographical or political boundaries, etc. Selection parameters can be based on drone request information  220 . Further, selection parameters can be based on other information, for example, drone set information, drone information for drones comprising a drone set, weather information, schedule information related to persons related to the mission event, etc. Drone allocation component  220  can determine what, if any, drone in one or more sets of available drones satisfy drone allocation parameters based on drone request information  220  and other related information. Additionally, selection parameters can identify a drone, a set of drones, multiple sets of drones, tiers of drones, etc. This information can be employed in determining, in conjunction with the selection information, a drone to provision. 
     Drone provisioning information  230  can be made accessible by DAC  210  to drone  270 . As such, a selected drone, e.g., drone  270 , or other drones can receive drone provisioning information  230 . Drone  270  can then indicate, either affirmatively, by absence of a refusal, etc., that it accepts being provisioned. In response, DAC  210  can generate request response information  240  that can be accessed by UE  250  via communication framework  260 . Request response information  240  can indicate that provisioning was successful, that selection of a drone was made but provisioning failed, that a drone could not be selected that met the parameters, alternate drones available and information on what parameters are not satisfied, etc. Request response information  240  functions to provide information back to the requestor via UE  250  about the state of fulfilling a drone request, including information related to the provisioning of a drone. In some embodiments, request response information  240  can further comprise a request for additional parameter information where a large set of drones meet the parameters. In further embodiments, request response information  240  can comprise information related to user selection of an available drone, for example, where two drones are available and meet the parameters, the selection choice can be left to the user. 
     In an aspect, rather than provisioning a single drone, multiple drones can be provisioned and request response information  240  can reflect information related to the provisioning of multiple drones. Moreover, where only one drone is needed from the set of provisioned drones, provisioned drones can be released from the provisioning according to one or more rules. As an example, three drones can be initially provisioned, at mission time, one drone can experience a mechanical failure such that the second provisioned drone acts as a fail over and assumes the mission. Where the second drone assumes the mission and undertakes execution of the mission, the third provisioned drone can be released and made available in to satisfy other incoming drone requests via system  200 . In some embodiments, drone provisioning can occur in one drone set, in multiple drone sets, in one tier, or in multiple tiers. 
     Communication framework  260  can comprise wired and wireless communication links or segments. As an example, communication framework  260  can comprise a radio access network (RAN) associated with a wireless carrier, a Wi-Fi access point connected through the internet to DAC  210 , a Bluetooth link to DAC  210 , etc. Given that the instant disclosure can enable nearly any UE to remotely provision a drone resource, the communication framework  260  can often comprise internet server devices in the communication path between UE  250  and DAC  210 . However, it is to be noted that the present disclosure is not limited solely to communication framework  260  comprising a link with, or between, internet servers. 
     UE  250  can receive input related to generating drone request information  220  or updating of other information relating to remotely provisioning a drone resource via various types of user input. In an embodiment, input can be received via a touch interface of UE  250 , such as a GUI having a touch interface on a modern smartphone. In some embodiments, inputs can comprise audio or verbal inputs, such as, providing spoken information or commands via a microphone of UE  250  that can then be converted, e.g., via speech recognition components, into information related to provisioning a drone, updating a provisioned drone, or controlling the drone before, during, or after the mission. In additional embodiments, inputs can include references to information generated in other applications, or on other devices, such as saved mission parameter files, etc. These can be stored local to UE  250  or can reside on a remote storage device such as a cloud server, networked computer, etc. Additional embodiments can accept inputs generated in virtual environments, such as designating a mission path, e.g., a flight path, in a virtual environment, such as can be enabled by an optical head-mounted display, a holographic interface, etc. 
       FIG.  3    illustrates a system  300  that facilitates remote provisioning of drone resources via a locally located drone allocation component in accordance with aspects of the subject disclosure. System  300  can include UE  350 . UE  350  can comprise DAC  310  that can facilitate remote provisioning of drone resources. DAC  310  can receive drone request information from UE  350  and can generate drone provisioning information  330 . Drone provisioning information  330  can be communicated via communication framework  360  to one or more drones, e.g., drone  372 ,  3743 ,  376 , etc. Drone request information received by DAC  310  of UE  350  can comprise information related to requesting provisioning of a drone or drone related resource, and can comprise name, address, phone number, identification information, account information, profile information, certifications information, logged hours or other training, mission parameters, such as, but not limited to, mission location, mission time, mission duration, mission type, mission payload, mission controller or interaction devices/services, level of autonomy, other drones/devices associated with the mission, etc., clearances, permits, approvals, waivers, mission path, mission locus resources available, e.g., power, fuel, internet connectivity, etc., historical drone use, additional operators/controllers, etc. It will be noted that nearly any pertinent information can be included in drone request information communicated to DAC  310  by UE  350 . Moreover, drone request information can be supplemented with associated information from other UEs (not illustrated) via UE  350 . 
     UE  350  can comprise a user interface that can allow input of information related to remote provisioning of a drone resource. In an embodiment, UE  350  can execute an application that can include a user interface, such as a graphical user interface (GUI), which can allow input of information related to remote provisioning of a drone resource. Information related to remote provisioning of a drone resource can include, but is not limited to, a date, a time, or other temporal or scheduling information, a location, drone mission parameters, specification of a drone type, drone model, etc., specification of drone mission payload or mission related equipment, such as image capture devices, speakers, radar devices, sonar devices, audio capture devices, laser range finders, or nearly any other type of sensor, instrument, or detector, for example, LiDAR, mass spectrometers, thermocouples, biological or chemical sensors, FLIR-type devices, communications equipment, Wi-Fi access points, cellular access points, LTE access points, femtocells, etc. Of note, information related to remote provisioning of a drone resource can also include mission parameters, such as, but not limited to, waypoints, mission paths, designated operator(s) information, etc., related to execution of a mission, scheduling a mission, planning a mission, altering a mission, autonomous actions, semi-autonomous action, manual control of a drone, etc. Further, drone request information can comprise information that can be used to infer parameters, allowing DAC  310  to determine a drone that meets explicit and inferred parameters. It will be noted that nearly any information vector can be employed in inferring values that can be employed in determining satisfaction of a drone allocation parameter. UE  350  can receive input related to generating drone request information via various types of user input. In an embodiment, input can be received via a touch interface of UE  350 , such as a GUI having a touch interface on a modern smartphone. In some embodiments, inputs can comprise audio or verbal inputs, such as, providing spoken information or commands via a microphone of UE  350  that can then be converted, e.g., via speech recognition components, into information related to provisioning a drone, updating a provisioned drone, or controlling the drone before, during, or after the mission. In additional embodiments, inputs can include references to information generated in other applications, or on other devices, such as saved mission parameter files, etc. These can be stored local to UE  350  or can reside on a remote storage device such as a cloud server, networked computer, etc. Additional embodiments can accept inputs generated in virtual environments, such as designating a mission path, e.g., a flight path, in a virtual environment, such as can be enabled by an optical head-mounted display, a holographic interface, etc. 
     DAC  310  can determine drone provisioning information  330 . Drone provisioning information can include drone selection parameters. Selection parameters can include, but are not limited to, a type of drone, a drone specification, a mission operating environment, drone availability, price, proximity, rules or laws, user profile, scheduling, a control interface or feature thereof, prior use of drones by the user, insurance features, intended use characteristics, certification, training, geographical or political boundaries, etc. Selection parameters can be based on drone request information. Further, selection parameters can be based on other information, for example, drone set information, drone information for drones comprising a drone set, weather information, schedule information related to persons related to the mission event, etc. Drone allocation component  310  can determine what, if any, drone in one or more sets of available drones, e.g., drones  372 - 376 , etc., satisfy drone allocation parameters based on drone request information and other related information. Additionally, selection parameters can identify a drone, a set of drones, multiple sets of drones, tiers of drones, etc. This information can be employed in determining, in conjunction with the selection information, a drone to provision. 
     Drone provisioning information  330  can be made accessible by DAC  310  to drone  370 ,  374 , and  376 , to enable provisioning of one or more of the drones  372 - 376 . As such, a selected drone(s), e.g., drones  372 - 376 , or other drones, can receive drone provisioning information  330 . Drones  372 - 376  can then indicate, either affirmatively, by absence of a refusal, etc., that it accepts being provisioned. In an embodiment, the first drone, e.g., of  372 - 376 , to indicate acceptance of provisioning can cause the other drones to be released, e.g., a first in first out (FIFO) schema. In other embodiments, drones  372 - 376  can negotiate, e.g., via communication framework  360 , as to which drone will accept provisioning. In an aspect, drones  372 - 376  can represent a selected subset of available drones wherein final acceptance of provision can be FIFO or negotiated. In this aspect, drone provisioning information  330  can be analogous to unicast information sent specifically to drones  372 - 374 . In another aspect, drones  372 - 376  can represent unselected drones that receive widely broadcast drone provisioning information  330 , wherein acceptance of provisioning by one or more drones can be performed at the drones themselves based on drone provisioning information  330  generated by DAC  310 . In this aspect, drone provisioning information  330  can be analogous to multicast information sent broadly to drones  372 - 374 . In a further aspect, drones  372 - 376  can represent selected sets of unselected drones that receive widely broadcast drone provisioning information  330 , wherein acceptance of provisioning by one or more drones can be performed at the drones themselves based on drone provisioning information  330  generated by DAC  310 . In this aspect, the sets of drones, e.g., drone  372 - 376  can be specifically targeted by DAC  310 , however the sets may contain multiple drones that subsequently can self-select within the set. This can analogously act as a hybrid of unicast and multicast information made available to drones  372 - 374 . 
     In response to acceptance of provisioning by one or more of drone  372 - 376 , DAC  310  can generate request response information that can be accessed by UE  350 . Request response information can indicate that provisioning was successful, that selection of a drone was made but provisioning failed, that a drone could not be selected that met the parameters, alternate drones available and information on what parameters are not satisfied, etc. Request response information can functions to provide information back to the requestor via UE  350  about the state of fulfilling a drone request, including information related to the provisioning of a drone. In some embodiments, request response information can further comprise a request for additional parameter information where a large set of drones meet the parameters. In further embodiments, request response information can comprise information related to user selection of an available drone, for example, where two drones are available and meet the parameters, the selection choice can be left to the user. In an aspect, rather than provisioning a single drone, multiple drones can be provisioned and request response information can reflect information related to the provisioning of multiple drones. Moreover, where only one drone is needed from the set of provisioned drones, provisioned drones can be released from the provisioning according to one or more rules. In some embodiments, drone provisioning can occur in one drone set, in multiple drone sets, in one tier, or in multiple tiers. 
     Communication framework  360  can comprise wired and wireless communication links or segments. Wherein nearly any UE can remotely provision a drone resource, communication framework  360  can often comprise internet server devices in the communication path between UE  350  and drones  372 - 376 . However, it is to be noted that the present disclosure is not limited solely to communication framework  360  comprising a link with, or between, internet servers. 
     In another embodiment, DAC  310  can be virtualized, in whole or in part, and virtualized parts can be comprised in communication framework  360 , not illustrated. As such, UE  350  can communicate via communication framework  360  to virtual DAC  310  components. Where DAC  310  is fully virtualized, DAC  310  may not be comprised in UE  350 , but rather would be comprised in communication framework  360  and in communication with UE  350 . Where DAC  310  is partially virtualized, a portion of DAC  310  can be comprised in UE  350  and in communication with the virtualized portion of DAC  310  comprised in communication framework  360 . As an example, DAC  310  can be a ‘thin client’ application on UE  350  that is in communication with a virtualized DAC  310  residing in the cloud, e.g., executing on cloud server platforms, to enable DAC  310  functionality in remotely provisioning drone resources  372 - 376 . 
       FIG.  4    illustrates a system  400  that facilitates remote provisioning of drone resources organized in a tiered environment in accordance with aspects of the subject disclosure. System  400  can include DAC  410  that can facilitate remote provisioning of tiered drone resources. DAC  410  can receive drone request information  420 . Drone request information  420  can comprise information related to requesting provisioning of a drone or drone related resource. Drone request information  420  can comprise name, address, phone number, identification information, account information, profile information, certifications information, logged hours or other training, mission parameters, such as, but not limited to, mission location, mission time, mission duration, mission type, mission payload, mission controller or interaction devices/services, level of autonomy, other drones/devices associated with the mission, etc., clearances, permits, approvals, waivers, mission path, mission locus resources available, e.g., power, fuel, internet connectivity, etc., historical drone use, additional operators/controllers, etc. It will be noted that nearly any pertinent information can be included in drone request information  420 . In an embodiment, drone request information  420  can be generated by a mobile device, a desktop computer, a laptop computer, a wearable computing device, etc. Moreover, drone request information  420  can be originated by a first device, e.g., a mobile device, and can be supplemented with associated information from other devices. Further, drone request information  420  can comprise information that can be used to infer parameters, allowing DAC  410  to determine a drone that meets explicit and/or inferred parameters. It will be noted that nearly any information vector can be employed in inferring values that can be employed in determining satisfaction of a drone allocation parameter. 
     DAC  420  can determine drone provisioning information  430  and  432 . Drone provisioning information  430 - 432  can include selection parameters. Selection parameters can include, but are not limited to, a type of drone, a drone specification, a mission operating environment, drone availability, price, proximity, rules or laws, user profile, scheduling, a control interface or feature thereof, prior use of drones by the user, insurance features, intended use characteristics, certification, training, geographical or political boundaries, etc. Selection parameters can be based on drone request information  420 . Further, selection parameters can be based on other information, for example, drone set information, drone information for drones comprising a drone set, weather information, schedule information related to persons related to the mission event, etc. Drone allocation component  420  can determine what, if any, drone in one or more sets of available drones, e.g., tier 1 drone(s)  470  and tier 2 drone(s)  472 , satisfy drone allocation parameters based on drone request information  420  and other related information. Additionally, selection parameters can identify a drone, a set of drones, multiple sets of drones, tiers of drones, etc. This information can be employed in determining, in conjunction with the selection information, a drone to provision. 
     Drone provision information  430  can be made accessible by DAC  410 . As such, a selected drone, e.g., tier 1 drone(s)  470  and tier 2 drone(s)  472 , can receive drone provisioning information  430 . The drone can then indicate, either affirmatively, by absence of a refusal, etc., that it accepts being provisioned. In response, DAC  410  can generate request response information  440 . Request response information  440  can indicate that provisioning was successful, that selection of a drone was made but provisioning failed, that a drone could not be selected that met the parameters, alternate drones available and information on what parameters are not satisfied, etc. Request response information  440  can function to provide information back to the requestor about the state of fulfilling a drone request, including information related to the provisioning of a drone, e.g., tier 1 drone(s)  470  and tier 2 drone(s)  472 . In some embodiments, request response information  440  can further comprise a request for additional parameter information where a large set of drones meet the parameters. In further embodiments, request response information  440  can comprise information related to user selection of an available drone, for example, where two drones are available and meet the parameters, the selection choice can be left to the user. 
     In an aspect, rather than provisioning a single drone, multiple drones can be provisioned and request response information  440  can reflect information related to the provisioning of multiple drones. Moreover, where only one drone is needed from the set of provisioned drones, provisioned drones can be released from the provisioning according to one or more rules. In some embodiments, drone provisioning can occur in one drone set, in multiple drone sets, in one tier, or in multiple tiers. 
     In an aspect, drones can be organized in one or more tiers, e.g., tier 1 drone(s)  470  and tier 2 drone(s)  472 . Tiers of drone sets can be associated with different drone factors, for example, actual, anticipated, or estimated usage of drones or drone resources, ownership of drones or drone resources, organizational structures, regional proximities, etc. As an example, a first set of drones, comprising one or more drones, can be associated with private drones made available to users other than the private owners, such as drones owned by one or more persons in a neighborhood being made available for provisioning to the general public, other members of the neighborhood but not the general public, to members of a club or determined group, etc. As such, where the private drones are made available to the general public, then John Q. Public can request a drone that can be allocated from this first set of drones. Further, where a second set of drones can be associated with a corporation, this second set can be designated as at another tier, for example, where a satisfactory drone from the first set cannot be found, the second set can be searched for an appropriate drone. In an embodiment, a hierarchical tier scheme can enable drones in different tiers to be identified based on criteria associated with the distinction between the tiers. As an example, where a corporation has three tiers of drone sets, the first tier can comprise older drones, the second tier can comprise newer drones that have already been amortized, and the third tier can comprise newer drones that have not yet been fully amortized. As such, request for a drone can first be searched against the first tier, then the second tier, then the third tier, wherein each tier can be associated with rules pertaining to the provisioning of a drone from that tier. Thus, where a satisfactory first tier drone is found, it can be provisioned in lieu of another satisfactory drone from the second or third tier drone sets. 
     In an embodiment, organizing drones into tiers can be performed by DAC  410 . DAC  410  can receive drone information from drones available to participate in remote drone provisioning and can assign these available drones to one or more tiers, or one or more sets of drones within one or more tiers. Nearly any criteria can be employed in determining sets and/or tiers of drone membership. In a further embodiment, drone ranking or assignment to a particular group or tier, can be associated with information related to an owner profile, such as, a drone owner assigning a ranking value associated with external use of the drone by others, etc. In some embodiments, drone tiers, e.g.,  470 ,  472 , etc., can be static or dynamic assignments. Further, in some embodiments, drone assignment to groups or tiers can be determined by devices other than DAC  410 . 
     As an example, an online commerce company, ‘Jungle.com’, can employ drones for delivery of packages and can desire to further monetize their drones by allowing them to be provisioned for use by the public. The drones of Jungle.com can be primarily intended for corporate use but unused drones can be rented out to the public. As such, Jungle.com can employ their sales projections to determine an expected surplus of drone resources. A first half of the expected surplus can be designated as publically available and associated with a first tier, while the second half of the expected surplus can be designated as public available and associated with a second tier. This first tier can further be associated with a lower use price than the second tier. DAC  410  can receive this availability and tier information from Jungle.com and can add the tier one drones to other tier one drones from other owners and can add the second tier drones of Jungle.com to a second tier pool of drones known to DAC  410 . When a drone request comes into DAC  410 , an acceptable drone from the tier one pool of drones, e.g., tier 1 drone  470 , can be determined, via drone provisioning information  430 . Where an acceptable drone is not found, a subsequent search can be performed, via drone provisioning information  432  on the second tier drones, e.g., tier 2 drone  472 . This can allow Jungle.com&#39;s first tier drones to be provisioned before considering provisioning of the second tier drones. The disparity between the tiers can be employed to better ensure that some of the excess drones from Jungle.com are less likely to be rented out just in case Jungle.com may need them. Further, wherein the allocation of drones can be dynamic, all of the Jungle.com drones can be included in the first tier drones until half of them have ben provisioned, at which point, the remaining half of Jungle.com&#39;s surplus drones can be dynamically designated as second tier drones. This can allow selection drones from the full set of drones, such as by functionality, while still reserving a subset of surplus drones for Jungle.com use. Of note, drone provisioning information  430  and drone provisioning information  432  can be the same or different, e.g., drone provisioning information  432  can include information that first tier drones have already been searched, different preferences/parameters can be included in  432 , etc. 
       FIG.  5    illustrates a system  500  that facilitates remote provisioning of drone resources based on user-centric information components in accordance with aspects of the subject disclosure. System  500  can include UE  550  that can generate drone request information  520 . UE  550  that can receive request response information  540 . 
     UE  550  can comprise schedule component  580  that can enable access to schedule information. Schedule information can be related to a user&#39;s schedule. The user&#39;s schedule can be populated by the user, other users, assistants, or other devices. As an example, a user can schedule an event, a spouse can place an event in the user&#39;s schedule, a conference call event can be placed in the user&#39;s schedule by an office device or a web based service, etc. This schedule information can be employed in remotely provisioning a drone resource. As an example, a user can reserve a drone for video capture of an upcoming round of golf with friends. The reservation, e.g., provisioning of the drone, can be associated with the golf event in the user&#39;s calendar. Where an intervening phone conference pushes the time of the golf event to start an hour later, the schedule information can be employed to update or cancel the drone reservation, generate a user input as to rescheduling the drone usage, etc. Further, inferences can be made based on the schedule information, such as inferring that changing the tee time by 10 minutes will not result in cancellation of the drone rental but that a change of three hours would result in cancellation of the drone rental. Further, in an aspect, schedule component  580  can access schedule information for other determined profiles. As an example, where the user has scheduled the golf event, but one of the other golfers schedules changes, this information can be employed to update the drone provisioning, for example, where the other golfer was designated as an operator, another operator can be substituted and their control device information can be employed to ensure that an acceptable drone is provisioned. As such, if the substitute operator will use an tablet to interact with the drone while executing the mission, the change in schedule can precipitate an update to the provisioning to ensure that the provisioned drone can interact with that tablet. 
     In an embodiment, UE  550  can comprise location component  582  that can enable access to location information. Location information can be employed in remotely provisioning a drone resource. Location information can be for UE  550  itself, or for other devices, e.g., GPS information, timed fingerprint location information, proximity information, etc. Further, location component  582  can facilitate access to location information related to a mission, such as, but not limited to, determining location information for drone mission paths, waypoints, depths, altitudes, obstacles, etc. As an example, a map can be employed to designate a drone flight path, wherein location component  582  can access information related to the path such as longitude, latitude, proximity to beacons, etc. Further, the two dimensional map information can be used to access elevation information, e.g., additional dimensional information, so as to populate an altitude parameter for the drone to fly to avoid a controlled flight into an obstacle. Of note, the altitude parameter can be employed in provisioning a drone and/or in conjunction with executing a mission. In the provisioning, the altitude can be employed to select drones capable of flying that altitude and excluding others. For example, where the mission path traverses a high mountain pass, some drones may lack the ability to operate in the thinner air at higher elevations and can be excluded from the set of drones comprising a drone that will be provisioned. While this example is related to altitude, similar examples are inherently supported for information related to depth, slew or yaw rate, passing through orifices, etc., which can be related to location information, for example, determining a distance between two objects that a flight path passes between can be important in drone selection. Location information can be accessed from UE  550  or from other location information sources via UE  550 . In some embodiments, location information can be included in drone request information  520  that can be supplemented, for example by additional details received by a DAC via other devices, such as remote map servers. 
     UE  550  can also comprise user interface (UI) component  584  to enable remote drone allocation. UI component  584  can receive information related to user interactions. These interaction can be touch, motion, audio, visual, etc. As an example, a user can input UI information via a touch screen, such as on a smartphone, via verbal commands, e.g., via a UE microphone, by tilting, rotating, or otherwise interacting with the position of the UE, e.g., tilting left can cause a mission path to move left, etc., a UE camera can capture images that can be employed in determining mission parameters and operation of a drone, etc. In an embodiment, these UI techniques can be combined in any combination, such as a user designating a path by dragging a finger along a map displayed on their UE and verbally designating waypoints, altitudes, angles, levels of zoom, microphone on/off, etc., as part of designating mission parameters. In a way, the user can act almost like movie director in that they can virtually fly the designated path of the example and tilt the UE to affect different desired drone or payload movements, while speaking other commands, such as zoom in, zoom out, hover, etc., and interacting with gesture commands. UI component  584  can receive input from nearly any UI and enable that input to be employed in determining drone request information  520  to facilitate remote provisioning of a drone. Moreover, UI component  584  can further be employed in updating a provisioning, executing a mission, etc. 
     UE  550  can comprise drone history component  586 , which can receive information related to the historical use of drones related to a user profile. This information can encompass prior mission types, prior operational data, user satisfaction surveys, or nearly any other historical information related to the use of a drone by the user. As an example, where a user has previously rented an ‘alpha drone’, successfully used it, and gave positive feedback as to the alpha drone. A new request for provisioning of an alpha drone can be accompanied by the flight statistics from the prior alpha drone flights. This can enable selection of an alpha drone that meets the parameters of the historical flights and accommodates the user&#39;s learning curve for operation for alpha drones. Further, where the expertise of the user in alpha drones satisfies a training rule, such as based on the historical flight time logged and flight statistics, a recommendation can be made to the user to use a beta drone (more advanced) where the upcoming mission parameters are within the beta drone envelope and the performance is improved over the alpha drone. Of course, where the user regularly crashes alpha drones, the ability to provision a beta drone can be withheld or downgraded, insurance can be required, etc. 
     System  500  can further comprise UE  550 , which can include user profile component  588 . User profile component  588  can enable access to user profile information related to a determined user. In an aspect, user profile information can include user determined preferences, user certification and/or training information, user device(s) information, etc. Also, as disclosed elsewhere herein, user profile component  588  can enable access to historical user information stored in relation to the user profile. This can include records of prior drone usage and operation, historical payment information, billing information, memberships and/or benefits, recurring events, e.g., birthdays, anniversaries, kids&#39; sporting events, etc. These can be relevant to suggesting or promoting reservation of a drone for the event, and/or constraints on drone parameters for a current drone request, etc. This information can be included in drone request information  520 , which can be employed by a DAC to provision a drone resource. 
     UE  550  can comprise share component  590  that can facilitate sharing information related to provisioning a drone, executing a mission, etc. In an aspect, share component  590  can provide for including other people in a drone request, such that they can be designated as invited, attending, declined, tentative, etc., and/or can be designated as an operator, spectator, etc. As such, information related to a person, e.g., someone invited and indicated as an operator of the drone, can be sourced to DAC as part of the provisioning of the drone. As an example, where the invited operator will use an augmented reality wearable device to control the drone for part of the mission, the provisioning of the drone can include the constraint that the drone should interface with the augmented reality wearable device. Furthermore, the example invited operator location and schedule information can be included to compensate for delays form a change in schedule or traffic on the way to a mission control point. Additionally, the example invited operator drone history can be indicated via drone request information  520 , to help ensure that an appropriate drone is selected for provisioning. Nearly any information pertinent to the provisioning of a drone, execution of a mission, etc., can be received or accessed via share component  590  to facilitate improved provisioning of a drone for a mission and/or operation of a drone on mission. In an embodiment, accessing or receiving this shared information can be subject to privacy controls/rules, such as getting permission to share said information. 
     Of note, any of the components illustrated as comprised in UE  550  can be located in other devices or in a distributed manner. They are illustrated as part of UE  550  merely for simplicity and brevity. As an example, Drone history component  586  can be located on a cloud server and can provide supportive information to the provisioning of a drone, such as by passing information to a DAC as part of generating drone provisioning information, e.g.,  130 - 430 ,  432 , etc., or to UE  550  in generating drone request information  120 - 220 ,  420 - 520 , etc. 
     In view of the example system(s) described above, example method(s) that can be implemented in accordance with the disclosed subject matter can be better appreciated with reference to flowcharts in  FIG.  6   - FIG.  8   . For purposes of simplicity of explanation, example methods disclosed herein are presented and described as a series of acts; however, it is to be understood and appreciated that the claimed subject matter is not limited by the order of acts, as some acts may occur in different orders and/or concurrently with other acts from that shown and described herein. For example, one or more example methods disclosed herein could alternatively be represented as a series of interrelated states or events, such as in a state diagram. Moreover, interaction diagram(s) may represent methods in accordance with the disclosed subject matter when disparate entities enact disparate portions of the methods. Furthermore, not all illustrated acts may be required to implement a described example method in accordance with the subject specification. Further yet, two or more of the disclosed example methods can be implemented in combination with each other, to accomplish one or more aspects herein described. It should be further appreciated that the example methods disclosed throughout the subject specification are capable of being stored on an article of manufacture (e.g., a computer-readable medium) to allow transporting and transferring such methods to computers for execution, and thus implementation, by a processor or for storage in a memory. 
       FIG.  6    illustrates a method  600  facilitating remote provisioning of drone resources in accordance with aspects of the subject disclosure. At  610 , method  600  can comprise receiving drone request information. In an embodiment, the drone request information can be received from a UE, such as, but not limited to a mobile device. Drone request information can comprise information related to requesting provisioning of a drone or drone related resource. Drone request information can comprise name, address, phone number, identification information, account information, profile information, certifications information, logged hours or other training, mission parameters, such as, but not limited to, mission location, mission time, mission duration, mission type, mission payload, mission controller or interaction devices/services, level of autonomy, other drones/devices associated with the mission, etc., clearances, permits, approvals, waivers, mission path, mission locus resources available, e.g., power, fuel, internet connectivity, etc., historical drone use, additional operators/controllers, etc. It will be noted that nearly any pertinent information can be included in drone request information. 
     In an embodiment, drone request information can be generated by a mobile device, a desktop computer, a laptop computer, a wearable computing device, etc. Moreover, drone request information can be originated by a first device, e.g., a mobile device, and can be supplemented with associated information from other devices. Further, drone request information can comprise information that can be used to infer parameters, allowing a device, such as DAC  110 - 410 , etc., to determine a drone that meets explicit and inferred parameters. It will be noted that nearly any information vector can be employed in inferring values that can be employed in determining satisfaction of a drone allocation parameter. 
     At  620 , method  600  can comprise determining drone allocation information based on the drone request information of  610 . Determining drone allocation information can include determining selection parameters from the drone request information of  610  and/or other supplemental information sources. Selection parameters can include, but are not limited to, a type of drone, a drone specification, a mission operating environment, drone availability, price, proximity, rules or laws, user profile, scheduling, a control interface or feature thereof, prior use of drones by the user, insurance features, intended use characteristics, certification, training, geographical or political boundaries, etc. Wherein, selection parameters can further be based on other information, for example, drone set information, drone information for drones comprising a drone set, weather information, schedule information related to persons related to the mission event, etc., such supplemental information can be received as part of method  600 , though not illustrated for clarity and brevity. The selection information can be employed to determine what, if any, drone in one or more sets of available drones satisfy drone allocation parameters based on drone request information and other related information. Additionally, selection parameters can identify a drone, a set of drones, multiple sets of drones, tiers of drones, etc. This information can be employed in determining, in conjunction with the selection information, a drone to provision. 
     At  630 , method  600  can comprise provisioning a drone based on drone allocation information from  620 . Drone provisioning information can be determined from drone allocation information and made accessible to one or more drones. As such, an allocated drone, e.g., a selected drone, can receive drone provisioning information. The drone can then indicate, either affirmatively, by absence of a refusal, etc., that it accepts being provisioned. 
     At  640 , method  600  can comprise, in response to the drone indicating that it accepts being provisioned, request response information can be generated, such as by DAC  110 - 410 , etc. At this point method  600  can end. Request response information can indicate that provisioning was successful, that selection of a drone was made but provisioning failed, that a drone could not be selected that met the parameters, alternate drones available and information on what parameters are not satisfied, etc. Request response information can function to provide information back to the requestor about the state of fulfilling a drone request, including information related to the provisioning of a drone. In some embodiments, request response information can further comprise a request for additional parameter information where a large set of drones meet the parameters. In further embodiments, request response information can comprise information related to user selection of an available drone, for example, where two drones are available and meet the parameters, the selection choice can be left to the user. 
     In an aspect, rather than provisioning a single drone, multiple drones can be provisioned and request response information can reflect information related to the provisioning of multiple drones. Moreover, where only one drone is needed from the set of provisioned drones, provisioned drones can be released from the provisioning according to one or more rules. In some embodiments, drone provisioning can occur in one drone set, in multiple drone sets, in one tier, or in multiple tiers. 
       FIG.  7    illustrates a method  700  that facilitates remote provisioning of drone resources based on drone information in accordance with aspects of the subject disclosure. At  710 , method  700  can comprise receiving drone request information. Drone request information can comprise information related to requesting provisioning of a drone or drone related resource. Drone request information can comprise name, address, phone number, identification information, account information, profile information, certifications information, logged hours or other training, mission parameters, such as, but not limited to, mission location, mission time, mission duration, mission type, mission payload, mission controller or interaction devices/services, level of autonomy, other drones/devices associated with the mission, etc., clearances, permits, approvals, waivers, mission path, mission locus resources available, e.g., power, fuel, internet connectivity, etc., historical drone use, additional operators/controllers, etc. It will be noted that nearly any pertinent information can be included in drone request information. 
     In an embodiment, drone request information can be generated by a mobile device, a desktop computer, a laptop computer, a wearable computing device, etc. Moreover, drone request information can be originated by a first device, e.g., a mobile device, and can be supplemented with associated information from other devices. Further, drone request information can comprise information that can be used to infer parameters, allowing a device, such as DAC  110 - 410 , etc., to determine a drone that meets explicit and inferred parameters. It will be noted that nearly any information vector can be employed in inferring values that can be employed in determining satisfaction of a drone allocation parameter. 
     At  720 , method  700  can comprise receiving drone profile information. Drone profile information can relate to features, characteristics, or availability of one or more drones, one or more sets of one or more drones, or one or more tiers of drones. Drone profile information can be compared to or filtered against explicit or implicit drone request information to enable selection of a drone that is appropriate for a mission based on the drone request information. In some embodiments, drones can populate drone profiles to facilitate rapid dissemination of drone profile information to devices that are employed in remote provisioning of drone resources, e.g., DAC  110 - 410 , etc. As such, this aspect can allow new drones to be added to sets of available drones that can be accessed by devices seeking to allocate drone resources, for example, drone profile information can enable a ‘plug-n-play’ type architecture for nearly anyone to add a drone to an internet-wide list of available drone resources. As such, drone profile information can comprise information related to the capabilities of the drone, modifications to the drone, payloads available, locations, ranges, availability, tier information, rules, pricing rates, restrictions, whitelists or blacklists of users, etc. 
     At  730 , method  700  can comprise determining drone allocation information based on the drone request information and the drone profile information. Determining drone allocation information can include determining selection parameters. Drone allocation information can further be based on other supplemental information sources relevant to the process. Selection parameters can include, but are not limited to, a type of drone, a drone specification, a mission operating environment, drone availability, price, proximity, rules or laws, user profile, scheduling, a control interface or feature thereof, prior use of drones by the user, insurance features, intended use characteristics, certification, training, geographical or political boundaries, etc. Selection parameters can further comprise information, such as, drone set information, drone information for drones comprising a drone set, weather information, schedule information related to persons related to the mission event, etc. The selection information can be employed to determine what, if any, drone in one or more sets of available drones satisfy drone allocation parameters. Additionally, selection parameters can identify a drone, a set of drones, multiple sets of drones, tiers of drones, etc. This information can be employed in determining, in conjunction with the selection information, a drone to provision. 
     At  740 , method  700  can comprise provisioning a drone based on drone allocation information from  720 . Drone provisioning information can be determined from drone allocation information and made accessible to one or more drones. As such, an allocated drone, e.g., a selected drone, can receive drone provisioning information. The drone can then indicate, either affirmatively, by absence of a refusal, etc., that it accepts being provisioned. 
     At  750 , method  700  can comprise, in response to the drone indicating that it accepts being provisioned, request response information can be generated, such as by DAC  110 - 410 , etc. At this point method  700  can end. Request response information can indicate that provisioning was successful, that selection of a drone was made but provisioning failed, that a drone could not be selected that met the parameters, alternate drones available and information on what parameters are not satisfied, etc. Request response information can function to provide information back to the requestor about the state of fulfilling a drone request, including information related to the provisioning of a drone. In some embodiments, request response information can further comprise a request for additional parameter information where a large set of drones meet the parameters. In further embodiments, request response information can comprise information related to user selection of an available drone, for example, where two drones are available and meet the parameters, the selection choice can be left to the user. 
     In an aspect, rather than provisioning a single drone, multiple drones can be provisioned and request response information can reflect information related to the provisioning of multiple drones. Moreover, where only one drone is needed from the set of provisioned drones, provisioned drones can be released from the provisioning according to one or more rules. In some embodiments, drone provisioning can occur in one drone set, in multiple drone sets, in one tier, or in multiple tiers. 
       FIG.  8    illustrates a method  800  that facilitates remote provisioning of drone resources organized in a tiered environment in accordance with aspects of the subject disclosure. At  810 , method  800  can comprise receiving drone request information. Drone request information can comprise information related to requesting provisioning of a drone or drone related resource. Drone request information can comprise name, address, phone number, identification information, account information, profile information, certifications information, logged hours or other training, mission parameters, such as, but not limited to, mission location, mission time, mission duration, mission type, mission payload, mission controller or interaction devices/services, level of autonomy, other drones/devices associated with the mission, etc., clearances, permits, approvals, waivers, mission path, mission locus resources available, e.g., power, fuel, internet connectivity, etc., historical drone use, additional operators/controllers, etc. It will be noted that nearly any pertinent information can be included in drone request information. 
     In an embodiment, drone request information can be generated by a mobile device, a desktop computer, a laptop computer, a wearable computing device, etc. Moreover, drone request information can be originated by a first device, e.g., a mobile device, and can be supplemented with associated information from other devices. Further, drone request information can comprise information that can be used to infer parameters, allowing a device, such as DAC  110 - 410 , etc., to determine a drone that meets explicit and inferred parameters. It will be noted that nearly any information vector can be employed in inferring values that can be employed in determining satisfaction of a drone allocation parameter. 
     At  820 , method  800  can comprise receiving tier one drone profile information. Drone profile information can relate to features, characteristics, or availability of one or more drones, one or more sets of one or more drones, or one or more tiers of drones. Drone profile information can be compared to or filtered against explicit or implicit drone request information to enable selection of a drone that is appropriate for a mission based on the drone request information. In some embodiments, drones can populate drone profiles to facilitate rapid dissemination of drone profile information to devices that are employed in remote provisioning of drone resources, e.g., DAC  110 - 410 , etc. As such, this aspect can allow new drones to be added to sets of available drones that can be accessed by devices seeking to allocate drone resources, for example, drone profile information can enable a ‘plug-n-play’ type architecture for nearly anyone to add a drone to an internet-wide list of available drone resources. As such, drone profile information can comprise information related to the capabilities of the drone, modifications to the drone, payloads available, locations, ranges, availability, tier information, rules, pricing rates, restrictions, whitelists or blacklists of users, etc. In an embodiment, drone profiles can be received for one or more drones comprising a tier one drone set. 
     At  830 , method  800  can comprise determining drone allocation value based on the drone request information and the tier one drone profile information. Determining drone allocation value can include determining selection parameters. A drone allocation value can further be based on other supplemental information sources relevant to the process. Selection parameters can include, but are not limited to, a type of drone, a drone specification, a mission operating environment, drone availability, price, proximity, rules or laws, user profile, scheduling, a control interface or feature thereof, prior use of drones by the user, insurance features, intended use characteristics, certification, training, geographical or political boundaries, etc. Selection parameters can further comprise information, such as, drone set information, drone information for drones comprising a drone set, weather information, schedule information related to persons related to the mission event, etc. The selection information can be employed to determine what, if any, drone in one or more sets of available drones satisfy drone allocation parameters. Additionally, selection parameters can identify a drone, a set of drones, multiple sets of drones, tiers of drones, etc. This information can be employed in determining, in conjunction with the selection information, a drone to provision. 
     At  840 , method  800  can comprise provisioning a tier one drone in response to the drone allocation value satisfying a rule related to allocating a tier one drone. Drone provisioning information can be determined from drone allocation information and made accessible to one or more drones of tier one. As such, an allocated drone, e.g., a selected drone, can receive drone provisioning information. The drone can then indicate, either affirmatively, by absence of a refusal, etc., that it accepts being provisioned. 
     At  850 , method  800  can comprise receiving tier two drone profile information. Drone profiles can be received for one or more drones comprising a tier two drone set. In an embodiment, where a drone has been provisioned at  840 , method  800  can skip to  870 . However, where no drone was provisioned at  840 , method  800  can evaluate tier two drones for mission fitness. In another embodiment, even where a tier one drone is provisioned at  840 , a drone from tier two can be additionally provisioned. In an aspect, this can provide redundancy or supplemental drone reservation based on the request. Moreover, where the tier one drone later initiates mission execution, the provision of the tier two drone can be released. 
     At  860 , method  800  can comprise provisioning a tier two drone in response to the drone allocation value satisfying a rule related to allocating a tier two drone. Drone provisioning information can be determined from drone allocation information and made accessible to one or more drones of tier two. As such, an allocated drone, e.g., a selected drone, can receive drone provisioning information. The drone can then indicate, either affirmatively, by absence of a refusal, etc., that it accepts being provisioned. 
     At  870 , method  800  can comprise, in response to the tier one and/or tier two drone indicating that it/they accept(s) being provisioned, request response information can be generated. At this point method  800  can end. Request response information can indicate that provisioning was successful, that selection of a drone(s) was made but provisioning failed, that a drone(s) could not be selected that met the parameters, alternate drone(s) available and information on what parameters are not satisfied, etc. Request response information can function to provide information back to the requestor about the state of fulfilling a drone(s) request, including information related to the provisioning of a drone(s). In some embodiments, request response information can further comprise a request for additional parameter information where a large set of drone(s) meet the parameters. In further embodiments, request response information can comprise information related to user selection of an available drone(s), for example, where two drones are available and meet the parameters, the selection of one or more drone(s) can be left to the user. 
     In an aspect, rather than provisioning a single tier one or tier two drone, multiple drones can be provisioned in either tier or between the tiers, and request response information can reflect information related to the provisioning of multiple drones. Moreover, where only one drone is needed from a set of provisioned drones, provisioned drones can be released from the provisioning according to one or more rules. In some embodiments, drone provisioning can occur in one drone set, in multiple drone sets, in one tier, or in multiple tiers. 
       FIG.  9    is a schematic block diagram of a computing environment  900  with which the disclosed subject matter can interact. The system  900  includes one or more remote component(s)  910 . The remote component(s)  910  can be hardware and/or software (e.g., threads, processes, computing devices). In some embodiments, remote component(s)  910  can include servers, personal servers, wireless telecommunication network devices, etc. As an example, remote component(s)  910  can be DAC  110 ,  210 ,  410 , etc., Drone  270 ,  372 ,  374 ,  376 , etc., Tier 1 drone  430 , tier 2 drone  472 , etc. 
     The system  900  also includes one or more local component(s)  920 . The local component(s)  920  can be hardware and/or software (e.g., threads, processes, computing devices). In some embodiments, local component(s)  920  can include, for example, UE  250 ,  350 ,  450 , etc., DAC  110 ,  310 ,  410 , etc. 
     One possible communication between a remote component(s)  910  and a local component(s)  920  can be in the form of a data packet adapted to be transmitted between two or more computer processes. Another possible communication between a remote component(s)  910  and a local component(s)  920  can be in the form of circuit-switched data adapted to be transmitted between two or more computer processes in radio time slots. The system  900  includes a communication framework  940  that can be employed to facilitate communications between the remote component(s)  910  and the local component(s)  920 , and can include an air interface, e.g., Uu interface of a UMTS network. Remote component(s)  910  can be operably connected to one or more remote data store(s)  950 , such as a hard drive, SIM card, device memory, etc., that can be employed to store information on the remote component(s)  910  side of communication framework  940 . Similarly, local component(s)  920  can be operably connected to one or more local data store(s)  930 , that can be employed to store information on the local component(s)  920  side of communication framework  940 . 
     In order to provide a context for the various aspects of the disclosed subject matter,  FIG.  10   , and the following discussion, are intended to provide a brief, general description of a suitable environment in which the various aspects of the disclosed subject matter can be implemented. While the subject matter has been described above in the general context of computer-executable instructions of a computer program that runs on a computer and/or computers, those skilled in the art will recognize that the disclosed subject matter also can be implemented in combination with other program modules. Generally, program modules include routines, programs, components, data structures, etc. that performs particular tasks and/or implement particular abstract data types. 
     In the subject specification, terms such as “store,” “storage,” “data store,” data storage,” “database,” and substantially any other information storage component relevant to operation and functionality of a component, refer to “memory components,” or entities embodied in a “memory” or components comprising the memory. It is noted that the memory components described herein can be either volatile memory or nonvolatile memory, or can include both volatile and nonvolatile memory, by way of illustration, and not limitation, volatile memory  1020  (see below), non-volatile memory  1022  (see below), disk storage  1024  (see below), and memory storage  1046  (see below). Further, nonvolatile memory can be included in read only memory, programmable read only memory, electrically programmable read only memory, electrically erasable read only memory, or flash memory. Volatile memory can include random access memory, which acts as external cache memory. By way of illustration and not limitation, random access memory is available in many forms such as synchronous random access memory, dynamic random access memory, synchronous dynamic random access memory, double data rate synchronous dynamic random access memory, enhanced synchronous dynamic random access memory, Synchlink dynamic random access memory, and direct Rambus random access memory. Additionally, the disclosed memory components of systems or methods herein are intended to comprise, without being limited to comprising, these and any other suitable types of memory. 
     Moreover, it is noted that the disclosed subject matter can be practiced with other computer system configurations, including single-processor or multiprocessor computer systems, mini-computing devices, mainframe computers, as well as personal computers, hand-held computing devices (e.g., personal digital assistant, phone, watch, tablet computers, netbook computers, . . . ), microprocessor-based or programmable consumer or industrial electronics, and the like. The illustrated aspects can also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network; however, some if not all aspects of the subject disclosure can be practiced on stand-alone computers. In a distributed computing environment, program modules can be located in both local and remote memory storage devices. 
       FIG.  10    illustrates a block diagram of a computing system  1000  operable to execute the disclosed systems and methods in accordance with an embodiment. Computer  1012 , which can be, for example, part of DAC  11 -,  21 -,  310 ,  410 , etc., drone  270 ,  372 ,  374 ,  376 , etc., tier 1 drone  470 , tier 2 drone  472 , etc., UE  250 ,  350 ,  550 , etc., includes a processing unit  1014 , a system memory  1016 , and a system bus  1018 . System bus  1018  couples system components including, but not limited to, system memory  1016  to processing unit  1014 . Processing unit  1014  can be any of various available processors. Dual microprocessors and other multiprocessor architectures also can be employed as processing unit  1014 . 
     System bus  1018  can be any of several types of bus structure(s) including a memory bus or a memory controller, a peripheral bus or an external bus, and/or a local bus using any variety of available bus architectures including, but not limited to, industrial standard architecture, micro-channel architecture, extended industrial standard architecture, intelligent drive electronics, video electronics standards association local bus, peripheral component interconnect, card bus, universal serial bus, advanced graphics port, personal computer memory card international association bus, Firewire (Institute of Electrical and Electronics Engineers  1194 ), and small computer systems interface. 
     System memory  1016  can include volatile memory  1020  and nonvolatile memory  1022 . A basic input/output system, containing routines to transfer information between elements within computer  1012 , such as during start-up, can be stored in nonvolatile memory  1022 . By way of illustration, and not limitation, nonvolatile memory  1022  can include read only memory, programmable read only memory, electrically programmable read only memory, electrically erasable read only memory, or flash memory. Volatile memory  1020  includes read only memory, which acts as external cache memory. By way of illustration and not limitation, read only memory is available in many forms such as synchronous random access memory, dynamic read only memory, synchronous dynamic read only memory, double data rate synchronous dynamic read only memory, enhanced synchronous dynamic read only memory, Synchlink dynamic read only memory, Rambus direct read only memory, direct Rambus dynamic read only memory, and Rambus dynamic read only memory. 
     Computer  1012  can also include removable/non-removable, volatile/non-volatile computer storage media.  FIG.  10    illustrates, for example, disk storage  1024 . Disk storage  1024  includes, but is not limited to, devices like a magnetic disk drive, floppy disk drive, tape drive, flash memory card, or memory stick. In addition, disk storage  1024  can include storage media separately or in combination with other storage media including, but not limited to, an optical disk drive such as a compact disk read only memory device, compact disk recordable drive, compact disk rewritable drive or a digital versatile disk read only memory. To facilitate connection of the disk storage devices  1024  to system bus  1018 , a removable or non-removable interface is typically used, such as interface  1026 . 
     Computing devices typically include a variety of media, which can include computer-readable storage media or communications media, which two terms are used herein differently from one another as follows. 
     Computer-readable storage media can be any available storage media that can be accessed by the computer and includes both volatile and nonvolatile media, removable and non-removable media. By way of example, and not limitation, computer-readable storage media can be implemented in connection with any method or technology for storage of information such as computer-readable instructions, program modules, structured data, or unstructured data. Computer-readable storage media can include, but are not limited to, read only memory, programmable read only memory, electrically programmable read only memory, electrically erasable read only memory, flash memory or other memory technology, compact disk read only memory, digital versatile disk or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or other tangible media which can be used to store desired information. In this regard, the term “tangible” herein as may be applied to storage, memory or computer-readable media, is to be understood to exclude only propagating intangible signals per se as a modifier and does not relinquish coverage of all standard storage, memory or computer-readable media that are not only propagating intangible signals per se. In an aspect, tangible media can include non-transitory media wherein the term “non-transitory” herein as may be applied to storage, memory or computer-readable media, is to be understood to exclude only propagating transitory signals per se as a modifier and does not relinquish coverage of all standard storage, memory or computer-readable media that are not only propagating transitory signals per se. Computer-readable storage media can be accessed by one or more local or remote computing devices, e.g., via access requests, queries or other data retrieval protocols, for a variety of operations with respect to the information stored by the medium. As such, for example, a computer-readable medium can comprise executable instructions stored thereon that, in response to execution, cause a system comprising a processor to perform operations, comprising: receiving drone request information a request for data via an air interface or other wireless interface from a remote device, e.g., UE  250 ,  550 , etc., and in response to the receiving drone request information, generating drone provisioning information that can be accessed via an air interface or other wireless interface by one or more drones to enable remote provisioning of a drone resource. 
     Communications media typically embody computer-readable instructions, data structures, program modules or other structured or unstructured data in a data signal such as a modulated data signal, e.g., a carrier wave or other transport mechanism, and includes any information delivery or transport media. The term “modulated data signal” or signals refers to a signal that has one or more of its characteristics set or changed in such a manner as to encode information in one or more signals. By way of example, and not limitation, communication media include wired media, such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media. 
     It can be noted that  FIG.  10    describes software that acts as an intermediary between users and computer resources described in suitable operating environment  1000 . Such software includes an operating system  1028 . Operating system  1028 , which can be stored on disk storage  1024 , acts to control and allocate resources of computer system  1012 . System applications  1030  take advantage of the management of resources by operating system  1028  through program modules  1032  and program data  1034  stored either in system memory  1016  or on disk storage  1024 . It is to be noted that the disclosed subject matter can be implemented with various operating systems or combinations of operating systems. 
     A user can enter commands or information into computer  1012  through input device(s)  1036 . As an example, a user interface can allow entry of user preference information, etc., and can be embodied in a touch sensitive display panel, a mouse input GUI, a command line controlled interface, etc., allowing a user to interact with computer  1012 . As an example, UI Component  584  can receive touch, motion, audio, visual, or other types of input. Input devices  1036  include, but are not limited to, a pointing device such as a mouse, trackball, stylus, touch pad, keyboard, microphone, joystick, game pad, satellite dish, scanner, TV tuner card, digital camera, digital video camera, web camera, cell phone, smartphone, tablet computer, etc. These and other input devices connect to processing unit  1014  through system bus  1018  by way of interface port(s)  1038 . Interface port(s)  1038  include, for example, a serial port, a parallel port, a game port, a universal serial bus, an infrared port, a Bluetooth port, an IP port, or a logical port associated with a wireless service, etc. Output device(s)  1040  use some of the same type of ports as input device(s)  1036 . 
     Thus, for example, a universal serial busport can be used to provide input to computer  1012  and to output information from computer  1012  to an output device  1040 . Output adapter  1042  is provided to illustrate that there are some output devices  1040  like monitors, speakers, and printers, among other output devices  1040 , which use special adapters. Output adapters  1042  include, by way of illustration and not limitation, video and sound cards that provide means of connection between output device  1040  and system bus  1018 . It should be noted that other devices and/or systems of devices provide both input and output capabilities such as remote computer(s)  1044 . As an example, vehicle subsystems, such as headlights, brake lights, stereos, vehicle information sharing device, etc., can include an output adapter  1042  to enable use in accordance with the presently disclosed subject matter. 
     Computer  1012  can operate in a networked environment using logical connections to one or more remote computers, such as remote computer(s)  1044 . Remote computer(s)  1044  can be a personal computer, a server, a router, a network PC, cloud storage, cloud service, a workstation, a microprocessor based appliance, a peer device, or other common network node and the like, and typically includes many or all of the elements described relative to computer  1012 . 
     For purposes of brevity, only a memory storage device  1046  is illustrated with remote computer(s)  1044 . Remote computer(s)  1044  is logically connected to computer  1012  through a network interface  1048  and then physically connected by way of communication connection  1050 . Network interface  1048  encompasses wire and/or wireless communication networks such as local area networks and wide area networks. Local area network technologies include fiber distributed data interface, copper distributed data interface, Ethernet, Token Ring and the like. Wide area network technologies include, but are not limited to, point-to-point links, circuit-switching networks like integrated services digital networks and variations thereon, packet switching networks, and digital subscriber lines. As noted below, wireless technologies may be used in addition to or in place of the foregoing. 
     Communication connection(s)  1050  refer(s) to hardware/software employed to connect network interface  1048  to bus  1018 . While communication connection  1050  is shown for illustrative clarity inside computer  1012 , it can also be external to computer  1012 . The hardware/software for connection to network interface  1048  can include, for example, internal and external technologies such as modems, including regular telephone grade modems, cable modems and digital subscriber line modems, integrated services digital network adapters, and Ethernet cards. 
     The above description of illustrated embodiments of the subject disclosure, including what is described in the Abstract, is not intended to be exhaustive or to limit the disclosed embodiments to the precise forms disclosed. While specific embodiments and examples are described herein for illustrative purposes, various modifications are possible that are considered within the scope of such embodiments and examples, as those skilled in the relevant art can recognize. 
     In this regard, while the disclosed subject matter has been described in connection with various embodiments and corresponding Figures, where applicable, it is to be understood that other similar embodiments can be used or modifications and additions can be made to the described embodiments for performing the same, similar, alternative, or substitute function of the disclosed subject matter without deviating therefrom. Therefore, the disclosed subject matter should not be limited to any single embodiment described herein, but rather should be construed in breadth and scope in accordance with the appended claims below. 
     As it employed in the subject specification, the term “processor” can refer to substantially any computing processing unit or device comprising, but not limited to comprising, single-core processors; single-processors with software multithread execution capability; multi-core processors; multi-core processors with software multithread execution capability; multi-core processors with hardware multithread technology; parallel platforms; and parallel platforms with distributed shared memory. Additionally, a processor can refer to an integrated circuit, an application specific integrated circuit, a digital signal processor, a field programmable gate array, a programmable logic controller, a complex programmable logic device, a discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. Processors can exploit nano-scale architectures such as, but not limited to, molecular and quantum-dot based transistors, switches and gates, in order to optimize space usage or enhance performance of user equipment. A processor may also be implemented as a combination of computing processing units. 
     As used in this application, the terms “component,” “system,” “platform,” “layer,” “selector,” “interface,” and the like are intended to refer to a computer-related entity or an entity related to an operational apparatus with one or more specific functionalities, wherein the entity can be either hardware, a combination of hardware and software, software, or software in execution. As an example, a component may be, but is not limited to being, a process running on a processor, a processor, an object, an executable, a thread of execution, a program, and/or a computer. By way of illustration and not limitation, both an application running on a server and the server can be a component. One or more components may reside within a process and/or thread of execution and a component may be localized on one computer and/or distributed between two or more computers. In addition, these components can execute from various computer readable media having various data structures stored thereon. The components may communicate via local and/or remote processes such as in accordance with a signal having one or more data packets (e.g., data from one component interacting with another component in a local system, distributed system, and/or across a network such as the Internet with other systems via the signal). As another example, a component can be an apparatus with specific functionality provided by mechanical parts operated by electric or electronic circuitry, which is operated by a software or firmware application executed by a processor, wherein the processor can be internal or external to the apparatus and executes at least a part of the software or firmware application. As yet another example, a component can be an apparatus that provides specific functionality through electronic components without mechanical parts, the electronic components can include a processor therein to execute software or firmware that confers at least in part the functionality of the electronic components. 
     In addition, the term “or” is intended to mean an inclusive “or” rather than an exclusive “or.” That is, unless specified otherwise, or clear from context, “X employs A or B” is intended to mean any of the natural inclusive permutations. That is, if X employs A; X employs B; or X employs both A and B, then “X employs A or B” is satisfied under any of the foregoing instances. Moreover, articles “a” and “an” as used in the subject specification and annexed drawings should generally be construed to mean “one or more” unless specified otherwise or clear from context to be directed to a singular form. 
     Further, the term “include” is intended to be employed as an open or inclusive term, rather than a closed or exclusive term. The term “include” can be substituted with the term “comprising” and is to be treated with similar scope, unless otherwise explicitly used otherwise. As an example, “a basket of fruit including an apple” is to be treated with the same breadth of scope as, “a basket of fruit comprising an apple.” 
     Moreover, terms like “user equipment (UE),” “mobile station,” “mobile,” subscriber station,” “subscriber equipment,” “access terminal,” “terminal,” “handset,” and similar terminology, refer to a wireless device utilized by a subscriber or user of a wireless communication service to receive or convey data, control, voice, video, sound, gaming, or substantially any data-stream or signaling-stream. The foregoing terms are utilized interchangeably in the subject specification and related drawings. Likewise, the terms “access point,” “base station,” “Node B,” “evolved Node B,” “eNodeB,” “home Node B,” “home access point,” and the like, are utilized interchangeably in the subject application, and refer to a wireless network component or appliance that serves and receives data, control, voice, video, sound, gaming, or substantially any data-stream or signaling-stream to and from a set of subscriber stations or provider enabled devices. Data and signaling streams can include packetized or frame-based flows. 
     Additionally, the terms “core-network”, “core”, “core carrier network”, “carrier-side”, or similar terms can refer to components of a telecommunications network that typically provides some or all of aggregation, authentication, call control and switching, charging, service invocation, or gateways. Aggregation can refer to the highest level of aggregation in a service provider network wherein the next level in the hierarchy under the core nodes is the distribution networks and then the edge networks. UEs do not normally connect directly to the core networks of a large service provider but can be routed to the core by way of a switch or radio access network. Authentication can refer to determinations regarding whether the user requesting a service from the telecom network is authorized to do so within this network or not. Call control and switching can refer determinations related to the future course of a call stream across carrier equipment based on the call signal processing. Charging can be related to the collation and processing of charging data generated by various network nodes. Two common types of charging mechanisms found in present day networks can be prepaid charging and postpaid charging. Service invocation can occur based on some explicit action (e.g. call transfer) or implicitly (e.g., call waiting). It is to be noted that service “execution” may or may not be a core network functionality as third party network/nodes may take part in actual service execution. A gateway can be present in the core network to access other networks. Gateway functionality can be dependent on the type of the interface with another network. 
     Furthermore, the terms “user,” “subscriber,” “customer,” “consumer,” “prosumer,” “agent,” and the like are employed interchangeably throughout the subject specification, unless context warrants particular distinction(s) among the terms. It should be appreciated that such terms can refer to human entities or automated components (e.g., supported through artificial intelligence, as through a capacity to make inferences based on complex mathematical formalisms), that can provide simulated vision, sound recognition and so forth. 
     Aspects, features, or advantages of the subject matter can be exploited in substantially any, or any, wired, broadcast, wireless telecommunication, radio technology or network, or combinations thereof. Non-limiting examples of such technologies or networks include broadcast technologies (e.g., sub-Hertz, extremely low frequency, very low frequency, low frequency, medium frequency, high frequency, very high frequency, ultra-high frequency, super-high frequency, terahertz broadcasts, etc.); Ethernet; X.25; powerline-type networking, e.g., Powerline audio video Ethernet, etc.; femtocell technology; Wi-Fi; worldwide interoperability for microwave access; enhanced general packet radio service; third generation partnership project, long term evolution; third generation partnership project universal mobile telecommunications system; third generation partnership project 2, ultra mobile broadband; high speed packet access; high speed downlink packet access; high speed uplink packet access; enhanced data rates for global system for mobile communication evolution radio access network; universal mobile telecommunications system terrestrial radio access network; or long term evolution advanced. 
     What has been described above includes examples of systems and methods illustrative of the disclosed subject matter. It is, of course, not possible to describe every combination of components or methods herein. One of ordinary skill in the art may recognize that many further combinations and permutations of the claimed subject matter are possible. Furthermore, to the extent that the terms “includes,” “has,” “possesses,” and the like are used in the detailed description, claims, appendices and drawings such terms are intended to be inclusive in a manner similar to the term “comprising” as “comprising” is interpreted when employed as a transitional word in a claim.