Bla

SOCIETE NATIONALE DES TELECOMMUNICATIONS

(TUNISIE TELECOM)

---------°°°°°°-----------

CONSULTATION N°…

POUR

CAHIER DES CLAUSES TECHNIQUES

LA FOURNITURE, L’INSTALLATION, LE TEST ET LA MISE EN

PLACE D’UNE PLATE-FORME RING BACK TONE

POUR LES ABONNES AU RESEAU MOBILE

DE TUNISIE TELECOM

SOMMAIRE

CHAPITRE I : Généralités ............................................................................................................. 5 1. Objet .......................................................................................................................................................................... 5

2. Portée de la commande ............................................................................................................................ 5 3. Conditions générales ................................................................................................................................................ 5

CHAPITRE II : MODELE DE PAIEMENT, ETATS D’ABONNES RBT, ETATS TONALITE RBT ..... 8

1. Modèle de paiement ......................................................................................................................................................... 8

2. Etats d’une tonalité RBT ................................................................................................................................................. 8 2.1 Tonalité en instance .................................................................................................................................................. 8

2.2 Tonalité rejetées ........................................................................................................................................................ 8

2.3 Tonalités approuvées ................................................................................................................................................ 8

3. Périodes de validité d’une tonalité RBT ........................................................................................................................ 8 3.1 Période de validité absolue (date limite de droit d’utilisation d’une tonalité RBT) ........................................... 8

3.2 Période de validité relative d’une tonalité RBT ..................................................................................................... 8

4.Etats d'un abonné RBT…………………………………………………………………………………………………11

4.1 Abonné RBT actif ..................................................................................................................................................... 9

4.2 Abonné RBT suspendu............................................................................................................................................. 9

4.3 Abonné RBT désactivé ............................................................................................................................................. 9

4.4 Abonné RBT désinscrit du service .......................................................................................................................... 9

CHAPITRE III : FONCTIONNALITES DU SERVICE RBT ..................................................................... 11 I. Fonctionnalités dédiées aux abonnés résidentiels ................................................................................................ 11

II. Fonctionnalités dédiées aux administrateurs RBT de l’entreprise (RBT corporate) ....................................... 15

III. Fonctionnalités dédiées à l’administrateur de la plate-forme RBT ................................................................... 16

IV. Fonctionnalités réservées au fournisseur de contenu .......................................................................................... 18

V. Fonctionnalités réservées au service Customer Care .......................................................................................... 19

CHAPITRE IV : INTERFACES UTILISATEURS ...................................................................................... 21 1. Interface Web ........................................................................................................................................................... 21 2. Interface WAP .......................................................................................................................................................... 22 3. Interface SMS ........................................................................................................................................................... 22 4. Interfaces USSD ....................................................................................................................................................... 23 5. Interface IVR ............................................................................................................................................................ 23

CHAPITRE V : TAXATION ET FACTURATION DU SERVICE RBT ................................................... 26 1. Conditions générales ................................................................................................................................................ 26 2. Taxation/facturation des abonnés RBT résidentiels mobiles................................................................................ 26 2.1 Cas des abonnés prépayés........................................................................................................................................ 27 2.2 Cas des abonnés post-payés ..................................................................................................................................... 27 3. Facturation des abonnés Corporate mobiles ......................................................................................................... 27

CHAPITRE VI : ARCHITECTURE ET INTERFACES DE LA PLATE-FORME RBT ......................... 29 1. Composants de la plate-forme RBT ........................................................................................................................ 29

2. Architecture d’intégration, Interfaces et Interfonctionnement ............................................................................ 31

2.1 Architecture ............................................................................................................................................................. 31

2.2 Interfaces avec les différents nœuds du réseau de Tunisie Télécom ................................................................... 31

3. Logique d’un appel RBT .......................................................................................................................................... 32

3.1 Cas d’un appel entrant vers un abonné ON-NET mobile ................................................................................... 32

3.2 Cas où l’appelé B active le service de transfert d’appel ...................................................................................... 33

3.3 Cas où l’appelé B active le service double appel (ou appel en attente) .............................................................. 33

4. Dimensionnement ...................................................................................................................................................... 33

5. Redondance ............................................................................................................................................................... 34

6. Capacité sur les interfaces ........................................................................................................................................ 34

7. Interfaces TCP/IP ..................................................................................................................................................... 35

8. Sécurité du Système .................................................................................................................................................. 35

CHAPITRE VII : EXPLOITATION, ADMINISTRATION ET MAINTENANCE .................................. 36 1. Gestion et maintenance de la plate-forme RBT ...................................................................................................... 36

2. Fonction de Gestion .................................................................................................................................................. 36

3. Equipements de gestion et de maintenance............................................................................................................. 39

4. Fiabilité ...................................................................................................................................................................... 40

5. Disponibilité générale ............................................................................................................................................... 41

CHAPITRE VIII : PRESTATIONS .............................................................................................................. 42 1. Prestations d’installation et de mise en service....................................................................................................... 42

2. Documentation .......................................................................................................................................................... 42

3. Formation .................................................................................................................................................................. 43

4. Assistance technique……………………………………………………………………………………………….. 47

5. Assistance commerciale ............................................................................................................................................ 46

6. Maintenance et pièces de rechanges ........................................................................................................................ 46

7. Planning de mise en service ...................................................................................................................................... 47

8. Climatisation ............................................................................................................................................................. 47

9. Tableau de conformité .............................................................................................................................................. 47

LISTE DES ABBRÉVIATIONS

Abonné A L’Abonné qui émet l’appel, ou qui initie un acte

Abonné B

ASN.1

ATM

L’Abonné destinataire de l’appel ou récepteur de l’acte

Abstract Syntax Notation One

Asynchronous Transfert Mode

CDR Call Detail Record

Diameter Diameter est un protocole de base destiné à fournir une plate-forme AAA

EMM Ericsson Multi Mediation

ETSI GIF

European Telecommunications Standards Institute

Graphic Interchange Format

GSM JPEG

Global System for Mobile communications

Joint Photographic Experts Group

HLR

INAP INS

Home Location Register

Intelligent Network Application Part

Intelligent system

IMSI

IP International Mobile Subscriber Identity

Internet Protocol

ISUP ISDN User Part

IVR

MAP MIB

Interactive Voice Response

Mobile Application Part

Management Information Base

MSISDN MSS

MPEG

NGN

Mobile Subscriber Integrated Services Digital Network Number

Mobile Soft Switch

Moving Picture Experts Group,

Next Generation Network

OSS PGS

Operation Sub System

Personalized Greeting Service

RI RBT

Réseau Intelligent

Ring Back Tone

SMPP Short Message Peer to Peer Protocol

SMSC Short Message Service Center

TCP/IP Transmission Control Protocol over Internet Protocol

USSD Unstructured Supplementary Service Data

VAS

VXML

WAP

Value Added Services

Voice XML

Wireless Application Protocol

http://fr.wikipedia.org/wiki/Joint_Photographic_Experts_Group

http://en.wikipedia.org/wiki/Home_Location_Register

5 Consultation N°… pour l’installation, le test et la mise en place d’une plateforme RBT

CHAPITRE I : GENERALITES

1. Objet

La présente consultation a pour objet la fourniture, l’installation, le test et la mise en place d’une plateforme

Ring Back Tone (RBT) pour les abonnés prépayés, post payés au réseau mobile ainsi qu’aux abonnés

en roaming de Tunisie Télécom.

Le présent cahier des spécifications techniques définit les exigences d’ordre technique et fonctionnel de

Tunisie Télécom quant aux fournitures et prestations attendues du soumissionnaire.

2. Portée de la commande

Tunisie Télécom se propose d’acquérir une plate-forme RBT permettant aux abonnés prépayés, post-payés,

résidentiels et Corporate au réseau mobile de Tunisie Télécom ainsi qu’aux abonnés mobiles en roaming de

bénéficier du service Ring Back Tone (RBT).

La solution proposée doit être capable de s’intégrer au réseau de Tunisie Télécom dans ses différentes

phases à savoir, TDM, phase transitoire TDM-NGN et 100% NGN.

La plateforme RBT doit être capable de s’interfacer au réseau Mobile actuel de Tunisie Télécom via SS7 et

avec le réseau NGN mobile de Tunisie Télécom via SIGTRAN.

A cet effet, le soumissionnaire doit proposer une offre financière et technique complète (architecture, listes

de matériels, licences de services, licences logicielles, prestations, délai de réalisation, etc.) tels que définis

dans le présent cahier des charges et ce, conformément à la méthode d’implémentation « IN-Based sans

tromboning ».

Le programme d’équipements et prestations, objet du présent marché, porte notamment sur:

La fourniture du matériel et des logiciels,

La fourniture des licences de service RBT et Multimédia RBT,

L’installation et la configuration du système,

L’installation et le paramétrage des logiciels,

L’installation et l’activation des fonctionnalités,

La gestion et la maintenance des services,

Le support technique,

L’intégration et l’adaptation avec le réseau existant de TUNISIE TÉLÉCOM,

La cohabitation des solutions RBT proposées à la fois dans un environnement TDM et NGN

La Migration de la solution du TDM vers NGN

La formation du personnel de TUNISIE TÉLÉCOM,

Les prestations d’installation, de test, de réception et de mise en service ainsi que toutes les

sujétions nécessaires au bon fonctionnement du réseau.

Les prestations d’assistance technique et commerciale.

La maintenance des équipements de la plateforme fournie.

3. Conditions générales

3.1 Généralités

1. Tunisie Télécom entend acquérir des systèmes complets, suffisamment dimensionnés et en service.

2. Le système attendu doit être une solution complète et clé en main.

3. Le système proposé doit être, à la date limite de remise de l’offre, disponible, testé et commercialisé.

4. Toute fonctionnalité ou caractéristique demandée dans ce document doit être offerte et supportée par le

système proposé tel qu’ils seront fourni en cas d’adjudication indépendamment du fait que cette

fonctionnalité ou cette caractéristique soit « de base » ou « optionnelle » vis-à-vis du soumissionnaire.


5. Le soumissionnaire donnera toutes les spécifications, marques, caractéristiques techniques et

mécaniques ainsi que la documentation complète de tous les équipements, matériels ou logiciels proposés

dans son offre.

6. Le système proposé doit être modulaire. A cet effet, le soumissionnaire est tenu à indiquer la position,

le rôle et la réalisation des entités physiques (architecture matérielle de la solution) ainsi qu’à identifier les

différents modules logiciels composant le système proposé.

7. Tout oubli d’un élément quelconque nécessaire au bon fonctionnement du système sera pris en charge

par le soumissionnaire.

8. Tout équipement, matériel ou logiciel nécessaire au fonctionnement, à l’exploitation, à la surveillance,

à la maintenance et à la gestion des systèmes proposés dans les meilleures conditions doit être inclus dans

l’offre.

9. Tunisie Télécom ne fournira, dans le cadre de ce projet, que les liens de transmission, les lignes Frame

Relay, les lignes téléphoniques ou lignes spécialisées, l’accès VPN et la connectivité IP, au cas où ils sont

disponibles, l’énergie primaire sous la forme de la basse tension triphasée 220/380V 50 Hz plus ou moins

10% et 5% respectivement ainsi que la climatisation de la salle qui abritera la plate-forme RBT.

10. L’installation, le fonctionnement, le test et la mise en service des systèmes proposés ne doivent en

aucun cas perturber le fonctionnement des équipements du réseau de Tunisie Télécom en service.

11. Dans le cas d’extensions éventuelles, correction et/ou des changements de configuration seraient

bénéfiques à Tunisie Télécom, le soumissionnaire est dans l’obligation d’en informer Tunisie Télécom tout

en précisant les effets de ces changements sur la qualité et la continuité du service. Avant chaque extension

ou correction et/ou changement, une documentation complète doit être fournie à Tunisie Télécom pour

convenir au travail à effectuer.

12. La modification des fonctionnalités existantes et l’introduction de nouvelles fonctionnalités doivent être

possibles sans aucun changement dans l’architecture et la structure du système et sans perturbation majeure

du service.

13. Le soumissionnaire doit indiquer clairement la politique de sécurité réseau adoptée pour assurer la

protection du réseau de son système contre les attaques et les intrusions extérieures. Il doit fournir à Tunisie

Télécom l’architecture détaillée du réseau de son système. Toute modification ultérieure du réseau doit

s’accompagner d’une modification du document.

14. Le soumissionnaire doit détailler pour chaque entité du système les paramètres décrivant les conditions

d’environnement (température, humidité, pression, résistance aux vibrations).

15. La plate-forme proposée doit supporter au moins la langue arabe, la langue française et la langue

anglaise dans les caractères des messages courts de notification.

16. La solution RBT proposée doit être implémentée selon la méthode « IN- Based sans tromboning » se

basant sur

le composant PGS/INS d’Ericsson intégrable sur le réseau intelligent mobile de Tunisie Télécom

une plate-forme de gestion de contenu RBT.

Toute la documentation relative à la solution proposée doit être présentée à l’appui.

17. Il appartient au soumissionnaire de prendre toutes les dispositions nécessaires (techniques et

financières) à la connexion des équipements proposés au réseau mobile de Tunisie Télécom en cours

d’exploitation. Ces dispositions incluent bien entendu le fait de se procurer, d’étudier, de s’adapter aux

spécifications techniques des équipements en cours d’exploitation.

18. Le système proposé doit être capable de s’interconnecter à un réseau 3G ou à un réseau conforme 3GPP

R4 et ce, sans changement de matériels. Le soumissionnaire doit indiquer clairement les actions à

entreprendre afin d’assurer cette interconnexion.

19. La plate-forme RBT proposée doit être capable de fonctionner sur un environnement hybride TDM et

NGN et ce, pendant la phase de migration du réseau mobile de Tunisie Télécom vers NGNs. Durant cette


phase aucune dégradation de la performance du service et des fonctionnalités existantes n’est tolérée.

L’architecture d’intégration de la solution proposée dans le réseau de Tunisie Télécom pendant la phase de

migration vers NGN doit être conforme à l’Annexe 3.

20. Le soumissionnaire s’engage à fournir les dernières versions opérationnelles à la date de livraison pour

les logiciels indépendamment des versions mentionnées dans l’annexe technique de sa soumission et ce, sur

la base des prix contractuels. Le soumissionnaire prendra à sa charge toutes les modifications résultant du

changement de la version logicielle.

21. Le système proposé doit être extensible vers des capacités plus importantes et ce, sans rajout de

matériel (uniquement augmentation en droit d’usage).

22. Le soumissionnaire doit détailler clairement les possibilités d’extension de la plate-forme proposée

ainsi que les modifications qu’il serait appelé à effectuer sur le système proposé, et ce, sur la base d’une

documentation complète fournie à TUNISIE TELECOM décrivant clairement les principes et les

procédures à appliquer pour convenir au travail à effectuer.

23. Le soumissionnaire doit présenter le roadmap de développement des nouvelles fonctionnalités de son

système ainsi que celles relatives aux évolutions matérielles, logicielles ou d’architecture, ou encore aux

évolutions des interfaces.

24. Dans le cas particulier où le soumissionnaire prévoit une modification matérielle, logicielle, de

prestation ou d’architecture intervenant dans les deux premières années d’exploitation de la plate-forme, il

fournira dans son offre une documentation spécifique à cette évolution, tout en précisant son impact sur

l’ancienne génération et les modifications à apporter pour sa mise à niveau.

3.2 Références aux normes internationales et protocoles supportés

1. La solution proposée doit être conforme à toutes les spécifications techniques de l’ETSI qui lui sont

applicables et les recommandations de l’UIT relatives à la signalisation SS7 (livre bleu 1989 et blanc

1993). Dans ce document, les références à des recommandations, des avis, des prescriptions ou des

spécifications concernent toujours les dernières versions en vigueur.

2. La solution proposée doit être conforme à toutes les recommandations de l’IETF (RFC 2719) relative au

transport de la signalisation au dessus de l’IP (SIGTRAN).

3. La solution proposée doit supporter l’intégration à un réseau conforme 3GPP R99 et 3GPP R4 relatives

à la spécification de la norme UMTS 3G.

Et ce, sans changement de matériel. Le soumissionnaire doit indiquer clairement les actions à entreprendre

pour assurer cette intégration.

4. La plateforme proposée doit supporter au moins les codecs audio suivants : G711, G722, G723, G726,

G729, AMR, Alaw, μlaw.

5. La plateforme proposée doit supporter au moins les formats image suivants : JPEG, GIF

6. La plateforme proposée doit supporter au moins les codecs vidéo suivants : MPEG4, H.263 et H.264


CHAPITRE II : MODELE DE PAIEMENT, ETATS D’ABONNES

RBT, ETATS TONALITE RBT

1. Modèle de paiement

1.1. La plate-forme RBT doit permettre à l’administrateur du système de configurer d’une manière flexible

le modèle de paiement à adopter (service RBT avec ou sans frais fixes d’activation du service, frais de

téléchargement de tonalité RBT avec ou sans période de validité, etc.).

1.2. La plate-forme de gestion de contenu RBT doit permettre à l’administrateur du système de définir

différents modèles de paiement et ce, selon le type des abonnés mobiles cibles (résidentiels TT, ou

corporate TT, abonnés en roaming.), et en fonction de leurs modes de paiement (prépayés ou post-payés).

1.3. A cet effet, le soumissionnaire doit fournir toute la documentation possible relative à la définition des

différents modèles de paiement ainsi que le cycle de vie des abonnés RBT associé à chaque modèle de

paiement.

2. Etats d’une tonalité RBT

Toutes les tonalités chargées sur le système doivent être soumises à un processus d’approbation dont le

principe est explicité en détail dans le chapitre III, paragraphe III.4 du présent cahier des charges. Le

processus d’approbation fait ressortir les 3 états de tonalités suivants :

2.1 Tonalité en instance

2.1.1 Une tonalité en instance est une tonalité qui a été téléchargée par le fournisseur de contenu sur le

système (upload) et devra être approuvée ou désapprouvée par l’administrateur de la plate-forme.

2.1.2 Pendant cette phase de suspension, le fournisseur de contenu n’a pas le droit d’accéder à ces tonalités.

A cet état, l’administrateur peut approuver ou rejeter la tonalité. Le fournisseur de contenu est alors notifié

par é-mail, ou par SMS de la décision de l’administrateur.

2.2 Tonalité rejetées

Une tonalité rejetée est une tonalité non approuvée par l’administrateur et par la suite, elle ne sera pas

publiée sur la plate-forme.

2.3 Tonalités approuvées

Une tonalité approuvée est une tonalité acceptée par l’administrateur et prête à être publiée sur le système

et par la suite utilisée.

3. Périodes de validité d’une tonalité RBT

Le système proposé doit définir deux types de périodes de validité des tonalités RBT :

4.1 Période de validité absolue (date limite de droit d’utilisation d’une tonalité RBT)

i. Chaque tonalité RBT publiée sur le système doit avoir une date de fin des droits d’utilisation.

ii. La date de fin des droits d’utilisation fait l’objet d’un accord entre l’administrateur de la plate-forme

et le fournisseur de contenu.

iii. A l’issu de cette date, le contenu ne sera plus disponible sur les canaux d'accès au service exigé par

le présent cahier des charges et qui sont : Web, WAP, IVR, SMS et USSD.

iv. La plateforme RBT doit notifier l’administrateur par é-mail ou par SMS X jours (X paramétrable

par l’administrateur) avant l’expiration de la période de validité absolue des tonalités RBT.

4.2 Période de validité relative d’une tonalité RBT

i. C’est la période pendant laquelle une tonalité RBT peut être utilisée après son téléchargement par

l’abonné dans sa propre librairie RBT.


ii. Une fois la période de validité relative d’une tonalité RBT arrive à sa fin, la plate-forme RBT doit

être capable de notifier l’abonné (par SMS, par email) de cet évènement et que la tonalité serait

renouvelée automatiquement par le système à moins que l’abonné renonce à cette action (arrêt du

renouvellement) et ce, par l’appel d’un numéro court pour les abonnés ON-NET en local ou d’un

numéro long pour les abonnés ON-NET en roaming.

iii. Le renouvellement de sa tonalité RBT devrait être possible par les différents canaux d’accès à la

plate-forme RBT (Web, WAP, SMS, IVR et USSD)

iv. La valeur de cette durée de validité relative doit être fixée par l’administrateur de la plate-forme une

fois la tonalité est approuvée sur le système.

v. Le système ne doit rendre visible que les tonalités RBT qui puisse être utilisées pendant au moins la

période de validité relative et avant la date limite de droit d’utilisation.

4. Etats d’un abonné RBT

La plateforme proposée doit permettre à l’administrateur du système de définir le cycle de vie d’un

abonné RBT dont les états doivent être comme suit :

4.1 Abonné RBT actif

Un abonné RBT à l’état « actif » est un abonné qui peut bénéficier des fonctionnalités proposées par

la plateforme RBT (achat, offre de tonalité RBT, copie de tonalité RBT, etc.). En l’appelant, ses

contacts entendent la tonalité RBT qu’i leur a réservée.

La période pendant laquelle un abonné RBT est à l’état « actif » (période de validité du service RBT)

doit être configurable par l’administrateur du système.

La plateforme RBT doit allouer une licence d’utilisation du service RBT à chaque abonné RBT à

l’état « actif ».

4.2 Abonné RBT suspendu

Un abonné RBT « suspendu » est abonné dont la date de validité de son compte RBT a expiré et qui

n’a pas encore renouvelé le service RBT ce, durant une période de grâce (ou période de suspension)

dont la durée est configurable par l’administrateur du système.

Durant la période de grâce, l’abonné sera dépourvu de toutes les fonctionnalités RBT. En l’appelant

ses contacts entendent la tonalité traditionnelle de l’IUT.

Le profile d’un abonné RBT à l’état « suspendu » reste intacte au niveau de la plateforme RBT, et ce,

en vue de le recharger suite au renouvellement du service par l’abonné en question.

4.3 Abonné RBT désactivé

Un abonné RBT à l’état « désactivé » est un abonné actif qui a initié la suspension de fonctionnalité

de jeu de la tonalité de retour RBT pour ses appelants et ce, pendant la période de validité de son

service.

Le profile d’un abonné RBT à l’état « désactivé » reste intact au niveau de la plateforme RBT et ce,

en vue de le recharger suite à une requête de réactivation du service.

La durée maximale de sauvegarde des données d’un abonné à l’état « désactivé » doit être

configurable par l’administrateur de la plateforme RBT.

Un abonné désactivé a tout les droits de personnaliser son compte RBT et d’exécuter les

fonctionnalités RBT qui lui sont dédiées.

4.4 Abonné RBT désinscrit du service

Un abonné RBT est à l’état « désinscrit » du service RBT soit à sa demande ou soit s’il garde son état


« suspendu » jusqu’à l’expiration de sa période de grâce.

Dans ce cas, il sera désapprovisionné du système et perdra par la suite son profil ainsi tout son

historique d’usage.

Par conséquent, une licence d’utilisation du service RBT devra être libérée. Cette licence peut être

réutilisée par un autre utilisateur.


CHAPITRE III : FONCTIONNALITES DU SERVICE RBT

1. La plate-forme RBT doit fournir une panoplie de fonctionnalités de base dédiées à la fois aux

abonnés au réseau mobiles de Tunisie Télécom (résidentiels et corporate, en local et en roaming), à

l’administrateur de la plate-forme, aux fournisseurs de contenu et aux agents du service à la clientèle.

2. Toute les fonctionnalités précisées dans le présent cahier des charges doivent être fournies par la

plate-forme RBT et ce, en environnement TDM, environnement hybride (TDM et NGN) et en

environnement tout NGN.

3. Les fonctionnalités exigées par le présent cahier des charges doivent inclure au moins :

I. Fonctionnalités dédiées aux abonnés résidentiels

I.1 Souscription /désinscription au/du service

i. La plate-forme RBT doit permettre aux abonnés résidentiels au réseau mobile de Tunisie Télécom

de se souscrire au service /se désinscrire du service et ce, à travers les interfaces suivantes : l’IVR,

SMS, USSD, Web, WAP.

ii. Une fois l’abonné s’est inscrit au service RBT, la plate-forme RBT doit lui envoyer un SMS de

notification l’informant de la réussite de l’opération d’inscription.

iii. La plate-forme doit de même attribuer au nouvel inscrit au service RBT un mot de passe relatif à

son nouveau compte RBT. Ce mot de passe lui sera envoyé par SMS ou par e-mail ou lui sera

délivré par le Customer Care. Par conséquent, à chaque accès aux interfaces du service, l’abonné

RBT doit s’authentifier par la saisie de son login (son MSISDN) et son mot de passe.

iv. La plateforme doit permettre à l’abonné RBT de changer son mot de passe à tout moment et selon

ses préférences.

v. La plateforme RBT doit offrir une tonalité par défaut au nouvel abonné RBT. Initialement cette

tonalité sera attribuée à tous les appelants de cet abonné.

vi. La plate-forme RBT doit permettre à l’administrateur d’envoyer des demandes de souscription aux

abonnés via SMS. Il doit avoir la possibilité de définir la date/ l’heure, le segment d’abonnés auquel est

destinée cette demande d’inscription.

I.2 Souscription au service RBT lors du premier achat de tonalité

i. La plateforme RBT doit permettre à un abonné non encore inscrits au service RBT et qui lance une

requête d’achat de tonalité RBT via SMS/USSD/WAP/Web/IVR de s’inscrire systématiquement au

service.

ii. Dans le cas où l’abonné choisit le menu IVR comme interface d’accès au service RBT, l’abonné

payera dans ce cas, les minutes de connexion au serveur IVR de la plate-forme RBT, les frais de

souscription au service RBT ainsi que les frais d’achat de(s) tonalité(s).

I.3 Activation/désactivation du service

i. La plate-forme doit permettre à l’abonné RBT d’activer/désactiver le service RBT et ce, à travers le

menu IVR, l’interface SMS, l’interface USSD ou le portail Web, le portail WAP

ii. Les appelants d’un abonné RBT désactivé entendent la tonalité de retour classique et ce, pendant la

période de validité du service du dit abonné.

iii. Un abonné désactivé a tous les droits de personnaliser son compte RBT et d’exécuter les

fonctionnalités RBT offertes par la plate-forme RBT.

iv. Le profile d’un abonné RBT désactivé doit rester intacte au niveau de la plate-forme RBT et ce, en

vue de le recharger suite à une requête de réactivation du service.


v. La durée de sauvegarde des données d’un abonné désactivé doit être configurable par

l’administrateur du système à travers une interface WUI.

I.4 Récupération de son mot de passe

i. La plate-forme RBT doit permettre à un abonné RBT mobile ayant oublié son mot de passe de le

récupérer et ce, à la base de la fourniture de son MSISDN et de son code PIN. Pour ce faire, il peut

appeler le serveur IVR ou visiter le portail Web de Tunisie Télécom, portail WAP ou encore

contacter le service Customer Care.

ii. La plateforme RBT doit permettre à l’administrateur de configurer le nombre de tentatives de

récupération de mots de passe par jour par abonné et ce, afin d’optimiser les ressources et améliorer

l’aspect sécurité du service.

I.5 Personnalisation de sa boîte RBT

i. La plateforme RBT doit permettre à un abonné RBT mobile, à travers une interface Web de

personnaliser son compte (groupe des appelants, configuration des listes de lecture, gestion du

temps de lecture des tonalités, etc.).

ii. Chaque abonné RBT doit avoir son propre album personnel dans lequel il stocke les tonalités RBT

achetées, reçues comme cadeau ou celles attribuées automatiquement par l’opérateur.

iii. Les tonalités doivent être classées, au niveau de l’album personnel en deux catégories :

Tonalités attribuées : la (les) tonalité(s) qui a (ont) été attribuée(s) à un appelant, à un groupe

d’appelant ou à tous les appelants.

Tonalités non attribuées : les tonalités qui ont été achetées, reçues comme cadeau, copiées etc. et

qui n’ont pas été attribuées.

I.6 Consultation de l’historique d’usage

i. La plate-forme RBT doit permettre à un abonné RBT mobile de consulter son historique d’usage

relatif aux transactions initiées (date de souscription, titre de la tonalité RBT, numéro du

bénéficiaire du cadeau, heure de début et de fin de la transaction, durée d’exécution de

téléchargement/offre de tonalité, prix de la tonalité téléchargée, date d’expiration de la tonalité

téléchargée, etc.) et ce, à travers l’interface Web.

I.7 Exploration et achat de RBT

i. La plateforme RBT doit permettre à un abonné RBT mobile de passer en revue, faire la recherche

des tonalités RBT (par artiste, par titre, par catégorie, Top 10, etc.), pré-écouter les morceaux de

musique, etc. à travers les interfaces utilisateurs disponibles (Web/IVR) et ce, avant de lancer

l’opération d’achat de la tonalité RBT désirée.

ii. Un SMS ou un email de notification du succès ou d’échec de l’opération d’achat doit être envoyé à

l’abonné RBT mobile à la fin de la transaction.

iii. La plate-forme RBT doit informer ses abonnés mobiles des mises à jour du contenu RBT par SMS,

par e-mail ou par out call (au décrochage de l’abonné RBT, il doit entendre un message

personnalisé configuré par l’opérateur lui informant de la liste des tonalités (intitulé tonalité et nom

de l’artiste) récemment publiées sur le système) et ce, à chaque période de temps définie par

l’opérateur.

I.8 Liste de lecture des tonalités RBT

i. Les abonnés RBT mobiles doivent avoir la possibilité de créer une liste de lecture RBT qui sera

jouée d’une manière aléatoire ou séquentielle en fonction de l’appelant et/ou en fonction de la date

(semaine, mois, année) et/ou en fonction de la plage horaire de la journée.

ii. L’abonné RBT doit être capable de configurer d’une manière simple et flexible, à travers

l’interface Web, une parmi les possibilités de programmation des listes de lecture suivantes :


a. Une tonalité RBT ou un groupe de tonalités sera joué d’une manière aléatoire ou séquentielle,

en fonction du numéro de l’appelant et en fonction de la plage horaire et ce, à une date fixée ou

encore pendant une durée bien déterminée.

b. Une tonalité RBT ou un groupe de tonalités sera joué d’une manière aléatoire ou séquentielle

en fonction du groupe auquel appartient l’appelant et en fonction de la plage horaire et ce, à

une date fixée ou encore pendant une durée bien déterminée.

c. Une tonalité RBT ou un groupe de tonalités sera joué d’une manière aléatoire ou séquentielle

en fonction de (s) la plage(s) horaire(s) bien déterminée(s) et ce, à une date fixée ou encore

pendant une durée bien déterminée.

d. Une tonalité RBT ou un groupe de tonalités sera joué d’une manière aléatoire ou séquentielle

pour un appelant bien déterminé à une date fixée ou pendant une durée bien déterminée.

e. Une tonalité RBT ou un groupe de tonalités sera joué d’une manière aléatoire ou séquentielle

pour un groupe d’appelants bien déterminé à une date fixée ou pendant une durée bien

déterminée.

f. Tonalité RBT par Défaut.

I.9 Offre de tonalités RBT

i. La plate-forme RBT doit permettre à un abonné RBT mobile (A) d’offrir une tonalité RBT à un

utilisateur (B). Dans ce cas, l’abonné A doit fournir le numéro du bénéficiaire de la tonalité RBT,

l’identifiant/nom de la tonalité à offrir ainsi que la date et l’heure de l’opération de l’offre et ce, à

travers les interfaces WEB, IVR, SMS, USSD et WAP.

ii. Dans le cas où les paramètres date et heure de l’offre n’ont pas été entrées par l’abonné RBT, le

système devrait enregistrer l’acte de l’offre à la date et l’heure de sa réalisation.

iii. L’opération d’offre de tonalité RBT n’est réalisée par la plate-forme RBT que dans le cas où

l’abonné RBT A possède une balance suffisante (cas où il est prépayé) pour pouvoir offrir la

tonalité à l’abonné B.

iv. Dans le cas où l’abonné RBT A est un abonné post-payé, la plate-forme RBT doit générer à la fin

de l’opération d’offre un CDR propre à cette opération.

v. Les champs d’un CDR généré par la plateforme RBT sont précisés dans le paragraphe 2 du

chapitre V Taxation.

vi. L’acte de l’offre de tonalité RBT consiste en le payement par l’offreur (A) des frais d’achat de la

tonalité RBT à offrir pour l’abonné B ainsi que les frais fixes de souscription de l’abonné B au

service RBT (au cas où ce dernier n’est pas encore inscrit au service).

vii. La logique de l’offre de tonalité RBT doit être comme suit :

i. Si l’abonné B accepte la tonalité offerte par A, la plate-forme RBT doit tester si l’abonné B est déjà

inscrit au service ou non.

Si l’abonné B est non encore souscrit au service RBT, la plate-forme RBT doit être capable de

l’approvisionner automatiquement sur le système.

La plate-forme teste de même si l’offreur (A) possède le solde suffisant pour pouvoir payer à

la fois les frais d’achat de la tonalité RBT pour l’abonné B ainsi que les frais de souscription

de ce dernier au service RBT et ce, pendant la première période de l’abonnement au service.

A la fin de la transaction d’offre de tonalité RBT avec succès, la plate-forme RBT doit

envoyer un message de notification de succès de l’opération de l’offre et de déduction du

solde à l’abonné A et un message de notification à l’abonné B lui informant du succès de la

réception du cadeau et qu’il payera les frais d’activation du service RBT dès la prochaine

période.

L’abonné B a la possibilité de désactiver à tout moment son inscription du service RBT.


Si l’abonné B est déjà souscrit au service RBT, la plate-forme RBT doit envoyer un message de

notification à l’abonné B lui indiquant que l’abonné A lui offre une tonalité RBT.

A la fin de la transaction d’offre de tonalité avec succès, la plate-forme RBT doit envoyer un

message de notification de succès de réception du cadeau et de déduction du solde à l’abonné A.

ii. Si l’abonné B refuse le cadeau, la plate-forme RBT doit envoyer un message de notification de

refus à l’abonné A.

viii. Les frais d’offre de tonalité RBT et éventuellement ceux d’inscription du récepteur du cadeau au

service RBT seront imputés sur la facture de l’abonné A au cas où il est post-payé. A cet effet, la

plate-forme RBT doit être capable de générer des CDRs de facturation relatifs à chaque acte initié.

I.10 Offre de service RBT

La plate-forme RBT doit permettre à un abonné RBT mobile (A) d’envoyer une invitation d’inscription au

service RBT à un utilisateur (B) qui n’est pas encore souscrit à ce service et ce, via

WEB/SMS/USSD/IVR/WAP

i. Dans le cas où l’abonné A possède une balance suffisante (A prépayé) pour pouvoir payer les frais de

souscription de l’abonné B au service RBT et ce, pendant la première période de l’abonnement au

service, la plate-forme RBT doit être capable d’approvisionner automatiquement l’abonné B sur le

système.

A la fin de la transaction d’offre de service RBT avec succès, la plate-forme RBT doit envoyer

un message de notification de succès de réception du cadeau et de déduction du solde à

l’abonné A.

La plate-forme RBT doit envoyer de même un message de notification à l’abonné B (message

de bienvenue au système et de nécessité de payer les frais du service dès la prochaine période).

L’abonné B a la possibilité à tout moment de désactiver son inscription du service RBT.

ii. Dans le cas où l’abonné A est un abonné post-payé et à la fin de l’opération d’invitation au service, la

plate-forme RBT doit générer un CDR relatif à cet acte initié et l’envoyer au système de facturation

BSCS IX R2 de Tunisie Télécom.

iii. Les champs d’un CDR généré par la plateforme RBT sont précisés dans le paragraphe 2 du chapitre

V Taxation.

I.11 Copie de tonalité RBT

La plate-forme RBT doit permettre aux abonnés mobiles résidentiels de copier des tonalités RBT et ce,

conformément aux deux procédures de copie suivantes :

I.11.1 Copie lors de l’établissement d’un appel RBT

i. La plate-forme RBT doit permettre aux abonnés RBT mobiles de copier des tonalités RBT pendant la

phase d’établissement d’appel.

ii. Le principe de cette fonctionnalité doit être comme suit : Quand un abonné RBT A appelle un abonné

B RBT et avant le décroché de B, l’abonné A peut appuyer sur une touche DTMF de son téléphone et

copier par la suite la tonalité RBT assignée par l’abonné B et ce, dans son album personnel. A la fin de

la transaction de copie, la plate-forme RBT doit envoyer un SMS de notification de copie de tonalité

RBT à l’abonné A.

iii. La fonctionnalité de copie de tonalité RBT consiste en le téléchargement d’une tonalité RBT à partir

de la librairie (album RBT) de l’appelé (B) vers la librairie de l’appelant (A).

I.11.2 Copie à travers l’IVR-RBT

i. Le principe de cette fonctionnalité doit être comme suit : un abonné RBT mobile (A) peut appeler le

module IVR de la plate-forme RBT moyennant un numéro court (abonné ON-NET en local) ou un

numéro long (abonné ON-NET en roaming) et ce, pour copier une tonalité RBT à partir de la

bibliothèque d’un abonné RBT B. Pour ce faire, l’abonné (A) doit entrer le MSISDN de l’abonné (B).


Par respect de confidentialité des informations personnelles, l’abonné A ne devrait en aucun cas accéder

à la bibliothèque de tonalités de l’abonné RBT B.

II. Fonctionnalités dédiées aux administrateurs RBT de l’entreprise (RBT corporate)

i. Le service RBT corporate permet à l’entreprise d’activer et d’attribuer une tonalité spécifique à son

activité sur les lignes corporate mobiles de ses employés et ce, pendant les horaires de travail.

ii. En dehors des horaires de travail, l’abonné RBT corporate est considéré par la plate-forme dans le cas

où est provisionné sur le système RBT, comme étant un abonné RBT résidentiel mobile. Il jouit de ce

fait de toutes les fonctionnalités réservées à ce segment d’abonnés spécifiées dans le paragraphe I du

présent chapitre.

iii. La plate-forme RBT doit permettre à l’administrateur RBT de l’entreprise et ce, à travers un outil

d’administration disponible sur le portail Web de Tunisie Télécom de configurer plusieurs types de

tonalités RBT :

o Musical,

o Publicitaire : Mini spot Publicitaire, diffusion musicale du slogan de la société, etc.

o Infos : Flash d'infos (horaires d’ouverture, changement d’adresse, changement de numéro de

téléphone, etc.), annonce d’offres spéciales, promotions, etc.

o Messages de dédicace et de félicitations :

iv. La plate-forme RBT doit permettre à l’administrateur RBT de l’entreprise de charger via le Web le

contenu audio enregistré par ses soins ou par Tunisie Télécom, et l’utiliser en tant que tonalité de

retour propre à son entreprise.

v. A cet effet, la plate-forme RBT doit être capable de recevoir cet enregistrement, de le stocker

temporairement, et ce, en vue de son approbation par l’administrateur de la plateforme RBT.

vi. La plateforme RBT doit notifier l’administrateur de la plateforme RBT (par e-mail, SMS) des

nouveaux enregistrements chargés sur le système par l’administrateur de l’entreprise. A cet effet,

l’administrateur de la plateforme RBT doit être capable d’accéder à son compte et ce, en vue de les

approuver. Une fois l’enregistrement est approuvé, il sera automatiquement attribué au compte

corporate de l’administrateur de l’entreprise.

vii. L’accès à l’interface d’administration RBT doit être authentifiable via un nom d’utilisateur et un mot

de passe attribués par le système dès l’inscription au service.

viii. La plate-forme RBT doit permettre à l’administrateur RBT de l’entreprise de changer à tout moment

via une interface WUI ses paramètres d’accès à son compte corporate.

ix. La plate-forme RBT doit permettre à l’administrateur RBT de l’entreprise de télécharger et de

contrôler les tonalités (musique, spot publicitaires, infos) sur les lignes téléphoniques mobiles des

employés de son entreprise par l’intermédiaire d’une interface graphique d’administration accessible à

travers le portail Web de Tunisie Télécom.

x. L’administrateur RBT de l’entreprise doit pouvoir utiliser l’outil d’administration RBT au moins

pour :

- approvisionner les abonnés RBT corporate

- approvisionner les tonalités RBT

- charger sur le système les tonalités DIY enregistrées par ses soins.

- Gérer (ajouter, supprimer, etc.) des lignes / des groupes de lignes du compte RBT.

- assigner les tonalités RBT à différents groupes d'employés différentes tonalités RBT selon

l’évènement ou la plage horaire de son choix.

- grouper certains numéros de lignes mobiles et leurs assigner les mêmes tonalités pendant des

horaires de travail bien particuliers.

xi. Le nombre maximal de tonalités RBT corporate téléchargeables par l’administrateur RBT de

l’entreprise doit être configurable par l’administrateur de la plateforme RBT.

xii. La plate-forme RBT doit permettre à l’administrateur RBT de l’entreprise de notifier par SMS ou par

e-mail ses employés des changements effectués sur leurs profils de tonalités RBT.


xiii. Un abonné RBT corporate n’a aucun accès à son compte corporate durant les plages horaires de

travail. Par conséquent, il n’a aucun droit d’attribution de tonalités ni de personnalisation de sa boîte

RBT par soi-même.

III. Fonctionnalités dédiées à l’administrateur de la plate-forme RBT

La plate-forme RBT doit fournir à l’administrateur un outil de gestion orienté Web et facile à s’interfacer

lui permettant au moins de :

- Administrer, contrôler et gérer le service RBT,

- gérer les différents intervenants sur la plate-forme (fournisseur de contenu, agent de service à la

clientèle, abonnés RBT et administrateurs RBT corporate)

- gérer les différentes tonalités publiées sur le système.

- Gérer les performances du système

Les tâches réservées à l’administrateur de la plate-forme RBT doivent être comme suit:

III.1 Gestion des comptes RBT

III.1.1 Gestion des droits

La plate-forme RBT doit être capable de créer un compte à l’administrateur du système lui allouant tous les

privilèges de gestion. Tous les comptes autres que le compte de l’administrateur du système ne peuvent

utiliser que des fonctions limitées d’administration du service.

III.1.2 Gestion des comptes des abonnés RBT

L’administrateur du système doit pouvoir créer et gérer un compte pour chaque abonné RBT mobile, et ce,

afin de lui attribuer les droits d’accès à sa propre boite RBT.

L’administrateur doit au moins pouvoir :

Inscrire un abonné ON-NET au service RBT et ce, en lui allouant une boîte RBT personnelle.

Désinscrire un abonné ON-NET RBT et ce, par la libération de sa boîte RBT personnelle.

réactiver un abonné RBT

Désactiver un abonné RBT

Modifier les informations personnelles des abonnés RBT, etc.

III.1.3 Gestion des comptes administrateur RBT corporate

La plate-forme RBT doit permettre à l’administrateur du système de créer et de gérer les comptes des

administrateurs RBT corporate et ce, afin de leur permettre la gestion, l’administration et la configuration

des comptes des abonnés RBT corporate mobiles.

III.1.4 Gestion des comptes des fournisseurs de contenu

L’administrateur du système doit pouvoir créer et gérer un compte pour chaque fournisseur de contenu et

ce, afin de lui attribuer les droits et les restrictions d’accès au système de gestion des contenus RBT.

A chaque chargement de tonalité ou de groupe de tonalités RBT sur le système, l’administrateur doit être

informé par mail ou par SMS et ce, en vue d’approuver/refuser le contenu chargé.

III.1.5 Gestion des comptes des agents du service Customer Care

L’administrateur du système doit pouvoir créer et gérer les comptes des agents du service Customer Care

afin de leur permettre la connexion à la plate-forme RBT et ce, en vue de fournir le support client aux

abonnés du service RBT.

III.2 Gestion des fournisseurs de Contenu


La plate-forme proposée doit supporter la gestion de plusieurs fournisseurs de contenu à la fois. A cet effet,

le soumissionnaire doit indiquer le nombre maximal de fournisseurs de contenu gérables par la plate-forme

et le nombre maximal de contenus édités par Fournisseur.

III.3 Gestion des tonalités RBT

L’administrateur du système doit être capable de supprimer et modifier les tonalités et les catégories des

contenus et ce, indépendamment des fournisseurs de contenu auxquels appartiennent ces tonalités. Il a de

même le droit de fixer la période de validité relative des tonalités publiées sur le système (chansons,

enregistrement personnel (DIY), etc.)

III.4 Approbation des tonalités RBT

III.4.1 L’administrateur de la plate-forme RBT doit pouvoir :

Approuver/refuser les tonalités RBT téléchargées par les fournisseurs de contenu

Approuver/refuser les tonalités RBT corporate chargées par l’administrateur RBT corporate

III.4.2 Les critères d’approbation ou de rejet des tonalités RBT se basent sur la qualité de

l’enregistrement, son contenu, le débit de lecture, l’intitulé de la tonalité, l'identification de tonalité,

l'artiste, le genre musical, la taille, le format, la catégorie, la période de validité, la date limite des

droits d’utilisation, le nom du fournisseur de contenu, etc.

III.4.3 Le processus d’approbation doit ressortir 3 types de tonalités : tonalité en instance, tonalité

acceptée et tonalité rejetée comme défini dans le Chapitre II du présent cahier des charges.

III.4.4 L’administrateur du système a le droit de rejeter les tonalités jugées non conformes aux exigences

spécifiées et fournir par conséquent les justificatifs nécessaires aux fournisseurs de contenus

correspondant et ce, à la base de la fourniture d’un rapport précisant les causes de rejet des tonalités.

III.4.5 Le système doit pouvoir vérifier automatiquement, les tonalités insérées et bloquer celles jugées

non conformes aux exigences spécifiées par l’administrateur de la plate-forme.

III.5 Gestion des capacités de stockage de la plate-forme de gestion de contenu

Cas des abonnés RBT résidentiels

La plate-forme RBT doit permettre à l’administrateur de configurer le nombre maximum de :

tonalités RBT par album personnel.

listes de lecture RBT par appelant

tonalités par liste de lecture

groupes d’appelants par abonné RBT.

numéros d'appels par groupe d’appelants.

Cas des abonnés RBT corporate mobile

La plate-forme RBT doit permettre à l’administrateur de configurer le nombre maximum de :

compte RBT corporate par entreprise

abonnés RBT corporate par compte corporate

tonalités RBT par album corporate

liste de lecture RBT par compte RBT corporate

tonalités RBT par liste de lecture

maximum de tonalités personnalisées « Do It Yourself » par compte corporate

III.6 Gestion des donnés d’usage sur la plateforme

i. La plate-forme RBT doit permettre à l’administrateur de la plateforme de configurer la durée

minimale de stockage des détails d’usage d’un abonné RBT dont notamment :

La date et l’heure d’inscription/désinscription au/du service RBT

La date et l’heure de l’activation/désactivation du service RBT

La date et l’heure de passage d’un état à un autre (actif/suspendu/désactvé/désinscrit)


Toutes les informations relatives aux transactions d’achat de tonalité RBT initiées

Toutes les informations relatives aux transactions d’offre de tonalité RBT ou d’invitation

au service RBT.

Toutes les informations relatives aux transactions de copie de tonalité RBT

Les périodes de validité relative des tonalités RBT téléchargées

.

ii. La plate-forme RBT doit permettre à l’administrateur de la plateforme de configurer la durée

minimale de stockage des détails d’usage d’un administrateur RBT corporate dont notamment :

La taille de flotte gérable

Les tonalités téléchargées

Les plages horaires de lecture des RBT corporate

La date et l’heure d’achat/upload de tonalité sur le système

iii. La plate-forme RBT doit permettre à l’administrateur de la plateforme de configurer la durée

minimale de stockage des tonalités sur le système dont notamment :

Les tonalités chargées sur le système : la date limite de droit d’utilisation des tonalités

RBT.

Les tonalités en instance

approuvées

Les tonalités rejetées

IV. Fonctionnalités réservées au fournisseur de contenu

i. La plate-forme RBT doit fournir aux fournisseurs de contenu une interface WUI, leur permettant de

gérer par eux mêmes leur contenu RBT et ce, dans la limite des privilèges qui leurs seront accordés.

ii. Chaque fournisseur de contenu aura un accès sécurisé au système de gestion de contenu par le biais

d’un nom d’utilisateur et d’un mot de passe fournis par l’administrateur de la plate-forme.

IV.1 Publication des tonalités RBT

i. La plate-forme RBT doit permettre aux fournisseurs de contenu la publication des tonalités RBT à

travers des connexions sécurisées (FTPS).

ii. En accédant à l’interface de gestion de contenu WUI, le fournisseur de contenu doit entrer des

informations concernant la (les) tonalité(s) à publier à savoir : l’identifiant de la tonalité, l’intitulé de la

tonalité, le nom de l’artiste, le genre musical, la taille, le format, la date limite des droits d’utilisation,

etc.

iii. Le fournisseur de contenu doit être capable de publier son contenu sur le système par lot de tonalités.

IV.2 Suppression d’une tonalité RBT

i. La plate-forme RBT doit permettre au fournisseur de contenu de ne supprimer que les tonalités publiées

par ses soins et ce, seulement suite à l'approbation de l'administrateur de la plate-forme.

IV.3 Modification d'une tonalité RBT

i. La plate-forme RBT doit permettre au fournisseur de contenu de ne modifier que les tonalités publiées

par ses soins et ce, seulement suite à l'approbation de l'administrateur de la plate-forme.

ii. La modification d’une tonalité implique le rechargement de cette tonalité sur le système et ce, en vue

d’être approuvée par l’administrateur et par la suite être publiée.

iii. Le fournisseur de contenu peut, sans avoir l’approbation de l’administrateur de la plate-forme, modifier

seulement les tonalités qui sont en attente d’approbation ou rejetées par l’administrateur du système.

IV.4 Cacher une tonalité RBT

i. La plateforme RBT doit permettre à l’administrateur du système de rendre invisible sur le portail

Web/WAP (cas de l’IVR : supprimer l’annonce vocale correspondante) une tonalité ou un groupe de


tonalités et ce, indépendamment du fournisseur de contenu.

ii. Un fournisseur de contenu ne peut cacher que les tonalités publiées par ses soins.

iii. La tonalité dont le statu sets désormais « caché » ne peut plus être consultée ni achetée.

iv. Les abonnés qui ont déjà une tonalité à l’état « caché » dans leur album doivent pouvoir continuer à

l’utiliser jusqu’à l’expiration de sa date de validité relative.

IV.5 Restitution d’une tonalité RT

i. La plateforme RBT doit permettre à l’administrateur du système de remettre à la disposition des abonnés

une tonalité ou un groupe de tonalité dont le statut était « caché ».

ii. Le fournisseur de contenu ne peut remettre au statut « caché » que les tonalités publiées par ses soins.

V. Fonctionnalités réservées au service Customer Care

V.1 La plate-forme RBT doit offrir un outil de gestion orienté Web permettant au Customer Care

d’assister les abonnés au service RBT qui manifestent des réclamations ou des problèmes lors de leurs

utilisation du service RBT.

V.2 A chaque réclamation sur le service RBT, parvenue au système, la plate-forme RBT doit générer

un feedback indiquant la date, l’heure de la réclamation ainsi que l’identifiant de l’agent ayant résolu la

réclamation.

V.3 L’interface de service d’aide à la clientèle doit supporter les fonctionnalités suivantes :

i. La connexion authentifiée à la page Web de gestion du compte RBT de l’utilisateur final moyennant le

numéro d’appel de l’utilisateur et un numéro de session attribué automatiquement à chaque réclamation.

ii. L’accès à l’historique d’usage des abonnés incluant les détails de chaque action d’inscription, d’achat,

etc. tels que la date/heure de début et de fin de la transaction, le nom de la tonalité téléchargée, sa date

d’expiration, l’état de l’action effectuée (succès ou échec), etc.

iii. L’accès à la liste des contacts, aux tonalités assignées, à l’album personnel de l’abonné.

iv. L’approvisionnement/le désapprovisionnement des utilisateurs au/du service RBT : Cette action

consiste à l’envoi d’un message de souscription/désinscription au système d’approvisionnement de la

plate-forme.

v. La programmation d’une tonalité par défaut,

vi. L’attribution/la suppression d’une tonalité à un contact ou à un groupe de contact, suppression de

tonalité de sa librairie, etc. et ce, suite à une demande de la part de l’abonné RBT.

vii. L’offre de tonalité RBT à un autre abonné et ce, suite à une demande de la part de l’abonné RBT.

viii. L’invitation d’un abonné non RBT à s’inscrire au service. et ce, suite à une demande de la part d’un

abonné RBT.

ix. Toutes les opérations d’aide et d’assistance aux abonnés au service RBT (récupération du mot de passe

oublié, etc.)

V.4 Toutes les modifications faites par l’agent du service Customer Care sur un compte d’utilisateur

devront être enregistrées parmi l’historique d’usage de l’abonné et seront marquées par la mention

« modifiées par le service Customer Care ».

4. En plus des fonctionnalités de base du service RBT, la plate-forme RBT doit offrir d’autres

fonctionnalités dont au moins :

4.1 Tonalité hybride

i La solution proposée doit supporter en plus du jeu de la tonalité RBT, le jeu hybride de tonalité

classique (ITU Tone) et de tonalités Ring Back Tone.


ii La plateforme proposée doit permettre à l’administrateur de sélectionner le mode simple (tonalité RBT

seulement) ou hybride de jeu de la tonalité de retour.

4.2 Offre massive de tonalité RBT

i. La plate-forme RBT doit permettre l’offre massive, à titre gratuit, d’une ou de plusieurs tonalités RBT

aux abonnés RBT mobiles.

ii. La plate-forme RBT doit permettre à l’administrateur de sélectionner le segment d’abonnés cible.

4.3 Promotions

i. La plate-forme RBT doit permettre à l’administrateur de lancer des promotions sur les tonalités RBT

(exemple : premier mois d’abonnement au service offert, deux sonneries offertes pour chaque abonnement,

deux sonneries au prix d’une, etc.). Par conséquent, la plateforme doit permettre à l’administrateur de

configurer les tonalités à promouvoir, configurer les périodes de promotion, le prix des tonalités durant ces

promotions, la durée de validité promotionnelle des tonalités RBT, etc.).

ii. Le soumissionnaire doit fournir une liste de promotions susceptible à être promulguer.

iii. Les promotions doivent être disponibles sur toutes les interfaces d’accès (WEB, SMS, IVR, WAP et

USSD).

4.4 Classe de service des abonnés RBT

i. La plateforme RBT doit permettre à l’administrateur de la plateforme d’offrir des

fonctionnalités/configurations propres à chaque classe d’abonnés mobile.

ii. La classification des abonnés RBT doit être conforme à celle (classes de service) au niveau de l’IN

mobile de Tunisie Télécom. La synchronisation de ces classes de service doit être via le protocole Diameter

SCAP. Le soumissionnaire se chargera d’assurer le développement nécessaire pour convenir à ce besoin.

5. Outre les fonctionnalités ci-dessus mentionnées, la plate-forme proposée doit être capable de fournir le

Multimédia RBT (vidéo-RBT, picture-RBT).

6. La plate-forme Multimédia RBT doit supporter la fonctionnalité « Vidéo RBT » ainsi que toutes les

exigences qui en découlent telles que le support des codecs Vidéo, le support des interfaces

d’interconnexion aux différents nœuds de Tunisie télécom.

7. Le soumissionnaire est tenu à préciser la liste des fonctionnalités offertes pour le service Multimédia

Ring Back Tone. Un document détaillé renfermant la liste des fonctionnalités propres au service

Multimédia RBT doit être fourni.


CHAPITRE IV : INTERFACES UTILISATEURS

La plate-forme RBT doit prévoir plusieurs canaux de communication. Les différents types d’interface qui

doivent être supportées et proposées dans la soumission sont les suivantes :

1. Interface Web

2. Interface WAP

3. Interface SMS

4. Menu IVR

5. Interface USSD

1. Interface Web

1.1 La plate-forme RBT doit permettre aux abonnés RBT mobile de Tunisie Télécom (résidentiels et

corporate) de personnaliser leur comptes RBT et ce, à travers une interface accessible à partir du portail

Web de Tunisie Télécom.

1.2 L’interface Web du service RBT doit permettre à un abonné RBT mobile résidentiels au moins de :

i. s’authentifier à chaque tentative d’accès à son compte. L’opération d’authentification doit se faire par

l’introduction du numéro MSISDN et d’un mot de passe.

ii. récupérer son mot de passe : cette facilité doit permettre à un abonné RBT mobile ayant oublié son

mot de passe de le récupérer à travers l’interface Web et ce, moyennant la fourniture de son login. Un

SMS renfermant le mot de passe oublié sera ainsi envoyé au MSISDN entré.

iii. personnaliser son propre compte (changer son mot de passe, choisir une tonalité par défaut,

programmer les méthodes de lecture des tonalités (aléatoire, par segment de temps, par appelant ou

groupe d’appelant, etc.), supprimer des tonalités RBT de son album, supprimer des contacts de son

compte, etc.).

iv. explorer le contenu RBT (navigation et consultation des tonalités RBT disponibles dans son album

personnel ainsi que celles publiées sur le système)

v. pré-écouter des morceaux des tonalités publiées sur le système et ce, avant confirmation d’achat.

vi. Acheter des tonalités RBT

vii. Copier des tonalités RBT

viii. Offrir des tonalités RBT

ix. Inviter un abonné non RBT à se souscrire au service RBT.

1.3 Les contenus RBT doivent être présentés aux abonnés RBT résidentiels Mobile de Tunisie Télécom

accédants au portail Web de Tunisie Télécom des albums classés au moins par :

i. catégories de la tonalité (chanson orientale, chanson occidentale, film, divertissements ; Religions,

fêtes spécifiques, sport, enfants, etc.).

ii. Titre de la tonalité (chanson)

iii. Les TOP 10 de la semaine

iv. Nom d’artiste

v. Les dernières tonalités publiées

vi. Les tonalités les plus souvent téléchargées

1.4 Ces types de classement doivent être disponibles à tout moment aux abonnés RBT.

1.5 L’interface de service RBT hébergée sur le site Web de Tunisie Télécom doit supporter les langues


arabe, français et anglais.

1.6 La plate-forme RBT doit permettre aux administrateurs RBT de l’entreprise de gérer, configurer les

comptes de leurs employées corporate et ce, pendant les horaires de travail à travers une interface web

(WUI) accessible via le portail WEB de Tunisie Télécom.

2. Interface WAP

2.1 La plate-forme RBT doit permettre aux abonnés RBT résidentiels au réseau mobile de Tunisie

Télécom de personnaliser leur comptes RBT et ce, à travers une interface de service consultée à

partir du portail WAP de Tunisie Télécom.

2.2 L’interface WAP du service RBT doit permettre à un abonné RBT mobile au moins de :

i. s’authentifier à chaque tentative d’accès à son compte. L’opération d’authentification doit se faire

par l’introduction d’un login (son MSISDN) et d’un mot de passe.

ii. récupérer son mot de passe : cette facilité doit permettre à un abonné RBT mobile ayant oublié son

mot de passe de le récupérer à travers l’interface WAP et ce, moyennant la fourniture de son login. Un

SMS renfermant le mot de passe oublié sera ainsi envoyé au MSISDN entré.

iii. personnaliser son propre compte (changer son mot de passe, choisir une tonalité par défaut,

programmer les méthodes de lecture des tonalités (aléatoire, par segment de temps, par appelant ou

groupe d’appelant, etc.), supprimer des tonalités RBT de son album, supprimer des contacts de son

compte, etc.).

iv. explorer le contenu RBT (navigation et consultation des tonalités RBT disponibles dans son album

personnel ainsi que celles publiées sur le système)

v. pré-écouter des morceaux des tonalités publiées sur le système et ce, avant confirmation d’achat.

vi. Acheter des tonalités RBT

vii. Copier des tonalités RBT

viii. Offrir des tonalités RBT

ix. Inviter un abonné non RBT à se souscrire au service RBT.

2.3 Les contenus RBT doivent être présentés aux abonnés RBT accédants au portail WAP de Tunisie

Télécom en des albums classés au moins par :

i. catégories de la tonalité (chanson orientale, chanson occidentale, film, divertissements ; Religions,


ii. Titre de la tonalité (chanson)


iv. Nom d’artiste


vi. Les tonalités les plus souvent téléchargées

2.4 Ces types de classement doivent être disponibles à tout moment aux abonnés RBT.

2.5 L’interface de service RBT hébergée sur le site WAP de Tunisie Télécom doit supporter les langues

arabe, français et anglais.

3. Interface SMS

3.1 La plate-forme RBT doit fournir une interface SMS permettant aux abonnés RBT mobiles

résidentiels de Tunisie Télécom au moins de :

i. S’inscrire au service RBT, avec ou sans achat de tonalité : Cette facilité inclut la demande de

confirmation envoyée à l’utilisateur via SMS. Le service ne doit pas être activé que si l’utilisateur


confirme par SMS sa demande d’inscription.

ii. Se désinscrire du service RBT : Cette facilité inclut la demande de confirmation envoyée à

l’utilisateur via SMS. Le service ne doit pas être désactivé que si l’utilisateur confirme par SMS sa

demande de désinscription.

iii. Acheter une tonalité ou plusieurs tonalités RBT : cette transaction consiste en l’envoi d’un SMS

contenant le(s) code(s) de(s) la tonalité(s) RBT à télécharger à un numéro court configurable par

l’administrateur du système pour le cas des abonnés mobiles en local. Pour le cas des abonnés en

roaming, ce message sera envoyé à un numéro long défini par l’administrateur du système.

iv. Attribuer une tonalité par défaut à tous les contacts

v. Attribuer des tonalités spécifiques à un contact ou à un groupe de contacts

vi. Offrir une tonalité RBT à un autre abonné comme cadeau

vii. Offrir le service RBT à un abonné non encore inscrit au service,

3.2 Le contenu des SMS envoyés par les abonnés à la plateforme RBT doit être configurable par

l’administrateur de la plate-forme.

3.3 Les dialogues SMS consistent en l’échange de SMS de notification de la plateforme RBT à

l’abonné RBT et des SMS de confirmation envoyés par l’abonné RBT à la plate-forme. Les messages de

notification doivent inclure au moins :

i. Les SMS de notification indiquant le mot de passe attribué par le système à l’abonné mobile et ce,

lors la création de son compte RBT.

ii. Les SMS de récupération du mot de passe oublié

iii. Les SMS de notification du risque d’expiration de la date de validité des tonalités RBT et de la

nécessité de les renouveler et ce, avant x jours (x configurable par l’administrateur) de la date

d’expiration de la période de validité relative de la tonalité en question. Ce message doit inclure des

informations sur la tonalité (date d’expiration, prix de renouvellement, méthodes de renouvellement,

etc.).

iv. Les SMS de notification de l’expiration prochaine de la validité du compte RBT. (la durée de validité

du compte RBT doit être configurable par l’administrateur de la plateforme)

v. Les SMS de notification de la réception de tonalité RBT/du service RBT comme cadeau.

4. Interfaces USSD

4.1 La plate-forme RBT devrait à travers une interface SOAP avec l’USSDC de Tunisie Télécom

permettre à un abonné RBT mobile au moins de :

i. S’inscrire au service RBT, avec ou sans achat d’une tonalité

ii. Se désinscrire du service RBT

iii. Acheter une tonalité ou plusieurs tonalités RBT

iv. Attribuer une tonalité par défaut à tous les contacts

v. Attribuer des tonalités spécifiques à un contact ou à un groupe de contacts

vi. Offrir une tonalité RBT à un autre abonné mobile.

vii. Inviter un abonné non RBT mobile à s’inscrire au service RBT.

5. Interface IVR

5.1 La plate-forme RBT doit fournir une interface IVR permettant aux abonnés RBT résidentiels

mobiles de Tunisie Télécom au moins de :

i. s’authentifier à chaque tentative d’accès à son compte par l’introduction de son login (MSISDN) et


son mot de passe.

ii. s’inscrire au service RBT, avec ou sans achat d’une tonalité

iii. se désinscrire du service RBT

iv. pré-écouter des morceaux des tonalités publiées sur le système et ce, avant confirmation d’achat.

v. acheter des tonalités RBT

vi. explorer le contenu RBT (navigation et écoute des tonalités RBT disponibles dans son album

personnel)

vii. copier des tonalités RBT

viii. offrir des tonalités RBT

ix. inviter un abonné non RBT à se souscrire au service RBT

x. explorer les tonalités disponibles sur le système

xi. personnaliser son propre compte (changer son mot de passe, choisir une tonalité par défaut,

attribuer une tonalité particulière à un contact ou à un groupe de contact, supprimer des tonalités

RBT de son album, etc.).

5.2 L’accès à l’IVR de la plate-forme RBT (IVR-RBT) doit être possible moyennant l’appel d’un

numéro court et ce, pour le cas des abonnés mobiles de Tunisie Télécom en local et moyennant l’appel

d’un numéro long pour le cas des abonnés ON-NET en roaming.

5.3 En accédant au serveur IVR- RBT, un message d’accueil au service RBT doit être joué à

l’abonné. Cette fonctionnalité peut être activée ou désactivée par l’administrateur du système.

5.4 Les contenus RBT doivent être présentés aux abonnés RBT résidentiels mobiles de Tunisie

Télécom accédants au serveur vocal de la plate-forme en des albums classés au moins par :

i. catégories de tonalité (chanson orientale, chanson occidentale, film, divertissements ; Religions,


ii. Titre de la tonalité


iv. Nom d’artiste


vi. Les tonalités les plus souvent téléchargées.

5.5 Ces types de classement doivent être disponibles à tout moment à l’abonné RBT.

5.6 Le module IVR-RBT proposé dans la solution doit être fourni avec au moins 3 langues (arabe,

français, Anglais) incluant l’ensemble des annonces statiques et dynamiques permettant d’assurer le

bon fonctionnement de l’ensemble du service RBT.

5.7 Le soumissionnaire doit s’engager à fournir le matériel et les logiciels nécessaires afin que

Tunisie Télécom puisse publier les enregistrements des nouvelles annonces statiques ainsi que

modifier celles existantes. Le soumissionnaire doit spécifier les formats des fichiers pour lesquels la

publication serait possible.

5.8 L’ensemble des ressources vocales du module IVR-RBT de la plate-forme proposée doit être

administrable. A cet effet, ce module IVR - RBT doit offrir depuis un unique centre de contrôle une

interface permettant de modifier d’une manière simple et flexible son flow : ajouter, modifier et

supprimer les annonces, afficher les alarmes, générer des fichiers logs, etc.

5.9 Le soumissionnaire est tenu à fournir toute la documentation se rapportant aux procédures de

configuration du module IVR RBT.


5.10 Toute modification introduite sur le contenu du serveur de gestion de contenu doit entrainer la

mise à jour de la librairie média (lecteur de tonalité RBT) du système ainsi que la mise à jour du

module IVR RBT. A cet effet, le soumissionnaire doit indiquer la fréquence avec laquelle les mises à

jour sont effectuées et doit fournir toute la documentation relative à la procédure de mise à jour.

5.11 Le module IVR-RBT devra supporter l’ensemble des fonctions nécessaires au bon déroulement

du service RBT. Les principales fonctions requises sont :

i. Enregistrement et lecture des annonces vocales (statiques ; dynamiques afin de jouer les chiffres

ou les dates),

ii. Demande et collecte des interactions utilisateurs (Recommandation Q23 de l’UIT relative aux

caractéristiques techniques des appareils téléphoniques à clavier),

iii. Possibilité d’interpréter des scripts VXML,

5.12 La durée moyenne d’un appel vers l’IVR-RBT ne doit pas dépasser les 100 secondes à l’heure

chargée.

Le soumissionnaire doit détailler les spécifications de l’interface permettant de s’interconnecter avec les

nœuds du réseau de Tunisie Télécom suivants : l’USSDC, le CRM et le site Web, et ce, afin d’assurer les

fonctionnalités relatives aux interfaces des nœuds ci-dessus mentionnés.

Le soumissionnaire doit fournir une XML API afin de s’interconnecter avec l’USSDC, le CRM et le site

Web de Tunisie Télécom.


CHAPITRE V : TAXATION ET FACTURATION DU SERVICE RBT

1. Conditions générales

1.1 La plate-forme RBT doit être en mesure de supporter les protocoles de taxation actuellement utilisés dans

le réseau de Tunisie Télécom et spécifiés ultérieurement.

1.2 La plateforme RBT doit envoyer Y fois /jour (Y configurable par l’administrateur du système) des SMS de

notifications aux abonnés RBT actifs pendant les X jours (X étant configurable par l’administrateur) qui

précèdent la fin de chaque période de paiement des frais (mensuel, trimestriels, semestriel, etc.) d’activation du

service RBT, informant l’abonné prépayé mobile du renouvellement automatique de son service RBT.

1.3 Si l’abonné mobile prépayé manque à l’action de renouvellement de son service à la fin de ces X jours, il

sera automatiquement suspendu et entrera par la suite dans une période de grâce dont la durée est configurable

par l’administrateur du système.

1.4 Si aucune alimentation de la balance de l’abonné n’a été constatée au bout de N vérifications/jour pendant

la période de grâce (N configurable par l’administrateur du système), l’abonné sera automatiquement

désapprovisionné de la plate-forme et perdra, dans ce cas, son profil ainsi que son historique d’usage. Un

message de notification de désinscription du service lui sera ainsi envoyé par la plateforme RBT.

1.5 La taxation et la facturation du service RBT doit être possible à l’acte initié (souscription au

service/désinscription, activation/désactivation du service, offre de tonalité RBT, etc.) et/ou à la durée de

connexion au module IVR –RBT

1.6 A cet effet, la plate-forme RBT doit :

s’interfacer avec le RI mobile via le protocole Diameter SCAP et ce, afin de d’envoyer les paramètres

de taxation relatifs à chaque acte initié par l’abonné mobiles prépayé

générer des CDRs relatifs à l’initiation d’un acte en format ASN.1.et les envoyer au système de

facturation BSCS IX R2 via FTP et ce, pour le cas des abonnés mobiles post-payés.

1.7 . La taxation à la durée des appels établis par les abonnés mobiles prépayés vers le module IVR –RBT via

le protocole INAP CS1+ est à la charge des MSC de Tunisie Télécom dans un environnement TDM et à la

charge des MSC-S dans le cas de la migration du réseau mobile de Tunisie Télécom vers NGN.

1.8 La facturation des appels établis par les abonnés mobiles post-payés vers le module IVR –RBT est à la

charge des MSC de Tunisie Télécom dans un environnement TDM et à la charge des MSC-S dans le cas de la

migration du réseau mobile de Tunisie Télécom vers NGN.

1.9 . La fréquence d’envoie des fichiers CDR par la plate-forme RBT doit être configurable par

l’administrateur.

1.10 La plate-forme RBT doit permettre la compression des fichiers CDRs dans un format standard (.zip ou

.rar)

1.11 La plateforme RBT proposée doit permettre le stockage des fichiers CDRs pendant au moins 3 mois.

1.12 Le nombre maximum de CDR pouvant être inclus dans un même fichier doit être configurable par

l’administrateur du système.

1.13 La plate-forme proposée doit générer des alarmes dans le cas de détection de problème dans la génération

ou lors du transfert des fichiers CDRs.

2. Taxation/facturation des abonnés RBT résidentiels mobiles

Afin de déterminer le type du compte de l’abonné RBT (abonné prépayé ou post-payé) et ce, pour des raisons

de taxation/éventuellement génération de CDR de facturation des actes initiés, la plateforme RBT doit être

capable, moyennant le protocole Diameter SCAP d’interroger le réseau Intelligent mobile sur le type de


compte de l’abonné en question. Dans le cas d’une réponse favorable du côté de l’IN mobile (ie. abonné

prépayé), la plateforme doit envoyer les paramètres de taxation précisés dans le paragrpahe 2.1 du présent

chapitre. Sinon, la plateforme doit générer des CDRs dont le contenu est précisé dans le paragrpahe 2.2 du

présent chapitre.

2.1 Cas des abonnés prépayés

i. A l’initiation d’un acte, les paramètres de taxation envoyés par la plate-forme RBT au RI mobile de

Tunisie Télécom via Diameter SCAP doivent inclure au moins :

Le numéro de l’abonné A (MSISDN (A))

Le numéro de l’abonné B (MSISDN (B))

Le type de l’acte (inscription, désinscription, activation, désactivation, achat, offre de tonalité

RBT, invitation au service RBT, copie, consultation des tonalités sur le système, etc.)

L’identifiant du contenu RBT.

La date et l’heure (heure : minute : seconde) de l’acte

ii. La liste exhaustive des actes possibles sera arrêtée lors de la mise en place de la plateforme RBT.

2.2 Cas des abonnés post-payés

i. Les CDR générés par la plate-forme RBT suite à l’accomplissement d’un acte initié par un abonné

RBT mobile post- payé doivent contenir au moins les informations suivantes :

Le numéro de l’abonné A (MSISDN (A))

Le numéro de l’abonné B (MSISDN (B))

L’IMSI de l’abonné A

Le type de l’acte (inscription, désinscription, activation, désactivation, achat, offre de tonalité

RBT, invitation au service RBT, copie, consultation des tonalités sur le système, etc.)

L’identifiant de la tonalité RBT


L’interface d’accès utilisée (Web/IVR/SMS/WAP/USSD)

ii. A la fin de l’acte, la plateforme RBT doit inclure un champ dans les CDR générés relatifs à l’état de la

transaction (succès, échec.) et ce, pour des raisons de statistiques de performance du système.

iii. La liste exhaustive des actes possibles sera arrêtée lors de la mise en place de la plateforme RBT.

iv. Le soumissionnaire doit expliciter la méthode d’extraction de l’IMSI et les procédures de son

inclusion dans les CDRs générés par la plateforme RBT. Un document décrivant ces procédures doit

être fourni à l’appui.

v. Le soumissionnaire doit prévoir la possibilité d’ajout d’autres champs au niveau des CDR générés et

ce, au besoin futur consenti par Tunisie Télécom.

vi. Les CDR des appels initiés par les abonnés post-payés au module IVR – RBT seront générés par les

MSC de Tunisie Télécom dans un environnement TDM et par les MSC-S dans le cas de la migration

du réseau mobile vers NGN.

3. Facturation des abonnés Corporate mobiles

3.1 Le service RBT pour les employés corporate mobiles d’une entreprise n’est valable que pendant les

horaires de travail. Hors horaires de travail un employé d’une entreprise est considéré comme étant un

abonné mobile résidentiel ; il jouit à cet effet de toutes les fonctionnalités RBT précisées dans le

paragraphe I. du chapitre III du présent cahier des charges.

3.2 A cet effet, la plate-forme RBT proposée doit être capable de tenir en compte de ces changements de

classe d’abonnés et des modifications qui leur sont afférentes.

3.3 Les administrateurs RBT corporate (clients entreprises) doivent être facturés périodiquement (dont la

durée est configurable par l’administrateur du système : mensuellement, trimestriellement, etc.) sur les


frais de souscription/activation au service RBT par ligne corporate affiliés et ce, en fonction de la taille de

la flotte de l’entreprise.

3.4 La mise à jour du contenu RBT Corporate (achat de tonalité RBT, chargement de tonalité DIY sur le

système) sera facturée périodiquement selon les critères suivants :

L’identifiant de la tonalité RBT achetée

le nombre de lignes configuré par l’administrateur RBT de l’entreprise : L’administrateur RBT de

l’entreprise peut ne pas généraliser la mise à jour pour toutes les lignes de la flotte.

la fréquence de(s) la mise (s) à jour effectuées pendant la durée de la validité du compte RBT

corporate.

3.5 Cas des abonnés Corporate mobiles post-payés

i. La plate-forme RBT doit être capable de générer des CDRs et de les envoyer au système de Facturation

BSCS IX R2 de Tunisie Télécom incluant au moins les paramètres suivants :

L’identifiant de l’administrateur de l’entreprise (MSISDN)

L’IMSI de l’administrateur de l’entreprise

L’identifiant de la tonalité RBT


La fréquence de la mise à jour de contenu effectuée pendant la période de validité du compte

RBT corporate

Le nombre de lignes d’abonnés corporate mobiles impliqués dans l’acte,

Le type de l’acte initié (inscription, désinscription, activation, désactivation, mise à jour de

contenu (achat, DIY))

ii. Le soumissionnaire est tenu à préciser tous les champs à insérer dans les CDRs nécessaires pour la

facturation des abonnés Corporate mobiles.


CHAPITRE VI : ARCHITECTURE ET INTERFACES DE LA PLATE-

FORME RBT

1. Composants de la plate-forme RBT

La plate-forme RBT, objet de la présente consultation, indépendamment qu’elle soit en environnement TDM

ou en environnement NGN, doit prévoir les principaux modules suivants :

1.1. Le module PGS/INS

Conformément à la logique d’implémentation « IN-Based sans trombonning », ce module doit permettre

principalement :

i Le contrôle de l’établissement d’un appel vers un abonné RBT

ii La gestion de multi-legs

iii L’extraction de l’identifiant de la tonalité RBT attribuée par l’abonné RBT à son (ses) appelant(s)

Ce module doit être intégrable au réseau intelligent mobile de Tunisie Télécom. A cet effet, le soumissionnaire

doit préciser les méthodes et les procédures d’intégration de ce module dans le système existant. Un document

détaillé décrivant ces procédures d’intégration doit être présenté à l’appui.

1.2 La plate-forme de gestion de contenu RBT

1.2.1 Le module d’inscription et de désinscription

i. Ce module doit permettre :

L’inscription (provisioning) des abonnés au service RBT et ce, via SMS, IVR, WEB, WAP, USSD ou

par l’intermédiaire du service Customer Care.

La désinscription du service RBT et ce, suite à une demande de la part de l’abonné via SMS, IVR,

WEB, WAP, USSD ou par l’intermédiaire du service Customer Care.

Le provisioning automatique : La plateforme RBT doit permettre à un abonné non encore inscrit au

service RBT et qui lance une opération d’achat de tonalité RBT de s’inscrire automatiquement au service. Le

soumissionnaire est tenu à communiquer un document détaillant le work flow de cette opération ainsi que les

nœuds et interfaces impliqués.

Le provisioning en masse : La plateforme RBT doit prévoir la possibilité d’approvisionner en masse un

ou plusieurs segments d’abonnés non encore inscrits au service RBT. Un document décrivant ce processus

doit être fourni à l’appui.

La désinscription du service RBT par le système et ce, suite à l’expiration de la période de grâce relative

à un abonné suspendu et qui n’a pas encore payé les redevances de prolongation de son abonnement au

service RBT.

ii. Toute demande d’inscription ou de désinscription parvenue à la plate-forme RBT proposée via les

interfaces d’accès possibles, ci-dessus mentionnées, doit mettre à jour la marque TICK au niveau HLR ainsi

que mettre à jour la base de données utilisateurs de la plate-forme RBT.

iii. A cet effet, le soumissionnaire doit fournir un document complet et détaillé décrivant la procédure de

provisioning des abonnés RBT sur le système ainsi que les différentes interactions et pré-requis sur les nœuds

de réseau de Tunisie Télécom impliqués dans ce processus.

iv. Toute de demande d’inscription ou de désinscription du service RBT doit tenir en compte la classe de

service de l’abonné prépayé ou post-payé résidentiel et corporate en question. A cet effet, la plateforme

proposée doit prévoir toute les interconnexions possibles avec les nœuds du réseau de Tunisie Télécom

nécessaires pour convenir à ce travail.


1.2.2 La Base de données utilisateurs

i. La base de données utilisateur doit permettre le stockage des profiles des abonnés RBT mobiles.

ii. Le profil d’un abonné RBT doit inclure au moins :

L’identifiant de l’abonné

Le nom de l’abonné

Le prénom de l’abonné

La date d’inscription/d’activation au service RBT

La date d’activation du service RBT

L’identifiant ou la liste des identifiants de tonalités RBT attribuées

Les numéros d’appel (MSISDN) ou identifiant des groupe d’appel auxquels est attribuée les

tonalités,

Le type du compte (prépayé, post-payé),

La classe de service de l’abonné

iii. La base de données proposée doit être gérée par le système de gestion de Base de donnée « ORACLE

10g » ou une version ultérieure. Le soumissionnaire doit tenir à sa charge la fourniture des licences

Oracles acquise sur son système ainsi que toute les dispositions qui en découlent et ce, afin de fournir à

Tunisie Télécom une solution complète et clé en main.

1.2.3 Le serveur de gestion du contenu RBT

i Le serveur de gestion du contenu RBT doit permettre :

au fournisseur de contenu d’uploader, stocker et gérer le contenu RBT qu’ils chargent sur le système

via HTTPS/FTPS. Toutes les fonctionnalités dédiées aux fournisseurs de contenu sont détaillées dans

le paragraphe IVdu chapitre III du présent cahier des charges.

à l’administrateur de la plateforme RBT d’administrer, gérer les comptes des fournisseurs de

contenu RBT ainsi que le contenu RBT et ce, à travers une interface graphique d’administration

WUI.

ii Le serveur de gestion du contenu RBT doit être capable de mettre à jour régulièrement le module IVR-

RBT de la plateforme et ce, pour rendre visible aux abonnés RBT le nouveau contenu sur la

plateforme.

1.2.4 Lecteur de tonalité RBT

i. Ce module doit servir essentiellement pour :

La mise en mémoire cash des tonalités RBT

La sélection et la lecture des tonalités RBT.

ii. Tout changement sur le profil de l’abonné RBT (ie : changement des tonalités RBT attribuées) doit

obligatoirement mettre à jour le lecteur de tonalité RBT.

iii. Le lecteur de tonalité RBT doit supporter la lecture et l’affichage des picture/vidéo RBT.


1.2.5 Module IVR RBT

i. Ce module doit permettre aux abonnés RBT mobiles au moins :

la souscription, la désinscription au/du service RBT,

l’activation et la désactivation du service RBT,

l’achat de tonalité RBT (audio, image ou vidéo),

l’offre de tonalité RBT

l’invitation au service RBT

la consultation des tonalités publiées sur le système

la personnalisation de son compte RBT

ii. Les caractéristiques techniques de ce module sont explicitées dans le paragraphe 5- interface IVR du

chapitre IV- Interfaces.

iii. Toute tonalité RBT approuvée par l’administrateur et publiée sur le système doit mettre à jour la liste

de tonalités du module IVR-RBT.

2. Architecture d’intégration, Interfaces et Interfonctionnement

2.1 Architecture

Le schéma de l’Annexe 1 illustre l’architecture d’intégration de la plate-forme RBT avec les nœuds du réseau

mobile de Tunisie Télécom en environnement TDM.


mobile TDM et NGN de Tunisie Télécom.


mobile NGN de Tunisie Télécom.

2.2 Interfaces avec les différents nœuds du réseau de Tunisie Télécom

2.2.1 Le soumissionnaire doit s'engager à adapter et à intégrer son système aux différents nœuds du

réseau de Tunisie Télécom avec lesquels la plate-forme RBT aurait à interagir et ce, indépendamment

qu’il soit en environnement TDM, à la fois TDM et NGN et full NGN.

2.2.2 Le système proposé doit fonctionner dans l'environnement spécifié sans qu'il soit nécessaire

d'apporter des modifications techniques aux équipements déjà en service ou en cours d'installation. Tous

les équipements d'interfonctionnement ou d'interfaçage doivent être inclus dans l'offre, incluant les câbles

et toute la connectique.

2.2.3 Le système proposé conformément à la méthode d’implémentation « IN-Based sans tromboning»

doit utiliser les protocoles d’interfaçage avec les différents nœuds du réseau de Tunisie Télécom exigés

par le présent cahier des charges et spécifiés dans les annexes ci-dessus mentionnés dont notamment :

a. Interface entre le PGS et les G-MSC/SSF : INAP CS1+ nécessaire pour le contrôle de l’appel RBT

et la gestion de multi-legs en environnement TDM.

b. Interface entre le PGS et les MSC-Server : SIGTRAN nécessaire pour le contrôle de l’appel RBT et

la gestion de multi-legs en environnement NGN.

c. Interface entre la plate-forme de gestion de contenu RBT et les G-MSCs : ISUP version 4

nécessaire pour la lecture du flux audio RBT.

d. Interface entre la plate-forme de gestion de contenu RBT et les MGWs : ISUP version 4 nécessaire

pour la lecture/affichage du flux RBT audio, vidéo et image


e. Interface entre le PGS et la base de donnés utilisateur de la plate-forme de gestion de contenu

RBT : interface SOAP/XML/JSON nécessaire pour l’extraction de l’identifiant de la tonalité attribuée

par l’abonné RBT à son appelant.

f. Interface entre la plate-forme de gestion de contenu RBT et le SMSR : SMPP V3.4 nécessaire pour

tout acte initié par un abonné RBT via l’interface SMPP, ainsi que pour l’envoie des SMS de

notification.

g. Interface entre la plate-forme de gestion de contenu RBT et l’USSDC : XML/HTTP nécessaire

pour tout acte initié par un abonné RBT via USSD.

h. Interface entre la plate-forme de gestion de contenu RBT et le serveur Web : HTTP nécessaire pour

tout acte initié par un abonné RBT via le portail WEB de Tunisie Télécom.

i. Interface entre la plate-forme de gestion de contenu RBT et le serveur WAP : WAP Version

nécessaire pour tout acte initié par un abonné RBT via le portail WAP de Tunisie Télécom.

j. Interface entre la plate-forme de gestion de contenu RBT et l'OSS : SNMP V 1.0 nécessaire pour

l’envoie des traps SNMP de supervision.

k. Interface entre la plate-forme de gestion de contenu RBT et le CRM : Web services1.1 pour tout

acte initié par un abonné RBT à travers le Customer Care.

l. Interface entre la plate-forme de gestion de contenu RBT et le BSCS IX- R2: FTP nécessaire pour

l’envoie des CDR.

m. Interface de taxation avec le RI mobile : Diameter SCAP pour l’envoie des paramètres de taxation

du service RBT.

n. Interface entre la plate-forme de gestion de contenu RBT et les fournisseurs de contenu : FTPS/

HTTPS nécessaire pour la gestion des tonalités RBT (ajout, suppression, modification, etc.).

o. Interface entre la plate- forme de gestion de contenu RBT et l'EMM : FTP ; pour l’envoie des CDR

d’achat, offre, copie, etc. de sonneries RBT des abonnés mobiles post-payés.

2.2.4 La plate-forme proposée doit être capable de s’interconnecter à des plates-formes de service à

valeur ajoutée. Par conséquent, le soumissionnaire doit préciser les interfaces de connexion aux plates-

formes externes.

2.2.5 Le soumissionnaire doit expliciter en détail les changements d’ordre matériels et logiciels ainsi que

les éventuelles prestations nécessaires pour la migration de la plate-forme proposée du TDM vers les

NGNs. Un document décrivant les changements à introduire ainsi que les différentes étapes de migration

doit être présenté à l’appui.

2.2.6 La plate-forme proposée doit fonctionner à la fois dans un environnement TDM, hybride et tout

NGN et ce, en fonction de l’état d’avancement du projet MSS de Tunisie Télécom. Par conséquent, le

soumissionnaire doit fournir toutes les prestations d’installation, d’assistance, de cohabitation des

solutions en environnement TDM et NGN, etc. nécessaires à la bonne intégration de sa plate-forme dans

cet environnement hybride.

2.2.7 La plateforme proposée doit être évolutive vers le Multimédia RBT (Picture RBT, Vidéo RBT). A

cet effet, le soumissionnaire doit s’engager à fournir la liste de matériel, software, éventuelles licences

logicielles requises, prestations nécessaires pour assurer l’évolutivité de sa solution et ce, sans mettre en

risque la plateforme RBT en cours d’exploitation.

3. Logique d’un appel RBT

Les étapes d’établissement d’un appel RBT conformément à la méthode d’implémentation « IN-Based sans

tromboning » doivent être comme suit :

3.1 Cas d’un appel entrant vers un abonné ON-NET mobile

3.1.1 Dans le cas d’un appel entrant au réseau mobile de Tunisie Télécom, le GMSC/SSF (A) interroge le

HLR sur le statut de l’appelé B.


Si l’abonné B est inscrit au service RBT (sa marque TICK est activée au niveau HLR), un trigger à

l’application PGS Call Handling, hébergée au niveau du réseau intelligent mobile de Tunisie

Télécom, est lancé par le GMSC/SSF (A) interrogeant ainsi le PGS sur la logique d’appel à suivre.

Le PGS ordonne au SSF (A) d’établir un 1er leg vers l’appelé B

Si l’abonné B est joignable, la SSF informe le PGS de l’état « Alerting » de l’abonné B. Dans

ce cas, l’application PGS lance une requête à la base de données utilisateur de la plate-forme

de gestion de contenu et ce, afin d’extraire l’identifiant de la tonalité que l’appelé B a choisi

pour A. Le PGS commande de même au GMSC/SSF (A) d’établir un 2nd

leg vers le lecteur de

tonalité RBT de la plate-forme de gestion de contenu. Le jeu de la tonalité RBT commence.

Au décroché de l’appelé B, le GMSC/SSF (A) informe le PGS de cet événement, l’application

PGS commande au GMSC/SSF (A) la suppression du leg établi avec le lecteur de tonalité et de

rétablir le lien avec l’appelé B. Le jeu de la tonalité de retour RBT est, par conséquent, corrompu

et la communication entre les deux parties débute.

Dans le cas où l’appelé B est injoignable ou occupé, la tonalité de retour d’appel classique est

jouée.

Si l’abonné B n’est pas inscrit au service RBT, l’acheminement classique de l’appel aura lieu et ce,

sans aucun recours à l’application PGS.

3.1.2 La plate-forme RBT proposée doit supporter les deux méthodes d’extraction de l’identifiant de la

tonalité à être jouée par le système : par le PGS et par le lecteur de tonalité RBT de la plateforme de gestion

de contenu. Le soumissionnaire doit préciser les flux d’appel relatifs à chaque méthode ainsi que les

différentes interfaces utilisées.

3.1.3 Le soumissionnaire doit prévoir dans sa soumission la fourniture et la configuration des flux d’appels

correspondant aux cas suivants :

rejet d’appel

de non réponse (no reply)

3.2 Cas où l’appelé B active le service de transfert d’appel

La plate-forme RBT doit pouvoir associer une tonalité RBT relative au service transfert d’appel. Cette tonalité

sera configurable par l’utilisateur final lors de la personnalisation de son compte RBT via IVR ou Web.

Dans ce cas, la tonalité jouée est indépendante de l’état de l’abonné (RBT ou non RBT) sur lequel le transfert

d’appel est activé.

3.3 Cas où l’appelé B active le service double appel (ou appel en attente)

Dans le cas où l’appelé B, ayant activé le service double appel, après avoir décroché à l’appel de l’abonné A,

choisit de permuter entre les numéros des appels entrants et de laisser l’appelant A en attente, la tonalité qui

doit être jouée à l’abonné A est la tonalité de retour classique.

4. Dimensionnement

4.1 La charge de la plate-forme RBT proposée ne doit pas dépasser 70% à l’heure chargée même dans le

cas de fonctionnement de secours.

4.2 La méthodologie suivie, le calcul de dimensionnement de la plate-forme RBT ainsi que les règles

d’ingénierie doivent être précisées en détails. Tous les documents justificatifs doivent être présentés à

l’appui.

4.3 Les données prévisionnelles des paramètres de dimensionnement de la plate-forme RBT pour le cas

des abonnés mobiles résidentiels et corporate sont données dans l’Annexe 4


4.4 Dimensionnement du module PGS

Le module PGS de la plateforme proposée dans le cadre de cette consultation doit être suffisamment

dimensionné pour supporter :

une capacité logicielle de 770.000 abonnés mobile

une capacité matérielle de 770.000 abonnés mobiles.

4.5 Dimensionnement de la plateforme de gestion de contenu

La plateforme de gestion de contenu doit être suffisamment dimensionnée pour supporter :

Une capacité logicielle de 770.000 abonnés mobile

Une capacité matérielle de 1 Million abonnés mobiles

4.6 L’extension de la plate-forme doit pouvoir se faire sans rajout ou changement de matériel

(Uniquement augmentation en droit d’usage).

4.7 Les capacités ci-dessus exigées ne doivent pas diminuer en cas de fonctionnement de secours.

5. Redondance

5.1 Le soumissionnaire doit s’engager sur le fait qu’un état de dysfonctionnement brusque du PGS n’impacte

en aucun cas l’état de l’appel initié. Le soumissionnaire est tenu à expliciter la procédure de retour de

contrôle de l’appel au réseau de Tunisie Télécom. Un flux d’appel complet (différent nœuds impliqués,

messages d’établissement d’appel, nombre de tentatives de sollicitation du PGS, message d’erreur

échangés, etc.) doit être présenté à l’appui.

5.2 La plate-forme de gestion de contenu RBT proposée doit avoir une redondance matérielle et logicielle

locale. La même plate-forme doit être dupliquée sur le même site.

5.3 La plate-forme de gestion de contenu doit être 1+1 redondante.

5.4 Tous les équipements réseau à titre indicatif et non restrictif les pare-feux, les balanceurs de charge, les

switch LANs et les routeurs doivent être 1+1 redondants.

5.5 Les unités actives doivent faire une mise à jour de la base de données des unités en stand-by en temps

réel.

5.6 En cas de panne ou d’arrêt des unités actives du premier système, le second système doit être en mesure

de prendre en charge le trafic géré par la plate-forme et il doit fournir le même niveau de service et de

fonctionnalités lorsqu’il est en fonctionnement normal. Une fois le serveur actif revient en service, sa base

de données doit être mise à jour par la base de données du système de secours et ce, avant de le mettre en

service.

5.7 Tout basculement entre l’unité active et l’unité stand-by et toute reconfiguration des liens doivent se faire

automatiquement sans aucune intervention manuelle et sans interruption du service.

5.8 La plate-forme RBT doit assurer une redondance pour le trafic. Cette redondance doit permettre la

continuité des services en cas de disfonctionnement du système. Le soumissionnaire expliquera en détail

cet aspect. Le basculement de l’état de fonctionnement « Normal » à l’état de fonctionnement de

« secours » doit se faire sans répercussion sur le service et inversement de l’état de « secours » à l’état de

fonctionnement « normal ».

5.9 Tout composant de la plate-forme RBT proposée dont l’échec ou le mis-fonctionnement risque

d’entrainer un écroulement total du système doit être 1+ 1 redondant.

6. Capacité sur les interfaces


6.1 Le soumissionnaire doit fournir le nombre de liens E1/STM1 nécessaires pour écouler le trafic

provenant de / allant vers la plate-forme RBT. Le soumissionnaire doit respecter dans sons calcul les

exigences de la clause 4.2 du paragraphe 4 –Dimensionnement du présent chapitre.

6.2 Le soumissionnaire doit fournir le nombre de liaisons de signalisations SS7 nécessaires pour écouler le

trafic ci-dessus calculé. Le soumissionnaire doit respecter dans sons calcul les exigences de la clause

4.2 du paragraphe 4 – Dimensionnement du présent chapitre.

6.3 Les cartes E1/STM1 de la plateforme RBT proposée doivent être 1+1 redondantes.

7. Interfaces TCP/IP

7.1 Le soumissionnaire doit spécifier le nombre de cartes Ethernets nécessaires, elles doivent être 1+1

redondantes au niveau de chaque serveur.

7.2 L’interface TCP/IP de chaque serveur de la plate forme RBT doit avoir une capacité minimale de

100Mbits/seconde pour la prise en charge du trafic avec les interfaces, du transfert des CDR, de

l’exploitation et la maintenance, de la gestion des clients, de la connexion à l’OSS, etc.

7.3 Si ce quantitatif est jugé insuffisant par le soumissionnaire, il doit prévoir des extensions en bande

passante et en interfaces nécessaires.

8. Sécurité du Système

8.1 Le soumissionnaire doit indiquer clairement la politique de sécurité réseau adoptée pour assurer la

protection du réseau de son système contre les attaques et les intrusions extérieures. Il doit fournir à Tunisie

Télécom l’architecture détaillée du réseau de son système.

8.2 La plate-forme proposée doit être parfaitement sécurisée dont notamment:

le réseau LAN de la plate-forme doit être dans une zone dématérialisée (DMZ),

l’accès aux différentes données du système doit se soumettre à des règles de sécurité (différents

comptes d’accès, accès limité à un certain nombre d’utilisateurs / fournisseurs, algorithmes de

cryptage, CSR etc.),

l’authentification de chaque utilisateur doit se faire à l’aide d’un identificateur et un mot de passe

bien sécurisé et modifiable par l’utilisateur lui même.

8.3 L’accès à la base de donnée du système doit être optimisé afin d’assurer la sécurité, la stabilité et la

rapidité d’accès.

8.4 Le système doit enregistrer les logs des paramètres de chaque commande exécutée, de chaque

changement de configuration, etc.

8.5 La solution doit offrir la possibilité de prendre des sauvegardes du système et de ses bases de

données dans un support de stockage.

8.6 Les données confidentielles doivent être échangées encryptées soit par :

L’utilisation du protocole HTTPS/FTPS.

L’implémentation d’un tunnel sécurisé (VPN IPSec) sur les interfaces TCP/IP.

8.7 Tout soumissionnaire doit s’engager à mettre à jour les patchs de sécurité des produits déployés et

doit inclure son engagement dans le contrat de maintenance.

8.8 Tout composant de la solution RBT proposée à titre indicatif et non restrictif les serveurs de

communication, serveurs de gestion, serveurs d’application, les firewalls, les interfaces avec le réseau cœur

et le système IT, etc. ne doit en aucun cas être implémenté sous le système d’exploitation Windows et ce,

afin d’assurer la sécurité de la solution proposée et éviter l’installation/l’utilisation des patchs inutiles.


CHAPITRE VII : EXPLOITATION, ADMINISTRATION ET

MAINTENANCE

1. Gestion et maintenance de la plate-forme RBT

1.1 La solution proposée doit inclure un système permettant l’exploitation et la maintenance incluant les

modules matériels et logiciels nécessaires pour la gestion de la plate-forme. Ce système doit répondre aux

spécifications techniques du présent cahier des charges.

1.2 Le système proposé doit pouvoir être configuré à travers des interfaces de gestion orientées Web.

1.3 La plate-forme proposée doit offrir un système d’aide en ligne, fournissant des détails sur toutes les

commandes et les fonctionnalités disponibles.

2. Fonction de Gestion

2.1. Généralités

i. Le soumissionnaire doit préciser la version software du système de gestion proposé. Toute la

documentation proposée doit correspondre à la version software délivrée

ii. La plate-forme RBT doit fournir un outil orienté Web de gestion et de contrôle du système proposé.

(statistique de performance, évolution des compteurs, graphes, etc.)

iii. Le système de gestion de la plateforme RBT doit supporter le protocole SNMP V1.0 pour

s’interconnecter avec un autre système de gestion. Le soumissionnaire doit décrire le contenu détaillé

de la MIB.

iv. Le système de gestion proposé par le soumissionnaire doit communiquer avec les différents éléments

du réseau en utilisant la gestion IN-BAND. Le soumissionnaire doit décrire les caractéristiques et

l’architecture de la solution de gestion IN-BAND proposée.

v. Le soumissionnaire doit mentionner si le système de gestion proposé supporte la gestion OUT-BAND

pour secourir la gestion IN-BAND. Dans le cas favorable le soumissionnaire doit :

décrire la solution de gestion OUT-BAND

décrire comment se réalisera la commutation de la solution de gestion IN-BAND vers la solution

de gestion OUT-BAND.

vi. Le système de gestion doit permettre d’exporter les données de configurations et les statistiques, vers

un format de base de données standard.

vii. Le soumissionnaire doit décrire les facilités disponibles dans le système de gestion pour

l’exportation des rapports de statistique et d’analyse et les mesures de trafic vers un fichier de format

standard (.doc, .txt, .xls, .pdf…..).

viii. Chaque élément réseau de la plateforme doit supporter une interface de gestion (control et

configuration) locale. La gestion locale devra supporter les mêmes fonctions de gestion fournies par le

système de gestion centralisée. Toutes limitations devront être indiquées par le soumissionnaire

ix. Afin de garantir les meilleures performances des équipements proposés et d’offrir une excellente

qualité de service, le soumissionnaire doit proposer un système de gestion centralisé. Le système

proposé doit supporter les fonctions FCAPS (Fault, Configuration, Accounting, Performance and

Security) pour les équipements proposés.

2.2 Gestion du système

i. Le système de gestion proposé doit offrir une vue détaillée de l'ensemble des objets gérés

ii. Le soumissionnaire doit indiquer tous les types de liaisons et les protocoles supportés entre le système de

gestion proposé et les différents éléments du réseau.

iii. Le système de gestion proposé doit supporter les facilités (Hardware et Software) pour backup et le


restore du software du système et de la base MIB. Le soumissionnaire doit décrire en détail ces

fonctionnalités.

iv. L’ensemble des opérations réalisées par les administrateurs et les exploitants doit être inscrit dans des

fichiers logs en précisant l’heure et la date de l’opération. La modification de ces fichiers logs ne devra

être possible que par des administrateurs ayant un privilège d’accès de haut niveau.

v. Le système de gestion proposé doit supporter la mise à jour, le patch, le Back-up et la récupération à

distance du Softwares des éléments réseau de la plateforme RBT et ce sans redémarrage ou interruption

de services. Le soumissionnaire doit décrire en détail toutes les fonctions supportées. Toutes les

limitations devront être indiquées par le soumissionnaire.

2.3 Gestion de la configuration

i. Le système de gestion proposé doit permettre au moins la visualisation des informations suivantes:

a) Type, modèle, capacité des éléments réseau de la plateforme RBT

b) Localisation des équipements

c) le nombre de ports installés, utilisés, disponibles,

d) Nombre de connexions crées, utilisés, disponibles,

e) Configuration des VLAN

ii. Le système de gestion proposé doit disposer des interfaces permettant un accès multiutilisateurs à la

création, suppression, modification et visualisation des configurations matérielles et logicielles.

iii. Le système de gestion proposé doit disposer d'une base de données centralisée incluant au moins :

a) L’ensemble des configurations matérielles et logicielles de chaque élément réseau de la

plateforme

b) La topologie du réseau.

iv. Le système de gestion proposé doit permettre la possibilité d’appliquer des configurations standards

modifiables par l’exploitant.

v. Le système de gestion proposé doit supporter les fonctions de sauvegarde et de restauration de

l’ensemble des données de configuration pour un ou plusieurs éléments du réseau sans interruption de

service.

vi. Le système de gestion proposé doit permettre le reset/restart des éléments du réseau.

vii. Le système de gestion proposé doit permettre le paramétrage de plusieurs éléments du réseau en même

temps.

viii. Le système de gestion proposé doit permettre le roll back vers une configuration de backup spécifique.

Le soumissionnaire doit décrire en détail cette fonctionnalité.

2.4 Gestion des services

i. Le soumissionnaire doit décrire l'architecture de sa plate-forme de gestion des services et l'ensemble des

outils offerts pour le provisioning et l’activation des services.

ii. Le système proposé doit supporter et fournir la fonctionnalité de gestion en masse des profils d’abonnés

ainsi que la gestion en masse des tonalités publiées sur le système. Le soumissionnaire doit décrire en

détail comment cette fonctionnalité est supportée.

iii. Le système proposé doit permettre au moins :

a) La configuration et la gestion du service RBT (cycle de vie des abonnés, cycle de vie des

tonalités RBT, classe de service, promotions, gestion des fournisseurs de contenu, etc.),

b) L’exploitation commerciale du service RBT (statistiques des promotions lancées, statistiques


d’usage, etc.)

c) la gestion du trafic RBT : le soumissionnaire doit expliquer clairement les algorithmes de

gestion, de régulation et de limitation du trafic en cas de pics de trafic.

2.5 Gestion des fautes et des alarmes

i. Le système de gestion proposé doit présenter les alarmes détectés en mode liste et graphique et en temps

réel pour l'ensemble des éléments réseaux et leurs liaisons.

ii. Le système de gestion proposé doit avoir un code couleur permettant de distinguer les différents états et

les niveaux de sévérité des alarmes. Les états et les niveaux de sévérité des alarmes se propagent de la

vue graphique de plus bas niveau à la vue graphique de plus haut niveau.

iii. Le soumissionnaire doit présenter l’ensemble des informations d’alarmes et observations pour les

éléments du réseau et les services gérés par le système de gestion proposé.

iv. Le système de gestion proposé doit être capable de signaler les alarmes non acquittées graphiquement

(e. g clignotement).

v. Le système de gestion proposé doit être capable d’empêcher l’affichage des alarmes pour des éléments

spécifiques du réseau (par exemple lors de l’installation).

vi. Le système de gestion proposé doit être capable de filtrer les alarmes selon des critères spécifiés par un

opérateur. Le soumissionnaire doit décrire en détail cette fonctionnalité.

vii. Le système de gestion proposé doit offrir l’exportation et l’importation d'archives pour consultation off

line d'une base d'alarmes. Le soumissionnaire doit décrire en détail cette fonctionnalité.

viii. Le système de gestion proposé doit supporter la commutation automatique vers les éléments de

redondance dans le cas de la détection d’un élément défectueux. Le soumissionnaire doit décrire en

détail cette fonctionnalité.

ix. Le soumissionnaire s’engage qu’aucune faute n’est perdue, de sa détection à son enregistrement dans le

système de gestion. En particulier, le soumissionnaire indique si un mécanisme de régulation des flux

entre le système de gestion et les éléments du réseau est prévu pour gérer les rafales d’alarmes.

2.6 Gestion de sécurité du système

i. L’affectation des droits d’accès pour les différents profils ne doit être contrôlée que par l’administrateur

du système.

ii. Le système de gestion proposé doit pouvoir contrôler l’accès multiple avec les mêmes paramètres

d’authentification. Le nombre d’accès multiple doit être paramétrable.

iii. Le système de gestion proposé doit pouvoir détecter une session inactive et exécuter un LOGOFF de

cette session (la durée du TIME OUT de la session doit être configurable).

iv. Le système de gestion proposé doit contrôler le nombre de tentatives incorrectes de LOGIN, bloquer

l’accès quand le nombre autorisé est atteint et aviser l’administrateur.

2.7 Gestion de la performance du système et statistiques

2.7. 1 Gestion de la performance

i. Le soumissionnaire doit préciser et décrire la liste des tests de performance qui peuvent être réalisés sur

le système.

ii. Le système de gestion proposé doit permettre de superviser moyennant des compteurs et des graphes et

ce, d’une façon continue les performances de la plateforme (capacité des disques, taux d’occupation des

processeurs, etc.).


iii. Le soumissionnaire doit décrire s’il est possible de fixer la durée du test de performance et de fixer le

seuil de performance pour l’analyse et l’exploitation des éléments réseaux de la plateforme.

iv. Les résultats d’analyse, de supervision et de test de performance devront être affichés par le système de

gestion. Le soumissionnaire doit décrire les types et les modes d’affichage.

v. Chaque fois, les compteurs de performance atteignent une valeur seuil définie par l’administrateur, le

système doit être en mesure d’envoyer à l’administrateur de la plate-forme des notifications par Email,

SMS ou par des trapes SNMP.

vi. Les données de performances devront être enregistrées dans des fichiers par le système de gestion et

devront être valables pour des utilisations ultérieures (rapport, analyse…).

vii. Les rapports de performance générés par le système de gestion doivent être sous format Excel, HTML,

graphique ou CSV.

viii. La plateforme proposée doit permettre l’envoie des rapports de performance vers une liste de contact

bien définie et ce, avec une fréquence configurable par l’administrateur du système ou bien à la

demande.

2.7.2 Statistiques

i. Les statistiques relatives à l’appel RBT générées par la plateforme proposée doivent inclure au moins :

Le nombre de fois les tonalités RBT n’ont pas été chargées avec succès.

Le nombre de fois pour lesquelles l’abonné A abandonne l’appel avant que l’abonné B décroche.

Le nombre de fois pour lesquelles l’abonné B est occupé.

Le nombre de fois pour lesquelles l’abonné B est injoignable.

Le nombre de fois où la sollicitation de la base de données de la plateforme échoue.

Le nombre de fois où le système détecte un état de congestion

ii. Les statistiques relatives aux tonalités RBT sur la plateforme proposée doivent inclure au moins :

Le nombre de tonalités RBT téléchargées par jour par canal

Le nombre de tonalités RBT chargées sur le système par fournisseur de contenu.

Le nombre de tonalités RBT actives par fournisseur de contenu

Le nombre de tonalités RBT en instance par fournisseur de contenu

Le nombre de tonalités RBT rejetée par fournisseur de contenu

iii. Les statistiques relatives aux donnés d’inscription au service RBT doivent inclure au moins :

Le nombre d’abonné inscrits au service par canal

L’évolution des licences allouées par période

iv. Le soumissionnaire doit également expliciter la liste exhaustive des statistiques fournies sur son système.

v. La visualisation des statistiques de performance du système doit être sous forme de graphes.

3. Equipements de gestion et de maintenance

Le soumissionnaire doit fournir au minimum deux ordinateurs portables puissants et une imprimante pour

assurer l’exploitation, l’administration, la maintenance et l’édition des statistiques de la plate-forme proposée.

Le soumissionnaire doit sous-traiter la fourniture de ces équipements auprès d’une entreprise tunisienne.

Les caractéristiques techniques minimales demandées de ces équipements sont les suivantes :

3.1 Ordinateurs de gestion

Processeur

Nombre de cœur : 2

Fréquence d’horloge : 2,1 GHz


Mémoire cache de niveau 2 : 2 Mo

Mémoire centrale:

Type de mémoire : DDR3

Capacité RAM : 8 Go

Disque dur:

Capacité : 500 Go

Moniteur graphique:

Taille 17 pouces

Type TFT

Résolution 1024*768 pixels

Lecteur optique

Type Graveur DVD (+/‐ R +/-RW) double couches

Carte Réseau

Port : 1 x RJ 45

LAN Gigabit Ethernet 10/100/1000 Mbps intégré 802.11b/g

Souris

Type Optique

Interface USB

Clavier

Clavier complet avec pavé numérique intégré.

Interfaces d’entrées/Sorties:

Sortie écran VGA

4 Ports USB 2.0

Système d’exploitation

Une licence professionnelle d’exploitation, d’administration, de maintenance et de génération des

statistiques de la plate-forme basée sur le système d’exploitation UNIX doit être fournie.

3.2 Imprimante laser

Vitesse d’impression: jusqu’à 30 ppm A4.

Résolution d’impression : 1200 dpi

Mémoire : 32 Mo en standard (SDRAM) Extensible jusqu’à 256 Mo.

Interfaces standard :

o Parallèle Bidirectionnelle rapide IEEE 1284 ou USB

o Ethernet 10/100 Base T.

4. Fiabilité

4.1 Une modification de la configuration de la plate-forme ne doit pas perturber le fonctionnement global du

système, ni nécessiter un arrêt total du système.

4.2 La plate-forme proposée doit comporter un mécanisme de surveillance des “processus” tournant dessus. En

cas d’arrêt d’un processus, ce mécanisme le relancera automatiquement.

4.3 Le système doit offrir des outils d’aide à la localisation des pannes.

4.4 La fiabilité des équipements doit être supérieure ou égale à 99.999%.


4.5 Le système doit avoir été soumis à des essais rigoureux qui lui confèrent les meilleures garanties de

performance.

4.6 Le soumissionnaire doit présenter des chiffres significatifs sur la fiabilité des équipements qui sera

exprimée par leurs taux de défaillances. Les calculs de fiabilité seront basés sur les taux de défaillances des

composants indiqués dans les documents de l'UIT-T.

4.7 Le soumissionnaire doit présenter la liste des cartes et des modules formant le système, ainsi que le temps

individuel moyen calculé entre les pannes (MTBF). En outre, il doit détailler la base de calcul du MTBF sur

les différents modules, montrant les méthodes de calcul de la disponibilité du système.

4.8 Le soumissionnaire doit prévoir la duplication des modules supportant les fonctionnalités suivantes :

Traitement “ on-line ” de la signalisation

Enregistrement des données d’exploitation

Transfert des données de facturation.

4.9 Les outils informatiques (hardware et software) utilisés doivent présenter une grande tolérance aux pannes

et doivent être munis d’une solution de sauvegarde automatique.

4.10 La durée de vie de la plate-forme RBT doit être égale à 10 ans au minimum.

4.11 Les mises à jour matérielles et logicielles de la plate-forme RBT proposée ne doivent pas perturber le

fonctionnement du système. Le soumissionnaire doit décrire en détail les procédures de ces mises à jour.

4.12 Le nombre total de redémarrages des serveurs de la plate-forme proposée doit être inférieur à cinq

redémarrages par an.

4.13 Dans 90% des cas de dérangements, le temps effectif de réparation du matériel doit être inférieur à 1

homme/heure.

5. Disponibilité générale

5.1 Le soumissionnaire doit indiquer et s’engager sur la disponibilité du système proposé aux moyens

d’indicateurs mesurant la capacité du système à accomplir.

5.2 Le système proposé doit être opérationnel et doit accomplir toutes les fonctions pour lesquelles il est conçu

pendant 24 heures par jour et 7 jours par semaine.

5.3 Sur une durée de mesure d’une année, le système proposé doit avoir une disponibilité générale de

99,999% lorsque les durées de coupure du système et les durées de réparation sont prises en compte.


CHAPITRE VIII : PRESTATIONS

1. Prestations d’installation et de mise en service

1.1 Tunisie Télécom entend acquérir une plate-forme RBT installée et en état de marche.

1.2 La soumission porte sur l’installation des équipements proposés et leur mise en service incluant aussi bien

l’ingénierie de l’installation du système ainsi que les prestations de coordination, d’installation, de test, de mise

en service et de réception.

1.3 Un planning de réalisation prévisionnel doit être présenté par le soumissionnaire détaillant les différentes

tâches à réaliser.

1.4 Toutes les prestations de reconnaissance des lieux, d’installation des équipements, de test, de mise en

service et de réception sont à la charge du soumissionnaire.

1.5 Tous les équipements et prestations nécessaires à l’intégration du système dans le réseau existant,

conformément aux exigences du cahier des charges, permettant de mettre en service les fonctionnalités et

services demandés doivent être fournis.

1.6 Toute omission constatée lors de l’exécution du projet et qui aurait dû être fournie par le soumissionnaire

conformément au cahier des charges, sera à la charge du soumissionnaire.

2. Documentation

2.1 La documentation à fournir doit être la plus récente et doit correspondre à la version logicielle et

matérielle proposée par le soumissionnaire, elle doit être claire, exacte et concise.

2.2 Le soumissionnaire doit fournir sur papier et en format électronique les documentations nécessaires pour

toutes les fournitures proposées notamment les documents décrits ci-dessous et ce, en 4 exemplaires sur

papier et 4 copies en format électronique.

2.3 Description fonctionnelle détaillée de la solution

Les documents descriptifs fonctionnels de la solution doivent inclure au moins :

a) L’architecture logique globale du système,

b) L’architecture matérielle du système

c) Les caractéristiques, le dimensionnement et la capacité de chaque composante du système,

d) La conception technique,

e) Le logiciel et le langage utilisés,

f) Les règles de dimensionnement du système

2.4 Description technique des fournitures

Les documents descriptifs techniques des fournitures doivent inclure les spécifications techniques de tous les

éléments de la solution proposée (serveurs, firewalles, imprimantes, routeurs, gateway, etc.)

2.5 Les spécifications des interfaces

Les documents descriptifs des interfaces doivent inclure les spécifications techniques détaillées de toutes les

interfaces et les protocoles utilisés.

2.6 Les manuels d’exploitation

Les documents relatifs à l’exploitation doivent comporter les manuels d’exploitation tels que :

a) Les procédures de configuration des équipements,

b) Les procédures de mesure de trafic,

c) Le mode de gestion de la qualité d’écoulement du trafic,

d) Les procédures de sauvegarde des données de configuration,


e) Les procédures des tests de performances des lignes abonnés.

2.7 Les manuels de maintenance et les guides de diagnostic

2.8 Les documents relatifs à la maintenance des équipements doivent inclure les procédures nécessaires pour:

a) Les opérations de maintenance préventive et corrective,

b) La maintenance et le réglage périodique,

c) Remédier aux défaillances de fonctionnement des circuits,

d) Remédier aux défaillances de composants, de blocs et de sous systèmes,

e) Remédier aux anomalies de type logiciel,

f) L’auto vérification du système,

g) Le redémarrage du système en cas de panne,

h) Interpréter convenablement les indications d’alarmes et les diagnostics des dérangements fournis

par le système ainsi que les procédures de remplacement et de réparation des organes

défectueux.

2.9 Les manuels d’administration et les guides d’installation hardware et software

2.10 Les documents relatifs à l’administration et l’installation du système doivent englober les opérations

d’installation, de configuration et les spécifications particulières du lieu d’installation notamment :

a) Un manuel relatif aux procédures d’installation,

b) Des schémas d’installation,

c) Des spécifications quantitatives, électriques et mécaniques,

d) Les schémas des circuits et des interfaces.

3. Formation

3.1 Modules de formation

Le soumissionnaire proposera une offre de formation qui sera assurée pour le personnel de Tunisie Télécom.

Le programme de formation proposé permettra au personnel de Tunisie Télécom de maîtriser aussi bien les

aspects techniques de la solution (l’ingénierie, la configuration, l’exploitation, la maintenance du système)

proposée ainsi que les aspects commerciaux (utilisation du service, commercialisation du service, etc.).

Il couvrira au minimum les modules suivants :

3.1.1 Ingénierie et planification

Ce module portera sur les aspects théoriques liés à l’ingénierie, le dimensionnement, la planification et

l’optimisation de la plate-forme RBT.

Ce module est destiné aux ingénieurs concepteurs des réseaux et aura pour objectifs de permettre aux stagiaires

de maîtriser au moins :

La conception de la plate-forme (architecture, dimensionnement, modules constitutifs de la plate-forme,

fonctionnement des différents modules, etc.),

La planification et le dimensionnement des différents équipements de la plate-forme proposée,

La liste de protocoles et de standards supportés,

La logique du service RBT (appel RBT, achat de tonalité, etc.)

Les fonctionnalités et les services offerts par la plate-forme RBT

3.1.2 Exploitation et maintenance locale et centralisée

Ce cours portera sur l'exploitation des différentes composantes de la plate-forme RBT proposée, l'utilisation

des dispositifs incorporés et des terminaux locaux de gestion pour le diagnostic des défauts et leur analyse ainsi

que la relève d’anomalies et le remplacement des organes et composants défectueux.


Il sera destiné aux techniciens de l’exploitation et la maintenance des équipements et les ingénieurs

responsables de la gestion de la plate-forme RBT.

A l’issu de cette formation, les stagiaires doivent maitriser les méthodes utilisées pour :

répertorier les différentes unités, décrire leurs fonctions, détecter les situations de mauvais

fonctionnement.

identifier et localiser les différents défauts sur le système

relever les pannes et interpréter les alarmes

configure l’environnement du système

3.1.3 Administration du système

i. Ce module est destiné aux ingénieurs responsables de l’administration de la plate-forme RBT.

ii. Ce module doit assurer :

Une formation d’une équipe solide des experts sur le système,

Une formation pratique sur l’administration du système dans le centre de formation du titulaire et

ce, sur une plate-forme réelle (autre que celle proposée dans la présente consultation).

iii. Le module de formation portera au moins sur :

L’administration des tonalités RBT,

L’administration des abonnés au service RBT

L’administration des fournisseurs de contenu RBT

L’administration des différents services

L’installation du service,

La gestion des clients,

La gestion des contenus,

La gestion des fournisseurs de contenu,

La gestion de l’accès aux tonalités.

La gestion de l’accès aux services

L’administration du système de gestion proposé et la maîtrise de toutes les fonctions de gestion

décrites dans le présent cahier des clauses techniques.

Le contrôle des performances,

La gestion des statistiques et des rapports système,

La gestion de la sécurité.

iv. A l’issu de cette formation, les stagiaires doivent maîtriser toutes les fonctions de gestion et

d’administration décrites dans le présent cahier des clauses techniques.

v. Par ailleurs, l’agent formé doit être en mesure de réaliser à lui seul les opérations suivantes :

Analyser les performances de la plate-forme RBT à travers le système de gestion et en prendre

les mesures préventives nécessaires,

Configurer tous les éléments de la plate-forme RBT à partir du système de gestion centralisée,

Remettre le système en situation normale en cas de défaillance sur un élément de la plate-forme.

3.1.4 Aspect Commercial

Ce module est destiné aux agents chargés de la commercialisation des services de la plate-forme et de

l’assistance clients couvrant au moins les éléments suivants :

Les différents services offerts par la solution,

L’assistance des clients à l’utilisation de ces services,

3.2 Evaluation des stagiaires

A l’issue des différents modules de formation, une évaluation sera effectuée pour chaque stagiaire. Elle devra

refléter les connaissances acquises lors de cette formation avec des épreuves pratiques. En particulier, le


soumissionnaire est tenu à communiquer à TUNISIE TELECOM et pour chaque stagiaire un certificat de

formation selon le modèle de l’Annexe 5 du présent cahier des charges.

3.3 Plan de formation, Nombre de stagiaires, durée de formation

Compte tenu du calendrier de livraison et d'installation des systèmes proposés, le soumissionnaire établira un

plan de formation, qui comprendra les renseignements suivants :

Nature et consistance des modules à dispenser.

Qualifications recommandées des stagiaires pour chaque cours.

Qualifications des formateurs (joindre CV ou profil type du formateur).

Programmation provisoire des cours.

Le nombre de stagiaires et les durées pour chaque cours sont comme suit :

Module de formation Nombre de

sessions

Nombre de

stagiaires

/session

Durée minimale en

jours ouvrables /

session

Ingénierie et planification 1 8 5

Exploitation et maintenance locales 1 8 5

Administration des systèmes 1 8 5

Commercial 1 8 5

3.4 Coût de formation

Le Soumissionnaire devra indiquer dans son offre commerciale les coûts de chaque module , étant entendu

que ces coûts doivent inclure toutes les dépenses encourues par le personnel du soumissionnaire en Tunisie

et la prise en charge de la formation du personnel de Tunisie Télécom pour les accommodations fournies

(pause café, déjeuner, locaux de formation, moyens de formation, etc.)

3.5 Qualification des formateurs

Les formateurs doivent satisfaire les conditions suivantes :

avoir une expérience professionnelle de 3 ans dans le domaine des TIC ou étant certifié

constructeur

ayant assuré au moins 4 actions de formation dans le domaine objet de la présent consultation et ce,

pour le compte des opérateurs de télécom.

Maitriser la langue française

Pour les formations dans le centre de formation du titulaire et sur une plate-forme réelle (autre que celle

proposée dans la présente consultation), les prix doivent comprendre la prise en charge complète (frais de

déplacement et séjour) des personnes à former.

4. Assistance Technique

4.1 Le soumissionnaire doit inclure dans sa soumission les prestations d’assistance technique sur site

d’un expert qualifié du système proposé et ce, pour une période de 60 jours ouvrables à partir d’une date

qui sera définie ultérieurement par Tunisie Télécom.

4.2 Les tâches principales de l’expert seront d’assister les techniciens de Tunisie Télécom à exécuter les

procédures principales de gestion, d’exploitation et de maintenance du système proposé sur site ou à travers

le gestionnaire.

4.3 Cette assistance doit porter sur la maintenance matérielle et logicielle nécessaire au bon


fonctionnement de tous les équipements objet de la présente consultation. Elle concerne l’entretien de la

plate-forme et la résolution de tous les problèmes liés aux équipements et logiciels de la plate-forme

proposée.

4.4 Les critères auxquels doit répondre l’expert sont les suivants :

L’expérience : l’expert doit avoir au moins 3 ans d’expérience dans le domaine des plates-formes

de services à valeur ajoutée des réseaux GSM.

L’expert doit avoir assuré au moins deux fois l’assistance technique chez des opérateurs pour une

période minimale de 2 semaines chacune.

5. Assistance commerciale

5.1 Le soumissionnaire doit inclure dans son offre les prestations d’assistance commerciale sur site d’un

assistant hautement qualifié et ayant une bonne expérience du produit, et ce, pour une période de 60 jours

ouvrables à partir d’une date qui sera définie ultérieurement par Tunisie Télécom.

5.2 L’assistance commerciale portera sur :

5.2.1 le développement commercial du service: définition du plan marketing, discussion de la politique

tarifaire, préparation des manuels d'utilisation et des campagnes promotionnelles, etc. ;

5.2.2 L'aide à l'exploitation commerciale: lancement du produit et de ses options, procédures de

commercialisation, support clients, calibrage du personnel de vente, etc.

5.3 Les critères auxquels doit répondre l’expert sont les suivants :

5.3.1 L’expérience : il doit avoir au moins 3 ans d’expérience dans le domaine des plates-formes de

services à valeur ajoutée des réseaux GSM.

5.3.2 Il doit avoir assuré au moins deux fois l’assistance commerciale chez des opérateurs pour une

période minimale de 2 semaines chacune.

6. Maintenance et pièces de rechanges

6.1 Le soumissionnaire doit proposer une offre de maintenance après garantie du réseau à installer dans le

cadre du présent projet sur la base du contrat-type, joint en Annexe N°6.

6.2 Dans le cadre du contrat de maintenance, le soumissionnaire fournira les prestations de maintenance et

les pièces de rechanges nécessaires pour maintenir le réseau en parfait état de fonctionnement.

6.3 Le soumissionnaire précisera les montants des prestations de maintenance (hors fourniture de

rechange) sur la base de la maintenance de la plate-forme objet de ce projet pour une période de 3 ans

après l’expiration des délais de garantie conformément aux conditions du contrat de maintenance joint en

Annexe N°6.

6.4 Le soumissionnaire doit présenter une liste séparée de pièces de rechanges avec indication de leurs

prix unitaires, recommandée pour garantir l'exploitation de tous les équipements commandés. Cette liste

doit porter sur tous les équipements objet de la présente consultation. Elle sera établie sur la base de la

fiabilité de ces équipements.

6.5 L’offre doit aussi justifier le dimensionnement des lots de rechanges et présenter les règles de calcul

du MTBF, ainsi que les formules détaillées pour évaluer le taux de disponibilité global de chaque

composant proposé.

6.6 Le montant du lot de rechanges objet de la présente consultation doit être égal à 3% du montant total

des fournitures (fournitures importées et fournitures locales) proposées dans l’offre et ce, conformément

au tableau récapitulatif des prix de l’Annexes 7 du présent cahier des clauses techniques.

6.7 Les prix unitaires proposés pour les pièces de rechanges ne peuvent pas excéder, sous peine de nullité

de l’offre, les prix unitaires des pièces identiques fournies dans l’offre, tous rabais compris.


6.8 Le soumissionnaire ne sera pas autorisé à utiliser le lot de rechanges pour l’installation et la mise en

service des équipements proposés.

6.9 Le soumissionnaire présentera, impérativement, les procédures de repair & return et les délais de

réparation et de retour sur site des pièces défectueuses.

7. Planning de mise en service

Un calendrier global dressé par le Soumissionnaire doit être joint à la soumission avec une durée d'exécution

du projet fixée à 12 semaines à partir de la date d’entrée en vigueur du marché.

Le soumissionnaire est tenu à préciser tous les facteurs et délais intervenant dans le processus de réalisation du

programme ainsi défini (fabrication, expédition, installation, test, mise en service, etc.) et de présenter un

planning prévisionnel détaillé de mise en œuvre du programme correspondant.

8. Climatisation

Le soumissionnaire est tenu d’indiquer le dégagement calorifique des équipements proposés et ce, afin de

calculer la puissance des climatiseurs qui seront déployés par Tunisie Télécom dans le cadre de la présente

consultation.

9. Tableau de conformité

Les tableaux de conformité ci-après doivent être remplis obligatoirement par le soumissionnaire. Ces

tableaux énumèrent les exigences du cahier des charges.

Dans le tableau de conformité, le soumissionnaire doit inclure obligatoirement les termes « Conforme » ou

« non-conforme » et un bref commentaire avec un renvoi à la partie de l’offre technique fournissant les détails

demandés.

Bla

Documents

Transcript of Bla