Bla

SOCIETE NATIONALE DES TELECOMMUNICATIONS

(TUNISIE TELECOM)

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

CONSULTATION N°…

POUR

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

CAHIER DES CLAUSES TECHNIQUES

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 L’Abonné destinataire de l’appel ou récepteur de l’acte
ASN.1 Abstract Syntax Notation One
ATM 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 European Telecommunications Standards Institute
GIF Graphic Interchange Format
GSM Global System for Mobile communications
JPEG Joint Photographic Experts Group
HLR Home Location Register
INAP Intelligent Network Application Part
INS Intelligent system
IMSI International Mobile Subscriber Identity
IP Internet Protocol
ISUP ISDN User Part
IVR Interactive Voice Response
MAP Mobile Application Part
MIB Management Information Base
MSISDN Mobile Subscriber Integrated Services Digital Network Number
MSS Mobile Soft Switch
MPEG Moving Picture Experts Group,
NGN Next Generation Network
OSS Operation Sub System
PGS Personalized Greeting Service
RI Réseau Intelligent
RBT 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 Value Added Services
VXML Voice XML
WAP Wireless Application Protocol

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.
Consultation N°… pour l’installation, le test et la mise en place d’une plateforme RBT 5

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.1La 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.2Le système proposé doit pouvoir être configuré à travers des interfaces de gestion orientées Web.
1.3La 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 :

Nombre de Durée minimale en
Nombre de
Module de formation stagiaires jours ouvrables /
sessions
/session 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.8Le soumissionnaire ne sera pas autorisé à utiliser le lot de rechanges pour l’installation et la mise en
service des équipements proposés.
6.9Le 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

Contenu connexe

Tendances

Bla