Process for provisioning resources in a radiotelephone network

[0002] I. Field of the Invention

[0003] The present invention relates to radio communications. More particularly, the present invention relates to provisioning resources in a radiotelephone network.

[0004] II. Description of the Related Art

[0005] Cellular radiotelephone networks provide mobile radiotelephone subscribers access to the land-line public switched telephone network (PSTN). FIG. 1 illustrates a typical prior art example of such a radiotelephone network.

[0006] This network is comprised of a number of base stations (104-109) that use multiple radio transceivers to communicate with the mobile subscriber (130). The base stations are controlled by base station controllers (101-103) that are coupled to a central switch (100), referred to in the art as the mobile switching center (MSC).

[0007] The MSC (100) is a point of access to the PSTN (120). The MSC (100) supervises and controls connections between the PSTN (120) and mobile subscribers (130). Any combination of calls are made possible by the MSC (100): land-to-land, mobile-to-land, land-to-mobile, or mobile-to-mobile. The MSC (100) is well known in the art and is therefore not described further.

[0008] This network and its elements are generic to multiple types of radiotelephone systems such as the advanced mobile phone system (AMPS), Global System for Mobile communications (GSM) time division multiple access (TDMA), and code division multiple access (CDMA). These standards are described in greater detail in their respective specifications available from the Electronic Industries Association/Telecommunications Industry Association (EIA/TIA).

[0009] In addition to functioning as the interface to the public land-line network, the above described switch also controls all of the subsystems required for the cellular system. These subsystems include radio channel units, cell site equipment, mobile subscriber billing, and system operational measurement software that are responsible for determining the operational measurements of the switch.

[0010] Operational measurements, as is well known in the cellular art, are counters for the events that occur in a cellular switch. These call-related events include, for example, the activity that takes place within the switch such as mobile-to-land calls, mobile-to-mobile calls, land-to-mobile calls, hand-offs, three-way calls, and dropped calls. Different systems have various operational measurements depending on the system requirements and features offered by the system operator.

[0011] The radiotelephone systems have various resources that must be allocated to the radiotelephone subscribers. These resources include system memory and radios. The resources are allocated by estimating the resources required when certain call features (call forwarding, conference calling, etc.) are in use by the system operator. The estimation technique's drawback is that the amount of resources can be under or overestimated.

[0012] Underestimating the required resources will cause service degradation and possibly a system reset since not enough memory is set aside for the traffic. Overestimating causes greater expense for the system operator due to the high cost of memory and other hardware.

[0013] The provisioning process of the present invention more accurately estimates the provisioning of system resources, thus increasing system reliability and reducing the operator's cost. The process allocates a system resource in a radiotelephone system. The radiotelephone system accumulates operational measurements, handles calls, and has call related features.

[0014] The provisioning process determines an average number of system resources required per call-related event. This average is used to determine the holding rate of the system resource, R_resource, by taking into account the busy hour call attempts and the ratio of the high day busy hour to average busy season busy hour.

[0015] Using the holding rate, the number of system resources to be allocated is found using resource =┌R_resource+7{square root over (R_resource)}┐. This estimate may then be adjusted to take into account roaming radiotelephones accessing the system. This adjustment is based on the probability of the estimated allocation of each resource being exceeded.

[0016] FIG. 1 shows a flowchart for the provisioning process of the present invention.

[0017] FIG. 2 shows a comparison of Erlang-B formula and a Gaussian Approximation.

[0018] FIG. 3 shows an Erlang Loss versus Erlang Loss(r,n) plot.

[0019] FIG. 4 shows a table of risk margin assessments and the new resource estimates for resources allocated by the provisioning process of the present invention.

[0020] The provisioning process of the present invention more accurately estimates the provisioning of system resources. This minimizes system outages and service degradation caused by the unavailability of the system resources. The present invention additionally provides a notification to the system operator thus allowing the system resources to be updated in a timely manner.

[0021] In the preferred embodiment, the system resources being provisioned are blocks of the system memory. Alternate embodiments use the present invention to provision other system resources such as radios.

[0022] FIG. 1 illustrates a flowchart for the provisioning process of the present invention. This flowchart is the general provisioning rule that is used in each of the subsequently described memory allocations for each system resource.

[0023] The general provisioning process determines the average number of units of the resource held per call event (step 101), in units of time. This parameter is subsequently referred to as X_resource. Finding X_resourceuses the call model frequency for the resource to be allocated, the average hold time for the call-related events, and the number of resource instances required for the call-related event.

[0024] The call model frequencies are derived from the operational measurements as explained above. These call model frequencies are data counted by the switch in response to call activity. In the preferred embodiment, unless stated otherwise, these models are expressed as a percentage of the total calls handled by the switch.

[0025] The average hold time of the call-related event is the average duration, in seconds, of each event. This hold time is referred to in the art as the call hold time (CHT). These values are different for different systems. Therefore, each system assumes certain CHT values for the various call-related events. The CHT values used in the subsequent discussion are typical but the invention is not limited to these values.

[0026] The number of resource instances required for the call-related event refers to the number of times that a call-related resource is needed. For example, a hand-off may require two memory blocks each time that call-related event occurs. This parameter is determined by past experience in the system over a period of time.

[0027] The process then determines R_resource, the holding rate of the resource under consideration (step 105). R_resourceis found from the equation: $R_{\mathrm{resource}}=\frac{\left(1.5·\mathrm{BHCA}\right)·X_{\mathrm{resource}}}{3600}$

[0028] in Erlang,

[0029] where BHCA is the Busy Hour Call Attempts in hours.

[0030] R_resourceis found using the assumption that the ratio of the High Day Busy Hour (HDBH) to the Average Busy Season Busy Hour (ABSBH) is 1.5. ABSBH is the average value of the Busy Hour Call Attempts over a season. The duration of a season is determined by the operator. HDBH is the peak value of the Busy Hour Call Attempts during a season.

[0031] Since the BHCA has units of hours, this needs to be changed to seconds. Therefore, the BHCA is divided by 3600 seconds. The number of Busy Hour Call Attempts can be computed as follows: $\mathrm{BHCA}=\frac{\mathrm{CPOCC}\star \left(3.60\times {10}^6\right)}{\mathrm{AWT}}$

[0032] where CPOCC is the time that the call processor is occupied with call processing tasks and is set at the engineering limit of 0.75 in the preferred embodiment, assuming the call processor is occupied 75% of the time doing call processing tasks. Alternate embodiments use other constants for CPOCC depending on the amount of time the call processor is performing call processing tasks.

[0033] AWT is the average work time, typically in milliseconds, so that the 3.60 ×10⁶converts the milliseconds to hours. AWT is determined using the frequency of call events, the call processing time, the call processing I/O time, and any other I/O time. This weighted average is computed using the following equation:

[0034] AWT=Σ(F_E* CP_E)+(F_E* CPIO_E)+I/O

[0035] where F_Eis the frequency of a particular event, CP_Eis the call processing time for that event, CPIO_Eis the timing for the call processing I/O, and I/O is the timing for the remaining I/O of the switch that is not related to call processing. This remaining I/O is a constant, 0.25 in the preferred embodiment, times the number of messages in a set of events. This summation is performed on all of the different events handled by the switch. BHCA, CPOCC, and AWT are all well known in the art and are not discussed further.

[0036] The number of resources required (step 110) is determined by assuming that the traffic in a telecommunication system typically follows the Poisson distribution. The provisioning rule of the present invention relies on the Erlang Loss Formula: $E\left(n,r\right)=\frac{\frac{r^n}{n!}}{\sum _{i=1}^n\frac{r^i}{i!}}$

[0037] where n is the number of instances of the required system resource and r is the ratio of ordered traffic and the average holding rate of the parameter. The value given by the Erlang Loss Formula is sometimes referred to as the “Grade of Service” but more accurately represents the portion of failed call requests. If the tolerable Grade of Service is known, the Erlang Loss Formula can be used to derive the number of required parameters.

[0038] The provisioning of traffic related parameters involves choosing a reasonable Grade of Service and then determining the number of required resources. This is accomplished more efficiently by reorganizing the Erlang Loss Formula as follows: $E\left(n,r\right)=\frac{\frac{r^i}{n!}{e}^{-r}}{\sum _{i=0}^n\frac{r^i}{i!}{e}^{-r}}\mathrm{and}$ $E\left(n,r\right)=\frac{P\left(n,r\right)}{\sum _{i=0}^{n}P\left(i,r\right)}$

[0039] where P(n,r) is a Poisson distribution with mean r. P(n,r) is given by: $P\left(n,r\right)=\frac{r^n}{n!}{e}^{-r}.$

[0040] By the Central Limit Theorem, when r is large enough, the Gaussian distribution can be used to approximate the Poisson distribution. Therefore, the equation for P can be approximated by: $G\left(n,r\right)=\frac{1}{\sqrt{2\pi }}{e}^{-\left(\frac{{\left(n-r\right)}^2}{2r}\right)}.$

[0041] The Erlang formula can therefore be approximated by: $E^{\prime }\left(n,r\right)=\frac{\frac{1}{\sqrt{2\pi }}{e}^{-\left(\frac{{\left(n-r\right)}^2}{2r}\right)}}{\sum _{i=0}^n\frac{1}{\sqrt{2\pi }}{e}^{-\left(\frac{{\left(i-r\right)}^2}{2r}\right)}}.$

[0042] Since a large r is assumed, the Erlang formula can be further simplified: $G^{\prime }\left(n,r\right)=\frac{\frac{1}{\sqrt{2\pi }}{e}^{-\left(\frac{{\left(n-r\right)}^2}{2r}\right)}}{\frac{1}{\sqrt{2\pi }}\left({\int }_{-\infty }^n{e}^{-\left(\frac{{\left(x-r\right)}^2}{2r}\right)}dx\right)}.$

[0043] When n is large: $\frac{1}{\sqrt{2\pi }}\left({\int }_{-\infty }^n{e}^{-\left(\frac{{\left(x-r\right)}^2}{2r}\right)}dx\right)=1.$

[0044] FIG. 2 illustrates a plot of (n), the number of instances of the required resource, versus the probability of loss. This plot shows a comparison of the Erlang Loss Formula (Erlang-B) and the Gaussian approximation, with r=1000. The two plots are so close, it is obvious that the Gaussian distribution above can be used to approximate the Erlang Loss Formula.

[0045] A Gaussian value can be determined by:

[0046] n=┌r +a{square root over (r)}┐,

[0047] where α=1, 2, 3, . . . , and ┌x┐ denotes the smallest integer that is greater than x. By choosing different values for α, where a is a constant used for the approximation, the desired Gaussian value is obtained. The Erlang Loss values, obtained by the equation for n above, are plotted in FIG. 3 with each line representing a different α.

[0048] FIG. 3 shows that by choosing α=7, the value of n derived through the above equation gives a probability of loss of less than 10⁻¹⁰. Therefore, the constant α=7 is used for the subsequent provisioning of various resources.

[0049] The equation for determining the number of resources required then becomes:

[0050] resourse =┌R_resource+7{square root over (R_resource)}┐.

[0051] For each of the subsequent discussions on the different resources being provisioned, the R_resourceequation above is used to determine the holding rate for each resource. This is then substituted into the above resource equation to determine the number of instances of the resource required.

[0052] The SEB parameter defines the number of switch extension blocks of memory available for use by calls on the switch. SEB parameters are associated with every type of call and are held for the duration of the call. The duration of the call is known in the art as the average call hold time (CHT). The SEB parameter is defined as follows:

[0053] X_SEB=(1)·CHT,

[0054] $R_{\mathrm{SEB}}=\frac{1.5·\mathrm{BHCA}·X_{\mathrm{SEB}}}{3600},$

[0055] and

[0056] SEB=┌R_SEB+7{square root over (R_SEB)}┐.

[0057] The number of call condense blocks (CCB) is a parameter that is required for all switch units. A call condense block is a portion of memory that is associated with a call throughout it duration. This resource contains information such as the identity of the calling and called parties. The parameter determines the maximum number of simultaneous calls. The number of CCBs is determined by the following:

[0058] X_CCB=(1)·CHT,

[0059] $R_{\mathrm{CCB}}=\frac{1.5·\mathrm{BHCA}·X_{\mathrm{CCB}}}{3600},$

[0060] and

[0061] CCB =┌R_CCB+7{square root over (R_CCB)}┐.

[0062] The parameter that determines the number of memory data blocks allocated to a call is referred to as MDB. This block of memory is related to the number of simultaneous inter-system hand-offs occurring. MDBs are seized once an inter-system hand-off takes place and is held for the duration of the call or until the roaming radiotelephone returns to its home switch (i.e., does an inter-system hand-off back to its originating switch).

[0063] The MDBs are determined by the total of the percentage of inter-system hand-off incoming calls (IHIC) and the percentage of inter-system hand-off outgoing calls (IHOG). The MDBs are provisioned as follows:

[0064] X_MDB=(IHIC+IHOG)·CHT,

[0065] $R_{\mathrm{MDB}}=\frac{1.5·\mathrm{BHCA}·X_{\mathrm{MDB}}}{3600},$

[0066] and

[0067] MDB=┌R_MDB+7{square root over (R_MDB)}┐.

[0068] The hand-off block count (HOB) parameter defines the number of hand-off data blocks to be allocated. One hand-off block is allocated for every hand-off attempt in progress. The holding times of HOBs vary depending on whether the HOB is being used for an intra-system hand-off (HHT) or inter-system hand-off (IHHT). In the preferred embodiment, the hand-off holding time is six seconds and the inter-system hand-off holding time is 20 seconds. The HOB parameter is provisioned as follows:

[0069] X_HOB=(HO+HONORESP)·HHT+(IHIC+IHOG)·IHHT,

[0070] X_HOB=(HO+HONORESP)·6+(IHIC+IHOG)·20

[0071] $R_{\mathrm{HOB}}=\frac{1.5·\mathrm{BHCA}·X_{\mathrm{HOB}}}{3600},$

[0072] and

[0073] HOB=┌R_HOB+7{square root over (R_HOB)}┐.

[0074] Feature data blocks (FDB) are associated with different call related features such as call forwarding (CFW), call waiting (CWT), three way calling (3WC), surveillance (SRV), cellular extension phone (CEP), call forward do not answer (CFD), and treatments (TRMT). In the preferred embodiment, these memory blocks are comprised of different sizes: large, medium, and small. The different sizes exist in order to achieve data store efficiency. The holding time for each FDB varies with the length of time that the feature is used. As in above resources, the designations CFW, CWT, 3WC, CFD, CEP, and SRV represent the percentage of calls using that particular feature.

[0075] The large feature data blocks are used by call forwarding, call forward do not answer, call surveillance, and cellular extension phone (group ringing). These resources are determined by:

[0076] X_FDB-LG=(CFW+CFD+CEP+SRV)·CHT+(ALCEP−1)·CEP·PRHT,

[0077] where PRHT is the page response holding time, CHT is the call holding time, and ALCEP is the average number of legs per CEP call

[0078] The page response holding time is the length of time required for the first radiotelephone to respond to a page. In the preferred embodiment, this time is set at six seconds. Alternate embodiments use other lengths of time for this holding time. The above equation for XFDB-LG then becomes:

[0079] X_FDB-LG=(CFW+CFD+CEP+SRV)·CHT+(ALCEP−1)·CEP·6.

[0080] Substituting X_FDB-LGinto the R_resourceequation above yields: $R_{\mathrm{FDB}-\mathrm{LG}}=\frac{1.5·\mathrm{BHCA}·X_{\mathrm{FDB}-\mathrm{LG}}}{3600}.$

[0081] Therefore, the number of large feature data blocks to be provisioned is determined by:

[0082] FDB_LG=┌R_FDB-LG+7{square root over (R_FDB-LG)}┐.

[0083] Medium feature data blocks are used by the features call waiting, three-way calling, and call treatments. These resources are provisioned similar to the large feature data blocks:

[0084] X_FDB-MED=(LEGS_CWT+LEGS_3WC·3WC+TRMT)·CHT,

[0085] X_FDB-MED=(2·CWT+3·3WC+TRMT)·CHT,

[0086] $R_{\mathrm{FDB}-\mathrm{MED}}=\frac{1.5·\mathrm{BHCA}·X_{\mathrm{FDB}-\mathrm{MED}}}{3600},$

[0087] and thus,

[0088] FDB_MED=┌R_FDB-MED+7{square root over (R_FDB-MED)}┐.

[0089] Two medium feature data blocks are required when the call waiting feature is invoked. One medium feature data block is needed for each leg of the call. Similarly, when three-way calling is used, when all three parties are bridged, a medium feature data block is required for each leg of the three-way all.

[0090] The small FDB parameter is associated with features such as call forward and call forward do not answer. Assuming that call forward is always deactivated once it is activated, two small feature data blocks are required for each use of the CFW feature. The provisioning of this resource is similar to the large and medium equations above and is not repeated.

[0091] The above described provisioning of memory blocks represents the use of the general provisioning process of the present invention. Any system resource can be provisioned in a similar way in other embodiments.

[0092] A system operator may additionally choose to provide a buffer of memory blocks beyond those calculated by the general provisioning process.

[0093] This provides a safety margin to guard against a large number of roaming callers entering the system and using system resources, a large number of home subscribers registering for an unforeseen event, or other anomalous events.

[0094] The risk of a traffic increase was determined by examining the resource usage and understanding the likelihood of usage spike occurring on that resource. Resources that are used for each call will most likely have a low probability of overshoot risk because they are already being used at a near capacity level. Those resources that are rarely used, such as the ones associated with specific features, have a higher likelihood of experiencing a usage spike.

[0095] The table of FIG. 4 shows examples of the outcome of the risk margin assessment and the new resource estimates for resources examined above. This table is only an example and will vary between systems due to varying resource usage and varying roaming callers for each system.

[0096] This table shows the system resource in the left column. The actual number of seconds per event for each resource is in the next column. The over-shoot risk determined for a particular system is then listed in the next column along with the correction factor to be applied to the result of the general provisioning process of the present invention.

[0097] In the preferred embodiment, the above provisioning information is provided to the system operator for implementation. The system operator then manually allocates the amount of memory for each call-related event or feature.

[0098] However, an alternate embodiment determines the amount of memory to be allocated for each call-related event and automatically reallocates the required resource without operator intervention. This is accomplished by feeding the number of instances of the required system resource into a system processor that then reallocates the resource accordingly.