Apparatus and method for implementing configurable resource management policies

BACKGROUND OF THE INVENTION

p-00021. Field of the Invention

p-0003The present invention generally relates to the management of system's resources to be assigned to entities requesting services from the system. In particular, albeit not limitatively, the invention relates to the management of resources, particularly radio resources, in radio communications systems like mobile telephony networks. Specifically, the invention concerns an apparatus for implementing configurable policies of resource management.

p-00042. Description of Related Art

p-0005In the field of radio communications networks, several different technologies and several different standards coexist. The radio communications networks of the second generation (so-called “2G” networks, like those complying with the standard GSM—Global System for Mobile communications), which nowadays are the most broadly deployed, and are mostly suited for enabling voice communications, will in the coming years go more and more side by side with radio communications networks of new generation, such as third-generation (“3G”) networks (like those complying with the standard UMTS—Universal Mobile Telecommunications System) and fourth-generation networks (still in the course of being standardized), designed for supporting, in addition to plain voice communications, data exchange and multimedia (e.g., video telephony, television broadcasting and similar) services, as well as broadband data communications networks of the Wireless LAN (WLAN) type.

p-0006A common approach in network deployment is not to completely replace 2G networks already in operation with new-generation networks, rather to integrate the different types of networks. The integration between radio communications networks of new generation with 2G networks is made possible by the new network standards, which are specifically defined in such a way to enable the networks integration. For example, in the 3GPP (Third Generation Partnership Project) specifications, that set forth the characteristics of the UMTS, several procedures are defined enabling the interoperation (“interworking”) with GSM networks (all the 3GPP specification documents cited in this description can be downloaded from the Internet site www.3GPP.org). In particular, in the 3GPP Technical Report (TR) 25.881 titled “Improvement of RRM across RNS and RNS/BSS, Release 5”, and in the 3GPP TR 25.891 titled “Improvement of RRM across RNS and RNS/BSS, Release 6” functional models and network architectures are defined where Common Radio Resource Management (CRRM) policies can be applied.

p-0007A known market trend is that of using, in certain geographic areas referred to as “hot spots”, WLAN technologies, so as to enable users that happen to be located in those areas to enjoy a broadband access to a number of data communications services like Internet access. WLAN technologies can also be integrated within a mobile telephony network, particularly in the access network segment. For this reason, interoperation mechanisms are also being defined that enable WLAN technologies (e.g., complying with the IEEE 802.11 family of standards, or with the ETSI standard known as HIPERLAN2) to intemperate with 3G mobile telephony networks so as to enable access to the transport network thereof. For example, the 3GPP TR 23.934, titled “3GPP system to Wireless Local Area Network (WLAN) interworking functional and architectural definition, Release 6” specifies the functional requirements to be satisfied by those network architectures that include IEEE 802.11 WLAN accesses in the UMTS network. Similarly, the ETSI TR 101.957, tiled “Broadband Radio Access Networks (BRAN): HIPERLAN Type 2; Requirements and architectures for interworking between HIPERLAN/2 and 3^rdgeneration cellular systems”, specifies the interoperation mechanisms of HIPERLAN2 WLANs with the UMTS network.

p-0008Radio communications systems integrating two or more Radio Access Technologies are referred to as “multi-RAT” systems.

p-0009So-called “multi-mode” mobile telecommunications terminals are already available on the market (like cellular phones, palmtops, Personal Digital Assistants—PDAs—, peripheral cards for Personal Computers—PCs, etc.) which can connect to networks complying with different standards, like the GSM, the UMTS, IEEE 802.11b/g/a WLAN. For example, dual-mode mobile phones can work both in GSM and in UMTS systems.

p-0010In the International applications WO 2005/101880 and WO 2005/101889, solutions are proposed to the problem of the decisions to be taken by the network as to which type of radio access is to be assigned to incoming service requests.

p-0011The U.S. published patent application US 2005/0026616, titled “Common radio resource management method in a multi-RAT cellular telephone network”, describes which information has to be exchanged between the different system entities to enable an efficient CRRM policy.

p-0012Generally, CRRM policies are implemented by means of CRRM algorithms that run on specific network equipment, like for example the Radio Network Controllers (RNCS) of a UMTS network, or the Base Station Controllers (BSCS) of a GSM network, and that, upon receiving service requests from users, allocate them on the better pool of radio communications resources, depending on a number of factors like the nature of the requested service, the load status of the network at the time the service request is received, the overall radio resources available.

SUMMARY OF THE INVENTION

p-0013The Applicant has observed that every network operator may be interested in designing its own CRRM algorithms, implementing proprietary CRRM policies that best fit that network operator's needs and desires. However, current implementations of CRRM policies do not allow or at least disfavor this kind of approach.

p-0014Indeed, the standards are essentially silent about the implementation details of CRRM algorithms, so every manufacturer of network equipment has developed its own CRRM algorithms. Thus, presently a network operator wishing to define and implement specific, custom CRRM algorithms has to ask the network equipment manufacturer to customize the network equipment: this has an impact on network equipment costs. Also, CRRM policies may vary in time, to match changes in the network configuration, or in the service requests coming from users; also in these cases, the network operator cannot do anything but ask the network equipment manufacturer to update the CRRM algorithms implemented.

p-0015Thus, the current implementation of CRRM policies is rather rigid.

p-0016The Applicant has thus tackled the problem of how to make the implementation of CRRM policies more flexible, at least from the network operator viewpoint.

p-0017The Applicant has found that by separating the hardware/software implementation of the network equipment from the CRRM algorithms that have to be implemented and executed by them, it is possible for the network operator to design and directly implement custom-defined CRRM algorithms, as well as to modify them when needed or desired, without the need to redesign the network equipment, i.e., without the need of any intervention of the network equipment manufacturer.

p-0018Essentially, the present invention sets forth an apparatus which, as far as the resource management policies are concerned, is configurable by, e.g., the network operator; thanks to the present invention, the network operator is thus left free to configure the equipment governing the operation of its system (e.g., network equipment like the BSCs, the RNCs, or other devices that govern the operation of radio communications networks, particularly of multi-RAT type) so as to choose, define, implement, and possibly vary after implementation the desired algorithms for managing the resources of the system, e.g. radio resources of a multi-RAT system, and the policy of assignment of such system resources to requesting entities, like users of mobile communications terminals.

p-0019According to an aspect of the present invention, a resource management apparatus as set forth in appended claim <b>1</b> is provided, adapted to implement resource management policies for the management of resources of a system, said resources being susceptible of being assigned to entities requesting services to the system. The resource management apparatus comprises: <ul><li id="ul0001-0001" num="0000"><ul><li id="ul0002-0001" num="0019">a configuration interface adapted to receive resource management configuration data from a user, said configuration data including a resource management decision logic adapted to specify a resource management policy;</li><li id="ul0002-0002" num="0020">a resource management policy implementation unit responsive to service requests from the requesting entities and adapted to manage the assignment of the resources of the system to the requesting entities based on the resource management decision logic,</li></ul></li></ul>

p-0020wherein said configuration interface is adapted to receive, and said resource management policy implementation unit is adapted to manage resource management decision logics structured as a set of one or more decision rules, each decision rule comprising:

p-0021a description of at least one service request intended to be governed by said decision rule;

p-0022a description of a state of the system in respect of which the decision rule is intended to apply; and

p-0023an action to be taken by the apparatus in case the decision rule applies.

p-0024Preferred features are set forth in the dependent claims.

p-0025According to another aspect of the present invention, a method as set forth in appended claim <b>21</b> is provided, of implementing resource management policies for the management of resources of a system, susceptible of being assigned to entities requesting services to the system. The method comprises: <ul><li id="ul0003-0001" num="0000"><ul><li id="ul0004-0001" num="0027">providing to a resource management apparatus, through a configuration interface thereof, resource management configuration data, said configuration data including a resource management decision logic adapted to specify a resource management policy;</li><li id="ul0004-0002" num="0028">having the resource management apparatus manage the assignment of the resources of the system to the requesting entities in response to received service requests based on the resource management decision logic;</li></ul></li></ul>

p-0026wherein said resource management decision logics is structured as a set of one or more decision rules, each decision rule comprising:

p-0027a description of at least one service request intended to be governed by said decision rule;

p-0028a description of a state of the system in respect of which the decision rule is intended to apply; and

p-0029an action to be taken by the apparatus in case the decision rule applies.

p-0030A decision logic structured as (a) set(s) of one or more decision rules ensures a high degree of flexibility. The decision rules are freely definable by the user, e.g. the network operator, simply respecting a predetermined syntax. Thus, it is relatively easy to build several different decision logics, defining different rules, so as to implement differentiated resource management policies.

BRIEF DESCRIPTION OF THE DRAWINGS

p-0031The features and advantages of the present invention will be made apparent by reading the following detailed description of an embodiment thereof, provided merely by way on non-limitative example, description that will be conducted making reference for better clarity to the attached drawings, wherein:

p-0032<figref idrefs="DRAWINGS">FIG. 1</figref> schematically shows an illustrative scenario wherein the present invention is applicable;

p-0033<figref idrefs="DRAWINGS">FIG. 2</figref> schematically shows, in terms of functional blocks, the structure of an illustrative, multi-RAT communications network reflecting the scenario of <figref idrefs="DRAWINGS">FIG. 1</figref>;

p-0034<figref idrefs="DRAWINGS">FIG. 3</figref> schematically shows, still in terms of functional blocks but in greater detail, an architecture of the multi-RAT network of <figref idrefs="DRAWINGS">FIG. 2</figref>;

p-0035<figref idrefs="DRAWINGS">FIG. 4A</figref> schematically shows, in terms of functional blocks, an illustrative structure of a system according to an embodiment of the present invention, adapted to enable configuring and then implementing customized CRRM algorithms;

p-0036<figref idrefs="DRAWINGS">FIG. 4B</figref> shows, in terms of a schematic flowchart, the main steps of a phase of set-up for configuring a customized CRRM algorithm, according to an embodiment of the present invention;

p-0037<figref idrefs="DRAWINGS">FIG. 5</figref> schematically shows an illustrative table of a set of tables implementing the rules of a CRRM decision logic, in an embodiment of the present invention;

p-0038<figref idrefs="DRAWINGS">FIG. 6</figref> schematically shows another illustrative table of the set of tables implementing the rules of a CRRM decision logic, in an embodiment of the present invention;

p-0039<figref idrefs="DRAWINGS">FIG. 7</figref> shows, in terms of a schematic flowchart, the main flow of operation of the CRRM algorithm, in an embodiment of the present invention;

p-0040<figref idrefs="DRAWINGS">FIG. 8</figref> shows, in terms of a schematic flowchart, the main steps of an operation included in the flowchart of <figref idrefs="DRAWINGS">FIG. 7</figref> of scanning the CRRM decision logic table of <figref idrefs="DRAWINGS">FIG. 5</figref>;

p-0041<figref idrefs="DRAWINGS">FIGS. 9A and 9B</figref> show, in terms of a schematic flowchart, the main steps of an operation included in the flowchart of <figref idrefs="DRAWINGS">FIG. 7</figref> of scanning the CRRM decision logic table of <figref idrefs="DRAWINGS">FIG. 6</figref>, in an embodiment of the present invention;

p-0042<figref idrefs="DRAWINGS">FIG. 10</figref> depicts a schematic deployment of cells of a GSM and a UMTS networks used in an example provided in the description;

p-0043<figref idrefs="DRAWINGS">FIG. 11</figref> show a CRRM decision logic table used in said example.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT(S) OF THE INVENTION

p-0044In the following of the present description, reference will be made, merely by way of non-limitative example, to the currently known types of radio communications networks, namely the GSM, the GPRS (General Packet Radio Service), the EDGE (Enhanced Data rate for GSM Evolution), the UMTS (Universal Mobile Telecommunications System), the WLAN, and to CRRM algorithms that are used for the interworking and the cooperation of such networks. However, it will be appreciated that the present invention has a more general applicability.

p-0045According to the present invention, the apparatuses that implement resource management policies are adapted to enable the definition of categories of resources to be managed; such categories are hereinafter referred to as “pools” of resources. In general, for the purposes of the present invention, a pool of resources is a set of one or more resources belonging to the considered system, which may have homogeneous properties (the specific property(ies) may vary according to the network operator's needs), or simply that, for some reason, the network operator wants to consider as homogeneous

p-0046In the example considered in the present description, the following pools of network (radio) resources are identified (this subdivision in categories is merely illustrative: different subdivisions may be considered): <ul><li id="ul0005-0001" num="0000"><ul><li id="ul0006-0001" num="0050">radio resources belonging to the different RATs, e.g. GERAN (GPRS/EDGE Radio Access Network) radio resources, UTRAN (UMTS Terrestrial Radio Access Network) radio resources, BRAN (Broadband Radio Access Network)/WLAN radio resources;</li><li id="ul0006-0002" num="0051">radio resources belonging to different Hierarchical Cellular Structures (HCSs), like for example a macro-cellular layer and a micro-cellular layer that share a same carrier within the UTRAN;</li><li id="ul0006-0003" num="0052">radio resources belonging to different frequency layers (e.g., the 900 MHz and the 1800 MHz layers in GSM); and</li><li id="ul0006-0004" num="0053">UTRAN radio resources based on different modalities and techniques, like for example radio resources of the UTRAN according to the Release 99 of the standard, and radio resources based on the HSDPA (High Speed Downlink Packet Access) Release 5.</li></ul></li></ul>

p-0047For each of the above-listed illustrative pools of resources, specific interworking mechanisms are defined by the standards, that enable the integrated management thereof; examples of such mechanisms are: <ul><li id="ul0007-0001" num="0000"><ul><li id="ul0008-0001" num="0055">inter-RAT or inter-frequency camping mechanisms, that are implemented at the radio communications terminal level and that allow the terminal initially selecting a cell among those belonging to different RATs or different frequencies (these mechanisms are for example specified in the 3GPP TS 25.304);</li><li id="ul0008-0002" num="0056">inter-RAT or inter-frequency cell reselection mechanisms, that are implemented at the radio communications terminal level and that allow the terminal selecting a cell from those belonging to different RATs or different frequencies (as specified in the cited 3GPP TS 25.304);</li><li id="ul0008-0003" num="0057">inter-RAT directed retry mechanisms, which relate to a procedure controlled by the network for moving the signaling channels used by a generic user from the GSM network to the UMTS network, or vice versa (as specified in the 3GPP TS 25.331);</li><li id="ul0008-0004" num="0058">inter-RAT handover mechanisms, which relate to a procedure controlled by the network for moving a call of a generic user from the GSM network to the UMTS network, or vice-versa (as specified in the above cited 3GPP TS 25.331);</li><li id="ul0008-0005" num="0059">common measurement mechanisms, which relate to a procedure for the exchange of cell load values between the RNC and the BSC (as specified in the 3GPP TS 25.423);</li><li id="ul0008-0006" num="0060">inter-frequency directed retry mechanisms, which relate to a procedure controlled by the network for moving the signaling channels used by a generic user from a frequency of the UTRAN to another, different UTRAN frequency (as specified in the 3GPP TS 25.331); and</li><li id="ul0008-0007" num="0061">inter-frequency handover mechanisms, which relate to a procedure controlled by the network for moving a call of a generic user from a UTRAN frequency to another UTRAN frequency (as specified in the 3GPP TS25.331).</li></ul></li></ul>

p-0048Among the CRRM algorithms that are directed to the joint and synergic management of the radio resources belonging to different pools of resources, like the pools of resources listed above, those algorithms that allocate traffic based on service requests from the users are particularly important. These algorithms allow the network traffic steering onto different pools of resources, depending on the network operator's preferences (reduction of costs, increase of the quality of service perceived by the users, revenues maximization, etc.).

p-0049<figref idrefs="DRAWINGS">FIG. 1</figref> depicts a possible scenario wherein the present invention can be applied. A geographic area of interest, denoted <b>105</b>, is assumed to be served by a GSM network; a portion <b>110</b> of the area <b>105</b> is assumed to be also served by a UMTS network (thus, the area <b>110</b> is served by both the GSM network and the UMTS network); in a portion <b>115</b> of the area <b>110</b>, coverage by a WLAN network is also assumed to exist. This scenario, albeit not limitative for the present invention, is rather true-to-reality, because it assumes that the GSM networks (or other 2G networks), nowadays largely diffused, in some areas (e.g., in urban areas, or along motorways) work side-by-side with UMTS networks (or other 3G networks), which are currently not as broadly deployed as 2G networks, and furthermore that, in limited portions of the territory (e.g., within hotels, or service stations along the motorways), WLAN hot-spots are present that enable a broadband connection to, e.g., the Internet (the fact that, in the considered scenario, the hot-spots <b>115</b> are contained within the area <b>110</b> covered by the UMTS is not to be considered limitative, but it is nonetheless a reasonable assumption, because WLAN hot-spots are usually placed in areas characterized by a high concentration of users with low mobility requiring broadband data communications services).

p-0050<figref idrefs="DRAWINGS">FIG. 2</figref> schematically shows, in terms of functional blocks, the structure of an illustrative, multi-RAT communications network reflecting the scenario of <figref idrefs="DRAWINGS">FIG. 1</figref>. The multi-RAT network comprises in particular a GERAN <b>205</b>, used by GSM/GPRS/EDGE terminals for accessing the network, a UTRAN <b>210</b>, used by UMTS terminals for accessing the network, and a BRAN <b>215</b> used by WLAN terminals for accessing the network. A 3G core network <b>220</b> forms the transport segment of the multi-RAT network.

p-0051The network architecture in <figref idrefs="DRAWINGS">FIG. 2</figref> is shown in greater detail in <figref idrefs="DRAWINGS">FIG. 3</figref>; the core network <b>220</b> is connected to the GERAN <b>205</b> through an interface <b>305</b>, for example the interface called “A” interface or “Gb” interface, depending on the core network domain, to the UTRAN <b>210</b> through an interface <b>310</b>, for example corresponding to the “lu” interface, and to the BRAN <b>215</b> through an interface <b>315</b> (for example, the interface sometimes referred to as the “lu-like” interface).

p-0052The GERAN <b>205</b> comprises, in a way per-se known in the art, Base Station Subsystems (BSS), including Base Transceiver Stations (BTSs) <b>320</b> and BSCs <b>325</b>. The UTRAN comprises, also in a way per-se known in the art, Radio Network Subsystems (RNS), including Node-Bs <b>330</b> and RNCs <b>335</b>. The BRAN <b>215</b> comprises, still in a way per-se known in the art, Access Points (APs) <b>340</b> and Access Points Controllers (APCs) <b>345</b>.

p-0053The BSCs <b>325</b>, the RNCs <b>335</b> and the APCs <b>345</b> may exchange information through the core network <b>220</b>, or, when suitable interfaces <b>350</b> (corresponding to the “lur-g” interface) and <b>355</b> (also referred to as the “lur-like” interface) are provided, they can communicate directly with each other.

p-0054CRRM algorithms can for example reside and be executed by the BSCs <b>325</b>, the RNCs <b>335</b> and the APCs <b>345</b>. Alternatively, a network entity, denoted <b>360</b> in the drawing and hereinafter referred to as “CRRM server” may be provided, dedicated to the common, integrated management of the resources of the multi-RAT network. The CRRM server <b>360</b> may be connected to the BSCs <b>325</b> through an interface <b>365</b>, to the RNCs <b>335</b> through an interface <b>370</b>, and to the APCs through an interface <b>375</b>. The CRRM server <b>360</b> may request to the BSCs <b>325</b> information about the state of the GSM network cells, as well as it may request to the RNCs <b>335</b> information about the state of the UMTS network cells; similarly, the CRRM server may request to the APCs <b>345</b> information about the state of the WLAN hot-spots.

p-0055Based on the specific nature, any service supported by the multi-RAT network may be allocated on one or more radio access networks; for example, a voice communication service may be offered through either the GSM or the UMTS network, whereas a specific data exchange service (e.g. a videocall) can only be provided through the UMTS network or the WLAN. The CRRM algorithms that run in the BSCs <b>325</b>, the RNCs <b>335</b> and the APCs <b>345</b>, or, alternatively, in the CRRM server <b>360</b> determine, based on the current state of the network, whether or not to accept service requests from the users, and which radio access network to use for providing the service, if the latter is accepted.

p-0056According to an embodiment of the present invention, a network operator can, without redesigning the BSCs <b>325</b>, the RNCs <b>335</b> and the APCs <b>345</b>, or, alternatively, of the CRRM server <b>360</b>, configure these network apparatuses so that they implement custom-defined CRRM algorithms. Non-limitative embodiments of the invention will be described in detail hereinafter.

p-0057Existing standards prescribe that, for each cell of the GSM and UMTS networks, it is possible to define different types of lists of adjacent cells; these lists are typically used in a phase of setting of the radio measurements that the mobile communications terminals can perform, e.g. for evaluating the opportunity of passing from one cell to another in order to get a better coverage (see for example 3GPP TS 25.215).

p-0058For example, according to the 3GPP TS 25.331, to each cell of the UTRAN the following adjacency lists are associated: <ul><li id="ul0009-0001" num="0000"><ul><li id="ul0010-0001" num="0073">list of intra-frequency adjacencies, i.e. the list of the cells of the UTRAN that are adjacent to the considered UTRAN cell and that use the same carrier frequency;</li><li id="ul0010-0002" num="0074">list of inter-frequency adjacencies, i.e. the list of the cells of the UTRAN that are adjacent to the considered UTRAN cell and that use different carrier frequencies;</li><li id="ul0010-0003" num="0075">list of GSM inter-RAT adjacencies, i.e. the list of the cells of the GSM (GERAN) network that are adjacent to the considered UTRAN cell.</li></ul></li></ul>

p-0059According to the 3GPP TS 04.18, to each cell of the GSM (GERAN) the following adjacency lists are associated: <ul><li id="ul0011-0001" num="0000"><ul><li id="ul0012-0001" num="0077">list of GSM neighbor cells, containing the list of cells of the GSM (GERAN) network adjacent to the GSM (GERAN) cell to which the mobile terminal is camped;</li><li id="ul0012-0002" num="0078">list of 3G neighbor cells, containing a list of cells of the UMTS network adjacent to the GSM (GERAN) cell to which the mobile terminal is camped.</li></ul></li></ul>

p-0060The 3GPP specification (3GPP TS 25.214) prescribes that the mobile terminal measures the radio quality of the pilot signal transmitted by the cells that are adjacent to the cell to which the terminal is camped.

p-0061The 3GPP specifications also set forth several modalities for making the BSCs and the RNCs aware of the functional characteristics of the mobile terminals (referred to as “terminal capabilities”).

p-0062For example, the UMTS network can get the functional characteristics of the terminal when the RRC (Radio Resource Control) connection is being set up: when a terminal establishes the connection with the network, a user context can be created within the RNC, where the information related to the terminal capabilities are stored.

p-0063In the GERAN, the request of the terminal capabilities can take place by means of a message called “CLASSMARK ENQUIRY” (as specified in the 3GPP TS 04.18); in the case of a multi-RAT terminal, the mobile terminal provides to the GERAN also the capabilities related to the UTRAN.

p-0064The above information can be used by the CRRM algorithms to take the most appropriate decisions according to the terminal capabilities. The pools of resources that a terminal can use, in fact, depend both on radio coverage and on the terminal capabilities.

p-0065A structure of an apparatus according to an embodiment of the present invention which is configured for implementing a custom-defined CRRM algorithm is schematically depicted in <figref idrefs="DRAWINGS">FIG. 4A</figref> in terms of functional modules; the apparatus may for example be the CRRM server <b>360</b>, or the BSCs <b>325</b>, the RNCs <b>335</b>, the APCs <b>345</b>, and in general any network equipment intended to implement CRRM policies; the depicted functional modules may for example be software modules of a software installed in, and executed by the network equipment that is intended to implement the CRMM policies. The configurable CRRM policy implementation apparatus comprises a CRRM algorithm configuration module <b>405</b> and a CRRM algorithm implementation module <b>410</b>. The configuration module <b>405</b> includes a services configuration module <b>415</b>, a pools of resources configuration module <b>420</b>, a list of cells in overlap configuration module <b>425</b>, a module <b>430</b> for the definition of measurements criteria to be used in the definition of the available pools of resources, a module <b>435</b> for the definition of the mode of determination (choice) of alternative pools of resources, a module <b>440</b> for the definition of events counters <b>455</b>, a module <b>445</b> for the definition of look-up tables <b>460</b>, a module <b>450</b> for the definition of a CRRM decision logic; the decision logic, in an embodiment of the present invention (described in detail later) may take the form of a set (e.g., one or more) of tables <b>465</b>, an example of which will be described later. The CRRM algorithm implementation module <b>410</b> includes the counters <b>455</b>, the look-up tables <b>460</b>, the CRRM decision logic, for example implemented as the set of tables <b>465</b>, and a CRRM decision logic tables scanner module <b>470</b>, adapted to scan the CRRM decision logic set of tables <b>465</b> in response to events corresponding to received service requests. An event counter updater module <b>475</b> is also provided, adapted to selectively update the events counters <b>455</b> depending on the received events. According to the present invention, the CRRM algorithm configuration module <b>405</b>, particularly the module <b>450</b> for the definition of a CRRM decision logic, and the CRRM algorithm implementation module <b>410</b>, particularly the CRRM decision logic tables scanner module <b>470</b>, are structured in such a way to manage decision logics that are structured as sets of one or more decision rules that have a homogeneous structure, as will be described in greater detail in the following.

p-0066The functions of the modules shown in <figref idrefs="DRAWINGS">FIG. 4A</figref> will be explained in the following in connection with the description of the operation of the configurable CRRM policy implementation apparatus.

p-0067According to an embodiment of the present invention, for configuring the network equipment so as to implement a desired CRRM algorithm, a set-up procedure is carried out. The main steps of the set-up procedure according to the illustrative invention embodiment considered herein are depicted in the schematic flowchart of <figref idrefs="DRAWINGS">FIG. 4B</figref>, and will be described in detail in the following.

p-0068Set-Up Phase: Definition of the Services

p-0069In this step (block <b>490</b>), the network operator (or, generally, any one who, on behalf of the network operator, is entrusted with the task of defining the CRRM policies to be implemented) defines which service requests have to be considered and managed by the CRRM algorithm to be implemented. This can be done for example by associating a unique identifier to each service which the network operator wants to be managed by the CRRM algorithm. For example, in case the CRRM algorithm has to allow the interworking between 2G and 3G systems, e.g. the interoperation between GERAN and the UTRAN, the service(s) to be managed by the CRRM algorithm should be identified, at the BSC and RNC level, by same or corresponding service identifiers.

p-0070From the BSC side, a service in the Packet-Switched (PS) domain can for example be identified by the Quality of Service (QoS) parameters defined in the Release 99 of the 3GPP specifications; referring to the 3GPP TS 23.107, these QoS parameters include for example a Traffic Class parameter, a Maximum Bitrate parameter, and so on. These QoS parameters are associated with the PDP (Packet Data Protocol) context set-up request (as known to those skilled in the art, a PDP context is a logical association that is created between a mobile terminal and a packet-based data network running across the GPRS or UMTS network and defining aspects like routing, billing, security, etc.). PDP contexts having a same or similar QoS profile may be grouped into a same PFC (Packet Flow Context). In the Release 99 of the GPRS standard, a SGSN (Serving GPRS Support Node, one of the entities of the GPRS system) is able to provide to the BSS (Base Station System, composed by a BSC and by the BTSs that are controlled by such BSC) information related to the ongoing user data transmission in terms of a BSS PFC. These are used to describe the QoS characteristics for data transmission for the mobile terminals, and are identified in terms of their PFI (Packet Flow Identity).

p-0071The QoS parameters associated with each PFC are then communicated to the BSC in aggregate form (ABQPs—Aggregate BSS QoS Parameters), as exemplified in the following table:

p-0072<tables id="TABLE-US-00001" num="00001"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center" /><tbody valign="top"><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>ABQP for streaming service session (e.g. PFI = 10)</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="offset" colwidth="42pt" align="left" /><colspec colname="1" colwidth="42pt" align="center" /><colspec colname="2" colwidth="133pt" align="center" /><tbody valign="top"><row><entry /><entry>Traffic Class</entry><entry>STREAMING</entry></row><row><entry /><entry namest="offset" nameend="2" align="center" rowsep="1" /></row><row><entry /><entry>GBR_DL</entry><entry>32 kbps</entry></row><row><entry /><entry>GBR_UL</entry><entry>32 kbps</entry></row><row><entry /><entry namest="offset" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables><br /> which is an example of the values of the ABQPs for a streaming service over GPRS/EGPRS (GBR_DLand GBR_ULstand for the Guaranteed Bit Rate in downlink and uplink, respectively).

p-0073Each PFC is identified by the PFI; according to an embodiment of the present invention, the definition of which services the CRRM algorithm is intended to manage in the BSC may be done exploiting the PFI, for example mapping the PFIs onto unique identifiers of the services, to be used by the CRRM algorithm being configured; the table below provides an example of definition of the services by mapping the respective unique identifiers (ID_s≧1) to the PFIs.

p-0074<tables id="TABLE-US-00002" num="00002"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="4"><colspec colname="1" colwidth="14pt" align="center" /><colspec colname="2" colwidth="56pt" align="left" /><colspec colname="3" colwidth="21pt" align="center" /><colspec colname="4" colwidth="126pt" align="left" /><thead><row><entry namest="1" nameend="4" align="center" rowsep="1" /></row><row><entry>ID_s</entry><entry>Description</entry><entry>PFI</entry><entry>ABQP</entry></row><row><entry namest="1" nameend="4" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="4"><colspec colname="1" colwidth="14pt" align="center" /><colspec colname="2" colwidth="56pt" align="left" /><colspec colname="3" colwidth="21pt" align="char" char="." /><colspec colname="4" colwidth="126pt" align="left" /><tbody valign="top"><row><entry>1</entry><entry>Voice</entry><entry>1</entry><entry>{“CONVERSATIONAL”, 12200, 12200}</entry></row><row><entry>2</entry><entry>Video streaming</entry><entry>10</entry><entry>{“STREAMING”, 32000, 32000}</entry></row><row><entry>. . .</entry><entry /><entry /><entry>. . .</entry></row><row><entry namest="1" nameend="4" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

p-0075From the RNC side, a service request is translated into a corresponding request for setting up a Radio Access Bearer (RAB) with a specific QoS. The different services can thus be univocally identified for example considering the following parameters associated with the RAB QoS profile:

p-0076{<class>, <transferDelay>, <UL_guaranteedBitRate>, <UL_maximumBitRate>, <DL_guaranteedBitRate>, <DL_maximumBitRate>}

p-0077which are associated with the requested service and respectively represent the traffic class (which can be conversational, streaming, interactive or background), the maximum transfer delay of the data packets, the average bit rate to be guaranteed in uplink and downlink, the maximum bit rate in uplink and downlink. The table below provides an example of definition of the services' unique identifiers (ID_s≧1) in RNC, based on the RAB parameters:

p-0078<tables id="TABLE-US-00003" num="00003"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="21pt" align="center" /><colspec colname="2" colwidth="42pt" align="left" /><colspec colname="3" colwidth="154pt" align="left" /><thead><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry>ID_s</entry><entry>Description</entry><entry>RAB parameters</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>1</entry><entry>Voice</entry><entry>{“CONVERSATIONAL”, 0., 12200, 12200, 12200,</entry></row><row><entry /><entry /><entry>12200}</entry></row><row><entry>3</entry><entry>Videocall</entry><entry>{“CONVERSATIONAL”, 0., 64000, 64000, 64000,</entry></row><row><entry /><entry /><entry>64000}</entry></row><row><entry>4</entry><entry>Video</entry><entry>{“STREAMING”, 0., 16000, 16000, 128000,</entry></row><row><entry /><entry>streaming</entry><entry>128000}</entry></row><row><entry>. . .</entry><entry /><entry>. . .</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

p-0079It should be noted that the same or different identifiers can be used for similar services in BSC and in RNC. The identifier should be unique in the table referring to BSC and in the table referring to RNC. In the previous illustrative tables, for example, in each table there are not replicated identifiers, but in both the tables the voice service is identified by ID_s=1.

p-0080Set-Up Phase: Definition of Pools of Resources for the RNCs and BSCs

p-0081In this step (block <b>491</b>), the network operator defines, for each RNC and each BSC, entities referred to as “pools of resources”. As mentioned in the foregoing, In general, for the purposes of the present invention, a pool of resources is a set of one or more resources belonging to the considered system, which may have homogeneous properties (the specific property(ies) may vary according to the network operator's needs), or simply that, for some reason, the network operator wants to consider as homogeneous. Examples of pools of resources that may be defined in the case herein considered of a multi-RAT mobile telephony network are provided in the foregoing. According to an embodiment of the present invention, a pool of resources is characterized by a list of cells that are associated therewith (as working assumption, it is assumed that each cell in the list of cells associated with the pool of resources belongs to one pool only, but this is not to be considered limitative).

p-0082The definition of the number of pools of resources and of the cells associated with each pool of resources is done by the network operator, and is susceptible of being modified. In this step of the set-up phase the network operator defines the number N_pof pools of resources for the specific CRRM algorithm being configured, with 1≦N_p. The table below provides an example of definition of pools of resources:

p-0083<tables id="TABLE-US-00004" num="00004"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="84pt" align="center" /><colspec colname="2" colwidth="133pt" align="left" /><thead><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row><row><entry>ID_p</entry><entry>Description</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>1</entry><entry>GSMTO1, GSMTO2, GSMTO3</entry></row><row><entry>2</entry><entry>GSMTO4, GSMTO5, UMTSTO1</entry></row><row><entry>. . .</entry><entry>. . .</entry></row><row><entry>N_p− 1</entry><entry>UMTSTO2</entry></row><row><entry>N_p</entry><entry>UMTSTO3, GSMTO5</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables><br /> where IDp=1, . . . , N_pis the identifier of the generic pool of resources, and GSMTO<b>1</b>, GSMTO<b>2</b>, GSMTO<b>3</b>, GSMTO<b>4</b>, GSMTO<b>5</b>, UMTSTO<b>1</b>, UMTSTO<b>2</b>, UMTSTO<b>3</b>, GSMTO<b>5</b> are labels of GSM or UMTS cells in the illustrative network of <figref idrefs="DRAWINGS">FIGS. 2 and 3</figref>.

p-0084Set-Up Phase: Definition of Overlaps Between Cells

p-0085In this step (block <b>492</b>), the network operator defines, for each cell, which other cells, belonging to pools of resources different from the one to which the considered cell belongs, are in overlap with the considered cell. As mentioned in the foregoing, the 3GPP specifications already allow associating to each cell different lists of adjacent cells (e.g., intra-frequency, inter-frequency, inter-RAT adjacency). These lists are normally used by the network for managing the user mobility and for guaranteeing services continuity when a user moves. According to an embodiment of the present invention, a more specific information is defined, to be exploited by the CRRM algorithm, consisting in the lists of overlaps defined in this set-up phase, that specify which cells, belonging to different pools of resources, cover a common area or portion of area: users that are located in areas served by different cells may for example use any one of the available pools of resources. Based on the definition of the cells' overlaps, the CRRM algorithm can choose, among the different possible alternatives, the pool of resources that allow optimizing the network operation.

p-0086The table below gives an example of definition of overlaps between the cells:

p-0087<tables id="TABLE-US-00005" num="00005"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="offset" colwidth="35pt" align="left" /><colspec colname="1" colwidth="77pt" align="left" /><colspec colname="2" colwidth="105pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="2" align="center" rowsep="1" /></row><row><entry /><entry /><entry>List of cells of other</entry></row><row><entry /><entry>Cell</entry><entry>pools in overlap</entry></row><row><entry /><entry namest="offset" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>GSMTO1</entry><entry>GSMTO4, UMTSTO2</entry></row><row><entry /><entry>GSMTO4</entry><entry>GSMTO1, UMTSTO2</entry></row><row><entry /><entry>. . .</entry><entry>. . .</entry></row><row><entry /><entry namest="offset" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables><br /> where it has been assumed by way of example that a GSM cell GSMTO<b>1</b> is in overlap with the GSM cell GSMTO<b>4</b> and with the UMTS cell UMTSTO<b>2</b>, and the GSM cell GSMTO<b>4</b> is in overlap with the GSM cell GSMTO<b>1</b> and with the UMTS cell UMTSTO<b>2</b>.

p-0088Set-Up Phase: Definition of the Measurement Criteria

p-0089In a way similar to what provided for by the specifications (3GPP TS 25.331 and TS 05.08) in respect of the adjacent cells, in this step (block <b>493</b>), the network operator defines, on a cell-by-cell basis and depending on the capabilities of the mobile terminals, which measurements have to be performed by the mobile terminals on the cells in overlap with the considered cell.

p-0090Set-Up Phase: Definition of the Mode of Determination of Alternative Pools of Resources

p-0091In this step (block <b>494</b>), the network operator defines, for each cell, the modality by which the determination (choice) of the possible alternative pools of resources is made. In particular, according to an embodiment of the present invention, either one of two modes may be defined: a “blind” mode and a “measure-based” mode. In the “blind” mode, when a service is requested through a certain cell, the alternatives for the selection of the most appropriate pool of resources are determined uniquely from the list of cells that are in overlap with the considered cell. In the “measure-based” mode, the mobile terminals perform measures on the adjacent cells, and provides the results of the measures to the network; thus, when a service is requested to a certain cell, the alternatives for the selection of the most appropriate pool of resources are determined from the list of cells that are in overlap with the considered cell, taking into account only the cells that are suitable from a radio coverage point of view (according to the measurement performed by the mobile terminal).

p-0092In particular, in an embodiment of the present invention, the definition of the mode of determination of the alternative pools of resources is made on a cell-by-cell basis; the table below provides an example of definition:

p-0093<tables id="TABLE-US-00006" num="00006"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="offset" colwidth="42pt" align="left" /><colspec colname="1" colwidth="84pt" align="left" /><colspec colname="2" colwidth="91pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="2" align="center" rowsep="1" /></row><row><entry /><entry>Cell</entry><entry>Mode</entry></row><row><entry /><entry namest="offset" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>GSMTO1</entry><entry>Blind</entry></row><row><entry /><entry>GSMTO4</entry><entry>Measure based</entry></row><row><entry /><entry>. . .</entry><entry>. . .</entry></row><row><entry /><entry namest="offset" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables><br /> where it has been assumed that for the GSM cell GSMTO<b>1</b> the “blind” mode has been selected, whereas for the GSM cell GSMTO<b>4</b> the “measure based” mode has been selected.

p-0094Set-Up Phase: Definition of Event Counters

p-0095In this step (block <b>495</b>) the network operator may define one or more counters of events corresponding to service requests; counting the events is useful to the CRRM algorithm for taking the most appropriate decision.

p-0096According to an embodiment of the present invention, a generic event, corresponding to a service request, may be characterized, within the network, by an n-uple of parameters comprised for example of the following elements:

p-0097<tables id="TABLE-US-00007" num="00007"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="49pt" align="left" /><colspec colname="2" colwidth="168pt" align="left" /><thead><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row><row><entry>Element's</entry><entry /></row><row><entry>name</entry><entry>Description</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>s</entry><entry>Identifier of the requested service</entry></row><row><entry /><entry>(1 ≦ s)</entry></row><row><entry>type</entry><entry>Request type:</entry></row><row><entry /><entry>0: new request, 1: HandOver (HO)</entry></row><row><entry>origin</entry><entry>Pool of resources to which the cell on which the terminal</entry></row><row><entry /><entry>is camped belongs</entry></row><row><entry /><entry>(1 ≦ origin ≦ N_p)</entry></row><row><entry>dest(1)</entry><entry>Possibility of re-allocation on pool of resources 1</entry></row><row><entry /><entry>(True, False)</entry></row><row><entry>dest(2)</entry><entry>Possibility of re-allocation on pool of resources 2</entry></row><row><entry /><entry>(True, False)</entry></row><row><entry>. . .</entry><entry>. . .</entry></row><row><entry>dest(N_p− 1)</entry><entry>Possibility of re-allocation on pool of resources N_p− 1</entry></row><row><entry /><entry>(True, False)</entry></row><row><entry>dest(N_p)</entry><entry>Possibility of re-allocation on pool of resources N_p</entry></row><row><entry /><entry>(True, False)</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables><br /> wherein s denotes the requested service (by means of the unique identifier ID_s) defined as discussed in the foregoing); type specifies whether the service request is a new request or rather it is a request due to a HO from another cell; origin is an identifier (ID_p=1, . . . , N_p, as discussed above) of the pool of resources to which the cell where the mobile terminal is camped at the time the service is requested belongs; dest(i) is a Boolean flag indicating, for the generic i-th pool of resources, whether or not that pool resources can be used in alternative to the pool of origin: according to the present invention, the value of this flag is assigned by the network based on the specified mode of determination of the alternative pools of resources (as discussed in the foregoing). In particular, the flag dest(i)=True for i=pool of the cell where the mobile terminal is camped at the time the service is requested.

p-0098The table below provides an example of event, under the assumption that N_p=4, that a new service request (i.e., not a handover) is received through a cell belonging to the pool of resources ID_p=1, and that the network evaluates that the service request may be satisfied also by the pools of resources ID_p=3 and ID_p=4, but not by the pool of resources ID_p=2:

p-0099<tables id="TABLE-US-00008" num="00008"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="42pt" align="left" /><colspec colname="2" colwidth="21pt" align="center" /><colspec colname="3" colwidth="154pt" align="left" /><thead><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry>Element's</entry><entry /><entry /></row><row><entry>name</entry><entry>Value</entry><entry>Comment</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>s</entry><entry>2</entry><entry>Service identifier</entry></row><row><entry>type</entry><entry>0</entry><entry>New request (not HO)</entry></row><row><entry>origin</entry><entry>1</entry><entry>The request came through a cell of the pool of</entry></row><row><entry /><entry /><entry>resources number 1</entry></row><row><entry>dest(1)</entry><entry>T</entry><entry>The pool of resources number 1 can be used for</entry></row><row><entry /><entry /><entry>satisfying the request</entry></row><row><entry>dest(2)</entry><entry>F</entry><entry>The pool of resources number 2 cannot be used for</entry></row><row><entry /><entry /><entry>satisfying the request</entry></row><row><entry>dest(3)</entry><entry>T</entry><entry>The pool of resources number 3 can be used for</entry></row><row><entry /><entry /><entry>satisfying the request</entry></row><row><entry>dest(4)</entry><entry>T</entry><entry>The pool of resources number 4 can be used for</entry></row><row><entry /><entry /><entry>satisfying the request</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

p-0100Let N_cbe the number of the distinct events counters defined by the network operator, it is 0≦N_c.

p-0101According to an embodiment of the present invention, the generic event counter may be defined to be of integer type or of real type.

p-0102Each event counter of integer type is associated with a corresponding event: the occurrence of such event causes the counter value to be incremented.

p-0103Real-type counters are defined as the ratio of two integer-type counters, specified by the network operator; therefore, each event counter of real type has associated therewith two counters of integer type, one for the numerator and the other for the denominator.

p-0104For each counter defined by the network operator, the network keeps track of the counter values for each cell (i.e., a generic event counter has multiple instances, one per each cell), and each event counter in a cell is incremented only for events related to that cell.

p-0105The generic counter, either of integer type or of real type, is identified by a respective counter identifier ID_c, where ID_c≦1 and ID_c≧N_c.

p-0106Since the same ID_crefers to many counters (one for each cell), the counters will be referenced in the following as:

p-0107<tables id="TABLE-US-00009" num="00009"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="56pt" align="left" /><colspec colname="2" colwidth="161pt" align="left" /><thead><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row><row><entry>Variable</entry><entry>Description</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>c_IDc[<cell>]</entry><entry>Value of the counter with identifier IDc in cell <cell></entry></row><row><entry>c_IDc[pool=ID_p]</entry><entry>Value of the counter with identifier IDc in a cell of</entry></row><row><entry /><entry>the pool with identifier ID_P</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

p-0108It has to be noted that the event counter associated with a pool of resources (second row in the previous table) has to be interpreted as a compact notation to represent each of the instances of the event counter associated to the cells belonging to the pool of resources; in other words, it is not a unique counter associated to all the cells of the pool of resources, rather it is a plurality of counter instances.

p-0109Two types of counters are defined: integer-type counters and real-type counters.

p-0110In particular, integer-type counters are defined as exemplified in the following table:

p-0111<tables id="TABLE-US-00010" num="00010"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="49pt" align="center" /><colspec colname="2" colwidth="168pt" align="left" /><thead><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row><row><entry>ID_c</entry><entry>Event description (not including the origin field)</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>1</entry><entry>s₁, type₁, dest(1)₁, . . . , dest(N_p)₁</entry></row><row><entry>2</entry><entry>s₂, type₂, dest(1)₂, . . . , dest(N_p)₂</entry></row><row><entry>. . .</entry><entry>. . .</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

p-0112It is observed that the origin field of the event is not taken explicitly into consideration because, as mentioned above, each event counter in a cell is incremented only for events related to that cell.

p-0113In the definition of an event counter, any field of the event description may be replaced by a wildcard, e.g. a “*”, to specify that the field may take any value.

p-0114A generic event counter may also be associated with two or more different events (in such a case, in the illustrative table above, two or more rows will be provided for that counter, each row specifying a different event that causes the counter value to be altered, particularly incremented). Similarly, a same event may be associated with two or more different counters.

p-0115Real-type counters can be specified by the network operator, like in the illustrative table below:

p-0116<tables id="TABLE-US-00011" num="00011"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="63pt" align="center" /><colspec colname="2" colwidth="49pt" align="center" /><colspec colname="3" colwidth="105pt" align="center" /><thead><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry>ID_c</entry><entry>ID_cnumerator</entry><entry>ID_cdenominator</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>3</entry><entry>ID_c1</entry><entry>ID_c1′</entry></row><row><entry>4</entry><entry>ID_c2</entry><entry>ID_c2′</entry></row><row><entry>. . .</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

p-0117It is to be noted that each counter with a specific identifier ID_ccan be either integer or real, not both integer and real at the same time; in other words, this means that the same identifier can not be present in both the tables (integer counters and real counters) at the same time.

p-0118By way of example, the following two tables are used to define three counters (N_c=3); the first table defines two integer-type counters with identifier ID_c=1 and ID_c=2 (the first counter is incremented whenever a service request with ID_s=2 or ID_s=8 occurs whereas the second counter is incremented whenever a service request with ID_s=5 occurs) and the second table defines one real-type counter with identifier ID_c=3 as the ratio between the first (ID_c=1) and the second counter (ID_c=2),

p-0119<tables id="TABLE-US-00012" num="00012"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="112pt" align="center" /><colspec colname="2" colwidth="105pt" align="left" /><thead><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row><row><entry>ID_c</entry><entry>Event description</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>1</entry><entry>2, *, *, *, *, *</entry></row><row><entry>1</entry><entry>8, *, *, *, *, *</entry></row><row><entry>2</entry><entry>5, *, *, *, *, *</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

p-0120<tables id="TABLE-US-00013" num="00013"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="63pt" align="center" /><colspec colname="2" colwidth="49pt" align="center" /><colspec colname="3" colwidth="105pt" align="center" /><thead><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry>ID_c</entry><entry>ID_cnumerator</entry><entry>ID_cdenominator</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>3</entry><entry>1</entry><entry>2</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

p-0121Set-Up Phase: Definition of Look-Up Tables

p-0122In this step (block <b>496</b>), the network operator may define one or more look-up tables, in each of which a predetermined number (e.g., 256) of, e.g., real values may be inserted. The generic look-up table is identified by a unique identifier ID_l, with 1≦ID_l≦N_lwhere N_lis the number of lookup tables defined by the network operator, the generic element of the generic look-up table is identified by an index j (with, in the considered example, 0≦j≦255).

p-0123The table below gives an example of a look-up table that may be defined according to an embodiment of the present invention:

p-0124<tables id="TABLE-US-00014" num="00014"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center" /><tbody valign="top"><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Look-up Table ID_l= 2</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="offset" colwidth="56pt" align="left" /><colspec colname="1" colwidth="28pt" align="center" /><colspec colname="2" colwidth="133pt" align="center" /><tbody valign="top"><row><entry /><entry>Index</entry><entry>Value</entry></row><row><entry /><entry namest="offset" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="offset" colwidth="56pt" align="left" /><colspec colname="1" colwidth="28pt" align="char" char="." /><colspec colname="2" colwidth="133pt" align="char" char="." /><tbody valign="top"><row><entry /><entry>0</entry><entry>3.5</entry></row><row><entry /><entry>1</entry><entry>99</entry></row><row><entry /><entry>. . .</entry></row><row><entry /><entry>255</entry><entry>6.67</entry></row><row><entry /><entry namest="offset" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

p-0125The look-up tables may be used by the CRRM algorithm in the process of deciding which resource devote to satisfy a service request, as will be described in greater detail later. A generic look-up table with ID_l=i may be accessed by the following invocation: <ul><li id="ul0013-0001" num="0000"><ul><li id="ul0014-0001" num="0130">lookup[i,j] <br /> where i and j are integers or real numbers (in the latter case, they are truncated). If no look-up tables have been defined, the invocation returns 0.0. If I<1, the look-up table with ID_l=1 is accessed; if i>N_l, the look-up table with ID_l=N_lis considered. If j<0, the look-up table element in position 0 is considered; if j>255, the element in position 255 is considered. </li></ul></li></ul>

p-0126Set-Up Phase: Definition of the CRRM Decision Logic (Policy)

p-0127In this step (block <b>497</b>), the network operator defines the decision logic of the CRRM algorithm to be implemented.

p-0128According to the present invention, in order to allow flexible configurability of the CRRM policies that the apparatuses have to implement, decision logic structured as sets of one or more decision rules are managed. The decision rules are freely definable by the network operator, provided that a predetermined syntax is respected; as described in detail hereafter, the decision rule syntax is such that the generic decision rule includes: <ul><li id="ul0015-0001" num="0000"><ul><li id="ul0016-0001" num="0134">a description of one or more events, i.e. one or more service requests to which the decision rule is intended to apply;</li><li id="ul0016-0002" num="0135">a description of the state of the system, e.g. of the network,</li><li id="ul0016-0003" num="0136">an action to be undertaken in case the rule is satisfied.</li></ul></li></ul>

p-0129The application of the decision logic calls for checking the decision rules, based on a comparison between a description of a received service request and the descriptions of the service requests specified in the decision rules, and a comparison between a description of the current state of the system at the time the service request is received and the descriptions of the state of the system included in the decision rules.

p-0130The radio resource controllers, namely the BSCs and the RNCs, in addition to the complete knowledge of the load state of the cells they directly manage, can also receive indications about the load state of the cells belonging to the alternative RAT. According to the 3GPP specifications (3GPP TS 25.423), the exchange of cell load values between the RNCs and the BSCs can take place exploiting a procedure called “Common Measurements” (over the lur-g interface, if provided, or over the A interface and the lu interface with the core network; in the latter case, the core network transfers in a transparent way the information that the UTRAN and the GERAN exchange).

p-0131In a multi-RAT, GERAN/UTRAN system, the quantities that the RNCs and the BSCs can exchange are all related to the cells' load. The specifications set forth the possibility that a parameter called “Cell Load” is estimated independently for the uplink and the downlink (possibly, the real-time traffic—“RT Load”—and the non-real-time traffic—“NRT Load”—may be treated independently). In particular, the value for the Cell Load can range from 0 to 100, defined as the percentage of the overall load supported by the generic cell in the generic instant with respect to the maximum planned cell capacity. By this convention, the Cell Load is a parameter independent from the specific RAT, so it can be used in a multi-vendor and/or multi-RAT environment (in the latter case, the proper equivalencies between the different RATs shall be respected, taking account of the proportions in terms of available radio resources and capacity of the different radio access networks).

p-0132In particular, the value for the RT Load can range from 0 to 100, defined as the percentage of the load generated by the traffic associated with real-time services with respect to the maximum planned cell capacity; the NRT Load indicates instead the cell load generated by the traffic associated with non-real-time services, and can for example take values “low”, “medium”, “high” and “overloaded”.

p-0133The values of the cell load parameters are dynamic, thus, for a proper working of the CRRM algorithms, the measurements necessary for calculating them are repeated with a proper periodicity.

p-0134In other words, the state of the network is usually not known in a transparent way to all the network equipment; for example, an RNC has only a partial knowledge of the load status of cells not directly controlled by it: a BSC/RNC has a full knowledge of the load status of the cells it controls, but as far as the cells controlled by other BSCs/RNCs, its knowledge may be limited to the Cell Load.

p-0135According to an embodiment of the present invention, the state of the network is expressed by a set of state variables, as specified in the table below:

p-0136<tables id="TABLE-US-00015" num="00015"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="56pt" align="left" /><colspec colname="2" colwidth="42pt" align="left" /><colspec colname="3" colwidth="189pt" align="left" /><thead><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry>Variable</entry><entry>Values</entry><entry>Description</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>RTLU[<cell>]</entry><entry>Int 0 . . . 100</entry><entry>Cell Load in uplink for real-time services in the cell <cell></entry></row><row><entry>RTLD[<cell>]</entry><entry>Int 0 . . . 100</entry><entry>Cell Load in downlink for real-time services in the cell <cell></entry></row><row><entry>N[<cell>,ID_s]</entry><entry>Int</entry><entry>Number of ongoing connections for the service with identifier</entry></row><row><entry /><entry /><entry>ID_sin the cell <cell></entry></row><row><entry>RTLU[pool=ID_p]</entry><entry>Int 0 . . . 100</entry><entry>Cell Load in uplink for real-time services in a cell of the pool of</entry></row><row><entry /><entry /><entry>resources with identifier ID_p</entry></row><row><entry>RTLD[pool=ID_p]</entry><entry>Int 0 . . . 100</entry><entry>Cell Load in downlink for real-time services in a cell of the pool</entry></row><row><entry /><entry /><entry>of resources with identifier ID_p</entry></row><row><entry>N[pool=ID_p,ID_s]</entry><entry>Int</entry><entry>Number of ongoing connections for the service with identifier</entry></row><row><entry /><entry /><entry>ID_sin a cell of the pool of resources with identifier ID_p</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

p-0137It has to be noted that the variables associated with a pool of resources (last three rows in the previous table, i.e. RTLU[pool=ID_p], RTLD[pool=ID_p] and N[pool=ID_p,ID_s]) have to be interpreted as a compact notation to represent single instances of the state variables, one for each cell belonging to the resource pool; they are not global variables associated to all the cells of the resource pool, as will be described in greater detail later.

p-0138Since, as mentioned, a BSC/RNC may not have full visibility of the state of cells controlled by different BSCs/RNCs, considered the generic BSC/RNC, not all the state variables defined above will in general have a value attributed thereto; the situation that is in general encountered in the generic BSC/RNC X is given in the table below:

p-0139<tables id="TABLE-US-00016" num="00016"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="4"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="56pt" align="left" /><colspec colname="2" colwidth="91pt" align="left" /><colspec colname="3" colwidth="56pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="3" align="center" rowsep="1" /></row><row><entry /><entry>Variable</entry><entry>Value</entry><entry>Condition</entry></row><row><entry /><entry namest="offset" nameend="3" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>RTLU[c]</entry><entry>Assigned</entry><entry>c ε X</entry></row><row><entry /><entry>RTLU[c]</entry><entry>Assigned</entry><entry>c ∉ X</entry></row><row><entry /><entry>RTLD[c]</entry><entry>Assigned</entry><entry>c ε X</entry></row><row><entry /><entry>RTLD[c]</entry><entry>Assigned</entry><entry>c ∉ X</entry></row><row><entry /><entry>N[c,ID_s]</entry><entry>Assigned</entry><entry>c ε X</entry></row><row><entry /><entry>N[c,ID_s]</entry><entry>Not Assigned (N.A.)</entry><entry>c ∉ X</entry></row><row><entry /><entry namest="offset" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables><br /> where c∈X stands for a cell c that is controlled by the BSC/RNC X, whereas c∉X stands for a cell that is not controlled by the BSC/RNC X, and ID_sis the identifier of the generic service.

p-0140According to an embodiment of the present invention, the decision logic of the CRRM algorithm to be implemented is expressed in the form of a set of tables <b>465</b>, wherein each table entry corresponds to a decision rule, which in turn corresponds to a certain CRRM action to be taken when a respective combination of event, counter values, network state applies.

p-0141Each table in the set of tables is identified through a respective table identifier ID_t, where 1≦ID_t≦N_t, being N_tthe number of the tables.

p-0142In particular, according to an embodiment of the present invention, the set of tables expressing the CRRM algorithm decision logic includes two different kinds of tables: a first kind of tables is referred to as “table for cells”, and a second type of tables is referred to as “table for pools”. A “table for cells” is used to specify CRRM rules at the level of the individual cells, whereas a “table for pools” is used to specify more general CRRM rules for which it is sufficient to consider pools of resources, being not necessary to consider the individual cells. For example, in order to implement a CRRM rule of the type “all the voice calls originated by the UMTS have to be diverted to the GSM”, it is not necessary to consider the individual cells, being sufficient to consider GSM pools of resources and UMTS pools of resources (each network equipment that has to implement the CRRM algorithm, like the BSCs and the RNCs, will translate and apply the general rule expressed in terms of pool of resources to the specific cells involved). Using this two types of tables may simplify the definition of CRRM rules (otherwise, several tables of the first type would be necessary to specify a general CRRM rule); however, the adoption of this table structure is not per se limitative, and alternative structures are possible.

p-0143An illustrative “table for cells” is structured as depicted in <figref idrefs="DRAWINGS">FIG. 5</figref>, whereas <figref idrefs="DRAWINGS">FIG. 6</figref> depicts the structure of an illustrative “table for pool”.

p-0144With reference to <figref idrefs="DRAWINGS">FIG. 5</figref>, a “table for cells” <b>465</b>-<i>c </i>includes table identifier ID_t<b>501</b> and a list <b>502</b> of a number L≧1 of cells considered in that table (i.e., the cells to which the CRRM rules specified in the table pertain); in the example at issue, it is assumed that the table ID_t=6 relates to the cell GSMTO<b>1</b> of the GSM network and the cell UMTSTO<b>3</b> of the UMTS network.

p-0145The table includes a number n of table rows RW<b>1</b>, RW<b>2</b>, RW<b>3</b>, . . . , RWn, and a number of table columns/groups of columns <b>505</b>, <b>510</b>, <b>520</b>, and <b>590</b>. In particular, the group of columns <b>520</b> includes a respective columns sub-group for each cell in the list <b>502</b>, like the columns sub-groups <b>520</b><i>a </i>and <b>520</b><i>b </i>for the cell GSMTO<b>1</b> and UMTSTO<b>3</b>, respectively (other sub-groups similar to the sub-groups <b>520</b><i>a </i>and <b>520</b><i>b </i>can be present if the list <b>502</b> contains other elements; <figref idrefs="DRAWINGS">FIG. 5</figref> describes for simplicity the case of two elements only).

p-0146Considering the generic table row, which corresponds to a decision rule of the CRRM decision logic, the table element in the column <b>505</b> may contain an expression, with the semantic described below; the table elements in the group of columns <b>510</b> are adapted to contain an event description, i.e. a description of a service request to which the decision rule is intended to apply, according to the event definition provided above, i.e. the table elements in the group of columns <b>510</b> are adapted to contain values for the parameters s, type, origin, dest(<b>1</b>), . . . , dest(N_p) which characterize the events.

p-0147The group of columns <b>520</b> contain a description of the network state. The generic sub-group of columns <b>520</b><i>a</i>, <b>520</b><i>b</i>, related to a respective cell of the list <b>502</b>, comprises a group of columns <b>521</b> and a group of columns <b>522</b>.

p-0148The table elements in the group of columns <b>521</b> related to a certain cell in the list <b>502</b>, all of integer type, are adapted to contain a description of the state of the corresponding cell, i.e. they are adapted to contain values for the above-defined state variables RTLU[<cell>], RTLD[<cell>] and N[<cell>,ID_s]. The table elements in the group of columns <b>522</b> related to a certain cell in the list <b>502</b>, of integer or real type, are adapted to contain values of the counters defined, during the set-up phase, for the corresponding cell.

p-0149The table element in the column <b>590</b> is adapted to contain an identifier of a CRRM action to be undertaken; in particular, the CRRM action identifier may be an identifier “Rej”, indicating that the service request has to be rejected, or it may be a label of a cell.

p-0150With reference to <figref idrefs="DRAWINGS">FIG. 6</figref>, a “table for pools” <b>465</b>-<i>p </i>includes a table identifier ID_t<b>601</b>.

p-0151The table for pools has a number m of table rows RWP<b>1</b>, RWP<b>2</b>, RWP<b>3</b>, . . . , RWPm, each one corresponding to a decision rule, and a number of table columns/groups of columns <b>605</b>, <b>610</b>, <b>621</b>, <b>622</b>, <b>640</b>, <b>651</b>, <b>652</b>, and <b>690</b>.

p-0152Considering the generic table row, similarly to the above-described “table for cells”, the table element in the column <b>605</b> may contain an expression, with the semantic described below; the table elements in the group of columns <b>610</b> are adapted to contain an event description.

p-0153The table elements in the group of columns <b>621</b>, all of integer type, are suitable to contain a description of the state of the origin cell where the service request was originated, i.e. they are suitable to contain values for the above-defined state variables RTLU[<cell>], RTLD[<cell>] and N[<cell>,ID_s] for the cell where the service request was originated.

p-0154The table elements in the group of columns <b>622</b>, of integer or real type, are suitable to contain values of the counters defined, during the set-up phase, in respect of the origin cell where the service request was originated.

p-0155The table element in the column <b>640</b> is suitable to contain an identifier of a pool of resources.

p-0156The table elements in the group of columns <b>651</b>, all of integer type, are suitable to contain a description of the state of a generic cell belonging to the pool specified in column <b>640</b>, i.e. suitable to contain values for the state variables RTLU[<cell>], RTLD[<cell>] and N[<cell>,ID_s] for a generic cell of the pool specified in column <b>640</b>.

p-0157The table elements in the group of columns <b>652</b>, of integer or real type, are suitable to contain predetermined values of event counters defined during the set-up phase, which in operation have to match with the values of the event counters defined for the generic cell of the pool specified in column <b>640</b>.

p-0158The table element in the column <b>690</b> is suitable to contain an identifier of a CRRM action to be undertaken; in particular, the CRRM action identifier can be either “Rej” (indicating that the service request has to be rejected), or an integer value being the identifier of a pool of resources.

p-0159In particular, in both the tables the table elements of integer type (int) or of real type (real), in addition to taking specific values, may also take the following values:

p-0160* indicates any value <br /> <n indicates any value lower than a number n <br /> ≦n indicates any value lower or equal to a number n <br /> >n indicates any value greater than a number n <br /> ]m,n[ indicates any value comprised between the numbers m and n (extremes excluded) <br /> [m,n] indicates any value comprised between the numbers m and n (extremes included) <br /> [m,n[ indicates any value comprised between the numbers m and n (excluded the extreme n) <br /> ]m,n] indicates any value comprised between the numbers m and n (excluded the extreme m)

p-0161The values of the table elements of Boolean type (type bool) may take, in addition to specific values (True, False), also the value “*”, to indicate any value.

p-0162The table elements in the column <b>505</b> of the generic “table for cells” or in the column <b>605</b> of the generic “table for pools” are as mentioned adapted to contain an expression (type expr), that may be defined in the way below:

p-0163expr

p-0164operand

p-0165expr operator expr

p-0166lookup[expr,exp]

p-0167!expr

p-0168(expr)

p-0169where: <br /> !expr denotes the logic negation; <br /> (expr) means that the syntax of an expression may include an expression in parenthesis; <br /> operator denotes:

p-0170+ (sum or logic OR)

p-0171* (multiplication or logic AND)

p-0172−

p-0173/ (division of real numbers)

p-0174>

p-0175>=

p-0176&lt;

p-0177&lt;=

p-0178=

p-0179< >(meaning “different”)

p-0180operand may be:

p-0181real_number

p-0182integer_number

p-0183variable

p-0184T (Boolean value True, treated as 1 in evaluation of expressions)

p-0185F (Boolean value False, treated as 0 in evaluation of expressions)

p-0186variable may be:

p-0187s

p-0188type

p-0189origin

p-0190dest

p-0191cont

p-0192state

p-0193where s denotes a service identifier, type denotes the type of service request (0 for new call or 1 for handover), origin denotes the pool of the cell where the service request was originated. dest may be:

p-0194dest(<b>1</b>)

p-0195. . .

p-0196dest(N_p)

p-0197cont may be:

p-0198c₁[<cell>]

p-0199. . .

p-0200c_Nc[<cell>]

p-0201c₁[origin]

p-0202. . .

p-0203c_Nc[origin]

p-0204c₁[pool]

p-0205. . .

p-0206c_Nc[pool]

p-0207where c_i[origin] denotes the counter with identifier ID_c=i of the cell where the service request was originated and c_i[pool] denotes the counter with identifier ID_c=i of a cell of the pool specified in column <b>640</b>. <br /> state may be:

p-0208RTLU[<cell>]

p-0209RTLD[<cell>]

p-0210N[<cell>, integer_number]

p-0211RTLU[origin]

p-0212RTLD[origin]

p-0213N[origin, integer_number]

p-0214RTLU[pool]

p-0215RTLD[pool]

p-0216N[pool, integer_number]

p-0217where RTLU[origin], RTLD[origin] and N[origin, integer_number] all refer to the cell where the service request was originated and RTLU [pool], RTLD[pool] and N[pool,integer_number] all refer to a cell of the pool specified in column <b>640</b>.

p-0218According to an embodiment of the present invention, the result of a generic expression is a Boolean value.

p-0219An illustrative expression is:

p-0220<br />(<i>c</i>₅[GSMTO1]<7.4)*(lookup[4,RTLU[UMTSTO3]]>=lookup[5<i>,N</i>[GSMTO1,2]])

p-0221which has to be construed as a logic AND between the following two conditions: <ul><li id="ul0017-0001" num="0000"><ul><li id="ul0018-0001" num="0217">the value of the event counter with ID_c=5 in cell GSMTO<b>1</b> has to be lower than 7.4; <br /> and </li><li id="ul0018-0002" num="0218">the value assumed by the look-up table with ID_t=4, of the table element specified by the uplink cell load for cell UMTSTO<b>3</b> has to be equal to or greater than the value assumed by the look-up table with ID_t=5, of the table element specified by the number of ongoing connections in the cell GSMTO<b>1</b> in respect of the service with ID_s=2.</li></ul></li></ul>

p-0222Another illustrative expression is:

p-0223<br />(<i>c</i>₅[GSMTO1]<7.4)*(lookup[4,RTLU[pool]]>=lookup[5<i>,N</i>[origin,2]])

p-0224which has to be construed as a logic AND between the following two conditions: <ul><li id="ul0019-0001" num="0000"><ul><li id="ul0020-0001" num="0220">the value of the event counter with ID_c=5 in cell GSMTO<b>1</b> has to be lower than 7.4;</li></ul></li></ul>

p-0225and <ul><li id="ul0021-0001" num="0000"><ul><li id="ul0022-0001" num="0222">the value, in the look-up table with ID_t=4, of the table element specified by the cell load for a cell of the pool specified in column <b>640</b> has to be equal to or greater than the value, in the look-up with ID_t=5, of the table element specified by the number of ongoing connections in the cell where the service request was originated in respect of the service with ID_s=2.</li></ul></li></ul>

p-0226Exploiting the set of tables <b>465</b> expressing the CRRM algorithm decision logic, in the way described in the following, the network entities (or, alternatively, the network entity) that implement the CRRM algorithm, e.g. the BSCs <b>325</b>, the RNCs <b>335</b> and the APCs <b>345</b> (or, alternatively, the CRRM server <b>360</b>), can take the appropriate decisions as to the way a generic service request has to be managed. In the shown example, an action value “Rej” means that the service request has to be blocked.

p-0227With the definition of the CRRM decision logic, the set-up phase ends.

p-0228Once the CRRM algorithm has been fully configured, in the way described above, it is ready to be implemented. The implementation of the CRRM algorithm (by the implementation module <b>410</b>, exploiting the decision logic set of tables <b>465</b>) is described below, making reference to the flowcharts of <figref idrefs="DRAWINGS">FIGS. 7</figref>, <b>8</b>, <b>9</b>A and <b>9</b>B, in an embodiment of the present invention.

p-0229The CRRM algorithm waits (block <b>703</b>) for the occurrence of an event corresponding to a service request in respect of a service which, in the set-up phase (block <b>490</b> in <figref idrefs="DRAWINGS">FIG. 4B</figref>), has been specified to be one of the services managed by the CRRM algorithm. Let it be assumed that a service request is received (event <b>705</b>): the n-uple of parameters that, as described in the foregoing, characterize the occurred event is created, assigning proper values to each parameter (identifier s of the requested service, request type type, service request origin origin, etc.) (block <b>707</b>). If, in the set-up phase (block <b>495</b>), one or more counters have been defined whose value is affected by the occurrence of the event considered, the counters are updated (block <b>709</b>).

p-0230Then, the tables scanner module <b>470</b> scans the set of CRRM decision logic tables <b>465</b> (in particular, as will be explained below, either a “table for cells” <b>465</b>-<i>c </i>or a “table for pools” <b>465</b>-<i>p </i>is scanned), until the first table and row (i.e., the first decision rule) is found that is compatible with the occurred event, as will be detailed in the following. The scanner module <b>470</b> selects the first one of the N_tCRRM decision logic tables (block <b>710</b>); the way the selected table is scanned depends on whether it is a “table for cells” (block <b>715</b>) or a “table for pools” (<b>717</b>). If no compatible row is found in the selected table (the way compatibility of a row is assessed is described afterwards, in connection with <figref idrefs="DRAWINGS">FIGS. 8 and 9A</figref>, <b>9</b>B), the next table is selected (block <b>719</b>, and loop back to point <b>711</b>), and the check is repeated; when there are no more tables (block <b>712</b>), no CRRM policy can be applied to the request, and the algorithm goes back to block <b>703</b>, waiting for the next occurrence of a service request; if instead a table is found wherein a compatible table row is found, the operations schematized by blocks <b>715</b> or <b>717</b> also include calculating the candidate cell C_t;

p-0231if the CRRM action resulting from the operations schematized by block <b>715</b> or block <b>717</b> is “Rej”, then the service request has to be rejected (<b>723</b>) and the algorithm goes back to block <b>703</b>, waiting for the next occurrence of a service request; otherwise the requested service is accepted, and an attempt is made to allocate it on the determined cell C_t(block <b>727</b>).

p-0232The operation flow jumps back to the wait-for-service request state (block <b>703</b>).

p-0233A method by which the tables scanner module <b>470</b> scans the “table for cells” <b>465</b>-<i>c </i>of the CRRM decision logic set of tables <b>465</b> will be now described, making reference to the schematic flowchart of <figref idrefs="DRAWINGS">FIG. 8</figref>.

p-0234Firstly, the involved cells list <b>502</b> specifying the cells involved in the “table for cells” being scanned is read (block <b>801</b>); let Cl₁, . . . , Cl_Lbe the L cells of the list <b>502</b> (in the example of <figref idrefs="DRAWINGS">FIG. 5</figref>, Cl₁=GSMTO<b>1</b> and Cl₂=UMTSTO<b>3</b>).

p-0235A vector variable S is calculated (block <b>802</b>) based on the event characterization (the n-uple of parameters s, type, origin, etc.), the counters and the state of all the cells Cl₁, . . . , Cl_Lin the list <b>502</b>:

p-0236<br /><i>S={s</i>,type,origin,dest(1), . . . , dest(<i>N</i>_p),counters and state of cells <i>Cl</i>₁<i>, . . . , Cl</i>_L}.

p-0237Thus, the vector variable S contains the description of the occurred event, the values of the counters and the state of the cells at the time the event occurred.

p-0238The “table for cells” <b>465</b>-<i>c </i>is scanned row by row, starting from the first row; a row counter i may be used to track the scanning of the table rows; the row counter is initially set to, e.g., 1 (block <b>803</b>), and it is increased, e.g. by 1, each time the scanning passes to the next row (block <b>805</b>), until the last table row is scanned (decision block <b>807</b>, exit branch Yes): in the latter case, no compatible table row is found (block <b>809</b>).

p-0239For the generic table row being scanned, i.e. for the generic decision rule under evaluation, the tables scanner module <b>470</b> reads the values of the elements stored in the table at the selected row; the expression in the element in column <b>505</b> is put into a variable Expr_i, the action in the element in column <b>590</b> is assigned to a variable Action_i, and the values of the other elements are assigned to a vector variable D_i(block <b>811</b>):

p-0240<br /><i>D</i>_i<i>={s</i>_i,types,origin_i,dest(1)_i, . . . , dest(<i>N</i>_p)_i,(Counters of cells 1, . . . , <i>L</i>)_i,(State of cells 1, . . . , <i>L</i>)_i}.

p-0241It is then checked if the mode of determination of the alternative pools of resources set in the set-up phase (block <b>494</b> in <figref idrefs="DRAWINGS">FIG. 4</figref>) for the origin cell origin_iis “measure based” or “blind” (block <b>813</b>); in case the mode is “blind”, the process continues by checking whether the vector variables S and D_icoincide (block <b>816</b>); if instead the mode is “measure based”, then it is also checked (block <b>815</b>) if the cell whose identifier is specified by the value of the variable Action_iis suitable, from a radio coverage point of view; if not, then the next row is considered (block <b>805</b>).

p-0242If, as mentioned, the “blind” mode has been set, or, in case of “measure based” mode, the cell specified by the value of the variable Action_iis suitable from the radio coverage viewpoint, it is checked if the two vector variables S and D_iare equal. if not, then the next row is considered (block <b>805</b>), otherwise the method continues by checking whether the element in column <b>505</b> of the selected table row contains an expression: in the affirmative case, the tables scanner module <b>470</b> computes the expression value (possibly, to do this the tables scanner module may access one or more of the look-up tables <b>460</b> that have been defined in the set-up phase).

p-0243The result of the calculated expression is then evaluated (block <b>817</b>). If the result of the calculation of the expression contained in the element in column <b>505</b> is “False”, the scanning proceeds with the next table row, otherwise (i.e., if the expression result is “True”) a compatible row has been found and the content of the variable Action_iis taken as the CRRM action to be undertaken (the value is assigned to a variable C_tthat is used to specify the action (block <b>819</b>).

p-0244If, in the computation of the expression value, an exception or error is encountered, the scanning proceeds with the next table row (if any). Examples of exceptions that may be encountered are a division by zero, the reference, in the expression, to a non-existing cell, the reference to a network state variable to which a value has not been assigned; a condition different from “*” in the table element that corresponds to a network state variable to which a value has not been assigned. Preferably, all the encountered exceptions/errors are stored in a log file, so to allow the network operator to easily identifying and correcting possible errors in, e.g., the CRRM decision logic.

p-0245A method by which the tables scanner module <b>470</b> scans the generic “table for pool” <b>465</b>-<i>p </i>of the CRRM decision logic set of tables <b>465</b> will be now described, making reference to the schematic flowchart of <figref idrefs="DRAWINGS">FIGS. 9A and 9B</figref>.

p-0246A variable C is used, and the variable C is assigned the value of the identifier of the origin cell where the service request was originated (block <b>901</b>).

p-0247The “table for pools” is scanned row by row, starting for example from the first row, i.e. from the first decision rule of the table; a row counter i may be used to track the scanning of the table rows; the row counter is initially set to, e.g., 1 (block <b>903</b>), and it is increased, e.g. by 1, each time the scanning passes to the next row (block <b>905</b>), until the last table row is scanned (decision block <b>907</b>, exit branch Yes): in the latter case, no compatible table row is found (block <b>909</b>).

p-0248For the generic table row being scanned, the tables scanner module <b>470</b> reads the values of the elements stored in the table at the selected row and assigns them (block <b>911</b>) to a variable Expr_i(taking the content read from the element in column <b>605</b>), to a variable P_i(taking the content read from the element in column <b>640</b>), to a variable Action_i(taking the content read from the element in column <b>690</b>); the content of the remaining elements of the row is assigned to a vector variable D_i:

p-0249<br /><i>D</i>_i<i>={s</i>_i,type,origin_i,dest(1), . . . , dest(<i>N</i>_p)_i,(State of the origin cell)_i,(Counters of the origin cell)_i,(State of pool's cell)_i,(Counters of pool's cell)_i}.

p-0250In case the value P_i=“*” (block <b>913</b>) the algorithm jumps (jumper J<b>1</b>) to a routine that will be described later on in connection with <figref idrefs="DRAWINGS">FIG. 9B</figref>, otherwise the Q cells belonging to the pool P_ispecified in the element in column <b>640</b> are then either reordered by descending radio signal level quality (in the case the “measure based” mode was set for the origin cell in the set-up phase) or they are kept in the same order as they are indicated in the definition of pool of resources (in the case the “blind” mode was selected for the origin cell). The names of the cells ordered as described are assigned to variables CP₁, . . . , CP_Q(block <b>915</b>).

p-0251The cells specified by the names assigned to the variables CP₁, . . . , CP_Qare scanned one by one, starting from the cell CP₁; a row counter j may be used to track the scanning of the cells; the row counter is initially set to, e.g., 1 (block <b>920</b>), and it is increased, e.g. by 1, each time the scanning passes to the next cell (block <b>930</b>), until the last cell is scanned (decision block <b>925</b>, exit branch Yes): in the latter case, a new table row has to be considered (block <b>905</b>).

p-0252For the generic cell CP_jbeing scanned, the tables scanner module <b>470</b> calculates a vector variable S (block <b>935</b>) based on the occurred event characterization, excluding the origin field (i.e., the parameters considered are s, type, dest(<b>1</b>), . . . , dest(N_p)), on the current values of the counters and the states of the cells C (i.e. the origin cell) and CP_j

p-0253<br /><i>S={s</i>,type,<i>C</i>,dest(1), . . . , dest(<i>N</i>_pmax),(State of cell <i>C</i>),(Counters of cell <i>C</i>),(State of cell <i>CP</i>_j),(Counters of cell <i>CP</i>_j)}.

p-0254A value VExpr is also calculated, applying to the expression contained in the element in column <b>605</b>) the following substitutions (block <b>940</b>):

p-0255<tables id="TABLE-US-00017" num="00017"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="6"><colspec colname="1" colwidth="49pt" align="left" /><colspec colname="2" colwidth="21pt" align="left" /><colspec colname="3" colwidth="42pt" align="left" /><colspec colname="4" colwidth="42pt" align="left" /><colspec colname="5" colwidth="21pt" align="left" /><colspec colname="6" colwidth="42pt" align="left" /><thead><row><entry namest="1" nameend="6" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>c₁[origin]</entry><entry>→</entry><entry>c₁[C]</entry><entry>c₁[pool]</entry><entry>→</entry><entry>c₁[CP_j]</entry></row><row><entry>. . .</entry><entry /><entry /><entry>. . .</entry></row><row><entry>c_Nc[origin]</entry><entry>→</entry><entry>c_Nc[C]</entry><entry>c_Nc[pool]</entry><entry>→</entry><entry>c_Nc[CP_j]</entry></row><row><entry>RTLU[origin]</entry><entry>→</entry><entry>RTLU[C]</entry><entry>RTLU[pool]</entry><entry>→</entry><entry>RTLU[CP_j]</entry></row><row><entry>RTLD[origin]</entry><entry>→</entry><entry>RTLD[C]</entry><entry>RTLD[pool]</entry><entry>→</entry><entry>RTLD[CP_j]</entry></row><row><entry>N[origin,*]</entry><entry>→</entry><entry>N[C,*]</entry><entry>N[pool,*]</entry><entry>→</entry><entry>N[CP_j,*].</entry></row><row><entry namest="1" nameend="6" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

p-0256In other words, the expression is calculated in respect of the origin cell C and of the considered cell of the pool specified for the table row being scanned.

p-0257It is then checked if both S=D_iand the value VExpr is True; if not (decision block <b>945</b>, exit branch No), then next cell CP_jis considered (back to block <b>930</b>).

p-0258It is then checked if Action_i=origin_i; in the affirmative case (decision block <b>950</b>, exit branch Yes), the variable C_ttakes the value of C (block <b>955</b>) and the process ends with a compatible row found (block <b>970</b>).

p-0259Otherwise, it is checked if Action_i=P_i; in the affirmative case (decision block <b>960</b>, exit branch Yes), C_ttakes the value of CP_j(block <b>965</b>) and the process ends with a compatible row found (<b>970</b>).

p-0260If none of the two previous checks succeeds, there are two possibilities (block <b>975</b>), depending on whether for the origin cell C the “blind” mode or the “measure based” mode were specified in the set-up phase; in the first case (block <b>980</b>), C_ttakes the value of the first cell in the list of cells belonging to the pool indicated by Action_i; in the second case (block <b>985</b>) C_ttakes the value of the first cell in the list of cells belonging to the pool indicated by Action_ireordered by decreasing radio signal quality.

p-0261The process ends with a compatible row found (<b>990</b>).

p-0262The case of the element in the column <b>640</b> takes the value “*” (in block <b>913</b>), i.e. of a row of the “table for pools” that specifies no particular pool of resources, is described in <figref idrefs="DRAWINGS">FIG. 9B</figref>:

p-0263Some elements of row i-th are used to calculate a vector variable DD_i(block <b>991</b>):

p-0264<br /><i>DD</i>_i<i>={s</i>_i,type_i,origin_i,dest(1)_i, . . . , dest(<i>N</i>_p)_i,(State of the origin cell)_i,(Counters of the origin cell)_i}.

p-0265It can be seen that the vector variable DD_iis the same as the vector variable D_iof block <b>911</b>, but it does not contain elements depending on (cells of) the pool P_i.

p-0266A vector variable SS is then calculated (block <b>992</b>) in the following way:

p-0267<br /><i>SS={s</i>,type,<i>C</i>,dest(1), . . . , dest(<i>N</i>_p),(State of cell <i>C</i>),(Counters of cell <i>C</i>)}.

p-0268It can be seen that the vector variable S is calculated in the same way as the vector variable S in block <b>935</b>, but it does not contain elements depending on the pool P_i.

p-0269A value VVExpr is then evaluated (block <b>993</b>), as follows: <ul><li id="ul0023-0001" num="0000"><ul><li id="ul0024-0001" num="0260">VVExpr=Expr_icontained in the element in column <b>605</b> evaluated applying the following substitutions:</li></ul></li></ul>

p-0270<tables id="TABLE-US-00018" num="00018"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="4"><colspec colname="offset" colwidth="28pt" align="left" /><colspec colname="1" colwidth="84pt" align="left" /><colspec colname="2" colwidth="42pt" align="left" /><colspec colname="3" colwidth="63pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="3" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>c₁[origin]</entry><entry>→</entry><entry>c₁[C]</entry></row><row><entry /><entry>. . .</entry></row><row><entry /><entry>c_Nc[origin]</entry><entry>→</entry><entry>c_Nc[C]</entry></row><row><entry /><entry>RTLU[origin]</entry><entry>→</entry><entry>RTLU[C]</entry></row><row><entry /><entry>RTLD[origin]</entry><entry>→</entry><entry>RTLD[C]</entry></row><row><entry /><entry>N[origin,*]</entry><entry>→</entry><entry>N[C,*]</entry></row><row><entry /><entry namest="offset" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

p-0271Thus, the value VVExpr is calculated in the same way as VExpr in block <b>940</b>, but it does not contain references to the state of a cell of the pool, otherwise an exception is raised.

p-0272It is then checked if both SS=DD_iand VVExpr is True (block <b>994</b>); if not (decision block <b>994</b>, exit branch No), then next mw is considered (back to block <b>905</b> through jumper J<b>3</b>); otherwise the process continues (through jumper J<b>2</b>) with the check of block <b>950</b>.

p-0273Hereinafter, an example of application of the method and system described above will be presented.

p-0274The scenario considered in the example to be presented is that of a mobile radio communications network capable of providing voice and data exchange services, wherein: <ul><li id="ul0025-0001" num="0000"><ul><li id="ul0026-0001" num="0265">the voice service is offered by both a GSM network and a UMTS network;</li><li id="ul0026-0002" num="0266">the data exchange service is offered by the UMTS network;</li><li id="ul0026-0003" num="0267">the GSM network includes two cells GSM<b>1</b> and GSM<b>2</b>, and the UMTS network includes two cells UMTS<b>1</b> and UMTS<b>2</b>, with respective coverage as depicted in <figref idrefs="DRAWINGS">FIG. 10</figref>;</li><li id="ul0026-0004" num="0268">the cells GSM<b>1</b> and GSM<b>2</b> are controlled by a same BSC;</li><li id="ul0026-0005" num="0269">the cells UMTS<b>1</b> and UMTS<b>2</b> are controlled by a same RNC.</li></ul></li></ul>

p-0275It is assumed that the mapping of the UMTS capacity on the cell load variable defined in the foregoing is known: for example, the table below provides the cell load values in downlink versus the number of active voice and data users:

p-0276<tables id="TABLE-US-00019" num="00019"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="42pt" align="left" /><colspec colname="1" colwidth="217pt" align="center" /><tbody valign="top"><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row><row><entry /><entry>Data</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="11"><colspec colname="offset" colwidth="42pt" align="left" /><colspec colname="1" colwidth="21pt" align="center" /><colspec colname="2" colwidth="21pt" align="center" /><colspec colname="3" colwidth="21pt" align="center" /><colspec colname="4" colwidth="21pt" align="center" /><colspec colname="5" colwidth="21pt" align="center" /><colspec colname="6" colwidth="21pt" align="center" /><colspec colname="7" colwidth="21pt" align="center" /><colspec colname="8" colwidth="21pt" align="center" /><colspec colname="9" colwidth="21pt" align="center" /><colspec colname="10" colwidth="28pt" align="center" /><tbody valign="top"><row><entry /><entry>0</entry><entry>1</entry><entry>2</entry><entry>3</entry><entry>4</entry><entry>5</entry><entry>6</entry><entry>7</entry><entry>8</entry><entry>9</entry></row><row><entry /><entry namest="offset" nameend="10" align="center" rowsep="1" /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="12"><colspec colname="1" colwidth="21pt" align="left" /><colspec colname="2" colwidth="21pt" align="char" char="." /><colspec colname="3" colwidth="21pt" align="char" char="." /><colspec colname="4" colwidth="21pt" align="char" char="." /><colspec colname="5" colwidth="21pt" align="char" char="." /><colspec colname="6" colwidth="21pt" align="char" char="." /><colspec colname="7" colwidth="21pt" align="char" char="." /><colspec colname="8" colwidth="21pt" align="char" char="." /><colspec colname="9" colwidth="21pt" align="char" char="." /><colspec colname="10" colwidth="21pt" align="char" char="." /><colspec colname="11" colwidth="21pt" align="char" char="." /><colspec colname="12" colwidth="28pt" align="center" /><tbody valign="top"><row><entry>Voice</entry><entry>0</entry><entry>0</entry><entry>11</entry><entry>23</entry><entry>34</entry><entry>46</entry><entry>57</entry><entry>69</entry><entry>80</entry><entry>92</entry><entry>100</entry></row><row><entry /><entry>1</entry><entry>7</entry><entry>17</entry><entry>29</entry><entry>40</entry><entry>51</entry><entry>61</entry><entry>74</entry><entry>85</entry><entry>100</entry></row><row><entry /><entry>2</entry><entry>14</entry><entry>24</entry><entry>35</entry><entry>46</entry><entry>56</entry><entry>66</entry><entry>79</entry><entry>90</entry></row><row><entry /><entry>3</entry><entry>21</entry><entry>31</entry><entry>42</entry><entry>52</entry><entry>62</entry><entry>71</entry><entry>84</entry><entry>95</entry></row><row><entry /><entry>4</entry><entry>28</entry><entry>38</entry><entry>48</entry><entry>58</entry><entry>67</entry><entry>76</entry><entry>89</entry><entry>100</entry></row><row><entry /><entry>5</entry><entry>35</entry><entry>45</entry><entry>55</entry><entry>64</entry><entry>73</entry><entry>80</entry><entry>94</entry></row><row><entry /><entry>6</entry><entry>42</entry><entry>52</entry><entry>61</entry><entry>70</entry><entry>78</entry><entry>85</entry><entry>100</entry></row><row><entry /><entry>7</entry><entry>50</entry><entry>58</entry><entry>67</entry><entry>76</entry><entry>83</entry><entry>90</entry></row><row><entry /><entry>8</entry><entry>57</entry><entry>65</entry><entry>74</entry><entry>82</entry><entry>89</entry><entry>95</entry></row><row><entry /><entry>9</entry><entry>64</entry><entry>72</entry><entry>80</entry><entry>88</entry><entry>94</entry><entry>100</entry></row><row><entry /><entry>10</entry><entry>71</entry><entry>79</entry><entry>87</entry><entry>94</entry><entry>100</entry></row><row><entry /><entry>11</entry><entry>78</entry><entry>86</entry><entry>93</entry><entry>100</entry></row><row><entry /><entry>12</entry><entry>85</entry><entry>93</entry><entry>100</entry></row><row><entry /><entry>13</entry><entry>92</entry><entry>100</entry></row><row><entry /><entry>14</entry><entry>100</entry></row><row><entry namest="1" nameend="12" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

p-0277The capacity of the GSM network is assumed to be 10 voice channels; the table below exemplifies the cell load values in downlink versus the number of active voice users:

p-0278<tables id="TABLE-US-00020" num="00020"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="offset" colwidth="42pt" align="left" /><colspec colname="1" colwidth="49pt" align="center" /><colspec colname="2" colwidth="126pt" align="center" /><thead><row><entry /><entry namest="offset" nameend="2" align="center" rowsep="1" /></row><row><entry /><entry>Voice users</entry><entry>Cell load</entry></row><row><entry /><entry namest="offset" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="offset" colwidth="42pt" align="left" /><colspec colname="1" colwidth="49pt" align="char" char="." /><colspec colname="2" colwidth="126pt" align="char" char="." /><tbody valign="top"><row><entry /><entry>0</entry><entry>0</entry></row><row><entry /><entry>1</entry><entry>10</entry></row><row><entry /><entry>2</entry><entry>20</entry></row><row><entry /><entry>3</entry><entry>30</entry></row><row><entry /><entry>4</entry><entry>40</entry></row><row><entry /><entry>5</entry><entry>50</entry></row><row><entry /><entry>6</entry><entry>60</entry></row><row><entry /><entry>7</entry><entry>70</entry></row><row><entry /><entry>8</entry><entry>80</entry></row><row><entry /><entry>9</entry><entry>90</entry></row><row><entry /><entry>10</entry><entry>100</entry></row><row><entry /><entry namest="offset" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

p-0279The two tables above are useful to understand the maximum load allowed in the cells. The first table indicates the cell load given the number of voice and data calls in a UMTS cell. Since the cell load cannot be greater than 100, it is clear for example that if 10 voice calls are running, then no more than 4 data calls can be accepted. The second table refers to GSM where, in this example, only voice calls are possible.

p-0280As described above, in the set-up phase of the CRRM algorithm the network operator defines the network services to be subjected to the CRRM algorithm; in the present example, two real-time services are considered, namely a voice service and a data exchange service, as exemplified in the table below, which are identified as ID_s=1 and ID_s=2, respectively, and are characterized as discussed in the foregoing on the basis of the QoS parameters.

p-0281Also, in the set-up phase the pool of resources are defined; in the example considered, two pools of resources are assumed to have been defined, one grouping the GSM cells and the other grouping the UMTS cells:

p-0282<tables id="TABLE-US-00021" num="00021"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="112pt" align="center" /><colspec colname="2" colwidth="105pt" align="left" /><thead><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row><row><entry>ID_P</entry><entry>Description</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>1</entry><entry>UMTS1, UMTS2</entry></row><row><entry>2</entry><entry>GSM1, GSM2</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

p-0283The step of definition of the cells' overlaps, based on the example of <figref idrefs="DRAWINGS">FIG. 9</figref>, gives:

p-0284<tables id="TABLE-US-00022" num="00022"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="offset" colwidth="42pt" align="left" /><colspec colname="1" colwidth="70pt" align="left" /><colspec colname="2" colwidth="105pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="2" align="center" rowsep="1" /></row><row><entry /><entry /><entry>List of cells of other</entry></row><row><entry /><entry>Cell</entry><entry>pools in overlap</entry></row><row><entry /><entry namest="offset" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>GSM1</entry><entry>UMTS1</entry></row><row><entry /><entry>GSM2</entry><entry>UMTS2</entry></row><row><entry /><entry>UMTS1</entry><entry>GSM1</entry></row><row><entry /><entry>UMTS2</entry><entry>GSM2</entry></row><row><entry /><entry namest="offset" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

p-0285Concerning the definition of the criteria for the radio measurements on the neighbour cells, it is assumed that the network is configured in such a way that dual-mode (i.e. GSM and UMTS) mobile terminals located in a cell perform measures on the overlapped cell belonging to the other system.

p-0286This measurement configuration makes it possible to set the “measure-based” modality in the next step of the set-up phase: in the example considered, it is assumed that in the cells GSM<b>1</b> and UMTS<b>1</b> the “blind” modality is selected, whereas in the cells GSM<b>2</b> and UMTS<b>2</b> the “measure-based” modality is selected.

p-0287In the considered example, the events (service requests) are characterized by 5-uples of the form: <ul><li id="ul0027-0001" num="0000"><ul><li id="ul0028-0001" num="0279">s, type, origin, dest(<b>1</b>), dest(<b>2</b>) <br /> where s=1 identifies voice service requests, s=2 identifies data service requests, type=0 for a new request, type=1 for a request originating from a handover, origin=1 if the mobile terminal is camped on the UMTS network, origin=2 if the mobile terminal is camped on the GSM network, dest(<b>1</b>)=True if it is possible to assign the request to the UMTS network, dest(<b>1</b>)=False otherwise, and dest(<b>2</b>)=True if the service request can be assigned to the GSM, dest(<b>2</b>)=False otherwise. </li></ul></li></ul>

p-0288It is also assumed that an events counter of integer type is defined for counting all the voice calls, and another events counter of integer type is defined for counting the voice calls that can be assigned to both the GSM and the UMTS networks. The two counters are thus defined in the following way:

p-0289<tables id="TABLE-US-00023" num="00023"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="7"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="14pt" align="center" /><colspec colname="2" colwidth="42pt" align="center" /><colspec colname="3" colwidth="21pt" align="center" /><colspec colname="4" colwidth="49pt" align="center" /><colspec colname="5" colwidth="28pt" align="center" /><colspec colname="6" colwidth="49pt" align="center" /><thead><row><entry /><entry namest="offset" nameend="6" align="center" rowsep="1" /></row><row><entry /><entry>ID_c</entry><entry>s</entry><entry>type</entry><entry>origin</entry><entry>dest(1)</entry><entry>dest(2)</entry></row><row><entry /><entry namest="offset" nameend="6" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>1</entry><entry>1</entry><entry>*</entry><entry>*</entry><entry>*</entry><entry>*</entry></row><row><entry /><entry>2</entry><entry>1</entry><entry>*</entry><entry>*</entry><entry>T</entry><entry>T</entry></row><row><entry /><entry namest="offset" nameend="6" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

p-0290Furthermore, a real counter is assumed to have been defined, as a ratio between the two counters above:

p-0291<tables id="TABLE-US-00024" num="00024"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="63pt" align="center" /><colspec colname="2" colwidth="49pt" align="center" /><colspec colname="3" colwidth="105pt" align="center" /><thead><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry>ID_c</entry><entry>ID_cnumerator</entry><entry>ID_cdenominator</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>3</entry><entry>2</entry><entry>1</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

p-0292A look-up table with ID_t=1 is also assumed to be defined in the set-up phase for specifying, in accordance with the illustrative capacity of the UMTS network given above, the maximum number of voice calls that can be accepted by a UMTS cell based on the number of ongoing data connections:

p-0293<tables id="TABLE-US-00025" num="00025"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="offset" colwidth="56pt" align="left" /><colspec colname="1" colwidth="28pt" align="center" /><colspec colname="2" colwidth="133pt" align="center" /><thead><row><entry /><entry namest="offset" nameend="2" align="center" rowsep="1" /></row><row><entry /><entry>Index</entry><entry>Value</entry></row><row><entry /><entry namest="offset" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="offset" colwidth="56pt" align="left" /><colspec colname="1" colwidth="28pt" align="char" char="." /><colspec colname="2" colwidth="133pt" align="char" char="." /><tbody valign="top"><row><entry /><entry>0</entry><entry>14</entry></row><row><entry /><entry>1</entry><entry>13</entry></row><row><entry /><entry>2</entry><entry>12</entry></row><row><entry /><entry>3</entry><entry>11</entry></row><row><entry /><entry>4</entry><entry>10</entry></row><row><entry /><entry>5</entry><entry>9</entry></row><row><entry /><entry>6</entry><entry>6</entry></row><row><entry /><entry>7</entry><entry>4</entry></row><row><entry /><entry>8</entry><entry>1</entry></row><row><entry /><entry>9</entry><entry>0</entry></row><row><entry /><entry>10</entry><entry>0</entry></row><row><entry /><entry>11</entry><entry>0</entry></row><row><entry /><entry>. . .</entry><entry>. . .</entry></row><row><entry /><entry>255</entry><entry>0</entry></row><row><entry /><entry namest="offset" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

p-0294The state of the network is assumed to be described by the state variables listed in the following table, wherein for each variable it is specified whether it is visible to the RNC, to the BSC or to both of them:

p-0295<tables id="TABLE-US-00026" num="00026"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="4"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="63pt" align="left" /><colspec colname="2" colwidth="63pt" align="center" /><colspec colname="3" colwidth="77pt" align="center" /><thead><row><entry /><entry namest="offset" nameend="3" align="center" rowsep="1" /></row><row><entry /><entry>State variable</entry><entry>Visibile to RNC1</entry><entry>Visibile to BSC1</entry></row><row><entry /><entry namest="offset" nameend="3" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>RTLU[UMTS1]</entry><entry>✓</entry><entry>✓</entry></row><row><entry /><entry>RTLD[UMTS1]</entry><entry>✓</entry><entry>✓</entry></row><row><entry /><entry>N[UMTS1,1]</entry><entry>✓</entry></row><row><entry /><entry>N[UMTS1,2]</entry><entry>✓</entry></row><row><entry /><entry>RTLU[UMTS2]</entry><entry>✓</entry><entry>✓</entry></row><row><entry /><entry>RTLD[UMTS2]</entry><entry>✓</entry><entry>✓</entry></row><row><entry /><entry>N[UMTS2,1]</entry><entry>✓</entry></row><row><entry /><entry>N[UMTS2,2]</entry><entry>✓</entry></row><row><entry /><entry>RTLU[GSM1]</entry><entry>✓</entry><entry>✓</entry></row><row><entry /><entry>RTLD[GSM1]</entry><entry>✓</entry><entry>✓</entry></row><row><entry /><entry>N[GSM1,1]</entry><entry /><entry>✓</entry></row><row><entry /><entry>RTLU[GSM2]</entry><entry>✓</entry><entry>✓</entry></row><row><entry /><entry>RTLD[GSM2]</entry><entry>✓</entry><entry>✓</entry></row><row><entry /><entry>N[GSM2,1]</entry><entry /><entry>✓</entry></row><row><entry /><entry>RTLU[pool=1]</entry><entry>✓</entry><entry>✓</entry></row><row><entry /><entry>RTLD[pool=1]</entry><entry>✓</entry><entry>✓</entry></row><row><entry /><entry>N[pool=1,1]</entry><entry>✓</entry></row><row><entry /><entry>N[pool=1,2]</entry><entry>✓</entry></row><row><entry /><entry>RTLU[pool=2]</entry><entry>✓</entry><entry>✓</entry></row><row><entry /><entry>RTLD[pool=2]</entry><entry>✓</entry><entry>✓</entry></row><row><entry /><entry>N[pool=2,1]</entry><entry /><entry>✓</entry></row><row><entry /><entry namest="offset" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

p-0296It can be appreciated that all the state variables related to the real-time load are visible to both the RNC and the BSC; the state variables related to the number of active connections for the voice or data services are visible only to the controller of the relevant cell.

p-0297The CRRM decision logic is assumed to be specified in the table of <figref idrefs="DRAWINGS">FIG. 11</figref>, with identifier ID_t=1; the table corresponds in principle to the table of <figref idrefs="DRAWINGS">FIG. 5</figref>.

p-0298It can be appreciated that:

Row 1 of the Table:

p-0299Specifies that service requests of the data type can be satisfied only by the UMTS network;

Rows 2 and 3 of the Table:

p-0300Specify that HO requests of voice services are kept on the RAT towards which they are being transferred by the HO;

Row 4 of the Table:

p-0301Specifies that a new request for a voice service that can be served only by the UMTS network is assigned to the UMTS network;

Row 5 of the Table:

p-0302Specifies that a new request for a voice service that can be served only by the GSM network is assigned to the GSM network;

Row 6 of the Table:

p-0303Specifies that a new request for a voice service received by the RNC, that can be served by both the UMTS network and the GSM network, is assigned to the GSM network (supposing that there is sufficient capacity for it);

Row 7 of the Table:

p-0304Specifies that if it is not possible to allocate a further voice call on the UMTS network, the service request is rejected; this check is performed exploiting the look-up table ID_t=1 defined above: the expression has the following meaning:

p-0305<br />(Number of voice calls in the cell of the UMTS pool)≦(maximum number of admissible voice calls when a number (<i>N</i>[pool,1]) of data calls are present in the cell of the UMTS pool)

Row 8 of the Table:

p-0306Specifies that if in the cell where the voice call request was originated counter c₃>0.7, then the call is accepted on the UMTS network

Row 9 of the Table:

p-0307Specifies that otherwise the call is rejected

Row 10 of the Table:

p-0308Specifies that a new voice service request received by the BSC, that can be served by both the GSM and the UMTS networks, is assigned to the GSM, if there is still room for it;

Row 11 of the Table:

p-0309Specifies that if it is not possible to allocate further voice calls on the UMTS network, the service request is rejected;

Row 12 of the Table:

p-0310Specifies that if in the cell where the voice call request was originated counter c₃>0.7, then the call is accepted on the UMTS network

Row 13 of the Table:

p-0311Specifies that otherwise the call is rejected.

p-0312The operation of the CRRM algorithm, in the considered example, is described in the following.

p-0313Let it be assumed that a mobile terminal, connected to the cell UMTS<b>1</b>, requests to perform a new voice call; let it also be assumed that the terminal is dual-mode capable. The event is in this case characterized by:

p-0314<tables id="TABLE-US-00027" num="00027"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="42pt" align="left" /><colspec colname="2" colwidth="161pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>s=1</entry><entry>(voice call)</entry></row><row><entry /><entry>type=0</entry><entry>(new voice call, not HO)</entry></row><row><entry /><entry>origin=1</entry><entry>(the terminal is connected to the UMTS network)</entry></row><row><entry /><entry>dest(1)=T</entry><entry>(the terminal might connect to the UMTS network)</entry></row><row><entry /><entry>dest(2)=T</entry><entry>(the terminal might connect to the GSM network)</entry></row><row><entry /><entry namest="offset" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

p-0315According to the method described in detail in the foregoing, the voice calls counter and the counter of the voice calls that can be handled by both the GSM and the UMTS networks are both incremented in cell UMTS<b>1</b>.

p-0316The rows of the CRRM decision logic table ID_t=1 are scanned by the table scanner module <b>470</b>, looking for a row compatible with the occurred event. The scan is the one specific for “table for pool” as table ID_t=1 is of this type.

p-0317In particular:

p-0318Row 1 is found to be non-compatible, because the requested service is not a data service;

p-0319Rows 2 and 3 are found to be non-compatible because the service request is for a new call, not a HO;

p-0320Rows 4 and 5 are found to be non-compatible, because they relate to terminals that can use only one of the RATs, i.e. either the GERAN or the UTRAN;

p-0321Row 6 is characterised by a value different from “*” in the column “pool”, therefore the pool <b>2</b> must be expanded in all its cells, namely cell GSM<b>1</b> and GSM<b>2</b>. Since the origin cell (UMTS<b>1</b>) is characterised by “blind” mode, the cells of the pool are kept in the same order as in the definition of the pool, i.e. {GSM<b>1</b>, GSM<b>2</b>}.

p-0322S is calculated considering the first cell (GSM<b>1</b>) as the pool's cell: S={1, 0, UMTS<b>1</b>, T, T, (State of cell UMTS<b>1</b>), (Counters of cell UMTS<b>1</b>), (State of cell GSM<b>1</b>), (Counters of cell UMTS<b>1</b>)}. VExpr is True and the compatibility between S and D_imust be checked. The part of the event is compatible; the remaining part is all “*” apart from column RTLD of the state of pool's cell (that refers to GSM<b>1</b>) where the condition is lower than or equal to 90. Assuming that the condition RTLD[GSM<b>1</b>]≦90 is satisfied, it is then successfully verified whether Action_i=2, therefore C_t=GSM<b>1</b> and the scanning of the table ends with a compatible row found and cell GSM<b>1</b> has to be used to accept the voice call request. <ul><li id="ul0029-0001" num="0000"><ul><li id="ul0030-0001" num="0309">§§§§§</li></ul></li></ul>

p-0323In an alternative embodiment of the invention, the decision logic is not defined in terms of a table, as described above, rather the network operator can input a decision algorithm implementing a desired CRRM policy. In particular, the algorithm may be specified as a compiled computer program code, generated from a source code written by the network operator. Also in this case, the decision logic is structured as a set of one or more decision rules, having the homogenous syntax described in the foregoing. The algorithm may be structured as one or more procedures, or functions with inputs and an output; each corresponding to a decision rule; the inputs to the function may be the characterization of the occurred event (for example, in terms of the n-uple of parameters described in the foregoing), and of the state of the network (as specified by the state variables described in the foregoing), including specific values for the counters defined during the set-up phase. The function output may be an identifier of an action to be taken.

p-0324For example, an interface in C (or similar) programming language may be provided for, of the type:

p-0325<tables id="TABLE-US-00028" num="00028"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="203pt" align="left" /><thead><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>  int CRRM(int s, int type, int origin, boolean* dest,</entry></row><row><entry /><entry>int* integercounter, double* realcounter, tState* networkstate)</entry></row><row><entry /><entry>  {</entry></row><row><entry /><entry>    // Code written by the network operator</entry></row><row><entry /><entry>    return ... // Returns the ID of an action to be taken</entry></row><row><entry /><entry>  }</entry></row><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables><br /> where tState* is a type of a data structure suitable to contain the state of the network.

p-0326The CRRM decision procedure or function is invoked each time an event occurs that necessitates the CRRM algorithm for deciding how it has to be handled (these events are specified in the set-up phase). Based on the output of the function, the network undertakes the corresponding action. Errors or exceptions encountered during the determination of the action to be taken may lead to default actions. <ul><li id="ul0031-0001" num="0000"><ul><li id="ul0032-0001" num="0313">§§§§§</li></ul></li></ul>

p-0327Thanks to the present invention, the network operator is given the possibility of defining and implementing the preferred CRRM policies that best fit the specific network context, possibly varying them in time, without the need of asking the producers of network equipment to customize them.

p-0328The present invention can be applied in general to any telecommunications network, either radio (i.e., wireless) or not, wherein, in order to satisfy service requests from users, network resources (e.g., radio communications resources) have to be assigned to the users, where the assigned network resources can be selected from among different pools of network resources, and the selection is made based on resource selection policies, implemented by algorithms that are executed by network equipment, that take into account the service request and the state of the network.

p-0329Even more generally, the present invention can be applied in any system wherein it is desired or useful to implement system resource management policies, specifying the way system resources are assigned to requesting entities when the latter request services to the system.

p-0330Although in the description it has always been assumed that the CRRM algorithm manages service requests from users, this is not to be construed limitatively: the service request may be triggered by the network itself, for example in order to offer a certain service to the users.

p-0331The present invention can be implemented in hardware or as a combination of hardware and software. Any programming language and any Graphical User Interface (GUI) may be used, particularly any language that can be interpreted by microprocessors included in the network equipment. The specific sets of instructions, as well as the number of variables used in the program, may differ, according to the specific implementation.

p-0332The present invention has been herein described making reference to an illustrative and non-limitative embodiment thereof. Those skilled in the art will recognize that several modifications can be made to the described embodiments, for example in order to satisfy contingent needs, as well as several other embodiments are possible, without departing from the scope of protection set forth in the appended claims.