Untitled record
Abstract
An apparatus (222) for managing the quality of service of a session, the apparatus (222) being configured to determine whether a media stream that requires the highest traffic class within a plurality of media streams is removed from the session, when the session established between two mobile terminals (110, 120) or a mobile terminal and a server is modified, through a communication link; characterized in that the apparatus (222) is further configured to maintain the existing traffic class for the remaining media flows for the session, if the media flow required by the highest traffic class is removed from the session.
Term
Term ended
Projected expiry passed 10 February 2024, 2.6 years ago.
- Priority
- Filed
- Published
- Projected expiry
- Today
18 claims: 6 independent, 12 dependent
- 1ES 2 349 583 T3 Reivindicaciones 1. Un aparato (222) para gestionar la calidad de servicio de una sesión, estando el aparato (222) configurado para determinar, si un flujo de medios que requiere la clase de tráfico más alta dentro de una pluralidad de flujos de medios se quita de la sesión, cuando se modifica la sesión establecida entre dos terminales móviles (110, 120) o un terminal móvil y un servidor, a través de un enlace de comunicación;que se caracteriza porque el aparato (222) está configurado además para mantener la clase de tráfico existente para los restantes flujos de medios para la sesión, si se quita de la sesión el flujo de medios que requiere la clase de tráfico más alta.
- 2Un aparato (222) para gestionar la calidad de servicio de una sesión, estando el aparato (222) configurado para determinar, si se añade un flujo unidireccional a la sesión que comprende un flujo bidireccional, cuando se establece o se modifica la sesión entre dos terminales móviles (110, 120) o entre un terminal móvil y un servidor, a través de un enlace de comunicación;que se caracteriza porque el aparato (222) está configurado además para asignar la clase de tráfico más alta, asignada a cualquiera de los flujos de medios de la sesión, a todos los flujos de medios de la sesión durante el tiempo de vida de la sesión, si se añade a la sesión el flujo unidireccional que comprende el flujo bidireccional.
- 3El aparato (222) de acuerdo con la reivindicación 1 ó 2, en el que el aparato (222) está configurado para generar un conjunto de información vinculante para vincular un nivel del subsistema multimedia del protocolo de Internet y un nivel de portador de servicio de radio general por paquetes de una sesión de un subsistema multimedia de protocolo de Internet.
- 4El aparato (222) de acuerdo con cualquier reivindicación precedente, en el que el terminal móvil (110, 120) comprende al menos uno de entre un equipo terminal y una función de adaptación de terminal configurada para realizar una transmisión de radio y las funciones relacionadas, y que comprende aplicaciones integrales para soportar servicios de telecomunicaciones.
- 5El aparato (222) de acuerdo con cualquier reivindicación precedente, en el que el aparato (222) está configurado para supervisar la gestión de las clases de calidad de servicio de la sesión.
- 6El aparato (222) de acuerdo con cualquier reivindicación precedente, en el que aparato (222) está configurado para tomar decisiones de política basándose en la sesión y en la información relacionada con los medios. ES 2 349 583 T3
- 7El aparato (222) de acuerdo con cualquier reivindicación precedente, en el que el aparato (222) está configurado para intercambiar información de decisión con una puerta (210) de enlace.
- 8El aparato (222) de acuerdo con la reivindicación 2 o cualquier reivindicación que dependa de la reivindicación 2, en el que el flujo unidireccional comprende un flujo de vídeo unidireccional.
- 9El aparato (222) de acuerdo con la reivindicación 2 o cualquier reivindicación que dependa de la reivindicación 2, en el que el flujo bidireccional comprende un flujo de audio bidireccional.
- 10Un procedimiento para gestionar la calidad de servicio de una sesión, que comprende:la determinación de, si se quita de la sesión un flujo de medios que requiere la clase de tráfico más alta dentro de una pluralidad de flujos de medios, cuando se modifica la sesión establecida entre dos terminales móviles o entre terminal móvil y un servidor, a través de un enlace de comunicación;que se caracteriza porque el procedimiento comprende: el mantenimiento de la clase de tráfico existente para los flujos de medios restantes para la sesión, si se quita de la sesión el flujo de medios que requiere la clase de tráfico más alta.
- 11Un procedimiento para gestionar la calidad de servicio de una sesión, que comprende:la determinación de, si se añade un flujo unidireccional a la sesión que comprende un flujo bidireccional, cuando la sesión se establece o se modifica entre dos terminales móviles o entre terminal móvil y un servidor, a través de un enlace de comunicación;que se caracteriza porque el procedimiento comprende: la aplicación de la clase de clase de tráfico más alta, asignada a cualquiera de las corrientes de medios de la sesión, a todas las corrientes de medios de la sesión durante el tiempo de vida de la sesión, si se añade el flujo unidireccional a la sesión que comprende el flujo bidireccional.
- 12El procedimiento de acuerdo con la reivindicación 10 ú 11, que comprende la ES 2 349 583 T3 generación de un conjunto de información vinculante para vincular un nivel de subsistema multimedia de protocolo de Internet y un nivel de portador de servicio de radio general por paquetes de una sesión de un subsistema multimedia de protocolo de Internet.
- 13El procedimiento de acuerdo con cualquiera de las reivindicaciones 10 a 12, que comprende la supervisión de la gestión de las clases de calidad de servicio de la sesión.
- 14El procedimiento de acuerdo con cualquiera de las reivindicaciones 10 a 13, que comprende la toma de al menos una decisión de política basándose en la sesión y en la información relacionada con los medios.
- 15El procedimiento de acuerdo con cualquiera de las reivindicaciones 10 a 14, que comprende el intercambio de la información de decisión con una puerta de enlace.
- 16El procedimiento de acuerdo con la reivindicación 11 o cualquier reivindicación que dependa de la reivindicación 11, en el que el flujo unidireccional comprende un flujo de vídeo unidireccional.
- 17El procedimiento de acuerdo con la reivindicación 11 o cualquier reivindicación que dependa de la reivindicación 11, en el que flujo bidireccional comprende un flujo de audio bidireccional.
- 18Un producto de programa de ordenador que comprende medios de código de programa almacenados en un medio legible por ordenador, los medios de código de programa están adaptados para realizar cualquiera de las reivindicaciones 10 a 17 cuando el programa se ejecuta en un procesador. ES 2 349 583 T3 S2 LL Ul Ul □ ES 2 349 583 T3 CONTEXTO PDP X-£10 ES 2 349 583 T3 CONTEXTO PDP ES 2 349 583 T3 4/1 0 4rt 0 w Ό Ό Φ Φ □ □ 0 0 C C C c •n. υ J w u ,ο. 3 0 V ζ II Π Ό co β % σ Ν JZ £ Ο zj ú ni I— ΐ 8 E E X X o O TD Φ D cd Ό S O Τ3 Φ * Ο α -ο ES 2 349 583 T3 video χ max.auth.QcS = flujo continuo de datos
Independent claims18
96 paragraphs in 17 sections, as filed
ES 2 349 583 T3
Description
BACKGROUND OF THE INVENTION
TECHNICAL FIELD
The present invention relates to mobile networks that include comprehensive quality of service (QoS) management, and more particularly, it relates to the authorization and dynamic management of QoS classes of a session (connection between users or mobile terminals, or between a mobile terminal and a server) comprising a plurality of different types of media streams within mobile networks.
BACKGROUND OF THE INVENTION
Mobile modem networks, such as those networks standardized by 3GPP (Third Generation Partnership Project) specifications that include all GSM (Global System for Mobile Communications) and third generation GSM networks, are seamless integration of networks. digital cellular and personal communication systems to provide telecommunication services including, for example, mobile data network services and IP multimedia services.
Each 3GPP system may include a core network and radio access network infrastructure that uses General Packet Radio Service (GPRS) and Evolutionary Enhanced Data Rates (EDGE) technologies or that support Radio Access. Universal Terrestrial (UTRA) operable in both Frequency Division Duplex (FDD) and Time Division Duplex (TDD). The core network CN can be logically divided into circuit-switched (CD) and packet-switched (PS) domains with CN entities arranged for user traffic and related signaling, and an IP Multimedia Subsystem (IMS) with network entities core (CN) arranged for IP multimedia services. Some CN entities such as the Own Subscriber Server (HSS), the Own Client Position Register (HLR), the Authentication Center (AuC), the Visitor Position Register (VLR) and the Equipment Identification Register ( EIR) can be common to the PS and CS domains, while other CN entities such as the Mobile Switching Center (MSC) and the Gateway MSC are specific to the CS domain to manage the circuit-switched services to / from the mobile stations, and the Support Node (GGSN) Gateway GPRS (general packet radio service) and Service GSN (SGSN) are specific to the PS domain for
ES 2 349 583 T3 manage packet transmission to / from mobile stations.
For IP multimedia services, functional IMS entities, such as the Call Session Control Function (CSCF) may be arranged to handle CDCF-related procedures, including setting the context of PDP (Packet Data Protocol, for example , IP) for IMS-related signaling, registration, and other procedures for IMS sessions. The CSCF can act as a CSCF Proxy (PCSCF) to serve as a first point of contact for a user equipment (UE) (for example, the device that allows a user to access network services, such as a mobile terminal within of the IP multimedia subsystem (IMS), the Serving CSCF (S-CSCF) to manage session states in the network or an Interrogative CSCF (I-CDCF) to serve as a point of contact within an operator network for all IMS connections destined for either a subscriber of that network operator or a roaming subscriber in a given service area. See Technical Specification (TS) 3GPP 23.002, V5.9.0 (December 2002) “Network Architecture”; TS 3GPP 23.101, V4.0.0 (April 202) "General UMTS Architecture"; and TS 3GPP 23.110, V4.0.0 (April 2001) "UMTS Access Stratum: Services and Functions"; and Technical Specification (TS) 3GPP 23.228, V6.0.1 (January 2003) “IP Multimedia Subsystem (IMS)”. All 3GPP (GSM / 3G) specifications can be found and downloaded from the 3GPP server at ftp://ftp.3gpp.org/especs. Furthermore, the mechanisms for creating, maintaining and updating 3GPP specifications (including different versions of a given 3GPP specification with new or modified functionality) can also be found in 3GPP Technical Specification (TS) 21.900 V5.0.1 (September 2002) " Technical Specification Group Working Methods. "
A Policy Decision Function (PDF) has been standardized to monitor the management of the Quality of Service (QoS) classes of a session comprising a plurality of media streams, to make strategy decisions based on the session and on the media-related information, including the maximum authorized class of traffic for a given media stream between two users (mobile terminals) or between a mobile terminal and a server, and to then exchange the decision information with the GGSM through a Go interface, as shown in TS 3GPP 29.207 V.5.2.0 (September 2002) “Policy Control over Go Interface”, Version 5 ; in 3GPP TS 23.207 V.5.6.0 (December 2002) "EndTo-End Quality of Service (QoS) Concept and Architecture", Version 5 and in TS 3GPP 29.208 V.5.2.0 (December 2002)) " End-To-End Quality of Service (QoS) signaling flows ”, Version 5. This PDF can be integrated into the P-CSFC as shown in the
ES 2 349 583 T3 3GPP specification, Version 5 (December 2002), or alternatively, it can be implemented in a separate network element that is separate from the P-CSCF as outlined in TS 3GPP, Version 6 (January 2003).
In general, when a session (connection) is established between user equipment (UE) (for example, mobile terminals), or between a mobile terminal and a server, and the session is modified (for example, two-way audio and one-way video to one-way video only), the PDF changes the traffic class (from conversational to real-time data stream). This is because the session as established between user equipments (UE), for example mobile terminals, or between a mobile terminal and a server, comprises a two-way audio stream and a unidirectional video stream. The two-way audio stream is used for real-time conversation, and consequently, requires a low-delay real-time traffic class, for example, the CONVERSATIONAL traffic class. One-way video stream is used to transfer moving video images in one direction only. Such one-way real-time video stream tolerates longer transmission delays and delay variations (aka, jitters) as the sender does not expect to receive a response. As a result, real-time one-way flow typically uses a STREAMING traffic class in practice. If the session is modified, that is, if one of the two-way audio stream or one-way video stream ends and is removed from the session, consequently it is necessary for the PDF to change the traffic class for bearer resources. For example, if the two-way audio stream with the CONVERSATIONAL traffic class is removed from the session, the one-way video stream, with the STREAMING traffic class as the default requirement, now has the "highest traffic class" of the session. Consequently, the PDF changes (eg, downgrading) the traffic class for the bearer of the session from CONVERSATIONAL traffic class to STREAMING traffic class.
However, some parameters, such as the size of the buffer in the receiving terminal, are different in these traffic classes, changing the traffic class with the inherent change of the transmission delay will cause the buffer underflow in the terminal. or receiving server, thus reducing the quality of the connection perceived by the end user.
Another significant problem can occur when a one-way stream (eg video) is added to an existing session that comprises a two-way stream (eg audio). The designated traffic class request of the one-way video stream is typically
ES 2 349 583 T3 real time data. The traffic class for the two-way session is conversational. If the media streams have a time relationship (for example a verbal explanation of the video stream in the audio stream), the difference in traffic classes will cause a difference in the transmission delays (due to the different lengths of the buffers). in the receivers to compensate for the different delays and fluctuations of the delay in the transmission), thus reducing the quality of the connection perceived by the end user.
Consequently, There is a need for solutions that can be applicable to all systems in which a session (connection between users or mobile terminals or between a mobile terminal or a server) can comprise a plurality of types of media streams and which are linked to the media authorization and better management of the quality of service (QoS) classes of a session (connection between users or mobile terminals or between a mobile terminal or a server) comprising a plurality of different types of media streams within mobile networks so that when media streams are modified (new ones are started and existing ones are removed) during the session, the traffic class of a session is defined by the higher class requirements traffic of media streams belonging to the same session to eliminate transmission delay differences of media streams belonging to the same session, and therefore improve the quality of the connection perceived by the end user.
The invention is defined in the independent claims. Certain specific embodiments are defined in the dependent claims.
Some aspects of the invention may be directed to solutions for dynamic media authorization and better management of the quality of service (QoS) classes of a session (connection between users or mobile terminals or between a mobile terminal or a server) that comprises a plurality of different types of media streams within mobile networks such that when one or more media streams are modified (new ones are started or existing ones are deleted) during the session, the traffic class of a session is defined by the higher traffic class requirements of the media streams belonging to the same session to eliminate the difference in transmission delays of the media streams belonging to the same session , and therefore improve the quality of the connection perceived by the end user.
According to one aspect of the invention, a Policy Decision Function is provided
ES 2 349 583 T3 (PDF) in a mobile network to determine a maximum allowed traffic class for a given media flow of a session between two mobile terminals or between a mobile terminal and a server. Said PDF is configured to determine whether one or more media streams, requiring the highest traffic class within a plurality of different types of media streams, have been removed from the session, when a session is established and is being modified between two mobile terminals or between a mobile terminal and a server, through a communication link; and maintaining the traffic class used for the remaining media streams for the session, if one or more media streams requiring the highest traffic class are removed from the session.
According to another aspect of the invention, a Policy Decision Function (PDF) is configured to determine if a unidirectional flow is added to the session comprising a bidirectional flow, when a session is established or modified between two mobile terminals or between a mobile terminal and a server, through a communication link; and to apply to all media streams in the session the highest traffic class, assigned to any of the media streams in the session, for the lifetime of the session, if the unidirectional stream is added to the session that it comprises bidirectional flow in a mobile network to determine a maximum allowed class of traffic for a given media flow of a session between two mobile terminals or between a mobile terminal and a server, through a communication link.
According to yet another aspect of the invention, a computer-readable medium is provided with instructions that, when executed by a mobile network, perform a procedure of determining a maximum authorized traffic class for a given media stream of a session. between two mobile terminals or between a mobile terminal and a server, including: determining whether a unidirectional flow is added to a session comprising a bidirectional flow, when establishing or modifying the session between two mobile terminals or between a mobile terminal and a server through a communication link; and apply the highest traffic class, assigned to any of the media streams in the session, to all media streams in the session for the lifetime of the session if the unidirectional stream is added to the session comprising the bidirectional flow.
The present invention is more specifically described, by way of example only, in the following paragraphs by reference to the accompanying drawings.
ES 2 349 583 T3
BRIEF DESCRIPTION OF THE DRAWINGS
A more complete appreciation of the present invention and many of its advantages will be readily apparent as it is better understood by reference to the following detailed description when considered in conjunction with the accompanying drawings in which like reference symbols indicate the same or similar components, where:
Figure 1 illustrates an example network system architecture for providing telecommunication services including IP multimedia services in accordance with the 3GPP Specification, Version 5.
Figure 2 illustrates an example interface architecture of IMS functional entities in accordance with the 3GPP Specification, Version 5.
Figure 3 illustrates an example interface architecture of IMS functional entities in accordance with one embodiment of the present invention.
Figure 4 illustrates an example work session between two user equipment (mobile terminals), or between a mobile terminal and a server, using new mapping rules, when the media streams are unidirectional and have the same address, according to with an embodiment of the present invention.
Figure 5 illustrates an example work session between two user equipment (mobile terminals) or between a mobile terminal and a server, using new mapping rules, when the media streams are unidirectional and do not have the same address, accordingly with an embodiment of the present invention.
Figure 6 illustrates an example work session between two user equipment (mobile terminals) or between a mobile terminal and a server, using new mapping rules, when one media stream is bidirectional and the other unidirectional, according to a embodiment of the present invention.
Figure 7 illustrates an example work session between two user equipment (mobile terminals) or between a mobile terminal and a server, using new mapping rules, when a media stream is bidirectional (different from audio / video) and the other
ES 2 349 583 T3 unidirectional (audio / video), according to an embodiment of the present invention.
BEST WAY TO CARRY OUT THE INVENTION
The present invention is applicable for use with all types of networks that support a plurality of different types of media streams, including second and third generations of GSM (Global System for Mobile Communications) networks, transit networks such as the Internet, Intranets, local area networks (LAN) and ATM-based transit networks and terminal networks such as public switched telephone networks (PSTN), ISDN, IP / LAN networks, X.25 and Land Mobile Networks (PLMN) and interconnected systems and related protocols used for voice, message, data and image transfers between systems on said mobile networks. However, for simplicity, the discussion will focus primarily on a simple multimedia network that includes IP Multimedia Subsystem (IMS) entities to provide IP multimedia services.
Attention is now focused on the drawings and particularly in Figure 1, an example network system architecture is illustrated for providing telecommunication systems including IP multimedia services in accordance with the 3GPP Specification, Version 5, As shown in Figure 1, the network system architecture 100 may broadly include a home user equipment (UE) 110, an end user equipment (UE) 120 or vice versa and a communication link 130 arranged to connect the user equipment (UE) 110/120 and can be expanded over a single network or over different networks, such as, for example, a Network Public Land Mobile (PLMN) 132, one or more transit networks 134 and a terminal network 136. The user equipment (UE) 110/120 can be a device or user terminal to allow the user to access network services, including, for example, a remote server or a mobile terminal for GSM as defined in TS 3GPP , V 5.0.0 (December 2001), Version 5.
Each UE 110/120 may include, for example, a mobile termination (MT) 112, a terminal equipment (TE) 114, and a terminal adaptation function (TAF) 116 arranged to perform radio transmission and related functions, and it may contain comprehensive applications to support telecommunication services.
The transit network 134 may include, but is not limited to, the Internet, Intranet, a local area network (LAN), or an ATM-based transit network. Terminal network 136 may include, but is not limited to, a public switched telephone network (PSTN), an ISDN, a
ES 2 349 583 T3 IP / LAN network, X.25 or other Public Land Mobile Network (PLMN).
Figure 2 illustrates an example interface architecture of IMS functional entities in mobile networks in accordance with the 3GPP Specification, Version 5. As shown in figure 2, the GPRS Support Node (GGSN) 210 (radio service Gateway General Packet) and Proxy Call Session Control Function (P-CSCF) 220 represent network entities that are part of the core network. The GGSN can be used to manage the transmission of packets to / from the UE 110/120 (eg mobile stations). The P-CSCF 220 can be used to serve as the first point of contact for a given UE 110/120 and to provide session management services and procedures related to the CSCF, including the establishment of the PDP context (Packet Data Protocol, for eg IP) for IP Multimedia Subsystem (IMS) related signaling, registration and other procedures for IMS sessions.
According to the 3GPP Specification, Version 5 (December 2002), A Policy Decision Function (PDF) 222 is integrated within the P-CSCF 220 to monitor an IMS session when the UE 110 sends or receives a SIP (Session Initiation Protocol) message containing SDP (Session Description Protocol) signaling. Session) to negotiate the parameters for an IMS session and make policy decisions based on the IMS session and media related information obtained from the P-CSCF 220, including the decisions that refer to the maximum class of authorized traffic for a given media flow between two users (e.g. mobile terminals) or between a mobile terminal and a server and then exchanging the information of the decisions with the GGSN 210 by means of a Go interface, as shown in TS 3GPP 29.207 V.5.2.0 (December 2002) “Policy Control over Go Interface”, Version 5. Furthermore, only one simple IMS session is allowed for each PDP context (Packet Data Protocol, eg IP). Alternatively, PDF can also be implemented in a separate network element that is separate from P-CSCF 220, as described in the 3GPP Specification, Version 6 (January 2003).
As previously discussed and highlighted in the 3GPP Specification, Version 5, PDF 222 can be used to generate a set of binding information (especially an authorization token to link the IMS level and the GPRS bearer level of an IMS session, and send the binding information to the GGSN 210 through the user equipment (UE) 110. The binding information associates a PDP context (
ES 2 349 583 T3
Packet Data, for example IP) with one or more media components (IP streams) of an IMS session, and is used by the GGSN 210 to request the Service-based local policy (SBLP) information from PDF 222. Said binding information typically includes:
(1) an authorization token sent by the P-CSCF 220 to the UE 110 during SIP / SDP signaling and (2) one or more flow identifiers (which can be added by the UE 110 after receiving the binding information from the P-CSCF / PDF) used by UE 110, GGSN 210, and PDS 222 to uniquely identify the IP media stream (s) associated with the SIP session.
Upon receipt of said binding information, the GGSN 210 is then used to look up the PDF address of the binding information set (from the authorization token) received from the UE 110, identify the correct PDF, and verify that the PDP context operations requested by the UE 110 obey the preceding negotiation at the IMS level.
In the GGSN 210, the Policy Enforcement Point (PEP) 212 is a logical entity that communicates with the PDF regarding the control of the local Service-based policy (SBLP). For simplicity, GGSN 210 is assumed to contain PEP 212 implicitly unless stated otherwise. The GGSN 210 sends requests and receives decisions from PDF 222. The GGSN 210 can temporarily store the PDF decision policy decision data that can later be used for a local policy decision allowing the GGSN 210 to make a policy control decision regarding QoS authorization. (QoS) for PDP context modifications without requiring any additional interaction with PDF 222. The PEP functionalities for the SBLP in the GGSN are described in TS 3GPP 29.207 V.5.2.0 (December 2002) “Policy Control over Go Interface”, Version 5 and therefore do not need to be repeated here.
Both the UE 110 and the GGSN 210 may also include mechanisms to manage comprehensive IP quality of service (QoS) functions and related signaling flows as described in TS 3GPP 23.207 V.5.6.0 (December 2002) "End -To-End Quality of Service (QoS) Concept and Architecture ”, Version 5 and in TS 3GPP 29.208 V.5.2.0 (December 2002)“ End-To-End Quality of Service (QoS) signaling flows ”, Version 5, which are incorporated herein by reference. For example, the UE 110 may include a client application (not
ES 2 349 583 T3 shown), an IP service bearer manager (BS) (not shown), a translation / mapping function (not shown) and optionally a UMTS bearer service manager (BS) (not shown) . Likewise, the GGSN 210 may also include an IP BS manager (not shown), a translation / mapping function (not shown), and optionally a UMTS bearer service (BS) manager (not shown). BS IP managers commonly use standard IP mechanisms to manage IP bearer services. The translation / mapping functions provide interoperation between the mechanisms and parameters used within the UMTS bearer services and those used within the IP bearer services and interact with the IP BS managers. BS UMTS managers use standard UMTS mechanisms to manage UMTS (Universal Mobile Telecommunications System) bearer services and QoS management functions for UMTS bearer services.
In general, a session is established (connection) between user equipment (UE) (eg mobile terminals capable of transmitting and receiving IP multimedia streams) or between a mobile terminal and a server. The session as established between user equipments (UE) (eg mobile terminals) or between a mobile terminal and a server, comprises, for example, a two-way audio stream and a unidirectional video stream. The two-way audio stream is used for real-time conversation and consequently requires a low-delay real-time traffic class, for example, the CONVERSATIONAL traffic class. Unidirectional video streaming is used to transfer moving video images in one direction only. Such a one-way real-time video stream tolerates higher transmission delays and delay variations (aka, jitter) since the sender does not expect to send any response. As a result, real-time one-way flow typically uses a STREAMING traffic class in practice. The CONVERSATIONAL class of traffic is characterized by a short maximum delay in transmission and a small delay variation to minimize the delay experienced by callers (for example, mobile terminals or between a mobile terminal and a server), while the class of STREAMING traffic is characterized by a higher maximum transmission delay and a higher delay variation since it is not a real-time two-way communication with real-time responses. As a result, the CONVERSATIONAL traffic class is known as a "higher traffic class" relative to the STREAMING traffic class, which is known as a "lower traffic class".
According to TS 3GPP 23.107, other traffic classes may be required in the example session, such as the INTERACTIVE traffic class and the BACKGROUND traffic class. By
For example, the INTERACTIVE traffic class can be characterized by tolerating even longer transmission delays and jitters than the STREAMING traffic class and, consequently, is a "lower traffic class" than the STREAMING traffic class. The BACKGROUND traffic class can be characterized by tolerating even longer transmission delays and jitters and as a result is an even lower traffic class than the INTERACTIVE traffic class. However, the audio and video streams of the example session may be carried by the same bearer (for example, a PDP context in the network system) or they may have a temporal relationship to each other, meaning that the bearer resources of the entire session has a CONVERSATIONAL traffic class according to the "highest traffic class" of the session.
After a while, the session may be modified, that is, the users of the communication (e.g. mobile terminals or a mobile terminal and a server) may wish to terminate, for example, the two-way audio stream of the session, while they maintain the one-way video stream of the session. Consequently, it is necessary for the PDF to change the traffic class for the session bearer resources. For example, if the session is modified and the two-way audio stream with the CONVERSATIONAL traffic class is removed from the session, the one-way video stream with the STREAMING traffic class as the default requirement, now has the "highest traffic class discharge »of the session. Consequently, the PDF changes (for example, updates to the above classification) the traffic class for the session bearer, from the CONVERSATIONAL traffic class to the STREAMING traffic class.
However, when the session is modified (for example, from two-way audio and one-way video to one-way video only) and the PDF 222 changes the traffic class (for example, from CONVERSATIONAL to STREAMING), some parameters, such as the size of the buffer in the receiving terminal, they are different in these QoS classes, the change of the traffic class with the inherent change of the transmission delay may cause underflows in the receiving terminal, thus reducing the quality of the connection perceived by the end user.
For example, when a session (connection) is established, the mobile terminals, or a mobile terminal and a server, initiate communication with a two-way voice stream. At this point, the PDF 222 assigns to the voice stream the maximum allowed traffic class which is equal to CONVERSATIONAL. After some time, one of the mobile terminals, or one of a mobile terminal and a server, decides to add a video stream to the communication and the video stream is unidirectional. At this point the PDF 222 checks the current set of flows
ES 2 349 583 T3 IP multimedia belonging to the session (connection) and decides to assign to the video stream a maximum authorized traffic class equal to "CONVERSATIONAL". This class is selected since there is an existing bi-directional media stream that is authorized for the "CONVERSATIONAL" traffic class. As a result, the mobile terminal or the server that receives both the voice and video streams is capable of obtaining audio-video synchronization. After some time, the two mobile terminals, or the mobile terminal and the server, decide to stop the voice communication, but continue the one-way video transmission. At this point, the PDF 222 checks the current set of IP media streams belonging to the session (only the one-way video stream remains in the communication) and decides to change its maximum allowed traffic class to "STREAMING". This occurs because the unidirectional media stream always achieves a maximum allowed class of traffic equal to "STREAMING".
However, if the maximum allowed traffic class is changed from "CONVERSATIONAL" to "STREAMING" this change would cause problems for the mobile terminal or the server receiving the video stream. In particular, the change could cause a renegotiation in the PDP context, where not only the traffic class is different but also the transfer delay is different. As a result, a longer transfer delay could lead to frequent and repeated buffer underflows at the receiving mobile terminal and a non-continuous medium, resulting in lower quality perceived by the end user. This is because the buffer of the mobile terminal or the server is dimensioned according to the transfer delay of the "CONVERSATIONAL" traffic class, not according to the "STREAMING" traffic class.
Another significant problem could also occur when adding a one-way stream (for example, video) to an existing session that comprises a two-way stream (for example, audio). The request for the designated traffic class of the one-way video stream is typically streaming. The two-way session traffic class is conversational. If the media streams have a time relationship (for example, a verbal explanation of the video stream in the audio stream) the difference in the traffic classes will cause a difference in the transmission delays (due to the different lengths of the buffers). in the receivers to compensate for the different delays and fluctuations of the delay in the transmission, thus reducing the quality of the connection perceived by the end user.
For example, a session (connection) starts with a one-way flow. At this point, the PDF
ES 2 349 583 T3
222 assigns "STREAMING" as the maximum authorized class of traffic. After some time, a two-way voice call stream is added to the communication. At this point, the PDF 222 assigns the voice stream a maximum allowed traffic class equal to "CONVERSATIONAL". The PDF 222 also rechecks the maximum allowed traffic class of the first existing stream and updates it to "CONVERSATIONAL". In some cases, the update may cause a PDP context negotiation for the IP media stream, particularly when the IP media streams are related and require synchronization. However, in most cases no update is needed.
Turning now to Figure 3, an example interface architecture of IMS functional entities is illustrated in accordance with one embodiment of the present invention. The interface architecture, as shown in Figure 3, advantageously maintains the traffic class used for the session, for example, for the rest of the IP multimedia streams, when the media streams that require the traffic class highest are removed from the session to avoid the problem produced when the traffic class is changed and to apply the highest traffic class (real time, for example CONVERSATIONAL, STREAMING) mapped to any of the media streams in the session, for all media streams (real-time) in the session for the lifetime of the session to avoid the problem that occurs when a media stream is added to an existing session.
As shown in Figure 3, an algorithm 310 may be implemented as part of PDF 222, provided that PDF 222 is integrated within P-CSCF 220 or a network entity remains separate from P-CSCF 220. In algorithm 310, the elimination of one or more multimedia streams during the lifetime of a session (connection) can be defined so that the previously assigned maximum authorized traffic class is not updated to the previous classification and, likewise, can be defined the addition of media streams to assign the maximum traffic class of the streams to all streams (real time) in the session (connection). The use of said algorithm 310 can be applied to all systems, including all future multimedia networks, in which a session can comprise a plurality of different types of media streams and can comply, for example, with TS 3GPP 23.207 V. 5.6.0 (December 2002) “End-To-End Quality of Service (QoS) Concept and Architecture” Version 5 and with TS 3GPP 29.208 V.5.2.0 (December 2002) “End-To-End Quality of Service (QoS) signaling flows ”, Version 5.
Synchronization of real-time media streams can also be improved by eliminating the
ES 2 349 583 T3 differentiates the transition delays of media streams belonging to the same session, thus improving the quality perceived by the end user. There can be a downside in that the QoS classes assigned to all media streams in the session may be higher than required, thus reducing the overall capacity of the network and also potentially causing higher connection costs for the end user.
For example the user / UE initiates a session or extends a session with lower class traffic flows, with one or more unidirectional data streams. At this point, PDF 222 assigns "STREAMING" as the maximum allowed class of traffic to the relevant media streams. Later during the lifetime of the session, the user / UE initiates a two-way flow (eg, audio) within the same session. At this point, the PDF 222 assigns the maximum allowed traffic class equal to "CONVERSATIONAL" to the audio stream. The PDF 222 also rechecks the maximum allowed traffic class for existing streams. Updating the existing media streams to the value of the traffic class of the new bi-directional stream may be unnecessary, since the unidirectional streams have started before the bi-directional conversational stream and consequently may not be temporally related to the two-way conversational flow. Upgrading is undesirable as the QoS classes assigned to some media streams in the session may be higher than required, thus reducing overall network capacity and also potentially causing higher connection costs for the end user.
However, updating can be avoided if the one-way flows were started first, and are considered independent of a subsequent two-way flow or flows, for example, there is no temporal relationship. Then no synchronization is needed, for example the traffic class will remain "STREAMING", when adding a two-way conversational media stream. (In an IMS system, flows with different traffic / QoS classes will then use separate PDP contexts). Alternatively, if a two-way conversational flow was started first and a one-way data stream is added later to the session, the one-way data stream flow is considered to be dependent on the two-way, for example there is a temporal relationship between them. Therefore synchronization is required, for example the traffic class of the one-way stream will be set to the same value as the traffic class of the two-way stream, ie "CONVERSATIONAL" (via PDF 222). (In an IMS system, flows with different traffic classes / QoS can then use a common PDP context or PDP contexts
ES 2 349 583 T3 separated.
The PDF 222, as shown in Figure 3, can be configured to determine the maximum allowed class of traffic for a given media stream from a connection between two mobile terminals or between a mobile terminal and a server. An example algorithm 310 in PDF 222 may include the following:
if a maximum allowed class of traffic has been assigned to a given stream X, then adding or removing one or more media streams during the lifetime of a session (connection) does not result in any change to the maximum allowed class of traffic previously assigned for flow X.
Mapping rules may also be required in accordance with TS 3GPP 29.208 V.5.6.0 (December 2002) “End-To-End Quality of Service (QoS) signaling flows”, Version 5, so that a maximum class can be assigned QoS authorization appropriate to a data stream service. Such mapping rules can be used by the PDF 222, as shown in Figure 3, when initiating or modifying a session to obtain the appropriate maximum authorized QoS per media component. However, it is necessary to define a suitable mapping in order to ensure that future services are not restricted and that abuse, fraud or inefficiency can be avoided. In general, a data stream service can be characterized by the direction of the data flow - whether or not it is unidirectional - and by the type of audio or video medium. In this way, all media components that belong to a session can be analyzed. For example, if all the audio and video components are unidirectional and have the same direction, the application can be considered as a data stream and therefore the QoS limits for the data stream can be applied as the maximum allowed QoS.
Now referring to Figures 4-7, examples of the mapping rules are shown. For example, Figure 4 illustrates an example work session between two user equipments (mobile terminals), when the media streams are unidirectional and have the same direction, in accordance with one embodiment of the present invention. Figure 5 illustrates an example of a work session between two user equipments (mobile terminals) when the media flows are unidirectional and do not have the same direction, according to an embodiment of the present invention. Figure 6 illustrates a work session between two user equipment (mobile terminals), when one media flow is bidirectional and the other
ES 2 349 583 T3 unidirectional, according to an embodiment of the present invention. Finally, figure 7 illustrates an example work session between two user equipment (mobile terminals), when one media stream is bidirectional (different from audio / video) and the other unidirectional (audio / video), according to an embodiment of the present invention.
Specifically, in Figure 4, when the media streams (audio and video) are unidirectional and have the same direction, the authorization of the media stream will be "STREAMING". In Figure 5, when the media streams are unidirectional and do not have the same direction, the media stream authorization will be "CONVERSATIONAL". In Figure 6, when one media stream is bidirectional and the other unidirectional, the media stream authorization will be "CONVERSATIONAL". In Figure 7, when one media stream is bidirectional (different from audio / video) and the other unidirectional (audio / video), the media stream authorization will be "CONVERSATIONAL" for application and "STREAMING" for video.
Mapping rules can be extended to ensure proper allocation of the maximum authorized QoS class according to the requested service. The rules that define the mapping of SDP parameters for the maximum classes allowed for QoS are extended, for example, to allow mapping for the streaming class in the case of one-way media components of type "audio" or "video" that have the same direction. Below are examples of the mapping rules that can be used by the UE 110 (for example, a mobile terminal or a server) and the PDF 222, as shown in Figure 2 and Figure 3. In particular, Table 1 illustrates example mapping rules for the derivation of maximum authorized data rates and maximum authorized class of service (QoS) per media component in PDF 222. Such example mapping rules can be packaged into software modules stored or supplied on a computer readable medium or alternatively can be supplied via internet download or integrated into PDF 222 as shown in Figure 2 and Figure 3 . Corresponding to Table 1, Table 2 illustrates example mapping rules for the derivation of the maximum allowed bandwidth and the maximum allowed class of traffic per media component in the UE 110 (for example, a mobile terminal or a server). Likewise, said mapping rules can also be packaged in a software module stored or arranged on a computer-readable medium or, alternatively, they can be provided via internet download or integrated within the UE 110 (for example, a mobile terminal or a server ), as shown in Figure 2 and Figure 3.
ES 2 349 583 T3
TABLE 1: Rules for the derivation of the Maximum Authorized Data Rates and the Maximum Authorized QoS Class by media component in the PDF.
<td>IP QoS Authorized Parameter per Media Component</td><td>5 Derivation from SDP parameters</td>
ES 2 349 583 T3
<td>Maximum allowed data rate for DL (Max_DR_DL) and UL (Max_DR_DL) per media component (see note 1)</td><td>IF a = recvonly THEN IF <SDP direction> = mobile originated THEN Direction: = downlink; ELSE / * mobile finished * / Direction: = uplink; ENDIF; ELSE IF a = sendonly THEN IF <SDP direction> = mobile originaed THEN Direction: = uplink; ELSE / * mobile finished * / Direction: = downlink; ENDIF; ELSE Direction: = both ENDIF; ENDIF; IF b = AS: <bandwith> is present THEN IF Direction = sownlink THEN IF <transport> = "RTP / AVP" THEN Max_DR_DL: = 0.025 * <bandwith>; Max_DR_UL: = 1.025 * <bandwith>; ELSE Max_DR_DL: = 0; Max_DR_UL: = <bandwith>; ENDIF; ELSE IF Direction = uplink THEN IF <transport> = "RTP / AVP" THEN Max_DR_UL: = 1.025 * <bandwith>; Max_DR_DL: = 0.025 * <bandwith>; ELSE Max DR UL: = <bandwith>;</td>
ES 2 349 583 T3
<td></td><td>Max_DR_DL: = 0; ENDIF; ELSE / * Address = both * / Max_DR_UL: = 1.025 * <bandwith>; Max_DR_DL: = 1.025 * <bandwith>; ENDIF, ENDIF; ELSE BW: = as set by the operator; IF Direction = downlink THEN Max_DR_UL: = 0; Max_DR_DL: = bw; ELSE IF Direction = uplink THEN Max_DR_UL: = bw; Max_DR_DL: = 0; ELSE / * Address = both * / Max_DR_UL: = bw; Max_DR_DL: = bw; ENDIF; ENDIF; ENDIF</td>
ES 2 349 583 T3
<td>Maximum allowed QoS class [MaxClass] per media component (See Note 2, x and y)</td><td>IF (all media components of media type "audio" or "video" for the session are unidirectional an have the same direction) THEN MaxClassDerivation: = B; / * streaming * / ELSE MaxClassDerivation: = A; / * conversational * / ENDIF; CASE <media> OF "Audio": MaxClass: = MaxClassDerivation; "Video": MaxClass: = MaxClassDerivation; "Application": MaxClass: = A; "Data": MaxClass: = B; ^ Interactive with priority 3 * / "Control": MaxClass: = E; / * Interactive with priority 1 * / /*New kind*/ OTHERWISE: MaxClass: = F; /*Environment*/ END;</td>
<td colspan="2">NOTE 1: For an RTP media component the DL / UL Maximum Data Rates are the sum of the DL / UL Maximum Allowable Data Rates for the RTP media streams and the associated DL / UL IP RTCP streams. UL. NOTE 2: The Maximum Allowed QoS Class for an IP RTCP stream is the same as for the corresponding RTP media stream. Note x: When an audio or video stream is removed from a session, the remaining media streams in the session will maintain the originally assigned maximum authorized QoS classes. Note y: When adding an audio or video stream to a session, the PDF will derive the maximum authorized QoS class taking into account the media streams already existing within the session.</td>
The PDF 222 will store, for each session in progress, the Authorized IP QoS parameters per media component. When the GGSN 210 requests the authorized UMTS QoS parameters for an activated / modified PDP Context carrying one or more media components, the PDF 222 can use the mapping rules, such as those shown, for example, in table 1 of so that it calculates the authorized parameters of the IP QoS.
ES 2 349 583 T3
TABLE 2: Rules for the derivation of the UL / DL of Maximum Authorized Bandwidth and the Maximum Authorized Class of Traffic by media component in the EU.
Authorized parameter of
<td>UMTS QoS</td><td>Derivation from SDP Parameters</td>
[MaxClass] by media component
<td>Bandwidth</td><td>/ * Check if IMS context (the criteria for this check is up to the manufacturers of the</td>
<td>Maximum</td><td>UE * / IF IMS context THEN</td>
Authorized from
DL (Max_BW_DL) and
<td>from UL</td><td>IF a = recvonly THEN</td>
<td>(Max_BW_UL)</td><td>IF <SDP direction> = mobile originated THEN</td>
<td>by component</td><td>Direction: = downlink;</td>
<td>media</td><td>ELSE / * mobile finished * / Direction: = upnlink; ENDIF; ELSE; IF a = sendonly THEN IF <SDP direction> = mobile originated THEN Direction: = upnlink; ELSE / * mobile finished * / Direction: = downlink; ENDIF; ELSE / * sendrecv or no direction attribute * / Direction: = both; ENDIF; ENDIF; IF b = AS: <bandwith> is present THEN IF Direction = downlink THEN IF <transport> = "RTP / AVP" THEN</td>
ES 2 349 583 T3
<td></td><td>Max_BW_UL: = 0.025 * <bandwidth>; Max_BW_DL: = 1.025 * <bandwidth>; ELSE Max_BW_UL: = 0; Max_BW_DL: = <bandwidth>; ENDIF; ELSE IF Direction = uplink THEN IF <transport> = "RTP / AVP" THEN Max_BW_UL: = 1.025 * <bandwidth>; Max_BW_DL: = 0.025 * <bandwidth>; ELSE Max_BW_UL: = <bandwidth>; Max_BW_DL: = 0; ENDIF; ELSE / * Address = both * / Max_BW_UL: = 1.025 * <bandwidth>; Max_BW_DL: = 1.025 * <bandwidth>; ENDIF; ENDIF; ELSE bw: = as set by the UE manufacturer; IF Direction = downlink THEN Max_BW_UL: = 0; Max_BW_DL: = bw; ELSE IF Direction = uplink THEN Max_BW_UL: = bw; Max_BW_DL: = 0; ELSE / * Address = both * / Max_BW_UL: = bw; Max_BW_DL: = bw; ENDIF; ENDIF; ENDIF;</td>
ES 2 349 583 T3
<td></td><td>ELSE No authorization is done; ENDIF;</td>
<td>Maximum Authorized Traffic Class [MaxTrafficClass] per media component (see NOTE x and y)</td><td>/ * Check if IMS context (the criteria for this check is up to the EU manufacturers) * / IF IMS context THEN IF (all media components of media type “audio” or “video” for the session are unidirectional and have the same direction) THEN MaxService: = streaming; ELSE MaxService: = conversational; ENDIF CASE <media> OF "Audio" MaxTrafficClass: = MaxService; "Video" MaxTrafficClass: = MaxService; "Application" MaxTrafficClass: = conversational; "Data" MaxTrafficClass: = interactive with priority 3; "Control" MaxTrafficClass: = interactive with priority 1; / * New media type * / OTHERWISE: MaxTrafficClass: = background; END ELSE No authorization is done; ENDIF</td>
NOTE x: When an audio or video stream is taken out of a session, the remaining media streams will maintain the originally assigned maximum authorized traffic class.
NOTE y: When adding an audio or video stream to a session, the UE will derive the maximum allowed class of traffic taking into account the media streams already existing within the session.
The UE 110 will store, for each ongoing session, the authorized UMTS QoS parameters per media component. Before the activation or modification of the PDP context, the UE 110 can check that the Guaranteed Bit rate requested from the UL / DL (if the
ES 2 349 583 T3
Traffic is Conversational or Streaming) or that the maximum requested UL / DL bit rate (if the Traffic Class is Interactive or Background) does not exceed the maximum authorized UL / DL bandwidth per PDP context (calculated according to the mapping rules). Furthermore, the UL 110 can check that the traffic class of the requested UMTS QoS parameters does not exceed the maximum allowed traffic class per PDP context (calculated according to the mapping rules).
As described above, the network interface architecture according to an embodiment of the present invention provides solutions for dynamic media authorization and better management of the QoS classes of a session (connection between users or mobile terminals, or between a mobile terminal and a server) comprising a plurality of different types of media streams within mobile networks such that, when one or more media streams within a plurality of different types of media streams are modified (new ones are started or existing ones are removed) during a session, the traffic class of a session is defined by the highest required traffic class by media streams belonging to the same session, to eliminate the difference in transmission delays of media streams belonging to the same session and therefore improve the quality of the connection perceived by the end user. The synchronization of the real-time media streams can also be improved by eliminating the difference in transmission delays of the media streams belonging to the same session, thus improving the quality perceived by the end user.
Although what is considered an example of embodiments of the present invention has been illustrated and described, those skilled in the art will understand that different changes and modifications can be made and that different elements can be substituted for their equivalents without departing from the true scope of the present invention. invention. Furthermore, many modifications can be made to adapt a particular situation to the teachings of the present invention without departing from the core scope of the present invention. Therefore, it is intended that the present invention is not limited to the particular embodiment presented as the best mode contemplated for practicing the present invention, but that the present invention includes all embodiments that fall within the scope of the appended claims.
Contents17
25 members in 11 offices
Priority claims3
| Document | Office | Kind | Date |
|---|---|---|---|
| 44579903 | United States of America | P | |
| 44579903 | United States of America | P | |
| US20030445799P | – | – | – |
Members25
| Document | Office | Kind | |
|---|---|---|---|
| WO2004071105A2 | World Intellectual Property Organization (WIPO) | A2 | |
| US2004190453A1 | United States of America | A1 | |
| US6888821B2 | United States of America | B2 | |
| WO2004071105A3 | World Intellectual Property Organization (WIPO) | A3 | |
| KR20050105208A | Republic of Korea | A | |
| EP1611719A2 | European Patent Office (EPO) | A2 | |
| RU2005128300A | Russian Federation | A | |
| CN1748394A | China | A | |
| RU2298290C2 | Russian Federation | C2 | |
| KR100742755B1 | Republic of Korea | B1 | |
| JP2007527634A | Japan | A | |
| EP1611719A4 | European Patent Office (EPO) | A4 | |
| EP1611719B1 | European Patent Office (EPO) | B1 | |
| AT410868T | Austria | T | |
| ATE410868T1 | Austria | T1 | |
| DE602004016980D1 | Germany | D1 | |
| CN100454912C | China | C | |
| EP2048836A1 | European Patent Office (EPO) | A1 | |
| JP4261579B2 | Japan | B2 | |
| EP2048836B1 | European Patent Office (EPO) | B1 | |
| AT483305T | Austria | T | |
| ATE483305T1 | Austria | T1 | |
| PT2048836E | Portugal | E | |
| DE602004029406D1 | Germany | D1 | |
| ES2349583T3This record | Spain | T3 |
Numbers
- Publication
- 2349583
- Publication, DOCDB
- 2349583
- Publication, EPODOC
- ES2349583T
- Application
- 8163110
- Application, DOCDB
- 08163110
- Application, EPODOC
- ES20080163110T
Titles2
- Spanish
- AUTORIZACION DINAMICA DE MEDIOS EN REDES MOVILES.
- English
- DYNAMIC AUTHORIZATION OF MEDIA IN MOBILE NETWORKS.
Classification
- IPC, 2
- H04L12 66
- H04L12 56