the invention discloses methods and systems provided for controlling per session throughput and ip application priority dynamically , utilizing a servomechanism and real - time performance monitoring , and applying the most appropriate packet flow control configurations to each connected session . this way , an mvno &# 39 ; s total bandwidth may be allocated most efficiently , without having to sacrifice the user experience of any particular service plan or user group . in examples , a feedback - based packet control system that automatically adjusts the mobile speed of different services to different consumers based on business rules is provided . in examples of the invention , a servomechanism that consists of four main components may be used to adjust the services of different customers . these four components may include a speed monitoring module , a business rule engine , a deep packet inspection unit , and a packet controller . the speed monitoring module may measure the speed of the service . the deep packet inspection unit may determine the number of packets lost and re - transmitted packets . the packet controller may adjust the speed of the service . additionally , the business rule engine may be responsible for setting requirements based on , but not limited to , the date , type of service , and type of consumer . all four components may operate with each other based on feedback from each component . fig1 illustrates an exemplary system that provides a feedback - based packet control system 106 to manage bandwidth allocation of a mobile virtual network operator , in accordance with embodiments of the invention . in this figure , user equipment (“ ue ”) 100 may start a data - based application . a nearby cellular tower 101 may pick up the request to create a session and send it to the appropriate mno &# 39 ; s serving gprs ( general packet radio service ) support node (“ sgsn ”) 104 . the sgsn 104 may be responsible for handling packet transmission from cellular tower 101 on the mno side 102 . in turn , the sgsn 104 may then distribute the request to the mvno side 103 . on the mvno side 103 , the gateway gprs support node (“ ggsn ”) 105 may receive the request . the ssgn 104 and ggsn 105 act as gateways between mno side 102 and mvno side 103 . once the request is processed , the request may be forwarded to the feedback - based packet control system 106 . the feedback - based packet control system 106 may be embedded within the mvno . additionally , the feedback - based packet control system 106 may be where the performance monitoring takes place before the request proceeds to the internet 107 and the server 109 of the requested data - based application . in examples , a speed monitoring module within the feedback - based packet control system 106 may be connected to its own cellular tower 108 . in examples , the speed monitoring module may act similarly to a user equipment , such as user equipment 100 . fig2 illustrates components of a feedback - based packet control system 200 , in accordance with embodiments of the invention . the feedback - based packet control system 200 as provided in fig2 includes four separate components working together : the business rule engine (“ bre ”) 210 , the speed monitoring module (“ smm ”) 220 , deep packet inspector (“ dpi ”) 230 , and packet controller (“ pc ”) 240 . the bre 210 may define hierarchical user groups , such as different enterprises and consumer groups . in an example , enterprise - a may be a company that an mvno serves based on a contract for a group of 3g / lte mobile users within the enterprise who use a specific tablet pc model with connectivity speeds of up to 300 kbps and who only use email and web browsing during business hours , monday through friday . another example is consumer group - a , which may be a group of users that uses the high - speed internet connectivity service the mvno offers . a third example is consumer group - b , which may be another group of users with up to 150 kbps internet connectivity service . consumer group - b may also have other plans associated with it , such as a pre - paid 200 hour plan and a 1 gb per month plan , both still restricted to 150 kbps . the bre 210 may also have a calendar and time table . the time table and calendar may be used in the speed adjustments of the different services of the different user groups . the bre 210 may also store business rules in its database system . these business rules may be customized . additionally , these business rules may include data such as total available bandwidth , guaranteed bandwidth to be assigned to a particular enterprise based on a service contract , minimum acceptable session throughput for each different service plan at different times of day , different days of the week , or different seasons , and minimum acceptable packet loss for different ip applications , such as voip , web browsing , p2p , and email . these business rules may also include bandwidth allotments and performance thresholds for different types and models of end - user devices , such as smartphones , tablet pcs , usb cellular modems , and cellular routers . the smm 220 may test the connectivity and transmission speeds of offered services and plans . in examples , the smm 220 may test the connectivity and transmission speeds of all offered service plans . the smm 220 may be a device that consists of a central processing unit ( cpu ) and memory , multiple 3g / lte mini - peripheral component interconnect express ( pcie ) modules , multiple sim slots for each mini - pcie modules , and multiple rf antenna connectors . subscriber identity module ( sim ) cards provisioned for each offered service plan ( i . e . high - speed , 300 kbps , and pre - paid plans , etc . ), or sim cards specifically provisioned for a particular enterprise , may be inserted in the sim card slots and external 3g / lte antennas may be connected through the antenna connectors . the cpu may send and receive certain sized data files in different formats using different communication ports to and from a predefined file server on the internet or in a specific network node at regular intervals . additionally , the cpu may compute data transmission and reception throughput based on file size and actual duration of data transmission or reception . results of these measured throughputs of different user groups , different service plans , and through different communication ports may be sent to the database portion of the bre 210 on a real - time basis . pc 240 may adjust the speed based on the requirements set by the bre 210 . in examples , pc 240 may be responsible for reconfiguring packet delay for each user group . additionally , pc 240 may be responsible for reconfiguring packet delay for each service plan . pc 240 may also be responsible for reconfiguring packet delay for each application on the patent controller . in alternative examples , the base stations may not be used , but a direct ethernet connection may be utilized between the server 109 and the feedback - based packet control system 160 with the same ip address range of each user group to measure the speeds of the different services . using a direct connection may remove external influences that may occur due to unstable wireless conditions . dpi 230 may utilize a conventional ip packet analyzer . additionally , dpi 230 may measure the packet loss and packet re - transmission rate of connected ip sessions from different user groups , different service plans , and different device models on a real - time basis . these statistics may be sent to the database portion of the bre 210 . based on those statistics , the bre 210 may adjust the requirements appropriately . in examples , the bre 210 may increase the speed of a service if the dpi 230 detects a high packet loss and a high packet re - transmission rate , or decrease the speed of a service if the dpi 230 detects a low packet loss and a low packet re - transmission rate , depending on the business rules at that time . fig3 illustrates a workflow that illustrates relationships between components of the feedback - based packet control system , in accordance with embodiments of the invention . in particular , fig3 illustrates the logical relationship between the different modules of the feedback - based packet control system and the bre &# 39 ; s 210 workflow . the business rules 300 , dpi measurement results 301 , and speed measurement results 302 of each user group may be located within the database of the bre 210 . as stated above , the business rules typically include , but may not be limited to , specifying total available bandwidth , maximum speed of different services , speed threshold of different services , application priority , speed threshold per application , busy seasons of the year , busy days of the week , and busy times of the day . the dpi measurement results 301 may come from the dpi 230 . additionally , the dpi measurement results 301 may include packet delay statistics due to packet drop and packet retransmission per user group and per application . lastly , the speed measurement results of each user group 302 may come from the smm 220 . in particular , the speed measurement results of each user group 302 may come from speed measurement data from the smm 303 . the speed measurement data from smm 303 may continuously provide the speed measurement results of each user group in a continuous manner as indicated by the feedback loop arrow . furthermore , by receiving the dpi measurement results 301 in a periodic manner as indicated by the feedback loop arrow , the bre 210 may determine available bandwidth allocation to different user groups at programmable intervals based on the business rules 300 . by analyzing the data received from the smm 220 and dpi 230 in a periodic manner , the bre 210 can make the necessary speed adjustments to the necessary services and user groups . in examples , the bre 210 may determine available bandwidth allocation to different user groups every two minutes . additionally , pc 240 may appropriately make the necessary adjustments as far as packet delays are concerned , whether to increase or decrease packet delay , depending on the business rules 300 . in particular , the pc 240 may reconfigure packet delay for each user group , service plan , and application on the pc 240 , as provided at block 304 . specific examples may include , but are not limited to , new year &# 39 ; s eve . on new year &# 39 ; s eve , data traffic might have a large spike in usage at about midnight on december 31 st , but only in certain applications . as such , the determination of which application is used at that time and by whom may affect bandwidth allocations . for an instance , if an individual consumer is trying to make a voip call at about that time , the individual customer might have priority over an enterprise that does not operate that late in the day . thus , the bandwidths allocated for that user and enterprise may be adjusted accordingly based on circumstances . fig4 displays another exemplary system that provides a feedback - based packet control system 400 to manage bandwidth allocation of a mobile virtual network operator , in accordance with embodiments of the invention . in particular , a feedback - based packet control system 400 to manage bandwidth allocation for a request received from user equipment 405 to access the internet 406 is provided . the components of the feedback - based control system 400 may be similar to the components of the feedback - based control system 200 in the following manner : speed monitoring module 401 may be similar to speed monitoring module 220 ; deep packet inspector 402 may be similar to deep packet inspector 230 ; business rule engine 403 may be similar to business rule engine 210 ; and packet controller 304 may be similar to packet controller 240 . once data from the smm 401 and dpi 402 reaches the bre 403 , the bre 403 may be responsible for setting different control policies and priorities based on the time and specifications ( type of application used , etc .) of the data received . the speed adjustment may start within the servomechanism , which is indicated by the feedback loops , of the smm 401 , bre 403 , mechanism of the packet controller 404 , and dpi 402 after the bre 403 handles the received data . the bre 403 may read the measured speed data originating from the smm 401 and packet loss and packet retransmission statistics originating from the dpi 402 through the database . then , the bre 403 may compare these values with the different business rules and dynamically change the configuration of the pc 404 to most efficiently allocate the bandwidth to different enterprises and different service plan groups . additionally , the bre 403 may limit the packet throughput for different speed limit services , ( i . e . 300 kbps and 150 kbps services ), or for different device models ( i . e . tablet pcs or usb dongles , etc . ), or both , by dynamically adjusting packet delays of each ip session . the pc 404 may further control remaining session length for time - based service plans , such as a high - speed 200 hours prepaid plan . additionally , the pc 404 may terminate or throttle an ip session when volume - based plans are used up . the pc 404 may also send an alert to users and notify them that their service plans are maxed out , or pop - up a web page to allow users to refill or change their service plans . furthermore , the pc 404 may adjust priority : maximum and minimum throughput for specific ip applications per session or for a group of specific ip applications based on preconfigured business rules , speed performance measurements conducted by the smm 401 , and real - time dpi measurements . for example , the total bandwidth of an mvno may be fully allocated to enterprises a and b and user groups a and b . the high - speed service group &# 39 ; s http speed is measured at 2 mbps , and the 150 kbps speed service is measured at 100 kbps by the smm 401 . if the business rules 300 specified a threshold speed of 1 . 5 mbps for the high - speed service and a 120 kbps threshold for the 150 kbps service , the bre 403 may revise the configuration of the pc 404 to throttle the high - speed service down to 1 . 5 mbps and wait to receive the next set of measured values from the smm 401 . if the speed of the 150 kbps service increases to 120 kbps , then speed control may end until a future rule violation is detected . the speed check is conducted on a regular basis by the smm 401 . another example may include an instance when all consumer group services &# 39 ; speeds are measured slower than the threshold . in this case , provided it is specified in the business rules , particular ip applications such as p2p , multi media , or android downloads may be throttled to slower throughput . as such , common ip applications , such as web browsing , email , and voip , may gain faster speeds than the threshold until http speeds come back to above threshold . in addition to the actual speed measured by the smm 401 , real - time dpi measurement results 301 such as packet loss value and packet retransmission rates that can also be used to determine current level of service performance and speed . fig5 illustrates a schematic of interactions between components of the feedback - based packet control system , in accordance with embodiments of the invention . in particular , fig5 illustrates another exemplary system that provides a feedback - based packet control system 506 to manage bandwidth allocation of a mobile virtual network operator , in accordance with embodiments of the invention . fig5 shows a specific embodiment of the invention in which a customer is using a cellphone 500 to connect to the internet 507 through the use of a cellular tower 501 . additional components of fig5 are similar to components of fig1 . in particular , mno side 502 is similar to mno side 102 ; sgsn / sgw 504 is similar to sgsn / sgw 104 ; mvno side 503 is similar to mvno side 103 ; ggsn / pgw 505 is similar to ggsn / pgw 105 ; feedback - based packet control system 506 is similar to feedback - based packet control system 106 ; internet 507 is similar to internet 107 ; cellular tower 508 is similar to cellular tower 108 ; and server 509 is similar to server 109 . business rules 300 may define busy traffic hours , such as morning commute time , lunch time , or afternoon commute hours , so that high - volume applications , such as media streaming or content downloading speeds are throttled during these time windows and , as a result , offer reasonably faster speeds to common ip applications , such as web browsing and smartphone applications . this way , day and night , or seasonally high traffic days , such as christmas or new years , can be pre - programmed to avoid traffic congestions . those business rules reside in the bre 403 component of the feedback based packet control system . fig6 illustrates a workflow showing performance balancing , in accordance with embodiments of the invention . in particular , fig6 shows how the traffic control tuning may occur . at first , the performance of the different services may be checked . in examples , the performance of one or more of the different services may be checked . this is illustrated in fig6 at block 600 , which provides that speed performances of the services are assessed . in examples , the speed performances of the services may be assessed by a speed monitoring module , such as smm 401 in fig4 . in examples , the performance speed of services may be assessed in multiple ways . one of the ways to measure the speed performance of the service may be done by using the time stamps recorded during the transmission of the packet . for example , if a user downloads a certain file at a specific speed , there is an expectation as to how long it will require to download the file . in an ideal situation , when there are no packet delays , an 8 megabit per second service should be able to download a 100 mb file in 100 seconds . if the packets sent or received are delayed , typically by packet loss and re - transmission , their recorded time stamps will also be delayed . if this packet delay exceeds the expected delay , more bandwidth may be required to download the file and the total bandwidth available for the mvno will not be used optimally . thus , the packet delay may lead to revenue loss and waste the mvno &# 39 ; s limited bandwidth . after the speed is measured by an smm , such as smm 401 , performance of the service may be assessed . in particular , the performance of the service is assessed against whether it met the rules / criteria set by the bre 210 . this is illustrated at choice 601 , which asks whether performances are around the criteria . the performance may be assessed at user equipment 405 . as mentioned earlier , different criteria may include , but are not limited to , seasons ( year - end , new - year , etc . ), days of the week , times of the day , and types of applications used . if the performance meets those expectations , a fixed amount of time may pass before the speed performance of that specific service is checked again to ensure quality of service . this is illustrated at block 605 , which provides for waiting a predetermined amount of time . in examples , the predetermined amount of time may be less than 10 seconds , 15 seconds , 20 seconds , 25 seconds , 30 seconds , 35 seconds , 40 seconds , 45 seconds , 50 seconds , 55 seconds , 60 seconds , 65 seconds , 70 seconds , 75 seconds , 80 seconds , 85 seconds , 90 seconds , 95 seconds , 100 seconds , 105 seconds , 110 seconds , 115 seconds , 120 seconds , 3 minutes , 4 minutes , 5 minutes , 10 minutes , 15 minutes , 20 minutes , 25 minutes , 30 minutes , 35 minutes , 40 minutes , 45 minutes , 50 minutes , 55 minutes , 60 minutes , 2 hours , or greater than 2 hours . alternatively , if the performance does not meet those expectations , performance adjustment may occur . when performance adjustment occurs , the service , protocol , and / or application with subpar performance may be identified . this is seen at block 602 . in particular , the service , protocol , and / or application with subpar performance may be identified by a deep packet inspection component , such as dpi 602 . next , at block 603 , performance balancing is executed . in particular , the performance balancing may be executed by a packet controller , such as pc 404 . the performance balance that is executed by pc 404 may determine whether or not the speed needs to be increased or decreased . at block 604 , when the performance balance is completed , a new temporary performance criteria may be set . in particular , the new temporary criteria may be set by a business rule engine , such as bre 403 . additionally , the cycle of assessing performance and adjusting parameters may continue after a fixed amount of time so as to continuously maintain proper performance . in some implementations , a time interval of executing the aforementioned cycle ( i . e . a time interval of a feedback cycle ) may be implemented as a tunable parameter . in examples , the time interval value may depend on the shortest interval value of the maximum time allowed to recover from a state where the traffic is below a required minimum network speed ( the network bandwidth threshold ), as defined as an attribute of a user group . the time interval value may range from a fraction of a second ( e . g . when a particular user group features a high level of service quality ) to a few hours depending on a level of service quality needed , as agreed with users of the services . the minimum value of the time interval may be larger than the total time required to process one feedback cycle . this minimum value may include scanning the traffic speed of data transmission of users , comparing the scanned traffic speed against the minimum traffic threshold value , and adjusting the traffic to satisfy the traffic requirement for respective user groups . as the time interval becomes larger , users may find the time lag of network speed recovery to be the more noticeable . typical implementations may feature some value between 3 and 5 minutes . fig7 illustrates a workflow showing performance balancing , in accordance with embodiments of the invention . in particular , fig7 shows how performance balancing may be executed . initially , at block 700 , the system may detect a user group that excessively consumes bandwidth . for example , the system may detect a user group that consumes more than a threshold amount of bandwidth capacity . the assessment of bandwidth consumption may be independent of whether the bandwidth consumed is high - speed / http , high - speed / multimedia , etc . after the user group is identified , the data consumption of the top users of that user group may be specified at block 701 . in examples , users / subscribers within a user group may be categorized based on their bandwidth consumption . after this categorization takes place , a determination may be made as to whether one or more users are the root cause for the high amount of bandwidth consumption . this is illustrated at choice 702 . if the high rate of bandwidth use is only associated with one user , or with a small group of users , there may be no need to penalize an entire user group . in examples , a small group of users may be considered to be less than 2 users , 3 users , 4 users , 5 users , 6 users , 7 users , 8 users , 9 users , 10 users , 15 users , 20 users , 25 users , 30 users , 35 users , 40 users , 50 users , 60 users , 70 users , 80 users , 90 users , 100 users , 200 users , 300 users , 400 users , 500 users , 1 , 000 users , or more than 1 , 000 users . instead , adjustments may be made to the upper limit of the speed of the particular user , or small group of users , that is using an excessive amount of bandwidth . this is illustrated at block 703 , which provides for regulating an upper limit for those subscribers ( with ip addresses ) within the user group . for example , if it is determined that ten users within the user group are using 10 × the amount of bandwidth as the average user within the user group , the upper limit for those ten users may be regulated , while the upper limit for the rest of the group may not be regulated . however , if multiple users within a user group are utilizing a high amount of bandwidth , speeds may be adjusted for the whole user group of users / subscribers that contains the multiple subscribers who are using a great amount of bandwidth . for example , if more than a threshold number of users within a user group are utilizing a high amount of bandwidth , speeds may be adjusted for the whole user group of users / subscribers that contain those users . this is illustrated at block 704 , which provides for regulating an upper limit for the user group quota if needed . in examples , a threshold number of users that are using an excessive amount of bandwidth may be set at more than 10 users , 15 users , 20 users , 25 users , 30 users , 35 users , 40 users , 50 users , 60 users , 70 users , 80 users , 90 users , 100 users , 200 users , 300 users , 400 users , 500 users , 1 , 000 users , or more than 1 , 000 users . in additional examples , if most of the users within the user group are using more bandwidth than an average user of the mvno , or if there are no particular “ exceptional ” users , then the entire user group may be regulated and / or penalized . adjustments made so as to reduce the bandwidth consumption of the greatest users of bandwidth may help in balancing the quotas of the rest of the user groups , as provided at block 705 . an example of user groups is shown in fig8 . in particular , fig8 illustrates an example of a user group table , in accordance with embodiments of the invention . as seen in fig8 , a threshold amount of bandwidth may be modified based on , but not limited to , a particular user group as well as a particular date . existing technologies can offer most or all of these packet controllers based on static configuration . when ip traffic conditions change , or when a few heavy users are using up the traffic capacity so as to constantly cause slowness to general users , mvnos or service providers may manually reconfigure the packet control system . in particular , mvno &# 39 ; s may manually reconfigure the packet control system to maintain desired service levels in accordance with users &# 39 ; service plans . methods provided herein may be used to dynamically and automatically apply suitable configurations to a packet controller using a servomechanism based on business rules compared against actual speed performance , packet loss , and packet retransmission rate . additionally , one or more of the actual speed performance , packet loss , and packet retransmission rate may be measured in real - time . although preferred embodiments of the invention have been shown and described herein , it will be obvious to those skilled in the art that such embodiments are provided by way of example only . numerous variations , changes , and substitutions will now occur to those skilled in the art without departing from the invention . it should be understood that various alternatives to the embodiments of the invention described herein may be employed in practicing the invention . it is intended that the following claims define the scope of the invention and that methods and structures within the scope of these claims and their equivalents be covered thereby .