Tout d’abord, nous définissons un profil de QoS spécifique à un flux. Un profil est défini par trois critères :
– Le BER (Bit Error Rate ou Taux d’Erreur Binaire) maximum supporté par le flux. Dans ce chapitre, tout comme le précédent, nous supposons que transmettre avec un MCS adapté1 est suffisant pour respecter cette contrainte.
1. Pour chaque utilisateur u, nous considérons qu’un MCS m est adapté si m ≥ mu,k pour tout k alloué à u.
4.1. Vers la quantification de la Qualité de Service 47 Tf densité de pr obabili té t (ms)
P DORf > P DORtargetf
Fig. 4.1 – Exemple de distribution du délai des paquets.
– Le délai maximum toléré par les paquets du flux. Nous notons Tf cette borne (pour le flux f ).
– Le PDOR cible, qui est défini ci-dessous.
Définition 3. Soit Pf(t) l’ensemble des paquets générés par la source du flux f durant l’intervalle [[0, t−1]]. Pour chaque paquet p ∈ Pf(t), nous notons dfp(t) le temps attendu dans le buffer d’émission par le pième paquet du flux f au début du t-ième TTI. Pour finir, nous notons Df(t) =np | df
p(t) > Tfo, l’ensemble des paquets hors-délai du flux f . Le PDOR de ce flux est alors défini par :
P DORf(t) = | Df(t) | | Pf(t) |.
Ainsi, le PDOR correspond au nombre de paquets hors-délais divisé par le nombre total de paquets générés. Le seuil à partir duquel le flux (et donc l’utilisateur) est considéré comme insatisfait est appelé le PDOR cible. Le PDOR cible du flux f est noté P DORtargetf . Il est donc considéré qu’un flux f est satisfait lorsque la condition suivante est vérifiée :
P DORf(t) ≤ P DORtargetf , ∀t. (4.1.1) La Figure 4.1 donne un exemple de la densité de probabilité du délai des paquets pour un flux. Le PDOR du flux f correspond à l’aire orangée sur cette figure. Afin de répondre aux besoins des flux, cette aire doit être inférieure au PDOR cible.
Comparée à une contrainte forte sur les délais (i.e. une contrainte stipulant que tous les paquets doivent être transmis avant l’échéance), notre contrainte sur le PDOR est plus souple. En effet, il est souvent acceptable que quelques paquets soient transmis avec du retard si la plupart des paquets sont délivrés à temps. Par exemple, pour une application de type vidéo-conférence, la perte de quelques paquets n’affecte pas l’expérience de l’utilisateur [84].
De plus, comme notre contrainte est plus souple, l’allocation de ressources peut être réalisée de manière plus flexible. Notons que l’Equation 4.1.1englobe également la contrainte forte sur les délais si on assigne au PDOR cible une valeur de zéro. Le seuil Tf peut également être paramétré pour s’adapter au degré de sensibilité des trafics par rapport au délai maximum supporté.
Enfin, le PDOR permet de limiter d’autres métriques de qualité de service telles que la gigue et le temps d’attente moyen des paquets dans le buffer. Nous donnons un exemple afin de donner une justification intuitive à cette propriété.
Exemple. Soit f un flux utilisateur. Nous supposons dans cet exemple que le délai des paquets est distribué selon une distribution de Rayleigh (comme illustré par la Figure 4.1) avec pour espérance µ et paramètre σ. Si nous supposons également que le taux de paquets hors-délai est inférieur à P DORtargetf , alors l’inégalité suivante est vérifiée : Z +∞ Tf t σ2exp −t2 2σ2 ! dt ≤ P DORtargetf (4.1.2) ⇔ exp −T 2 f 2σ2 ! ≤ P DORtargetf (4.1.3) ⇔ σ ≤ v u u u t Tf2 −2 lnP DORtargetf . (4.1.4)
Comme l’écart type σ0 d’une distribution de Rayleigh est égal à σ r 4−π 2 , alors : σ0≤ Tf v u u t 4 − π −4 lnP DORtargetf . (4.1.5)
Ainsi, l’écart type (i.e. la gigue) est borné par une fonction du PDOR cible. Selon (4.1.5), plus le PDOR cible est faible, plus la gigue sera faible. Par conséquent, si la gigue est une métrique majeure pour un type de flux donné, il est possible de limiter sa valeur en paramétrant le PDOR cible avec une valeur adaptée.
Le raisonnement ci-dessus peut être étendu à d’autres distributions. Si la distribu-tion n’est pas connue (comme nous le supposons dans ce chapitre), il est possible de tester empiriquement différentes valeurs du PDOR cible.
4.1.1 Objectif
L’objectif TFDPS. Dans ce chapitre, nous souhaitons traiter des objectifs per-mettant de fournir de la QoS à travers le temps. Avec un objectif tel que celui présenté dans la section précédente (Objectif 3.1.1), nous pouvons remarquer que l’allocation de ressources effectuée au TTI t aura un impact sur l’état du système aux TTIs t + 1, t + 2, etc... Ainsi, même une succession d’allocations optimales peut mener à de faibles performances globales. De plus, avec des trafics multimédias, cela n’a pas vraiment de sens de considérer le problème sur un seul TTI, puisque les débits de ces trafics varient avec le temps. Nous souhaitons donc intégrer le temps à la formulation du problème.
Pour cela, nous commençons par définir une période de temps.
Définition 4. Soit n ∈ N. Une période de temps est une séquence de TTIs : n + 1, n + 2, . . . , n + T avec T ∈ N la taille de la période.
4.1. Vers la quantification de la Qualité de Service 49 Nous modifions également la définition d’une fonction d’utilité afin d’intégrer les flux au problème. Ainsi, nous notons ϕf(Rf(t) | Nu(t), mu(t)) la valeur de la fonction d’utilité pour le flux f au TTI t, avec :
– Nu(t) l’ensemble des ressources allouées à l’utilisateur u (u étant le propriétaire du flux),
– mu(t) le single MCS de l’utilisateur u, – Rf(t) le débit accordé au flux f .
En effet, la contrainte du single MCS s’applique pour toutes les ressources allouées à un utilisateur (pas uniquement sur les ressources allouées à un flux). En d’autres termes, pour tous les flux de l’utilisateur u, le même MCS est utilisé sur un TTI. D’autre part, nous faisons apparaître explicitement le paramètre Rf dans la fonction d’utilité car une nouvelle contrainte s’applique aux débits des flux. Effectivement, la non-linéarité du calcul du débit rend le paramètre Rf dépendant des allocations réa-lisées pour tous les autres flux de l’utilisateur. C’est à l’ordonnanceur de partager le débit de l’utilisateur u, toujours noté R(Nu, mu), entre tous les flux appartenant à u. Nous appelons ce nouveau problème le LTE UL TFDPS (Joint Time and Frequency Packet Scheduling). Pour chaque utilisateur u et pour chaque TTI t d’une période de taille T , nous cherchons à trouver une allocation (Nu(t), mu(t)) et à calculer en conséquence les débits des flux {Rf(t)}f de façon à :
Maximiser n+T X t=n+1 X u∈U X f ∈Fu ϕf(Rf(t) | Nu(t), mu(t)) , (4.1.6) sujet à : X f ∈Fu Rf(t) ≤ R(Nu(t), mu(t)), ∀u, ∀t (4.1.7)
et les contraintes habituelles de LTE (3.1.1) appliquées à chaque TTI.
Objectif principal. Pour des raisons de concision, nous nous concentrons plus spé-cifiquement sur un objectif permettant de satisfaire les utilisateurs. Afin d’assurer la qualité de service, nous exprimons la fonction d’utilité de l’utilisateur u de la façon suivante (pour le TTI t) :
ϕf(Rf(t) | Nu(t), mu(t)) = (
1 si P DORf(t) ≤ P DORtargetf . 0 sinon.
L’objectif est donc de maximiser le nombre de flux satisfaits (et par conséquent les utilisateurs) :
maximiser Cardn(f, t) | P DORf(t) ≤ P DORftarget, ∀to.
Bien sûr, cet objectif est uniquement cohérent si le débit total des flux est inférieur à la capacité du système. De plus, l’objectif dépend évidemment des débits offerts aux utilisateurs puisqu’un utilisateur satisfait est un utilisateur qui reçoit des données.