Modèle vIMS RFI&RFP

Modèle vIMS RFI&RFP

Modèle vIMS RFI&RFP

Version Date Auteur Révisé par Remaue

CCN Product
V1.00 2017-2-21 N’est pas autorisé aux tiers
Line

Table des matières

© 2020 ZTE Corporation. Tous les droits réservés.

ZTE CONFIDENTIAL: Ce document contient des informations de propriété de ZTE Corporation et ne doit pas
être communiqué ou transmis à des tiers sans autorisation préalable de ZTE.
En raison de la mise à jour et de l'amélioration des produits et des technologies de ZTE, l'information du
document est soumise à des changements sans notification préalable.
.

All rights reserved. No spreading without permission of ZTE. 1

 Modèle vIMS RFI&RFP

Modèle vIMS RFI&RFP.......................................................................................................... 1

1 BESOINS GENERAUX........................................................................................3
1.1 LES CONCEPTS RELATIVES A L’ARCHITECTURE NFV...................................3
1.1.1 CONFORMITE AUX STANDARDS.......................................................................3
1.1.2 ARCHITECTURE DE LOGICIEL VNF...................................................................4
1.1.3 INFORMATION DE DESCRIPTION ET MODÉLISATION DES DONNÉES..........7
1.1.4 ENVIRONNEMENT ARCHITECTURAL IMS.........................................................7
1.1.5 INTERFONCTIONNEMENT DES VNFs AVEC NFVI............................................9
1.1.6 PROCESSUS INFLUENCÉS..............................................................................10
1.2 VIRTUALISATION - EXIGENCES NON FONCTIONNELLES.............................12
1.2.1 GENERALITES...................................................................................................12
1.2.2 ELASTICITY........................................................................................................13
1.2.3 DISPONIBILITÉ & RÉSILIENCE & GÉO-REDONDANCEY................................14
1.2.4 SECURITE..........................................................................................................17
1.2.5 COEXISTENCE AVEC DES RÉSEAUX EXISTANTS – TRANSITION................18

2 Exigences générales du IP Multimedia subsystem pour le réseau de

l’opérateur XXX....................................................................................................................19
2.1.1 Généralité............................................................................................................ 19
2.1.2 Besoins de l’O&M du réseau...............................................................................20
2.1.3 Conformité au Standard......................................................................................20
2.2 Exigences détaillées relatives à IMS Core...........................................................26
2.2.1 A-SBC.................................................................................................................26
2.2.2 I-SBC................................................................................................................... 30
2.2.3 I-CSCF................................................................................................................ 31
2.2.4 S-CSCF............................................................................................................... 33
2.2.5 HSS/SLF............................................................................................................. 36
2.2.6 MMTel AS/SCC AS............................................................................................39
2.2.7 MGCF/IM-MGW..................................................................................................42
2.2.8 MRFC/MRFP.......................................................................................................43
2.2.9 Charging.............................................................................................................. 44
2.2.10 ENUM/DNS......................................................................................................... 47
2.2.11 AGCF.................................................................................................................. 49

3 Annexe A........................................................................................................... 52

2 All rights reserved. No spreading without permission of ZTE.

 Modèle vIMS RFI&RFP

1 BESOINS GENERAUX

2 LES CONCEPTS RELATIVES A

L’ARCHITECTURE NFV

3 CONFORMITE AUX STANDARDS

1.1.1.1 Standards-01
L'architecture de la solution NFV proposée doit être conforme au cadre architectural
présenté dans le document ETSI GS NFV 002 et suivre les concepts qui y sont
énoncés.

1.1.1.2 Standards-02
Si le fournisseur ajoute un autre élément relatif à l'architecture ; Il doit identifier ledit
élément ainsi que son rôle fonctionnel et l'interfonctionnement avec les autres
éléments, y compris les raisons de l’introduction de cet élément.

1.1.1.3 Standards-03
Si le vendeur ne peut pas prendre pas en charge un élément particulier
d'architecture et introduit des éléments tiers pour le but de la réalisation de
l'architecture NFV, le vendeur doit identifier ces éléments, leurs fonctions, leur rôle
architectural et fournir toutes les informations nécessaires.

1.1.1.4 Standards-04
Le fournisseur doit fournir des informations sur la mise en œuvre de l'ensemble de
l'environnement VNF - VNFs, vEMS (s), NFVI, VNFM(s), VNFO, Service et VNF et
la description de l'infrastructure (y compris par exemple VNF Descriptor). Si un ou
plusieurs de ces composants architecturaux ne sont pas pris en charge dans sa
mise en œuvre virtualisée, le fournisseur doit l'identifier et clarifier les raisons.

All rights reserved. No spreading without permission of ZTE. 3

 Modèle vIMS RFI&RFP

1.1.1.5 Standards-05
Le fournisseur doit aligner les termes et définitions architecturaux sur les
constructions d'architecture NFV, les fonctions de support et les interfaces
appliquées dans la solution NFV proposée avec ceux spécifiés dans les documents
ETSI GS NFV 002, 003 et 004. Le fournisseur doit fournir un mapping strict entre
eux et identifier les écarts, le cas échéant

1.1.1.6 Standards-06
Le fournisseur doit clarifier ces divergences (par exemple, en cas d’introduction des
éléments en plus ou l'absence de constructions architecturales NFV déclarées par
l'ETSI, ou de fonctions de support et d'interfaces) et les raisons / justifications
relatives. Si différentes constructions / blocs VNF, fonctions de support et / ou
interfaces ont été introduits en plus de ceux spécifiés par ETSI, le fournisseur doit
les identifier et fournir leur rôle et tout au long de la description.

1.1.1.7 Standards-07
Le fournisseur doit fournir des informations sur la manière dont les termes et
définitions architecturaux de la solution NFV proposés sont configurés avec les
termes et définitions énoncés par l’ETSI dans les spécifications : ETSI GS NFV INF
001-005 & 007, ETSI GS NFV MAN 001, ETSI GS NFV PER 001, ETSI GS NFV-
REL 001, ETSI GS NFV-SEC 001, ETSI GS NFV-SWA 001.

1.1.1.8 Standards-08
Le fournisseur doit fournir pour chaque VNF un modèle complet d'informations
descriptives conformément à l'ETSI GS NFV 004. Le modèle doit fournir des
informations sur le déploiement et le comportement des VNFs, y compris à titre
d’exemple la structure des attributs VNF opérationnels, les caractéristiques du
service réseau pris en charge par le VNF en termes de capacité, performances,
résilience, contraintes et sécurité.

4 ARCHITECTURE DE LOGICIEL VNF

4.1.1.1 VNF-SW-Architecture-01
Le fournisseur doit prendre en charge la mise en œuvre virtualisée de toutes les NF
définis (SBC,CSCF,MMTEL-AS,ENUM,HSS、BSF).

4 All rights reserved. No spreading without permission of ZTE.

 Modèle vIMS RFI&RFP

4.1.1.2 VNF-SW-Architecture-02
Le fournisseur doit fournir des informations sur toutes les NF supplémentaires
prises en charge, à l'exception de celles mentionnées ci-dessus.

4.1.1.3 VNF-SW-Architecture-03
Le fournisseur doit fournir des informations sur le mapping de l'architecture de la
solution NFV proposée avec l'architecture ETSI NFV.

4.1.1.4 VNF-SW-Architecture-04
Le fournisseur doit clarifier la structure interne de chacun des VNFs définis - c'est-à-
dire si le VNF est monolithique (implémenté comme un seul composant VNF),
composite, composé de plus de VNFC. Le fournisseur doit clarifier les critères
appliqués pour la décomposition VNF et les justifications derrière, liés à l'efficacité
de la satisfaction des exigences fonctionnelles et non fonctionnelles.

4.1.1.5 VNF-SW-Architecture-05
Si l'architecture SW de la solution NFV proposée par le fournisseur est monolithique
ou basée sur un module, l'opérateur doit être en mesure de gérer du point de vue
fonctionnel et non fonctionnel (par exemple la capacité, etc.) chaque fonction de la
solution NFV si nécessaire.

4.1.1.6 VNF-SW-Architecture-06
Le fournisseur doit fournir une description détaillée de l'architecture SW de la
solution dNFV. Toutes les interfaces (Telco & IT) doivent être également
présentées.
• Solution NFV– description de la haute disponibilité (ex. cluster vs. non-cluster).
• Description de la solution VF (basé sur le module ou monolithique)
o Mapping entre VF et VM
o Nombre de VMs Minimum/maximum
o Mode de fonctionnement de VF, ex. mode active ou standby.
o Mécanisme de partage de charge.
Le fournisseur doit identifier le type de VNFC (stateless or stateful: avec ou sans
statut) pour tous les VNFCs constitués de chacun des VNF identifiés. Pour chaque
VNFC avec statut, le fournisseur doit clarifier la façon dont les informations de statut
sont conservées et mises à jour, et son impact sur les mécanismes de partage de
charge appliqués.

All rights reserved. No spreading without permission of ZTE. 5

 Modèle vIMS RFI&RFP

4.1.1.7 VNF-SW-Architecture-07
Le fournisseur doit fournir une description détaillée de l'architecture SW utilisée
dans la mise en œuvre du gestionnaire vEMS / VNF.

4.1.1.8 VNF-SW-Architecture-08
Le fournisseur doit clarifier en détail le mapping appliqué entre les fonctionnalités
vIMS et les fonctionnalités IMS ordinaires. Si certaines fonctionnalités ne peuvent
pas être prises en charge dans vIMS mais uniquement prises en charge dans IMS
ordinaire, veuillez spécifier les fonctionnalités non prises en charge et expliquer la
raison.

4.1.1.9 VNF-SW-Architecture-09
Le fournisseur doit prendre en charge les VNFs dans NFV et les IMS ordinaires
peuvent être gérés par un EMS convergent (ou vEMS).

4.1.1.10 VNF-SW-Architecture-10
Le fournisseur doit garantir que la solution NFV proposée est entièrement
compatible IPv4 et IPv6, du point de vue des clients finaux mobiles, ainsi que du
point de vue des communications réseau de la solution NFV (pour la signalisation et
le débit).

4.1.1.11 VNF-SW-Architecture-11
Le fournisseur doit garantir que le SBC virtuel proposé peut être mis à niveau et
migré vers la fonctionnalité TC (transcodage) intégrée. Le transcodage peut être
mis à l'échelle séparément sans affecter les autres fonctions..

4.1.1.12 VNF-SW-Architecture-12
Le fournisseur doit prendre en charge l'architecture de séparation du stockage avec
statut et du traitement des services sans statut. Par exemple, les informations
d'enregistrement et d'appel avec statut peuvent être stockées dans un module de
stockage dédié, qui sont séparés avec le traitement VNF du service. Sinon, le
fournisseur doit expliquer comment changer de machine virtuelle sans affecter le
service.

4.1.1.13 VNF-SW-Architecture-13
Le fournisseur doit confirmer que tous les ports physiques externes doivent prendre

6 All rights reserved. No spreading without permission of ZTE.

 Modèle vIMS RFI&RFP

en charge la méthode active-standby et le partage de charge, y compris les ports

de capacité SR-IOV.

5 INFORMATION DE DESCRIPTION ET MODÉLISATION DES

DONNÉES

5.1.1.1 DescrInformation-DataModeling-01
Pour chacun des VNFs définis, le fournisseur doit prendre en charge le descripteur
VNF correspondant (VNFD, alias modèle de déploiement).

5.1.1.2 DescrInformation-DataModeling-02
Les informations incluses dans le VNFD doivent permettre au VNFM / NFVO d'être
en mesure d'exécuter correctement toutes leurs fonctions liées à la gestion
automatique du cycle de vie de ce VNF - déploiement, instanciation, migration de
VM, mise à l'échelle, etc.

5.1.1.3 DescrInformation-DataModeling-03
Le vendeur doit garantir que les informations incluses dans un VNFD fournissent
les garanties fonctionnelles et non fonctionnelles du VNF correspondant (par
exemple, performances, sécurité, fiabilité, élasticité / instanciation / mise à
l'échelle / sortie, etc..).

5.1.1.4 DescrInformation-DataModeling-04
Le vendeur doit expliquer le rôle du VNFD dans les processus de gestion du VNF
(en particulier en cas d'interfonctionnement des VNF fournis par différents
fournisseurs, le VNFD étant spécifié en utilisant différentes techniques, langues,
etc.) - par ex. Intégration VNF, instanciation / mise à l'échelle automatisée.

All rights reserved. No spreading without permission of ZTE. 7

 Modèle vIMS RFI&RFP

6 ENVIRONNEMENT ARCHITECTURAL IMS

6.1.1.1 NFVI CIBLE

6.1.1.1.1 Cible-NFVI-01
Le fournisseur doit fournir et certifier que la solution vIMS proposée peut fonctionner
avec du matériel basé sur HP, DELL, ZTE.

6.1.1.1.2 Cible-NFVI-02
La solution NFV doit être conforme au matériel Intel x86 COTS (Commercial Off the
Shelf), prenant en charge le « blade » et le facteur de montage du rack.

6.1.1.1.3 Cible-NFVI-03
Pour Hypervisor, la solution proposée doit être conforme aux KVM, XEN, ESXi.

6.1.1.1.4 Cible-NFVI-04
La solution NFVO et VNFM proposée doit être conforme à la version OpenStack
Makata, VMware vCloud Suite 6.5.

6.1.1.1.5 Cible-NFVI-05
Le fournisseur doit fournir des informations et spécifier tout matériel supplémentaire
(par exemple, type de carte réseau spécifique NIC, équipement de réseau
spécifique, etc.) ou composant / mécanisme SW (par exemple DPDK, SR-IOV) qui
est utilisé pour atteindre les performances demandées en fonction du modèle de
trafic fourni.

6.1.1.1.6 Cible-NFVI-06
Le fournisseur doit expliquer la considération de sélection VIM et Hypervisor.

6.1.1.1.7 Cible-NFVI-07
Le fournisseur doit fournir des informations détaillées sur l'optimisation de
« OpenStack ».

8 All rights reserved. No spreading without permission of ZTE.

 Modèle vIMS RFI&RFP

6.1.1.2 NFVI DE FOURNISSEUR RECOMMANDEE

6.1.1.2.1 Fournisseur-NFVI-01
Le fournisseur doit fournir des informations sur les ressources NFVI - HW
préférées:
  - Computing HW (la spécification HW doit être sur un serveur x86)
  - HW Storage
  - Networking HW (y compris les éléments de réseau)

6.1.1.2.2 Fournisseur-NFVI-02
Le fournisseur doit fournir des informations sur son hypervisor de solution NFV
préféré (y compris la dernière version SW prise en charge).

6.1.1.2.3 Fournisseur-NFVI-03
Le vendeur sera responsable de l'installation, de la configuration et de la
maintenance du système d'exploitation invité.

6.1.1.2.4 Fournisseur-NFVI-04
Le fournisseur doit fournir des informations sur son système d'exploitation invité
préféré pour la solution NFV (y compris la dernière version logicielle prise en
charge).

6.1.1.2.5 Fournisseur-NFVI-05
Le fournisseur doit fournir des informations sur sa solution NFV préférée
« Virtualized Infrastructure Manager » (y compris la dernière version SW prise en
charge).

7 INTERFONCTIONNEMENT DES VNFs AVEC NFVI

7.1.1.1 VNF-Interw-NFVI-01
Le fournisseur doit décrire les techniques de virtualisation appliquées et les normes
sur lesquelles elles sont basées, pour l'interfonctionnement avec le NFVI.

7.1.1.2 VNF-Interw-NFVI-02
Dans le cas où des composants et des mécanismes HW / SW spécifiques sont

All rights reserved. No spreading without permission of ZTE. 9

 Modèle vIMS RFI&RFP

appliqués (par exemple, des NICs spécialisées, des cartes spécialisées pour : par
exemple le support DPI, DPDK, Direct IO, SR-IOV, etc.), le fournisseur doit décrire
clairement leur objectif, les raisons de leur utilisation. Introduction.

7.1.1.3 VNF-Interw-NFVI-03
Le fournisseur doit préciser si les machines virtuelles (VM) de différents types de
VNFC peuvent résider sur et partager un seul et même hôte matériel HW.
Si oui, le vendeur doit clarifier les contraintes et complications potentielles liées par
exemple à la répartition des capacités entre les machines virtuelles.
Sinon, le vendeur doit fournir les raisons

7.1.1.4 VNF-Interw-NFVI-04
Le fournisseur doit préciser si l'intercommunication entre les VM prenant en charge
les VNFC des VNF définis (le cas échéant) a besoin de capacités supplémentaires,
au-delà des capacités L2 / L3 existantes.
Dans le cas où ceux-ci sont utilisés, le fournisseur doit les spécifier et doit suivre les
normes.

7.1.1.5 VNF-Interw-NFVI-05
Le fournisseur doit clarifier l'impact de ces capacités supplémentaires nécessaires
pour la communication inter-VM sur la mise à l'échelle VNF / VNFC appliquée et les
mécanismes de redondance et de géo-redondance.

8 PROCESSUS INFLUENCÉS

8.1.1.1 SUPPORT & PREPARATION OPERATIONNELLE

8.1.1.1.1 Operational-Support-01
Le fournisseur doit fournir une procédure automatique qui exécute la mise à jour /
mise à niveau de l'instance VNF. Cette procédure devrait faire partie du VNF
Package.

8.1.1.1.2 Operational-Support-02
La procédure de mise à jour / mise à niveau doit contrôler la progression de la mise
à jour / mise à niveau de l'instance VNF, y compris la demande de ressources
virtuelles auprès de NFVM et NFVO.

10 All rights reserved. No spreading without permission of ZTE.

 Modèle vIMS RFI&RFP

8.1.1.1.3 Operational-Support-03
La mise à jour / mise à niveau doit prendre en charge la restauration de la mise à
jour / mise à niveau de l'instance VNF, y compris le retour des ressources virtuelles
obtenues auprès de NFVM et NFVO.

8.1.1.1.4 Operational-Support-04
Chacun des VNF définis doit prendre en charge des capacités pour effectuer des
opérations de migration de ses ressources.

8.1.1.1.5 Operational-Support-05
Le fournisseur doit clarifier le type de migration prise en charge par VNF: migration
en direct de VNF vers différentes ressources NFVI; arrêt et redémarrage sur un
autre matériel; autre; aucune migration prise en charge.

8.1.1.1.6 Operational-Support-06
Si un type de migration est pris en charge, le fournisseur doit expliquer le
mécanisme, les composants fonctionnels architecturaux impliqués et leur rôle, ainsi
que la relation entre la procédure de migration et le concept de redondance
appliqué.

8.1.1.1.7 Operational-Support-07
Le vendeur doit décrire en détail le rôle des vEMS et des autres éléments de
gestion de l'architecture NFV pour la prise en charge des mécanismes et
procédures de tests administratifs et automatiques mentionnés ci-dessus, le type
d'interface (s) établie (s), le ou les protocole (s) utilisés, et format des informations
recueillies, y compris référence aux normes appliquées.

8.1.1.1.8 GESTION DE PERFORMANCE DES RESSOURCES

8.1.1.1.9 Resource-Performance-Mgmt-01
Le fournisseur doit identifier les sources d'informations sur les performances des
ressources (en temps réel et historiques) liées à NFV (compteurs bruts) et les
formats d'informations pris en charge. En ce qui concerne l'influence sur
l'architecture NFV globale et la distribution fonctionnelle, le fournisseur doit indiquer
les mécanismes et procédures pris en charge pour le stockage local, la collecte, la
corrélation, l'agrégation et l'exportation de ces informations vers l'environnement
OSS / BSS de l'opérateur.

All rights reserved. No spreading without permission of ZTE. 11

 Modèle vIMS RFI&RFP

8.1.1.1.10 Resource-Performance-Mgmt-02
Le fournisseur doit décrire en détail comment les informations sur les performances
des ressources sont impliquées et utilisées par les mécanismes et procédures de
gestion du cycle de vie VNF (instanciation VNF; static/dynamic/automatic VNF
scale-in/scale-out & scaling up/down; Suppression ou migration VNF) - KPI définis,
surveillance, corrélation, automatisation, actions de gestion

8.1.1.1.11 Resource-Performance-Mgmt-03
Le fournisseur doit spécifier en détail le rôle de chacun des éléments de gestion de
l'architecture NFV (EMS, VIM, VNFM, NFVO ou fournisseur spécifique), les
interfaces correspondantes entre eux, et vers l'OSS / BSS de l'opérateur, et leur
interfonctionnement pour la prise en charge des mécanismes et procédures de
gestion de performance de ressource (Resource-Performance-Management)
mentionnés ci-dessus

8.1.1.1.12 MÉDIATION ET RAPPORTS DE RESSOURCES

8.1.1.1.13 Resource-Mediation-&-Reporting-01
Le fournisseur doit spécifier en détail le rôle de chacun des éléments de gestion de
l'architecture NFV (EMS, VIM, VNFM, NFVO, ou fournisseur spécifique), les
interfaces correspondantes entre eux, et vers l'OSS / BSS de l'opérateur, et leur
interfonctionnement pour le support des mécanismes et procédures de médiation et
de reporting des ressources mentionnés ci-dessus.

8.1.1.1.14 Resource-Mediation-&-Reporting-02
Le fournisseur doit clarifier les spécificités et l'influence du cycle de vie VNF
(instanciation VNF; static/dynamic/automatic VNF scale-in/scale-out & scaling
up/down; suppression / migration VNF) sur les mécanismes et procédures de
médiation et de reporting des ressources.

8.1.1.1.15 Resource-Mediation-&-Reporting-03
Le fournisseur doit fournir le nombre maximal de VM.

8.1.1.1.16 Resource-Mediation-&-Reporting-04
Le fournisseur doit fournir la performance de chaque VM.

12 All rights reserved. No spreading without permission of ZTE.

 Modèle vIMS RFI&RFP

9 VIRTUALISATION - EXIGENCES NON

FONCTIONNELLES

10 GENERALITES

10.1.1.1 Non-functional-General-01
Les offres proposées par les fournisseurs relatives aux solutions NFV-IMS doivent
fournir un support global cohérent et holistique des VNF définis tout au long de leur
cycle de vie, y compris leur création, déploiement, mise à l'échelle, opération,
contrôle, gestion, maintenance et suppression.

10.1.1.2 Non-functional-General-02
Le fournisseur doit confirmer la fonctionnalité/caractéristique de la version du
logiciel de la solution de plate-forme basé sur HW & COTS ordinaire. Le fournisseur
doit expliquer son approche du principe de parité fonctionnalité / caractéristique et
énumérer toutes les différences de fonctionnalité / fonctionnalité actuelles.

10.1.1.3 Non-functional-General-03
Le fournisseur doit garantir qu'aucun impact négatif sur les performances, le
fonctionnement et la gestion de l'environnement du réseau existant n'est causé par
l'introduction des VNFs définis.

11 ELASTICITY

11.1.1.1 Elasticity-01
Le fournisseur doit expliquer comment le « scaling in/out and up/down » est
réalisable sur la base des critères de définition VNFC et fournir des arguments pour
les performances et l'efficacité d'utilisation des ressources

11.1.1.2 Elasticity-02
Le fournisseur doit prendre en charge la mise à l'échelle automatique (auto-
scaling), la mise à l'échelle à la demande (on-demand scaling) et la mise à l'échelle
en fonction d'une demande de gestion pour les VNFC évolutifs constitués par

All rights reserved. No spreading without permission of ZTE. 13

 Modèle vIMS RFI&RFP

chacun des VNF de portée. Les règles de mise à l'échelle doivent être présentées
dans le VNFD correspondant.

11.1.1.3 Elasticity-03
Le fournisseur doit clarifier les sources des événements déclenchant la mise à
l'échelle automatique et les critères / seuils appliqués.

11.1.1.4 Elasticity-04
Le fournisseur doit expliquer si l'orchestration et la gestion NFV fournissent
l'ensemble complet des politiques de provisionnement et de gestion pour ce VNF
nécessaires pour les tâches opérationnelles automatisées (c'est-à-dire qu'il est
entièrement basé sur des politiques VNF), ou le VNF fournit la gestion des
politiques par lui-même (c'est-à-dire il s'agit de non-policy-based VNF).

11.1.1.5 Elasticity-05
Le fournisseur doit expliquer le déclenchement de mise à l'échelle pris en charge
sur la base d'une demande de gestion identifiant les sources possibles (par
exemple NFVO; Network Monitoring Center ou autre système OSS / BSS avec /
sans implication EMS; autre), les interfaces utilisées vers le VNFM et la procédure
appliquée.

11.1.1.6 Elasticity-06
Le fournisseur doit préciser quelle est l'unité de granularité minimale possible pour
le changement de capacité (augmentation / diminution) de chaque type de VNFC.

11.1.1.7 Elasticity-07
Le fournisseur doit fournir des informations sur les avantages quantitatifs d'une
augmentation de capacité avec l'unité de granularité minimale possible pour les
différents types de VNFC. Par exemple : Combien de débit en Mbit / s, sessions
simultanées, etc. sont atteints (pertinents pour le fournisseur recommandé ou les
options d'implémentation de l'environnement NFVI requises par l'opérateur).

11.1.1.8 Elasticity-08
Le vendeur doit expliquer comment les procédures de mise à l'échelle sont
protégées contre les fluctuations de la charge à court terme (ou de tout autre critère
KPI de seuil pertinent) autour de la valeur du seuil actuel afin d'éviter toute erreur
trompeuse et donc une mise à l'échelle VNF / VNFC non nécessaire.

14 All rights reserved. No spreading without permission of ZTE.

 Modèle vIMS RFI&RFP

11.1.1.9 Elasticity-09
Le vendeur doit garantir que toute procédure liée à la montée / sortie d'échelle
n'entraîne pas la détérioration, ou l'interruption du service réseau (par exemple, les
sessions de données actuelles). Sinon, le vendeur doit expliquer les cas pertinents
et les raisons.

12 DISPONIBILITÉ & RÉSILIENCE & GÉO-REDONDANCE

12.1.1.1 DISPONIBILITE (AVAILABILITY)

12.1.1.1.1 Availability-01
La solution vIMS doit prendre en charge une disponibilité de service de bout en
bout ≥ 99,999% sur une base annuelle, c'est-à-dire que le temps d'arrêt maximal de
la solution pour les temps d'arrêt planifiés et non planifiés doit être inférieur à cinq
(5) minutes et seize (16) secondes par an.
Pour éviter tout doute: cette exigence fait référence aux services de bout en bout
qui utilisent les fonctionnalités de la solution vIMS.
Pour éviter tout doute: si une disponibilité de 99,999% sur le service de bout en
bout ne peut être obtenue qu'en ayant une disponibilité plus élevée de la solution
vIMS, alors cela doit être pris en compte par le fournisseur."
Availability-04 " La solution NFV doit fournir des fonctionnalités permettant de
déplacer toutes les sessions d'abonnés ou une gamme de sessions avec le même
type de fonctionnalités:
1) d'une VM à une autre VM
2) d’un HW host à un autre HW

12.1.1.1.2 Availability-02
La solution NFV doit fournir une protection contre tous les points de défaillance
uniques (matériel et logiciel) pour tous les VNF, et doit tenter de revenir à un état
opérationnel lorsque plusieurs défaillances simultanées se produisent.

12.1.1.1.3 Availability-03
Le fournisseur doit prendre en charge la réparation automatique de tout VNFC / VM
inclut dans un VNF.

All rights reserved. No spreading without permission of ZTE. 15

 Modèle vIMS RFI&RFP

12.1.1.1.4 Availability-04
Le fournisseur doit expliquer si au cours de l'exécution des procédures de guérison,
des ressources supplémentaires sont nécessaires (par exemple, des VMs
supplémentaires).

12.1.1.1.5 Availability-05
Pour les procédures de rétablissement prises en charge, le fournisseur doit clarifier
tous les composants fonctionnels architecturaux impliqués (par exemple VNF,
VNFM, VNF EMS, autres) et leur rôle. Le vendeur doit expliquer la ou les
procédures appliquées faisant référence à la pile de protocoles utilisée et aux
normes pertinentes (dans le cas où un mécanisme propriétaire n'est pas appliqué).

12.1.1.1.6 Availability-06
Pour la ou les procédures de rétablissement prises en charge, le vendeur doit
clarifier les processus de surveillance appliqués et spécifier les critères de décision
pour la détermination du statut VNF.

12.1.1.1.7 Availability-07
Outre le mécanisme de redondance "active-standby", pour obtenir une utilisation et
une fiabilité des ressources plus élevées, le mécanisme de partage de charge "N +
K" doit également être pris en charge dans le déploiement des VNFC qui sont
responsables du traitement de la logique de service.

12.1.1.2 RESILIENCE (RESILIENCY)

12.1.1.2.1 Resiliency-01
The vendor shall clarify the supported redundancy concepts (e.g. Active/Standby;
Active/Active - i.e. load sharing; cluster; other) on each of the virtualized
environment layers - Physical layer, hypervisor/OS layer, Virtualization resources
layer (e.g.VM), and related to them VIM; Functional VNF/VNFC layer, Management
layer - EMS, and related to them VNFM; NFVO layer.
Le fournisseur doit clarifier les concepts de redondance pris en charge (par
exemple, Active/Standby; Active/Active - c'est-à-dire partage de charge; cluster;
autre) sur chacune des couches d'environnement virtualisé - couche physique,
couche hypervisor / système d'exploitation, couche de ressources de virtualisation
(par exemple VM), et lié à eux VIM; Couche fonctionnelle VNF / VNFC, couche de
gestion - EMS, et VNFM connexe; Couche NFVO.

16 All rights reserved. No spreading without permission of ZTE.

 Modèle vIMS RFI&RFP

12.1.1.2.2 Resiliency-02
Le fournisseur doit garantir que l'exécution du ou des mécanismes de résilience
n'entraîne aucune interruption du service réseau.

12.1.1.2.3 Resiliency-03
Le fournisseur doit expliquer les concepts de redondance appliqués au vEMS
(considéré également comme un composant SW distinct), le cas échéant.

12.1.1.2.4 Resiliency-04
En cas de défaillance de vEMS, le fournisseur doit identifier l'impact sur
l'environnement OSS / BSS hérité externe et les VNF correspondants pour prendre
correctement en charge leurs exigences non fonctionnelles (alarme, chargement et
collecte d'informations sur les performances, etc..)

12.1.1.2.5 Resiliency-05
Le fournisseur doit expliquer les concepts de redondance appliqués au composant
fonctionnel de gestion VNF « VNFM » (considéré également comme un composant
SW distinct), le cas échéant..

12.1.1.2.6 Resiliency-06
En cas de panne de VNFM, le vendeur doit identifier l'impact sur
l'interfonctionnement correct avec le NFVO & VIM.

12.1.1.2.7 Resiliency-07
La solution proposée doit prendre en charge la réplication de session de niveau
télécom et la résilience de session qui doivent être fournies par la solution NFV,
mais pas l'hyperviseur.
• Une description du mécanisme de réplication de session doit être fournie.
• Une description du mécanisme de résilience de session doit être fournie.

12.1.1.2.8 Resiliency-08
Le système doit prendre en charge la récupération de session pour fournir un
basculement et une reconstruction en toute transparence des informations de
session d'abonné en cas de défaillance matérielle ou logicielle du système,
empêchant ainsi la déconnexion de sessions utilisateur connectées.

All rights reserved. No spreading without permission of ZTE. 17

 Modèle vIMS RFI&RFP

12.1.1.2.9 Resiliency-09
Le système doit fournir une redondance matérielle. En cas de défaillance de l'unité
matérielle, tous les appels concernés doivent être migrés vers l'unité matérielle
redondante, sans perte de session.

12.1.1.2.10 Resiliency-10
Le fournisseur doit fournir des informations sur les mécanismes de redondance des
cartes d'interface réseau.

12.1.1.2.11 Resiliency-11
La solution NFV proposée doit fournir un mécanisme fonctionnant au niveau de
l'application qui garantit le fonctionnement normal de la solution NFV. Applications
en cas de défaillances différentes du système (par exemple défaillance d'interface,
défaillance d'élément, etc.).

12.1.1.2.12 Resiliency-12
La solution NFV proposée doit fournir un mécanisme qui garantit le fonctionnement
normal du système de solution NFV en cas de défaillance d'un composant NFV (par
exemple, défaillance d'interface, défaillance d'élément, etc.).

13 SECURITE

13.1.1.1 Security-01
La solution NFV proposée doit être en mesure de résoudre les problèmes de
sécurité potentiels causés par l'introduction de la couche de virtualisation. En
réponse à l'exigence, le fournisseur doit fournir une description des mécanismes de
sécurité mis en œuvre.

13.1.1.2 Security-02
La solution NFV proposée doit pouvoir assurer la protection des données, stockées
ou transmises. En réponse à l'exigence, le fournisseur doit fournir une description
des mécanismes de protection des données mis en œuvre.

13.1.1.3 Security-03
La solution NFV proposée doit être en mesure d'assurer la protection de toutes les

18 All rights reserved. No spreading without permission of ZTE.

 Modèle vIMS RFI&RFP

interfaces réseau liées à NFV, par exemple interface avec le NFVI, interface avec le
système de gestion, etc. En réponse à l'exigence, le vendeur doit fournir une
description des mécanismes de protection des interfaces NFV.

14 COEXISTENCE AVEC DES RÉSEAUX EXISTANTS – TRANSITION

14.1.1.1 Transition-01
La transition de l'ancien IMS vers la solution NFV proposée ne doit pas avoir
d'impact négatif sur la capacité de service des clients finaux, la disponibilité du
service et le contrat SLA convenu. En réponse à l'exigence, le fournisseur doit
fournir une procédure décrivant les principales étapes de transition de l'ancien IMS
à la solution NFV.

14.1.1.2 Transition-02
L'intégration de la solution NFV proposée avec les systèmes de gestion existants
doit être facilement réalisée, c'est-à-dire sans impact sur les nœuds et interfaces
existants. Le fournisseur de la solution NFV sera en charge de toute solution NFV -
intégration des systèmes de gestion, si nécessaire.

All rights reserved. No spreading without permission of ZTE. 19

 Modèle vIMS RFI&RFP

2 Exigences générales du IP Multimedia

subsystem pour le réseau de l’opérateur
XXX

2.1.1 Généralité

2.1.1.1 Le fournisseur doit fournir les services d'appel vidéo VoLTE et GSMA IR94
conformes à GSM-A IR92.

2.1.1.2 Les Fournisseurs proposeront une solution globale sur la base des exigences
IMS et des caractéristiques techniques de ses propres équipements et
systèmes.

2.1.1.3 Les fournisseurs doivent fournir une architecture détaillée et une description de
chaque élément proposé de la solution IMS, y compris, mais sans s'y limiter, sa
capacité, le protocole pris en charge, l'interface, etc. En outre, le fournisseur
doit décrire l'interfonctionnement avec les réseaux existants, tels que PSTN,
PLMN, IN, etc.

2.1.1.4 Les fournisseurs doivent fournir des informations IMS IOT avec les équipements
pertinents d'autres fournisseurs.

2.1.1.5 Le fournisseur doit fournir une déclaration pour le déploiement commercial IMS,
y compris le numéro d'abonné, les services fournis et le délai de livraison.

2.1.1.6 Le fournisseur doit fournir l'OSS unifié pour les composants IMS.

20 All rights reserved. No spreading without permission of ZTE.

 Modèle vIMS RFI&RFP

2.1.2 Besoins de l’O&M du réseau

2.1.2.1 Pour le système IMS, le fournisseur doit fournir des fonctions O&M pratiques.

2.1.2.2 Le fournisseur doit fournir l'interface d'exploitation avec la commande MML

(Human-Machine Language) et l'interface utilisateur graphique (GUI), divers
modes de gestion tels que la gestion unifiée du réseau, la maintenance locale
et la télémaintenance. L'interface est conviviale, facile à utiliser et à entretenir,
sécurisée et contrôlable.

2.1.2.3 Le système O & M / EMS proposé doit prendre en charge la correction en ligne.
La mise à niveau et la maintenance du logiciel peuvent être effectuées sans
affecter le système.

2.1.2.4 Le système O & M / EMS proposé doit fournir les fonctions d'enregistrement,
d'alarme, de mesure du rendement et de diagnostic des défauts. Il aide le
personnel de maintenance à prévenir, localiser et gérer les pannes du système.

2.1.2.5 Le système O & M / EMS proposé doit fournir une mesure de performance
avancée et un document utile pour la maintenance et l'optimisation du réseau.

2.1.2.6 Le système O & M / EMS proposé doit fournir une tâche de traçage de
signalisation améliorée qui facilite la gestion des défauts et le traçage de
signalisation.

2.1.2.7 Le système O & M / EMS proposé doit fournir un système d’aide en ligne
intégrée et un centre de documentation pour les utilisateurs.

2.1.3 Conformité au Standard

2.1.3.1 L’architecture IMS du fournisseur doit être conforme à 3GPP R10 ou version
supérieure.

All rights reserved. No spreading without permission of ZTE. 21

 Modèle vIMS RFI&RFP

2.1.3.2 Le fournisseur doit fournir la liste détaillée de conformité du protocole.

2.1.3.3 Les soumissionnaires doivent détailler les protocoles et interfaces utilisés entre
les différents éléments du réseau.

2.1.3.4 Le système IMS doit prendre en charge IPv4 dans tous les éléments du réseau.

2.1.3.5 Le système IMS doit prendre en charge IPv6 dans tous les éléments du réseau.

2.1.3.6 Le soumissionnaire doit fournir des détails sur toutes les interfaces propriétaires
qui sont utilisées dans la solution et un chemin d'évolution clair avec un intrvalle
temps vers celui standard tel que décrit dans les spécifications 3GPP. Cela
inclut toutes les interfaces qui ne sont pas conformes aux normes 3GPP ou
TISPAN pertinentes. Toutes les interfaces qui ne sont pas clairement décrites
comme propriétaires sont considérées comme conformes aux normes.

2.1.3.7 La solution IMS doit prendre en charge tous les en-têtes et méthodes SIP / SDP
facultatifs et obligatoires décrits dans 3GPP TS 24.229; 24.141; 24.841; 29.847;
24.247; 24.147.

2.1.3.8 Au moins les méthodes suivantes doivent être prises en charge: BYE; ACK;
INVITE; MESSAGE; NOTIFY; OPTION; REGISTER; REFER; SUBSCRIBE,
PUBLISH, CANCEL, INFO, UPDATE comme décrite dans : 3GPP TS 24.229;
24.141; 24.841; 24.847; 24.247; 24.147.

2.1.3.9 Au moins les en-têtes SDP suivants doivent être pris en charge au niveau de la
session:

 a= (zéro ou plusieurs lignes d'attribut)

 c =( informations sur la connexion).

 i= (informations sur la session)

22 All rights reserved. No spreading without permission of ZTE.

 Modèle vIMS RFI&RFP

 b= (Information sur la largeur de bande)

 s= (nom de la session)

 v= (version de protocole)

 o= (origine et ID de la session)

2.1.3.10 Au moins les en-têtes (headers) SIP suivants doivent être pris en charge :

 Accept-Language

 Contact

 Call-ID

 Cseq

 Content-Length

 Content-Type

 Event

 From

 Max-Forwards

 Authorization

 WWW-Authenticate

 P-Asserted-Identity

 P-Called-Party-ID

 P-Preferred-Identity

 Record-Route

 Route

All rights reserved. No spreading without permission of ZTE. 23

 Modèle vIMS RFI&RFP

 Timestamp

 Supported

 To

 Via

 Security-Client

 Security-Verify

 Security-Server

 Path

 Service-Route

 P-Charging-Vector header

 P-Charging-Function-Addresses header

2.1.3.11 L'en-tête du vecteur de P-charging doit contenir au moins les informations

suivantes:

 ICID

 Identité Inter Operator

 Utilisateur IMSI

 Utilisateur MSISDN

24 All rights reserved. No spreading without permission of ZTE.

 Modèle vIMS RFI&RFP

2.1.3.12 SIP sur SCTP doit être pris en charge conformément à la RFC 4168 pour SIP
sur SCTP dans P / I / S-CSCF, HSS et SIP-ALG. La gestion demandée doit être
disponible sur les interfaces réseau de l'interface interne IMS (c'est-à-dire que
SIP sur SCTP n'est pas requis sur l'interface Gm).

2.1.3.13 Il devrait être possible de transporter plusieurs types de contenu avec différents
types MIME dans les messages SIP.

2.1.3.14 Le système IMS doit prendre en charge une interface ISC telle que définie par
3GPP en 23.228 et 24.229.

2.1.3.15 Le système IMS doit prendre en charge l'interface Sh comme décrit dans 3GPP
TS 29.329 et 3GPP TS 29.328.

2.1.3.16 La solution IMS doit être conforme au protocole Dh et aux procédures décrites
dans 3GPP TS 29.329 et 3GPP TS 29.328 et dans la section de l’interface Sh.

2.1.3.17 La solution IMS doit prendre en charge une interface Cx standard comme décrit
dans 29.229 29.228.

2.1.3.18 La solution IMS doit être conforme au protocole Dx et aux procédures décrites
dans 3GPP TS 29.229; 29.228 et dans la section Cx.

2.1.3.19 La solution IMS doit prendre en charge une interface Gm entre le terminal et le
P-CSCF. L'interface doit être entièrement conforme à SIP comme décrit dans
3GPP TS 24.229.

2.1.3.20 La solution IMS doit prendre en charge une interface Mw entre les CSCF.
(Toutes les combinaisons possibles P-CSCF, I-CSCF, S-CSCF). L'interface doit
être entièrement conforme à SIP comme décrit dans 3GPP TS 24.229.

All rights reserved. No spreading without permission of ZTE. 25

 Modèle vIMS RFI&RFP

2.1.3.21 La solution IMS doit prendre en charge l'interface Mg entre MGCF et S-CSCF.
Le protocole utilisé pour le point de référence Mg est SIP tel que défini dans
3GPP TS 24.229.

2.1.3.22 La solution IMS doit fournir une interface Rx entre la fonctionnalité PCRF et P-
CSCF conformément à TS 29.211.

26 All rights reserved. No spreading without permission of ZTE.

 Modèle vIMS RFI&RFP

2.2 Exigences détaillées relatives à IMS Core

2.2.1 A-SBC

2.2.1.1 A-SBC doit pouvoir s'intégrer avec P-CSCF, ATCF et ATGW

2.2.1.2 A-SBC doit supporter Ipv4/Ipv6 dual stack.

2.2.1.3 A-SBC doit supporter SIP sur UDP, TCP , TLS et IPsec.

2.2.1.4 A-SBC peut supporter B2BUA mode et proxy mode.

2.2.1.5 A-SBC doit prendre en charge les fonctions de filtrage de signalisation SIP pour
empêcher les abonnés de recevoir des messages SIP illégaux.

2.2.1.6 A-SBC doit prendre en charge la manipulation SIP pour l'édition des en-têtes
SIP / corps SDP.

2.2.1.7 A-SBC doit prendre en charge pour connecter PCRF via DRA ou directement.
Si vous connectez directement le PCRF, l'A-SBC doit prendre en charge un
itinéraire flexible vers le PCRF.

2.2.1.8 A-SBC doit être en mesure de prendre en charge l'interface Rf pour la

facturation hors ligne, conformément aux ETSI 282 010, 3GPP TS 32.240,
32.260, 32.295, 32.296, 32.297, 32.298 and 32.299.

2.2.1.9 A-SBC doit pouvoir prendre en charge le mécanisme de temporisation de

session défini dans RFC 4028. Et dans le cas où l'UE ne prend pas en charge
le minuteur de session, le support SBC utilise le message Sip (par exemple,
mettre à jour ou réinviter) pour effectuer l'appel long UPDATE.

All rights reserved. No spreading without permission of ZTE. 27

 Modèle vIMS RFI&RFP

2.2.1.10 A-SBC doit être en mesure d'identifier et de gérer les appels d'urgence tels que
définis dans le 3GPP TS 24.229, et être capable de hiérarchiser les appels
d'urgence en priorité afin de garantir que les appels d'urgence sont servis
même en cas de congestion.

2.2.1.11 A-SBC doit authentifier l'utilisateur et établir une association de sécurité IP-sec
avec le terminal IMS. Le SBC doit être en mesure d'empêcher les attaques
d'usurpation d'identité et les attaques par rejeu et doit protéger la vie privée de
l'utilisateur.

2.2.1.12 Le soumissionnaire doit fournir une description du mécanisme de sécurité SBC,

et comment défendre DDOS.

2.2.1.13 Les mécanismes de politique de transcodage proactif sont pris en charge

conformément aux procédures TS 24.229.

2.2.1.14 A-SBC fournit l'interception de IRI et CC à l'aide des interfaces X1, X2, X3.

2.2.1.15 A-SBC doit supporter eSRVCC/aSRVCC/bSRVCC/rSRVCC et interagir avec le

réseau LTE selon 3GPP TS 23.216 Rel-12

2.2.1.16 A-SBC doit attribuer un STN-SR, prendre en charge la signalisation SIP et

effectuer l'ancrage des supports dans l'ATGW pour les sessions de terminaison
et d'origine.

2.2.1.17 A-SBC doit garder une trace des sessions en état d'alerte, actif ou maintenu
pour pouvoir effectuer le transfert d'accès de la session sélectionnée.

2.2.1.18 A-SBC doit effectuer le transfert d'accès et mettre à jour ATGW avec le nouveau
chemin pour le tronçon d'accès CS sans nécessiter la mise à jour du tronçon
distant.

28 All rights reserved. No spreading without permission of ZTE.

 Modèle vIMS RFI&RFP

2.2.1.19 A-SBC effectuera l'ancrage des supports dans les sessions d'origine et de fin
conformément aux instructions fournies par le ATCF.

2.2.1.20 A-SBC prendra en charge le transcodage après le transfert eSRVCC dans le

cas où le support utilisé avant le transfert n'est pas pris en charge par le serveur
MSC.

2.2.1.21 A-SBC doit interagir avec PCRF via l'interface Rx et avec PCRF via l'interface
Rx et prendre en charge le contrôle des politiques de QoS.

2.2.1.22 A-SBC doit interagir avec le système de charge hors ligne via l'interface Rf
(diamètre).

2.2.1.23 A-SBC doit interagir avec PDN Gateway via Sgi interface.

2.2.1.24 A-SBC doit interagir avec I-CSCF et S-CSCF via Mw interface.

2.2.1.25 A-SBC doit interagir avec user terminal via Gm interface.

2.2.1.26 A-SBC doit interagir avec MSC via interface I2 selon 3GPP 23.237 Rel-12.

2.2.1.27 A-SBC doit interagir avec via Mx interface.

2.2.1.28 A-SBC doit supporter media relay pour les appels voix/video et FAX T.38 et
DTMF (RFC 2833).

2.2.1.29 A-SBC doit supporter media relay pour IM, file transfer, et le partage
image/video sharing base sur MSRP.

2.2.1.30 A-SBC doit supporter la fonction Optimal Media Routing.

All rights reserved. No spreading without permission of ZTE. 29

 Modèle vIMS RFI&RFP

2.2.1.31 A-SBC doit prendre en charge la fonction de détection d'inactivité des médias et
le minuteur de détection doit être configurable.

2.2.1.32 A-SBC doit prendre en charge le transcodage des médias. Les codecs suivants
doivent être pris en charge: AMR, AMR-WB, G.711, G.729, G.723, G.722,
G.728, G.722, G.722.1, G.726,GSM,Ilbc,SILK.

2.2.1.33 A-SBC doit prendre en charge les rapports QoS des médias dans les CDR. Les
rapports QoS doivent inclure les informations suivantes:Taux de perte de
paquets, délai Round-trip, Jitter, nombre de paquets RTP reçus / envoyés,
nombre d'octets dans les paquets RTP reçus / envoyés.

2.2.1.34 A-SBC doit prendre en charge la restauration P-CSCF basée sur HSS et la
restauration P-CSCF basée sur PCRF, qui est conforme à 23.380.

2.2.1.35 SBC devrait prendre en charge la fonction de détection de média

unidirectionnelle. Lorsque SBC n'y trouve aucun flux de média dans une
direction alors que le profil du SDP est "sendrecev", SBC doit libérer l'appel
directement. Pour un flux multimédia unidirectionnel normal tel que l'annonce, le
fax, la mise en attente d'appels dont le profil SDP est envoyé ou reçu
uniquement, SBC doit traiter le trafic comme d'habitude.

2.2.1.36 SBC devrait prendre en charge le mécanisme NAT keep-alive. Ce mécanisme

permet à ces clients de demander d'inverser la direction dans laquelle les
requêtes keep-alive sont envoyées (c'est-à-dire qu'elles seront envoyées du
réseau au client) en incluant un paramètre "rkeep" dans la Via en-tête de la
requête SIP utilisée de la même manière que le paramètre "rkeep". SBC peut
décider de procéder ou non au test Ping / Pong (RFC 5626) pour le client en
fonction du paramètre "rkeep".

30 All rights reserved. No spreading without permission of ZTE.

 Modèle vIMS RFI&RFP

2.2.2 I-SBC

2.2.2.1 I-SBC doit être capable d’intégrer avec IBCF et TrGW

2.2.2.2 I-SBC doit supporter Ipv4/Ipv6 dual stack.

2.2.2.3 I-SBC doit supporter SIP over UDP, TCP , TLS.

2.2.2.4 I-SBC peut supporter B2BUA et proxy mode.

2.2.2.5 I-SBC doit supporter IP address/port translation (NAT/PT) pour Signalling plane
et media planes..

2.2.2.6 I-SBC doit supporter SIP manipulation pour la modification de SIP header/SDP
bodies.

2.2.2.7 I-SBC doit supporter flexible routing policy basé sur numéro appelant / appelé,
CIC, RN , TGRP/Trunk-Context etc.

2.2.2.8 I-SBC doit supporter ENUM routing et DNS-SRV/NAPTR/A routing.

2.2.2.9 I-SBC doit supporter rerouting lors de la transmission des échecs, ce qui signifie
que le SBC doit être en mesure d'acheminer les messages en fonction des
réponses d'erreur reçues.

2.2.2.10 I-SBC doit interagir avec le système de charge hors ligne via l'interface Rf
(diamètre).

2.2.2.11 I-SBC doit supporter media relay pour les appels voix/vidéo et FAX T.38 et
DTMF (RFC 2833).

All rights reserved. No spreading without permission of ZTE. 31

 Modèle vIMS RFI&RFP

2.2.2.12 I-SBC doit prendre en charge le relais multimédia pour la messagerie

instantanée, le transfert de fichiers et le partage d'images / vidéos en fonction
de MSRP.

2.2.2.13 I-SBC doit prendre en charge la fonction Optimal Media Routing.

2.2.2.14 I-SBC doit prendre en charge la fonction de détection d'inactivité des médias et
le minuteur de détection doit être configuré.

2.2.2.15 I-SBC doit prendre en charge les rapports QoS des médias dans les CDR. Les
rapports QoS doivent inclure les informations suivantes:Taux de perte de
paquets, délai Round-trip, Jitter, éléments de QoS, MOS, nombre de paquets
RTP reçus / envoyés, nombre d'octets dans les paquets RTP reçus / envoyés

2.2.2.16 SBC doit prendre en charge le transcodage des médias. Les codecs suivants
doivent être pris en charge: AMR, AMR-WB, G.711, G.729, G.723, G.722,
G.728, G.722, G.722.1, G.726,GSM,Ilbc,SILK. La capacité de TC peut
s'étendre séparément.

2.2.2.17 I-SBC doit interagir avec BGCF/CSCF via Mx/Mm interface.

2.2.2.18 I-SBC doit interagir avec IBCF via Ici interface.

2.2.2.19 I-SBC doit interagir avec TrGW via lzi interface.

2.2.2.20 I-SBC doit supporter le réseau IPPBX avec IMS. Dans ce scénario
d'interfonctionnement, IMS peut fournir un service ou n'a pas besoin.

2.2.3 I-CSCF

32 All rights reserved. No spreading without permission of ZTE.

 Modèle vIMS RFI&RFP

2.2.3.1 I-CSCF doit être capable de transmettre une demande d’enregistrement

entrante au S-CSCF approprié sur la base des informations reçues du HSS et /
ou des données de configuration locales.

2.2.3.2 I-CSCF doit recevoir la signalisation entrante d'un réseau étranger qui pourrait
être national ou international.

2.2.3.3 I-CSCF doit être capable de transmettre une demande d'enregistrement

entrante à la S-CSCF appropriée sur la base des informations reçues du HSS
et / ou des données de configuration locales.

2.2.3.4 I-CSCF doit prendre en charge l'interconnexion avec SLF pour sélectionner le
HSS approprié.

2.2.3.5 I-CSCF doit prendre en charge les fonctionnalités THIG (Topology Hiding Inter-
working Gateway).

2.2.3.6 I-CSCF doit prendre en charge l'exécution des fonctions de base de gestion de
session et de gestion de la facturation

2.2.3.7 I-CSCF doit aider à localiser le S-CSCF qui sert la partie appelée.

2.2.3.8 I-CSCF doit être en mesure de prendre en charge l'interface Rf pour la charge
hors ligne.

2.2.3.9 I-CSCF doit supporter PSI (Public Service Identity) routing.

2.2.3.10 I-CSCF doit pouvoir se déployer physiquement en un seul nœud physique avec
S-CSCF et également évoluer d'un nœud physique unique à des nœuds I-
CSCF et S-CSCF séparés.

All rights reserved. No spreading without permission of ZTE. 33

 Modèle vIMS RFI&RFP

2.2.3.11 I-CSCF peut sélectionner un autre S-CSCF lorsque le S-CSCF desservi est en
panne.

2.2.4 S-CSCF

2.2.4.1 S-CSCF doit prendre en charge les fonctionnalités d'enregistrement, de

réenregistrement et de désenregistrement initiées par le réseau décrites dans le
3GPP 23.228 et 24.229.

2.2.4.2 S-CSCF offrira la possibilité d'enregistrer implicitement au moins cinq

identifiants publics tels que décrits par le 3GPP 3GPP TS 23.228 et 24.229.

2.2.4.3 S-CSCF doit prendre en charge l'enregistrement tiers en parallèle à plusieurs

serveurs d'applications.

2.2.4.4 Il doit être possible de configurer la valeur de la durée de l'enregistrement que le

S-CSCF accordera aux utilisateurs IMS en définissant la valeur de l'en-tête
Expires. Il doit être possible de configurer des valeurs différentes en fonction du
type d'accès utilisé par l'UE indiqué dans l'en-tête P-Access-Network-Info.

2.2.4.5 S-CSCF doit prendre en charge le contrôle de la charge de trafic.

2.2.4.6 S-CSCF est responsable de la coordination des procédures d'authentification

IMS entre l'UE et le HSS. La S-CSCF doit prendre en charge l'authentification
IMS précoce

2.2.4.7 S-CSCF est responsable de la coordination des procédures d'authentification

IMS entre l'UE et le HSS. Le S-CSCF doit prendre en charge l'authentification
SIP Digest.

34 All rights reserved. No spreading without permission of ZTE.

 Modèle vIMS RFI&RFP

2.2.4.8 S-CSCF est responsable de la coordination des procédures d'authentification

IMS entre l'UE et le HSS. Le S-CSCF doit prendre en charge l'authentification
groupée NASS.

2.2.4.9 S-CSCF est responsable de la coordination des procédures d'authentification

IMS entre l'UE et le HSS. Le S-CSCF doit prendre en charge l'authentification
IMS AKA.

2.2.4.10 S-CSCF doit prendre en charge le déclenchement pour les identités des
utilisateurs publics, les identités de service public distinctes et les identités de
service public génériques. Le fournisseur doit décrire le mécanisme de
déclenchement de toutes ces identités.

2.2.4.11 S-CSCF doit prendre en charge les critères de filtrage initiaux (iFC : initial filter
criteria) pour gérer le déclenchement d'un serveur d'applications externe.

2.2.4.12 S-CSCF doit supporter Initial Filter Criteria (iFC) partagé en utilisant le modèle
iFC pour réduire l'iFC téléchargé sur l'interface Cx et pour améliorer la capacité
de modifier l'iFC de l'utilisateur du groupe.

2.2.4.13 S-CSCF doit être en mesure de faire la distinction entre son rôle S-CSCF
d'origine et de destination.

2.2.4.14 S-CSCF doit être en mesure de vérifier si les types de médias et le codec reçus
dans une offre / réponse SDP sont conformes à la politique de l'opérateur et
éventuellement au profil multimédia de l'utilisateur.

2.2.4.15 En cas de coupure de la connexion avec CCF, le S-CSCF stocke les

informations comptables et les envoie à CCF lorsque la connexion est rétablie.
Si la mémoire est pleine, le S-CSCF peut rejeter un nouvel appel.

2.2.4.16 S-CSCF dit supporter Cx interface à HSS.

All rights reserved. No spreading without permission of ZTE. 35

 Modèle vIMS RFI&RFP

2.2.4.17 S-CSCF doit supporter Dx interface à SLF.

2.2.4.18 S-CSCF doit supporter 3GPP procédure de restauration définie.

2.2.4.19 S-CSCF doit supporter NP (Number Portability).

2.2.4.20 S-CSCF doit supporter Rf interface pour la recharge hors ligne, se conformer
aux exigences spécifiées dans ETSI 282 010, 3GPP TS 32.240, 32.260,
32.295, 32.296, 32.297, 32.298 and 32.299.

2.2.4.21 S-CSCF doit être en mesure de prendre en charge le mécanisme de

temporisateur de session défini dans la RFC 4028. Et dans le cas où l'UE ne
prend pas en charge le temporisateur de session, la prise en charge S-CSCF
utilise le message Sip (par exemple, Option) pour effectuer l'appel long
UPDATE

2.2.4.22 S-CSCF doit prendre en charge le forking SIP conformément à la RFC 3261.
Les abonnés IMS doivent pouvoir enregistrer la même adresse publique à partir
d'adresses de contact différentes (par exemple à partir de plusieurs appareils
différents) et en fonction des préférences de service de l'utilisateur, une
demande pour cette adresse publique peut être bifurquée à chaque appareil en
parallèle ou en série.

2.2.4.23 E-CSCF doit prendre en charge la capacité du mécanisme de routage des

appels d'urgence lorsque l'accès des abonnés via VoLTE et VoWiFi. (En
particulier, E-CSCF est capable de traiter l'appel d'urgence lorsque le terminal
VoWiFi prend l'emplacement géographique, c'est-à-dire la longitude et la
latitude dans l'appel d'urgence sans l’information CELL correcte.

36 All rights reserved. No spreading without permission of ZTE.

 Modèle vIMS RFI&RFP

2.2.4.24 S-CSCF doit être conforme aux normes 3GPP et prendre en charge deux types
de restauration de P-CSCF, avec un mode de restauration P-CSCF basé sur
HSS, l'autre est une restauration de P-CSCF basé sur PCRF. Réaliser que les
abonnés restent en service en initialisant la réinscription des abonnés en cas
d'échec de P-CSCF est l'objectif final de chaque solution.

2.2.5 HSS/SLF

2.2.5.1 HSS doit prendre en charge l'interface Cx et Sh 3GPP TS 29.228, TS 29.229,

3GPP TS 29.328, 3GPP TS 29.329.

2.2.5.2 SLF doit prendre en charge Dx et Dh interface comme par 3GPP TS 23.228, TS
29.229. Le protocole de transport SCTP doit être pris en charge pour les
interfaces Dx et Dh.

2.2.5.3 HSS doit être en mesure de procéder à la radiation administrative comme décrit
par 3GPP 29.228.

2.2.5.4 HSS doit permettre au serveur d'applications de mettre à jour les données
transparentes stockées dans le HSS pour une identité d'utilisateur public ou une
identité de service public.

2.2.5.5 HSS doit permettre l'attribution du serveur S-CSCF et la désignation des

capacités pour les abonnés IMS, et les informations d'abonnement peuvent être
téléchargées vers S-CSCF, et le HSS doit maintenir la cohérence des données.

2.2.5.6 HSS doit supporter (CAVE) AKA / HTTP Digest authentication pour les
utilisateurs IMS.

All rights reserved. No spreading without permission of ZTE. 37

 Modèle vIMS RFI&RFP

2.2.5.7 HSS doit prendre en charge la procédure de désinscription initiée par le réseau.
En cas de désenregistrement initié par le réseau par le HSS, administratif, le
HSS change l'état des identités publiques en non enregistré et envoie une
notification RTR au S-CSCF indiquant les identités qui doivent être
désenregistrées.

2.2.5.8 HSS doit prendre en charge le stockage des informations d'authentification de

l'abonné IMS comme décrit par 3GPP TS 23.008, 33.102, 33.105, 43.020.

2.2.5.9 HSS doit prendre en charge le stockage des informations d'abonnement de

l'abonné IMS comme décrit par 3GPP TS 23.008.

2.2.5.10 HSS doit supporter « User Location Query ».

2.2.5.11 HSS doit supporter “Diameter Base Protocol”.

2.2.5.12 HSS agit comme le seul élément NE pour la gestion centralisée des données
d'abonnement dans le réseau. L'une de ses fonctions de base est l'abonnement
aux services des utilisateurs. La fonction d'administration des données
d'abonné local fournit des opérations d'ajout, de suppression, de modification et
de requête.

2.2.5.13 HSS doit prendre en charge la fonction d'administration des données d'abonné
local / distant.

2.2.5.14 HSS doit fournir une interface avec BOSS pour la gestion des services à
distance. Cette interface fournit un groupe d'instructions de caractères de ligne
de commande ou une interface SOAP / XML pour les opérateurs dans la
gestion des informations d'abonnement des abonnés.

2.2.5.15 HSS devrait fournir à l'opérateur la gestion des classes.

38 All rights reserved. No spreading without permission of ZTE.

 Modèle vIMS RFI&RFP

2.2.5.16 Les composants matériels clés du HSS fonctionnent en mode de sauvegarde à

chaud de redondance 1 + 1 en évitant la défaillance d'un point unique. Ce mode
haute fiabilité augmente la stabilité de l'ensemble du système.

2.2.5.17 HSS doit permettre à SIP AS / OSA-SCS de mettre à jour les données
transparentes (référentiel) et / ou non transparentes stockées au HSS pour une
identité d'utilisateur public IMS ou une identité de service public spécifiée.

2.2.5.18 HSS doit permettre à l'UE d'indiquer sa capacité de service au réseau central, et
le réseau peut indiquer la capacité de service de l'UE à UE par l'identifiant de
service de communication IMS.

2.2.5.19 HSS doit fournir une fonction d'ensemble de profils de service pour améliorer
l'efficacité de l'approvisionnement. HSS permet aux opérateurs qui ont des
autorisations différentes d'ajouter, de supprimer, de modifier et d'interroger le
profil de service.

2.2.5.20 Le système HSS doit enregistrer toutes les informations exploitées dans le
terminal d'approvisionnement qui permet d'interroger et d'analyser facilement
les problèmes.

2.2.5.21 HSS doit identifier l'IMPU de la session d'urgence et prévoir un processus

spécial pour ce type d'IMPI.

2.2.5.22 HSS doit prendre en charge le HSS virtuel, prend en charge la gestion des
autorités en fonction de l'emplacement et du groupe de services, différents
opérateurs ont des droits différents et il n'est possible d'accepter le
fonctionnement que pour des opérateurs dans la plage de droits actuelle.

2.2.5.23 Les FE et BE du HSS devraient prendre en charge tous les mécanismes de

redondance suivants:

 1+1 Master/Slave Backup

All rights reserved. No spreading without permission of ZTE. 39

 Modèle vIMS RFI&RFP

 1+1 Mutual Backup

 N+1 Master/Slave Backup

 N+K Redundancy

40 All rights reserved. No spreading without permission of ZTE.

 Modèle vIMS RFI&RFP

2.2.6 MMTel AS/SCC AS

2.2.6.1 Le fournisseur doit prendre en charge MMTel AS et SCC AS intégré.

2.2.6.2 MMTel AS proposé doit prendre en charge la fonction MRFC intégrée ou

indépendante.

2.2.6.3 MMTel AS doit prendre en charge la fonction GWF, qui fonctionne avec S-CSCF
pour fournir une interface de charge Ro.

2.2.6.4 MMTel AS doit fournir la fonction de passerelle de messages courts (IP-SM-

GW). Il permet l'interfonctionnement de messages courts entre les utilisateurs
du domaine CS et du domaine IMS.

2.2.6.5 MMTel AS doit supporter la fonction IM-SSF, pour s’interfonctionner avec IN

traditionnel.

2.2.6.6 MMTel AS doit prendre en charge l'interface ISC avec S-CSCF pour le
déclenchement de service défini dans la spécification 3GPP 23.218.

2.2.6.7 MMTel AS doit fonctionner en mode B2BUA pour la gestion des services.

2.2.6.8 MMTel AS doit prendre en charge le service de traitement par URI TEL et URI
SIP pour le numéro E.164.

2.2.6.9 MMTel AS doit prendre en charge l'interface Sh avec HSS pour récupérer /
mettre à jour les données du service d'abonné.

2.2.6.10 MMTel AS doit prendre en charge l'interface standard IMS Rf comme dans
3GPP TS 32.299, 3GPP TS 32.260.

All rights reserved. No spreading without permission of ZTE. 41

 Modèle vIMS RFI&RFP

2.2.6.11 MMTel AS doit supporter le contrôle de surcharge de CPU.

2.2.6.12 MMTel AS devrait prendre en charge l'interface Ro standard IMS comme dans
3GPP TS 32.299 3GPP TS 32.260.

2.2.6.13 MMTel AS devrait prendre en charge les modes automatiques (détection de lien
avec message OPTIONS) et manuel configuré. Le transfert du maître vers
l'esclave AS et le transfert en retour sont pris en charge. Le MMTel AS doit
prendre en charge la redondance maître / esclave 1 + 0, ce qui signifie que le
transfert ne se produit qu'en cas de défaillance du maître. Le MMTel AS devrait
prendre en charge la redondance de partage de charge 1 + 1. Dans ce mode,
l'AS partage la charge de service entre maître et esclave avec une certaine
stratégie, ce qui améliore l'efficacité des ressources.

2.2.6.14 La solution MMTEL doit prendre en charge, mais sans s'y limiter, les fonctions
suivantes décrites dans la directive GSMA IR.92, et fournir la même expérience
utilisateur 3G CS et GSM aux utilisateurs du domaine IMS:
a) Originating Identification Presentation 3GPP TS 24.607
b) Terminating Identification Presentation 3GPP TS 24.608
c) Originating Identification Restriction 3GPP TS 24.607
d) Terminating Identification Restriction 3GPP TS 24.608
e) Communication Forwarding Unconditional 3GPP TS 24.604
f) Communication Forwarding on not Logged in 3GPP TS 24.604.
g) Communication Forwarding on Busy 3GPP TS 24.604
h) Communication Forwarding on not Reachable 3GPP TS 24.604
i) Communication Forwarding on No Reply 3GPP TS 24.604
j) Barring of All Incoming Calls 3GPP TS 24.611
k) Barring of All Outgoing Calls 3GPP TS 24.611
l) Barring of Outgoing International Calls 3GPP TS 24.611
m) Communication Hold 3GPP TS 24.610
n) Communication Waiting 3GPP TS 24.615

42 All rights reserved. No spreading without permission of ZTE.

 Modèle vIMS RFI&RFP

2.2.6.15 SCC AS doit supporter SRVCC/eSRVCC service.

2.2.6.16 La solution MMTEL doit supporter Ut interface pour UE pour modifier les
données de services.

2.2.6.17 MMTel AS doit supporter la description de service dans Annex A.

2.2.6.18 MMTel AS doit supporter Network API qui est basé sur le protocole HTTP défini
par OMA pour que le tiers fournisse ensemble des services intégrés.

2.2.6.19 MMTel AS doit prendre en charge la fonction de réacheminement lorsque

l'utilisateur de l'appelé n'est pas enregistré ou n'est pas accessible dans IMS.
MMTel AS peut ajouter un préfixe devant le numéro de l'appelé et réacheminer
vers CS pour connecter l'utilisateur.

2.2.6.20 MMTEL/SCC AS doit prendre en charge la reconnaissance d'une certaine

logique de service (par exemple, logique MMTEL ou logique SCC) qui doit être
appliquée en fonction du paramètre "AS URI" contenu dans le champ d'en-tête
Route de la demande INVITE que l'AS reçoit.

2.2.6.21 MMTEL/SCC AS doit prendre en charge l'enregistrement d'un tiers unique

envoyé par CSCF vers la collecte de MMTEL TAS et SCC AS, et il n'a pas
besoin d'enregistrement séparé vers MMTEL AS et SCC-AS.

2.2.6.22 MMTE/SCC AS doit prendre en charge les fonctionnalités VoWiFi améliorées: 1)

VoWiFi T-ADS (sélectionne directement le WiFi pour la logique T-ADS et ne
demande pas le HSS lorsque les utilisateurs accèdent au réseau IMS via le
WiFi); 2) fonction de nouvelle tentative CS en cas d'échec de l'appel VoWiFi; 3)
Politique de charge différente pour le WiFi et le LTE.

All rights reserved. No spreading without permission of ZTE. 43

 Modèle vIMS RFI&RFP

2.2.6.23 MMTE/SCC AS doit prendre en charge la récupération très efficace des

données utilisateur sur l'interface Sh. Par exemple, il envoie un message UDR
transportant plusieurs ServiceIndications au HSS pour la récupération de
plusieurs informations de services ou envoie un message UDR transportant
plusieurs DataRefs au HSS pour la récupération de plusieurs données
d'abonné.

2.2.6.24 SCC AS doit supporter eSRVCC/aSRVCC/bSRVCC/rSRVCC et eSRVCC pour

les statuts appel en attente ou maintien d’appel.

2.2.6.25 MMTel AS doit prendre en charge une interface reposante pour permettre à une
application tierce d'invoquer la capacité de MMTEL AS.

2.2.7 MGCF/IM-MGW

2.2.7.1 Le fournisseur doit confirmer séparément pour l'interface Nb et Mb la prise en

charge du codec WB-AMR.

2.2.7.2 Le fournisseur doit confirmer séparément pour l'interface Nb et Mb la prise en

charge du codec suivant: G.711 A-law/G.711 µ-law/G.729/G.729A/ G.729B/T.38

2.2.7.3 Le fournisseur doit fournir des informations si TFO est pris en charge dans l'IM-
MGW conformément à 3GPP TS 28.062.

2.2.7.4 Le fournisseur doit fournir des informations si la fonctionnalité TFO est prise en
charge avec le codec suivant: GSM HR, GSM FR, GSM EFR, WB AMR, HR
AMR, FR AMR.

2.2.7.5 Le fournisseur doit fournir des informations si l'IM-MGW prend en charge

l'interfonctionnement TFO / TrFO conformément au 3GPP TR 23.977.

44 All rights reserved. No spreading without permission of ZTE.

 Modèle vIMS RFI&RFP

2.2.7.6 Les éléments du réseau central CS doivent prendre en charge la

synchronisation à partir de sources d'horloge externes. La source d'horloge
pourrait être soit un serveur d'horloge fournissant une synchronisation à partir
d'une source fiable, par ex. GPS, ou ce pourrait être une horloge avec une
précision suffisante (par exemple. Caesium clock).

2.2.7.7 Le fournisseur doit confirmer la prise en charge du marquage Diffserv dans le

MGCF.

2.2.7.8 Le MGCF et MGW doit prendre en charge la configuration des VLAN.

2.2.7.9 Le fournisseur doit décrire les capacités de routage du MGCF pour prendre en
charge la fonction de transit, comme décrit dans 3GPP TS 24.229.

2.2.7.10 Le fournisseur doit détailler toute procédure de routing, ex. Routing on “calling
called party address” resp. on “p-asserted id” “request URI”.

2.2.7.11 Le fournisseur doit indiquer et décrire la capacité déjà mise en œuvre de la

prise en charge MGCF et IM-MGW sur les interconnexions vers le RTPC /
RNIS, la procédure de base de limitation de l'écho conformément aux normes
UIT ISUP. Le fournisseur doit également décrire le plan de mise en œuvre de
cette fonctionnalité.

2.2.7.12 MGCF doit être capable de générer des données de facturation, soit en
générant des Charging Data Records (CDRs) ou en utilisant / envoyant des
messages de diamètre.

2.2.7.13 Le MGCF doit gérer les appels en cours dans des situations de surcharge.

2.2.8 MRFC/MRFP

All rights reserved. No spreading without permission of ZTE. 45

 Modèle vIMS RFI&RFP

2.2.8.1 Le MRFC doit prendre en charge les ressources multimédias et le contrôle des
supports conformément au 3GPP TS 23.002, tels que l'annonce multimédia, la
conférence, le processus DTMF, la fonction de transcodage vocal.

2.2.8.2 MRFC doit contrôler MRFP via l'interface Mp.

2.2.8.3 MRFC doit prendre en charge l'interface Mr vers l'I / S-CSCF et les
comportements fonctionnels associés.

2.2.8.4 Le soumissionnaire doit indiquer le degré de conformité aux normes et décrire

les écarts par rapport aux normes.

2.2.8.5 MRFP doit prendre en charge le traitement des ressources et des supports
multimédias conformément à la norme 3GPP TS 23.002, comme le contrôle des
supports et des ressources, le mixage des supports et le contrôle de l'étage.

2.2.8.6 MRFP doit supporter G.711 codec.

2.2.8.7 The MRFP doit supporter G.729 codec.

2.2.9 Charging

2.2.9.1 Le fournisseur doit indiquer si le charging hors ligne et en ligne est prise en
charge.

2.2.9.2 Pour le charging hors ligne, le système proposé devrait recevoir le CDR du NE
(tel que S-CSCF, MGCF, etc.) et un mécanisme de stockage flexible en plus du
stockage du CDR basé sur le NE. Le fournisseur doit décrire le détail.

2.2.9.3 Le système de charging proposé devrait prendre en charge les points de

référence Rf / Ro / Bx standard.

46 All rights reserved. No spreading without permission of ZTE.

 Modèle vIMS RFI&RFP

2.2.9.4 Le fournisseur doit décrire le format des CDR livrés au système de billing
(ASN.1, ASCII, Binary, etc).

2.2.9.5 Le système de charging proposé devrait fournir un système de gestion de

fichiers CDR convivial pour l'exploitation et la maintenance des CDR.

2.2.9.6 Le système de charging proposé devrait générer les CDR en fonction, mais
sans s'y limiter, de la taille du fichier CDR, de l'intervalle de temps, etc.

2.2.9.7 Le système de charging proposé devrait prendre en charge la fonction de fusion

CDR pour fusionner les CDR partiels d'une session IMS en un CDR. Et la
fonction de consolidation CDR doit être fournie pour combiner plusieurs
enregistrements de détail en un seul enregistrement complet détaillé.

2.2.9.8 Le système de charging proposé devrait fournir une fonction de filtrage CDR
pour traiter les données CDR collectées conformément aux exigences de XXX
OPERATOR.

2.2.9.9 Le système de charging proposé devrait être utilisé à la fois pour le domaine
IMS / PS.

2.2.9.10 Tous les composants x-CSCF, xGCF et le proxy SIP IETF doivent être capables
de générer des événements de charging.

2.2.9.11 Tous les composants x-CSCF, xGCF et le proxy SIP IETF doivent prendre en
charge le mécanisme de charging hors ligne.

2.2.9.12 Tous les composants x-CSCF, xGCF et le proxy SIP IETF doivent prendre en
charge la génération d'événements de facturation à des fins de comptabilité
avec des tiers (réseau de desserte en cas d'itinérance (roaming), fournisseurs
de services d'application, partenaires d'interconnexion PLMN et RTPC).

All rights reserved. No spreading without permission of ZTE. 47

 Modèle vIMS RFI&RFP

2.2.9.13 Tous les composants x-CSCF, xGCF et le proxy SIP IETF doivent prendre en
charge le charging en fonction du temps pour les sessions SIP.

2.2.9.14 Tous les composants x-CSCF, xGCF et le proxy SIP IETF doivent prendre en
charge le charging basée sur les événements pour les sessions SIP.

2.2.9.15 Le composant S-CSCF doit prendre en charge la génération d'événements de

taxation aux fins de la taxation du client final.

2.2.9.16 Aucun événement de facturation de composants autres que le S-CSCF ne sera

nécessaire aux fins de charging basée sur le temps ou sur l'événement des
sessions SIP du client final.

2.2.9.17 Tous les composants x-CSCF, xGCF et le proxy SIP IETF doivent contenir CDF
(Charging Data Function) comme spécifié dans les spécifications de charge
3GPP.

2.2.9.18 Tous les composants x-CSCF, xGCF et le proxy SIP IETF peuvent contenir la
fonction CGF (Charging Gateway Function). Cela signifie que les composants
produiront CDRs (Call Data Records).

2.2.9.19 Les composants x-CSCF, xGCF et le proxy SIP IETF peuvent partager un ou
plusieurs CGF communs.

2.2.9.20 La perte et la corruption de données de charging doivent être inférieures à 1x

10-6 du total des volumes CDR collectés sur une période de 365 jours.

2.2.9.21 Les paramètres de décalage horaire doivent être pris en charge pour tous les
horodatages définis dans ETSI 3GPP TS 32.225 pour les changements d'heure
d'été. Ajustez les heures de fermeture / réponse / fin et durée pour éviter les
horodatages antérieurs aux horodatages de demande / ouverture et début.

48 All rights reserved. No spreading without permission of ZTE.

 Modèle vIMS RFI&RFP

2.2.9.22 Le fournisseur doit s'assurer que la charge en double ne se produit pas et est
gérée correctement de bout en bout dans des conditions normales et d'échec /
défaillance. Cela doit inclure le stockage et la suppression des données
comptables en double dans la mémoire volatile et non volatile, le transfert CDR
vers la médiation »et la messagerie ACR (drapeau T) et prendre en charge les
mécanismes de détection des doublons conformément à ETSI 3GPP 32.225.

2.2.9.23 Le fournisseur doit prendre en charge les fonctions de vérification des erreurs et
de validation sur le terrain des contenus CDR avant leur transfert par FTP ou
GTP »vers la médiation.

2.2.9.24 Le fournisseur doit décrire la vérification des erreurs effectuée sur chaque
champ et inclure les détails des valeurs par défaut ajoutées par l'entité IMS.

2.2.10 ENUM/DNS

2.2.10.1 Le vendeur doit prendre en charge l'application ENUM à mettre en œuvre en

tant qu'application convergente DNS / ENUM dans UDC FE.

2.2.10.2 L'ENUM doit prendre en charge au moins les exigences spécifiées par ETSI /
TISPAN telles que décrites dans le document «ETSI ETS 102 172 - Exigences
minimales pour l'interopérabilité des implémentations ENUM.

2.2.10.3 L'ENUM doit prendre en charge l'URI Tel tel que défini dans IETF RFC 3966
L'URI Tel pour les numéros de téléphone.

2.2.10.4 L'ENUM doit prendre en charge les requêtes / réponses ENUM conformément
au numéro IETF RFC 2916 E.164 et DNS.

2.2.10.5 L’ENUM doit être conforme à IETF RFC 2915 The Naming Authority Pointer
(NAPTR) DNS Resource Record.

All rights reserved. No spreading without permission of ZTE. 49

 Modèle vIMS RFI&RFP

2.2.10.6 ENUM doit prendre en charge au moins deux enregistrements NAPTR par
abonné.

2.2.10.7 La base de données ENUM doit se comporter comme une fonction ENUM Tier-
2 et doit avoir la capacité de démarrer une requête récursive vers les serveurs
ENUM Tier-0 et / ou Tier-1 en fonction du nom de domaine.

2.2.10.8 Le traitement des requêtes NAPTR de l'ENUM doit être au moins 100 000 fois
par seconde.

2.2.10.9 ENUM doit prendre en charge la fonction de liste noir / blanc / gris.

2.2.10.10 doit prendre en charge la correspondance partielle de l'enregistreur NAPTR.

2.2.10.11 ENUM doit prendre en charge la requête récursive / itérative.

2.2.10.12 ENUM doit prendre en charge la fonction de cache; le résultat de la requête

d'un autre ENUM doit être stocké dans le cache local, afin de répondre
rapidement.

2.2.10.13 ENUM doit prendre en charge la fourniture de réponses DNS et ENUM aux
requêtes respectives en fonction de l'expéditeur de la demande. L'ENUM doit
soutenir le concept des «vues».

2.2.10.14 ENUM doit prendre en charge les requêtes vers les bases de données de
portabilité des numéros mobiles (MNP) existantes au moyen par exemple de:
MAP ATI ou SRI comme spécifié dans 3GPP TS 23.066. Le fournisseur doit
décrire en détail comment la solution est réalisée, par exemple décrivant
l'interface et le protocole.

2.2.10.15 ENUM doit prendre en charge l'interface basée sur LDAP pour la requête de
données MNP.

50 All rights reserved. No spreading without permission of ZTE.

 Modèle vIMS RFI&RFP

2.2.10.16 ENUM doit prendre en charge une interface d'approvisionnement pour

permettre l'intégration avec les systèmes d'approvisionnement existants. Le
fournisseur doit indiquer les protocoles pris en charge pour l'approvisionnement.

2.2.11 AGCF

2.2.11.1 AGCF doit supporter ISDN BRA access, ISDN PRA access, V5ISDN access,
H248 access, SIP access, MGCP access, NCS access, V5 access.

2.2.11.2 AGCF doit fournir la capacité d'accès pour ISDN/ISUP PBX, CAS PBX, IETF
SIP PBX, etc.

2.2.11.3 AGCF ne doit pas avoir la limite de la quantité de AGW si la quantité d'abonné
ne dépasse pas la capacité du système.

2.2.11.4 AGCF doit pouvoir prendre en charge le fax / modem initié par les utilisateurs
A / R-MGF ou par CSCF.

2.2.11.5 AGCF doit prendre en charge la fonction P-Early-Media.

2.2.11.6 AGCF doit être en mesure de prendre en charge la fonction de détection du

heartbeat entre AGCF et la passerelle, la fonction de détection du heartbeat
entre AGCF et CSCF.

2.2.11.7 AGCF doit adopter la même plate-forme matérielle avec d'autres composants
IMS tels que CSCF, PSS, HSS etc.

2.2.11.8 AGCF doit être mis en œuvre sur la base de l'ETSI TS 182 012 pour la
passerelle de média d'accès contrôlant.

2.2.11.9 AGCF doit prendre en charge les abonnés POTS et RNIS sur MSAN.

All rights reserved. No spreading without permission of ZTE. 51

 Modèle vIMS RFI&RFP

2.2.11.10 AGCF doit prendre en charge ISDN PRI sur MSAN.

2.2.11.11 AGCF doit effectuer l'interconnexion de signalisation entre la signalisation SIP et

la signalisation analogique.

2.2.11.12 L'AGCF doit fonctionner en tant qu'agent utilisateur SIP avec d'autres
composants IMS.

2.2.11.13 L'AGCF doit prendre en charge l'interface Mw avec d'autres composants IMS
CSCF.

2.2.11.14 L'AGCF doit prendre en charge l'interface Mx vers l'IBCF.

2.2.11.15 L'AGCF doit prendre en charge l'interface Ut vers le serveur d'applications.

2.2.11.16 L'AGCF doit prendre en charge l'interface P1 vers la passerelle média.

2.2.11.17 L'AGCF doit fournir le couple libre entre l'AGCF et l'AS.

2.2.11.18 L'AGCF doit prendre en charge la fourniture du modèle de tonalité approprié.

2.2.11.19 L'AGCF doit prendre en charge le traitement des événements de mi-appel et les
envoyer au noyau IMS pour le traitement des services.

2.2.11.20 L'AGCF doit prendre en charge la progression de l'enregistrement comme un

UE IMS SIP suivant la procédure d'enregistrement 3GPP.

2.2.11.21 L'AGCF doit prendre en charge l'authentification de ligne individuelle.

52 All rights reserved. No spreading without permission of ZTE.

 Modèle vIMS RFI&RFP

2.2.11.22 L'AGCF doit prendre en charge l'authentification d'un ensemble de lignes

appartenant à un groupe d'enregistrement IMS au moyen d'une seule phase
d'enregistrement.

2.2.11.23 L'AGCF doit prendre en charge la préconfiguration d'un ou plusieurs

identificateurs pour le contenu du P-Visited-Network-Id header field.

2.2.11.24 L'AGCF doit prendre en charge la configuration de la carte numérique et peut

envoyer la carte numérique à MSAN lorsque MSAN est enregistré.

2.2.11.25 L'AGCF doit prendre en charge le mécanisme de commandes de code de

service (SCC) tel que défini dans ETSI TS 183 043.

2.2.11.26 L'AGCF doit prendre en charge le mécanisme de commande d'ordre de

commutation (SOC) tel que défini dans ETSI TS 183 043.

2.2.11.27 L'AGCF doit prendre en charge la configuration du numéro d'urgence.

2.2.11.28 L'AGCF doit prendre en charge la trace de signalisation pour les messages
H.248 et SIP.

2.2.11.29 L'AGCF prend en charge la redondance géographique.

2.2.11.30 AGCF doit supporter T.30 Fax operation.

2.2.11.31 AGCF doit supporter T.38 Fax operation.

2.2.11.32 AGCF doit supporter le mécanisme de négociation des capacités.

2.2.11.33 AGCF doit supporter les services supplémentaires ci-dessous pour les abonnés
H.248 / MGCP :

All rights reserved. No spreading without permission of ZTE. 53

 Modèle vIMS RFI&RFP

 Identification / restriction du numéro appelant

 Identification / restriction des numéros connectés

 Suivi des appels malveillants

 Maintien de l’appel

 Appel en attente

 Service tiers

 Service de refus d'appel anonyme

 Renvoi d'appel inconditionnel

 Renvoi d'appel si pas de réponse

 Renvoi d'appel si occupé

 Renvoi d'appels non enregistré / hors ligne

 Service de sonnerie différenciée

 Restriction des appels entrants

 Restriction des appels sortants

3 Annexe A

Service SUpplémetaire
Service Description

Il est fourni à l'appelé: le numéro

Originating Identification
d'appel entrant ou le nom de l'appelant
Presentation (OIP)
peut être affiché à l'appelé.

54 All rights reserved. No spreading without permission of ZTE.

 Modèle vIMS RFI&RFP

Service Description

Il est fourni à l'appelant: après avoir

souscrit au service OIR, l'identification
Originating Identification
de l'appelant n'est pas présentée à
Restriction (OIR)
l'appelé, même si l'appelé a souscrit au
service OIP.
Le numéro ou l'identification de
l'appelant sera toujours présenté à
OIR Override
l'appelé même si l'appelant a souscrit
au service OIR.
Originating Name Le nom de l'appelant (préconfiguré) est
Presentation présenté à l'appelé.
Terminating Identification Il est fourni à l'appelant: l'identification
Presentation (TIP) de l'appelé est présentée à l'appelant.
Elle est fournie du côté de l'appelé:
Terminating Identification l'identification de l'appelé n'est pas
Restriction (TIR) affichée à l'appelant après la
souscription au service.
Le numéro ou l'identification de l'appelé
sera toujours présenté à l'appelant
TIR Override
même si l'appelé a souscrit au service
TIR.
Anonymous Il refuse les appels sans informations
Communication Rejection sur l'appelant si l'appelé souscrit au
(ACR) service ACR.
Pour le MCID permanent, chaque appel
entrant sera enregistré. Les
Malicious Communication informations d'appel enregistrées
Identification (MCID) comprennent: le numéro de l'appelant,
Permanent Mode l'URL de l'appelant, le numéro de
l'appelé, l'URL de l'appelé et la durée
de l'appel.

All rights reserved. No spreading without permission of ZTE. 55

 Modèle vIMS RFI&RFP

Service Description

Pour le MCID temporaire, une fois

l'appel répondu, l'appelé peut suivre
Malicious Communication
l'identification de l'appelant en
Identification (MCID)
composant un code d'accès spécifique.
Temporary Mode
Le système envoie le message
d'alarme à O&M et est enregistré.
Transfère automatiquement l'appel
entrant vers une autre cible en fonction
de la préconfiguration de l'appelé. Il
existe 4 types de services: renvoi
Communication
d'appel si occupé renvoi d'appel si pas
Diversion(CDIV)
de réponse, renvoi d'appel
inconditionnel (renvoi de tous les
appels) et renvoi d'appel si l’abonné
hors ligne.
Les appels entrants sont transférés
vers différents numéros cibles en
fonction des différents types de
supports. Il est applicable à CFU, CFB,
CDIV par Media
CFNRy, CFNRd, CFNRc. Par exemple,
un appel vidéo + vocal est transféré
vers le numéro C, mais un appel vocal
peut être transféré vers le numéro D.
Les appels entrants de différents
appelants sont renvoyés vers différents
numéros cibles. Par exemple, un appel
CFU par l'appelant anonyme est renvoyé vers le numéro
C, et l'appel entrant de B est renvoyé
vers le numéro D, et les autres appels
entrants sont acceptables.
Un appel entrant anonyme est transféré
Renvoi d'appel anonyme
vers un autre numéro.

56 All rights reserved. No spreading without permission of ZTE.

 Modèle vIMS RFI&RFP

Service Description

Il est déclenché lors de l'établissement

de la session (INVITE a été envoyé au
terminal, mais sans réponse). Cela
Communication Deflection dépend de l'utilisateur de prendre la
décision: transférer ou non et quel type
de transfert. Il prend en charge CFU,
CFB et CFNRy.
Lorsque l'appelé est occupé, l'appel
entrant peut être transféré vers
CFB par l'appelant différents numéros cibles en fonction de
l'appelant différent, 5 numéros cibles
maximum peuvent être pris en charge.
L'appelé peut configurer 2 numéros de
transfert: A et B. Lorsque l'appelé est
Transfert de communication
occupé, l'appel entrant est renvoyé vers
occupé vers deux parties
A, et il sera renvoyé vers B si A est
également occupé.
Les appels entrants sont renvoyés vers
différents numéros à différents
CFU by Time moments selon la configuration de
l'appelé. Il prend en charge un
maximum de 5 numéros cibles.
Le CF implicite comprend 4 types de
CF: Renvoi d'appel si pas de réponse,
Renvoi d'appel si occupé, Renvoi
d'appel si hors ligne et Renvoi d'appel
Implicit Communication
si inaccessible. Tous les 4 types de CF
Forwarding
ci-dessus seront activés lorsque
l'utilisateur souscrit un service de renvoi
d'appel implicite (Implicit
Communication Forwarding).

C'est un service côté appelant. Lorsque

Completion of l'appelé est occupé, l'appelant
Communications to Busy demande au système d'appeler des
Subscriber (CCBS) deux côtés lorsqu'il détecte que l'appelé
est inactif.

All rights reserved. No spreading without permission of ZTE. 57

 Modèle vIMS RFI&RFP

Service Description

L'appelant est limité à effectuer certains

types d'appels, tels que les appels
nationaux et internationaux.
Il prend également en charge les
Interdiction de scénarios suivants:
communication sortante Interdiction des appels sortants en
fonction de l'heure: les appels sortants
seront interdits pendant une période
spécifique; le statut de l'appel entrant
reste le même.
Tous les appels entrants sont interdits.
L'appelant sera informé d'une annonce
telle que: "Désolé, le numéro que vous
avez composé n'est pas disponible,
veuillez l'essayer plus tard ..."
Interdiction de
Il prend également en charge les
communication entrante
scénarios suivants:
Appel entrant basé sur le temps interdit:
l'utilisateur ne sera pas dérangé
pendant un temps spécifique, le statut
de l’appel sortant reste le même.
Liste noire sortante: l'appelant n'est pas
autorisé à appeler des numéros
spécifiques. L'appel entrant n'est pas
affecté et l'appel d'urgence n'est pas
Liste noire entrante /
restreint.
sortante
Liste noire entrante: l'utilisateur n'est
pas autorisé à recevoir l'appel entrant
des numéros spécifiques. L'appel
sortant n'est pas affecté.

58 All rights reserved. No spreading without permission of ZTE.

 Modèle vIMS RFI&RFP

Service Description

Liste blanche sortante: l'utilisateur n'est

autorisé à appeler que des numéros
spécifiques, l'appel entrant n'est pas
affecté et l'appel d'urgence ne sera pas
Liste blanche entrante /
restreint.
sortante
Liste blanche entrante: l'utilisateur est
limité à recevoir l'appel entrant de
numéros spécifiques. L'appel sortant ne
sera pas affecté.
Le système rejette l'appel entrant
Anonymous
anonyme et renvoie le message
Communication Rejection
d'erreur à l'appelant, ce qui indique que
(ACR)
l'appelé rejette l'appel.
DND: Les appels entrants sont limités.
DND limité: les appels entrants sont
limités pendant une période spécifique.
Do Not Disturb Mais le DND ne sera pas valide si
l'appelant active la fonction
«remplacement de l'ensemble de
services».
Restriction des
Le système rejette l'appel lorsque
communications entrantes -
l'utilisateur est appelé.
Opérateurs contrôlés
Interdiction de
Le système rejette l'appel lorsque
communication sortante -
l'utilisateur tente de passer l'appel.
Opérateurs contrôlés

All rights reserved. No spreading without permission of ZTE. 59

 Modèle vIMS RFI&RFP

Service Description

Une fois souscrit au service ONLY ,

l'utilisateur peut avoir plusieurs
numéros de terminal liés (numéro A, B,
C, etc.) et choisir l'un d'entre eux (par
exemple: numéro A) comme numéro
public. A est le numéro principal de
ONLY .
One Number Link You L'appelant ONLY signifie que l'appelant
(ONLY) peut appeler depuis n'importe quel
terminal parmi les 4 terminaux liés,
mais seul le numéro principal (numéro
A) sera présenté à l'appelé.
Appelé ONLY signifie que tous les
terminaux liés sonnent simultanément
ou en séquence si le numéro principal
(par exemple: Numéro A) est appelé.

L'utilisateur peut interroger l'heure en

Report of Time(RT)
composant un code d'accès spécial.

Les utilisateurs peuvent composer un

Self Number Reporting code spécial pour demander le numéro
E.164 du terminal actuel.

Le terminal sonne à l'heure indiquée

Service d’alarme
comme rappel (alarme) à l'utilisateur.

Il est fourni à l'appelant. Lors de la

définition du service, l'appelant peut
toujours composer avec succès l'appelé
d'une manière normale, même si
Communication Override
l'appelé définit le transfert d'appel ou
service ne pas dérangé (DND). À ce
moment, le renvoi d'appel ou le DND ne
sont pas invalide.

Les utilisateurs réalisent la composition

Numérotation abrégée du code de destination réel en
composant le «** code d'abréviation».

60 All rights reserved. No spreading without permission of ZTE.

 Modèle vIMS RFI&RFP

Service Description

Lorsque ce service est activé, les

autres utilisateurs entendent un
Service d'abonné absent message comme: «le numéro que vous
composez ne répond pas, veuillez
rappeler plus tard”.
Le service Advice Of Charge (AOC)
AoC informe l'UE des informations de
charging.

Service IP Centrex
Service Description

Intra-group Short Les abonnés de même groupe peuvent

Number Call composer directement les numéros de poste.
Intra-group Long Les abonnés de même groupe peuvent
Number Call également composer les numéros longs.
L'appelant est un utilisateur de groupe,
l'appelé n'est pas un utilisateur de groupe,
Intra-group Outgoing l'appelant peut composer directement le
Call numéro de l'appelé ou ajouter un préfixe au
numéro.
Le numéro de préfixe peut être configuré.
Inter-group Incoming Les appels entrants hors groupe proviennent
Call d'abonnés ordinaires hors groupe vers des
utilisateurs de groupe. Actuellement, il existe
trois modes.1. Les abonnés hors groupe
ordinaires composent un grand nombre
(numéros nationaux valides) d'utilisateurs du
groupe pour les appels directs.
2. Les abonnés hors groupe composent le
numéro de ligne pilote des utilisateurs du
groupe et sont connectés aux utilisateurs du
groupe par la console OPR de l'ordinateur.
3. Les abonnés hors groupe composent le
numéro de ligne pilote des utilisateurs du
groupe et sont connectés aux utilisateurs du

All rights reserved. No spreading without permission of ZTE. 61

 Modèle vIMS RFI&RFP

groupe par la console OPR manuelle.

Les utilisateurs B et C sont le même groupe,
lorsque B et A (inter-groupe ou intra-groupe)
Call Park sont en dialogue, B peut maintenir A et
connecter C, puis C converse avec A et B
quitte le dialogue.
Les utilisateurs A et B sont dans le même
groupe centrex, l'utilisateur B souscrit au
«Service de prise d'appel dirigé intra-
Intra-Group Directed
groupe», lorsqu'il n'y a pas de réponse pour
Call Pickup Service
l'appel entrant de A, B peut répondre à partir
de son propre téléphone par une opération
spécifique.
Les utilisateurs A et B sont dans le même
groupe centrex, l'utilisateur B souscrit au
Dedicated Call "Service de prise d'appel dédié", lorsqu'il n'y
Pickup Service a pas de réponse à l'appel entrant de A, B
peut répondre à partir de son propre
téléphone par une opération spécifique.
Lorsque le groupe est appelé, le système
peut choisir un utilisateur au sein du groupe
pour répondre à l'appel selon une certaine
stratégie (séquence, priorité, inactif ou
Call Group by Turns
simultanément). En cas d'échec, le système
choisira le prochain utilisateur en fonction de
la stratégie, jusqu'à ce que quelqu'un
ramasse ou atteigne la limite maximale.
Le type d'utilisateur est un utilisateur IP
Centrex. Si l'utilisateur A active ce service et
affecte l'utilisateur B comme standard
Personal Attendant personnel, alors tous les appels entrants pour
Service l'utilisateur A peuvent être connectés vers
l'utilisateur B, après filtré par l'utilisateur B,
l'appel sera transféré vers l'utilisateur A ou B
peut le traiter directement .
Opérateur Le système peut recevoir le numéro saisi par
automatique l'appelant via la voix analogique, de sorte que
l'appel peut être acheminé vers le poste
souhaité. L'appel entrant peut être renvoyé

62 All rights reserved. No spreading without permission of ZTE.

 Modèle vIMS RFI&RFP

vers un ou plusieurs groupes centrex par un

opérateur automatique; en outre, l'appel
vidéo et l'appel de données (support audio
inclus) peuvent également être transférés
vers la destination.
Le numéro de l'appelant peut être configuré
comme «Numéro complet», «Numéro
OIP for Outgoing
d'opérateur» ou «Numéro d'opérateur +
Group Call
numéro de poste». Le format par défaut est
«Numéro complet».
Originating
Identique à l'OIP dans les services
Identification
supplémentaires.
Presentation
Terminating
Identique à TIP dans les services
Identification
supplémentaires.
Presentation
Identique à OIR dans les services
OIR
supplémentaires.
Identique à TIR dans les services
TIR
supplémentaires.
Identique à DND dans les services
Do not Disturb
supplémentaires.
IP Centrex Service Identique à override setting dans les services
Override Setting supplémentaires.
Identique à CB dans les services
Call Barred
supplémentaires.
Malicious Call Identique à MCID dans les services
Identification supplémentaires.
IP Centrex Restrict
Identique aux services supplémentaires.
Destination Code
IP Centrex Connect
Specific Destination Identique aux services supplémentaires..
Code
Not Available for
Identique aux services supplémentaires.
Incoming Call

Not Available for Identique aux services supplémentaires.

All rights reserved. No spreading without permission of ZTE. 63

 Modèle vIMS RFI&RFP

Outgoing Call
Lorsque la liste noire ou blanche du groupe
est configurée, tous les utilisateurs du groupe
Group Black/White
ne sont pas autorisés à composer le numéro
List
dans la liste noire, ou ils peuvent uniquement
composer le numéro dans la liste blanche.
IP Centrex
Anonymous Call Identique aux services supplémentaires.
Rejection(ACR)
Call Forward when Identique à CDIV de services
Busy supplémentaires.
Call Forward Identique à CDIV de services
Unconditional supplémentaires.

Call Forward when Identique à CDIV de services

no reply supplémentaires.

Call Forward when Identique à CDIV de services

unreachable supplémentaires.

Call Forward when Identique à CDIV de services

not available supplémentaires.

Call Waiting Identique à CW de services supplémentaires.

Call Holding Identique à CH de services supplémentaires.
Call Transfer Identique à CT de services supplémentaires.
Identique à N-PARTIE de services
N-Party
supplémentaires.
Identique à Abbreviation dialing de services
Abbreviation dialing
supplémentaires.
Identique à ONLY de services
ONLY
supplémentaires.
L'utilisateur peut dire qu'il s'agit d'un appel
Differential Ringing
inter-groupe ou intra-groupe.

64 All rights reserved. No spreading without permission of ZTE.