WO2010142902A1 - Optimisation d'une communication de données, notamment pour des applications de transmission en continu de données vidéo - Google Patents

Optimisation d'une communication de données, notamment pour des applications de transmission en continu de données vidéo Download PDF

Info

Publication number
WO2010142902A1
WO2010142902A1 PCT/FR2010/051127 FR2010051127W WO2010142902A1 WO 2010142902 A1 WO2010142902 A1 WO 2010142902A1 FR 2010051127 W FR2010051127 W FR 2010051127W WO 2010142902 A1 WO2010142902 A1 WO 2010142902A1
Authority
WO
WIPO (PCT)
Prior art keywords
network
service
request
messages
parameters
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.)
Ceased
Application number
PCT/FR2010/051127
Other languages
English (en)
Inventor
Alaeddine Abdallah
Djamal-Eddine Meddour
Toufik Ahmed
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
France Telecom SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by France Telecom SA filed Critical France Telecom SA
Publication of WO2010142902A1 publication Critical patent/WO2010142902A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • 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
    • 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
    • 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/75—Media network packet handling
    • H04L65/752—Media network packet handling adapting media to network capabilities
    • 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
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W84/00—Network topologies
    • H04W84/02—Hierarchically pre-organised networks, e.g. paging networks, cellular networks, WLAN [Wireless Local Area Network] or WLL [Wireless Local Loop]
    • H04W84/04—Large scale networks; Deep hierarchical networks
    • H04W84/042—Public Land Mobile systems, e.g. cellular systems
    • H04W84/047—Public Land Mobile systems, e.g. cellular systems using dedicated repeater stations

Definitions

  • the present invention relates to the field of data communications, in particular video data, in streaming (or streaming) applications, preferably in broadband wireless networks such as networks according to the IEEE 802 standard 16, still called “WMAX® networks"
  • the IEEE 802 standard 16 offers a broadband wireless technique that achieves high data throughput by ensuring a satisfactory quality of service (or "QoS") in IEEE data communication management.
  • QoS quality of service
  • 802 16 the OSI ("Open Systems Interconnection") MAC (Medium Access Control) layers play an important role in addressing quality of service aspects, as will be discussed later.
  • This technique fits well to real-time multimedia applications such as the streaming of video data (or "video streaming”)
  • video streaming Such applications have many constraints to ensure proper operation of the streaming, especially in terms of minimum bandwidth required, maximum time allowed, maximum jitter tolerated
  • the present invention improves the situation It proposes for this purpose a method of managing a data communication via a network, preferably for a continuous data transmission service, in which messages for service flow management (or "service flow" in word
  • the method according to the invention comprises in particular a step of collecting service flow management messages, a step of interpreting at least one of said messages. collected to estimate current constraints of the network, and a decision step to adapt or not parameters of said service according to these constraints
  • the aforesaid service comprises a streaming video data transmission (or "video streaming” in Anglo-Saxon terms).
  • the constraints of the network then comprise at least one data rate constraint and the service parameters advantageously comprise at least one data transmission constraint.
  • the interpreting message belongs to a group comprising a response to a request to add a dynamic service flow, a modification request a service flow, a response to a request to modify a service flow
  • the steps of the method are preferably repetitiously repeated during the above-mentioned continuous data transmission service.
  • the implementation of the present invention then makes it possible to ensure that the streaming service continues, if necessary with a quality of service.
  • the network may advantageously be a broadband wireless network operating according to the IEEE 802 standard 16
  • the invention can then take advantage of the fact that certain layers of the OSI model of the IEEE 802 standard 16 in particular, such as MAC (for "Medium Access Control") layers generate messages relating to a dynamic service flow in progress. Such messages can be for example the creation, modification or interruption of a service flow
  • MAC for "Medium Access Control”
  • a software layer "transverse" adaptation retrieves these messages, interprets and possibly imposes new video parameters to an application layer (higher level than the MAC layers in the OSI model), in order to possibly modify the quality of the video signal, for example to satisfy network constraints and in particular a current state of network congestion
  • an application such as, for example, a continuous transmission of video data (or "video streaming") adapts the transmission rate of these data according to the state of the network. and in particular changes in state of the network, and this, thanks to the contribution of the transverse layer in the sense of the invention
  • the main objective a mechanism using such a transverse layer, adaptation is to drive video transmission applications from the application layer of the OSI model, using the messages returned by a lower layer of the standard IEEE 802 16 (typically one of the MAC layers as will be seen later)
  • These three layers MAC, transverse and applicative then exchange information to make quick adaptations including video parameters
  • the management means may comprise a module executing the computer program in the sense of the invention and are then arranged to collect the service flow management messages, interpret at least one of the collected messages to further estimate current constraints of the network, and decide whether to adapt the service parameters according to the current constraints of the network
  • FIG. 6 schematically shows a terminal SS2 comprising means for receiving the messages REC and the aforementioned management means (which may typically comprise a processor PROC and a working memory MEM).
  • the aforementioned management means which may typically comprise a processor PROC and a working memory MEM.
  • FIG. 1 representing a network comprising base stations BS1 and BS2 ("BS" for “Base Station”), the network here being a WIMAX® network according to the 802 standard 16
  • BS base stations
  • SS for "Subsc ⁇ ber Station”
  • it can further provide relay stations RS1 and RS2 ("RS" for "Relay Station"), in the coverage area of the base station BS1 to cover respectively the terminal SS2 and another terminal SS3
  • a terminal SSl is, meanwhile, directly in the coverage area of the base station BS1
  • the terminal SS4, in video transmission traffic with the terminal SS2 is moreover directly in the coverage area of the base station BS2, like an SS5 terminal.
  • RS3 which covers here the terminal SS6
  • the base stations BS1 and BS2 are interconnected by
  • the video transmission traffic is streaming (or “video streaming”) and is for example here in “peer to peer” mode (English or “P2P”)
  • video streaming or “video streaming”
  • peer to peer” mode English or "P2P”
  • Many types There may be video traffic between the different nodes of the network.
  • the video transmission traffic intervenes between two SS2 and SS4 stations covered (globally directly or via relay stations) by two base stations BS 1 and BS 2
  • the invention can be implemented both in the case of a single hop (the SS4 station is directly connected to the base station BS2) and / or in the case of a multi-hop configuration (the station SS2 being connected to "two jumps" of the base station BS1, via here a relay station RS1)
  • a service flow SF is characterized by a main identifier SFID (for "Service Flow IDentifier") of a current service flow in the network.
  • a service flow SF thus has at least one SFID identifier and an associated direction, an identifier of CID connection when the SF service flow is active or accepted, the identifier
  • ProvisionedQoSParamSet although this type of parameter is not specifically provided for in the standard; a set of reserved parameters such as bandwidth, memory, or time-based resource (or “Time based Resource” in English), required to activate the service flow subsequently "AdmittedQoSParamSet", a set of parameters identifying the resources actually provided for the given service flow "ActiveQoSParamSet", it being understood that only an active service flow can transmit packets
  • An SF service flow can be created, modified or deleted using management messages
  • DSA Dynamic Service Flow Add
  • the creation of a service flow is initiated by an SS terminal or a BS BS
  • the DSA_REQ message issued by the terminal includes a reference to the relevant service flow, QoS QoS parameter sets or a service class name
  • the base station responds by a "DSA_RSP" message indicating the acceptance or rejection of the request
  • the rejection message may include additional information such as the parameters that were not supported in order to offer the service or incorrect values in the Reversal request
  • the base station BS can itself initiate the creation of a service flow by issuing a "DSA_REQ" message comprising the identifiers SFID, CFD and the QoS quality of service active or accepted parameters.
  • FIG. 2A shows different layers of an OSI model with an APP video transmission application layer, MAC layers including a CS convergence sublayer, a CPS common sub-layer, a sub-layer security layer SEC Under the MAC layers, there is shown by way of example at least one layer of the lowest level, which is here a PHY physical layer of the OSI protocol stack schematized in FIG. 2A.
  • the messages transmitted by the MAC layer are copied to be transmitted to an XLO transverse layer within the meaning of the invention (for "Cross Layer Optimizer").
  • software application installed with the video content server is meant by "video content server” the entity that sends the video data Therefore, this server can be for example an SS terminal which sends in video transmission (in P2P mode) this video data to other SS terminals
  • the XLO adaptation software application interprets or derives DSA_RSP, DSC_RSP, DSC_REQ messages from the MAC layer CPS new video parameters, typically to increase or reduce the bit rate to be adapted to the conditions of the network, for example by increasing or reducing the amount of frames per second, or even the image definition More precisely, one of these messages is interpreted in order to estimate current constraints of the network and the video parameters are then adapted if necessary.
  • the adaptation of the video parameters is performed by the XLO transverse layer executed with the server (initial owner of the video content, such as an SS terminal, as previously indicated)
  • the server initial owner of the video content, such as an SS terminal, as previously indicated
  • the cross-layer XLO (or "cross-layer"), which in reality is presented as an adaptation software application, is installed and executed in a node of the network such, for example, that the aforementioned terminal SS which plays the role of a server (in the sense that this terminal SS holds the service in the manner of a "video content server")
  • the reference model of FIG. 2A is represented essentially for the MAC and PHY physical layers as defined in the IEEE 802 16d standard and which will involve, for the purposes of the invention, the XLO transverse layer.
  • the CPS layer of the MAC layer stack is responsible, in this OSI protocol stack, for the management of the service flows.
  • the XLO transverse layer interacts in particular with this CPS sub-layer to receive management messages. service flow and, as previously described, with the application layer APP video transmission to transmit the new suitable video parameters
  • FIG. 2B describes the general steps of a method according to the invention using the XLO transverse layer.
  • the overall processing method of FIG. 2B (which may be an example of a flowchart of a computer program algorithm that comprises the XLO transverse layer) is generally divided into three steps.
  • the first step consists in collecting at least one piece of information from the CPS MAC sublayer
  • the second step is to process this information and make a decision to the XLO layer
  • the third step is to finally determine adaptations to be made with new video transmission application settings
  • the CPS sublayer in step 10 transmits service flow management messages to handle possible responses to service flow creation or service flow change request messages (DSA_RSP and DSC_RSP) , or to a service flow modification request (DSC_REQ) If such messages are received by the XLO transverse layer (OK arrow at the output of the test 1 1), the transverse layer XLO interprets these messages to estimate current constraints of the network (in step 12) and decides (in step 13), if necessary, to determine new NVP video parameters, for example to reduce the bit rate in case of rejection of request II is underlined here that the one of the collected messages is interpreted in step 12
  • these new parameters NVP are communicated to the APP application layer (step 14), which then determines the video quality corresponding to the bit rate compatible with the new NVP video parameters (step 15 conducted by the APP application layer)
  • the modification of the video quality can then generate requests for modification or modification.
  • new service flow management messages can be generated to further decrease the rate, or increase it, depending on the current state of the network and the new rate adopted. If such new service flow management messages are issued (in particular by the MAC CPS sublayer), a copy of these new service flow management messages is issued to the XLO cross-layer, again. that the NVP parameter optimization process forms a continuous loop during transmission, as shown in FIG. 2B
  • the service flows are managed (added, modified or deleted) by respective messages DSA, DSC and DSD. Therefore, among the multiplicity of messages exchanges between an entity such as an SS terminal and an entity such as a base station BS, an implementation of the present invention focuses in particular on the messages DSAJtSP, DSC_REQ and DSC_RSP Indeed, insofar as the invention is implemented in particular at the level of an SS transmission entity, a copy of such service flow management messages initiated by the transmitting entity, or else received by a transmission station, base BS, will be collected and transmitted to the XLO transverse layer After this information collection step, a possible step of adaptation and modification (steps 12 and 13 of Figure 2B) is conducted to process all messages collected service flow management
  • Such messages may contain a positive response when a request is accepted and a negative response when a request is not fully accepted or is rejected Rejection of a request means that available resources are not sufficient for the application It is then proposed to adapt the parameters of the video transmission so as to obtain a positive response to the next request that will be sent.
  • a request is preferably sent here redundantly until it is satisfied. general, the transmission parameters are changed to reduce the video data rate if a previous request has been rejected. This procedure can be repeated until the video transmission application is finally accepted or rejected with minimal video quality (in which case the video transmission application does not take place)
  • the minimum and maximum in qu video channel are therefore negotiated since the beginning of the transmission between the content provider (terminal sending the video data) and the client (the terminal receiving these data)
  • XLO transverse layer optimizes the video quality of the transmission, by showing in particular the messages exchanged between the different entities concerned.
  • the optimization in the sense of the invention occurs in particular in the acceptance control step of a video transmission and also during the video transmission itself when a new video stream is added.
  • XLO transverse layer intervenes in order to adapt the video parameters and to guarantee the acceptance of the corresponding service flow with the MAC layer.
  • FIG. 1 the configuration illustrated in FIG. 1 is taken as an example with an SS2 terminal at the origin of the transmission of the video content, which must be received by the terminal SS4.
  • service flow management messages are relayed here by the RS 1 station so as to reach the base station BS 1
  • the service flow management messages intervening for the optimization of the quality of service are here the response to a request to add a dynamic service flow (DSA_RSP), a request to modification of a service flow (DSC_REQ), and the response to a request to modify a service flow (DSC_RSP).
  • DSA_RSP dynamic service flow
  • DSC_REQ request to modification of a service flow
  • DSC_RSP response to a request to modify a service flow
  • the request for adding a dynamic service flow DSA_REQ is initiated by an emitting entity SS2 of the video data and the response to the adding request DSA_RSP, issuing from the base station, is received and interpreted by SS2 Issuing Entity
  • SS2 Issuing Entity The following describes how the interpretation of a rejection of the add request to SS2 leads to a decision to decrease the quality of service.
  • FIG. 3 is then used to describe the situation in which a DSA_REQ message is initiated by the terminal station SS2 which seeks to create the service flow for a streaming video transmission (the station SS2 memorizing the video content to be transmitted)
  • the MAC layer of a protocol stack of the terminal SS2 receives a request for adding a service for a video stream (typically of a higher application layer)
  • the MAC layer initiates a request message DSA_REQ with the quality of service parameters Desired QoS
  • the message crosses the relay station RS1 so as to reach the base station BS 1, which verifies the integrity of the message and responds with a message of the type DSX_RVD (RVD for "received" according to the standard 802 16) if the message request is valid
  • the base station BS1 sends a DSA_RSP message with a code of success or rejection
  • FIG. 3 is then used to describe the situation in which a DSA_REQ message is initiated by the terminal station
  • the sequence diagram represents a case where the addition of a service flow is rejected a first time (message received from the BS1 base station: "DSA_RSP (reject)”) and accepted. the next time (message "DSA_RSP (success)”) thanks to the optimization provided by the XLO trans verse layer by producing the new NVP parameters after the rejection of the first request.
  • DSA_RSP rejection message this message is transmitted to the XLO transverse layer that interprets this message and instructs the APP video transmission application layer to change the parameters of the video application, typically in view. reduce the video data rate to be compatible with the current state of the network (especially in terms of current network constraints).
  • a new video stream addition request is initiated (DSA_REQ (new)).
  • DSA_REQ new
  • the same steps are implemented between the base station BS1 and the terminal SS2 and, in the example shown, the request is finally satisfied and the video transmission VID STRM can start with the new parameters NVP.
  • the reference VID STRM designates in FIG. 3 the term "Video Streaming".
  • the base station BS1 or the terminal SS2 can send a message DSC_REQ so as to further change the QoS parameters of the service flow.
  • base station BS1 initiates a DSC_REQ message.
  • the request for modification of a service flow (DSC_REQ) is initiated by the base station BS1 and received by the entity sending the video data SS2.
  • DSC_REQ request for modification of a service flow
  • the base station BS1 sends a message DSC_REQ because, for example, it no longer has the resources necessary to satisfy the constraints of a given QoS quality service flow.
  • links beyond the base station itself can no longer satisfy these constraints (for example if these constraints can no longer be satisfied by the link between the BS1 base station and the station at the reception SS4).
  • the base station BS l then sends a message DSC_REQ to the station SS2 so as to change the parameters of the service flow in favor of a respect of the constraints of the network.
  • the base station BS1 can decide whether requested modifications can be supported by the capabilities of the terminal SS2 or not.
  • the terminal SS2 receives a request and changes its flow parameters. direct service
  • the video transmission stops simply if the constraints in terms of quality of service in particular are not respected.
  • the transverse layer XLO which, in a particularly advantageous way, adapts the parameters of the video application before stopping the video transmission and causes a modification of the quality of service parameters of the video transmission so that the latter is carried out under new conditions while respecting the constraints of the network This is how as shown in FIG. 4, the transmission of the video data is effected, in practice, without discontinuity as a result of the adaptation. ation and optimization of the video parameters realized by the XLO transverse layer
  • a request for modification of a service flow (DSC_REQ) is initiated by the data transmission entity SS2 and the base station which covers it BS1 returns to the transmission entity SS2 a response to the change request (DSC_RSP)
  • DSC_REQ request for modification of a service flow
  • DSC_RSP change request
  • the terminal SS2 can initiate a message DSC_REQ if it detects changes in the channel conditions.
  • a modification request can aim at an increase or a decrease in the QoS quality of service. act typically of a case where for example the connection between the terminal SS2 and the base station BS1 becomes insufficient, in which case a decrease in the quality of service is to be considered
  • the station BS1 receives a message DSC_REQ
  • the base station responds with a DSX_RVD message if the request message is valid
  • the base station checks whether the new SF service flow parameters can be supported and sends a DSC_RSP message to the SS2 terminal with a success or rejection response.
  • the SS2 terminal continues with the old parameters Otherwise, it determines new NVP parameters and, in particular, the role of the transverse layer XLO is to adapt, each time, the video parameters based on the active and accepted service flow parameters, so as to avoid the rejection of a video transmission, if new active service flow parameters are no longer appropriate for a correct transmission
  • the present invention is not limited to the embodiment described above by way of example, it extends to other variants
  • the video streaming application is described above as an example.
  • the invention applies to any type of service and advantageously to services whose transmission must not be interrupted.
  • the present invention can be implemented in any type of communication network (not necessarily WIMAX ®), since requests for addition, rejection and / or modification of service can be collected to adapt the quality. service without interrupting data transmission.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Quality & Reliability (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

L'invention concerne une technique de gestion de communication de données via un réseau, pour un service de transmission de données en continu tel que par exemple un streaming vidéo. Dans une telle application, des messages de gestion de flux de service sont échangés entre entités du réseau (SS2, BS 1). Au sens de l'invention, on prévoit : une étape de collecte de ces messages, une étape d'interprétation d'au moins un des messages collectés pour estimer des contraintes courantes du réseau, et une étape de décision d'adapter ou non des paramètres du service en fonction de ces contraintes.

Description

Optimisation d'une communication de données, notamment pour des applications de transmission en continu de données vidéo
La présente invention concerne le domaine des communications de données, notamment de données vidéo, dans des applications de transmission en continu (ou « streaming »), préférentiel lement dans des réseaux sans fil large bande tels que les réseaux selon la norme IEEE 802 16, encore appelés « réseaux WMAX ® »
Avec l'émergence de l'Internet et des techniques diverses pour supporter des services multimédia, les efforts de développement des technologies sans fil se poursuivent dans le but de fournir une bande passante et une couverture maximales avec la meilleure qualité de service possible
La norme IEEE 802 16 propose une technique sans fil large bande permettant d'atteindre un débit élevé de transmission de données en assurant une qualité de service (ou « QoS ») satisfaisante En effet, dans la gestion de communication de données selon la norme IEEE 802 16, les couches MAC (pour « Médium Access Control ») du modèle OSI (pour « Open Systems Interconnection ») jouent un rôle important pour traiter les aspects de qualité de service, comme on le verra plus loin Cette technique s'adapte bien à des applications multimédia en temps réel telles que la transmission en continu de données vidéo (ou « video streaming ») De telles applications présentent de nombreuses contraintes pour assurer un fonctionnement correct de la transmission en continu, notamment en termes de bande passante minimum requise , délai maximum toléré , gigue maximale tolérée
Toutefois, ces contraintes nécessitent beaucoup de ressources, lesquelles sont parfois indisponibles selon un état en cours du réseau
II n'est pas proposé aujourd'hui de solution pour tenir compte d'un changement d'état du réseau qui pourrait nécessiter un changement, en conséquence, des ressources requises pour assurer la continuité de l'application de transmission vidéo Ainsi, si la ressource nécessaire disponible sur le réseau n'est pas suffisante pour une telle application, la transmission vidéo a partir du terminal d'un individu (ou la réception du flux video sur le terminal d'un individu) s'arrête et la transmission est simplement interrompue
La présente invention vient améliorer la situation Elle propose à cet effet un procédé de gestion d'une communication de données via un réseau, préférentiel lement pour un service de transmission de données en continu, dans lequel des messages pour la gestion de flux de service (ou « service flow » en vocable anglo-saxon) et relatifs audit service sont échangés entre entités du réseau Le procédé au sens de l'invention comporte en particulier une étape de collecte des messages de gestion de flux de service, une étape d' interprétation d'au moins un desdits messages collectés pour estimer des contraintes courantes du réseau, et une étape de décision d'adapter ou non des paramètres dudit service en fonction de ces contraintes
Ainsi, suite à la décision d'adapter les paramètres du service, les paramètres de qualité de service du flux de service (tels que par exemple la bande passante minimum requise, le délai maximum toléré, la gigue maximale tolérée) sont modifiés et permettent de respecter les contraintes courantes du réseau (notamment en termes de bande passante disponible)
Dans une application avantageuse, le service précité comporte une transmission de données vidéo en continu (ou « video streaming » en vocable anglo-saxon) Les contraintes du réseau comportent alors au moins une contrainte de débit des données et les paramètres du service comportent avantageusement au moins un élément parmi au moins une résolution d'image, un nombre d'images par unité de temps, ou autres
On comprendra alors que toute modification des paramètres d'une application telle que de la transmission vidéo en continu (ces paramètres étant par exemple un nombre d'images par seconde, une résolution d'image, ou autres) peut se traduire directement par une modification du débit des données vidéo
Ainsi, dans une mise en œuvre au sens de la présente invention où on applique une transmission de données vidéo en continu (ou « video streaming »), cette transmission ne s'interrompt pas lorsque les ressources du réseau ne sont plus disponibles Comme on le verra en détails plus loin, les paramètres du service sont modifiés Par exemple, la qualité de rendu d'image dans des applications de transmission de données vidéo, telles que notamment la quantité d'images par seconde, la définition d'image en nombre de pixels, ou autres, peut être modifiée avec une qualité de service moindre en cas de restriction de ressources Avantageusement, le message interprète appartient à un groupe comprenant une réponse à une requête d'ajout d'un flux de service dynamique, une requête de modification d'un flux de service, une réponse à une requête de modification d'un flux de service Les étapes du procédé sont préférentiellement réitérées répétitivement pendant le service précité de transmission de données en continu La mise en œuvre de la présente invention permet alors d'assurer que le service de transmission en continu se poursuit toujours, le cas échéant avec une qualité de service moindre
Le réseau peut avantageusement être un réseau sans fil large bande opérant selon la norme IEEE 802 16
L'invention peut alors tirer profit du fait que certaines couches du modèle OSI de la norme IEEE 802 16 notamment, telles les couches MAC (pour « Médium Access Control ») génèrent des messages relatifs à un flux de service dynamique en cours De tels messages peuvent être par exemple la création, la modification ou l'interruption d'un flux de service Au sens de l'invention, une couche logicielle « transverse », d'adaptation, récupère ces messages, les interprète et impose éventuellement de nouveaux paramètres vidéo à une couche applicative (de plus haut niveau que les couches MAC dans le modèle OSI), en vue de modifier éventuellement la qualité du signal vidéo, par exemple pour satisfaire des contraintes du réseau et en particulier un état courant de congestion du réseau
Ainsi, dans une réalisation avantageuse, on prévoit, pour la gestion de la communication de données, un empilement protocolaire comportant au moins une première couche logicielle, applicative pour la mise en œuvre du service, une deuxième couche logicielle, de plus bas niveau que la première couche, apte à générer les messages pour la gestion de flux de service, et au sens de l'invention, une couche logicielle d'adaptation pour o recevoir une copie des messages générés et/ou reçus par la deuxième couche, o interpréter au moins un desdits messages pour estimer des contraintes courantes du réseau, o décider d'adapter ou non les paramètres du service en fonction des contraintes courantes du reseau, et o transmettre le cas échéant de nouveaux paramètres du service, adaptes, a la première couche
Ainsi, selon l'un des avantages que procure la présente invention, une application telle que par exemple une transmission en continu de données vidéo (ou « video streaming ») adapte le débit de transmission de ces données en fonction de l'état du reseau et en particulier des changements d'état du reseau, et ce, grâce à l'apport de la couche transverse au sens de l'invention L'objectif principal d'un mécanisme utilisant une telle couche transverse, d'adaptation, est de piloter des applications de transmission vidéo à partir de Ia couche applicative du modèle OSI, en utilisant les messages retournés par une couche de plus bas niveau de la norme IEEE 802 16 (typiquement l'une des couches MAC comme on le verra plus loin) Ces trois couches MAC, transverse et applicative échangent alors de F information afin de réaliser des adaptations rapides notamment des paramètres vidéo
A ce titre, la présente invention vise aussi un programme informatique comportant des instructions pour la mise en œuvre du procédé ci-avant, lorsque ce programme est exécuté par un processeur Un tel programme peut correspondre à la couche logicielle d'adaptation précitée, auquel cas elle comporte avantageusement des instructions d'interfaçage avec la première et la deuxième couche du modèle OSI Un exemple d'organigramme d'un algorithme de ce programme informatique est illustré sur la figure 2B décrite ci-après
Par ailleurs, il est préféré, dans une réalisation particulière, que la couche logicielle d'adaptation (ou plus généralement le programme informatique au sens de l'invention) soit installée et exécutée auprès de l'entité du réseau qui émet les données à transmettre en continu
A ce titre, la présente invention vise aussi un terminal de communication, comportant des moyens de gestion d'une communication de données via un réseau, pour un service de transmission de données en continu, et des moyens de réception de messages pour la gestion de flux de service issus d'autres entités du réseau
Les moyens de gestion peuvent comporter un module exécutant le programme informatique au sens de l'invention et sont alors agencés pour collecter les messages de gestion de flux de service, interpréter au moins un des messages collectés pour estimer en outre des contraintes courantes du réseau, et décider d'adapter ou non les paramètres du service en fonction des contraintes courantes du réseau
On a représenté schématiquement sur la figure 6 un terminal SS2 comportant des moyens de réception des messages REC et les moyens de gestion précités (qui peuvent comprendre typiquement un processeur PROC et une mémoire de travail MEM)
D'autres caractéristiques et avantages de l'invention apparaîtront à l'examen de la description détaillée ci-apres, et des dessins annexes sur lesquels la figure 1 représente schématiquement une situation typique de transmission vidéo sur un réseau WIMAX ® , la figure 2A représente une optimisation de couches transverses au sens de l'invention entre les couches MAC et une couche applicative d'un modèle OSI , la figure 2B représente schématiquement les étapes principales d'un procédé selon un exemple de réalisation de l'invention , la figure 3 représente une situation dans laquelle un terminal requiert un flux de service avec une qualité supérieure à celle que peut offrir le réseau , la figure 4 représente une situation dans laquelle une station de base du réseau sollicite un changement de flux de service (par exemple en vue d'offrir une qualité moindre pour faire face à un état du réseau plus congestionné) , la figure 5 représente une situation dans laquelle un terminal (par exemple le terminal qui émet les données vidéo) sollicite lui-même une modification du flux de service (par exemple si le lien entre ce terminal et sa station de base devient insuffisant) , et la figure 6 représente schématiquement un terminal que vise aussi la présente invention
On se réfère tout d'abord à la figure 1 représentant un réseau comportant des stations de base BSl et BS2 (« BS » pour « Base Station »), le réseau étant ici un réseau WIMAX ® selon la norme 802 16 Une session de transmission vidéo entre deux terminaux SS2 et SS4 (« SS » pour « Subscπber Station ») est établie et matérialisée par un trait pointillé sur la figure 1 A titre d'exemple, on peut prévoir en outre des stations relais RSl et RS2 (« RS » pour « Relay Station »), dans la zone de couverture de la station de base BSl pour couvrir respectivement le terminal SS2 et un autre terminal SS3 On observera qu'un terminal SSl est, quant à lui, directement dans la zone de couverture de la station de base BSl Le terminal SS4, en trafic de transmission vidéo avec le terminal SS2, est d'ailleurs directement dans la zone de couverture de la station de base BS2, comme un terminal SS5 Dans cet exemple, on relèvera la possibilité encore de passer par une station relais RS3 qui couvre ici le terminal SS6 Par ailleurs, les stations de base BSl et BS2 sont reliées entre elles par un réseau de communication, tel que le réseau Internet
Dans ce qui suit, le trafic de transmission vidéo est en continu (ou « video streaming ») et s'effectue par exemple ici en mode "pair à pair" (« peer to peer » en anglais ou « P2P ») Beaucoup de types de trafics vidéo peuvent exister entre les différents nœuds du réseau Dans l'exemple simplifié représente sur la figure 1, le trafic de transmission vidéo intervient entre deux stations SS2 et SS4 couvertes (de façon globale directement ou par l'intermédiaire de stations relais) par deux stations de base BS l et BS2 Dans l'exemple décrit, l'invention peut être mise en œuvre aussi bien dans le cas d'un saut unique (la station SS4 étant directement connectée à la station de base BS2) et/ou dans le cas d'une configuration en multi-sauts (la station SS2 étant reliée à « deux sauts » de la station de base BSl , par l'intermédiaire ici d'une station relais RSl)
On décrit ci-après les caractéristiques de gestion de flux de service au sens de la norme IEEE 802 16
Chaque paquet de données traversant l'interface MAC, dans la norme IEEE 802 16, appartient à un flux de service identifié par un identifiant de connexion Un flux de service (ou « service flow ») est un flux unidirectionnel de paquets fournissant une qualité de service (ou « QoS ») particulière en fonction d'un jeu de paramètres de qualité de service QoS tels que le temps d'attente ou « latence », la gigue, ou de façon plus générale l'assurance d'un débit donné
On décrit ci-après quelques caractéristiques de flux de service
Un flux de service SF est caractérisé par un identifiant principal SFID (pour « Service Flow IDentifier ») d'un flux de service courant dans le réseau Un flux de service SF a donc au moins un identifiant SFID et une direction associée , un identifiant de connexion CID quand le flux de service SF est actif ou admis, l'identifiant
SFID est relié à un identifiant de connexion CID (pour « Connection IDentifier ») , éventuellement, un ensemble de paramètres de qualité de service prévu
« provisionedQoSParamSet », bien que ce type de paramètres ne soit pas spécifiquement prévu dans le standard ; un ensemble de paramètres réservés tels que de la bande passante, de la mémoire, ou encore de la ressource à base de temps (ou "Time based Ressource" en anglais), requise pour activer le flux de service par la suite « AdmittedQoSParamSet » , un ensemble de paramètres identifiant les ressources effectivement fournies pour le flux de service donné « ActiveQoSParamSet », étant entendu que seul un flux de service actif peut transmettre des paquets
On comprendra que de telles caractéristiques peuvent permettre à une couche applicative d'optimiser le débit des données vidéo (par exemple, en modifiant la résolution des données image, en modifiant le nombre d'images par seconde, ou autre)
Comme on le verra plus loin en référence à la figure 2A, la couche transverse d'adaptation, au sens de l'invention, peut envoyer de telles caractéristiques à la couche applicative pour réguler le débit, en fonction de messages de gestion de flux de service qu'elle-même reçoit de l'une des couches MAC du modèle OSI au sens de la norme IEEE 802 16, ces messages de gestion de flux de service permettant de déterminer la qualité de service qui peut être offerte en fonction de l'état courant du réseau
Quelques exemples de messages de gestion de flux de service issus d'une des sous-couches MAC sont donnés ci-après II s'agit notamment d'une sous-couche CPS (pour "Common Part Sub- Layer"), présentée ultérieurement
Un flux de service SF peut être créé, modifié ou supprimé en utilisant des messages de gestion
MAC tels que l'ajout d'un flux de service dynamique ou « DSA » (pour « Dynamic Service Flow Add ») la création d'un flux de service est initiée par un terminal SS ou une station de base BS Typiquement, lorsque le terminal SS initie la création du flux de service, le message DSA_REQ qu'émet le terminal comporte une référence au flux de service concerné, des jeux de paramètres de qualité de service QoS ou un nom de classe de service, et la station de base répond par un message « DSA_RSP » indiquant l'acceptation ou le rejet de la requête Le message de rejet peut comporter des informations supplémentaires telles que les paramètres qui n'ont pas été supportés pour pouvoir offrir le service ou encore des valeurs erronées dans la requête Inversement, la station de base BS peut initier elle-même la création d'un flux de service en émettant un message « DSA_REQ » comportant les identifiants SFID, CFD et les paramètres actifs ou admis de qualité de service QoS La réponse du terminal SS est de même type DSA_RSP que celle que donnait la station de base BS dans le cas précédent , un message de type DSC (pour « Dynamic Service flow Change ») après création du flux de service, un flux de service SF peut être modifié par un message DSC_REQ Une telle modification inclut typiquement des paramètres QoS admis et actifs Les modifications deviennent effectives lorsque les paramètres admis et actifs sont remplacés En particulier, si seuls les paramètres admis sont inclus dans le message, les paramètres actifs sont fixés « à zéro » et le flux de service est alors désactivé En revanche, lorsque les paramètres à la fois admis et actifs sont insérés dans le message, le jeu de paramètres admis est vérifié dans un premier temps par un mécanisme de contrôle d'admission des paramètres et, ensuite, le jeu de paramètres actifs est vérifie pour s'assurer qu'il s'agit bien d'un sous-ensemble des paramètres admis Si ces vérifications sont positives, les modifications du flux de service s'opèrent Sinon, le flux de service reste inchangé et continue à fonctionner avec les mêmes paramètres existants , un message DSD pour « Dynamic Service flow Delete » un flux de service est supprime d'une station de base BS ou d'un terminal SS par l'utilisation d'un message DSD_REQ De plus, un flux de service peut être supprimé implicitement lorsque se produit une erreur II convient de préciser ici que le cas d'une liaison à un seul saut ou d'une liaison multi-sauts peut être traité de la même manière
La gestion d'un flux de service pour un lien multi-sauts reste le même puisque les mêmes messages de gestion du flux de service sont utilisés Les messages de type DSA, DSC et/ou DSD sont échangés entre la station de base BS et le terminal SS à travers une ou plusieurs stations relais En effet, le projet de norme EEEE 802 16j définit deux modèles de transmission pour la communication de données MAC dans le sens général, et donc en particulier ici de messages de gestion de flux de service
Un premier modèle se base sur la transmission d'un identifiant de connexion CID et un deuxième modèle se base sur la transmission dite « tunnel » La transmission de l'identifiant de connexion CID est le schéma de transmission de base Lorsqu'un paquet MAC (bloc de données nommé aussi « PDU » pour « Packet Data Unit ») traverse une station relais RS, cette dernière extrait l'identifiant de connexion CID inclus dans le champ d'en-tête MAC du paquet Ensuite, cette station relais RS route le paquet à une station relais suivante ou délivre le paquet directement à un terminal SS ou une station de base BS Pour ce qui concerne le modèle de transmission « tunnel », un tunnel est établi entre la station de base BS et la station relais RS qui est directement connectée au terminal concerné SS Lorsque la station relais RS reçoit un paquet MAC (PDU) à partir d'un tunnel, la station relais RS extrait un identifiant de tunnel pour le faire correspondre à un identifiant de connexion CID et route alors le paquet au terminal SS et vice versa (du terminal SS à la station BS)
Une mise en œuvre de l'invention consiste en un mécanisme d'adaptation d'une application de transmission vidéo en utilisant une couche « transverse » entre la couche MAC et la couche d'application de transmission vidéo, comme représenté sur la figure 2A
En effet, on a représenté sur la figure 2A différentes couches d'un modèle OSI avec une couche applicative de transmission vidéo APP, des couches MAC dont une sous-couche de convergence CS, une sous-couche de partie commune CPS, une sous-couche de sécurité SEC Sous les couches MAC, on a représenté à titre d'exemple au moins une couche de plus bas niveau, qui est ici une couche physique PHY de l'empilement protocolaire OSI schématisé sur la figure 2A En particulier ici, les messages que transmet la couche MAC (plus particulièrement la couche CPS dans l'exemple décrit) sont recopiés pour être transmis à une couche transverse XLO au sens de l'invention (pour « Cross Layer Optimizer ») II s'agit en particulier d'une application logicielle installée auprès du serveur de contenu vidéo On entend ici par « serveur du contenu video » l'entité qui envoie les données video Par conséquent, ce serveur peut être par exemple un terminal SS qui envoie en transmission vidéo (en mode P2P) ces données vidéo à d'autres terminaux SS
L'application logicielle d'adaptation XLO interprète ou déduit des messages DSA_RSP, DSC_RSP, DSC_REQ issus de la couche MAC CPS de nouveaux paramètres vidéo, typiquement en vue d'augmenter ou de réduire le débit pour être adapté aux conditions du reseau, par exemple en augmentant ou en réduisant la quantité d'images par seconde, ou encore la définition d'image Plus précisément, un de ces messages est interprété afin d'estimer des contraintes courantes du reseau et les paramètres vidéos sont ensuite adaptés si nécessaire Ainsi, la couche d'adaptation XLO reçoit des copies des messages de gestion de flux de service de type « DSA_RSP », « DSC_RSP », ou encore « DSC_REQ » et en déduit si une requête de flux de service, par exemple, est acceptée ou rejetée pour, en cas de rejet notamment, décider de nouveaux paramètres vidéo NVP pour réduire le débit La couche applicative de transmission vidéo APP, sur réception des nouveaux paramètres vidéo NVP en provenance de la couche d'adaptation XLO modifie par exemple la quantité d'images par seconde ou la définition d'image, ou encore éventuellement par exemple des nuances de couleurs de pixels dans les images, ou autres, pour réduire le débit On passe ainsi d'une grande qualité d'image (flèche Fl ou F2) à une qualité moindre (flèche F2 ou F3, respectivement) L'adaptation des paramètres vidéo est effectuée par la couche transverse XLO exécutée auprès du serveur (propriétaire initial du contenu vidéo, tel qu'un terminal SS, comme indiqué précédemment) Ainsi, la couche transverse XLO (ou « cross-layer »), qui en réalité se présente comme une application logicielle d'adaptation, est installée et exécutée dans un nœud du réseau tel, par exemple, que le terminal précité SS qui joue le rôle d'un serveur (dans le sens où ce terminal SS détient le service a la manière d'un « serveur de contenu vidéo »)
II convient d'indiquer que le modèle de référence de la figure 2A est représenté essentiellement pour les couches MAC et physiques PHY telles que définies dans la norme IEEE 802 16d et qui fera intervenir, au sens de l'invention, la couche transverse XLO En effet, la couche CPS de l'empilement de couches MAC est responsable, dans cet empilement protocolaire OSI, de la gestion des flux de service Ainsi, la couche transverse XLO interagit en particulier avec cette sous- couche CPS pour recevoir des messages de gestion de flux de service et, comme décrit précédemment, avec la couche applicative de transmission vidéo APP pour transmettre les nouveaux paramètres vidéo adaptes
On se réfère maintenant à la figure 2B pour décrire les étapes générales d'un procède au sens de l'invention utilisant la couche transverse XLO Le procédé global de traitement de la figure 2B (qui peut être un exemple d'organigramme d'un algorithme de programme informatique que comporte la couche transverse XLO) est globalement divisé en trois étapes La première étape consiste à collecter au moins une information depuis la sous-couche MAC CPS La deuxième étape consiste à traiter cette information et à prendre une décision auprès de la couche XLO La troisième étape consiste finalement à déterminer des adaptations à apporter avec de nouveaux paramètres d'application de transmission vidéo
Ainsi, la sous-couche CPS à l'étape 10 transmet des messages de gestion de flux de service pour gérer d'éventuelles réponses à des messages de demande de création de flux de service ou de changement de flux de service (DSA_RSP et DSC_RSP), ou encore à une requête de modification de flux de service (DSC_REQ) Si de tels messages sont reçus par la couche transverse XLO (flèche OK en sortie du test 1 1), la couche transverse XLO interprète ces messages pour estimer des contraintes courantes du réseau (à l'étape 12) et décide (à l'étape 13), le cas échéant, de déterminer de nouveaux paramètres vidéo NVP, en vue par exemple de réduire le débit en cas de rejet de requête II est souligné ici que l'un des messages collectés est interprété lors de l'étape 12 Une fois ces nouveaux paramètres déterminés à l'étape 13 (réduction de la résolution d'image ou du nombre d'images par seconde ou autres, par exemple), ces nouveaux paramètres NVP sont communiqués à la couche applicative APP (étape 14), laquelle détermine ensuite la qualité vidéo correspondant au débit compatible avec les nouveaux paramètres vidéo NVP (étape 15 menée par la couche applicative APP) La modification de la qualité vidéo peut générer alors des requêtes de modification ou d'ajout de flux de service, comme décrit plus loin en référence aux figures 3 à 5, et les messages correspondants sont reçus et/ou générés par la couche MAC (notamment la sous- couche CPS) à l'étape 16
Ensuite, une fois le nouveau débit établi dans le réseau, de nouveaux messages de gestion de flux de service peuvent être générés pour diminuer encore le débit, ou au contraire l'augmenter, suivant l'état courant du réseau et suivant le nouveau débit adopté Si de tels nouveaux messages de gestion de flux de service sont émis (en particulier par la sous-couche MAC CPS), une copie de ces nouveaux messages de gestion de flux de service est émise à la couche transverse XLO, à nouveau On comprendra alors que le processus d'optimisation des paramètres NVP forme une boucle continue pendant la transmission, comme représenté sur la figure 2B
Ainsi, comme indique précédemment, les flux de service sont gères (additionnés, modifiés ou supprimés) à l'aide de messages respectifs DSA, DSC et DSD Par conséquent, parmi la multiplicité de messages échanges entre une entité telle qu'un terminal SS et une entité telle qu'une station de base BS, une mise en œuvre de la présente invention se focalise en particulier sur les messages DSAJtSP, DSC_REQ et DSC_RSP En effet, dans la mesure ou l'invention est mise en œuvre en particulier au niveau d'une entité émettπce SS, une copie de tels messages de gestion de flux de service initiée par l'entité émettπce, ou encore reçue par une station de base BS, va être collectée et transmise à la couche transverse XLO Après cette étape de collection d'informations, une éventuelle étape d'adaptation et de modification (étapes 12 et 13 de la figure 2B) est menée de façon à traiter tous les messages collectés de gestion de flux de service
De tels messages peuvent contenir une réponse positivées lorsqu'une requête est acceptée et une réponse négative lorsqu'une requête n'est pas totalement acceptée ou est rejetée Le rejet d'une requête signifie que les ressources disponibles ne sont pas suffisantes pour l'application de transmission vidéo II est alors proposé d'adapter les paramètres de la transmission vidéo de manière à obtenir une réponse positive à la prochaine requête qui sera émise Une requête est préférentiel lement envoyée ici de façon redondante tant qu'elle n'est pas satisfaite En général, les paramètres de transmission sont modifiés de manière à réduire le débit de données vidéo si une requête précédente a été rejetée Cette procédure peut être répétée jusqu'à ce que l'application de transmission vidéo soit finalement acceptée ou rejetée avec une qualité vidéo minimale (auquel cas l'application de transmission vidéo n'a pas lieu) Le minimum et le maximum en qualité vidéo sont donc négociés depuis le début de la transmission entre le fournisseur de contenu (terminal envoyant les données vidéo) et le client (le terminal recevant ces données)
Ainsi, lorsqu'une requête est acceptée, cette information est conservée pendant le temps d'acceptation de cette requête Si la transmission vidéo se déroule correctement pendant une certaine période, il est possible ensuite de rechercher une qualité vidéo améliorée (en passant par exemple de la flèche F2 ou F3 à la flèche Fl ou F2, respectivement, comme représenté sur la figure 2A), en espérant bien entendu que les mêmes ressources seront encore disponibles En cas de rejet, l'application de transmission vidéo se poursuivra en fonctionnant toutefois avec des paramètres anciens et liés à une qualité vidéo moindre que celle espérée, grâce à la mise en œuvre de l'invention En revanche, si la requête est acceptée, on réitère ces étapes jusqu'à atteindre une qualité vidéo maximum (de sorte que le diagramme représenté sur la figure 2B correspond bien à une boucle)
On décrit ci-après des diagrammes de séquence pour expliquer comment la couche transverse XLO permet d'optimiser la qualité video de la transmission, en montrant en particulier les messages échanges entre les différentes entités concernées Dans les exemples ci-apres, l'optimisation au sens de l'invention intervient en particulier dans l'étape de contrôle d'acceptation d'une transmission vidéo et aussi pendant la transmission vidéo elle-même Lorsqu'un nouveau flux vidéo est ajouté, la couche transverse XLO intervient de manière à adapter les paramètres vidéo et à garantir l'acceptation du flux de service correspondant auprès de la couche MAC Ainsi, pendant la transmission vidéo, si les conditions de la couche MAC évoluent et que la transmission vidéo risque d'être rejetée, la solution au sens de l'invention est mise en œuvre pour adapter la transmission vidéo selon les nouvelles conditions de la couche MAC et éviter ainsi un rejet de la transmission vidéo On comprendra que la présente invention s'applique de façon avantageuse à la transmission en continu (dite « streaming »)
Dans les exemples décrits ci-après, la configuration illustrée sur la figure 1 est reprise à titre d'exemple avec un terminal SS2 à l'origine de l'émission du contenu vidéo, lequel doit être reçu par le terminal SS4 En outre, les messages de gestion de flux de service sont relayés ici par la station RS 1 de manière à atteindre la station de base BS 1
Comme on le verra ci-après, les messages de gestion de flux de service intervenant pour l'optimisation de la qualité de service sont ici la réponse à une requête d'ajout d'un flux de service dynamique (DSA_RSP), une requête de modification d'un flux de service (DSC_REQ), et la réponse à une requête de modification d'un flux de service (DSC_RSP).
Dans le premier exemple de la figure 3, la requête d'ajout d'un flux de service dynamique DSA_REQ est initiée par une entité émettπce SS2 des données vidéo et la réponse à la requête d'ajout DSA_RSP, issue de la station de base, est reçue et interprétée par l'entité émettπce SS2 On décrit ci-après comment l' interprétation d'un rejet de la requête d'ajout, auprès de l'entité émettπce SS2, conduit à une décision de diminuer la qualité de service
On se réfère alors à la figure 3 pour décrire la situation dans laquelle un message DSA_REQ est initié par la station-terminal SS2 qui cherche a créer le flux de service pour une transmission vidéo en continu (la station SS2 mémorisant le contenu video à émettre) Lorsque la couche MAC d'un empilement protocolaire du terminal SS2 reçoit une requête d'ajout de service pour un flux video (typiquement d'une couche applicative supérieure), la couche MAC initie un message de requête DSA_REQ avec les paramètres de qualité de service QoS désirés Le message traverse la station relais RSl de manière à atteindre la station de base BS l , laquelle vérifie l'intégrité du message et repond par un message de type DSX_RVD (RVD pour « received » selon la norme 802 16) si le message de requête est valide Ensuite, selon une acceptation ou un rejet des paramètres QoS, la station de base BSl envoie un message DSA_RSP avec un code de succès ou de rejet Dans l'exemple de la figure 3, le diagramme de séquence représente un cas où l'ajout d'un flux de service est rejeté une première fois (message reçu de la station de base BSl : « DSA_RSP (reject) ») et accepté la fois suivante (message « DSA_RSP (success) ») grâce à l'optimisation qu'apporte la couche trans verse XLO en produisant les nouveaux paramètres NVP après le rejet de la première requête. Lorsque la station SS2 reçoit un message de rejet DSA_RSP, ce message est transmis à la couche transverse XLO qui interprète ce message et donne l'ordre à la couche applicative de transmission vidéo APP de changer les paramètres de l'application vidéo, typiquement en vue de réduire le débit des données vidéo pour qu'ils soient compatibles avec l'état courant du réseau (en particulier en termes de contraintes courantes du réseau). Après adaptation, une nouvelle requête d'ajout de flux vidéo est initiée (DSA_REQ (new)). Les mêmes étapes sont mises en œuvre entre la station de base BSl et le terminal SS2 et, dans l'exemple représenté, la requête est finalement satisfaite et la transmission vidéo VID STRM peut commencer avec les nouveaux paramètres NVP. La référence VID STRM désigne sur la figure 3 le vocable « Video Streaming ».
Après l'addition d'un flux vidéo, les conditions des canaux dans le réseau et la disponibilité des ressources peuvent changer. Dans ce cas, la station de base BSl ou le terminal SS2 peuvent envoyer un message DSC_REQ de manière à changer encore les paramètres QoS du flux de service.
Cette situation est illustrée sur la figure 4 et ici la station de base BSl initie un message DSC_REQ.
Dans le deuxième exemple illustré sur la figure 4, la requête de modification d'un flux de service (DSC_REQ) est initiée par la station de base BSl et reçue par l'entité émettrice des données vidéo SS2. On décrit ci-après comment l' interprétation d'une requête de modification, auprès de l'entité émettrice SS2, conduit à une décision de modifier les paramètres vidéo du service VID STRM.
Dans le diagramme de séquence illustré sur la figure 4, la station de base BSl envoie un message DSC_REQ car, par exemple, elle n'a plus les ressources nécessaires pour satisfaire les contraintes d'un flux de service de qualité QoS donné. En variante ou en complément, il est possible aussi que des liens au-delà de la station de base elle-même ne puissent plus satisfaire ces contraintes (par exemple si ces contraintes ne peuvent plus être satisfaites par la liaison entre la station de base BSl et la station à la réception SS4). La station de base BS l envoie alors un message DSC_REQ à la station SS2 de manière à changer les paramètres du flux de service en faveur d'un respect des contraintes du réseau. On indique ici que, avant d'envoyer un message DSC_REQ, la station de base BSl peut décider si des modifications demandées pourront être supportées par les capacités du terminal SS2 ou non Ainsi, le terminal SS2 reçoit une requête et change ses paramètres de flux de service directement Le plus souvent, la transmission vidéo s'arrête tout simplement si les contraintes en termes de qualité de service notamment ne sont pas respectées On comprend alors le rôle de la couche transverse XLO qui, de façon particulièrement avantageuse, adapte les paramètres de l'application vidéo avant l'arrêt de la transmission vidéo et entraîne une modification des paramètres de qualité de service de la transmission vidéo de manière à ce que cette dernière s'effectue dans de nouvelles conditions en respectant les contraintes du réseau C'est ainsi que, comme représenté sur la figure 4, la transmission des données vidéo s'effectue, en pratique, sans discontinuité suite à l'adaptation et à l'optimisation des paramètres vidéo que réalise la couche transverse XLO
Dans le troisième exemple illustré sur la figure 5, une requête de modification d'un flux de service (DSC_REQ) est initiée par l'entité emettπce des données SS2 et la station de base qui la couvre BSl renvoie à l'entité émettπce SS2 une réponse à la requête de modification (DSC_RSP) On décrit ci-après comment l'interprétation d'une réponse positive à la requête de modification, auprès de l'entité émettπce SS2, conduit à une décision de modifier la qualité de service
En référence à la figure 5, le terminal SS2 peut initier un message DSC_REQ s'il détecte des modifications dans les conditions de canaux Dans ce cas, une requête de modification peut viser une augmentation ou une diminution de la qualité de service QoS II peut s'agir typiquement d'un cas où par exemple le lien entre le terminal SS2 et la station de base BSl devient insuffisant, auquel cas une diminution de la qualité de service est à envisager Lorsque la station BSl reçoit un message DSC_REQ, la station de base répond par un message DSX_RVD si le message de requête est valide Ensuite, la station de base vérifie si les nouveaux paramètres de flux de service SF peuvent être supportés et envoie un message DSC_RSP au terminal SS2 avec une réponse de succès ou de rejet En cas de rejet, le terminal SS2 continue avec les anciens paramètres Sinon, il détermine de nouveaux paramètres NVP et, en particulier, le rôle de la couche transverse XLO est d'adapter, à chaque fois, les paramètres vidéo en fonction des paramètres de flux de service actifs et admis, de manière à éviter le rejet d'une transmission video, si de nouveaux paramètres de flux de service actifs ne sont plus appropries pour une transmission correcte
Bien entendu, la présente invention ne se limite pas à la forme de réalisation décrite ci-avant à titre d'exemple , elle s'étend a d'autres variantes Par exemple, l'application de transmission vidéo en continu (« video streaming ») est décrite ci- avant à titre d'exemple. L'invention s'applique à tout type de service et avantageusement aux services dont la transmission ne doit pas être interrompue.
Par ailleurs, la présente invention peut être mise en œuvre dans tout type de réseau de communication (non nécessairement WIMAX ®), dès lors que des requêtes d'ajout, de rejet et/ou de modification de service peuvent être collectées pour adapter la qualité de service sans rompre la transmission des données.

Claims

REVENDICATIONS
1 Procédé de gestion d'une communication de données via un réseau, pour un service de transmission de données en continu (VED STRM), dans lequel des messages pour la gestion de flux de service (SF) relatifs audit service sont échangés entre entités du réseau (SS2, BSl), caractérisé en ce qu'il comporte une étape de collecte (11 ) desdits messages, une étape d'interprétation (12) d'au moins un desdits messages collectés pour estimer des contraintes courantes du réseau, et une étape de décision (13) d'adapter ou non des paramètres dudit service en fonction desdites contraintes courantes du réseau
2 Procédé selon la revendication 1 , dans lequel ledit service comporte une transmission de données vidéo en continu, caractérisé en ce que les contraintes du réseau comportent au moins une contrainte de débit des données
3 Procédé selon la revendication 2, caractérisé en ce que les paramètres du service comportent au moins un élément parmi au moins une résolution d'image, un nombre d'images par unité de temps.
4 Procédé selon la revendication 1, dans lequel on prévoit, pour la gestion de la communication de données, un empilement protocolaire (OSI) comportant au moins une première couche logicielle (APP), applicative pour la mise en œuvre dudit service, et une deuxième couche logicielle (CPS), de plus bas niveau (MAC) que la première couche, apte à générer lesdits messages pour la gestion de flux de service (SF), caractérisé en ce que l'on prévoit en outre une couche logicielle d'adaptation (XLO) pour recevoir une copie desdits messages générés et/ou reçus par la deuxième couche, interpréter au moins un desdits messages pour estimer des contraintes courantes du réseau, décider d'adapter ou non les paramètres du service en fonction des contraintes courantes du réseau, et transmettre le cas échéant de nouveaux paramètres, adaptés, du service à la première couche
5 Procédé selon la revendication 4, dans lequel les données à transmettre en continu sont émises par une entité émettπce (SS2) du réseau, caractérisé en ce que la couche logicielle d'adaptation est exécutée auprès de ladite entité emettπce
6 Procédé selon la revendication 1 , caractérise en ce que le message interprète appartient à un groupe comprenant une réponse à une requête d'ajout d'un flux de service dynamique (DSA_RSP), une requête de modification d'un flux de service (DSC_REQ), une réponse à une requête de modification d' un flux de service (DSC_RSP)
7 Procédé selon la revendication 6, dans lequel les données à transmettre en continu sont émises par une entité émettπce (SS2) du réseau et le réseau est un réseau sans fil comportant au moins une station de base (BSl) couvrant l'entité émettπce, la requête d'ajout d'un flux de service dynamique est initiée par l'entité émettπce et la réponse à la requête d'ajout, issue de la station de base, est reçue par l'entité émettπce, caractérisé en ce que l'interprétation d'un rejet de la requête d'ajout, auprès de l'entité émettπce, conduit à une décision d'adapter les paramètres du service conduisant à l'acceptation d'une nouvelle requête d'ajout du flux de service
8 Procédé selon la revendication 6, dans lequel les données à transmettre en continu sont émises par une entité émettπce (SS2) du réseau et le réseau est un réseau sans fil comportant au moins une station de base (BSl) couvrant l'entité émettπce, la requête de modification d'un flux de service (DSC_REQ) est initiée par la station de base et reçue par l'entité émettπce, caractérisé en ce que l' interprétation d'une requête de modification, auprès de l'entité émettπce, conduit à une décision d'adapter les paramètres du service
9 Procédé selon la revendication 6, dans lequel les données à transmettre en continu sont émises par une entité émettπce (SS2) du réseau et le réseau est un réseau sans fil comportant au moins une station de base (BSl) couvrant l'entité émettπce, la requête de modification d'un flux de service (DSC_REQ) est initiée par l'entité émettπce et la station de base renvoie à l'entité émettπce une réponse à la requête de modification (DSCLRSP), caractérisé en ce que F interprétation d'une réponse positive a la requête de modification, auprès de l'entité émettπce, conduit à une décision d'adapter les paramètres du service
10 Procède selon la revendication 1 , caractérisé en ce que le reseau est un reseau sans fil large bande opérant selon la norme IEEE 802 16 U . Procédé selon la revendication 1, caractérisé en ce que lesdites étapes sont réitérées répétitivement pendant le service de transmission de données en continu.
12. Programme informatique comportant des instructions pour la mise en œuvre du procédé selon la revendication 1 , lorsque ce programme est exécuté par un processeur.
13. Programme informatique selon la revendication 12, caractérisé en ce qu'il comporte des instructions d' interfaçage avec la première et la deuxième couche pour la mise en œuvre du procédé selon la revendication 4.
14. Terminal (SS2) de communication, comportant : des moyens de gestion d'une communication de données via un réseau, pour un service de transmission de données en continu (VID STRM), et des moyens de réception de messages pour la gestion de flux de service (SF) issus d'autres entités du réseau (BSl), caractérisé en ce que les moyens de gestion sont agencés pour : collecter les messages de gestion de flux de service, interpréter au moins un desdits messages pour estimer des contraintes courantes du réseau, et décider d'adapter ou non les paramètres du service en fonction des contraintes courantes du réseau.
PCT/FR2010/051127 2009-06-11 2010-06-08 Optimisation d'une communication de données, notamment pour des applications de transmission en continu de données vidéo Ceased WO2010142902A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0953911 2009-06-11
FR0953911 2009-06-11

Publications (1)

Publication Number Publication Date
WO2010142902A1 true WO2010142902A1 (fr) 2010-12-16

Family

ID=41612380

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2010/051127 Ceased WO2010142902A1 (fr) 2009-06-11 2010-06-08 Optimisation d'une communication de données, notamment pour des applications de transmission en continu de données vidéo

Country Status (1)

Country Link
WO (1) WO2010142902A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105532013A (zh) * 2013-07-12 2016-04-27 佳能株式会社 利用推送消息控制的自适应数据流传输方法

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2005041516A2 (fr) * 2003-10-15 2005-05-06 Ntt Docomo, Inc. Appareil et procede de commande de fonctionnement d'une pluralite de couches de communication dans un scenario de communication a couches
EP1901524A1 (fr) * 2006-09-15 2008-03-19 NTT DoCoMo Inc. Appareil pour assister la communication de données entre un moyen de configuration et un moyen de traitement de données pour une optimisation à couches croisées

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2005041516A2 (fr) * 2003-10-15 2005-05-06 Ntt Docomo, Inc. Appareil et procede de commande de fonctionnement d'une pluralite de couches de communication dans un scenario de communication a couches
EP1901524A1 (fr) * 2006-09-15 2008-03-19 NTT DoCoMo Inc. Appareil pour assister la communication de données entre un moyen de configuration et un moyen de traitement de données pour une optimisation à couches croisées

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
KAHN, PENG, STEINBACH, SGROI, KELLERER: "Application-Driven Cross-Layer Optimization for Video Streaming over Wireless Networks", IEEE COMMUNICATION MAGAZINE, vol. january 2006, 31 January 2006 (2006-01-31), pages 122 - 130, XP002567860, Retrieved from the Internet <URL:http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=01580942> [retrieved on 20100210] *
NOORDIN K A ET AL: "Cross-Layer Optimization Architecture for WiMAX Systems", IEEE INTERNATIONAL SYMPOSIUM ON PERSONAL, INDOOR AND MOBILE RADIO COMMUNICATIONS. PIMRC, IEEE; PI, XX, 1 September 2007 (2007-09-01), pages 1 - 4, XP031168569, ISBN: 978-1-4244-1143-6 *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105532013A (zh) * 2013-07-12 2016-04-27 佳能株式会社 利用推送消息控制的自适应数据流传输方法
US10104190B2 (en) 2013-07-12 2018-10-16 Canon Kabushiki Kaisha Adaptive data streaming method with push messages control

Similar Documents

Publication Publication Date Title
EP3238406B1 (fr) Procédé de traitement d&#39;une requête de livraison de données
EP1872543A1 (fr) Procede et systeme de transmission d un flux multicast en reseau d echange de donnees
EP2887743B1 (fr) Procédé de communication dans un réseau de télécommunications sans fil, programme d&#39;ordinateur et noeud de communication sans fil associés
EP3053326B1 (fr) Procédé d&#39;accès d&#39;un utilisateur a au moins un service de communication fourni par l&#39;intermédiaire d&#39;un centre informatique d&#39;un système d&#39;informatique en nuage
FR2925808A1 (fr) Procede de communication dans un reseau comprenant un reseau primaire et un reseau secondaire
FR2945690A1 (fr) Procede et dispositif de parametrage d&#39;un pont au sein d&#39;un reseau de communication.
EP2345210B1 (fr) Gestion de topologie de routage dans un reseau
EP1453276B1 (fr) Dispositif de gestion de communications par sélection de terminaux et de médium de communication
EP1650910B1 (fr) Contrôle des paramètres d&#39;une connexion Ethernet-GMPLS
WO2010142902A1 (fr) Optimisation d&#39;une communication de données, notamment pour des applications de transmission en continu de données vidéo
EP1908259B1 (fr) Appareil et procede d&#39;estimation du taux de remplissage des tampons d&#39;entree de clients d&#39;une distribution de contenu temps reel
FR2894752A1 (fr) Procede d&#39;etablissement de connexion entre des portions d&#39;une application distribuee dans des noeuds connectes a un reseau de communication a plan de controle gmpls
WO2009122071A2 (fr) Procede de gestion de charge d&#39;un equipement d&#39;un systeme de mise en oeuvre d&#39;un service applicatif
FR2933261A1 (fr) Procede de traitement d&#39;une requete, passerelle d&#39;acces et systeme de controle d&#39;admission a un service
EP1515489B1 (fr) Réseau de communications à gestion de trafic par mesures actives configurables
KR20060124402A (ko) 지능형 컨텐츠 분배 방식에 의한 컨텐츠 전송 네트워크시스템
FR2951045A1 (fr) Procede de gestion de la taille de paquets de donnees d&#39;un flux de donnees, produit programme d&#39;ordinateur, moyen de stockage, et tete de tunnel correspondants.
EP1716670B1 (fr) Passerelle et systeme de transmission de donnees pour reseau de diagnostic de vehicule automobile
EP2446608B1 (fr) Technique de contrôle d&#39;accès par une entité cliente à un service
CN103873282A (zh) 一种实现p2p流量优化的方法及装置
WO2023275490A1 (fr) Procede de traitement d&#39;une connexion entre un equipement utilisateur et un equipement distant dans un reseau de communication, procede de controle, dispositifs, satellite, station terrestre, systeme et programmes d&#39;ordinateur correspondants
WO2025133033A1 (fr) Procédés visant à optimiser l&#39;efficacité énergétique d&#39;un équipement utilisateur, entité d&#39;un réseau de télécommunications et équipement utilisateur
FR3019429A1 (fr) Procede et dispositif de controle d&#39;un telechargement de contenus multimedia
WO2024068725A1 (fr) Procédé de gestion du trafic de données entre une entité source et une entité destinataire, entité et programme d&#39;ordinateur correspondants
FR3153713A1 (fr) Procédé d’optimisation de la diffusion d’un contenu multicast au sein d’un réseau de communication mettant en œuvre une pluralité de tranches réseau.

Legal Events

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

Ref document number: 10737960

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 10737960

Country of ref document: EP

Kind code of ref document: A1