METHOD FOR RESOURCE MANAGEMENT OF A CONVERTED FIXED ACCESS AND MOBILE NETWORK AND ASSOCIATED COMPUTER PROGRAM PRODUCT AND DEVICES

Description

Scope of the invention

[0001] The field of the invention is the implementation of converged fixed-access and mobile-radio telecommunications networks. The invention relates more particularly to the management of resources (e.g., resources implemented in the local loop, radio resources, resources for the implementation of virtualized functions, referred to as virtualized resources, etc.) in such telecommunications networks.

[0002] The invention has numerous applications, including, but not limited to, the field of telecommunications networks conforming to the latest or future generations of 3GPP (from the English "3rd Generation Partnership Project") standards. Prior art and its drawbacks

[0003] Next-generation mobile radio networks aim to centralize and virtualize baseband processing in central units (CUs) located upstream in the network. The processed radio signals are then transmitted to distributed units (DUs), such as base stations, via resources implemented in the local loop (or front end) of the network. For example, local loop resources are implemented as optical links, microwave links, or even copper conductor pairs (e.g., in some configurations where DUs are connected to a home gateway, also called a modem or router). In this context, a certain capacity of the resources used between the CUs and DUs must be guaranteed by the network.

[0004] Furthermore, different mobile operators may have all or part of their DUs connected to a single converged fixed-access and mobile-radio network, the resources of which are shared among them. In this context, the mobile operators in question compete to obtain resources from the telecommunications network to which their DUs are connected. This is particularly the case when a new resource requirement arises following a reconfiguration of the mobile-radio component of one of the operators (e.g., a change in the number of carrier frequencies allocated to a DU). New resources from the converged fixed-access and mobile-radio network must therefore be allocated to the mobile operator in question to support the associated new data rates. The issue then arises of the impact of this new allocation on the resources previously allocated to the other mobile operator.

[0005] Such mobile operators also find themselves in competition with fixed customers (e.g., user equipment connected to the fixed access portion of the network via a modem connected to the local loop). For example, when such a fixed customer implements new services requiring virtual resources located upstream in the network (e.g., for applications such as virtual reality, augmented reality, value-added services for micro-enterprises, data collection and processing from sensors (Internet of Things, CCTV cameras, etc.), multimedia storage services, etc.).

[0006] Thus, the allocation of new resources to a given customer (e.g., a customer of a given mobile operator) when a new resource need is expressed should not be done in a way that gives other customers (e.g., customers of other mobile operators) the impression that they are being disadvantaged, especially in a context of limited total resources.

[0007] There is therefore a need for an improved technique for managing resources (e.g. virtualized resources, local loop resources, etc.) in a converged fixed-access and radio-mobile telecommunications network when different mobile operators compete to obtain resources from the telecommunications network in question.

[0008] There is also a need for the technology in question to manage competition between different mobile operators and fixed-line customers of the converged fixed-access and radio-mobile telecommunications network. A known example is US 10 116 732 B1. Description of the invention

[0009] In one embodiment of the invention, a method for managing resources in a converged fixed-access and mobile-radio telecommunications network is proposed. A portion of the resources, referred to as virtualized resources, is implemented in a virtualized form and distributed throughout the network. Another portion of the resources, referred to as local loop resources, is implemented in a local loop of the network, with multiple mobile operators each having at least one base station connected to a mobile-radio portion of the network via a mobile-radio modem connected to the local loop. According to this method, a centralized resource allocation management module performs the following steps: reception of at least one resource request, called a mobile customer request, issued either by a mobile radio resource management module of each of the mobile operators, or by a first centralized resource request management module from at least one mobile radio service request previously received from the mobile radio resource management module of each of the mobile operators; sending at least one resource allocation offer to the mobile radio resource management modules based on said at least one mobile customer request and at least one predetermined resource allocation offer rule.

[0010] Thus, the invention proposes a new and inventive solution for managing the resources of the convergent fixed-access and radio-mobile telecommunications network in the context where several mobile operators seek to obtain resources from the network in question.

[0011] More specifically, according to the proposed method, the centralized network resource allocation management module (software or hardware) issues allocation offers to the various mobile operators, taking into account their different requests (requests for virtualized resources and requests for resources located in the local loop, which can be implemented, for example, as optical links, microwave links, copper conductor pairs, etc.) and based on predetermined allocation offer rules. Since these predetermined rules used by the centralized network resource allocation management module are, or can be, known to the operators, they can have confidence in the resource allocation offers made to them.

[0012] In some embodiments, the functionality performed by the centralized network resource allocation management module is implemented via several centralized allocation management modules, for example via one centralized management module dedicated to the allocation of virtualized network resources, and another centralized management module dedicated to the allocation of local loop network resources.

[0013] In one embodiment, at least one user device of a fixed-line operator is connected to a fixed-access portion of the network via at least one fixed-access modem connected to the local loop. The centralized resource allocation management module receives at least one resource request issued either by said at least one user device of the fixed-line operator or by a second centralized resource request management module based on at least one fixed service request previously received from said at least one user device, referred to as a fixed customer request. This at least one allocation offer is also sent to said at least one user device, this at least one allocation offer being a function of said at least one fixed customer request.

[0014] Thus, resource allocation offers also take into account resource requests (in virtualized resources and local loop resources) from customers connected to the fixed-access part of the network.

[0015] According to one embodiment, the centralized resource allocation management module performs a reception: at least one piece of information representative of the availability of local loop resources transmitted by a local loop and fixed-access resource management module of the network; and / or at least one piece of information representative of the availability of virtualized resources transmitted by a remote virtualized resource management module in the network, said at least one allocation offer being a function of said at least one piece of information representative of the availability of local loop resources and / or of said at least one piece of information representative of the availability of virtualized resources.

[0016] Thus, resource allocation offers also take into account resource requests (in virtualized resources and local loop resources) from customers connected to the fixed-access part of the network.

[0017] According to one embodiment, the centralized resource allocation management module transmits said at least one piece of information representing the availability of local loop resources and / or said at least one piece of information representing the availability of virtualized resources to the first and / or second centralized resource request management module.

[0018] Thus, the first and / or second centralized resource request management module can create a shared and up-to-date database containing information on local loop and virtualized resource offerings. Furthermore, the first and / or second centralized resource request management module can distribute the information contained in this database to fixed or mobile clients as needed. Alternatively, the database can be distributed to each fixed or mobile client, and the recorded information can also be certified by consensus by each client as a certified distributed ledger.

[0019] According to one embodiment, the centralized resource allocation management module receives at least one confirmation of acceptance of the resource allocation offer, referred to as a confirmed allocation offer, sent by: at least one module from among the mobile radio resource management modules of each of the mobile operators; and / or said at least one user device.

[0020] According to one embodiment, the centralized resource allocation management module sends at least one resource reservation confirmation to the local loop and fixed-access network resource management module and / or to the remote virtualized resource management module in the network, said at least one resource reservation confirmation being sent when said at least one confirmation of acceptance of the resource allocation offer is received.

[0021] Thus, the resources are effectively allocated to the customer who sent the booking confirmation.

[0022] According to one embodiment, said at least one predetermined resource allocation offer rule belongs to the group comprising: A resource allocation offer is sent as a priority in response to a request received first in a series of several requests; a resource allocation offer is sent as a priority in response to a request received last in a series of several requests; a resource allocation offer is sent as a priority in response to a request with a priority processing urgency level in a series of several requests received with different processing urgency levels; a resource allocation offer is made following an auction mechanism; a resource allocation offer is made for a defined duration; and a resource allocation offer is made only if other resources are released in exchange.

[0023] For example, when the offer of resource allocation is made according to an auction mechanism, the mechanism in question is for example a simple auction mechanism (the highest price wins), a double auction mechanism (average bids), or an auction mechanism with or without a reserve price (the offer must be higher than the reserve price).

[0024] In one embodiment of the invention, it is proposed that the first centralized resource request management module for mobile clients performs the following steps: reception of at least one radio-mobile service request issued by a radio-mobile resource management module of each of the mobile operators; and transmission to the centralized network resource allocation management module of at least one resource request taking into account said at least one radio-mobile service request.

[0025] Thus, the end mobile customer simply expresses their service needs. The first module translates these service requirements into resource requirements, which can be of various types, e.g., virtual resources and / or local loop resources. This first module then requests and ensures that all the resources, potentially of different types, required by the end customer are available from the centralized network resource allocation management module(s).

[0026] In one embodiment of the invention, at least one user device of a fixed-line operator is connected to a fixed-access portion of the network via at least one fixed-access modem connected to the local loop. It is thus proposed that a second centralized resource request management module for fixed customers performs the following steps: reception of at least one fixed service request issued by said at least one user equipment of the fixed operator; and transmission to the centralized network resource allocation management module of at least one resource request taking into account said at least one fixed service request.

[0027] Thus, the end-user client simply expresses their service needs. The second module translates these service requirements into resource requirements, which can be of various types, e.g., virtual resources and / or local loop resources. This second module then requests and ensures that all the resources, potentially of different types, required by the end-user client are available from the centralized network resource allocation management module(s).

[0028] The invention also relates to a computer program comprising program code instructions for implementing the process as described above, according to any one of its various embodiments, when executed on a computer.

[0029] In one embodiment of the invention, a centralized resource allocation management device for a converged fixed-access and mobile radio telecommunications network is proposed. Such a management device comprises a reprogrammable computing machine or a dedicated computing machine configured to implement the steps of the management process according to the invention as performed by the centralized resource allocation management module for a converged fixed-access and mobile radio telecommunications network (according to any one of the aforementioned embodiments).

[0030] Thus, the characteristics and advantages of this device are the same as those of the corresponding steps in the management process described previously. Therefore, they are not detailed further.

[0031] In one embodiment of the invention, a centralized resource request management device for a converged fixed-access and mobile radio telecommunications network for mobile clients is proposed. Such a management device comprises a reprogrammable computing machine or a dedicated computing machine configured to implement the steps of the management process according to the invention as performed by the first centralized resource request management module for mobile clients (according to any one of the aforementioned embodiments).

[0032] Thus, the characteristics and advantages of this device are the same as those of the corresponding steps in the management process described previously. Therefore, they are not detailed further.

[0033] In one embodiment of the invention, a centralized resource request management device for a converged fixed-access and mobile-radio telecommunications network for fixed customers is proposed. Such a management device comprises a reprogrammable computing machine or a dedicated computing machine configured to implement the steps of the management process according to the invention as performed by the second centralized resource request management module for fixed customers (according to any one of the aforementioned embodiments).

[0034] Thus, the characteristics and advantages of this device are the same as those of the corresponding steps in the management process described previously. Therefore, they are not detailed further.

[0035] In one embodiment of the invention, a convergent fixed-access and mobile radio telecommunications network node is proposed. Such a network node comprises at least one of the aforementioned devices (according to any one of the aforementioned embodiments), i.e., a centralized resource allocation management device for a convergent fixed-access and mobile radio telecommunications network, a centralized resource request management device for a convergent fixed-access and mobile radio telecommunications network for mobile clients, and a centralized resource request management device for a convergent fixed-access and mobile radio telecommunications network for fixed clients. List of figures

[0036] Other objects, features and advantages of the invention will become more apparent upon reading the following description, given by way of simple illustration and not limitation, in relation to the figures, among which: [ Fig. 1 ] represents the architecture of a convergent fixed-access and mobile-radio telecommunications network whose resources are managed by a management process according to an embodiment of the invention; [ Fig. 2 ] represents the steps in a network resource management process of the Fig. 1 according to one embodiment of the invention; [ Fig. 3 ] represents the architecture of a convergent fixed-access and mobile-radio telecommunications network whose resources are managed by a management process according to another embodiment of the invention; [ Fig. 4] represents the steps in the network resource management process of the Fig. 3 according to another embodiment of the invention; [ Fig. 5 ] represents an example of a device structure enabling the implementation of the steps of the resource management process according to an embodiment of the invention. Detailed description of embodiments of the invention

[0037] The general principle of the invention is based on the use of a centralized resource allocation management module (software or hardware) for a converged fixed-access and mobile-radio telecommunications network. This module centrally addresses the various resource requests issued by mobile customers of different mobile operators who have at least some of their distribution units (DUs) connected to the network in question. More specifically, the centralized resource allocation management module issues allocation offers to the various mobile operators, taking into account the different resource requests issued by these operators as well as predetermined allocation offer rules. Since such predetermined rules are, or can be, known to the operators, they can have confidence in the resource allocation offers made to them.

[0038] We now present, in relation to the Fig. 1 the architecture of a convergent fixed-access and mobile-radio telecommunications network whose resources are managed by a management process according to an embodiment of the invention.

[0039] In the network in question, a node 150 of the converged fixed-access and mobile-radio network is connected upstream to the core 140 of the network itself and downstream to a plurality of network modems. The plurality of modems includes: fixed-access modems 100mf, with at least one fixed 100cpe user device connected to the fixed-access part of the network via a corresponding fixed-access modem 100mf; and mobile-radio modems 100mma, 100mmb, with 100dua, 100dub base stations connected to the mobile-radio part of the network via a corresponding mobile-radio modem 100mma, 100mmb.

[0040] More specifically, the plurality of 100mf, 100mma, 100mmb modems is connected to a 100r router of node 150 via local loop resources, here 100fr, 100ff optical fibers passing through a 170 multiplexer. The 100mf fixed-access modems are connected to the 100r router by corresponding 100ff optical fibers and the 100mma, 100mmb mobile radio modems are connected to the 100r router by corresponding 100fr optical fibers (e.g. according to an FTTH (Fiber To The Home) type infrastructure).

[0041] In other embodiments, there may be only one 100mf fixed-access modem.

[0042] In other embodiments, the local loop uses a technology other than optical fiber, and the 100mf, 100mm modems are connected to the 100r router via means other than 100fr, 100ff optical fibers (e.g., via microwave links, copper conductor pairs, etc.).

[0043] Back to the Fig. 1 The 100dua and 100dub base stations each belong to two different mobile operators. More specifically, the first mobile operator has the 100dua base station connected to the mobile radio portion of the network via the 100mma mobile radio modem, and the second mobile operator has the 100dub base station connected to the mobile radio portion of the network via the 100mmb mobile radio modem.

[0044] In other embodiments, more than two mobile operators each have at least one base station connected to the radio-mobile part of the network via a modem itself connected to the local loop of the network.

[0045] Back to the Fig. 1 Module 120 is a centralized management module that also: local loop resources dedicated to both the operation of the radio-mobile part and the fixed-access part of the network; and other resources, called fixed-access, dedicated more specifically to the operation of the fixed-access part of the network.

[0046] In this application, module 120 is also referred to as " Local loop and fixed-access resource management moduleFurthermore, it should be noted that the term "module" can generally refer to a software component, a hardware component, or a set of hardware and software components. A software component itself corresponds to one or more computer programs or subprograms, or more generally, to any element of a program capable of implementing a function or set of functions as described for the module(s) in question. Similarly, a hardware component corresponds to any element of a hardware assembly capable of implementing a function or set of functions for the module(s) in question (integrated circuit, smart card, memory card, etc.). In this case, the hardware component takes the form of a device capable of, or configured to, implement a function or set of functions as described for the module(s) in question.

[0047] More specifically, module 120 centrally manages, among other things, the network's local loop resources based on at least one local loop performance indicator, known as the "local loop performance indicator." This local loop performance indicator(s) is / are transmitted, notably by router 100r and / or all or some of the 100mma, 100mmb, and 100mf modems via router 100r.

[0048] Furthermore, module 120 transmits to a module 160bl of centralized management dedicated to the allocation of local loop resources of the network one (or more) pieces of information representative of the availability of local loop resources. Such information representative of the availability of local loop resources is obtained, for example, from the local loop performance indicator(s).

[0049] As described below in relation to the Fig. 2The 160bl centralized management module, dedicated to allocating local loop network resources, receives one or more requests for local loop resources issued by a 170mob centralized network resource request management module for mobile radio clients and / or by a 170fix centralized network resource request management module for fixed clients. In response to such requests, the 160bl module sends one or more local loop resource offers to the corresponding mobile and / or fixed clients.

[0050] Modules 110a and 110b management of radio-mobile resourcesare dedicated respectively to the operation of the mobile radio infrastructure of the first and second mobile operators mentioned above. As an illustrative example, modules 110a and 110b could each be considered C-SON (Centralized-Self Organizing Networks) as defined within 3GPP, but here with new functionalities enabling network resource management. For example, modules 110a and 110b each receive one (or more) performance indicators for the mobile radio infrastructure they manage, transmitted by all or some of the 100dua and 100dub base stations and / or by the 100vrana and 100vranb modules. These are virtualized radio functions located within the network and dedicated to the mobile radio infrastructure of the first and second mobile operators. For example, modules 100vrana and 100vranb correspond to a centralized radio element (CU) as defined by 3GPP.In other embodiments, more than two mobile operators each have a base station connected to a mobile radio portion of the network. In this case, each mobile operator has a corresponding mobile radio resource management module to manage the operation of its dedicated mobile radio portion.

[0051] Back to the Fig. 1 , THE module 130 for virtualized resource managementThe remote network management module centrally manages the 100vm virtualized resources (in terms of hardware resources, e.g., computing power, storage capacity, RAM capacity, etc.) of the network based on the module. To do this, the 130 module receives one (or more) performance indicators for the virtualized portion of the network, referred to as the "virtualized performance indicator," sent by the 100vcpe module(s) of virtualized functions located on the network and / or by the 100vm virtualized resource module. More specifically, the 100vcpe module implements virtualized functions located on the network and dedicated to a corresponding 100cpe fixed user device. In this application, the 100vcpe module is also referred to as the "virtualized fixed device function module." The 100vcpem module is a management module for the virtualized functions located on the network as implemented in the 100vcpe module.

[0052] Furthermore, the 130 module transmits to a 160v module centralized management dedicated to the allocation of virtualized resources from the network one (or more) pieces of information representative of the availability of virtualized resources. Such information representative of the availability of virtualized resources is obtained for example from one (or more) performance indicator of the virtualized network resources sent by the 100vcpe module(s) of virtualized functions located in the network and / or of 100vm virtualized resources (e.g. an availability and / or load indicator of the virtualized resources, a performance indicator of the functions (e.g. vCPE or vRAN) supported by these resources).

[0053] As described below in relation to the Fig. 2The 160v centralized management module, dedicated to allocating virtualized network resources, receives one or more resource requests (virtual or local loop) issued by the 170mob centralized network resource request management module for mobile radio clients and / or by the 170fix centralized network resource request management module for fixed clients. In response to such requests, the 160bl module sends one or more virtualized resource offers to the corresponding mobile and / or fixed clients.

[0054] The 170mob module, for centralized management of network resource requests for mobile radio clients, centralizes mobile client requests sent by modules 110a and 110b in terms of mobile services. Module 170mob translates the needs associated with these mobile services into resource requirements (virtualized and / or local loop). Module 170mob requests the resource requirements obtained from modules 160bl and / or 160v.

[0055] Similarly, the 170fix module for centralized network resource request management for fixed clients centralizes requests from 100cpe fixed clients in terms of fixed services. The 170fix module translates the needs associated with these fixed services into resource requirements (virtualized and / or local loop). The 170fix module requests the resource requirements obtained from the 160bl and / or 160v modules.

[0056] We now present, in relation to the Fig. 2 the steps in a network resource management process Fig. 1 according to one embodiment of the invention. Phase P1 :

[0057] During a step P1E200, Module 120 receives the local loop performance indicator(s) transmitted in particular by router 100r and / or all or part of the 100mma, 100mmb, 100mf modems via router 100r.

[0058] During a step P1E201, Module 160bl receives one or more pieces of information from module 120 that represent the availability of local loop resources. Such information, representing the availability of local loop resources, is obtained, for example, by module 120 from the local loop performance indicator(s) received at step P1E200 (e.g., mobile clients must have a guaranteed bandwidth).

[0059] During a step P1E202,The 160bl module transmits information representing the availability of local loop resources to the 170fix and 170mob modules. This allows the 170mob and 170fix modules to build a shared, up-to-date database containing information on local loop resource offerings. Furthermore, fixed and mobile clients can read the information in this database as needed. Alternatively, the database can be distributed to all or some fixed and mobile clients with the necessary resources. The information stored in the database can also be certified by consensus by each client as a certified distributed ledger.

[0060] In other embodiments, the 160bl module transmits the information representing the availability of local loop resources only to one of the 170fix and 170mob modules in order to limit data exchange. In other embodiments, the 160bl module does not implement step P1E202 in order to further limit data exchange. Phase P2 :

[0061] During a step P2E200 (not illustrated on the Fig. 1 ), module 130 receives the virtualized performance indicator(s), e.g. sent by the 100vcpe module(s) of remote virtualized functions in the network and / or 100vm virtualized resources.

[0062] During a step P2E201,Module 160v receives one or more pieces of information from module 130 that represent the availability of virtualized resources. Such information representing the availability of virtualized resources is obtained, for example, by module 130 from the virtualized performance indicator(s) received at step P2E200 (e.g., the resources in question are of the type computing capacity, storage memory capacity, RAM capacity, etc.).

[0063] During a step P2E202,The 160v module transmits information regarding the availability of virtualized resources to the 170fix and 170mob modules. This allows the 170mob and 170fix modules to build a shared, up-to-date database containing information on virtualized resource offerings. Furthermore, the 170mob and 170fix modules can distribute this database information to fixed or mobile clients as needed.

[0064] In other embodiments, the 160v module transmits the information representing the availability of the virtualized resources only to one of the 170fix and 170mob modules in order to limit data exchange. In other embodiments, the 160v module does not implement the P2E202 step in order to further limit data exchange. Phase P3 :

[0065] During a step P3E210,The 170mob centralized network resource request management module for radio-mobile clients centralizes mobile client requests, sent by modules 110a and 110b, in terms of mobile services.

[0066] During a step P3E211,The 170mob module translates the needs associated with the mobile services in question into resource requirements (virtualized and / or local loop) and sends one (or more) corresponding resource requests to the 160bl and / or 160v modules, depending on the nature of the resources requested (i.e., to the 160bl module for local loop resources and to the 160v module for virtualized resources). For example, for mobile clients, the resource request sent by the 170mob module to the 160bl module concerns "guaranteed bandwidth" resources, and the request to the 160v module concerns "dedicated" resources (or "high resilience" resources, meaning they cannot be shared when not in use).

[0067] In some embodiments, the 170mob module checks before sending them that the request(s) in question correspond to resources actually available by using knowledge of information representative of the availability of local loop and / or virtualized resources issued by the 160bl and / or 160v modules during steps P1E202 and P2E202. Phase P4 During a step P4E210, The 170fix module for centralized management of network resource requests for fixed clients centralizes requests from 100cpe fixed clients in terms of fixed services (e.g., for an augmented reality service).

[0068] During a step P4E211,The 170fix module translates the needs associated with the fixed services in question into resource requirements (virtualized and / or local loop) and sends one (or more) corresponding resource requests to the 160bl and / or 160v modules depending on the nature of the resources requested (i.e. to the 160bl module for local loop resources and the 160v module for virtualized resources).

[0069] In some embodiments, the 170fix module checks before sending them that the request(s) in question correspond to resources actually available by using knowledge of information representative of the availability of local loop and / or virtualized resources issued by the 160bl and / or 160v modules during the P1E202 and P2E202 steps. Phase P5 :

[0070] During a step P5E220,The 160v module decides which offer(s) of virtualized network resources to make to the different clients for whom the 160v module received a resource request during the P3E211 step and / or during the P4E211 step.

[0071] More specifically, the 160v module decides which virtualized resource allocation offer(s) to use based on the request(s) in question and at least one predetermined resource allocation offer rule. Since such predetermined rules used by the 160v module are (or can be) known to mobile operators, they can have confidence in the resource allocation offers made to them.

[0072] For example, such a predetermined resource allocation offer rule belongs to the group comprising: A resource allocation offer is sent as a priority in response to the first request received in a sequence of several requests; a resource allocation offer is sent as a priority in response to the last request received in a sequence of several requests; a resource allocation offer is sent as a priority in response to a request with a high level of processing urgency in a sequence of several requests received with different levels of processing urgency; a resource allocation offer is made following an auction mechanism (e.g.a simple auction mechanism (highest price wins), a double auction mechanism (average bids), or an auction mechanism with or without a reserve price (the bid must be higher than the reserve price); a resource allocation offer is made for a defined period; and a resource allocation offer is only made if other resources are released in exchange.

[0073] In some embodiments, the offer(s) of virtualized resource allocation is also a function of the information(s) representing the availability of local loop resources and / or the information(s) representing the availability of virtualized resources.

[0074] During a step P5E221,The 160v module sends the offer(s) for the allocation of virtualized resources to the different clients via the 170mob module and / or the 170fix module depending on the origin of the resource requests received during the P3E211 step and / or during the P4E211 step.

[0075] In some variations, a virtualized resource offered in a given allocation offer cannot be offered to another customer through a different offer. It is reallocated among all available resources if the customer to whom the offer is addressed does not send confirmation of acceptance of the allocation offer before a predetermined time. Phase P6 :

[0076] During a step P6E220, The 160bl module decides which local loop resource allocation offer(s) to make to the various clients for whom the 160v module received a resource request during the P3E211 step and / or during the P4E211 step.

[0077] More specifically, the 160bl module decides which local loop resource allocation offer(s) to use based on the request(s) in question and at least one predetermined resource allocation offer rule. For example, the 160bl module implements a rule similar to those implemented by the 160v module during phase P5 and given in the example above.

[0078] In some embodiments, the local loop resource allocation offer(s) is also a function of the information representing the availability of local loop resources and / or the information representing the availability of virtualized resources.

[0079] During a step P6E221,The 160bl module sends the offer(s) for virtualized resource allocation to the different clients via the 170mob module and / or the 170fix module depending on the origin of the resource requests received during the P3E211 step and / or during the P4E211 step.

[0080] Similarly, in some variations, a local loop resource offered in a given allocation offer cannot be offered to another client through a different offer. It is reallocated among all available resources if the client to whom the offer is addressed does not send confirmation of acceptance of the allocation offer before a predetermined time. Phase P7 :

[0081] Following phases P5 and P6, the 170mob and / or 170fix modules received resource allocation offers from the 160bl and / or 160v modules. The 170mob and / or 170fix modules then send these offers to the mobile and / or fixed customers who have received a resource allocation offer.

[0082] In the example shown on the Fig. 2 The first mobile operator's module 110a received a resource allocation offer following its service request at step P3E210. Conversely, the second mobile operator's module 110b and the fixed customer 100cpe did not receive any resource allocation offers following their requests at steps P3E210 and P4E210, respectively. Therefore: during a step P7E230,Module 170mob sends the resource allocation offer (virtualized and / or local loop depending on the need expressed in the service request sent during the aforementioned P3E210 step) to module 110a; during a step P7E231, Module 110a sends a confirmation of acceptance of the resource allocation offer, called a confirmed allocation offer, to module 170mob; during a step P7E232, The 170mob module sends the confirmed allocation offer to the 160bl module and / or the 160v module, depending on the nature of the resources offered (to the 160v module for virtualized resources and / or to the 160bl module for local loop resources); during a step P7E233,Module 160bl and / or module 160v sends one or more resource reservation confirmations to module 120 and / or module 130, depending on the nature of the resources offered (to module 130 for virtualized resources and / or to module 120 for local loop resources). For example, the resource reservation confirmation(s) are sent to module 120 and / or module 130 when the acceptance confirmation(s) of the resource allocation offer are received during the aforementioned step P7E232. In some variants, module 120 and / or module 130 acknowledge receipt of the received resource reservation confirmation(s). step P7E234, The 160bl module and / or the 160v module sends information Modules 170mob and 170fix indicate that module 110b and fixed client 100cpe have not received any resource allocation offers. Modules 170mob and 170fix then transmit this information to module 110b and fixed client 100cpe, respectively.

[0083] We now present, in relation to the Fig. 3 the architecture of a convergent fixed-access and mobile-radio telecommunications network whose resources are managed by a management process according to another embodiment of the invention.

[0084] The same elements are found as in the embodiment illustrated on the Fig. 1 except for the 170fix and 170mob modules, which are absent here. Furthermore, the 160v and 160bl modules are merged into a single 160 module which, with some adaptations, implements the functionalities of both the 160v and 160bl modules as described below in relation to the Fig. 4We now present, in relation to the Fig. 4 the steps in a network resource management process Fig. 3 according to another embodiment of the invention.

[0085] This embodiment includes the steps of phases P1 and P2 of the embodiment illustrated in the Fig. 2 However, during step P1E201, module 120 now sends the information representing the availability of local loop resources to module 160 and no longer to module 160bl, as module 160 now implements the functionalities of both modules 160v and 160bl. Similarly, during step P2E201, module 130 sends the information representing the availability of virtualized resources to module 160 and no longer to module 160v.

[0086] Furthermore, steps P1E202 and P2E202 are no longer implemented here, as modules 170fix and 170mob are no longer implemented.

[0087] In the implementation of the Fig. 4 , during phase P3, steps P3E210 and P3E211 of the Fig. 2 are here merged into one step P3E410 during which the radio-mobile clients send, via modules 110a and 110b, directly to module 160 one (or more) resource requests (virtualized resources and / or local loop resources).

[0088] Similarly, during phase P4, steps P4E210 and P4E211 of the Fig. 2 are here merged into one step P4E410 During this time, mobile clients send one or more resource requests (virtualized and / or local loop) directly to module 160 via modules 110a and 110b. The same applies to fixed 100cpe clients.

[0089] Thus, according to this embodiment, the end customer (mobile or fixed) expresses their need directly in terms of resource requirements, which can be of different types (e.g., virtual and / or local loop resources). Therefore, it is the end customer who must ensure they receive as many resource allocation offers, potentially of different types, as necessary to implement a given service. Conversely, in the embodiment of the fig.2 , it is the 170fix and 170mob modules that ensure this consistency and not the end customer.

[0090] Back to the Fig. 4 , during phase P5 / 6 (corresponding to a fusion of phases P5 and P6 of the Fig. 2 ), steps P5E220 and P6E220 of the Fig. 2 are here merged into one step P56E420during which module 160 decides the resource allocation offer(s) (virtualized and / or local loop) of the network to be made to the different clients for whom module 160 received a resource request during step P3E410 and / or step P4E410.

[0091] Furthermore, steps P5E221 and P6E221 of the Fig. 2 are here merged into one step P56E421 during which module 160 sends the (virtualized and / or local loop) resource allocation offer(s) from the network to the corresponding clients, i.e. modules 110a and / or 110b and / or fixed clients 100cpe, according to the origin of the resource requests received during step P3E410.

[0092] Similarly, during phase P7, steps P7E231 and P7E232 of the Fig. 2 are here merged into one étape P7E431 during which module 110a sends a confirmation of acceptance of the resource allocation offer, called confirmed allocation offer, to module 160 and no longer to module 170mob.

[0093] Similarly, during step P7E233, it is module 160, and no longer module 160bl and / or module 160v, that sends one (or more) resource reservation confirmations to module 120 and / or module 130, depending on the nature of the resources offered (virtualized and / or local loop). Indeed, module 160 now implements the functionalities of both modules 160v and 160bl.

[0094] The same applies during the P7E234 step during which it is the 160 module, and no longer the 160bl module and / or the 160v module, which sends information directly to the 110b module and the fixed client 100cpe indicating respectively that they do not have a resource allocation offer made to them.

[0095] In other embodiments, the 170fix and 170mob modules are not implemented, as in the embodiment of figs. 3 And 4 However, modules 160v and 160bl are still implemented separately and not as a single module 160. In these embodiments, module 160v manages the allocation bids for virtualized network resources, and module 160bl manages the allocation bids for local loop network resources, with the functionalities described above in relation to the figs. 1 And 2 .

[0096] In other embodiments, the 160v and 160bl modules are merged into a single 160 module, as in the embodiment of figs. 3 And 4 However, the 170fix and 170mob modules are still implemented (as a single module or two separate modules) with the functionalities described above in relation to the figs. 1 And 2 .

[0097] In other embodiments, a single module implements the functionalities of modules 170fix, 170mob, 160v, and 160bl. In these embodiments, mobile clients 110a and 110b send one or more mobile service requests to this single module. Similarly, fixed clients 100cpe send one or more fixed service requests to the single module. Thus, this single module translates the service requirements into resource needs (virtualized and / or local loop) by implementing the functionalities of modules 170fix and 170mob described above in relation to the figs. 1 And 2 .

[0098] We now present, in relation to the fig. 5 an example of a 500 device structure allowing the implementation of the steps in the resource management process figs. 2 And 3 according to one embodiment of the invention.

[0099] The device 500 comprises a random access memory 503 (for example, RAM), a processing unit 502 equipped, for example, with a processor, and controlled by a computer program stored in a read-only memory 501 (for example, ROM or a hard drive). At initialization, the code instructions of the computer program are, for example, loaded into the random access memory 503 before being executed by the processor of the processing unit 502. This fig. 3 illustrates only one particular way, among several possible ways, of implementing device 500 so that it performs certain steps of the management process according to the invention (according to any one of the embodiments and / or variants described above in relation to the fig. 2Indeed, these steps can be carried out interchangeably on a reprogrammable computing machine (a PC, a DSP processor or a microcontroller) running a program comprising a sequence of instructions, or on a dedicated computing machine (for example a set of logic gates such as an FPGA or an ASIC, or any other hardware module).

[0100] In the case where the 500 device is made with a reprogrammable computing machine, the corresponding program (i.e. the sequence of instructions) may be stored in a removable storage medium (such as, for example, a floppy disk, a CD-ROM or a DVD-ROM) or not, this storage medium being readable partially or totally by a computer or a processor.

[0101] In some embodiments, the 500 device implements any one of the 170fix, 170mob, 160v and 160bl modules.

[0102] In some embodiments, the 500 device implements several or all of the 170fix, 170mob, 160v and 160bl modules.

[0103] In some embodiments, device 500 is included in a network node, e.g. in node 150.

Claims

1. Method for managing allocation of resources of a converged fixed access and mobile radio telecommunications network, the method being implemented by a module (160, 160bl, 160v) for centralized management of the allocation of said resources, a part of said resources, called virtualized resources, being implemented in a virtualized form and moved in said network, another part of said resources, called local-loop resources, being implemented in a local loop of said network, a plurality of mobile operators each having at least one base station connected to a mobile radio part of said network via a modem called the mobile radio modem connected to said local loop, the method for managing allocation of resources comprising the following steps: - receiving (P3E211, P3E410) at least one request of resources, called mobile client request, emitted either by a module (110a, 110b) for management of the mobile radio resources of each of said mobile operators, or by a first module (170mob) for centralized management of the requests for resources from at least one request for mobile radio service previously received from said mobile radio resource management module of each of said mobile operators; - sending (P5E221, P56E421) at least one offer of allocation of said resources to said modules for management of the mobile radio resources according to said at least one mobile client request and on at least one predetermined resource-allocation-offer rule.

2. Method according to Claim 1, wherein at least one user equipment of a fixed operator is connected to a fixed access part of said network via at least one modem called fixed access modem, which is connected to said local loop, and wherein said module for centralized management of the allocation of said resources carries out a reception of (P4E211, P4E410) at least one request for resources emitted either by said at least one user equipment (100cpe) of said fixed operator, or by a second module (170fix) for centralized management of the requests for resources from at least one request for fixed service previously received from said at least one user equipment, called the fixed client request; and wherein said at least one allocation offer is also sent to said at least one user equipment, said at least one allocation offer being dependent on said at least one fixed client request.

3. Method according to Claim 1 or 2, wherein said module for centralized management of the allocation of said resources carries out a reception of (P1E201, P2E201) : - at least one piece of information representing the availability of said local-loop resources transmitted by a module (120) for management of the local-loop and fixed access resources of said network; and / or - at least one piece of information representing the availability of said virtualized resources transmitted by a module (130) for management of the virtualized resources moved in said network, said at least one allocation offer being dependent on said at least one piece of information representing the availability of the local-loop resources and / or on said at least one piece of information representing the availability of the virtualized resources.

4. Method according to Claim 3, wherein said module for centralized management of the allocation of said resources carries out a transmission of(P1E202, P2E202) said at least one piece of information representing the availability of the local-loop resources and / or said at least one piece of information representing the availability of the virtualized resources to said first and / or second centralized resource request management module.

5. Method according to any of Claims 1 to 4, wherein said module for centralized management of the allocation of said resources carries out a reception of (P7E231, P7E232, P7E431) at least one confirmation of acceptance of said offer of allocation of said resources, called the confirmed allocation offer, sent by: - at least one module out of said modules for management of the mobile radio resources of each of said mobile operators; and / or - said at least one user equipment.

6. Method according to Claim 5 when dependent on Claim 3, wherein said module for centralized management of the allocation of said resources sends (P7E233) at least one confirmation of reservation of said resources to said network local loop and fixed access resource management module and / or to said module for management of the virtualized resources moved in said network, said at least one confirmation of reservation of said resources being sent when said at least one confirmation of acceptance of said offer of allocation of said resources is received.

7. Method according to any of Claims 1 to 6, wherein said at least one predetermined resource-allocation-offer rule belongs to the group containing: - an offer of allocation of said resources is sent first in response to a request received first in a series of several requests; - an offer of allocation of said resources is sent first in response to a request received last in a series of several requests; - an offer of allocation of said resources is sent first in response to a request having a priority level of urgency processing in a series of several received requests having various levels of urgency of processing; - an offer of allocation of said resources is made according to an auction mechanism; - an offer of allocation of said resources is made for a defined duration; and - an offer of allocation of said resources is only made if other resources are freed in exchange.

8. Method for managing requests for resources of a converged fixed access and mobile radio telecommunications network, the method being implemented by a module (170mob) for centralized mobile client resource request management, a part of said resources being implemented in a virtualized form and moved in said network, another part of said resources being implemented in a local loop of said network, a plurality of mobile operators each having at least one base station connected to a mobile radio part of said network via a modem called the mobile radio modem connected to said local loop, the method for managing requests for resources comprising the following steps: - receiving (P3E210, P3E410) at least one request for mobile radio service emitted by a module (110a, 110b) for management of the mobile radio resources of each of said mobile operators; and - transmitting (P3E211, P3E410) to a module (160, 160bl, 160v) for centralized management of the allocation of said resources of said network at least one request for resources taking into account said at least one request for mobile radio service.

9. Computer program product comprising program code instructions for implementing the method according to any of Claims 1 to 7, when said program is executed on a computer.

10. Computer program product comprising program code instructions for implementing the method according to Claim 8, when said program is executed on a computer.

11. Device for centralized management of allocation of resources of a converged fixed access and mobile radio telecommunications network, a part of said resources, called virtualized resources, being implemented in a virtualized form and moved in said network, another part of said resources, called local-loop resources, being implemented in a local loop of said network, a plurality of mobile operators each having at least one base station connected to a mobile radio part of said network via a modem called mobile radio modem connected to said local loop, the device comprising a reprogrammable computing machine (502) or a dedicated computing machine, configured to: - receive at least one request for resources, called mobile client request, emitted either by a module (110a, 110b) for management of the mobile radio resources of each of said mobile operators, or by a first module (170mob) for centralized management of the requests for resources from at least one request for mobile radio service previously received from said module for mobile radio resource management of the of each of said mobile operators; - send at least one offer of allocation of said resources to said modules for management of the mobile radio resources according to said at least one mobile client request and on at least one predetermined resource-allocation-offer rule.

12. Device for centralized management of requests for resources of a converged fixed access and mobile radio telecommunications network, a part of said resources, called virtualized resources, being implemented in a virtualized form and moved in said network, another part of said resources, called local-loop resources, being implemented in a local loop of said network, a plurality of mobile operators each having at least one base station connected to a mobile radio part of said network via a modem called mobile radio modem is connected to said local loop, the device comprising a reprogrammable computing machine (502) or a dedicated computing machine, configured to: - receive at least one request for mobile radio service sent by a module (110a, 110b) for management of the mobile radio resources of each of said mobile operators; and - transmit to a module (160, 160bl, 160v) for centralized management of the allocation of said resources of said network at least one request for resources taking into account said at least one request for mobile radio service.

13. Node of a converged fixed access and mobile radio telecommunications network, comprising at least one device according to Claim 11 or 12.