ES2236370T3 - Metodo para permitir la negociacion de la calidad de servicio extremo a extremo por utilizacion del protocolo de negociacion extremo a extremo (e2enp). - Google Patents
Metodo para permitir la negociacion de la calidad de servicio extremo a extremo por utilizacion del protocolo de negociacion extremo a extremo (e2enp).Info
- Publication number
- ES2236370T3 ES2236370T3 ES02001900T ES02001900T ES2236370T3 ES 2236370 T3 ES2236370 T3 ES 2236370T3 ES 02001900 T ES02001900 T ES 02001900T ES 02001900 T ES02001900 T ES 02001900T ES 2236370 T3 ES2236370 T3 ES 2236370T3
- Authority
- ES
- Spain
- Prior art keywords
- service
- quality
- information
- e2enp
- negotiation
- Prior art date
- Legal status (The legal status 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 status listed.)
- Expired - Lifetime
Links
- 238000000034 method Methods 0.000 title claims abstract description 177
- 230000008859 change Effects 0.000 claims abstract description 35
- 238000001514 detection method Methods 0.000 claims abstract description 4
- 230000006978 adaptation Effects 0.000 claims description 108
- 230000008569 process Effects 0.000 claims description 93
- 238000004891 communication Methods 0.000 claims description 92
- 230000011664 signaling Effects 0.000 claims description 57
- 230000007246 mechanism Effects 0.000 claims description 56
- 230000000875 corresponding effect Effects 0.000 claims description 45
- 238000012546 transfer Methods 0.000 claims description 32
- 238000005516 engineering process Methods 0.000 claims description 18
- 230000008901 benefit Effects 0.000 claims description 14
- 239000003999 initiator Substances 0.000 claims description 8
- 230000002596 correlated effect Effects 0.000 claims description 7
- 230000001360 synchronised effect Effects 0.000 claims description 6
- 230000015556 catabolic process Effects 0.000 claims description 5
- 238000006731 degradation reaction Methods 0.000 claims description 5
- 230000000903 blocking effect Effects 0.000 claims description 3
- 230000003213 activating effect Effects 0.000 claims description 2
- 230000002776 aggregation Effects 0.000 claims description 2
- 238000004220 aggregation Methods 0.000 claims description 2
- 230000003111 delayed effect Effects 0.000 claims 1
- 238000009434 installation Methods 0.000 claims 1
- 239000000306 component Substances 0.000 description 68
- 238000007726 management method Methods 0.000 description 51
- 239000000543 intermediate Substances 0.000 description 33
- 230000004044 response Effects 0.000 description 23
- 238000010276 construction Methods 0.000 description 21
- 238000005457 optimization Methods 0.000 description 17
- 230000032258 transport Effects 0.000 description 13
- 230000007704 transition Effects 0.000 description 12
- 230000009471 action Effects 0.000 description 9
- 230000003044 adaptive effect Effects 0.000 description 9
- 230000006870 function Effects 0.000 description 9
- 230000000977 initiatory effect Effects 0.000 description 9
- 230000010354 integration Effects 0.000 description 9
- 235000021190 leftovers Nutrition 0.000 description 9
- 238000007906 compression Methods 0.000 description 8
- 230000006835 compression Effects 0.000 description 8
- 230000001419 dependent effect Effects 0.000 description 8
- 239000012634 fragment Substances 0.000 description 8
- 230000015654 memory Effects 0.000 description 8
- 230000007423 decrease Effects 0.000 description 7
- 230000037230 mobility Effects 0.000 description 7
- 238000010586 diagram Methods 0.000 description 6
- 230000007613 environmental effect Effects 0.000 description 6
- 230000014509 gene expression Effects 0.000 description 6
- 230000001976 improved effect Effects 0.000 description 6
- 230000003993 interaction Effects 0.000 description 6
- 238000012545 processing Methods 0.000 description 6
- 230000000007 visual effect Effects 0.000 description 5
- 230000035508 accumulation Effects 0.000 description 4
- 238000009825 accumulation Methods 0.000 description 4
- 230000002457 bidirectional effect Effects 0.000 description 4
- 230000006872 improvement Effects 0.000 description 4
- 230000005540 biological transmission Effects 0.000 description 3
- 238000006243 chemical reaction Methods 0.000 description 3
- 230000000295 complement effect Effects 0.000 description 3
- 239000008358 core component Substances 0.000 description 3
- 238000013461 design Methods 0.000 description 3
- 238000011161 development Methods 0.000 description 3
- 230000018109 developmental process Effects 0.000 description 3
- 230000000694 effects Effects 0.000 description 3
- 230000005611 electricity Effects 0.000 description 3
- 230000002829 reductive effect Effects 0.000 description 3
- 238000013519 translation Methods 0.000 description 3
- 230000006399 behavior Effects 0.000 description 2
- 230000015572 biosynthetic process Effects 0.000 description 2
- 210000004556 brain Anatomy 0.000 description 2
- 239000003795 chemical substances by application Substances 0.000 description 2
- 239000002131 composite material Substances 0.000 description 2
- 238000012790 confirmation Methods 0.000 description 2
- 230000008094 contradictory effect Effects 0.000 description 2
- 230000008030 elimination Effects 0.000 description 2
- 238000003379 elimination reaction Methods 0.000 description 2
- 238000005265 energy consumption Methods 0.000 description 2
- 238000011156 evaluation Methods 0.000 description 2
- 230000002452 interceptive effect Effects 0.000 description 2
- 238000002955 isolation Methods 0.000 description 2
- 238000005304 joining Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000002028 premature Effects 0.000 description 2
- 238000013138 pruning Methods 0.000 description 2
- 238000011084 recovery Methods 0.000 description 2
- 230000009467 reduction Effects 0.000 description 2
- 238000012552 review Methods 0.000 description 2
- 230000029305 taxis Effects 0.000 description 2
- 230000001960 triggered effect Effects 0.000 description 2
- 238000012795 verification Methods 0.000 description 2
- 241000227425 Pieris rapae crucivora Species 0.000 description 1
- 125000002015 acyclic group Chemical group 0.000 description 1
- 230000003466 anti-cipated effect Effects 0.000 description 1
- 238000013459 approach Methods 0.000 description 1
- 238000005284 basis set Methods 0.000 description 1
- 230000002146 bilateral effect Effects 0.000 description 1
- 238000012512 characterization method Methods 0.000 description 1
- 230000001427 coherent effect Effects 0.000 description 1
- 230000001010 compromised effect Effects 0.000 description 1
- 239000000470 constituent Substances 0.000 description 1
- 238000012937 correction Methods 0.000 description 1
- 230000008878 coupling Effects 0.000 description 1
- 238000010168 coupling process Methods 0.000 description 1
- 238000005859 coupling reaction Methods 0.000 description 1
- 238000013499 data model Methods 0.000 description 1
- 230000003247 decreasing effect Effects 0.000 description 1
- 230000007812 deficiency Effects 0.000 description 1
- 230000000593 degrading effect Effects 0.000 description 1
- 230000007717 exclusion Effects 0.000 description 1
- 231100000727 exposure assessment Toxicity 0.000 description 1
- 238000001914 filtration Methods 0.000 description 1
- 230000005021 gait Effects 0.000 description 1
- 238000005469 granulation Methods 0.000 description 1
- 230000003179 granulation Effects 0.000 description 1
- 230000002650 habitual effect Effects 0.000 description 1
- 230000000670 limiting effect Effects 0.000 description 1
- 230000007257 malfunction Effects 0.000 description 1
- 230000000873 masking effect Effects 0.000 description 1
- 230000001404 mediated effect Effects 0.000 description 1
- 239000000203 mixture Substances 0.000 description 1
- 238000010295 mobile communication Methods 0.000 description 1
- 238000012544 monitoring process Methods 0.000 description 1
- 230000006855 networking Effects 0.000 description 1
- 230000008520 organization Effects 0.000 description 1
- 230000010355 oscillation Effects 0.000 description 1
- 238000010422 painting Methods 0.000 description 1
- 230000000644 propagated effect Effects 0.000 description 1
- 230000008929 regeneration Effects 0.000 description 1
- 238000011069 regeneration method Methods 0.000 description 1
- 238000012827 research and development Methods 0.000 description 1
- 230000000717 retained effect Effects 0.000 description 1
- 239000011435 rock Substances 0.000 description 1
- 238000005070 sampling Methods 0.000 description 1
- 238000000926 separation method Methods 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
- 238000003860 storage Methods 0.000 description 1
- 230000008093 supporting effect Effects 0.000 description 1
- 230000008685 targeting Effects 0.000 description 1
- 230000002123 temporal effect Effects 0.000 description 1
- 230000009466 transformation Effects 0.000 description 1
- 238000000844 transformation Methods 0.000 description 1
- 230000035899 viability Effects 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/80—Responding to QoS
-
- 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
- H04L47/18—End to end
-
- 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
- H04L47/20—Traffic policing
-
- 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
- H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
-
- 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
- H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
- H04L47/2416—Real-time traffic
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
- H04L47/72—Admission control; Resource allocation using reservation actions during connection setup
- H04L47/724—Admission control; Resource allocation using reservation actions during connection setup at intermediate nodes, e.g. resource reservation protocol [RSVP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
- H04L47/76—Admission control; Resource allocation using dynamic resource allocation, e.g. in-call renegotiation requested by the user or requested by the network in response to changing network conditions
- H04L47/762—Admission control; Resource allocation using dynamic resource allocation, e.g. in-call renegotiation requested by the user or requested by the network in response to changing network conditions triggered by the network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
- H04L47/76—Admission control; Resource allocation using dynamic resource allocation, e.g. in-call renegotiation requested by the user or requested by the network in response to changing network conditions
- H04L47/765—Admission control; Resource allocation using dynamic resource allocation, e.g. in-call renegotiation requested by the user or requested by the network in response to changing network conditions triggered by the end-points
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
- H04L47/76—Admission control; Resource allocation using dynamic resource allocation, e.g. in-call renegotiation requested by the user or requested by the network in response to changing network conditions
- H04L47/765—Admission control; Resource allocation using dynamic resource allocation, e.g. in-call renegotiation requested by the user or requested by the network in response to changing network conditions triggered by the end-points
- H04L47/767—Admission control; Resource allocation using dynamic resource allocation, e.g. in-call renegotiation requested by the user or requested by the network in response to changing network conditions triggered by the end-points after changing the attachment point, e.g. after hand-off
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
- H04L47/80—Actions related to the user profile or the type of traffic
- H04L47/801—Real time traffic
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
- H04L47/80—Actions related to the user profile or the type of traffic
- H04L47/805—QOS or priority aware
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
- H04L47/80—Actions related to the user profile or the type of traffic
- H04L47/808—User-type aware
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
- H04L47/82—Miscellaneous aspects
- H04L47/822—Collecting or measuring resource availability data
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
- H04L47/82—Miscellaneous aspects
- H04L47/824—Applicable to portable or mobile terminals
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/1066—Session management
- H04L65/1069—Session establishment or de-establishment
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/1066—Session management
- H04L65/1101—Session protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/1066—Session management
- H04L65/1101—Session protocols
- H04L65/1104—Session initiation protocol [SIP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/40—Support for services or applications
- H04L65/403—Arrangements for multi-party communication, e.g. for conferences
- H04L65/4038—Arrangements for multi-party communication, e.g. for conferences with floor control
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/60—Network streaming of media packets
- H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
- H04L65/612—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for unicast
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/60—Network streaming of media packets
- H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/2866—Architectures; Arrangements
- H04L67/30—Profiles
- H04L67/303—Terminal profiles
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/2866—Architectures; Arrangements
- H04L67/30—Profiles
- H04L67/306—User profiles
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/24—Negotiation of communication capabilities
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
- H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
- H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
- H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/40—Network security protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W28/00—Network traffic management; Network resource management
- H04W28/16—Central resource management; Negotiation of resources or communication parameters, e.g. negotiating bandwidth or QoS [Quality of Service]
- H04W28/18—Negotiating wireless communication parameters
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W8/00—Network data management
- H04W8/02—Processing of mobility data, e.g. registration information at HLR [Home Location Register] or VLR [Visitor Location Register]; Transfer of mobility data, e.g. between HLR, VLR or external networks
- H04W8/04—Registration at HLR or HSS [Home Subscriber Server]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W28/00—Network traffic management; Network resource management
- H04W28/16—Central resource management; Negotiation of resources or communication parameters, e.g. negotiating bandwidth or QoS [Quality of Service]
- H04W28/24—Negotiating SLA [Service Level Agreement]; Negotiating QoS [Quality of Service]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W36/00—Hand-off or reselection arrangements
- H04W36/08—Reselecting an access point
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W36/00—Hand-off or reselection arrangements
- H04W36/14—Reselecting a network or an air interface
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W56/00—Synchronisation arrangements
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W76/00—Connection management
- H04W76/10—Connection setup
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
Abstract
Un método para intercambiar flujos de información entre iguales finales (810, 811) en una red y para soportar el End-to-End Negotiation Protocol (E2ENP, 908), en el que la negociación de calidad de servicio de extremo a extremo comprende los pasos de: - prenegociar (802) una pluralidad de contratos de calidad de servicio antes del establecimiento de flujos de información, - continuar la correlación (804) de calidad de servicio y la sincronización (805) en el tiempo de flujos múltiples o de grupos de flujos, - negociar (806) el uso de uno de los contratos prenegociados (802) de calidad de servicio antes o en el momento de establecimiento de flujo de información, y - renegociar (808) un contrato de calidad de servicio a partir de los contratos prenegociados (802), después de la detección de un cambio o violación de calidad de servicio, caracterizado por el uso del Session Description Protocol Next Generation (SDPng, 912) para definir información de perfiles de usuarios para ser usada como entrada para el E2ENP (908).
Description
Método para permitir la negociación de la calidad
de servicio extremo a extremo por utilización del protocolo de
negociación extremo a extremo (E2ENP).
La invención fundamental se refiere generalmente
al campo de la computación móvil en un entorno de operación en red
móvil inalámbrica con aplicaciones y tecnologías multimedia
distribuidas. Más específicamente, está dirigida al campo de la
gestión de calidad de servicio (QoS:
Qualitiy-of-Service) para servicios
adaptables en tiempo real que funcionan en dispositivos móviles que
soportan tecnologías de acceso diferentes en redes inalámbricas
dinámicas de Internet Protocol (IP), incluyendo de tal modo
cuestiones de investigación y desarrollo que están relacionadas
especialmente con software intermedio (middleware) multimedia y
mecanismos de reserva de recursos. En este contexto, la invención
propone un modelo para definir información de perfiles de usuarios
y capacidades de terminales de tal modo que las especificaciones
jerárquicas de contratos de calidad de servicio (QoS) (por ejemplo,
correlaciones apremiantes a través de conjuntos diferentes de
contratos de calidad de servicio para flujos de información
relacionados) pueden ser impuestas y usadas para obtener información
negociable.
Como una implementación de referencia de este
concepto, esta invención propone un uso original del Session
Initiation Protocol (SIP) normalizado por la Internet Engineering
Task Force (IETF) en conjunción con ampliaciones de la
especificación de Session Description Protocol Next Generation
(SDPng) basada en el Extensible Markup Language (XML) para
implementar conceptos del End-to-End
QoS Negotiation Protocol (E2ENP). El concepto de la solución
propuesta según la invención fundamental está basado en una
propuesta que ha sido identificada originalmente en "Conceptos
para adaptación de servicios, variabilidad de escala y manejo de
calidad de servicio (QoS) en redes con movilidad habilitada"
(IST-1999-10050 BRAIN Deliverable
1.2, 31/03/2001, \underline{http://www.ist.brain.org/}), designada
[BRAIN] en lo siguiente, junto con una arquitectura de referencias
específica. En este contexto, debe ser obtenido un conjunto de
exigencias básicas. De tal modo, debe abrirse una discusión
referente a este conjunto de exigencias y la elección de una
solución óptima con respecto a dichas exigencias.
Internet ha demostrado ser una arquitectura
satisfactoria para suministrar un conjunto amplio de servicios
electrónicos (incluyendo, entre muchos otros, servicios de
telefonía, mensajería electrónica y audio/video) no solo a usuarios
fijos sino también a usuarios móviles. Micro y macromovilidad IP y
tecnologías IP inalámbricas preparan el terreno realmente para la
integración completa de Internet con las generaciones segunda y
tercera de sistemas de teléfonos móviles. Para conseguir este
objeto, las redes y aplicaciones IP de la próxima generación
tendrán que estudiar los desafíos crecientemente importantes de
acceso inalámbrico, gestión de movilidad, provisión de calidad de
servicio y servicios multimedia.
Un problema primordial que los usuarios móviles
arrostrarán más probablemente dentro de este contexto es como
enfrentarse con la cantidad limitada de recursos en los sistemas
finales y en la red, y con condiciones ambientales inestables. De
hecho, se espera que los usuarios móviles incurran más
frecuentemente en el caso desafortunado de que sus contratos de
calidad de servicio no sean soportados ya por la infraestructura de
red, debido a varias razones como: degradaciones de calidad del
enlace inalámbrico, transferencias horizontales y/o verticales,
cantidad limitada de recursos de terminales móviles. En el resto de
este documento, estos casos desafortunados deben ser denominados
"violaciones de calidad de servicio". Suponiendo provisión
excesiva de recursos apropiados en la parte principal, puede
esperarse que las violaciones de calidad de servicio se originaran
más probablemente en la red de acceso, especialmente en su parte de
radio.
Además, las aplicaciones multimedia móviles que
tratan con flujos de información múltiples siendo intercambiados
simultáneamente con una multiplicidad de iguales, requerirían un
modo eficaz y eficiente de manejar las exigencias de calidad de
servicio, especialmente enfrente de las condiciones ambientales
inestables antes mencionadas.
Un modo posible de enfrentarse con las
condiciones ambientales inestables es permitir que las aplicaciones
de usuarios móviles reaccionen eficiente y oportunamente a las
violaciones de calidad de servicio, planificando acciones contrarias
por adelantado. De hecho, los iguales pueden negociar fuera de
línea diversos contratos alternativos de calidad de servicio en
niveles diferentes de abstracción, de modo que en el instante de
establecimiento de conexión y siempre que ocurran violaciones de
calidad de servicio, acuerdos sobre como adaptarse más eficazmente
a las condiciones mutadas pueden ser alcanzados oportunamente entre
los iguales.
Además, los iguales pueden seguir un
procedimiento específico para imponer eficazmente los contratos
prenegociados de calidad de servicio, evitando solicitar cualquier
reserva de recursos de red antes de que los recursos locales en
todos los iguales implicados hayan sido determinados y sus reservas
hayan sido efectuadas consiguientemente. Este procedimiento es
designado además como "principio de economía".
La solución global que combina los dos mecanismos
de planificación antes mencionados será denominada ahora
"End-to-End Negotiation
Protocol" ("E2ENP").
En particular, debería observarse que la
negociación de capacidades (por ejemplo,
codificadores-descodificadores) es considerada por
la presente como una cuestión separada, complementaria de la
negociación de información de perfiles y preferencias de calidad de
servicio de usuarios. Aplicaciones inteligentes adaptables y/o
software intermedio (middleware) pueden así usar eficazmente
cualquier información tal negociada de extremo a extremo por los
iguales para elegir la estrategia de adaptación óptima como
reacción a una violación dada de calidad de servicio como se
describe en [BRAIN].
Según el estado de la técnica, métodos y
tecnologías diferentes están disponibles actualmente referentes al
problema de la gestión de calidad de servicio en entornos móviles,
que están relacionadas estrechamente con el tópico de la invención
fundamental. Para comprender el contexto de la invención, es
necesario explicar brevemente las características principales
implicadas con dichas tecnologías.
En la Solicitud de patente europea EP 01 122
366.6, el protocolo E2ENP ha sido introducido y descrito con
detalle. Dicha invención presenta un marco para conseguir la
negociación dinámica de calidad de servicio de extremo a extremo, y
la coordinación de control para aplicaciones multimedia
distribuidas. El marco se forma sobre la negociación dinámica de
capacidades y la especificación de trayectos de adaptación y
contratos de calidad de servicio (alternativos) basados en las
preferencias de usuarios. En particular, es presentado un protocolo
que proporciona negociación de extremo a extremo de calidad de
servicio alternativa, capacidades, preferencias y/o configuraciones
basadas en ampliaciones de protocolos basados en IP como Session
Initiation Protocol (SIP), Real Time Media Streaming Protocol
(RTSP) y/o Session Description Protocol (SDP), en coordinación con
mecanismos para reserva de recursos de red (por ejemplo, Resource
Reservation Protocol: RSVP), reserva de recursos de terminales
locales (por ejemplo, UCP, memoria, alimentación, dispositivos
auxiliares) y mecanismos de adaptación. Hasta este punto, y con
respecto a dos o más iguales, son identificadas seis fases mediante
las que los iguales son habilitados para establecer comunicaciones
multi-abonado, multiflujo y/o multimedia. En
detalle, estas fases son descubrimiento de protocolo,
prenegociación, sincronización en el tiempo y correlación de
calidad de servicio de flujos múltiples, negociación rápida
(obedeciendo al principio de economía), renegociación (obedeciendo
al principio de economía) y reserva y/o liberación de recursos.
Todas estas seis fases pueden ser concatenadas o ejecutadas en
instantes diferentes.
En "Conceptos para adaptación de servicios,
variabilidad de escala y manejo de calidad de servicio en redes con
movilidad habilitada" [BRAIN], son presentados los fundamentos
del concepto de E2ENP.
en "Información útil de Real Time Protocol
(RTP) para datos de audio redundantes" (Request for Comments
(RFC) 2198, Network Working Group, septiembre de 1.997) de C.
Perkins y otros, designado [RFC2198] en lo siguiente, y "Perfil
de RTP para conferencias de audio y video con control mínimo"
(Universidad de Columbia, trabajo en marcha,
<draft-ietf-avt-profile-new-09.txt>)
de H. Schulzrine y otros, designado [RTP-Profile]
en lo siguiente, son descritas las probabilidades de
renegociaciones rápidas por medio de señalización dentro de banda.
Sin embargo, esta clase de señalización solo concierne a cambios de
codificadores-descodificadores y al soporte
redundante de medios de información codificados diferentemente sin
considerara los efectos respectivos cuando la calidad de servicio
debería ser soportada.
En "Integración de gestión de recursos y
Session Initiation Protocol (SIP) - Ampliaciones de SIP para gestión
de recursos" (IETF SIP Working Group, trabajo en marcha,
<draft-ietf-sip-manyfolks-resource-01.text>)
de W Marshall y otros, designado [SIPRES01] en lo siguiente, y
"Ampliaciones de SIP para gestión de recursos" (IETF Draft,
noviembre de 2.000,
<draft-ietf-sip-many-folks-resource-00>)
de W. Marshall y otros, designado [Marsh00] en lo siguiente, los
autores presentan un mecanismo de establecimiento de llamadas
multifase que hace a la calidad de servicio y el establecimiento de
seguridad de red una condición previa para las sesiones iniciadas
por el Session Initiation Protocol (SIP) y descritas por el Session
Description Protocol (SDP). Los recursos de red son reservados
antes de que la sesión sea iniciada usando mecanismos existentes de
reserva de recursos de red (como RSVP). El protocolo de gestión de
recursos es intercalado entre dos fases de la señalización de
llamada y los participantes son invitados después de que recursos
están disponibles en la red. Una configuración de las condiciones
previas es señalizada explícitamente. La gestión de recursos es
efectuada solo para los recursos de red. Una ampliación de SDP es
introducida para determinar si las condiciones previas son
satisfechas. Sin embargo, [SIPRES01] y [Marsh00] no consideran la
prenegociación de calidad de servicio y la integración de la gestión
de recursos locales y de iguales.
En "Confirmación de condiciones previas de
SDP" (IETF Internet Draft, trabajo en marcha,
<draft-camarillo-manyfolks-con-firm-02.txt>)
de G. Camarillo, designado [Cama00] en lo siguiente, un atributo
adicional de sentido es introducido para indicar que abonado envía
la confirmación de las condiciones previas. Finalmente, [Cama00]
proporciona un mecanismo para efectuar el control de llamada de
tercer abonado en el SIP cuando son usadas las condiciones previas
del SDP. Sin embargo, [Cama00] no considera la prenegociación de la
calidad de servicio ni la integración de la gestión de recursos
locales y de iguales.
En "Una sintaxis para describir conjuntos de
características de medios de información" (RFC 2533, 5GM/Content
Technologies, marzo de 1.999) de G. Klyne, designado [RFC2533] en lo
siguiente, el autor presenta un formato para expresar conjuntos de
características de medios de información que representan capacidades
de manejo de medios de información. Además, es proporcionado un
algoritmo que empareja los conjuntos de características. Podría ser
usado para determinar si son compatibles las capacidades de un
emisor y un receptor. Este algoritmo de emparejamiento es mejorado
en "Un algoritmo revisado de emparejamiento de conjuntos de
características de medios de información" (IETF Media Feature
Registration Working Group, trabajo en marcha,
<draft-klyne-conneg-feature-match-02.txt>)
de G. Klyne (ed.), designado [Conneg00] en lo siguiente. Además, en
"Identificar características compuestas de medios de
información" (IETF Conneg Working Group, trabajo en marcha,
<draft-ietf-conneg-feature-hash-05.txt>)
de G. Klyne (ed.), designado [Conneg00a] en lo siguiente, es
descrito un formato abreviado para conjuntos de características
compuestas de medios de información que usan una dirección
calculada (hash) de la representación de características para
describir las características compuestas. Esto puede ser usado para
proporcionar una forma abreviada para hacer referencia a una
expresión arbitraria de conjuntos de características, independiente
de cualquier mecanismo particular para deshacer la referencia.
[RFC2533] junto con [CONNEG00] y [CONNEG00a] o "Exigencias de
negociación de capacidades sencillas de SDP" (IETF MMUSIC Working
Group, trabajo en marcha,
<draft-andreasen-mmusic-sdp-simcap-reqts-00.txt>)
de F. Andreasen, designado [SDPCN01] en lo siguiente, no integran
protocolos de Internet existentes ni incluyen el concepto de
prenegociar contratos alternativos de calidad de servicio ni
integran mecanismos de reserva de recursos locales, de red y de
iguales.
En "Negociaciones de capacidades sencillas de
SDP" (IETF MMUSIC Working Group, trabajo en marcha,
<draft-andreasen-mmusic-sdp-simcap-00.txt>)
de F. Andreasen, designado [SDPCN00] en lo siguiente, el autor
expresa la exigencia de que un conjunto de capacidades debería
contener un manejador (similar al hash antes mencionado)
permitiendo hacer referencia fácilmente al conjunto de
capacidades.
En "Marco de negociación de contenidos
independiente de protocolo" (RFC 2703, SGM/Content Technologies,
septiembre de 1.999) de G. Klyne, designado [RFC2703] en lo
siguiente, el autor presenta un marco abstracto para una
negociación de contenido independiente de protocolo para los
recursos con los que interacciona. Sin embargo, no proporciona el
proceso de negociación de contenido. Identifica la necesidad de
expresar las capacidades del emisor y los recursos de datos para ser
transmitidos, las capacidades del receptor y la necesidad de un
protocolo para intercambiar estas capacidades. La negociación es
llevada a cabo por una serie de intercambios de metadatos de
negociación. La negociación se detiene tan pronto como ha sido
hallado un archivo específico de datos para ser transmitido. El
emisor transfiere los datos si el emisor determina el archivo, en
caso contrario el receptor informa al emisor. Por tanto, esta
propuesta se refiere a la negociación de contenido en lugar de
tratar de la prenegociación de capacidades y contratos de calidad
de servicio de configuraciones. La solución propuesta en [RFC2703]
tampoco integra la reserva de recursos locales, de iguales y de
red.
En "Un modelo de oferta/respuesta con SDP"
(IETF Internet Draft, trabajo en marcha,
<draft-rosenberg-mmusic-sdp-offer-answer-00.txt>)
de J. Rosenberg y H. Schulzrinne, designado [SDPOA00] en lo
siguiente, es descrito un modelo completo para la negociación de
capacidades de uno con uno con SDP. Sin embargo, este modelo tiene
problemas por la definición de información referida mutuamente e
información sobre agrupar flujos de información debido a la
estructura de jerarquía plana del SDP. Adicionalmente, este modelo
concierne solo a la negociación de capacidades pero no al soporte
de calidad de servicio.
En "Exigencias de la descripción de sesión y la
negociación de capacidades" (IETF Internet Draft, trabajo en
marcha,
<draft-kutscher-mmusic-sdpng-req-01.txt>)
de D. Kutscher y otros, designado [SDPNG01] en lo siguiente, son
identificadas las exigencias de un marco que se ocupa de la
descripción de sesión y la negociación de capacidades de puntos
finales en escenarios de conferencias multimedia
multi-abonado. De tal modo, dicho documento
proporciona un conjunto de exigencias relevantes para un marco para
una descripción de sesión y una negociación de capacidades de puntos
finales en escenarios de conferencias multimedia
multi-abonado. Dependiendo de la preferencia de
usuarios, las capacidades del sistema u otras restricciones,
configuraciones diferentes pueden ser elegidas para la conferencia.
La necesidad de un proceso de negociación entre los iguales es
identificada pero no descrita para determinar un conjunto común de
configuraciones potenciales y seleccionar una de las configuraciones
comunes a ser usada para intercambio de información. Esta
negociación de capacidades es usada para obtener una descripción de
sesión válida compatible con las capacidades de sistemas finales y
las preferencias de usuarios de los participantes potenciales.
Diferentes directrices de negociación pueden ser usadas para
reflejar tipos de conferencias diferentes. También identifican la
necesidad de reserva de recursos de red acoplada con el
establecimiento de sesión. Finalmente una propuesta es redactada
para describir capacidades y proporcionar el lenguaje de
negociación pero no un protocolo. Sin embargo, la solución propuesta
en [SDPNG01] no considera el protocolo de negociación para
determinar un conjunto común de configuraciones de calidad de
servicio ni integra la reserva de recursos locales, de iguales y de
red. Además, no integra el proceso de hacer referencia a
configuraciones mediante manejadores ni se desarrolla sobre el
concepto de contrato de calidad de servicio. Además, dicha solución
solo se ocupa de la negociación de codificadores/descodificadores
sin considerar las capacidades de terminales ni los mecanismos de
reserva de recursos de
red.
red.
La versión más reciente de este borrador de IETF,
"Descripción de sesión y negociación de capacidades" (IETF
Internet Draft, trabajo en marcha,
<draft-ietf-mmusic-sdpng-03.txt>)
de Kutscher y otros, designado [SDPNG03] en lo siguiente,
proporciona una especificación detallada de esquema de XML y un
prototipo del codificador-descodificador de audio y
los perfiles de RTP. Comparado con tal versión última, más completa
de esta propuesta de IETF, el E2ENP presenta (como una extensión de
esta propuesta):
- -
- noción de las fases de E2ENP,
- -
- nuevas secciones de SDPng y diversas configuraciones de él, según el formato de las unidades de datos de protocolo (PDUs: Protocol Data Units) asociadas con las diversas fases de E2ENP,
- -
- uso del elemento <session> explícito en la nueva sección <purpose>, en lugar del elemento <owner> en la sección <conf> (que todavía permanece pero para otros fines),
- -
- la negociación y el uso de identificadores de sesión derivados (por ejemplo, por medio de hash) del elemento <session> para limitar el tamaño de las unidades de datos de protocolo (PDUs) de E2ENP, en el que el elemento <session> (con un hash calculado) es usado en la primera unidad de datos de protocolo (PDU) de cualquier fase dada de E2ENP o concatenación de ellas,
- -
- alquiler de información negociada,
- -
- concatenación de información negociada,
- -
- la <def> original sustituida ahora por las nuevas secciones <qosdef>,
- -
- soporte de cualquier tipo de red y/o versión de protocolo en la sección <cfg>,
- -
- aplicaciones del codificador-descodificador de audio y perfiles de RTP,
- -
- posibilidad de modelar las restricciones de correlación de calidad de servicio y las restricciones de sincronización en el tiempo en cualquier nivel de abstracción, para una imposición local del dispositivo de terminal dado o para delegar esto en un componente de tercer abonado (por ejemplo, puente de conferencia),
- -
- manejo de escenarios de negociación asistida por tercer abonado, y
- -
- manejo de información de codificador-descodificador de video.
Los dos documentos "Transporte de información
orientado a la conexión en SDP" (IETF MMUSIC Working Group,
trabajo en marcha,
<draft-ietf-mmusic-sdp-comedia-01.txt>)
de D. Yon, designado [SDPCO01] en lo siguiente, y [SDPNG03]
identifican la necesidad de definir cuales de los abonados de
comunicación están con respecto al modo de conexión (emisor,
receptor o emisor-receptor). Adicionalmente,
[SDPCO01] identifica la necesidad de indicar que un solo puerto
podría ser usado para emisión o recepción de los medios de
información codificados diferentemente con el mismo contenido. Esta
definición respectiva con SDP es problemática debido a la estructura
plana del protocolo, por otra parte, SDPng como se describe en
[SDPNG03] con un esquema de XML puede realizar referencias cruzadas
para la descripción respectiva. Para las necesidades de
negociaciones de calidad de servicio, la identificación de los
abonados emisor y/o receptor puede servir para la aceleración de la
negociación eligiendo el modo de negociación más apropiado
(empujar, tirar o empujar-tirar).
El autor de [SDPCN00] propone un conjunto de
ampliaciones de SDP que proporcionan un mecanismo de negociación de
capacidades mínimo y compatible hacia atrás. [SDPCN00] añade
ampliaciones de SDP solo para negociación de capacidades.
En "Atributo de capacidades de
codificadores-descodificadores para SDP" (IETF
Internet Draft, trabajo en marcha,
<draft-beser-mmusic-capabilities-00.txt>)
de B. Beser, designado [Beser00] en lo siguiente, el autor amplia
SDP de modo que los puntos finales conocen las elecciones de
codificadores-descodificadores y pueden ponerse de
acuerdo en un conjunto común. El socio de comunicación puede obtener
así las capacidades y preferencias de iniciadores. Sin embargo, la
solución propuesta en [Beser 00] solo proporciona las ampliaciones
de SDP necesarias para que los puntos finales negocien
codificadores-descodificadores.
en "Descripción de capacidades para cooperación
de grupo" (IETF Internet Draft, trabajo en marcha,
<draft-ott-mmusic-cap-00.txt>)
de J. Ott y otros, designado [Ott99] en lo siguiente, es dada una
notación para describir configuraciones potenciales y específicas
de sistemas finales en sesiones de colaboración
multi-abonado. Esto habilita mecanismos para
definir capacidades de sistemas finales, calcular un conjunto de
capacidades comunes y expresar una descripción de medios de
información seleccionados para uso en descripciones de sesiones. No
proporcionan un protocolo para intercambio de capacidades. Sin
embargo, la solución propuesta en [Ott99] solo proporciona una
notación para descripción de configuraciones.
En "Protocolo de control de conferencia
sencilla" (IETF Internet Draft, trabajo en marcha,
<draft-ietf-mmusic-sccp-01.txt>)
de C. Bormann y otros, designado [Bor00] en lo siguiente, los
autores definen servicios para un protocolo de control de
conferencia sencilla (SCCP: simple conference control protocol) para
conferencias acopladas estrechamente. Son definidas reglas de
gestión de miembros, gestión de aplicación/sesión y control de
acceso para recursos distribuidos de aplicaciones. El estado de la
conferencia, que podría ser establecido usando el SIP, es gestionado
durante el tiempo de vida usando el SCCP. Esto incluye hallar las
configuraciones apropiadas, negociar para configuraciones y cambiar
la configuración. Sin embargo, no se pretende la interacción con la
gestión de recursos locales y de red. El SCCP tampoco cubre el
manejo de contratos de calidad de servicio ni como prenegociar sus
configuraciones.
El documento "El intermediario de calidad de
servicio" (IEEE Multimedia Magazine, primavera de 1.995
(2)1, páginas 53-67) de K. Nahrstedt y J. M.
Smith, designado [Nahr95] en lo siguiente, presenta un modelo para
una arquitectura de puntos finales basada en un intermediario de
calidad de servicio, que es una entidad funcional que orquesta los
recursos en los puntos finales y coordina la gestión de recursos a
través de capas. Para configurar el sistema apropiadamente, el
intermediario usa negociación y control de admisión. La negociación
entre entidades de iguales produce una configuración válida que
implica todos los componentes necesarios del sistema de
comunicación. Sin embargo, el modelo descrito en [Nahr95] no
integra los protocolos de Internet existentes ni considera otros
recursos como alimentación por batería o disponibilidad de subredes
inalámbricas.
En "Exigencias de SIP para soporte de
multimedia y video" (IETF Internet Draft, trabajo en marcha,
<draft-levin-sip-for-video-00.txt>)
de O. Levin, designado [Levin01] en lo siguiente, presenta un
conjunto de exigencias para un protocolo de control de llamada para
soporte multimedia en tiempo real sobre IP. Las capacidades han de
ser expresadas, las capacidades han de ser señalizadas para
identificar la cantidad de recursos que son necesarios, y un
mecanismo de control de llamada es necesario para abrir/
cerrar/modificar los flujos de información dentro de los límites
expuestos por capacidades y recursos reservados. Asimismo, proponen
anunciar capacidades nuevas (si están disponibles) durante una
sesión. Además, los iguales tienen que ponerse de acuerdo sobre un
conjunto común de codificadores-descodificadores
para ser usados. Un mecanismo de control de sesión para
iniciar/parar los flujos de información es declarado como una
exigencia.
Sin embargo, [Levin01] no considera la
integración de la gestión de recursos locales, remotos y de red en
un marco coherente; más bien, [Levin01] solo proporciona
exigencias. No son propuestos protocolos ni mecanismos para imponer
las exigencias.
En los documentos
- -
- "Conceptos para adaptación de servicios, variabilidad de escala y manejo de calidad de servicio en redes con movilidad habilitada" [BRAIN],
- -
- "Soporte de calidad de servicio para un sistema todo IP más allá de tercera generación (3G)" (IEEE Communications Magazine, agosto de 2.001, Volumen 39, Número 8) de T. Robles, A. Kadelka, H. Velayos, A. Lappetelainen, A. Kassler, H. Li, D. Mandato, J. Ojala y B. Wegmann, designado [Roble01] en lo siguiente,
- -
- "BRENTA - Soportar la movilidad y la calidad de servicio para comunicación multimedia adaptable" (en Proceedings of the 1st Mobile Communications Summit 2000, Galway, Irlanda, octubre de 2.000, páginas 403-408) de A. Kassler y otros, designado [Kass100] en lo siguiente, y
- -
- "Una arquitectura abierta de sistemas finales para servicios multimedia adaptables con soporte de calidad de servicio" (en: Proceedings of the BRAIN Workshop, Londres, 2.000), de A. Kassler y otros, designado [Kass100a] en lo siguiente,
ha sido presentada una arquitectura
de sistemas finales que integra la reserva de recursos locales, de
iguales y de red dentro de un marco para gestión de calidad de
servicio de extremo a extremo, en la que las preferencias de
usuarios y los trayectos de adaptación son usados junto con estados
de calidad de servicios para negociar la calidad de servicio al
nivel de aplicación. Es introducida la interacción con la gestión de
recursos locales. La arquitectura en capas proporciona soporte para
tipos diferentes de
aplicaciones.
Los tres documentos
- -
- "Conceptos para adaptación de servicios, variabilidad de escala y conceptos de calidad de servicio en redes con movilidad habilitada" (IST Global Summit 2001, Barcelona, septiembre de 2.001, páginas 285-293) de D. Mandato, A. Kassler, T. Robles, G. Neureiter, designado [Manda00] en lo siguiente,
- -
- "Manejar la calidad de servicio de extremo a extremo en entornos de operación en red heterogénea móvil", (PIMRC2001, San Diego, 30/9/2.001 a 3/10/2.001, páginas c-49 a C-54) de D. Mandato, A. Kassler, T. Robles y G. Neureiter, designado [Manda00a] en lo siguiente, y
- -
- "Agrupamiento de líneas de medios de información en SDP" (IETF Internet Draft, trabajo en marcha, <draft-ietf-mmusic-fid-04.txt>) de G. Camarillo y otros, designado [Cama01] en lo siguiente,
tratan la posibilidad de
agrupamiento de flujos de información pero no consideran criterios
para el agrupamiento, la posibilidad de construcción de grupo
recurrente (un grupo de muchos grupos) y el tratamiento de flujos
de información en tiempo real, tiempo pseudo-real y
tiempo no real que también pueden ser agrupados. Además, [Manda00]
y [Manda00a] definen pasos de negociación que pueden funcionar o no
de una vez, pero no fases independientes y no tienen exigencia para
la consistencia de la información de calidad de servicio negociada
durante una fase de negociación y después de ella. De este modo, en
[Manda00] son descritos los conceptos de núcleo del E2ENP. El
tratamiento de aplicaciones en colisión del "principio de
economía" tampoco es considerado. Además, [Manda00] y [Manda00a]
describen la posibilidad de disponer y gestionar trayectos de
adaptación para la adaptación de calidad de servicio, que es
controlada por un componente de tercer abonado (intermediario de
calidad de servicio). No es considerada la posibilidad de que los
abonados finales realicen y controlen las negociaciones por
sí
mismos.
mismos.
En "Un marco para calidad de negociación de
servicios percibida por usuarios de extremo a extremo" (IETF
Internet Draft, trabajo en marcha,
<draft-bos-mmusic-sdpqos-framework-00.txt>)
de L. Bos y otros, designado [Bos01] en lo siguiente, es descrita
una negociación de calidad de servicio percibida por usuarios de
extremo a extremo con la suposición de que algunos componentes
intermedios y servicios pueden estar implicados fuertemente en la
decisión final sobre la información de calidad de servicio
negociada de los iguales finales. Como se describe, la decisión
puede ser tomada sobre algunos "tipos de contrato" estándares.
Aunque se menciona que la señalización y el trayecto de datos
pueden ir por caminos diferentes a través de la red, se sugiere que
algunos componentes intermedios en el camino del trayecto de
negociación pueden influir en la negociación aunque, en general, no
tienen nada que ver con los trayectos de datos. Mediante este
modelo de protocolo, la red no es transparente. El proceso de
negociación según [Bos01] es realizado de una vez intercalando
también con alguna información no de calidad de servicio (por
ejemplo, seguridad, entrada a la red, etc.), no se consideran la
modularidad de protocolo ni la consistencia de la información con
respecto a la calidad de servicio. Con el modelo de [Bos01], solo
es posible usar modo de empujar para la negociación, lo que puede
ser restrictivo para algunas aplicaciones y servicios. Los
trayectos de adaptación solo son degradantes ("trayecto de
degradación") y fijos (no hay posibilidad de realizar
transiciones diferentes entre los contratos de calidad de servicio
acordados). El modelo de [Bos01] sugiere negociaciones de calidad de
servicio solo en el nivel de flujo de información sin considerar
algunas dependencias de flujos de información como grupos y
jerarquías de flujos de información.
En "Cuestiones fundamentales respecto a la
calidad de servicio de extremo a extremo" (trabajo en marcha,
<draft-bergsten-e2eqos-questions-00.txt>)
de A. Bergsten, K. Nemeth, I. Cselenyi y G. Feher, designado
[Berg01] en lo siguiente, es propuesta una lista de cuestiones
clave (en efecto, exigencias reales). Más específicamente, "1) el
intercambio de información relacionada con la calidad de servicio y
2) de decisiones relacionadas con la calidad de servicio" son
indicadas como "mejoras necesarias para proporcionar calidad de
servicio previsible de extremo a extremo". El E2ENP satisface
estas dos exigencias en tanto que
- -
- define un protocolo a nivel de aplicación que se ocupa de la primera exigencia, y
- -
- impone la gestión de recursos según el principio de economía.
Más específicamente, con respecto a la segunda
exigencia, el E2ENP supone la existencia de la Extended Socket
Interface (ESI), descrito en [BRAIN] y [Roble01], en la que los
detalles de la gestión de recursos de red están ocultos para las
aplicaciones. Esto significa que la ESI ofrece un nivel de
abstracción sobre el que pueden ser construidas aplicaciones y
software intermedio (middleware) consciente de la calidad de
servicio. Sin embargo, si la ESI no está disponible, el E2ENP supone
que las aplicaciones y/o el software intermedio (middleware) serán
capaces de obtener contratos de calidad de servicio a nivel de red
a partir de contratos de calidad de servicio de alto nivel, así como
usar información monitorizada de bajo nivel para activar mecanismos
de adaptación de calidad de servicio en aplicaciones y/o software
intermedio (middleware).
Más específicamente, en [Berg01] son mencionados
los cinco puntos siguientes:
- 1.
- "La red de acceso: La probabilidad de congestión es la máxima en la red de acceso, así que es muy probable que sea necesario aquí alguna clase de mecanismo soportando la información de calidad de servicio". Esta es exactamente la hipótesis efectuada en [BRAIN], [Roble01] (de la que procede el concepto original de E2ENP), en la que la abstracción de ESI permite aplicaciones y/o middleware (influenciando el E2ENP), no solo para usar en general cualquier clase de arquitectura de red disponible sin también (más particularmente) para efectuar una hipótesis similar referente a la red de acceso.
- 2.
- "Señalización de extremo a extremo entre aplicaciones: Debe suponerse que un intercambio de información de alto nivel debe ser el primero de la iniciación de sesión de calidad de servicio en varios casos". Esta es exactamente una de las exigencias que señala el E2ENP. Además, el E2ENP se ocupa de prenegociaciones proactivas de contratos alternativos de calidad de servicio y también de contratos de calidad de servicio a nivel superior. Además, el E2ENP ofrece adicionalmente un conjunto completo de procedimientos para manejar renegociaciones.
- 3.
- "Comunicación interdominios, particularmente en enlace entre iguales: Es necesario un anuncio de servicio automático, algo como BGP (Border Gateway Protocol), pero con mejoras de calidad de servicio. Además, es importante tener un mecanismo que proporcione realmente aprovisionamiento interdominios de estos recursos". El E2ENP es un protocolo puro a nivel de aplicación de extremo a extremo en el que solo los iguales (y finalmente algunos componentes intermedios como puentes de conferencia o transcodificadores) están implicados directamente. La funcionalidad de nivel inferior, que se ocupa del encaminamiento y la gestión de recursos de red intradominio y/o interdominios, está oculta para el E2ENP, gracias a la Extended Socket Interface (ESI), o abstracción equivalente. Esto significa que el E2ENP es un protocolo puro a nivel de aplicación, que los iguales pueden usar para comunicar sobre cualquier arquitectura de red.
- 4.
- "Identificar que cliente penalizar en el caso de una congestión de red: Cuando ocurre una congestión grave y un contrato ha de ser incumplido, debería ser bajo el control de la red". El E2ENP es compatible con esta exigencia puesto que el E2ENP supone que la detección de violación de calidad de servicio es llevada a cabo por la arquitectura de red fundamental.
- 5.
- "Proporcionar información de exigencias para clientes: Los clientes podrían informar a los proveedores de servicios sobre la utilización actual y pretendida de red, especificando por ejemplo los volúmenes de tráfico y los destinos previstos. Entonces, el operador podría usar este conocimiento para dimensionar mejor su red, y también para calcular la cantidad de servicios a comprar de los operadores vecinos". Esta es exactamente la hipótesis efectuada en [BRAIN] y [Roble01], de la que procede el concepto original de E2ENP. Más específicamente, los usuarios pueden no solo proporcionar la "utilización actual y pretendida de la red, especificando por ejemplo los volúmenes de tráfico y los destinos previstos" en términos de contratos de calidad de servicio a nivel de aplicación prenegociados con el proveedor de red (durante el proceso descrito después), sino también intercambiar con iguales conjuntos recontratos alternativos de calidad de servicio (los trayectos de adaptación (APs)), y en niveles diferentes de abstracciones, a fin de tener en cuenta las relaciones entre flujos de información (con APs también).
Finalmente, en [Berg01] es descrita la necesidad
de tener iguales que se ponen de acuerdo con sus proveedores de red
sobre el tipo de calidad de servicio junto con información de
tarificación, antes de cualquier establecimiento de sesión. Esto es
similar al proceso descrito anteriormente, donde el usuario
especifica la información de calidad de servicio a nivel de
aplicación que finalmente es hecha corresponder con contratos de
calidad de servicio a nivel de red validados respecto a
predisposiciones con el proveedor de red, o por vía de comunicación
directa con el último. Como estos procesos de bajo nivel son
efectuados está en el alcance de E2ENP, gracias a la abstracción de
ESI (o funcionalidad similar).
Los tres documentos
- 1.
- "Conferencia usando el SIP" (IETF Internet Draft, trabajo en marcha, <draft-khartabil-sip-conferencing-00.txt>) de H. Khartabil, designado [Khart01] en lo siguiente,
- 2.
- "Modelos para conferencia multi-abonado en SIP" (IETF SIPPING Working Group, trabajo en marcha, <draft-rosenberg-sip-conferencing-models-01.txt>) de J. Rosenberg y H. Schulzrine, designado [Rosen01] en lo siguiente, y
- 3.
- "Modelos para conferencia multi-abonado en SIP" (IETF SIPPING Working Group, trabajo en marcha, <draft-ietf-sipping-conferencing-models-00.txt>) de J. Rosenberg y H. Schulzrine, designado [Rosen00a] en lo siguiente,
introducen modelos para conferencia
multi-abonado que consideran escenarios como
conexiones de uno con muchos y de muchos con muchos. Los modelos
descritos aprovechan una arquitectura centralizada usando servidor
de conferencia. En este caso, no hay comunicación directa de
extremo a extremo entre los iguales finales y la aplicación de
E2ENP podría ser realizada de varios modos
diferentes:
- -
- señalización directa entre los iguales finales, trayecto de datos por el servidor de conferencia,
- -
- señalización indirecta entre los iguales finales por el servidor de conferencia, conexión directa de datos entre los iguales finales, y
- -
- señalización indirecta entre los iguales finales por el servidor de conferencia y trayecto de datos por él.
Tal aplicación de E2ENP puede precisar secuencias
de mensajes y estructura de E2ENP diferentes para cada escenario
diferente. Los modelos de [Khart01], [Rosen01] y [Rosen00a] están
interesados principalmente en la descripción de las secuencias de
mensajes por un escenario de conferencia que usan un componente
centralizado. Mediante negociaciones necesarias de capacidades y/o
calidad de servicio y reservas respectivas, estas secuencias pueden
experimentar cambios si E2ENP también debería ser aplicado a tales
escenarios. La ventaja de la aplicación de E2ENP en un escenario con
algunos componentes centralizados es que el modelo de comunicación
puede ser reducido al escenario de uno con muchos.
En lo siguiente deber ser proporcionadas un
número de expresiones necesarias para la definición de las
reivindicaciones y la descripción de la invención fundamental.
- -
- Trayecto de adaptación: Un conjunto ordenado de contratos de calidad de servicio que indican preferencias y deseos específicos de usuarios que pueden ser usados para permitir que las aplicaciones y/o el middleware adopten estrategias de adaptación de un modo planificado previamente. Típicamente, el contrato más importante de calidad de servicio (o sea, el contrato que el sistema debería intentar imponer por omisión) es el primero indicado en el trayecto. Adicionalmente, un trayecto de adaptación puede incluir la especificación de reglas que definen las circunstancias en las que el sistema debería imponer un contrato diferente de calidad de servicio, a partir del conjunto dado de ellos.
- -
- Asociación: Un grupo de flujos de información asociados con un igual dado. Como subcaso de agrupamiento de flujos de información, una asociación agrupa todos los flujos de información procedentes de, y/o terminado en, el dispositivo de terminal de usuario dado, y conectando con un igual dado dentro de la sesión dada. Por tanto, la especificación de una asociación debe incluir un identificador del igual (por ejemplo, un localizador uniforme de recursos (URL), un número de teléfono o un par de dirección de IP y número de puerto).
- -
- Contestador: El contestador es un participante en una sesión de SIP que genera una respuesta a una descripción de sesión multimedia propuesta de un ofertante (véase después). La respuesta contiene una descripción de las condiciones en las que puede ser soportada la descripción de sesión propuesta del ofertante [SOPOA00].
- -
- Trayectos de adaptación de grupos o asociaciones: Modelado como un trayecto de adaptación, una configuración de asociaciones o grupos alternativos junto con sus contextos de calidad de servicio y contratos de calidad de servicio a nivel de flujo, pueden ser usados para permitir que aplicaciones y/o middleware adopten estrategias de adaptación de un modo planificado previamente.
- -
- Capacidad: Asociada con el perfil de hardware y/o software de un dispositivo de terminal, una capacidad describe la aptitud de este dispositivo para realizar ciertas tareas y/o manejar ciertos tipos de información. Una sola capacidad puede estar asociada con una cierta cantidad de recursos de hardware y/o software (cada uno manejando un tipo de información dado). Una capacidad asociada con un tipo único dado de información puede ser usada para presentar esta información en uno o muchos niveles de calidad de servicio. Por otra parte, un nivel dado de calidad de servicio puede estar asociado con conjuntos de capacidades diferentes (por ejemplo, codificadores-descodificadores diferentes pueden producir uno y el mismo nivel de calidad de servicio como se ve desde la aplicación).
- -
- Modo de conexión: El modo de conexión se refiere a un flujo de información de datos reales intercambiado por los iguales. Esta información es el medio de información (audio, video, etc.) directamente perceptible por el usuario final. El modo de conexión expresa quienes son los abonados emisores y quienes son los abonados receptores de los flujos de información.
- -
- Trayecto de datos: El trayecto de red tomado por los datos de medios de información (audio, video, texto, etc.).
- -
- Principio de economía: el principio de economía dicta el orden de la reserva de recursos. Como los recursos de red son compartidos y así son más caros que los recursos de terminales, es mejor reservar primero recursos en todos los terminales y después proseguir con la reserva de recursos de red.
- -
- Prenegociación de calidad de servicio de extremo a extremo: un proceso que los iguales finales pueden realizar antes del comienzo real de una sesión, e independientemente de la propia sesión, para intercambiar (de una manera no obligada) información sobre las configuraciones de especificaciones de calidad de servicio, deducida de sus perfiles de calidad de servicio. Estas configuraciones incluyen trayectos de adaptación de modo que los iguales finales pueden ponerse de acuerdo proactivamente sobre el modo de reaccionar a posibles cambios de calidad de servicio o violaciones de calidad de servicio de una manera eficaz y eficiente. El intercambio de mensajes de prenegociación tiene carácter informativo para los iguales finales, y es usado no solo para informar entre sí por adelantado sobre las capacidades y las posibilidades de rendimiento funcional aplicables al conjunto dado de iguales sino también para alcanza acuerdos sobre redefinir algunas de esas configuraciones. De este modo, los iguales son capaces así de establecer un vocabulario común, a priori, de cualquier negocio específico. Los resultados de este proceso son observados en el tiempo y pueden ser usados varias veces dentro de su intervalo de validez.
- -
- Negociación compacta de calidad de servicio de extremo a extremo: Un proceso que los iguales finales pueden realizar antes de, o en el comienzo real de, una sesión para ponerse de acuerdo sobre un nivel dado de calidad de servicio a ser impuesto para la sesión y los flujos de información dados, basado en resultados de un proceso de prenegociación de calidad de servicio de extremo a extremo aplicado previamente (suponiendo que la validez de esos resultados se aplica todavía en el momento que este proceso es ejecutado). Este proceso es considerablemente más rápido comparado con el caso de la negociación completa de calidad de servicio de extremo a extremo puesto que solo referencias de información prenegociada son intercambiadas realmente entre los iguales. Al completar el proceso de negociación compacta de calidad de servicio de extremo a extremo, los iguales finales se han puesto de acuerdo sobre los perfiles de calidad de servicio que van a usar para la comunicación.
- -
- Negociación completa de calidad de servicio de extremo a extremo: Un proceso que los iguales finales pueden realizar antes de, o en el comienzo real, de una sesión para ponerse de acuerdo sobre un nivel dado de calidad de servicio a imponer para la sesión y los flujos de información dados, redefiniendo finalmente algunas de las configuraciones propuestas originalmente de especificaciones de calidad de servicio. Al completar el proceso de negociación compacta de calidad de servicio de extremo a extremo, los iguales finales se han puesto de acuerdo sobre los perfiles de calidad de servicio que van a usar para la comunicación.
- -
- Renegociación compacta de calidad de servicio de extremo a extremo: Un proceso que los iguales finales pueden activar al detectar un cambio de calidad de servicio o una violación de calidad de servicio para ponerse de acuerdo sobre un nivel dado de calidad de servicio a ser impuesto para la sesión dada, basado en los resultados de un proceso de prenegociación de calidad de servicio de extremo a extremo aplicado previamente (suponiendo que la validez de esos resultados se aplica todavía en el momento que este proceso es ejecutado). Este proceso es considerablemente más rápido comparado con el caso del proceso de renegociación completa de calidad de servicio de extremo a extremo puesto que solo referencia de información prenegociada son intercambiadas realmente entre iguales. Al completar el proceso de renegociación compacta de calidad de servicio de extremo a extremo, los iguales finales se han puesto de acuerdo sobre nuevos perfiles de calidad de servicio que van a usar para la comunicación.
- -
- Renegociación completa de calidad de servicio de extremo a extremo: Un proceso que los iguales finales pueden activar al detectar un cambio de calidad de servicio o una violación de calidad de servicio para ponerse de acuerdo sobre un nivel dado de calidad de servicio a ser impuesto para la sesión y los flujos de información dados, redefiniendo finalmente algunas de las configuraciones propuesta originalmente de especificaciones de calidad de servicio. Al completar el proceso de renegociación completa de calidad de servicio de extremo a extremo, los iguales finales se han puesto de acuerdo sobre nuevos perfiles de calidad de servicio que van a usar para la comunicación.
- -
- Caudal: Un caudal es un conjunto de paquetes que pasan por un punto de observación en la red durante un cierto intervalo de tiempo. Todos los paquetes pertenecientes a un caudal particular tienen un conjunto de propiedades comunes obtenidas de los datos contenidos en el paquete y del tratamiento de paquete en el punto de observación como se describe en "Exigencias para exportación de información de caudal de IP" (véase <draft-ietf-ipfix-reqs-00.txt>) de J. Quittek y otros, designado [Quit00] en lo siguiente. Como un ejemplo, todos los paquetes para un caudal dado deberían tener el mismo quinteto (identificador de protocolo, dirección de red de origen, dirección de red de destino, número de puerto de origen, número de puerto de destino). Los flujos de información sencillos (o sea, esos sin capas multiplexadas) y las capas son hechas corresponder con en caudales en la capa de transporte, donde son usados para reserva. Un caudal puede transportar una capa de un flujo dado de información o un flujo sencillo dado de información en conjunto.
- -
- Grupo de flujos de información: Basados en diversos criterios, los flujos de información pueden ser agrupados lógicamente para imponer algunas restricciones, por ejemplo, agrupar todos los flujos de información de audio para imponer la traducción, agrupar todos los flujos de información abiertos por un usuario dado en un terminal de usuarios múltiples para imponer cuotas. Un grupo también puede contener un solo flujo de información. Los grupos son útiles para representar haces de flujos de información, que las aplicaciones conscientes de calidad de servicio pueden manejar como un todo cuando se cambia calidad por disponibilidad de recursos, entre una multiplicidad de haces equivalentes y dentro de un contexto dado de calidad de servicio. Cada grupo está asociado con un contexto de calidad de servicio.
- -
- Componentes intermedios: Los componentes intermedios son cualesquier componentes de red situados en el trayecto de señalización y/o el trayecto de datos entre dos dispositivos finales (terminales), que pueden comprender el protocolo pasante que los dispositivos finales usan el menos en el nivel de red. Los componentes intermedios pueden ser encaminadotes, proxies, servicios independientes, partes de un intermediario, etc. Los componentes intermedios forman la red entre los iguales finales.
- -
- Capa: Los flujos de información pueden ser codificados en capas múltiples, donde cada capa aumenta por incrementos el nivel de detalle relativo a la información base dada (transportada por la denominada "capa base"). Esto significa que añadir capas puede incrementar progresivamente el nivel de detalle de la información base. Cada capa puede ser hecha corresponder con un caudal dado.
- -
- Modo de negociación: el modo de negociación se refiere al trayecto de señalización y a la información de negociación usados por los iguales para intercambiar información sobre la gestión y el control de los flujos de información de datos. El modo de negociación expresa quienes son los abonados ofertantes y quienes son los abonados contestadores por la negociación.
- -
- Mediador: El mediador es una funcionalidad de un igual para reorientar llamadas entrante a uno o más otros iguales según algunos preajustes de perfil del usuario y/o el proveedor de servicios del igual respectivo con tal funcionalidad de facilitación.
- -
- Ofertante: El ofertante es un participante de una sesión de SIP que generó una descripción de sesión multimedia que el ofertante desea usar abriendo la sesión multimedia. Esta descripción es transportad al contestador (véase lo anterior) [SDPOA00].
- -
- Igual: Un servicio o un dispositivo final asociado con un usuario final.
- -
- Calidad de servicio: El efecto colectivo de rendimiento funcional de servicio que determina el grado de satisfacción de un usuario del servicio según una definición de la Recomendación E.800 del ITU-T (anterior CCITT). De este modo, la calidad de servicio puede ser descrita para cada servicio con un conjunto de parámetros que caracterizan el servicio. Como un ejemplo, para un servicio de videoconferencia, la calidad de servicio puede ser definida como calidad de servicio global de extremo a extremo como es observada por el usuario final, que puede ser medida por parámetros como la frecuencia de cuadros, la calidad visual y el retardo.
- -
- Cambio de calidad de servicio: El cambio del contrato de calidad del servicio iniciado por el usuario del servicio.
- -
- Contexto de calidad de servicio: Un contexto de calidad de servicio identifica una disposición de parámetros de calidad de servicio que deben ser impuestos en todo un conjunto dado de flujos de información. Un contexto de calidad de servicio es una entidad lógica modelada como una especialización del concepto de contrato de calidad de servicio.
- -
- Contrato de calidad de servicio: Acuerdo entre un usuario y un proveedor de servicios dado, especificando las exigencias y las restricciones de calidad de servicio, así como las directrices necesarias para mantenerse al tanto de la calidad de servicio durante todas las fases de dicho servicio. Los contratos de calidad de servicio generalizan el concepto de contratos de calidad de servicio a nivel de flujo de información y de contratos a nivel superior, los denominados contextos de calidad de servicio. Esto significa que los contratos de calidad de servicio pueden ser organizados en una estructura jerárquica.
- -
- Tipo de contrato de calidad de servicio: Capta la estructura de una clase de contratos de calidad de servicio, identificando como los contratos individuales de calidad de servicio especifican las propiedades de calidad de servicio sobre un conjunto dado de tipos de parámetros de calidad de servicio, también conocidas como dimensiones en "QML (Quantum Markup Language): un lenguaje para especificación de calidad de servicio" (HP-Lab Technical Reports, HPL-98-10, 980210) de S. Frolund y J. Koistinien, designado [Frolu98] en lo siguiente. Cada tipo de parámetro consiste en un nombre y un dominio de valores. Las especificaciones de calidad de servicio pueden ser propuestas simplemente como un conjunto de restricciones sobre dichos dominios, una por tipo de parámetro.
- -
- Nivel de calidad de servicio: El espacio multidimensional de calidad de servicio de parámetros que caracteriza a un servicio puede ser dividido en subespacios discretos múltiples. Un subespacio dado es indicado como nivel de calidad de servicio y debe ser distinguible de otro nivel de calidad de servicio por el usuario de servicio. Un contrato de calidad de servicio describe un nivel específico de calidad de servicio y es usado para aplicar tal nivel en el caso de que tenga lugar renegociación. En otras palabras, los usuarios perciben los niveles de calidad de servicio como el resultado de aplicar ciertos contratos de calidad de servicio a los servicios dados. Sin embargo, podría haber algunas divisiones predefinidas naturales específicas de aplicación o específicas de negocio del espacio de calidad de servicio, en el que los usuarios pueden hacer corresponder entonces sus propios contratos de calidad de servicio con niveles de calidad de servicio (pertenecientes a la división dada) en diversos grados (uno a uno, intersección, granularidad diferente, etc.).
- -
- Parámetro de calidad de servicio: Un parámetro de calidad de servicio es una representación funcional de una sola característica de un servicio dado (como un ejemplo, el retardo global de extremo a extremo).
- -
- Siguiendo las definiciones expuestas en "Tecnología de Información - calidad de servicio: marco" (Recomendación X-641 de ITU-T, 12/97, ISO/IEC 13236: 1998), designado [ISOX641] en lo siguiente, los parámetros de calidad de servicio (las características de calidad de servicio en terminología ISO) se identifican cantidades medibles relacionadas con la calidad de servicio y pueden ser clasificados además en parámetros genéricos, especializados y derivados:
- \blacklozenge
- Los parámetros genéricos de calidad de servicio intentan captar un parámetro subyacente común de calidad de servicio que puede ser aplicado a cualquier circunstancia particular, independientemente así de a lo que es aplicado.
- \blacklozenge
- Los parámetros especializados de calidad de servicio son casos concretos de características genéricas de calidad de servicio (finalmente, las características genéricas de calidad de servicio pueden ser suficientemente concretas para ser usadas como son pero, en la mayoría de los casos, una especialización es necesaria para captar la peculiaridad específica de sistema o de red). Por ejemplo, una característica genérica de retardo de tiempo en calidad de servicio puede ser especializada más a fin de reflejar cuestiones específicas de implementación del sistema. El método de especialización es adecuado para dirigirse a sistemas distribuidos complejos, haciendo corresponder características de calidad de servicio en niveles apropiados de abstracciones.
- \blacklozenge
- Los parámetros derivados de calidad de servicio captan las dependencias entre características de calidad de servicio, basadas en relaciones matemáticas. Algunas características derivadas de calidad de servicio incluso pueden ser de naturaleza estadística (por ejemplo, máximo, mínimo, margen, valor medio, varianza y, desviación típica, percentil-n, momentos estadísticos, etc.). Incluso los parámetros derivados de calidad de servicio pueden ser especializados de modo muy parecido que los parámetros genéricos. Por tanto, la especialización y las derivaciones pueden ser consideradas como transformaciones ortogonales de características de calidad de servicio. Sin embargo, debe observarse que la derivación puede implicar más de una característica genérica/derivada/especializada de calidad de servicio (por ejemplo, la disponibilidad es una función de la fiabilidad y la mantenibilidad).
- -
- Perfil de calidad de servicio: Una colección de datos que especifican preferencias de usuarios finales en términos de calidad de servicio, referentes al uso de un servicio dado. Los perfiles de calidad de servicio pueden ser almacenados en el dispositivo de terminal de usuario o en bases de datos específicas.
- -
- Especificación de calidad de servicio: Expresión general para identificar un conjunto de parámetros y restricciones de calidad de servicio especificados por un usuario para un servicio dado.
- -
- Violación de calidad de servicio: La violación de un contrato de calidad de servicio causada por el proveedor de servicios.
- -
- Sesión: Un conjunto de conexiones duraderas entre dos o más iguales (servidores o dispositivos finales de usuarios), implicando usualmente el intercambio de muchos paquetes de "información asociada" (la información de una sesión concierne a un cierto tópico) entre los iguales. Según "Protocolo de descripción de sesión (SDP)" (IETF Request for Comments: 2327, abril de 1.998) de M. Handley y V. Jacobson, designado [Handl98] en lo siguiente, una sesión multimedia es "un conjunto de emisores y receptores multimedia y los flujos de información de datos que circulan desde emisores a receptores. Una conferencia multimedia es un ejemplo de una sesión multimedia". Aquí, son reconocidos dos tipos de sesión con respecto a su contexto:
- \blacklozenge
- Sesión de información - La sesión de información tiene el contexto de transferir datos perceptibles por el usuario entre iguales.
- \blacklozenge
- Sesión de señalización - La sesión de señalización tiene el contexto de negociación de ajustes y permanencias de sesión de información generalmente invisibles para el usuario final. Los protocolos SIP, SCCP, etc. pueden ser usados para realizar una sesión de señalización. La sesión de señalización es visible para la aplicación y puede resultar visible para el usuario solo si la aplicación requiere alguna intervención de usuario o generación de sucesos por usuario (por ejemplo, hacer aparecer una ventana de interfaz gráfica de usuario (GUI) con la exigencia de pulsar una u otra tecla virtual).
Debería observarse que algunos protocolos (por
ejemplo: el RTP - Real Time Transfer Protocol) pueden transportar
tanto los datos de información como la descripción de información,
realizando así en paralelo la transferencia de información y la
señalización.
- -
- Trayecto de señalización: El trayecto de red tomado pro los mensajes de SIP.
- -
- Flujo de información: El intercambio unidireccional continuo de información entre dos iguales a nivel de aplicación. Pueden existir tipos diferentes de flujos de información: audio, video, datos, texto o cualquier combinación de ellos. Un abonado dado puede actuar como una fuente pura de flujos de información (que envía información exclusivamente), como un sumidero puro de flujos de información (que recoge flujos de información procedentes de otro abonado, tal como un servicio de video a petición), o tanto como fuente de flujos de información y como sumidero de flujos de información (que es típico de un modo de conversación tal como un servicio de videoconferencia). Un flujo de información puede ser hecho corresponder con uno o varios caudales.
En la sección siguiente, deben ser descritos
escenarios de comunicación posibles diferentes que pueden ocurrir en
un entorno multimedia y que se aprovecharán del uso de un
End-to-End QoS Negotiation Protocol
(E2ENP).
La sección introduce primero definiciones clave
de los abonados y los componentes considerados para la comunicación,
así como las estructuras que construyen para formar la arquitectura
de comunicación.
Las arquitecturas descritas están asociadas con
algunos servicios específicos. Son considerados modos de
comunicación diferentes que los participantes usan para negociar la
calidad de servicio. Para definir los casos de uso, son tenidos en
cuenta los aspectos siguientes:
- \bullet
- quienes son los abonados que comunican,
- \bullet
- quién es el iniciador de la conexión,
- \bullet
- cuantos abonados en comunicación participan en un escenario específico de comunicación,
- \bullet
- que clase de estructura construyen dichos abonados en comunicación, y
- \bullet
- que clase de modo de conexión (unidifusión o multidifusión) es aplicado.
Algunos ejemplos son proporcionados finalmente
para mostrar la idea de funcionamiento de los escenarios.
Los abonados en comunicación de sistemas finales
(ofertantes y contestadores) son los componentes activos de
cualquier negociación de extremo a extremo. Según las definiciones
expuestas anteriormente, los ofertantes y los contestadores son
iguales: El ofertante es el abonado que inicia el proceso de
negociación de conexión. Los contestadores son los abonados con los
que hace contacto el ofertante, con los que desea establecer una
conexión. Los diversos abonados pueden desempeñar un papel activo
en la comunicación real, como un emisor (o sea, enviando o
enviando/recibiendo flujos de información), o un papel pasivo como
un receptor (o sea, recibiendo flujos de información).
Otro tipo de abonado de comunicación es el
componente intermedio. Estos componentes pueden diferir en términos
de complejidad en diversos grados y pueden ser empleados en niveles
diferentes de la conexión de red. Los componentes intermedios
pueden ser todos los dispositivos (proxies, encaminador, etc.) y
servicios dentro de la red (por ejemplo, nombramiento, asignación,
presencia, etc.). En este caso, los componentes intermedios solo
son actores pasivos que solo soportan la construcción de la
conexión entre los iguales finales pero no interfiriendo en los
procesos de negociación entre ellos. La hipótesis del E2ENP es que
no hay componentes intermedios que forman parte en el proceso de
negociación, más bien pueden influir en alguna de información
negociada antes o después de que la negociación hay tenido lugar.
Eso es por lo que es necesario considerar componentes intermedios
con respecto a su funcionalidad e influencia en la información
negociada.
Estableciendo una conexión es importante
expresar:
- 1.
- El modo de negociación describe la secuencia de intercambiar información de contratos de capacidades y calidad de servicio y que abonado envía primero su contrato. Hasta este punto, son diferenciados los modos siguientes:
- a.
- El modo de empujar es usado cuando un ofertante hace una oferta al contestador sobre como deberían hacerse los ajustes de conexión y declara por adelantado sus deseos de calidad de servicio y capacidades. El modo de empujar puede ser usado con comunicación de voz sobre IP, como telefónica, de uno con uno.
- b.
- El modo de tirar es usado cuando un ofertante llama al contestador sin declarar deseos sobre los ajustes de conexión. El ofertante recupera esta información desde el contestador y adapta sus deseos sobre el perfil recibido. Este modo puede ser usado para servicios diferentes como "video a petición" o por "disertación virtual" cuando el igual central (servidor de "video a petición" o el conferenciante) define previamente perfiles para ser usados.
- c.
- En algunos casos puede ser necesario usar modo de empujar-tirar siempre que el ofertante no solo hace una oferte sobre los ajustes de conexión al contestador sino que también recupera simultáneamente los ajustes de contestador.
- 2.
- El modo de conexión: El conocimiento de que igual es el emisor y cual es el receptor sirve para establecer cual de los modos de negociación (empujar/tirar) es más razonable usar iniciando una negociación.
- 3.
- La conexión funciona (especialmente en los casos donde hay más de un participante)
- a.
- como una multidifusión a un grupo de abonados receptores,
- b.
- como una unidifusión a cada abonado receptor
- 4.
- El número de los abonados de comunicación es la información que es necesaria para determinar cual de los modos de negociación (empujar/tirar) es más razonable usar y en que secuencia tendrían lugar los subprocesos de negociación. Los abonados de comunicación pueden formar las estructuras de conexión siguientes:
- a.
- Uno con uno: Este puede ser un caso de telefonía entre dos abonados. Un ejemplo de servicio típico aquí es la voz sobre IP (véase ejemplo más adelante).
- b.
- Uno con muchos: Este es el caso de servicio de video a petición o disertación en línea (véase ejemplo más adelante)
- c.
- Muchos con muchos: Un ejemplo típico aquí es la conferencia virtual (véase ejemplo más adelante).
En la sección siguiente deben ser descritos
algunos ejemplos de escenarios de comunicación para reconocer mejor
las necesidades de un protocolo de negociación. Como la
comunicación de igual con igual (uno con uno) muy sencilla ya es
tratada completamente en la literatura [SDPOA00], los escenarios
siguientes consideran algunos modelos de comunicación más
complejos. Los escenarios describen algunas situaciones típicas que
pueden producirse por comunicaciones dinámicas y por conexiones
multi-abonado. Se muestra la influencia de la
movilidad de dispositivos y personas con respecto a redes móviles.
Son introducidas algunas ideas de dependencias de información
posibles y del modo de describir esto. Los ejemplos muestran algunos
aspectos de la comunicación multi-abonado en los
que puede estar implicado el uso de componentes intermedios como
abonados de comunicación pasivos.
El ejemplo representado en la Figura 1 muestra
una reubicación 108 de llamada en una situación de conmutación de
una sesión 102 de telecomunicación para un escenario 100 de
comunicación de uno con uno que exhibe la idea de cómo puede ser
dispuesta la comunicación futura semejante a telefónica. Los dos
usuarios 104a+b implicados en dicho escenario deben ser llamados
Mary y Kate.
Mary recibe, en su reloj 106a1 habilitado para
Internet, una llamada de su amiga Kate que desea informarla sobre su
nuevo novio. La llamada transporta un mensaje que indica "quién
está llamando" (la identificación del abonado que llama) y "de
que trata la llamada" (información del asunto). El reloj 106a1 de
Mary no es capaz de mostrar las imágenes de alta resolución
recibidas 112 puesto que su monitor es muy pequeño y monocromo, así
que inicia automáticamente la búsqueda de un dispositivo 106a2 que
puede hacer eso. Conecta con el servidor central de la casa y
descubre que el perfil de Mary indica que está autorizada a usar un
dispositivo 106a2 de terminal inteligente en su habitación. El
reloj 106a1 establece contacto con el dispositivo 106a2 de
"habitación" para reubicar la sesión 102 e informa a Mary de
que hay una llamada 110 esperándola en su disposición 106a2 de
"habitación". Por esta razón, Mary se desplaza a su habitación
para coger la llamada 110. Mientras tanto, Kate sabe que Mary ha
aceptado su llamada 110 pero necesita algún tiempo para el
procedimiento de reubicación 108. Entonces, esta información es
curvada por un protocolo apropiado. Kate también sabe que Mary será
capaz de aceptar la llamada 110 en un dispositivo 106a2 de terminal
habilitado para video, de modo que serán capaces de intercambiar
las imágenes. Una vez en su habitación, Mary puede acceder a su
dispositivo 106a2 de terminal inteligente para hablar con su
amiga.
- Mary: "¡Hola Kate!. Bien, ¿tienes un nuevo novio?"
- Kate: "Hola, también tengo algunas fotos magníficas de él".
- (Finalmente, Kate es capaz de enviar a Mary unas pocas fotos de alta resolución digitalizadas 112 e incluso unos pocos videoclips cortos de su banda de rock preferida).
Este escenario se refiere al caso de una Red de
Área Personal 604 (PAN: Personal Area Network), en la que una
negociación 806 asistida por tercer abonado de capacidades y
calidad de servicio necesita ser llevada a cabo sobre una base de
extremo a extremo. Esto significa que el reloj 106a1 de Mary debe
ser capaz de negociar de parte del dispositivo inteligente 106a2
descubierto recientemente (mecanismo de proxy).
Alternativamente, el proceso de negociación 806
podría ser llevado a cabo directamente por el dispositivo 106a2 de
"habitación" de Mary con el dispositivo 106b de terminal de
Kate: En este caso, el mecanismo de reubicación 108 trasferiría
completamente el proceso completo de establecimiento de conexión al
nuevo dispositivo 106a2 (mecanismo de reorientar).
Como un subcaso de este escenario 100, por
supuesto también es posible que no sea necesaria en absoluto la
reubicación 108, en el que el proceso de negociación 806 podría ser
llevado a cabo directamente por el reloj 106a1 de Mary con el
dispositivo 106b de terminal de Kate. Tal subcaso corresponde a la
comunicación de uno con uno muy sencilla como se describe en
[SDPOA00]. Este caso es mostrado en la Figura 8 junto con las fases
de negociación del protocolo de señalización.
El ejemplo representado en la Figura 2 muestra
una disertación virtual en una situación de un escenario 200 de
comunicación de uno con muchos en el que están implicados un
conferenciante 202 (profesor T. Martin) y tres estudiantes
204a-c (A, B Y C). De tal modo, debe suponerse que
el profesor T. Martin está asistiendo a una conferencia en Roma
mientras que al mismo tiempo debería tener su programa de
disertaciones habitual en la universidad de Berlín. Ha acordado con
sus estudiantes A, B y C que estaría dando la disertación en línea
aprovechando un espacio libre en el programa de conferencias, y así
ha anunciado que la sesión 102 empezará a las 2:00 de la tarde.
Hasta este punto, el profesor T. Martin ha configurado su ordenador
de habitación del hotel para soportar varios perfiles de emisión
diferentes correspondientes a los dispositivos de sus estudiantes.
A la 1:00 de la tarde, su asistente digital personal (PDA) le
informa que los primeros estudiantes han iniciado una negociación
806 (o 809) para abrir una sesión 102 de conexión con su ordenador
en su habitación del hotel. El profesor T. Martin va a su habitación
y a las 1:55 de la tarde hace una comprobación en mesa redonda de
los participantes A, B y C antes de iniciar finalmente la sesión
102 de disertación. La conexión de disertación transporta
información de identificación como siendo de importancia académica y
eso es por lo que no es cobrada, o los cargos son contabilizados en
una cuenta de la universidad.
Este ejemplo describe el caso de un escenario 200
de comunicación de uno con muchos. Tal clase de comunicación es
equivalente también al caso de un servicio de "video a
petición", con la diferencia principal siendo que en el ejemplo
antes descrito la transmisión es en directo más bien que pregrabada
como en el caso de video a petición. Por tanto, en este ejemplo
cada receptor A, B y C será capaz de recibir solo la misma
información al mismo tiempo (nominalmente).
Como se representa en la Figura 3, el ejemplo
siguiente puede ser tratado como una forma sencilla de una
videoconferencia 1204a/b en un escenario 300 de comunicación de
muchos con muchos en el que están implicados los cuatro usuarios
302a-d (Caroline, Martha, Miranda y una
secretaria).
Debe suponerse que Caroline y Martha son
empleadas de una corporación de diseño de moda en Los Ángeles. Están
trabajando en un proyecto conjunto referente a una colección nueva
con su colega francesa Miranda. Cada semana, las señoras 302
a-c efectúan una videoconferencia 1204 a/b sobre el
estado actual del desarrollo de la colección. Caroline y Martha
envían sus diseños a Miranda para comprobación y aprobación. Como
Miranda está viajando mucho y no tiene tiempo suficiente para
escribir informes bonitos para su jefe, ha autorizado a su
secretaria para disponer su revisión de modelos para preparar una
presentación para el jefe. Cuando la conferencia tiene lugar
finalmente, Miranda, Caroline y Martha pueden empezar a intercambiar
contenido de audio y video así como imágenes y mensajes de texto.
Mientras tanto, la secretaria 302d está escuchando en línea y
tomando las notas de la conferencia así como las observaciones de
Miranda.
Este escenario 300 se aplica al caso de
información procedente de fuentes diferentes. Este es el caso de un
grupo de flujos 206 de información relacionados, en el que los
usuarios pueden precisar la correlación 804 entre los flujos 206 de
información intercambiados (por ejemplo, en el punto final de
secretaría).
Como se representa en la Figura 4, el ejemplo
siguiente incumbe a un escenario 400 de comunicación de muchos con
muchos que muestra un escenario complejo de una videoconferencia
1204a/b en la que están implicados los cuatro usuarios
402a-d (Sussanne Jones, dos examinadores y el señor
Jones).
De tal modo, debe suponerse que Sussanne Jones
está efectuando un examen previo de Doctor en Filosofía abierto al
público y ha invitado a su padre a participar pasivamente en su
sesión 102 de examen en línea, dándole una clave de conexión a
sesión para unirse a la sesión 102 de examen como un oyente 402d.
Ella está haciendo una exposición en línea que es multidifundida a
sus supervisores 402b+c y a un grupo de oyentes. Las disposiciones
iniciales de la sesión 102 son efectuadas entre el terminal 404a de
Sussane y los terminales 404b+c de los supervisores, puesto que los
supervisores 402b+c intercambian notas en línea sobre la exposición
para ser capaces de guiar a Sussane durante su examen real y
señalar los lados positivo y negativo de esta exposición. Las
observaciones son escritas directamente sobre las páginas de
exposición o en una pizarra blanca común. Las notas son conjuntas
con la exposición en marcha y las disposiciones iniciales definen
esta correspondencia (correlación 804).
Tan pronto como las disposiciones iniciales son
satisfechas, el examen comienza. El oyente 402d y los otros oyentes
pueden unirse en un momento posterior puesto que no interfieren con
el examen en marcha como participantes activos. Cualquiera de los
oyentes que se unen a la sesión 102 pueden obtener información sobre
la evaluación actual de la exposición. El terminal 404d del padre
de Sussane se une a la sesión 102 firmando para obtener la propia
exposición y las evaluaciones que proporcionan sus supervisores
402b+c de Doctor en Filosofía. El terminal 404d efectúa las
disposiciones correspondientes con el terminal 404a de Sussane y los
terminales 404b+c de los supervisores 402b+c según los perfiles
prefijados correspondientes a los deseos del padre de Sussane, de
modo que se une a la multidifusión de exposición y obtiene las
evaluaciones como unidifusiones.
Para un curso apropiado de dicho escenario 400,
es necesario tener una noción de cómo agrupar los flujos de
información únicos 206 y quienes son los abonados interesados para
un flujo 206 de información en marcha. En tales escenarios, es
importante definir grupos de participantes y grupos de flujos 206 de
información en una sesión 102. También es posible que sean formadas
estructuras de agrupamiento jerárquicas para comunicación.
Este escenario 400 también muestra que a veces no
solo tráfico en tiempo real sino también tráfico en tiempo no real
deberían ser tratados como tráfico de alta prioridad: Por ejemplo,
el flujo 206 de información de subtítulos que transportan la
traducción en directo del examen para un participante extranjero ha
de ser considerado como en tiempo pseudo-real, en
tanto que si no mantuviera el ritmo con el contenido (o no fuera
entregado en absoluto), no sería de ninguna utilidad. En este caso,
el tráfico en tiempo no real (subtítulos) está asociado en un grado
dado con el tráfico en tiempo real (video en directo).
Dicho escenario 400 también puede ser aplicado a
juegos y conferencias en línea de la red 604 con varios grupos de
trabajo. Considerando la complejidad de tal escenario 400, puede
ser necesario o no efectuar ciertas predisposiciones y
planificaciones de la conexión multi-abonado.
El ejemplo representado en la Figura 5 exhibe
algunos aspectos adicionales de la comunicación
multi-abonado considerando también el uso de algunos
servicios que soportan el descubrimiento de los abonados y
servicios de comunicación, y el comienzo de la negociación 806 (o
809). De tal modo, dos usuarios móviles 508a+b (el Dr. R. Harris y
su ayudante el señor A. Frank) están implicados en dicho
escenario.
En este ejemplo, debe suponerse que el Dr. Harris
está viajando de Frankfort a Paris y tiene que participar en una
videoconferencia 1204a/b con sus colegas franceses referente a la
realización de una operación de cerebro de un paciente en Paris.
Sus colegas están enviándole información de monitorización actual en
línea del paciente. También llevan a cabo una discusión sobre la
realización de la operación para ser capaces de empezar tan pronto
como el Dr. Harris llegue al hospital en Paris. Cuando el Dr.
Harris sube al tren 502, conecta de modo inalámbrico su terminal con
la red de área local (LAN) del tren. El servidor del tren es
informado ahora que el el Dr. Harris está presente dentro de la red
de área local (LAN) del tren. El señor Frank sube al tren en
Estrasburgo. Entrando en el tren 502, también conecta de modo
inalámbrico su terminal con la red de área local del tren y así
descubre que su jefe ya está en otro vagón de dicho tren 502 (debe
suponerse que el tren está reservado completamente, y por tato el
señor Frank no tiene posibilidad de reservar un asiento próximo al
Dr. Harris). El señor Frank emite una llamada para unirse también a
la conferencia en marcha. de tal modo, los terminales del Dr. Harris
y del señor Frank forman una red "ad hoc" 604 y usan el
terminal del doctor Harris como una conexión con el "mundo
exterior" que retransmite los flujos 206 de información de
conferencia al terminal del señor Frank.
Este escenario 500 es un ejemplo de presencia
virtual usando el servidor del tren como un servicio de
descubrimiento. Pero también es posible tener algunos otros
servicios intermedios como servicios de nombramiento y/o asignación,
etc. o dispositivos como proxies o registradores. En este caso, los
componentes intermedios solo soportan la construcción de la
conexión entre los iguales finales sin participar activamente en
las negociaciones 808 y 809 que realizan los iguales finales.
En la sección siguiente deben tratarse las
cuestiones referentes a como manejar la calidad de servicio en
aplicaciones multimedia que se ocupan de tipos y números múltiples
de flujos 206 de información concurrentes 206. Entonces, son
presentados con detalle los aspectos clave de la solución propuesta
según la invención fundamental, la prenegociación 802 de calidad de
servicio a nivel de aplicación y la coordinación de la gestión de
recursos distribuidos, en los que es aplicado el denominado
"principio de economía". Las exigencias identificadas en esta
sección son recogidas en una lista de exigencias que también
contiene información sobre las dependencias entre las exigencias
identificadas.
Un problema primordial que los usuarios móviles
arrostrarán más probablemente dentro del contexto de las redes 604
IP y las aplicaciones de la próxima generación es como enfrentarse
con cantidades limitadas de recursos en los sistemas finales y en
la red 604, y condiciones ambientales inestables. Por tanto, puede
ser postulada la exigencia siguiente:
| \begin{minipage}{150mm} Exigencia 1: Los promotores y los usuarios de terminales móviles y/o fijos DEBEN ser capaces de ocuparse de las condiciones ambientales inestables, especialmente cuando imponen la calidad de servicio.\end{minipage} |
Las sesiones multimedia 102 pueden contener
varios flujos 206 de información de tipos básicos (o sea, audio,
video y datos). Como un ejemplo, una sesión 102 para una
perspectiva de usuario dado podría consistir en dos flujos 206 de
información de video y cuatro flujos 206 de información de audio
generados desde iguales diferentes (o incluso desde un igual en un
escenario circundante). Entonces, el usuario dado desearía
especificar la calidad de servicio que desea obtener para cada flujo
de información único 206, y además cualquier parámetro que podría
determinar el comportamiento entre flujos 206 de información.
Típicamente, las aplicaciones de videoconferencia 1204a/b se ocupan
de flujos 206 de información de voz y video, que deben ser
sincronizados en el terminal final. La videoconferencia 1204a/b no
sincronizada puede no ser satisfactoria en algunos escenarios.
Adicionalmente, algún nivel de correlación 804
puede ser requerido entre algunos o todos los flujos 206 de
información antes mencionados, sobre una base de tiempo y/o calidad
de servicio. Esta correlación 804 constituye una generalización del
problema de sincronización 805 en el tiempo. Por ejemplo, las
aplicaciones de juegos electrónicos y/o las aplicaciones
interactivas ricas en información podrían presentar haces de flujos
de información de audio y video que están asociados con objetos para
ser presentados al usuario. Por ejemplo, un cubo móvil y/o
rotatorio puede ser visualizado en un monitor con sus caras
configuradas con imágenes procedentes de flujos 206 de información
de video, y flujos diferentes 206 de información de audio, cada uno
asociado con una cara de cubo, pueden ser reproducidos siempre que
la cara correspondiente está orientada en una cierta dirección.
Hasta este punto, las aplicaciones deben ser
capaces de garantizar no solo que los flujos 206 de información
relacionados sean reproducidos dentro de relaciones temporales
dadas (sincronización absoluta en el tiempo) sino también que la
calidad de servicio combinada de un haz dado de flujos 206 de
información esté dentro de algunas restricciones dadas (correlación
804 de calidad de servicio). Por ejemplo, continuando justo con el
ejemplo de aplicación de juego, podría no tener sentido hacer que
algunas facetas del cubo sean visualizadas en videos en blanco y
negro y las otras como videos en color de alta calidad a
frecuencias de cuadros más altas, aunque las imágenes estuvieran
sincronizadas completamente desde una perspectiva temporal absoluta.
Más bien, tendría más sentido visualizar todas las facetas
exhibiendo películas en blanco y negro a la frecuencia de cuadros
máxima disponible, evitando así el consumo inútil de recursos para
obtener imágenes en color con detrimento de la frecuencia de cuadros
a la que dichas imágenes serían visualizadas.
Por supuesto, la decisión de que nivel de
correlación 804 debería ser impuesto a nivel de calidad de servicio
entre un conjunto de flujos 206 de información es dejada a la
discreción de los promotores e incluso del usuario.
Por tanto, las aplicaciones de flujos múltiples
pueden requerir además de la especificación de relaciones de
temporización entre grupos de flujos 206 de información, también
una especificación de correlación 804 de calidad de servicio.
Realmente, esta distinción no está identificando completamente dos
aspectos ortogonales puesto que la sincronización en el tiempo
puede ser considerada como un caso especial de correlación 804 de
calidad de servicio. En el caso de que un flujo 206 de información
dado esté compuesto por un número de caudales distintos de capas de
transporte (por ejemplo, como son generados por
codificadores-descodificadores de capas múltiples),
estas cuestiones son aún más evidentes.
\newpage
| \begin{minipage}{150mm} Exigencia 2: Los promotores y los usuarios de aplicaciones multimedia que se ocupan de flujos 206 de información múltiples PUEDEN aumentar sus especificaciones de calidad de servicio incluyendo aspectos de correlación 804 de calidad de servicio y sincronización en el tiempo\end{minipage} |
Debería observarse que el agrupamiento de flujos
206 de información no depende solo de la aplicación o del usuario
sino que también puede ser estructurado según un esquema
jerárquico.
Por ejemplo, en aplicaciones de videoconferencia
1204a/b puede tener sentido distinguir (y por tanto tratar
diferentemente) grupos diferentes de flujos 206 de información, a
fin de identificar casos concurrentes múltiples de la
videoconferencia 1204a/b y, dentro de cada sesión 102 de
videoconferencia 1204a/b, las diversas asociaciones del usuario dado
con iguales múltiples (siendo cada asociación un haz de flujos 206
de información correlacionados).
Esta propuesta modela así restricciones de
sincronización 805 en el tiempo y correlación 804 de calidad de
servicio de flujos múltiples como contratos 1108 de calidad de
servicio de alto nivel, asociadas con la lista de los flujos 206 de
información afectados. Además, permite agrupar recurrentemente tales
contratos 1108 de calidad de servicio de alto nivel entre ellos
mismos, produciendo así un esquema jerárquico de especificación de
calidad de servicio, o sea equivalente a un árbol. Cada hoja tal
representa un flujo 206 de información y tiene un contrato 1108
asociado de calidad de servicio. Los nodos padre están asociados
con un contrato 1108 de calidad de servicio de alto nivel,
especificando para sus niveles hijo de calidad de servicio en
términos de restricciones de sincronización 805 en el tiempo y
correlación 804 de calidad de servicio de flujos múltiples.
Además, los usuarios pueden priorizar y conceder
cantidades diferentes de recursos a diversas aplicaciones
(multimedia). Esto es especialmente importante para dispositivos
manuales con recursos limitados como memoria, alimentación por
pilas como se describe en [BRAIN]. Este método produce restricciones
de sincronización 805 en el tiempo y correlación 804 de calidad de
servicio de nivel aún mayor, que han de ser impuestas localmente
por el dispositivo de terminal. Los contratos 1108 correspondientes
de calidad de servicio de alto nivel amplían el modelo de datos en
árbol en la raíz. Sin embargo, tales contratos 1108 adicionales de
calidad de servicio de alto nivel no son propuestos para ser
negociados con iguales. Más bien, cada igual puede aplicar
independientemente contratos 1108 de calidad de servicio de alto
nivel. Alternativamente, los contratos 1108 de calidad de servicio
de alto nivel pueden ser impuestos globalmente en todo el conjunto
cerrado dado de iguales, una vez que ha sido seleccionado un
coordinador.
| \begin{minipage}{150mm} Exigencia 3: Los promotores y los usuarios de aplicaciones multimedia que se ocupan de flujos de información múltiples 206 DEBERÍAN estructurar sus especificaciones de calidad de servicio de una manera jerárquica.\end{minipage} |
Un modo posible de enfrentarse con violaciones de
calidad de servicio y cambios de calidad de servicio es permitir que
las aplicaciones de usuarios móviles reaccionen eficiente y
oportunamente a esos sucesos, planificando acciones contrarias por
adelantado.
De esta manera, siempre que ocurren violaciones
de calidad de servicio, acuerdos sobre como adaptarse más
eficientemente a las condiciones mutadas pueden ser alcanzados
oportunamente entre los iguales.
La soluciones global que combina estos dos
mecanismos de planificación es denominada por la presente
End-to-End Negotiation Protocol 908
(E2ENP 908).
| \begin{minipage}{150mm} Exigencia 4: El E2ENP 908 DEBE incluir mecanismos y medios para planificar por adelantado acciones contrarias apropiadas, enfrentándose con sucesos imprevisibles de otro modo producidos por violaciones de calidad de servicio (por ejemplo, transferencias) o cambios de calidad de servicio (por ejemplo, usuario que cambia la información de perfil cuando vaga).\end{minipage} |
La especificación jerárquica de calidad de
servicio puede ser mejorada ayudando a las aplicaciones a decidir
como deberían reaccionar durante situaciones de sobrecarga para
estar de acuerdo con los deseos de usuarios.
La negociación 806 absoluta de un solo nivel de
calidad de servicio solo tiene sentido realmente en tiempo de
ejecución, puesto que solo en tiempo de ejecución el proveedor de
red puede estar implicado en una negociación 806 asistida por
tercer abonado (en el que los actores son un iniciador, un proveedor
y uno o múltiples respondedores según [ISOX641]). Para armonizar
con la terminología actual usada en la comunidad de la Internet
Engineering Task Force (IETF), la siguiente convención de
nombramiento será usada dentro del alcance de la invención
fundamental: ofertante 914 en lugar de iniciador y contestador 911
en lugar de respondedor. Esto es necesario si los recursos de red
han de ser reservados explícitamente para proporcionar garantías más
estrictas de calidad de servicio.
Sin embargo, ha sido identificada la necesidad de
acelerar las fases más críticas de servicios multimedia móviles
(incluyendo no solo servicios de conversación y conferencia sino
también recuperación de información) desde una perspectiva de
calidad de servicio: a saber, transferencias y establecimiento de
conexión. Esto, como el tráfico fundamental es típicamente sensible
al retardo y el uso de redes 604 móviles y heterogéneas, puede
implicar capacidad de red 604 y anchura de banda limitadas, así
como transferencias frecuentes. La solución propuesta por la
presente es planificar apropiadamente por adelantado un conjunto de
niveles de calidad de servicio para enfrentarse con las cantidades
actual y futura de recursos.
Además, cada conjunto puede ser referido rápida y
unívocamente en instantes de negociación (renegociación) de calidad
de servicio, asociando cada elemento en el conjunto con un
identificador único.
Además, características especiales de las
aplicaciones finales y los servicios pueden requerir modos
diferentes de negociación 806 y órdenes diferentes de los mensajes
intercambiados.
Finalmente, debería observarse que cualquier
información de calidad de servicio procede del conocimiento de
recursos disponibles. Puesto que cualquier calidad dada perceptible
por el usuario puede ser conseguida usando recursos diferentes (por
ejemplo, codificadores-descodificadores), es
necesario recoger información sobre recursos para poder crear
contrato(s) 1108 de calidad de servicio consiguientemente.
Además, la información sobre recursos también es usada para llevar a
cabo reservas de recursos.
| \begin{minipage}{150mm} Exigencia 5: El E2ENP 908 DEBE incluir mecanismos y medios para realizar rápida y eficientemente negociaciones 806 de calidad de servicio y renegociaciones 808 de calidad de servicio.\end{minipage} |
\vskip1.000000\baselineskip
| \begin{minipage}{150mm} Exigencia 6: El E2ENP 908 DEBE incluir mecanismos y medios para definir los modos de intercambio de información (empujar, tirar, empujar-tirar) puesto que con aplicaciones y servicios diferentes, pueden ser necesarios esquemas diferentes de negociación 806.\end{minipage} |
\vskip1.000000\baselineskip
| \begin{minipage}{150mm} Exigencia 7: El E2ENP 908 DEBE manejar la información de calidad de servicio obtenida del conocimiento sobre recursos disponibles (por ejemplo, codificadores-descodificadores.\end{minipage} |
\vskip1.000000\baselineskip
| \begin{minipage}{150mm} Exigencia 8: El E2ENP 908 DEBE incluir mecanismos y medios para especificar y prenegociar niveles alternativos múltiples de calidad de servicio.\end{minipage} |
\vskip1.000000\baselineskip
| \begin{minipage}{150mm} Exigencia 9: Cada nivel de calidad DEBE ser descrito por un contrato 1108 específico de calidad de servicio.\end{minipage} |
\vskip1.000000\baselineskip
| \begin{minipage}{150mm} Exigencia 10: El E2ENP 908 DEBE incluir mecanismos y medios para hacer referencia unívocamente a cada nivel prenegociable de calidad de servicio durante negociaciones 806 de calidad de servicio y renegociaciones 808 de calidad de servicio para mantener mínima la señalización.\end{minipage} |
Los usuarios móviles precisan la capacidad de
cambiar sus puntos de terminales móviles de unión a la red 604
mientras conservan la dirección antigua de red 604, así como
mantener cualesquier sesiones activas 102 de telecomunicación en
las que pueden ocurrir tres tipos posibles de sucesos
(transferencia).
Dado que los usuarios tienen típicamente
relaciones comerciales con un proveedor específico de red (por
ejemplo, una suscripción con un proveedor de servicios de Internet
(ISP) o una tarjeta de pago por adelantado con un operador de
telecomunicación), pueden ocurrir tres tipos posibles de
transferencia:
- -
- Transferencia horizontal: La transferencia tiene lugar dentro de un dominio administrativo dado de un proveedor de red, y dentro del mismo tipo de red 604 de acceso.
- -
- Transferencia vertical: La transferencia tiene lugar entre dos tipos diferentes de redes 604 de acceso y/o a través de la frontera administrativa entre dos proveedores de red.
Cuando se trata con transferencias, los usuarios
deben estar preparados para arrostrar cambios en la disponibilidad
de recursos de red, dependiendo no solo del tipo de red 604 de
acceso a la que se accede sino también del tipo de relaciones
comerciales que los usuarios pueden tener con los diversos
operadores de red 604 a los que accede. En algunos casos extremos,
los usuarios podrían intentar realmente acceder a la red 604
propiedad de un operador de red 604 con el que los usuarios no
tienen ninguna relación comercial o que pueden restringir el acceso
de usuarios o limitar la cantidad de recursos asignados a dichos
usuarios. Los aspectos de tarificación también desempeñan un papel
clave.
Todo esto significa que los usuarios deben estar
preparados para experimentar violaciones espectaculares de calidad
de servicio siempre que ocurren transferencias, pero también
influenciar ventajosamente cualquier mejora potencial siempre que
durante tales transferencias los usuarios acceden a redes 604 con
más recursos y/o menos restricciones.
| \begin{minipage}{150mm} Exigencia 11: El E2ENP 908 DEBE suponer que los usuarios habrán validado preventivamente sus niveles alternativos preferidos de calidad de servicio en contraste con el que puede soportar realmente su proveedor preferido de red.\end{minipage} |
Siguiendo la base lógica expuesta en el párrafo
anterior, los iguales podrían arreglárselas para ponerse de acuerdo
no solo en un contrato dado 1108 de calidad de servicio sino
también en contratos alternativos que pueden ser usados
convenientemente siempre que la disponibilidad de recursos de
terminales y/o de red 604 cambian en el tiempo.
De tal modo, cada igual conocería exactamente que
contrato 1108 alternativo de calidad de servicio (y en que
condiciones) debe ser impuesto para enfrentarse con un cambio
crítico de calidad de servicio o con cualquier violación de calidad
de servicio con respecto al contrato 1108 habilitado actualmente de
calidad de servicio.
El concepto de trayecto de adaptación prescribe
la especificación de contratos 1108 alternativos de calidad de
servicio además del contrato nominal, junto con un conjunto de
reglas que indican que contrato 1108 alternativo 1108 de calidad de
servicio debería ser impuesto en qué circunstancia. Los contratos
1108 alternativos de calidad de servicio describen típicamente
niveles inferiores de calidad de servicio comparados con el
especificado por el contrato nominal 1108 de calidad de servicio.
Más específicamente, directrices de adaptación identificarán
adaptaciones bien definidas del contrato nominal 1108 de calidad de
servicio para un conjunto de especificaciones degradadas
alternativas de calidad de servicio (o sea, niveles inferiores de
calidad de servicio), en correspondencia con conjuntos bien
definidos de cambios y/o violaciones de calidad de servicio, como
son monitorizados por el software intermedio (middleware) global
como se describe en "Lenguajes de aspectos de calidad de servicio
y su integración en tiempo de ejecución" (en: Lecture Notes in
Computer Science, Vol. 1511, Springer-Verlag) de J.
P. Loyall y otros, designado [Loyal] en lo siguiente.
En el alcance de la invención fundamental, es
aplicada la terminología indicada en [BRAIN], en el trayecto de
adaptación (AP: adaptation path) es usado en lugar de trayecto de
degradación para subrayar que la adaptación podría ser usada
realmente para mejorar una calidad dada, si más recursos resulten
disponibles en un momento posterior (por ejemplo, en el caso de
transferencia).
| \begin{minipage}{150mm} Exigencia 12: El E2ENP 908 DEBE permitir que los usuarios definan previamente trayectos de adaptación.\end{minipage} |
\vskip1.000000\baselineskip
| \begin{minipage}{150mm} Exigencia 13: Cada elemento de un trayecto de adaptación DEBE ser un contrato 1108 de calidad de servicio.\end{minipage} |
\vskip1.000000\baselineskip
| \begin{minipage}{150mm} Exigencia 14: Cada flujo 206 de información único en cada sesión 102 dada DEBERÍA estar asociado con un contrato dado 1108 de calidad de servicio.\end{minipage} |
\vskip1.000000\baselineskip
| \begin{minipage}{150mm} Exigencia 15: Cada contrato 1108 de calidad de servicio DEBE estar asociado con un identificador único.\end{minipage} |
\vskip1.000000\baselineskip
| \begin{minipage}{150mm} Exigencia 16: El E2ENP 908 DEBE imponer especificar y prenegociar de un contrato elegido 1108 de calidad de servicio a partir de cualquier trayecto de adaptación dado, como el contrato 1108 por omisión de calidad de servicio que la(s) aplicación(es) debe(n) usar cuando se inicia el flujo de información.\end{minipage} |
| \begin{minipage}{150mm} Exigencia 17: Adicionalmente, un trayecto de adaptación PODRÍA incluir la especificación de reglas que definen las circunstancias en las que la aplicación y/o el middleware deberían imponer un contrato 1108 diferente de calidad de servicio, a partir del conjunto dado de ellos.\end{minipage} |
\vskip1.000000\baselineskip
| \begin{minipage}{150mm} Exigencia 18: El E2ENP 908 DEBE incluir mecanismos y medios para especificar trayectos de adaptación a nivel de flujo 206 de información.\end{minipage} |
Aplicando el trayecto de adaptación en cualquier
nivel de la especificación jerárquica de calidad de servicio, antes
mencionada, el proceso de adaptación puede ser mejorado más
incluyendo tanto especificaciones de sincronización en el tiempo
como de correlación 804 de calidad de servicio.
En este modelo, cada especificación alternativa
de sincronización en el tiempo y de correlación 804 de calidad de
servicio está asociada con un contrato 1108 específico de calidad
de servicio.
El uso de contratos 1108 alternativos de calidad
de servicio, estructurados en un formato jerárquico a fin de captar
diversos aspectos de correlación 804, permite realmente que los
iguales se pongan de acuerdo a priori (en el tiempo de
prenegociación 802) sobre un "vocabulario de calidad de
servicio" estructurado común sin precisar la intervención del
proveedor de red durante el proceso de prenegociación 802.
Hasta este punto, los iguales pueden usar
ventajosamente información de perfiles, prenegociada con proveedores
de red en el tiempo de suscripción, siempre que participan en el
proceso de prenegociación 802 de extremo a extremo. En caso de
vagar, los proveedores de red podrían prever (por medio de acuerdos
de nivel de servicio) que la información de perfiles de usuarios se
mantenga todavía (total o parcialmente) cuando los usuarios visitan
un nuevo dominio de red.
La imposición de restricciones de correlación 804
de calidad de servicio y/o sincronización 805 en el tiempo implica
el agrupamiento lógico de flujos 206 de información, basado en
diversos criterios. Por ejemplo:
- -
- agrupar todos los flujos 206 de información de audio para imponer la traducción sincronizada;
- -
- agrupar todos los flujos 206 de información abiertos por un usuario dado en un terminal de usuarios múltiples para imponer cuotas.
Un grupo de flujos 206 de información podría
contener finalmente solo un flujo 206 de información: en tal caso,
el contrato 1108 de calidad de servicio de flujo 206 de información
básico sería aumentado simplemente con restricciones de calidad de
servicio a nivel superior (por ejemplo, específicas de
aplicación).
Los grupos son principalmente útiles para
representar haces de flujos 206 de información, que las aplicaciones
conscientes de calidad de servicio pueden manejar como un todo
cuando se intercambia calidad por disponibilidad de recursos, entre
una multiplicidad de haces equivalentes en un conjunto dado de
estados ambientales.
Hasta este punto, los iguales pueden ponerse de
acuerdo proactivamente no solo en el trayecto de adaptación de cada
flujo individual 206 de información sino también en composiciones
alternativas de todo el haz dado, junto con restricciones
específicas de correlación 804 de calidad de servicio y/o
sincronización 805 en el tiempo para cada una de las
configuraciones resultantes. Por consiguiente, las aplicaciones (y/o
el middleware) serán capaces de adaptar a cambios y/o violaciones
dados de calidad de servicio, basadas en reglas predefinidas,
dictando que flujos 206 de información deberían ser adaptados
(incluyendo acciones como parar o reiniciar un flujo), y qué nuevas
restricciones de correlación 804 de calidad de servicio y/o
sincronización 805 en el tiempo deberían ser impuestas en la nueva
situación.
| \begin{minipage}{150mm} Exigencia 19: EL E2ENP 908 DEBE incluir mecanismos y medios para especificar trayectos de adaptación para grupos de flujos 206 de información, junto con cualesquier restricciones correspondientes de correlación 804 de calidad de servicio y sincronización 805 en el tiempo.\end{minipage} |
También es razonable definir un contrato 1108 de
calidad de servicio de flujo NULO para tener en cuenta, durante el
proceso de adaptación, la posibilidad de que en situaciones
críticas algunos de los flujos 206 de información de un grupo ya no
pudieran ser soportados. De este modo, se puede impedir la
renegociación 808 completa de los ajustes de calidad de servicio de
todo el grupo de flujos 206 de información, dejando así esos flujos
206 de información dentro del grupo en marcha, para los que las
condiciones de límite son todavía válidas.
La idea detrás del flujo NULO es permitir que los
iguales finales activen implícitamente una orden de
"PAUSA-FLUJO"
("PAUSE-STREAM") debido a una violación/ cambio
detectado de calidad de servicio. conservando información sobre los
niveles negociados de calidad de servicio antes de que ocurriera la
pausa, podría usarse tal información para renegociar correcta y
rápidamente la calidad de servicio en un momento posterior en el
caso de que no exista más el estado de violación/cambio de calidad
de servicio. Por ejemplo, supóngase que Mary está observando
videoclips en su dispositivo móvil 106a1 y que ha indicado en su
perfil de usuario que, si disminuye la calidad de conexión,
preferiría interrumpir el flujo de video a fin de conservar recursos
para escuchar la música. Durante una transferencia, ocurre una
violación de calidad de servicio y el dispositivo envía
consiguientemente una señal al servidor de video a petición para
interrumpir el flujo de video. El servidor de video a petición
interrumpe el flujo de video y conserva información de calidad de
servicio prenegociada para poder reanudar el flujo tan pronto como
la transferencia es completada, según la calidad de servicio
prenegociada (incluyendo cuestiones de sincronización en el tiempo
con respecto al flujo de audio). El dispositivo 106a1 de Mary
también tiene que recordar la existencia del flujo de video para no
renegociar completamente de nuevo la calidad de servicio para él
cuando lo reanuda.
La definición de las condiciones de límite es
específica de aplicación y depende del contexto de la sesión 102. En
general, la aplicación del flujo NULO dentro de un grupo no debería
afectar al contexto de la sesión 102. Esto significa que los flujos
206 de información todavía en marcha de un grupo de flujos dentro de
una sesión 102 deberían ser bastante significativos para que los
abonados finales mantengan integro el grupo de flujos y no lo
anulen ni lo renegocien de nuevo. Así, la aplicación de un flujo
NULO es justamente una herramienta para evitar renegociaciones
completas 808 y sirve para la adaptación significativa de un grupo
de flujos.
Por ejemplo, considérese el caso de un grupo de
flujos 206 de información conteniendo un flujo 206 de información de
audio y video. Entonces, el trayecto de adaptación de grupo
correspondiente puede incluir una opción en la que el flujo 206 de
información de video está asociado con un contrato 1108 de calidad
de servicio de flujo NULO para tener en cuenta los casos de
condiciones marginales como la reducción de la anchura de banda por
debajo de un umbral dado. En tal caso, el flujo 206 de información
de video sería detenido pero continuaría el flujo de información de
audio.
| \begin{minipage}{150mm} Exigencia 20: EL E2ENP 908 DEBE incluir mecanismos y medios para especificar contratos 1108 de calidad de servicio de flujo NULO en trayectos de adaptación de grupo.\end{minipage} |
| \begin{minipage}{150mm} Exigencia 21: La aplicación del flujo NULO no DEBERÍA afectar al contexto de la sesión 102 en marcha.\end{minipage} |
La asociación es un tipo particular de
agrupamiento de flujos 206 de información, asociando todos los
flujos 105 de información entre el usuario dado y un igual dado.
Este tipo de agrupamiento es el más intuitivo y se espera que sea
usado bastante a menudo.
| \begin{minipage}{150mm} Exigencia 22: EL E2ENP 908 DEBE incluir mecanismos y medios para especificar trayectos de adaptación para asociaciones de flujos 206 de información, junto con cualesquier restricciones correspondientes de correlación 804 de calidad de servicio y sincronización 805 en el tiempo.\end{minipage} |
Un contexto de calidad de servicio identifica una
disposición de parámetros de calidad de servicio que deben ser
impuestos en todo un grupo dado de flujos 206 de información. Un
contexto de calidad de servicio es una entidad lógica modelada como
una especialización del concepto de contrato de calidad de
servicio.
Esto significa que cualquiera que pudiera ser la
especificación de calidad de servicio de flujos 206 de información
individuales, el contexto de calidad de servicio obliga a que un
conjunto de restricciones de calidad de servicio sean aplicadas a
todos los flujos 206 de información pertenecientes al grupo
dado.
Los contextos de calidad de servicio también
pueden captar los parámetros de calidad de servicio obtenidos de los
contratos 1108 de calidad de servicio de los flujos 206 de
información individuales pertenecientes a los grupos asociados con
los contextos dados de calidad de servicio [ISOX641]. Ejemplos son
la cantidad total de memoria o la anchura media de banda usadas por
el conjunto dado de flujos 206 de información.
Para resumir, los contextos de calidad de
servicio distribuyen cuestiones de agrupamiento de flujos 206 de
información, correlación 804 de calidad de servicio y
sincronización en el tiempo, enfocando más precisamente en la
especificación de:
- \bullet
- nivel común de calidad de servicio para un grupo de flujos 206 de información;
- \bullet
- parámetros de calidad de servicio derivados;
- \bullet
- parámetros de calidad de servicio que afectan indirectamente a especificaciones de calidad de servicio de flujos 206 de información agrupados.
Por supuesto, la decisión sobre qué nivel de
correlación 804 de calidad de servicio y/o sincronización 805 en el
tiempo debería ser impuesto entre un grupo de flujos 206 de
información, puede ser tomada no solo por el promotor sino también
por el usuario.
| \begin{minipage}{150mm} Exigencia 23: EL E2ENP 908 DEBE incluir mecanismos y medios para especificar y prenegociar contextos de calidad de servicio asociados con grupos dados de flujos 206 de información.\end{minipage} |
\vskip1.000000\baselineskip
| \begin{minipage}{150mm} Exigencia 24: Cada contexto de calidad de servicio DEBE estar asociado con un identificador único.\end{minipage} |
\vskip1.000000\baselineskip
| \begin{minipage}{150mm} Exigencia 25: EL E2ENP 908 DEBE imponer la especificación y la prenegociación de un contexto elegido de calidad de servicio a partir de cualquier trayecto de adaptación de grupo dado, como el contexto por omisión de calidad de servicio que la(s) aplicación(es) debe(n) usar cuando inician el flujo de información.\end{minipage} |
Según el modelo jerárquico antes mencionado,
pueden ser definidas jerarquías basadas en árbol de contextos de
calidad de servicio. Las hojas de cualquier estructura tal de datos
en árbol serían representadas entonces por los contratos 1108 de
calidad de servicio asociados con los flujos 206 de información
individuales pertenecientes a un grupo dado de flujos 206 de
información.
Cualquier nodo interno de cualquier estructura
tal de datos en árbol sería representado en cambio por un contexto
de calidad de servicio que entonces afectaría indirectamente a la
especificación de calidad de servicio de todos los flujos 206 de
información, cuyos contratos 1108 de calidad de servicio están
contenidos en el subárbol que se extiende desde el nodo interno
dado. Esto significa que los contextos de calidad de servicio
pueden aplicarse así a parámetros específicos de calidad de servicio
que afectan indirectamente a todos los flujos 206 de información
fundamentales (por ejemplo, cuestiones de fiabilidad a nivel de
sistema).
Además, a nivel superior en cualquier estructura
tal de datos en árbol, contextos de calidad de servicio pueden ser
definidos recurrentemente a partir de otros a nivel inferior.
De este modo, cualquier estructura tal de datos
en árbol puede ser usada para agregar no solo flujos 206 de
información individuales sino también una multiplicidad de grupos
ya definidos de flujos 206 de información, basada en criterios de
correlación 804 de calidad de servicio y sincronización en el
tiempo.
| \begin{minipage}{150mm} Exigencia 26: EL E2ENP 908 DEBE incluir mecanismos y medios para especificar y prenegociar jerarquías basadas en árbol de contextos de calidad de servicio asociados con agregaciones de grupos dados de flujos 206 de información.\end{minipage} |
A cada contexto de calidad de servicio puede
asignársele una prioridad que las aplicaciones conscientes de
calidad de servicio pueden usar para determinar la importancia
relativa de contextos hermanos de calidad de servicio.
| \begin{minipage}{150mm} Exigencia 27: EL E2ENP 908 DEBE incluir mecanismos y medios para especificar y prenegociar prioridades relativas entre contextos de calidad de servicio que resultan ser hermanos en una jerarquía dada basada en árbol de contextos de calidad de servicio.\end{minipage} |
Influenciando los conceptos de contexto de
calidad de servicio y especificación jerárquica de calidad de
servicio, los iguales pueden imponer el concepto antes mencionado
de trayecto de adaptación de grupo (GAP: Group Adaptation
Path).
Por supuesto, la imposición de restricciones de
correlación 804 de calidad de servicio y sincronización en el tiempo
solo es posible cuando los iguales implicados en el proceso de
negociación 806 se ponen de acuerdo a priori sobre un negocio
dado (qué aplicación usar, con quien ponerse en contacto, qué
otras sesiones 102 han de ser abiertas, etc.).
Prácticamente, en la mayoría de los casos los
usuarios imponen estas restricciones localmente y no revelan esta
información a sus iguales. El único caso donde estas restricciones
pueden ser impuestas en todo un conjunto dado de iguales es solo
cuando están dispuestas unidades de control de tercer abonado como
una unidad de control de conferencia (típicamente, en el caso de
escenarios de conferencia en línea)
\newpage
| \begin{minipage}{150mm} Exigencia 28: EL E2ENP 908 DEBE incluir mecanismos y medios para especificar y prenegociar trayectos de adaptación de grupo expresados en términos de contextos de calidad de servicio como opciones alternativas.\end{minipage} |
\vskip1.000000\baselineskip
| \begin{minipage}{150mm} Exigencia 29: Cada contexto de calidad de servicio dentro de un trayecto dado de adaptación de grupo DEBE representar un grupo de flujos 206 de información asociados con restricciones de correlación 804 de calidad de servicio y/o sincronización 805 en el tiempo.\end{minipage} |
\vskip1.000000\baselineskip
| \begin{minipage}{150mm} Exigencia 30: EL E2ENP 908 DEBE permitir envolver cualquier trayecto dado de adaptación de grupo dentro de un contexto de calidad de servicio, permitiendo así negociar restricciones de correlación 804 de calidad de servicio y/o sincronización 805 en el tiempo a través de todos los elementos constituyentes de dicho trayecto de adaptación de grupo.\end{minipage} |
\vskip1.000000\baselineskip
| \begin{minipage}{150mm} Exigencia 31: EL E2ENP 908 debe permitir la aplicación recurrente de las exigencias 28 y 29.\end{minipage} |
El proceso de renegociación 808 implica
típicamente un ofertante 914 y uno o múltiples contestadores 106a2,
y puede ser realizado de una vez o sobre una base iterativa
(Loyal).
El ofertante 914 ofrece una oferta a los
contestadores 106a2 que la examinan y devuelven una contraoferta al
ofertante 914. Este último recoge las contraofertas y determina la
que satisface (si hay alguna) las exigencias de todos los abonados
implicados. Una vez que tal contraoferta óptima ha sido
seleccionada, el ofertante 914 la envía como una oferta nueva a
cada contestador 911.
En un esquema iterativo, el proceso podría volver
a empezar en este punto si uno de los contestadores 911 sigue sin
aceptar la nueva oferta. Sin embargo, el método iterativo debe ser
constreñido con un límite superior de iteración, y en cualquier
caso es bastante complejo y no eficiente.
La regeneración 808 mediante los escenarios de
conexión multi-abonado debería ser hecha por
posibilidad sobre una base única como por la renegociación 808 de
uno con uno, puesto que el caso de cambios por un solo abonado de
comunicación podría no influenciar las conexiones de los otros
abonados implicados, o sea, si un igual descubre problemas por su
conexión, esto no significa que otros iguales también tengan
problemas con sus conexiones. Por tanto, mediante conexiones
multi-abonado es mejor renegociar los flujos 206 de
información independientes sobre una base única para minimizar la
señalización necesaria. Los flujos 206 de información de un grupo
(flujos 206 de información dependientes) también pueden ser
renegociados sobre una base única en el caso de que esta
renegociación 808 no influencie los contextos del grupo.
| \begin{minipage}{150mm} Exigencia 32: El E2ENP 908 DEBE imponer esquemas básicos no iterativos de prenegociación 802, negociación 806 y renegociación 808.\end{minipage} |
\vskip1.000000\baselineskip
| \begin{minipage}{150mm} Exigencia 33: El E2ENP 908 DEBE permitir esquemas de negociación 806 más complejos empleando solo unidades de control de tercer abonado (por ejemplo, unidades de control de conferencia).\end{minipage} |
\vskip1.000000\baselineskip
| \begin{minipage}{150mm} Exigencia 34: En general, EL E2ENP 908 DEBERIA ser usado para realizar prenegociaciones 802, negociaciones 806 y renegociaciones 808 solo entre los iguales finales implicados en una sesión 103. Si esta exigencia no es aplicable debido a razones específicas de servicio, la exigencia 31 tendría prioridad.\end{minipage} |
\vskip1.000000\baselineskip
| \begin{minipage}{150mm} Exigencia 35: Mediante escenarios complejos de negociación 806 (por ejemplo, como conferencia), los iguales finales ocupados en un proceso de E2ENP 908 PUEDEN publicar los contratos 1108 de calidad de servicio ya prenegociados y la información de perfiles de usuarios en algunos servicios de registro, permitiendo así un proceso corto de negociación 806 para los abonados que se unen posteriormente.\end{minipage} |
\vskip1.000000\baselineskip
| \begin{minipage}{150mm} Exigencia 36: DEBERÍA ser posible renegociar un solo flujo 206 de información de un grupo, si esto no es contradictorio con el contexto del grupo, para minimizar la señalización para la renegociación 808.\end{minipage} |
\vskip1.000000\baselineskip
| \begin{minipage}{150mm} Exigencia 37: En el caso de que un flujo 206 de información esté siendo correlacionado con otros flujos 206 de información, DEBERÍA ser la responsabilidad del abonado que correlaciona realizar la renegociación 808 con todos los abonados afectados.\end{minipage} |
La base lógica de negociación 806 propuesta por
la presente es permitir que los receptores especifiquen que nivel de
calidad de servicio desean recibir. La diferencia entre esta
propuesta y las tendencias actuales (por ejemplo, SDP/SDPng 912)
consiste en que las últimas no se concentran principalmente en la
negociación 806 de calidad de servicio, más bien en la negociación
806 de capacidad. Por ejemplo, tanto el SDP como el SDPng 912
permiten que un emisor proporcione información al (a los)
receptor(es) sobre la información de transporte y formato
que el emisor pretende usar para emisión. Intentando emparejar el
E2ENP 908 con este método bien conocido, la base lógica antes
mencionada puede ser relajada como sigue: tanto los emisores como
los receptores pueden especificar que nivel de calidad de servicio
desean enviar/recibir en el nivel de flujo 206 de información, pero
solo los receptores son autorizados a especificar que nivel de
calidad de servicio de nivel alto/trayectos de adaptación desean
imponer para recibir. Esto es porque es más probable que los
receptores se interesen por las restricciones de correlación 804 de
calidad de servicio y sincronización 805 en el tiempo entre flujos
206 de información recibidos múltiples, mientras que esto no es
generalmente relevante para los emisores.
| \begin{minipage}{150mm} Exigencia 38: El E2ENP 908 DEBE permitir que los emisores, los receptores y los emisores/receptores especifiquen que nivel de calidad de servicio desean enviar/recibir a nivel de flujo 206 de información.\end{minipage} |
\vskip1.000000\baselineskip
| \begin{minipage}{150mm} Exigencia 39: El E2ENP 908 DEBE permitir que solo los receptores y los emisores/receptores especifiquen que nivel de calidad de servicio nivel alto/trayectos de adaptación (o sea, restricciones de correlación 804 de calidad de servicio y sincronización 805 en el tiempo) desean recibir\end{minipage} |
Sin embargo, se deja para estudio adicional la
extensión de esta propuesta para permitir que los emisores
especifiquen restricciones de correlación 804 de calidad de
servicio y sincronización 805 en el tiempo entre los flujos 206 de
información que emiten.
Los iguales pueden seguir un procedimiento
específico para imponer eficazmente la especificación de calidad de
servicio negociada no solo en el momento de establecimiento de
conexión sino también siempre que tienen lugar violaciones de
calidad de servicio.
Hasta este punto, [BRAIN] sugiere coordinar la
reserva real de recursos locales así como recursos de red para
evitar esperar la reserva de recursos de red hasta que son
reservados los recursos en todos los puntos finales. Más
precisamente, la expresión principio de economía es usada en el
presente documento para describir el orden de reserva descrito en
"El intermediario de calidad de servicio" (IEEE Multimedia
Magazine, primavera de 1.995 (2)1, páginas
53-67) de K. Nahrstedt y J. M. Smith, designado
[Nahr95] en lo siguiente.
Por tanto, es propuesta una integración de los
procesos antes mencionados de prenegociación 802 de calidad de
servicio, negociación 806 de calidad de servicio y renegociación
808 de calidad de servicio, con el principio de economía para
reservar los recursos más caros en el último paso. Como los recursos
de red son compartidos entre varios clientes y hay que pagarlos
típicamente, es mejor reservar primero recursos en todos los
sistemas finales y después reservar recursos de red en el último
paso.
Entonces, las secuencia de acciones se parece a
la siguiente:
- 1.
- Primero son reservaros recursos locales.
- 2.
- Después, la negociación 806 con la entidad de igual produce una configuración que puede ser hecha corresponder con exigencias de recursos en el igual, que entonces son reservados.
- 3.
- Finalmente, la reserva de recursos de red es efectuada en el último paso porque los recursos de red son caros y compartidos entre usuarios múltiples.
\newpage
| \begin{minipage}{150mm} Exigencia 40: El E2ENP 908 DEBE proporcionar mecanismos y medios para imponer la coordinación de la gestión de recursos distribuidos.\end{minipage} |
\vskip1.000000\baselineskip
| \begin{minipage}{150mm} Exigencia 41: Según el "principio de economía", los recursos remotos en el igual DEBEN ser reservados solo después de que los recursos locales han sido reservados satisfactoriamente.\end{minipage} |
\vskip1.000000\baselineskip
| \begin{minipage}{150mm} Exigencia 42: Según el "principio de economía", los recursos de red DEBEN ser reservados solo después de que los recursos locales han sido reservados satisfactoriamente en todos los iguales.\end{minipage} |
Para coordinar apropiadamente la reserva de
recursos locales, de iguales y de red según el "principio de
economía" anterior mencionado, entre más de dos iguales, debe
tenerse un cuidado especial mientras se especifica el protocolo
correspondiente para proporcionar consistencia (que también produce
mejor utilización de recursos) y evitar interbloqueos. La
consistencia también producirá mejor utilización de recursos.
El resto de esta sección presenta dos escenarios
ejemplares, motivando estas exigencias. Primero es dada una
descripción de los requisitos previos generales que se aplican a
los escenarios ejemplares. Estos requisitos previos ilustran el
dominio del problema. Sin embargo, no limitan la aplicabilidad del
escenario.
En lo siguiente deben suponerse tres dispositivos
de terminales equivalente, cada uno equipado con el mismo
codificador-descodificador de video. La potencia de
procesamiento de los dispositivos de terminales es tal que cada uno
de ellos es capaz de gestionar 25 cuadros por segundo para emisión
o recepción.
O sea, la potencia de la unidad central de
procesamiento (UCP) permite procesar 25 cuadros/s en el modo de
transmisión (captar, comprimir, dividir en paquetes y emitir) o en
el modo de recepción (recibir los paquetes, reensamblar,
descomprimir y representar). Sin embargo, el terminal no tiene
recursos suficientes para emitir y recibir 25 cuadro/s
simultáneamente. Además, debe suponerse que el consumo de recursos
varía de escala linealmente con el número de cuadros por segundo.
Como un ejemplo, los dispositivos de terminales pueden emitir
simultáneamente un flujo 206 de información a 10 cuadros/s y
recibir un flujo 206 diferente de información a 15 cuadros/s a fin
de procesar 25 cuadros/s en total.
El diagrama de interacción para escenario de
negociación 806 con tres iguales 602a-c (A, B y C),
como se representa en la Figura 6, muestra porqué es necesario
proporcionar consistencia. De tal modo, debe suponerse que en el
instante t_{0} el igual A inicia una negociación 806 con el igual
B para gestionar que el igual A envíe un flujo 206 de información
al igual B a una frecuencia de cuadros de 15 cuadros/s.
El igual A reserva satisfactoriamente recursos
locales para procesar 15 cuadros/s, envía la solicitud de
negociación 806 al igual B que ya tiene una sesión 102 similar en
marcha que consume 20 cuadros/s con un igual diferente. Así, el
igual B reserva recursos para 5 cuadros/s para procesar el flujo
206 de información entrante porque eso es todo lo que puede
soportar. Esta información es propagada de vuelta al igual A que
libera recursos reservados previamente para sostener el valor
negociado de frecuencia de cuadros de 5 cuadros/s, y después
empieza a reservar recursos de red equivalentes a 5 cuadros/s en el
instante t_{1}.
Supóngase que la red 604 no es el factor
limitativo y que finalmente el igual A, el igual B y la red 604 son
capaces de sostener 5 cuadros/s para la sesión 102 dada. Si se
supone que en cualquier instante entre t_{0} y t_{1} el igual C
quiere crear una sesión 102 con el igual A, el igual A solo sería
capaz de permitir que el igual C admita 10 cuadros/s (25 cuadros/s
- 15 cuadros/s) localmente.
Sin embargo, si el igual A recibe la solicitud
del igual C en cualquier instante después de t1, el igual A sería
capaz de admitir al menos 20 cuadros/s (25 cuadros/s - 5 cuadros/s)
para la nueva sesión 102 con el igual C porque las exigencias de
recursos para la primera sesión 102 han disminuido debido a las
restricciones impuestas al igual B, que están fuera del control del
igual C.
A partir de este escenario, puede ser obtenida la
exigencia de que cualquier protocolo tal que gestiona recursos
locales remotos y de red entre dos iguales no debe servir
solicitudes de exigencias de recursos procedentes de otro igual
hasta que el protocolo ha conseguido establecer una sesión 102 de
telecomunicación en marcha. Esta exigencia debe ser llamada
consistencia.
| \begin{minipage}{150mm} Exigencia 43: EL E2ENP 908 DEBE imponer una aplicación consistente del "principio de economía" entre iguales múltiples.\end{minipage} |
El diagrama de interacción para un escenario de
negociación 806 con dos iguales 602a+b (A y B), como se representa
en la Figura 7, muestra porqué es necesario evitar interbloqueos
(puntos muertos), o sea, porqué EL E2ENP 908 debe garantizar que no
hay estado de retención y espera o que tal estado puede estar
presente solo durante una magnitud limitada de tiempo. Supóngase
que el igual A quiere enviar un flujo 206 de información de video a
25 cuadros/s al igual B y viceversa.
En el instante t_{0}, el igual A reserva los
recursos locales y envía la solicitud de negociación 806 al igual B
que recibe esta solicitud en el instante t_{2}. Mientras tanto,
el igual B reserva los recursos en el instante t_{1} para enviar
un flujo 206 de información al igual A. El igual A recibe esta
solicitud en el instante t_{3}.
Por tanto, el igual A espera la respuesta del
igual B empezando en el instante t_{0}, mientras que el igual B
espera la respuesta del igual A empezando en el instante t_{1}.
En consecuencia, cuando ambos iguales intentan reservar sus
recursos locales en el instante t_{2} (igual B) y el instante
t_{3} (igual A) para servir las solicitudes remotas, ambos
fallarán.
A partir de este escenario, puede obtenerse la
exigencia de que cualquier protocolo que gestione recursos locales,
remotos y de red entre dos iguales debe evitar situaciones de
interbloqueo o al menos permitirlas que ocurran solo durante un
período limitado de tiempo, después de lo cual el protocolo debe ser
capaz de recuperar en cualquier caso.
| \begin{minipage}{150mm} Exigencia 44: EL E2ENP 908 DEBE asegurar que en cualquier momento dado la aplicación del "principio de economía" no produce estados de interbloqueo. \end{minipage} |
\vskip1.000000\baselineskip
| \begin{minipage}{150mm} Exigencia 45: EL E2ENP 908 DEBE asegurar que mecanismos de recuperación son situados para enfrentarse con aplicaciones en colisión posibles del "principio de economía".\end{minipage} |
Los iguales finales son conectados en general
por una o una multiplicidad de redes 604 interconectadas, incluyendo
también componentes intermedios.
| \begin{minipage}{150mm} Exigencia 46: EL E2ENP 908 debería funcionar basado en una abstracción de la red fundamental 604.\end{minipage} |
Los componentes intermedios ofrecen servicios que
no solo pueden influenciar la información que los iguales negocian
finalmente por medio del E2ENP 908 posteriormente sino que también
pueden imponer los resultados del proceso del E2ENP 908.
Los componentes intermedios DEBERÍAN ser
informados sobre la decisión tomada por los iguales finales. El
modo de informar a los componentes intermedios PUEDE ser soportado
con alguna información de perfil estándar antes del comienzo del
E2ENP 908 y/o publicando los contratos 1108 acordados de calidad de
servicio en algún servicio de registro.
| \begin{minipage}{150mm} Exigencia 47: EL E2ENP 908 DEBERIA poder ser usado en combinación con (pero independientemente de) componentes intermedios, lo que podría resultar eficaz para preparar y/o garantizar los contratos 1108 de calidad de servicio acordados por los iguales finales.\end{minipage} |
\vskip1.000000\baselineskip
| \begin{minipage}{150mm} Exigencia 48: El intercambio de información (por ejemplo, perfiles, seguridad, autenticación, directrices de proveedores, etc.) que no afecta directamente al proceso del E2ENP, sino que más bien influencia a la información que va a ser negociada, DEBERÍA ser llevado a cabo antes del comienzo del E2ENP 908.\end{minipage} |
\vskip1.000000\baselineskip
| \begin{minipage}{150mm} Exigencia 49: Cualquier negociación 806 llevada a cabo antes del comienzo del E2ENP 908 DEBERIA ser realizada de un modo modular y controlado a fin de garantizar la consistencia y evitar interbloqueos.\end{minipage} |
En general, los caudales que transportan mensajes
del E2ENP 908 (el trayecto de señalización) y los caudales que
transportan los flujos 206 de informaciones reales (el trayecto de
datos) podrían ser encaminados diferentemente dependiendo no solo
de cuestiones relacionadas con la red sino también de razones
específicas de aplicación/servicio.
\newpage
| \begin{minipage}{150mm} Exigencia 50: Los trayectos de señalización y los trayectos de datos correspondientes del E2ENP 908 entre dos iguales finales dados cualesquiera DEBERÍAN ser considerados diferentes en general.\end{minipage} |
Cada vez que es construido un trayecto de
señalización y/o un trayecto de datos, puede haber algunos
componentes intermedios (encaminador, proxies, etc.) situados a lo
largo del trayecto, cuyo uso es específico de aplicación, y que
podrían "comprender" parcialmente los protocolos usados por
los iguales finales. Estas entidades estarían en una posición para
"interferir" también con el E2ENP 908 (por ejemplo, el SIP 910
puede permitir esto), trastornando así la misma naturaleza de
"extremo a extremo" del E2ENP 908.
Para evitar esta amenaza, la exigencia siguiente
obliga que los componentes intermedios sean siempre pasivos con
respecto al E2ENP 908.
| \begin{minipage}{150mm} Exigencia 51: Con respecto al E2ENP 908, los componentes intermedios DEBEN funcionar basados solamente en información proporcionada (directa o indirectamente) por los iguales para llevar a cabo tareas específicas de aplicación. \end{minipage} |
Por ejemplo, esto puede ser conseguido poniendo
una observación explícita en mensajes de E2ENP 908 indicando que los
componentes intermedio nunca deberían alterar el contenido del E2ENP
908 durante el proceso de E2ENP 908. O publicando alguna de la
información relacionada con el E2ENP por adelantado en un servicio
de registro, que los componentes intermedios pueden interrogar
entonces para planificar acciones.
Cuando calidad de audio definida por usuario deba
ser aplicada a un codificador-descodificador según
las definiciones estándar de tipo de información útil de los
codificadores-descodificadores, como se describe en
"Perfil de RTP para conferencias de audio y video con control
mínimo" (Universidad de Columbia, trabajo en marcha,
<draft-ietf-avt-profile-new-09.txt>)
de H. Schulzrinne y otros, designado [RTP-Profile]
en lo siguiente, una calidad específica puede ser hecha corresponder
con un tipo de información útil justamente que expresa esta
calidad.
Hay una correspondencia unívoca de una con una
entre una calidad de audio y una capacidad (tipo de información
útil).
Por otra parte, un
codificador-descodificador único de video puede
producir calidades múltiples. La calidad de un video comprimido
indica la calidad como es pasada al codificador
(codificador-descodificador). Representa la calidad
visual global de los cuadros únicos. Esto significa que aplicando
alguna calidad definida por el usuario a un video, es posible
definir esta calidad como un porcentaje de compresión para el
rendimiento funcional del codificador-descodificador
de video. Adicionalmente, es posible para algunos
codificadores-descodificadores (por ejemplo,
WaveVideo, nombre de formato - "WAVI") como se describe en
"WaveVideo - Una aproximación integrada al video inalámbrico
adaptable" (en: ACM Monet, Special Issue on Adaptive Mobile
Networking and Computing, 1998) de G. Fankhauser, M. Dasen, N.
Weiler, B. Plattner y B. Stiller, designado [WAVI] en lo siguiente,
especificar la calidad visual global de los planos de crominancia
de los cuadros únicos, separando así entre la calidad de luminancia
global y la calidad cromática. La calidad cromática también puede
ser expresada como un porcentaje. Los diferentes
codificadores-descodificadores de video tienen
números diferentes de niveles de compresión. Cuando un usuario
especifica una calidad perceptible visualmente, esta calidad
debería ser hecha corresponder unívocamente con un número que
expresa el nivel de compresión del
codificador-descodificador de video. Si el usuario
especifica su calidad perceptible como un número o un margen de
números, este ajuste debería tener resolución suficiente para hacer
corresponder unívocamente con un cierto nivel de compresión de un
codificador-descodificador. Así, pueden ser
definidas dos exigencias referentes al ajuste de calidad de
video:
| \begin{minipage}{150mm} Exigencia 52: El margen de numeración para la especificación de calidades perceptibles por el usuario (calidad visual global y calidad cromática, si la calidad cromática es aplicable) DEBERÍA ser unívocamente comprensible para la aplicación y el E2ENP 908 para ser capaz de hacer corresponder unívocamente la calidad de video con un codificador-descodificador dado.\end{minipage} |
\vskip1.000000\baselineskip
| \begin{minipage}{150mm} Exigencia 53: El margen de numeración para la especificación de calidades perceptibles por el usuario (calidad visual global y calidad cromática, si la calidad cromática es aplicable) DEBERÍA tener resolución suficiente para hacer corresponder unívocamente con los niveles de compresión de un codificador-descodificador dado.\end{minipage} |
Los iguales deberían prenegociar un una
directriz de gestión de recursos para evitar inestabilidades en
tiempo de ejecución siempre que manejan renegociaciones 808 de
calidad de servicio.
De otro modo, si dos o varios iguales, unidos
(supóngase) a una videoconferencia 1204a/b, detectan un uso de
recursos que viola alguna directriz patentada de gestión de
recursos, las decisiones que cada igual tomaría independientemente
podrían influenciar a las restantes, de modo que podrían contradecir
las decisiones de esos otros iguales podrían intentar tomar
concurrentemente. Esto produciría "oscilaciones" en el espacio
de configuración de recursos, lo que influiría sobre el rendimiento
funcional global del sistema y la calidad de servicio percibida por
el usuario.
Por la misma razón, solo el emisor debería tomar
la decisión de activar el proceso de renegociación 808. Sin embargo,
si un receptor detecta concurrentemente una degradación de
disponibilidad de recursos, podría activar una renegociación 808 y
cualquier colisión eventual con otros iguales (incluyendo en
emisor) sería resuelta concediendo el derecho de continuar este
proceso al emisor solamente.
Hasta este punto, es propuesta la definición de
un conjunto de directrices bien definidas de gestión de recursos,
sobre la que los iguales pueden ponerse de acuerdo mediante
negociación 806. De este modo, los iguales todavía pueden gestionar
independientemente sus propios recursos en tiempo de ejecución pero
de una manera coordinada.
Tales directrices deberían cubrir cualquier
combinación lógica de al menos los aspectos siguientes:
- \bullet
- optimización de recursos de memoria,
- \bullet
- optimización de potencia de procesamiento,
- \bullet
- optimización de rendimiento funcional de recursos de red, y
- \bullet
- optimización de consumo de energía eléctrica
Más específicamente, la optimización de consumo
de energía eléctrica está correlacionada con todos los otros tipos
de gestión de recursos: por ejemplo, un intercambio de memoria
consume energía eléctrica.
Si una directriz no específica explícitamente la
optimización del consumo de energía eléctrica, la directriz
optimizaría así el uso de otros tipos de recursos, sin preocuparse
mucho del consumo de energía (por ejemplo, esto puede tener sentido
para un ordenador personal de sobremesa enchufado permanentemente a
la red eléctrica, que tendría mucha energía eléctrica para
optimizar cualquier tipo de recursos excepto el consumo de
energía).
Si una directriz especifica explícitamente la
optimización de consumo de energía eléctrica, este criterio de
directriz afectaría a todos los demás criterios de
optimización.
El uso de directrices permite que aplicaciones
y/o middleware tomen flexiblemente sus propias decisiones de
adaptación mientras sean satisfechas las condiciones impuestas por
los contratos 1108 negociados de calidad de servicio y las
directrices de gestión de recursos. Por tanto, no son necesarias la
definición ni la negociación 806 de prioridades para contratos 1108
de calidad de servicio. Además, tampoco son necesarias la
definición ni la negociación 806 de prioridades para
codificadores-descodificadores/capacidades. La razón
de tal acción de priorizar sería realmente debida al hecho de que
las capacidades como codificadores-descodificadores
consumen recursos de modo diferente entre si. Además, los
codificadores-descodificadores que funcionan
típicamente menos bien que otros todavía pueden optimizar más
convenientemente el uso de recursos cuando son usados en
configuraciones específicas.
| \begin{minipage}{150mm} Exigencia 54: EL E2ENP 908 DEBE proporcionar mecanismos y medios para especificar y prenegociar directrices de gestión de recursos.\end{minipage} |
\vskip1.000000\baselineskip
| \begin{minipage}{150mm} Exigencia 55: Las directrices de gestión de recursos deben incluir, pero no estar limitadas a, cualquier combinación lógica de los criterios siguientes: optimización de recursos de memoria, optimización de potencia de procesamiento, optimización de rendimiento funcional de recursos de red, optimización de consumo de energía eléctrica.\end{minipage} |
\vskip1.000000\baselineskip
| \begin{minipage}{150mm} Exigencia 56: Las aplicaciones y/o el software intermedio (middleware) que usan el E2ENP 908 pueden priorizar autónomamente la lista de codificadores - descodificadores/capacidades, basadas en directrices prenegociadas de gestión de recursos y la disponibilidad actual de recursos.\end{minipage} |
El entorno dinámico de comunicación requiere no
solo adaptabilidad por el establecimiento y la gestión de las
conexiones de datos sino también realizando negociaciones 808 y 809.
La Figura 1 muestra un caso especial para una negociación 808 y 809
del escenario 100 de comunicación de uno con uno, en el que la
conexión de datos de igual a igual está siendo negociada
"asistida por tercer abonado". Tal clase de negociación 806
puede aprovechar el uso de servicios de registro, asignación,
presencia, etc., permitiendo así la satisfacción más completa de las
exigencias de usuarios para calidad de servicio y la posibilidad de
descubrir y utilizar dispositivos múltiples dentro de la zona
próxima a un usuario.
Iniciando una negociación 806, el dispositivo
llamado puede descubrir que no tiene posibilidad de manejar la
llamada. Como el dispositivo no puede adaptar, la llamada puede no
suceder simplemente. Una clase de adaptación que puede ser aplicada
en este caso sin cambiar las capacidades del igual sería delegar la
llamada en otro igual según una definición de perfil del usuario.
Tal funcionalidad es denominada aquí mediador 106a1 y describe la
capacidad de un igual para negociar en nombre de algún otro igual y
según una definición prefijada de perfil de usuario. Este tipo de
negociación 809 es denominada "negociación asistida por tercer
abonado". El mediador 106a1 participa activamente en la
negociación 809 entre dos iguales pero no toma parte en la conexión
de datos. Si el mediador 106a1 debiera participar activamente en
una conexión de datos, necesitaría adicionalmente funcionalidad de
conexión en puente que, en algunos casos, puede producir
transcodificación necesaria, tropezando así con la conexión
multi-abonado y precisando su negociación 809. Un
problema adicional de un mediador 106a1 situado en el trayecto de
datos puede ser que el dispositivo cause un embotellamiento,
influenciando así negativamente la posibilidad de soportar la
calidad de servicio necesaria. Considerando estos problemas, tal
clase de adaptabilidad solo puede ser preformada si todos los
iguales (incluyendo el mediador 106a1) intercambian información
sobre sus perfiles de capacidad (por ejemplo, rendimiento de
velocidad de bits del dispositivo), esto significa que debería ser
negociada la conexión multi-abonado, lo que debe ser
tratado posteriormente. Así, para el caso de negociación 809, la
mediación es considerada de tal modo que el mediador 106a1 no
participa en el flujo de información de datos.
La funcionalidad de facilitación de un mediador
106a1 es activada cuando un ofertante 106b emite una llamada que el
dispositivo no puede manejar. En este caso, el mediador 106a1 busca
un contestador 106a2 apropiado y delega la llamada informando
también al usuario y pidiendo la aceptación del estado de
delegación. Por consiguiente, el ofertante 106b y el contestador
106a2 reciben información de perfil de uno sobre otro por el
mediador 106a1, acelerando así el descubrimiento y el proceso de
negociación 806 directa entre el ofertante 106b y el contestador
106a2 en tiempo posterior.
La funcionalidad del mediador 106a1 necesita ser
capaz de usar servicios adicionales que soportan su capacidad de
facilitación. La aplicación específica de tales servicios está
fuera del alcance de este documento, aquí solo es reconocida la
ventaja de su uso y como el E2ENP 908 está siendo afectado.
El mediador 106a1 debería tener cuidado de no
referir la información 112 de sesión desconocida para un abonado
(ofertante 106b) o para el otro abonado (contestador 1062 futuro)
para los que la mediación está siendo efectuada. El mediador 106a1
debería ser autorizado a realizar la facilitación reestructurando
finalmente la información 112 de sesión procedente de un igual,
cuando la información sobre sesiones múltiples 102 es referida
solamente llamando al mediador 106a1, pero no contenida
explícitamente en el mensaje. Así, el mediador 106a1 atiende a
completar el conjunto 112 de información sobre una sesión 102 por
los abonados para los que está siendo efectuada la facilitación. El
mediador 106a1 no cambia el contenido de la información 112 de
sesión pero finalmente añade partes de descripción completas a sus
llamadas para reunir la información dispuesta por los otros
abonados 106b y 106a2 de la negociación.
| \begin{minipage}{150mm} Exigencia 57: Mediante negociación 806 asistida por tercer abonado, un mediador puro 106a1 solo DEBERÍA facilitar la delegación de una conexión sin tomar parte activamente en ella.\end{minipage} |
\vskip1.000000\baselineskip
| \begin{minipage}{150mm} Exigencia 58: Un mediador 106a1 PUEDE aprovechar el uso de servicios de registro, asignación, presencia, etc., cuya información PUEDE ser usada solo para formación de mensajes de acuerdo con E2ENP, pero no influye en la estructura ni en el comportamiento funcional del E2ENP 908.\end{minipage} |
\vskip1.000000\baselineskip
| \begin{minipage}{150mm} Exigencia 59: El mediador 106a1 DEBERÍA ser capaz de generar nuevas descripciones 112 de sesión a partir de las antiguas mencionadas, sin cambiar el contenido de la información sino solo reestructurándola para las necesidades de la facilitación. El mediador 106a1 DEBERÍA tener cuidado de enviar descripciones 112 de sesión completas sin referencias desconocidas.\end{minipage} |
En la solicitud de patente europea EP 01 122
366.6, es descrito el concepto global de E2ENP, sus exigencias y una
implementación posible de él, sin embargo, sin detallar ninguna
implementación con respecto a las tecnologías actuales. Cualquier
información prenegociada no es llevada a cabo a tiempo.
Aunque la forma actual de SDPng [SDPNG03] está
estructurada de un modo modular, no considera aspectos de E2ENP y no
puede ser usada de un modo modular a través de mensajes diferentes
de SIP (u otro protocolo). SDPng está basado en el modelo de
oferta/respuesta de SDP en el que procesos complejos de negociación
multifase, como el propuesto en el alcance de E2ENP, no son tenidos
en cuenta explícitamente.
Un proceso capaz de tener en cuenta información
de perfiles de usuarios como entrada para el proceso global de
negociación de calidad de servicio no es tratado en la solicitud de
patente europea EP 01 122 366.6 ni en el SDPng.
En vista de las explicaciones antes mencionadas,
el objeto de la invención fundamental es proponer un método que
soporta la gestión de calidad de servicio y mecanismos de reserva
de recursos para servicios en tiempo real adaptables y aplicaciones
multimedia que funcionan en terminales móviles que están conectados
a una red inalámbrica para adaptar dinámicamente a características
de enlace variables en el tiempo del radiocanal móvil fundamental.
De tal modo, deben ser comprendidos conceptos basados en una
integración y coordinación de la gestión de recursos locales, de
iguales y de red que permiten a los iguales prenegociar un
conjunto común de capacidades, calidades y mecanismos de adaptación
antes de que tenga lugar la comunicación real para proporcionar una
calidad garantizada de extremo a extremo para dichos terminales.
Este objeto es conseguido por medio de las
características de las reivindicaciones independientes.
Características ventajosas son definidas en las reivindicaciones
subordinadas. Objetos y ventajas adicionales de la invención son
evidentes en la descripción detallada siguiente.
La invención fundamental está dedicada
básicamente a un modelo para definir información de perfiles de
usuarios y capacidades de terminales de tal modo que
especificaciones jerárquicas de contratos de calidad de servicio
(por ejemplo, correlaciones apremiantes a través de conjuntos
diferentes de contratos de calidad de servicio para flujos de
información relacionados) pueden ser impuestas y usadas para obtener
información negociable. Como una implementación de referencia de
este concepto, esta invención describe un uso original del Session
Initiation Protocol (SIP) normalizado por la Internet Engineering
Task Force (IETF) en conjunción con ampliaciones de la
especificación del Session Description Protocol Next Generation
(SDPng) basada en el Extensible Markup Language (XML) para
implementar conceptos del End-to-End
QoS Negotiation Protocol (E2ENP).
Más específicamente, el modelo propuesto por la
presente amplía los mecanismos de negociación de SDPng
permitiendo
- -
- secciones del SDPng transportando fragmentos diferentes de información complementaria que son transmitidas en fases diferentes del E2ENP que permiten la formación de una imagen de negociación completa complementando las fases de negociación, en las que cada fase es mencionada explícitamente en la descripción del SDPng;
- -
- la imposición de cuadros de tiempo para algunas de dichas secciones usadas para la fase de prenegociación, evitando así que información obsoleta sea impuesta equívocamente posteriormente.
La reivindicación independiente 1 y las
reivindicaciones subordinadas 2 a 12 se refieren a una ampliación
del Session Description Protocol Next Generation (SDPng) para
implementar conceptos necesarios dentro del alcance del
End-to-End Negotiation Protocol
(E2ENP) que proporciona una calidad garantizada de extremo a extremo
para una sesión de telecomunicación en la que aplicaciones
multimedia funcionando en terminales móviles, que están conectados
a una red inalámbrica, están implicados para adaptarse
dinámicamente a características de enlace variable en el tiempo del
radiocanal móvil fundamental. En este contexto, dichos conceptos
están basados en una integración y coordinación de la gestión de
recursos locales, de iguales y de red que permite a los iguales
prenegociar un conjunto común de capacidades, calidades y mecanismos
de adaptación antes de que tenga lugar la comunicación real. De tal
modo, dicho Session Description Protocol Next Generation (SDPng) es
usado para definir un protocolo a nivel de aplicación.
A continuación, las reivindicaciones subordinadas
13 a 49 están orientadas a un método para implementar conceptos
necesarios en el alcance del E2ENP que proporcionan una calidad
garantizada de extremo a extremo para una sesión de
telecomunicación. De tal modo, dicho SDPng puede ser aplicado para
definir información de perfiles de usuarios que es usada para
obtener entrada para el E2ENP.
Además, la reivindicación independiente 50
incumbe a un E2ENP en el que una sesión de telecomunicación
habilitada en calidad de servicio es establecida prenegociando
capacidades y aspectos alternativos de calidad de servicio sobre
una base de extremo a extremo para establecer de antemano un nivel
común de capacidades y calidad de servicio alternativas, sobre cuyo
uso pueden ponerse de acuerdo todos los iguales de la sesión de
telecomunicación.
Además, la reivindicación subordinada 51 se
refiere a un intermediario para una negociación de extremo a extremo
que proporciona una calidad garantizada de extremo a extremo para
una sesión de telecomunicación. De este modo, dicho intermediario
es capaz de liberar a los iguales de una red de la necesidad de
llevar a cabo la fase de prenegociación y, opcionalmente, la fase de
sincronización en el tiempo y la fase de correlación de calidad de
servicio de flujos múltiples según la reivindicación 35.
A continuación, la reivindicación subordinada 52
se refiere a una rutina de software que implementa un método según
una cualquiera de las reivindicaciones 13 a 49 cuando es ejecutada
por un dispositivo de computación.
Además, las reivindicaciones subordinadas 53 a 61
están dirigidas a un igual, configurado para implementar un método
según una cualquiera de las reivindicaciones 13 a 49, comprendiendo
una unidad de coordinación que coordina las fases diferentes del
proceso de negociación del proceso de gestión de recursos
distribuidos.
Finalmente, la reivindicación subordinada 62
incumbe a un protocolo que proporciona una calidad garantizada de
extremo a extremo para una sesión de telecomunicación establecida
prenegociando capacidades y aspectos alternativos de calidad de
servicio sobre una base de extremo a extremo para establecer de
antemano un nivel común de capacidades y calidad de servicio
alternativas, sobre cuyo uso pueden ponerse de acuerdo todos los
iguales de la sesión de telecomunicación. Además, la negociación y
la renegociación de capacidades incluyen la señalización de los
codificadores-descodificadores seleccionados y sus
configuraciones.
Ventajas y aplicaciones posibles adicionales de
la invención fundamental resultan de las reivindicaciones
subordinadas así como de las descripción siguiente de una
realización de dicha invención, que son representadas en los dibujos
siguientes:
la Figura 1 representa un escenario 100 de
comunicación "asistida por tercer abonado", de uno con uno,
mostrando la reubicación de llamada en una situación de conmutación
de una sesión de telecomunicaciones que presenta la idea de cómo
puede ser dispuesta la futura comunicación semejante a
telefónica,
la Figura 2 exhibe un escenario 200 de
comunicación de uno con muchos mostrando una disertación
virtual,
la Figura 3 esboza un escenario de comunicación
de muchos con muchos mostrando una forma sencilla de una
videoconferencia,
la Figura 4 esboza un escenario de comunicación
de muchos con muchos mostrando una forma compleja de una
videoconferencia,
la Figura 5 presenta un ejemplo que muestra
varios aspectos adicionales de una comunicación
multi-abonado considerando el uso de algunos
servicios que soportan el descubrimiento de los abonados y
servicios de comunicación, y el comienzo de la negociación,
la Figura 6 esboza un escenario que muestra
porqué es necesario proporcionar consistencia,
la Figura 7 esboza un escenario que muestra
porqué es necesario evitar interbloqueos, o sea, porqué el E2ENP
debe garantizar que no hay un estado de retención y espera o que
tal estado puede estar presente solo durante un período limitado de
tiempo.
la Figura 8 representa un diagrama de interacción
que muestra las fases y los actores del E2ENP por un escenario
sencillo de negociación de uno con uno para establecer una
comunicación sencilla de uno con uno,
la Figura 9 muestra la funcionalidad del E2ENP
usando el SDPng y el SIP,
la Figura 10 representa un ejemplo que muestra el
uso de la denominada sección
<e2enp:alternative-service>,
la Figura 11 muestra un escenario en el que son
validados los contratos obtenidos de la información de perfil de
usuario y configuración del sistema,
la Figura 12 muestra un ejemplo de un usuario que
se une simultáneamente a dos sesiones de videoconferencias
diferentes, y
la Figura 13 muestra un ejemplo de un escenario
de muchos con muchos que es denominado "transición a ad
hoc".
En lo siguiente debe se explicada con detalle la
realización preferida de la invención fundamental como se representa
en las Figuras 1 a 13. El significado de los símbolos designados
con signos de referencia en las Figuras 1 a 13 puede ser tomado de
la Tabla 3.
\newpage
1. Ampliación del SDPng 912 para implementar
conceptos del E2ENP 908 y sus ampliaciones propuestas por la
presente, en particular:
- -
- el contenido de SDPng (912) puede ser obtenido de la información de perfiles de usuarios, que entonces es usado como entrada para el E2ENP (908),
- -
- el contenido de SDPng (912) puede ser obtenido de información de capacidades de terminales, que entonces es usado como entrada para el E2ENP (908),
- -
- introducción de dos nuevas secciones de SDPng que detallan aspectos de calidad de servicio para un solo flujo 206 de información o grupos de ellos,
- -
- uso modular de secciones: secciones diferentes de SDPng (como se propone en el borrador de SDPng real y nuevo) pueden ser intercambiadas en las diversas fases del protocolo E2ENP 908,
- -
- adición de una etiqueta que identifica explícitamente cada contenido de SDPng en cada fase del E2ENP 908, en el que el contenido de SDPng resulta realmente una Unidad de Datos de Protocolo del E2ENP 908, siendo superpuesto (piggybacked) sobre el SIP 910 o protocolo similar (por ejemplo, SCCP).
- -
- información de SDPng prenegociada de E2ENP 908 con un alquiler para limitar oportunamente la validez de esta información, y
- -
- ampliación de soporte de SDPng 912 para especificar tipos diferentes de direcciones de red 604, más allá del soporte absoluto de IP v4.
2. Ampliación del E2ENP 908:
- -
- uso del SDPng 912 para definir información de perfiles de usuarios para ser usada como entrada para el E2ENP 908,
- -
- uso del SDPng 912 para definir la información de capacidades de terminales para ser usada como entrada para el E2ENP 908,
- -
- correspondencia detallada de E2ENP 908 sobre el protocolo SIP 910 por medio de superposición (piggybacking), y
Para satisfacer las exigencias expuestas en el
capítulo anterior, es propuesto un protocolo nuevo denominado
End-to-End QoS Negotiation Protocol
(E2ENP).
Antes de seguir con la descripción del concepto
de E2ENP 908, son presentadas por la presente algunas hipótesis
clave que completan la descripción genérica de actores y escenarios
antes descritos.
El escenario 800 sencillo de comunicación de uno
con uno.
El uso de los modos de comunicación (empujar,
tirar y empujar-tirar) puede ser dependiente de la
situación y la aplicación con respecto a los emisores y los
receptores. Algunos usos estándares de los modos son descritos
aquí:
- \bullet
- Si el ofertante 810 no tiene noción del parecido del perfil del contestador 811, el ofertante 810 puede usar el modo de "tirar" para recuperar primero los ajustes del contestador 811 y adaptar finalmente los propios ajustes del ofertante 810.
- \bullet
- Si el ofertante 810 no tiene posibilidades de adaptar (o cualquier otra razón), el ofertante 810 puede "empujar" sus ajustes al contestador 811, obligándole así finalmente a adaptar y usando el modo de "empujar".
- \bullet
- Si la adaptación en ambos lados puede ser necesaria, el modo de "empujar - tirar" podría ser usado para permitir el intercambio tripartito de la propuesta del ofertante 810. Este modo puede ser usado para ponerse de acuerdo en la comunicación bilateral (bidireccional).
Mediante una hipótesis de que los
"receptores" deberían sintonizar con "emisores" dados, los
"receptores" deberían ser los que adaptan. Si los
"emisores" deberían emparejarse con "receptores" dados, la
adaptación tiene lugar mediante los "emisores".
Hay tres escenarios para el caso del escenario
800 sencillo de comunicación de uno con uno considerando qué abonado
es el ofertante 810 y cual es el contestador 811, qué abonado es
emisor o receptor, y si ambos abonados pueden emitir y recibir:
- \bullet
- Emisor (ofertante 810) - receptor (contestador 811) En general, ambos modos de "empujar" y "tirar" pueden ser usados para este escenario según las posibilidades y reglas de adaptación del emisor y/o el receptor. Si el ofertante 810 es el que debería adaptar, el ofertante 810 debería usar un modo de "tirar", en caso contrario debería ser usado el modo de "empujar". El uso del modo de "empujar-tirar" también puede ser aplicado pero por el flujo 206 esperado de información de datos unidireccional, esto solo complicaría el protocolo de señalización y sería contradictorio con la exigencia de sencillez del E2ENP.
- \bullet
- Receptor (ofertante 810) - emisor (contestador 811).
- También en este caso, ambos modos de "empujar" y "tirar" pueden ser usados según las posibilidades y reglas de adaptación del emisor y/o el receptor. Si el ofertante 810 es el que debería adaptar, el ofertante 106b debería usar un modo de "tirar", en caso contrario debería ser usado el modo de "empujar". El uso del modo de "empujar - tirar" aquí tampoco es recomendable por las mismas razones que en el escenario anterior.
- \bullet
- Emisor - receptor (ofertante 810) o emisor - receptor (contestador 811).
- Cuando todos los iguales planean tanto emitir como recibir flujos 206 de información, el ofertante 810 recoge información sobre las capacidades de recepción y los deseos de calidad de servicio del contestador 811 antes de que el ofertante 810 curse una invitación al contestador 811 dado.
- De este modo, en el momento de invitación, el ofertante 810 puede enviar al contestador 811 una propuesta incluyendo:
- -
- información sobre las capacidades del ofertante 810 para emitir y recibir flujos 206 de información;
- -
- especificación de calidad de servicio deseada propia del ofertante 810 para recibir flujos 206 de información, adaptada a las preferencias del contestador 811; y
- -
- propuestas de calidad de servicio para emitir flujos 206 de información, adaptadas a las preferencias del contestador 811.
- El contestador 811 responde entonces al ofertante 810 con un subconjunto de la oferta del ofertante 810.
- Este escenario usa más probablemente el modo de "empujar - tirar" puesto que debería ser establecida una comunicación bidireccional.
Mediante el escenario 200 de comunicación de uno
con muchos, no todas las combinaciones de modos de conexión y modos
de negociación 806 son posibles y razonables. Por ejemplo, el
escenario de "receptor único y muchos emisores" puede causar
sobrecarga en el lado de receptor, y esto es porqué este caso
debería ser tratado obligando al receptor a llevar a cabo
negociaciones múltiples 808 y 809 sobre una base separada con cada
emisor, como en el escenario de "emisor (ofertante 810) -
receptor" (contestador 811).
Algunos escenarios de conexión bien conocidos,
correspondientes al escenario de uno con muchos, son:
- -
- Multidifusión pura: Los receptores "sintonizan" con emisores dados seleccionando un grupo dado de multidifusión, basado en información prediseminada (por ejemplo, por medio del Session Announcement Protocol (SAP)). En este caso, el emisor actúa como una clase de ofertante 810.
- -
- Este escenario funcionaría como el escenario de "receptor (ofertante 810) - emisor (contestador 811)". Esto permite flexibilidad para unirse a, y separarse de, la sesión 102. Entonces, el contestador 811 puede adaptar la sesión 102 sobre una base única para cada participante, pero teniendo en cuenta también los recursos usados por sesiones 102 ya existentes. En cambio, si el emisor hubiera tomado el papel de ofertante 810, algunos de los receptores podrían no haber sido capaces de enfrentarse a tales exigencias.
En ambos casos, el ofertante 810 (emisor o
receptor) podría usar ventajosamente información prenegociada fuera
de línea para acelerar el establecimiento de comunicación en tiempo
de ejecución. Finalmente, esto podría ser llevado a cabo mediante
agentes de usuarios como se describe en documentos publicados por
FIPA (Foundation for Intelligent Physical Agents)
(\underline{http://www.fipa.org}), designado [FIPA] en lo
siguiente, o mediante un intermediario (pero estos casos están fuera
del alcance de este documento). Todos los escenarios donde el
abonado único es un receptor deberían ser considerados como
negociación 806 de uno con uno puesto que puede ser necesaria
alguna gestión separada de recursos para cada flujo 206 de
información entrante. Escenario 300, 400, 500 de comunicación de
muchos con muchos:
Este caso podría ser tratado como la
superposición de negociaciones múltiples 809 si los iguales se
ponen de acuerdo al principio sobre la elección de un líder de
conferencia, que orquestó las negociaciones 809 para unirse
a/separarse de la sesión 102 y gestionó la ejecución de ella. Los
iguales también podría efectuar algunas disposiciones a
priori sobre como configurar el entorno de comunicación antes de
que negocien las conexiones reales. Las ejecuciones de negociación
806 en paralelo y/o en serie entre los iguales negociadores
dependen de la aplicación y de allí a partir del alcance de la
solución propuesta según la invención fundamental.
El E2ENP 908 comprende cuatro fases clave, o
sea:
- 1.
- fase 802 de prenegociación de calidad de servicio de extremo a extremo;
- 2.
- fase de imposición de correlación 804 de calidad de servicio y sincronización 805 en el tiempo de flujos múltiples;
- 3.
- fase de negociación compacta de calidad de servicio de extremo a extremo (con principio de economía) o, más brevemente, "negociación rápida" 806, y
- 4.
- fase de renegociación compacta de calidad de servicio de extremo a extremo (con principio de economía) o, más brevemente, "renegociación rápida" 808.
Todas las cuatro fases pueden ser concatenadas
dentro de la duración de una sesión 102 de información dada.
Alternativamente, las dos primeras fases pueden ser ejecutadas
independientemente de las dos últimas y en momentos diferentes, pero
siguiendo estrictamente el orden dado. Como una consecuencia, dado
que los resultados de las diversas fases de E2ENP 908 son válidas
dentro de una magnitud limitada de tiempo, las escalas de tiempo de
validez correspondientes pueden diferir de fase a fase.
Más específicamente, la fase de prenegociación
802 de calidad de servicio de extremo a extremo puede ser
ejecutada a priori, y entonces los resultados pueden ser
aplicados a las fases restantes de sesiones 102 de telecomunicación
sucesivas múltiples en momentos posteriores. Esta fase está
caracterizada por un proceso que los iguales finales pueden
realizar antes del comienzo real de una sesión 102 de multimedia, e
independientemente de la propia sesión 102. El objeto de esta fase
es permitir el intercambio (de una manera no obligada) de
información entre iguales, concerniente a configuraciones de
capacidades y contratos 1108 de calidad de servicio, como se deduce
de sus perfiles de calidad de servicio.
Estas configuraciones incluyen trayectos de
adaptación, de modo que los iguales finales pueden ponerse de
acuerdo proactivamente sobre el modo de reaccionar a posibles
cambios de calidad de servicio o violaciones de calidad de servicio
de una manera eficaz y eficiente. Opcionalmente, esta fase permite
que cada pareja de iguales negocie trayectos de adaptación de
grupo a nivel de asociación, o sea, imponga la correlación 804 de
calidad de servicio y la sincronización 805 en el tiempo a través de
todos los flujos 206 de información establecidos entre la pareja
dada de iguales.
Este intercambio de información tiene carácter
informativo para los iguales implicados y es usado no solo para
informarse entre sí por adelantado sobre las capacidades y
posibilidades de rendimiento funcional aplicables al conjunto dado
de iguales sino también para alcanzar acuerdos sobre redefinir
algunas de esas configuraciones. De este modo, los iguales son
capaces así de establecer un vocabulario común antes de cualquier
negocio específico.
La fase de imposición de correlación 804 de
calidad de servicio y sincronización 805 en el tiempo de flujos
múltiples es opcional en tanto que es necesaria solo si los iguales
están planificando establecer flujos 206 de información múltiples
que necesitan ser correlacionados y sincronizados. Los iguales
individuales únicamente aplican tal fase. Como una excepción, una
entidad separada (por ejemplo, un componente intermedio como un
puente de llamada de conferencia) también podría emplear esta fase
si los diversos iguales delegan en ella para llevar a cabo
negociaciones 806 complejas entre ellos. El caso de componentes
intermedios está fuera del alcance de este escrito, y solo es
mencionado para completar. Las fases y los actores del E2ENP 908
pueden ser tomados del diagrama de interacción representado en la
Figura 8.
La tercera fase está caracterizada por un proceso
que los iguales finales pueden realizar antes, o en el comienzo
real, de una sesión 102 de multimedia para ponerse de acuerdo sobre
un nivel dado de calidad de servicio a ser impuesto para la sesión
102 y los flujos 206 de información dados, basados en los resultados
de un proceso de prenegociación 802 de calidad de servicio, de
extremo a extremo, aplicado previamente. Este proceso es
considerablemente más rápido comparado con el caso de una
negociación completa 806 de calidad de servicio de extremo a extremo
puesto que solo referencias de información prenegociada son
intercambiadas realmente entre iguales. Una negociación completa
806 de calidad de servicio de extremo a extremo es un proceso que
los iguales finales pueden realizar antes, o en el comienzo real,
de una sesión para ponerse de acuerdo en un nivel dado de calidad
de servicio a imponer para la sesión y los flujos dados,
redefiniendo finalmente algunas de las configuraciones propuestas
originalmente de especificaciones de calidad de servicio. Al
completar el proceso de negociación compacta de calidad de servicio
de extremo a extremo, los iguales finales se han puesto de acuerdo
sobre los perfiles de calidad de servicio que van a usar durante la
comunicación. Al completar el proceso de negociación compacta 806 de
calidad de servicio de extremo a extremo, los iguales finales se
han puesto de acuerdo sobre los perfiles de calidad de servicio que
van a usar para la
comunicación.
comunicación.
La cuarta fase está caracterizada por el proceso
que los iguales finales pueden activar cuando detectan un cambio
de calidad de servicio o una violación de calidad de servicio para
ponerse de acuerdo sobre un nivel dado de calidad de servicio a ser
impuesto para la sesión 102 de multimedia dada, basados en los
resultados de un proceso de prenegociación 802 de calidad de
servicio, de extremo a extremo, aplicado previamente.
Este proceso es considerablemente más rápido
comparado con el caso de una renegociación completa 808 de calidad
de servicio de extremo a extremo puesto que solo referencias de
información prenegociada son intercambiadas realmente entre
iguales. Una prenegociación 802 de calidad de servicio de extremo a
extremo es un proceso que los iguales finales pueden activar
cuando se detecta un cambio de calidad de servicio o una violación
de calidad de servicio para ponerse de acuerdo sobre un nivel dado
de calidad de servicio a ser impuesto para la sesión y los flujos
dados, redefiniendo finalmente algunas de las configuraciones
propuestas originalmente de especificaciones de calidad de
servicio. Al completar el proceso de renegociación compacta de
calidad de servicio de extremo a extremo, los iguales finales se
han puesto de acuerdo sobre perfiles nuevos de calidad de servicio
que van a usar para la comunicación.
Al completar el proceso de renegociación compacta
808 de calidad de servicio de extremo a extremo, los iguales finales
se han puesto de acuerdo sobre perfiles nuevos de calidad de
servicio que van a usar para la comunicación.
La fase de renegociación compacta 808 de calidad
de servicio de extremo a extremo puede ser aplicada varias veces
durante la duración de cualquier sesión 102 de información
dada.
Basados en las exigencias expuestas
anteriormente, los iguales pueden prenegociar proactivamente una
directriz de gestión de recursos comunes para evitar
inestabilidades siempre que son satisfechas las condiciones que
producen las renegociaciones 808.
Hasta este punto, los iguales pueden realizar
renegociaciones 808 en dos niveles diferentes:
- \bullet
- un proceso rápido de señalización dentro de la banda (por ejemplo, cambiando en el tiempo de ejecución, en la cabecera de paquete de RTP, el tipo de información útil de RTP sin afectar a los contratos 1108 de calidad de servicio a nivel de aplicación impuestos actualmente), y
- \bullet
- un proceso más estructurado basado en la fase de renegociación 808 de calidad de servicio de extremo a extremo (siempre que el proceso anterior no es suficiente para enfrentarse con una violación/cambio dado de calidad de servicio).
Más específicamente, los iguales pueden elegir
dinámicamente usar cualquier tipo de información útil aplicable para
un contrato 1108 de calidad de servicio a nivel de usuario dado,
como se describe después. Esta elección se reflejaría en un caso de
la señalización usual dentro de banda de RTP como una forma de
renegociación 808 muy rápida. Mientras que, si ocurren violaciones
de calidad de servicio o cambios de calidad de servicio, precisando
imponer un nuevo contrato 1108 de calidad de servicio a nivel de
usuario, tendría lugar la fase de renegociación 808 de calidad de
servicio de extremo a extremo.
El campo de tipo de información útil de RTP
contenido en las cabeceras de RTP puede ser usado por emisores para
señalizar dentro de banda a sus receptores la decisión de usar otro
codificador-descodificar (negociado). Esta es una
forma de renegociación 808 que sería transparente de por sí para el
E2ENP 908. Sin embargo, los iguales que usan esta señalización
dentro de banda todavía pueden usar convenientemente el E2ENP 908
para reaccionar eficaz y eficientemente a las violaciones/cambios
de calidad de servicio. Dentro de este contexto, el uso de
señalización dentro de banda de RTP puede ser armonizado fácilmente
obligando a los iguales a validar el nuevo
codificador-descodificador propuesto respecto a
cualquier información prenegociada, no solo en términos de
capacidades sino también de contratos 1108 de calidad de
servicio.
Esto significa que el emisor validaría
primeramente (y reservarla previamente recursos consiguientemente)
la nueva capacidad, así como un nuevo contrato 1108 de calidad de
servicio (optimizando el uso de esa capacidad), con respecto a la
información prenegociada. Por otra parte, cada receptor validaría la
nueva capacidad señalizada dentro de banda por el emisor, respecto
a la información prenegociada.
Puede haber casos donde el receptor detecta que
no están disponibles recursos suficientes para activar el
codificador-descodificador dado, mientras que el
emisor ya ha conmutado el codificador-descodificador
y enviado paquetes codificados con él. Por tanto, el receptor no
puede descodificar esos paquetes, o no puede descodificarlos en un
nivel inferior de calidad de servicio (por ejemplo, a menor
velocidad/frecuencia de cuadros). Para evitar este problema, puede
suponerse que el receptor elige la última opción (descodificar a
nivel inferior de calidad de servicio) pero señaliza explícitamente
al emisor que seleccione un nivel inferior de calidad de servicio
(por medio de renegociación 808 compacta de E2ENP 908), por ejemplo
uno intermedio (suponiendo que está disponible información
prenegociada). Hasta este punto, es necesario mencionar que perder o
no interpretar un solo paquete de video, durante el tiempo de
conmutación de calidad de servicio entre el emisor y el receptor,
no es tan crítico puesto que, desde la perspectiva del usuario
humano, el cuadro único de video que falta no es observado
fácilmente. Así, la calidad de servicio de video percibida por el
usuario no debería ser considerada afectada gravemente por tales
perturbaciones pequeñas de video. Por otra parte, perder o no
interpretar un solo paquete de audio produce chasquidos audibles que
deberían ser considerados una violación desde la perspectiva del
usuario. Una solución posible de este problema puede ser la emisión
de datos de audio redundantes con calidad igual o diferente en el
mismo paquete de audio como se describe en "Información útil de
RTP para datos de audio redundantes" (RFC 2198, Network 604
Working Group, septiembre de 1.997) de C. Perkins y otros,
designado [RFC2198] en lo siguiente. Los paquetes transportan así
los datos de audio dos veces y si se pierde un solo paquete de
audio, el siguiente sustituye redundantemente a los datos perdidos.
Para soportar la calidad de servicio de audio percibida por el
usuario, tal información duplicada debería ser suministrada con
respecto a las capacidades y los contratos 1108 de calidad de
servicio acordados entre los pares, permitiendo así que el emisor
suministre en paralelo datos de audio codificados diferentemente. La
recepción de paquetes de audio aislados con calidad inferior no
debería ser considerada una violación desde el punto de vista del
usuario puesto que una persona percibiría raramente tales cambios
como, por ejemplo, conmutadores de singularidad entre señal
monofónica y señal estereofónica, si la señal monofónica es
reproducida simultáneamente en todas las cajas de audio del
dispositivo. En términos generales, la acumulación de
perturbaciones de singularidad de audio y video debería ser
considerada una violación y debería ser permitida solo durante el
tiempo de una renegociación 808 en marcha. El tratamiento de las
singularidades de información producidas es un problema de la
realización de la gestión de recursos, los mecanismos de tolerancia
y control, etc. y puede ser dependiente de la aplicación y de la
heurística.
Cuestiones clave para comprender el mecanismo
antes descrito son:
- 1.
- La señalización dentro de banda no es suficiente para permitir que los iguales se pongan de acuerdo sobre los contratos 1108 de calidad de servicio a imponer: el mecanismo de renegociación 808 completa es obtenible de hecho usando métodos más estructurados, como el E2ENP 908. Sin embargo, como una alternativa a usar E2ENP 908, el receptor puede monitorizar el nivel actual de calidad de servicio, influenciando finalmente los monitores del Real Time Control Protocol (RTCP), e identificar así cual de los contratos 1108 prenegociados de calidad de servicio está aplicando actualmente el emisor.
- 2.
- Las reservas de recursos de red no deberían ser comprometidas hasta que ambos iguales se hayan puesto de acuerdo sobre qué codificador-descodificador y qué contrato 1108 de calidad de servicio imponer. El E2ENP 908 garantiza esto gracias al "principio de economía".
Basados en las exigencias necesarias para
enfrentarse con escenarios de transferencia, todos esos contratos
1108 de calidad de servicio no soportados por el proveedor
preferido de red de usuarios dados podrían ser considerados
convenientemente como sobrantes. Estos contratos 1108 tendrían que
ser negociados en tanto que el ofertante 810 y el contestador 811
podrían ponerse de acuerdo convenientemente a priori sobre
contratos 1108 similares, a fin de tener en cuenta los acuerdo entre
los otros iguales y sus proveedores de red usados actualmente.
Cuando ocurre una transferencia vertical,
cualquiera de los iguales puede intentar validar todos sus
contratos 1108, incluyendo los sobrantes, que podrían resultar
finalmente aplicables con respecto al nuevo proveedor de red y/o al
nuevo tipo de red 604 de acceso. Esto significa que el igual que
detecta una violación o cambio de calidad de servicio puede, al
hallar que algunos contratos 1108 sobrantes son validados ahora,
iniciar una fase de renegociación 808 compacta de calidad de
servicio de extremo a extremo, no solo para indicar el nuevo
contrato 1108 de calidad de servicio a imponer sino también para
"desbloquear" dichos contratos 1108 sobrantes
prenegociados.
Además, debería observarse que después de una
transferencia vertical, algunos de los contratos 1108 válidos
previamente podrían no ser aplicables ya. Esto significa que el
"bloqueo" de tales contratos 1108 también debería ser tomado en
cuenta durante la fase de renegociación 808 compacta de calidad de
servicio de extremo a extremo.
El E2ENP 908 interacciona con las funciones de
gestión de recursos locales durante todas las cuatro fases. Más
específicamente, el E2ENP 908 interacciona con las funciones de
gestión de recursos locales y de red tanto durante la fase de
negociación 806 compacta de calidad de servicio de extremo a extremo
como durante la fase de renegociación 808 compacta de calidad de
servicio de extremo a extremo según el "principio de economía",
y basado en las directrices de gestión de recursos prenegociadas
durante la fase de prenegociación 802 de calidad de servicio de
extremo a extremo.
Dada la estructura jerárquica de la
especificación de calidad de servicio prescrita por las exigencias,
puede ser previsto que un modelo que satisface bien esas exigencias
es el basado en el concepto de máquina de estados finitos (FSM:
Finite State Machine) jerárquica como se describe en "La guía de
usuario de Unified Modeling Lenguage (UML)" (Addison Wesley
Longman, 1.999) de G. Booch, J. Rumbaugh y I. Jacobson, designado
[Booch99] en lo siguiente. En tal modelo, cada contrato 1108 de
calidad de servicio corresponde a un estado de una máquina de
estados finitos (FSM) jerárquica. En el nivel mínimo de esta
estructura jerárquica, los estados tienen correspondencia con
contratos 1108 de calidad de servicio de flujos 206 de información
individuales. El contrato 1108 nominal de calidad de servicio (o
sea, el que el usuario desea habilitar por omisión) corresponde al
estado inicial de la máquina de estados finitos (FSM) asociada con
el trayecto de adaptación dado. Cada trayecto de adaptación
corresponde a una máquina de estados finitos (FSM) elemental, en la
que los estados son mutuamente excluyentes. Estados y/o FSMs
elementales completas pueden ser anidadas dentro de estados de
nivel superior que, a su vez, son asociados con contratos 1108 de
calidad de servicio como se indicó antes: esto representa el
concepto de contexto de calidad de servicio. Dentro de un estado de
nivel superior dado, pueden coexistir FSMs anidadas concurrentes:
esto representa un grupo de trayectos de adaptación que son
correlacionados por el contexto dado de calidad de servicio.
Cada transición de tal FSM jerárquica describe un
cambio peculiar de contrato 1108 de calidad de servicio como
reacción a un suceso dado, por ejemplo una violación de calidad de
servicio. Las transiciones son activadas siempre que predicados
específicos se evalúan como verdaderos: esto se traduce en nuestro
modelo en comparar los valores de parámetros monitorizados
específicos de calidad de servicio con los valores correspondientes
expresados en los contratos 1108 dados de calidad de servicio.
Las transiciones son asociadas finalmente con
acciones de nivel alto (por ejemplo, suprimir un flujo 206 de
información existente o empezar un nuevo flujo 206 de información).
Estas acciones pueden causar finalmente la generación de sucesos
para los usuarios que indican un estado de fuera de servicio
temporal, por ejemplo debido a un caso de transferencia.
De modo diferente que el lenguaje de descripción
de calidad de servicio (QDL: QoS Description Language) como se
describe en [loyal], las especificaciones de contratos 1108 de
calidad de servicio (y, en un grado limitado, de contextos de
calidad de servicio) y de la FSM jerárquica son desacopladas entre
sí. Esto introduce modularidad y por tanto flexibilidad en el
diseño: se puede combinar un contrato 1108 dado de calidad de
servicio con directrices de adaptación diferentes, y las directrices
de adaptación pueden ser configuradas con FSMs jerárquicas
diferentes.
El proceso de negociación 806 empleado por el
E2ENP 908 consiste básicamente en ejecutar un proceso de negociación
806 in iterativa en el tiempo de establecimiento de conexión, en el
que los iguales intercambian simplemente entre ellos un conjunto
de identificadores de estados, con respecto a la FSM jerárquica que
representa un trayecto de adaptación prenegociada dado.
El ofertante 810 propondrá una oferta y cada
contestador 811 validará la oferta respecto a sus propias
directrices de adaptación y responderá consiguientemente con una
contraoferta. Este modelo limita el alcance de las contraofertas a
la definición de un subconjunto de la oferta original (para limitar
la complejidad del problema). Esto se traduce a nivel de
contestador como sigue:
- \bullet
- en una verificación de conformidad de contrato de calidad de servicio según [Frolu98] aplicada a cada elemento en la oferta, con respecto a los tipos de contratos de calidad de servicio prenegociados y los contratos 1108 de calidad de servicio; si los contratos 1108 son expresados en un documento en XML, la verificación de conformidad podría ser conseguida, por ejemplo, imponiendo una Definición de Tipo de Documento (DTD: Document Type Definition) en XML específica predefinida.
- \bullet
- en un conjunto opcional de operaciones de poda aplicadas a la estructura de la FSM jerárquica prenegociada original.
Debería observarse que siempre que un nuevo igual
se une a un grupo de iguales ya comunicando, el nuevo igual podría
actuar como el ofertante 810 de un nuevo proceso de E2ENP
(empezando finalmente desde la fase de negociación compacta de
calidad de servicio de extremo a extremo, si el nuevo igual ya tiene
información prenegociada con los iguales en comunicación),
siguiendo los mismo mecanismos antes descritos. Además, cualquier
creación, modificación o eliminación ad hoc de contextos de calidad
de servicio y/o flujos 206 de información, después de que el proceso
de negociación 809 ha sido completado satisfactoriamente (y no
tenido ya en cuenta como un cambio de calidad de servicio dentro
del trayecto de adaptación negociado), activaría un nuevo caso del
proceso de negociación 808 y 809. Más específicamente, debería
observarse que el usuario podría causar deliberadamente un cambio
de calidad de servicio en un aplicación multimedia ya en marcha,
por ejemplo para aumentar o reducir el nivel global de calidad de
servicio, o solo alguna parte de él. Esta negociación 808 y 809 se
reflejaría en un cambio en los contratos 1108 de calidad de
servicio asociados con el trayecto de adaptación, pero también
podría reflejarse en la estructura del propio trayecto de
adaptación. Como el proceso de negociación 808 y 809 es bastante
caro, cualquier reaplicación sucesiva por incrementos del E2ENP 908
o partes de él puede causar ineficacias. Hasta este punto, debería
observarse:
- \bullet
- En un escenario de video a petición, ambos abonados se ponen de acuerdo simplemente a priori sobre un trayecto de adaptación para un conjunto predeterminado de flujos 206 de información para enfrentarse con violaciones de calidad de servicio o cambios de calidad de servicio. Por tanto, la variabilidad de los cambios ad hoc antes mencionados no se aplican a este caso.
- \bullet
- El ofertante 810 ya puede finalmente tener en cuenta sucesos como la creación, modificación o eliminación de contextos de calidad de servicio y/o flujos 206 de información dentro del trayecto de adaptación que oferta.
- \bullet
- Después de la negociación 809 inicial, todos los iguales pueden convergir más rápidamente en acuerdos de negociación 806 comparados con el caso de la negociación 809 inicial, puesto que la mayoría de ellos están usando una FSM jerárquica ya negociada.
Sin embargo, las reglas para manejar estas
situaciones dependen mucho del tipo de gestión aplicada a las
sesiones 102 de telecomunicación dadas. Por ejemplo, en el caso de
servicios de conferencia, esto se traduce en elegir directrices y
protocolos específicos de control de conferencia. Por tanto, la
funcionalidad absoluta de E2ENP 908 es ideada de tal modo que
delega estas tareas de gestión de sesión 102 de alto nivel en
mecanismos y protocolos externos, que están fuera así del alcance de
la invención fundamental.
Ampliando el método por fases de E2ENP 908, son
previstos refinamientos como la introducción de microfases. Esto
significa que los iguales pueden actualizar por incrementos la
información prenegociada, por ejemplo para ajustar información
prenegociada en el caso de transferencias verticales, en los que la
tecnología/capacidad de la nueva red 604 de acceso y/o el nuevo
proveedor de red pueden ofrecer niveles diferentes de calidad de
servicio comparados con los prenegociados. Hasta este punto, es
necesaria una descripción modular de elementos negociables de modo
que los que no son afectados por los cambios sean mantenidos
válidos. Esto significa que para tales elementos no sería necesaria
entonces renegociación 808 completa, con beneficios evidentes en
términos de rendimiento funcional con respecto al tratamiento de
cambios/violaciones de calidad de servicio.
Este concepto es dejado para estudio adicional.
Más específicamente, deben ser considerados con detalle aspectos
como el impacto sobre máquinas de estados preexistentes que
describen trayectos de adaptación prenegociados.
En las secciones siguientes deben ser presentados
modos posibles de implementar la solución propuesta influenciando
protocolos existentes como SIP 910 y SDPng 912.
Hasta este punto, el SIP 910 será usado en modos
originales pero permanecerá sustancialmente inalterado, mientras que
las ampliaciones y algunos cambios de la especificación de SDPng
son propuestos aquí a fin de satisfacer las exigencias expuestas
anteriormente. La funcionalidad del E2ENP 908 usando el SDPng 912 y
el SIP 910 es representada en la Figura 9.
La idea es ampliar el uso del SIP 910 y realzar
la especificación de SDPng (que está siendo estudiada actualmente
dentro del IETF MMUSIC Working Group) para incluir las exigencias
de E2ENP, con cambios mínimos y modulares. Esta no es todavía una
especificación desarrollada sino más bien una explicación detallada
de la idea propuesta por la presente, pretendiendo aumentar el
interés y promover la discusión dentro de la comunidad técnica.
Antes de proseguir más adelante, debe ser
estudiada la cuestión de la especificación de calidad de servicio a
nivel de aplicación.
Los usuarios están interesados típicamente en
definir qué información desean intercambiar con iguales y con que
calidad (especialmente si tendrán que pagar no solo por el
contenido sino también por la calidad de servicio),
independientemente de cómo sus solicitudes serán llevadas a cabo
realmente por sus dispositivos de terminales y la red 604. Por
tanto, puede esperarse que los usuarios expresarán sus deseos
detallando la descripción de contenido y los contratos 1108 de
calidad de servicio. Este tipo de especificación de calidad de
servicio es denominada especificación de calidad de servicio a nivel
de usuario.
Además, debe suponerse que los usuarios pueden
desear definir un conjunto de contratos 1108 de calidad de servicio
como asociado con un conjunto de contenidos y/o servicios
diferentes múltiples. Hasta este punto, puede esperarse que los
usuarios querrán especificar estos contratos 1108 de calidad de
servicio sobre la marcha o, más convenientemente, predefinirlos y
almacenarlos en las denominadas bases de datos de información de
perfiles de usuarios.
Aplicaciones o software intermedio (middleware)
traducirán la especificación de calidad de servicio a nivel de
usuario en la especificación de calidad de servicio a nivel de
aplicación, que es considerada por la presente como entrada para el
E2ENP 908.
Dentro del alcance de la invención fundamental,
de hecho se está interesado en especificar la calidad de servicio
como el usuario la percibe según se describe en "Un marco para la
negociación 806 de calidad de servicio percibida por el usuario de
extremo a extremo" (IETF Internet Draft, trabajo en marcha,
<draft-bos-mmusic-sdpqos-framework-00.txt>)
de L. Bos y otros, designado [Bos01] en lo siguiente. Sin embargo,
no preocupa como el usuario expresa esto.
Claramente, es necesario que haya una
correspondencia de los deseos y preferencias de usuarios con un
conjunto de parámetros de calidad de servicio que definen la
calidad del proceso de transmisión de extremo a extremo. Este
conjunto de parámetros es denominado calidad de servicio a nivel de
aplicación. Esta correspondencia es específica de aplicación y está
fuera del alcance.
El siguiente documento en XML es un ejemplo de
cómo pueden ser especificados los contratos 1108 de calidad de
servicio a nivel de aplicación: en este ejemplo, solo son indicados
contratos 1108 de calidad de servicio para flujos 206 de
información de audio y video, pero la ampliación para incluir otros
tipos de flujos 206 de información (como flujos 206 de información
de datos o control) es sencilla. Para cada tipo de flujo 206 de
información, un conjunto de parámetros de calidad de servicio a
nivel de aplicación son especificados en términos de valores
nominales, conjuntos nominales o márgenes operativos.
Los parámetros indicados en los contratos 1108 de
calidad de servicio para flujos 206 de información de audio
reflejan los parámetros de
codificadores-descodificadores de audio indicados en
[RTP-Profile], con la diferencia que la
información de perfiles de usuarios describirá márgenes más bien que
configuraciones fijas de esos parámetros. Por otra parte, los
parámetros indicados en los contratos 1108 de calidad de servicio
para flujos 206 de información de audio no reflejan las
prescripciones de [RTP-Profile]; más bien, son
usados los parámetros de calidad de servicio sugeridos en
[BRAIN].
Ejemplo 1 de
XML
En perfiles de usuarios, los usuarios pueden
especificar la calidad de servicio con niveles diferentes de
granulaciones: valores objetivo específicos o márgenes operativos,
como conjuntos discretos o como intervalos continuos. El
"frame-size-set" indica el
tamaño de los cuadros representados. Puede ser especificado como un
tamaño de cuadro estándar (CIF, QCIF, SIF, etc.) o como una
resolución de anchura-altura en píxeles (por
ejemplo, 352x288).
El
"frame-rate-set" indica un
intervalo para especificar la frecuencia objetivo de cuadros de los
iguales. Por ejemplo, si la frecuencia de cuadros es dispuesta en
20 cuadros/s, el emisor debería ser capaz de comprimir, dividir en
paquetes y enviar 20 cuadros por segundo. El receptor debería ser
capaz de descodificar y representar 20 cuadros por segundo.
Información adicional sobre la correspondencia de
codificadores-descodificadores de video con respecto
al tamaño de cuadro puede ser hallada en
"Codificadores-descodificadores de IP/TV,
Consideraciones sobre exigencias de transferencia y almacenamiento
de archivos" (White Paper, julio de 2000,
\underline{http://www.cisco.com/warp/public/}
\underline{cc/pd/mxsv/iptv3400/tech/ipcod\_wp.htm}), designado [WP-CISCO] en lo siguiente.
\underline{cc/pd/mxsv/iptv3400/tech/ipcod\_wp.htm}), designado [WP-CISCO] en lo siguiente.
El
"color-quality-range" y el
"overall-quality-range" indican
un margen de niveles posibles de compresión para un solo cuadro que
pueden estar disponibles para un
codificador-descodificador dado. Cuanto mayor es la
compresión producida de los datos de video, menor es la calidad. En
[Handl98] se sugiere expresar la calidad con números entre 0
(calidad mínima) y 10 (calidad máxima), indicando que esta debería
ser la calidad de un solo cuadro. Sin embargo, esta resolución es
bastante pequeña considerando que los
codificadores-descodificadores existentes y los
codificadores-descodificadores que ha de ser
desarrollados en el futuro pueden tener más de 10 niveles de
compresión. El margen así definido como se describe en [Handl98] no
satisface las exigencias antes definidas, de aquí la propuesta para
un margen de calidad más amplio entre 0 y 10.000, donde 0 es la
calidad mínima y 10.000 es la máxima. Este margen debería ser
aplicado tanto al
"color-quality-range" y al
"overall-quality-range". Como
la calidad de los planos de crominancia de un solo cuadro no es
relevante para cada codificador-descodificador, el
"color-quality-range" debería
ser considerado opcional.
La sección siguiente describe una propuesta de
ampliación de SDPng teniendo en cuenta las exigencias expuestas
anteriormente (a favor de la sencillez y la legibilidad, en este
documento se sigue la convención de indicar caracteres como
"&" como son en lugar de la versión evitada (o sea,
"&" por "&") asignada por la norma de XML).
En este contexto, el objeto es definir ampliaciones modulares de
SDPng 912. Esto puede ser conseguido introduciendo un conjunto de
secciones nuevas dentro del nuevo espacio de nombre "e2enp".
Las secciones nuevas pueden ser definidas como parte de una versión
nueva de SDPng 912 o en un perfil separado de SDPng 912 denominado
E2ENP 908, conteniendo el esquema correspondiente de XML como se
describe en "Esquema de XML: fundamentos", "Esquema de XML:
estructuras" y "Esquema de XML: fundamentos", "Esquema de
XML: estructuras" y "Esquema de XML: tipos de datos" (W3C,
2001), designado [XMLSC] en lo siguiente. Así, un nuevo perfil de
E2ENP 908 presentaría una cabecera como la siguiente:
Ejemplo 2 de
XML
En cualquier caso, por la presente son propuestos
algunos cambios en la propuesta actual de SDPng (incluyendo el
codificador-descodificador de audio y los perfiles
de RTP) definida en la "Descripción de sesión y negociación de
capacidades" (IETF Internet Draft, trabajo en marcha,
<draft-ietf-mmusic-sdpng-03.txt>)
de D. Kutscher y otros, designado [SDPNG03] en lo siguiente. Si son
aceptados, estos cambios afectarían por tanto al esquema de XML del
SDPng 912 original (y codificador-descodificador de
audio y perfiles de RTP).
La decisión sobre si moverse a una versión nueva
de SDPng 912 o definir una ampliación de ella es dejada para
discusión.
El nuevo espacio de nombre "e2enp" debe ser
indicado en el elemento raíz del documento de SDPng (o sea, el
elemento <desc>).
En primer lugar, esta propuesta introduce el uso
de una nueva sección <e2enp:purpose> de SDPng para
identificar unívocamente el contenido de SDPng como asociado con
fases específicas de E2ENP 908, según las exigencias antes
expuestas. Como es propuesto que la información de SDPng sea
superpuesta (piggybacked) por medio de métodos estándar de SIP 910,
este método permite ampliar las posibilidades de uso de SIP 910
definiendo un metaprotocolo basado en SDPng de E2ENP 908, sin
cambiar la semántica ni la gramática del SIP 910.
Además, para imponer las características del
E2ENP 908, esta propuesta (i) define otras dos secciones nuevas de
SDPng, <e2enp_qosdef> y <e2enp:qoscfg>, y (ii) permite
que las diversas secciones resultantes del SDPng 912 sean
suministradas independientemente por SIP 910 (u otros protocolos de
sesión 103 de señalización) por medio de superposición
(piggybacking), en momentos diferentes y por medio de métodos
diferentes, según las diversas fases de E2ENP 908.
Esta propuesta introduce cambios pequeños en la
sección <cfg> de SDPng 912, y proporciona pautas detalladas
de cómo la información contenida en esa sección debería ser
enlazada con las otras secciones nuevas.
Esta propuesta también revisa la semántica de la
sección <constraints> de SDPng 912, desde la sección
<e2enp:
qoscfg>, que permite especificar restricciones de correlación 804 de calidad de servicio y sincronización 805 en el tiempo y ya cubre la mayoría de las características correspondientes.
qoscfg>, que permite especificar restricciones de correlación 804 de calidad de servicio y sincronización 805 en el tiempo y ya cubre la mayoría de las características correspondientes.
Así, esta propuesta intenta definir las máximas
ampliaciones modulares posibles de SDPng 912 a fin de permitir la
interoperatividad fácil con aplicaciones que no soportan dichas
ampliaciones.
El SIP 910 es definido como un protocolo de
sesión 103 de señalización para establecer la comunicación entre
iguales. En general, solo considera la iniciación de la conexión,
dejando aparte las características específicas de uso y/o
aplicación. Estas características son descritas con los medios de
SDP o SDPng 912.
En algunos casos es necesario que la aplicación
tenga alguna información adicional sobre como tratar la información
de SDP/SDPng suministrada sobre el SIP 910, considerando
especialmente que, desde el punto de vista de aplicación, el
protocolo se ejecuta como en un modo modular. El "modo modular"
no satisface siempre las características de atomicidad,
consistencia, aislamiento y durabilidad de las transacciones, que
es por lo que este procedimiento de SIP NO debería ser considerado
generalmente una transacción.
Como el E2ENP 908 requiere tres intercambios de
información diferentes entre iguales (es decir, las fases de
prenegociación 802 de calidad de servicio de extremo a extremo,
negociación 806 de calidad de servicio de extremo a extremo y
renegociación 808 de calidad de servicio de extremo a extremo), es
necesario diferenciar los procedimientos correspondientes dentro del
protocolo.
SDPng 912 puede transportar explícitamente la
señalización sobre el tipo de fase, el comienzo/parada de la fase
dada y/o el estatus de reserva de recursos, independientemente del
SIP 910 (o cualquier protocolo de sesión 103 de señalización que es
usado para superponer (piggybacking) información de SDPng). Hasta
este punto, debe ser definido un metaprotocolo basado en SDPng,
introduciendo una sección nueva de SDPng, que esté presente en toda
la información de SDPng relacionada con E2ENP, en el mismo
principio del contenido de SDPng, como una forma de cabecera de PDU
(Protocolo Data Unit).
El ejemplo siguiente muestra una declaración
posible de la sección <e2enp:purpose>.
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
(Esquema pasa a página
siguiente)
\vskip1.000000\baselineskip
Ejemplo 3 de
XML
El elemento <session> identifica
unívocamente la fase dada de E2ENP 908 descrita en la porción
restante del contenido de SDPng. La definición del elemento
<session> está basada en el elemento <owner> propuesto
en [SDPNG03]. La negociación y el uso de identificadores compactos
de sesión es obtenida (por ejemplo, por medio de dirección
calculada (hash)) del elemento <session> para limitar el
tamaño de las PDUs del E2ENP. El elemento <session> (con una
dirección calculada (hash)) puede ser usado en la primera PDU de
cualquier fase dada de E2ENP o concatenación de ellas.
El elemento hijo <expires> indica durante
cuanto tiempo ha de ser considerad válida la información de SDPng
correspondiente al elemento <session> dado. Al responder al
ofertante 810, cada contestador 811 debe iniciar un temporizador,
dispuesto en el valor especificado en el elemento <expires>.
Si este temporizador termina, el contestador 811 debería mover la
información de SDPng correspondiente en un estado "zombi". A
su vez, el ofertante 810 debe regenerar la información dada de SDPng
antes de que termine dicho temporizador.
Solo cuando ya no existen sesiones 102/103 de
información o señalización referentes a esa información de SDPng,
el ofertante 810 y/o el contestador 811 pueden desechar
silenciosamente la información "zombi". Esta base lógica
también se aplica al caso de otra información de SDPng referente a
la información obsoleta dada de SDPng (véase el párrafo siguiente):
mientras exista cualquier información válida (o sea, no en un
estado "zombi") de SDPng referente a la información
"zombi" dada, el ofertante 810 y/o el contestador 811 no
pueden desechar silenciosamente dicha información "zombi" de
SDPng.
La información de SDPng, a la que se refiere el
elemento <session>, puede ser usada en otros casos de
contenido de SDPng para referirse a elementos definidos en el
contenido referenciado de SDPng. Este mecanismo es proporcionado por
medio del elemento <use> que permite crear una lista de
referencias a casos preexistentes conocidos del elemento
<session>.
Por ejemplo, el contenido de SDPng, que describe
un caso de la fase de negociación 806 de calidad de servicio de
extremo a extremo para una pareja dada de iguales, debe hacer
referencia a información prenegociada por adelantado indicando en
la construcción <use> de la sección <e2enp:purpose> el
elemento <session> único de esa información prenegociada. Por
supuesto, esta referencia no sería necesaria (y así el elemento
<use> no estaría presente) si el contenido de SDPng relativo a
las dos fases fuera superpuesto (piggybacked) conjuntamente en un
mensaje de SIP (o sea, el caso de fases llevadas a cabo
consecutivamente en el tiempo).
La presencia del elemento hijo <expires> en
los elementos <session> relacionados dentro de la sección
<use> no es obligatoria. Si está presente, no obstante, el
significado diferiría ligeramente del uso normal del elemento hijo
<expires>: de hecho su presencia significaría durante cuanto
tiempo el elemento <session> referido dado debería ser
considerado válido (o sea, tiempo restante de validez de la sesión
E2ENP), desde el punto de vista del elemento <session> que lo
refiere. Por supuesto, un elemento <session> dado puede hacer
referencia a otros durante una ventana de tiempo no mayor que el
valor original del tiempo especificado en el elemento hijo
<expires> de las sesiones 103 referidas.
El elemento <description> indica la
naturaleza de la información de SDPng, a la que se refiere la
sección <e2enp:
purpose> dada. Los atributos "type", "name" y "mode" del elemento <description> son definidos como sigue:
purpose> dada. Los atributos "type", "name" y "mode" del elemento <description> son definidos como sigue:
El atributo "type" identifica quién es el
ofertante 810 y quién es el contestador 811 de una fase dada de
E2ENP 908.
El atributo "name" define el tipo de fase de
E2ENP 908, cuya descripción está contenida en la parte restante del
contenido de SDPng:
- \bullet
- "Standard": Uso estándar del mensaje de SIP que se superpone a (piggybacking) este contenido de E2ENP 908 según "SIP 910": Session Initiation Protocol'', IETF SIP 910 Working Group, ACIRI, marzo de 1.999, trabajo en marcha, <draft-ietf-sip-rfc2543bis-04.txt>, de M. Handley y otros, designado [SIPBIS04] en lo siguiente.
- \bullet
- "Pre-negotiation" 802: El mensaje de SIP que se superpone a (piggybacking) este contenido de E2ENP 908 es usado para llevar a cabo la fase de prenegociación 802 de calidad de servicio de extremo a extremo.
- \bullet
- "Negotiation" 806: El mensaje de SIP que se superpone a (piggybacking) este contenido de E2ENP 908 es usado para llevar a cabo la fase de negociación 806 de calidad de servicio de extremo a extremo.
- \bullet
- "Re-negotiation" 808: El mensaje de SIP que se superpone a (piggybacking) este contenido de E2ENP 908 es usado para llevar a cabo la fase de renegociación 808 de calidad de servicio de extremo a extremo.
- \bullet
- "Start-Reservation": El mensaje de SIP que se superpone a (piggybacking) este contenido de E2ENP 908 es usado para señalizar el comienzo de un proceso de reserva (durante una fase de negociación 806 de calidad de servicio de extremo a extremo o una fase de renegociación 808 de calidad de servicio de extremo a extremo).
- \bullet
- "Ready-Reservation": El mensaje de SIP que se superpone a (piggibacking'' este contenido de E2ENP 908 es usado para señalizar la terminación de un proceso de reserva (durante una fase de negociación 806 de calidad de servicio de extremo a extremo o una fase de renegociación 808 de calidad de servicio de extremo a extremo).
- \bullet
- "Cancel-Reservation": El mensaje de SIP que se superpone a (piggybacking) este contenido de E2ENP 908 es usado para señalizar la solicitud para liberar recursos reservados previamente.
- \bullet
- "Canceled-Reservation": El mensaje de SIP que se superpone a (piggybacking) este contenido de E2ENP 908 es usado para confirmar la liberación de recursos reservados previamente.
- \bullet
- "Expire": El mensaje de SIP que se superpone a (piggybacking) este SDPng 912 es usado para forzar la terminación de la información de SDPng identificada por el elemento <session> dado. Contextualmente, el tiempo de atributo del elemento hijo <expires> del elemento <session> dado debe ser puesto a cero. Cuando esta orden es usada, los contenidos de E2ENP 908 que hacen referencia al elemento <session> dado son forzados a ser liberados según la base lógica.
- \bullet
- "Taken-Over": Esta orden es usada por el mediador 106a1 en negociaciones 806 asistidas por tercer abonado para notificar al igual, a quien la negociación 806 está siendo reorientada, que tal reorientación está teniendo lugar.
Si algunas fases son concatenadas, el atributo
"name" indicaría solo la última fase. Otras definiciones del
elemento "name" podrían ser consideradas en el futuro.
El atributo "mode" indica el modo de
negociación 806. Este atributo se aplica solo si el atributo
"name" es dispuesto en "pre-negotiation" o
"negotiation". Los valores por omisión para los elementos
"type", "name" y "mode" son "request",
"standard" y "push", respectivamente.
El parámetro <mediation> es opcional y
puede tomar cualquier de los valores siguientes:
Si no es aplicado, el tipo de la negociación 806
es simplemente de igual a igual. Este parámetro es usado para
indicar que un igual está negociando en nombre de algún otro. Esto
también sería indicado implícitamente sobre la cabecera "Form"
del mensaje de SIP y el elemento <session> de la sección
<purpose>. Los iguales que negocian en nombre de algún otro
deberían ser considerados generalmente servicios como partes
mediadoras de un intermediario, servicios de conferencia, etc. El
mediador 106a1 usa el parámetro <mediation> para informar a
los abonados negociadores que no es el abonado que va a enviar y/o
recibir sino solo un abonado que media en la negociación 806. En
este caso, el mediador 106a1 debería usar
"third-party-assisted" como
indicación de su funcionalidad.
Siempre que se inicia una sesión con un operador
de red (en el momento de encendido y siempre que ocurre una
transferencia vertical), el operador de red validará las
preferencias de calidad de servicio de usuario (ya emparejadas
respecto a las capacidades de terminales) respecto a las
capacidades de red.
Sin embargo, en este momento todavía no es
posible prever si y cuando ocurren casos en los que dos iguales
finales no tienen en absoluto ninguna oportunidad de ponerse de
acuerdo sobre un conjunto común de contratos de calidad de servicio.
En tales casos, una solución adoptada típicamente es insertar
unidades de transcodificación a lo largo del trayecto de datos.
Es prevista la posibilidad de acoplar tales
unidades con proxies de SIP y servicios de directorio a fin de
obligar al ofertante a usar un transcodificador específico o una
cadena de ellos.
Siempre que falla la sesión de E2ENP entre los
dos iguales finales, el ofertante podría intentar pedir apoyo del
operador de red o de cualquier otro proveedor de servicios, para
proporcionar servicios de transcodificación.
Esto significa descubrir cualquier (cualesquier)
unidad(es) de transcodificación disponible(s) por
medio de un servicio de directorio, satisfaciendo las exigencias
dadas del ofertante y las capacidades del contestador, y gestionar
la negociación de tercer abonado entre el ofertante, los diversos
transcodificadores en el medio y el contestado. Por tanto, el
servicio de transcodificación usaría el E2ENP análogamente a lo que
hace actualmente MEGACO ("Media Gateway Control (MEGACO)",
http://www.ietf.
org/html.charters/megaco-charter.html, designado
[MEGACO] en lo siguiente. El servicio de transcodificación
orquestaría el emparejamiento de nodos en la cadena de iguales y
tendría cuidado de que los recursos sean reservados apropiadamente
por medio del principio de economía de E2ENP (consideración similar
para liberación de recursos).
Si la conexión entre los dos usuarios finales
abarca dominios y/o tecnologías administrativas múltiples, también
puede ser posible que cooperen los servicios de transcodificación
ofrecidos por proveedores diferentes, usando E2ENP nuevamente para
realizar negociación de tercer abonado.
Hasta este punto,
"external-negotiation" ("negociación
externa") describe el caso en el que el mediador 106a1 actúa
como un tercer abonado externo en nombre de una entidad que intenta
obligar a dos iguales a llevar a cabo el E2ENP entre ellos mismos.
El servicio de transcodificación indicado anteriormente controlaría
uno o varios de tales "mediadores externos" en tándem.
La idea de una funcionalidad externa que controla
el establecimiento de un trayecto entre varias unidades de
procesamiento es bien conocida en la literatura (por ejemplo,
"Conseguir la transportabilidad de servicios en ICEBERG" de Z.
M. Mao y R. Katz, en Memorias del IEEE 2.000, Globecomm Workshop
"Entornos de clientes virtuales y transportabilidad de servicios
del IEEE 2000", IEEE, diciembre de 2.000). Así, el objeto de la
solución propuesta por la presente es permitir ampliar el alcance
del protocolo E2ENP a casos complejos, precisando de tal modo
componentes intermedios como transcodificadores. Hasta este punto,
el concepto de una multiplicidad de mediadores externos del E2ENP
controlados por el núcleo de servicio de transcodificación es
considerado como una innovación propuesta por esta invención.
El elemento <mediation> podría experimentar
desarrollo futuro con respecto a valores adicionales diferentes que
los descritos anteriormente. Si la participación activa del
mediador 106a1 en el flujo de información de datos debería ser
considerada o si más de un componente de mediación debería tener
lugar en la negociación 806, por ejemplo implicación de Unidades de
Control de Conferencia, intermediario de calidad de servicio, etc.,
esto sería indicado por medio del elemento <mediation>.
El ejemplo siguiente corresponde al mensaje
inicial de una sesión de SIP dentro de la sesión de E2ENP entre el
mediador 106a1 y el contestador 106a2 futuro:
Ejemplo 4 de
XML
\vskip1.000000\baselineskip
La respuesta "380 Alternative Service" de
SIP, como se describe en [SIPBIS04], podría ser usada no solo para
indicar un servicio redundante a un servicio que no puede tomar
actualmente la llamada sino también para reorientar una conexión a
otro dispositivo si el igual llamado no tiene capacidades para
manejar la llamada, pero puede aprovechar el uso de algunos
servicios de asignación y presencia para detectar otro igual
próximo que puede manejar la llamada. El proceso de asignación de
dispositivos y servicios está fuera del alcance de la invención
fundamental, pero en general podrían tenerse en cuanta tecnologías
existentes como Bluetooth, como se describe en la Especificación de
la Versión 1.1 del Sistema de Bluetooth
(\underline{http://bluetooth.com/files/Bluetooth\_11\_Specifications\_Book.pdf}),
designado [BLUE] en lo siguiente, y el soporte de SIP 910 para
presencia como se describe en "Ampliaciones de SIP 910 para
presencia" (SIMPLE Working Group, trabajo en marcha,
<draft-rosenberg-impp-presence-01.txt>)
de J. Rosenberg y otros, designado [SIPPRE01] en lo siguiente.
Según [SIPBIS04], los servicios alternativos son
descritos "en el cuerpo de mensaje de la respuesta". Una
posible estructura de SDPng 912, que describe la dirección y la
referencia a los ajustes de perfiles de un servicio alternativo, es
mostrada a continuación:
\vskip1.000000\baselineskip
Ejemplo 5 de
XML
en el que
La sección <service> es usada para
describir el servicio alternativo, se refiere a descripciones 112 de
sesiones de mensajes de E2ENP o es transportada dentro de ellas.
Muchas de estas descripciones transportadas empiezan con una sección
<purpose>. De tal modo, la sección <service> puede ser
repetida.
En caso de mediación, las secciones
<service> múltiples pueden tener la misma
<service-id> pero se dirigen a descripciones
de sesiones diferentes puesto que el mediador 106a1 debería
informar tanto al ofertante 106b como al contestador 106a2 futuro
sobre las negociaciones correspondientes que el mediador 106a1
realiza por una parte con el ofertante 106b y por otra parte con el
contestador 106a2 futuro dirigirse a información desconocida como
se describe en las exigencias para el mediador.
Si el uso es estándar según [SIPBIS04], las
sesiones <service> múltiples describen servicios alternativos
múlti-
ples.
ples.
La descripción actual de la sección
<alternative-service> es solo en el sentido
de E2ENP y negociación mediada. La descripción adicional del uso de
<alternative-service>, en el sentido como es
definido por [SIPBIS04], sería considerada en el futuro cuando son
tenidos en cuenta servicios habilitados para SIP.
Ejemplo 6 de
XML
Según las exigencias del mediador 106a1, no es
permitido usar referencias a sesiones desconocidas. Eso es porqué
implementando un mediador el elemento <use> de una sección
<purpose> dentro de una sesión referida desde una sección
<service>, debería ser suprimido como en el ejemplo anterior.
Entonces, el mediador debería tener cuidado de recoger toda la
información referida y ponerla explícitamente (sin referencias) en
la(s) descripción(es) actual(es).
La Figura 10 exhibe un ejemplo que muestra el uso
de la sección <e2enp:alternative-service>.
La indicación de la dirección y la versión en el
tercer mensaje dentro del elemento
<service-id> puede ser usada directamente por
el ofertante 106b (dispositivo de Kate) para crear la nueva llamada
de SIP 910 al nuevo contestador 106a2 (terminal en la casa de
Mary). Esta información es necesaria especialmente en casos cuando
el ofertante 106b no conoce el dispositivo móvil a donde esta
siendo reorientada la llamada.
En comparación con la propuesta de SDPng
existente [SDPNG03], adjunto se propone distinguir definiciones de
codificadores-descodificadores de definiciones de
tipos de información útil de RTP y parametrización de
codificador-descodificador. Para parametrización de
codificador-descodificador, por la presente se
propone la lista de parámetros que acompaña a la definición de un
codificador-descodificador dado, por ejemplo la
frecuencia de muestreo y el número de canales en el caso de
codificadores-descodificadores de audio. Esto
produce la definición de una nueva sección de SDPng y la
redefinición del codificador-descodificador de audio
y perfiles de RTP.
Con estas hipótesis, los abonados negociadores
pueden convergir directamente en acuerdos podando primero todos los
codificadores-descodificadores que no son soportados
por todos los iguales. Una vez que ha sido identificado el conjunto
de codificadores-descodificadores acordado en común,
los abonados negociadores pueden, como un paso adicional, manejar
la negociación 806 de tipos de información útil y parametrizaciones
de codificadores-descodificadores. La definición de
tipos de información útil es descrita en
[RTP-Profile], y el [RTP-Profile] es
definido en [SDPNG03].
Con respecto a
codificadores-descodificadores de audio, los tipos
de información útil estática están asociados con parametrizaciones
fijas de codificadores-descodificadores, como se
define en [RTP-Profile]: por tanto, sólo para tipos
de información útil dinámica es necesaria una especificación
detallada de parametrización de
codificador-descodificador. Hasta este punto, se
propone usar el formato de línea como se describe en [SDPNG03].
Referente a
codificadores-descodificadores de video, la
parametrización indicada en [RTP-Profile] no es
suficiente para caracterizar completamente el
codificador-descodificador dado desde una
perspectiva de calidad de servicio. Son previstas dos soluciones
posibles:
- 1.
- Prenegociar los nombres, tipos de información útil y parametrizaciones de codificadores-descodificadores (parcialmente) antes de cualquier prenegociación 802 específica de usuario: Esto significa dividir la fase de prenegociación 802 de calidad de servicio de extremo a extremo en dos subfases distintas: en una etapa anterior, solo tendría lugar la prenegociación 802 de información relacionada con terminales; después esta subfase sería seguida por una (o muchas) subfases de prenegociación 802 específicas de usuarios que influencian la información de perfiles de usuarios en momentos posteriores, en los que cada una de estas subfases posteriores establecería una correspondencia de la información de perfiles de usuarios con los resultados de subfases anteriores. La razón para prenegociar también la parametrización de codificador-descodificador en la subfase de prenegociación 802 relacionada con terminales procede del hecho de que los abonados negociadores pueden desear estrechar el margen de configuraciones posibles de codificadores-descodificadores de video, a fin de satisfacer las exigencias de viabilidad, con respecto a la cantidad real de recursos de hardware/software de los iguales dados.
- 2.
- Alternativamente, determinar que subconjuntos del perfil de usuario coinciden con las capacidades dadas y la cantidad (potencial) de recursos locales, y negociar solo esos subconjuntos con iguales, junto con nombre de codificadores-descodificadores y los tipos de información útil.
Ambas alternativas son ilustradas en el diagrama
representado en la Figura 11. En el caso de negociar solo
codificadores-descodificadores, la "calidad de
servicio a nivel de usuario" es inexistente y el "boceto de
contratos de calidad de servicio" es igual al "archivo de
configuración del sistema". Respectivamente, solo las capacidades
del sistema serían validadas para tal caso. Siguiendo esta base
lógica, las aplicaciones pueden ser diseñadas de un modo más
sencillo: manejan negociaciones 806 de parametrización de
codificador-descodificador en una subfase anterior o
manejan simplemente la negociación 806 de especificación de calidad
de servicio específica de usuario.
Las descripciones de
codificadores-descodi-ficadores
pueden ser asimiladas a descripciones de capacidades de utilidad
general que los iguales pueden prenegociar fuera de línea entre
ellos mismos. La información prenegociada también puede referirse
a, y/o ser incorporada en, perfiles de SDPng 912 como se describe en
[SDPNG03].
Además, deben ser introducidos intervalos en la
parametrización original de
codificador-descodificador de SDPng 912 para reducir
el número de elementos a negociar. Este método también permite una
definición de trayectos de adaptación de una manera intuitiva así
como evitar ambigüedades, especialmente con respecto a la
caracterización del flujo 206 de información de video.
Una nueva sección <e2enp:qosdef> de SDPng
912 proporciona medios para expresar tanto las capacidades como los
contratos 1108 de calidad de servicio a nivel de flujo de un modo
modular:
- -
- un caso de la sección <e2enp:qosdef> calificada con el atributo "name" dispuesto en "capabilities" describe solo la información relacionada con terminales referente a capacidades, mientras que
- -
- un caso de sección <e2enp:qosdef> calificada con el atributo "name" dispuesto en "contracts" describe las diversas parametrizaciones de esas capacidades que coinciden con la información dada de perfiles de usuarios en términos de contratos 1108 a nivel de flujo.
La aplicación y/o el middleware seleccionarán el
codificador- descodificador óptimo a partir de la sección
<e2enp: qosdef name="capabilities"> prenegociada, y un
subconjunto de contratos 1108 de calidad de servicio a partir de la
información dada de perfiles de usuarios. La información
resultante (un subconjunto del producto cruzado de la sección
<e2enp:qosdef name ="capabilities"> y de la información
de perfiles de usuario) formará entonces la sección
<e2enp:qosdef name = "contracts"> que se ocupa de los
contratos 1108 de calidad de servicio a nivel de flujo en el nivel
de aplicación. Esta nueva sección difiere de la información
original contenida en la información de perfiles de usuarios en
tanto que ahora son especificados atributos de codificación
específicos. Entonces, esta sección <e2enp:qosdef name =
"contracts"> será intercambiada entre iguales durante la
fase de prenegociación 802. La Figura 11 muestra un escenario 1100
en el que contratos 1108 de calidad de servicio son obtenidos de
información de perfiles de usuarios y configuración del sistema.
Después de eso, ellos son validados.
La prenegociación 802 de los dos tipos de
secciones <e2enp:qosdef> puede tener lugar entre iguales en
momentos diferentes, con independencia del uso real posterior, y
ser observada en el tiempo con escalas de tiempo diferentes, usando
el elemento <expires> de la sección <purpose> asociada
con la sección <e2enp:qosdef> dada. La limitación en el
tiempo de la validez de información de E2ENP 908 es necesaria para
evitar usar información obsoleta en un momento posterior.
La sección <e2enp:qosdef name =
"capabilities"> permite que los iguales se pongan de
acuerdo sobre un subconjunto común de capacidades a ser empleadas
durante sesiones 102 de información posteriores. Esta sección actúa
como un recipiente de dos clases de elementos, definiciones de
codificadores-descodificadores y definiciones de
tipos de información útil, aplicadas a cada tipo de información
(audio, video, etc.). Se prevé que serán usadas definiciones
procedentes de los perfiles originales de
codificador-descodificador de audio, RTP y
codificador-descodificador de video especificados
en [SDPNG03] pero con algunas ampliaciones, como se indica a
continuación.
Ejemplo 7 de
XML
A favor de la sencillez, este ejemplo muestra la
definición de codificadores-descodificadores de
video tanto con como sin parametrización de
codificador-descodificador. De otro modo, la sección
<e2enp:qosdef name = "capabilities"> debe contener
parametrización de codificador-descodificador o no
contener ninguna de ellas.
Puede observarse fácilmente que la información
transportada en esta sección es equivalente ahora a una clase de
archivo de configuración del dispositivo de terminal de usuario;
esta información es independiente del usuario y por tanto
complementaria del contenido de la información de perfil de usuario
así como del contenido de la sección <e2enp:qosdef> (obtenido
de dicha información de perfil de usuario) que se ocupa de los
contratos 1108 de calidad de servicio a nivel de flujo.
El atributo "scope" indica en una solicitud
(oferta de negociación) si el elemento de SDPng 912 correspondiente
ha de ser considerado como una opción necesaria (aplicable) o
deseada (posible); mientras que en una respuesta (contraoferta de
negociación), ese atributo indica si el elemento de SDPng 912
correspondiente ha sido validado (aplicable) o rechazado (no
aplicable)
El contestador 811 también puede indicar en la
contraoferta qué capacidades puede soportar y hasta que grado. Si
una capacidad dada es soportada "como es", solo es indicado el
identificador correspondiente, junto con el atributo "scope"
dispuesto en "applicable". Si una capacidad dada no es
soportada, el identificador correspondiente es suprimido
simplemente.
Si el contestador 811 propone en la contraoferta
una versión modificada de la parametrización de una capacidad dada
en la sección <e2enp:qosdef name = "capabilities"> (como
un subconjunto de la oferta original), toda la descripción con las
actualizaciones es devuelta en ambos tipos de secciones
<e2enp:qosdef>. En cualquier caso, la sección
<e2enp:qosdef>, que se ocupa de los contratos 1108 de calidad
de servicio a nivel de flujo, contiene en una respuesta solo
parametrizaciones actualizadas de
codificadores-descodificadores.
Adicionalmente, el contestador 811 puede indicar
una opción nueva (desconocida para el ofertante 810 en el tiempo de
prenegociación 802): esto será marcado como "possible". La
idea es que el ofertante 810 puede ser informado así de una opción
potencial que podría ser usada finalmente más tarde si el ofertante
810 es mejorado con una capacidad nueva que coincide con esa
opción.
Por ejemplo, el contestador 811 podría indicar el
soporte de un codificador-descodificador que el
ofertante 810 no soporta actualmente. Si el ofertante 810 adquiere
de algún modo ese codificador-descodificador dado
(por ejemplo, descargando un componente de software), el ofertante
810 podría mejorar entonces sus directrices para tener en cuenta
esta nueva capacidad.
El valor "possible" también podría indicar
que el estado del contestador 811 es parcialmente ocupado con
respecto a un codificador-descodificador propuesto
por el ofertante 810. De este modo, el contestador 811 puede tener
en cuenta su carga de trabajo actual. Por ejemplo, esto podría
traducirse en una respuesta al ofertante 810, indicando que el
contestador 811 tiene generalmente gran capacidad pero que solo
parte de ella está disponible de momento. Entonces, el ofertante
810 puede conservar esta información para renegociaciones 808
futuras siempre que intenta mejorar la conexión para trabajar con
un nivel diferente de calidad de servicio.
Si una capacidad es eliminada o reconfigurada en
un momento posterior, un nuevo caso del proceso correspondiente de
prenegociación 802 de <e2enp:qosdef name="capabilities">
tendría lugar entre iguales para diseminar preactiva y
oportunamente información sobre el cambio dado, de modo que los
iguales pueden emplear estrategias apropiadas de adaptación.
Si el contestador 811 añade una capacidad como
"possible", la parametrización correspondiente sería devuelta
directamente en la sección <e2enp:qosdef
name="capabilities">, en el elemento correspondiente a esa
nueva capacidad. En este caso, la parametrización indica
simplemente información de configuración relativa a esa capacidad.
Si el ofertante 810 es mejorado con esta capacidad adicional en un
momento posterior, el ofertante 810 podría extraer algunos contratos
1108 de la información de configuración para ejecutar una nueva
ronda del proceso de prenegociación 802.
Los iguales también pueden renegociar
capacidades después del proceso antes descrito, en cualquier
momento, para informarse entre sí sobre cualquier cambio en la
disponibilidad de capacidades.
Continuando el ejemplo anterior, el fragmento de
código siguiente presenta un ejemplo de parametrización de
codificador-descodificador en la nueva sección
<e2enp:qosdef name="contracts">, como se obtiene de un
proceso de establecimiento de correspondencia descrito en el
párrafo anterior. Esta sección se ocupa de los contratos 1108 de
calidad de servicio a nivel de aplicación que son generalmente
aplicables a cualquier flujo 206 de información del tipo de
información identificado.
Esta sección nueva contiene un número de
elementos complejos de XML:
- \bullet
- un elemento <policy> obligatorio usado para negociar la directriz de gestión de recursos a imponer;
- \bullet
- como máximo un caso de cualquiera de los elementos siguientes:
- -
- <audio>: que describe todos los contratos 1108 de calidad de servicio para flujos 206 de información de audio
- -
- <video>: que describe todos los contratos 1108de calidad de servicio para flujos 206 de información de video
- -
- <data>: que describe todos los contratos 1108 de calidad de servicio para flujos 206 de información de datos
- -
- <control>: que describe todos los contratos 1108 de calidad de servicio para flujos 206 de información de control
donde tales contratos 1108 de
calidad de servicio son obtenidos de la correspondencia de
información de perfiles de usuarios con capacidades. Al menos uno de
estos elementos debe ser
presentado.
Ejemplo 8 de
XML
La descripción del
"color-quality-range" y del
"overall-quality-range" es
introducida anteriormente. En este caso, el
frame-rate-set="10, 15"
significa que el receptor debería ser capaz de descodificar 15
cuadros/s como máximo y 10 cuadros/s como mínimo. Cualquier
descodificación que produzca menos de 10 cuadros/s es considerada
como una violación del contrato 1108. El emisor no necesita
proporcionar más de 15 cuadros/s a no ser que cambie un contrato
debido a, por ejemplo, que es hecho el descubrimiento de más
recursos en el lado de receptor y es efectuada una solicitud de
cambio de contrato.
El elemento <policy> transporta el tipo de
directrices a negociar. El atributo "name" proporciona una
descripción legible por persona de la directriz. El elemento hijo
"predicate" opcional permite expresar un predicado de Boole
implicando dos términos, cada uno extraído del conjunto
siguiente:
- \bullet
- "optMemoryUsage" - indica la directriz de optimización de uso de memoria.
- \bullet
- "optNetworkPerformance" - indica la directriz de optimización de rendimiento funcional de la red 604.
- \bullet
- "optPowerConsumption" - indica la directriz de optimización de consumo de energía eléctrica.
- \bullet
- "optCpuLoad" - indica la directriz de optimización de carga de unidad central de procesamiento (UCP).
En el futuro pueden ser añadidos valores
adicionales correspondientes a otras directrices.
Alternativamente, el valor de los términos de
predicado puede ser extraído del conjunto de otros casos del
elemento <predicate>. El tipo de función de Boole es indicado
por medio del atributo "function" que puede tomar cualquier
valor del conjunto: "and", "or". La función "not" no
es usada puesto que la ausencia de una directriz indica
implícitamente que tal directriz no es usada. Así, el elemento hijo
"predicate" permite especificar combinaciones de las
directrices elementales relacionadas anteriormente. Estas
combinaciones indican correlaciones específicas entre las diversas
directrices.
El elemento hijo <criterion> identifica una
directriz dada por medio del atributo "type" que puede tomar
cualquier valor del conjunto antes indicado. Además, un caso de
este elemento puede imponer un caso del elemento <predicate>
especificando la cadena "expression" como valor del atributo
"type" y usando un atributo adicional "idref" que
identifica un caso dado del elemento <predicate>. El elemento
hijo <criterion> es obligatorio y solo un caso de él puede
parecer dentro de un caso dado del elemento <policy>.
El elemento <contract> representa el
resultado del proceso de producto cruzado. Esas exigencias de
calidad de servicio a nivel de aplicación de usuario 1101, que
coinciden con las capacidades disponibles, son copiadas por la
presente de la información de perfil de usuario del usuario 1101 y
negociadas entre iguales. Por tanto, puede resultar que al final
del proceso de negociación 806, las exigencias originales de
calidad de servicio a nivel de aplicación del usuario 1101 son
reducidas a un subconjunto de ellas.
Con respecto a las exigencias expuestas
anteriormente y al concepto de contrato sobrante, el elemento hijo
"spare" del elemento <contract> es introducido por la
presente para indicar los contratos sobrantes que no son soportados
por el proveedor de red preferido por usuarios dados.
Entonces, el elemento hijo <spare> sería un
elemento opcional y su presencia indica que el contrato 1108 dado no
va a ser soportado por el operador preferido de red 604 del
ofertante 810. El contestador 811 elimina de modo similar los no
indicados como no sobrantes, basado en sus acuerdos con su operador
preferido de red 604.
Cuando ocurre una transferencia vertical,
cualquiera de los abonados puede intentar validar todos sus
contratos 1108, incluyendo los sobrantes, que finalmente podrían
resultar aplicables con respecto al nuevo proveedor de red.
El elemento <rtp:map> es propuesto como una
ampliación del perfil de RTP de SDPng 912 [SDPNG03] para
representar la asociación de contratos 1108 de calidad de servicio
a nivel de aplicación dado con un formato específico. El tipo de
información útil es especificado por el atributo "format" que
hace referencia a casos del atributo "name" del elemento
<rtp:pt>.
El atributo "contract" identifica la calidad
de servicio a nivel de aplicación asociada haciendo referencia a
casos del atributo "name" del elemento "contract".
El atributo "role" indica si el formato de
flujos/contratos de calidad de servicio a nivel de aplicación de
asociación dado es propuesto por un receptor, un emisor o un
emisor/receptor, según las exigencias expuestas anteriormente. De
este modo, no solo los receptores sino también los emisores pueden
diseminar proactivamente información que será usada posteriormente
para decidir como manejar renegociaciones 808, basados en trayectos
de adaptación.
Los conceptos de contexto de calidad de servicio
y agrupamiento de flujos 206 de información (y, más
específicamente, asociación) pueden ser modelados introduciendo una
nueva sección <e2enp:qoscfg> como una adición de la sección
<cfg>. Más específicamente, la sección <e2enp:qoscfg>
contiene la descripción de trayecto de adaptación para un flujo 206
de información dado así como las definiciones de asociaciones (o
más generalmente, agrupamientos) de ellos. Contratos 1108 de calidad
de servicio a nivel superior, que captan las restricciones de
correlación 804 de calidad de servicio y sincronización 805 en el
tiempo entre diversos grupos de flujos 206 de información, así como
sus trayectos de adaptación (nivel superior), también pueden ser
especificados con esta sección nueva.
La información contenida en la sección
<e2enp:qoscfg> puede ser prenegociada entre iguales, con
independencia del uso real posterior, o negociada en el tiempo de
establecimiento de conexión.
Dentro del contexto de la idea de E2ENP 908, el
alcance de la sección <cfg> original del SDPng necesita ser
clarificado: la sección <cfg> define simplemente la
correspondencia de formatos (por ejemplo, tipos de información útil
de RTP) con información relacionada con el transporte; mientras que
la definición completa de trayectos de adaptación (en términos de
las capacidades y de los contratos 1108 de calidad de servicio
definidos en las secciones <e2enp:qosdef>) es soportada
totalmente por la nueva sección <e2enp:qoscfg>.
La única diferencia entre esta propuesta y
[SDPNG03] es la introducción de atributos adicionales en el
elemento <rtp:session> para especificar que tipo de red 604 y
versión suya es usada (respectivamente, los atributos "nettype"
y "addrtype"). Este cambio afecta también al perfil de RTP de
SDPng 912 [SDPNG03]. Además, las direcciones son expresadas usando
la sintaxis propuesta para SDP en "Soporte para IPv6 en SDP"
(IETF Internet Draft, trabajo en marcha,
<draft-olson-sdp-ipv6-02.txt>)
de S. Olson, G. Camarillo y A. Roach, designado [Olson01] en lo
siguiente. Las ampliaciones propuestas de SDPng 912 para la sección
<cfg> son indicadas en negrita en el ejemplo siguiente.
Ejemplo 9 de
XML
Obsérvese por favor el uso de la sección
<cfg> para especificar un par dado de dirección/puerto como
asociado con dos tipos de información útil diferentes, cuya
elección depende de que contrato 1108 de calidad de servicio (a
partir de la sección <e2enp:qoscfg>) es impuesto, según
reglas de trayecto de adaptación y las correspondencias descritas en
el elemento <rtp:map> de la sección <e2enp:qosdef
name="contracts">.
La diferencia entre esta propuesta y el SDP y el
SDPng 912 heredados consiste en que los últimos no se concentran
primariamente en la negociación 806 de calidad de servicio, más
bien en la negociación 806 de capacidad. Esto significa que
SDP/SDPng 912 permiten que un emisor proporcione información al (a
los) receptor(es) sobre el formato y la información de
transporte que el emisor intenta usar para emisión.
Intentando emparejar E2ENP 908 con este método
bien conocido, debería observarse que la negociación 806 de
capacidad absoluta ya es tenida en cuenta en la fase de
prenegociación 802 de calidad de servicio de extremo a extremo. De
hecho, la fase de prenegociación 802 puede ser considerada como
suficientemente general para indicar los contratos 1108 de calidad
de servicio a nivel de flujo solo que los iguales pueden desear
usar tanto cuando emite como cuando recibe. Más específicamente, el
atributo "role" del elemento <rtp:map> de la sección
<e2enp:qosdef name="contracts"> permite hacer eso.
Sin embargo, estos dos atributos homónimos están
ocupándose de dos aspectos diferentes: el atributo "role" usado
en la sección <e2enp:qosdef name="contracts"> permite que
los receptores formulen trayectos de adaptación y contratos de
calidad de servicio a nivel alto/trayectos de adaptación basados
también en información/preferencias diseminadas por los emisores.
Mientras que el atributo "role" de la sección <cfg>
permite simplemente que la aplicación/middleware se configuren para
usar flujos 206 de información apropiadamente (en términos de
aspectos de capacidad y transporte), como se mencionó
anteriormente.
La sección <e2enp:qoscfg> permite definir
trayectos de adaptación así como restricciones de correlación 804
de calidad de servicio y sincronización 805 en el tiempo en
diversos niveles de abstracciones, empezando en contratos 1108 de
calidad de servicio a nivel de flujo. Cada nivel de abstracción es
identificado por el atributo "name" de esta sección.
Un ejemplo de esta sección a nivel de flujo es
indicado en el fragmento de documento en XML a continuación.
Ejemplo 10 de
XML
Los subpárrafos siguientes detallan cada elemento
que aparece en esta sección.
Los dos primeros casos del elemento
<adapath> que aparecen en el ejemplo anterior permiten
definir dos trayectos de adaptación distintos recogiendo un
conjunto de contratos 1108 de calidad de servicio a nivel de flujo,
mutuamente excluyentes, extraídos del conjunto de elementos
<contract> de la sección <qosdef
name="capabilities"> y asociados con receptores solamente
(según las exigencias expuestas anteriormente). Cada elemento
<adapath> está asociado con un <component> específico de
la sección <cfg> por medio del atributo "ref_component".
Este atributo solo es obligatorio para elementos <adapath>
que describen trayectos de adaptación a nivel de flujo.
Cada contrato 1108 de calidad de servicio es una
opción alternativa en el trayecto de adaptación: de aquí el uso de
la construcción <alt> para definirlos ("alt" significa
alternativa). Suponiendo el modelo de máquina de estados finitos
(FSM: Finite State Machine) jerárquica antes descritas, cada uno de
estos trayectos de adaptación representa una FSM distinta, cuyo
estado inicial es indicado explícitamente por el elemento
<default> de la construcción <adapath> dada.
Suponiendo el modelo de FSM jerárquica antes
descrito, la elección de conmutar desde un contrato 1108 de calidad
de servicio a otro dentro de un trayecto de adaptación dado puede
ser determinada dinámicamente emparejando niveles monitorizados de
calidad de servicio respecto al conjunto de contratos 1108 de
calidad de servicio definidos en el trayecto de adaptación dado,
usando por ejemplo lógica difusa como se describe en "Habilitar
decisiones de adaptación de calidad de servicio para aplicaciones
de Internet" (Londres/Reino Unido, 1.999) de S. Bhatti y G.
Knight, designado [Bhatt99] en lo siguiente, y [BRAIN].
Alternativamente, la construcción <adapath> puede incluir un
conjunto predefinido de transiciones de estado entre esos contratos
1108 de calidad de servicio: en este caso, la construcción
<event> indica que transiciones deberían ser disparadas al
detectar sucesos dados como
"frame-rate-increase" (aumento
de frecuencia de cuadros) o
"frame-rate-decrease"
(reducción de frecuencia de cuadros), como en el ejemplo anterior.
Estos sucesos son designados notificaciones de monitor bien
conocidas, a las que las aplicaciones y/o el middleware pueden estas
diseñados para tener en cuenta. Hasta este punto, tanto el nombre
como la semántica de sucesos deben ser sometidos a esfuerzos de
estandarización. Un <event> (suceso) dado puede estar asociado
con trayectos múltiples, cuyos disparadores determinan el que será
activado.
Las transiciones individuales son descritas en
construcciones <path>, que describen el estado de disparador
(indicados como parámetros de protección) y los contratos 1108 de
calidad de servicio implicados en la transición (indicados con los
atributos fuente y objetivo). El atributo fuente en la construcción
<path> es opcional en tanto que podría haber casos donde la
especificación de ese atributo podría ser suprimida a propósito. En
esos casos, de hecho, la transición correspondiente se originaría
en cualquier estado en el que está dispuesto actualmente la FSM
jerárquica dada. De este modo, el cambio de cualquier contrato 1108
de calidad de servicio puede ser modelado, dentro de un conjunto
dado, en uno definido en el caso de que la transición
correspondiente sea disparada (una clase de mecanismo por omisión).
En el ejemplo anterior, el suceso
<video1-e-2>, disparado por la
detección de una frecuencia de cuadros inferior (véase el atributo
<reason>), obligaría a la FSM descrita por la construcción
<adapath> denominada video1 a imponer
video-contract-1, no importa que
contrato 1108 fue impuesto en el momento que el suceso fue lanzado.
Para conseguir interoperatividad, debería observarse que los
iguales deberían ponerse de acuerdo sobre la semántica del atributo
<reason>. Expresiones como
"higher-frame-rate" o
"lower-frame-rate", que
aparecen en el ejemplo anterior, deberían ser sometidas así a
estandarización, junto con su significado. Esta predefinición de
conjuntos de transiciones es opcional.
El atributo "scope" indica en una solicitud
(oferta de negociación) si el elemento correspondiente de SDNpg 912
ha de ser considerado como una opción necesaria ("applicable")
o deseada ("possible"); mientras que en una respuesta
(contraoferta de negociación), ese atributo indica si el elemento
correspondiente de SDNpg 912 ha sido validado ("applicable") o
rechazado ("not-applicable").
El contestador 811 también puede indicar en la
contraoferta qué capacidades puede soportar y en que grado. Si una
capacidad dada es soportada "como es", solo es indicado el
identificador correspondiente junto con el atributo "scope"
dispuesto en "applicable". Si una capacidad dada no es
soportada, el identificador correspondiente es suprimido
simplemente. Si el contestador 811 propone en la contraoferta una
versión modificada de la parametrización de una capacidad dada en la
sección <e2enp:qosdef> (como un subconjunto de la oferta
original), toda la descripción con las actualizaciones es devuelta
en ambas secciones <e2enp:qosdef name="capabilities"> y
<e2enp: qosdef name="contracts">. En cualquier caso, la
sección <e2enp:qosdef name="contracts"> contiene en una
respuesta solo parametrizaciones actualizadas de
codificadores-descodificadores.
Adicionalmente, el contestador 811 puede indicar
una opción nueva (desconocida para el ofertante 810 en el tiempo de
prenegociación 802): esta será marcada como "possible". La
idea es que el ofertante 810 pueda ser informado así de una opción
potencial que podría ser usada finalmente más tarde si el ofertante
810 es mejorado con una capacidad nueva que coincide con esa
opción.
Los elementos <context> definen
asociaciones posibles de los flujos 206 de información dados, y así
permite definir restricciones de sincronización en el tiempo y/o
correlación 804 de calidad de servicio. Como tales, los elementos
<context> describen básicamente contratos 1108 de calidad de
servicio a nivel alto.
En el ejemplo anterior, un flujo 206 de
información de video y un flujo 206 de información de audio son
definidos como correlacionados en un contexto dado
("association1-1") junto con ambas
restricciones de sincronización en el tiempo y correlación 804 de
calidad de servicio definidas. Alternativamente, también podría ser
usado un contexto incluyendo solo el flujo 206 de información de
audio ("association1-2").
Cuando y como imponer cualquiera de los contextos
es descrito en el segundo caso del elemento <adapath> que
aparece en el ejemplo anterior. En este caso, el uso del elemento
<default> es evidente: la combinación
("association1-1") de un flujo de información
de audio y un flujo de información de video es indicada como la
preferida. El caso donde solo es usado un flujo de información de
audio ("association1-2") sería considerado
entonces como un caso de reserva, que puede ser impuesto para
enfrentarse, por ejemplo, con violaciones de calidad de servicio.
Los elementos hijo individuales del elemento <adapath> hacen
referencia a los casos de los elementos <context> antes
mencionados por medio del atributo
"ref-context".
Como una regla general, puede observarse así el
caso recurrente de elementos <adapath> y <context> que
hacen referencia entre sí en una cadena acíclica de referencias.
Las construcciones <context> alternativas son agrupadas en una
construcción <adapath> que define una FSM. Este trayecto de
adaptación y cualesquier otros (concurrentes) pueden ser envueltos
entonces a su vez dentro de una construcción <context>, que
dispone restricciones a un nivel más alto. Además, también hay la
alternativa de definir tales construcciones <context>, que
entonces pueden ser recogidas en un trayecto de adaptación a nivel
más alto. Este proceso puede ser aplicado recurrentemente.
Un usuario dado puede imponer restricciones de
correlación 804 de calidad de servicio a nivel más alto y
sincronización 805 en el tiempo (como una forma de información
ampliada de perfil de usuario) para orquestar la utilización de
recursos (y por tanto la calidad de servicio) a través de conjuntos
dados de flujos 206 de información establecidos con iguales
diferentes. Hasta este punto, el usuario dado no necesita negociar
esta información con los iguales.
Sin embargo, el usuario dado precisa imponer
algunas restricciones nuevas en un momento posterior, o descubre
que las restricciones preexistentes ya no pueden ser satisfechas,
debido a la unión/separación posterior de algunos iguales a/de las
sesiones 102 de telecomunicación abiertas actualmente, podrían ser
necesarias nuevas rondas del E2ENP 908, según las directrices de
conferencia dadas (que están fuera del alcance de la invención
fundamental).
Finalmente, los iguales también pueden recurrir
a una entidad de tercer abonado que gestiona prenegociaciones 802,
negociaciones 806 y renegociaciones 808 (las "completas"),
incluyendo especificación de nivel superior referente a aspectos de
correlación 804 de calidad de servicio y sincronización 805 en el
tiempo. Esta entidad actuaría como una clase de intermediario de
calidad de servicio como se describe en "Soporte de calidad de
servicio para un sistema de IP total más allá de tercera generación
(3G)" (IEEE Communication Magazine, agosto de 2.001, volumen 39,
número 8) de T. Robles, A. Kadelka, H. Velayos, A. Lappetelainen, A.
Kassler, H.Li, D. Mandato, J. Ojala y B. Wegmann, designado
[Roble01] en lo siguiente, y [BRAIN], que están fuera del alcance
de la invención fundamental.
Los flujos de información pueden ser asociados de
diversas maneras. En el ejemplo siguiente, debe ser propuesto el
concepto de una sesión 102 que es pensada, por ejemplo, como una
videoconferencia 1204a/b. Hasta este punto, las asociaciones de
flujos 206 de información entre el usuario dado (usuario A) y sus
iguales (B, C y D) dentro del contexto de una sesión 102 de
videoconferencia 1204a/b dada son acumuladas de diversas maneras.
Entonces, las acumulaciones resultantes son asociadas con contextos
de calidad de servicio usando las construcciones <context>
antes mencionadas.
Hasta este punto, cada acumulación puede ser
asociada con un conjunto de restricciones que dictan niveles
específicos de correlaciones 804/805 entre las diversas
asociaciones de flujos 206 de información pertenecientes a la
acumulación dada. Esto significa que las restricciones afectan a
todos los flujos 206 de información pertenecientes a cada
asociación, independientemente de las especificaciones de calidad de
servicio de los flujos 206 de información individuales
pertenecientes a la asociación dada. Las construcciones
<context> especifican así la correlación 804/805 de calidad de
servicio para haces concurrentes de flujos 206 de información.
Entonces pueden ser posibles contextos alternativos como se
describen en las construcciones <adapath> (una por caso de
videoconferencia).
Estas construcciones <adapath> son
comparables así con la descripción de una FSM, cuyos estados
contienen a su vez otras construcciones <adapath>
concurrentes, describiendo cada una el agrupamiento de flujos 206 de
información entre el usuario dado y un igual dado. Este modelo
recurrente permite usar gráficos de estados como se describe en
[Booch99].
\vskip1.000000\baselineskip
Ejemplo 11 de
XML
Continuando el método recurrente antes descrito,
pueden agregarse además flujos 206 de información basados en una
base lógica de nivel todavía más alto. Por ejemplo, pueden
asociarse todos los flujos 206 de información gestionados por todos
los casos de una aplicación dada, y diferenciar el contexto de
calidad de servicio resultante procedente de otras aplicaciones,
así como imponer especificaciones de correlación 804 de calidad de
servicio a nivel más alto
Ejemplo 12 de
XML
Este ejemplo muestra una vez más el uso de la
sección <e2enp:qoscfg> para expresar la información antes
descrita. En el ejemplo puede verse como esta especificación de
alto nivel permite expresar fácilmente restricciones sobre consumo
de recursos locales, en línea con el concepto de BRENTA descrito en
[Roble01] y [BRAIN].
La idea detrás de la fase de renegociación 808
compacta de calidad de servicio de extremo a extremo es evitar
realizar una renegociación 808 completa durante tareas de duración
crítica como recuperación de una violación de calidad de servicio
debida, supóngase, a una transferencia. Este objeto puede ser
conseguido permitiendo que los iguales señalicen entre sí los
nuevos contratos 1108 (prenegociados) de calidad de servicio a
imponer y/o señalizando los contratos 1108 (prenegociados) de
calidad de servicio que (al transferir a una nueva red 604 de
acceso y/o proveedor de red) resultan aplicables y/o ya no
aplicables. Hasta este punto, es necesario soporte específico basado
en SDPng para el E2ENP 908.
La nueva sección <e2enp:enforce> de SDPng
permite que uno de los iguales (típicamente el primero que detecta
un cambio o violación de calidad de servicio) señalice a los otros
iguales qué contratos 1108 de calidad de servicio deberían ser
impuestos, a partir de los trayectos de adaptación
prenegociados.
La idea es transportar información de
señalización según la estructura jerárquica de la especificación de
calidad de servicio prenegociada. Esto significa observar
correctamente cada nombre de contrato de calidad de servicio. Al
menos dos implementaciones alternativas están disponibles: usar un
nombre-espacio para contratos 1108 de calidad de
servicio o un lenguaje para hacer referencia a alguna parte de un
documento, como la norma XPath, como se describen la
"Recomendación de lenguaje de trayecto de XML" (W3C, XML Path
Language Recommendation Version 1, http://www.w3.org/TR/xpath,
noviembre de 1.999) o la tecnología XPointer no estandarizada
todavía como se describe en la "Recomendación de XPointer"
(W3C, 2.000, trabajo en marcha,
\underline{http://www.w3.org/TR/xptr}), designado [XPOINT] en lo
siguiente.
La solución anterior está basada en asignar
nombre especificados completamente a contratos 1108 de calidad de
servicio, haciendo pender previamente los nombres de cualquier
contrato 1108 de calidad de servicio de nivel más alto del que
depende el contrato 1108 dado de calidad de servicio dentro de la
especificación dada de calidad de servicio basada en árbol, usando
como carácter separador el carácter de punto por ejemplo. Sin
embargo, esta solución requiere el uso consecuente de nombres
(bastante complejos y largos frecuentemente) por toda una
multiplicidad de secciones de E2ENP 908 y de unidades de datos de
protocolo (PDUs) de E2ENP. Además, esta solución obliga a las
aplicaciones a ser capaces de analizar correctamente el
nombre-espacio dado.
Por ejemplo, el nombre especificado completamente
del video-contract-2 dentro del
trayecto de adaptación de video1, dentro del contexto de calidad de
servicio de association-1-1, a
partir del trayecto de adaptación de
associations-A-B, parecería lo
siguiente:
associations-A-B.association-1-1.video1.video-contract-2.
En cambio, la solución alternativa está basada en
Xpath o incluso en tecnología XPointer (que, como de la invención
fundamental, todavía no ha alcanzado el estatus de
estandarización), ambas de las cuales indican la tendencia actual
referente a la indicación no ambigua de elementos a través de
diversos documento de XML.
Dentro del alcance de la invención fundamental,
se decidió usar esta última solución, sin ninguna pérdida de
generalidad comparada con la otra antes descrita (o cualquier otra
equivalente), con respecto a los conceptos. Para explicar la
solución elegida, se introduce el siguiente fragmento de documento
de XML que describe la misma información usada en el ejemplo
anterior:
Ejemplo 13 de
XML
El contrato 1108 de calidad de servicio a imponer
es indicado por el elemento <target>.
En este fragmento de documento de XML se puede
reconocer fácilmente el uso del atributo "name" (nombre) para
el elemento raíz de la rama dada del árbol
(associations-A-B), mientras que los
otros elementos en esa rama son denominados por medio de los
atributos de referencia (ref_context, ref_adapath, ref_contract)
del padre respectivo. Esto significa que solo el nombre de los
elementos <contract>, <context> y <adapath> debe
ser usado únicamente a través de secciones/fases múltiples,
mientras que los nombres de los elementos hijo de XML de los
elementos antes mencionados pueden ser elegidos arbitrariamente.
Usando esta metodología, puede imponerse la señalización no solo de
contratos 1108 de calidad de servicio a nivel de flujo 206 de
información, como en el ejemplo anterior, sino también de cualquier
contrato 1108 de calidad de servicio a nivel alto, terminando la
especificación anterior para el contexto dado de calidad de
servicio. Por ejemplo, el fragmento de documento de XML a
continuación:
\newpage
Ejemplo 14 de
XML
Podría ser usado para señalizar a los otros
iguales que debería ser impuesto la assocation1-1
de alto nivel con independencia de los contratos 1108 de calidad de
servicio a nivel de flujo impuestos actualmente (en este caso,
estados por omisión dictarían que contratos 1108 de calidad de
servicio a nivel de flujo 206 de información imponer en el nuevo
contexto de calidad de servicio). Además, la sección
<e2enp:enforce> también puede ser usada para señalizar a
otros iguales un trayecto de adaptación específico a imponer, en la
que el estado por omisión sería usado entonces para separar la
información restante a nivel más bajo. Por ejemplo, la sección
<e2enp:enforce>:
Ejemplo 15 de
XML
Obligaría al igual A a usar
"video-contract-1" para el
flujo 206 de información de "video1", puesto que el contrato
1108 fue especificado como por omisión en la sección
<e2enp:qoscfg> prenegociada.
La tecnología XPath (o incluso la XPointer) antes
mencionada puede ser usada para permitir que un igual señalice a
los otros qué contratos 1108 de calidad de servicio bloquear según
la base lógica anterior.
Hasta este punto, una nueva sección de SDPng es
propuesta por la presente: la sección <e2enp:block>. El
ejemplo siguiente representa el uso de tal sección nueva.
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
(Esquema pasa a página
siguiente)
Ejemplo 16 de
XML
El contrato 1108 de calidad de servicio a
bloquear es indicado por el elemento <target>.
La tecnología XPath (o incluso la XPointer) antes
mencionada también puede ser usada para permitir que un igual
señalice a los otros que contratos 1108 de calidad de servicio
desbloquear según la base lógica antes descrita.
Hasta este punto, una nueva sección de SDPng es
propuesta por la presente: la sección <e2enp:unblock>. El
ejemplo siguiente representa el uso de tal sección nueva.
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
(Esquema pasa a página
siguiente)
Ejemplo 17 de
XML
El contrato 1108 de calidad de servicio a
desbloquear es indicado por el elemento <target>.
Dentro del contexto de la solución presentada en
este capítulo, la semántica de la sección original
<constraints> de SDPng 912, como se describe en "Exigencias
para descripción de sesión y negociación de capacidades" (IETF
Internet Draft, trabajo en marcha,
<draft-kutscher-mmusic-sdpng-req-01.txt>)
de D. Kutscher y otros, designado [SDPNG01] en lo siguiente, puede
ser interpretada como una forma de especificación de restricciones
de correlación 804 de calidad de servicio y/o sincronización 805 en
el tiempo aplicada a toda la especificación de calidad de servicio
descrita en las nuevas secciones de SDPng antes mencionadas. Dicho
documento proporciona un conjunto de exigencias relevantes para un
marco para descripción de sesión 102 y negociación de capacidades
de puntos finales en escenarios de conferencia multimedia
multi-abonado.
Teniendo en cuenta SIP 910 y SDPng 912 como
protocolos sobre los cuales debería ser hecho establecida una
correspondencia del E2ENP 908, es necesario señalar que SIP 910 es
un protocolo asimétrico. El modelo de ofertante
914-contestador 911 de SIP no proporciona la
posibilidad de señalizar errores, estados de fallo o excepciones
(cambios de estado) cuando ocurren en el lado del ofertante 914. El
E2ENP 908 precisa varios recorridos de ida y vuelta de mensajes de
SIP dentro de sus fases y cada mensaje unidireccional de un
recorrido de ida y vuelta debería ser comprobado tanto respecto a
su corrección como su aceptabilidad en todos los iguales implicados
en la señalización de E2ENP. Adicionalmente, deberían ser
considerados cambios de estado de los iguales finales dentro del
tiempo de ejecución de una fase de E2ENP. Estos cambios pueden
concernir a un igual que está implicado
en:
en:
- -
- negociación(es) de prioridad más alta;
- -
- el comienzo de procesos internos de prioridad más alta del igual, que afectan a la gestión de recursos y a los ajustes de perfiles de E2ENP 908;
- -
- averías de hardware y/o software que producen exclusiones de recursos.
Hasta este punto, el E2ENP 908 usando el SIP 910
debería transportar, dentro de su cuerpo de SDPng 912, códigos de
error indicando fallos que ocurren por el ofertante 914 y razones
del fallo; o el código de error de SIP 910 tanto para el ofertante
914 como el contestador 911. El estudio de los posibles códigos de
error de SDPng con respecto a E2ENP y su estructura debería ser
considerado completamente: los nuevos fragmentos respectivos de XML
de SDPng para describir los códigos de error de E2ENP y señalizar
errores para resolver este problema son considerados como solución
posible pero no mostrados en los ejemplos en favor de la sencillez.
Como el E2ENP 908 es aplicado a SIP 910 por medio de su preposición
(piggybacking), los códigos de error y mensajes superpuestos
(piggybacked) respectivos dentro del SDPng 912 deberían ser tenidos
en cuenta por el desarrollo del E2ENP 908. En general, el ofertante
914 debería considerar repetir las llamadas con
razones-notificación dentro de la parte de SDPng 912
del mensaje y el contestador 911 debería aprovechar el uso de
"Códigos de estatus" de SIP 910 describiendo también razones
en la parte de mensajes de SDPng 912.
El E2ENP DEBERÍA ser capaz de suministrar la
misma posibilidad de señalizar ambos estados de fallo, excepciones y
errores internos y externos que ocurren en cualquiera de los
iguales implicados en la señalización de E2ENP. Hasta este punto,
el E2ENP DEBERÍA ser simétrico aplicando códigos de error en los
iguales afectados por el E2ENP.
Según "Un modelo de oferta/respuesta con
SDP" (IETF Internet Draft, trabajo en marcha,
<draft-rosenberg-mmusic-sdp-offer-answer-00.txt>)
de J. Rosenberg y H. Schulzrinne, designado [SDPOA00] en lo
siguiente, puede ser manifestado que "una oferta DEBE ser
preparada para recibir información descrita por esa oferta una vez
que ha sido enviada por un ofertante 914". Este método no es
tolerante al fallo con respecto al E2ENP 908 y a los mecanismos de
adaptación, puesto que debería ser tomada en cuenta la posible
reconfiguración dinámica de los iguales tanto en casos de fallo
como de mejora, cuando los datos negociados resultan inválidos
dentro del tiempo de una negociación 806 en marcha o antes de que
haya empezado el flujo de información.
También debería ser considerado que algunos
componentes intermedios que interaccionan con iguales finales a lo
largo del trayecto de señalización de E2ENP 908 podrían causar
perturbaciones del protocolo si no lo comprenden. En este caso,
debería haber mecanismos para detectar y recuperar tales
perturbaciones.
Lo siguiente es una descripción de casos de
errores posibles donde alguna forma de notificación entre el
ofertante 914 y el contestador 911 es necesaria para indicar los
estados cambiantes y las perturbaciones causadas. La flecha
(\rightarrow) indican soluciones posibles. La "A" indica un
contestador 911 y la "O" un ofertante 914.
- \bullet
- El contestador 911 descubre que la propuesta del ofertante 914 no coincide con ninguna de sus capacidades.
- \circ
- El contestador 911 tiene las capacidades para descargar codificadores-descodificadores.
- \NAK
- El contestador 911 debería informar al ofertante 914 que la transacción puede durar un poco más, porque necesita tiempo para la descarga y ajuste de sus datos de perfil.
- \rightarrow
- Respuesta A \rightarrow O con "100 Trying" ("100 Intentando") o "183 Session Progress" ("183 Progreso de sesión")
- \circ
- El contestador 911 no tiene capacidades para descargar codificadores-descodificadores
- \NAK
- Si el contestador 911 es un servicio \rightarrow respuesta A \rightarrow O con "380 Alternative Service" ("380 Servicio Alternativo") si el contestador 911 conoce tal servicio. Entonces, el ofertante 914 puede comenzar una nueva prenegociación 802 con el servicio alternativo.
- \NAK
- \rightarrow El contestador 911 elimina todas las capacidades del ofertante 106b desde la sección <e2enp: qosdef name="capabilities"> y hace una contraoferta para las capacidades y los contratos 1108 (<e2enp:qosdef name="capabilities"> y <e2enp:qosdef name="contracts">).
- \bullet
- si el ofertante 914 puede descargar codificadores-descodificadores, \rightarrow el ofertante 914 descarga codificadores-descodificadores, finalmente reordena perfiles, finalmente comienza una nueva prenegociación 802.
- \bullet
- Si el ofertante 914 no puede descargar codificadores-descodificadores, \rightarrow el ofertante 914 debería tener en cuenta el uso de un servicio de transcodificador.
- \NAK
- \rightarrow El contestador 911 también puede emitir "606 Not Aceptable" ("606 No Aceptable") si el ofertante 914 pide soporte de capacidades que no está disponible en el momento.
- \bullet
- El contestador 911 descubre que la propuesta del ofertante 914 coincide con las capacidades del contestador 911 pero los contratos 1108 ofertados no pueden ser soportados.
- \circ
- El contestador 911 ajusta respectivamente su perfil.
- \NAK
- El contestador 911 debería informar al ofertante 914 de que la transacción puede durar un poco más debido al ajuste de perfil.
- \rightarrow
- Respuesta A \rightarrow O con "100 Trying" ("100 Intentando") o "183 Session Progress" ("183 Progreso de Sesión").
- \NAK
- \rightarrow El contestador 911 también puede emitir "606 Not Aceptable" ("606 No Aceptable") si el ofertante 914 pide soporte de calidad de servicio que no está disponible en el momento.
- \circ
- El contestador 911 no tiene posibilidad de ajustar su perfil.
- \NAK
- Si el contestador 911 es un servicio \rightarrow respuesta A \rightarrow O con "380 Alternative Service" ("380 Servicio Alternativo") si el contestador 911 conoce tal servicio. Entonces, el ofertante 914 puede comenzar una nueva prenegociación 802 con el servicio alternativo.
- \NAK
- El contestador 911 hace una contraoferta para la (<e2enp:qosdef name="contracts"> ajustando los márgenes de los contratos 1108 del ofertante 914 o proponiendo márgenes completamente nuevos \rightarrow Corresponde al ofertante 914 ajustar su perfil y comenzar finalmente una nueva prenegociación 802.
- \bullet
- El ofertante 914 descubre que la respuesta del contestador no coincide con ninguna de sus capacidades.
- \circ
- El ofertante 914 tiene las capacidades para descargar codificadores-descodificadores.
- \NAK
- \rightarrow El ofertante 914 descarga los codificadores-descodificadores, ajusta respectivamente su perfil e inicia una nueva prenegociación 802.
- \circ
- El ofertante 914 no tiene capacidades para descargar codificadores-descodificadores.
- \NAK
- \rightarrow El ofertante 914 debería tener en cuenta el uso de un servicio de transcodificador.
- \bullet
- El ofertante 914 descubre que la propuesta del contestador 911 no coincide con ninguno de sus perfiles de "contrato".
- \circ
- \rightarrow El ofertante 914 ajusta su perfil consiguientemente antes de crear una contraoferta para el contestador 911.
- \circ
- \rightarrow El ofertante 914 inicia una nueva prenegociación 802 en modo de empujar para imponer la adaptación del contestador 911.
Este caso debería ser tratado como una
combinación de los dos casos anteriores.
Puede suceder que algunos de los datos
prenegociados y conservados en el ofertante 914 y/o el contestador
911 se alteren debido a razones de cambiar información de
perfil:
- \bullet
- Usuarios diferentes imponen sus directrices de rendimiento funcional en los dispositivos (ofertante 914 y contestador 911).
- \bullet
- Algunos procesos de prioridad más alta (internos y/o externos) usan los recursos de modo que los perfiles prenegociados ya no son válidos.
- \bullet
- Han tenido lugar algunos cambios de configuración del sistema, como
- \circ
- Fallos por reserva de recursos locales debidos a ocupación o mal funcionamiento de recursos.
- \circ
- Fallo por reserva de recursos de red si, por ejemplo, la red 604 soporta solo el "esfuerzo óptimo" con respecto a los niveles inferiores de calidad de servicio de red.
- \circ
- Nuevos codificadores-descodificadores y/o subdispositivos de hardware están siendo instalados, influyendo así sobre las capacidades y los perfiles de calidad de servicio.
El ofertante 914 y/o el contestador 911 pueden
descubrir tal expiración prematura en el momento que intentan
iniciar una prenegociación 802 adicional o una negociación 806. En
tal caso, los iguales deberían ser capaces de imponer la
expiración de los datos prenegociados en el lado de sus socios de
comunicación, empujándolos así prematuramente al estado
"zombi".
- \rightarrow
- Indicación necesaria de la expiración prematura con nueva prenegociación 802 siguiente. Hasta este punto, el elemento <expires> es puesto a cero y puede ser usada una orden <expire> adicional.
Si un cambio de perfil ocurre dentro del tiempo
de flujo de información en marcha \rightarrow el lado que
descubre la violación debería iniciar un nuevo proceso E2ENP 908 de
renegociación 808 completa.
Si un igual llamado recibe un mensaje con una
indicación para un modo de negociación 806, que no soporta, un
fallo ocurre en su lado. \rightarrow En tal caso, el contestador
811 envía "606 Not Aceptable" ("606 No Aceptable") al
ofertante 810, indicando en el cuerpo de mensaje el modo de
negociación 806 que soporta el contestador 811. El ofertante 810
debería iniciar respectivamente de nuevo la fase de negociación
806.
Este podría ser el caso usando servicios puesto
que los servicios deberían ser capaces de soportar clientes
múltiples en paralelo y así pueden tener preferencias para el modo
de negociación 806.
Debido a fallos de iguales y/o red 604, el cuerpo
de un mensaje de SIP (el SDPng 912) o todo el mensaje de SIP puede
ser deformado. Si el contestador 911 obtiene tal mensaje, las
respuestas posibles pueden ser:
- \bullet
- \rightarrow"400 Bad Request" ("400 Solicitud Mala") - si todo el mensaje de SIP es deformado.
- \bullet
- \rightarrow"420 Bad Extension" ("420 Ampliación Mala") - si solo es deformado el mensaje de SDPng 912.
Si el ofertante 914 obtiene un mensaje deformado
o ha recibido una notificación de "mensaje deformado"
\rightarrow el ofertante 914 debería repetir la solicitud de SIP
910.
Cuando un tercer abonado interfiere con la
negociación 806 deseando iniciar una negociación 806, son
realizados los pasos siguientes:
- \bullet
- Si la llamada tiene la misma prioridad:
- \rightarrow
- El igual emite "182 Queued" ("182 Puesto en cola") si el igual decide que puede manejar la llamada en un momento posterior.
- \rightarrow
- El igual emite "600 Busy" ("600 Ocupado") si algún otro igual fue más rápido al emitir la llamada y ha ocupado todas las capacidades disponibles del igual que contesta. Esto es especialmente cierto por flujos 206 de información ya en marcha cuando podría ser requerida renegociación 808 completa final.
- \rightarrow
- El igual emite "603 Decline" ("603 Rehusar") si algún otro igual fue más rápido al emitir la llamada y ocupaba todas las capacidades disponibles del igual que contesta pero el igual que contesta sabe durante cuanto tiempo debe continuar la llamada. Este es también el caso de que una transacción similar con respecto a la prioridad está siendo procesada en el momento y el que llama tiene que esperar.
- \rightarrow
- El igual emite "380 Alternative Service" ("380 Servicio Alternativo") si el igual es un servicio y tiene información sobre servicios alternativos comunes.
- \bullet
- Si la llamada tiene prioridad más alta:
- \circ
- En el lado de ofertante 914:
- \rightarrow
- El ofertante 914 debería ser capaz de informar al contestador 911 sobre la interrupción de la negociación 806 - algún código de error de SDPng 912.
- \circ
- En el lado de contestador 911:
- \rightarrow
- El contestador 911 puede emitir "600 Busy" (" 600 Ocupado") o "603 Decline" ("603 Rehusar") con algunas razones indicando la interrupción.
- \rightarrow
- Dependiendo de la prioridad de la llamada y los recursos actualmente disponibles por flujos 206 de información ya en marcha, el igual puede realizar renegociación 808 rápida o completa, o anular completamente el flujo de información.
Según [SIPBIS04], puede ser declarado que "los
proxies" no modifican generalmente la descripción de sesión 102
pero PUEDEN hacerlo así si es necesario, por ejemplo, para
traductores de direcciones de red 604 y si la descripción de sesión
102 no está protegida por un mecanismo de integridad criptográfica.
Esto significa que los proxies comprenden los cuerpos de SDPng 912
de los mensajes y pueden cambiarlos. Para proteger a los mensajes
de E2ENP 908 de ser alterados desde componentes que no comprenden
el protocolo, \rightarrow firmas digitales y resúmenes deberían
ser aplicados para los mensajes de E2ENP. Algunos mecanismos de
señalización adicionales también deberían ser aplicados en el SDPng
912 para E2ENP 908 a fin de permitir que los iguales se informen
entre sí de que un mensaje de E2ENP está siendo alterado por algún
componente de red 604 no interesado en el E2ENP 908.
La integridad de los mensajes debería ser
considerada una cuestión de seguridad, que es un tópico de estudios
futuros. Si un contestador 911 comprende E2ENP 908 en general pero
no la versión de él, \rightarrow el contestador 911 emite el
mensaje "606 Not aceptable" ("606 No Aceptable") con
descripción de SDPng 912 indicando que la versión de E2ENP 908 no
es soportada pero que otra versión de E2ENP 908 es soportada. Esto
también es necesario para garantizar la compatibilidad hacia atrás
de las versiones de E2ENP 908. Esto significa que la parte de XML
que describe la versión de E2ENP 908 debería ser uniforme para
todas las versiones de E2ENP 908.
La consideración de redes 604 protegidas (o sea,
uso de proxies y cortafuegos) es una cuestión de seguridad, que es
un tópico de estudios futuros. Lo siguiente es solo una descripción
breve sobre como la seguridad puede influir en la mensajería de
errores de E2ENP 908:
- 1.
- El componente de protección no comprende E2ENP 908 pero comprende SIP 910 y/o SDPng 912. En este caso, una prenegociación 802 no de E2ENP 908 con el componente de protección sería necesaria para hacerlo transparente para el siguiente protocolo E2ENP.
- 2.
- El componente de protección comprende E2ENP 908. En este caso, el E2ENP 908 puede transportar información que concierne a los componentes no transparentes en forma de referencias a información no E2ENP 908 finalmente (autenticación, seguridad, etc.), permitiendo así que los componentes no transparentes comprueben silenciosamente y cursen los mensajes de E2ENP. Los ofertantes 106b y los contestadores 106a2 no interesados en esta información pueden desecharla simplemente. Este método permite ocuparse silenciosamente de componentes no transparentes (con respecto a E2ENP 908), haciendo así a la red 604 explícitamente transparente y enmascarando algunos de los mensajes "Request Failures 4xx" ("Solicitar Fallos 4xx") de SIP 910, que pueden influir negativamente en el E2ENP 908.
Cuestiones particulares con el uso de SIP 910
concerniente a E2ENP 908 pueden ser resumidas como sigue:
- 1.
- El E2ENP 908 es un metaprotocolo sobre SIP 910 en tanto que el E2ENP 908 no sigue el paradigma de organización en capas.
- 2.
- El metaprotocolo E2ENP 908 debería ser nombrado explícitamente en los mensajes de SIP para evitar la interferencia de los componentes intermedios en las sesiones 103 de E2ENP. Según la definición de SIP 910 en [SIPBIS04], el campo de cabecera "Subject" ("Sujeto") proporciona un resumen o indica la naturaleza de la llamada, permitiendo filtración de llamada sin tener que analizar la descripción de sesión 102, así la indicación
- puede ser usada para definir el comienzo de una sesión 103 de E2ENP 908 en la solicitud inicial del E2ENP 908. Entonces, los componentes intermedios que comprenden E2ENP 908 cursarían simplemente los mensajes de una llamada de E2ENP 908 como se indica en la definición de SIP 910.
- Para seguir el rastro de los mensajes de E2ENP 908 a lo largo del trayecto de señalización y garantizar que la llamada para negociación 806 de extremo a extremo es comprendida inequívocamente, una indicación adicional del metaprotocolo DEBERÍA ser transportada en la cabecera "Content - Type":
- para informar a todos los componentes intermedios que comprenden SIP 910 que los cuerpos de mensajes de E2ENP 908 NO DEBEN experimentar cambios. Esta indicación adicional es necesaria puesto que la cabecera "Subject" es usada por definición solo con la request-calls (solicitud-llamadas), lo que es insuficiente con respecto a la inviolabilidad de la response-calls (respuesta-llamadas). En la estructura del content-type name (nombre de contenido-tipo)
"application/e2enp/sdpng"
- la indicación del E2ENP 908 está en el medio, evitando así el mal uso del cuerpo de mensaje desde componentes que comprenden SIP 910 y SDPng 912 pero no E2ENP 908. Los componentes que comprenden E2ENP 908 también deberían comprender SDPng 912 de por sí.
- 3.
- Nota: El uso adicional de la respuesta de llamada de estatus "380 Alternative Service" debería ser considerado realizando negociación de tercer abonado. El contestador 811, en un modelo estructural ofertante-mediador-contestador, es el "servicio alternativo" desde la perspectiva del mediador 106a1.
En la sección siguiente, deben ser presentados
algunos ejemplos que representan como la solución puede ser usada en
casos prácticos. El primer ejemplo se ocupa de servicios de
videoconferencia 1204a/b, en los que son usados escenarios de uno
con uno y de uno con muchos. El segundo ejemplo se ocupa de
escenarios de negociación 806 asistida por tercer abonado. El tercer
ejemplo representa el caso de un escenario de muchos con muchos.
Más específicamente, debe ser considerado el caso
de un usuario A dado que se une simultáneamente a dos sesiones de
videoconferencias 1204a/b diferentes como se representa en la Figura
12. El usuario A NO esta actuando como un mezclador en nombre de los
otros iguales, más bien está participando simplemente en dos
videoconferencias diferentes 1204a/b. En nuestra terminología, cada
caso de la aplicación de videoconferencia es denominado "sesión de
videoconferencia" 1204a/b. Entonces, el usuario A 1202a abrirá la
sesión nº 1 de videoconferencia con el usuario B 1202b y el usuario
C 1202c, y la sesión nº 2 de videoconferencia con el usuario D
1202d.
En este ejemplo, nos fijamos simplemente en el
nivel de calidad de servicio solicitado y percibido por el usuario A
1202a. Por tanto, este ejemplo se limita a la negociación 806 del
nivel de calidad de servicio que el usuario A 1202a desea obtener
para flujos 206 de información entrantes desde sus iguales
1202b/c/d; además, puede suponerse bien que el usuario A 1202a tiene
información suficiente para imponer la correlación 804 de calidad de
servicio y la sincronización 805 en el tiempo en todos los flujos
206 de información incluidos en ambas sesiones de videoconferencias
1204a/b.
En el resto de esta sección es aplicada la
convención siguiente:
- 1.
- Gráficos de secuencias de mensajes son presentados primero, detallando los procedimientos de protocolo a ser aplicados. El contenido de SDPng 912 es referido por palabras clave: las ofertas son referidas con la palabra clave "bid-x", las respuestas con la palabra clave "answer-y", en las que en ambos casos x e y significan un valor positivo entero de incremento.
- 2.
- Una descripción detallada del contenido de SDPng 912 es recogido entonces en un subpárrafo separado.
El diagrama siguiente se refiere a una
prenegociación en un escenario 100 de comunicación de uno con
uno:
- \bullet
- Modo de empujar
\newpage
- \bullet
- Modo de tirar:
Nota (1): El ofertante 914 puede
necesitar o no notificar la respuesta al contestador 911 con el
segundo método OPTIONS
(OPCIONES).
Por ejemplo, en el caso de un escenario de video
a petición, el ofertante 914 podría usar equivalentemente el método
RSTP DESCRIBE para recoger información sobre contratos 1108 de
calidad de servicio asociados con una información dada. En ese
caso, el contestador 911 (por ejemplo, un servidor de video a
petición) no necesitaría ser informado sobre la elección del
ofertante 914 (o sea, del cliente), hasta que es iniciado el flujo
real de información. Sin embargo, este documento se fija en
escenarios de conferencia basados en SIP, en los que los iguales
han de ser considerados sustancialmente en pie de igualdad: cada
para pretende ser informado sobre otros iguales para comunicación
posterior. Esto es especialmente cierto si, por ejemplo, el igual B
pretende imponer la correlación 804 de calidad de servicio y la
sincronización 805 en el tiempo. Por tanto, el escenario
representado anteriormente se aplica al ejemplo estudiado por la
presente.
- \bullet
- Modo de empujar-tirar:
Nota (2): Al recibir una oferta
desde el ofertante 914, el contestador 911 valida primero de todo
su propia oferta (por ejemplo, basado en información de perfil de
usuario), y después la oferta del ofertante 914, siguiendo un
subcaso del principio de economía (comprometer primero a recursos
locales y después a recursos de igual
remoto).
\newpage
En la sección siguiente son descritos los cuerpos
de mensajes de SIP indicados con las palabras clave
bid-x, answer-y en los ejemplos
anteriores.
Ejemplo 18 de
XML
La contraoferta indica qué capacidades soporta el
contestador 911 y en que grado. Si una capacidad dada es soportada
"como es", solo es indicado el identificador correspondiente
junto el atributo "scope" ("alcance") dispuesto en
aplicable. Si una capacidad dada no es soportada, el identificador
correspondiente es suprimido simplemente (en el ejemplo, el
codificador-descodificador de audio G.729 y el
codificador-descodificador de video WAVI). Si una
capacidad dada es actualizada en la sección <e2enp:qosdef
name="contracts">, es devuelta toda la descripción con las
actualizaciones. En cualquier caso, la sección <e2enp:qosdef
name="contracts"> contiene en una respuesta solo
parametrizaciones actualizadas de
codificadores-descodificadores. En el ejemplo, el
codificador-descodificador de audio PCMU y los
codificadores-descodificadores de video H.261 son
parametrizados nuevamente por el contestador 911.
Finalmente, la contraoferta puede relacionar
algunas capacidades no soportadas por el ofertante 914. En el
ejemplo, un codificador-descodificador de audio L16
y un codificador-descodificador de video
MEPG-2.
Contraofertas a la parte <e2enp:qosdef
name="contracts"> de una oferta pueden ser propuestas por
el contestador 911, independientemente de las líneas
correspondientes en la sección <e2enp:qosdef
name="capabilities">, y viceversa. En el ejemplo, el
alcance del codificador-descodificador de audio
G.722 es contraofertado como aplicable en la sección
<e2enp:qosdef name ="capabilities"> pero el contrato
1108 correspondiente en la sección <e2enp:qosdef
name="contracts"> es mantenido como es.
\newpage
Como se mencionó antes, una contraoferta al
contrato 1108 relativo al
codificador-descodificador de audio PCMU es
propuesta en la sección <e2enp:qosdef name="contracts">,
mientras que la oferta correspondiente en la sección
<e2enp:qosdef name="capabilities"> es mantenida como es.
Esta flexibilidad es debida a la definición modular de las diversas
secciones.
Los cambios con respecto a la oferta original son
indicados en negrita. En este ejemplo, el contestador 911 responde
al ofertante indicando que:
- -
- El codificador-descodificador de audio G729 no puede ser soportado (líneas correspondientes eliminadas).
- -
- El codificador-descodificador de audio L16 podría ser soportado (indicado como "posible" con configuración dispuesta).
- -
- El codificador-descodificador de video WAVI no puede ser soportado (líneas correspondientes eliminadas).
- -
- El codificador-descodificador de video MPEG-2 podría ser soportado (indicado como "posible" con configuración dispuesta).
- -
- Solo debe ser usada la directriz de optimización de recursos de red.
- -
- Audio-contract-1: solo puede ser aplicado un subconjunto del sampling-range (margen de muestreo) propuesto.
- -
- Video-contract-2: solo puede ser aplicado un subconjunto del frame-rate-range (cuadro-frecuencia-margen) propuesto.
Ejemplo 19 de
XML
Dichas oferta y respuesta difieren de las otras
descritas en los párrafos anteriores en tanto que la sección
<e2enp:
purpose> indica el modo de tirar en este caso.
purpose> indica el modo de tirar en este caso.
Para las "OPTIONS" ("OPCIONES"):
Ejemplo 20 de
XML
Para la "Bid-1.2"
("Oferta-1.2"):
\newpage
Ejemplo 21 de
XML
Para la "Answer-1.2"
("Respuesta-1.2"):
Ejemplo 22 de
XML
y la respuesta final del igual B es:
Ejemplo 23 de
XML
Estas ofertas y respuestas difieren de las
descritas en los párrafos anteriores en tanto que la sección
<e2enp:
purpose> indica en este caso el modo de empujar-tirar. La "Bid-1.3" ("oferta-1.3") debe incluir como sección <e2enp:
purpose> lo siguiente:
purpose> indica en este caso el modo de empujar-tirar. La "Bid-1.3" ("oferta-1.3") debe incluir como sección <e2enp:
purpose> lo siguiente:
Ejemplo 24 de
XML
Más específicamente,
"Answer-1.3+Bid-1.4"
("Respuesta-1.3+Oferta-1.4") da
cuenta del caso en el que el contenido de SDPng de E2ENP 908 incluye
tanto la oferta como la respuesta del contestador 911. Para
distinguir la oferta de la respuesta, cada una de ellas debe
presentar una sección <e2enp:purpose> distinta. Esto significa
que la prenegociación 802 de empujar-tirar produce
la intercalación de dos sesiones 103 de prenegociación 802, cada una
con su propio identificador.
Más concretamente, si por ejemplo la
"Bid-1.3" ("Oferta-1.3")
presenta una sección <e2enp:purpose> como la indicada
anteriormente, entonces la
"Answer-1.3+Bid-1.4" debe
presentar dos secciones <e2enp:purpose> como lo siguiente:
\vskip1.000000\baselineskip
Ejemplo 25 de
XML
La oferta del contestador 911 hace referencia a
la oferta del ofertante 914 por medio de la construcción
<use> en tanto que el contestador 911 formula su oferta
basada no solo en las preferencias del contestador 911 (por ejemplo,
a partir de información de perfil de usuario) sino también en la
oferta del ofertante 914 (y basada finalmente en restricciones de
correlación 804 de calidad de servicio y/o sincronización 805 en el
tiempo).
Por supuesto, siguiendo el ejemplo anterior, la
"Answer-1.4"
("Respuesta-1.4") debe incluir como sección
<e2enp:
purpose> lo siguiente:
purpose> lo siguiente:
Ejemplo 26 de
XML
En la sección siguiente deben ser descritas la
negociación y la reserva de recursos:
- \bullet
- Modo de empujar:
Nota(1): Después de haber
comprometido previamente recurso local con respecto a
"Bid-2.1" ("Oferta-2.1"),
el igual A reserva finalmente el subconjunto negociado
"Answer-2.1"
("Respuesta-2.1") para liberar cualquier
recurso
sobrante.
- \bullet
- Modo de tirar
Nota (2): Después de haber
comprometido previamente recurso local con respecto a
"Bid-2.2" ("Oferta-2.2"),
el igual B reserva finalmente el subconjunto negociado
"Answer-2.2"
("Respuesta-2.2") para liberar cualquier
recurso
sobrante.
Nota (3):
"Bid-2.2" ("Oferta-2.2") y
"Answer-2.2"
("Respuesta-2.2") son sustancialmente
equivalentes (de modo correspondiente) a
"Bid-2.1" ("Oferta-2.1") y
"Answer-2.1"
("Respuesta-2.1") excepto por la sección
<e2enp:
purpose> que presenta el atributo "mode" dispuesto en "pull" y, en el caso de "Answer-2.2" ("Respuesta-2.2"), el atributo "type" dispuesto en "start-reservation".
purpose> que presenta el atributo "mode" dispuesto en "pull" y, en el caso de "Answer-2.2" ("Respuesta-2.2"), el atributo "type" dispuesto en "start-reservation".
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
(Tabla pasa a página
siguiente)
\newpage
- \bullet
- Modo de empujar-tirar
Nota (4): Después de haber
comprometido previamente recursos local con respecto a
"Bid-2.3" ("Oferta-2.3"),
el igual A reserva finalmente el subconjunto negociado
"Answer-2.3"
("Respuesta-2.3") para liberar cualquier
recurso
sobrante.
Nota (5): Después de haber
comprometido previamente recurso local con respecto a
"Bid-2.4" ("Oferta-2.4"),
el igual B reserva finalmente el conjunto negociado
"Answer-2.4"
("Respuesta-2.4") para liberar cualquier
recurso
sobrante.
Nota (6):
"Bid-2.3"/"Bid-2.4" y
"Answer-2.3"/"Answer-2.4"
son sustancialmente equivalentes (de modo correspondiente) a
"Bid-2.1" y "Answer-2.1"
excepto por la sección <e2enp:purpose> que presenta el
elemento "mode" dispuesto en empujar-tirar y,
en el caso de "Answer-2.4", el atributo
"type" dispuesto en
"start-reservation".
Nota (7): La
"Answer-2.3" es una TSpec para recibir, la
"Answer-2.4" es una TSpec para
emitir.
Nota (8): La
"Answer-2.3" es una TSpec para emitir, la
"Answer-2.4" es una TSpec para
recibir.
En la sección siguiente, deben ser descritos los
cuerpos de mensajes de SIP indicados con las palabras clave
bid-x, answer-y en los ejemplos
anteriores.
Esta oferta se refiere a información
prenegociada, indicando el identificador de sesión 103 que indica
únicamente esa información por medio de la construcción <use>
en la sección <e2enp:purpose>. En este ejemplo, la información
referida es "Bid-1.1" que fue usada para
prenegociar capacidades y contratos 1108 de calidad de servicio a
nivel de flujo. Alternativamente, los iguales podrían haber
prenegociado la información de trayecto de adaptación contenida en
este párrafo, directamente en "Bid-1.1" para
acelerar la fase de negociación 806.
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
(Esquema pasa a página
siguiente)
\newpage
Ejemplo 27 de
XML
Referente a la sección <cfg> de SDPng 912,
el contestador 911 en este ejemplo contesta al ofertante 914
relacionando solo la información de transporte sobre la que se ha
alcanzado el acuerdo. Los cambios con respecto a la oferta original
son indicados en negrita. En este ejemplo, el contestador 911
responde al ofertante 914 indicando lo siguiente:
- \bullet
- La opción "AVP-video-33" no puede ser soportada debido, por ejemplo, a IPv6 no soportado por el contestador 911 (líneas correspondientes eliminadas).
- \bullet
- "association1-1": Solo puede ser aplicado un subconjunto del "lipsync-delay" propuesto.
- \bullet
- "association1-1": Solo puede ser aplicado un subconjunto del "aggregated-bw" propuesto.
- \bullet
- "association1-2": Confirmada como sea aplicable.
En esta fase, los iguales negocian el trayecto
de adaptación de flujo 206 de información y el trayecto de
adaptación de asociación por medio de la sección
<e2enp:qoscfg>: en este ejemplo, el contestador 911 responde
con un subconjunto de las restricciones de sincronización 805 en el
tiempo y correlación 804 de calidad de servicio de oferta (solo son
detallados los elementos cambiados: los cambios son indicados en
negrita).
\vskip1.000000\baselineskip
Ejemplo 28 de
XML
Para señalizar la orden de un igual para empezar
a reservar recursos, el contenido de SDPng presentará simplemente
una sección e2enp:purpose> con el atributo "name" dispuesto
en "start-reservation", como en el ejemplo
siguiente:
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
Ejemplo 29 de
XML
Para señalizar al igual que la reserva ha sido
efectuada, el contenido de SDPng presentará simplemente una sección
<e2enp:purpose> con el atributo "name" dispuesto en
"ready-reservation", como en el ejemplo
siguiente:
\vskip1.000000\baselineskip
\newpage
Ejemplo 30 de
XML
Como se anticipó antes, los iguales podrían haber
prenegociado la información de trayecto de adaptación descrita en el
resto de este párrafo directamente en
"Bid-1.1" para acelerar la fase de negociación
806. Lo siguiente es un ejemplo de información de oferta y
respuesta de prenegociación 802 (para el caso sencillo de una
prenegociación 802 en modo de empuje), y después oferta y respuesta
de la negociación 806 (modo de empuje nuevamente). El ejemplo
siguiente está basado en los correspondientes antes descritos.
- \bullet
- Bid-1.1 (Oferta-1.1) - con trayecto de adaptación de flujo 206 de información y trayecto de adaptación de grupo (con respecto a asociaciones de flujos)
\vskip1.000000\baselineskip
Ejemplo 31 de
XML
- \bullet
- Answer-1.1 (Respuesta-1.1) - con trayecto de adaptación de flujo 206 de información y trayecto da adaptación de grupo (con respecto a asociaciones de flujos)
\vskip1.000000\baselineskip
Ejemplo 32 de
XML
- \bullet
- Bid-2.1 (Oferta-2.1) - hacer referencia solo al trayecto de adaptación de flujo 206 de información y al trayecto de adaptación de grupo (con respecto a asociaciones de flujos)
Ejemplo 33 de
XML
- \bullet
- Answer-2-2 (Respuesta-2.2) - hacer referencia solo al trayecto de adaptación de flujo 206 de información y al trayecto de adaptación de grupo (con respecto a asociaciones de flujos)
Ejemplo 34 de
XML
En este caso, tanto el ofertante 914 como el
contestador 911 acuerdan implícitamente imponer los trayectos de
adaptación prenegociados iniciando el flujo de información con los
contratos 1108 indicados por la construcción <default>.
Si cualquiera de los iguales decide de otro modo
debido a algunas condiciones que se aplican en el momento de la
negociación 806 (y del comienzo del flujo de información, que se
aplicaría inmediatamente después de la negociación 806), podría ser
incluida una versión reducida de la sección <e2enp:qosdef>,
indicando el nuevo contrato 1108(s) por omisión.
Recuérdese que el estado por omisión corresponde,
en el modelo de Máquina de Estados Finitos (FSM) jerárquica, al
estado inicial de una FSM dada (anidada finalmente).
En el caso de renegociación 808, no es usado el
atributo "mode" de la sección <e2enp:purpose>.
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
(Tabla pasa a página
siguiente)
Nota (1): Ambos iguales reservan
recursos correspondientes a los niveles de calidad de servicio
renegociados, añadiendo cualquier recurso requerido y/o liberando
cualquier recurso sobrante, con respecto a la cantidad de recursos
reservados
previamente.
Nota (2): Para una descripción de
"Command-start-reservation" y
"Command-stop-reservation",
véase la descripción
anterior
Nota (3): El método DO (HACER) usa
el mecanismo fiable sencillo de acuse de recibo del método BYE.
También son posibles otros método. Por ejemplo, el uso de un
re-INVITE (re-INVITAR) impondría el
acuse de recibo tridireccional, que garantiza que los iguales
empiezan el flujo de información con el nuevo nivel de calidad de
servicio de una manera coordinada y segura. Podría ser útil para
obligar al igual a usar otro terminal o para realizar una
renegociación 808 completa de calidad de servicio de extremo a
extremo. La elección del método correcto está abierta a
discusión.
Nota (4): La
"Answer-3.1" en este mensaje presenta el
atributo "type" dispuesto en
"start-reservation".
En la sección siguiente, deben ser descritos los
cuerpos de mensajes de SIP indicados con las palabras clave
bid-x, answer-y en los ejemplos
anteriores.
En este ejemplo, con respecto a la información ya
negociada durante fases anteriores (la última de las cuales es
identificada por el elemento <session> envuelto por el
elemento <use> de la sección <e2enp:purpose>, el igual B
solicita al igual A imponer un contrato alternativo de calidad de
servicio. Más específicamente, el igual B solicita al igual A
imponer el contrato 1108 de calidad de servicio a nivel de flujo
"video-contract-2", el lugar
del contrato por omisión
"video-contrat-1", con respecto
al flujo 206 de información de video "video1" de la asociación
activa actualmente "association1-1". Esta
orden es expresada por medio de la sección "enforce". En este
fragmento de XML, el uso de XPath es mostrado de un modo
simplificado para captar el concepto de la sección <enforce>.
Una descripción rigurosamente formal de las ampliaciones globales de
SDPng propuestas por la presente será proporcionada
posteriormente.
Además, el A igual puede descubrir que
video-contrat-1 ya no es aplicable
con el nuevo tipo de red 604 de acceso/proveedor de red: por tanto,
el igual A señaliza un "bloqueo" para ese contrato 1108. Si
contratos 1108 sobrantes están disponibles y son válidos ahora, una
señal "desbloqueo" también podría ser incluida en la
oferta.
Ejemplo 35 de
XML
Alternativamente, el igual B también puede
indicar simplemente al igual A alguna información de nivel
superior, en la que el igual A separaría entonces la información
restante de nivel inferior recurriendo a valores por omisión. Por
ejemplo, la sección </e2enp:enforce> siguiente:
Ejemplo 36 de
XML
Obligaría al igual A a usar
"video-contract1" para el flujo 206 de
información "video1", puesto que el contrato 1108 fue
especificado como por omisión en la sección <e2enp:qoscfg>
prenegociada. Además, el igual B puede solicitar al igual A
conmutar a un grupo totalmente diferente de flujos 206 de
información, seleccionado a partir de la información prenegociada.
Por ejemplo, suponiendo que la asociación actualmente activa de
flujos 206 de información entre el igual A y el igual B es la
"association1-1", el igual B puede solicitar al
igual A que seleccione la "association1-2" como
en el ejemplo siguiente de la sección <e2enp:enforce>:
Ejemplo 37 de
XML
Según la exigencia 31, el contestador 911 debería
limitar su reacción a aprobar la oferta del ofertante 914 o elegir
simplemente un nivel inferior de calidad de servicio a ser
seleccionado de información prenegociada. Siguiendo el ejemplo
indicado en el párrafo anterior, el igual A podría elegir entonces
aceptar la propuesta como es o seleccionar una opción alternativa a
partir de la información prenegociada, que satisface todavía la
oferta original del ofertante 914.
En el primer caso, la
"Answer-3.1"
("Respuesta-3.1") se parecería a lo
siguiente:
Ejemplo 38 de
XML
La ausencia de la sección <e2enp:enforce>
en la respuesta del contestador 911 indicó que el contestador 911
ha estado de acuerdo con la oferta del ofertante 914.
En el caso de que el contestador 911 (el igual A
en este ejemplo) prefiriera un nivel inferior de calidad de
servicio, la "Answer-3.1"
("Respuesta-3.1") se parecería a lo
siguiente:
Ejemplo 39 de
XML
En este ejemplo debe suponerse que un
"video-contract-3" que define
un nivel inferior de calidad de servicio comparado con el definido
por el "video-contract-1"
propuesto, ha sido negociado previamente entre los dos iguales (no
mostrado en los ejemplos anteriores). Alternativamente, el igual A
puede especificar un nivel inferior de calidad de servicio
especificando otra asociación, como se describió en el párrafo
anterior
Ejemplo 40 de
XML
En la sección siguiente debe ser descrita una
prenegociación 802 en un escenario 200 de comunicación de uno con
muchos:
- \bullet
- Modo de empujar
Nota (1): las diversas respuestas
"Answer-1.1.Bj" pueden coincidir, diferir
parcialmente o diferir completamente entre sí. Sustancialmente, son
equivalente a "Answer-1.1" descrita
anteriormente.
Nota (2): después de recibir todas
las respuestas del igual B_{j}, el igual A puede imponer las
restricciones de correlación 804 de calidad de servicio y
sincronización 805 en el tiempo, y renegociar así con los iguales
B_{j} nuevos niveles inferiores de calidad de
servicio.
\newpage
- \bullet
- Modo de tirar
Nota (3): las diversas respuestas
"Answer-1.2.A_{j}" pueden coincidir, diferir
parcialmente o diferir completamente entre sí. Sustancialmente,
"Answer-1.2.A_{j}" son equivalentes a
"Answer-1.2" descrita anteriormente.
"Bid-1.2" también es sustancialmente
equivalente a la descrita
anteriormente.
Nota (4): durante el control de
admisión local, el igual B podría imponer las restricciones de
correlación 804 de calidad de servicio y sincronización 805 en el
tiempo antes de contestar a cada igual A_{j}, pero los diversos
A_{j} llevan a cabo generalmente esta fase de E2ENP 908
independientemente entre
sí.
Por tanto, no es generalmente posible negar
respuestas a OPTIONS (OPCIONES) más allá de la duración
correspondiente de temporizador de SIP. Alternativamente, el igual B
puede decidir aceptar la solicitud dentro de una cierta ventana de
tiempo, después de lo cual el igual B puede imponer restricciones de
correlación 804 de calidad de servicio y sincronización 805 en el
tiempo y, por consiguiente, llevar a cabo nuevas prenegociaciones
802 con cada igual A_{j}.
En este caso, el igual B desempeñaría entonces la
función del ofertante 914. Como un ejemplo, el igual B podría ser
un emisor como en el escenario de disertación, que prenegocia la
calidad de servicio con cada receptor primero individualmente, y
después vuelve a ejecuta finalmente alguna prenegociación 802 para
imponer restricciones de correlación 804 de calidad de servicio y
sincronización 805 en el tiempo.
Prenegociar conexiones bidireccionales para el
caso de uno con muchos puede producir una conexión real de muchos
con muchos; por tanto, este caso no es tratado aquí.
La negociación 806 bidireccional no es presentada
por la presente puesto que esto podría producir un caso de
escenario de muchos con muchos en el que debería prestarse atención
particular a cuestiones de sincronización. Los escenarios
siguientes son válidos así para el caso donde el igual "uno" de
la relación de uno con muchos es un emisor (receptor) y cada uno de
los "muchos" iguales de tal relación es un receptor
(emisor).
\newpage
- \bullet
- Modo de empujar
\newpage
- Nota(1):
- "Bid-2.1" ("Oferta-2.1") es sustancialmente equivalente a la descrita en los ejemplos precedentes.
- Nota(2):
- Equilibrar los recursos en las respuestas de B_{j} liberando cualquier recurso sobrante.
- Nota(3):
- Usando la señalización "command-start-reser-vation", el igual A será capaz dedeterminar si y cuando las reservas de recursos de red deberían ser llevadas a cabo basadas en toda la {"Answer-2.1.B_{j}"} o solo en cualquier subconjunto de ella que esté actualmente disponible.
- Nota(4):
- Basada en la answer-2.1.B_{j} (respuesta-2.1.B_{j}) de B_{j}.
- \bullet
- Modo de tirar
- Nota (5):
- Las diversas respuestas "Answer-2.2.A_{j}" pueden coincidir, diferir parcialmente o diferir completamente.
- Nota (6):
- "Bid.2.2" y "Answer-2.2.A_{j}" son sustancialmente equivalentes (de modo correspondiente) a "Bid.2.1" y "Answer-2.1" excepto por la sección <e2enp:purpose> que presenta el atributo "mode" dispuesto en "pull" ("tirar") y, en el caso de "Answer-2.2.A_{j}", el atributo "name" dispuesto en "start-reservation".
- Nota (7):
- Basada en la "Answer-2.2.A_{j}" de B_{j}.
- Nota (8):
- Usando la señalización "command-start-reservation", el igual A será capaz de determinar si y cuando las reservas de recursos de red deberían ser llevadas a cabo basadas en todas las ("Answer-2.2.Aj") o solo en cualquier subconjunto de ellas que está actualmente disponible.
Negociar conexiones bidireccionales para el caso
de uno con muchos puede producir una conexión real de muchos con
muchos; por tanto, este caso no es tratado aquí.
En general, la renegociación 808 de conexiones
multi-abonado (como son las conexiones de uno con
muchos) debería ser considerada equivalente al caso de conexiones de
uno con uno. La exigencia 37 produce solo dos casos especiales
cuando más de un flujo 206 de información deberían ser renegociados
simultáneamente. Estos dos casos son determinados por las
circunstancias siguientes:
- \bullet
- Si el componente central (el "uno") descubre una violación, debería comprobar si el flujo 206 de información afectado es un flujo 206 de información de un grupo y, si pertenece a un grupo, es afectado el contexto del grupo en el sentido de calidad de servicio. Mediante flujos 206 de información únicos y descubriendo que el contexto del grupo no es afectado, el componente central realiza la negociación 806 de uno con uno con el igual respectivo, de otro modo el componente central realiza la renegociación 808 de uno con muchos como se describe en el primer caso a continuación.
- \bullet
- Si uno de los "muchos" descubre una violación, señaliza esta al componente central en forma de uno con uno puesto que los "muchos" no están enterados del agrupamiento final de flujos 206 de información realizado por el componente central. Para decidir como proceder, el componente central comprueba las dependencias del flujo 206 de información afectado:
- \circ
- Si el flujo 206 de información no pertenece a un grupo o el contexto del grupo no es afectado, el componente central continúa la negociación 806 en forma de uno con uno.
- \circ
- Si el componente central descubre dependencias que no sólo afectan al flujo 206 de información único, señaliza al ofertante 914 en espera (como se describe después - caso 2) que a partir de ahora sería responsable de la renegociación 808. El ofertante 914 debería anular su llamada y esperar una oferta desde el componente central.
Los siguientes son los ejemplos de los dos casos
de renegociación 808 de uno con muchos:
- 1.
- El abonado central de una conexión dada de uno con muchos descubre una violación que afecta a un flujo 206 de información único de su grupo dado y, según los ajustes de perfiles (o sea, los trayectos de adaptación de alto nivel prenegociados) de este grupo, realiza la adaptación necesaria de todo el grupo de flujos 206 de información. En el caso de conexiones de uno con muchos, de hecho solo el igual que actúa como el "uno" es quien cuida del agrupamiento de flujos 206 de información.
\newpage
- 2.
- Uno de los "muchos" iguales descubre una violación:
En lo siguiente debe ser descrito un ejemplo de
negociación asistida por tercer abonado usando el E2ENP 908.
Los abonados que negocian son:
A - El igual para el que la mediación está siendo
efectuada,
B - El igual mediador 106a1, y
C - El igual ofertante 914 que se dirige al
mediador 106a1.
La negociación asistida por tercer abonado está
siendo disipada cuando un ofertante 914 llama a un dispositivo
mediador y este igual respectivo descubre que no puede manejar la
llamada por sí mismo pero tiene la posibilidad de delegar la llamada
en otro contestador 911. El contestador 911 descubierto es un
dispositivo alternativa desde el punto de vista del mediador 106a1,
que el ofertante 914 que llama puede usar en lugar del mediador
106a1 y por aprobación respectiva del usuario, cuyo dispositivo es
el mediador 106a1.
El fin de las prenegociaciones 802 con un
mediador 106a1 es permitir que el mediador 106a1 recoja información
sobre esos iguales, que pueda estar implicada en reorientaciones
futuras posibles. El mediador 106a1 puede hacer esto usando algún
mecanismo de descubrimiento de servicios como JINI, como se describe
en documentos publicados por JINI™ Network 604 Technology
(cf.http:// www.sun.com/jini/), designado [JINI] en lo siguiente,
Bluetooth SDP como se describe en [BLUE], etc., o llamando
directamente a los iguales afectados para los que está siendo
efectuada la facilitación. En el último caso, la prenegociación 802
puede ser realizada de modo similar que el caso de prenegociaciones
802 de uno con uno, en las que el mediador 106a1 actúa como el
ofertante 914 y el igual, para el que es efectuada la mediación,
actúa como el contestador 914. Hasta este punto, es requerida una
indicación especial en la sección <e2enp:purpose> para
indicar que el ofertante 914 es el mediador 106a1 (<mediation
mode="third-party-assisted"/).
\newpage
En el caso de que el abonado para el que la
mediación es efectuada conviene la prenegociación 802 con el
mediador 106a1, el esquema de SIP es como sigue:
El mediador 106a1 escoge justamente los ajustes
de A (respuesta) y los usa para realizar la mediación. La
prenegociación 802 entre el igual mediador y el ofertante 914 es
más o menos igual que la prenegociación 802 de uno con uno con la
indicación en la sección <purpose> de que el contestador 911
es el mediador 106a1 (<mediation
mode="third-party-assisted"/>).
El ofertante 914 debería modo de empujar o modo de
empujar-tirar para activar la funcionalidad de
facilitación del mediador 106a1. En lugar de usar "200 OK"
como respuesta para las OPTIONS (OPCIONES), el mediador 106a1 usa
"380 Alternative Service" ("380 Servicio Alternativo")
indicando así que no es el igual que va a comunicar. El ofertante
914 ya es informado en esta etapa sobre la existencia de un igual
alternativo y en algunos casos, donde el usuario llamado es
informado y está de acuerdo en el uso del igual alternativo, el
ofertante 914 puede empezar directamente una negociación 806 con el
igual alternativo aplicando el esquema de negociación 806 de uno
con uno.
La negociación asistida por tercer abonado
siempre debería ser realizada en modo de empujar o modo de
empujar-tirar con el mediador 106a1 para activar la
funcionalidad de facilitación del igual mediador en el caso de que
no pueda soportar una oferta.
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
(Tabla pasa a página
siguiente)
Como un resultado de esta negociación, el igual C
sabe quién es el igual A y los ajustes de él y puede iniciar con él
una negociación normal de uno con uno (véase ejemplo de negociación
806 de uno con uno).
Realizar una renegociación 808 sobre un mediador
106a1 solo tiene sentido en el caso de renegociación 808 completa
cuando debería ser elegido un nuevo dispositivo con el que
comunicar, de otro modo la renegociación 808 resultaría demasiado
compleja. De hecho, esto desmentiría la exigencia de sencillez de
E2ENP 908 y en cualquier caso no sería realmente lógico puesto que
el ofertante 914 ya sabe por la fase de negociación 806 quién es
exactamente su contestador 911. Mediante la renegociación 808 yendo
sobre un mediador 106a1, el mediador 106a1 actúa como un proxy. En
el caso de renegociación 808 completa, este proceso es igual que la
prenegociación 802 y la negociación 806 antes descritas. Mediante
la renegociación 808, el mediador 106a1 también debería satisfacer
la exigencia sobre la integridad de los datos negociados.
La construcción y la negociación 806 de los
escenarios 300, 400 y 500 de comunicación de muchos con muchos son
dependientes del contexto con respecto a los escenarios
considerados, por ejemplo conferencia, juego, etc. Una solución
general no es posible para este caso pero tomar algunos escenarios
dispuestos dependientes del tópico, como se describe en "Modelos
para conferencia multi-abonado en SIP 910" (IETF
SIP 910 PING Working Group, trabajo en marcha,
<draft-rosenberg-sip-conferencing-models-01.txt>)
de J. Rosenberg y H. Schulzrine, designado [Rosen01] en lo
siguiente, y "Modelos para conferencia
multi-abonado en SIP" (IETF SIPPING Working
Group, trabajo en marcha,
<draft-ietf-sipping-conferencing-models-00.txt>)
de J. Rosenberg y H. Schulzrine, designado [Rosen0a] en lo
siguiente, y desarrollarlos en términos de E2ENP 908 debería ayudar
a comprender como funciona E2ENP 908 cuando son aplicadas conexiones
multi-abonado. El ejemplo siguiente tomado de
[Rosen00a], y realzado más en términos de E2ENP, está relacionado
con operación en red ad hoc.
Considerando la numeración en la Figura 13, los
pasos siguientes son tenidos en cuenta para aplicar el E2ENP
908:
- \bullet
- En el número 1 - A proporciona a B su vista de calidad de servicio.
- \bullet
- En el número 4 - B proporciona al servidor de conferencia la vista de calidad de servicio de A y B.
- \bullet
- En los números 4 a 14 - El servidor de conferencia suministra su vista sobre la conferencia (número 5) a B y B hace las reservas para él mismo hasta el servidor.
- \bullet
- En el número 15 - A consigue conocer la vista del servidor de conferencia sobre la conferencia desde B.
- \bullet
- En el número 17 - A invita al servidor de conferencia con lo suministrado desde la vista de servidor de B sobre la calidad de servicio. Esto es justamente una referencia a la vista de calidad de servicio del servidor puesto que A y el servidor de conferencia en ambos lados ya conocen esta vista común.
- \bullet
- En los números 17 a 27 - A hace las reservas para el mismo hasta el servidor.
- \bullet
- En el número 32 - B proporciona a C la vista del servidor sobre la conferencia.
- \bullet
- En el número 34 - C proporciona al servidor esta vista sobre la conferencia restringida según la información procedente de B.
- \bullet
- En los números 34 a 44 - C hace las reservas para el mismo hasta el servidor.
- \bullet
- En el número 45 - C informa a B que está dispuesto.
- \bullet
- En los números 49 a 52 - B informa adicionalmente al servidor de conferencia que todos los socios están dispuestos y el servidor debería suministrar una orden de comenzar a todos.
A partir de este ejemplo, es evidente que algunas
ideas procedentes del escenario de uno con uno referentes a las
reservas también pueden ser aplicadas a la comunicación de igual
con igual entre los usuarios y el servidor de conferencia. Las
ofertas y las respuestas son comunes a las en el ejemplo de
negociación de uno con uno antes descrito. Este ejemplo representa
el procedimiento de reservas con mensajes de SIP de la misma manera
que en el escenario de uno con uno, la única diferencia es qué
clase de mensajes son puestos como información suplementaria de
SDPng. Según el ejemplo anterior, hay tres funciones diferentes que
pueden desempeñar los iguales finales:
- \bullet
- Iniciador de conferencia ad hoc - Como B
- \bullet
- Participante ya en conferencia - Como A
- \bullet
- Nuevo participante en conferencia - Como C
Estas tres funciones corresponden a tres modelos
de comunicación diferentes con el servidor de conferencia con
respecto a los mensajes de SDPng intercambiados.
La máxima información suplementaria de
comunicación tiene B (el iniciador de conferencia ad hoc), puesto
que transporta todos los mensajes de SDPng de los participantes ya
en conferencia. Esta capacidad de B es una clase de capacidad de
mediación para inicializar la conferencia obligando a los iguales
afectados a negociar con el servidor de conferencia y terminando la
negociación para transferir los controles al servidor.
La mínima información suplementaria de
comunicación tiene un participante ya en conferencia como A, puesto
que el servidor de conferencia ya está informado sobre el perfil de
A por medio de B y A solo necesita recordar al servidor que perfil
le pertenece (consúltese la Figura 13. mensaje 17).
El nuevo participante C en conferencia conoce lo
validado a partir de los perfiles de servidor de conferencia de los
participantes ya en conferencia, minimizando así su conjunto de
decisiones y permitiéndole alcanzar una cuerdo más rápido con el
servidor de conferencia. La información suplementaria de
comunicación de C es así aproximadamente igual que mediante la
comunicación de uno con uno puesto que tiene que alcanzar el
acuerdo con el servidor por el mismo.
Los ejemplos siguientes ilustran algunos de los
casos de fallos descritos anteriormente.
Escenario 100 de comunicación de uno con uno
- \bullet
- Prenegociación 802:
Nota (1): El contestador 911
responde con "600 Busy" ("600 Ocupado") si en el momento
no hay capacidad para manejar ninguna llamada. Alternativamente, el
contestador 911 podría responder con "603 Decline" ("603
Rehusar") indicando en qué momento posterior puede tener lugar
la llamada, si este tiempo es conocido. Lo mismo puede ser usado en
ambos modos de empujar y tirar, pero en el modo de tirar la llamada
"OPTIONS" ("OPCIONES") no contiene
oferta.
\newpage
- \bullet
- Negociación 806:
Nota (2): El contestador 911 emite
"600 Busy" ("600 Ocupado") si algún otro ofertante 914
fue más rápido al emitir la llamada y ocupaba todas las capacidades
disponibles del contestador 911. El contestador 911 emite "603
Decline" ("603 Rehusar") si algún otro ofertante 914 fue
más rápido al emitir la llamada y ocupaba todas las capacidades
disponibles del contestador 911 pero el contestador 911 sabe cuanto
tiempo debe continuar la llamada. Este es también el caso de que
una transacción similar con respecto a la prioridad está siendo
procesada en el momento y el que llama tiene que esperar. El
contestador 911 emite "606 Not Aceptable" ("606 No
Aceptable") si el ofertante 914 pide soporte de calidad de
servicio que no está disponible en el momento. El contestador 911
emite "380 Alternative Service" ("380 Servicio
Alternativo") si las condiciones del ofertante no son aceptables
para él pero conoce un servicio alternativo que puede soportar
estas condiciones. Esta llamada debería ser usada con servicios
automáticos como video a petición. En cualquier de los casos
anteriores, el ofertante 914 puede iniciar una nueva llamada con
"OPTIONS" ("OPCIONES") puesto que las condiciones
prenegociadas pueden no ser válidas ya. Este esquema es aplicable
para todos los modos de comunicación (empujar, tirar,
empujar-tirar). La única diferencia entre ellos es
el envío de una oferta inicial con el "INVITE"
("INVITAR") o enviarla posteriormente (modo de
tirar).
- \bullet
- Renegociación 808: Los casos de fallos por la renegociación 808 son iguales que por la negociación 806. Las indicaciones de error respectivas son devueltas como una respuesta a las llamadas "DO" ("HACER") del ofertante 914.
La estructura de las fases de negociación 806 por
el escenario de uno con muchos es muy parecida a la del escenario
de uno con uno; hasta este punto, los casos de error de E2ENP 908
descritos en el escenario de uno con uno también son válidos en
este caso. Como el escenario de uno con muchos está relacionado con
la posibilidad de fallos múltiples causados por los "muchos"
iguales, el componente central (el "uno") debería tener la
capacidad de enfrentarse con tales fallos. Las siguientes son
algunas sugerencias de cómo pueden ser tratados estos:
- -
- Cada conexión de negociación 806 entre el igual que actúa como el "uno" y cada uno de los que actúan como los "muchos" debería ser considerada como una autónoma única con respecto a señalización de SIP 910. De este modo, los iguales que actúan como "muchos" implicados en la fase de negociación 806 no necesitan conoce sobre los fallos que efectúan algunos iguales del grupo. El tratamiento de fallos tiene lugar solo en el componente central.
- -
- Si algunas de las conexiones de negociación 806 no tienen éxito dentro del límite de tiempo, deberían ser llamadas posteriormente para negociación 806 repetida. El componente central detectaría esto por el período de espera de una llamada de SIP 910 o recibiendo un mensaje de error de SIP desde el abonado llamado. Como E2ENP 908 tiene una exigencia de consistencia pero no de aislamiento, sería suficiente conservar los datos actuales de las llamadas insatisfactorias para tener una referencia sobre su estado actual, antes del fallo, por la repetición de la llamada. Esto significa que no es necesaria la conservación de estados completa de las ejecuciones de E2ENP 908 puesto que no es necesario "deshacer".
- -
- El abonado central debería ser capaz de reconfigurar los flujos 206 de información en línea. Si algunos de los flujos 206 de información no tienen éxito en ser renegociados dentro del límite de tiempo, el componente central reconfigura consiguientemente solo los que han tenido éxito e intenta renegociar los insatisfactorios en un momento posterior. Nuevamente aquí, las negociaciones 806 satisfactorias no necesitan conocer que algunas de ellas fallaron.
- -
- El componente central intenta llamar a los abonados con negociación 806 insatisfactoria varias, pero un número limitado de, veces, por ejemplo 3 veces. Si hay abonados cuyas fases de negociación 806 no tuvieron éxito después de la tercera llamada, deberían ser expulsados del grupo y sus flujos 206 de información serían cancelados finalmente, por ejemplo si la señalización de RTP por la conexión de datos también es inexistente. Este método debería proporcionar la posibilidad a los "muchos" insatisfactorios de tener oportunidad de recuperar e iniciar finalmente la llamada de negociación 806 por si mismos.
- -
- El rendimiento funcional en paralelo de las llamadas de negociación 806 permite la ejecución rápida de la negociación 806. Hasta este punto, el componente central debería tener posibilidad de reconfigurar flexiblemente sus recursos. Es necesario conocer a cuantos abonados en paralelo puede servir el componente central y, si este límite es superado, el componente central emite "486 Busy Here" ("486 Ocupado aquí") o (380 Alternative Service) ("380 Servicio Alternativo") (si el componente central es un servicio y conoce uno alternativo).
La sección siguiente se refiere al caso de un
E2ENP 908 asistido por tercer abonado en el que falla la búsqueda
de reubicación 108:
El mediador 106a1 señaliza que no fue hallada
alternativa y el ofertante 914 debería llamar nuevamente en modo de
tirar, adaptando a los ajustes del mediador 106a1.
Si el usuario rehusa la reubicación 108 de
llamada, el resultado posible de la negociación 806 es:
El mediador 106a1 responde con:
- \bullet
- "480 Temporarily Unavailable" ("480 Temporalmente no Disponible", si el usuario no reacciona a la señal o a la ventana aparecida durante cierto tiempo, debería ser considerado no disponible.
- \bullet
- "603 Decline" ("603 Rehusar"), si el usuario rehusa explícitamente la llamada.
- \bullet
- "606 Not Aceptable" ("606 No Aceptable"), si el usuario rehusa la delegación de la llamada.
Si la negociación 806 con el contestador 911
esperado (el abonado de C) es insatisfactoria o el abonado al que
ha de ser delegada no acepta la llamada.
El significado de estas propuesta es:
- \bullet
- "480 Temporarily Unavailable" ("480 Temporalmente no Disponible"), si el usuario no reacciona a la señal a la ventana aparecida durante cierto tiempo, debería ser considerado no disponible.
- \bullet
- "603 Decline" ("603 Rehusar"), si el usuario rehusa explícitamente la llamada.
- \bullet
- "606 Not Aceptable" ("606 No Aceptable"), si el usuario desea comunicar pero la delegación de la llamada ha resultado mal. Esta respuesta permitiría la iniciación de una negociación 806 nueva con el mediador 106a1 como un contestador 911; el ofertante 914 debería tener cuidado de realizar la nueva negociación 806 en modo de tirar para adaptarse al perfil del mediador 106a1 no activando su funcionalidad de facilitación.
En conclusión, las diferencias ventajosas
principales entre la invención fundamental y el estado de la
técnica pueden ser resumidas brevemente como sigue:
- -
- uso de SDPng 912 para implementar el concepto de E2ENP 908, aprovechando así la flexibilidad ofrecida por una estructura de documento basada en XML,
- -
- definición de una interfaz clara entre E2ENP 908 y las aplicaciones, debida al uso de identificadores explícitos que establecen unívocamente una correspondencia de una descripción dada de SDPng 912 con una fase dada del proceso de E2ENP 908,
- -
- capacidad de describir simultáneamente una jerarquía de contextos de calidad de servicio para varios flujos multimedia 206,
- -
- capacidad de negociar simultáneamente una jerarquía de contextos de calidad de servicio para varios flujos multimedia 206,
- -
- negociación por incrementos de dicha jerarquía de contextos de calidad de servicio para varios flujos multimedia 206 usando el concepto de sesiones y fases, y
- -
- el concepto de una multiplicidad de mediadores externos de E2ENP controlados por el núcleo de Servicio de Transcodificación es considerado como una innovación por esta invención.
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
(Tabla pasa a página
siguiente)
Claims (45)
1. Un método para intercambiar flujos de
información entre iguales finales (810, 811) en una red y para
soportar el End-to-End Negotiation
Protocol (E2ENP, 908), en el que la negociación de calidad de
servicio de extremo a extremo comprende los pasos de:
- -
- prenegociar (802) una pluralidad de contratos de calidad de servicio antes del establecimiento de flujos de información,
- -
- continuar la correlación (804) de calidad de servicio y la sincronización (805) en el tiempo de flujos múltiples o de grupos de flujos,
- -
- negociar (806) el uso de uno de los contratos prenegociados (802) de calidad de servicio antes o en el momento de establecimiento de flujo de información, y
- -
- renegociar (808) un contrato de calidad de servicio a partir de los contratos prenegociados (802), después de la detección de un cambio o violación de calidad de servicio,
caracterizado por
el uso del Session Description Protocol Next
Generation (SDPng, 912) para definir información de perfiles de
usuarios para ser usada como entrada para el E2ENP (908).
2. Un método según la reivindicación 1,
caracterizado por el uso de SDPng (912) para definir
información de capacidades de terminales para ser usada como
entrada para el E2ENP (908).
3. Un método según una cualquiera de las
reivindicaciones 1 y 2, caracterizado por una prenegociación
(802) de directrices de gestión de recursos entre iguales
diferentes.
4. Un método según una cualquiera de las
reivindicaciones 1 a 3, caracterizado por un concepto de
contratos (1108) sobrantes, y el concepto de bloqueo o desbloqueo
de estado basado respectivamente en la presencia o ausencia de
marcas sobrantes en la descripción de contrato (1108) fundamental
sobre la admisión de proveedor de red actual.
5. Un método según una cualquiera de las
reivindicaciones 1 a 4, caracterizado porque los contratos
sobrantes (1108) son negociados proactivamente de tal modo que
pueden ser usados en el caso de que ocurran situaciones de
transferencia y al menos uno de dichos contratos sobrantes (1108)
resulte aplicable.
6. Un método según una cualquiera de las
reivindicaciones 1 a 5, caracterizado por una señalización de
bloqueo de estado o desbloqueo de estado durante una renegociación
(808) siempre que ocurre un cambio de tecnología y/o un cambio de
proveedor respectivo de red causado por una situación de
transferencia.
7. Un método según una cualquiera de las
reivindicaciones 1 a 6, caracterizado por un establecimiento
de correspondencia detallada de E2ENP (908) sobre SIP (910) por
medio de superposición (piggybacking).
8. Un método según una cualquiera de las
reivindicaciones 1 a 7, caracterizado por un soporte de
señalización de negociación asistida por tercer abonado.
9. Un método según una cualquiera de las
reivindicaciones 1 a 8, caracterizado por un soporte de
señalización de escenario (200) de comunicación de uno con muchos y
escenarios (300, 400 y 500) de comunicación de muchos con
muchos.
10. Un método según una cualquiera de las
reivindicaciones 1 a 9, caracterizado por el concepto de
desplegar sesiones de señalización de E2ENP que aprovechan por
incrementos cualquier resultado de negociación de sesiones
anteriores de señalización de E2ENP, mediante lo cual cada sesión de
señalización de E2ENP corresponde a una de las diversas fases (802,
804, 805, 806, 808) de E2ENP.
11. Un método según la reivindicación 10,
caracterizado por el concepto de desplegar fases (micro y/o
macro) de E2ENP dispuestas lógicamente en una estructura en forma
de árbol que es construida por medio de varias cadenas de
referencia.
12. Un método según una cualquiera de las
reivindicaciones 10 y 11, caracterizado por el concepto de
alquilar subárboles para fases diferentes (micro y/o macro) de
E2ENP que están dispuestas en estructuras en forma de árbol.
13. Un método según una cualquiera de las
reivindicaciones 10 a 12, caracterizado por el concepto de
desplegar estados para igual la liberación retardada de subárboles
caducados para dichas fases (micro y/o macro) de E2ENP, subárboles
que son liberados entonces tan pronto como todas las conexiones
pendientes son cerradas.
14. Un método según una cualquiera de las
reivindicaciones 10 a 13, caracterizado por el concepto de
una negociación por incrementos para microfases.
15. Un método según una cualquiera de las
reivindicaciones 10 a 14, en el que es aplicado el RTP, en el que
una renegociación (808) es realizada durante el flujo de
información de los iguales (602a/b/c), que está basada en un estado
prenegociado que refiere a un contrato (1108) prenegociado de
calidad de servicio y a un conjunto prenegociado de capacidades,
caracterizado porque
- -
- un igual emisor (602a/b/c) puede decidir cambiar el formato del flujo (206) de información empleando otros codificadores-descodificadores negociados y señalizar este cambio usando señalización dentro de banda bien conocida a uno o más receptores sustituyendo el tipo de información útil de RTP en la cabecera de RTP por el tipo de información útil correspondiente a los nuevos codificadores- descodificadores siempre que permanezca dentro de un contrato (1108) acordado de calidad de servicio,
- -
- o dicho igual emisor (602a/b/c) puede usar explícitamente una señalización de E2ENP cuando ocurre una violación de calidad de servicio y/o un cambio de calidad de servicio, y/o restricciones de correlación (804) de calidad de servicio y sincronización (805) en el tiempo han de ser impuestas a través de flujos (206) de información múltiples.
16. Un método según una cualquiera de las
reivindicaciones 10 a 15, caracterizado por el concepto de
flujos NULOS para detener explícitamente flujos (206) de
información en el caso de degradaciones de anchura de banda para
mantener flexiblemente sesiones (102) de telecomunicación.
17. Un método según una cualquiera de las
reivindicaciones 10 a 16, caracterizado porque los iguales
(602a/b/c) negocian durante el paso de prenegociación (802)
conjuntos de contratos (1108) de calidad de servicio sobre una base
por flujo y/o sobre una base de asociación por flujo en el nivel
más fino de resolución, en el que las asociaciones de flujos de
información son haces de flujos (206) de información desde un igual
emisor (602a/b/c) a un igual receptor (602a/b/c).
18. Un método según una cualquiera de las
reivindicaciones 1 a 17, caracterizado porque los iguales
(602a/b/c) son informados sobre cambios configuraciones de
capacidades y/o calidad de servicio por medio de señalización de
E2ENP.
19. Un método según la reivindicaciones 18,
caracterizado porque información de configuración y calidad
alternativa prenegociada de un tipo dado de flujo (206) de
información ya puede estar disponible en un servidor para que los
clientes elijan.
20. Un método según una cualquiera de las
reivindicaciones 1 a 19, comprendiendo los pasos de descubrimiento
de protocolo, prenegociación (802), sincronización (805) en el
tiempo y correlación (804) de calidad de servicio de flujos
multimedia opcionales, negociación rápida que despliega un principio
de economía, renegociación (808) que despliega dicho principio de
economía y liberación de reserva de recursos.
21. Un método según la reivindicación 20, en el
que dichas seis fases pueden ser aplicadas opcionalmente varias
veces. Son concatenadas y ejecutadas continuamente o en momentos
diferentes, siguiendo de tal modo el orden indicado en la
reivindicación 32.
22. Un método según la reivindicación 21, en el
que la fase de sincronización (805) en el tiempo y correlación (804)
de calidad de servicio de flujos multimedia es opcional y necesaria
solo si un iniciador comunica con iguales múltiples (602a/b/c)
usando flujos (206) de información múltiples que necesitan ser
correlacionados y sincronizados, basado en directrices de usuarios
para ser impuestas en el lado de iniciador solamente.
23. Un método según la reivindicación 22, en el
que las fases de descubrimiento de protocolo y prenegociación (802)
son ejecutadas a priori, y los resultados pueden ser
aplicados entonces a sesiones (103) de señalización sucesivas
múltiples para establecer sesiones (102) de telecomunicación
sucesivas múltiples. Cada sesión (102) de telecomunicación es
iniciada con una fase opcional específica de sincronización (805)
en el tiempo y correlación (804) de calidad de servicio de flujos
multimedia.
24. Un método según la reivindicación 23, en el
que, si los resultados de la fase (805) de sincronización en el
tiempo y la fase (804) de correlación de calidad de servicio de
flujos multimedia son aplicables a sesiones (102) de
telecomunicación sucesivas múltiples, pueden ser iniciadas con una
fase (806) de negociación rápida específi-
ca.
ca.
25. Un método según una cualquiera de las
reivindicaciones 20 a 24, en el que el protocolo interacciona con
unidades de gestión de recursos locales durante las fases de
prenegociación (802), sincronización (805) en el tiempo y
correlación (804) de calidad de servicio de flujos múltiples,
negociación rápida (806), renegociación (808) y liberación de
recursos.
26. Un método según una cualquiera de las
reivindicaciones 20 a 25, en el que durante el tiempo de ejecución
de una sesión multimedia (102), en cualquier momento cualquier
componente de cualquier igual (602a/b/c) puede solicitar una
adaptación, activando así finalmente una fase de renegociación
(808).
27. Un método según una cualquiera de la
reivindicaciones 20 a 26, comprendiendo el paso de prenegociación
(802) del tipo de E2ENP (908) durante la fase de descubrimiento de
protocolo, obligando a los iguales a consultar un servidor de
directorio que puede ser implementado como un registrador de SIP, o
haciendo que los iguales anuncien tal información.
28. Un método según la reivindicación 27,
comprendiendo el paso de prenegociación (802) de capacidades
diferentes durante dicha fase de prenegociación (802).
29. Un método según una cualquiera de las
reivindicaciones 20 a 28, comprendiendo el paso de prenegociación
(802) de una lista completa de
codificadores-descodificadores durante dicha fase de
prenegociación (802).
30. Un método según una cualquiera de las
reivindicaciones 20 a 29, comprendiendo el paso de prenegociación
(802) de trayectos de adaptación a nivel de flujo de información
durante la fase de prenegociación (802).
31. Un método según una cualquiera de las
reivindicaciones 20 a 30, comprendiendo el paso de prenegociación
(802) de trayectos de adaptación al nivel de agregación de flujos
de información durante la fase de sincronización (805) en el tiempo
y la fase de correlación (804) de calidad de servicio de flujos
múltiples.
32. Un método según una cualquiera de las
reivindicaciones 20 a 31, caracterizado por los pasos de:
- -
- indexar capacidades y contratos (1108) prenegociados de calidad de servicio para acelerar la fase de negociación rápida (806), y
- -
- indexar capacidades y contratos (1108) prenegociados de calidad de servicio para acelerar la fase de renegociación (808).
33. Un método según una cualquiera de las
reivindicaciones 20 a 32, caracterizado por el paso de
manejar la instalación y/o la desinstalación de capacidades incluso
en el tiempo de ejecución intercambiando mensajes asíncronos entre
iguales (602a/b/c) para notificar tales sucesos.
34. Un método según una cualquiera de las
reivindicaciones 1 a 33, caracterizado porque la negociación
y el uso de identificadores de sesión es obtenido de tuplas de
identificadores de sesión por medio de dirección calculada (hash)
para limitar el tamaño de PDUs (Protocol Data Units) de E2ENP, en
el que las tuplas completas de identificadores de sesión,
comprendiendo cada una al menos una dirección calculada (hash), son
usadas en la primera PDU de cualquier fase dada de E2ENP o
concatenación de ellas.
35. Un método según una cualquiera de las
reivindicaciones 1 a 33 y 34, caracterizado porque el E2ENP
(908) abarca una negociación asistida por tercer abonado por medio
de un mediador (106a1).
36. Un método según una cualquiera de las
reivindicaciones 1 a 33, 34 y 35, caracterizado por
mecanismos de E2ENP para imponer la consistencia y evitar
interbloqueos.
37. Un método según una cualquiera de las
reivindicaciones 1 a 33 y 34 a 36, caracterizado porque el
E2ENP (908) es capaz de manejar escenarios (100) de comunicación de
uno con uno, escenarios (200) de comunicación de uno con muchos y
escenarios (300, 400) de comunicación de muchos con muchos.
38. Un método según una cualquiera de las
reivindicaciones 1 a 33 y 34 a 37, caracterizado por un
servicio de transcodificación usado para acoplar unidades de
transcodificación con servicios de directorio y proxies de SIP para
permitir que el ofertante (914) use una unidad de transcodificación
específica o una cadena de ellas siempre que sea necesario.
39. Un método según la reivindicación 38,
caracterizado porque el ofertante (914) tiene la posibilidad
de pedir soporte del operador de red o cualquier otro proveedor de
servicios para proporcionar servicio de transcodificación
gestionando la negociación de tercer abonado entre el ofertante
(914), los diversos transcodificadores en el medio y el contestador
(911) siempre que la sesión de E2ENP entre estos iguales finales
(914, 911) falla en el caso de que no se ha alcanzado un
acuerdo.
40. Un método según una cualquiera de las
reivindicaciones 38 y 39, caracterizado porque el servicio de
transcodificación orquesta el emparejamiento de nodos en la cadena
de iguales (911, 914), y tiene cuidado de que los recursos sean
reservados apropiadamente por medio del principio de economía de
E2ENP.
41. Un método según una cualquiera de las
reivindicaciones38 a 40, caracterizado por una cooperación de
servicios de transcodificación ofrecidos por proveedores diferentes
usando el E2ENP (908) para realizar negociación de tercer
abonado.
42. Un método según una cualquiera de las
reivindicaciones 34 a 41, caracterizado porque el manejo de
errores del E2ENP (908) es simétrico aplicando códigos de error
para señalizar estados de fallos, excepciones y errores tanto
internos como externos producidos en cualquiera de los iguales
(911, 914) implicados en la señalización de E2ENP afectada por el
E2ENP (908).
43. Un producto de programa de software de
ordenador, caracterizado porque implementa un método según
una cualquiera de las reivindicaciones 1 a 33 cuando se ejecuta en
un dispositivo de computación.
44. Un igual configurado para implementar un
método según una cualquiera de las reivindicaciones 1 a 33,
comprendiendo una unidad de coordinación que coordina las fases
diferentes del E2ENP (End-to-End-
Negotiation Protocol = Protocolo de Negociación de Extremo a
Extremo) y del proceso de gestión de recursos distribuidos,
caracterizado porque la unidad de coordinación ordena un
descubrimiento de protocolo y después activa y coordina las fases
de prenegociación (802), sincronización (805) en el tiempo y
correlación (804) de calidad de servicio de flujos múltiples
opcionales, negociación rápida con principio de economía,
renegociación (808) con principio de economía y liberación de
reserva de recursos.
45. Un igual según la reivindicación 44,
caracterizado por una unidad de protocolo de sesión que
permite que la unidad de coordinación lleve a cabo las diferentes
fases del E2ENP.
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| EP02001600 | 2002-01-23 | ||
| EP20016002 | 2002-01-23 | ||
| EP02001900A EP1331785B1 (en) | 2002-01-23 | 2002-01-28 | A method for enabling the negotiation of end-to-end QoS by using the end-to-end negotiation protocol (E2ENP) |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2236370T3 true ES2236370T3 (es) | 2005-07-16 |
Family
ID=27614615
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES02001900T Expired - Lifetime ES2236370T3 (es) | 2002-01-23 | 2002-01-28 | Metodo para permitir la negociacion de la calidad de servicio extremo a extremo por utilizacion del protocolo de negociacion extremo a extremo (e2enp). |
Country Status (8)
| Country | Link |
|---|---|
| US (1) | US7602723B2 (es) |
| EP (1) | EP1331785B1 (es) |
| JP (1) | JP4342948B2 (es) |
| CN (1) | CN1623308B (es) |
| AT (1) | ATE293863T1 (es) |
| DE (1) | DE60203779T2 (es) |
| ES (1) | ES2236370T3 (es) |
| WO (1) | WO2003063439A2 (es) |
Families Citing this family (199)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP1213895B1 (en) * | 2000-12-08 | 2007-09-05 | Sony Deutschland GmbH | High-level interface for QoS-based mobile multimedia applications |
| US8037188B2 (en) * | 2003-02-12 | 2011-10-11 | Qualcomm Incorporated | Soft handoff across different networks assisted by an end-to-end application protocol |
| US7912902B2 (en) * | 2003-02-13 | 2011-03-22 | Telcordia Licensing Company, Llc | Application service peering and aggregation |
| US7284054B2 (en) * | 2003-04-11 | 2007-10-16 | Sun Microsystems, Inc. | Systems, methods, and articles of manufacture for aligning service containers |
| US20050021840A1 (en) * | 2003-07-11 | 2005-01-27 | Nokia Corporation | Method and an apparatus for enhancing messaging |
| GB2406464B (en) | 2003-09-29 | 2006-07-05 | Siemens Ag | Network entity |
| US7644182B2 (en) * | 2004-03-11 | 2010-01-05 | Hewlett-Packard Development Company, L.P. | Reconfiguring a multicast tree |
| EP1610492B1 (en) * | 2004-06-21 | 2007-04-11 | Matsushita Electric Industrial Co., Ltd. | Adaptive and scalable qos architecture for multiple-bearer multicast/broadcast services |
| US7574510B2 (en) | 2004-07-30 | 2009-08-11 | Nokia Corporation | Systems, nodes, and methods for dynamic end-to-end session-enhancing services for transport-level-based connections |
| US20060072541A1 (en) * | 2004-09-28 | 2006-04-06 | Vivian Pecus | Network management system & method |
| US20060083242A1 (en) * | 2004-10-20 | 2006-04-20 | Nokia Corporation | Address modification in application servers |
| KR100561686B1 (ko) * | 2004-10-22 | 2006-03-15 | 에스케이 텔레콤주식회사 | 이동통신망에서의 화상통화 서비스 제공 방법 |
| US7369502B2 (en) * | 2004-12-02 | 2008-05-06 | Cisco Technology, Inc. | Intelligent provisioning of DSP channels for codec changes |
| KR100599174B1 (ko) * | 2004-12-16 | 2006-07-12 | 삼성전자주식회사 | 프로파일 정보를 이용한 서비스 제공방법 및 서비스제공시스템 |
| KR100688079B1 (ko) | 2004-12-17 | 2007-03-02 | 한국전자통신연구원 | 개인화 서비스를 위한 프로파일 정보 분류 및 처리 방법그리고 이를 이용한 개인화 서비스 제공 시스템 |
| DE102004063298B4 (de) * | 2004-12-29 | 2006-11-16 | Infineon Technologies Ag | Verfahren zum rechnergestützten Verwalten von Kommunikationsrechten zum Kommunizieren mittels mehrerer unterschiedlicher Kommunikationsmedien in einer Telekommunikations-Konferenz mit mehreren Telekommunikations-Einrichtungen |
| US8159999B2 (en) | 2005-01-25 | 2012-04-17 | Interdigital Technology Corporation | Peer-to-peer wireless communication system |
| US8077635B2 (en) | 2005-01-28 | 2011-12-13 | Cisco Technology, Inc. | Method and system for reserving facility resources for a conference |
| US20060218353A1 (en) * | 2005-03-11 | 2006-09-28 | Interdigital Technology Corporation | Method and apparatus for implementing path-based traffic stream admission control in a wireless mesh network |
| US7583662B1 (en) * | 2005-04-12 | 2009-09-01 | Tp Lab, Inc. | Voice virtual private network |
| MX2007013843A (es) * | 2005-05-03 | 2008-02-05 | Nokia Corp | Senalizacion de parametros de calidad de servicio para sesion multimedia. |
| EP1724984A1 (en) * | 2005-05-20 | 2006-11-22 | Alcatel | A terminal comprising a transceiver |
| CN100544388C (zh) * | 2005-07-01 | 2009-09-23 | 华为技术有限公司 | 一种控制业务多次前转套打的方法 |
| US7796589B2 (en) * | 2005-08-01 | 2010-09-14 | American Power Conversion Corporation | Communication protocol |
| US9660808B2 (en) * | 2005-08-01 | 2017-05-23 | Schneider Electric It Corporation | Communication protocol and method for authenticating a system |
| EP1758334A1 (en) * | 2005-08-26 | 2007-02-28 | Matsushita Electric Industrial Co., Ltd. | Establishment of media sessions with media adaptation |
| US7788698B2 (en) | 2005-08-31 | 2010-08-31 | Microsoft Corporation | Pre-negotiation and pre-caching media policy |
| US20070110034A1 (en) * | 2005-11-14 | 2007-05-17 | Broadcom Corporation, A California Corporation | Pathways analysis and control in packet and circuit switched communication networks |
| US8077707B2 (en) * | 2005-11-18 | 2011-12-13 | Sri International | Systems and methods for digital stream denting |
| US20070121532A1 (en) * | 2005-11-28 | 2007-05-31 | Nokia Corporation | Application specific encoding of content |
| WO2007074269A1 (fr) * | 2005-12-27 | 2007-07-05 | France Telecom | Procede de determination d'un mode d'encodage spatial de donnees audio |
| US8811369B2 (en) | 2006-01-11 | 2014-08-19 | Qualcomm Incorporated | Methods and apparatus for supporting multiple communications modes of operation |
| EP1992114B1 (en) | 2006-01-11 | 2012-11-07 | QUALCOMM Incorporated | Method and apparatus for sharing bandwidth between a wide area network and local area peer-to-peer network |
| CN101026812B (zh) * | 2006-02-24 | 2010-04-14 | 华为技术有限公司 | 在多方通信系统中获得会话参与用户会话能力的方法 |
| ES2382387T3 (es) | 2006-04-28 | 2012-06-07 | Motorola Mobility, Inc. | Actualización de capacidades durante una llamada |
| US7756134B2 (en) | 2006-05-02 | 2010-07-13 | Harris Corporation | Systems and methods for close queuing to support quality of service |
| AU2007249777A1 (en) * | 2006-05-11 | 2007-11-22 | Cfph, Llc | Methods and apparatus for electronic file use and management |
| US7894509B2 (en) | 2006-05-18 | 2011-02-22 | Harris Corporation | Method and system for functional redundancy based quality of service |
| EP1858210A1 (en) * | 2006-05-19 | 2007-11-21 | Whitestein Information Technology Group AG | Method and system for adaptive communication service access |
| US8705558B2 (en) | 2006-06-01 | 2014-04-22 | Cisco Technology, Inc. | Swapping bandwidth reservations |
| US9112872B2 (en) * | 2006-06-07 | 2015-08-18 | Broadcom Corporation | Method and system for communication of information by a handheld communication device in an ad-hoc network |
| US7856012B2 (en) * | 2006-06-16 | 2010-12-21 | Harris Corporation | System and methods for generic data transparent rules to support quality of service |
| US7990860B2 (en) * | 2006-06-16 | 2011-08-02 | Harris Corporation | Method and system for rule-based sequencing for QoS |
| US8064464B2 (en) | 2006-06-16 | 2011-11-22 | Harris Corporation | Method and system for inbound content-based QoS |
| US8516153B2 (en) | 2006-06-16 | 2013-08-20 | Harris Corporation | Method and system for network-independent QoS |
| US8730981B2 (en) | 2006-06-20 | 2014-05-20 | Harris Corporation | Method and system for compression based quality of service |
| ATE543298T1 (de) * | 2006-06-20 | 2012-02-15 | Alcatel Lucent | Wimax-netz, wimax-netzelement und eine verfahrensweise der behandlung der dienstleistungsqualität |
| US7769028B2 (en) | 2006-06-21 | 2010-08-03 | Harris Corporation | Systems and methods for adaptive throughput management for event-driven message-based data |
| US8077626B2 (en) * | 2006-07-14 | 2011-12-13 | Qualcomm Incorporated | Quality of service (QoS) aware establishment of communication sessions |
| CN101110972B (zh) * | 2006-07-18 | 2010-05-12 | 华为技术有限公司 | 分布式架构中sip消息分发和处理方法及其系统 |
| GB2440381B (en) * | 2006-07-27 | 2008-11-05 | Motorola Inc | An internet protocol multimedia subsystem network element and method of operation therefor |
| US8300653B2 (en) | 2006-07-31 | 2012-10-30 | Harris Corporation | Systems and methods for assured communications with quality of service |
| US7940653B2 (en) * | 2006-08-29 | 2011-05-10 | Verizon Data Services Llc | Audiovisual data transport protocol |
| US7817557B2 (en) * | 2006-08-29 | 2010-10-19 | Telesector Resources Group, Inc. | Method and system for buffering audio/video data |
| ATE471037T1 (de) * | 2006-09-05 | 2010-06-15 | Ericsson Telefon Ab L M | Ip-unicast-streaming-dienstablieferung |
| CN101087301B (zh) * | 2006-09-07 | 2010-05-12 | 华为技术有限公司 | 用户接入网络的方法和系统 |
| PL2064855T3 (pl) * | 2006-09-20 | 2016-08-31 | Orange | Sposób komunikacji między kilkoma terminalami |
| KR20080030899A (ko) * | 2006-10-02 | 2008-04-07 | 엘지전자 주식회사 | 맞춤형 방송 신호 수신기 및 방송 수신 방법 |
| US7840686B2 (en) * | 2006-10-25 | 2010-11-23 | Research In Motion Limited | Method and system for conducting communications over a network |
| CN101175293B (zh) * | 2006-10-30 | 2010-09-08 | 华为技术有限公司 | 采用push模式的呼叫方法 |
| GB2444096B (en) * | 2006-11-22 | 2009-10-14 | Adam Hill | Audio communications system using networking protocols |
| US8019326B2 (en) * | 2006-11-30 | 2011-09-13 | Motorola Mobility, Inc. | System and method for adaptive contextual communications |
| US8218458B2 (en) * | 2006-11-30 | 2012-07-10 | Cisco Systems, Inc. | Method and apparatus for voice conference monitoring |
| US8737349B2 (en) * | 2006-12-01 | 2014-05-27 | Sigram Schindler Beteiligungsgesellschaft Mbh | Handover process and information support for communication transfer between telecommunication networks |
| FR2909822B1 (fr) * | 2006-12-06 | 2010-04-30 | Radiotelephone Sfr | Procede et systeme de controle de l'etablissement de canaux de communication pour permettre une transmission d'informations multimedia. |
| JP2008153896A (ja) * | 2006-12-15 | 2008-07-03 | Nec Corp | コンテンツ配信システム、コンテンツ配信側ユーザー端末、コンテンツ被配信側ユーザー端末、コンテンツ配信システムの認証方法 |
| US8959239B2 (en) * | 2006-12-29 | 2015-02-17 | Telefonaktiebolaget L M Ericsson (Publ) | Method and apparatus for reporting streaming media quality |
| US7971132B2 (en) * | 2007-01-05 | 2011-06-28 | Dialogic Corporation | Universal multimedia engine and method for producing the same |
| CN101005511B (zh) * | 2007-01-17 | 2010-06-16 | 华为技术有限公司 | QoS资源预留方法、系统及会话建立和修改媒体的方法 |
| US20100053300A1 (en) * | 2007-02-02 | 2010-03-04 | Einarsson Torbjoern | Method And Arrangement For Video Telephony Quality Assessment |
| CN104093175B (zh) * | 2007-02-12 | 2019-06-04 | 西格拉姆申德勒有限公司 | 用于管理潜在的或实际的切换的方法和管理综合接入设备 |
| US8761009B2 (en) | 2007-02-12 | 2014-06-24 | Sigram Schindler Beteiligungsgesellschaft Mbh | Managed handover process |
| US9998956B2 (en) | 2007-02-12 | 2018-06-12 | Sigram Schindler Beteiligungsgesellschaft Mbh | Managed handover process |
| US9019830B2 (en) | 2007-05-15 | 2015-04-28 | Imagine Communications Corp. | Content-based routing of information content |
| EP2009892B1 (fr) * | 2007-06-29 | 2019-03-06 | Orange | Positionnement de locuteurs en conférence audio 3D |
| US8151005B2 (en) * | 2007-08-04 | 2012-04-03 | Broadcom Corporation | System and method for adjusting a level of compression for computing clients |
| US7929553B2 (en) * | 2007-08-10 | 2011-04-19 | Broadcom Corporation | System and method for adjusting compression for computing clients based on a latency level |
| US8856206B2 (en) * | 2007-08-28 | 2014-10-07 | International Business Machines Corporation | Maintaining message versions at nodes in a network |
| US8554865B2 (en) * | 2007-09-21 | 2013-10-08 | Honeywell International Inc. | System and method for remotely administering and synchronizing a clustered group of access control panels |
| CA2701123C (en) * | 2007-09-29 | 2014-05-20 | Research In Motion Limited | System and method of responding to a request in a network environment including ims |
| CA2703912C (en) | 2007-10-27 | 2016-09-27 | Research In Motion Limited | Content disposition system and method for processing message content in a distributed environment |
| MX2010005624A (es) | 2007-11-30 | 2010-06-01 | Samsung Electronics Co Ltd | Metodo y aparato de busqueda de dispositivos de retransmision de servicio de television de protocolo de internet y metodo y aparato de interaccion con dispositivos. |
| US8614996B1 (en) * | 2007-12-12 | 2013-12-24 | Sprint Spectrum L.P. | Predictive personality negotiation during session negotiation |
| EP2073467A1 (en) * | 2007-12-21 | 2009-06-24 | Nokia Siemens Networks Oy | Messaging mechanism |
| US7877453B2 (en) * | 2008-01-02 | 2011-01-25 | International Business Machines Corporation | System and method for optimizing data traffic in signaling stream of IP multimedia subsystem service |
| US9705935B2 (en) | 2008-01-14 | 2017-07-11 | Qualcomm Incorporated | Efficient interworking between circuit-switched and packet-switched multimedia services |
| CN101222502B (zh) * | 2008-01-25 | 2012-08-22 | 华为技术有限公司 | 媒体能力重协商的方法及装置 |
| MX2010008642A (es) * | 2008-02-05 | 2010-12-14 | Samsung Electronics Co Ltd | Metodo y aparato de transmision y recepcion de metadatos para aplicacion que proporciona servicio de television de protocolo de internet. |
| US20090207988A1 (en) * | 2008-02-15 | 2009-08-20 | Ericsson, Inc. | Method and system for telecommunication sessions using only initial signal messages |
| US8144187B2 (en) | 2008-03-14 | 2012-03-27 | Microsoft Corporation | Multiple video stream capability negotiation |
| EP2259591A4 (en) | 2008-03-28 | 2013-08-14 | Samsung Electronics Co Ltd | METHOD AND DEVICE FOR RECEIVING DATA FOR APPLICATIONS PROVIDING AN IP TELEVISION COMMUNICATIONS SERVICE |
| US8595501B2 (en) | 2008-05-09 | 2013-11-26 | Qualcomm Incorporated | Network helper for authentication between a token and verifiers |
| CN101282339B (zh) * | 2008-05-16 | 2012-12-12 | 华为技术有限公司 | 流媒体系统的能力协商方法、数据传输方法及相关设备 |
| US8902821B2 (en) * | 2008-06-12 | 2014-12-02 | Motorola Mobility Llc | Method and system for intermediate node quality of service negotiations |
| EP2303975A2 (en) * | 2008-07-17 | 2011-04-06 | Hercules Incorporated | Process for tailoring water-borne coating compositions |
| GB0813203D0 (en) * | 2008-07-18 | 2008-08-27 | Eldon Technology Ltd | Dynamic QoS in a network distributing audio visual content |
| KR101661210B1 (ko) | 2008-07-24 | 2016-09-29 | 삼성전자주식회사 | Ｉｐｔｖ 통신 서비스 수행 방법 및 장치 |
| US8005015B2 (en) * | 2008-07-28 | 2011-08-23 | Telefonaktiebolaget L M Ericsson (Publ) | Signaling framework for negotiating and executing composition of registries |
| US8700033B2 (en) * | 2008-08-22 | 2014-04-15 | International Business Machines Corporation | Dynamic access to radio networks |
| US8059615B1 (en) | 2008-09-08 | 2011-11-15 | Sprint Spectrum L.P. | Selective personality negotiation during session negotiation |
| US8185489B2 (en) * | 2008-10-16 | 2012-05-22 | At&T Intellectual Property, I, L.P. | Devices, methods, and computer-readable media for providing calendar-based communication system services |
| US8346233B2 (en) * | 2008-10-16 | 2013-01-01 | At&T Intellectual Property I, L.P. | Devices, methods, and computer-readable media for providing sevices based upon identification of decision makers and owners associated with communication services |
| US8615575B2 (en) * | 2008-10-16 | 2013-12-24 | At&T Intellectual Property I, L.P. | Devices, methods, and computer-readable media for providing quality of service optimization via policy-based rearrangements |
| US8320927B2 (en) * | 2008-10-16 | 2012-11-27 | At&T Intellectual Property I, L.P. | Devices, methods, and computer-readable media for providing broad quality of service optimization using policy-based selective quality degradation |
| US9015599B2 (en) * | 2008-10-16 | 2015-04-21 | At&T Intellectual Property I, L.P. | Devices, methods and computer-readable media for providing control of switching between media presentation screens |
| US8391882B2 (en) * | 2008-10-22 | 2013-03-05 | Qualcomm Incorporated | Method and system for interference management in a spectrum shared by WAN and femto cells |
| US8904276B2 (en) | 2008-11-17 | 2014-12-02 | At&T Intellectual Property I, L.P. | Partitioning of markup language documents |
| US8549198B2 (en) * | 2009-03-27 | 2013-10-01 | Schneider Electric It Corporation | Communication protocol |
| US9626681B2 (en) * | 2009-04-02 | 2017-04-18 | International Business Machiines Corporation | Negotiable information access in electronic social networks |
| US8972596B2 (en) * | 2009-04-28 | 2015-03-03 | The Boeing Company | System and method for effecting communications among devices in different domains employing different operating protocols |
| US9369510B2 (en) * | 2009-07-16 | 2016-06-14 | International Business Machines Corporation | Cost and resource utilization optimization in multiple data source transcoding |
| US8953038B2 (en) * | 2009-08-31 | 2015-02-10 | International Business Machines Corporation | Distributed video surveillance storage cost reduction using statistical multiplexing principle |
| FR2951898B1 (fr) * | 2009-10-27 | 2015-10-02 | Sagem Comm | Procede d'etablissement d'une session applicative, dispositif et notification correspondante |
| US8578020B2 (en) * | 2009-12-24 | 2013-11-05 | Empire Technology Development Llc | Dynamic mobile application quality-of-service monitoring and reporting |
| CN102195959B (zh) * | 2010-03-11 | 2015-08-12 | 中兴通讯股份有限公司 | Sip信令的xml数据的解析方法及装置 |
| US20110302287A1 (en) * | 2010-06-04 | 2011-12-08 | Muppirala Kishore Kumar | Quality of service control |
| US8943451B2 (en) * | 2010-06-23 | 2015-01-27 | Mentor Graphics Corporation | Hierarchical finite state machine generation for power state behavior in an electronic design |
| US20120005351A1 (en) * | 2010-07-02 | 2012-01-05 | Cisco Technology, Inc. | Method and apparatus for transmitting an application identifier across application elements |
| TW201215214A (en) * | 2010-07-06 | 2012-04-01 | Interdigital Patent Holdings | IP multimedia subsystem (IMS)-based pre-negotiation of video codec for video single radio video call continuity |
| US10250678B2 (en) * | 2010-07-07 | 2019-04-02 | Qualcomm Incorporated | Hybrid modes for peer discovery |
| FR2959088A1 (fr) * | 2010-09-14 | 2011-10-21 | France Telecom | Procede de traitement d'une demande d'etablissement d'une communication, systeme, equipement et programme d'ordinateur correspondants |
| US8805970B2 (en) * | 2010-10-25 | 2014-08-12 | International Business Machines Corporation | Automatic management of configuration parameters and parameter management engine |
| US9043797B2 (en) | 2010-10-26 | 2015-05-26 | Qualcomm Incorporated | Using pause on an electronic device to manage resources |
| US9191284B2 (en) | 2010-10-28 | 2015-11-17 | Avvasi Inc. | Methods and apparatus for providing a media stream quality signal |
| US10531516B2 (en) | 2010-11-05 | 2020-01-07 | Mark Cummings | Self organizing system to implement emerging topologies |
| US10687250B2 (en) | 2010-11-05 | 2020-06-16 | Mark Cummings | Mobile base station network |
| US10694402B2 (en) | 2010-11-05 | 2020-06-23 | Mark Cummings | Security orchestration and network immune system deployment framework |
| US10285094B2 (en) | 2010-11-05 | 2019-05-07 | Mark Cummings | Mobile base station network |
| WO2012060887A1 (en) | 2010-11-05 | 2012-05-10 | Mark Cummings | Integrated circuit design and operation |
| US9531774B2 (en) * | 2010-12-13 | 2016-12-27 | At&T Intellectual Property I, L.P. | Multicast distribution of incrementally enhanced content |
| KR20120083033A (ko) * | 2011-01-17 | 2012-07-25 | 삼성전자주식회사 | 무선통신시스템에서 응용 프로그램의 서비스 품질 서비스를 지원하기 위한 시스템 및 방법 |
| US8929561B2 (en) * | 2011-03-16 | 2015-01-06 | Apple Inc. | System and method for automated audio mix equalization and mix visualization |
| US8694587B2 (en) * | 2011-05-17 | 2014-04-08 | Damaka, Inc. | System and method for transferring a call bridge between communication devices |
| US8966095B2 (en) * | 2011-07-08 | 2015-02-24 | Avaya Inc. | Negotiate multi-stream continuous presence |
| WO2013044367A1 (en) * | 2011-09-29 | 2013-04-04 | Avvasi Inc. | Systems and methods for media service delivery |
| US9042449B2 (en) | 2011-09-29 | 2015-05-26 | Avvasi Inc. | Systems and methods for dynamic transcoding of indexed media file formats |
| US20130304934A1 (en) * | 2011-09-29 | 2013-11-14 | Avvasi Inc. | Methods and systems for controlling quality of a media session |
| US20140181266A1 (en) * | 2011-09-29 | 2014-06-26 | Avvasi Inc. | System, streaming media optimizer and methods for use therewith |
| US9118738B2 (en) | 2011-09-29 | 2015-08-25 | Avvasi Inc. | Systems and methods for controlling access to a media stream |
| US20130124708A1 (en) * | 2011-11-10 | 2013-05-16 | Electronics And Telecommunications Research Institute | Method and system for adaptive composite service path management |
| EP2640100B1 (en) * | 2012-03-11 | 2019-01-02 | Samsung Electronics Co., Ltd | Method and apparatus for providing an enhanced wi-fi display session in a wi-fi display network |
| US20140095695A1 (en) * | 2012-09-28 | 2014-04-03 | Ren Wang | Cloud aware computing distribution to improve performance and energy for mobile devices |
| US9021091B2 (en) * | 2012-10-15 | 2015-04-28 | International Business Machines Corporation | Transaction middleware based application level transaction instance tracking across a composite application |
| WO2014066975A1 (en) * | 2012-10-30 | 2014-05-08 | Avvasi Inc. | Methods and systems for controlling quality of a media session |
| JP2014090387A (ja) * | 2012-10-31 | 2014-05-15 | Ricoh Co Ltd | 情報処理装置、会議システムおよびプログラム |
| US9621480B2 (en) | 2013-03-04 | 2017-04-11 | Vigo Software Ltd | Data acquisition pertaining to connectivity of client applications of a service provider network |
| US9391749B2 (en) * | 2013-03-14 | 2016-07-12 | Ashwin Amanna, III | System and method for distributed data management in wireless networks |
| US9299049B2 (en) * | 2013-03-15 | 2016-03-29 | Sap Se | Contract-based process integration |
| AU2014253672B2 (en) | 2013-04-19 | 2019-05-30 | Commonwealth Scientific And Industrial Research Organisation | Checking undoability of an API-controlled computing system |
| US9591514B2 (en) * | 2013-04-19 | 2017-03-07 | Microsoft Technology Licensing, Llc | Optimization of over-the-top (OTT) services on carrier networks |
| US9563907B2 (en) | 2013-06-13 | 2017-02-07 | Vigo Software Ltd | Offer based provision of fee based network access |
| FR3007604A1 (fr) * | 2013-06-21 | 2014-12-26 | France Telecom | Procede d'acquisition d'un module de codage/decodage dans un reseau de telecommunications |
| US9282019B2 (en) | 2013-07-12 | 2016-03-08 | Nicira, Inc. | Tracing logical network packets through physical network |
| US9344349B2 (en) | 2013-07-12 | 2016-05-17 | Nicira, Inc. | Tracing network packets by a cluster of network controllers |
| FR3011704A1 (fr) * | 2013-10-07 | 2015-04-10 | Orange | Procede de mise en œuvre d'une session de communication entre une pluralite de terminaux |
| US9894117B2 (en) * | 2013-10-09 | 2018-02-13 | Cisco Technology, Inc. | File transfers for virtual conferences |
| US9986044B2 (en) * | 2013-10-21 | 2018-05-29 | Huawei Technologies Co., Ltd. | Multi-screen interaction method, devices, and system |
| US10637948B2 (en) | 2013-10-28 | 2020-04-28 | Saturn Licensing Llc | Content supply apparatus, content supply method, program, terminal apparatus, and content supply system |
| US10037554B2 (en) | 2013-10-30 | 2018-07-31 | Vigo Software Ltd | Aggregated billing for application-based network access and content consumption |
| CN103634299B (zh) * | 2013-11-14 | 2016-09-14 | 北京邮电大学 | 基于多连接的实时流媒体传输终端与方法 |
| US9173133B2 (en) * | 2013-12-26 | 2015-10-27 | Cellco Partnership | Mobile device with guaranteed QoS |
| US9462618B2 (en) * | 2014-03-06 | 2016-10-04 | Mediatek Inc. | Method of call setup time reduction for voice over LTE |
| DE102014006038A1 (de) | 2014-04-25 | 2015-10-29 | Unify Gmbh & Co. Kg | Verfahren und Vorrichtung zur Übermittlung und Adaption von Daten, Computerprogramm, Softwareprodukt und Digitales Speichermedium |
| FR3026595A1 (fr) * | 2014-09-25 | 2016-04-01 | Orange | Procede de negociation de codecs dans les reseaux ip |
| US10469342B2 (en) | 2014-10-10 | 2019-11-05 | Nicira, Inc. | Logical network traffic analysis |
| WO2016069009A1 (en) | 2014-10-31 | 2016-05-06 | Hewlett Packard Enterprise Development Lp | End to end quality of service in storage area networks |
| DE102015001622A1 (de) | 2015-02-09 | 2016-08-11 | Unify Gmbh & Co. Kg | Verfahren zur Übertragung von Daten in einem Multimedia-System, sowie Softwareprodukt und Vorrichtung zur Steuerung der Übertragung von Daten in einem Multimedia-System |
| US20160269493A1 (en) * | 2015-03-10 | 2016-09-15 | Qualcomm Incorporated | Methods and devices to establish services between service and connectivity strata |
| FR3034608A1 (fr) | 2015-03-31 | 2016-10-07 | Orange | Procede de priorisation de flux medias dans un reseau de communications |
| WO2016169008A1 (en) * | 2015-04-22 | 2016-10-27 | Qualcomm Incorporated | Correlating and combining of mdt and qoe metrics |
| KR102401477B1 (ko) * | 2015-11-24 | 2022-05-25 | 삼성전자주식회사 | 사용자 단말 장치 및 그 제어 방법 |
| KR102540459B1 (ko) | 2016-12-22 | 2023-06-05 | 한화비전 주식회사 | Rtp/rtsp 표준을 따르는 서버와 클라이언트에서 실시간 영상 스트리밍 방법 |
| US10200914B2 (en) | 2017-01-20 | 2019-02-05 | Microsoft Technology Licensing, Llc | Responsive quality of service management |
| US10805239B2 (en) | 2017-03-07 | 2020-10-13 | Nicira, Inc. | Visualization of path between logical network endpoints |
| EP4250868A3 (en) * | 2017-05-08 | 2023-11-01 | Huawei Technologies Co., Ltd. | Method and apparatus for moving between communications systems |
| US10608887B2 (en) | 2017-10-06 | 2020-03-31 | Nicira, Inc. | Using packet tracing tool to automatically execute packet capture operations |
| US10673962B2 (en) * | 2017-11-28 | 2020-06-02 | Sap Se | Service cross-consumption based on an open service broker application programming interface |
| US11477667B2 (en) | 2018-06-14 | 2022-10-18 | Mark Cummings | Using orchestrators for false positive detection and root cause analysis |
| WO2020005208A1 (en) * | 2018-06-26 | 2020-01-02 | Nokia Technologies Oy | Methods and apparatuses for enhanced data packet flow handling in communications systems |
| KR102436246B1 (ko) * | 2018-07-05 | 2022-08-25 | 삼성전자 주식회사 | 전자 장치에서 멀티미디어 서비스 제공 방법 및 장치 |
| CN112106326B (zh) * | 2018-09-28 | 2022-11-04 | 上海诺基亚贝尔股份有限公司 | 用于通信的主动资源预留 |
| CN111107589B (zh) * | 2018-11-12 | 2021-12-24 | 维沃移动通信有限公司 | 配置参数协商方法、终端设备、系统和存储介质 |
| US11689583B2 (en) | 2018-12-10 | 2023-06-27 | Telefonaktiebolaget Lm Ericsson (Publ) | Network node, entity and methods performed therein for handling a communication session in a communication network |
| CN111290983B (zh) | 2018-12-10 | 2023-05-16 | 澜至电子科技（成都）有限公司 | Usb传输设备及传输方法 |
| CN111277972B (zh) * | 2019-01-25 | 2022-12-23 | 维沃移动通信有限公司 | 一种直接通信接口QoS参数确定方法及相关设备 |
| US11109394B2 (en) * | 2019-07-30 | 2021-08-31 | Cypress Semiconductor Corporation | Methods, systems and devices for providing differentiated quality of service for wireless communication devices |
| US11283699B2 (en) | 2020-01-17 | 2022-03-22 | Vmware, Inc. | Practical overlay network latency measurement in datacenter |
| US11570090B2 (en) | 2020-07-29 | 2023-01-31 | Vmware, Inc. | Flow tracing operation in container cluster |
| US11196628B1 (en) | 2020-07-29 | 2021-12-07 | Vmware, Inc. | Monitoring container clusters |
| US11558426B2 (en) | 2020-07-29 | 2023-01-17 | Vmware, Inc. | Connection tracking for container cluster |
| US11777863B2 (en) * | 2020-12-21 | 2023-10-03 | Landis+ Gyr Innovations | Optimized route for time-critical traffic in mesh network |
| US11736436B2 (en) | 2020-12-31 | 2023-08-22 | Vmware, Inc. | Identifying routes with indirect addressing in a datacenter |
| US11336533B1 (en) | 2021-01-08 | 2022-05-17 | Vmware, Inc. | Network visualization of correlations between logical elements and associated physical elements |
| CN113301055A (zh) * | 2021-06-22 | 2021-08-24 | 展讯通信（上海）有限公司 | 提高ims会话系统兼容性的方法及装置、网络设备及移动设备 |
| US11687210B2 (en) | 2021-07-05 | 2023-06-27 | Vmware, Inc. | Criteria-based expansion of group nodes in a network topology visualization |
| US11711278B2 (en) | 2021-07-24 | 2023-07-25 | Vmware, Inc. | Visualization of flow trace operation across multiple sites |
| US11855862B2 (en) | 2021-09-17 | 2023-12-26 | Vmware, Inc. | Tagging packets for monitoring and analysis |
| CN114866300A (zh) * | 2022-04-22 | 2022-08-05 | 中国人民解放军国防科技大学 | 一种基于重放分析的网络协议软件状态变量识别方法 |
| WO2024011019A2 (en) * | 2022-07-08 | 2024-01-11 | Qualcomm Incorporated | Contextual quality of service for mobile devices |
Family Cites Families (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5574934A (en) * | 1993-11-24 | 1996-11-12 | Intel Corporation | Preemptive priority-based transmission of signals using virtual channels |
| US6678264B1 (en) * | 1999-06-30 | 2004-01-13 | Nortel Networks Limited | Establishing connections with a pre-specified quality of service across a communication network |
| US6707820B1 (en) * | 1999-12-16 | 2004-03-16 | Intervoice Limited Partnership | Virtual circuit network dynamic channel management |
| US7058973B1 (en) * | 2000-03-03 | 2006-06-06 | Symantec Corporation | Network address translation gateway for local area networks using local IP addresses and non-translatable port addresses |
| EP1158740B1 (en) * | 2000-05-24 | 2009-09-16 | Sony Deutschland GmbH | Quality of Service negotiation |
| EP1213895B1 (en) | 2000-12-08 | 2007-09-05 | Sony Deutschland GmbH | High-level interface for QoS-based mobile multimedia applications |
| EP1248431B1 (en) * | 2001-03-27 | 2007-10-31 | Sony Deutschland GmbH | Method for achieving end-to-end quality of service negotiation for distributed multimedia applications |
| US6957071B1 (en) * | 2001-07-18 | 2005-10-18 | Cisco Technology, Inc. | Method and system for managing wireless bandwidth resources |
-
2002
- 2002-01-28 ES ES02001900T patent/ES2236370T3/es not_active Expired - Lifetime
- 2002-01-28 EP EP02001900A patent/EP1331785B1/en not_active Expired - Lifetime
- 2002-01-28 AT AT02001900T patent/ATE293863T1/de not_active IP Right Cessation
- 2002-01-28 DE DE60203779T patent/DE60203779T2/de not_active Expired - Lifetime
-
2003
- 2003-01-14 CN CN038026651A patent/CN1623308B/zh not_active Expired - Fee Related
- 2003-01-14 WO PCT/EP2003/000309 patent/WO2003063439A2/en active Application Filing
- 2003-01-14 JP JP2003563172A patent/JP4342948B2/ja not_active Expired - Fee Related
-
2004
- 2004-07-21 US US10/896,319 patent/US7602723B2/en active Active
Also Published As
| Publication number | Publication date |
|---|---|
| ATE293863T1 (de) | 2005-05-15 |
| DE60203779T2 (de) | 2006-03-09 |
| JP2005527133A (ja) | 2005-09-08 |
| JP4342948B2 (ja) | 2009-10-14 |
| US7602723B2 (en) | 2009-10-13 |
| CN1623308B (zh) | 2011-11-16 |
| CN1623308A (zh) | 2005-06-01 |
| WO2003063439A2 (en) | 2003-07-31 |
| DE60203779D1 (de) | 2005-05-25 |
| EP1331785B1 (en) | 2005-04-20 |
| US20050157660A1 (en) | 2005-07-21 |
| EP1331785A1 (en) | 2003-07-30 |
| WO2003063439A3 (en) | 2003-12-24 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2236370T3 (es) | Metodo para permitir la negociacion de la calidad de servicio extremo a extremo por utilizacion del protocolo de negociacion extremo a extremo (e2enp). | |
| Piro et al. | Information centric services in smart cities | |
| CN104170337B (zh) | 一种用于促进无线网络之上的统一通信会话的方法和设备 | |
| Wolf et al. | Multimedia communication | |
| JP2004537187A (ja) | 分散型マルチメディアアプリケーションのためにエンドツーエンドのサービス品質交渉を提供する方法及び分散型マルチメディアアプリケーションのための分散型リソース管理メカニズムと協調したエンドツーエンドのサービス品質交渉を提供するｉｐに基づくプロトコル及びメカニズム | |
| CN102365850A (zh) | 用于提供相关服务级别的方法和装置 | |
| US8423652B2 (en) | Service templates for an IP multimedia subsystem | |
| ES2327969T3 (es) | Procedimiento de control del establecimiento de canales de comunicacion multimedia. | |
| Steinmetz et al. | Quality of Service: Where are we? | |
| Yoo | The dynamic internet: How technology, users, and businesses are transforming the network | |
| CN101453459A (zh) | 一种实现媒体协商的方法和装置 | |
| Hakiri et al. | Supporting SIP-based end-to-end data distribution service QoS in WANs | |
| Montpetit | The 2nd convergence: A technology viewpoint | |
| Delgrossi | Design of reservation protocols for multimedia communication | |
| CN117176704A (zh) | 用于网络即服务模式的方法、装置和计算机程序产品 | |
| Mohan et al. | A convergent framework for QoS-driven social media content delivery over mobile networks | |
| Li et al. | IPv6 Network Slicing: Offering New Experience for Industries | |
| Sanchez-Loro et al. | Proposal of a clean slate network architecture for ubiquitous services provisioning | |
| Simon et al. | DIPCS: An interprocess communication architecture for distributed multimedia systems | |
| Ge et al. | A method to efficiently integrate Internet Telephony call signaling with dynamic resource negotiation | |
| Van | INTERNET-OF-THINGS STREAMING OVER REALTIME TRANSPORT PROTOCOL | |
| CN101164302A (zh) | 通过接入域管理服务绑定的方法及其节点 | |
| Chou et al. | Web service for tele-communication | |
| Roy | Handbook on Networked Multipoint Multimedia Conferencing and Multistream Immersive Telepresence Using SIP: Scalable Distributed Applications and Media Control Over Internet | |
| CN114640729A (zh) | 一种通信方法、通信设备及计算机可读存储介质 |