ITU-T E 716 FRENCH-1996 User demand modelling in Broadband-ISDN《在宽带综合业务数字网(ISDN)中的用户需求模型 2号研究组 20pp》.pdf

上传人:medalangle361 文档编号:795360 上传时间:2019-02-02 格式:PDF 页数:21 大小:112.91KB
下载 相关 举报
ITU-T E 716 FRENCH-1996 User demand modelling in Broadband-ISDN《在宽带综合业务数字网(ISDN)中的用户需求模型 2号研究组 20pp》.pdf_第1页
第1页 / 共21页
ITU-T E 716 FRENCH-1996 User demand modelling in Broadband-ISDN《在宽带综合业务数字网(ISDN)中的用户需求模型 2号研究组 20pp》.pdf_第2页
第2页 / 共21页
ITU-T E 716 FRENCH-1996 User demand modelling in Broadband-ISDN《在宽带综合业务数字网(ISDN)中的用户需求模型 2号研究组 20pp》.pdf_第3页
第3页 / 共21页
ITU-T E 716 FRENCH-1996 User demand modelling in Broadband-ISDN《在宽带综合业务数字网(ISDN)中的用户需求模型 2号研究组 20pp》.pdf_第4页
第4页 / 共21页
ITU-T E 716 FRENCH-1996 User demand modelling in Broadband-ISDN《在宽带综合业务数字网(ISDN)中的用户需求模型 2号研究组 20pp》.pdf_第5页
第5页 / 共21页
点击查看更多>>
资源描述

1、UNION INTERNATIONALE DES TLCOMMUNICATIONS5)4 4% SECTEUR DE LA NORMALISATIONDES TLCOMMUNICATIONSDE LUIT(10/96)SRIE E: RSEAU TLPHONIQUE ET RNISQualit de service, gestion de rseau et ingnierie dutrafic Ingnierie du trafic Ingnierie du trafic RNIS-ODLISATION DE LA DEMANDE USAGER DANS LE2.)3 LARGE BANDER

2、ecommandation UIT-T E.716(Antrieurement Recommandation du CCITT)RECOMMANDATIONS UIT-T DE LA SRIE E2 3%!5 4 , 0(/.)15% %4 2.)3Pour plus de dtails, voir la Liste des Recommandations de lUIT-T.%80,/)4!4)/. .5- 2/4!% !#(%-).%-%.4 %4 3%26)#% -/“),%EXPLOITATION DES RELATIONS INTERNATIONALES E.100E.229DISP

3、OSITIONS OPRATIONNELLES RELATIVES LA TAXATION ET LACOMPTABILIT DANS LE SERVICE TLPHONIQUE INTERNATIONALE.230E.299UTILISATION DU RSEAU TLPHONIQUE INTERNATIONAL POUR LESAPPLICATIONS NON TLPHONIQUESE.300E.329DISPOSITIONS DU RNIS CONCERNANT LES USAGERS E.330E.39915!,)4 $% 3%26)#% %34)/. $% 2 3%!5 %4 ).

4、.)%2)% $5 42! tous les utilisateurs de la prsente Recommandation sontdonc invits rechercher la possibilit dappliquer les ditions les plus rcentes desRecommandations et autres rfrences indiques ci-aprs. Une liste des Recommandations UIT-T envigueur est publie rgulirement. Recommandation E.711 du CCIT

5、T (1992), Modlisation de la demande de lusager. Recommandation UIT-T E.7351, Cadre gnral de rgulation du trafic et dedimensionnement du RNIS large bande. Recommandation UIT-T E.7361, Mthode de la rgulation de trafic au niveau cellule pourle RNIS large bande. Recommandation UIT-T E.7371, Mthodes de d

6、imensionnement pour le RNIS large bande. Recommandation UIT-T I.150 (1995), Caractristiques fonctionnelles du mode de transfertasynchrone du RNIS large bande. Recommandation UIT-T I.210 (1993), Principes des services de tlcommunication assurspar un RNIS et moyens permettant de les dcrire. Recommanda

7、tion UIT-T I.311 (1996), Aspects gnraux du rseau pour le RNIS largebande. Recommandation UIT-T I.361 (1995), Spcifications de la couche mode de transfertasynchrone pour le RNIS large bande. Recommandation UIT-T I.371 (1996), Gestion du trafic et des encombrements dans le RNIS large bande._1Actuellem

8、ent ltat de projet.2 Recommandation E.716 (10/96)3 DfinitionsIl est utile de clarifier lutilisation des termes de “connexion ATM“ et “dappel“, faite dans la prsenteRecommandation, avant de spcifier les concepts fondamentaux tels que les attributs dun appel ou ledroulement dun appel. Une “connexion A

9、TM“ fait rfrence soit une connexion de voievirtuelle (VCC) ou une connexion de conduit virtuel (VPC), se rfrer la Recommandation I.150.Une connexion VCC ou une connexion VPC peut se faire de point point ou de point multipoint.Une connexion VCC ou une connexion VPC est une connexion avec communicatio

10、nunidirectionnelle, cest-dire avec une seule direction de transmission2.Un appel se constitue dau moins deux connexions ATM: une connexion VCC dans chaque directionou une connexion VPC dans chaque direction. Un appel peut se constituer de connexions ATMmultiples dans chaque direction dune configurat

11、ion point point ou vers chaque point determinaison dune connexion multipoint. Une communication multimdia peut, par exemple, utiliserdans chaque direction une connexion ATM pour une visioconfrence et une autre pour le transportde fichiers de donnes.4 AbrviationsLa prsente Recommandation utilise les

12、abrviations suivantes.ATM mode de transfert asynchrone (asynchronous transfer mode)B-ISUP sous-systme utilisateur du RNIS large bande (broadband ISDN user part)CAC commande dadmission de connexion (connection admission control)CLP priorit de perte de cellule (cell loss priority)CPE quipement des loc

13、aux client (customer premises equipment)NPC commande de paramtre de rseau (network parameter control)QS qualit de serviceRNIS-LB rseau numrique intgration de services large bandeSTD descripteur de trafic source (source traffic descriptor)UNI interface utilisateur-rseau (user-network interface)UPC co

14、mmande de paramtre dutilisation (usage parameter control)VC voie virtuelle (virtual channel)VCC connexion de voie virtuelle (virtual channel connection)VCI identificateur de voie virtuelle (virtual channel identifier)VP conduit virtuel (virtual path)VPC connexion de conduit virtuel (virtual path con

15、nection)VPI identificateur de conduit virtuel (virtual path identifier)_2Il convient de noter, comme cela est spcifi dans la Recommandation I.150, quil existe deux sens detransmission au niveau dune interface RNIS-LB. Quand une valeur du champ de routage un identificateurde conduit virtuel (VPI, vir

16、tual path identifier) pour une connexion VPC ou un identificateurVPI/identificateur de voie virtuelle (VPI/VCI, virtual channel identifier) pour une connexion VCC estattribue une liaison de conduit virtuel ou de voie virtuelle, la mme valeur est attribue chaque sensde la transmission. Les caractrist

17、iques du trafic et les ressources attribues pour chaque sens decommunication peuvent tre les mmes ou tre diffrentes. La largeur de bande dans lun des sens peuttre nulle (communication unidirectionnelle sans information en retour). Elle peut aussi correspondre lalargeur suffisante qui permet de trans

18、porter les informations de gestion de la couche ATM(communication unidirectionnelle avec informations de gestion en retour).Recommandation E.716 (10/96) 35 IntroductionLa Recommandation E.711 traite de la modlisation de la demande de lusager dans le RNIS. Laprsente Recommandation est centre principa

19、lement sur les aspects de la modlisation de lademande de lusager qui sont spcifiques dun RNIS large bande utilisant le mode de transfertasynchrone (ATM) et rsume la Recommandation E.711 pour ceux des aspects qui sont communsau RNIS bande troite et au RNIS large bande.Lexpression “demande de lusager“

20、 dsigne les demandes de services de tlcommunication utilisantles moyens du rseau, faites par lusager afin de satisfaire ses besoins de transfert dinformation.Elle dsigne non seulement les demandes faites par lusager, mais galement les demandes quecelui-ci reoit de la part dautres usagers dsirant com

21、muniquer avec lui. La demande de lusager semanifeste au niveau de linterface utilisateur-rseau (UNI) par laction de son quipement CPE et decelle de lquipement CPE de lautre usager impliqu dans lappel, dune manire qui dpendragalement des caractristiques des quipements CPE mis en jeu.La prsente Recomm

22、andation traite de la caractrisation de la demande de lusager telle quelle semanifeste au niveau de linterface UNI. Pour le propos de la modlisation, la demande de lusager auniveau de linterface UNI sera reprsente sous la forme dun processus darrives de diffrents typesde “demandes dappel“3. Il sensu

23、it que la caractrisation de la demande de lusager exige: la caractrisation des types de demandes dappel gnres et reues par lusager, traite parlarticle 6; la caractrisation du processus darrive des diffrents types de demandes dappel, traite parlarticle 7.La prsente Recommandation identifie des paramt

24、res utiliss dans ces processus de caractrisation.Les paramtres choisis sont ceux qui ont un effet sur les performances du rseau et qui, enconsquence ont une pertinence pour la modlisation du trafic que lusager prsente au rseau, enparticulier la couche ATM dans le plan utilisateur, la couche de signa

25、lisation (couche 3 de lasignalisation Q.2931 et couche 4 pour la partie utilisateur B-ISUP) et aux couches de niveau infrieursitues dans le plan de commande.Lobjet de la prsente Recommandation est de prsenter des paramtres qui sont importants pour ladfinition des mthodes de dimensionnement et pour l

26、es algorithmes de rgulation du trafic (ycompris les algorithmes de rgulation de ladmission de connexion). La prsente Recommandationfournit aux oprateurs de rseaux un guide pour la dtermination de ceux des paramtres quil estncessaire destimer laide de mesures ou dautres moyens, en vue de leur utilisa

27、tion commeinformation dentre pour le dimensionnement ou la rgulation du trafic. La faon dont cesparamtres sont utiliss ces fins nest pas traite par la prsente Recommandation, mais par lesRecommandations des sries E.730 et E.740._3Il convient de noter quon considre comme phnomne de base de la demande

28、 de lutilisateur, la demandedappel (cest-dire, la demande dtablissement dun appel) et non lappel ou la tentative dappeltraditionnellement utiliss. Contrairement lappel, la demande dappel comprend toutes les tentativesncessaires dans la phase dtablissement de lappel. Une squence de tentatives sans ab

29、outissement finalest galement considre comme tant une demande dappel.4 Recommandation E.716 (10/96)6 Modlisation dune demande dappel6.1 GnralitsLa demande dappel est la manifestation fondamentale de la demande de lusager au niveau delinterface UNI. Une demande dappel se constitue:1) de la squence de

30、 tentatives dappel faites par lusager ou par son quipement CPE;2) de lappel qui sensuit si la tentative aboutit.Du point de vue de lingnierie de trafic, une demande dappel est dfinie par un ensemble dattributsdappel et par une structure dappel4: les attributs dappel sont les attributs de la demande

31、dappel qui identifient les ressources durseau dont a besoin la demande dappel, aussi bien dans le plan utilisateur que dans le plande commande; les attributs dfinissent les connexions ncessaires et la manire dont ellessont tablies; la plupart des attributs de lappel correspondent aux attributs dfini

32、s dans laRecommandation I.210; la structure de lappel est dfinie sous la forme dune squence dvnements au niveau delinterface utilisateur-rseau et des intervalles de temps qui sparent ces vnements.La structure de lappel et les attributs de lappel doivent suffire dfinir leffet de lappel sur laperforma

33、nce du rseau et pour quantifier les ressources qui doivent tre alloues lappel ainsi que ladure doccupation de ces ressources.6.2 Attributs de lappelComme indiqu dans 6.1, les attributs de lappel sont dfinis par un ensemble de valeurs dattributsidentifiant les ressources requises par la demande dappe

34、l. Ces attributs sont les suivants: tablissement de la communication (par des fonctions du plan de commande ou desfonctions du plan de gestion, dune manire semi-permanente, la demande ou surrservation); configuration de communication (point point, multipoint, diffusion, nombre et localisationdes poi

35、nts); nombre de connexions ATM dans chaque direction entre chaque couple de points; utilisation de connexions de voie virtuelle (VCC) ou de connexions de conduit virtuel (VPC)dutilisateur utilisateur5; les composantes du contrat de trafic (voir la Recommandation I.371) de chaque connexionATM, compor

36、tant:1) le descripteur de trafic source;_4Le terme “attributs dappel“ a le mme sens que le terme “caractristiques de connexion“ utilis dans laRecommandation E.711. Ce changement de terme a pour but de souligner quil sagit des caractristiquesou des attributs de la totalit de la demande dappel et non

37、simplement de lune de ses connexions. Poursimplifier, on utilise les termes “attributs dappel“ et “structure dappel“ au lieu “dattributs de demandedappel“ et de “structure de demande dappel“. De plus, toujours pour simplifier, si lappel a t tabli, leterme “appel“ sera frquemment utilis la place de “

38、demande dappel“.5Quand une connexion VPC dutilisateur utilisateur est tablie, le rseau est transparent aux connexionsVCC tablies par lutilisateur lintrieur de cette connexion VPC. Dans ce cas, on considrera alors, dansle contexte de la prsente Recommandation, que lappel est constitu des connexions V

39、PC dutilisateur utilisateur en jeu, mais que les connexions VCC individuelles ne constituent pas un appel.Recommandation E.716 (10/96) 52) la tolrance de variation de retard de cellule;3) la classe de qualit de service; les couches 1 3 du protocole daccs de signalisation (il nexiste lheure actuelle

40、que laseule classe de protocole Q.2931 pour laccs de signalisation); les services complmentaires; la liste des services complmentaires qui sont significatifs dupoint de vue de lingnierie de trafic appelle une tude ultrieure.En pratique, seuls certains des attributs mentionns ci-dessus sont significa

41、tifs lorsquunemodlisation de la demande dappel est effectue pour une activit donne dingnierie de trafic.6.3 Structure de lappel et variables de traficComme indiqu dans 6.1, la structure dune demande dappel est dfinie sous la forme dunesuccession dvnements au niveau de linterface utilisateur-rseau et

42、 des intervalles de tempssparant ces vnements.La structure de lappel est dcrite par un ensemble de variables de trafic, exprimes sous formestatistique, cest-dire sous la forme de variables alatoires ou sous la forme de paramtres lis ladistribution de variables alatoires. Ceci permet de modliser une

43、grande varit de demandesdappel au moyen dune mme structure de lappel. Les demandes dappel qui ont les mmes typesdvnements, mais avec des occurrences diffrentes (par exemple le nombre de renouvellement destentatives) ou avec des diffrences de dures (par exemple la dure doccupation), peuvent tremodlis

44、es par une mme structure de lappel.Il est possible de distinguer deux types de variables de trafic: les variables de trafic dappel et lesvariables de trafic de cellule6. Elles dcrivent toutes deux des successions dvnements au niveau delinterface utilisateur-rseau et les intervalles de temps entre ce

45、s vnements, mais la dfinition delvnement est diffrente dans chaque cas. pour les variables de trafic dappel, un vnement reprsente la transmission sur linterfaceutilisateur-rseau dune cellule ATM qui conclut un message de signalisation correspondantaux phases dtablissement, de rengociation et de dcon

46、nexion de lappel; lvnement estdfini la fois par linstant darrive de la cellule et par le contenu du message designalisation; pour les variables de trafic de cellule, un vnement reprsente la transmission sur linterfaceutilisateur-rseau dune cellule ATM quelconque; lvnement est dfini par les informati

47、onssuivantes: instant darrive de la cellule, la relation avec lappel auquel appartient la cellule,le type de charge utile et la valeur du bit dindication CLP.NOTES1 La dfinition de variables de trafic dappel lies la transmission de messages de signalisation travers linterface UNI ne sapplique quaux appels tablis par des fonctions du plan de commande. Ladfinition pour les appels tablis par des fonctions du plan de gestion appelle une tude ultrieure.2 En cas dencombrement dans le rseau au niveau de la ce

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 标准规范 > 国际标准 > 其他

copyright@ 2008-2019 麦多课文库(www.mydoc123.com)网站版权所有
备案/许可证编号:苏ICP备17064731号-1