WO2013004497A1 - Methods and systems for resource allocation - Google Patents

Methods and systems for resource allocation Download PDF

Info

Publication number
WO2013004497A1
WO2013004497A1 PCT/EP2012/061824 EP2012061824W WO2013004497A1 WO 2013004497 A1 WO2013004497 A1 WO 2013004497A1 EP 2012061824 W EP2012061824 W EP 2012061824W WO 2013004497 A1 WO2013004497 A1 WO 2013004497A1
Authority
WO
WIPO (PCT)
Prior art keywords
resource
user
idle time
requesting
current user
Prior art date
Application number
PCT/EP2012/061824
Other languages
English (en)
French (fr)
Inventor
Ritu SAMA
Parashar SHAH
Original Assignee
Alcatel Lucent
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Alcatel Lucent filed Critical Alcatel Lucent
Publication of WO2013004497A1 publication Critical patent/WO2013004497A1/en

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/70Admission control; Resource allocation
    • H04L47/82Miscellaneous aspects
    • H04L47/826Involving periods of time
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/70Admission control; Resource allocation
    • H04L47/82Miscellaneous aspects
    • H04L47/823Prediction of resource usage
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/70Admission control; Resource allocation
    • H04L47/83Admission control; Resource allocation based on usage prediction
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/70Admission control; Resource allocation
    • H04L47/78Architectures of resource allocation
    • H04L47/781Centralised allocation of resources
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/70Admission control; Resource allocation
    • H04L47/82Miscellaneous aspects
    • H04L47/822Collecting or measuring resource availability data

Definitions

  • the present subject matter relates to resource allocation and, particularly but not exclusively, to allocation of resources for sharing the resources between contending users.
  • a resource is allocated to a user for a pre-defined duration of time. During this pre-defined time no other user is allowed to use the resource and requests for the resource from all other users are kept pending. Only after the first user has finished using the resource, the resource is allocated to the next user.
  • the resource may be allocated to a user not on the basis of the order of receiving the request, but on the basis of urgency and priority. In some cases, pre-arranged sharing of the resource may take place.
  • the resource may be shared.
  • a particular resource is allocated to more than one user, each contending for the idle time of the resource, mainly through word of mouth.
  • a system for resource allocation includes a processor and a memory, coupled to the processor, having an idle time detection module and a resource allocation module.
  • the idle time detection module is configured to determine an idle time of a resource based on at least one of operation data and historical data of the resource.
  • the resource allocation module is configured to allocate the resource to a selected requesting user during the idle time.
  • the resource allocation module selects the selected requesting user from one or more requesting users based on requests received from the one or more requesting users.
  • a computer implemented method for allocating resources includes receiving, from a network device, operation data of a resource allocated to a current user. Based on the operation data, an idle time of the resource is determined. The computer implemented method also includes comparing a request received for allocation of the resource from one or more requesting users with activities performed by the current user on the resource. The method further includes allocating the resource, for the idle time duration, to a selected requesting user from amongst the one or more requesting users based on the comparison.
  • a computer readable medium has a computer program for executing a method for allocating resources.
  • the computer program when executed, performs acts including determining an idle time of a resource allocated to a current user. Further, a requesting user is selected from one or more requesting users based on the determined idle time and the resource is allocated to the selected requesting user for the idle time duration.
  • Figure 1 illustrates a network environment implementing a resource allocation system for idle time detection and resource allocation, according to one embodiment of the present subject matter
  • Figure 2 illustrates the resource allocation system, in accordance with an embodiment of the present subject matter.
  • Figure 3 illustrates a method for idle time detection and resource allocation, in accordance with an embodiment of the present subject matter.
  • an idle time such as ad-hoc idle time
  • an idle time usually goes unnoticed if the user currently using the resource does not inform the other users waiting for the resource that the resource is free.
  • a testing lab for testing network equipments is to be shared amongst five users
  • users 2-5 have to wait for the testing lab to become free.
  • user 1 may leave the testing lab for debugging due to which the network equipment may be left idle for 2 hours.
  • the users 2-5 would not know this unless user 1 informs them or the lab administrator.
  • testing lab in case the testing lab is not available, an interested user may contact the lab administrator and the resource may get allocated only if the resource is free or there is urgency. In some other scenarios, the interested user may track the resource and the resource may be acquired based on word of mouth. For example, a current user may inform the interested user that the resource will be free for certain time duration and the interested user may use the resource during that time.
  • a user currently using the resource also referred to as a current user
  • a current user is registered by providing different inputs, such as an activity planned by the user, an approximate time required to complete the activity, an expected idle time of the resource, requirements and conditions of the current user, and user specific information.
  • the user specific information can include a variety of information, such as email-id and mobile number of the current user.
  • a status of the resource is indicated as occupied for a duration mentioned by the current user.
  • one or more requesting users interested in using that resource during an overlapping time duration are registered by providing information similar to that provided by the current user.
  • the background process analyzes the activities performed on the network equipment and determines the CPU utilization, disk utilization, and memory utilization of the processes being used by the current user to run the test scenarios. If the CPU utilization is below the threshold value, the resource is assumed to be idle.
  • the idle time may also be predicted by analyzing the historical data of the resource or the current user.
  • the historical data on call processing is fetched and analyzed to predict the idle time of the resource, i.e., past scenarios are analyzed to determine the actual idle time.
  • actual time required for using the resource by the current user and the requesting user may also be determined.
  • the requests of the requesting users are analyzed to allocate the resource for the idle time.
  • the requests may be analyzed and compared sequentially. For example, a request of the first requesting user may be analyzed first, followed by an analysis of a request of a second requesting user, and so on. In another implementation, the requests may be analyzed and compared based on a parameter, such as priority. [0020] Further, the requests of the requesting users are analyzed and compared with the information provided by the current user to determine whether the resource can be allocated to a certain requesting user.
  • the time required by the requesting users along with the activities planned by the requesting users are compared with the idle time of the resource, activities performed by the current user, and the conditions specified by the current user to allocate the resource to a certain requesting user. For example, time required by the first requesting user is compared with the idle time. Also, activities planned by the first requesting user can be compared with the activities performed by the current user and the conditions specified by the current user. If the activities planned by the first requesting user do not affect the activities performed by the current user, the resource is allocated to the first requesting user. If the activities planned by the first requesting user affect the activities of the current user, the resource is not allocated to the first requesting user and the request of the second requesting user is analyzed instead.
  • a health of the resource is also determined before allocating a resource to a requesting user.
  • the health of the resource refers to the usability of the resource.
  • the current user is requested to confirm whether the resource can be allocated to the requesting user. If the current user allows the allocation of the resource, the resource is allocated to the requesting user. If the current user rejects the allocation of the resource to the requesting user, pending requests from other requesting users may be analyzed. In one implementation, the requesting user whose request is rejected may again be identified as a requesting user, and the rejected requesting user may again be added to a queue of requesting users.
  • the resource After selecting the requesting user to whom the resource may be allocated, and the health of the resource, the resource can be allocated and a message can be sent to the selected requesting user regarding the allocation.
  • the settings such as the runtime conditions required by the selected requesting user and as permitted by the current user, are provided to the selected requesting user before allocating the resource.
  • the idle time detection and resource allocation achieved according to the present subject matter considerably reduces the time spent by the requesting user in determining whether the resource is available or not, and allows for sharing of resources during idle time, even ad-hoc idle time. Also, the user can get the required settings before starting to use the resource. As a result, the resources are efficiently used, resulting in cost saving and less wastage of resources.
  • Figure 1 illustrates a network environment 100 implementing a resource allocation system 102, in accordance with an embodiment of the present subject matter.
  • the resource allocation system 102 can be implemented in any network environment comprising a variety of network devices, including routers, bridges, servers, computing devices, storage devices, etc.
  • the resource allocation system 102 can be implemented as a variety of computing devices, such as a laptop computer, a desktop computer, a notebook, a workstation, a mainframe computer, and a server.
  • the resource allocation system 102 is configured to detect and allocate an idle time of a resource to a requesting user.
  • the resource allocation system 102 includes an idle time detection module 110 and a resource allocation module 112.
  • the idle time detection module 110 detects an idle time of the resource and the resource allocation module 112, based on the idle time, may allocate the resource to one or more requesting users.
  • the resource allocation system 102 is connected through a communication network 104 to current user devices 106-1 , 106-2, 106-N, collectively referred to as current user devices 106, and requesting user devices 108-1 , 108-2,....,108-N, collectively referred to as requesting user devices 108.
  • the current user devices 106 and the requesting user devices 108 may include computing devices, such as a laptop computer, a desktop computer, a notebook, a mobile phone, a personal digital assistant, a workstation, and a mainframe computer.
  • the user devices 106 and 108 facilitate interaction of current users and requesting users, respectively, with the resource allocation system 102, either directly or through the communication network 104.
  • the communication network 104 may be wireless or wired network, or a combination thereof.
  • the communication network 104 can be a combination of individual networks, interconnected with each other and functioning as a single large network, for example, the Internet or an intranet.
  • the communication network 104 may be any public or private network, including a local area network (LAN), a wide area network (WAN), the Internet, an intranet, and a virtual private network (VPN), and may include a variety of network devices, such as routers, bridges, servers, computing devices, and storage devices.
  • LAN local area network
  • WAN wide area network
  • VPN virtual private network
  • the resource allocation system 102 receives a request for a resource which is allocated to a current user, from one or more requesting users.
  • the resource allocation system 102 may allocate the resource to a requesting user, if the resource is found to be idle.
  • the idle time detection module 110 detects the idle time of the resource.
  • the idle time detection module 1 10 receives usage data, also referred to as operation data, from one or more network devices (not shown in the figure) communicatively coupled to the resource allocation system 102.
  • the network devices provide the operation data from, for example, one or more background processes or sensors monitoring the resource usage.
  • the network devices are a part of the resource.
  • the network devices are connected to the resource, for example, through the communication network 104.
  • the idle time detection module 110 Based on the operation data, the idle time detection module 110 detects the idle time of the resource. In another implementation, the idle time detection module 110 may also predict the idle time of the resource based on historical data of the resource and of the current user using the resource.
  • the idle time detection module 110 detects that the resource is idle, if the resource is currently not allocated to any user and is free to be used. In another implementation, the idle time detection module 1 10 detects that the resource is idle if the resource is allocated to the current user, but the current user has not used the resource for a pre-defined time duration.
  • the idle time detection module 110 analyzes activities performed on one or more equipments by the current user.
  • the idle time detection module 110 may determine the CPU utilization during the testing, using operation data of RNC 1 monitored by, for example, a background process. This data may be provided to the idle time detection module 110 through a network device. If the CPU utilization is below a specified threshold value, the idle time detection module 1 10 may determine that RNC 1 is idle.
  • RNC radio network controller
  • the idle time detection module 1 10 is also configured to predict the idle time of the resource.
  • the idle time detection module 110 may analyze historical data based on automated testing. The idle time detection module 110 may determine that, subsequent to the execution of an automated test, the testing lab may be idle, even if the desired back up of the data takes place for the automated test, i.e., after 2 pm the lab would be idle. After predicting the idle time, the idle time detection module 110 may also confirm from the current user whether the resource will actually be idle for the duration of idle time predicted by the idle time detection module 1 10.
  • the idle time detection module 110 determines the total duration of the idle time.
  • the idle time detection module 1 10 analyzes the historical data or statistical data, or both to predict the approximate duration of the idle time.
  • Statistical data is used to determine the idle time by analyzing the historical information on the type of activity planned. For example if the current user is performing a call processing test, the idle time can be analyzed based on the typical amount of time taken in the past by different users for a similar activity and the expected idle time can be determined accordingly.
  • the duration of the idle time may also be provided by the current user. In the above example, consider a case where RNC 1 is currently idle, i.e., the CPU utilization is below the specified threshold.
  • the idle time detection module 1 10 analyzes the historical data of the current user to determine the time and total duration for which the current user typically takes a break. If the current user takes a break for 2 hours, this duration can be predicted as the duration of the idle time.
  • the idle time detection module 1 10 may also analyze the historical data on a call processing testing and determine the duration of the idle time for the test scenario. Based on the historical data, the duration of the idle time is predicted.
  • the idle time detection module 1 10 may also enquire from the current user whether the resource will actually be idle for that duration. In another implementation, if the current user has finished working on the resource, the resource may be assumed to be free and can be allocated to the requesting user. For example, the idle time detection module 1 10 may determine whether the current user has finished testing on RNC 1 . In one example, background processes may be used to determine whether the processes that were running on RNC 1 have been completed and there are no processes currently in use. This can be used as an indication that the current user has completed using RNC 1 . In such a case, RNC 1 is considered to be idle and available for allocation to the requesting user.
  • the resource allocation module 1 12 analyzes the requests received from the requesting users.
  • the resource allocation module 1 12 may analyze the request on the principal of first-in- first-out (FIFO), i.e., the first request is given the highest preference.
  • FIFO first-in- first-out
  • other methods of request scheduling may be used, i.e., on the basis of priority or urgency.
  • the resource allocation module 1 12 may analyze the request of the first requesting user which may be for Operation & Maintenance (O&M) testing on RNC 1 .
  • the request may include information, such as equipment required for testing, software version, time required for executing the test, and specific requirements.
  • the requesting users interact with the resource allocation module 1 12 through requesting user devices 108.
  • the resource allocation module 1 12 After analyzing the requests from the requesting users, the resource allocation module 1 12 compares the requests received from the requesting users with the activities performed by the current user and the condition specified by the current user. If the activities requested by the requesting user do not affect the activities of the current user, the resource allocation module 1 12 determines that the resource can be allocated. The resource allocation module 1 12 may determine that the request from the first requesting user does not affect the activities performed by current user based on the conditions specified by the current user, and therefore the resource can be allocated to first requesting user. For example, if current user is performing call processing functions on RNC 1 using software version A from 10am to 4pm. Also, during the registration the current user may have specified that the software version should not be changed for the duration of test.
  • the idle time is detected between 1pm and 2pm. If the first requesting user wants to execute O&M on RNC 1 for 1 hour, with software version B, the resource allocation module 1 12 will reject the request, as the current user had specified that software version should not change. If the second requesting user wants to execute O&M on RNC 1 for 1 hour with software version A, the resource allocation system 1 12 will accept the request as the conditions specified by the current user are met.
  • the resource allocation module 1 12 determines the health of the resource, i.e., whether the resource is in a condition to be allocated or not. After determining the health, the resource allocation module 1 12 may request the current user to confirm whether the resource can be allocated or not. If the current user allows the resource to be allocated, the resource allocation module 1 12 sends a notification to the requesting user.
  • the notification can be sent through different modes, such as an email, a Short Message Service (SMS), or an automated voice call.
  • SMS Short Message Service
  • Figure 2 illustrates components of the resource allocation system 102 for idle time detection and allocation, in accordance with an embodiment of the present subject matter.
  • the resource allocation system 102 include, but are not limited to, computing device, such as mainframe computers, workstations, personal computers, desktop computers, minicomputers, servers, multiprocessor systems, and laptops; and a cellular communicating device, such as a personal digital assistant, a smart phone, and a mobile phone.
  • the resource allocation system 102 hereinafter referred to as the system 102, includes one or more processors) 202, interface(s) 204, and a memory 206 coupled to the processor 202.
  • the processor 202 can be a single processing unit or a number of units, all of which could also include multiple computing units.
  • the processor 202 may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuitries, and/or any devices that manipulate signals based on operational instructions.
  • the processor 202 is configured to fetch and execute computer-readable instructions and data stored in the memory 206.
  • processors may be provided through the use of dedicated hardware as well as hardware capable of executing software in association with appropriate software.
  • the functions may be provided by a single dedicated processor, by a single shared processor, or by a plurality of individual processors, some of which may be shared.
  • explicit use of the term "processor” should not be construed to refer exclusively to hardware capable of executing software, and may implicitly include, without limitation, digital signal processor (DSP) hardware, network processor, application specific integrated circuit (ASIC), field programmable gate array (FPGA), read only memory (ROM) for storing software, random access memory (RAM), and non volatile storage.
  • DSP digital signal processor
  • ASIC application specific integrated circuit
  • FPGA field programmable gate array
  • ROM read only memory
  • RAM random access memory
  • non volatile storage Other hardware, conventional and/or custom, may also be included.
  • the I/O interfaces 204 may include a variety of software and hardware interfaces, for example, interface for peripheral device(s), such as a keyboard, a mouse, an external memory, and a printer. Further, the I/O interfaces 106 may enable the system 102 to communicate with other computing devices, such as a personal computer, a laptop, and like.
  • the memory 206 may include any computer-readable medium known in the art including, for example, volatile memory such as static random access memory (SRAM) and dynamic random access memory (DRAM), and/or non-volatile memory, such as read only memory (ROM), erasable programmable ROM, flash memories, hard disks, optical disks, and magnetic tapes.
  • the memory 108 also includes module(s) 208 and data 210.
  • the module(s) 208 include routines, programs, objects, components, data structures, etc., which perform particular tasks or implement particular abstract data types.
  • the module(s) 208 further include a registration module 212, the idle time detection module 1 10, the resource allocation module 112, and other module(s) 218.
  • the idle time detection module 110 includes an analysis module 214 and a prediction module 216.
  • the other module(s) 218 may include programs or coded instructions that supplement applications and functions of the system 102.
  • the data 210 serves as a repository for storing data processed, received, and generated by one or more of the module(s) 208.
  • the data 210 includes, for example, user data 220, historical data 222, operation data 224, and other data 226.
  • the other data 226 includes data generated as a result of the execution of one or more modules in the other module(s) 208.
  • the system 102 is configured to detect the idle time of the resource and allocate the resource to a requesting user for the idle time.
  • the user currently using the resource also referred to as current user
  • users requesting for the usage of that resource also referred to as requesting users
  • the registration module 212 registers the current user of a resource and requesting users of the resource.
  • the current user can register through the current user device 106 and the requesting users can register through requesting user device 108.
  • the registration module 212 requests different inputs from the current user.
  • the different inputs can include activity planned on the resource, approximate time required to complete the activity, expected idle time, specific requirements of the current user, and other user- specific information, such as department, email-id, and mobile number.
  • the inputs provided by the current user also referred to as first user data, are stored as part of user data 220.
  • user data 220 For an example of a testing lab where the current user interested in using the testing lab provides usage related information, such as call processing testing to be performed by the current user on a network equipment 1 using software version A.
  • the registration module 212 may request the current user to provide information on time required to complete the activity and expected idle time, i.e., the time duration for which the current user will not use the resource.
  • the current user on receiving the request, provides the information that the lab is required from 10 am to 4 pm and the expected idle time is from 1 pm to 3 pm.
  • the registration module 212 may also request the current user to specify the requirements and may also specify if there any conditions that need to be considered for the time duration for which the resource is booked. For example, the current user may specify that software version, i.e., version A and the binary code should not be changed for the test duration, i.e., between 10am and 4pm.
  • the current user may also enter details, such as the department, email-id and mobile number to complete the registration process.
  • the registration module 212 stores the information provided by the current user, referred to as first user data, in the user data 220.
  • the registration module 212 updates the status of the resource as Occupied' for the duration of time specified by the current user.
  • the registration module 212 provides information regarding activities performed by the current user and the time duration for which the resource would be occupied.
  • the registration module 212 registers the requesting users and similar information is requested from the requesting users as already received from the current user.
  • the information from the requesting users referred to as second user data, is also stored as part of the user data 220.
  • the terms first user data and the second user data have been used to refer to the user data 220 of the current user and the requesting users, respectively.
  • the idle time of the resource is determined by the idle time detection module 102.
  • the idle time detection module 102 includes the analysis module 214 and the prediction module 216.
  • the analysis module 214 monitors operation data 224 of the resource in real time to determine whether the resource is idle. Thus even if the current user does not inform that the resource is free, the analysis module 214 through, for example, the background processes running on the resource can determine the idle time of the resource.
  • the prediction module 216 predicts the idle time of the resource based on the user data 220 and the historical data 222.
  • the analysis module 214 analyzes the CPU utilization, disk utilization, memory utilization, and other parameters, to determine the idle time. If the CPU utilization is below a specified threshold value, the resource is assumed to be idle.
  • the prediction module 216 can predict the idle time of the resource. For example, the prediction module 216 analyzes the activities planned by the current user to predict the idle time based on the historical data 222. In the example of the testing lab, suppose the current user has booked the lab from 10am to 4pm for executing an automated call processing test on the network equipment 1. The prediction module 216, by analyzing the historical data 222 of call processing tests, predicts that the lab would be only required for 4 hours and therefore, the lab would be free after 2pm. The remaining time, i.e.
  • the prediction module 216 predicts that O&M test scenario related resources will be free after 2 hours, therefore this time can be allocated to a suitable requesting user Therefore, equipment required for O&M are identified as idle and can be allocated to one of the requesting users.
  • the prediction module 216 may also request the current user to confirm whether the resource would actually be idle for the predicted time. In the above example, after predicting that the lab would be idle after 2pm, the prediction module 216 may also request the current user to confirm whether the lab would be idle after 2pm.
  • the current user can also override the background processes running on the resource.
  • the current user may inform the system 102 when the idle time starts.
  • the current user may interact with the system 102 through a computing device, for example, by sending an e-mail to inform that the resource is idle.
  • the idle time detection module 1 determines the idle time of the resource either on the basis of actual monitoring of the operation data 224 or through prediction based on historical data 222
  • the prediction module 216 determines the duration of the idle time by analyzing the historical data 222. In the "testing lab" example presented earlier, if a user is executing a call processing test on the network equipment 1, an idle time can be detected based on the background processes running on the resource.
  • the prediction module 216 then analyzes the historical data 222 on call processing test and the current user using the testing lab. Suppose the current user takes a break for 2 hours, then this time may be predicted as the total duration of the idle time. The prediction module 216 also analyzes the historical data on call processing scenario to predict the duration of idle time.
  • the resource allocation module 1 12 analyzes the requests of the requesting users to determine whether the resource can be allocated or not.
  • the resource allocation module 112 compares the requests of the requesting users with the activities performed by the current user and the conditions specified by the current user during the registration process to determine whether the resource can be allocated or not.
  • the registration information of the requesting users stored in user data 220 is analyzed.
  • the resource allocation module 1 12 allocates the resource to a requesting user.
  • the idle time of the resource may be determined by analyzing the operation data 224 of the resource. The allocation can be done either on the basis of the order of the request made or on the basis of priority and urgency.
  • the resource allocation module 112 compares the time required by the requesting users with the duration of the idle time.
  • the resource allocation module 1 12 also compares the activities planned by the requesting users and the activities performed by the current user, keeping in consideration the condition specified by the current user during the registration.
  • the resource may be allocated. If the activities planned by the requesting user do not affect the activities of the current user for the duration of idle time, the resource may be allocated. If the activities planned by the requesting user affect the working of the current user, the resource may not be allocated and the request may be denied. In an implementation, the resource allocation module 1 12 may inform the respective requesting user on the denial of the request. In another implementation, the request of the requesting user, whose request is earlier denied, may again be analyzed with other requesting users.
  • the resource allocation module 1 12 fetches the first user data from the user data 220. Based on the user data 220, the resource allocation module 112 determines that the current user is performing call processing activities on the network equipment 1 using software version X. Also, the current user had specified during registration that the software version and the binary code should not be changed during the test scenario, i.e., between 10am and 4pm. Further, the idle time determined by the idle time detection module 1 10 is between 1pm and 3pm.
  • the resource allocation module 112 compares the requests of the requesting users, for example, in the order of FIFO, with the activities performed by current user along with the duration idle time. For example, if a first requesting user wants to continuously use the testing lab for 4 hours, his or her request will be denied as the idle time is only 2 hours. Likewise, if upon analyzing a request from a second requesting user, the resource allocation module 112 determines that the second requesting user wants to use the lab for 2 hours with the software version Y, the resource allocation module 112 may also deny the request of the second requesting user as the current user had specified during registration that the software version should not be changed.
  • the resource allocation module 1 12 determines that the third requesting user wants to use the lab for two hours with software version X but the testing scenario requires binary code to be changed, the request will again be denied as the condition specified by the current user are affected with the request of the third requesting user.
  • the resource allocation module 112 keeps on scanning the requests until a certain requesting user is found whose request does not affect the activities of the current user and taking into consideration the conditions specified by the current user.
  • a fourth requesting user wants to use the lab for 4 hours, but not continuously, with software version X and without changing the binary code.
  • the resource allocation module 112 determines that the fourth requesting user can be allocated the testing lab.
  • the resource allocation module 112 determines the health of the resource. In an implementation, the resource allocation module 1 12 determines whether the resource is in a condition to be allocated or not. In the above example, before allocating the testing lab to the fourth requesting user, the resource allocation module 1 12 determines the health of the testing lab, i.e., whether all the equipment required for the testing have the required version of the software, and whether all the equipments are in working condition. In an implementation, if the testing lab is in usable state, the testing lab can be allocated to the fourth requesting user. In another implementation, if the time required to bring the lab in usable state is 1.5 hrs, the lab will not be allocated to the fourth requesting user as the idle time is only 2 hours.
  • the resource allocation module 112 Upon determining that the resource is in a condition to be allocated, before notifying the selected requesting user, the resource allocation module 112 seeks confirmation from the current user on allocation of the resource. If the current user allows the resource to be allocated, the resource allocation module 112 notifies the selected requesting user on the allocation of the resource. In the above example, the resource allocation module 112 informs the fourth requesting user on the allocation of the resource. If the current user denies the allocation of the resource to the fourth requesting user the resource allocation module 112 informs the fourth requesting user on the rejection of the request.
  • the resource allocation module 1 12 enquires the current user whether the selected requesting user should not be allocated the resource or resource not be allocated to any requesting user during the idle time. If the current user specifies that the selected requesting user should not be allocated the resource, the resource allocation module 112 analyzes the other pending requests and also schedules the request of the requesting user, which is currently rejected, along with the other pending requests. If the current user specifies that the resource should not be allocated, the resource allocation module 112 waits for the current user to finish its activities and then allocates the resource to the requesting users.
  • the resource allocation module 112 After, seeking confirmation from the current user, the resource allocation module 112 notifies the selected requesting user on the allocation of the resource and provides the desired setting to the requesting user, i.e., the required version of the software, resources, etc. In one implementation, the resource allocation module 112 sends an e-mail to the requesting user. In another, implementation the resource allocation module 112 informs the requesting user through an SMS. In yet another implementation, the resource allocation module 112 may generate an automated voice call on the selected requesting user's mobile.
  • the present system 102 thus, provides an efficient way of determining the idle time, for example ad-hoc idle time, of the resource and allocating the resource during the idle time. This results in effective utilization of the idle time. Real time analysis of the resource allows effective determination of the idle time. Also, the time spent by the requesting users in determining the availability of the resource is saved. The system 102 also provides the setting required to perform the activities on the resource to the selected requesting user beforehand.
  • Figure 3 illustrates a method 300 for idle time detection and allocation of a resource, in accordance with an embodiment of the present subject matter.
  • the order in which the method 300 is described is not intended to be construed as a limitation, and any number of the described method blocks can be combined in any order to implement the methods, or alternative methods. Additionally, individual blocks may be deleted from the methods without departing from the spirit and scope of the subject matter described herein. Furthermore, the methods can be implemented in any suitable hardware, software, firmware, or combination thereof.
  • steps of the method can be performed by programmed computers.
  • program storage devices for example, digital data storage media, which are machine or computer readable and encode machine-executable or computer-executable programs of instructions, wherein said instructions perform some or all of the steps of the described methods.
  • the program storage devices may be, for example, digital memories, magnetic storage media, such as a magnetic disks and magnetic tapes, hard drives, or optically readable digital data storage media.
  • the embodiments are also intended to cover both communication network and communication devices configured to perform said steps of the exemplary methods.
  • a current user is registered.
  • registration module 212 requests the current user to provide information, such as resource required, activities planned on the resource, restrictions put by the current user, time required to complete the activities, expected idle time, condition specified by the current users, e-mail id, and a mobile number.
  • the information provided by the current user is stored as user data 220.
  • a resource is allocated to the current user. For example, based on the information provided by the current user during registration, the resource allocation system 102 allocates the resource that is not in use to the current user.
  • status of the resource is updated. For example, the registration module 212 updates the status of the resource allocated to the current user as Occupied'. In one implementation, the registration module 212 also updates the information on the resource, such as a time required to perform the activity, an expected idle time, and name of the current user.
  • requests from one or more requesting users for the resource are received.
  • the registration module 212 receives the request from the one or more requesting users for the resource which is currently allocated to the current user.
  • the registration module 212 registers the requesting users by requesting information similar to that obtained from the current user.
  • idle time of the resource is monitored.
  • the idle time detection module 1 10 determines the idle time of the resource.
  • the analysis module 214 monitors the operation data 224 to determine the idle time. For example, in case of the testing lab, the analysis module 214 monitors the CPU utilization or memory utilization. If the CPU utilization is below a specified threshold, the resource is assumed to be idle. In another implementation, the prediction module 216 predicts the idle time of the resource based on the historical data 222.
  • the control flows to block 310 and the idle time of the resource is monitored. In case it is determined that the resource is idle, which is the 'Yes' path, the control flows to block 314 and the requests of the requesting user are processed, for example, the requests are processed to allocate the idle time of the resource to a certain requesting user.
  • the prediction module 216 analyzes the historical data 222 to predict the duration of the idle time.
  • pending requests from the requesting users are processed.
  • the resource allocation module 1 12 selects a requesting user for using the resource.
  • the resource allocation module 112 compares the activities planned by the requesting user with activities of the current user along with idle time and the condition specified by the current user to determine whether the resource can be allocated or not.
  • a requesting user is selected from the one or more requesting users. Based on the comparison, as described in step 314, a particular requesting user is selected. For example, if the activities planned by the requesting user do not affect the activities performed by the current user, the requesting user is selected to use the resource by the resource allocation module 1 12. In an implementation, after identifying the selected requesting user, a health of the resource is determined. If the resource is in a usable health, the resource allocation module 1 12 identifies that the resource can be allocated, else the requests from the requesting user are denied. In another implementation, the resource allocation module 112, after selecting a particular requesting user for the resource, may also determine whether the selected requesting user has any additional requirements. For example, if the selected requesting user requires additional resources, the resource allocation module 112 may determine the availability of the other resource. If the resources are available, the resource allocation module 112 may provide the resources to the selecting requesting user.
  • confirmation from the current user for the allocation of the resource is requested. Before notifying the selected requesting user about the allocation of the resource, the current user is requested to confirm that the resource can eb allocated. If the current user confirms the allocation of the resource, which is the 'YES' path, the control flows to block 320. If the current user rejects the allocation of the resource, which is the 'No' path, the control flows to block 322.
  • the resource is allocated to the selected requesting user.
  • the resource allocation module 112 notifies the selected requesting user on the allocation of the resource.
  • the resource is allocated for the duration of the idle time and on expiration of the idle time the resource allocation module 1 12 again allocates the resource to the current user.
  • the notification to the selected requesting can be through the e-mail.
  • the notification can be through a Short Message Service (SMS) or automated voice call on the selected requesting user's mobile phone.
  • SMS Short Message Service
  • the request of the selected requesting user is rejected. If the current user rejects the allocation of the resource to the selected requesting user, described at block 318, the selected user is notified on the rejection of the request. For example, the resource allocation module 1 12 notifies the selected requesting user that the resource cannot be allocated. Thereafter, the control flows back to block 314 and other pending requests are processed. The rejected request may also go back to the pending requests. In one implementation, the current user may reject the allocation of the resource to any requesting user. In such a case the resource allocation module 1 12 may stop processing the requests from the requesting users.
PCT/EP2012/061824 2011-07-06 2012-06-20 Methods and systems for resource allocation WO2013004497A1 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
IN1915DE2011 2011-07-06
IN1915/DEL/2011 2011-07-06

Publications (1)

Publication Number Publication Date
WO2013004497A1 true WO2013004497A1 (en) 2013-01-10

Family

ID=46319149

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2012/061824 WO2013004497A1 (en) 2011-07-06 2012-06-20 Methods and systems for resource allocation

Country Status (1)

Country Link
WO (1) WO2013004497A1 (es)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20230015531A1 (en) * 2021-07-09 2023-01-19 International Business Machines Corporation Dynamic allocation of computing resources
WO2023072281A1 (en) * 2021-10-31 2023-05-04 Huawei Technologies Co., Ltd. Resource allocation in data center networks

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6912232B1 (en) * 1998-10-19 2005-06-28 At&T Corp. Virtual private network
WO2006021223A1 (en) * 2004-08-21 2006-03-02 Telefonaktiebolaget Lm Ericsson (Publ) Resource management
US20070076728A1 (en) * 2005-10-04 2007-04-05 Remi Rieger Self-monitoring and optimizing network apparatus and methods
EP1944922A1 (en) * 2007-01-10 2008-07-16 Alcatel Lucent Method of providing QoS
US20100110887A1 (en) * 2008-10-30 2010-05-06 Motorola, Inc. Admission control for a heterogeneous communication system

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6912232B1 (en) * 1998-10-19 2005-06-28 At&T Corp. Virtual private network
WO2006021223A1 (en) * 2004-08-21 2006-03-02 Telefonaktiebolaget Lm Ericsson (Publ) Resource management
US20070076728A1 (en) * 2005-10-04 2007-04-05 Remi Rieger Self-monitoring and optimizing network apparatus and methods
EP1944922A1 (en) * 2007-01-10 2008-07-16 Alcatel Lucent Method of providing QoS
US20100110887A1 (en) * 2008-10-30 2010-05-06 Motorola, Inc. Admission control for a heterogeneous communication system

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20230015531A1 (en) * 2021-07-09 2023-01-19 International Business Machines Corporation Dynamic allocation of computing resources
US11689472B2 (en) * 2021-07-09 2023-06-27 International Business Machines Corporation Dynamic allocation of computing resources
WO2023072281A1 (en) * 2021-10-31 2023-05-04 Huawei Technologies Co., Ltd. Resource allocation in data center networks
US11902110B2 (en) 2021-10-31 2024-02-13 Huawei Technologies Co., Ltd. Resource allocation in data center networks

Similar Documents

Publication Publication Date Title
US9727372B2 (en) Scheduling computer jobs for execution
US8424007B1 (en) Prioritizing tasks from virtual machines
US9524296B2 (en) Managing events in a computing environment
US9262220B2 (en) Scheduling workloads and making provision decisions of computer resources in a computing environment
Hashem et al. MapReduce scheduling algorithms: a review
US20170206462A1 (en) Method and apparatus for detecting abnormal contention on a computer system
US20080320482A1 (en) Management of grid computing resources based on service level requirements
Singh et al. The journey of QoS-aware autonomic cloud computing
JP2018533122A (ja) マルチバージョンタスクの効率的なスケジューリング
Idris et al. An improved ant colony optimization algorithm with fault tolerance for job scheduling in grid computing systems
CN111950988B (zh) 分布式工作流调度方法、装置、存储介质及电子设备
CN111625331B (zh) 任务调度方法、装置、平台、服务器及存储介质
Adhikary et al. Quality of service aware cloud resource provisioning for social multimedia services and applications
Wang et al. Energy utilization task scheduling for mapreduce in heterogeneous clusters
US8312466B2 (en) Restricting resources consumed by ghost agents
Avanes et al. Adaptive workflow scheduling under resource allocation constraints and network dynamics
US8510273B2 (en) System, method, and computer-readable medium to facilitate application of arrival rate qualifications to missed throughput server level goals
Xu et al. Fault tolerance and quality of service aware virtual machine scheduling algorithm in cloud data centers
WO2013004497A1 (en) Methods and systems for resource allocation
Soualhia et al. ATLAS: An adaptive failure-aware scheduler for hadoop
Ebenezer et al. A novel proactive health aware fault tolerant (HAFT) scheduler for computational grid based on resource failure data analytics
CN113824590A (zh) 微服务网络的问题预测方法、计算机设备和存储介质
JP2018536945A (ja) タスクをタイムベーススケジューリングする方法及び装置
Anselmi et al. Load Balancing with Job-Size Testing: Performance Improvement or Degradation?
Hamad An overview of Hadoop scheduler algorithms

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 12728099

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 12728099

Country of ref document: EP

Kind code of ref document: A1