WO2010100311A1 - Dispositivos y método para la admisión y control de recursos en entornos multidominio - Google Patents

Dispositivos y método para la admisión y control de recursos en entornos multidominio Download PDF

Info

Publication number
WO2010100311A1
WO2010100311A1 PCT/ES2010/070123 ES2010070123W WO2010100311A1 WO 2010100311 A1 WO2010100311 A1 WO 2010100311A1 ES 2010070123 W ES2010070123 W ES 2010070123W WO 2010100311 A1 WO2010100311 A1 WO 2010100311A1
Authority
WO
WIPO (PCT)
Prior art keywords
request
type
domain
resources
connection
Prior art date
Application number
PCT/ES2010/070123
Other languages
English (en)
French (fr)
Inventor
María Angeles CALLEJO RODRIGUEZ
José ENRIQUEZ GABEIRAS
Original Assignee
Telefonica, S.A.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Telefonica, S.A. filed Critical Telefonica, S.A.
Priority to BRPI1009096A priority Critical patent/BRPI1009096A2/pt
Priority to EP10748371A priority patent/EP2405615A1/en
Priority to MX2011009045A priority patent/MX2011009045A/es
Publication of WO2010100311A1 publication Critical patent/WO2010100311A1/es

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control

Definitions

  • the present invention relates, in general, to the management of resources to ensure the quality of service in telecommunication networks and more particularly to the management of resources in New Generation Networks.
  • control planes set of systems responsible for manage the physical resources of an NGN network
  • ETSI / TISPAN RACSs Resource and Admission Control Sub-System, Resource Management and Admission Subsystem
  • ITU- T RACFs Resource and Admission Control Functions
  • end-to-end QoS solutions is also being studied making use of the functionalities available at the service or application level.
  • provision of end-to-end QoS is being studied using the IMS core [IP Multimedia Subsystem, IP Multimedia Subsystem) to coordinate the configuration of resources in the networks of access.
  • IMS core IP Multimedia Subsystem, IP Multimedia Subsystem
  • SIP Session Initiation Protocol
  • the major drawback of this approach is that it would be essential to use the SIP (Session Initiation Protocol) protocol at the application level, that is, not only on the operator's servers but also on the client's applications; Which would be a limitation of the solution, since it could not be used in the provision of services with guaranteed QoS whose signaling is not based on SIP. If a new application / service is developed that requires specific network features in a multi-domain environment and cannot use SIP, the network administrator would have to redefine and implement the interactions between the interdomain servers.
  • SIP Session Initiation Protocol
  • devices and a method that extend the capabilities of the control plane of a telecommunication network are proposed, such as the NGN network, allowing the reservation and configuration of network resources with other networks of the same type. to provision guaranteed QoS in multi-domain environments that also contemplate the home network of the end user.
  • This control plane may be used by any service or application plane, including the IMS itself or any other service platform of the network operator. This allows convergent network operators the use of this control plane with any of their service platforms.
  • the present invention is implemented in the QoS provision modules in NGN ETSI / TISPAN RACS and ITU- environments.
  • T RACF that allows the provision of QoS in a feasible way in multidomain environments and in the particular case of a residential gateway, the element responsible for managing the resources of the home network. It also includes the implementation of the interfaces between the QoS provision modules, the functionalities associated with them and the optimization in time of the negotiation between the different devices arranged in the different networks.
  • Another aspect of the invention is a computer program, which is stored in at least one support readable by a computer and comprising code means adapted to execute the described method, when said program is executed in a computer.
  • Figure 1. Shows multiple telecommunication networks in a multidomain environment.
  • Figure 2.- Shows the ITU-T NGN architecture.
  • Figure 3. Shows the ETSI / TISPAN NGN architecture.
  • Figure 4. Shows the interaction between domains when the source domain manages the source IP address.
  • Figure 5. Shows the interaction between domains when the source domain does not manage the source IP address.
  • Figure 6. Shows a simplified interaction diagram between two domains.
  • Figure 7. Shows a simplified interaction diagram between three domains.
  • FIG. 1 shows an example of a multidomain environment, which includes multiple telecommunication networks, in which the present invention can be implemented. Only the elements necessary to understand the present invention are shown.
  • the multidomain environment comprises several domains (which consist, for example, of New Generation Networks NGN networks), which generally, although not necessarily from different operators.
  • the figure shows the architecture of the NGN networks in two domains, domain A 100 and domain B 200, as well as the particular case of the residential gateway 400.
  • the NGN networks basically comprise the following three functions : 110,210 service plane functions, a device (also referred to as a module) for admission and control of resources in new generation networks 120,220 and functions of the 130,230 transport plane.
  • the admission and control module may be the RACS (Resource and Admission Control Sub-System, Resource Management and Admission Subsystem) of the ETSI / TISPAN architecture or the RACF (Resource and Admission Control Function, Resource Management and Admission Function ) of the ITU-T NGN architecture.
  • the interface 500 between admission modules and resource control is specified in a multi-domain environment (which is called the Ri interface in the ITU-T NGN and Ri 'architecture in the ETSI / TISPAN NGN architecture) and the interface 600 between the module for admission and control of resources and the residential gateway (Rpr interface), which is considered as an extension of the control plane.
  • Figures 2 and 3 detail the main functions and interfaces of the architectures defined in ITU-T and in ETSI / TISPAN.
  • the devices (modules) responsible for admission control and resource reservation are RACF 1200 (in the case of ITU-T NGN) and RACS 1210 (in the case of ETSI / TISPAN).
  • each of these modules consists of the following submodules:
  • the ITU-T PD-FE (Policy Decision Functional Entity) 1220 and the ETSI / TISPAN SPDF ⁇ Service-based Policy Decision Function) 1230 are the independent modules of the underlying technology and are responsible for providing a common interface to the service plane or application. They are also responsible for configuring all those computers that are common to different network technologies (such as edge routers, for example).
  • the ITU-T TRC-FE (Transport Resource Control Functional Entity) 1240 and the ETSI / TISPAN x-RACF (Generic Resource and Admission Control Function) 1250 are the modules dependent on the underlying network technology and are responsible for configuring the specific functions in the transport plane.
  • interfaces and functionalities such as those implemented by the ITU-T NACF Network Attachment Control Function) or ETSI / TISPAN NASS ⁇ Network Attachment Subsystem) module that is responsible for maintaining the user authorization information, maintaining information about its location, etc.
  • ITU-T NACF Network Attachment Control Function or ETSI / TISPAN NASS ⁇ Network Attachment Subsystem
  • the Ri / Ri '500 interface is the interface in charge of the synchronization of the admission control and resource reservation processes between several domains. Therefore, the following requirements are essential:
  • the interface must allow the SPDF of the initial domain to require the reservation and configuration of resources in the domains through which the session will take place.
  • the interface must allow interaction between the control planes of different operators without compromising their security and privacy. This implies that information regarding the intra-domain topology or mechanisms of each of the operators cannot be exchanged. Although this interface is identified in the standards, today there is no specification and / or implementation of it. In this description an implementation of the same is presented.
  • Resource & AdmisionControl request ⁇ 720 request for resources and admission control
  • 720 used to ask the next SPDF to reserve and configure the necessary resources.
  • Relay request ⁇ release request 800 used to release the allocated resources.
  • Modify request ⁇ modify request 760 to modify previously allocated resources
  • Resource & AdmissionControllnitiation request (request for initiation of resources and admission control) 830: this primitive is necessary to ask the final domain to begin the reservation of resources. It is used when resources have to be reserved in the initial domain for a flow whose source IP does not belong to the domain. This primitive is necessary if the transit domains are not the same in one direction and another of the communication. This function is optional but necessary to manage inter-domain links of transit domains.
  • Releaselnititiation request requests the domain that manages the source IP of the flow to release resources. This function is optional but necessary to manage inter-domain links of transit domains.
  • Modifylnititation request request the domain that manages the IP Origin of the flow Ia modification of the reserved resources. This function is optional but necessary to manage inter-domain links of transit domains.
  • Resource & Admision Control response (resource response and admission control) 730: the destination domain informs about the result of its admission operation and resource configuration.
  • Relay response (release response) 810 response to the request for release of resources.
  • Modify response (modification response) 770 response to the request to modify previously allocated resources
  • Resource & AdmissionControllnitiation response 840 response to the request Resource & AdmissionControllnitiation request. This function is optional but necessary to manage inter-domain links of transit domains.
  • Releaselnititiation response response to the Releaselnitiation request.
  • This function is optional but necessary to manage inter-domain links of transit domains.
  • Modifylnititation response response to the Modifylnitiation request. This function is optional but necessary to manage inter-domain links of transit domains.
  • - Service Class information of the kind of service required.
  • - Flow (s) description information on the flows (connections) (source IP, destination IP, source and / or destination ports and protocol)
  • Figures 4-5 show the negotiation sequence in two different scenarios.
  • Figure 4 shows the use of these primitives in a scenario in which they are reserved (use of the Resource & Admision Control request and Resource & Admision Control responsive primitives), modify (use of the Modify request and Modify response primitives) and release resources (use of the Relay primitives request and Relay response) for a connection with a third domain 300, taking into account the requests received by the admission and resource control module 120 of the first domain 100 of the functions of the service plane 110.
  • module 120 receives a Resourcelnitiation Request 710 from service plane 110, it reserves and configures the necessary resources for the connection and sends a Resource & Admission Control request 720 to the admission and resource control module 220 of the second domain 200. It also reserves and configures the necessary resources and sends the Resource & Admission Control Request 720 to the admission and control module 320 of the third domain 300. This module also reserves and configures the necessary resources and being the admission and control module of the last domain 300 in the chain , sends a Resource & Admission Control response 730 response to the admission and resource control module 220 of the second domain 200, which passes to the admission and resource control module 120 of the first domain 100. This module sends a Resourcelnitation Response 740 response to the service plane 110.
  • module 120 receives a ResourceModification Request 750 from the service plane 110, it modifies the resources necessary for the connection and sends a Modil and request 760 to the admission and resource control module 220 of the second domain 200. It also modifies the necessary resources and sends the Modify request 760 to the admission and resource control module 320 of the third domain 300. This module also modifies the necessary resources and being the admission and control module of the last domain 300 in the chain, sends a Modify response response 770 to the admission and resource control module 220 of the second domain 200, which passes to the admission and resource control module 120 of the first domain 100. This module sends a ResourceModification Response 780 response to the service plane 110.
  • the module 120 receives a ResourceRelease Request 790 from the service plane 110, it releases the resources of the connection and sends a Relay request 800 to the admission and resource control module 220 of the second domain 200. It also releases the resources and sends the Relay request 800 to the admission and resource control module 320 of the third domain 300. This module also releases the resources and being the admission and resource control module of the last domain 300 in the chain, sends a Relay response 810 response to the module of admission and control of resources 220 of the second domain 200, which passes to the module of admission and control of resources 120 of the first domain 100. This module sends a ResourceRelease Response 820 response to the service plane 110.
  • Figure 5 shows the use of the primitives previously qualified as optional that allow the domain that manages the source IP to manage the reserve of resources associated with said connection and send the result of this operation to the domain that received the application plane request.
  • This functionality is optional and would be required when the traffic domains are different in one direction and another from the communication.
  • the Resource & AdmissionControllnitiation request / response primitives are used,
  • the module 120 of the first domain 100 receives a Resourcelnitiation Request 710 from the service plane 1 10 and does not manage the source IP address of the connection, it sends a Resource & AdmissionControllnitiation request 830 to the resource admission and control module 220 of the second domain 200.
  • the situation that the first domain does not manage the originating IP address of the connection occurs for example in the following case: different flows (different connections) may be required for the same application, from the client to the server and from the server to the client. Only one domain requests from the service part reserve for all these flows, and therefore it may be necessary to contemplate this case.
  • the second domain 200 passes the request 830 to the module for admission and control of resources 320 of the third domain 300.
  • the procedure for reserving and configuring the necessary resources begins previously described with reference to Figure 4, sending a ResourceAdmission Control Request 720 to the admission and resource control module 220 of the second domain 200.
  • This procedure ends with the sending of a Resource Admission Control response of the admission and control module of resources. 220 of the second domain 200 to the admission and resource control module 320 of the third domain 300. It sends a Resource & AdmissionControllnitiation response 840 to the admission and resource control module 220 of the second domain 200, which passes it to the admission and control module of resources 120 of the first domain 100.
  • This module sends a Resourcelnitation Response 740 response the service plan 1 10.
  • the BGP ⁇ Border Gateway Protocol routing information available in all domains (either on the edge routers or in the route reflectors), is used, in order to find the next path domain (available for each destination IP in the AS Path field or path of autonomous systems or domains).
  • This information is combined with a DNS-based resolution (Domain ⁇ ame System) to obtain the pointer (address of the system in charge of managing resources in the next domain) to which to send requests for a given domain.
  • the SPDF applies an admission control algorithm, that is, computes a mathematical function or evaluates the user's profile and resource configuration, in which SPDF 1230 interacts with the x-RACF 1250, module dependent on the underlying network technology, so that it configures the transport plane resources
  • the interaction between domains is based on two phases to parallelize the configuration of resources in the different domains.
  • the process of configuring resources in the transport plane is the most expensive in time, of the order of hundreds of milliseconds to even seconds, depending on the underlying technology.
  • the reserve of resources through the application of an admission control algorithm is of the order of 1 -10 milliseconds. Therefore, a solution that sequences the resource configuration processes in all traversed domains would introduce high response latencies to the end user.
  • Figure 6 shows in a simplified way the paralysis of the configuration when there are two domains involved.
  • the arrival of a new request Resourcelnitiation Request 710 in the admission and control module of the initial domain triggers the following processes:
  • Process 900 The admission and control module 120 of the initial domain 100 checks the type of request and applies an admission control algorithm (resource reservation) to verify that new resources can be admitted after consulting the NACF or NASS. Once the connection is admitted, a request for admission and resource control (Resource & AdmissionControl request) 720 is sent to the next domain 200 and the process is carried out 910.
  • the operations to be carried out in 900 require 1 ms to 10ms and are performed by sub-module SPDF 1230.
  • Process 910 The admission and control module of the initial domain 120 proceeds to the configuration of the functions of the transport layer, launching the actions of the x-RACF 1250 that interacts with the transport plane, to effectively apply the necessary policies that guarantee The desired quality. This operation requires the order of 100ms to 1 s.
  • Process 920 The admission and control module 220 of the second and last domain 200 receives the request 720 (Resource & Admission Control request). During the period 920, this module checks if there are resources available in the network in this case it proceeds to processes 930. This operation is similar to that described in 900 and therefore requires 1 ms to 10ms and is performed by the SPDF of the second domain 200.
  • Process 930 The last domain proceeds to the configuration of the transport plane. Once this task has been successfully completed, it sends a 730 response to the request for resources made by the previous domain (Resource & AdmissionControl response). The configuration process takes from the order of 100ms to 1 s.
  • Figure 7 shows a variant of Figure 6 in which the modules interact admission and control of resources from three domains.
  • the resource admission and control module 1020 of the transit domain 1000 has verified the availability of resources 940, it forwards the request 720 to the last domain 200. Then, proceed to the 950 configuration of the transport plane.
  • the 910,930,950 configuration processes are parallelized, avoiding that the largest component of the response time to the QoS request depends linearly on the number of domains involved, thus reducing the time of establishment of a guaranteed QoS connection.
  • the proposed solution allows a telecommunication network operator the provision of services with guaranteed service qualities in a multi-domain environment. For this, the coordination of the mechanisms available in each of the domains must be guaranteed in order to guarantee the provision of end-to-end QoS in the communications that pass through the networks.
  • the invention can be implemented with networks of Telecommunications that operate according to standards other than the NGN standard disclosed in this description.
  • a computer program may be stored / distributed on a suitable medium, such as an optical storage medium or a solid state medium supplied together with or as part of other hardware, although it may also be distributed in other ways, such as via the Internet or other cable or wireless telecommunication systems. No reference symbol in the claims should be construed as limiting the scope.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Selective Calling Equipment (AREA)
  • Coating With Molten Metal (AREA)
  • Radio Relay Systems (AREA)

Abstract

Dispositivos y método para la admisión y control de recursos en entornos multidominio, particularmente en Redes de Nueva Generación. Un dispositivo (120) en el plano de control de un primer dominio (100) está configurado, en el caso de recibir una petición desde el plano de servicio (110) para establecer, modificar o liberar una conexión, para enviar una de las siguientes peticiones a otro dispositivo (220) en un segundo dominio (200) y de este modo aprovisionar calidad de servicio garantizada en entornos multidominio: - una petición de un primer tipo (720) para que el otro dispositivo (220) reserve y configure los recursos necesarios; - una petición de un segundo tipo (800) para que el otro dispositivo (220) libere recursos asignados previamente; y - una petición de un tercer tipo para que el otro dispositivo (220) modifique (760) los recursos asignados previamente.

Description

DISPOSITIVOS Y MÉTODO PARA LA ADMISIÓN Y CONTROL DE RECURSOS EN ENTORNOS MULTIDOMINIO
D E S C R I P C I Ó N
CAMPO TÉCNICO DE LA INVENCIÓN
La presente invención se refiere, en general, a Ia gestión de recursos para asegurar Ia calidad de servicio en redes de telecomunicación y más particularmente a Ia gestión de recursos en Redes de Nueva Generación.
ANTECEDENTES DE LA INVENCIÓN
En Ia actualidad existen grupos de trabajo en Ia ITU-T (International Telecommunications Union - Standardisation) y ETSI/TISPAN (European Telecommunications Standards Institute/Telecommunications and Internet converged Services and Protocols for Advanced Networking) cuyo trabajo se centra en Ia definición de estándares en el campo de las Redes de Nueva Generación (NGN, Next Generation Networks). El desarrollo de Ia red de nueva generación tiene tres objetivos fundamentales:
- Proveer un mejor acceso, en términos de ancho de banda y parámetros de prestaciones de red (QoS, Quality of Service Calidad de Servicio).
- Capacitar a Ia red para transportar de forma eficiente distintos servicios, con distintos requisitos de red.
- Integrar distintos tipos de redes y sus servicios. P. e., integración fijo- móvil, integración de servicios entre distintos operadores, etc.
En este contexto, donde Ia provisión de QoS es reconocida como uno de los objetivos a cubrir en las redes de nueva generación así como Ia provisión de los nuevos servicios en entornos con múltiples redes, Ia capacidad de proporcionar QoS en entornos multidominio es necesaria para proporcionar servicios con QoS garantizada sobre las redes actuales.
Si bien el trabajo realizado en los grupos de trabajo en Ia ITU-T y ETSI/TISPAN es extenso y es tomado como referencia en el desarrollo de equipos comerciales, existen trabajos inconclusos como, por ejemplo, en el campo de Ia provisión de QoS en entornos multidominio y/o multioperador.
En el artículo "Bridging the standardization gap to provide QoS in current NGN architectures" de Ia publicación IEEE Communications Magazine, special issue on "ITU-T International Standards in Information and Communications Technologies" (Octubre de 2008) se hace un análisis exhaustivo de los problemas actuales de las arquitecturas de redes de nueva generación que impiden el despliegue de QoS garantizada. En particular, se identifica como un claro inconveniente Ia mala especificación de las interfaces entre los distintos sistemas de gestión o su no especificación Io cual hace inviable Ia coordinación efectiva de los distintos sistemas que componen una red NGN. Este hecho es un claro problema técnico en Ia provisión de servicios avanzados que requieran Ia sincronización de los procesos de distintos sistemas. Es preferible no depender de implementaciones dependientes de fabricante que, bien pondrían en peligro Ia cooperación entre dominios, o bien no interesaría a las operadoras, al quedar cautivas de un proveedor específico.
En concreto, con el fin de proveer QoS extremo a extremo en entornos multidominio (es decir, atravesando dos ó más redes, posiblemente de distintos operadores), sería necesaria Ia especificación y estandarización de interfaces en los planos de control (conjunto de sistemas encargados de gestionar los recursos físicos de una red NGN) de las distintas redes con el fin de coordinar los mecanismos de calidad de servicio disponibles en cada uno de los dominios.
No se debe confundir esta interfaz interdominio con Ia interfaz que podrían tener dos ETSI/TISPAN RACSs (Resource and Admission Control Sub-System, Subsistema de gestión de recursos y admisión) o ITU- T RACFs (Resource and Admission Control Functions, Funciones de gestión de recursos y admisión) desplegados en un mismo dominio con el fin de proporcionar soluciones de QoS intradominio en redes extensas, como podría ser Ia red de Telefónica de España.
En Ia actualidad, tanto Ia ITU-T como ETSI/TISPAN han identificado Ia necesidad de definir una interfaz interdominio entre los módulos encargados de gestionar los recursos (interfaz Ri) e incluso han provisto una serie de requisitos para Ia misma. Ahora bien, dicha interfaz no está estandarizada en términos de primitivas y atributos por ninguno de los dos organismos de estandarización. Por ello, Ia solución técnica a Ia provisión de QoS extremo a extremo en entornos multidominio no está disponible a día de hoy ni en estándares y, por tanto, tampoco en productos comerciales.
Por otro lado, con el fin de proveer QoS garantizada al usuario final, también sería necesario coordinar los mecanismos de QoS disponibles en Ia red del hogar con el fin de asegurar Ia QoS al usuario final. A día de hoy, el RACS o el RACF no se coordinan con el CPE (Customer Premise Equipment, Equipo Local del Cliente), ya que dicha interfaz se ha dejado para futuros estudios, con Io cual no existe ninguna solución que permita Ia coordinación entre el plano de control del operador de red y los mecanismos disponibles en Ia red del usuario.
Por consiguiente, a día de hoy, Ia provisión de QoS garantizada extremo a extremo no es técnicamente viable, puesto que no existen procedimientos que permitan coordinar los mecanismos de QoS de un operador con los de otros operadores o con Ia red del hogar.
En Ia actualidad, también se están estudiando Ia implementación de soluciones de QoS extremo a extremo haciendo uso de las funcionalidades disponibles en el plano de servicio o de aplicación. En concreto, se está estudiando Ia provisión de QoS extremo a extremo haciendo uso del núcleo de IMS [IP Multimedia Subsystem, Subsistema Multimedia IP) para coordinar Ia configuración de recursos en las redes de acceso. El mayor inconveniente de esta aproximación es que sería imprescindible el uso del protocolo SIP (Session Initiation Protocol, Protocolo de Inicio de Sesiones) en el nivel de aplicación, es decir, no sólo en los servidores del operador sino también en las aplicaciones del cliente; Io cual sería una limitación de Ia solución, ya que no podría ser utilizada en Ia provisión de servicios con QoS garantizada cuya señalización no esté basada en SIP. En caso de desarrollar una nueva aplicación/servicio que requiriese unas prestaciones específicas de red en un entorno multidominio y que no pudiese usar SIP, el administrador de red tendría que volver a definir e implementar las interacciones entre los servidores interdominio.
DESCRIPCIÓN DE LA INVENCIÓN
Es un objetivo de Ia invención proporcionar un procedimiento y su sistema de comunicación correspondiente mediante los que se solucionen los problemas anteriormente mencionados al menos en parte.
Para ello, según Ia invención se proporcionan dispositivos y un método según las reivindicaciones independientes. Realizaciones favorables se definen en las reivindicaciones dependientes.
Según un aspecto de Ia invención se proponen dispositivos y un método que extienden las capacidades del plano de control de una red de telecomunicación, tal y como Ia red NGN, permitiendo Ia negociación con otras redes del mismo tipo Ia reserva y configuración de recursos de red para aprovisionar QoS garantizada en entornos multidominio que también contemplan Ia red del hogar del usuario final. Este plano de control podrá ser utilizado por cualquier plano de servicio o de aplicación, incluyendo el propio IMS o cualquier otra plataforma de servicios del operador de red. Esto permite a los operadores de redes convergentes Ia utilización de este plano de control con cualquiera de sus plataformas de servicios.
Preferentemente, se implementa Ia presente invención en los módulos de provisión de QoS en entornos NGN ETSI/TISPAN RACS e ITU- T RACF que permite Ia provisión de QoS de forma factible en entornos multidominio y en el caso particular de una pasarela residencial, el elemento encargado de Ia gestión de los recursos de Ia red del hogar. Incluye también Ia implementación de las interfaces entre los módulos de provisión de QoS, las funcionalidades asociadas a las mismas y Ia optimización en tiempo de Ia negociación entre los distintos dispositivos dispuestos en las distintas redes.
Otro aspecto de Ia invención es un programa de ordenador, que se almacena en al menos un soporte legible por un ordenador y que comprende medios de código adaptados para ejecutar el método descrito, cuando dicho programa se ejecuta en un ordenador.
DESCRIPCIÓN DE LOS DIBUJOS
La invención se entenderá mejor y sus numerosos objetivos y ventajas resultarán más evidentes para los expertos en Ia técnica en referencia a los siguientes dibujos, junto con Ia memoria descriptiva que los acompaña, en los que:
La Figura 1.- Muestra múltiples redes de telecomunicación en un entorno multidominio.
La Figura 2.- Muestra Ia arquitectura ITU-T NGN.
La Figura 3.- Muestra Ia arquitectura ETSI/TISPAN NGN.
La Figura 4.- Muestra Ia interacción entre dominios cuando el dominio origen gestiona Ia dirección IP origen.
La Figura 5.- Muestra Ia interacción entre dominios cuando el dominio origen no gestiona Ia dirección IP origen.
La Figura 6.- Muestra un diagrama de interacción simplificado entre dos dominios.
La Figura 7.- Muestra un diagrama de interacción simplificado entre tres dominios.
En todas las figuras los mismos números de referencia se refieren a elementos iguales.
REALIZACIONES PREFERENTES DE LA INVENCIÓN
A Ia vista de las figuras reseñadas, puede describirse aquí una realización práctica de Ia invención. La figura 1 muestra un ejemplo de un entorno multidominio, que incluye múltiples redes de telecomunicación, en el que puede implementarse Ia presente invención. Sólo se muestran los elementos necesarios para entender Ia presente invención. El entorno multidominio comprende varios dominios (que consisten por ejemplo de Redes de Nueva Generación redes NGN), que generalmente, aunque no necesariamente son de distintos operadores. La figura muestra Ia arquitectura de las redes NGN en dos dominios, dominio A 100 y dominio B 200, así como el caso particular de Ia pasarela residencial 400. Tal y como se resalta en Ia figura, las redes NGN comprenden básicamente las siguientes tres funciones: funciones de plano de servicio 110,210, un dispositivo (también se hace referencia a él como módulo) de admisión y control de recursos en redes de nueva generación 120,220 y funciones del plano de transporte 130,230. El módulo de admisión y control puede ser el RACS (Resource and Admission Control Sub-System, Subsistema de gestión de recursos y admisión) de Ia arquitectura ETSI/TISPAN o el RACF (Resource and Admission Control Function, Función de gestión de recursos y admisión) de Ia arquitectura ITU-T NGN. Según Ia presente invención se especifican Ia interfaz 500 entre módulos de admisión y control de recursos en un entorno multidominio (que se llama interfaz Ri en Ia arquitectura ITU-T NGN y Ri' en Ia arquitectura ETSI/TISPAN NGN) y Ia interfaz 600 entre el módulo de admisión y control de recursos y Ia pasarela residencial (interfaz Rpr), que es considerada como una extensión del plano de control.
La implementación del nuevo procedimiento para el módulo de admisión y control de recursos para Redes de Nueva Generación en entornos multidominio ha requerido el desarrollo de los siguientes puntos: - Implementación de Ia interfaz Ri/Ri' para Ia interacción interdominio de los módulos de control de Ia red NGN (que podrían ser los ETSI/TISPAN RACSs o los ITU-T NGN RACFs) y de Ia nueva interfaz Rpr para Ia interacción del módulo con Ia pasarela residencial. Estas interfaces se muestran en Ia figura 1. Con el fin de facilitar Ia compresión de esta figura, se han obviado algunas funciones disponibles en las redes NGN y sólo se muestran las interfaces implementar en el nuevo método propuesto.
- Implementación de Ia secuencia de mensajes y acciones de los módulos implicados en Ia negociación de recursos de red extremo a extremo.
- Particularización de Ia interacción interdominio para el caso de Ia red del hogar.
El desarrollo de estos tres puntos constituye Ia implementación del nuevo método que extiende las capacidades del Plano de Control de Ia red NGN de modo que se puede proporcionar QoS garantizada en entornos multidominio, que contemplan tanto entornos multioperador como entornos en los que se incluye Ia red del hogar.
Las figuras 2 y 3 detallan las funciones e interfaces principales de las arquitecturas definidas en Ia ITU-T y en ETSI/TISPAN.
En Ia actualidad, los dispositivos (módulos) encargados del control de admisión y de Ia reserva de recursos son el RACF 1200 (en el caso de ITU-T NGN) y el RACS 1210 (en el caso de ETSI/TISPAN). A su vez, cada uno de estos módulos se compone de los siguientes submódulos:
- El ITU-T PD-FE (Policy Decisión Functional Entity) 1220 y el ETSI/TISPAN SPDF {Service-based Policy Decisión Function) 1230 son los módulos independientes de Ia tecnología subyacente y encargados de proporcionar una interfaz común al plano de servicio o aplicación. También son los responsables de configurar todos aquellos equipos que sean comunes a distintas tecnologías de red (como, por ejemplo, los routers de borde). - El ITU-T TRC-FE (Transport Resource Control Functional Entity) 1240 y el ETSI/TISPAN x-RACF (Generic Resource and Admission Control Function) 1250 son los módulos dependientes de Ia tecnología de red subyacente y son los responsables de configurar las funciones específicas en el plano de transporte.
También se muestran en las figuras algunas interfaces y funcionalidades tales como las implementadas por el módulo ITU-T NACF Network Attachment Control Function) o ETSI/TISPAN NASS {Network Attachment Subsystem) que se encarga de mantener Ia información de Ia autorización del usuario, mantener información sobre su localización, etc. Sin embargo, como estas interfaces y funcionalidades no son objeto de Ia presente invención no se explican en detalle.
El presente documento describe un nuevo método que se implementa en los módulos independientes de Ia tecnología de red, es decir, en el ITU-T PD-FE ó ETSI/TIPAN SPDF. Tal y como se aprecia en las figuras éstos son los módulos responsables de Ia interfaz interdominio 500 (Ri y Ri', respectivamente), cuya implementación se describe a continuación. Por simplicidad, a partir de ahora cuando se mencione cualquier modificación del SPDF, esta misma modificación es aplicable al PD-FE.
Tal y como se comenta previamente, Ia interfaz Ri/Ri' 500 es Ia interfaz encargada de Ia sincronización de los procesos de control de admisión y reserva de recursos entre varios dominios. Por Io tanto, los siguientes requisitos son imprescindibles:
- La interfaz debe permitir al SPDF del dominio inicial requerir Ia reserva y configuración de recursos en los dominios por los que va a transcurrir Ia sesión.
- Dada su naturaleza interdominio, Ia interfaz debe permitir Ia interacción entre los planos de control de distintos operadores sin comprometer Ia seguridad y privacidad de los mismos. Esto implica, que información relativa a Ia topología intradominio o a mecanismos de cada uno de los operadores no puede ser intercambiada. Si bien esta interfaz está identificada en los estándares, a día de hoy no existe una especificación y/o implementación de Ia misma. En esta descripción se presenta una implementación de Ia misma.
Puesto que al SPDF pueden llegar peticiones para Ia reserva de flujos unidireccionales o bidireccionales, las siguientes transacciones son implementadas, de que las figuras 4-7 muestran algunas:
Requests (peticiones) utilizadas para desencadenar acciones en otro SPDF:
- Una petición de un primer tipo, Resource&AdmisionControl request {petición de recursos y control de admisión) 720: utilizada para pedir al siguiente SPDF que reserve y configure los recursos necesarios.
- Una petición de un segundo tipo, Reléase request {petición de liberación) 800: utilizada para liberar los recursos asignados.
- Una petición de un tercer tipo, Modify request {petición de modificaή 760: para modificar los recursos asignados previamente
- Una petición de un cuarto tipo, Resource&AdmissionControllnitiation request {petición de iniciación de recursos y control de admisión) 830: esta primitiva es necesaria para pedir al dominio final que comience Ia reserva de recursos. Es utilizada cuando en el dominio inicial se tienen que reservar recursos para un flujo cuya IP origen no pertenece al dominio. Esta primitiva es necesaria si los dominios de tránsito no son los mismos en un sentido y otro de Ia comunicación. Esta función es opcional aunque necesaria para gestionar los enlaces interdominio de los dominios de tránsito.
- Una petición de un quinto tipo, Releaselnititiation request {petición de iniciación de liberación): solicita al dominio que gestiona Ia IP origen del flujo Ia liberación de recursos. Esta función es opcional aunque necesaria para gestionar los enlaces interdominio de los dominios de tránsito.
- Una petición de un sexto tipo, Modifylnititation request {petición de iniciación de modificación): solicita al dominio que gestiona Ia IP origen del flujo Ia modificación de los recursos reservados. Esta función es opcional aunque necesaria para gestionar los enlaces interdominio de los dominios de tránsito.
Responses (respuestas) utilizadas para informar de los resultados del
SPDF:
- Una respuesta de un primer tipo, Resource&AdmisionControl response (respuesta de recursos y control de admisión) 730: el dominio destino informa sobre el resultado de su operación de admisión y configuración de recursos.
- Una respuesta de un segundo tipo, Reléase response (respuesta de liberación) 810: respuesta a Ia petición de liberación de recursos.
- Una respuesta de un tercer tipo, Modify response (respuesta de modificación) 770: respuesta a Ia petición de modificar los recursos asignados previamente
- Una respuesta de un cuarto tipo, Resource&AdmissionControllnitiation response (respuesta de iniciación de recursos y control de admisión) 840: respuesta a Ia petición Resource&AdmissionControllnitiation request. Esta función es opcional aunque necesaria para gestionar los enlaces interdominio de los dominios de tránsito.
- Una respuesta de un quinto tipo, Releaselnititiation response (respuesta de iniciación de liberación): respuesta a Ia petición Releaselnitiation request. Esta función es opcional aunque necesaria para gestionar los enlaces interdominio de los dominios de tránsito.
- Una respuesta de un sexto tipo, Modifylnititation response (respuesta de iniciación de modificación): respuesta a Ia petición Modifylnitiation request. Esta función es opcional aunque necesaria para gestionar los enlaces interdominio de los dominios de tránsito.
La información intercambiada en estas interfaces contendrá los siguientes campos:
- Service Class: información de Ia clase de servicio requerida. - Flow(s) description: información de los flujos (conexiones) (IP origen, IP destino, puertos origen y/o destino y protocolo)
- Bandwidth: ancho de banda requerido para cada flujo (conexión).
- Punto de entrada en el dominio: obtenido de Ia del campo next_hop de Ia tabla de routing BGP (Border Gateway Protocol). Esto permite al dominio receptor de Ia petición saber cuál es el punto de entrada del tráfico.
Las figuras 4-5 muestran Ia secuencia de negociación en dos escenarios distintos. La figura 4 muestra el uso de estas primitivas en un escenario en el que se reservan (uso de las primitivas Resource&AdmisionControl request y Resource&AdmisionControl responsé), modifican (uso de las primitivas Modify request y Modify response) y liberan recursos (uso de las primitivas Reléase request y Reléase response) para una conexión con un tercer dominio 300, teniendo en cuenta las peticiones recibidas por el módulo de admisión y control de recursos 120 del primer dominio 100 de las funciones del plano de servicio 110.
Si el módulo 120 recibe una Resourcelnitiation Request 710 desde el plano de servicio 110, reserva y configura los recursos necesarios para Ia conexión y envía una Resource&AdmisionControl request 720 al módulo de admisión y control de recursos 220 del segundo dominio 200. Éste también reserva y configura los recursos necesarios y envía Ia Resource&AdmisionControl request 720 al módulo de admisión y control de recursos 320 del tercer dominio 300. Este módulo también reserva y configura los recursos necesarios y al ser el módulo de admisión y control de recursos del último dominio 300 en Ia cadena, envía una respuesta Resource&AdmisionControl response 730 al módulo de admisión y control de recursos 220 del segundo dominio 200, que Ia pasa al módulo de admisión y control de recursos 120 del primer dominio 100. Este módulo envía una respuesta Resourcelnitation Response 740 el plano de servicio 110. Si el módulo 120 recibe una ResourceModification Request 750 desde el plano de servicio 110, modifica los recursos necesarios para Ia conexión y envía una Modil y request 760 al módulo de admisión y control de recursos 220 del segundo dominio 200. Éste también modifica los recursos necesarios y envía Ia Modify request 760 al módulo de admisión y control de recursos 320 del tercer dominio 300. Este módulo también modifica los recursos necesarios y al ser el módulo de admisión y control de recursos del último dominio 300 en Ia cadena, envía una respuesta Modify response 770 al módulo de admisión y control de recursos 220 del segundo dominio 200, que Ia pasa al módulo de admisión y control de recursos 120 del primer dominio 100. Este módulo envía una respuesta ResourceModification Response 780 el plano de servicio 110.
Si el módulo 120 recibe una ResourceRelease Request 790 desde el plano de servicio 110, libera los recursos de Ia conexión y envía una Reléase request 800 al módulo de admisión y control de recursos 220 del segundo dominio 200. Éste también libera los recursos y envía Ia Reléase request 800 al módulo de admisión y control de recursos 320 del tercer dominio 300. Este módulo también libera los recursos y al ser el módulo de admisión y control de recursos del último dominio 300 en Ia cadena, envía una respuesta Reléase response 810 al módulo de admisión y control de recursos 220 del segundo dominio 200, que Ia pasa al módulo de admisión y control de recursos 120 del primer dominio 100. Este módulo envía una respuesta ResourceRelease Response 820 el plano de servicio 110.
La Figura 5 muestra el uso de las primitivas calificadas anteriormente como opcionales que permiten al dominio que gestiona Ia IP origen gestionar Ia reserva de recursos asociada a dicha conexión y enviar el resultado de esta operación al dominio que recibió Ia petición del plano de aplicación. Esta funcionalidad es opcional y sería requerida cuando los dominios de tránsito sean distintos en un sentido y otro de Ia comunicación. Tal y como se ve en esta figura, cuando un dominio recibe una petición para reservar, modificar o liberar recursos de una conexión cuya dirección IP origen no es gestionada por este dominio, se hace uso de las primitivas Resource&AdmissionControllnitiation request/response,
Releaselnititation request/response y Releaselnititation request/response, respectivamente.
Si el módulo 120 del primer dominio 100 recibe una Resourcelnitiation Request 710 desde el plano de servicio 1 10 y no gestiona Ia dirección IP origen de Ia conexión, envía una Resource&AdmisionControllnitiation request 830 al módulo de admisión y control de recursos 220 del segundo dominio 200. La situación que el primer dominio no gestiona Ia dirección IP origen de Ia conexión ocurre por ejemplo en el siguiente caso: para una misma aplicación se pueden necesitar distintos flujos (distintas conexiones), desde el cliente al servidor y desde el servidor al cliente. Sólo un dominio pide desde Ia parte de servicio reserva para todos esos flujos, y por tanto puede ser necesario contemplar este caso. El segundo dominio 200 pasa Ia petición 830 al módulo de admisión y control de recursos 320 del tercer dominio 300. En vista de que es este dominio el que gestiona Ia dirección IP origen de Ia conexión, comienza el procedimiento para reservar y configurar los recursos necesarios anteriormente descrito con referencia a Ia figura 4, enviando una ResourceAdmission Control Request 720 al módulo de admisión y control de recursos 220 del segundo dominio 200. Este procedimiento se acaba con el envío de una Resource Admission Control response del módulo de admisión y control de recursos 220 del segundo dominio 200 al módulo de admisión y control de recursos 320 del tercer dominio 300. Éste envía una respuesta Resource&AdmissionControllnitiation response 840 al módulo de admisión y control de recursos 220 del segundo dominio 200, que Ia pasa al módulo de admisión y control de recursos 120 del primer dominio 100. Este módulo envía una respuesta Resourcelnitation Response 740 el plano de servicio 1 10. En estas interacciones es muy importante saber el criterio para seleccionar el dominio al cual enviar Ia petición. Para ello, se usa Ia información de encaminamiento BGP {Border Gateway Protocol), disponibles en todos los dominios (ya sea en los routers de borde o en los reflectores de rutas), con el fin de encontrar el siguiente dominio del camino (disponible para cada IP destino en el campo AS Path o camino de sistemas autónomos o dominios). Esta información se combina con una resolución basada en DNS (Domain Ñame System) para obtener el puntero (dirección del sistema encargado de gestionar los recursos en el siguiente dominio) al que enviar las peticiones para un dominio determinado.
Uno de los logros más importantes del nuevo método objeto de esta solicitud de patente es Ia implementación de un proceso de reserva y configuración de recursos que permite Ia minimización del tiempo de respuesta a Ia petición de QoS extremo a extremo.
Con el fin de optimizar el proceso de reserva, en el que el SPDF aplica un algoritmo de control de admisión, es decir, computa una función matemática o evalúa el perfil del usuario y configuración de recursos, en el que el SPDF 1230 interacciona con el x-RACF 1250, módulo dependiente de Ia tecnología de red subyacente, para que éste configure los recursos del plano de transporte, Ia interacción entre dominios está basada en dos fases para paralelizar Ia configuración de recursos en los distintos dominios. El proceso de configurar los recursos en el plano del transporte es el más costoso en tiempo, del orden de cientos de milisegundos a incluso segundos, dependiendo de Ia tecnología subyacente. La reserva de recursos mediante Ia aplicación de un algoritmo de control de admisión es del orden de 1 -10 milisegundos. Por tanto, una solución que secuencie los procesos de configuración de recursos en todos los dominios atravesados introduciría altas latencias de respuesta al usuario final.
En Ia figura 6 se muestra de forma simplificada Ia paralización de Ia configuración cuando hay dos dominios implicados. Tal y como muestra Ia figura, Ia llegada de una nueva petición Resourcelnitiation Request 710 en el módulo de admisión y control del dominio inicial desencadena los siguientes procesos:
Proceso 900: El módulo de admisión y control 120 del dominio inicial 100 comprueba el tipo de petición y aplica un algoritmo de control de admisión (reserva de recursos) para comprobar que se pueden admitir nuevos recursos tras realizar una consulta al NACF o NASS. Una vez admitida Ia conexión, se envía una petición de control de admisión y de recursos (Resource&AdmissionControl request) 720 al siguiente dominio 200 y se pasa a realizar el proceso 910. Las operaciones a realizar en 900 requieren de 1 ms a 10ms y son realizadas por el sub-módulo SPDF 1230.
Proceso 910: El módulo de admisión y control del dominio inicial 120 procede a Ia configuración de las funciones de Ia capa de transporte, lanzándose las acciones del x-RACF 1250 que interacciona con el plano de transporte, para efectivamente aplicar las políticas necesarias que garanticen Ia calidad deseada. Esta operación requiere del orden de 100ms a 1 s.
Proceso 920: El módulo de admisión y control 220 del segundo y último dominio 200 recibe Ia petición 720 (Resource&AdmissionControl request). Durante el periodo 920, este módulo comprueba si hay recursos disponibles en Ia red en tal caso procede a los procesos 930. Esta operación es similar a Ia descrita en 900 y por tanto requiere de 1 ms a 10ms y es realizada por el SPDF del segundo dominio 200.
Proceso 930: El último dominio procede a Ia configuración del plano de transporte. Una vez que ha finalizado exitosamente dicha tarea, envía una respuesta 730 a Ia petición de recursos realizada por el dominio anterior (Resource&AdmissionControl response). El proceso de configuración lleva del orden de 100ms a 1 s.
Tal y como se ha comentado previamente, con este procedimiento se consigue paralelizar Ia configuración de recursos en los dos dominios. Para mostrar el efecto positivo de esta solución Ia figura 7 muestra una variante de Ia figura 6 en Ia que interaccionan los módulos de admisión y control de recursos de tres dominios. En el diagrama de secuencias de Ia figura 7, tal y como se muestra una vez que el módulo de admisión y control de recursos 1020 del dominio de transito 1000 ha verificado Ia disponibilidad de recursos 940, éste reenvía Ia petición 720 al último dominio 200. Luego, procede a Ia configuración 950 del plano de transporte. En esta ocasión vemos que con el procedimiento se paralelizan los procesos de configuración 910,930,950 evitando que el mayor componente del tiempo de respuesta a Ia petición de QoS dependa linealmente del número de dominios implicados, reduciendo así el tiempo de establecimiento de una conexión con QoS garantizada.
Finalmente, se implementa una nueva interfaz entre Ia pasarela residencial 400 y el RACF 1200 o el RACS 1210 que estará basada en Io anteriormente descrito (se mantienen las primitivas y el procedimiento descrito anteriormente). De este modo, Ia coordinación de los mecanismos de provisión de QoS en Ia red del hogar con los propios de Ia red del operador, es contemplado como un caso particular de interacción entre dos dominios en el que el único cambio es que en Ia información intercambiada, el punto de entrada en el dominio es omitido y se tiene en cuenta el punto de acceso a Ia red o primer nodo IP en Ia misma (ej, el BRAS en una red xDSL).
La solución propuesta permite a un operador de redes de telecomunicación Ia provisión de servicios con calidades de servicio garantizadas en un entorno multidominio. Para ello hay que garantizar Ia coordinación de los mecanismos disponibles en cada uno de los dominios con el fin de garantizar Ia provisión de QoS extremo a extremo en las comunicaciones que transcurran a través de las redes.
Aunque Ia invención se ha ilustrado y descrito en detalle en los dibujos y en Ia descripción anterior, tal ilustración y descripción han de considerarse ilustrativas o ejemplares y no restrictivas; Ia invención no está limitada a las realizaciones dadas a conocer.
Por supuesto, Ia invención puede implementarse con redes de telecomunicación que funcionen según normas diferentes a Ia norma NGN dada a conocer en Ia presente descripción.
Los expertos en Ia técnica pueden entender y efectuar otras variaciones de las realizaciones dadas a conocer poniendo en práctica Ia invención reivindicada, a partir de un análisis de los dibujos, Ia memoria descriptiva, y las reivindicaciones adjuntas. En las reivindicaciones, el término "que comprende" o "comprendiendo" no excluye otros elementos o etapas, y el artículo indefinido "un" o "una" no excluye una pluralidad. Un único procesador u otra unidad puede cumplir las funciones de diversos elementos enumerados en las reivindicaciones. El mero hecho de que ciertas medidas se mencionen en diferentes reivindicaciones mutuamente dependientes no indica que no pueda utilizarse ventajosamente una combinación de estas medidas. Un programa informático puede almacenarse/distribuirse sobre un medio adecuado, tal como un medio de almacenamiento óptico o un medio de estado sólido suministrado junto con o como parte de otro hardware, aunque también puede distribuirse de otras formas, tal como a través de Internet u otros sistemas de telecomunicación por cable o inalámbricos. Ningún símbolo de referencia en las reivindicaciones ha de interpretarse como limitativo del alcance.

Claims

R E I V I N D I C A C I O N E S
1.- Dispositivo (120) en el plano de control de una red de telecomunicación (100) con una arquitectura que comprende funciones de plano de servicio (110), de plano de control y de plano de transportes (130), en el que el dispositivo está configurado para el control de admisión y Ia reserva de recursos para redes de telecomunicación en entornos multidominio, es decir en entornos con redes de telecomunicación multidominio y/o multioperador o en entornos con al menos una red de telecomunicación de un operador y una red del hogar de un usuario final, en el que el dispositivo comprende una interfaz (500,600) para comunicarse con otro dispositivo (220) para el control de admisión y Ia reserva de recursos, que está ubicado en otro dominio (200), es decir en una red de telecomunicación de otro operador o en Ia red del hogar, caracterizado porque el dispositivo (120) está configurado, en el caso de recibir una petición desde el plano de servicio (110) para establecer, modificar o liberar una conexión cuya dirección origen es gestionada por el dominio (100) del dispositivo (120), para enviar a través de Ia interfaz una de las siguientes peticiones para encadenar una de las siguientes acciones en el otro dispositivo (220) y de este modo aprovisionar calidad de servicio garantizada en entornos multidominio: una petición de un primer tipo (720) para que el otro dispositivo reserve y configure los recursos necesarios; una petición de un segundo tipo (800) para que el otro dispositivo libere recursos asignados previamente; y una petición de un tercer tipo para que el otro dispositivo modifique
(760) los recursos asignados previamente.
2.- Dispositivo según Ia reivindicación 1 , caracterizado porque el dispositivo (120) está configurado para enviar a través de Ia interfaz (500,600) las siguientes respuestas al otro dispositivo (120): una respuesta de un primer tipo (730) para informar el otro dispositivo sobre el resultado de una operación de reserva y configuración de recursos, puesta en marcha después de recibir una petición del primer tipo (720) del otro dispositivo; una respuesta de un segundo tipo (810) para informar el otro dispositivo sobre el resultado de una operación de liberación de recursos asignados previamente, puesta en marcha después de recibir una petición del segundo tipo (800) del otro dispositivo; y una respuesta de un tercer tipo (770) para informar el otro dispositivo sobre el resultado de una operación de modificación de recursos asignados previamente, puesta en marcha después de recibir una petición del tercer tipo (760) del otro dispositivo.
3.- Dispositivo según Ia reivindicación 1 o 2, caracterizado porque el dispositivo está configurado, en el caso de recibir una petición desde el plano de servicio para establecer, modificar o liberar una conexión cuya dirección origen no es gestionada por el dominio del dispositivo, para enviar a través de Ia interfaz una de las siguientes peticiones: una petición de un cuarto tipo (830) para que el dispositivo para el control de admisión y Ia reserva de recursos, que está ubicado en el dominio final comience Ia reserva y configuración de recursos, enviando una petición del primer tipo (720); una petición de un quinto tipo para que el dispositivo para el control de admisión y Ia reserva de recursos, que está ubicado en el dominio que gestiona Ia origen de Ia conexión, comience Ia liberación de recursos asignados previamente, enviando una petición del segundo tipo; y una petición de un sexto tipo para que el dispositivo para el control de admisión y Ia reserva de recursos, que está ubicado en el dominio que gestiona Ia origen de Ia conexión, comience Ia modificación de recursos asignados previamente, enviando una petición del tercer tipo.
4.- Dispositivo según Ia reivindicación 3, caracterizado porque el dispositivo está configurado para enviar a través de Ia interfaz las siguientes respuestas al otro dispositivo: una respuesta de un cuarto tipo (840) a una petición del cuarto tipo
(830) del otro dispositivo; una respuesta de un quinto tipo a una petición del quinto tipo del otro dispositivo; y una respuesta de un sexto tipo a una petición del sexto tipo del otro dispositivo.
5.- Dispositivo según cualquiera de las reivindicaciones anteriores, caracterizado porque el dispositivo está configurado para enviar Ia siguiente información a través de Ia interfaz: información de Ia clase de servicio requerida para cada conexión; información de las conexiones; ancho de banda requerido para cada conexión; y punto de entrada en el dominio.
6.- Dispositivo según Ia reivindicación 1 , caracterizado porque el dispositivo está configurado para, después de recibir Ia petición (710) desde el plano de servicio, comprobar que se pueden admitir nuevos recursos (900), y una vez admitida Ia conexión, enviar Ia petición del primer, segundo o tercer tipo al otro dispositivo y después de enviar Ia petición configurar las funciones de Ia capa de transporte necesarias para Ia conexión (910).
7.- Dispositivo según cualquiera de las conexiones anteriores, caracterizado porque comprende un primer submódulo (1220,1230) independiente de Ia tecnología de red subyacente y encargado de proporcionar Ia interfaz común al plano de servicio y otra interfaz común al plano de aplicación y un segundo submódulo (1240,1250) dependiente de Ia tecnología de red subyacente y encargado de configurar las funciones específicas en el plano de transporte.
8.- Dispositivo según cualquiera de las conexiones anteriores, caracterizado porque Ia red de telecomunicación es una Red de Nueva Generación y Ia conexión es una conexión IP.
9.- Dispositivo (220) en el plano de control de una red de telecomunicación con una arquitectura que comprende funciones de plano de servicio (210), de plano de control y de plano de transportes (230), en el que el dispositivo está configurado para el control de admisión y Ia reserva de recursos para redes de telecomunicación en entornos multidominio, es decir en entornos con redes de telecomunicación multidominio y/o multioperador o en entornos con al menos una red de telecomunicación de un operador y una red del hogar de un usuario final, en el que el dispositivo comprende una interfaz (500,600) para comunicarse con otro dispositivo (120) para el control de admisión y Ia reserva de recursos, que está ubicado en otro dominio (100), es decir en una red de telecomunicación de otro operador o en Ia red del hogar, caracterizado porque el dispositivo está configurado, en el caso de recibir una petición a través de Ia interfaz del otro dispositivo encadenar una de las siguientes acciones y de este modo aprovisionar calidad de servicio garantizada en entornos multidominio: en el caso de recibir una petición de un primer tipo (720) reservar y configurar los recursos necesarios; en el caso de recibir una petición de un segundo tipo (800) liberar recursos asignados previamente; y en el caso de recibir una petición de un tercer tipo (760) modificar los recursos asignados previamente.
10.- Dispositivo según Ia reivindicación 9, caracterizado porque el dispositivo (220) está configurado para enviar a través de Ia interfaz las siguientes respuestas al otro dispositivo (120): una respuesta de un primer tipo (730) para informar el otro dispositivo sobre el resultado de Ia operación de reserva y configuración de recursos, puesta en marcha después de recibir Ia petición del primer tipo (720) del otro dispositivo; una respuesta de un segundo tipo (810) para informar el otro dispositivo sobre el resultado de Ia operación de liberación de recursos asignados previamente, puesta en marcha después de recibir Ia petición del segundo tipo (800) del otro dispositivo; y una respuesta de un tercer tipo (770) para informar el otro dispositivo sobre el resultado de Ia operación de modificación de recursos asignados previamente, puesta en marcha después de recibir Ia petición del tercer tipo (760) del otro dispositivo.
11.- Método para el control de admisión y Ia reserva de recursos para redes de telecomunicación en entornos multidominio, es decir en entornos con redes de telecomunicación multidominio y/o multioperador o en entornos con al menos una red de telecomunicación de un operador y una red del hogar de un usuario final, caracterizado por los siguientes pasos: recibir por un dispositivo (120) en el plano de control de una red de telecomunicación (100) con una arquitectura que comprende funciones de plano de servicio (110), de plano de control y de plano de transportes (130) una petición (710) desde el plano de servicio para establecer, modificar o liberar una conexión cuya dirección origen es gestionada por el dominio (100) del dispositivo; enviar a otro dispositivo (220,400) para el control de admisión y Ia reserva de recursos, que está ubicado en otro dominio (200), es decir en una red de telecomunicación de otro operador o en Ia red del hogar a través de una interfaz (500,600) una de las siguientes peticiones para encadenar una de las siguientes acciones en el otro dispositivo y de este modo aprovisionar calidad de servicio garantizada en entornos multidominio: una petición de un primer tipo (720) para que el otro dispositivo reserve y configure los recursos necesarios; una petición de un segundo tipo (800) para que el otro dispositivo libere recursos asignados previamente; y una petición de un tercer tipo (760) para que el otro dispositivo modifique los recursos asignados previamente y por el otro dispositivo (220): en caso de recibir una petición del primer tipo reservar y configurar los recursos necesarios; en caso de recibir una petición del segundo tipo liberar recursos asignados previamente; y en caso de recibir una petición del tercer tipo modificar recursos asignados previamente.
12.- Método según Ia reivindicación 11 , caracterizado porque el otro dispositivo (220) envía al dispositivo (120) una de las siguientes respuestas: una respuesta de un primer tipo (730) para informar el dispositivo
(120) sobre el resultado de una operación de reserva y configuración de recursos, puesta en marcha después de recibir una petición del primer tipo (720) del dispositivo; una respuesta de un segundo tipo (810) para informar el dispositivo
(120) sobre el resultado de una operación de liberación de recursos asignados previamente, puesta en marcha después de recibir una petición del segundo tipo (800) del dispositivo; y una respuesta de un tercer tipo (770) para informar el dispositivo
(120) sobre el resultado de una operación de modificación de recursos asignados previamente, puesta en marcha después de recibir una petición del tercer tipo (760) del dispositivo.
13.- Método según Ia reivindicación 11 o 12, caracterizado por los siguientes pasos: recibir por el dispositivo (120) una petición desde el plano de servicio (110) para establecer, modificar o liberar una conexión cuya dirección origen no es gestionada por el dominio (100) del dispositivo; enviar al otro dispositivo (220) una de las siguientes peticiones:
una petición de un cuarto tipo (830) para que el dispositivo para el control de admisión y Ia reserva de recursos, que está ubicado en el dominio final comience Ia reserva y configuración de recursos, enviando una petición del primer tipo (720); una petición de un quinto tipo para que el dispositivo para el control de admisión y Ia reserva de recursos, que está ubicado en el dominio que gestiona Ia dirección origen de Ia conexión, comience Ia liberación de recursos asignados previamente, enviando una petición del segundo tipo (800); y una petición de un sexto tipo para que el dispositivo para el control de admisión y Ia reserva de recursos, que está ubicado en el dominio que gestiona Ia dirección origen de Ia conexión, comience Ia modificación de recursos asignados previamente, enviando una petición del tercer tipo (760).
14.- Método según Ia reivindicación 13, caracterizado por el envío de una de las siguientes respuestas al dispositivo (120): una respuesta de un cuarto tipo (840) a Ia petición del cuarto tipo (830) por parte del dispositivo ubicado en el dominio final; una respuesta de un quinto tipo a Ia petición del quinto tipo por parte del dispositivo ubicado en el dominio que gestiona Ia dirección origen de Ia conexión una respuesta de un sexto tipo a una petición del sexto tipo por parte del dispositivo ubicado en el dominio que gestiona Ia dirección origen de Ia conexión.
15.- Método según cualquiera de las reivindicaciones 1 1 -14, caracterizado porque se envía Ia siguiente información a través de Ia interfaz: información de Ia clase de servicio requerida para cada conexión; información de las conexiones; ancho de banda requerido para cada conexión; y punto de entrada en el dominio.
16.- Método según Ia reivindicación 1 1 , caracterizado por los siguientes pasos: después de recibir Ia petición (710) desde el plano de servicio (1 10) por el positivo (120), comprobar por parte de éste que se pueden admitir nuevos recursos (900), una vez admitida Ia conexión, enviar Ia petición del primer, segundo o tercer tipo al otro dispositivo (220); y después de enviar Ia petición configurar las funciones de Ia capa de transporte necesarias para Ia conexión (910).
17.- Programa de ordenador que comprende medios de código adaptados para realizar los pasos de cualquiera de las reivindicaciones 1 1 - 16, cuando dicho programa se ejecuta en un ordenador.
PCT/ES2010/070123 2009-03-06 2010-03-05 Dispositivos y método para la admisión y control de recursos en entornos multidominio WO2010100311A1 (es)

Priority Applications (3)

Application Number Priority Date Filing Date Title
BRPI1009096A BRPI1009096A2 (pt) 2009-03-06 2010-03-05 dispositivo e método para a admissão e controle de recursos em ambientes multi-domínios.
EP10748371A EP2405615A1 (en) 2009-03-06 2010-03-05 Devices and method for the admission and control of resources in multi-domain environments
MX2011009045A MX2011009045A (es) 2009-03-06 2010-03-05 Dispositivos y metodo para la admision y control de recursos en entornos multidominio.

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
ES200900640 2009-03-06
ESP200900640 2009-03-06

Publications (1)

Publication Number Publication Date
WO2010100311A1 true WO2010100311A1 (es) 2010-09-10

Family

ID=42709235

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/ES2010/070123 WO2010100311A1 (es) 2009-03-06 2010-03-05 Dispositivos y método para la admisión y control de recursos en entornos multidominio

Country Status (9)

Country Link
EP (1) EP2405615A1 (es)
AR (1) AR076092A1 (es)
BR (1) BRPI1009096A2 (es)
CL (1) CL2011002178A1 (es)
CO (1) CO6420384A2 (es)
MX (1) MX2011009045A (es)
PE (1) PE20120728A1 (es)
UY (1) UY32476A (es)
WO (1) WO2010100311A1 (es)

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070189293A1 (en) * 2006-02-15 2007-08-16 Fujitsu Limited QoS guarantee system in multidomain network and QoS server applied to the same

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070189293A1 (en) * 2006-02-15 2007-08-16 Fujitsu Limited QoS guarantee system in multidomain network and QoS server applied to the same

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
"Bridging the standardization gap to provide OoS in current NGN architectures", IEEE COMMUNICATIONS MAGAZINE, SPECIAL ISSUE ON ''ITU-T INTERNATIONAL STANDARDS IN INFORMATION AND COMMUNICATIONS TECHNOLOGIES, October 2008 (2008-10-01)
"Innovations in NGN: Future Network and Services, 2008. K-INGN 2008. First ITU-T Kaleidoscope Academic Conference.", ISBN: 978-92-61-124, article M. A. CALLEJO-RODRIGUEZ ET AL.: "EUQOS: END-TO-END QOS OVER HETEROGENEOUS NETWORKS.", pages: 177 - 184., XP031272295 *

Also Published As

Publication number Publication date
PE20120728A1 (es) 2012-07-13
UY32476A (es) 2010-09-30
CL2011002178A1 (es) 2012-01-13
EP2405615A1 (en) 2012-01-11
CO6420384A2 (es) 2012-04-16
BRPI1009096A2 (pt) 2016-03-01
MX2011009045A (es) 2011-09-21
AR076092A1 (es) 2011-05-18

Similar Documents

Publication Publication Date Title
ES2942465T3 (es) Determinación de información de identificación sobre trayectoria entre dominios
EP2894820A1 (en) Dynamic end-to-end network path setup across multiple network layers with network service chaining
JP5335444B2 (ja) 次世代ネットワークにおけるリアルタイムのアプリケーション駆動のリソース管理のための方法および装置
EP1379036A1 (en) Method and system for automatically establishing a return label switched path
Cerroni et al. Cross-layer resource orchestration for cloud service delivery: A seamless SDN approach
WO2015035616A1 (zh) 跨网通信方法及装置
ES2543921T3 (es) Procedimiento de asignación de recursos de red en arquitecturas de servicio basadas en TISPAN
US7463580B2 (en) Resource sharing among network tunnels
Helebrandt et al. Novel SDN multi-domain architecture
Farrel et al. Unanswered questions in the path computation element architecture
US20190379596A1 (en) Methods and Systems preventing Make Before Break failures during soft preemption in MPLS
Petropoulos et al. Software-defined inter-networking: Enabling coordinated QoS control across the Internet
CN106330701B (zh) 环形组网的快速重路由方法及装置
Dugeon et al. End to end quality of service over heterogeneous networks EuQoS
WO2010100311A1 (es) Dispositivos y método para la admisión y control de recursos en entornos multidominio
WO2017143958A1 (en) System, method and apparatus for implementing fast reroute (frr)
Jauhari et al. INET Framework modifications in OMNeT++ simulator for MPLS traffic engineering
Li et al. Cheetah virtual label switching router for dynamic provisioning in ip optical networks
EP4277424A1 (en) Path computation method and apparatus, storage medium, and electronic device
Kaczmarek et al. The performance of ASON/GMPLS network with hierarchical control plane structure
Tarasiuk et al. On the signaling system in the IPv6 QoS Parallel Internet
Awais et al. Traffic engineering using multi-protocol label switching (MPLS) for delay sensitive traffic
Baggan et al. Performance Evaluation of Path Restoration Techniques in a Network Check for updates
Muñoz et al. End-to-end service provisioning across MPLS and IP/WDM domains
Kim et al. Analysis of mpls signaling protocols and traffic dissemination in ospf and mpls

Legal Events

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

Ref document number: 10748371

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: MX/A/2011/009045

Country of ref document: MX

WWE Wipo information: entry into national phase

Ref document number: 2011002178

Country of ref document: CL

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 2010748371

Country of ref document: EP

REG Reference to national code

Ref country code: BR

Ref legal event code: B01A

Ref document number: PI1009096

Country of ref document: BR

ENP Entry into the national phase

Ref document number: PI1009096

Country of ref document: BR

Kind code of ref document: A2

Effective date: 20110906